<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Observation: It's dramatic how
injecting a tiny amount of shared mutable state ripples
throughout the design. <br>
<br>
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.
<br>
<br>
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. <br>
<br>
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.<br>
</font></font><br>
<div class="moz-cite-prefix">On 6/9/2023 2:38 AM, Adam Sotona wrote:<br>
</div>
<blockquote type="cite" cite="mid:I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com">
<pre class="moz-quote-pre" wrap="">On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <a class="moz-txt-link-rfc2396E" href="mailto:asotona@openjdk.org"><asotona@openjdk.org></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Classfile context object and multi-state options have been discussed at <a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html">https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html</a>
This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
Please review.
Thanks,
Adam
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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: <a class="moz-txt-link-freetext" href="https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539">https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539</a>
</pre>
</blockquote>
<br>
</body>
</html>