Re: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking

On Thu, 17 Mar 2022 23:44:32 GMT, Liam Miller-Cushon wrote: > This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. > As discussed in the bug the feature doesn't current work, and only ever > supported scenarios where a security manager is installed, so it seems safe >

Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]

On Fri, 22 Jan 2021 22:16:28 GMT, Jiangli Zhou wrote: >> The directory structure is intact - only the file is removed from the >> filesystem. >> More generally, for many frameworks, where there used to be >> >> >> the file is gone, but >> >>

Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]

On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz wrote: >> 8252412: [macos11] system dynamic libraries removed from filesystem > > Martin Buchholz has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared t

Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]

On Fri, 22 Jan 2021 20:08:48 GMT, Martin Buchholz wrote: >> src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java >> line 132: >> >>> 130: // existence of the containing directory instead of the file. >>> 131: lib = PCSC_FRAMEWORK; >>> 132: if (new

Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]

On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz wrote: >> 8252412: [macos11] system dynamic libraries removed from filesystem > > Martin Buchholz has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared t

Re: RFR: 8228581: Archive BigInteger constants

On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: > > Hi Claes, > > For those of us unfamiliar with the archive mechanism, can you describe > its semantics or send a pointer to such a description? That's a good point. There are some design docs describing how Java objects and object graphs archiv

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

s, Jiangli > > Thanks > Yumin > > On Thu, Jun 20, 2019 at 8:08 AM Jiangli Zhou wrote: >> >> Hi Yumin, >> >> Moving away from re-reading class byte stream and re-computing CRC at >> runtime is definitely in the right direction. That will make CDS user &

Re: Thread stack size issue related to glibc TLS bug

Hi Florian, On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote: > > * Jiangli Zhou: > > > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/ > > (contributed by Jeremy Manson) > > _dl_get_tls_static_info is an internal symbol (it carries a > GLIBC

Re: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES

Looks good! Thanks, Jiangli On Thu, Mar 14, 2019 at 9:26 AM Claes Redestad wrote: > Hi, > > this RFE was stalled due an interaction with SA that has since been > resolved. As it still applies cleanly I'll consider it reviewed. I'm > just going to do some sanity testing (tier1) before push. > >

Re: RFR: 8214858: Improve module graph archiving

Hi Claes, This is awesome. Like the change of encapsulating all the individual fields into the single instance of 'archivedModuleGraph'! All the improvements look great from subgraph archiving point of view. I'll leave the module part to Alan, Mandy and others. Thanks! Jiangli On 12/5/18

Re: RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES

Hi Claes, Looks good from object graph archiving perspective. Placing the KNOWN_NAMES map in the closed archive looks safe since no additional names are added after initialization. If you also agree, maybe add a comment above the KNOWN_NAMES field declaration with those information. Thanks!

Re: RFR: 8213033: Archive remaining primitive box caches

Hi Claes, This looks great! Ship it! :) Thanks, Jiangli On 11/20/18 8:09 AM, Claes Redestad wrote: Hi, this enables archiving of remaining primitive box caches, meaning contents can be mapped in from the CDS archive. These caches appear early in many applications, and bootstrapping each c

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

Thanks! Jiangli On 11/2/18 5:15 PM, Ioi Lam wrote: Hi Jiangli, This looks good to me. Ship it! Thanks - Ioi On 11/2/18 10:57 AM, Jiangli Zhou wrote: Hi Ioi, Here is the updated webrev with the warning message below for the Integer cache.   http://cr.openjdk.java.net/~jiangli/8212995

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

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 HeapShared::check_closed_archive_heap_region_object(InstanceKlass* k, 577

Re: RFR: 8209120: Archive the Integer.IntegerCache

Hi Claes, Looks good! Thanks, Jiangli On 8/13/18 7:16 AM, Claes Redestad wrote: Hi Jiangli, On 2018-08-10 19:15, Jiangli Zhou wrote: Hi Claes, The updated Integer.java looks good. The test also looks good to me. I'd suggest adding some checks in CheckIntegerCacheApp test for the c

Re: RFR: 8209120: Archive the Integer.IntegerCache

Hi Claes, The updated Integer.java looks good. The test also looks good to me. I'd suggest adding some checks in CheckIntegerCacheApp test for the cached Integers using WhiteBox API, WhiteBox.isShared(object) to make sure that they are archived. Checking all cached Integers is probably too ex

Re: RFR: 8209120: Archive the Integer.IntegerCache

Hi Claes, The change on the VM side looks good! Hope to see more graphs like this in the initial java heap being discovered and archived. Thanks! Jiangli On 8/9/18 4:33 AM, Claes Redestad wrote: Hi, using the new ability to archive immutable heap graphs into the CDS archive, even archivi

RFR: 8207263: Store the Configuration for system modules into CDS archive

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

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

Thanks a lot for reviewing, Mandy! Jiangli > On Jul 6, 2018, at 1:40 PM, mandy chung wrote: > > Hi Jiangli, > > On 6/28/18 4:15 PM, Jiangli Zhou wrote:> webrev: > http://cr.openjdk.java.net/~jiangli/8202035/webrev.00/ >> RFE: https://bugs.openjdk.java.net/brow

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

> I don't see anything got placed under the "mods" dir, is it by design? >> Yes. >> > > > On 7/6/18 12:34 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> Thanks for the review! Here is the updated webrevs that address the >> feedbacks from

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

mdLine.toString() + "]"); > 183 } > > Consider putting the above method in ProcessTools.java so that > ProcessTools.createJavaProcessBuilder() and the above test can call it and > avoiding duplicate code. > A separate follow-up bug to address this is fine. That sounds

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

MAT "] => " PTR_FORMAT, > p2i(new_p), p2i(archived)); It is for the case where there is an existing copy of the archived object. Maybe ‘found existing archived copy’ would help? > > > For your consideration, I've incorporated my comments above into >

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

