Design notes for next values iteration

Maurizio Cimadamore maurizio.cimadamore at
Wed Nov 22 11:46:17 UTC 2017

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 

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.


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.
> 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

More information about the valhalla-spec-observers mailing list