Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long
christian.thalinger at oracle.com
Thu Jun 18 16:02:20 UTC 2015
> On Jun 15, 2015, at 9:13 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Jun 15, 2015, at 8:57 PM, Dean Long <dean.long at oracle.com> wrote:
>> Thanks for the explanation. It sounds like we are modeling the abstract Java stack representation of long and double, and this wouldn't be
>> easy to change, because I see things like "TypeFunc::Parms + 1" and "argument(2)" that would need to change before this could go away.
> Indeed. Slot pairs are a mess, an optimization (or concession) for platforms that no longer matter. (Primitives might look like that in a few years.) Some messes in HotSpot stem (IMO) from excessive attention to the bytecode syntax, designing a managed execution engine around the oddities of a code format.
> In an ideal world, I would like to isolate, deprecate, and eventually remove the "evil twin" slots, since they no longer have any meaning (except maybe on some 32-bit systems). Doing it at all levels will be hard, except in the context of some other breaking change. But it could be done locally in the JVM, removing the notion of twin slots from modules that don't have an absolute need to work with them. JITs shouldn't have to know about them, IMO; maybe not even the interpreter (though that would involve a renumbering prepass).
> When we get value types, we may be able to make such a change, even to the bytecode syntax itself. Or perhaps we will perpetuate the "evil twin" convention, but apply it to all value types (plus long and double). Or perhaps (happy thought) we can make every value/ref/prim occupy one stack slot, in some bytecode of the future.
I’m all for happy thoughts :-)
> — John
More information about the hotspot-dev