[aarch64-port-dev ] System.arraycopy() intrinsics

[Andrew Dinn]

On 23/09/13 17:58, Andrew Haley wrote:
> On 09/23/2013 04:26 PM, Andrew Dinn wrote:
>> That requires adding
>>
>>    __ c_stub_prolog(3, 0, MacroAssembler::ret_type_void);
>>
>> at the start of StubGenerator methods generate_disjoint_copy(),
>> generate_conjoint_copy() and generate_checkcast_copy(). It also requires
>> changing the code above to remove the if/then clauses and only make the
>> VM_leaf call plus reverting some similar call in c1_LIRAssembler (to the
>> generic copy routine) back to a VM_leaf call. This restores both calls
>> to be as per the equivalent x86 code.
>>
>> The patch below fixes this problem in C2 by making the stubs x86
>> callable.
> 
> Oh yuck, that's disgusting.  Is there really no way that C2 can't just
> do what C1 does, and call via an x86 thunk only if it's absolutely
> necessary?
> 
> The arraycopy function should always be ARM code.  I'll grant
> ypu that it should not be an ExternalAddress -- that's just a
> mistake.

Well, it is a tad yucky but so is adding the code blob lookup to the
back end generator for CallRuntime (to anyone comparing the code to the
x86 version it not exactly very clear why we would be doing that). This
solution also avoids doing this codeblob lookup for every runtime call
-- unlike C1, where the lookup only happens when planting an arraycopy.
That's not an issue when running on the sime but it slows us down on
real hardware.

My main preference for this is that it means the code is now written the
way it will need to be once we decommision the sim. I would rather not
have to remember to take the lookup out and also revert the other calls
I changed in the posted diff. It will always be easy to spot and remove
the c_stub_prolog and blrt calls if/when we finally decide to
decommision the sim but leaving the above changes for later means
someone has to remember why the workaround code is there and recall
how/that it can be taken out.

regards,


Andrew Dinn
-----------