[aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2

Dean Long dean.long at oracle.com
Thu Apr 23 19:01:01 UTC 2015


On 4/23/2015 9:46 AM, Andrew Haley wrote:
> On 04/23/2015 04:13 PM, Edward Nevill wrote:
>> On Thu, 2015-04-23 at 08:40 +0100, Andrew Haley wrote:
>>> On 22/04/15 10:40, Edward Nevill wrote:
>>>> If there is no other feedback shall I prepare a revised patch with R29 marked NS?
>>> I think you should.  I'm as certain as I can be that the GC root-
>>> finding code won't find an OOP saved in R29 and then pushed by
>>> native code.
>> Done.
>>
>> http://cr.openjdk.java.net/~enevill/8075930/webrev.04/
> Please run webrev after committing, so that the webrev is a proper
> changeset.  Please make sure that the jcheck extension is enabled.
>
> http://openjdk.java.net/projects/code-tools/jcheck/
>
>> However I don't believe it makes any difference to the code
>> generated. C2 will still use R29 as a general purpose register, and
>> will still not spill it on a method call (I have checked).
>>
>> I think that in order to do a GC root scan it must be at a safe
>> point and I don't believe it can be at a safe point in native code.
> Sure it can.  Native methods are always safepoints, as are calls to
> the runtime to allocate objects, etc.  But all such calls have a
> wrapper, and it pushes FP, it has an OopMap, so it should be fine.

What happens at a safepoint polling point in a loop?  Will C2 try to 
keep an oop value
in R29 live across the safepoint?  If so, I assume the oopmap takes care 
of that case as
well.

dl

>> In compiled code it uses the OopMaps, unwinds the stack and finds
>> the OOP in R29.
> Okay, I see.
>
> Thanks,
> Andrew.



More information about the aarch64-port-dev mailing list