Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

2020-05-06 Thread Alan Bateman

On 06/05/2020 15:45, Jim Laskey wrote:

http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02

This version looks okay to me.

-Alan.


Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

2020-05-06 Thread Jim Laskey
http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 



> On May 6, 2020, at 11:05 AM, Alan Bateman  wrote:
> 
> On 06/05/2020 14:42, Jim Laskey wrote:
>> :
>> 
>> Aside: The order in the file is still somewhat scattered, based on archive 
>> and archive content.  We have the a pattern based sorting plugin which we 
>> don't use and we never did any locality vs performance testing.
>> 
> Not in the test but the JDK does use the order-resources plugin with the 
> following pattern:
> 
> JLINK_ORDER_RESOURCES += \
> /java.base/java/** \
> /java.base/jdk/** \
> /java.base/sun/** \
> /java.base/com/** \
> /jdk.localedata/** \
> #
> 
> Anyway, I looked at webrev-01 and the jlink changes look good. The updated 
> test doesn't use the jimage API so no need to open jdk.internal.jimage. The 
> imports can be removed too, also RUNTIME is no longer used in this version. 
> Have you decided on a test name? The rallying call is "reproducible builds" 
> and I'd prefer to have "Reproducible" in the test name so its consistent with 
> the existing test that checks for reproducible with user modules.
> 
> -Alan.
> 
> 



Re: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ

2020-05-06 Thread Alan Bateman

On 06/05/2020 14:42, Jim Laskey wrote:

:

Aside: The order in the file is still somewhat scattered, based on 
archive and archive content.  We have the a pattern based sorting 
plugin which we don't use and we never did any locality vs performance 
testing.


Not in the test but the JDK does use the order-resources plugin with the 
following pattern:


JLINK_ORDER_RESOURCES += \
    /java.base/java/** \
    /java.base/jdk/** \
    /java.base/sun/** \
    /java.base/com/** \
    /jdk.localedata/** \
    #

Anyway, I looked at webrev-01 and the jlink changes look good. The 
updated test doesn't use the jimage API so no need to open 
jdk.internal.jimage. The imports can be removed too, also RUNTIME is no 
longer used in this version. Have you decided on a test name? The 
rallying call is "reproducible builds" and I'd prefer to have 
"Reproducible" in the test name so its consistent with the existing test 
that checks for reproducible with user modules.


-Alan.