-
Notifications
You must be signed in to change notification settings - Fork 334
Verify EnsoContext can be GCed after cleaning up ContextUtils rule
#14219
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
Conversation
| var ref = new WeakReference<>(ensoContext()); | ||
| context.close(); | ||
| context = null; | ||
| assertGC("EnsoContext can be GCed when context is closed", true, ref); |
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.
- The ultimate goal is to make sure that once
org.graalvm.polyglot.Contextis closed - all references to
EnsoContextare closed - that's not really the case right now and fixes may be needed all over the place to make that happen
EnsoContext can be GCed after cleaning up ContextUtils rule
|
The CI is failing in JVM unit tests (as expected) with a ton of error messages:
There are memory leaks holding |
build.sbt
Outdated
| "-Dpolyglot.engine.AllowExperimentalOptions=true" | ||
| "-Dpolyglot.engine.AllowExperimentalOptions=true", | ||
| "-XX:+HeapDumpOnOutOfMemoryError", | ||
| "-XX:HeapDumpPath=" + (Compile / packageBin / artifactPath).value |
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.
Update on Nov 6, 2025
- with Add
Upload heapdumpstep to all JVM tests jobs #14251 you can download the.hproffile from GitHub Actions CI
How to Analyze Heap Dump
When a test fails because of assertGC, then following message is printed:
java.lang.OutOfMemoryError: Java heap space
Dumping heap to /home/devel/NetBeansProjects/enso/enso/engine/runtime-integration-tests/target/scala-2.13/runtime-integration-tests.jar ...
Heap dump file created [16382020915 bytes in 18,771 secs]
java.lang.OutOfMemoryError: Java heap space
| => rat org.enso.test.utils.MemoryUtils.checkAndAlloc(MemoryUtils.java:60)
at org.enso.test.utils.MemoryUtils.assertGC(MemoryUtils.java:17)
at org.enso.test.utils.ContextUtils.close(ContextUtils.java:134)
at org.enso.test.utils.ContextUtils$CustomStatement.evaluate(ContextUtils.java:481)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
with that .hprof file at hand, one can open it in VisualVM as
jvisualvm --openfile ./engine/runtime-integration-tests/java_pid969397.hprof
and then
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.
The problem in previous picture shows a reference from CleanableReference.QUEUE - that may go away eventually, but df08637 does its best to force the processing of the QUEUE.
|
With recent changes, there is now 130 failing tests: Fix or make the |
|
There is 55 unit test failures on Windows remaining: Some of these failures will hopefully go away after fc3401b that disables the There are failures in runtime-benchmarks - they should be solved with the new default introduced in fc3401b. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-10-30): Progress: .
|
|
Down to seventeen failures: |
…ng unless special magic is performed
|
|
I believe all tests are fixed. They run in seven minutes:
The memory usage when running `runtime-integration-tests/test` seems to _not leak_ anything. After each test it returns back to previous memory state. The TruffleTCK tests require enormous amount of heap. Not sure why, but then they clean after itself, so the purpose of this PR should be met.
Reviewers, @Akirathan, @hubertp, @4e6 please act! |
Akirathan
left a comment
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.
The amount of explicit null assignment to local variables is surprising. I understand why that is necessary for static fields, but for local variables used inside try-with-resources block?
engine/runtime-compiler/src/main/scala/org/enso/compiler/pass/resolve/TypeSignatures.scala
Outdated
Show resolved
Hide resolved
...runtime-integration-tests/src/test/java/org/enso/compiler/test/ExportCycleDetectionTest.java
Outdated
Show resolved
Hide resolved
...runtime-integration-tests/src/test/java/org/enso/compiler/test/ExportCycleDetectionTest.java
Outdated
Show resolved
Hide resolved
|
Jaroslav Tulach reports a new STANDUP for today (2025-10-31): Progress: .
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-11-01): Progress: .
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2025-11-02): Progress: .
|
| "-Dpolyglot.engine.AllowExperimentalOptions=true" | ||
| "-Dpolyglot.engine.AllowExperimentalOptions=true", | ||
| "-XX:+HeapDumpOnOutOfMemoryError", | ||
| "-XX:HeapDumpPath=" + (Compile / packageBin).value.getParentFile |
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.
Now there should be .hprof file in the engine/runtime-integration-tests/target directory when any of the tests yields OutOfMemoryException.


Pull Request Description
Adding support for "assert GC mode" into
ContextUtils. TheassertGCis invoked after each@Ruleor@ClassRuleusage ofContextUtilsis beingclosed. This default behavior can be manually configured viaContextUtils.Builder.assertGC(boolean).This work is based on investigation of a non-deterministic CI failure. By watching the process performing
runtime-integration-tests/testexecution in VisualVM at least one memory leak was revealed: That problem was fixed by replacingstatic finalfield byEnsoContext.Extraper context value in d21d2fd. That way those cachedEnsoMultiTypes shall garbage collect at the same time asEnsoContext.Important Notes
Originally there seemed to be 173 of instances of
org.graalvm.polyglot.Contextduring test execution. There seemed to be millions of instances ofTreeMap$Entryheld in the memory:and they seem to leak via
EnsoMultiType.ALL_TYPES:After this PR this debris will be completely gone!
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,