This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: java aliasing rules
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: tromey at redhat dot com, Dan Nicolaescu <dann at godzilla dot ics dot uci dot edu>, java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Sun, 31 Mar 2002 11:03:52 +1200
- Subject: Re: java aliasing rules
- References: <Pine.LNX.4.10.10203300926250.5677-100000@mars.deadcafe.org>
Jeff Sturm wrote:
>>The optimal, correct code for
>>Java is really something like:
>>
>>lhz r9, [ps1.f1]
>>addi r9,r9,1
>>sth r9, [ps1.f1]
>>
>
>Wouldn't accessing r9 immediately after the load cause a pipeline stall?
>Assuming an in-order processor? That would be a significant performance
>hit.
>
Right, its not optimal scheduling, but there's no way to avoid that and
still have the correct behaviour for NullPointers. And as you suggest, a
modern processor may be speculativly executing the following loads, so
it probibly doesn't matter too much.
>Come to think of it, what happens on an out-of-order processor (e.g.
>Alpha EV6) when an instruction traps? Are preceding instructions
>guaranteed to have completed? I'm curious.
>
No matter what re-ordering the hardware does internally, everything must
be seen to be executed sequentially. So if an instruction traps while
being executed out of order, any following instructions (eg in the
signal handler) that depend on results of instructions before the trap,
must see the results of them having been run.
regards
Bryce.