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

Re-fetch objects after VM access is released and reacquired #18420

Merged
merged 1 commit into from
Nov 9, 2023

Conversation

babsingh
Copy link
Contributor

@babsingh babsingh commented Nov 8, 2023

Stale objects can manifest many issues. In this case, stale objects
cause complex and intermittent synchronization issues.

Related: #17865
Related: #17869
Related: #18370

Stale objects can manifest many issues. In this case, stale objects
cause complex and intermittent synchronization issues.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

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

babsingh commented Nov 8, 2023

@gacholio Requesting your review.

fyi @tajila

@babsingh babsingh requested review from tajila and gacholio and removed request for tajila November 8, 2023 18:52
@gacholio
Copy link
Contributor

gacholio commented Nov 8, 2023

I looked at acquireVThreadInspector while reviewing this and I think the exit/enter calls in there should actually be release/acquire VM access (assuming that the code is only called while the VM has been entered).

@gacholio
Copy link
Contributor

gacholio commented Nov 8, 2023

jenkins test sanity zlinux jdk21

@babsingh
Copy link
Contributor Author

babsingh commented Nov 8, 2023

I looked at acquireVThreadInspector while reviewing this and I think the exit/enter calls in there should actually be release/acquire VM access (assuming that the code is only called while the VM has been entered).

Yes, VM is always entered prior to invoking acquireVThreadInspector. I will update it to release and acquire VM access in a new PR.

babsingh added a commit to babsingh/openj9 that referenced this pull request Nov 9, 2023
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>
@gacholio gacholio merged commit 001e9c5 into eclipse-openj9:master Nov 9, 2023
5 checks passed
babsingh added a commit to babsingh/openj9 that referenced this pull request Nov 9, 2023
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 babsingh mentioned this pull request Nov 9, 2023
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