This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Remove data race in libgcj interpreter
- From: "Bryce McKinlay" <bryce at mckinlay dot net dot nz>
- To: "Andrew Haley" <aph at redhat dot com>
- Cc: "Java Patch List" <java-patches at gcc dot gnu dot org>, "Jakub Jelinek" <jakub at redhat dot com>, "Lillian Angel" <langel at redhat dot com>
- Date: Fri, 22 Aug 2008 13:10:58 +0100
- Subject: Re: Remove data race in libgcj interpreter
- References: <48AD67B2.4040308@redhat.com>
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