[Exp] First prototype of new acmp bytecode
tobias.hartmann at oracle.com
Thu Mar 15 08:47:12 UTC 2018
On 15.03.2018 05:52, John Rose wrote:
> 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.
Thank you! I've pushed the changes to the exp branch. I think we can soon add them to lworld as well.
> Interesting. I'm sure we'll see lots more stuff like this. It doesn't
> worry me much; I think it is controllable.
Yes, I think so too.
> 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
> Example from 2012, before we invented Q-types:
>> 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), …
More information about the valhalla-dev