Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee wrote: >> Sure, this is problematic - but at the same time I don't think there's a >> better way to deal with this? I'd prefer to defer this to a separate issue >> (and I think the build team is in a much better position to sugges

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := --add-exports >>> java.base/sun.security.util=ALL-UNNAMED

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5]

2022-03-24 Thread Jorn Vernee
On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Jorn Vernee
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18]

2021-11-05 Thread Jorn Vernee
On Fri, 5 Nov 2021 14:33:44 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java >> line 134: >> >>> 132: * >>> 133: * Upcall stubs are generally safer to work with, as the linker >>> runtime can validate the type of the target

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v18]

2021-11-05 Thread Jorn Vernee
On Fri, 5 Nov 2021 11:06:53 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v16]

2021-11-03 Thread Jorn Vernee
On Wed, 3 Nov 2021 13:08:55 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

2021-11-02 Thread Jorn Vernee
On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore wrote: >> What is missing, I think, is a check (size > arenaSize) at the beginning of >> the method (we only check this in one of the paths). But we need to check >> before and after, I think, as it is possible to allocate a segment and

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 15:38:18 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 17 commits: >> >> - Add cache for memory address var handles >> - Merg

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

2021-11-02 Thread Jorn Vernee
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8253757: Add LLVM-based backend for hsdis

2021-10-14 Thread Jorn Vernee
On Thu, 14 Oct 2021 14:04:12 GMT, Andrew Haley wrote: > Some feedback from those who have tested it would be appeciated here I haven't really tested it beyond building the lib and seeing if assembly was output instead of just bytes, so I can't really comment on that I'm afraid. Since the

Re: RFR: 8253757: Add LLVM-based backend for hsdis

2021-10-13 Thread Jorn Vernee
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, > as published in the never integrated PR >

Re: RFR: 8253757: Add LLVM-based backend for hsdis

2021-10-12 Thread Jorn Vernee
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > but it caused hotspot to segfault in LoadLibrary (!) in os::dll_load when I > tried to load the library. I tried compiling the binutils-based hsdis earlier as well, but on WSL instead of cygwin (using the `mingw-w64` package), and

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7]

2021-10-12 Thread Jorn Vernee
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

Integrated: 8269761: idea.sh missing .exe suffix when invoking javac on WSL

2021-07-07 Thread Jorn Vernee
On Thu, 1 Jul 2021 15:02:03 GMT, Jorn Vernee wrote: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this > results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such &

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4]

2021-07-06 Thread Jorn Vernee
On Mon, 5 Jul 2021 18:05:19 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this >> results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4]

2021-07-05 Thread Jorn Vernee
javac path fixes this issue, which can be done > just for WSL. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Make idea.sh work on WSL with a Linux boot JDK - Changes: - all: https://git.openjdk.java.net/jdk/

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v2]

2021-07-05 Thread Jorn Vernee
javac path fixes this issue, which can be done > just for WSL. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. - Changes: - all: https://git.openjd

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v3]

2021-07-05 Thread Jorn Vernee
On Mon, 5 Jul 2021 10:40:15 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this >> results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v3]

2021-07-05 Thread Jorn Vernee
javac path fixes this issue, which can be done > just for WSL. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since

Re: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v2]

2021-07-05 Thread Jorn Vernee
On Mon, 5 Jul 2021 10:31:13 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this >> results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/

Integrated: 8269760: idea.sh should not invoke cygpath directly

2021-07-05 Thread Jorn Vernee
On Thu, 1 Jul 2021 14:54:04 GMT, Jorn Vernee wrote: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking > `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to > something e

Re: RFR: 8269760: idea.sh should not invoke cygpath directly [v2]

2021-07-05 Thread Jorn Vernee
ygpath` directly, the value of the `CYGPATH` variable > should be used. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. - Changes: - all: https:/

Integrated: 8269758: idea.sh doesn't work when there are multiple configurations available.

