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
