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