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

Dean Long dean.long at
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 
> <mailto:dean.long at>> 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.


More information about the hotspot-dev mailing list