RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI
Christian Thalinger
cthalinger at twitter.com
Wed Jun 29 16:50:49 UTC 2016
> On Jun 28, 2016, at 2:23 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>
> I rearranged that during the push.
>
> + // We can't compile with a JVMCI compiler until the module system is initialized past
> + // phase 3. The JVMCI API itself isn't available until phase 2 and ServiceLoader isn't
> + // usable until after phase 3.
> + if (level == CompLevel_full_optimization && EnableJVMCI && UseJVMCICompiler) {
> + if (SystemDictionary::java_system_loader() == NULL) {
> + return;
> + }
> + assert(Universe::is_module_initialized(), "must be”);
Good.
>
> tom
>
>> On Jun 28, 2016, at 4:19 PM, Christian Thalinger <cthalinger at twitter.com <mailto:cthalinger at twitter.com>> wrote:
>>
>> src/share/vm/runtime/simpleThresholdPolicy.cpp
>>
>> + 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 <mailto: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.
>>>
>>> tom
>>>
>>>> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>>
>>>> Looks good.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> 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>
>>>>> http://cr.openjdk.java.net/~dnsimon/8160121/ <http://cr.openjdk.java.net/~dnsimon/8160121/>
>>>>>
>>>>> -Doug
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160629/5133eb8e/attachment.html>
More information about the hotspot-compiler-dev
mailing list