RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v11]

[Brian Goetz]

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<asotona at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230609/e065f743/attachment-0001.htm>