RFR: 8266291: (jrtfs) Calling Files.exists may break the JRT filesystem

Problematic paths that start with /modules/modules prefix are handled properly - Commit messages: - fixed typos in comments - 8266291: (jrtfs) Calling Files.exists may break the JRT filesystem Changes: https://git.openjdk.java.net/jdk/pull/4022/files Webrev:

Re: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2 [v4]

> This bug was discovered during the development of > [JDK-6824466](https://bugs.openjdk.java.net/browse/JDK-6824466): when CDS is > enabled, if `BootLoader::loadClassOrNull` is called before `initPhase2`, it > would trigger the initialization of the archived module graph in the wrong > order.

Re: RFR: 8254598: StringDedupTable should use OopStorage [v4]

On Fri, 14 May 2021 04:31:59 GMT, Kim Barrett wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >>

Re: RFR: 8254598: StringDedupTable should use OopStorage [v4]

> Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by

RFR: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems

Looks like it is similar to JDK-8236282, except for "hdiutil create". Based on call stack from failed test we launched "hdiutil create" and were waiting for it to terminate while reading output from it. However, based on process dump from machine which reproduced this issue, hdiutil no longer

Re: RFR: 8266310: deadlock while loading the JNI code

On 14/05/2021 7:20 am, Mandy Chung wrote: On 5/13/21 6:05 AM, David Holmes wrote: Not every problem has a solution :) If JNI_OnLoad has to execute atomically with respect to loading a library then there will always be a deadlock potential. The only complete solution would not hold a lock

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3]

On Thu, 13 May 2021 23:07:07 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 >> (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 >> on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

On Thu, 13 May 2021 18:16:23 GMT, Mandy Chung wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > There are a few tests with `--illegal-access=deny`

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3]

> Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementally with one

Re: RFR: 8254598: StringDedupTable should use OopStorage [v2]

On Wed, 12 May 2021 11:55:08 GMT, Thomas Schatzl wrote: >> Kim Barrett has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - more comment improvements >> - improve naming and comments around injected String flags >> - fix some typos in

Re: RFR: 8254598: StringDedupTable should use OopStorage [v3]

> Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by

Re: RFR: 8254598: StringDedupTable should use OopStorage [v2]

On Wed, 12 May 2021 21:13:54 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - more comment improvements >> - improve naming and comments around injected String flags >> - fix some

Re: [External] : Re: ReversibleCollection proposal

- Mail original - > De: "Anthony Vanelverdinghe" > À: "Remi Forax" > Cc: "Stuart Marks" , "core-libs-dev" > > Envoyé: Jeudi 13 Mai 2021 21:18:22 > Objet: Re: [External] : Re: ReversibleCollection proposal > Hi Rémi > > The discussion "new types? or new default methods?" is indeed a

Re: RFR: 8266310: deadlock while loading the JNI code

On 5/13/21 6:05 AM, David Holmes wrote: Not every problem has a solution :) If JNI_OnLoad has to execute atomically with respect to loading a library then there will always be a deadlock potential. The only complete solution would not hold a lock while JNI_OnLoad is executed, but that

Re: Proposal for new interface: TimeSource

On Wed, 12 May 2021 at 18:41, Roger Riggs wrote: > Will you be posting a PR for the implementation? > It is frequently helpful to evaluate the CSR and the implementation > concurrently. PR: https://github.com/openjdk/jdk/pull/4016 Issue: https://bugs.openjdk.java.net/browse/JDK-8266846 CSR:

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v4]

On Thu, 13 May 2021 20:38:20 GMT, Lance Andersen wrote: >> HI all, >> >> Please review the fix to HashesTest.java to support running on TestNG 7.4. >> >> The fix adds a no-arg constructor which TestNG requires. >> >> The change allows the test to run with the current jtreg as well as the

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v4]

> HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the > upcoming jtreg > > > Best > Lance Lance Andersen has updated

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass

Maybe you were thinking `jdk.internal.reflect.ReflectUtil::isVMAnonymousClass` that is now removed by this patch [1]. [1] https://github.com/openjdk/jdk/pull/3974/files#diff-1af3026a3b4942af3ebe6a4df02f8952fb9d51bf93336a2f7f93ce175d047574 On 5/13/21 12:03 PM, Brian Goetz wrote: Thanks for

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v3]

