Avoid leaking plugin classes into Gradle's pattern spec result cache#430
Merged
johnrengelman merged 1 commit intoGradleUp:masterfrom Nov 21, 2018
Merged
Avoid leaking plugin classes into Gradle's pattern spec result cache#430johnrengelman merged 1 commit intoGradleUp:masterfrom
johnrengelman merged 1 commit intoGradleUp:masterfrom
Conversation
Collaborator
|
Thank you for the digging into this and providing the fix @mark-vieira ! |
Collaborator
|
This fix is now available in 4.0.3 |
Contributor
Author
|
Awesome. Thanks for the quick turnaround. |
This file contains hidden or 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
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.
This pull request fixes some memory leak issues we noticed when using the Shadow plugin with long lived Gradle daemons. The commit addresses two items:
RelativeArchivePathwas unnecessarily keeping a reference toDefaultFileCopyDetailswhich is a pretty heavyweight object. Turns out this is never actually used so this has been removed.The whole reason item (1) was an issue was is because results of calls to pattern specs are actually cached by Gradle, such as this one. The cache computes a key based on this
RelativeArchivePath, therefore instances of those stay in memory. Making those instances lighter (by removing the reference toFileCopyDetails) helps here but the root cause is that the daemon keeps strong references back to plugin classes, and therefore, their classloader. When changes tobuildSrchappen these old classloaders pile up, as we cannot garbage collect them due to these cache references. The solution here is to not use non-core types in these caches at all, thus the addition ofgetAsFileTreeElement()toArchiveFileTreeElement. This avoids the need to passArchiveFileTreeElementdirectly toisSatisfiedBy()and thereby ensuring no classes from this plugin leak into the pattern set result caches.