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
