lib/ext JAR file search order

From sun.misc.Launcher$ExtClassLoader: private static URL[] getExtURLs(File[] dirs) throws IOException { VectorURL urls = new VectorURL(); for (int i = 0; i dirs.length; i++) { String[] files = dirs[i].list(); if (files != null) {

Re: RFR: 8042243: Map shared archive to preallocated static address

So backgrounds: The C code in HotSpot is platform-independent, and will take no effect if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace(). Since the code inside HotSpot is pretty small, we could always leave it in (compiled unconditionally for both 32-bit and 64-bit) and

Re: RFR: 8042243: Map shared archive to preallocated static address

had a non-trivial implementation on one platform. Thanks, David On 7/05/2014 4:14 AM, Ioi Lam wrote: So backgrounds: The C code in HotSpot is platform-independent, and will take no effect if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace(). Since the code inside HotSpot is pretty

RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #1

Hi Folks, Please review a the following clean up and refactoring of the AppCDS code http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v1/ https://bugs.openjdk.java.net/browse/JDK-8046070 Summary of fix: Clean up and refactor the Class Data Sharing (CDS) code, including: +

RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

Hi Folks, Please review the following clean up and refactoring of the CDS code, for JDK9 http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v2/ https://bugs.openjdk.java.net/browse/JDK-8046070 Summary of fix: Clean up and refactor the Class Data Sharing (CDS) code, including:

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

, Ioi Lam wrote: Hi Folks, Please review the following clean up and refactoring of the CDS code, for JDK9 http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v2/ https://bugs.openjdk.java.net/browse/JDK-8046070 Summary of fix: Clean up and refactor the Class Data Sharing (CDS) code

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

/testlibrary/BuildHelper.java File has the wrong copyright header. On 29/07/2014 9:09 AM, Ioi Lam wrote: Hi Folks, Please review the following clean up and refactoring of the CDS code, for JDK9 http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v2/ https://bugs.openjdk.java.net/browse/JDK

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

. This is the reason for the iterations. Let me double check. I have to go to a meeting, so more later. Thank you so much! - Ioi thanks, Karen On Jul 28, 2014, at 7:09 PM, Ioi Lam wrote: Hi Folks, Please review the following clean up and refactoring of the CDS code, for JDK9 http

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

On 8/6/14, 8:25 PM, David Holmes wrote: A couple of responses inline ... Cheers, David On 7/08/2014 11:25 AM, Ioi Lam wrote: Hi David, Thanks for the reviews. I will incorporate your suggestions. See additional comments below: On 8/6/14, 3:20 AM, David Holmes wrote: Hi Ioi, Continuing

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #2

On 8/7/14, 1:48 AM, Florian Weimer wrote: On 07/29/2014 01:09 AM, Ioi Lam wrote: Hi Folks, Please review the following clean up and refactoring of the CDS code, for JDK9 http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v2/ https://bugs.openjdk.java.net/browse/JDK-8046070 Can you

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

wrote: Hi Ioi, We seem to have lost core-libs-dev so I added them back. A couple of minor follow ups. On 9/08/2014 6:02 PM, Ioi Lam wrote: Hi, Thanks a lot to everyone for the very useful comments. I have updated the webrev Just the delta from the previous round of review: http

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/11/14, 4:01 PM, Mandy Chung wrote: On 8/11/14 2:15 PM, Ioi Lam wrote: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-v3/ I would like to avoid adding private methods for VM to call as fewer as possible. SecureClassLoader.getProtectionDomain(URL) Can you use the existing

Re: RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, round #3

On 8/10/14, 7:16 PM, David Holmes wrote: Hi Ioi, We seem to have lost core-libs-dev so I added them back. A couple of minor follow ups. On 9/08/2014 6:02 PM, Ioi Lam wrote: Hi, Thanks a lot to everyone for the very useful comments. I have updated the webrev Just the delta from

RFR (XL) 8046070 - Class Data Sharing clean up and refactoring, final round

Hi, Thank you all for the reviews! I have prepared a final version that has incorporated all the comments. http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-vfinal/ - Ioi On 8/9/14, 1:02 AM, Ioi Lam wrote: Hi, Thanks a lot to everyone for the very useful comments. I have updated

RFR (7u): 8046070 - Class Data Sharing clean up and refactoring

Bug: https://bugs.openjdk.java.net/browse/JDK-8046070 jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-August/012235.html jdk9 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-vfinal/ jdk8u-40 webrev:

Re: RFR: race with nested repos in hgforest.sh

How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. 177 while [ ! -d $path ] ## nested repo, ensure containing dir exists

Re: Dismal performance of String.intern()

Hi Steven, This looks like a promising patch. If all goes well I can sponsor this patch into hotspot-rt. I have problems building your test. Could you send a stand-alone test that can be build with plain JDK (i.e., exclude things like com.google.common. and org.openjdk.jmh)? Also, I saw

RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time

Please review this fix: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v1/ Bug: Add an interface to the JVM's Class/Resource Lookup Index Cache for improving sun.misc.URLClassPath search time https://bugs.openjdk.java.net/browse/JDK-8061651 Summary of fix: Some J2EE

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 2)

Hi Mandy, Thanks for the review. I have updated the patch: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v2/ Please see comments in-line. On 10/21/14, 12:56 PM, Mandy Chung wrote: Hi Ioi, On 10/21/14 10:27 AM, Ioi Lam wrote: Please review this fix: http://cr.openjdk.java.net

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 2)

webrev. Please take a look to see if it makes sense. http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v2/ Thanks - Ioi Thanks, Jiangli On 10/21/2014 10:27 AM, Ioi Lam wrote: Please review this fix: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v1/ Bug: Add

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 2)

