RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI
cthalinger at twitter.com
Tue Jun 28 23:19:54 UTC 2016
+ assert(Universe::is_module_initialized(), "must be");
Shouldn’t that be !Universe::is_module_initialized()? No, that’s wrong too. I don’t think you can have this assert.
> On Jun 27, 2016, at 4:56 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I’ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev <http://cr.openjdk.java.net/~never/8160121-v3/webrev>. The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp.
>> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>> Looks good.
>> On 6/23/16 8:55 AM, Doug Simon wrote:
>>> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored.
>>> Thanks to Tom for most of this code!
>>> https://bugs.openjdk.java.net/browse/JDK-8160121 <https://bugs.openjdk.java.net/browse/JDK-8160121>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev