Repository navigation
fix(deps): pin kryo to 4.0.2 to restore IdentityObjectIntMap.clear fix (kryo #558/#549) - #2310
Merged
Merged
Conversation
…x (kryo filodb#558/filodb#549) The Scala 2.13 upgrade left kryo resolving to 4.0.0 in the assembly. Two differently-named kryo artifacts coexist on the classpath — plain `com.esotericsoftware:kryo` (from de.javakaffee:kryo-serializers + the direct pin) and `com.esotericsoftware:kryo-shaded:4.0.2` (via chill). sbt does not evict across different artifact names, and sbt-assembly's `MergeStrategy.first` for `com.esotericsoftware.**` arbitrarily selected the plain `kryo:4.0.0` classes in the newer build. kryo 4.0.0 predates fix filodb#558/filodb#549 ("IdentityObjectIntMap.clear taking more time — Realloc instead of clearing large maps"): MapReferenceResolver.reset()/DefaultClassResolver.reset() call `clear()` (walks the entire retained backing array) instead of `clear(2048)` (realloc/shrink). On query fan-in (aggregator) nodes the pooled Kryo reference map never shrinks after a large result, so every subsequent reset() is O(peak-capacity) — observed as a hot IdentityObjectIntMap.clear() in JFR profiles plus retained-map GC pressure. Pinning `kryo` to 4.0.2 evicts the 4.0.0 copy so both `kryo` and `kryo-shaded` resolve to 4.0.2; verified the built assembly's MapReferenceResolver.reset() now uses clear(2048).
adya-shrivastava
approved these changes
Jul 15, 2026
siri-varma
approved these changes
Jul 15, 2026
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
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.
The Scala 2.13 upgrade left kryo resolving to 4.0.0 in the assembly. Two differently-named kryo artifacts coexist on the classpath — plain
com.esotericsoftware:kryo(from de.javakaffee:kryo-serializers + the direct pin) andcom.esotericsoftware:kryo-shaded:4.0.2(via chill). sbt does not evict across different artifact names, and sbt-assembly'sMergeStrategy.firstforcom.esotericsoftware.**arbitrarily selected the plainkryo:4.0.0classes in the newer build.kryo 4.0.0 predates fix #558/#549 ("IdentityObjectIntMap.clear taking more time — Realloc instead of clearing large maps"): MapReferenceResolver.reset()/DefaultClassResolver.reset() call
clear()(walks the entire retained backing array) instead ofclear(2048)(realloc/shrink). On query fan-in (aggregator) nodes the pooled Kryo reference map never shrinks after a large result, so every subsequent reset() is O(peak-capacity) — observed as a hot IdentityObjectIntMap.clear() in JFR profiles plus retained-map GC pressure.Pinning
kryoto 4.0.2 evicts the 4.0.0 copy so bothkryoandkryo-shadedresolve to 4.0.2; verified the built assembly's MapReferenceResolver.reset() now uses clear(2048).Pull Request checklist
Current behavior :
No change in behavior expected
New behavior :
No change in behavior expected