Add walkReferenceChain JITServer Support #8293
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
harryyu1994
changed the title
harryyu1994
force-pushed
the
walkReferenceChain
branch
8 times, most recently
from
38f42ae
to
6f373ca
Compare
The purpose of this change is to avoid using object addresses on JITServer. Using object addresses on JITServer creates problems when GC changes the object addresses. Instead, JITServer must use some kind of handle (a GlobalReference or some other GC root) to hold the object so that JITServer always has the valid object addresses. walkReferenceChain is special in that it needs half of its information from the JITServer(TR::Node) and half of its information from JITClient(object address). During the walk, we need vmaccess so that GC doesn't move the object of interest. We can only have vmaccess on JITClient, which means we need to do walkReferenceChain on JITClient. This change makes JITServer to generate the offsets information JITClient needed for the walk and passes to JITClient in the form of a vector. Issue: eclipse-openj9#8109 Signed-off-by: Harry Yu <harryyu1994@gmail.com>
harryyu1994
force-pushed
the
walkReferenceChain
branch
from
6f373ca
to
b3eb10f
Compare
After JITClient receives the globalreference from JITServer, we need to obtain vmaccess before we dereference it. Signed-off-by: Harry Yu <harryyu1994@gmail.com>
There are 4 instances where JITServer incorrectly uses the walkReferenceChain routine. Update them to the new implementation. Signed-off-by: Harry Yu <harryyu1994@gmail.com>
harryyu1994
force-pushed
the
walkReferenceChain
branch
from
50040fb
to
ff14e56
Compare
This messageType has been eliminated by the JITServer walkReferenceChain routine. Signed-off-by: Harry Yu <harryyu1994@gmail.com>
harryyu1994
force-pushed
the
walkReferenceChain
branch
from
ff14e56
to
42f4a74
Compare
Now that walkReferenceChain is handled properly on JITServer and JITClient, the LocalGCCOunter hack, which does not cover all cases and not an efficient workaround, should be removed. Signed-off-by: Harry Yu <harryyu1994@gmail.com>
Signed-off-by: Harry Yu <harryyu1994@gmail.com>
harryyu1994
force-pushed
the
walkReferenceChain
branch
from
305c981
to
4c6ddf7
Compare
harryyu1994
changed the title
|
A generic remark: now that we've 'released` a version of JITServer, any change to the communication protocol including adding/removing of messages or APIs needs to increment the version number |
Signed-off-by: Harry Yu <harryyu1994@gmail.com>
|
Incremented MINOR_NUMBER from 1 to 2. |
|
Added another change to handle 3 invokeFilterArgumentsWithCombinerHandle methods, they appeared to be without JITServer support. The latest commit can be reviewed separately. I put it in the same PR because 1. they both modify the same set of files 2. both are related to JSR292 3. both added new messageTypes so it's convenient to have them in the same PR. |
harryyu1994
force-pushed
the
walkReferenceChain
branch
2 times, most recently
from
fed1f06
to
b20baef
Compare
This change handles the following 3 methods for JITServer: 1. java_lang_invoke_FilterArgumentsWithCombinerHandle_numSuffixArgs 2. java_lang_invoke_FilterArgumentsWithCombinerHandle_filterPosition 3. java_lang_invoke_FilterArgumentsWithCombinerHandle_argumentIndices Signed-off-by: Harry Yu <harryyu1994@gmail.com>
harryyu1994
force-pushed
the
walkReferenceChain
branch
from
b20baef
to
2bac4a7
Compare
mpirvu
reviewed
Jan 16, 2020
Signed-off-by: Harry Yu <harryyu1994@gmail.com>
mpirvu
reviewed
Jan 16, 2020
mpirvu
reviewed
Jan 16, 2020
Signed-off-by: Harry Yu <harryyu1994@gmail.com>
|
Jenkins test sanity xlinuxjit jdk11 |
1 similar comment
|
Jenkins test sanity xlinuxjit jdk11 |
|
Jenkins test sanity plinuxjit jdk11 |
|
All tests have passed, hence merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose of this change is to avoid using object addresses on JITServer. Using object addresses on JITServer creates problems when GC moves the object (thus changing the addresses). Instead, JITServer must use some kind of handle (a GlobalReference or some other GC root) to hold the object so that JITServer always has the valid object addresses when it tries to perform operations on it.
walkReferenceChain()is special in that it needs half of its information from JITServer(TR::Node) and half of its information from JITClient(object address). During the walk, we need vmaccess so that GC doesn't move the object of interest. We can only have vmaccess on JITClient, which means we need to do the walk on JITClient.This change makes JITServer generate the offset information JITClient needs for the walk and passes to JITClient in the form of a vector.
Originally we have a LocalGCCounter hack where we can detect if the object has been moved to a different location. And when object has been moved, JITClient will abort the compilation. However, this does not work for all gcpolicies and also is not very efficient because JITClient can abort compilations that might not need to be aborted. This change offers a better solution: since the walk is done on JITClient and JITClient has control over vmaccess, object is guaranteed to not be moved during the operation.
I have also noticed a few misuses of globalreference read and vmaccess and have corrected them. We must have vmaccess before we perform a read.
Issue: #8109
Signed-off-by: Harry Yu harryyu1994@gmail.com