RFR: JDK-8156781 - change to jlink has result in test failure

http://cr.openjdk.java.net/~jlaskey/8156781/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8156781

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

> On May 11, 2016, at 2:21 PM, Mandy Chung wrote: > >> >> On May 11, 2016, at 10:17 AM, Jim Laskey (Oracle) >> wrote: >> >> >>> On May 11, 2016, at 2:03 PM, Mandy Chung wrote: >>> >>> >>>> On May 9, 2016, at 10:

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

> On May 11, 2016, at 2:03 PM, Mandy Chung wrote: > > >> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) >> wrote: >> >> Modifies the jlink sort-plugin to accept a classlist to order files in the >> jimage. >> >> http://cr.openjdk.j

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

Only that experimentation is still ongoing. I have an agreement with Claes that he will make that change when he is satisfied with an improvement. > On May 11, 2016, at 9:35 AM, Alan Bateman wrote: > > > > On 11/05/2016 13:30, Claes Redestad wrote: >> Updated changes look good, too. >> >>

RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8155237

Re: Having problem building jdk9-dev

Mac OS X - reproducible with a clean repo. > On May 9, 2016, at 10:08 AM, Jim Laskey (Oracle) > wrote: > > > > > Generating blacklisted certs > java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules > at > jdk.internal.loader.BuiltinCla

Having problem building jdk9-dev

Generating blacklisted certs java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-ea/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-ea/Class

RFR: JDK-8132994 - /modules and /packages should not be parsed by the jimage parser

Changed to special case parse /modules/ and /packages/. Will actually reduce string table size slightly (better common string match.) http://cr.openjdk.java.net/~jlaskey/8132994/webrev/index.html https://bugs.openjdk.java.net/brows

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Thank you, changes incorporated. > On Apr 22, 2016, at 2:08 PM, Mandy Chung wrote: > > Hi Jim, > >> On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle) >> wrote: >> >> Listing is by module, extract has been by module for some time. >> >> ht

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

Thank you. > On Apr 24, 2016, at 5:23 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> The unused cache is being unnecessarily activated (ThreadLocal) when buffers >> are being released. >> >> http://cr.openjdk.java

Re: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

JCK change incorporated. Thank you. > On Apr 24, 2016, at 5:22 AM, Alan Bateman wrote: > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the >> jdk jimage.hpp header. Brought the head

Build craziness

make clean ; make images Building target 'images' in configuration 'macosx-x86_64-normal-server-fastdebug' Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 dtrace fprof jni-check jvmci jvmti management nmt services vm-structs' Compiling 8 files for BUILD_TOOLS_LANGTOO

Re: RFR: JDK-8154090 - Remove support for jimage recreate

Thank you. > On Apr 22, 2016, at 10:53 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html >> <http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html> >&g

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Thank you, will wait. > On Apr 22, 2016, at 10:55 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> Listing is by module, extract has been by module for some time. >> >> http://cr.openjdk.java.net/~jlaskey/80

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

Will change. Thank you. > On Apr 22, 2016, at 10:59 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:54, Jim Laskey (Oracle) wrote: >> It can be outside, does the change add value? >> >> > I think so as it's always been odd that the jimage tool wou

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

It can be outside, does the change add value? > On Apr 22, 2016, at 10:12 AM, Jim Laskey (Oracle) > wrote: > > Now prints usage. > > http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html > <http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html> >

RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name

Implemented as requested by the runtime team. http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8147634

RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Listing is by module, extract has been by module for some time. http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8069079

RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

The unused cache is being unnecessarily activated (ThreadLocal) when buffers are being released. http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8154179

RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html https://bugs.openjdk.java.net/browse/JDK

RFR: JDK-8153930 - Compiler crashed (intermittently)

Two race conditions eliminated and ImageReader made idempotent. http://cr.openjdk.java.net/~jlaskey/8153930/webrev/index.html (Note webrev fails to diff ImageReader.java, best to view new file.) https://bugs.openjdk.java.net/browse/

