On Mon, 10 Feb 2025 18:54:26 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> copyright
>
> Re dougxc: This migration is specific to the Java language. I am not so sure
> about the C++ counterparts,
On Thu, 30 Jan 2025 00:37:16 GMT, Shaojin Wen wrote:
>> The type of the Unsafe base offset constant is int, which may cause overflow
>> when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027)
>> fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are
>> st
On Fri, 13 Dec 2024 08:35:11 GMT, Volker Simonis wrote:
>> In the past, the Graal Compiler used `sun.misc.Unsafe` but these usages were
>> recently changed to `jdk.internal.misc.Unsafe` [1]. We should therefor
>> export `jdk.internal.misc` to `jdk.graal.compiler` which is an upgradeable
>> mod
On Thu, 12 Dec 2024 14:40:17 GMT, Volker Simonis wrote:
> In the past, the Graal Compiler used `sun.misc.Unsafe` but these usages were
> recently changed to `jdk.internal.misc.Unsafe` [1]. We should therefor export
> `jdk.internal.misc` to `jdk.graal.compiler` which is an upgradeable module in
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
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
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 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
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 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 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 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 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
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 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
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 Sun, 21 Apr 2024 22:00:52 GMT, Doug Simon wrote:
> This PR adds a check for the format of ProblemList files and ensures they
> only have entries referring to existing tests.
>
> The cleanups in the second commit of this PR were done based on the output of
> `CheckProblemLis
On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon wrote:
>> This PR adds a check for the format of ProblemList files and ensures they
>> only have entries referring to existing tests.
>>
>> The cleanups in the second commit of this PR were done based on the output
On Wed, 24 Apr 2024 13:14:02 GMT, Ludvig Janiuk wrote:
> While not a blocker IMO, I'm curious about the issues for the removed lines.
> Taking the first one as an example, I see it's "unresolved" (JDK-8192647) but
> the file was removed in JDK-8289764. I don't see any other mentions of
> "prob
On Sun, 21 Apr 2024 22:00:52 GMT, Doug Simon wrote:
> This PR adds a check for the format of ProblemList files and ensures they
> only have entries referring to existing tests.
>
> The cleanups in the second commit of this PR were done based on the output of
> `CheckProblemLis
cibilityTest.java 000 generic-all
>
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516:
> java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any
> test root
> java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837
> gener
On Wed, 3 Apr 2024 19:57:21 GMT, Tomáš Zezula wrote:
>> Problem:
>> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not
>> work in libjvmci because they are enabled via the
>> `jdk.internal.vm.TranslatedException.debug` system property. However,
>> HotSpot system propert
On Wed, 3 Apr 2024 13:58:23 GMT, Tomáš Zezula wrote:
>> Problem:
>> The debugging stack traces in `jdk.internal.vm.TranslatedException` do not
>> work in libjvmci because they are enabled via the
>> `jdk.internal.vm.TranslatedException.debug` system property. However,
>> HotSpot system propert
On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory`. See [this
>> PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this
>> change.
>>
>> Overall, making this an intrinsic improves overall performance of
>> `Un
On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon wrote:
> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail
> when run on libgraal and `-Xcomp` is specified. The problem is that libgraal
> in `-Xcomp` temporarily causes some extra memory pressure (probably due t
On Sun, 3 Mar 2024 17:03:51 GMT, Doug Simon wrote:
>> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail
>> when run on libgraal and `-Xcomp` is specified. The problem is that libgraal
>> in `-Xcomp` temporarily causes some extra memory pressur
On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon wrote:
> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail
> when run on libgraal and `-Xcomp` is specified. The problem is that libgraal
> in `-Xcomp` temporarily causes some extra memory pressure (probably due t
The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail
when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in
`-Xcomp` temporarily causes some extra memory pressure (probably due to
[JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which c
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote:
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
> class loader instead of the boot class loader. This allows Native Image to
> load a version of JVMCI different than the version on top of which Native
&
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on t
On Wed, 24 Jan 2024 12:16:44 GMT, xxDark wrote:
> You need to check if class is already loaded by trying findLoadedClass first.
You're right. I had forgotten the intricacies of class loader delegation. The
only hard constraint on loading a class in multiple loaders is that `java.*`
classes [mu
On Wed, 24 Jan 2024 06:11:30 GMT, David Holmes wrote:
> I'm still puzzled by the need to do this as any non-delegating classloader
> would have allowed this even if JVMCI were loaded by the bootloader.
As far as I understand, even a non-delegating classloader cannot redefine a
class loaded by
On Wed, 24 Jan 2024 06:07:55 GMT, David Holmes wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use null to denote boot class loader as delegation parent
>
> tes
On Tue, 23 Jan 2024 17:00:20 GMT, xxDark wrote:
> Passing `null` as parent class loader would suffice as boot loader just uses
> `findBootstrapClassOrNull` in `JavaLangAccess` either way
Thanks! I've simplified the test accordingly:
1642276ea22a5d789e01a5ecb1059d8c5c8be284
-
PR C
d and tested by
> `LoadAlternativeJVMCI.java`.
Doug Simon has updated the pull request incrementally with one additional
commit since the last revision:
use null to denote boot class loader as delegation parent
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17520/files
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote:
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
> class loader instead of the boot class loader. This allows Native Image to
> load a version of JVMCI different than the version on top of which Native
&
This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
class loader instead of the boot class loader. This allows Native Image to load
a version of JVMCI different than the version on top of which Native Image is
running. This capability is demonstrated and tested by
`LoadA
On Tue, 3 Oct 2023 07:47:30 GMT, Gergö Barany wrote:
> This test requires certain methods to be compiled, but without `-Xbatch` the
> compiler races against the test code, which can lead to intermittent failures.
@PaulSandoz do you see any problem with this change? Adding `-Xbatch` does not
si
On Tue, 3 Oct 2023 07:47:30 GMT, Gergö Barany wrote:
> This test requires certain methods to be compiled, but without `-Xbatch` the
> compiler races against the test code, which can lead to intermittent failures.
Marked as reviewed by dnsimon (Reviewer).
-
PR Review: https://git.o
On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee wrote:
>> Explicitly handle UpcallStub allocation failures by terminating. We
>> currently might try to use the returned `nullptr` which would fail sooner or
>> later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the p
On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon wrote:
> The Graal code base has
> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
> its module to `jdk.compiler.graal` as part of preparations for Project
> Galahad. Due to the way Java module
On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to t
On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to t
6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28)
> and so the binding fails for the new Graal module. To address this, this PR
> reflects the Graal module rena
ming, including adjusting the qualified export.
Doug Simon has updated the pull request with a new target base
On Fri, 20 Oct 2023 15:32:55 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to t
6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28)
> and so the binding fails for the new Graal module. To address this, this PR
> reflects the Graal module rena
ming, including adjusting the qualified export.
Doug Simon has updated the pull request incrementally with one addit
6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28)
> and so the binding fails for the new Graal module. To address this, this PR
> reflects the Graal module rena
ming, including adjusting the qualified export.
Doug Simon has updated the pull request incrementally with one additi
On Fri, 20 Oct 2023 14:27:43 GMT, Vladimir Kozlov wrote:
> Why you replaced pair of copyright years with one year in module-info.Java
> files? Instead of updating last year only. Why also update 'since' there?
> Even if you changed location these files existed already.
The files may be renamed
The Graal code base has
[renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
its module to `jdk.compiler.graal` as part of preparations for Project
Galahad. Due to the way Java modules work, this requires a JDK change. The core
of the issue is that the
[se
On Tue, 17 May 2022 15:53:05 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This PR updates the VM implementation of the foreign linker, by bringing
>> over commits from the panama-foreign repo.
>>
>> This is split off from the main JEP integration for 19, since we have
>> limited resources to handle t
On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic
wrote:
> The current code for cgroup support in the JDK has large and expensive
> dependencies: it uses NIO, streams, and regular expressions. This leads to
> unnecessary class loading and slows down startup, especially when the code is
> e
On Thu, 1 Jun 2023 10:25:49 GMT, Severin Gehwolf wrote:
> I'm concerned about the hard-coding of delimiter values and the added
> accidential complexity in order to avoid the Regex engine. Note that this
> test fails due to the delimiter hard-coding:
>
> ```
> jdk/internal/platform/cgroup/Test
On Thu, 10 Aug 2023 13:56:37 GMT, Doug Simon wrote:
>> In a test that stresses metaspace (such as
>> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also
>> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in
>> `Translate
On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon wrote:
> In a test that stresses metaspace (such as
> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also
> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in
> `TranslatedException.` due to ex
o be tested in libgraal. The test itself is not included as
> libgraal is not part of OpenJDK.
Doug Simon has updated the pull request incrementally with two additional
commits since the last revision:
- guard test-only code with ASSERT instead of !PRODUCT
- omit test-only code in product b
On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon wrote:
> In a test that stresses metaspace (such as
> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also
> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in
> `TranslatedException.` due to ex
In a test that stresses metaspace (such as
`vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also
uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in
`TranslatedException.` due to exhausted metaspace:
java.lang.OutOfMemoryError: Metaspace
at
jdk.internal
On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon wrote:
> This PR reduces the amount of code executed during libgraal initialization.
> This not only improves VM startup overall but all fixes a number of JDK test
> failures that are caused by Java code executing "too early". Fo
On Mon, 12 Jun 2023 18:55:42 GMT, Doug Simon wrote:
>> This PR reduces the amount of code executed during libgraal initialization.
>> This not only improves VM startup overall but all fixes a number of JDK test
>> failures that are caused by Java code executing "
user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
>
>
> (3) Eagerly initialize libgraal (
On Mon, 12 Jun 2023 03:00:23 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 one commit:
>>
>> copy system properties into libgraal more efficiently
>
>
user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
> 0.05 real 0.03 user 0.01 sys
>
>
> (3) Eagerly initialize libgraal (w
01 sys
> 0.08 real 0.07 user 0.01 sys
> 0.10 real 0.07 user 0.01 sys
> 0.08 real 0.06 user 0.01 sys
> 0.10 real 0.07 user 0.01 sys
> 0.08 real 0.07 user 0.01 sys
>
On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon wrote:
> This PR improves the startup time for libgraal by speeding up how
> `VM.savedProps` is copied into libgraal. This data structure is now
> serialized to a native buffer directly from C++ and the native buffer is then
> directl
On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung wrote:
> The `RuntimeArguments` test verifies the VM arguments returned by
> `jdk.internal.misc.VM::getRuntimeArguments` as expected.This test fails
> when running with GraalVM as it was created with `jlink --add-options` and
> the application w
On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung wrote:
> The `RuntimeArguments` test verifies the VM arguments returned by
> `jdk.internal.misc.VM::getRuntimeArguments` as expected.This test fails
> when running with GraalVM as it was created with `jlink --add-options` and
> the application w
On Wed, 7 Jun 2023 22:51:48 GMT, Doug Simon wrote:
>> This PR improves the startup time for libgraal by speeding up how
>> `VM.savedProps` is copied into libgraal. This data structure is now
>> serialized to a native buffer directly from C++ and the native buffer is
>&g
On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon wrote:
> This PR improves the startup time for libgraal by speeding up how
> `VM.savedProps` is copied into libgraal. This data structure is now
> serialized to a native buffer directly from C++ and the native buffer is then
> directl
01 sys
> 0.08 real 0.07 user 0.01 sys
> 0.10 real 0.07 user 0.01 sys
> 0.08 real 0.06 user 0.01 sys
> 0.10 real 0.07 user 0.01 sys
> 0.08 real 0.07 user 0.01 sys
>
On Mon, 5 Jun 2023 18:58:36 GMT, Tom Rodriguez wrote:
> I don't really love the hard code parsing of the HashMap. What properties are
> actually required for JVMCI? It seems to me that the contents of
> Arguments::system_properties() should contain all the properties we want to
> advertise to
On Mon, 5 Jun 2023 19:12:52 GMT, Tom Rodriguez wrote:
> This allows bin/idea.sh to properly see the JVMCI files again.
Marked as reviewed by dnsimon (Committer).
Finally ;-)
-
PR Review: https://git.openjdk.org/jdk/pull/14318#pullrequestreview-1463296723
PR Comment: https://git.op
On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon wrote:
> This PR improves the startup time for libgraal by speeding up how
> `VM.savedProps` is copied into libgraal. This data structure is now
> serialized to a native buffer directly from C++ and the native buffer is then
> directl
This PR improves the startup time for libgraal by speeding up how
`VM.savedProps` is copied into libgraal. This data structure is now serialized
to a native buffer directly from C++ and the native buffer is then directly
decoded by libgraal.
## Times
The basic benchmarking below shows that thi
On Thu, 1 Jun 2023 18:19:14 GMT, Mandy Chung wrote:
> Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would
> be more reliable in waiting for the class loader to be unloaded.
Marked as reviewed by dnsimon (Committer).
-
PR Review: https://git.openjdk.org/jd
On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson wrote:
> The current target user of the .a libraries is GraalVM, so we should check
> with them that the changes to the contents of the `.a` files isn't impacting
> them in a bad way. @dougxc what do you think?
Thanks for the heads up - I've asked
On Tue, 18 Apr 2023 07:27:47 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, 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:
> * All methods in the `Annotated` interface explicitly speci
On Tue, 18 Apr 2023 07:27:47 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 Tue, 18 Apr 2023 02:22:11 GMT, Joe Darcy wrote:
> I think the code should reject it
The `AnnotationData` constructor already has a check for unknown annotation
element types so I think this concern is covered.
> leaving some bread crumb comments to future maintainers of core reflection
> a
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
On Tue, 18 Apr 2023 01:06:31 GMT, Joe Darcy wrote:
>> Just above (line 228) you can see a call to this method where the argument
>> comes from `Map.values()` whose type is `Collection` so I'd prefer to leave
>> it as is rather than have to convert the argument to a `List`.
>
> In that case, I t
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
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
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 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 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 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
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
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
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
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 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
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'
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 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
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
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 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
1 - 100 of 133 matches
Mail list logo
