Classfile representation of specializable classes

[Maurizio Cimadamore]

On 11/07/14 18:21, Dan Smith wrote:
> On Jul 11, 2014, at 10:58 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> The example in the writeup has many pleasing properties (one artifact, so can't get out of sync; encode minimal additional metadata needed to efficiently transform an erased classfile to a specialized classfile; the "template" can be used as an erased classfile as is, just by ignoring the specialization metadata attributes.)
>>
>> It also has an unpleasant property: the bytecode for an already loaded class is not available easily through its classloader or reflection, meaning that a runtime specialization mechanism would have to jump through hoops (e.g., retransform-classes) to get at the bytecode.  Since specializing a class under this scheme requires, as input, the bytecode of the original class, this could become problematic for classes that are themselves generated (i.e., not findable with ClassLoader.getResource("Foo.class")).
> Maybe what you're after with classdynamic is (primarily) a ClassLoader feature rather than a VM feature?  That is, maybe 'defineClass' should be parameterized by a pluggable class-generation system, and that's where the expansion should take place, intercepting the bytes and spitting out the special class.  It's not totally clear to me how this would work, but I think it may be the right place for it.  (I have consistently felt like what we really want with classdynamic is ClassLoaders 2.0.)
I believe that classloader was also NextGen way to get there:

http://dl.acm.org/citation.cfm?id=1141656

Maurizio
>
> —Dan