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) _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
