----- Original Message -----
From: "Cliff Click" <cliff.click@eng.sun.com>
To: "Steve Kautz" <skautz@newmonics.com>
Sent: Monday, February 05, 2001 11:20 AM
Subject: Re: JavaMemoryModel: fusing synch blocks
> Steve Kautz wrote:
>
> > Your mention of Hotspot makes me want to clarify the following - are we
> > talking about fusing synch blocks at the bytecode level or at runtime in
a
> > dynamic compiler?
> > --Steve K
>
> I'm talking about runtime in a dynamic compiler, but I suppose the issues
are the same.
>
> Cliff
>
>
Yes and no. I am curious what other people think about this. As it stands
there are no guarantees in Java about liveness, fairness, timing,
scheduling, thread priorities, etc., so that, e.g., a compliant VM designed
for a certain purpose can use a non-preemptive scheduler or can map all
threads to the same priority or what have you. The other side of the coin
is that there are no limitations build into the language either; there is at
present nothing _preventing_ a vendor from implementing a VM that _does_
have explicit guarantees regarding fairness, scheduling, priorities, etc.
Now, if you are fusing synch blocks in a dynamic compiler that is hidden
inside a VM implementation, I don't think the JLS has anything to say about
it; it is just a question of whether you are happy with the VM's
performance. If you are optimizing for desktop apps, then a soft timing
constraint of "what looks good on a GUI" makes sense, and the way you allow
the compiler to choose when to coursen locks can be designed accordingly.
But fusing synch blocks at the bytecode level is (to my mind) a change in
the semantics of the language, and the JLS would have to explicitly say that
this is allowed and to what extent it is allowed, e.g., "at most 256
apparently trivial blocks can be fused", or "blocks can be fused as long as
the lock isn't held for more than 1/10 second", or something. The problem
is that now a bound on responsiveness and/or fairness has been imposed on
_all_ VM implementors. Speaking as someone who writes Java for embedded
controllers rather than desktop apps, a timing constraint defined by "what
looks good on a GUI" is not something our customers are going to be very
happy with. (Please note - I'm not talking about hard real-time; every
application has some kind of soft timing constraint that determines whether
it is, on average, performing "well". It just happens to be different for
fiber optic switches than for GUIs.) You might well argue that our
customers could just use some other Java compiler; that is certainly one
possible answer.
I've been mulling over Bill's suggestion:
> T1 T2
> for(;;) { synchronized(x) { a = 1; }
> synchronized(x) {
> if (a != 0) break;
> ... work ...
> }
>
> Under my rule, it would be legal for the compiler to transform the code
> for T1 to something like:
>
>
> monitorenter x
> L1:
> if (a != 0) goto L2
> ... work ...
> if (x.monitorContested()) {
> monitorexit x
> Thread.yield();
> monitorenter x
> }
> goto L1
> L2:
> monitorexit x
>
Let me try throwing out a similar suggestion. What if in the process of
combining synch blocks, the compiler were required to simply insert a
bytecode whose meaning could be loosely described as "here is where the
monitor release was in the original code". It would then be up to the VM to
decide how to interpret this bytecode - for some, it would be a no-op;
others could interpret it as an unconditional release/reacquire; but the
implementor would have the option, for example, of checking whether a higher
priority thread is waiting for the monitor.
Steve K
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT