On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote:
> This PR modifies the GitHub Actions product build on Linux to include
> building of the static-libs bundle.
> This is a minimal smoke test to ensure these builds don't break.
This pull request has now been integrated.
Chang
On Tue, 3 Sep 2024 16:15:33 GMT, Erik Joelsson wrote:
>> This PR modifies the GitHub Actions product build on Linux to include
>> building of the static-libs bundle.
>> This is a minimal smoke test to ensure these builds don't break.
>
> I think adding static libs to one platform and flavor comb
On Mon, 2 Sep 2024 11:01:00 GMT, Magnus Ihse Bursie wrote:
>> This PR modifies the GitHub Actions product build on Linux to include
>> building of the static-libs bundle.
>> This is a minimal smoke test to ensure these builds don't break.
>
> Also, you might not be aware of this, but I am workin
This PR modifies the GitHub Actions' linux product build to include building of
the static-libs bundle as a minimal smoke test that these builds don't break.
-
Commit messages:
- build static-libs on linux
Changes: https://git.openjdk.org/jdk/pull/20803/files
Webrev: https://webr
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
`CheckProblemLists`:
> make test TEST=build/problemLists/CheckProblemLists.java
...
STDOUT:
Chec
On Thu, 22 Feb 2024 09:46:00 GMT, Magnus Ihse Bursie wrote:
> However, I interpret your comment as that it is possible to remove the
> JNIEXPORT from these functions in a follow-up PR. And that is good to know!
I believe you're right. In any case, most of the JVMCI tests will fail if
JNIEXPORT
On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes wrote:
> The Graal folk will need to chime in here as it may be that these are needed
> for libgraal.
They should be fine. JNI linkage is only used by the native methods in
`CompilerToVM.java`.
-
PR Comment: https://git.openjdk.org/j
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 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 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 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 Fri, 3 Mar 2023 17:47:20 GMT, Doug Simon wrote:
> The layout of the sources in `jdk.internal.vm.ci` stems from their initial
> development outside the JDK where they adopted a layout influenced by Eclipse.
>
> There's no good reason for maintaining this layout any
On Fri, 3 Mar 2023 18:02:22 GMT, Vladimir Kozlov wrote:
>> The layout of the sources in `jdk.internal.vm.ci` stems from their initial
>> development outside the JDK where they adopted a layout influenced by
>> Eclipse.
>>
>> There's no good reason for maintaining this layout any more. Moving t
On Fri, 3 Mar 2023 18:02:22 GMT, Vladimir Kozlov wrote:
> Please, test it in mach5
Done - please see link in issue. All 6 failures are not related to this change.
-
PR: https://git.openjdk.org/jdk/pull/12860
The layout of the sources in `jdk.internal.vm.ci` stems from their initial
development outside the JDK where they adopted a layout influenced by Eclipse.
There's no good reason for maintaining this layout any more. Moving to a
standard layout also means IDEs will be able to make sense of the JVM
On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik wrote:
> The newline is added to be compatible with old make 3.81 which is still used
> on MacOSX.
> Fixed actually by dnsimon.
Marked as reviewed by dnsimon (Committer).
-
PR: https://git.openjdk.org/jdk/pull/12461
On Tue, 7 Feb 2023 06:14:24 GMT, Hao Sun wrote:
>> The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does
>> not give the compiler a chance to specify whether it supports a given GC.
>> Instead, we want a JVMCI upcall like
>> `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupport
On Mon, 6 Feb 2023 07:05:39 GMT, Hao Sun wrote:
>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 413:
>>
>>> 411: }
>>> 412:
>>> 413: if (UseBranchProtection == nullptr || strcmp(UseBranchProtection,
>>> "none") == 0) {
>>
>> My understanding is that `UseBranchProtection` requires J
On Tue, 22 Feb 2022 14:35:19 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Wed, 24 Aug 2022 11:33:01 GMT, Fei Yang wrote:
>>> Do you have details about testing performed in Native Image as mentioned in
>>> PR decription?
>>
>> Yes, the RISC-V LLVM backend for Native Image passes 99% of the tests
>> performed, which is similar to the other LLVM backends.
>>
>>> I
On Tue, 23 Aug 2022 11:29:45 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
On Mon, 22 Aug 2022 11:37:52 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
On Wed, 27 Jul 2022 11:25:22 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
39 matches
Mail list logo