2021-07-05 Thread Jorn Vernee
On Thu, 1 Jul 2021 14:41:53 GMT, Jorn Vernee wrote: > From the JBS issue: > > The idea.sh script invokes `make`, but doesn't specify a configuration. So, > when multiple configurations are present, this results in an error like this: > > > $ bash bin/idea.sh java.base &

Re: RFR: 8269760: idea.sh should not invoke cygpath directly

2021-07-01 Thread Jorn Vernee
On Thu, 1 Jul 2021 16:06:47 GMT, Maurizio Cimadamore wrote: > Not an expert on the value of these variables My own line of thought is that it is reasonable to expect that anything found in the `CYGPATH` variable is fine to treat as if it were `cygpath` like this (this could be an alternative

RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL

2021-07-01 Thread Jorn Vernee
>From the JBS issue: At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory Adding a .exe suffix to the javac path fixes this issue, which can be done

RFR: 8269760: idea.sh should not invoke cygpath directly

2021-07-01 Thread Jorn Vernee
>From the JBS issue: Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. Instead of invoking `cygpath` directly, the value of the `CYGPATH`

RFR: 8269758: idea.sh doesn't work when there are multiple configurations available.

2021-07-01 Thread Jorn Vernee
>From the JBS issue: The idea.sh script invokes `make`, but doesn't specify a configuration. So, when multiple configurations are present, this results in an error like this: $ bash bin/idea.sh java.base Error: No CONF given, but more than one configuration found. Available configurations in

[jdk17] Integrated: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

2021-06-21 Thread Jorn Vernee
On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: > https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. This pull re

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2]

2021-06-17 Thread Jorn Vernee
On Thu, 17 Jun 2021 11:28:54 GMT, Jorn Vernee wrote: >> Upstream a critical fix from the panama-foreign repo. >> >> See the prior review thread here: >> https://github.com/openjdk/panama-foreign/pull/558 >> >> Testing: tier 1-2, local run of run-test-jdk_

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

2021-06-17 Thread Jorn Vernee
On Thu, 17 Jun 2021 12:30:46 GMT, David Holmes wrote: > Now that you have explained it I think a much simpler comment will suffice :) Ok, I've shortened the comment. Thanks :) - PR: https://git.openjdk.java.net/jdk17/pull/76

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v3]

2021-06-17 Thread Jorn Vernee
On Thu, 17 Jun 2021 12:50:10 GMT, Jorn Vernee wrote: >> Upstream a critical fix from the panama-foreign repo. >> >> See the prior review thread here: >> https://github.com/openjdk/panama-foreign/pull/558 >> >> Testing: tier 1-2, local run of run-test-jdk_

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v3]

2021-06-17 Thread Jorn Vernee
> Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: > https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Jorn Vernee has updated the pull request incrementally with two additio

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2]

2021-06-17 Thread Jorn Vernee
> Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: > https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Jorn Vernee has updated the pull request incrementally with one additi

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2]

2021-06-17 Thread Jorn Vernee
On Thu, 17 Jun 2021 00:23:19 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add comment about optimized entry frames only being generated on x86_64 > > src/hotspot/

[jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

2021-06-16 Thread Jorn Vernee
Upstream a critical fix from the panama-foreign repo. See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 Testing: tier 1-2, local run of run-test-jdk_foreign. - Commit messages: - Fix a couple of CI build problems - Upstream: 8268673: Stack walk

Integrated: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10

2021-06-08 Thread Jorn Vernee
On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C > libraries. > > > However, currently it is not poss

RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10

2021-06-07 Thread Jorn Vernee
Hi, The documentation of `CLinker::systemLookup` [1] says this: * Obtains a system lookup which is suitable to find symbols in the standard C libraries. However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v6]

2020-12-04 Thread Jorn Vernee
On Fri, 4 Dec 2020 18:54:32 GMT, Magnus Ihse Bursie wrote: >> For the build to work on Windows, we need a unix compatibility layer (known >> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The >> build system then needs to adapt various aspect to get the build to work in

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v5]

