Integrated: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from GetModuleHan

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from GetModuleHan

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Wed, 26 Jan 2022 08:59:49 GMT, Alan Bateman wrote: >> Please review, >> When jlink with --compress=2, zip is used to compress the files while >> doing copy. The user case failed to load zip.dll, since zip.dll is not set >> in PATH. This failure is after we get NULL from GetModuleHandle("zi

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing > copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. > This failure is after we get NULL from GetModuleHan

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Tue, 25 Jan 2022 10:29:48 GMT, Thomas Stuefe wrote: > I'm curious, under what circumstances would, before > https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary > in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where > the JVM was not involve

Re: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call

On Tue, 25 Jan 2022 01:59:56 GMT, David Holmes wrote: > * The jimage code was using the OS code (dlopen/loadlibrary etc) to try and > load the zip library when needed. Yes. The zip library has to be in PATH. > * The VM, which is always loaded first, always used to load the zip library > uncondi

Re: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default > CDS archive, time to update test configuration for this platform. This is a > very small one-line change. LGTM. - Marked as reviewed by mi

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5]

On Thu, 6 May 2021 21:59:32 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove tab space > > The latest version LGTM @iklam @calvinccheung Thanks for rev

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5]

On Thu, 6 May 2021 23:59:21 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove tab space > > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFil

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5]

successful dump, the temporary file will be rename > to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation > result is not same as on Linux. > >Tests: tier1,tier2,tier3,tier4

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v4]

successful dump, the temporary file will be rename > to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation > result is not same as on Linux. > >Tests: tier1,tier2,tier3,tier4

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v3]

successful dump, the temporary file will be rename > to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation > result is not same as on Linux. > >Tests: tier1,tier2,tier3,tier4

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2]

On Wed, 5 May 2021 18:20:43 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JCmdTestFileSecurity.java should be excluded from dynamic test group > > src/java.base/share/clas

Re: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2]

successful dump, the temporary file will be rename > to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation > result is not same as on Linux. > >Tests: tier1,tier2,tier3,tier4

RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens

Hi, Please review When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the tempo

Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"

On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi wrote: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. > In mapping CDS archive we first reserve enough memory then before mapping, > release them. For cds archive and using class space, ne

Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]

On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi wrote: >> Changes requested by iklam (Reviewer). > > Please check 03. 02 is generated when merge with most current and remote head > not updated correctly. After set remote head correct, 03 is regenerated and > is correct one for re

Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]

the 'real' split either. For Windows (and using > class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Added test

Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]

