JDK-8137018 : [JVMCI] Encapsulate new Thread fields for JVMCI
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-09-23
  • Updated: 2021-09-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8062493 - JEP 243: Java-Level JVM Compiler Interface
Relates :  
JDK-8156206 - Use flags fields for JVMCI specific bool fields in JavaThread
Description
>>
>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/src/share/vm/runtime/thread.hpp.udiff.html
>>
>> I thought you were only going to add 3 words to thread?  (If you reordered the fields, it would be).
> I reordered the fields a bit.
>>
>> Having to declare this many fields inline to any class suggests it should be refactored into a different class, and a pointer to that class in the global thread class.   I've made this comment before, I know.   It seems all the blue in this could be a new class.
> We can make this change later if we want to.
Comments
Probably not in a portable way - no. You'd have to know exactly how it was implemented. Okay forget that idea.
11-05-2016
Is there some way to expose such C++ thread locals so that JIT compiled code can access them?
10-05-2016
Sounds interesting although I have no experience with these type of thread locals and I don't see evidence of them being used anywhere in HotSpot. Is there already existing discussion about introducing them to HotSpot?
10-05-2016
What do you mean by compiler-based thread-local-variables? Keep in mind that these thread locals need to be available on all JavaThreads, not just CompilerThreads. Some of them also need to be accessed from compiled code.
10-05-2016
I wonder if we can actually start to use compiler-based thread-local-variables for this kind of thing instead of adding fields to the thread instance?
10-05-2016
No general discussion about starting to use this instead of thread fields, but I thought I'd put it out there.
10-05-2016
C/C++ compiler based thread locals ie: __thread static int field; [Fixed syntax]
10-05-2016
I introduced them to track the current thread a few months ago (with a backup technique for platforms that don't have the support - a concession for mobile-dev). THREAD_LOCAL_DECL is the platform independent way to express it. There are a number of uses in the Aarch64 open port, and one for BSD: ./cpu/aarch64/vm/frame_aarch64.cpp:static __thread unsigned long nextfp; ./cpu/aarch64/vm/frame_aarch64.cpp:static __thread unsigned long nextpc; ./cpu/aarch64/vm/frame_aarch64.cpp:static __thread unsigned long nextsp; ./cpu/aarch64/vm/frame_aarch64.cpp:static __thread RegisterMap *reg_map; ./os/bsd/vm/jsig.c:static __thread bool reentry = false; /* prevent reentry deadlock (per-thread) */ ./os_cpu/linux_aarch64/vm/globals_linux_aarch64.hpp:extern __thread Thread *aarch64_currentThread;
10-05-2016
Alright. [~bharadwaj], can you take care of this?
09-02-2016
sure, why not? If you refactor later, it may be harder for backports.
09-02-2016
[~coleenp], do you want this in 9?
08-02-2016