RE: JavaMemoryModel: Interaction between the memory model and exc eptions, Tread.stop()

From: Boehm, Hans (hans.boehm@hp.com)
Date: Thu Apr 08 2004 - 18:10:54 EDT


As far as I can tell, requiring the precise exception model for Thread.stop()
wouldn't require any memory barriers. Any exception handler would be executed
in the same thread, and would thus see memory operations preceding the exception
in that thread.

(I wasn't reading the current spec as saying anything about ordering with
respect to other threads. I think that's the correct reading, especially since
I don't think there's any way to have such a requirement make sense in our world.
It might not hurt to clarify that.)

If you do require precise handling of Thread.stop(), I think you need to do one
of:

(1) Defer Thread.stop() handling to the next "safe point", and avoid compiler
reordering around safe points, or

(2) (If there is no notion of safe point) Avoid any observable compiler reordering
at all.

(3) Provide lots of recovery code to undo the damage when you see an exception.

Only option (1) sounds remotely tolerable to me, and it would be very painful for
VMs that don't otherwise need safe points. And even (1) sounds rather expensive,
since the only thing you get in return is the preservation of a fundamentally
broken construct. (And you're probably increasing the failure rate of clients
of that broken construct by only a trivial percentage.)

I'm not sure any existing VMs do anything to make Thread.stop() precise.
(I'm pretty sure gcj/gij doesn't.) Perhaps some other implementers can comment.

Hans

> -----Original Message-----
> From: Vijay Saraswat [mailto:vijay@saraswat.org]
> Sent: Thursday, April 08, 2004 2:37 PM
> To: Boehm, Hans
> Cc: javamemorymodel-cs.umd.edu
> Subject: Re: JavaMemoryModel: Interaction between the memory model and
> exc eptions, Tread.stop()
>
>
> Boehm, Hans wrote:
>
> >I agree that this should be discussed explicitly, and hasn't
> been discussed sufficiently.
> >
> >My impression is that the precise exception model should be
> preserved for synchronous exceptions,
> >and it never really existed for asynchronous ones. If
> everyone agrees with that, we're arguably
> >done, though perhaps the JLS should really state that only
> synchronous exceptions are precise.
> >
> What is the cost of implementing the precise exception model
> on modern
> multiprocessors? Is it fairly pointless to go to all this length
> specifying what should happen in the presence of race
> conditions when in
> fact implementing the precise exception model might be the
> more onerous
> burden? (because e.g. it forces the introduction of barriers at every
> JVM instruction that might potentially throw an exception.)
>
> I have no idea, I am asking for illumination ...hopefully someone on
> this list has thought this through...
>
> The Memory Model semantics will have to say something about it. For
> instance, take any of our 20-odd Tests. Somewhere in the loop
> in which a
> read sees an out-of-order write put in an instruction that
> potentially
> throws an exception. Does this force a barrier of some sort
> so that in
> fact that read cant see the write?
>
> I haven't thought this through, it just worries me that at this late
> stage of the game there are no test cases that cover this potentially
> tricky area of interaction. If someone can lay these worries to rest,
> great, otherwise there is more work to be done.
>
> Best,
> Vijay
>
> PS: Just got hold of
http://citeseer.ist.psu.edu/gupta00optimizing.html
-- will look at it overnight.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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