On Fri, Aug 15, 2014 at 5:39 PM, John Rose <john.r.r...@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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
