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
>
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
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
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
>>
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 pres
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
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
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
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
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
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:
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
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
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
b8eb/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 due t
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
b8eb/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 additional
b8eb/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 additional
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
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
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
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
>
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:
>
> ```
>
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
>> `TranslatedExce
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 exhaust
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 build
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 exhaust
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
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 libgra
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
> dire
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
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
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
> dire
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:
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
> dire
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
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:
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
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
>
gt; 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/deserializing to/from a byte arr
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
gt; 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/deserializing to/from a byte array.
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:
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
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
gt; 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/deserializing to/from a byte arr
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
gt; 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 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 JDK-83034
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' into JD
gt; 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
gt; 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 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 annot
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 wrote
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
gt; 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
gt; 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
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
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
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,
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
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 pr
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
raal 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 merge
o
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]
>
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
raal 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
commits s
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]
&
raal 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
commits
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
raal 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
commit
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
1 - 100 of 115 matches
Mail list logo
