naming of internal MH classes
forax at univ-mlv.fr
Fri Aug 19 05:26:58 PDT 2011
On 08/19/2011 01:31 AM, John Rose wrote:
> Here is a heads-up before an engineering code review!
> The OpenJDK implementation of JSR 292 has a number of private MH subclasses, including DirectMethodHandle, BoundMethodHandle, AdapterMethodHandle, AdapterMethodHandle.AsVarargsCollector. Except for the last, these names date back to the days of prototyping JSR 292.
> As we tune and refactor the implementation, I am starting to define more subclasses. Now it is time to consider some name changes. Because these can impact the JVM (as it recognizes intrinsics) I would like to keep these changes as low-impact as possible.
> In particular, I want to switch to something similar to Dan Heidinga's naming convention (in IBM's implementation), where private subclasses have simpler but more specific names like AsTypeHandle.
> Dan's account of MH type names is on slide 6 of his 2010 talk:
> http://www.wiki.jvmlangsummit.com/images/a/ad/J9_MethodHandle_Impl.pdf (2010)
> I don't propose to duplicate this, but rather to use the names as a model.
> (It is possible that this might ease the creation of a common implementation API with IBM, which would be good, but that's not the immediate goal.)
> Before I start refactoring and renaming, in the OpenJDK implementation, I want to know if we see any downside to using such a naming scheme in OpenJDK.
I don't see any downside.
I have prototyped a way to do reflection on method handle,
(more on this in a later mail)
which depends on these names but I don't see why I will not be able to
the implementation to use the new name.
BTW, I don't understand why I don't understand why the current
of a constructor call ( new + dup + constructor call) uses
of two consecutive folds.
> -- John
> P.S. The immediate occasion for naming and refactoring is the (likely) need for a CountingHandle (or is it CountingAdapterMethodHandle or AdapterMethodHandle$AsCounter?), to assist in profiling tasks. (Cf. the methodDataOop which profiles for bytecodes. We need similar infra. for MH graphs.)
You can already do that with a fold that takes a method that returns
bound the counter object.
> P.P.S. Dan's 2011 talk is here, for the record. It's delves into other interesting details of the J9 implementation, including their version of supercombinators:
> http://www.wiki.jvmlangsummit.com/images/6/6b/2011_Heidinga.pdf (2011)
More information about the mlvm-dev