OK, stepping aside from the details of what the VM spec requires,
I'd like to suggest that we should provide either of two kinds
of class initialization safety:
* Weak Class Initialization Safety
- Before a thread T1 invokes a NEW, GETSTATIC, PUTSTATIC or
INVOKESTATIC opcode on a class C, thread T1 must attempt
to initialize C (defined below).
* Strong Class Initialization Safety
- In addition to the above, if T1 invokes a invokevirtual or
invokespecial that resolves to a method defined in class C,
thread T1 must attempt to initialize C.
How thread T1 attempts to initialize class C:
- if thread T1 can guarantee that thread T1 has already attempted
to initialize C, it may perform a no-op.
- otherwise, it must perform the steps described in section
2.17.5. These steps include getting a lock, which acts
as a memory barrier. Therefore, if as a result of 2.17.5
T1 believes C has been initialized by another thread, T1 will
see all of the effects of that initialization.
Place where weak and strong class initialization differ:
Assume that the class initializer for Bar changes Foo.x
and that an instance method for Bar reads Foo.x. Then
the instance method could see a stale value for Foo.x.
Implementation note: Under weak initialization, in instance
methods for a class C, you can't assume that C has been initialized.
Before executing a NEW, GETSTATIC, PUTSTATIC or INVOKESTATIC opcode
on class C, you need to check to see if it is.
I believe the current spec boils down to requiring weak class initialization
safety, but that isn't a big issue.
Bill Pugh
-------------------------------
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