refactoring BMH

[Maurizio Cimadamore]

Hi,
it's good to see this kind of effort being started. I have a general 
question on the shape of the classes generated by the ClassSpecializer; 
in the doc you say:

  class Species_[[types]] extends [[T]] {
          *     final [[S]] speciesData() { return ... }
          *     static [[T]] make([[fields]]) { return ... }
          *     [[fields]]
          *     final [[T]] transform([[args]]) { return ... }

How much the 'transform' primitives belong in here? The fact that the 
underlying species kind is able to apply transforms to get new kinds 
seem very BMH specific.

Also, the fact that Species_XYZ classes are constructed with an 
initially empty 'kind', which is injected later through Unsafe, also 
seems very specific.

I guess it would help to have a bit more background on what kind of 
things you imagine would be possible to express given this framework, 
and judge how much of the existing BMH cruft is getting in the way.

Thanks
Maurizio


On 18/07/17 03:12, John Rose wrote:
> I have felt for some time that the BoundMethodHandle code
> is not easy to work with, and I have wanted to refactor it
> for a long time to separate out the specialization logic
> from the BMH logic proper.
>
> Here is an experimental refactoring that accomplishes this:
>
> https://bugs.openjdk.java.net/browse/JDK-8184777
> http://cr.openjdk.java.net/~jrose/jdk/8184777/webrev.0
>
> I'd like to commit it to JDK10 first as a cleanup,
> but the motivation for it comes from Valhalla and Amber.
>
> If you work on java.lang.invoke code, please take a look
> and tell me what you think.
>
> Caveat:  It basically passes smoke tests only, but it
> does pass its own regression test (which builds a toy
> specialization schema, including nominal types the
> could be replaced by value types).
>
> — John