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:
http://cr.openjdk.java.net/~rschatz/JDK-8142329/webrev.02/
Thanks,
Roland
-------------- 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