RFR: Adapt upstream object pinning API

[Aleksey Shipilev]

On 04/04/2018 07:34 PM, Zhengyu Gu wrote:
> On 04/04/2018 01:17 PM, Aleksey Shipilev wrote:
>> On 04/04/2018 07:02 PM, Zhengyu Gu wrote:
>>> Adapted upstream object pinning API, also made adjustment to critical native support to use new API.
>>>
>>>
>>> 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.

>>
>> *) 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.

-Aleksey