Re: JavaMemoryModel: No "Spooky errors at a distance"

From: Clifford Click (
Date: Fri Mar 08 2002 - 15:17:23 EST

Jerry Schwarz wrote:
> I anticipated Bill's subsequent message containing an example of a compiler
> optimization that feature 2 would prohibit. (That is, I didn't know exactly
> what the example would be, but I anticipated there would be one). Now the
> difference between feature 2 and feature 2' become clear. In Bill's
> example if we accept feature 2 then the optimization would be disallowed.
> If we accept feature 2' then the example doesn't contain [fill in the
> blank] so feature 2' doesn't apply and we can say (as I anticipate Cliff
> will say) that any behavior is acceptable for code containing
> unsynchronized references.

Indeed. I've been keeping quiet on this thread and waiting to see
how it falls out. So far, I see these issues:
(1) Person writes junk code and gets bit. No big deal.
(2) Person calls on a 3rd party library, which is junk, and gets
bit. Annoying, but calling 3rd party code is always fraught with
danger - if the library doesn't perform as advertised you are
screwed anyways. Hence, there's no more risk here than there
always was, nor will disallowing "poisoned" references from
escaping the library significantly lower the risk.

Unconditionally turning off CSE isn't an option; too much performance
lost to save too rare a case. I'm hoping that we either live with
this problem, or discover a [fill in the blank] that's appropriate.


Cliff Click           Chief Architect, HotSpot Server   Sun Microsystems, Inc.
Cliff.Click@Sun.COM   Senior Staff Engineer             4150 Network Circle
(408) 276-7046        MS USCA14-102                     Santa Clara, CA 95054
JavaMemoryModel mailing list -

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