New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add thread local storage to java thread objects #15541
Conversation
The above test covers virtual threads, platform threads, event callbacks, event notification modes and thread local storage. It should succeed with this PR. |
I was planning to leave the usage of the tls functions and hooks/allocations to a third pr once the current two have been merged since this pr requires the hidden field, native methods, and the virtual thread linked list. Also I thought we were going to use the new TLS for all java versions. I am adding new changes such as |
This PR should fix the following JVMTI functions in JDK19:
The TLS will only be used in the above listed methods. We don't need to allocate Then, the virtual thread list will only be needed by See #15183 (comment) and surrounding comments for more details. This approach was preferred by @gacholio.
Memory footprint will increase. Perf team will notice it and tag it as a regression for JDK 8/11/17. This suggestion would work if we completely disable the existing TLS for |
I am not sure about this, two more recent comments mention allocate/freeing in the virtual thread natives. #15183 (comment) |
That seems like the correct spot |
1e563af
to
03af58f
Compare
Java 19 sanity.functional passed: https://hyc-runtimes-jenkins.swg-devops.com/view/OpenJ9%20-%20Personal/job/Pipeline-Build-Test-Personal/13890/ I also tested locally with a This PR is ready for review |
No because it depends on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
High level overview:
- Commit/PR's description should highlight the startup performance benefits on all JDK version.
- The description should also highlight the extra memory that is needed for the TLS in JDK19+.
- Majority of the feedback is related to avoiding redundant code.
Also, can you point me to the code that sets |
I will do that after your changes get merged; it will be done after |
On leave till 31 Aug 22; won't be able to complete the review. Delegating the review to either @tajila or @gacholio or @hangshao0. |
Looks good - almost all my comments are just doc-related. Documentation for non-static functions should go only in the header file that prototypes them (to avoid multiple copies of the doc diverging over time). |
Updated |
jenkins test sanity win jdk19,jdk8 |
- Add an array hidden field to java/lang/Thread as the TLS for a given thread object (JDK19+). JDK18 and below will continue to use the OMR TLS - Implement JVMTI TLS functions to store env-thread-pair TLS data - Add tls pool to vm to allocate threads' tls arrays from - (JDK19+) Lazy allocate a thread's TLS array at first use (SetThreadLocalStorage and SetEventNotificationMode) - (JDK19+) Free the TLS array at VMThread destroy and virtual thread end - Lazy allocate TLS thread data blocks at first use (SetThreadLocalStorage and SetEventNotificationMode) - Implement new hook events for platform and virtual thread end to free the thread data block allocated by a JVMTI env Issue: eclipse-openj9#15183 Signed-off-by: Eric Yang <eric.yang@ibm.com>
PR tests: Fixing merge conflict from getThreadInfo PR (j9nonbuilder.h) JDK8 passed |
jenkins test sanity win jdk19 |
targetThread is NULL only for virtual threads, as per the assertion in getVMThread, when mustBeAlive is TRUE. vmThreadForTLS is only used to acquire J9JavaVM in createThreadData and jvmtiTLSGet. If targetThread is NULL, currentThread is passed to createThreadData and jvmtiTLSGet for retrieving J9JavaVM in JDK19+. Related: eclipse-openj9#15541 Related: eclipse-openj9#15183 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
targetThread is NULL only for virtual threads, as per the assertion in getVMThread, when mustBeAlive is TRUE. vmThreadForTLS is only used to acquire J9JavaVM in createThreadData and jvmtiTLSGet. If targetThread is NULL, currentThread is passed to createThreadData and jvmtiTLSGet for retrieving J9JavaVM in JDK19+. Related: eclipse-openj9#15541 Related: eclipse-openj9#15183 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
thread object (JDK19+). JDK18 and below will continue to use the OMR TLS
(SetThreadLocalStorage and SetEventNotificationMode)
(SetThreadLocalStorage and SetEventNotificationMode)
the thread data block allocated by a JVMTI env
Issue: #15183
Signed-off-by: Eric Yang eric.yang@ibm.com