On Thu, 13 May 2021 18:53:25 GMT, Mandy Chung wrote: >> Lance Andersen has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update copyright typo > > test/jdk/tools/jmod/hashes/HashesTest.java line 90: > >> 88: } >> 89:

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v2]

On Thu, 13 May 2021 18:26:52 GMT, Lance Andersen wrote: >> HI all, >> >> Please review the fix to HashesTest.java to support running on TestNG 7.4. >> >> The fix adds a no-arg constructor which TestNG requires. >> >> The change allows the test to run with the current jtreg as well as the

Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview)

On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for > switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: >

Re: ReversibleCollection proposal

Hi Stuart Will EnumSet also be updated to implement ReversibleSet? Or will it be updated to implement NavigableSet [1] independently of this enhancement? I'd also like to propose adding `ReversibleSet::of` factory methods. This is something I miss having on SortedSet occasionally, but

Re: [External] : Re: ReversibleCollection proposal

Hi Rémi The discussion "new types? or new default methods?" is indeed a valid one. In fact, I think this choice has already been made once in favor of a default method, when adding `List::sort` was chosen over adding `SortedList` (though I imagine that choice was a no-brainer). In this case I

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass

Thanks for checking.  I thought I remembered something like this somewhere, but it may be that you already fixed such tests when you did hidden classes?  In any case, seems like we're all good now. Cheers, -Brian On 5/13/2021 2:50 PM, Mandy Chung wrote: I did a search on java.base and the

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v3]

On Thu, 13 May 2021 18:37:21 GMT, Lance Andersen wrote: >> HI all, >> >> Please review the fix to HashesTest.java to support running on TestNG 7.4. >> >> The fix adds a no-arg constructor which TestNG requires. >> >> The change allows the test to run with the current jtreg as well as the

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass

I did a search on java.base and the tests on `String::indexOf` and `String::contains` of a slash and don't spot any such test.  The JDK has no use of VM anonymous class.   If the test is trying to determine if it's lambda proxy class, it should be converted to call `Class::isHidden` but

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v3]

> HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the > upcoming jtreg > > > Best > Lance Lance Andersen has updated

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 10:49:21 GMT, Lance Andersen wrote: > HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the >

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods [v2]

> HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the > upcoming jtreg > > > Best > Lance Lance Andersen has updated

Re: JEP draft: Scope Locals

Em qui., 13 de mai. de 2021 às 13:36, Alan Snyder escreveu: > >> Is this a common practice? Doesn’t it point to a deficiency in the > library API? > > > > Not necessarily. For example, say you want to give access to a particular > > resource (a log stream, say) to trusted callees. Nobody AFAIK

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

On Thu, 13 May 2021 18:11:30 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 >> (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 >> on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

On Thu, 13 May 2021 17:37:42 GMT, Harold Seigel wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > src/hotspot/share/runtime/arguments.cpp line

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

> Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementally with one

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

On Thu, 13 May 2021 17:14:36 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64.

RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on {linux,macos,windows}-x64 and {linux,macos}-aarch64. - Commit messages: - 8266851: Implement JEP 403: Strongly

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 10:49:21 GMT, Lance Andersen wrote: > HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the >

Integrated: 8266162: Remove JPackage duplicate tests

On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk wrote: > 8266162: Remove JPackage duplicate tests This pull request has now been integrated. Changeset: f3c6cda4 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/f3c6cda47631cc123dbcddbfb627dc05cf7bc13b Stats:

Integrated: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11

On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. This pull request has now been integrated. Changeset: a259ab4a Author:Naoto Sato URL:

Re: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v2]

> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in > the following cases: > > 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= > this.length()` >The original implementation throws `ArrayIndexOutOfBoundsException` but > this case should

Re: JEP draft: Scope Locals

> On May 13, 2021, at 2:03 AM, Andrew Haley wrote: > > On 5/12/21 8:12 PM, Alan Snyder wrote: >> From the motivation section: >> >>> So you want to invoke a method |X| in a library that later calls back into >>> your code. In your callback you need some context, perhaps a transaction ID

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 11:24:34 GMT, Chris Hegarty wrote: > The non-static state in this test class is initialized for each of the static > testXXX scenarios. An alternative could be to move said state (four fields) > into a static inner class, and have each of the testXXX scenarios create an >

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 11:11:23 GMT, Alan Bateman wrote: >> HI all, >> >> Please review the fix to HashesTest.java to support running on TestNG 7.4. >> >> The fix adds a no-arg constructor which TestNG requires. >> >> The change allows the test to run with the current jtreg as well as the >>

Re: Fuzzing the Java core libs

On Thu, May 13, 2021 at 1:22 PM Alan Bateman wrote: > The workflow is shown on the Vulnerability Group page [1]. There isn't a > repo that you can test commits on before the publication date. > > -Alan > > [1] https://openjdk.java.net/groups/vulnerability/ > Based on the information on that

Integrated: JDK-8266552 Technical corrections to java/util/random/package-info.java

On Wed, 5 May 2021 12:41:50 GMT, Jim Laskey wrote: > The author (Guy Steele) of https://bugs.openjdk.java.net/browse/JDK-8193209 > with others have post-integration reviewed commentary (javadoc) and has > submitted technical corrections. This pull request has now been integrated. Changeset:

Re: RFR: 8266310: deadlock while loading the JNI code

Hi Aleksei, On 13/05/2021 9:54 pm, Aleksei Voitylov wrote: Hi David, On 12/05/2021 10:56, David Holmes wrote: Hi Aleksei, On 11/05/2021 11:19 pm, Aleksei Voitylov wrote: Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated

Re: RFR: 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0() [v2]

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and > https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class` > expressions like > > String str = baseName.replace('.', '/') + '/' + name; > > are not compiled into invokedynamic-based code, but into one

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]

On Thu, 13 May 2021 12:31:44 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). >> The change removes dAC relevant code and changes a lot of tests. Many of >> the changed tests need renaming. I hope to do this in a follow up RFE. >> Some

Integrated: 8243287: Removal of Unsafe::defineAnonymousClass

On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel wrote: > Please review this large change to remove Unsafe::defineAnonymousClass(). > The change removes dAC relevant code and changes a lot of tests. Many of the > changed tests need renaming. I hope to do this in a follow up RFE. Some of >

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]

On Thu, 13 May 2021 07:19:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix Weak hidden comment > > src/hotspot/share/oops/constantPool.hpp line 493: > >> 491: // object into a

Re: RFR: 8266162: Remove JPackage duplicate tests

On Wed, 12 May 2021 20:34:08 GMT, Alexey Semenyuk wrote: > 8266162: Remove JPackage duplicate tests Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4003

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]

On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> test changes and small fixes > > src/hotspot/share/classfile/classLoaderData.cpp line 299: > >> 297: } >> 298: >>

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]

> Please review this large change to remove Unsafe::defineAnonymousClass(). > The change removes dAC relevant code and changes a lot of tests. Many of the > changed tests need renaming. I hope to do this in a follow up RFE. Some of > the tests were modified to use hidden classes, others

Re: RFR: 8266310: deadlock while loading the JNI code

Hi David, On 12/05/2021 10:56, David Holmes wrote: > Hi Aleksei, > > On 11/05/2021 11:19 pm, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between >> the two lock objects - a lock object associated with the class being >> loaded, and the

Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available

Okay, that makes sense. Thanks for clarifying. Greetings, Michael Am 13. Mai 2021 00:45:13 MESZ schrieb Claes Redestad : >Hi, > >I gave this some thought the other day when looking at one of Sergey's >patches. > >I'm no expert on javac but I think translating to String::concat is >likely to be

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 10:49:21 GMT, Lance Andersen wrote: > HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the >

Re: Fuzzing the Java core libs

