From: "Bryce McKinlay" <bryce@mckinlay.net.nz>
To: "Andrew Haley" <aph@redhat.com>
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
Date: Fri, 22 Aug 2008 12:51:00 -0000 [thread overview]
Message-ID: <7230133d0808220510n5626ea9fx2a372af41925de77@mail.gmail.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2008-08-22 12:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 13:31 Andrew Haley
2008-08-21 21:54 ` Andrew Haley
2008-08-22 12:12 ` gij: more thread-safety fixes Andrew Haley
2008-08-22 12:51 ` Bryce McKinlay [this message]
2008-08-24 1:46 ` Remove data race in libgcj interpreter Andrew Haley
2008-09-04 16:00 ` Andrew Haley
2008-09-04 16:12 ` David Daney
2008-09-04 16:25 ` Andrew Haley
2008-09-04 18:37 ` David Daney
2008-09-05 9:39 ` Boehm, Hans
2008-09-05 11:28 ` Andrew Haley
2008-09-06 9:26 ` Hans Boehm
2008-09-08 17:42 ` Andrew Haley
2008-09-22 14:25 ` Andrew Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7230133d0808220510n5626ea9fx2a372af41925de77@mail.gmail.com \
--to=bryce@mckinlay.net.nz \
--cc=aph@redhat.com \
--cc=jakub@redhat.com \
--cc=java-patches@gcc.gnu.org \
--cc=langel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).