Re: JVM optimization

John C. Bollinger wrote:
>
> I can't speak for Mark or Chris, but I insist that the behavior of a
> Java program must be among those consistent with the language
> specification, inasmuch as can be observed. How is one to write
> programs with predictable behavior if one cannot rely on the specs? You
> can argue that the specs are inconvenient or poorly conceived. Indeed,
> the JSR 133 working group did precisely that, and came up with what
> appears to be a significant improvement. If you are really supporting
> implementation of JVM / program behavior that is observably inconsistent
> with the spec, however, then we are indeed at an impasse, and this
> discussion cannot progress.

It seems that we are at the 'agree to disagree' stage. However, you added some parting
shots below, which I will respond to.

> Assuming that you are not arguing for outright VM non-compliance, you
> seem to be arguing for different semantics than Java has chosen, even in
> the new memory model. That's fine, but I don't think I can reason with
> you about the relative merits of your preferred semantics vs. Java's
> specified semantics (or about whether there is a difference at all)
> without considerably more detail on what your preferred semantics
> actually are. Unless you're prepared to pledge support for one of the
> existing models, that would amount to you more or less presenting a
> whole memory model of your own, at least in outline. I'm guessing that
> (the latter) won't happen.

No, I'm not arguing for a new memory model. The 'purpose' of the current (1.5) memory
model is to ensure proper utilization of shared variables within shared synchronization
blocks. Like most technical writing, it concerns itself with the mechanism rather than
describing its purpose, its reason for existing. In order to cover the general case, it
includes all shared variables (because of 'anonymous' locks). The fact that this
mechanism also affects shared variable access outside the synchronized sections is a an
unavoidable side effect. Depending on this side effect is very dicey coding and
is improper/obtuse code. It can only be guaranteed to avoid stale values in extreme
cases. Instead of referencing shared variables outside synchronized sections, a better
technique would be to store the current value in a local variable inside the
synchronized section for use outside the synchronization. Our system uses that exact
technique to improve concurrency.

I'm not arguing for a new memory model. To achieve the capability I'm referring to would
require the memory model spec add a section saying that a compiler could violate
covering all shared variables when it knew it was 'safe'. That would just clutter the
spec, just like the JLS section that says that *all* objects are allocated on the heap
doesn't bother saying, "Oh, if the compiler is smart enough, it can violate this
principle." It would have to add this in a lot of places, diluting the spec. The spec is
intended to enforce a minimum level of compliance, to ensure the expectations of correct
execution by even the most complex Java application are met.

No, I'm not arguing for outright VM non-compliance but for an "as if" reading of the
spec. In my view, you're being overly rigid in this aspect (there has been a goodly
amount of authoritarianism on this forum recently), since you can't describe a case
where expecting special behavior of shared variables outside synchronization sections
would be justified or useful.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
.

Relevant Pages

  • Re: JVM optimization
    ... I am arguing, however, that the JLS specifies synchronization semantics that affect shared variables that are referenced outside synchronized blocks, and that this is intentional and consistent. ... This means that the specs place requirements that go beyond the intended purpose of synchronization, but that isn't any justification for ignoring those parts of the spec that we don't like. ... *correctness* of the potential optimization; ...
    (comp.lang.java.programmer)
  • Re: C#, Threads, Events, and DataGrids/DataSets
    ... Jon asked me to weigh in on the memory model issue below. ... there is enough wiggle room in the spec to cause grief. ... so the JIT compiler can know special things about it). ... memory cell will be access cross thread without synchronization). ...
    (microsoft.public.dotnet.general)
  • Re: When is "volatile" used instead of "lock" ?
    ... obscure post by Vance does nothing to clarify the spec for everyone else, including those writing JITs on other platforms or for other processors. ... I'd comment more on what Vance posted; but we're talking about the spec, not what was implemented--it clearly doesn't follow the spec to the letter already. ... True, the CLR V2 and JIT compilers do not strictly follow the ECMA specs "memory model", the V2 CLR is currently based on a redesigned memory model, and it's the first implementation of the CLI that targets X64 and IA64, The ECMA specs. ...
    (microsoft.public.dotnet.languages.csharp)