On 13/05/2021 10:37, Fabian Meumertzheim wrote: OSS-Fuzz files bugs in a Monorail instance (of https://bugs.chromium.org fame), which can be used to

Re: RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

On Thu, 13 May 2021 10:49:21 GMT, Lance Andersen wrote: > HI all, > > Please review the fix to HashesTest.java to support running on TestNG 7.4. > > The fix adds a no-arg constructor which TestNG requires. > > The change allows the test to run with the current jtreg as well as the >

Re: RFR: 8266310: deadlock while loading the JNI code

On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov wrote: > Please review this PR which fixes the deadlock in ClassLoader between the two > lock objects - a lock object associated with the class being loaded, and the > ClassLoader.loadedLibraryNames hash map, locked during the native library

RFR: 8266461: tools/jmod/hashes/HashesTest.java fails: static @Test methods

HI all, Please review the fix to HashesTest.java to support running on TestNG 7.4. The fix adds a no-arg constructor which TestNG requires. The change allows the test to run with the current jtreg as well as the upcoming jtreg Best Lance - Commit messages: - Remove

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v19]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v19]

On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v18]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: Fuzzing the Java core libs

OSS-Fuzz files bugs in a Monorail instance (of https://bugs.chromium.org fame), which can be used to discuss the issues, but of course doesn't have to be. Authentication to that Monorail instance as well as to oss-fuzz.com, which provides additional information on findings and fuzzer performance,

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v17]

> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull

Re: JEP draft: Scope Locals

On 5/12/21 8:12 PM, Alan Snyder wrote: > From the motivation section: > >> So you want to invoke a method |X| in a library that later calls back into >> your code. In your callback you need some context, perhaps a transaction ID >> or some |File| instances. However, |X| provides no way to pass

Integrated: 8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers"

On Wed, 12 May 2021 15:48:16 GMT, Daniel Fuchs wrote: > ParentLoggersTest.java has been (rarely) seen failing with "checkLoggers: > getLoggerNames() returned unexpected loggers" > The suspicion is that there might be some possible interaction with other > tests running in the same VM. This

Re: RFR: 8266310: deadlock while loading the JNI code

On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov wrote: > Please review this PR which fixes the deadlock in ClassLoader between the two > lock objects - a lock object associated with the class being loaded, and the > ClassLoader.loadedLibraryNames hash map, locked during the native library

Re: Fuzzing the Java core libs

On 13/05/2021 09:14, Fabian Meumertzheim wrote: I'm one of the maintainers of Jazzer ( https://github.com/CodeIntelligenceTesting/jazzer), a new open-source fuzzer for the JVM platform. Jazzer has recently been integrated into Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for

Fuzzing the Java core libs

I'm one of the maintainers of Jazzer ( https://github.com/CodeIntelligenceTesting/jazzer), a new open-source fuzzer for the JVM platform. Jazzer has recently been integrated into Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free continuous fuzzing of important open-source

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). >> The change removes dAC relevant code and changes a lot of tests. Many of >> the changed tests need renaming. I hope to do this in a follow up RFE. >> Some

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]

On Tue, 11 May 2021 14:11:22 GMT, Harold Seigel wrote: >> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? >> It may minimally need a comment to be updated. That's the only additional >> test that I could find in test/jdk. > > Hi Alan, > Thanks for find this. I

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). >> The change removes dAC relevant code and changes a lot of tests. Many of >> the changed tests need renaming. I hope to do this in a follow up RFE. >> Some

Re: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2 [v3]

On Wed, 12 May 2021 21:03:27 GMT, Ioi Lam wrote: >> This bug was discovered during the development of >> [JDK-6824466](https://bugs.openjdk.java.net/browse/JDK-6824466): when CDS is >> enabled, if `BootLoader::loadClassOrNull` is called before `initPhase2`, it >> would trigger the

Re: RFR: 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2 [v2]

On Wed, 12 May 2021 22:20:53 GMT, Mandy Chung wrote: >> How about the latest version (4cd981c)? I removed the `archivedClassLoaders` >> argument; this also makes the callers simpler. > > Looks good to me. This makes it simpler and much nicer - thank you! - PR:

Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available

> Before we start to change every usage of String+String into String.concat, > shouldn't the compiler be so smart to do that for us? > Currently it compiles to invokedynamic if available and to using > StringBuilder otherwise. Now why doesn't it compile to String.concat instead > of

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v16]

On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore wrote: >> src/hotspot/share/runtime/sharedRuntime.hpp line 465: >> >>> 463: static void restore_native_result(MacroAssembler *_masm, BasicType >>> ret_type, int frame_slots); >>> 464: >>> 465: static void move32_64(MacroAssembler*