[Nestmates] RFR: JVM TI and related updates

[David Holmes]

This RFR is for the JVM TI specification and implementation changes, and 
related JDWP, instrumentation and JDI changes. The bulk of this work was 
done by Serguei - which was very much appreciated. I have written the 
test based on initial examples that Serguei provided.

The actual spec changes are done under sub-task:

bug: https://bugs.openjdk.java.net/browse/JDK-8196311
webrev: http://cr.openjdk.java.net/~dholmes/8196311/webrev/

This has been discussed/reviewed on the EG list and here as part of the 
CSR review. The changes are being putback now so that we can also 
putback the implementation changes - as the specs, in part, generate 
some of the code. If you have comments on the actual specification 
changes please respond to the CSR review thread - thanks.

The implementation changes, and accompanying tests have been done under:

bug: https://bugs.openjdk.java.net/browse/JDK-8191118
webrev: http://cr.openjdk.java.net/~dholmes/8191118/webrev/

The basic change is simple: redefinition/retransformation may not modify 
either the NestHost or NestMembers attributes of a class: no additions, 
no removals, no changes. As the order of classes in the NestMembers 
attribute is not specified (and can easily vary across compilers, or 
even within one compiler under different conditions) we cannot consider 
a change in order to be a change, so we have to allow for that.

The testing is simple in principle, but in practice quite complicated to 
set up the necessary conditions and manage all the different "versions" 
of the "same class". The testing approach is explained in great detail 
in the main test: TestNestmateAttr.java

We are still awaiting a standalone JDI test to be written, but that will 
be coming shortly and I want to clear the decks so will follow up on 
that later.

In addition some existing redefinition tests started to fail because 
they were inadvertently changing the NestHost attribute. This arose 
because the tests were using nested classes to be redefined, but the way 
the InMemoryJavaCompiler was used actually produces a top-level class 
(no NestHost attribute) that happens to have a $ in the name (A$B is 
actaully a legal class name for a top-level class). These tests will be 
updated shortly but for now are ProblemListed.

bug: https://bugs.openjdk.java.net/browse/JDK-8199837
webrev: http://cr.openjdk.java.net/~dholmes/8199837/webrev/

Thanks,
David