Hi Mandy, Thanks for the review. please see comments in-line On 10/24/14, 2:33 PM, Mandy Chung wrote: On 10/23/2014 9:34 PM, Ioi Lam wrote: Hi Mandy, Thanks for the review. I have updated the patch: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v2/ Thanks for removing

RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

/test/sun/misc/URLClassPath/EnableLookupCache.java.html Thanks - Ioi On 10/26/14, 4:27 PM, David Holmes wrote: Style nit: all the int cache[] should be int[] cache Also not clear if 8061651-lookup-index-open-v2 is latest webrev ?? Thanks, David On 25/10/2014 9:38 AM, Ioi Lam wrote: Hi Mandy

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

On 10/27/14, 7:04 PM, Mandy Chung wrote: On 10/27/2014 3:32 PM, Ioi Lam wrote: Hi David, I have update the latest webrev at: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v3/ The update looks good. Thanks. This version also contains the JDK test case that Mandy requested

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

without throwing ClassNotFoundException. Thanks - Ioi Thanks, Jiangli On 10/27/2014 3:32 PM, Ioi Lam wrote: Hi David, I have update the latest webrev at: http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v3/ and fixed the int cache[] style you mentioned. This version also contains

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

On 10/27/14, 9:52 PM, Mandy Chung wrote: On 10/27/2014 9:38 PM, Ioi Lam wrote: What I request to add is a test setting the system property (-Dsun.cds.enableSharedLookupCache=true) and continue to load class A and B. Removing line 44-58 should do it and also no need to set -Dfoo.foo.bar

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

)); } Thanks - Ioi David David H and Mandy - does that make sense to you both? thanks, Karen On Oct 28, 2014, at 12:38 AM, Ioi Lam wrote: On 10/27/14, 7:04 PM, Mandy Chung wrote: On 10/27/2014 3:32 PM, Ioi Lam wrote: Hi David, I have update the latest webrev at: http://cr.openjdk.java.net

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

and is final so no worries there. thanks, Karen On Oct 29, 2014, at 2:37 AM, David Holmes wrote: On 29/10/2014 4:04 PM, Ioi Lam wrote: On 10/28/14, 7:34 PM, David Holmes wrote: Hi Karen, I haven't been tracking the details of this and am unclear on the overall caching strategy however ... On 29/10

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

