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

Add comment on where _recompilationMethodInfo is freed #8082

Merged

Conversation

a7ehuo
Copy link
Contributor

@a7ehuo a7ehuo commented Dec 12, 2019

CompilationInfoPerThreadRemote::_recompilationMethodInfo was allocated
in the persistent memory in CompilationInfoPerThreadRemote::processEntry().
_recompilationMethodInfo is related to per compilation. Ideally it should be
allocated in the scratch memory. However the scratch memory is part of
the compilation object which has not been created when the entry is being processed.

During the compilation, _recompilationMethodInfo is passed
to J9::Recompilation::_methodInfo, which will get freed in populateBodyInfo()
when creating the method meta data during the compilation.
Since _recompilationMethodInfo is already freed in populateBodyInfo(),
no need to free it at the end of the compilation in CompilationInfoPerThreadRemote::processEntry().

Closes #7988

Signed-off-by: a7ehuo Annabelle.Huo@ibm.com

`CompilationInfoPerThreadRemote::_recompilationMethodInfo` was allocated
in the persistent memory in `CompilationInfoPerThreadRemote::processEntry()`.
`_recompilationMethodInfo` is related to per compilation. Ideally it should be
allocated in the scratch memory. However the scratch memory is part of
the compilation object which has not been created when the entry is being processed.

During the compilation, `_recompilationMethodInfo` is passed
to `J9::Recompilation::_methodInfo`, which will get freed in `populateBodyInfo()`
when creating the method meta data during the compilation.
Since `_recompilationMethodInfo` is already freed in `populateBodyInfo()`,
no need to free it at the end of the compilation in `CompilationInfoPerThreadRemote::processEntry()`.

Closes eclipse-openj9#7988

Signed-off-by: a7ehuo <Annabelle.Huo@ibm.com>
@a7ehuo a7ehuo changed the title WIP: Add comment on where _recompilationMethodInfo is freed Add comment on where _recompilationMethodInfo is freed Dec 12, 2019
@a7ehuo a7ehuo marked this pull request as ready for review December 12, 2019 16:38
Copy link
Contributor

@mpirvu mpirvu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mpirvu mpirvu added the comp:jitserver Artifacts related to JIT-as-a-Service project label Dec 12, 2019
@mpirvu
Copy link
Contributor

mpirvu commented Dec 12, 2019

Jenkins test sanity plinux jdk8

@mpirvu mpirvu added this to In progress in JIT as a Service via automation Dec 12, 2019
@mpirvu mpirvu self-assigned this Dec 12, 2019
@mpirvu
Copy link
Contributor

mpirvu commented Dec 12, 2019

Jenkins compile xlinuxjit jdk8

@mpirvu
Copy link
Contributor

mpirvu commented Dec 12, 2019

This is a very simple commit composed of one comment and two simple and safe assignments.
Tests have passed, hence merging.

@mpirvu mpirvu merged commit 82e5889 into eclipse-openj9:master Dec 12, 2019
JIT as a Service automation moved this from In progress to Done Dec 12, 2019
@a7ehuo a7ehuo deleted the scratchMemRecompilationMethodInfo branch December 16, 2019 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:jitserver Artifacts related to JIT-as-a-Service project
Projects
Development

Successfully merging this pull request may close these issues.

JITServer use scratch memory for _recompilationMethodInfo
2 participants