[10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

[Aleksey Shipilev]

On 07/14/2017 05:24 PM, Claes Redestad wrote:
>>> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/
>> I think this is fine from concurrency standpoint. Not sure how safe it is to
>> increase OSF footprint, that's your call! I also think the largest improvement
>> would be from avoiding the intern() call in constructor -- I frequently observed
>> it on the OSF hot paths. I would trade excess field for avoiding String.intern()
>> any day.
> 
> Maybe I'm not being imaginative enough, but I've not seen any heap
> dumps where #OSFs are anywhere near problematic quantities.
> 
> For 64-bit VMs with compressed oops then it appears the change is
> footprint neutral due to padding (according to JOL estimates), and if we
> had to really optimize for applications with a huge number of OSFs then
> it appears there are other things we could examine to do as well..

OK then! Having no impact on 64-bit COOPs VM is good enough for me today.

Maybe we should drop "null" stores in constructors, and instead rely on default
values for them, since we are talking startup performance here where optimizing
compilers have not yet got their chance.

-Aleksey