ow the use of @CallerSensitive in the jdk.vm.cds module. Thanks - Ioi On 11/2/15 7:40 PM, Ioi Lam wrote: Hi, I have updated the webrev to include all the feedback from the past few days: Delta from the previous webrev http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/ Full ch

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

regarding the usage of new_permanent_symbol() and TempNewSymbol in classLoaderExt.cpp. It doesn’t seem to be consistent. Thanks, Jiangli On Oct 30, 2015, at 10:00 AM, Ioi Lam <ioi@oracle.com> wrote: Please review the following fix: http://cr.openjdk.java.net/~iklam/81408

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

Coleen On 10/30/15 1:00 PM, Ioi Lam wrote: Please review the following fix: http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ Bug: Clean up and refactor of class loading code for CDS https://bugs.openjdk.java.net/browse/JDK-8140802 Summary of fix: We need to clean up and re

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

an entry in the SystemDictionary on success This assert code is a copy of some code elsewhere. Can you make it a function that they boh can call? Can you also comment the raw #endif's to what they're endifing? Otherwise, this looks okay. Coleen On 10/30/15 1:00 PM, Ioi Lam wrote: Please review the

RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

Please review the following fix: http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ Bug: Clean up and refactor of class loading code for CDS https://bugs.openjdk.java.net/browse/JDK-8140802 Summary of fix: We need to clean up and refactor the class loading code in order

Re: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08

On 8/10/17 9:46 PM, David Holmes wrote: On 11/08/2017 2:31 PM, Igor Ignatyev wrote: On Aug 10, 2017, at 9:22 PM, David Holmes wrote: Hi Igor, On 11/08/2017 2:02 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html 14

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry,

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

is using reflection. So until the jtreg bug is fixed, I am not at all sure that removing all the explicit @build is the correct thing to do, as it's still bound to make existing unrelated tests fail randomly if new tests with an explicit @build are added later on... my2c -- daniel On 01/06/2017

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/2/17 8:44 AM, Ioi Lam wrote: On 6/2/17 6:40 AM, Chris Hegarty wrote: On 02/06/17 00:14, Ioi Lam wrote: ... The gem is hidden in the compile.0.jta file. It contains something like: -sourcepath :/jdk/foobar/test/lib: So if my test refers to a class under /test/lib

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/2/17 6:40 AM, Chris Hegarty wrote: On 02/06/17 00:14, Ioi Lam wrote: ... The gem is hidden in the compile.0.jta file. It contains something like: -sourcepath :/jdk/foobar/test/lib: So if my test refers to a class under /test/lib, such as jdk.test.lib.process.ProcessTools, javac

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 6/1/17 1:17 PM, Igor Ignatyev wrote: On Jun 1, 2017, at 1:20 AM, Chris Hegarty wrote: Igor, On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry,

Re: RFR(M) : 8181761: add explicit @build actions for jdk.test.lib classes in all :tier2 tests

On 6/8/17 9:18 AM, Igor Ignatyev wrote: Alan, I totally agree there are many places which we need to clean up in testlibraries, including these weird dependencies, but it would be much easier to clean up test libraries after they are merged in one place. personally I don't think that

Re: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary

From the mails I can appreciate people have wildly different opinion about the virtue of @build :-) But regardless of your opinion on @build, I think the issue I identified in CODETOOLS-7901986 [1] is definitely a bug -- the bug is when a library is compiled, it incorrectly depends on

Re: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary

Just as a point of information: The HotSpot team was well aware of these issues when removing the @build flags from the HotSpot test cases. We felt these were less evils than random failures in our test runs. After the @build removal, the incidence of random NoClassDefFoundError in HotSpot

RFR (XS) 8188828 Intermittent ClassNotFoundException: jdk.test.lib.Platform for compiler tests

