Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long

[Lindenmaier, Goetz]

Hi,

I would like to ping again for my change.

I want to recall that this only extends the existing mechanism guarded
by CCallingConventionRequiresIntsAsLongs to multiplyToLen, CRC32, 
AES and SHA.

http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/
Could somebody please review this change?  I please need a sponsor.

Thanks and best regards,
  Goetz.



-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger
Sent: Donnerstag, 18. Juni 2015 18:02
To: John Rose
Cc: HotSpot Developers; aarch64-port-dev at openjdk.java.net
Subject: Re: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long


> 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