From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-patches-return-19209-listarch-java-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12525 invoked by alias); 22 Aug 2008 12:51:48 -0000
Received: (qmail 12513 invoked by uid 22791); 22 Aug 2008 12:51:47 -0000
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 12:50:54 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) 	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m7MCopep025663; 	Fri, 22 Aug 2008 08:50:52 -0400
Received: from zebedee.pink (vpn-13-116.rdu.redhat.com [10.11.13.116]) 	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7MCogYG016573; 	Fri, 22 Aug 2008 08:50:42 -0400
Message-ID: <48AEB621.9090006@redhat.com>
Date: Sun, 24 Aug 2008 01:46:00 -0000
From: Andrew Haley <aph@redhat.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: Bryce McKinlay <bryce@mckinlay.net.nz>
CC: Java Patch List <java-patches@gcc.gnu.org>,         Jakub Jelinek <jakub@redhat.com>, Lillian Angel <langel@redhat.com>
Subject: Re: Remove data race in libgcj interpreter
References: <48AD67B2.4040308@redhat.com> <7230133d0808220510n5626ea9fx2a372af41925de77@mail.gmail.com>
In-Reply-To: <7230133d0808220510n5626ea9fx2a372af41925de77@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <java-patches.gcc.gnu.org>
List-Subscribe: <mailto:java-patches-subscribe@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/java-patches/>
List-Post: <mailto:java-patches@gcc.gnu.org>
List-Help: <mailto:java-patches-help@gcc.gnu.org>, <http://gcc.gnu.org/ml/#faqs>
Sender: java-patches-owner@gcc.gnu.org
X-SW-Source: 2008-q3/txt/msg00053.txt.bz2

Bryce McKinlay wrote:
> On Thu, Aug 21, 2008 at 2:03 PM, Andrew Haley <aph@redhat.com> wrote:
> 
>> I've discovered a nasty data race in libgcj's interpreter.
>>
>> It is the cause of several bug reports, in particular
>> https://bugzilla.redhat.com/show_bug.cgi?id=458921
>>
>> An optimization rerwites instructions of the form
>>
>>  invokespecial <constant pool index>
>>
>> to
>>
>>  invokespecial_resolved <address>
>>
>> the first time that each invokespecial is encountered.
>>
>> However, in the presence of multiple threads this breaks.
> 
> Ahh, yeah. I remember this bug:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8995
> 
> As Tom suggests, the proper fix may be to do all the rewriting in the
> compile phase, which is protected by a lock.

Ah right, thanks.  It's rather appalling that we once knew about this
bug but didn't fix it, preferring a fast interpreter to a correct one.
Thankfully, my name doesn't appear on any of the comments!  :-)

> There is at least one other interpreter bug which shows up only on
> multi-core systems:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902

Thanks.

Andrew.