Please review this very simple change: https://bugs.openjdk.java.net/browse/JDK-8188828 http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/ The dependency of     FileInstaller -> Utils -> JDKToolLauncher -> Platform has caused many intermittent

Re: FW: RFR(S): [testbug] add @requires vm.cds to CDS tests in jdk test suite

identified three tests in the jdk suite that require the same. Best regards, Goetz. Thanks - Ioi On 8/29/17 7:48 AM, Ioi Lam wrote: These changes look good to me. Thanks - Ioi On 8/28/17 10:58 PM, Lindenmaier, Goetz wrote: Hi, could I please get a review on core-libs-dev? Thanks

Re: FW: RFR(S): [testbug] add @requires vm.cds to CDS tests in jdk test suite

These changes look good to me. Thanks - Ioi On 8/28/17 10:58 PM, Lindenmaier, Goetz wrote: Hi, could I please get a review on core-libs-dev? Thanks, Goetz. -Original Message- From: David Holmes [mailto:david.hol...@oracle.com] Sent: Dienstag, 29. August 2017 00:33 To:

Re: RFR: 8209120: Archive the Integer.IntegerCache

On 8/10/18 8:44 AM, Claes Redestad wrote: On 2018-08-10 16:10, Ioi Lam wrote: I've verified all cases I can think of manually, but would like to defer the creation of a sanity test to a follow-up RFE to allow time to think through and discussing how to best go about that (do we need

Re: Makefile Suppress Deprecation Warnings

It would be helpful if you can provide information like: + Which version of the JDK repo are you using? + Which platform are you building? The only case I found under the make/ directory is here in the latest repo:

Re: Command 'make jdk' no longer runs ; request a quick look

What kind of modifications have you made to get you to this state? Have you tried undoing your changes one by one to see what causes this to happen? I have to be honest with you. With the vague (and rude) questions that you have been sending to these mailing lists, I doubt anyone is really

Re: RFR: 8209120: Archive the Integer.IntegerCache

> On Aug 10, 2018, at 6:32 AM, Claes Redestad wrote: > > >> On 2018-08-09 18:28, Claes Redestad wrote: >> >> >>> On 2018-08-09 17:41, Peter Levart wrote: >>> >>> There's danger when you overwrite a non-null @Stable field with another >>> value that this new value will not be seen. Or is

Re: Javac Compiler

$ find . -name main | grep javac ./src/jdk.compiler/share/classes/com/sun/tools/javac/main ./test/langtools/tools/javac/main On 8/23/18 6:10 PM, mr rupplin wrote: com.sun.tools.javac.main.Main com.sun.tools.javac.main.Main compiler = new

Re: RFR(L): 8202035: Archive the set of ModuleDescriptor and ModuleReference objects for system modules

Hi Jiangli, Thank you so much for working on this. I think it's great that we can get the start-up improvement by archiving the ModuleDescriptor. I just have some coding style comments regarding heapShared.cpp. This file contains the code for coping objects and relocating pointers. By its

Re: RFR(L): 8202035: Archive the set of ModuleDescriptor and ModuleReference objects for system modules

Hi Jiangli, The VM changes look good to me. For the tests: I think we need a comment here saying that "mods" is intentionally empty, and also an explanation why it's not necessary to actually fill with actual modules? Thanks - Ioi 3) ArchivedModuleComboTest.java 55 Path

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 10/31/18 5:13 PM, dean.l...@oracle.com wrote: On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related comments:

Re: RFR: 8212995: Consider placing the Integer.IntegerCache and cached Integer objects in the closed archive heap region

not be assigned 1000  * with new Integer object(s) after initialization. Including core-lib-dev mailing list since the change now touches the core library file. Thanks, Jiangli On 11/1/18 10:58 PM, Jiangli Zhou wrote: Hi Ioi, On Nov 1, 2018, at 9:37 PM, Ioi Lam wrote: Hi Jiangli,   576 void

Re: RFR(S) 8190737: use unicode version of the canonicalize() function to handle long path on windows

