On Wed, 3 Apr 2024 02:28:08 GMT, Julian Waters wrote:
>> https://github.com/openjdk/jdk/pull/18586
>
> @kimbarrett I've been doing things to permit gcc/Windows, not clang. clang
> has too many different distributions on Windows for me to settle on one, and
> generalising all of them to be able
Hi all,
This patch merges the class `GenMarkSweep` into `MarkSweep`. Just simply move.
It may be better to merge the class `DeadSpacer` and `Compacter` into
`MarkSweep` and then rename `MarkSweep`. The `MarkSweep` will be renamed at
[JDK-8329521](https://bugs.openjdk.org/browse/JDK-8329521).
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote:
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window.cpp
>> - Label to empty line in
On Tue, 2 Apr 2024 20:10:12 GMT, Kim Barrett wrote:
>> I'm waiting for a bunch of tests to complete, so decided to just take that
>> issue.
>
> https://github.com/openjdk/jdk/pull/18586
@kimbarrett I've been doing things to permit gcc/Windows, not clang. clang has
too many different
This is a retake on https://github.com/openjdk/jdk/pull/15096.
I tried to fix the remaining issues in that PR, but could not push them. In the
end, it seemed easier to create a new branch in my own personal fork.
The majority of the work in this PR has been done by @TheShermanTanker. I have
On Tue, 2 Apr 2024 11:35:44 GMT, Joachim Kern wrote:
>> linux macos and now Aix use this file.
>
> Who is able to explain if
> `#if defined(LINUX) || defined(_ALLBSD_SOURCE) || defined(_AIX)`
> in this file is equivalent to
> `#if 1`
See my other comments and
On Tue, 2 Apr 2024 17:01:07 GMT, Kim Barrett wrote:
>> https://bugs.openjdk.org/browse/JDK-8329546 - I can take this if nobody else
>> grabs it soon.
>
> I'm waiting for a bunch of tests to complete, so decided to just take that
> issue.
https://github.com/openjdk/jdk/pull/18586
On Tue, 2 Apr 2024 16:29:07 GMT, Alan Bateman wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove use of jdk.crypto.ec
>
> src/java.base/share/classes/module-info.java line 265:
>
>> 263:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
> thrpt3 6443.934 ± 6.491 ops/s
>
On Tue, 2 Apr 2024 16:52:04 GMT, Kim Barrett wrote:
>> There was at one time an attempt at a gcc/Solaris port, but I think it was
>> never completed, and most vestiges removed. More recently, @TheShermanTanker
>> has been doing stuff to permit clang/Windows, and clang-based builds use
>> this
On Tue, 2 Apr 2024 16:41:40 GMT, Kim Barrett wrote:
>> I cannot answer this question.
>> If this line is now obsolete it was also obsolete before including AIX,
>> because AIX didn't use this file beforehand.
>
> There was at one time an attempt at a gcc/Solaris port, but I think it was
> never
On Tue, 2 Apr 2024 11:20:49 GMT, Joachim Kern wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 62:
>>
>>> 60: #include
>>> 61:
>>> 62: #if defined(LINUX) || defined(_ALLBSD_SOURCE) || defined(_AIX)
>>
>> What else is left? Could we just remove this line altogether now?
>
On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
Performance. Before:
Benchmark(algorithm) (dataSize) (keyLength)
(provider) Mode Cnt ScoreError Units
SignatureBench.ECDSA.signSHA256withECDSA1024 256
thrpt3 6443.934 ± 6.491 ops/s
SignatureBench.ECDSA.sign
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window.cpp
>> - Label to empty line in
On Tue, 2 Apr 2024 14:48:49 GMT, Martin Doerr wrote:
>> My question is, do we need this block, because now already configure warns
>> about an outdated compiler, or is a warning to weak and we want to force
>> this error here?
>
> I think that building with xlc 16 is no longer possible because
On Tue, 2 Apr 2024 11:22:54 GMT, Joachim Kern wrote:
>> I'd prefer having less AIX specific parts in this file. Can this be moved
>> somewhere else? Or maybe combine it with the AIX code above?
>
> My question is, do we need this block, because now already configure warns
> about an outdated
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 use of the "DLL_ENTRY", so I removed it.
>>
>>
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote:
> Currently a lot of code is duplicated between SetupJdkExecutable and
> SetupJdkLibrary. Furthermore, some functionality is still missing from
> SetupJdkExecutable that is present in SetupJdkLibrary. These functions also
> have not
> Currently a lot of code is duplicated between SetupJdkExecutable and
> SetupJdkLibrary. Furthermore, some functionality is still missing from
> SetupJdkExecutable that is present in SetupJdkLibrary. These functions also
> have not had their documentation properly updated as they have evolved.
On Thu, 28 Mar 2024 18:22:27 GMT, Magnus Ihse Bursie wrote:
> For some reason, I missed adding the new standard header for SetupJdkLibrary
> in java.management and jdk.management. I also missed to remove a now
> superfluous CFLAGS_JDKLIB in libmanagement_ext.
This pull request has now been
On Fri, 22 Mar 2024 12:26:25 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cpp
>
>
On Sat, 20 Jan 2024 00:38:04 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Tue, 2 Apr 2024 11:28:30 GMT, Joachim Kern wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 103:
>>
>>> 101: #endif
>>> 102:
>>> 103: #if !defined(LINUX) && !defined(_ALLBSD_SOURCE) && !defined(_AIX)
>>
>> I believe this whole section can be removed now.
>>
>> At least
On Fri, 29 Mar 2024 08:06:01 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Thu, 28 Mar 2024 17:33:29 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 83:
>>
>>> 81: #error "xlc version not supported, macro __open_xl_version__ not
>>> found"
>>> 82: #endif
>>> 83: #endif // AIX
>>
>> This `#ifdef _AIX` might be obsolete,
On Fri, 29 Mar 2024 07:39:06 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Fri, 29 Mar 2024 07:25:30 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Fri, 29 Mar 2024 07:19:33 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/aix/loadlib_aix.cpp line 120:
>>
>>> 118: (lm->is_in_vm ? '*' : ' '),
>>> 119: (uintptr_t)lm->text, (uintptr_t)lm->text + lm->text_len,
>>> 120: (uintptr_t)lm->data, (uintptr_t)lm->data + lm->data_len,
>>
On Thu, 28 Mar 2024 18:41:03 GMT, Paul Sandoz wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
> Hamlin, thank you for working on this. I think integrating a sub-set of SLEEF
> is valuable (not all
On Fri, 29 Mar 2024 07:21:43 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Tue, 2 Apr 2024 09:14:10 GMT, Joachim Kern wrote:
>> Other than that, and kind of depending on your answer: How important is it
>> that we catch every use of the original malloc? Can be safely mix the
>> original malloc with vec_malloc if logging is not involved?
>>
>> I am asking, because
On Fri, 29 Mar 2024 07:59:05 GMT, Thomas Stuefe wrote:
>> While looking at this, I noticed that my question in
>> https://github.com/openjdk/jdk/pull/14146#discussion_r1207078176 and
>> followups had never been answered. Do you know the answers now?
>>
>> Quoting myself:
>>
>>> So, we do
On Fri, 29 Mar 2024 05:23:57 GMT, Julian Waters wrote:
> > The rest of the changes are needed because of using
> > utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about
> > ill formatted printf
>
> Did you mean compilerWarnings_gcc.hpp?
Yes, you're right. I fixed it.
39 matches
Mail list logo
