RE: JavaMemoryModel: Major yuck! GET/PUTSTATIC prohibitsreordering

From: David Holmes (dholmes@ics.mq.edu.au)
Date: Sun Nov 14 1999 - 16:24:11 EST


> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of David Detlefs -
> 1) Do whatever barriers are necessary, all the time, in the
> interpreter. If you're doing a lot of interpretation, you're not
> interested in high performance, so performance in the interpreter
> isn't very critical (see Ole Agesen and my upcoming PLDI submission).

I was thinking along these lines on the way home Friday.

If all methods must be executed at least once by the interpreter then all
class loading and initialisation will be done via the interpreter. Hence by
the time a method using (A.x+B.x) is compiled we are guaranteed that
initialisation has already taken place and so static fields can be treated
just like instance fields and the compiled code can do whatever reordering
it likes (within the other rules of course).

As Dave said the interpreter puts in all necessary sync and memory barriers
etc. At some point during execution of an INVOKE* bytecode the decision has
to be made as to whether we go to the interpreter or a compiled version of
the method. If the latter then again we have a place to ensure that all
necessary sync is in place.

One thing I'm learning about VM design is that the path from bytecode to
machine instructions can be a long one. :)

Cheers,
David

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:23 EDT