Looks good. Thanks! Ioi > On Sep 10, 2018, at 11:42 AM, Calvin Cheung wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8190737 > > webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/ > > Please review this change for handling long path specified in the > -Xbootclasspath/a

Re: RFR(s): 8205131: remove Runtime trace methods

On 6/4/19 7:46 PM, Stuart Marks wrote: Hi all, Please review this changeset and CSR request that remove the traceInstructions() and traceMethodCalls() methods from java.lang.Runtime. These methods have been deprecated for removal since Java 9, and they do nothing. I've also removed a

Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Hi Jie, Instead of using an obscure call Reference.reachabilityFence(loader), how about just making "loader" a static field in the test class, so it will be kept alive until it's explicitly set to null? Thanks - Ioi On 6/12/19 1:37 AM, Jie Fu wrote: Hi all, JBS:   

Re: RFR: JDK-8222373 Improve CDS performance for custom class loaders

On 6/19/19 11:36 PM, Alan Bateman wrote: On 20/06/2019 02:36, yumin qi wrote: Hi, Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8222373 webrev: http://cr.openjdk.java.net/~minqi/8222373/01/ To load shared class from CDS, first class file stream is read from jar file, then

Re: RFR: JDK-8222373 Improve CDS performance for custom class loaders

On 6/20/19 10:35 AM, Alan Bateman wrote: On 20/06/2019 17:50, yumin qi wrote: Hi, Alan and Ioi   Thanks. Forget to add core-libs-dev for the review.   If add a public API, surely it should be discussed in detail the design, implementation and effects. One question, will adding a public API

Re: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths on Windows?

Hi Thorsten, since you have problems filing bugs on JBS, I filed the following bug on your behalf. https://bugs.openjdk.java.net/browse/JDK-8234363 I have not investigated the issue in detail yet. How often do you see ERROR_NO_MORE_FILES happening? Have you checked if your process (apache?)

Re: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

73 Rough example webrev:http://cr.openjdk.java.net/~afarley/8232773/webrev/ Best Regards Adam Farley IBM Runtimes From:   David Holmes To: Martin Buchholz Cc: Ioi Lam, core-libs-dev , Adam Farley8 Date:   24/10/2019 05:22 Subject:    [EXTERNAL] Re: RFR: JDK-8232773: ClassLoadin

Re: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

Hi Adam, The HotSpot logging option:   -Xlog:class+load=debug will show the class loader, super class, interfaces, size of the classfile, etc. A related option:   -Xlog:class+resolve=debug shows all the class resolution done by the Java code during execution. You're right that

Loading classes during VM shutdown

For JDK-8232081 (Try to link all classes with ArchiveClassesAtExit), when creating a dynamic CDS archive, I need to link all classes in the "loaded" state. I am thinking of doing it at this point: src/java.base/share/classes/java/lang/Shutdown.java:     private static void runHooks() {    

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

On 2/27/20 10:14 PM, Calvin Cheung wrote: Hi Ioi, On 2/27/20 8:22 PM, Ioi Lam wrote: Hi Calvin, This looks good to me. Thanks for taking another look. I would suggest adding the something like this to the test case: class Child extends Parent {     int get() {return 2;}     int dummy

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

On 2/26/20 7:50 PM, David Holmes wrote: Hi Calvin, Adding core-libs-dev as you are messing with their code :) On 27/02/2020 1:19 pm, Calvin Cheung wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8232081 webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/ The proposed

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

e never linked when the application actually executed ?? On 28/02/2020 10:48 am, Calvin Cheung wrote: Hi David, Ioi, Thanks for your review and suggestions. On 2/26/20 9:46 PM, Ioi Lam wrote: On 2/26/20 7:50 PM, David Holmes wrote: Hi Calvin, Adding core-libs-dev as you are messing with the

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

:48 PM, Calvin Cheung wrote: Hi David, Ioi, Thanks for your review and suggestions. On 2/26/20 9:46 PM, Ioi Lam wrote: On 2/26/20 7:50 PM, David Holmes wrote: Hi Calvin, Adding core-libs-dev as you are messing with their code :) On 27/02/2020 1:19 pm, Calvin Cheung wrote: JBS: https

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

