RFR: 8254793: [JVMCI] improve speculation encoding [v3]

Tom Rodriguez never at openjdk.java.net
Fri Oct 16 20:03:21 UTC 2020


On Fri, 16 Oct 2020 16:30:43 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 1171:
>> 
>>> 1169:   // uniquely identify the  speculative optimization guarded by the uncommon trap.
>>> 1170:   // The id value is only 32-bits but since this field is exposed via VMStructs to
>>> 1171:   // JVMCI as a jlong, it needs to be kept as a long to maintain backwards compatibility
>> 
>> I am confusing about backword compatibility comment. It said that old Graal (link in current JDK) generate code which
>> writes 64 bits into this word. Will it use [32:32] index:length format or it will use new [0:27:5] format? I don't see
>> changes to Graal in this PR.
>
> The version of Graal in the JDK does not change. It is agnostic about the encoding format. All is does is write a value
> to `Thread::_pending_failed_speculation` where said value is provided by JVMCI. The width of the write is determined by
> the width of the value. You can follow the code that does this
> [here](https://github.com/openjdk/jdk/blob/6c3bc71079bd9f4de005d005ded5a7cc3b7e373a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRGenerator.java#L529).

Based on some of my comments from elsewhere we've undone some of the original changes so it just produces int friendly
long constants.  Changing the actual encoding size poses some compatibility problems because we weren't careful enough
to be completely size agnostic in Graal code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/667


More information about the hotspot-dev mailing list