Here's one set of, no doubt controversial, opinions:
0) (Uncontroversial, I hope.) I think it's great that we got to a point at which
we actually agree on most of the substance of this proposal. I'd also like
to thank especially Bill, Jeremy, and Sarita for getting us this far.
Unfortunately, I have some serious remaining concerns, but they are
mostly related to the presentation.
1) So long as we don't have volatile array elements, I suspect there will be
many incorrectly synchronized programs that greatly outperform the correctly
synchronized versions. Thus I think incorrectly synchronized programs are
important, even aside from bugs and malicious programs. We need to specify their
semantics.
2) I think the causality discussion and the comparison of the different models
is almost certainly the most interesting research aspect of this work. And it
needs to be correctly specified somewhere. But (putting aside the JSR rules,
on which I'm not an expert), I'm not convinced that it's the most important piece
to get right before a public comment period. It seems unlikely to impact current
implementations much. Nor does it seem likely to me that it will seriously break
a lot of client code. (It would be wonderful to have examples of real code that
cares about more than type-safety.)
3) Unless I'm having an unusual amount of difficulty with this, I think it is
important to have a final field semantics that is more precise than the current
informal semantics and easier to understand than the recursive set equations.
AFAICT, this piece has a potentially major impact on current implementations
(often a full memory barrier per constructor, plus possible restrictions
on CSE which I don't yet understand). It also has a significant effect on
correctness of client code, although I don't think it's likely to break existing code
in practice. Since AFAIK, synchronized constructors are not part of this proposal,
it's painful for a user to work around anything we get wrong.
4) I'm still waiting for clarification on, or revision of, the last sentence of the proposal
dealing with finalizers, which I think unintentionally imposes a serious optimization
constraint. It would be nice to do this for the public comment version, since the
exact formulation has some impact on client code. I think this is less critical than
the final fields discussion
Hans
> -----Original Message-----
> From: victor.luchangco@sun.com [mailto:victor.luchangco@sun.com]
> Sent: Thursday, July 31, 2003 1:31 AM
> To: javamemorymodel@cs.umd.edu
> Subject: JavaMemoryModel: How bad are incorrectly
> synchronized programs?
>
>
>
> On Tuesday, I was strongly disabused of the notion that we might want
> to provide guarantees to help programmers write correct but
> incorrectly
> synchronized code. Nonetheless, in talking with some people, I still
> get the impression that they want to be able to write incorrectly
> synchronized programs in some particular (and very restricted) cases.
> So I have the following question:
>
> Assuming we had the technology, would we want to rule out incorrectly
> synchronized programs? That is, suppose the compiler determines that
> there is a data race in your program. Should it refuse to compile
> your program (as it would if the program were badly typed)? If not,
> why not? (Remember, we're assuming that we can decide whether a
> program is correctly synchronized, just like it decides whether a
> program is well-typed--no false positives or negatives.)
>
> Victor
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:49 EDT