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

Reducing memory leaks in runtime-integration-tests #10793

Merged
merged 3 commits into from
Aug 13, 2024

Conversation

hubertp
Copy link
Collaborator

@hubertp hubertp commented Aug 10, 2024

Pull Request Description

Inspired by the revert done in #10778, started looking into apparent memory leaks in runtime-integration-tests, written in Java.

Initial state:
Screenshot from 2024-08-09 14-36-29

After:
Screenshot from 2024-08-12 16-33-40

Important Notes

Some remaining issues:

  • TCK tests appear to have some memory leaks but we are essentially enabling them via simple inheritance
  • RuntimeManagementTest appears to be broken as it doesn't seem to shutdown properly created threads:
    Screenshot from 2024-08-12 16-29-09

Leaving this for now, as it will probably need to be taken care by initial authors of those tests, if possible. Plus this PR leaves tests in a much better state than before.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.

Making sure that resources are properly closed when test suits are done.
Previously memory usage in Java tests was steadily rising until ~8GB.
Now, we only see jumps in the last tests but the baseline sticks to
~3GB.

We are not done yet.
@hubertp
Copy link
Collaborator Author

hubertp commented Aug 10, 2024

With latest changes:

Screenshot from 2024-08-10 16-19-17

@hubertp hubertp added the CI: No changelog needed Do not require a changelog entry for this PR. label Aug 10, 2024
@@ -28,14 +28,15 @@ public static void prepareCtx() {
ctx = ContextUtils.createDefaultContext(out);
}

@Before
@After
public void resetOut() {
Copy link
Member

Choose a reason for hiding this comment

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

Reset @Before is desirable to clean any debris from previous executions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It also meant that we weren't cleaning up tests after runs. Double-edged sword.

Copy link
Member

Choose a reason for hiding this comment

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

You may want to do both. @Before and @After then.

public static void disposeCtx() {
ctx.close();
}
public class SignatureTest extends ContextTest {
Copy link
Member

@JaroslavTulach JaroslavTulach Aug 11, 2024

Choose a reason for hiding this comment

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

Extending ContextTest is a nice trick. See also @Rule, btw.

Copy link
Member

Choose a reason for hiding this comment

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

On many places in our tests, we use @Rule TemporaryFolder. See https://github.com/enso-org/enso/blob/develop/engine/runtime-integration-tests/src/test/java/org/enso/interpreter/test/privateaccess/PrivateCheckDisabledTest.java#L15. Implementing ContextTest as Rule, we wouldn't probably need to subclass it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sadly sometimes sometimes we use default context, sometimes more specialized one. Sometimes we cleanup on every test case, sometimes when the whole class is done. A lot of variation tbh.

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

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

I'd estimate the difference between ctx.close() and ctx.close(); ctx = null to be minimal, not gigabytes. But it doesn't hurt.

PackageManager.shutdown() might be the culprit.

In any case, these changes do not hurt.

Copy link
Member

@Akirathan Akirathan left a comment

Choose a reason for hiding this comment

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

Thanks for investigating the issue. All the changes seems reasonable.

@hubertp
Copy link
Collaborator Author

hubertp commented Aug 12, 2024

Seems like some of our leaks come from TCK tests. This is after I disabled them:
Screenshot from 2024-08-12 12-34-55

@hubertp
Copy link
Collaborator Author

hubertp commented Aug 12, 2024

Updated description to reflect on the achieved/potential improvements.

Can't read IR from an already closed context
@hubertp hubertp force-pushed the wip/hubert/tests-memory-leaks branch from 7f67066 to 9eb3f2f Compare August 12, 2024 15:33
@hubertp hubertp added the CI: Ready to merge This PR is eligible for automatic merge label Aug 13, 2024
@mergify mergify bot merged commit ff7e31c into develop Aug 13, 2024
43 checks passed
@mergify mergify bot deleted the wip/hubert/tests-memory-leaks branch August 13, 2024 08:01
@JaroslavTulach JaroslavTulach mentioned this pull request Sep 26, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants