[Exp] First prototype of new acmp bytecode

[John Rose]

On Mar 8, 2018, at 8:39 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> I think this is stable enough to be pushed to the Exp branch. Any objections?

This is a great success, I think.  You are using microbenchmarks
with a very high frequency of acmp operations, and still it is hard
to find a signal from the extra ALU operations, and all the signals
you do find are not very bad.

Yes, it's time to push this.

On Mar 9, 2018, at 2:02 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> The problem is that with type speculation, C2 adds an uncommon trap (Java call) and although that
> trap is never taken, we now need stack banging at method entry (see Compile::need_stack_bang()):
> 
> 0x00007f62f8ea5f40: mov    %eax,-0x14000(%rsp)
> 
> I've verified that disabling stack banging brings back performance (almost - it seems like method
> size has also an impact) but the implicit null check does not improve performance in this case.

Interesting.  I'm sure we'll see lots more stuff like this.  It doesn't
worry me much; I think it is controllable.

Excellent progress!

— John

P.S. Years ago when we started, one of the factors that decided us to
investigate QRU-world was the fear that we could never hide the
Q-types flowing through acmp.  This fear led me to advocate, for a
time, for "heisenboxes" whose distinctive property was that their
acmp behavior was somewhat indeterminate, as if the acmp
instruction were not updated—because I had doubts we could
update it without losing lots of performance.

Well, you have supplied significant evidence that we don't need
heisenboxes, and we don't need explicit Q-types.  Surely there
are other dragons to be slain in L-world, such as mixing flat
and non-flat arrays, but this was the one that I was most afraid
of.

Example from 2012, before we invented Q-types:
https://blogs.oracle.com/jrose/value-types-in-the-vm <https://blogs.oracle.com/jrose/value-types-in-the-vm>
Sample:
> If a value type is represented by a JVM reference, that reference
> cannot be successfully synchronized on, and cannot be usefully
> compared for reference equality.  A value type can be viewed in terms
> of what it doesn’t do. We can say that a value type omits all
> value-unsafe operations, which could violate the constraints on value
> types. These operations, which are ordinarily allowed for Java object
> types, are pointer equality comparison (the acmp instruction),
> synchronization (the monitor instructions), …