RFR: 8175561: Memory churn in jimage code affects startup after resource encapsulation changes

[Claes Redestad]

Hi,

thanks Mandy and Jim for reviewing!

However, I've found enough evidence now that we should this
one step further and eliminating the allocation in
BasicImageReader::findLocation(String, String), which completely
gets rid of the regressions we're seeing:

http://cr.openjdk.java.net/~redestad/8175561/jdk.02/
http://cr.openjdk.java.net/~redestad/8175561/jdk.01.02.diff/

Working through the details on how to do this it became clear
that stringing together ImageStringsReader.hashCode - as done in
ImageLocationWriter - is likely a bug in the making since it's not
guaranteed to give equivalent results to applying the same method
to the whole string. I took the liberty to fix this, and ran the final
patch through several JDK and HotSpot test lists without any surprises.

Thanks!

/Claes

On 02/23/2017 10:57 PM, Claes Redestad wrote:
> Hi,
>
> various resource encapsulation changes in 9+148 meant an uptick in
> footprint and startup times for certain applications.
>
> While some of this regression is hard to avoid[1] (opening readers,
> touching more memory mapped pages etc), a large part is due to simple
> java allocation churn, some of which can be optimized away by reducing
> the number of objects we create when scanning modules for resources.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175561
> Webrev: http://cr.openjdk.java.net/~redestad/8175561/jdk.01/
>
> Thanks!
>
> /Claes
>
> [1] Things we could do in the future to improve further include adding
> an index to the jimage (too late for 9) or marking modules with no 
> non-encapsulated resources as such so that they can be skipped.