We shouldn't try to read too much into the tea leaves of the JLS,
because parts of it are not clear, and they don't really take this
situation into account.
For the 2nd edition of the JVM spec, the discussion of class
initialization was substantially rewritten. Here is part of the
discussion:
>5.5 Initialization
>
>Initialization of a class or interface consists of invoking its static
>initializers (§2.11) and the initializers for static fields (§2.9.2)
>declared in the class. This process is described in more detail in
>§2.17.4 and §2.17.5.
>
>A class or interface may be initialized only as a result of:
>
> The execution of any one of the Java virtual machine
> instructions new, getstatic, putstatic, or invokestatic that
> references the class or interface. Each of these instructions
> corresponds to one of the conditions in §2.17.4. All of the
> previously listed instructions reference a class directly or
> indirectly through either a field reference or a method
> reference. Upon execution of a new instruction, the
> referenced class or interface is initialized if it has not been
> initialized already. Upon execution of a getstatic, putstatic,
> or invokestatic instruction, the class or interface that
> declared the resolved field or method is initialized if it has
> not been initialized already.
>
> Invocation of certain reflective methods in the class library
> (§3.12), for example, in class Class or in package
> java.lang.reflect.
>
> The initialization of one of its subclasses.
>
> Its designation as the initial class at Java virtual machine
> start-up (§5.2).
>
>Prior to initialization a class or interface must be linked, that is,
>verified, prepared, and optionally resolved.
OK, so this pretty clearly states that invoking a virtual method
cannot cause a class to be initialized.
At 3:15 PM -0700 7/9/99, Paul Haahr wrote:
>that the Class object contains state that
> indicates one of four situations:
>
Note that a thread cannot view a Class object in a consistent, final
state unless that thread has done a memory barrier (on relaxed memory
order machines).
At 3:15 PM -0700 7/9/99, Paul Haahr wrote:
>I suspect it's possible to determine that the Class
>object is fully initialized without doing any memory barriers. (We can
>all imagine variants of the double-check idiom which get there.)
You could detect that some other thread thinks that the Class is
fully initialized. But your thread wouldn't be guaranteed a
consistent view of the fully initialized class without either a
memory barrier, or some per-thread data structure that tells the
thread which classes it has seen fully initiallized (the first time a
thread T1 determines that a class has been initialized by another
thread T2, the thread T1 needs to do a memory barrier. For later
actions by T1 that need to verify that the same class is initialized,
if T1 can determine that it has already checked the class, it can
skip the memory barrier).
So if
> * This Class object is fully initialized and ready for use.
is interpreted as "Some thread thinks the Class is fully
initialized", then we don't have class initialization safety. If
> * This Class object is fully initialized and ready for use.
is interpreted as "_This_ thread has a fully initialized view of the
Class", then we need lots of memory barriers and other complications
on relaxed memory order systems.
And, of course, there is the problem with virtual method invocations.
If we don't add them to the list of things that are guaranteed an
initialized class, then we also loose class initialization safety.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:16 EDT