2020-12-04 Thread Jorn Vernee
On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson wrote: >> Ok, after looking at `set -x` output WSL seems to have a problem with the >> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk >> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that >>

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v5]

2020-12-04 Thread Jorn Vernee
On Fri, 4 Dec 2020 18:07:22 GMT, Magnus Ihse Bursie wrote: >> Ok, after looking at `set -x` output WSL seems to have a problem with the >> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk >> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v5]

2020-12-04 Thread Jorn Vernee
On Fri, 4 Dec 2020 14:22:45 GMT, Jorn Vernee wrote: >> @JornVernee I have now pushed a fix that will make `fixpath import` ignore >> invalid or unknown paths be ignored. Please try again with it. > > @magicus Thanks! But, now I get the same error as the GH action: > https

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v4]

2020-12-04 Thread Jorn Vernee
On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie wrote: >> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin >> PATH in .bash_profile. If I remove that I get a little further. >> >> But the same command fails later on a path with a space in it: >> >> fixpath:

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 23:25:28 GMT, Magnus Ihse Bursie wrote: >> @magicus Ah dang, I tested passing `--with-tools-dir` a unix path before but >> messed up the drive letter. So, passing unix path to `--with-tools-dir` >> (i.e. `--with-tools-dir='/cygdrive/j/Program Files (x86)/Microsoft Visual >>

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 22:52:57 GMT, Magnus Ihse Bursie wrote: >> Hey, >> >> Since I often work on Windows I'm taking this for a spin, but the current >> patch fails during `configure` for me with: >> >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 22:21:52 GMT, Jorn Vernee wrote: >> Overall this is very nice. Some comments and questions inline. > > Hey, > > Since I often work on Windows I'm taking this for a spin, but the current > patch fails during `configure` for me with: > > configu

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v2]

2020-12-03 Thread Jorn Vernee
On Thu, 3 Dec 2020 21:11:19 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missed my last bugfix for fixpath.sh... > > Overall this is very nice. Some comments and questions inline. Hey,

Integrated: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-04 Thread Jorn Vernee
On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native > libraries on Windows. The comme

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2]

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 19:08:05 GMT, Jorn Vernee wrote: >> I knew this looks familiar. Look at [existing macros in >> jlong_md.h](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/jlong_md.h#L67-L81) >> and use/match them? There is a little difference

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2]

2020-11-03 Thread Jorn Vernee
t; this has been removed [1], it seemed safe to propagate the macro now (backed > up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to > having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JD

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 19:16:02 GMT, Magnus Ihse Bursie wrote: >> Thanks for the suggestion. >> >> Note the code that adds _LP64 for the JVM (below): >> >> if test "x$FLAGS_OS" != xaix; then >> # xlc on AIX defines _LP64=1 by default and issues a warning if we >> redefine it. >>

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 18:30:46 GMT, Aleksey Shipilev wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native >> libraries on Windows. The comment says that this

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 18:46:29 GMT, Magnus Ihse Bursie wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native >> libraries on Windows. The comment says that

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 17:42:08 GMT, Jorn Vernee wrote: >> test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c >> line 32: >> >>> 30: #define PTR_TO_JLONG(value) ((jlong) (value)) >>> 31: #else >>> 32: #define JLO

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
On Tue, 3 Nov 2020 17:40:32 GMT, Coleen Phillimore wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native >> libraries on Windows. The comment says that

RFR: 8255128: linux x86 build failure with libJNIPoint.c

2020-11-03 Thread Jorn Vernee
Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c This removes the reported warning. Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

2020-10-22 Thread Jorn Vernee
On Thu, 22 Oct 2020 16:31:00 GMT, Maurizio Cimadamore wrote: >> Some of this is familiar to me from reviews in the `panama-foreign` >> repository, but less so than the memory API. I focused on the Java code, and >> ignored changes that are common with the memory API PR. >> >> If it helps in

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

2020-10-22 Thread Jorn Vernee
On Tue, 20 Oct 2020 21:53:55 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into 8254231_linker >> - Fix incorrect capitalization in one

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

2020-10-22 Thread Jorn Vernee
On Tue, 20 Oct 2020 21:08:26 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into 8254231_linker >> - Fix incorrect capitalization in one

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-21 Thread Jorn Vernee
On Mon, 19 Oct 2020 11:24:45 GMT, Jorn Vernee wrote: >> I looked through some Hotspot runtime code and that looks ok. I saw a >> couple of strange things on my way through the code. See comments. > > Hi David, this code somewhat predates me, so I initially kept the

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-19 Thread Jorn Vernee
On Fri, 16 Oct 2020 11:12:01 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56: >> >>> 54: } >>> 55: >>> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) { >> >> I don't know if you care about

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-19 Thread Jorn Vernee
On Thu, 15 Oct 2020 23:15:07 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Re-add file erroneously deleted (detected as rename) > > I looked through some Hotspot runtime code and

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-16 Thread Jorn Vernee
On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Re-add file erroneously deleted (detected as rename) > > src/hotspot/cpu/x86/foreign_globals_x86.cpp line

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-16 Thread Jorn Vernee
On Thu, 15 Oct 2020 22:52:14 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Re-add file erroneously deleted (detected as rename) > > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-16 Thread Jorn Vernee
On Thu, 15 Oct 2020 22:44:54 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Re-add file erroneously deleted (detected as rename) > > src/hotspot/cpu/x86/foreign_globals_x86.hpp line

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

2020-10-16 Thread Jorn Vernee
On Thu, 15 Oct 2020 22:39:50 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Re-add file erroneously deleted (detected as rename) > > src/hotspot/cpu/x86/foreign_globals_x86.cpp line

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator)

2020-10-15 Thread Jorn Vernee
hich contains only the differences between this PR > and the memory access PR. I will be > periodically uploading new webrevs, as new iterations come out, to try and > make the life of reviewers as simple as > possible. A big thank to Jorn Vernee and Vladimir Ivanov - they are the main

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

2020-09-10 Thread Jorn Vernee
On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to >> post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due >> to: >> " Too many recipients to

Re: RFR: JDK-8241768 git needs .gitattributes

2020-09-03 Thread Jorn Vernee
Looks good. Jorn On 03/09/2020 17:49, Magnus Ihse Bursie wrote: This is an old bug that was opened long time ago, but with a much better solution for the "autocrlf" problem. Erik and I have agreed that using "-text" as attribute for all files is the best solution to mimic the old mercurial

Re: RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

2020-07-13 Thread Jorn Vernee
Hey Peter, Thank you for looking into this. I planned on coming back to this later, as it wasn't as much of a quick-fix as I'd hoped, but got caught up working on other issues in the mean time. Jorn On 11/07/2020 12:00, Peter Levart wrote: On 7/11/20 9:31 AM, Peter Levart wrote: - compile

Re: RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

2020-07-07 Thread Jorn Vernee
On 30/06/2020 22:51, Erik Joelsson wrote: On 2020-06-30 13:15, Claes Redestad wrote: On 2020-06-30 22:12, Magnus Ihse Bursie wrote: Second to that a solution in the build would be preferable - if we can come up with something that has infinitesimal impact to build times. Are we talking about

Re: RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

2020-06-30 Thread Jorn Vernee
onvenience users who need to run the jar file directly. So it seems we should consider fixing so that only those benchmarks that actually need --enable-preview are built with that flag. /Claes On 2020-06-27 00:21, Jorn Vernee wrote: Forgot to attach the JBS link: https://bugs.openjdk.java.net/

Re: RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

2020-06-26 Thread Jorn Vernee
Forgot to attach the JBS link: https://bugs.openjdk.java.net/browse/JDK-8248429 Jorn On 27/06/2020 00:14, Jorn Vernee wrote: Hi, https://bugs.openjdk.java.net/browse/JDK-8248135 added --enable-preview to the javac options when building micro benchmarks. We should also add it to the set

RFR [XS]: 8248429: Add --enable-preview as VM argument when running microbenchmarks

2020-06-26 Thread Jorn Vernee
Hi, https://bugs.openjdk.java.net/browse/JDK-8248135 added --enable-preview to the javac options when building micro benchmarks. We should also add it to the set of default VM arguments passed to the microbenchmark jar so it doesn't need to be passed manually. If --enable-preview is not

Re: RFR: 8246572: Always pass java.library.path when running micro benchmarks

2020-06-04 Thread Jorn Vernee
Thanks to the both of you! Jorn On 04/06/2020 14:40, Claes Redestad wrote: On 2020-06-04 14:39, Magnus Ihse Bursie wrote: On 2020-06-04 11:56, Claes Redestad wrote: Hi, sponsoring this patch for Jorn, which ensures the -Djava.library.path argument is always passed in when running

Sponsor request: Always pass java.library.path when running micro benchmarks

2020-06-03 Thread Jorn Vernee
Hi, Please sponsor the following patch that correctly passes java.library.path when running micro benchmarks [1]. As a little bit of background; previously the java.library.path was appended to $1_MICRO_JAVA_OPTIONS and this was passed to the java VM running the JMH jar. But, the problem

Re: RFR 8233844: Add LogCompilation build artifacts to .gitignore

2019-11-11 Thread Jorn Vernee
is indiscriminately running maven on the LogCompilation project (which it's picking up). Time to start disabling some plugins :) Jorn On 08/11/2019 18:48, Jorn Vernee wrote: Hello Erik, You are right, I spoke too soon. I deleted the artifacts and tried to trigger the creation by doing

Re: RFR 8233844: Add LogCompilation build artifacts to .gitignore

2019-11-08 Thread Jorn Vernee
for these artifacts appearing again. Thanks, Jorn On 08/11/2019 15:16, Erik Joelsson wrote: Hello Jorn, On 2019-11-08 04:24, Jorn Vernee wrote: Hi, I'd like to contribute this very small patch that adds some LogCompilation build artifacts to the .gitignore file. Bug: https://bugs.openjdk.java.net/browse

RFR 8233844: Add LogCompilation build artifacts to .gitignore

2019-11-08 Thread Jorn Vernee
Hi, I'd like to contribute this very small patch that adds some LogCompilation build artifacts to the .gitignore file. Bug: https://bugs.openjdk.java.net/browse/JDK-8233844 Webrev: http://cr.openjdk.java.net/~jvernee/8233844/webrev.00/index.html Testing = manual FWIW, it seems that these

Re: VS install found through --with-tools-dir value is discarded

2019-10-11 Thread Jorn Vernee
Hi Magnus, I've created a JBS ticket for it: https://bugs.openjdk.java.net/browse/JDK-8232167 But, I'm not a committer on the jdk project, so I would need a sponsor. Could you push the patch? Thanks, Jorn On 11/10/2019 09:06, Magnus Ihse Bursie wrote: 9 okt. 2019 kl. 16:00 skrev Jorn

Re: VS install found through --with-tools-dir value is discarded

2019-10-11 Thread Jorn Vernee
though I'm not sure they were caused by OOM, that seems the most likely to me. Jorn On 10/10/2019 19:52, Erik Joelsson wrote: Hello Jorn, On 2019-10-09 07:00, Jorn Vernee wrote: Hi, I was testing with different versions of Visual Studio to try and nail down the source of a deprecation warning. I

VS install found through --with-tools-dir value is discarded

2019-10-10 Thread Jorn Vernee
Hi, I was testing with different versions of Visual Studio to try and nail down the source of a deprecation warning. I was using the --with-tools-dir config option to quickly switch between installations but noticed the VS install that was being found through that method was being discarded,

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Jorn Vernee
Great! Thanks for picking this up. Jorn Claes Redestad schreef op 2019-02-19 22:36: Hi Jorn, I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it seeing it's already reviewed. Thanks! /Claes On 2019-02-19 19:35, Jorn Vernee wrote: Hi Erik, I have included your suggestions

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Jorn Vernee
, please add ", \" plus newline like on 123-124. /Erik On 2019-02-19 03:49, Jorn Vernee wrote: Hi, I've taken a first stab at adding support for native dependencies: http://cr.openjdk.java.net/~jvernee/micronative/webrev.00/ With a small test benchmark: http://cr.openjdk.java.ne

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Jorn Vernee
) \     $$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \     $$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS) $$(MICRO_OPTIONS) \ /Erik On 2019-02-18 14:20, Claes Redestad wrote: http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html> Hi, On 2019-02-18 22:34, Jorn Vernee wrote: Hi Cl

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-19 Thread Jorn Vernee
/784537ff9c4e/make/RunTests.gmk#l692 Jorn Vernee schreef op 2019-02-18 23:38: Hi,   1.) I did not get a warning when I was missing --with-jmh for configure, although it looks like there is supposed to be one (without --with-jmh I got the same access error, but the benchmarks.jar did not exist

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

2019-02-18 Thread Jorn Vernee
Hi,   1.) I did not get a warning when I was missing --with-jmh for configure, although it looks like there is supposed to be one (without --with-jmh I got the same access error, but the benchmarks.jar did not exist). --with-jmh is an optional configure flag, not sure what we could do to

Re: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows

2019-01-21 Thread Jorn Vernee
I'm downstream from JDK-8215635, I can see it in the revision history. I've also checked the files that were updated, and the changes are still there as well. Jorn Magnus Ihse Bursie schreef op 2019-01-21 11:58: On 2019-01-17 15:42, Jorn Vernee wrote: Hello, I'm updating some

Re: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows

2019-01-17 Thread Jorn Vernee
Never mind, this works: bash configure PANDOC=/cygdrive/j/ChocolateyInstall/bin/pandoc.exe I should have tried that first. Sorry, Jorn Jorn Vernee schreef op 2019-01-17 18:07: Hi Erik, Thanks for the insights. The make/devkit/createPandocBundle.sh seems to try to install the linux

Re: 'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows

2019-01-17 Thread Jorn Vernee
. I'm pretty sure the target works if you provide pandoc to configure on Windows. There is a script in make/devkit/createPandocBundle.sh that can help you get the pandoc you need. /Erik On 2019-01-17 06:42, Jorn Vernee wrote: Hello, I'm updating some documentation for the panama repo foreign

'make update-build-docs' fails with 'fixpath Unknown argument: --toc' on Windows

2019-01-17 Thread Jorn Vernee
Hello, I'm updating some documentation for the panama repo foreign branch [1]. When running `make update-build-docs` I get the following output: ``` $ make update-build-docs Building target 'update-build-docs' in configuration 'windows-x86_64-server-release' fixpath Unknown argument: --toc

src.zip is not being updated when running make images

2018-09-25 Thread Jorn Vernee
Hello, I'm running into a problem where running `make images` does not update the `images/jdk/lib/src.zip` file. I have tried deleting the file and then running the command, which creates the src.zip, but it still has the old source files in it. I'm debugging using my IDE (Netbeans), but

jvmFlagRangeList.cpp(341): warning C4305: 'argument': truncation from 'const intx' to 'double'

2018-07-14 Thread Jorn Vernee
/msvc/1414~1.264/bin/hostx86/x64/cl) * C++ Compiler: Version 19.14.26430 (at /cygdrive/j/progra~2/micros~2/2017/buildt~1/vc/tools/msvc/1414~1.264/bin/hostx86/x64/cl) Note that this is the BuildTools only version of VS 2017. Best regards, Jorn Vernee