RFR: JDK-8154090 - Remove support for jimage recreate

http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8154090

RFR: JDK-8082537 - jimage should print usage when started with no args

Now prints usage. http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8082537

error reading module path

Periodically, when doing an incremental build I run into the following; Error: error reading module path java.io.IOException: error reading module path at jdk.tools.jmod.JmodTask$JmodFileWriter.hashDependences(jdk.jlink/JmodTask.java:585) at jdk.tools.jmod.JmodTask$JmodFileWriter.writeModuleInfo

Re: RFR: JDK-8147460: Clean-up jrtfs implementation

+1 > On Apr 14, 2016, at 2:47 PM, Xueming Shen wrote: > > > [re-post, including jigsaw list] > > Hi, > > Please hep review the cleanup changes for jrtfs implementation. > > issue: https://bugs.openjdk.java.net/browse/JDK-8147460 > webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev >

Re: RFR: JDK-8151807 - ImageBufferCache should release buffers when all classes are loaded

javac uses 3 buffers concurrently even without compression. These seem to be legit (allocated and released properly.) > On Apr 13, 2016, at 10:23 AM, Alan Bateman wrote: > > > On 13/04/2016 14:18, Jim Laskey (Oracle) wrote: >> Yes, needed for decompression. >> >

Re: RFR: JDK-8151807 - ImageBufferCache should release buffers when all classes are loaded

Yes, needed for decompression. > On Apr 13, 2016, at 10:15 AM, Alan Bateman wrote: > > On 11/04/2016 14:37, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/8151807/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8151807 > This looks quit

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

Thank you. > On Apr 11, 2016, at 9:52 AM, Sundararajan Athijegannathan > wrote: > > +1 > > On 4/11/2016 6:13 PM, Jim Laskey (Oracle) wrote: >> Any one else. >> >>> On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: >>> >>

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

Any one else. > On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: > > Hi Jim, > > lower-case thumbs up! > > Best, > > Michael > >> Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) > <mailto:james.las...@oracle.com>>: >> >>

RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

The code was reworked to use jrtfs: instead of reading from javafx.jar. http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8075550

Re: [9] Review request: 8153754: Nashorn needs access to com.sun.javafx.application

+1 > On Apr 7, 2016, at 1:47 PM, Kevin Rushforth > wrote: > > Jim L, > > Please review the following simple change to add the needed qualified exports: > > http://cr.openjdk.java.net/~kcr/8153754/webrev.00/ > > -- Kevin >

Re: Please review 8148491: Revisit jlink --genbom

+1 > On Mar 29, 2016, at 12:38 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8148491 > > Thanks, > -Sundar

Re: Initial webrev with changes for JDK 9 - jimage

://bugs.openjdk.java.net/browse/JDK-8151807 ImageBufferCache should use sun.nio.ch.Util — Jim > On Mar 10, 2016, at 7:22 PM, Jim Laskey (Oracle) > wrote: > > Thank you Roger. Comments inline. In general, I will hold off changes until > after merge so as not to destabilize. Note that I

Re: Initial webrev with changes for JDK 9 - jimage

narrow it down. >> >> It would be useful to create an jira entry for the changes that are being >> delayed. >> >> Roger >> >> >> On 3/10/2016 6:22 PM, Jim Laskey (Oracle) wrote: >>> Thank you Roger. Comments inline. In general, I will h

Re: Initial webrev with changes for JDK 9 - jimage

Thank you Roger. Comments inline. In general, I will hold off changes until after merge so as not to destabilize. Note that ImageBufferCache and Decompression are not currently used. > On Mar 8, 2016, at 2:07 PM, Roger Riggs wrote: > > Hi, > > Review comments for the jimage code in java.ba

Re: [9] RFR: 8146249: libjimage should use delete[] with new[]

+1 Note that these changes will be superceded (thrown out) by the Jake merge. — Jim > On Feb 2, 2016, at 3:48 PM, Artem Smotrakov > wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates a couple of files in libjimage to use delete[] operator together > with n