the 'real' split either. For Windows (and using > class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision: - Add total_

Re: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the > `jdk.internal.lambda.disableEagerInitialization` property was not captured > during dumping of lambda proxy classes. There's a workaround in > `LambdaProxyClassArchive.find`, it won't call `findFr

Re: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the > `jdk.internal.lambda.disableEagerInitialization` property was not captured > during dumping of lambda proxy classes. There's a workaround in > `LambdaProxyClassArchive.find`, it won't call `findFr

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

On Thu, 15 Oct 2020 15:59:31 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix comment adding \f for Replace > > Looks good. Thanks @iklam and @calvinccheung for

Integrated: 8254192: ExtraSharedClassListFile contains extra white space at end of line

On Wed, 14 Oct 2020 22:09:50 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.ja

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

ocal test on runtime/cds/appcds. Mach5 tier1,4 is in progress. > > Thanks Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix comment adding \f for Replace - Changes: - all: https://git.openjdk.java.net/jdk

RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line

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 trimming line code. Tests: local test on runtime/cds/appcds. Mach5 tie

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

On Fri, 25 Sep 2020 21:45:13 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8247536: Support for pre-generated java.lang.invoke classes in CDS static >> archive > > t

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

asses is simply to call the new added > GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - In case of exception happens during rel

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

On Mon, 28 Sep 2020 16:17:21 GMT, Igor Ignatyev wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead >> of creating a new one. > > Marked

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

asses is simply to call the new added > GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of htt

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

asses is simply to call the new added > GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classe

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

asses is simply to call the new added > GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classe

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

asses is simply to call the new added > GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - 8247536: Support for pre-generated jav

Integrated: 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 n

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

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 ProblemList.txt. The real root cause for the failure is detailed i

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

On Wed, 16 Sep 2020 19:01:18 GMT, Ioi Lam 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 >> integra

Integrated: 8253492: Miss comma after second copyright year in FDBigInteger.java

On Tue, 22 Sep 2020 18:06:40 GMT, Yumin Qi wrote: > In patch for jdk-8253208, a comma missed after copyright year in > src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed > "@return" to "Returns" in the comment for > CDS.getRandomSeedFo

RFR: 8253492: Miss comma after second copyright year in FDBigInteger.java

In patch for jdk-8253208, a comma missed after copyright year in src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed "@return" to "Returns" in the comment for CDS.getRandomSeedForDumping to keep consistent with others. - Commit messages: - 8253492: Miss com

Integrated: 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 This pull request has now been integrated. Changeset: c1df13b8 Author:

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

> 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 commit since the last revision: 8253208: Move

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

On Sun, 20 Sep 2020 06:10:53 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8253208: Move CDS related code to a separate class > > src/java.base/share/native/libjava/CDS.

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

> 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 commit since the last revision: 8253208: Move

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

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 - Commit messages: - 8253208: Move CDS related code to a separate class - Merge branch 'master' of https://github.com/yminqi/jdk i

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

l be added to CDS.java > 493 * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE > > s/simimar/similar > > 494 * @see InvokerBytecodeGenerator > 495 * @param line the line to output. > > @see is typically placed after @param. > > Should it say @see ja

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

HI, all   Please review changes for  8247536: Support for pre-generated java.lang.invoke classes in CDS static archive.   What happened:   I pushed with commit comment:     8247536: Support for pre-generated java.lang.invoke classes in CDS static archive   When created pullrequest, the tit

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

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 integrated, the regeneration of holder classes is simply to call the new

Re: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError

On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder > classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` > methods are invoked > unco

Re: RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError

On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder > classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` > methods are invoked > unco

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

Hi, Alan   Thanks. Pushed before saw your email, could not credit you on reviewers. Thanks Yumin On 9/4/20 2:10 AM, Alan Bateman wrote: On 04/09/2020 05:37, Yumin Qi wrote: HI, Sundar   Thanks for review. On 9/3/20 6:34 PM, sundararajan.athijegannat...@oracle.com wrote: Looks good to me

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

. (Certainly will build first to verify that). Thanks Yumin -Sundar On 04/09/20 3:41 am, Yumin Qi wrote: HI, Mandy   Thanks for review and comment. Yumin On 9/3/20 9:13 AM, Mandy Chung wrote: On 9/3/20 8:36 AM, Yumin Qi wrote: Hi, Please review bug: https://bugs.openjdk.java.net

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

HI, Mandy   Thanks for review and comment. Yumin On 9/3/20 9:13 AM, Mandy Chung wrote: On 9/3/20 8:36 AM, Yumin Qi wrote: Hi, Please review bug: https://bugs.openjdk.java.net/browse/JDK-8252725 webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ Looks good to me

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

Sorry push "send" too soon: Tests: local build. mach5 tier1-4 have 2 timeouts on build which I think related to lab move(?). Thanks Yumin On 9/3/20 8:36 AM, Yumin Qi wrote: Hi, Please review bug: https://bugs.openjdk.java.net/browse/JDK-8252725 webrev: http://cr.openjdk.java.

RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

Hi, Please review bug: https://bugs.openjdk.java.net/browse/JDK-8252725 webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ Summary: The work is part of 8247536, which supports archive pre-generated java.lang.invoke classes in CDS. In this patch (thanks to Mandy): 1. Two metho

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

invoke_GenerateJLIClassesHelper_cdsTraceResolve(JNIEnv *env, jclass ignore, jstring line) { Maybe this should be moved to the "VM" class as well? = lambdaFormInvokers.hpp: Need these declarations:     #include "memory/allocation.hpp"    <-- fo

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

ang/invoke/GenerateJLIClassesHelper.java, so VM call its function to regenerate holder classes.   Re-tested Mach5 tier1-4 Thanks Yumin ** On 8/20/20 8:05 PM, Yumin Qi wrote: Hi, Mandy 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 to

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

Hi, Mandy 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

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

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 review/suggestion. I have updated the webrev at the following link: http

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

x27;s still applicable. https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068160.html -Sundar On 18/08/20 1:07 am, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev at the following link: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/  

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

uld contain it. Thanks Yumin thanks, Calvin On 8/11/20 10:36 AM, Yumin Qi wrote: Forget to send to @core-lib-dev, the patch changed jdk code. Thanks Yumin Forwarded Message Subject: RFR: 8247536: Support pre-generated MethodHandle lambda forms in CDS Date:

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

_LOG_PREFIX: 5) DumpSymbolAndStringTable.java 37 private static final String my_string = "DumpSymbolAndStringTable"; Unused variable? thanks, Calvin On 8/11/20 10:36 AM, Yumin Qi wrote: Forget to send to @core-lib-dev, the patch changed jdk code. Thanks Yumin -

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

Forget to send to @core-lib-dev, the patch changed jdk code. Thanks Yumin Forwarded Message Subject:RFR: 8247536: Support pre-generated MethodHandle lambda forms in CDS Date: Tue, 11 Aug 2020 07:44:34 -0700 From: Yumin Qi To: hotspot-runtime

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks Mandy for review! Yumin On 5/6/20 6:50 PM, Mandy Chung wrote: This looks okay to me. Mandy On 5/6/20 6:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks for review, yes, enough for a push! Yumin On 5/6/20 7:15 PM, David Holmes wrote: On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: On 5/6/20 9:01 PM, Yumin Qi wrote: Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http

Re: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Thanks for review! Yumin On 5/6/20 6:26 PM, Kim Barrett wrote: On May 6, 2020, at 9:01 PM, Yumin Qi wrote: Hi, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8244495 webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink

RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750

Hi,   Please review the fix for   bug: https://bugs.openjdk.java.net/browse/JDK-8244495   webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750 pushed. The fix of 8237750 changed default behavior of lo

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

gt; > 2) Dumping process > This is for both the static dumping process and dynamic dumping > process. For the static dumping process, a complete new design is > needed in order to make the support adoptable. > > Best regards, > > Jiangli > > On Wed, Jun 1

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

