Re: JavaMemoryModel: What's "control dependence" mean?

From: Jan-Willem Maessen (jmaessen@alum.mit.edu)
Date: Fri Sep 14 2001 - 10:18:53 EDT


I wrote:
> >Nonsense. The only thing that could possibly be prohibited in
> >practice is _reordering_ based on this information; we wouldn't be
> >able to tell if we did all sorts of other transformations (like
> >removing exception handlers and exception points, eliding tests,
> >etc.). We can simplify as much as we like.

And Bill Pugh <pugh@cs.umd.edu> responded:
> OK, you can actually eliminate the null-pointer check or array bounds
> check. But you need to leave in place a compiler memory barrier that
> prevents the compiler from reordering around a location where you've
> determined an exception cannot occur.
>
> Furthermore, on processors that allow a read to be reordered with a
> following write, you may need to issue a memory fence/barrier
> instruction.
>
> VM implementors will not be happy about this, since it seems so
> completely useless. I doubt you could get VM implementor to generate
> the appropriate compiler memory barriers.

It seems like you have something else in mind. Could you reiterate
what you would like to happen in these cases? And compare it with
what happens in the case of other control- and data-dependent
operations? Where do you want to draw the line, and how do you plan
on formalizing the distinction?

As I said elsewhere in the message quoted above, semantics need to
exist independent of program transformation---if the semantics
restrict reordering after a program transformation, either we need to
deal with it, or we need to ask what semantics we really want. Next
week, a new program transformation will be invented; Java programmers
will be none the wiser, and the system still needs to behave
explicably.

That said, how big is the impact in practice? My impression is that
most null pointer checks, etc. can be resolved using purely local
information (and indeed that doing so was crucial to performance).
It's a pain to insert the ordering constraints, sure, but what real
performance impact does it have? For example, I suspect, but don't
know, that the main benefit of related field analysis is in
eliminating comparisons and conditional traps/branches, and the extra
flexibility in instruction scheduling isn't a huge win. Does anyone
have data either way? Keith?

-Jan-Willem Maessen
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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