naming of internal MH classes

[Rémi Forax]

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.
>
> Comments?

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 
update
the implementation to use the new name.

BTW, I don't understand why I don't understand why the current 
implementation
of a constructor call ( new + dup + constructor call) uses 
spread/collect instead
of two consecutive folds.

>
> -- John

Rémi

>
> 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 
void and
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)