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
-- 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 - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:38 EDT