Hi Chris,
On 21/05/2015 4:18 AM, Chris Plummer wrote:
On 5/19/15 9:26 PM, David Holmes wrote:
Hi Chris,
On 20/05/2015 12:25 AM, Chris Plummer wrote:
Hi,
Please review the following changes for allowing java debugging when CDS
is enabled.
Webrev:http://cr.openjdk.java.net/~cjplummer/8054386/webrev.01/
Bug:https://bugs.openjdk.java.net/browse/JDK-8054386
The VM changes are simple. I removed the check that prevents debugging
with CDS enabled, and added logic that will map the CDS archive RW when
debugging is enabled.
The tests are a bit more complex. There are a bunch of existing JDI
tests for testing debugging support. Rather than start from scratch or
clone them, I instead just wrote wrapper tests that put the relevant JDI
test classes in the archive, and then invoke the JDI test. I did this
I'm not sure that the jdk tests will always be available in the same
test bundle as the hotspot tests. I know they will be in the full
forest but some testing uses test bundles not full repos.
I'm not familiar with test bundles. Who creates them and who uses them?
I was thinking of the test-image target in the build, which is then used
to create a test-bundle for JPRT. But that seems to be only native code
that must be built as part of the binary build process. So I think the
actual test execution will be using the source repository - for JPRT
anyway.
Not sure how nightly testing handles things though - if it is executing
the hotspot jtreg tests only does it use a full repo or just the
hotspot/test directory tree?
David
-----
Chris
David
-----
for 3 of the JDI tests. If you feel there are others that would be good
candidates, I'd be happy to add them. I'm looking for ones that would
result in modification of the RO class metadata, such as setting a
breakpoint (for which I already added two tests).
Testing done:
-Using JPRT to run the new jtreg tests on all platforms.
-Using JPRT to run all jtreg runtime tests on linux x86 and x_64.
-Regular JPRT "-testset hotspot" run
-Putting the JCK JVMTI tests in the archive and then running them.
-Putting the nsk jdb, jdwp, jvmti, and jdi tests in the archive and then
running them.
-Putting a simple test class in the archive and then setting a
breakpoint on it using jdb
Some of the above testing resulted in the discovery of bugs that still
need to be addressed: JDK-8078644, JDK-8078730, and JDK-8079181.
I also verified that without the change to map the archive RW, the above
testing resulted in a SEGV, which is what you would expect (and actually
want to see to prove that the testing is effective).
thanks,
Chris
