Fix file descriptor leak through worker classpath #173
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
Workers created through the worker API live as long as the Gradle daemon. Therefor, they should not have any JARs on their classpath that are part of the project being built. Otherwise, the worker keeps these JARs open, leading to a file descriptor leak and an unability to clean the project on Windows. Also, on every change to the dependencies, a new worker would be created, greatly increasing memory pressure on the system. Finally, the workers of different subprojects would be incompatible due to their different classpaths, increasing the number of spwawned workers even more. This fix changes the worker such that only JMH is put on the worker classpath. The project's own dependencies are passed to the worker as arguments. Some trickery was necessary, because JMH insists on looking for project-specific files on its own classpath. This should probably be reported as a bug to JMH. It should either look on the Thread's context classloader (which we could change) or make these locations externally configurable on the Runner class.
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.
Workers created through the worker API live as long as the Gradle daemon.
Therefor, they should not have any JARs on their classpath that are part
of the project being built. Otherwise, the worker keeps these JARs open,
leading to a file descriptor leak and an unability to clean the project
on Windows. Also, on every change to the dependencies, a new worker would
be created, greatly increasing memory pressure on the system. Finally,
the workers of different subprojects would be incompatible due to their
different classpaths, increasing the number of spwawned workers even more.
This fix changes the worker such that only JMH is put on the worker classpath.
The project's own dependencies are passed to the worker as arguments.
Some trickery was necessary, because JMH insists on looking for project-specific
files on its own classpath. This should probably be reported as a bug to JMH.
It should either look on the Thread's context classloader (which we could change)
or make these locations externally configurable on the Runner class.
Fixes #170, #163