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

Properly close Scala compiler classloaders in server and unit tests #3468

Merged
merged 9 commits into from
Sep 6, 2024

Conversation

lihaoyi
Copy link
Member

@lihaoyi lihaoyi commented Sep 6, 2024

Previously we were just leaking the URLClassLoaders, which would give CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled. in scalajslib.test and sometimes in actual usage for a long lived server. This PR ensures we ZincWorkerImpl.close actually calls URLClassLoader.close, and also replaced val eval = UnitTester in our test suite with UnitTester.scoped{ eval => so we can ensure closing of the UnitTester and URLClassLoader after each test completes

With this change, scalajslib.test no longer prints the above error. Hopefully it makes it stop happening in production as well. scalajslib.test also drops from 7.5min to 6.5min (and drops further to 5min when I removed Scala.js 1.3.1 from the test matrix)

@lihaoyi lihaoyi marked this pull request as ready for review September 6, 2024 04:05
@lihaoyi lihaoyi merged commit 588e1b7 into com-lihaoyi:main Sep 6, 2024
25 checks passed
@lefou lefou added this to the 0.12.0-RC1 milestone Sep 6, 2024

// Make sure we at least pick up all the URLClassLoaders, since we know those are
// AutoCloseable, although there may be other AutoCloseable classloaders as well
assert(urlClassLoaders.toSet[AutoCloseable].subsetOf(closeableClassloaders.toSet))
Copy link
Member

@lefou lefou Sep 6, 2024

Choose a reason for hiding this comment

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

This assert could fail at runtime, potentially breaking a workflow that was working before. Since we're just detecting after the fact, a log/error message without a hard failure would be more appropriate.

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