On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao wrote:
> This patch enables BTI branch protection for runtime part on Linux/aarch64
> platform.
>
> Motivation
>
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level
> packages can gain additional hardening by compiling with
On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>> * NOTE: This pr depends on
On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley wrote:
> @theRealAph Thanks for clarification.
>
> I think there are several different parts involved in the above discussion,
> please kindly correct me if I misunderstood.
>
> 1. package builders. This is about the releas
On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip TANH
>
>> Currently,
>>
>> * in [8329816: Add SLEEF version 3.6
On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>> * NOTE: This pr depends on
On Mon, 15 Jul 2024 21:17:03 GMT, Mikael Vidstedt wrote:
> I think the key question is whether we're comfortable relying on/pointing at
> an external repository which may or may not be there tomorrow and/or where
> tags may change outside of our control.
Right. We should adopt best practice,
On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
> Given the Sleef build system currently uses cmake, we would have two choices
> to build the header files as part of the OpenJDK build system
I don't think that anyone is proposing to do that, so we can discount it
altogether.
>
On Mon, 15 Jul 2024 14:42:45 GMT, Hamlin Li wrote:
> > I can't tell what problem we're trying to solve by not simply checking in
> > the source code, in its preferred form, to the OpenJDK tree. Thhis has
> > practical advantages to do with traceability and security, and in-principle
> >
On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 33 commits:
>>
>> - Merge branch 'master' into sleef-aarch64-integrate-source
>> -
On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>> * NOTE: This pr depends on
On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>> * NOTE: This pr depends on
On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with previous
On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with previous
On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with previous
On Mon, 24 Jun 2024 15:37:43 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with
-variants=client or
minimal), it fails on those platforms as well (it works fine on the server
variant, as that grabs c2_globals.hpp).
The patch for the equivalent code in C1 is in progress. I'll make sure it
works for minimal VM.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only noticed when running
On Fri, 5 Apr 2024 12:17:17 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
>>
>> Compared with previous
On Thu, 4 Apr 2024 16:43:18 GMT, Magnus Ihse Bursie wrote:
> I apologize for the late reply. I've been just working spotty hours due to
> spring break.
I apologize for my bad temper.
Thanks to everyone working on this. I still think that hsdis ought not to have
any dependencies on HotSpot,
On Mon, 25 Mar 2024 09:11:40 GMT, Magnus Ihse Bursie wrote:
> > And neither should we compile or link it with "-fvisibility=hidden". That
> > is the root of this problem.
>
> If you suggest that we should not compile hsdis with hidden visibility, I
> disagree.
Yes, that's what I would do.
On Fri, 15 Mar 2024 13:58:05 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 Fri, 22 Mar 2024 13:38:54 GMT, Robbin Ehn 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 12:31:01 GMT, Andrew Haley 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
> > `-ma
On Fri, 15 Mar 2024 13:58:05 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 Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF
>>> > is making their program faster without running benchmarks. They'll put
>>> > SLEEF somewhere and hope that Java uses it.
>>>
>>> Please kindly
On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think
On Tue, 19 Mar 2024 17:00:48 GMT, Hamlin Li wrote:
> > The problem I see is that J. Random Java User has no way to know if SLEEF
> > is making their program faster without running benchmarks. They'll put
> > SLEEF somewhere and hope that Java uses it.
>
> Please kindly correct me if I
On Fri, 15 Mar 2024 11:35:05 GMT, Hamlin Li wrote:
> > I'm running the tests, but I have no way to confirm that SLEEF or SVE is in
> > use. Exactly what did you do, and how did you confirm it?
>
> Thanks for running test. I just turn on some log, and check the output.
The problem I see is
On Fri, 15 Mar 2024 13:58:05 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 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 Thu, 14 Mar 2024 11:20:26 GMT, Robbin Ehn wrote:
> Hi, thanks for continuing with this.
>
> As this is similar to SVML, comments applies to x86 also:
>
> * There is no way to stop the VM from trying to load vmath ?
> There is both a UseNeon and a UseSVE, if I set both to false I
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 Sat, 24 Feb 2024 20:01:50 GMT, Martijn Verburg wrote:
>> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How
>> can we help in this particular case?
>
> I assume you want to know if we use DAS/DAS1 for debugging purposes on that
> platform?
I use `das` every day.
On Fri, 16 Feb 2024 12:43:29 GMT, Magnus Ihse Bursie wrote:
> I think Kim's approach here -- to separate compiler upgrades from C++17 usage
> -- is the right way. Then we can discuss each part separately -- what version
> is suitable for each compiler, and then -- if or when we end up with all
On 2/16/24 08:49, Thomas Stüfe wrote:
It is probably safe to hide C++ mangled symbols since those decorations are
compiler-specific anyway, no? So they cannot have worked in a reliable fashion
They're not entirely compiler specific, but part of the ABI. See
On Fri, 16 Feb 2024 08:35:29 GMT, Andrew Haley wrote:
>
> To be clear: I do not object to this PR. I would like to use C++17.
Maybe the advantages of C++17 have been discussed elsewhere, in which case all
we need is a link to that discussion on the Bug page. Maybe it's just that we
On Thu, 15 Feb 2024 17:11:34 GMT, Thomas Stuefe wrote:
> > Sure, you can always install a newer GCC than the system one, but it's
> > another thing that makes it harder for people to build OpenJDK. Having said
> > that, C++17 is nice to have.
>
> @theRealAph I am still just hearing
imic how Oracle compiles
both OpenJDK and Oracle JDK as closely as possible.
I sh ./configure --helpbelieve Oracle probably does it by specifying different
parts of the version string on configure, something like
bash configure
"sh ./configure --help" and look for the --with-version
On Wed, 17 Jan 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
> We have been stuck on a very old gcc for a long time, due to various reasons.
> Partly because old gcc versions were not as terrible as old versions of
> cl.exe, and partly to support odd linux platforms where newer gcc versions
>
On Fri, 15 Dec 2023 13:05:32 GMT, Julian Waters wrote:
>> The keyword also happens to go in the same location as well. How
>> coincidental...
>
> I also realized that this uses a gcc statement expression currently, I wonder
> if this could use a lambda expression instead in another change?
ng important here: what is the downside of treating a
build as a cross compilation? Is it simply that more work has to be done,
or something else?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 12/6/23 14:35, erik.joels...@oracle.com wrote:
On 12/6/23 04:18, Andrew Haley wrote:
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sysroot
. By definition,
because if you're building against a compatible set of libraries you
don't have a different sysroot.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong 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 ten addi
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Fri, 1 Dec 2023 01:19:12 GMT, Xiaohong Gong wrote:
> > Not having a build time dependency on libsleef means you cannot really
> > verify that the functions you want to call are correct, but maybe you feel
> > secure that they will never change?
>
> I'm not sure. The main reason that we add
On Fri, 1 Dec 2023 09:59:58 GMT, Andrew Haley wrote:
> Not having a build time dependency on libsleef means you cannot really verify
> that the functions you want to call are correct, but maybe you feel secure
> that they will never change?
We can still have SLEEF tests, but they wil
On Fri, 1 Dec 2023 01:13:37 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-sleef.m4 line 56:
>>
>>> 54: AC_MSG_CHECKING([for the specified LIBSLEEF])
>>> 55: if test -e ${with_libsleef}/lib/libsleef.so &&
>>> 56:test -e ${with_libsleef}/include/sleef.h; then
>>
>>
On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley wrote:
>> Do this, but with the name vect_math.S. Don't use SLEEF headers in the
>> build. I think you can do this with no build-time dependency on SLEEF at all
>> if you load the library lazily at runtime.
>>
&g
On Thu, 30 Nov 2023 11:46:58 GMT, Andrew Haley wrote:
> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
I guess this will live only in os_linux and os_bsd because the Windows compiler
won't like it AFAIK.
-
PR Comment: https://git.openjdk.org/
On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 30 Nov 2023 09:35:04 GMT, Magnus Ihse Bursie wrote:
> This version looks much better, thank you! I guess cflags/SVE_CFLAGS is an
> okay-ish solution.
>
> I'm still not 100% happy though, but it might be due to my limited
> understanding. Let me write down a few numbered statements and
On Wed, 29 Nov 2023 08:33:33 GMT, Andrew Haley wrote:
>> When building linux-aarch64 at Oracle using jib,
>> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
>> building natively or cross compiling (on linux-x64). Among other things this
>> h
On Wed, 29 Nov 2023 02:25:20 GMT, Mikael Vidstedt wrote:
> When building linux-aarch64 at Oracle using jib,
> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
> building natively or cross compiling (on linux-x64). Among other things this
> has the (harmless) effect of
On Tue, 28 Nov 2023 01:37:01 GMT, Xiaohong Gong wrote:
>>> In fact, I am not even sure why it seems to the PR author to be a good idea
>>> to let the default be dependent on the build machine at all. My personal
>>> opinion is that it would be better to select either "SVE enabled" or "SVE
>>>
On Mon, 27 Nov 2023 15:22:32 GMT, Magnus Ihse Bursie wrote:
> In fact, I am not even sure why it seems to the PR author to be a good idea
> to let the default be dependent on the build machine at all. My personal
> opinion is that it would be better to select either "SVE enabled" or "SVE
>
On Mon, 27 Nov 2023 14:59:23 GMT, Magnus Ihse Bursie wrote:
> You still need to separate out the SVE detection from the libsleef code, and
> provide a way to enable/disable it from the configure command line.
Why? I don't think this should be a build-time option at all, because it puts
the
On Mon, 27 Nov 2023 07:38:28 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
On Mon, 27 Nov 2023 01:06:21 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-vmath.m4 line 94:
>>
>>> 92: # Check the ARM SVE feature
>>> 93: SVE_CFLAGS="-march=armv8-a+sve"
>>> 94:
>>
>> What's this about? We're building a standard binary, and all SVE detection
>> is to
On Thu, 23 Nov 2023 16:31:22 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
On Thu, 23 Nov 2023 16:31:22 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 23 Nov 2023 09:09:37 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See
On Wed, 22 Nov 2023 01:52:51 GMT, Xiaohong Gong wrote:
> > Have you considered the possibility of copying the sleef source to the
> > OpenJDK repository and thereby it becomes part of the build process? I
> > don't know how straightforward that is technically and IANAL but I think
> > it's
On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley wrote:
> A bug in GCC causes shared libraries linked with -ffast-math to disable
> denormal arithmetic. This breaks Java's floating-point semantics.
>
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>
> One s
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Delete src/hotspot/os/linux/.#os_linux.cpp
-
Changes:
- all: https://git.openjdk.
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 42 commits:
- Merge
- Fix header
- Move IEE subnormal check to globalDefiniti
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
>> or caller option is empty string.
>>
>>
On Fri, 27 Oct 2023 11:59:59 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
On Tue, 31 Oct 2023 14:42:22 GMT, Robbin Ehn wrote:
>> The parse_caller_options handles the NULL case, so I forgot about the early
>> bailout.
>>
>> for (p = caller_options; p != NULL; ) {
>> }
>> *iop = '\0';
>>
>>
>> Sorry.
>
> Sorry again, long day:
>
> struct hsdis_app_data
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 string.
>
> Tested
On Thu, 26 Oct 2023 15:41:35 GMT, Thomas Stuefe wrote:
> This looks good to me.
>
> One suggestion: to reduce code duplication and to make the code a bit safer
> against accidental returns prior to fesetenv, I would have used a mark object
> like this:
Thanks. I take your point, but I think
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Fix header
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10661/files
- new:
On Thu, 26 Oct 2023 17:42:39 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove accidental include
>
> make/test/JtregNativeH
On Thu, 26 Oct 2023 15:59:08 GMT, Thomas Stuefe wrote:
> One more thought, it would be good to add the FTZ_mode_enabled check to
> `os::run_periodic_checks()`.
>
> We already do signal handler checks there, and it is the right place to check
> for "global things third party native code may
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Move IEE subnormal check to globalDefinitions
-
Changes:
- all: https://git.o
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Remove accidental include
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10661
On Wed, 25 Oct 2023 18:26:23 GMT, Aleksey Shipilev wrote:
> The comment in the block says:
>
> ```
> # do this on s390x also for libjvm (where serviceability agent is not
> supported)
> ```
>
> ...which I read as "if we enable this, SA would break". Does
> `serviceability/sa` pass in
On Wed, 25 Oct 2023 17:26:13 GMT, Andrew Haley wrote:
> On s390x only, HotSpot is built by GCC with -ffunction-sections.
> This means that debug helpers such as ps() and pfl() are not available. These
> helpers are extremely useful in debugging, so it makes no sense to omit them
>
On Wed, 25 Oct 2023 18:30:36 GMT, Aleksey Shipilev wrote:
> The block in question also works when link-time gc is enabled, which is only
> so on s390x by default:
>
> https://github.com/openjdk/jdk/blob/d96f38b80c1606b54b9f3dbfe9717ab9653a0605/make/autoconf/jdk-options.m4#L105-L110
It does,
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Duh
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10661/files
- new: https
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Remove dead code
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10661/files
On Wed, 18 Oct 2023 19:13:40 GMT, Vladimir Ivanov wrote:
> > Meta-question and apologies if this was covered before, but why is this
> > logic being added to stubRoutines.cpp?
>
> Because tha'ts where @iwanowww asked me to put it. I don't much care.
Hi @iwanowww , do you have any suggestion
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 36 commits:
- Merge from head
- s/Denormal/Subnormal/g
- Review feedback
On Thu, 19 Oct 2023 09:31:36 GMT, Andrew Haley wrote:
>> src/hotspot/os/linux/os_linux.cpp line 1853:
>>
>>> 1851:
>>> 1852: #ifndef IA32
>>> 1853: // Quickly test to make sure denormals are correctly handled.
>>
>> Nit: I recommend u
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
s/Denormal/Subnormal/g
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10661/fil
On s390x only, HotSpot is built by GCC with -ffunction-sections.
This means that debug helpers such as ps() and pfl() are not available. These
helpers are extremely useful in debugging, so it makes no sense to omit them
from debug builds.
-
Commit messages:
- 8318834: Debug builds
On Thu, 19 Oct 2023 01:26:43 GMT, Joe Darcy wrote:
>> Andrew Haley has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Review feedback
>> - Merge branch 'JDK-8295159' of https://github.com/theRe
On Wed, 18 Oct 2023 08:50:13 GMT, Andrew Haley wrote:
>> Meta-question and apologies if this was covered before, but why is this
>> logic being added to stubRoutines.cpp?
>
>> Meta-question and apologies if this was covered before, but why is this
>> logic bein
On Wed, 18 Oct 2023 09:31:22 GMT, Daniel Jeliński wrote:
> hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
> absent on Ubuntu (installed separately, and under a different path), so
> removing the include fixes the hsdis compilation on Ubuntu.
>
> Additionally, the
On Wed, 18 Oct 2023 00:01:20 GMT, David Holmes wrote:
> Meta-question and apologies if this was covered before, but why is this logic
> being added to stubRoutines.cpp?
Because tha'ts where @iwanowww asked me to put it. I don't much care.
-
PR Comment:
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with three additional
commits since the last revision:
- Review feedback
- Merge branch 'JDK-8295159' of https://github.com/theRealAph
On Tue, 17 Oct 2023 02:15:45 GMT, David Holmes wrote:
>> Andrew Haley has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Comments only.
>> - Review feedback
>
> src/hotspot/cpu/x86/macroAss
he best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
- Comments only.
- Review feedback
-
Changes:
- all: https://git.openjdk.
On Wed, 11 Oct 2023 18:08:55 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add TestDenormalDouble.java
>
> test/hotspot/jtreg/compiler/floatingpoint/li
On Wed, 11 Oct 2023 19:51:34 GMT, Vladimir Ivanov wrote:
> And I was confused at first why there's a volatile on `tresh`. A short
> comment describing the intentions would definitely help here.
OK.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/10661#discussion_r1356952291
On Wed, 11 Oct 2023 17:57:27 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add TestDenormalDouble.java
>
> src/hotspot/os/bsd/os_bsd.cpp line 977:
>
1 - 100 of 191 matches
Mail list logo
