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