[aarch64-port-dev ] Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long
Dean Long
dean.long at oracle.com
Tue Jun 16 03:57:05 UTC 2015
On 6/15/2015 5:26 PM, John Rose wrote:
> On Jun 15, 2015, at 5:07 PM, Dean Long <dean.long at oracle.com
> <mailto:dean.long at oracle.com>> wrote:
>>
>> This may be a dumb (but hopefully related) question, but why do we
>> need to add top() for _LP64:
>>
>> 4364 #ifdef _LP64
>> 4365 #define XTOP ,top() /*additional argument*/
>> 4366 #else //_LP64
>> 4367 #define XTOP /*no additional argument*/
>> 4368 #endif //_LP64
>>
>> 4396 make_runtime_call(RC_LEAF|RC_NO_FP,
>> 4397 OptoRuntime::fast_arraycopy_Type(),
>> 4398 StubRoutines::unsafe_arraycopy(),
>> 4399 "unsafe_arraycopy",
>> 4400 TypeRawPtr::BOTTOM,
>> 4401 src, dst, size XTOP);
>>
>> And why only for"size", but not "src" and "dst"?
>
> That is one of the awkward places we jam in LP64-specific code.
> Java has no size_t type; the closest it gets is "long".
> But the compiler uses Java types to set up runtime stub call signatures.
> So if we want the compiler to pass a size_t value to a stub, it has to
> pass a long on !LP64 and int on ILP32.
> (There's no need for an int-in-a-long here, since size_t is never 32
> bits on an int-in-a-long machine.)
> To complete the embarrassment, the compiler has an internal convention
> of always representing the twin word for longs and doubles (see JVMS).
> Net result is that if you want to ask for a size_t in the JIT on LP64,
> you have to #ifdef in a jlong, and pass a "top" twin word.
> — John
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.
dl
More information about the aarch64-port-dev
mailing list