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

Mandy Chung mandy.chung at oracle.com
Fri Feb 24 23:38:30 UTC 2017

> On Feb 23, 2017, at 2:57 PM, Claes Redestad <claes.redestad at 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/

   Should the hashCode methods taking byte[] parameter be removed?

   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.


More information about the jigsaw-dev mailing list