A small typo: retransformation =>
- * The redefinition may change method bodies, the constant pool and attributes.
+ * The redefinition may change method bodies, the constant pool and attributes
+ * (unless explicitly prohibited).
* The redefinition must not add, remove or rename fields or methods, change the
- * signatures of methods, or change inheritance. These restrictions maybe be
- * lifted in future versions. The class file bytes are not checked, verified and installed
+ * signatures of methods, or change inheritance.
+ * The retransformation must not change the <code>NestHost</code> or
+ * <code>NestMembers</code> attributes.
+ * These restrictions maybe be lifted in future versions.
+ * The class file bytes are not checked, verified and installed
Otherwise, the changes look good.
No need in another webrev if the above is fixed.
Thank you for taking care about this!
On 5/16/18 23:33, David Holmes wrote:
updated the webrev with an additional change to the JDI/JDWP
version - which needed updating to 11. This was done under
and the patch has now been included here. Only two files with
On 15/05/2018 10:52 AM, David Holmes wrote:
This review is being spread across four
groups: langtools, core-libs, hotspot and serviceability. This
is the specific review thread for serviceability - webrev:
See below for full details - including annotated full webrev
guiding the review.
The intent is to have JEP-181 targeted and integrated by the end
of this month.
The nestmates project (JEP-181) introduces new classfile
attributes to identify classes and interfaces in the same nest,
so that the VM can perform access control based on those
attributes and so allow direct private access between nestmates
without requiring javac to generate synthetic accessor methods.
These access control changes also extend to core reflection and
the MethodHandle.Lookup contexts.
Direct private calls between nestmates requires a more general
calling context than is permitted by invokespecial, and so the
JVMS is updated to allow, and javac updated to use,
invokevirtual and invokeinterface for private class and
interface method calls respectively. These changed semantics
also extend to MethodHandle findXXX operations.
At this time we are only concerned with static nest definitions,
which map to a top-level class/interface as the nest-host and
all its nested types as nest-members.
Please see the JEP for further details.
All of the specification changes have been previously been
worked out by the Valhalla Project Expert Group, and the
implementation reviewed by the various contributors and
discussed on the valhalla-dev mailing list.
Acknowledgments and contributions: Alex Buckley, Maurizio
Cimadamore, Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen
Kinnear, Vladimir Kozlov, John Rose, Dan Smith, Serguei Spitsyn,
Master webrev of all changes:
Annotated master webrev index:
Performance: this is expected to be performance neutral in a
general sense. Benchmarking and performance runs are about to
The testing for nestmates can be broken into four main groups:
- New tests specifically related to nestmates and currently in
the runtime/Nestmates directory
- New tests to complement existing tests by adding in testcases
not previously expressible.
- For example java/lang/invoke/SpecialInterfaceCall.java
tests use of invokespecial for private interface methods and
performing receiver typechecks, so we add
java/lang/invoke/PrivateInterfaceCall.java to do similar tests
- New JVM TI tests to verify the spec changes related to nest
- Existing tests significantly affected by the nestmates
In most cases the nestmate changes makes certain invocations
that were illegal, legal (e.g. not requiring invokespecial to
invoke private interface methods; allowing access to private
members via reflection/Methodhandles that were previously not
- Existing tests incidentally affected by the nestmate changes
This includes tests of things utilising class
redefinition/retransformation to alter nested types but which
unintentionally alter nest relationships (which is not
There are still a number of tests problem-listed with issues
filed against them to have them adapted to work with nestmates.
Some of these are intended to be addressed in the short-term,
while some (such as the runtime/SelectionResolution test
changes) may not eventuate.
There is also further test work still to be completed (the JNI
and JDI invocation tests):
which will continue in parallel with the main RFR.
- Mach5: hs/jdk tier1,2
- Mach5: hs-nightly (tiers 1 -3)
- nashorn (for asm changes)
- hotspot: runtime/*
- jdk: java/lang/invoke/*
- langtools: tools/javac