Use invokedynamic to statically cache materialized class tags (initially disabled by default)#7862
Use invokedynamic to statically cache materialized class tags (initially disabled by default)#7862retronym wants to merge 2 commits intoscala:2.13.xfrom
Conversation
|
Marking for (late) consideration for 2.13.0 because binary compatibility constraints would not allow us to add the bootstrap method in 2.13.x |
|
Could |
|
That sounds like a good use case for value classes, but it would take a bit of work to untangle the current design from |
One issue is that |
|
An alternative approach to |
Yes :-) But maybe it's time to do that, instead of adding more complexity (even if hidden behind the scenes) to ClassTag?
I don't see why that wouldn't work though?
Right, that seems like a good fit. |
c33cff5 to
c04b7b9
Compare
|
Pulling this thread a little further, I'm trying to unify symbol literal, structural call site, and class tag caching behind a single bootstrap method. |
c97a79b to
e118f59
Compare
During compiler profiling, I've found cases where the repeated allocation of `s.r.ClassTags` (a wrapper over j.l.Class) contributed to allocation pressure. This commit introduces a static cache at the materialization site using invokedynamic. This is analagous to the way we cache Symbol literals.
e118f59 to
6f7ec45
Compare
During compiler profiling, I've found cases where the repeated allocation
of
s.r.ClassTags(a wrapper over j.l.Class) contributed to allocationpressure.
This commit introduces a static cache at the materialization site using
invokedynamic. This is analagous to the way we cache Symbol literals.