From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19138 invoked by alias); 15 Mar 2006 17:17:28 -0000 Received: (qmail 19118 invoked by uid 48); 15 Mar 2006 17:17:28 -0000 Date: Wed, 15 Mar 2006 17:17:00 -0000 Message-ID: <20060315171728.19117.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/8995] race cases in interpreter In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "tromey at gcc dot gnu dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2006-q1/txt/msg00386.txt.bz2 List-Id: ------- Comment #3 from tromey at gcc dot gnu dot org 2006-03-15 17:17 ------- Despite what the original report says, we don't really want to resolve all entries when compiling. Also it would be best to avoid any kind of synchronization at all. One idea would be to 'or' the argument to one of these instructions with 0x1 when the datum is unresolved. This can be tested reasonably quickly. And, since these lookups are all idempotent, it does not matter if two threads happen to do a small amount of redudant lookup work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8995