5`
>
>
> Using diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/23905.diff";>https://git.openjdk.org/jdk/pull/23905.diff
>
>
simon has updated the pull request incrementally with one additional commit
since the
On Mon, 28 Apr 2025 20:04:22 GMT, Chen Liang wrote:
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
>> another possible cause of a NullPointerException - when the exception
>> supplying function returns a null result.
>> -
>> ### Progress
>> - [ ] Change mus
On Wed, 26 Mar 2025 00:21:38 GMT, Chen Liang wrote:
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
>> another possible cause of a NullPointerException - when the exception
>> supplying function returns a null result.
>> -
>> ### Progress
>> - [ ] Change mus
On Mon, 28 Apr 2025 20:04:22 GMT, Chen Liang wrote:
>> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
>> another possible cause of a NullPointerException - when the exception
>> supplying function returns a null result.
>> -
>> ### Progress
>> - [ ] Change mus
On Tue, 4 Mar 2025 16:34:19 GMT, simon wrote:
> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
> another possible cause of a NullPointerException - when the exception
> supplying function returns a null result.
> -
> ### Progress
> -
On Tue, 4 Mar 2025 16:34:19 GMT, simon wrote:
> Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
> another possible cause of a NullPointerException - when the exception
> supplying function returns a null result.
> -
> ### Progress
> -
Javadoc for java.util.Optional.orElseThrow(Supplier) misses mentioning of
another possible cause of a NullPointerException - when the exception supplying
function returns a null result.
-
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1
[Reviewer](h
On Mon, 28 Apr 2025 14:32:59 GMT, Christoph Langer wrote:
>> Thank you all for the help. Let's wait for the OCA verify process. Happy to
>> contribute to Java. 😀
>
> @gustavosimon Now the oca seems to be approved and the CSR is progressing.
> Can you update your change to match the exact specif
On Tue, 4 Mar 2025 16:45:22 GMT, simon wrote:
> @robilad As you asked, I have already sent you an e-mail verify my OCA. I
> will need for this PR. Cheers, looking forward! 😀
@robilad Any luck into this matter?
-
PR Comment: https://git.openjdk.org/jdk/pull/23905#issuec
On Mon, 28 Apr 2025 17:44:31 GMT, Benjamin Peterson wrote:
>> This issue has the "oca" label so we cannot engage, sorry.
>
>> This issue has the "oca" label so we cannot engage, sorry.
>
> Ah, sorry. I only asked because I saw a colleague of yours helping out with
> OCA verification over at
>
8360122: Refine formatting of Connection.java interface
-
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1
[Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issu
On Sun, 22 Jun 2025 01:13:26 GMT, simon wrote:
> 8360122: Refine formatting of Connection.java interface
>
> -
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1
> [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Ch
On Mon, 23 Jun 2025 14:51:44 GMT, Chen Liang wrote:
> FYI people don't usually review on weekends (you opened this PR in a weekend)
> or holidays. This PR is sent to core-libs-dev list so people will eventually
> see and review it.
Great, @liach! Thanks for the information! 😄
-
P
On Mon, 23 Jun 2025 14:50:24 GMT, Roger Riggs wrote:
> The indentation fixes look ok. The reformatting of declarations seem
> unnecessary and create lines that are longer than desirable to be able to do
> side-by-side compares (100 char max). Generally, avoid just asking the IDE to
> re-format
On Mon, 23 Jun 2025 14:50:24 GMT, Roger Riggs wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: refactor code formatting to enforce 100 chars line length limit
>> for improved r
g diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/25925.diff";>https://git.openjdk.org/jdk/pull/25925.diff
>
>
> Using Webrev
>
> [Link to Webrev
> Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993
g diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/25925.diff";>https://git.openjdk.org/jdk/pull/25925.diff
>
>
> Using Webrev
>
> [Link to Webrev
> Comment](https://git.openjdk.org/jdk/pull/25925#issuecomme
On Mon, 23 Jun 2025 17:35:50 GMT, Roger Riggs wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: refactor code formatting to enforce 100 chars line length limit
>> for improved read
g diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/25925.diff";>https://git.openjdk.org/jdk/pull/25925.diff
>
>
> Using Webrev
>
> [Link to Webrev
> Comment](https://git.openjdk.org/jdk/pull/25925#issuecomme
On Mon, 23 Jun 2025 19:54:24 GMT, Roger Riggs wrote:
>> @RogerRiggs My preferred formatting style is like this:
>>
>>
>> default boolean setShardingKeyIfValid(ShardingKey shardingKey,
>> ShardingKey superShardingKey,
>>
On Wed, 2 Jul 2025 14:37:04 GMT, Lance Andersen wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: revert reformatting method signatures
>
> src/java.sql/share/classes/java/sql/Conne
On Wed, 2 Jul 2025 15:14:47 GMT, Lance Andersen wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: revert reformatting method signatures
>
> src/java.sql/share/classes/java/sql/Connect
g diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/25925.diff";>https://git.openjdk.org/jdk/pull/25925.diff
>
>
> Using Webrev
>
> [Link to Webrev
> Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2
On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: refactor code formatting to enforce 100 chars line length limit
>> for improved rea
On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen wrote:
>> simon has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8360122: refactor code formatting to enforce 100 chars line length limit
>> for improved rea
g diff file
>
> Download this PR as a diff file: \
> href="https://git.openjdk.org/jdk/pull/25925.diff";>https://git.openjdk.org/jdk/pull/25925.diff
>
>
> Using Webrev
>
> [Link to Webrev
> Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment
On Tue, 8 Jul 2025 18:53:08 GMT, Lance Andersen wrote:
>> It was just a suggestion, but it’s not really related to the main change. I
>> can undo it if you think it’s appropriate
>
> Please revert this change
Fixed
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discus
On Wed, 9 Jul 2025 19:38:21 GMT, Chen Liang wrote:
>>> The changes are OK.
>>
>> Great, @LanceAndersen! Thanks for reviewing. 😃
>>
>> Can you integrate it when you think it is appropriate? I guess I do not have
>> permission to do it.
>
>> Can you integrate it when you think it is appropriate
On Wed, 9 Jul 2025 18:59:49 GMT, Lance Andersen wrote:
> The changes are OK.
Great, @LanceAndersen! Thanks for reviewing. 😃
Can you integrate it when you think it is appropriate? I guess I do not have
permission to do it.
-
PR Comment: https://git.openjdk.org/jdk/pull/25925#issu
On Sun, 22 Jun 2025 01:13:26 GMT, simon wrote:
> 8360122: Refine formatting of Connection.java interface
>
> -
> ### Progress
> - [x] Change must be properly reviewed (1 review required, with at least 1
> [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Ch
On Sun, 20 Jul 2025 23:36:53 GMT, Chen Liang wrote:
> > I think we should create some unit tests for this API and classes involved.
> > Where do you think that is the most appropriate location in the project to
> > do it?
>
> Unit tests for `java.lang.classfile` reside in `test/jdk/jdk/classfi
On Sun, 20 Jul 2025 22:19:07 GMT, simon wrote:
> 8355652: add new method to return ClassFileFormatVersion from
> ClassFileVersion.
> -
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1
> [Reviewer](https://openjdk.org/bylaws
8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
-
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1
[Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit messag
On Mon, 21 Jul 2025 00:11:20 GMT, Chen Liang wrote:
>> 8355652: add new method to return ClassFileFormatVersion from
>> ClassFileVersion.
>> -
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1
>> [Reviewer](https://openjdk.org/bylaws#reviewer)
This PR addresses intermittent failures in jtreg GC stress tests. The failures
occur under these conditions:
1. Using a libgraal build with assertions enabled as the top tier JIT compiler.
Such a libgraal build will cause a VM exit if an assertion or GraalError occurs
in a compiler thread (as th
On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote:
> This PR addresses intermittent failures in jtreg GC stress tests. The
> failures occur under these conditions:
> 1. Using a libgraal build with assertions enabled as the top tier JIT
> compiler. Such a libgraal build will cause
aal needs to be able to distinguish a GraalError
> caused by an OOME. This PR modifies the exception translation code to make
> this possible.
Doug Simon has updated the pull request incrementally with one additional
commit since the last revision:
fixed TestTranslatedException
---
On Tue, 9 Jul 2024 14:37:47 GMT, Yudi Zheng wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed TestTranslatedException
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 782
On Wed, 10 Jul 2024 06:19:52 GMT, David Holmes wrote:
>> Though I see this is inconsistent with `Exceptions::_throw_msg_cause`
>
> Okay I think I see how the logic works. If we were going to abort we would
> never reach `_throw_cause` as the initial `_throw` would have exited. But for
> the `!t
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote:
>> This PR addresses intermittent failures in jtreg GC stress tests. The
>> failures occur under these conditions:
>> 1. Using a libgraal build with assertions enabled as the top tier JIT
>> compiler. Such a libgraal bu
On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote:
> This PR addresses intermittent failures in jtreg GC stress tests. The
> failures occur under these conditions:
> 1. Using a libgraal build with assertions enabled as the top tier JIT
> compiler. Such a libgraal build will cause
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926)
is fixed to reduce the noise in testing.
-
Commit messages:
- Problem list jdk/internal/util/ReferencedKeyTest.java
Changes: https://git.openjdk.org/jdk/pull/20488/files
Webrev: https://webrevs.openjdk.
On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon wrote:
> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926)
> is fixed to reduce the noise in testing.
Great, thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/20488#issuecomment-2275017545
On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon wrote:
> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926)
> is fixed to reduce the noise in testing.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/20488
This PR adds a new jlink plugin (`--copy-files=`) that copies
specified files from the current image into the output image.
This is useful in the context of GraalVM where libgraal (e.g.
`lib/libjvmcicompiler.so`) is produced after the final jlink step in the
GraalVM JDK build process. The plugin
On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon wrote:
> This PR adds a new jlink plugin (`--copy-files=`) that copies
> specified files from the current image into the output image.
> This is useful in the context of GraalVM where libgraal (e.g.
> `lib/libjvmcicompiler.so`) is produc
On Tue, 27 Sep 2022 19:11:07 GMT, Mandy Chung wrote:
>> This PR adds a new jlink plugin (`--save-jlink-argfiles=`) to
>> support persisting jlink options.
>>
>>
>>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy
>>> --vendor-version="XyzzyVM 3.14.15"
>>> --vendor-bug-url=ht
/bugs.xyzzy.com/
> java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_ima
/bugs.xyzzy.com/
> java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_ima
/bugs.xyzzy.com/
> java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build
> 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_ima
On Tue, 27 Sep 2022 22:38:48 GMT, Mandy Chung wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> SaveJlinkArgfilesPlugin should verify that jdk.jlink is in the output image
>
> Looks
On Tue, 27 Sep 2022 11:12:57 GMT, Doug Simon wrote:
> This PR adds a new jlink plugin (`--save-jlink-argfiles=`) to
> support persisting jlink options.
>
>
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy
>> --vendor-version="Xyzzy
On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon wrote:
> This PR adds a new jlink plugin (`--copy-files=`) that copies
> specified files from the current image into the output image.
> This is useful in the context of GraalVM where libgraal (e.g.
> `lib/libjvmcicompiler.so`) is produc
Libgraal is compiled ahead of time and should not need any JVMCI Java code to
be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
* Code to copy system properties from the HotSpot heap into the libgraal heap.
This is in `jdk.vm.ci.services.Services.initializeSavedPro
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request incrementally with one addition
On Mon, 5 Dec 2022 13:32:38 GMT, Alan Bateman wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> generalized ClassLoader::has_jvmci_module to is_module_resolvable
>
> src/hotspot/share/
On Mon, 5 Dec 2022 13:49:28 GMT, Doug Simon wrote:
>> Libgraal is compiled ahead of time and should not need any JVMCI Java code
>> to be dynamically loaded at runtime. Prior to this PR, this is not the case
>> due to:
>>
>> * Code to copy system properties
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request incrementally with one additiona
On Mon, 5 Dec 2022 15:58:19 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/classLoader.hpp line 378:
>>
>>> 376:
>>> 377: // Determines if the `module_name` module is resolvable.
>>> 378: static bool is_module_resolvable(const char* module_name);
>>
>> Is "resolvable" the right co
On Mon, 5 Dec 2022 17:17:16 GMT, Doug Simon wrote:
>> Assuming --limit-modules isn't used, it is testing if the module is
>> "observable".
>
> I assume this function should therefore be named `is_module_observable`?
How about this:
// Determines if t
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request incrementally with one additional
comm
On Tue, 6 Dec 2022 05:28:24 GMT, David Holmes wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> renamed is_module_resolvable to is_module_observable
>
> src/hotspot/share/jvmci/jvmci.c
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request incrementally with two additional
co
On Tue, 6 Dec 2022 13:02:40 GMT, Alan Bateman wrote:
>> Doug Simon has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - incorporate review feedback [skip ci]
>> - removed hard-coded module name [skip ci]
&
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request incrementally with four additional
comm
On Tue, 6 Dec 2022 15:41:20 GMT, Doug Simon wrote:
>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
>>
>>> 64: * only contains String keys and values.
>>> 65: */
>>> 66: private static byte[] seri
On Wed, 7 Dec 2022 18:42:43 GMT, Alan Bateman wrote:
>> Doug Simon has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - formatting to avoid very long lines [skip ci]
>> - removed debug code [skip ci]
>
graal but does not include
> `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces
> footprint and better isolates the JAVMCI and the Graal compiler as accessing
> these components from Java code is now impossible.
Doug Simon has updated the pull request with a new target base due to a mer
On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon wrote:
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to
> be dynamically loaded at runtime. Prior to this PR, this is not the case due
> to:
>
> * Code to copy system properties from the HotSpot heap in
On Wed, 7 Dec 2022 19:49:47 GMT, Doug Simon wrote:
>> Libgraal is compiled ahead of time and should not need any JVMCI Java code
>> to be dynamically loaded at runtime. Prior to this PR, this is not the case
>> due to:
>>
>> * Code to copy system properties
On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 wrote:
> The enanchment is useful for applications that make heavy use of BitSet
> objects as sets of integers, and therefore they need to make a lot of calls
> to cardinality() method, which actually require linear time in the number of
> words in
On Wed, 11 Jan 2023 16:02:40 GMT, Sergey Kuksenko wrote:
> It would be better to see benchmark results other than cardinality operation.
> To understand how big performance regression is.
Agreed - I suspect this is adding unnecessary overhead to the most common uses
of BitSet; I'd be tempted t
On Tue, 6 Dec 2022 21:14:07 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 71 commits:
>
> - Merge from JDK mainline
> - Add comment
> - Merge https://github.
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
> That said, I think it is reasonable on a given JVM invocation if
> Float.floatToFloat16(f) gave the same result for input f regardless of in
> what context it was called.
Yes, I'm under the impression that for math API methods like this, the
This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing
annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
* Each `Annotated` method explicitly specifies the annotation type(s) for which
it wants annotation data. That is, there is no direct equi
JDK-8297431 added code for special handling of OutOfMemoryError when
translating an exception between libjvmci and HotSpot[1].
Unfortunately, this code was deleted by JDK-8298099 when moving the exception
translation mechanism to VMSupport[2].
This causes the VM to crash when an OOME occurs while
t; -> LoopExplosionKind.FULL_UNROLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/deseriali
t; -> LoopExplosionKind.FULL_UNROLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/dese
On Fri, 3 Mar 2023 18:05:51 GMT, Vladimir Kozlov wrote:
>> JDK-8297431 added code for special handling of OutOfMemoryError when
>> translating an exception between libjvmci and HotSpot[1].
>> Unfortunately, this code was deleted by JDK-8298099 when moving the
>> exception translation mechanism
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon
On Sun, 5 Mar 2023 22:37:38 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * Each `Annotated` method explicitly specifi
On Wed, 1 Mar 2023 18:07:34 GMT, Doug Simon wrote:
> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing
> annotations. The main differences from `java.lang.reflect.AnnotatedElement`
> are:
> * Each `Annotated` method explicitly specifies the annotation
t; -> LoopExplosionKind.FULL_UNROLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/dese
t; -> LoopExplosionKind.FULL_UNROLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/deseriali
On Mon, 13 Mar 2023 19:23:39 GMT, Vladimir Kozlov wrote:
>> Doug Simon has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge remote-tracking branch 'openjdk-jdk/master'
On Tue, 14 Mar 2023 06:28:20 GMT, Tom Rodriguez wrote:
>> Doug Simon has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge remote-tracking branch 'openjdk-jdk/master' into
t; -> LoopExplosionKind.FULL_UNROLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/dese
On Tue, 14 Mar 2023 16:06:06 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface expl
On Wed, 15 Mar 2023 19:23:52 GMT, Joe Darcy wrote:
> I assume https://bugs.openjdk.org/browse/JDK-8303431 recounts the motivation
> behind this change?
Yes, it does. Thanks in advance.
-
PR: https://git.openjdk.org/jdk/pull/12810
OLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/deserializing to/from a byt
Agreed, I believe there should be an hb relationship with this, if the
target is not alive.
On Mon, Apr 3, 2023, 04:50 Quan Anh Mai wrote:
> On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>
> >> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will
On Mon, 17 Apr 2023 15:48:53 GMT, Joe Darcy wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSu
On Mon, 17 Apr 2023 15:32:56 GMT, Joe Darcy wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSu
On Mon, 17 Apr 2023 20:33:26 GMT, Doug Simon wrote:
>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>>
>>> 232: * Encodes a list of annotations to a byte array. The byte array
>>> can be decoded with {@link #decodeAnnotations(byte[]
On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy wrote:
> From the long-term perspective, it is likely that the set of kinds of
> elements that can occur in an annotation will be expanded, for example,
> method references are a repeated request. Easing future maintenance to gives
> more inter-sourc
On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy wrote:
> the methods should phrase their operations in terms of these concepts...
I think this is what you're suggesting:
https://github.com/openjdk/jdk/pull/12810/commits/362738a61410cc8d60d8c4c4fc9e3e8ed0393aed
-
PR Comment: https://gi
OLL;
> case "FULL_UNROLL_UNTIL_RETURN" ->
> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
> ...
> }
>
>
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for
> parsing annotations and serializing/deserializing to/from a byte ar
1 - 100 of 171 matches
Mail list logo
