RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance [v20]

[Jorn Vernee]

On Wed, 5 Jul 2023 16:00:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ok, thanks. This is similar to the solution I would have suggested.
>> 
>> The only thing I'm unsure about is races. ClassValue allows multiple threads to race to compute the final value, but in the end only 1 is chosen that is returned to all threads.
>> 
>> If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.
>> 
>> Maybe this code should synchronize on `r` to make sure only 1 lookup is created per interface. (Letting threads race to compute the value is also a possibility, but it also leads some threads to do work that is then discarded, and then the VM has to clean up the class they defined as well).
>
>> If multiple threads race to create a new proxy lookup here, they will all get a distinct lookup returned to them. I think this is okay? Though, it would mean we have less sharing of proxy classes.
> 
> yes, that's okay.  We can also do what you suggest to synchronize on `r`.

I don't have a strong opinion, but I'm in favor of synchronizing (in a double-checked locking style), because the amount of work that would be discarded in the case of a race would be non-trivial.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1253523585