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 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 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 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
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 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
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
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 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 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 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 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
>
or.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_image2/bin/java -d jdk.internal.vm.ci
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
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=https://bugs.xyzzy.com/;
> > my_image.argfile
> export ALL_MODULES=$(java
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"
>>>
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 pr
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 pr
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
or.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_image2/bin/java -d jdk.internal.vm.ci
or.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_image2/bin/java -d jdk.internal.vm.ci
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 four additional
commits s
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]
>
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 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 pr
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
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
c
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 pr
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 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
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 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
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
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, 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
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
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 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 wrote
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 annot
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
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,
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
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
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 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
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 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:
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 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 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 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 arr
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
>
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 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 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 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 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 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
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, 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
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 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 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
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
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 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 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 "
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 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 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 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 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 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 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
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
1 - 100 of 115 matches
Mail list logo