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
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 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
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
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 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
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 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
>
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 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 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
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 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 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 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 Thu, 27 Mar 2025 17:37:04 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
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
1 - 100 of 157 matches
Mail list logo
