Skip to content
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

Virtual Thread Support #18432

Merged
merged 3 commits into from
Nov 9, 2023
Merged

Virtual Thread Support #18432

merged 3 commits into from
Nov 9, 2023

Conversation

babsingh
Copy link
Contributor

@babsingh babsingh commented Nov 9, 2023

1. Update acquireVThreadInspector and enterVThreadTransitionCritical

VM is entered by the invocation of internalEnterVMFromJNI.
VM is exited by the invocation of internalExitVMToJNI.

VM is always entered before acquireVThreadInspector and
enterVThreadTransitionCritical are invoked.

In these functions, the goal can be achieved by just releasing
and re-acquiring VM access. The new changes just release and
re-acquire VM access instead of exiting and entering the VM.
This has less overhead.

Addresses: #18420 (comment)

2. Update error handling in JVMTI NotifyFramePop

Return JVMTI_ERROR_THREAD_NOT_SUSPENDED if the thread was not
suspended and was not the current thread.

For virtual threads, VirtualThread.state is read and it is checked
if JVMTI_VTHREAD_STATE_SUSPENDED is set in VirtualThread.state.

This check is incorrect because JVMTI_VTHREAD_STATE_SUSPENDED
represents an internal state at the Java level. It does not
imply if the virtual thread is suspended through JVMTI.

JVMTI NotifyFramePop is updated to check if the virtual thread
is suspended through JVMTI.

3. Remove unused variables in jvm.c

This improves perf by saving the resources used to store and
initialize these variable.

Signed-off-by: Babneet Singh sbabneet@ca.ibm.com

This improves perf by saving the resources used to store and
initialize these variable.

Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
Return JVMTI_ERROR_THREAD_NOT_SUSPENDED if the thread was not
suspended and was not the current thread.

For virtual threads, VirtualThread.state is read and it is checked
if JVMTI_VTHREAD_STATE_SUSPENDED is set in VirtualThread.state.

This check is incorrect because JVMTI_VTHREAD_STATE_SUSPENDED
represents an internal state at the Java level. It does not
imply if the virtual thread is suspended through JVMTI.

JVMTI NotifyFramePop is updated to check if the virtual thread
is suspended through JVMTI.

Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
VM is entered by the invocation of internalEnterVMFromJNI.
VM is exited by the invocation of internalExitVMToJNI.

VM is always entered before acquireVThreadInspector and
enterVThreadTransitionCritical are invoked.

In these functions, the goal can be achieved by just releasing
and re-acquiring VM access. The new changes just release and
re-acquire VM access instead of exiting and entering the VM.
This has less overhead.

Addresses: eclipse-openj9#18420 (comment)

Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
@babsingh
Copy link
Contributor Author

babsingh commented Nov 9, 2023

@gacholio Requesting your review. This PR address your feedback from #18420 (comment), and a few other issues.

@gacholio
Copy link
Contributor

gacholio commented Nov 9, 2023

jenkins test sanity win jdk8

@gacholio
Copy link
Contributor

gacholio commented Nov 9, 2023

jenkins test sanity zlinux jdk21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants