RFR: Adapt upstream object pinning API

[Zhengyu Gu]

>>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/pin_interface/webrev.00/
>>>
>>> *) The changeset contains JDK-8200429 only, make sure you are pushing the correct changeset:
>>>    http://cr.openjdk.java.net/~zgu/shenandoah/pin_interface/webrev.00/shenandoah-jdk10.changeset
>>
>> Yes, we need this one for new API. The patch is from upstream jdk repo, but did not apply cleanly.
> 
> I was saying that the webrev had generated the changeset that contains only JDK-8200429. So, be
> careful when pushing stuff, because maybe the repo is not the state you want it to be.

Ah. JDK-8200429 is pretty isolated. I think we are good here.

> 
>>>
>>> *) Since you are renaming the RT stubs, should you also rename the MacroAssembler entries? Does it
>>> do something special for arrays, or is it just the stub for the call to
>>> SharedRuntime::{pin|unpin}_object?
>>>
>>>     MacroAssembler::pin_critical_native_array
>>>     MacroAssembler::unpin_critical_native_array
>>
>> No. SharedRuntime::{pin|unpin}_object are generic. MacroAssembler::pin/unpin_critical_native_array
>> generate code to make RT calls for array arguments.
> 
> Right. But is there anything special about MacroAssembler::pin/unpin_critical_native_array so that
> we need to call them *_array? If not, we should just call them pin/unpin_object, regardless where
> they are being called from. This would help to employ these stubs for future use cases.

I see.

However, this method is not that generic, it follows 
unpack_array_argument(), uses rax as temporary register, and does not 
support all object sizes.

Thanks,

-Zhengyu



> 
> -Aleksey
>