From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-patches-return-19208-listarch-java-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31379 invoked by alias); 22 Aug 2008 12:12:35 -0000
Received: (qmail 31122 invoked by uid 22791); 22 Aug 2008 12:12:16 -0000
X-Spam-Check-By: sourceware.org
Received: from mail-gx0-f17.google.com (HELO mail-gx0-f17.google.com) (209.85.217.17)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 12:11:01 +0000
Received: by gxk10 with SMTP id 10so1017864gxk.8         for <java-patches@gcc.gnu.org>; Fri, 22 Aug 2008 05:10:58 -0700 (PDT)
Received: by 10.150.12.3 with SMTP id 3mr1758314ybl.18.1219407058695;         Fri, 22 Aug 2008 05:10:58 -0700 (PDT)
Received: by 10.150.192.9 with HTTP; Fri, 22 Aug 2008 05:10:58 -0700 (PDT)
Message-ID: <7230133d0808220510n5626ea9fx2a372af41925de77@mail.gmail.com>
Date: Fri, 22 Aug 2008 12:51:00 -0000
From: "Bryce McKinlay" <bryce@mckinlay.net.nz>
To: "Andrew Haley" <aph@redhat.com>
Subject: Re: Remove data race in libgcj interpreter
Cc: "Java Patch List" <java-patches@gcc.gnu.org>,  	"Jakub Jelinek" <jakub@redhat.com>,  	"Lillian Angel" <langel@redhat.com>
In-Reply-To: <48AD67B2.4040308@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48AD67B2.4040308@redhat.com>
X-Google-Sender-Auth: 73ef05698fc3b692
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/msg00052.txt.bz2

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.

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