tried to avoid such process, that may not be a good choice for this case. Thanks Yumin On Thu, Jun 20, 2019 at 12:12 AM Ioi Lam wrote: > > > On 6/19/19 11:36 PM, Alan Bateman wrote: > > On 20/06/2019 02:36, yumin qi wrote: > >> Hi, Please review: > >> bug: https:/

Re: Anonymous class

David Holmes wrote: > > > On 25/01/2019 6:52 pm, yumin qi wrote: > > Hi, > > > >I have a question of anonymous class. We know the anonymous class > with a > > host_klass, and the flag is set when the InstanceKlass is created after > the > > class

Anonymous class

Hi, I have a question of anonymous class. We know the anonymous class with a host_klass, and the flag is set when the InstanceKlass is created after the class parsed. In case of a regular java class file, the flag will be set correctly but for the case it is not set: SystemDictionary::parse_st

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Roger, Thanks. Pushed. On Wed, Feb 21, 2018 at 2:00 PM, Roger Riggs wrote: > Hi Yumin, > > Use your OpenJDK id "minqi" for the Author instead of your email. > > Roger > > > > On 2/21/2018 4:54 PM, yumin qi wrote: > >> Alan, >> >>

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

fc6df5c6d4d2 2018-01-23 14:21:17 -0800] remote: remote: > Changeset: 48927:0736b1e12c70 remote: > Author: Yumin Qi remote: > Date: 2018-02-21 12:01 remote: > remote: > 8194154: System property user.dir should not be changed remote: > Summary: Cached user.dir so getCanonicalPath use

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Yes, I am committer. Brian, do you okay with the version? If no objection, I will push it into jdk. Thanks Yumin On Mon, Feb 19, 2018 at 2:28 AM, Alan Bateman wrote: > On 19/02/2018 05:09, yumin qi wrote: > >> Thanks! >> >> I need a sponsor for pushing it to jdk. Can

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Thanks! I need a sponsor for pushing it to jdk. Can you or someone else help to push it? Yumin On Fri, Feb 16, 2018 at 11:45 PM, Alan Bateman wrote: > On 16/02/2018 20:35, yumin qi wrote: > > : > >> >> Updated bug, and update webrev at same link: > http://cr.open

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On Fri, Feb 16, 2018 at 3:52 AM, Alan Bateman wrote: > On 15/02/2018 20:28, yumin qi wrote: > >> : >> Since the property string contains non-normalized characters, it >> crashed in native canonicalize. >> I believe user.dir from the system is normalized,

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

n is user.dir should not be changed, how about changing description to 8194154: System property user.dir should not be changed. The test case renamed to: UserDirChangedTest.java ? Thanks Yumin On Thu, Feb 15, 2018 at 10:41 AM, yumin qi wrote: > There are two problems here, so

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

covers two of them. Should we handle them in two separate bugs? Yumin On Thu, Feb 15, 2018 at 10:00 AM, yumin qi wrote: > OK, let's work on a suitable test case. > > Thanks > Yumin > > On Thu, Feb 15, 2018 at 9:41 AM, Alan Bateman > wrote: > >> On

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

OK, let's work on a suitable test case. Thanks Yumin On Thu, Feb 15, 2018 at 9:41 AM, Alan Bateman wrote: > On 15/02/2018 17:25, yumin qi wrote: > >> Alan, >> >> The real reason is if we do not change on resolve, the string passed >> into native canonica

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

