RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory
David M. Lloyd
duke at openjdk.org
Fri Jul 5 14:46:47 UTC 2024
On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd <duke at openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 441:
>>
>>> 439: }
>>> 440:
>>> 441: return SerializationBytecodeGenerator.defaultReadObjectForSerialization(cl);
>>
>> How likely is it for multiple libraries to request readObject for the same class?
>>
>> If it happens that many clients request factories for the same class, we can consider computing and leaving the MHs in a `ClassValue` instead (so the MHs can be GC'd when `cl` is unreachable, but are otherwise cached and shared)
>
> My hope is that the method handle would be more easily inlined when each one is a separate constant. I'd feel less confident that this would be the case if I indirected through `List`. I think it would also increase the size of the generated method as well, though I'm not sure if there actually is any practical consequence to this.
>
> Also, this was easier. ;-)
Oh, this comment landed on the wrong spot for some reason. To respond to the actual post here, I figured that the serialization library is likely to perform this caching anyway, so adding another layer here would just put more burden on the GC for no gain. But I'm not strongly committed to that stance.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661016516
More information about the core-libs-dev
mailing list