8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading
Reviewed-by: dcubed, sspitsyn, alanb
--- a/hotspot/src/share/vm/prims/jvmti.xml Wed Jan 18 14:36:54 2017 -0800
+++ b/hotspot/src/share/vm/prims/jvmti.xml Wed Jan 18 19:54:18 2017 -0500
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="jvmti.xsl"?>
<!--
- Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved.
+ Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
This code is free software; you can redistribute it and/or modify it
@@ -12864,11 +12864,13 @@
If the capability has been added then the VM posts the event as early
as possible. The VM is capable of executing bytecode but it may not have
initialized to the point where it can load classes in modules other than
- <code>java.base</code>. Agents that do load-time instrumentation in this
+ <code>java.base</code>, or even arbitrary classes in <code>java.base</code>.
+ Agents that do load-time instrumentation in this
phase must take great care when instrumenting code that potentially
- executes in this phase. Care should also be taken with JNI
- <code>FindClass</code> as it may not be possible to load classes that are
- not in the <code>java.base</code> module.
+ executes in this phase. Extreme care should also be taken with JNI
+ <code>FindClass</code> as it may not be possible to load classes and attempts
+ to do so may result in unpredictable behavior, maybe even stability issues
+ on some VM implementations.
If the capability has not been added then the VM delays posting this
event until it is capable of loading classes in modules other than
<code>java.base</code> or the VM has completed its initialization.