Defining anonymous classes

Charles Oliver Nutter headius at headius.com
Mon Aug 25 19:14:39 UTC 2014


On Fri, Aug 15, 2014 at 5:39 PM, John Rose <john.r.rose at oracle.com> wrote:
> If the host-class token were changed to a MethodHandles.Lookup object, we could restrict the host-class to be one which the user already had appropriate access to.  Seems simple, but of course the rest of the project is complicated:   API design, spec completion, security analysis, positive and negative test creation, code development, quality assurance—all these would be expensive, and (again) most easily justified in the context of a larger refresh of our classfile format.

Sounds like a good candidate to be a standalone project first. I think
we have the right people on this list to do it (and many of us have
already done large portions of that work on our own already).

> Or, most or all of dAC could be simulated using regular class loading, into a single-use ClassLoader object.  The nominal bytecodes would have to be rewritten to use invokedynamic to manage the linking, at least to host-class names.  But given that ASM is inside the JDK, the tools are all available.  (Remi could do most of it in an afternoon. :-) )  Given such a simulation, the internal dAC mechanism could be used as an optimization, when available, but there would be a standard (complex) semantics derived from ordinary classes and indy.

This is how JRuby has survived for years. A classloader-per-class has
a big memory load (ClassLoader has a lot of internal state, classes
have a lot of metadata) but with permgen bumped up (or replaced with
metaspace as in 8) and a few reuse tricks, it hasn't been a major
issue for us. In JRuby, the following are all generated into
single-shot classloaders:

* Ruby methods JIT-compiled to bytecode at runtime
* Wrapper logic ("invokers") around AOT or JIT-compiled method and
closure bodies (including core methods written in Java)
* Synthetic interface implementations and subclasses (for implementing
or extending from Ruby)
* Most other one-off pieces of bytecode we generate at runtime. We
almost never need to look up those classes once created and
instantiated.

- Charlie


More information about the mlvm-dev mailing list