On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd <d...@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
