> On Feb 23, 2017, at 2:57 PM, Claes Redestad <claes.redes...@oracle.com> 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/ >
ImageStringsReader.java Should the hashCode methods taking byte[] parameter be removed? ImageLocation.java I suggest to add the comment to describe the expect format comparing to the name. something like “/<module>/[<parent>/]<base>[.<ext>]” and a comment for each if-statement what segment is checking. I have carefully reviewed the change which attempts to inline the code and write to avoid object allocation. It looks correct to me. Since jimage is a sensitive area, I suggest to run PIT and do the automated hotspot testing. Mandy
