JavaMemoryModel: Efficient class initialization is _very_ hard

From: Bill Pugh (pugh@cs.umd.edu)
Date: Thu Nov 11 1999 - 21:26:17 EST


Whenever a thread T performs a NEW, GETSTATIC,
PUTSTATIC or INVOKESTATIC on class C, we need to
check to see if the class is initialized. If we can
determine that thread T has already checked to see
if C is initialized, we are done. Otherwise, we
need to check. If it isn't initialized, we need to
initialize. If some other thread initialized it,
we need to:

        perform a memory barrier and reload
        all values cached in registers

Yuck!

This is _very unpleasant_. If we set aside the
strong class initialization stuff I talked about
in August, we even need to include these checks
in instance methods.

So what do we do? In native code, you can't patch
the code to eliminate the initialization check until
you are guaranteed that all existing threads have
performed the memory barrier and reloaded. Doing any sort
of check to see "has my thread seen the initialization of
this class" is going to be tricky.

The strong class initialization stuff I talked about
earlier won't work. The problem is that while we can
perform an operation to force the results of class
initialization into the cache of all processors,
we can't force the results into the registers of all
threads.

The Sun interpreter is, as usual, badly broken for
weak memory models. It patches the opcodes to eliminate
the check as soon as the first thread executes the opcode.
The problem is that other threads still need to perform
the initialization check so that they do the required memory
barrier.

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



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