Observation: It's dramatic how injecting a tiny amount of shared mutable
state ripples throughout the design.
After thinking about this some more, I think the main problem is that we
are still trying to have the cache be transparent, which means that
Classfile is taking on all the complexity of unbounded shared mutability
"just in case" the user wants some.
The other part of this refactor, which we've not done yet, is
refactoring the caching of the CHR data (through Option) so it is more
explicit. I think part of what we're running into here is that we've
not done that part yet, so we are stills stuck in the as-if-static world.
So let's take a step back and sketch out what the CHR/caching options
might look like. If we make caching explicit, we can make sharability
explicit too, and then we are not trying to add thread-safety back into
a seemingly-immutable-but-not-really object.
On 6/9/2023 2:38 AM, Adam Sotona wrote:
On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona<asot...@openjdk.org> wrote:
Classfile context object and multi-state options have been discussed
athttps://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
This patch implements the proposed changes in Classfile API and fixes all
affected code across JDK sources and tests.
Please review.
Thanks,
Adam
Adam Sotona has updated the pull request incrementally with two additional
commits since the last revision:
- proposed semi-synchronized caching, where the map is not locked during
delegate call
- used Factory.INSTANCE for system ClassHierarchyResolver cache
I'll run our standard benchmarks to compare following scenarios:
- static synchronized single instance cache (current master)
- context-based non-synchronized caches `HM::computeIfAbsent`
- context-based fully synchronized caches `CHM::computeIfAbsent`
- context-based thread-safe lazy synchronized caches `CHM::get ... compute ...
CHM::put`
And let's see the performance impact.
-------------
PR Comment:https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539