Hi Erik, Thank you for the quick review! Jiangli > On Jun 28, 2018, at 5:44 PM, Erik Joelsson wrote: > > Build changes look good. > > /Erik > > > On 2018-06-28 16:15, Jiangli Zhou wrote: >> This is a follow-up RFE of JDK-8201650 (Move iteration order randomi

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

This is a follow-up RFE of JDK-8201650 (Move iteration order randomization of unmodifiable Set and Map to iterators), which was resolved to allow Set/Map objects being archived at CDS dump time (thanks Claes and Stuart Marks). In the current RFE, it archives the set of system ModuleReference and

Re: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators

Hi Claes, Moving the use of SALT to iterator creation is a great idea! You change looks really good. Thanks for making the change! Jiangli > On Apr 18, 2018, at 8:20 AM, Claes Redestad wrote: > > Hi, > > please review this change that moves the use of SALT to iterator creation, > which wou

Re: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line

> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov > wrote: > > On 11/29/17 4:37 AM, Alan Bateman wrote: >> On 29/11/2017 11:26, David Holmes wrote: >>> >>> The current approach basically prevents anyone using JVMCI from shooting >>> themselves in the foot by setting --limit-modules in a way that

Re: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line

> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov > wrote: > > On 11/29/17 4:37 AM, Alan Bateman wrote: >> On 29/11/2017 11:26, David Holmes wrote: >>> >>> The current approach basically prevents anyone using JVMCI from shooting >>> themselves in the foot by setting --limit-modules in a way that

Re: AppCDS in OpenJDK?

Hi Deepak, In JDK 8u40, AppCDS is an experimental (i.e can not be used in production) feature and is not available in OpenJDK. Following is related info from release notes for 8u40 : Application Class Data Sharing (AppCD

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi Alan and Mandy, Thanks for confirming that. Thanks, Jiangli > On May 25, 2016, at 12:39 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 12:24 PM, Jiangli Zhou wrote: >> >> Hi Mandy, >> >>> On May 25, 2016, at 12:17 PM, Mandy Chung wrote: &

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi Mandy, > On May 25, 2016, at 12:17 PM, Mandy Chung wrote: > > >> On May 25, 2016, at 11:28 AM, Jiangli Zhou wrote: >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > > The version restoring

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

> On May 25, 2016, at 11:43 AM, Alan Bateman wrote: > > > > On 25/05/2016 19:28, Jiangli Zhou wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ > This patch changes long standing behavior in URLs to re

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.01/ Thanks, Jiangli > On May 24, 2016, at 1:00 PM, Jiangli Zhou wrote: > > Hi Martin, > > Thanks for the review. > >> On May 24, 2016, at 10:57 AM, Martin Buchholz wrote: >

Re: RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

. > > > On Tue, May 24, 2016 at 10:47 AM, Jiangli Zhou > wrote: >> Hi, >> >> Please review the following webrev that changes the >> jdk.internal.loader.ClassLoaders.addURLToUCP() to >> java.internal.loader.ClassLoaders.toFileURL(). The change is prov

RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL

Hi, Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ but: https://bugs.openjdk.java

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

Hi Ioi, The change looks pretty clean. The new src/share/vm/classfile/systemDictionary_ext.hpp and src/share/vm/classfile/vmSymbols_ext.hpp do not have copyright header. Please add the copyright headers. Please also fix the copyright year for the modified files prior to pushing. In src/share/

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

Hi Ioi, This sounds ok. Thanks, Jiangli On 10/27/2014 09:57 PM, Ioi Lam wrote: On 10/27/14, 7:52 PM, Jiangli Zhou wrote: Hi Ioi, I have a question for following code in AppClassLoader.loadClass(). If a class is 'known to not exist' for the AppClassLoader (not in the AppClass

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

Hi Ioi, I have a question for following code in AppClassLoader.loadClass(). If a class is 'known to not exist' for the AppClassLoader (not in the AppClassLoader and parent classloaders' shared lookup cache), it seems findLoadedClass() would only find classes that's dynamically loaded by the p

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

Hi Ioi, Here are some comments from me: -src/share/vm/classfile/classLoader.cpp In ClassLoader::setup_search_path, if canonicalize is true it's not necessary to allocate the 'path' and copy the 'class_path' to 'path'. -src/share/vm/memory/metadataFactory.hpp In free_array, is it possible to d

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

Hi Ioi and Mandy, Please see comments below. On 08/11/2014 11:10 PM, Ioi Lam wrote: 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 p

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

Hi David, On 08/10/2014 07:16 PM, David Holmes wrote: src/share/vm/runtime/arguments.cpp 3340 // This causes problems with CDS, which requires that all directories specified in the classpath 3341 // must be empty. Should that be "must not be empty"? Or did you mean directory names? That co

Re: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt

10/30/2012 11:38 AM, Jiangli Zhou wrote: Hi Chris, Here is the updated webrev with added '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options and timeout setting for the following tests: test.java.lang.invoke.RicochetTest test.java.lang.invoke.BigArityTest test.java

Re: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt

Hi Vladimir, Thanks for the review! Jiangli On 11/02/2012 03:03 PM, Vladimir Kozlov wrote: Looks good. We know that VerifyDependencies has significant effect on debug VM performance. Thanks, Vladimir Jiangli Zhou wrote: Redirecting the review request to core-libs-dev@openjdk.java.net

Re: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt

On 11/02/2012 02:33 PM, Jiangli Zhou wrote: Redirecting the review request to core-libs-dev@openjdk.java.net mail list (second try) ... Here is the webrev based on the jdk8/tl/jdk repository: http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ The '-XX:+IgnoreUnrecognizedVMOption