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

Roland Schatz roland.schatz at oracle.com
Tue Nov 10 10:20:33 UTC 2015

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:


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

More information about the hotspot-compiler-dev mailing list