RFR(S): 8142329: [JVMCI] pass Handle by value

[Christian Thalinger]

> On Nov 10, 2015, at 12:20 AM, Roland Schatz <roland.schatz at oracle.com> wrote:
> 
> On 11/09/2015 11:21 PM, Coleen Phillimore wrote:
>> We have three things with unfortunately similar names:
>> 
>> 1. Handle  including instanceHandle, arrayHandle, objArrayHandle and typeArrayHandle.   These hold oops.  They don't have anything but a trivial constructor and since the only field in these handles is the oopDesc pointer, there is no penalty for passing them by value.   By convention in the JVM sources, they are passed by value:  ie:   void foo(Handle h).
>> 
>> 2. metadata Handles including methodHandle and constantPoolHandle.   These hold metadata.  Their purpose is to keep the metadata from being deallocated due to disuse after redefinition.  These handles have copy constructors and destructors and are have to call these to pass by value.   These values shouldn't be written either.   So you should pass these as const references.  ie   void foo(const methodHandle& m);
>> 
>> 3. instanceKlassHandle and KlassHandle.  These are vestigial but were left in the code because they might have been needed for enhanced class redefinition.  They have no semantics so can be passed however you want.
>> 
>> In my opinion, none of these things should be passed as non-const references since they should never be output parameters.
>> 
>> So part of this change is correct to remove the non-const references but the Handles should be passed by value and the methodHandles and constantPoolHandles should be passed as const references.
> 
> Thanks for the detailed explanation.
> I updated the webrev, the jvmci code should now conform to those rules.
> 
> This is also including the changes by Chris. Thanks for noticing these. That's what I get from doing this in a hurry.
> 
> New webrev:
> http://cr.openjdk.java.net/~rschatz/JDK-8142329/webrev.02/ <http://cr.openjdk.java.net/~rschatz/JDK-8142329/webrev.02/>

Looks good.  I’m pushing this now.

> 
> Thanks,
> Roland
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151110/a624fb7c/attachment-0001.html>