Re: hg: jigsaw/jake/jdk: Fix build breakage

Just caught this myself. Change in makes? Have been building all along. > On Jan 5, 2016, at 12:35 PM, alan.bate...@oracle.com wrote: > > Changeset: dbfd01abc3f7 > Author:alanb > Date: 2016-01-05 16:11 + > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dbfd01abc3f7 > >

Re: RFR: JDK 9: 8143879 jdk/internal/jimage/JImageReadTest.java crashes jvm in msvcr120.dll

I had it in my pending changes, but I’ll isolate and add. > On Dec 2, 2015, at 11:17 AM, Roger Riggs wrote: > > Hi Alan, > > I just pushed it to jdk9, it should merge easily; can you or Jim take care > of getting it into Jake. > > Thanks, Roger > > > On 12/02/2015 10:15 AM, Alan Bateman

Re: RFR: JDK 9: 8143879 jdk/internal/jimage/JImageReadTest.java crashes jvm in msvcr120.dll

+1 > On Dec 1, 2015, at 7:18 PM, Roger Riggs wrote: > > Please review a fix for jimage native code to correctly maintain the list of > ImageFileReaders. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8143879 > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jimage-read-814387

Re: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in msvcr120.dll

+1 > On Nov 12, 2015, at 11:20 AM, Roger Riggs wrote: > > Please review additions to jimageFile to diagnose an intermittent failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8141571 > > Thanks, Roger

Re: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages

+1 > On Nov 5, 2015, at 5:45 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8141521 > > Thanks > -Sundar

Re: [9] RFR: 8140649: imageFile should use delete[] with new[]

+1 > On Nov 2, 2015, at 9:30 AM, Artem Smotrakov > wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates imageFile.cpp to use delete[] operator together with new[]. It > also adds a check to ImageLocation::set_data(u1*) method to prevent a > possible null-dere

Re: CFV: New Committer: Christian Tornqvist

Vote: Yes — Jim > On Sep 16, 2015, at 3:42 PM, Karen Kinnear wrote: > > I hereby nominate Christian Tornqvist to Jigsaw Committer. > > Christian is the hotspot runtime SQE lead and a Reviewer on the jdk9 project. > Christian has contributed new tests and made extensive changes to the hotspot

Re: CFV: New Jigsaw Committer: Lois Foltan

Vote: Yes — Jim > On Sep 16, 2015, at 3:43 PM, Karen Kinnear wrote: > > > I hereby nominate Lois Foltan to Jigsaw Committer. > > Lois is a member of the hotspot runtime team and a committer on the jdk9 > project. > Lois has been contributing to Project Jigsaw for more than a year, including

Re: jlink tool doesn't create windows os compatible launcher in resulting runtime image

Note that before we can accept external changes you must complete an OCA http://www.oracle.com/technetwork/community/oca-486395.html . Thank you, — Jim > On Sep 16, 2015, at 12:55 PM, Ali Ebrahimi wrote: > > Hi, > > The following patch tries to fix this: > > diff --git > a/src/jdk.jlink/

Re: CFV: New Jigsaw Committer: Harold Seigel

Vote: yes — Jim > On Sep 11, 2015, at 1:31 PM, Karen Kinnear wrote: > > > I hereby nominate Harold Seigel to Jigsaw Committer. > > Harold is a member of the hotspot runtime team and a Reviewer on the jdk9 > project. > Harold has been contributing to Project Jigsaw in the hotspot runtime for

Re: RFR: 8087181: Move native jimage code to its own library (maybe libjimage) (against hs-rt)

Have a patch ready with these changes. > On Sep 5, 2015, at 10:54 AM, Alan Bateman wrote: > > On 28/08/2015 18:05, Jim Laskey (Oracle) wrote: >> https://bugs.openjdk.java.net/browse/JDK-8087181 >> <https://bugs.openjdk.java.net/browse/JDK-8087181> >> >>

Re: RFR: 8087181: Move native jimage code to its own library (maybe libjimage) (against hs-rt)