wrote: > On 14/02/2018 23:52, yumin qi wrote: > >> Brian, >> >> Updated using RuntimeException, which will not need -ea so removed. >> http://cr.openjdk.java.net/~minqi/8194154/webrev1/ < >> http://cr.openjdk.java.net/%7Eminqi/8194154/webrev1/> >> >&

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

have the @requires annotation on a separate line > for example as: > > /* @test > * @requires (os.family == "linux") | (os.family == "mac”) > * | (os.family == "solaris") | (os.family == "aix") > * @bug 8194154 > * @summary Test

Re: RFR: 8194154 patch for crash at File.getCanonicalPath()

rom inside the > file system implementation. > > Regards, Roger > > > On 2/13/2018 6:45 PM, yumin qi wrote: > >> Alan, >> >>In fact, if property "user.dir" is cached, the problem will go away >> without any changes to native or UnixFileSystem.java,

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Hi, Alan Thanks. Updated on same link http://cr.openjdk.java.net/~minqi/8194154/webrev1/ as your recommendation. Yumin On Wed, Feb 14, 2018 at 4:42 AM, Alan Bateman wrote: > On 14/02/2018 01:23, yumin qi wrote: > >> Hi, >> >> I have update the webrev: >&

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

atically exiting if the platform is not Windows. (I am > assuming that this should be run on all Unix variants, not just Linux.). > > Thanks, > > Brian > > [1] http://openjdk.java.net/jtreg/tag-spec.html#requires_names > > On Feb 13, 2018, at 5:23 PM, yumin qi wrote: > > I have update the webrev: > http://cr.openjdk.java.net/~minqi/8194154/webrev1/ > > >

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

;user.dir" is cached, any changes via property setting for it has no effect. Thanks Yumin On Wed, Feb 7, 2018 at 10:54 PM, Alan Bateman wrote: > On 07/02/2018 20:10, yumin qi wrote: > >> Hi, >> >>Please review the fix (extra small) for: >>bug 8194154: h

Re: RFR: 8194154 patch for crash at File.getCanonicalPath()

Alan, In fact, if property "user.dir" is cached, the problem will go away without any changes to native or UnixFileSystem.java, since it won't canonicalize the string supplied from user. The output will be getProperty("user.dir") + "/" + file. (The result is not as expected, user can not chang

Re: RFR: 8194154 patch for crash at File.getCanonicalPath()

HI, Alan As in your email to RFR of 8194154 which now has a new fix in canonicalize_md.c, switch back to discuss solution here again. The current fix is not in java, instead, I put it in C function. In the function before the fix, it assumes no more "//" pattern in the string so failed to get

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

David, Thanks! On Wed, Feb 7, 2018 at 7:32 PM, David Holmes wrote: > Moving to core-libs-dev. Code reviews don't take place on jdk-dev but on > the component area mailing lists. > > Thanks, > David > > > On 8/02/2018 6:10 AM, yumin qi wrote: > >> Hi, >&

Re: RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

Kumar is in CC, i believe, he is the one that sync the private copy of ASM used by the JDK with the SVN trunk. regards, Rémi - Mail original ----- De: "Yumin Qi" À: core-libs-dev@openjdk.java.net, "CHRIS.HEGARTY" , "harold seigel" , "Lois Foltan" ,

RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

Hi, All Can I have a review for bug: https://bugs.openjdk.java.net/browse/JDK-8147755 Webrev: http://cr.openjdk.java.net/~minqi/8147755/webrev-01/ Summary: When fix bug 8145148 to follow: JVMS-5.4.3.3 Method Resolution: " If C is an interface, method resolution throws an Incompa

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

I function so put it in jni.cpp. This function is more like a private function. Thanks Yumin Thanks, David On 6/05/2014 9:15 AM, Yumin Qi wrote: Hi, Please have codereview for 8042243: Map shared archive to preallocated static address webrev: http://cr.openjdk.java.net/~minqi/8042243/web

RFR: 8042243: Map shared archive to preallocated static address

Hi, Please have codereview for 8042243: Map shared archive to preallocated static address webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8042243 Summary: Mapping shared archive (jsa) some time fail due to ASLR (Address space layout ran

Re: declaring class of a default method Was: Bug 8027734

Thanks. I will look back in hotspot. Yumin On 11/12/2013 6:25 AM, Joel Borggren-Franck wrote: Hi Yumin, Basically this is due to a difference in declaring class for a Method representing a default method vs a normal Method. On 2013-11-11, Yumin Qi wrote: Hi, Joel This bug is a SQE

Bug 8027734

Hi, Joel This bug is a SQE testing bug, see https://bugs.openjdk.java.net/browse/JDK-8027734 I have commented with the exception stacktrace. It only fails when defmeth set call through reflection and passed with other two modes: -mode