Memory usage improvements for transform cache #336
Merged
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
This avoids storing data in memory but slows down cache building, so we gate it behind a system property that's off by default
|
This looks good, thanks! |
AlexIIL
added a commit
that referenced
this pull request
Jul 28, 2023
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 PR implements some basic optimizations to the transform cache memory usage that are simple and should not break anything.
The first change involves changing the internals hider transformation logic to read the class bytes from disk twice instead of storing them in a map, thus avoiding storing all class bytes in RAM at once. I checked and this didn't seem to regress transform cache build times meaningfully compared to 0.2.0-beta.4.
I also added a new system property,
loader.zipfs.use_temp_file, which allows bypassing the JavaZipFileSystemlogic of storing all files being written to the ZIP in RAM. Unfortunately this introduces a fairly hefty performance penalty to building the transform cache (presumably due to all the IO going to temporary files on disk first) so it can't be enabled by default. I still think it's a worthwhile tunable to offer as it only impacts launches in which the transform cache needs to be rebuilt.Additionally, I took the opportunity to fix an annoying bug where the transform cache cannot be recreated correctly if incomplete, due to
FileAlreadyExistsExceptionbeing thrown elsewhere in the code. I chose the simplest solution of just deleting the old incomplete file before proceeding.This allows the BlanketCon 23 testing pack to be launched on 700MB of RAM.