From Alan.Bateman at oracle.com Wed Aug 1 12:28:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Aug 2018 05:28:21 -0700 Subject: override module with an alternative implementation in the child layer In-Reply-To: References: <2b7560e0-1c40-36b6-b832-3a815b937515@oracle.com> Message-ID: <7a1c660d-f2a3-ec80-5604-99da2a4d526f@oracle.com> On 31/07/2018 06:33, Milen Dyankov wrote: > Thank you for the clarification Alan, > > it seams ALL-DEFAULT does not work with jlink but that is OK as I can > easily find those modules while running my assembly tool and pass the list > to jlink. Right, the ALL-DEFAULT token doesn't mean anything at link time because there is only one module path. Compare that to compile-time or run-time where the module path is composed from an optional upgrade module path, the system modules, and the application module path. > The only difference between what I find and what you posted (I assume 7 was > a typo as your list contains 9 modules) is that there seems to be no ` > java.net.http` module (at least not among the 99 modules shipped in 10.0.1 > that I'm experimenting with) > Sorry, I did mean 9, not 7. The java.net.http module is new for Java SE 11. -Alan From claes.redestad at oracle.com Sat Aug 4 16:22:14 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 4 Aug 2018 18:22:14 +0200 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: References: Message-ID: <8cddf807-c122-3d91-4220-5ddc2b09d948@oracle.com> Hi, Jiangli and I discussed a subtle issue with the archiving changes here last week (she's currently on vacation, and I was at JVMLS this week, so it was never brought to the list, sorry!) Basically: the empty configuration uses things like Collections.emptySet(), which means it will end up deserializing an object from the archive that doesn't (necessarily) have the same identity as the object retrieved from direct uses of Collection.emptySet(). Same goes for the Set.of()/Map.of()/List.of() singletons which might now already exist at runtime in two versions since the change to archive ModuleDescriptors. Oops! This glitch is probably fine semantically for most intents and purposes, but could lead to some unnecessary inefficiencies and theoretically real surprises/bugs, so we probably need to ensure that all singletons we serialize retain the property that they are identical to the object a caller of the respective getter would receive. I think this can be deferred to a must-fix follow-up, mainly since there's some benefit in first cleaning up a few things here first: - currently we have uses of both Collections.emptyFoo() and Foo.of() in the ModuleDescriptor/Configuration code - to be correct, we thus need to archive the Collections.emptyFoo() singletons *and* the various java.util.ImmutableCollections ones - if we first consolidated all uses of Collections.emptyFoo() to Foo.of() (in java.lang.module), we'd only need to archive the immutable singletons in java.util.ImmutableCollections Consolidating to Foo.of() was actually already being considered anyway, so I'll go ahead with a separate RFE.. Thanks! /Claes On 2018-07-20 20:31, Jiangli Zhou wrote: > > > Many thanks to Alan and Claes for discussions and contributions to > this change! > > Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ From jiangli.zhou at oracle.com Mon Aug 6 17:10:04 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 6 Aug 2018 10:10:04 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <8cddf807-c122-3d91-4220-5ddc2b09d948@oracle.com> References: <8cddf807-c122-3d91-4220-5ddc2b09d948@oracle.com> Message-ID: <4b744e13-c4e6-fb36-bba9-611195c0c7e6@oracle.com> Hi Claes, Thanks for filing JDK-8209003 (https://bugs.openjdk.java.net/browse/JDK-8209003)! I'll look into archiving the immutable singletons in ImmutableCollections. Thanks again!! Jiangli On 8/4/18 9:22 AM, Claes Redestad wrote: > Hi, > > Jiangli and I discussed a subtle issue with the archiving changes here > last week (she's currently on vacation, and I was at JVMLS this week, > so it was never brought to the list, sorry!) > > Basically: the empty configuration uses things like > Collections.emptySet(), which means it will end up deserializing an > object from the archive that doesn't (necessarily) have the same > identity as the object retrieved from direct uses of > Collection.emptySet(). > > Same goes for the Set.of()/Map.of()/List.of() singletons which might > now already exist at runtime in two versions since the change to > archive ModuleDescriptors. Oops! > > This glitch is probably fine semantically for most intents and > purposes, but could lead to some unnecessary inefficiencies and > theoretically real surprises/bugs, so we probably need to ensure that > all singletons we serialize retain the property that they are > identical to the object a caller of the respective getter would receive. > > I think this can be deferred to a must-fix follow-up, mainly since > there's some benefit in first cleaning up a few things here first: > > - currently we have uses of both Collections.emptyFoo() and Foo.of() > in the ModuleDescriptor/Configuration code > > - to be correct, we thus need to archive the Collections.emptyFoo() > singletons *and* the various java.util.ImmutableCollections ones > > - if we first consolidated all uses of Collections.emptyFoo() to > Foo.of() (in java.lang.module), we'd only need to archive the > immutable singletons in java.util.ImmutableCollections > > Consolidating to Foo.of() was actually already being considered > anyway, so I'll go ahead with a separate RFE.. > > Thanks! > > /Claes > > > On 2018-07-20 20:31, Jiangli Zhou wrote: >> >> >> Many thanks to Alan and Claes for discussions and contributions to >> this change! >> >> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ > From Alan.Bateman at oracle.com Mon Aug 6 18:42:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Aug 2018 19:42:58 +0100 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <8cddf807-c122-3d91-4220-5ddc2b09d948@oracle.com> References: <8cddf807-c122-3d91-4220-5ddc2b09d948@oracle.com> Message-ID: <4153c9d4-dd1d-7ddc-c0d8-17c1a18dd057@oracle.com> On 04/08/2018 17:22, Claes Redestad wrote: > Hi, > > Jiangli and I discussed a subtle issue with the archiving changes here > last week (she's currently on vacation, and I was at JVMLS this week, > so it was never brought to the list, sorry!) > > Basically: the empty configuration uses things like > Collections.emptySet(), which means it will end up deserializing an > object from the archive that doesn't (necessarily) have the same > identity as the object retrieved from direct uses of > Collection.emptySet(). > > Same goes for the Set.of()/Map.of()/List.of() singletons which might > now already exist at runtime in two versions since the change to > archive ModuleDescriptors. Oops! > > This glitch is probably fine semantically for most intents and > purposes, but could lead to some unnecessary inefficiencies and > theoretically real surprises/bugs, so we probably need to ensure that > all singletons we serialize retain the property that they are > identical to the object a caller of the respective getter would receive. > > I think this can be deferred to a must-fix follow-up, mainly since > there's some benefit in first cleaning up a few things here first: > > - currently we have uses of both Collections.emptyFoo() and Foo.of() > in the ModuleDescriptor/Configuration code > > - to be correct, we thus need to archive the Collections.emptyFoo() > singletons *and* the various java.util.ImmutableCollections ones > > - if we first consolidated all uses of Collections.emptyFoo() to > Foo.of() (in java.lang.module), we'd only need to archive the > immutable singletons in java.util.ImmutableCollections It's good to bring this up. I don't think there is a real issue right now but it is a lurking hazard. As I recall, we started out in java.lang.module long before the immutable collections were added so this is why it has been using Collections.emptyXXX(). There shouldn't be any issues changing all these usages to XXX.of(). A discussion for core-libs-dev but I wonder if we could get to the point where emptyXXX() and XXX.of() returns the same empty collection so that we don't have any issues elsewhere. -Alan From claes.redestad at oracle.com Tue Aug 7 16:16:27 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 7 Aug 2018 18:16:27 +0200 Subject: RFR: 8209003: Consolidate use of empty collections in java.lang.module Message-ID: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> Hi, feel free to review this cleanup to consolidate some uses of Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as appropriate. This aligns better with code already generated by jlink, so avoids observing a mix of many implementation classes in some places.. Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8209003 Due the specified need to throw IAE rather than NPE in certain cases, code in some performance-insensitive API methods in ModuleDescriptor.Builder now does an extra copy up front (List/Set/Map.copyOf will throw NPE on any null element or key). I'd rather keep the code simple than add extra handling to squeeze out the last bit of performance here (maybe I'm getting old...) Thanks! /Claes From Alan.Bateman at oracle.com Tue Aug 7 18:25:45 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Aug 2018 19:25:45 +0100 Subject: RFR: 8209003: Consolidate use of empty collections in java.lang.module In-Reply-To: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> Message-ID: On 07/08/2018 17:16, Claes Redestad wrote: > Hi, > > feel free to review this cleanup to consolidate some uses of > Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as > appropriate. This aligns better with code already generated by jlink, > so avoids observing a mix of many implementation classes in some places.. > > Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209003 > > Due the specified need to throw IAE rather than NPE in certain cases, > code in some performance-insensitive API methods in > ModuleDescriptor.Builder now does an extra copy up front > (List/Set/Map.copyOf will throw NPE on any null element or key). I'd > rather keep the code simple than add extra handling to squeeze out the > last bit of performance here (maybe I'm getting old...) This looks okay, I don't see anywhere where the behavior changes. -Alan From mandy.chung at oracle.com Tue Aug 7 19:05:48 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 7 Aug 2018 12:05:48 -0700 Subject: RFR: 8209003: Consolidate use of empty collections in java.lang.module In-Reply-To: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> Message-ID: <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com> This cleanup looks fine. Mandy On 8/7/18 9:16 AM, Claes Redestad wrote: > Hi, > > feel free to review this cleanup to consolidate some uses of > Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as > appropriate. This aligns better with code already generated by jlink, so > avoids observing a mix of many implementation classes in some places.. > > Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209003 > > Due the specified need to throw IAE rather than NPE in certain cases, > code in some performance-insensitive API methods in > ModuleDescriptor.Builder now does an extra copy up front > (List/Set/Map.copyOf will throw NPE on any null element or key). I'd > rather keep the code simple than add extra handling to squeeze out the > last bit of performance here (maybe I'm getting old...) > > Thanks! > > /Claes > From claes.redestad at oracle.com Tue Aug 7 21:16:54 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 7 Aug 2018 23:16:54 +0200 Subject: RFR: 8209003: Consolidate use of empty collections in java.lang.module In-Reply-To: <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com> References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com> <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com> Message-ID: <09ca9dcc-95ae-73b5-c625-5956b934a9ed@oracle.com> Alan, Mandy, thanks for reviewing. Pushed. /Claes On 2018-08-07 21:05, mandy chung wrote: > This cleanup looks fine. > > Mandy From luke.hutch at gmail.com Wed Aug 8 05:16:53 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 7 Aug 2018 23:16:53 -0600 Subject: ModuleReader does not have a method for getting size hint for a named resource Message-ID: The current ModuleReader API has methods list(), open(String name), and read(String name). However, there is no way to get the length (file size) of a resource short of opening or reading the whole resource, then examining the number of bytes read or mapped. This can lead to unnecessary resizing of arrays, and therefore unnecessary array copying. Internally, the resource size is available in ImageLocation#getUncompressedSize(). Can this be exposed as a size hint in the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String name) ? From luke.hutch at gmail.com Wed Aug 8 05:19:06 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 7 Aug 2018 23:19:06 -0600 Subject: Resource size hints appear to be used incorrectly in JPMS Message-ID: The uncompressed size of a resource is used in BasicImageReader#getResource(ImageLocation), which calls readBuffer(offset, uncompressedSize) . The readBuffer method then does two or three things that seem incorrect if the size is obtained from ZipEntry#getSize(): (1) size < 0 is rejected, but ZipEntry#getSize() returns "the uncompressed size of the entry data, or -1 if not known": if (size < 0 || Integer.MAX_VALUE <= size) { throw new IndexOutOfBoundsException("Bad size: " + size); } (2) size is used directly without restriction, rather than as a size hint. ZipEntry#getSize() may actually return a totally bogus value (you can write anything you want for the uncompressed size in a zipfile entry). If the requested size is large, e.g. something close to Integer.MAX_VALUE, large allocations will occur every time a resource is read, which can be used as a memory allocation attack vector. ByteBuffer buffer = slice(memoryMap, (int)offset, (int)size); // ... ByteBuffer buffer = ImageBufferCache.getBuffer(size); Instead, the initial buffer size should be set to something like Math.min(16 * 1024 * 1024, size), and then grown as needed if the resource is indeed larger than this initial allocation. (3) The BasicImageReader#readBuffer(long offset, long size) checks if the filesize is larger than Integer.MAX_VALUE. However, InputStream contains the following max limit for byte array sizes: /** * The maximum size of array to allocate. * Some VMs reserve some header words in an array. * Attempts to allocate larger arrays may result in * OutOfMemoryError: Requested array size exceeds VM limit */ private static final int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8; If this limit applies to ByteBuffers (and it does apply to ByteBuffers if they are array-backed), then the check of size against Integer.MAX_VALUE is incorrect. From Alan.Bateman at oracle.com Wed Aug 8 07:40:55 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Aug 2018 08:40:55 +0100 Subject: ModuleReader does not have a method for getting size hint for a named resource In-Reply-To: References: Message-ID: <8baa2d15-5318-c32f-bb92-c094258a59ae@oracle.com> On 08/08/2018 06:16, Luke Hutchison wrote: > The current ModuleReader API has methods list(), open(String name), and > read(String name). However, there is no way to get the length (file size) > of a resource short of opening or reading the whole resource, then > examining the number of bytes read or mapped. This can lead to unnecessary > resizing of arrays, and therefore unnecessary array copying. > > Internally, the resource size is available in > ImageLocation#getUncompressedSize(). Can this be exposed as a size hint in > the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String > name) ? The issue of exposing the resource size, in the context of the Module API, was issue #ResourceExistenceAndSize in JSR 376. It was decided to defer it as it wasn't critical for a first version. If you are using the ModuleReader API then I assume you are doing something that is scanning the module path (although your other mail seems to be about resources in run-time image with compression so you might be doing something else). If you need the size then one way to do this is with: ??? int size = reader.read(name) ??????????????????? .map(bb -> { ??????????????????????? int rem = bb.remaining(); ??????????????????????? reader.release(bb); ??????????????????????? return rem; ??????????????????? }).orElseThrow(() -> new RuntimeException("not found")); When not using compression then this should be backed by a region from the underlying file mapping. Yes, the compressed case is more expensive but it's not the default. -Alan From luke.hutch at gmail.com Wed Aug 8 10:49:37 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Wed, 8 Aug 2018 04:49:37 -0600 Subject: ModuleReader does not have a method for getting size hint for a named resource In-Reply-To: <8baa2d15-5318-c32f-bb92-c094258a59ae@oracle.com> References: <8baa2d15-5318-c32f-bb92-c094258a59ae@oracle.com> Message-ID: Yes, I'm scanning the modules in the system. Thanks for the pointer to the relevant section of JSR 376. Although your code example would work for either compressed or uncompressed resources, reading the entirety of compressed resources to determine their size is not optimal -- hence this email, requesting an API call to get the size hint from the corresponding ZipEntry. Did you have comments on any of the observations in my other message that the size of a ZipEntry cannot be trusted, or can be -1? On Wed, Aug 8, 2018 at 1:40 AM Alan Bateman wrote: > On 08/08/2018 06:16, Luke Hutchison wrote: > > The current ModuleReader API has methods list(), open(String name), and > > read(String name). However, there is no way to get the length (file size) > > of a resource short of opening or reading the whole resource, then > > examining the number of bytes read or mapped. This can lead to > unnecessary > > resizing of arrays, and therefore unnecessary array copying. > > > > Internally, the resource size is available in > > ImageLocation#getUncompressedSize(). Can this be exposed as a size hint > in > > the ModuleReader API, e.g. in a method ModuleReader#getSizeHint(String > > name) ? > The issue of exposing the resource size, in the context of the Module > API, was issue #ResourceExistenceAndSize in JSR 376. It was decided to > defer it as it wasn't critical for a first version. > > If you are using the ModuleReader API then I assume you are doing > something that is scanning the module path (although your other mail > seems to be about resources in run-time image with compression so you > might be doing something else). If you need the size then one way to do > this is with: > > int size = reader.read(name) > .map(bb -> { > int rem = bb.remaining(); > reader.release(bb); > return rem; > }).orElseThrow(() -> new RuntimeException("not > found")); > > When not using compression then this should be backed by a region from > the underlying file mapping. Yes, the compressed case is more expensive > but it's not the default. > > -Alan > From Alan.Bateman at oracle.com Wed Aug 8 12:22:08 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Aug 2018 13:22:08 +0100 Subject: Resource size hints appear to be used incorrectly when using compression In-Reply-To: References: Message-ID: <5bcb8d34-f0b0-e988-9168-a49820de23be@oracle.com> On 08/08/2018 06:19, Luke Hutchison wrote: > : > > (2) size is used directly without restriction, rather than as a size hint. > ZipEntry#getSize() may actually return a totally bogus value (you can write > anything you want for the uncompressed size in a zipfile entry). If the > requested size is large, e.g. something close to Integer.MAX_VALUE, large > allocations will occur every time a resource is read, which can be used as > a memory allocation attack vector. > I've changed the subject line as the original subject line suggested an issue with the module system. Instead, I think your mail is about run-time images created with `jlink --compress `. The JDK run-time images do not use compression so the code paths in the jimage code for compressed resources may not be tested as well as the uncompressed case. If there are bugs or inefficiencies in the handling of compressed resources then we should get them into JIRA. -Alan From jiangli.zhou at oracle.com Wed Aug 8 23:43:26 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 8 Aug 2018 16:43:26 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: References: <5B64A0F1.9060302@oracle.com> Message-ID: Thanks Claes for resolving JDK-8209003 quickly. Here is my updated weberv that includes following changes: - Added archiving for singletons in ImmutableCollections (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see changes in ImmutableCollections.java. - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. - Added a new test case to check the parents and modules of archived EMPTY_CONFIGURATION. - Added argument length check in CheckArchivedModuleApp.java test as Calvin suggested. http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ Thanks, Jiangli On 8/6/18 9:48 AM, Jiangli Zhou wrote: > Hi Calvin and Ioi, > > Thanks for reviewing the change! I'll incorporate your suggestions. > > As Claes pointed out in his email, there was a subtle issue with the > empty configuration, which was undetected by the testing for archiving > changes but could introduce a bug in certain cases. Claes has already > filed JDK-8209003 for consolidating empty collections usage in module > code. I'll look into archiving the immutable singletons in > java.util.ImmutableCollections. > > Thanks! > > Jiangli > > > On 8/3/18 2:58 PM, Ioi Lam wrote: >> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>> Hi Jiangli, >>> >>> The changes look good to me. >>> >>> I have couple of minor comments: >>> >>> 1) vmSymbols.hpp >>> >>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>> ?654?? template(toFileURL_name, "toFileURL") \ >>> ?655?? template(toFileURL_signature, >>> "(Ljava/lang/String;)Ljava/net/URL;") >>> >>> Since you've moved the above lines to after >>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>> entire block (lines 652 - 659) in alphabetical order. >>> >> Hi Jiangli, >> >> I've reviewed the code. It looks like a clean change and it's great >> to make further progress in start-up improvement! >> >> Just a small note on vmSymbols.hpp:? this line can be deleted because >> the symbol is no longer used. >> >> ? template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >> >> Thanks >> - Ioi >> >>> 2) CheckArchivedModuleApp.java >>> >>> Since it now expects two input args, I?d suggest checking the number >>> of input args and throw an exception if it is not equal to two. >>> >>> thanks, >>> Calvin >>> >>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>> Please review the following webrev that archives the system module >>>> boot layer Configuration (including all java objects reachable from >>>> the Configuration) in CDS archive. This is built on top of the >>>> earlier change for JDK-8202035 >>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which provides >>>> a framework for object sub-graph archiving. >>>> >>>> The boot layer Configuration is created in ModuleBootstrap.boot() >>>> (similar to the archived system ModuleDescriptor objects, etc) and >>>> is unchanged after construction. With archived boot layer >>>> Configuration, it allows runtime to bypass the work for creating >>>> the configuration. Currently, this is only supported when the >>>> initial module is unnamed module. Measurements indicate archiving >>>> the boot layer Configuration improves the startup time by 1% ~ 1.5% >>>> (on linux-x64) when running HelloWorld from -cp at runtime. >>>> >>>> Many thanks to Alan and Claes for discussions and contributions to >>>> this change! >>>> >>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>> >>>> Tested with tier1 - tier5 tests via mach5. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >> > From luke.hutch at gmail.com Thu Aug 9 09:42:36 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Thu, 9 Aug 2018 03:42:36 -0600 Subject: Resource size hints appear to be used incorrectly when using compression In-Reply-To: <5bcb8d34-f0b0-e988-9168-a49820de23be@oracle.com> References: <5bcb8d34-f0b0-e988-9168-a49820de23be@oracle.com> Message-ID: Good info, I was wondering about the claims (in the ModuleReader javadoc) about how ByteBuffer was being used for high-speed classloading, given that in the past rt.jar has been compressed. This makes a lot more sense if the system modules are not compressed. So yes, the issues I raised are about the use of decompressed sizes in the loading of resources from runtime images that were created with compression. On Wed, Aug 8, 2018 at 6:22 AM Alan Bateman wrote: > On 08/08/2018 06:19, Luke Hutchison wrote: > > : > > > > (2) size is used directly without restriction, rather than as a size > hint. > > ZipEntry#getSize() may actually return a totally bogus value (you can > write > > anything you want for the uncompressed size in a zipfile entry). If the > > requested size is large, e.g. something close to Integer.MAX_VALUE, large > > allocations will occur every time a resource is read, which can be used > as > > a memory allocation attack vector. > > > I've changed the subject line as the original subject line suggested an > issue with the module system. Instead, I think your mail is about > run-time images created with `jlink --compress `. The JDK > run-time images do not use compression so the code paths in the jimage > code for compressed resources may not be tested as well as the > uncompressed case. If there are bugs or inefficiencies in the handling > of compressed resources then we should get them into JIRA. > > -Alan > From claes.redestad at oracle.com Thu Aug 9 09:55:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 9 Aug 2018 11:55:05 +0200 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: References: <5B64A0F1.9060302@oracle.com> Message-ID: Library and test changes look good to me. Nits: ImmutableCollections: - // Initialize EMPTY_FOO from the archive comments feel redundant CheckArchivedModule: - perhaps call out that checking identity is necessary and intentional /Claes On 2018-08-09 01:43, Jiangli Zhou wrote: > Thanks Claes for resolving JDK-8209003 quickly. Here is my updated > weberv that includes following changes: > > - Added archiving for singletons in ImmutableCollections > (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see > changes in ImmutableCollections.java. > - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. > - Added a new test case to check the parents and modules of archived > EMPTY_CONFIGURATION. > - Added argument length check in CheckArchivedModuleApp.java test as > Calvin suggested. > > http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ > > Thanks, > Jiangli > > On 8/6/18 9:48 AM, Jiangli Zhou wrote: >> Hi Calvin and Ioi, >> >> Thanks for reviewing the change! I'll incorporate your suggestions. >> >> As Claes pointed out in his email, there was a subtle issue with the >> empty configuration, which was undetected by the testing for >> archiving changes but could introduce a bug in certain cases. Claes >> has already filed JDK-8209003 for consolidating empty collections >> usage in module code. I'll look into archiving the immutable >> singletons in java.util.ImmutableCollections. >> >> Thanks! >> >> Jiangli >> >> >> On 8/3/18 2:58 PM, Ioi Lam wrote: >>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>> Hi Jiangli, >>>> >>>> The changes look good to me. >>>> >>>> I have couple of minor comments: >>>> >>>> 1) vmSymbols.hpp >>>> >>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>> ?655?? template(toFileURL_signature, >>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>> >>>> Since you've moved the above lines to after >>>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>>> entire block (lines 652 - 659) in alphabetical order. >>>> >>> Hi Jiangli, >>> >>> I've reviewed the code. It looks like a clean change and it's great >>> to make further progress in start-up improvement! >>> >>> Just a small note on vmSymbols.hpp:? this line can be deleted >>> because the symbol is no longer used. >>> >>> ? template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >>> >>> Thanks >>> - Ioi >>> >>>> 2) CheckArchivedModuleApp.java >>>> >>>> Since it now expects two input args, I?d suggest checking the >>>> number of input args and throw an exception if it is not equal to two. >>>> >>>> thanks, >>>> Calvin >>>> >>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>> Please review the following webrev that archives the system module >>>>> boot layer Configuration (including all java objects reachable >>>>> from the Configuration) in CDS archive. This is built on top of >>>>> the earlier change for JDK-8202035 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which provides >>>>> a framework for object sub-graph archiving. >>>>> >>>>> The boot layer Configuration is created in ModuleBootstrap.boot() >>>>> (similar to the archived system ModuleDescriptor objects, etc) and >>>>> is unchanged after construction. With archived boot layer >>>>> Configuration, it allows runtime to bypass the work for creating >>>>> the configuration. Currently, this is only supported when the >>>>> initial module is unnamed module. Measurements indicate archiving >>>>> the boot layer Configuration improves the startup time by 1% ~ >>>>> 1.5% (on linux-x64) when running HelloWorld from -cp at runtime. >>>>> >>>>> Many thanks to Alan and Claes for discussions and contributions to >>>>> this change! >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>> >>>>> Tested with tier1 - tier5 tests via mach5. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>> >> > From Alan.Bateman at oracle.com Thu Aug 9 10:06:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 9 Aug 2018 11:06:46 +0100 Subject: Resource size hints appear to be used incorrectly when using compression In-Reply-To: References: <5bcb8d34-f0b0-e988-9168-a49820de23be@oracle.com> Message-ID: <0f30d55c-2bd4-b60d-dc64-c4f8cb365ba5@oracle.com> On 09/08/2018 10:42, Luke Hutchison wrote: > Good info, I was wondering about the claims (in the ModuleReader > javadoc) about how ByteBuffer was being used for high-speed > classloading, given that in the past rt.jar has been compressed. This > makes a lot more sense if the system modules are not compressed. > > So yes, the issues I raised are about the use of decompressed sizes in > the loading of resources from runtime images that were created with > compression. > I don't think rt.jar was compressed in JDK 8 or older, at least not unless you are looking at embedded builds where it helped with the static footprint (and depending on processor/environment, it may help with class loading performance too). The API note (and it's just a note, not normative text) about class loading in the ModuleReader javadoc was to document the rational for the read/release methods. The built-in class loaders make heavy use of it when loading classes/resources from modules in the run-time image and significant work was done to ensure that the buffers are views on the underlying memory mapped file. The support for compressing resources in the jimage is something that does need attention so I created JDK-8209176 to track that. As I said, we haven't done as much performance testing with compression enabled. I'll also add that your comments about malicious values need to be viewed in the context of the tool that creates the run-time image - there is no support whatsoever for using jimage files that have not been created by the jlink tool. -Alan From jiangli.zhou at oracle.com Thu Aug 9 15:50:16 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Aug 2018 08:50:16 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: References: <5B64A0F1.9060302@oracle.com> Message-ID: <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> Hi Claes, Thanks for reviewing the library and test changes! I'll remove the comments that you pointed below from ImmutableCollections and update the CheckArchivedModule test. Thanks! Jiangli On 8/9/18 2:55 AM, Claes Redestad wrote: > Library and test changes look good to me. Nits: > > ImmutableCollections: > > - // Initialize EMPTY_FOO from the archive comments feel redundant > > CheckArchivedModule: > > - perhaps call out that checking identity is necessary and intentional > > /Claes > > On 2018-08-09 01:43, Jiangli Zhou wrote: >> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >> weberv that includes following changes: >> >> - Added archiving for singletons in ImmutableCollections >> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >> changes in ImmutableCollections.java. >> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >> - Added a new test case to check the parents and modules of archived >> EMPTY_CONFIGURATION. >> - Added argument length check in CheckArchivedModuleApp.java test as >> Calvin suggested. >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >> >> Thanks, >> Jiangli >> >> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>> Hi Calvin and Ioi, >>> >>> Thanks for reviewing the change! I'll incorporate your suggestions. >>> >>> As Claes pointed out in his email, there was a subtle issue with the >>> empty configuration, which was undetected by the testing for >>> archiving changes but could introduce a bug in certain cases. Claes >>> has already filed JDK-8209003 for consolidating empty collections >>> usage in module code. I'll look into archiving the immutable >>> singletons in java.util.ImmutableCollections. >>> >>> Thanks! >>> >>> Jiangli >>> >>> >>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>> Hi Jiangli, >>>>> >>>>> The changes look good to me. >>>>> >>>>> I have couple of minor comments: >>>>> >>>>> 1) vmSymbols.hpp >>>>> >>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>> ?655?? template(toFileURL_signature, >>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>> >>>>> Since you've moved the above lines to after >>>>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>>>> entire block (lines 652 - 659) in alphabetical order. >>>>> >>>> Hi Jiangli, >>>> >>>> I've reviewed the code. It looks like a clean change and it's great >>>> to make further progress in start-up improvement! >>>> >>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>> because the symbol is no longer used. >>>> >>>> ? template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> 2) CheckArchivedModuleApp.java >>>>> >>>>> Since it now expects two input args, I?d suggest checking the >>>>> number of input args and throw an exception if it is not equal to >>>>> two. >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>> Please review the following webrev that archives the system >>>>>> module boot layer Configuration (including all java objects >>>>>> reachable from the Configuration) in CDS archive. This is built >>>>>> on top of the earlier change for JDK-8202035 >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>> provides a framework for object sub-graph archiving. >>>>>> >>>>>> The boot layer Configuration is created in ModuleBootstrap.boot() >>>>>> (similar to the archived system ModuleDescriptor objects, etc) >>>>>> and is unchanged after construction. With archived boot layer >>>>>> Configuration, it allows runtime to bypass the work for creating >>>>>> the configuration. Currently, this is only supported when the >>>>>> initial module is unnamed module. Measurements indicate archiving >>>>>> the boot layer Configuration improves the startup time by 1% ~ >>>>>> 1.5% (on linux-x64) when running HelloWorld from -cp at runtime. >>>>>> >>>>>> Many thanks to Alan and Claes for discussions and contributions >>>>>> to this change! >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>> >>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Thu Aug 9 18:42:06 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Aug 2018 11:42:06 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> Message-ID: <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> Here is the updated webrev with comment changes suggested by Claes: http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ Updated files: http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html Thanks, Jiangli On 8/9/18 8:50 AM, Jiangli Zhou wrote: > Hi Claes, > > Thanks for reviewing the library and test changes! I'll remove the > comments that you pointed below from ImmutableCollections and update > the CheckArchivedModule test. > > Thanks! > > Jiangli > > > On 8/9/18 2:55 AM, Claes Redestad wrote: >> Library and test changes look good to me. Nits: >> >> ImmutableCollections: >> >> - // Initialize EMPTY_FOO from the archive comments feel redundant >> >> CheckArchivedModule: >> >> - perhaps call out that checking identity is necessary and intentional >> >> /Claes >> >> On 2018-08-09 01:43, Jiangli Zhou wrote: >>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>> weberv that includes following changes: >>> >>> - Added archiving for singletons in ImmutableCollections >>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>> changes in ImmutableCollections.java. >>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>> - Added a new test case to check the parents and modules of archived >>> EMPTY_CONFIGURATION. >>> - Added argument length check in CheckArchivedModuleApp.java test as >>> Calvin suggested. >>> >>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>> >>> Thanks, >>> Jiangli >>> >>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>> Hi Calvin and Ioi, >>>> >>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>> >>>> As Claes pointed out in his email, there was a subtle issue with >>>> the empty configuration, which was undetected by the testing for >>>> archiving changes but could introduce a bug in certain cases. Claes >>>> has already filed JDK-8209003 for consolidating empty collections >>>> usage in module code. I'll look into archiving the immutable >>>> singletons in java.util.ImmutableCollections. >>>> >>>> Thanks! >>>> >>>> Jiangli >>>> >>>> >>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>> Hi Jiangli, >>>>>> >>>>>> The changes look good to me. >>>>>> >>>>>> I have couple of minor comments: >>>>>> >>>>>> 1) vmSymbols.hpp >>>>>> >>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>> ?655?? template(toFileURL_signature, >>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>> >>>>>> Since you've moved the above lines to after >>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>>>>> entire block (lines 652 - 659) in alphabetical order. >>>>>> >>>>> Hi Jiangli, >>>>> >>>>> I've reviewed the code. It looks like a clean change and it's >>>>> great to make further progress in start-up improvement! >>>>> >>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>> because the symbol is no longer used. >>>>> >>>>> ? template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> 2) CheckArchivedModuleApp.java >>>>>> >>>>>> Since it now expects two input args, I?d suggest checking the >>>>>> number of input args and throw an exception if it is not equal to >>>>>> two. >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>>> >>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>> Please review the following webrev that archives the system >>>>>>> module boot layer Configuration (including all java objects >>>>>>> reachable from the Configuration) in CDS archive. This is built >>>>>>> on top of the earlier change for JDK-8202035 >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>> provides a framework for object sub-graph archiving. >>>>>>> >>>>>>> The boot layer Configuration is created in >>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>> construction. With archived boot layer Configuration, it allows >>>>>>> runtime to bypass the work for creating the configuration. >>>>>>> Currently, this is only supported when the initial module is >>>>>>> unnamed module. Measurements indicate archiving the boot layer >>>>>>> Configuration improves the startup time by 1% ~ 1.5% (on >>>>>>> linux-x64) when running HelloWorld from -cp at runtime. >>>>>>> >>>>>>> Many thanks to Alan and Claes for discussions and contributions >>>>>>> to this change! >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>> >>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>> >>>> >>> >> > From claes.redestad at oracle.com Thu Aug 9 19:13:37 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 9 Aug 2018 21:13:37 +0200 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> Message-ID: <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> Updates looks good, thanks! /Claes On 2018-08-09 20:42, Jiangli Zhou wrote: > Here is the updated webrev with comment changes suggested by Claes: > > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ > > Updated files: > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html > > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html > > > Thanks, > Jiangli > > On 8/9/18 8:50 AM, Jiangli Zhou wrote: >> Hi Claes, >> >> Thanks for reviewing the library and test changes! I'll remove the >> comments that you pointed below from ImmutableCollections and update >> the CheckArchivedModule test. >> >> Thanks! >> >> Jiangli >> >> >> On 8/9/18 2:55 AM, Claes Redestad wrote: >>> Library and test changes look good to me. Nits: >>> >>> ImmutableCollections: >>> >>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>> >>> CheckArchivedModule: >>> >>> - perhaps call out that checking identity is necessary and intentional >>> >>> /Claes >>> >>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>>> weberv that includes following changes: >>>> >>>> - Added archiving for singletons in ImmutableCollections >>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>> changes in ImmutableCollections.java. >>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>> - Added a new test case to check the parents and modules of >>>> archived EMPTY_CONFIGURATION. >>>> - Added argument length check in CheckArchivedModuleApp.java test >>>> as Calvin suggested. >>>> >>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>> Hi Calvin and Ioi, >>>>> >>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>> >>>>> As Claes pointed out in his email, there was a subtle issue with >>>>> the empty configuration, which was undetected by the testing for >>>>> archiving changes but could introduce a bug in certain cases. >>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>> collections usage in module code. I'll look into archiving the >>>>> immutable singletons in java.util.ImmutableCollections. >>>>> >>>>> Thanks! >>>>> >>>>> Jiangli >>>>> >>>>> >>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> The changes look good to me. >>>>>>> >>>>>>> I have couple of minor comments: >>>>>>> >>>>>>> 1) vmSymbols.hpp >>>>>>> >>>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>>> ?655?? template(toFileURL_signature, >>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>> >>>>>>> Since you've moved the above lines to after >>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>>>>>> entire block (lines 652 - 659) in alphabetical order. >>>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>> great to make further progress in start-up improvement! >>>>>> >>>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>>> because the symbol is no longer used. >>>>>> >>>>>> ? template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> 2) CheckArchivedModuleApp.java >>>>>>> >>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>> number of input args and throw an exception if it is not equal >>>>>>> to two. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>>> >>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>> Please review the following webrev that archives the system >>>>>>>> module boot layer Configuration (including all java objects >>>>>>>> reachable from the Configuration) in CDS archive. This is built >>>>>>>> on top of the earlier change for JDK-8202035 >>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>> >>>>>>>> The boot layer Configuration is created in >>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>> construction. With archived boot layer Configuration, it allows >>>>>>>> runtime to bypass the work for creating the configuration. >>>>>>>> Currently, this is only supported when the initial module is >>>>>>>> unnamed module. Measurements indicate archiving the boot layer >>>>>>>> Configuration improves the startup time by 1% ~ 1.5% (on >>>>>>>> linux-x64) when running HelloWorld from -cp at runtime. >>>>>>>> >>>>>>>> Many thanks to Alan and Claes for discussions and contributions >>>>>>>> to this change! >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>> >>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>> >>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jiangli >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Thu Aug 9 19:10:20 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Aug 2018 12:10:20 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> Message-ID: <499ef931-4f02-0a04-ab3f-8ac02113023e@oracle.com> Thanks, Claes! Jiangli On 8/9/18 12:13 PM, Claes Redestad wrote: > Updates looks good, thanks! > > /Claes > > On 2018-08-09 20:42, Jiangli Zhou wrote: >> Here is the updated webrev with comment changes suggested by Claes: >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ >> >> Updated files: >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html >> >> >> Thanks, >> Jiangli >> >> On 8/9/18 8:50 AM, Jiangli Zhou wrote: >>> Hi Claes, >>> >>> Thanks for reviewing the library and test changes! I'll remove the >>> comments that you pointed below from ImmutableCollections and update >>> the CheckArchivedModule test. >>> >>> Thanks! >>> >>> Jiangli >>> >>> >>> On 8/9/18 2:55 AM, Claes Redestad wrote: >>>> Library and test changes look good to me. Nits: >>>> >>>> ImmutableCollections: >>>> >>>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>>> >>>> CheckArchivedModule: >>>> >>>> - perhaps call out that checking identity is necessary and intentional >>>> >>>> /Claes >>>> >>>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>>>> weberv that includes following changes: >>>>> >>>>> - Added archiving for singletons in ImmutableCollections >>>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>>> changes in ImmutableCollections.java. >>>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>>> - Added a new test case to check the parents and modules of >>>>> archived EMPTY_CONFIGURATION. >>>>> - Added argument length check in CheckArchivedModuleApp.java test >>>>> as Calvin suggested. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>>> Hi Calvin and Ioi, >>>>>> >>>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>>> >>>>>> As Claes pointed out in his email, there was a subtle issue with >>>>>> the empty configuration, which was undetected by the testing for >>>>>> archiving changes but could introduce a bug in certain cases. >>>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>>> collections usage in module code. I'll look into archiving the >>>>>> immutable singletons in java.util.ImmutableCollections. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> The changes look good to me. >>>>>>>> >>>>>>>> I have couple of minor comments: >>>>>>>> >>>>>>>> 1) vmSymbols.hpp >>>>>>>> >>>>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>>>> ?655?? template(toFileURL_signature, >>>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>>> >>>>>>>> Since you've moved the above lines to after >>>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange >>>>>>>> the entire block (lines 652 - 659) in alphabetical order. >>>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>>> great to make further progress in start-up improvement! >>>>>>> >>>>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>>>> because the symbol is no longer used. >>>>>>> >>>>>>> ? template(jdk_vm_cds_SharedClassInfo, >>>>>>> "jdk/vm/cds/SharedClassInfo") >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>>> 2) CheckArchivedModuleApp.java >>>>>>>> >>>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>>> number of input args and throw an exception if it is not equal >>>>>>>> to two. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>>> >>>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>>> Please review the following webrev that archives the system >>>>>>>>> module boot layer Configuration (including all java objects >>>>>>>>> reachable from the Configuration) in CDS archive. This is >>>>>>>>> built on top of the earlier change for JDK-8202035 >>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>>> >>>>>>>>> The boot layer Configuration is created in >>>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>>> construction. With archived boot layer Configuration, it >>>>>>>>> allows runtime to bypass the work for creating the >>>>>>>>> configuration. Currently, this is only supported when the >>>>>>>>> initial module is unnamed module. Measurements indicate >>>>>>>>> archiving the boot layer Configuration improves the startup >>>>>>>>> time by 1% ~ 1.5% (on linux-x64) when running HelloWorld from >>>>>>>>> -cp at runtime. >>>>>>>>> >>>>>>>>> Many thanks to Alan and Claes for discussions and >>>>>>>>> contributions to this change! >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>>> >>>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jiangli >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From ioi.lam at oracle.com Thu Aug 9 23:06:34 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 9 Aug 2018 16:06:34 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> Message-ID: <16ade059-5c01-89a4-367d-25f7cc925c83@oracle.com> Looks good to me, too. Thanks! - Ioi On 8/9/18 12:13 PM, Claes Redestad wrote: > Updates looks good, thanks! > > /Claes > > On 2018-08-09 20:42, Jiangli Zhou wrote: >> Here is the updated webrev with comment changes suggested by Claes: >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ >> >> Updated files: >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html >> >> >> Thanks, >> Jiangli >> >> On 8/9/18 8:50 AM, Jiangli Zhou wrote: >>> Hi Claes, >>> >>> Thanks for reviewing the library and test changes! I'll remove the >>> comments that you pointed below from ImmutableCollections and update >>> the CheckArchivedModule test. >>> >>> Thanks! >>> >>> Jiangli >>> >>> >>> On 8/9/18 2:55 AM, Claes Redestad wrote: >>>> Library and test changes look good to me. Nits: >>>> >>>> ImmutableCollections: >>>> >>>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>>> >>>> CheckArchivedModule: >>>> >>>> - perhaps call out that checking identity is necessary and intentional >>>> >>>> /Claes >>>> >>>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>>>> weberv that includes following changes: >>>>> >>>>> - Added archiving for singletons in ImmutableCollections >>>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>>> changes in ImmutableCollections.java. >>>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>>> - Added a new test case to check the parents and modules of >>>>> archived EMPTY_CONFIGURATION. >>>>> - Added argument length check in CheckArchivedModuleApp.java test >>>>> as Calvin suggested. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>>> Hi Calvin and Ioi, >>>>>> >>>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>>> >>>>>> As Claes pointed out in his email, there was a subtle issue with >>>>>> the empty configuration, which was undetected by the testing for >>>>>> archiving changes but could introduce a bug in certain cases. >>>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>>> collections usage in module code. I'll look into archiving the >>>>>> immutable singletons in java.util.ImmutableCollections. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> The changes look good to me. >>>>>>>> >>>>>>>> I have couple of minor comments: >>>>>>>> >>>>>>>> 1) vmSymbols.hpp >>>>>>>> >>>>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>>>> ?655?? template(toFileURL_signature, >>>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>>> >>>>>>>> Since you've moved the above lines to after >>>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange >>>>>>>> the entire block (lines 652 - 659) in alphabetical order. >>>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>>> great to make further progress in start-up improvement! >>>>>>> >>>>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>>>> because the symbol is no longer used. >>>>>>> >>>>>>> ? template(jdk_vm_cds_SharedClassInfo, >>>>>>> "jdk/vm/cds/SharedClassInfo") >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>>> 2) CheckArchivedModuleApp.java >>>>>>>> >>>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>>> number of input args and throw an exception if it is not equal >>>>>>>> to two. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>>> >>>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>>> Please review the following webrev that archives the system >>>>>>>>> module boot layer Configuration (including all java objects >>>>>>>>> reachable from the Configuration) in CDS archive. This is >>>>>>>>> built on top of the earlier change for JDK-8202035 >>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>>> >>>>>>>>> The boot layer Configuration is created in >>>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>>> construction. With archived boot layer Configuration, it >>>>>>>>> allows runtime to bypass the work for creating the >>>>>>>>> configuration. Currently, this is only supported when the >>>>>>>>> initial module is unnamed module. Measurements indicate >>>>>>>>> archiving the boot layer Configuration improves the startup >>>>>>>>> time by 1% ~ 1.5% (on linux-x64) when running HelloWorld from >>>>>>>>> -cp at runtime. >>>>>>>>> >>>>>>>>> Many thanks to Alan and Claes for discussions and >>>>>>>>> contributions to this change! >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>>> >>>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jiangli >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Thu Aug 9 23:20:53 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Aug 2018 16:20:53 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <16ade059-5c01-89a4-367d-25f7cc925c83@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> <9e558e49-6241-b43d-f45a-147b1e4ade4c@oracle.com> <16ade059-5c01-89a4-367d-25f7cc925c83@oracle.com> Message-ID: <778d4afc-3672-2ee4-46b5-115a100a591e@oracle.com> Thanks, Ioi! Jiangli On 8/9/18 4:06 PM, Ioi Lam wrote: > Looks good to me, too. Thanks! > > - Ioi > > > On 8/9/18 12:13 PM, Claes Redestad wrote: >> Updates looks good, thanks! >> >> /Claes >> >> On 2018-08-09 20:42, Jiangli Zhou wrote: >>> Here is the updated webrev with comment changes suggested by Claes: >>> >>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ >>> >>> Updated files: >>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html >>> >>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 8/9/18 8:50 AM, Jiangli Zhou wrote: >>>> Hi Claes, >>>> >>>> Thanks for reviewing the library and test changes! I'll remove the >>>> comments that you pointed below from ImmutableCollections and >>>> update the CheckArchivedModule test. >>>> >>>> Thanks! >>>> >>>> Jiangli >>>> >>>> >>>> On 8/9/18 2:55 AM, Claes Redestad wrote: >>>>> Library and test changes look good to me. Nits: >>>>> >>>>> ImmutableCollections: >>>>> >>>>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>>>> >>>>> CheckArchivedModule: >>>>> >>>>> - perhaps call out that checking identity is necessary and >>>>> intentional >>>>> >>>>> /Claes >>>>> >>>>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my >>>>>> updated weberv that includes following changes: >>>>>> >>>>>> - Added archiving for singletons in ImmutableCollections >>>>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>>>> changes in ImmutableCollections.java. >>>>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>>>> - Added a new test case to check the parents and modules of >>>>>> archived EMPTY_CONFIGURATION. >>>>>> - Added argument length check in CheckArchivedModuleApp.java test >>>>>> as Calvin suggested. >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>>>> Hi Calvin and Ioi, >>>>>>> >>>>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>>>> >>>>>>> As Claes pointed out in his email, there was a subtle issue with >>>>>>> the empty configuration, which was undetected by the testing for >>>>>>> archiving changes but could introduce a bug in certain cases. >>>>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>>>> collections usage in module code. I'll look into archiving the >>>>>>> immutable singletons in java.util.ImmutableCollections. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>>>> >>>>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>>>> Hi Jiangli, >>>>>>>>> >>>>>>>>> The changes look good to me. >>>>>>>>> >>>>>>>>> I have couple of minor comments: >>>>>>>>> >>>>>>>>> 1) vmSymbols.hpp >>>>>>>>> >>>>>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>>>>> ?655?? template(toFileURL_signature, >>>>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>>>> >>>>>>>>> Since you've moved the above lines to after >>>>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange >>>>>>>>> the entire block (lines 652 - 659) in alphabetical order. >>>>>>>>> >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>>>> great to make further progress in start-up improvement! >>>>>>>> >>>>>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>>>>> because the symbol is no longer used. >>>>>>>> >>>>>>>> ? template(jdk_vm_cds_SharedClassInfo, >>>>>>>> "jdk/vm/cds/SharedClassInfo") >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>>> 2) CheckArchivedModuleApp.java >>>>>>>>> >>>>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>>>> number of input args and throw an exception if it is not equal >>>>>>>>> to two. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >>>>>>>>> >>>>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>>>> Please review the following webrev that archives the system >>>>>>>>>> module boot layer Configuration (including all java objects >>>>>>>>>> reachable from the Configuration) in CDS archive. This is >>>>>>>>>> built on top of the earlier change for JDK-8202035 >>>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>>>> >>>>>>>>>> The boot layer Configuration is created in >>>>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>>>> construction. With archived boot layer Configuration, it >>>>>>>>>> allows runtime to bypass the work for creating the >>>>>>>>>> configuration. Currently, this is only supported when the >>>>>>>>>> initial module is unnamed module. Measurements indicate >>>>>>>>>> archiving the boot layer Configuration improves the startup >>>>>>>>>> time by 1% ~ 1.5% (on linux-x64) when running HelloWorld from >>>>>>>>>> -cp at runtime. >>>>>>>>>> >>>>>>>>>> Many thanks to Alan and Claes for discussions and >>>>>>>>>> contributions to this change! >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>>>> >>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>>>> >>>>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From calvin.cheung at oracle.com Thu Aug 9 23:26:53 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 09 Aug 2018 16:26:53 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> Message-ID: <5B6CCDBD.8020806@oracle.com> Looks good. thanks, Calvin On 8/9/18, 11:42 AM, Jiangli Zhou wrote: > Here is the updated webrev with comment changes suggested by Claes: > > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ > > Updated files: > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html > > http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html > > > Thanks, > Jiangli > > On 8/9/18 8:50 AM, Jiangli Zhou wrote: >> Hi Claes, >> >> Thanks for reviewing the library and test changes! I'll remove the >> comments that you pointed below from ImmutableCollections and update >> the CheckArchivedModule test. >> >> Thanks! >> >> Jiangli >> >> >> On 8/9/18 2:55 AM, Claes Redestad wrote: >>> Library and test changes look good to me. Nits: >>> >>> ImmutableCollections: >>> >>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>> >>> CheckArchivedModule: >>> >>> - perhaps call out that checking identity is necessary and intentional >>> >>> /Claes >>> >>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>>> weberv that includes following changes: >>>> >>>> - Added archiving for singletons in ImmutableCollections >>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>> changes in ImmutableCollections.java. >>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>> - Added a new test case to check the parents and modules of >>>> archived EMPTY_CONFIGURATION. >>>> - Added argument length check in CheckArchivedModuleApp.java test >>>> as Calvin suggested. >>>> >>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>> Hi Calvin and Ioi, >>>>> >>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>> >>>>> As Claes pointed out in his email, there was a subtle issue with >>>>> the empty configuration, which was undetected by the testing for >>>>> archiving changes but could introduce a bug in certain cases. >>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>> collections usage in module code. I'll look into archiving the >>>>> immutable singletons in java.util.ImmutableCollections. >>>>> >>>>> Thanks! >>>>> >>>>> Jiangli >>>>> >>>>> >>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> The changes look good to me. >>>>>>> >>>>>>> I have couple of minor comments: >>>>>>> >>>>>>> 1) vmSymbols.hpp >>>>>>> >>>>>>> 653 template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>> 654 template(toFileURL_name, "toFileURL") \ >>>>>>> 655 template(toFileURL_signature, >>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>> >>>>>>> Since you've moved the above lines to after >>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange the >>>>>>> entire block (lines 652 - 659) in alphabetical order. >>>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>> great to make further progress in start-up improvement! >>>>>> >>>>>> Just a small note on vmSymbols.hpp: this line can be deleted >>>>>> because the symbol is no longer used. >>>>>> >>>>>> template(jdk_vm_cds_SharedClassInfo, "jdk/vm/cds/SharedClassInfo") >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> 2) CheckArchivedModuleApp.java >>>>>>> >>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>> number of input args and throw an exception if it is not equal >>>>>>> to two. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>>> >>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>> Please review the following webrev that archives the system >>>>>>>> module boot layer Configuration (including all java objects >>>>>>>> reachable from the Configuration) in CDS archive. This is built >>>>>>>> on top of the earlier change for JDK-8202035 >>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>> >>>>>>>> The boot layer Configuration is created in >>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>> construction. With archived boot layer Configuration, it allows >>>>>>>> runtime to bypass the work for creating the configuration. >>>>>>>> Currently, this is only supported when the initial module is >>>>>>>> unnamed module. Measurements indicate archiving the boot layer >>>>>>>> Configuration improves the startup time by 1% ~ 1.5% (on >>>>>>>> linux-x64) when running HelloWorld from -cp at runtime. >>>>>>>> >>>>>>>> Many thanks to Alan and Claes for discussions and contributions >>>>>>>> to this change! >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>> >>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>> >>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jiangli >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Fri Aug 10 01:39:48 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Aug 2018 18:39:48 -0700 Subject: RFR: 8207263: Store the Configuration for system modules into CDS archive In-Reply-To: <5B6CCDBD.8020806@oracle.com> References: <5B64A0F1.9060302@oracle.com> <3c154c4f-3734-982c-7ac0-0fcdfc1eeef6@oracle.com> <6f4226f5-cfe4-79bf-3983-3b94c6b4e6fd@oracle.com> <5B6CCDBD.8020806@oracle.com> Message-ID: <09805db0-b451-b3b6-1aa6-cc54c128796b@oracle.com> Thanks, Calvin! Jiangli On 8/9/18 4:26 PM, Calvin Cheung wrote: > Looks good. > > thanks, > Calvin > > On 8/9/18, 11:42 AM, Jiangli Zhou wrote: >> Here is the updated webrev with comment changes suggested by Claes: >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/ >> >> Updated files: >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/java/util/ImmutableCollections.java.frames.html >> >> http://cr.openjdk.java.net/~jiangli/8207263/webrev.02/src/java.base/share/classes/jdk/internal/module/ArchivedModuleGraph.java.frames.html >> >> >> Thanks, >> Jiangli >> >> On 8/9/18 8:50 AM, Jiangli Zhou wrote: >>> Hi Claes, >>> >>> Thanks for reviewing the library and test changes! I'll remove the >>> comments that you pointed below from ImmutableCollections and update >>> the CheckArchivedModule test. >>> >>> Thanks! >>> >>> Jiangli >>> >>> >>> On 8/9/18 2:55 AM, Claes Redestad wrote: >>>> Library and test changes look good to me. Nits: >>>> >>>> ImmutableCollections: >>>> >>>> - // Initialize EMPTY_FOO from the archive comments feel redundant >>>> >>>> CheckArchivedModule: >>>> >>>> - perhaps call out that checking identity is necessary and intentional >>>> >>>> /Claes >>>> >>>> On 2018-08-09 01:43, Jiangli Zhou wrote: >>>>> Thanks Claes for resolving JDK-8209003 quickly. Here is my updated >>>>> weberv that includes following changes: >>>>> >>>>> - Added archiving for singletons in ImmutableCollections >>>>> (ListN.EMPTY_LIST, SetN.EMPTY_SET and MapN.EMPTY_MAP). Please see >>>>> changes in ImmutableCollections.java. >>>>> - Incorporated Calvin and Ioi feedbacks on vmSymbols.hpp. >>>>> - Added a new test case to check the parents and modules of >>>>> archived EMPTY_CONFIGURATION. >>>>> - Added argument length check in CheckArchivedModuleApp.java test >>>>> as Calvin suggested. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8207263/webrev.01/ >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 8/6/18 9:48 AM, Jiangli Zhou wrote: >>>>>> Hi Calvin and Ioi, >>>>>> >>>>>> Thanks for reviewing the change! I'll incorporate your suggestions. >>>>>> >>>>>> As Claes pointed out in his email, there was a subtle issue with >>>>>> the empty configuration, which was undetected by the testing for >>>>>> archiving changes but could introduce a bug in certain cases. >>>>>> Claes has already filed JDK-8209003 for consolidating empty >>>>>> collections usage in module code. I'll look into archiving the >>>>>> immutable singletons in java.util.ImmutableCollections. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>>> On 8/3/18 2:58 PM, Ioi Lam wrote: >>>>>>> On 8/3/18 11:37 AM, Calvin Cheung wrote: >>>>>>>> Hi Jiangli, >>>>>>>> >>>>>>>> The changes look good to me. >>>>>>>> >>>>>>>> I have couple of minor comments: >>>>>>>> >>>>>>>> 1) vmSymbols.hpp >>>>>>>> >>>>>>>> ?653?? template(url_void_signature, "(Ljava/net/URL;)V") \ >>>>>>>> ?654?? template(toFileURL_name, "toFileURL") \ >>>>>>>> ?655?? template(toFileURL_signature, >>>>>>>> "(Ljava/lang/String;)Ljava/net/URL;") >>>>>>>> >>>>>>>> Since you've moved the above lines to after >>>>>>>> ?template(systemModules_signature, ??, I?d suggest rearrange >>>>>>>> the entire block (lines 652 - 659) in alphabetical order. >>>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> I've reviewed the code. It looks like a clean change and it's >>>>>>> great to make further progress in start-up improvement! >>>>>>> >>>>>>> Just a small note on vmSymbols.hpp:? this line can be deleted >>>>>>> because the symbol is no longer used. >>>>>>> >>>>>>> ? template(jdk_vm_cds_SharedClassInfo, >>>>>>> "jdk/vm/cds/SharedClassInfo") >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>>> 2) CheckArchivedModuleApp.java >>>>>>>> >>>>>>>> Since it now expects two input args, I?d suggest checking the >>>>>>>> number of input args and throw an exception if it is not equal >>>>>>>> to two. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>>> >>>>>>>> On 7/20/18, 11:31 AM, Jiangli Zhou wrote: >>>>>>>>> Please review the following webrev that archives the system >>>>>>>>> module boot layer Configuration (including all java objects >>>>>>>>> reachable from the Configuration) in CDS archive. This is >>>>>>>>> built on top of the earlier change for JDK-8202035 >>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8202035), which >>>>>>>>> provides a framework for object sub-graph archiving. >>>>>>>>> >>>>>>>>> The boot layer Configuration is created in >>>>>>>>> ModuleBootstrap.boot() (similar to the archived system >>>>>>>>> ModuleDescriptor objects, etc) and is unchanged after >>>>>>>>> construction. With archived boot layer Configuration, it >>>>>>>>> allows runtime to bypass the work for creating the >>>>>>>>> configuration. Currently, this is only supported when the >>>>>>>>> initial module is unnamed module. Measurements indicate >>>>>>>>> archiving the boot layer Configuration improves the startup >>>>>>>>> time by 1% ~ 1.5% (on linux-x64) when running HelloWorld from >>>>>>>>> -cp at runtime. >>>>>>>>> >>>>>>>>> Many thanks to Alan and Claes for discussions and >>>>>>>>> contributions to this change! >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ >>>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 >>>>>>>>> >>>>>>>>> Tested with tier1 - tier5 tests via mach5. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jiangli >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>