Passes JPRT -testset hotspot, and no new fails on -testset pit . > On Aug 28, 2015, at 2:05 PM, Jim Laskey (Oracle) > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8087181 > <https://bugs.openjdk.java.net/browse/JDK-8087181> > > http://cr.openjdk.java.ne

RFR: 8087181: Move native jimage code to its own library (maybe libjimage) (against hs-rt)

https://bugs.openjdk.java.net/browse/JDK-8087181 http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-top http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-jdk http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-hotspot

Re: RFR: Hotspot jimage API

I’ll see if I can float that balloon today > On Aug 24, 2015, at 3:43 AM, Alan Bateman wrote: > > > > On 20/08/2015 18:16, Jim Laskey (Oracle) wrote: >> External link is here >> http://cr.openjdk.java.net/~jlaskey/jake/HotSpotJImageAPI.pdf >>

Re: RFR: JDK-8080511 - Refresh of jimage support

2. Any plan that bootmodules.jiamge or > other jimage files will contain such compressed resources? > > Thanks a lot! > > 2015-06-18 8:08 GMT+08:00 Jim Laskey (Oracle) <mailto:james.las...@oracle.com>>: > https://bugs.openjdk.java.net/browse/

Re: RFR: Hotspot jimage API

External link is here http://cr.openjdk.java.net/~jlaskey/jake/HotSpotJImageAPI.pdf > On Aug 20, 2015, at 12:39 PM, Jim Laskey (Oracle) > wrote: > > This is a description of changes precipitated from > https://bugs.openjdk.java.net/browse/JDK-8087181 > > https://wiki.

RFR: Hotspot jimage API

This is a description of changes precipitated from https://bugs.openjdk.java.net/browse/JDK-8087181 https://wiki.se.oracle.com/display/JPG/Hotspot+jimage+API Cheers, — Jim

Re: Review for JDK-8132527

+1 > On Aug 18, 2015, at 5:34 AM, Jean-Francois Denise > wrote: > > Hi, > asking for review to fix jvm crashing when replacing jimage file with > recreated one. > > The name of the module metadata resource was wrongly associated to the name > of the recreated jimage file. The original name m

Re: Review for JDK-8132335

+1 > On Jul 24, 2015, at 12:29 PM, Jean-Francois Denise > wrote: > > Hi, > asking for review to fix jimage recreate that is failing with NPE. Bug is > http://cr.openjdk.java.net/~jfdenise/JDK-8132335/ > Thanks. > JF

RFR: JDK-8080511 - Refresh of jimage support

https://bugs.openjdk.java.net/browse/JDK-8080511 This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and impro

Re: RFR: Proposed jimage refresh for JDK9

[Have been OOTO] I have a cunning plan. However, getting this jimage refresh in play has me really bogged down (there is always one more thing -- curse you Jobs.) I do plan on moving the bulk of the jimage JVM_ calls to the JDK. The callbacks into the VM will be reduced to a few calls (open, c

Re: RFR: Proposed jimage refresh for JDK9

> in JrtPath, instead of > boolean isSame = Arrays.equals(this.getResolvedPath(), > ((JrtPath)other).getResolvedPath()); > return isSame? isSame : jrtfs.isSameFile(this, (JrtPath)other); > the usual code is: > JrtPath path = (JrtPat

Re: RFR: Proposed jimage refresh for JDK9

> On May 19, 2015, at 1:50 PM, Alan Bateman wrote: > > > > On 19/05/2015 17:43, Jim Laskey (Oracle) wrote: >> : >>> jdk.internal.jimage.ExternalFilesWriter >>> >>> 93 private static String nativeDir(String filename) { >>> 94

Re: RFR: Proposed jimage refresh for JDK9

7;)) > 73 .sorted() > 74 .collect(Collectors.toList()); > 75 modulePackages.put(moduleName, localPackages); > 76 }); > > can replace forEach with collect(Collectors.toMap(Functions.identity(), n -> > modulePackages

<    1   2