Design notes for next values iteration

[Maurizio Cimadamore]

great writeup - I like where this is going (although I'm a but afraid of 
"value invasions", as we're essentially redefining semantics of existing 
classfiles).

One thing that struck me as inconsistent is that we are enhancing almost 
all a- bytecodes to work with value types as well as reference types. 
But acmp is weird, as it always return false for values. I think I get 
where that is coming from (e.g. one possible way would be to do a 
bit-by-bit comparisons of the two values on the stack but, in doing so, 
we would tell as equal values that come from different classes but 
happen to have the same layout).

The thing that concerns me is that this model really really seems to 
want to tell the classfile users that there's no distinction between R 
and Q, and your old good L opcodes can be used freely in the new world 
too. But acmp is a place where the bytecode writer has to stop and 
think: am I operating on values? If so I need something else. This seems 
a sticking point in the design IMHO.

Maurizio




On 22/11/17 05:54, Dan Smith wrote:
> Following up on John's mail, here are some detailed notes about the design choices for "U types", and the concrete proposal we settled on last week.
>
> http://cr.openjdk.java.net/~dlsmith/values-notes.html
>
> John may have raised additional points I didn't cover in this document. I'll do another review of his mail and make any needed updates; or feel free to call them out. :-)
>
> —Dan