Libjava failures status

[Boehm, Hans]

My take on this is that the compiler has two choices:

1) It can load foo only once, in which case it only has to check for null
once, since it can't possibly see a null foo for the load of foo.b, or
2) it can load foo twice, in which case the null check has to be performed
twice.

I don't believe the proposed Java semantics would require the read to be
repeated even if foo were declared volatile.  Reusing the result of the
first read is not distinguishable from two reads that immediately follow
each other.  Unlike C, Java "volatile" is not designed for device register
accesses.

I copied Bill Pugh, in case he wants to disagree.

Hans 

> -----Original Message-----
> From: Eric Blake [mailto:ebb9@email.byu.edu]
> Sent: Tuesday, March 12, 2002 10:01 AM
> To: tromey@redhat.com
> Cc: Bryce McKinlay; Jan Hubicka; Anthony Green; gcc@gcc.gnu.org;
> java@gcc.gnu.org
> Subject: Re: Libjava failures status
> 
> 
> Tom Tromey wrote:
> > 
> > Bryce> a = foo.a;
> > Bryce> b = foo.b;
> > 
> > Bryce> Then obviously the second load from foo can not trap.
> > 
> > Unless foo is a field and is changed by another thread.
> > Maybe this case is undefined if we haven't synchronized?
> 
> I'm not so sure about this case.  Chapter 17 of the JLS (and thus
> chapter 8 of JVMS) is currently under revision,
> http://jcp.org/jsr/detail/133.jsp, so multi-thread semantics are not
> presently set in stone.  But my personal take on the matter 
> is that the
> compiler is allowed to assume foo.b cannot trap iff foo is not
> volatile.  Without a synchronized block or volatile reference 
> to force a
> memory flush, the compiler is free to used a cached version of foo
> rather than reloading the (possibly changed) field.
> 
> -- 
> This signature intentionally left boring.
> 
> Eric Blake             ebb9@email.byu.edu
>   BYU student, free software programmer
>