improvement (?): Allow for clearing JrtClassPath caches #11070
Closed
Conversation
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
| That said, I don't know if those caches are causing the issue, but it's my best guess. |
In long running sessions of presentation compiler it seem like these caches can easily get corrupted and we longer can use the compiler within the current JVM or classloader. I couldn't find the exact problem, but this is the only difference with Scala 2.12 and Scala 3, where those caches are not present. We don'tget those issues there. I added a workaround in Metals for this, but it uses reflection quite heavily. Alternatively, maybe this caching is not needed? I see that it's created only in Global once, so maybe we could cache it in Global instead?
tgodzik force-pushed the allow-clearing-caches branch from a5cbb30 to 9ef54d3 Compare | I know realized, we can do the same with |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
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.
In long running sessions of presentation compiler it seem like these caches can easily get corrupted and we longer can use the compiler within the current JVM or classloader.
I couldn't find the exact problem, but this is the only difference with Scala 2.12 and Scala 3, where those caches are not present. We don'tget those issues there.
I added a workaround in Metals for this, but it uses reflection quite heavily.
Alternatively, maybe this caching is not needed? I see that it's created only in Global once, so maybe we could cache it in Global instead?
The workaround with reflection is in https://github.com/scalameta/metals/pull/7541/files
Should help with scala/bug#13045