or new webrev. Thanks - Ioi On 3/5/20 11:48 AM, Calvin Cheung wrote: On 3/5/20 9:17 AM, Ioi Lam wrote: Hi Calvin, Looks good overall. I just have two comment: I think this is not needed:  306 void ConstantPool::resolve_class_constants(TRAPS) {  307   Arguments::assert_is_dumping_archive();

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

to answer your questions inline below.. Responses inline below ... On 28/02/2020 10:48 am, Calvin Cheung wrote: Hi David, Ioi, Thanks for your review and suggestions. On 2/26/20 9:46 PM, Ioi Lam wrote: On 2/26/20 7:50 PM, David Holmes wrote: Hi Calvin, Adding core-libs-dev as you a

Re: Improving ZipFile.getEntry performance using Bloom filters

On 4/13/20 12:26 PM, Eirik Bjørsnøs wrote: Hi, While working on improvements to JarFile.getVersionedEntry, it occurred to me that the missing lookups we are removing there may be just one example of a more general issue. To get a better understanding of how ZipFile.getEntry is used, I added

Re: RFR(XS): 8174768: Make ProcessTools print executed process output into a separate file

On 4/1/20 12:13 PM, Igor Ignatyev wrote: Hi Evgeny, (widening the audience, given this affects not just hotspot compiler, but hotspot tests as well as core libs tests in general) overall that looks good to me. one suggestion, for the ease of failure analysis it might be worth to print out

Re: RFR(T) : 8244066 : ClassFileInstaller should be run in driver mode

Looks good and trivial. Thanks - Ioi On 4/28/20 9:41 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00 16 lines changed: 0 ins; 0 del; 16 mod; Hi all, could you please review this trivial cleanup in tests? from JBS: ClassFileInstaller is a test utility class

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

More comments below On 4/26/20 11:20 PM, David Holmes wrote: Hi Ioi, On 27/04/2020 3:22 pm, Ioi Lam wrote: https://bugs.openjdk.java.net/browse/JDK-8241071 http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/ The goal is to for "java -Xshare:dump" to produce

Re: RFR(S) 8241071 Generation of classes.jsa with -Xshare:dump is not deterministic

anually as we go. Or could we not order the placement of Klass and Symbol at dump time? Dump time is not that time critical, no? Thanks & Sorry, Thomas On Mon, Apr 27, 2020 at 7:31 AM Ioi Lam mailto:ioi@oracle.com>> wrote: https://bugs.open

Re: RFR(S) 8241071 Generation of classes.jsa is not deterministic

On 4/27/20 7:05 PM, David Holmes wrote: On 28/04/2020 10:01 am, David Holmes wrote: On 28/04/2020 9:37 am, Ioi Lam wrote: Hi David & Jiangli, Thanks for your comments. I thought about using a system property, but the user can also specify it like java -Djdk.xshare.dump.sa

Re: RFR(S) 8241815: Unnecessary calls to SystemDictionaryShared::define_shared_package

Hi Calvin, this looks good to me, too. Thanks - Ioi On 4/27/20 12:21 PM, Calvin Cheung wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8241815 webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/ This change is to avoid java up call of definePackage() while loading a

RFR(S) 8241071 Generation of classes.jsa is not deterministic

https://bugs.openjdk.java.net/browse/JDK-8241071 http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/ The goal is to for "java -Xshare:dump" to produce deterministic contents in the CDS archive that depend only on the contents of $JAVA_HOME/lib/modules. Problems: [1]

Re: RFR: 8244778: Archive full module graph in CDS [v2]

On Wed, 9 Sep 2020 18:41:25 GMT, Lois Foltan wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request >> contains six

Re: RFR: 8244778: Archive full module graph in CDS [v2]

/041496.html). > The rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merg

