Someone else pointed out to me what was really going on. They looked at the
assembly the JIT created, and it turned out that the JIT assigned the
reference to refer to raw memory before running an inlined constructor to
initialize that memory. So there was a small window during which partially
constructed singletons could be seen.
While this sounds like buggy behavior, the Java Memory Model allows it. So
is this a bug? Does a relaxed memory model mean that Java environments are
allowed to cause problems that normally require a multiprocessor on a
uniprocessor?
I think the answers are that technically this is not a bug since the
behavior is consistent with the JMM. There is nothing that says that
reorderings of visibility can only take place on multiprocessors. So all
code must be careful in how it synchronizes no matter what machine it will
run on. These answers aren't very pleasant. Any other opinions?
--Paul
-----Original Message-----
From: David Holmes [mailto:dholmes@dstc.edu.au]
Sent: Thursday, May 25, 2000 5:30 PM
To: Paul Jakubik
Cc: jmm
Subject: Re: JavaMemoryModel: Problem on single processor
> As far as the Butenhof discussions go, they are very useful for
> understanding the multiprocessor problem, and I understand these issues.
> They don't address seeing this behavior on a uniprocessor.
You are right I was mistaken in my recollection. With no JVM in the process
the POSIX situation is simpler - though arguably an optimising C compiler
could perform similar reordering.
Of course there is always the possibility that the observed behaviour is
simply the result of a JIT bug.
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:25 EDT