On Wed, 10 Apr 2024 09:24:09 GMT, Hamlin Li wrote:
> With that in mind, it looks like we could potentially use SLEEF for other
> architectures on linux in the future? And potentially additional operating
> systems as well?
Hi Mikael(@vidmik ) ! :)
Thanks for looking into the legal stuff!
We
On Wed, 20 Mar 2024 16:17:36 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY",
On Fri, 5 Apr 2024 10:45:24 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any
On Tue, 9 Apr 2024 08:06:19 GMT, Ludovic Henry wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use JNIEXPORT
>
> Marked as reviewed by luhenry (Committer).
Thank you @luhenry !
--
On Sat, 6 Apr 2024 13:18:54 GMT, Andrew Haley wrote:
> Thanks to everyone working on this. I still think that hsdis ought not to
> have any dependencies on HotSpot, but I'm not going to be fanatical about it.
I agree, good :)
If everyone is 'okay' with this, can someone do the second review?
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks, Robbin
Robbi
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any
On Mon, 25 Mar 2024 15:13:54 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
>> > > But that raises an interesting question. What happens if you try to load
>> > > a library
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any
On Mon, 25 Mar 2024 09:12:19 GMT, Magnus Ihse Bursie wrote:
> (In fact, I think we have a problem everywhere in the code base where someone
> is using `__declspec(dllexport)` directly)
src/java.base/share/native/libzip/zlib/zconf.h:# define ZEXPORT
__declspec(dllexport)
ZEXPORT is
On Fri, 22 Mar 2024 11:43:34 GMT, Magnus Ihse Bursie wrote:
> > is this how you want us to export these symbols?
>
> Close but no cigar. :-)
>
> Use `JNIEXPORT` instead, that is properly defined for this purpose and works
> on all compilers. You will need to also add:
>
> ```
> #include
On Fri, 22 Mar 2024 10:22:54 GMT, Magnus Ihse Bursie wrote:
> > What is the relevance of SVE support at build time? Should it matter what
> > the build machine is?
>
> My understanding is that we need a compiler that supports
> `-march=armv8-a+sve`; otherwise we can't build the redirect
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks, Robbin
Robbi
On Thu, 21 Mar 2024 06:02:56 GMT, David Holmes wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
Hi, please consider.
[8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
Tested with gcc and clang, and llvm and binutils backend.
I didn't find any use of the "DLL_ENTRY", so I removed it.
Thanks, Robbin
-
Commit messages:
- export symbols
Changes:
On Thu, 14 Mar 2024 09:14:04 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Mon, 1 Jan 2024 11:04:35 GMT, Guoxiong Li wrote:
> Hi all,
>
> This trivial patch removes the information about the path `debian-ports`
> because the riscv related packages had been moved to the path `debian` at
> 2024-01-01. Now the arm and riscv use the same url
>
On Thu, 23 Nov 2023 14:24:40 GMT, Magnus Ihse Bursie wrote:
> The C snippet in AC_COMPILE_IFELSE is incorrect.
>
> As noted by @galderz:
> https://github.com/openjdk/jdk/pull/15138#discussion_r1402918327
Thank you @magicus and @galderz!
Looks good!
-
Marked as reviewed by rehn
On Thu, 23 Nov 2023 14:23:54 GMT, Magnus Ihse Bursie wrote:
>> Yea, you are correct. Apparently the gcc extension is not turned off even if
>> you use -ansi.
>> clang on the other hand complains.
>>
>> @galderz your suggested patch is correct, can you open PR ?
>
> @robehn Way ahead of you:
On Thu, 23 Nov 2023 13:42:22 GMT, Magnus Ihse Bursie wrote:
>> I don't know why.
>>
>>
>> [rehn@rehn-xps ~]$ cat m.c
>> int main() {
>> void foo() {
>> return;
>> };
>> foo();
>> return 0;
>> }
>> [rehn@rehn-xps ~]$ gcc -Wall -Wextra -std=c89 m.c
>> [rehn@rehn-xps ~]$
>
> @robehn
On Thu, 23 Nov 2023 07:47:30 GMT, Galder Zamarreño wrote:
>> Yes, you are correct, this was not my intention.
>> For some reason I mixed up AC_LANG_SOURCE and AC_LANG_PROGRAM.
>>
>> But nested function are fine, so there is actually no issue with it.
>
>> But nested function are fine, so there
On Thu, 23 Nov 2023 05:01:14 GMT, Galder Zamarreño wrote:
>> make/autoconf/lib-hsdis.m4 line 272:
>>
>>> 270:
>>> 271: AC_MSG_CHECKING([Checking binutils API])
>>> 272: AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include $disasm_header],[[void
>>> foo() {init_disassemble_info(0, 0, 0, 0);}]])],
On Tue, 31 Oct 2023 13:05:44 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> insn_options[0] is set to empty string if there is no options (NULL or empty
> strings).
> Checking it for empty string should cover both cases, caller option is NULL
> or caller option is empty s
On Thu, 2 Nov 2023 09:22:55 GMT, Andrew Haley wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More clear
>
> src/utils/hsdis/binutils/hsdis-binutils.c line 341:
>
>> 339:
> Hi, please consider.
>
> insn_options[0] is set to empty string if there is no options (NULL or empty
> strings).
> Checking it for empty string should cover both cases, caller option is NULL
> or caller option is empty string.
>
> Tested hsdis no longer gives me the
On Wed, 1 Nov 2023 11:52:20 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> insn_options[0] is set to empty string if there is no options (NULL or empty
>> strings).
>> Checking it for empty string should cover both cases, caller option is NULL
>&
> Hi, please consider.
>
> insn_options[0] is set to empty string if there is no options (NULL or empty
> strings).
> Checking it for empty string should cover both cases, caller option is NULL
> or caller option is empty string.
>
> Tested hsdis no longer gives me the
On Tue, 31 Oct 2023 14:21:02 GMT, Hamlin Li wrote:
>> Hi, please consider.
>>
>> insn_options[0] is set to empty string if there is no options (NULL or empty
>> strings).
>> Checking it for empty string should cover both cases, caller option is NULL
>> or caller option is empty string.
>>
>>
On Tue, 31 Oct 2023 14:30:26 GMT, Robbin Ehn wrote:
>> src/utils/hsdis/binutils/hsdis-binutils.c line 340:
>>
>>> 338: native_bfd,
>>> 339: /* On some archs we get warnings, if
>&g
On Tue, 31 Oct 2023 14:30:26 GMT, Robbin Ehn wrote:
>> src/utils/hsdis/binutils/hsdis-binutils.c line 340:
>>
>>> 338: native_bfd,
>>> 339: /* On some archs we get warnings, if
>&g
On Tue, 31 Oct 2023 14:15:16 GMT, Andrew Haley wrote:
>> Hi, please consider.
>>
>> insn_options[0] is set to empty string if there is no options (NULL or empty
>> strings).
>> Checking it for empty string should cover both cases, caller option is NULL
>> or caller option is empty string.
>>
Hi, please consider.
insn_options[0] is set to empty string if there is no options (NULL or empty
strings).
Checking it for empty string should cover both cases, caller option is NULL or
caller option is empty string.
Tested hsdis no longer gives me the warning.
-
Commit
On Tue, 31 Oct 2023 12:53:56 GMT, Erik Joelsson wrote:
> > I think you are correct, I tested on some more machines.
> > On my vf2 dev board (4-core rv64) it do speed up sh configure, from 7:19 to
> > 3:40. I see like 20 instances of cc1 instead 1, a bit to many :)
>
> Adding the `-j` flag
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> Tested configure with binutils-src.
>
> Thanks
I think you are correct, I tested on some more machines.
On my vf2 dev board (4-core rv64) it do speed up sh configure, from 7:19 to
3:40
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> Tested configure with binutils-src.
>
> Thanks
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/16421
Hi all, please consider.
Tested configure with binutils-src.
Thanks
-
Commit messages:
- Use -j
Changes: https://git.openjdk.org/jdk/pull/16421/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=16421=00
Issue: https://bugs.openjdk.org/browse/JDK-8319121
Stats: 2 lines in 1
On Thu, 26 Oct 2023 22:17:45 GMT, Claes Redestad wrote:
> The binutils build of libiberty is put in `$BINUTILS_INSTALL_DIR/lib64` on
> some Linux distributions (e.g. Fedora, Oracle Linux),
> `$BINUTILS_INSTALL_DIR/lib` on others (e.g. Ubuntu).
>
> This PR suggest simply adding logic to look
On Thu, 3 Aug 2023 12:48:50 GMT, Robbin Ehn wrote:
> Hi please consider.
>
> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
> (tested x64 and some RV)
>
> There are 4 changes in binutils we work around.
> - zstd compressed debug section
On Thu, 19 Oct 2023 13:49:21 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
>> (tested x64 and some RV)
>>
>> There are 4 changes in binutils we work around.
>> - zst
On Thu, 19 Oct 2023 21:20:20 GMT, Magnus Ihse Bursie wrote:
> This looks soo much better! Thank you for taking the time to clean it up and
> expand/generalize the functionality. Now I think the binutils functionality
> is close to as good as we're ever going to get it.
Thank you, great that
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request incrementally with one additional
commit since the last revision:
Added back guard
On Thu, 19 Oct 2023 13:02:58 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
>> (tested x64 and some RV)
>>
>> There are 4 changes in binutils we work around.
>> - zst
On Wed, 18 Oct 2023 17:57:47 GMT, Magnus Ihse Bursie wrote:
> Ok, fine, let's go with this patch then.
Thank you, but I was unhappy with the situation.
I redid the patch:
- Source build now do make install, then uses same steps as pre-built after the
"make install".
- Prebuilt now uses the
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains ten com
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes
On Wed, 18 Oct 2023 15:18:34 GMT, Magnus Ihse Bursie wrote:
> I still think we're talking past each other here.
>
> I am talking about situation 3: We have built and installed it locally with
> `make install`, and have removed the installation directory (or at least
> points the configure
On Fri, 29 Sep 2023 10:44:49 GMT, Magnus Ihse Bursie wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check API during conf
>
> Nevertheless, I believe the .libs issue needs to be a
On Mon, 2 Oct 2023 22:54:02 GMT, David Holmes wrote:
>> @Hamlin-Li thanks!
>
> @robehn this change failed in GHA and then broke our CI as well.
@dholmes-ora sorry. GHA have been failing for my in PR for various unrelated
reason, so I missed this, sorry again.
-
PR Comment:
On Fri, 29 Sep 2023 16:27:48 GMT, Hamlin Li wrote:
>> Hi all, please consider.
>>
>> latomic is used for non native atomic operation which causes problems with
>> extra dependency.
>> This have been fixed in recent gcc, so latomic is no longer needed.
>>
>> Added new gtest, passes t1 on
On Tue, 26 Sep 2023 12:04:49 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> latomic is used for non native atomic operation which causes problems with
> extra dependency.
> This have been fixed in recent gcc, so latomic is no longer needed.
>
> Added new gtest,
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request incrementally with one additional
commit since the last revision:
Minor fixes
-
On Fri, 29 Sep 2023 10:44:49 GMT, Magnus Ihse Bursie wrote:
> Nevertheless, I believe the .libs issue needs to be addressed as well,
> otherwise this will be a regression for older versions of binutils that are
> in a non-build installed location.
>
> That is, you need to break out the check
On Fri, 29 Sep 2023 03:38:48 GMT, Fei Yang wrote:
>> Hi all, please consider.
>>
>> latomic is used for non native atomic operation which causes problems with
>> extra dependency.
>> This have been fixed in recent gcc, so latomic is no longer needed.
>>
>> Added new gtest, passes t1 on
On Mon, 7 Aug 2023 10:57:57 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
>> (tested x64 and some RV)
>>
>> There are 4 changes in binutils we work around.
>> - zst
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request incrementally with one additional
commit since the last revision:
Check API dur
On Wed, 27 Sep 2023 09:02:23 GMT, Magnus Ihse Bursie wrote:
> Ok, so let me see if I get this right. With gcc >= 13.2, we will use a gcc
> intrinsic. But this patch will work for older gcc versions as well, but then
> it uses assembly code?
Yes!
-
PR Comment:
On Wed, 27 Sep 2023 07:37:52 GMT, Magnus Ihse Bursie wrote:
> Looks good from a build perspective. It's nice to get rid of such special
> cases.
Thank you @magicus !
> > This have been fixed in recent gcc, so latomic is no longer needed.
>
> I just noticed this. Does this mean RISC-V
Hi all, please consider.
latomic is used for non native atomic operation which causes problems with
extra dependency.
This have been fixed in recent gcc, so latomic is no longer needed.
Added new gtest, passes t1 on vf2/qemu.
-
Commit messages:
- Remove latomic, add cmpxchg 1
On Mon, 25 Sep 2023 09:41:13 GMT, Andrew Haley wrote:
> Maybe, but would it really be easier? I don't see that it would be
> _significantly_ easier, and it would be much more riscv community friendly to
> work on the shared disassembler.
The build would be easier, no deps at all and could be
On Fri, 22 Sep 2023 09:20:47 GMT, Robbin Ehn wrote:
>>> It may be possible to read some elf header about binutils version. I.e. do
>>> make install from our build system, then reading out version from elf
>>> section and pass that into our build. As we
On Fri, 22 Sep 2023 16:44:07 GMT, Andrew Haley wrote:
> I dunno Robbin, is this really the sort of stuff we should be doing? Binutils
> is looking less useful as a base for hsdis. I see your problem, but I can't
> help wondering if rather than trying to keep up with Binutils it'd be a
>
On Fri, 22 Sep 2023 08:02:16 GMT, Magnus Ihse Bursie wrote:
>> I'm still not really happy about this. The old solution without .libs has
>> worked before -- has anything changed in newer versions of binutils?
>>
>> Also, we support building binutils in place as a convenience, but it should
On Thu, 21 Sep 2023 14:49:55 GMT, Magnus Ihse Bursie wrote:
> Thanks for your effort of getting hsdis to work with a wider range of
> binutils! This has been problematic for a while.
Thanks for having a look!
-
PR Comment:
On Fri, 22 Sep 2023 06:46:46 GMT, Robbin Ehn wrote:
>> make/autoconf/lib-hsdis.m4 line 245:
>>
>>> 243: HSDIS_CFLAGS="-DLIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB"
>>> 244: elif test "x$BINUTILS_DIR" != x; then
>>> 245: if t
On Thu, 21 Sep 2023 14:45:52 GMT, Magnus Ihse Bursie wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reverted bad change
>
> make/autoconf/lib-hsdis.m4 line 245:
>
>
On Tue, 19 Sep 2023 14:14:35 GMT, Antonios Printezis wrote:
>> The build failure happens when building on RISC-V with GCC 12.3. Is there a
>> better way to address this than disabling the stringop-overflow warnings for
>> the two files in question?
>
> Antonios Printezis has updated the pull
On Wed, 13 Sep 2023 18:18:53 GMT, Kim Barrett wrote:
> It seems to be complaining about atomic increment of a data member, which is
> really weird.
>
> ```
> Atomic::add(&_claimed, flushed);
> ```
>
> When we saw this warning in other places it was because we were passing a
> pointer that
On Wed, 6 Sep 2023 14:29:56 GMT, Antonios Printezis wrote:
> The build failure happens when building on RISC-V with GCC 12.3. Is there a
> better way to address this than disabling the stringop-overflow warnings for
> the two files in question?
Thanks!
I don't see any other non-trivial work
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request incrementally with one additional
commit since the last revision:
Reverted bad change
s added to it frequently we really need
> to be able to build with bleeding-edge binutils. (capstone RV is not actively
> worked on, llvm have many more dependencies)
Robbin Ehn has updated the pull request incrementally with one additional
commit since the last revision:
Added parameter name
On Thu, 3 Aug 2023 12:48:50 GMT, Robbin Ehn wrote:
> Hi please consider.
>
> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
> (tested x64 and some RV)
>
> There are 4 changes in binutils we work around.
> - zstd compressed debug section
Hi please consider.
This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
(tested x64 and some RV)
There are 4 changes in binutils we work around.
- zstd compressed debug sections
- libsframe added
- init_disassemble_info() change
- libbfd.a is only present in .lib
On Fri, 16 Dec 2022 16:10:10 GMT, Magnus Ihse Bursie wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify logic for including __ubsan_default_options
>>
>> Signed-off-by: Justin King
>
> I much also
On Tue, 13 Dec 2022 16:29:59 GMT, Justin King wrote:
> I guess the advantage to putting this in the build machinery (as opposed to
> using `--with-extra-cflags=-fsanitize=undefined
> --with-extra-ldflags=-fsanitize=undefined`) is that we can turn some of these
> onn by default once we've
On Mon, 12 Dec 2022 07:02:04 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior with well defined
>>
On Fri, 9 Dec 2022 13:46:07 GMT, Justin King wrote:
> What version of GCC are you using?
gcc 11.3 with libubsan 11.2
Also it seem to big overlap with -Wcast-align(=strict) for the warnings/errors
I see and I do like that warning.
Do you have an idea if the coverage are pretty much the same
On Fri, 9 Dec 2022 06:53:31 GMT, Justin King wrote:
> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
> the image due to lots of undefined behavior (it invokes the built JVM).
> Follow up PRs will either replace the undefined behavior with well defined
> behavior
On Fri, 9 Sep 2022 10:44:47 GMT, Erik Österlund wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed ws
>
> This looks good to me. I looked through the code to see if I can find
On Fri, 9 Sep 2022 09:55:46 GMT, Martin Doerr wrote:
> Thanks for the update! LGTM. I hope that no other platform with older linux
> kernel is still needed.
Yes, thanks!
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 83:
>
>> 81:
>> 82: void LinuxSystemMemoryBarrier::emit() {
>>
> Please consider, only implemented on x64/aarch64 linux/windows.
> (@TheRealMDoerr have now contributed PPC64)
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robb
On Thu, 8 Sep 2022 18:13:56 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>> (@TheRealMDoerr have now contributed PPC64)
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Pas
> Please consider, only implemented on x64/aarch64 linux/windows.
> (@TheRealMDoerr have now contributed PPC64)
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robb
On Thu, 1 Sep 2022 17:49:59 GMT, Erik Joelsson wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> PPC64 port courtesy Martin Doerr
>
> Build changes look good.
@erikj79 I had to remove t
On Thu, 8 Sep 2022 12:10:34 GMT, Martin Doerr wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change header and constants handling
>
> We need to support older kernel versions on
> Please consider, only implemented on x64/aarch64 linux/windows.
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robbin Ehn has updated the pull request incrementally with
On Mon, 5 Sep 2022 13:36:31 GMT, Martin Doerr wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change header and constants handling
>
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp
On Thu, 8 Sep 2022 09:44:44 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also passes t1-4 as
> Please consider, only implemented on x64/aarch64 linux/windows.
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robbin Ehn has updated the pull request incrementally with
On Mon, 5 Sep 2022 13:36:31 GMT, Martin Doerr wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
>
>
On Mon, 5 Sep 2022 13:41:31 GMT, Martin Doerr wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
>
> Nice to see
On Thu, 1 Sep 2022 17:49:59 GMT, Erik Joelsson wrote:
> Build changes look good.
Thank you!
-
PR: https://git.openjdk.org/jdk/pull/10123
On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote:
> Please consider, only implemented on x64/aarch64 linux/windows.
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Yes,
Please consider, only implemented on x64/aarch64 linux/windows.
On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
-
Commit messages:
- 8292591 - initial
Changes:
On Thu, 11 Aug 2022 12:38:50 GMT, David Holmes wrote:
>> Please review this fix for a problem discovered by @stuart-marks in the
>> course of examining the VM shutdown behaviour. The VM code assumed that only
>> unattached threads called JNI's DestroyJavaVM and so they were always
>> attached
96 matches
Mail list logo