Re: RFR: 8244778: Archive full module graph in CDS [v3]

/041496.html). > The rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Feedback from Coleen - Chang

Re: RFR: 8244778: Archive full module graph in CDS [v3]

On Tue, 8 Sep 2020 17:32:44 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Feedback from Coleen > > src/hotspot/share/classfile/classLoaderDataShared.cpp line 17

Re: RFR: 8244778: Archive full module graph in CDS

On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in > [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.n

RFR: 8244778: Archive full module graph in CDS

This is the same patch as [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) published in [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). The rest of

Re: RFR: 8244778: Archive full module graph in CDS [v4]

/041496.html). > The rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merg

Re: RFR: 8244778: Archive full module graph in CDS [v4]

On Sat, 12 Sep 2020 12:34:06 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request >> contains

Re: RFR: 8244778: Archive full module graph in CDS [v6]

/041496.html). > The rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed failure in runtime/cds/DeterministicDump.java

Re: RFR: 8244778: Archive full module graph in CDS [v5]

/041496.html). > The rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Claes feedback (typos, refactored archived fields init);

Integrated: 8244778: Archive full module graph in CDS

On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in > [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.n

Re: RFR(L) 8244778 Archive full module graph in CDS

-graph.v03/ http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03.delta/ Please see my comments in-line. On 8/25/20 7:58 AM, Lois Foltan wrote: Hi Ioi, Changes looks really good.  Comments interspersed below. Thanks, Lois On 8/12/2020 6:06 PM, Ioi Lam wrote: Hi Lois

Re: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2]

On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote: >> Hi, Please review the simple change. >> >> The removing of white spaces from end of line in ClassListParser should be >> moved to before we add lambda-form-invoker >> line to array. After made such arrangement, changed CDS.java for

Re: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5]

On Tue, 13 Oct 2020 23:08:22 GMT, Calvin Cheung wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE >> adds the functionality of archiving of >> lambda proxy classes in static CDS archive.

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/20/20 5:10 PM, Mandy Chung wrote: On 8/19/20 10:14 PM, Yumin Qi wrote: HI, Mandy   Thanks for the review, I took one day off yesterday so just got a detail look of your reply. On 8/19/20 1:30 PM, Mandy Chung wrote: On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

Hi Yumin, This looks good overall. Here are my comments: = 6065 size_t new_id = Atomic::add(, (size_t)1); 6066 jio_snprintf(addr_buf, 20, INTPTR_FORMAT, new_id); I think this should be SIZE_FORMAT =   65 class KlassFactory : AllStatic {   66  

Re: RFR: 8253208: Move CDS related code to a separate class [v2]

On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a >> separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional >

Re: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class

On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused > runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by > this patch, the test case now is put on >

RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class

Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed DeterministicDump.java. I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. I executed the command: git revert

Integrated: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class

On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests > locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3]

On Fri, 25 Sep 2020 21:19:39 GMT, Yumin Qi wrote: >> This patch is reorganized after 8252725, which is separated from this patch >> to refactor jlink glugin code. The previous >> webrev with hg can be found at: >> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 >>

Re: RFR: 8253208: Move CDS related code to a separate class

On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a > separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 src/java.base/share/classes/jdk/internal/misc/CDS.java line 52: > 50: * Check

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On Tue, 15 Sep 2020 18:57:55 GMT, Yumin Qi wrote: > This patch is reorganized after 8252725, which is separated from this patch > to refactor jlink glugin code. The previous > webrev with hg can be found at: > http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 >

Re: Fwd: RFR: 8247536: Support pre-generated MethodHandle lambda forms in CDS

Hi Yumin, This looks good! Here are my comments: [1] classListParser.cpp: #define LAMBDA_FOMRM_INVOKER "@lambda-form-invoker" I think this should be moved to classListParser.hpp:     const char* lambda_form_invoker_tag() {     return "@lambda-form-invoker";     } Also, instead of also

  1   2   3   >