-
Enhancement
-
Resolution: Fixed
-
P3
-
7
-
b08
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2170002 | 7 | John Rose | P3 | Closed | Fixed | b41 |
JDK-2172828 | 6u14 | John Rose | P3 | Resolved | Fixed | b01 |
http://blogs.sun.com/jrose/entry/anonymous_classes_in_the_vm
One pain point in dynamic language implementation is managing
code dynamically. Too often the JVM's class loaders and
naming conventions get in the way.
Desired features:
- load an arbitrary class from bytecodes
- put class in class hierarchy but *not* in any class loader
- piggyback on a "host class" as if it were an inner class
- element of the anonymous constant pool can be patched easily
- string constants can be replaced by arbitrary objects in CP
Why the patching stuff? Mainly, it makes some use cases much easier.
Second, the constant pool needed some internal patching anyway,
to anonymize the loaded class itself. Also, if you are going
to use this seriously, you'll want to build anonymous classes
on top of pre-existing anonymous classes, and that requires patching.
Finally, generated code often needs to get to complex constants
(e.g., lists or tables) and this provides a hook to introduce
them directly via the CP.
We want to cut ClassLoaders and the system dictionary out of the loop.
This means there will be fewer locks and no GC entanglements.
Drop the last object, and the class goes away too, just as it should.
One pain point in dynamic language implementation is managing
code dynamically. Too often the JVM's class loaders and
naming conventions get in the way.
Desired features:
- load an arbitrary class from bytecodes
- put class in class hierarchy but *not* in any class loader
- piggyback on a "host class" as if it were an inner class
- element of the anonymous constant pool can be patched easily
- string constants can be replaced by arbitrary objects in CP
Why the patching stuff? Mainly, it makes some use cases much easier.
Second, the constant pool needed some internal patching anyway,
to anonymize the loaded class itself. Also, if you are going
to use this seriously, you'll want to build anonymous classes
on top of pre-existing anonymous classes, and that requires patching.
Finally, generated code often needs to get to complex constants
(e.g., lists or tables) and this provides a hook to introduce
them directly via the CP.
We want to cut ClassLoaders and the system dictionary out of the loop.
This means there will be fewer locks and no GC entanglements.
Drop the last object, and the class goes away too, just as it should.
- backported by
-
JDK-2172828 dynamic languages need to be able to load anonymous classes
- Resolved
-
JDK-2170002 dynamic languages need to be able to load anonymous classes
- Closed
- relates to
-
JDK-6471009 Significantly higher CPU usage in jvm1.6 build 97/98 vs jvm1.5.0_06-b05 on DOTS ATCJ2 test
- Resolved
-
JDK-8171335 MethodHandle.Lookup functionality to define a nestmate class
- Closed