On Fri, 23 Feb 2024 22:05:44 GMT, Erik Joelsson wrote:
> And then I think this will actually help Julian, since we'll push the
> microsoft strangeness away in a separate file
Thanks! Though I do first need to rebase on top of it and fix all the merge
conflicts first...
(Thinking about it,
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
>
On Fri, 23 Feb 2024 21:40:22 GMT, Magnus Ihse Bursie wrote:
>> There is not much overlap on how linking is done on Windows on one hand, and
>> on all Unix platforms on the other. This makes Link.gmk basically consists
>> of two parts, each in it own half of if statements, and the few common
On Fri, 23 Feb 2024 21:31:09 GMT, Magnus Ihse Bursie wrote:
> Ok, fair enough, I should have phrase this split as "Microsoft toolchain" and
> "everything else". The point is that linking is vastly different on Windows
> than on other platforms. Our efforts to force "lib" to behave as "ar" etc
> There is not much overlap on how linking is done on Windows on one hand, and
> on all Unix platforms on the other. This makes Link.gmk basically consists of
> two parts, each in it own half of if statements, and the few common parts are
> artificially shoehorned in to fit both sides.
>
> The
On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie wrote:
> There is not much overlap on how linking is done on Windows on one hand, and
> on all Unix platforms on the other. This makes Link.gmk basically consists of
> two parts, each in it own half of if statements, and the few common parts
On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie wrote:
> There is not much overlap on how linking is done on Windows on one hand, and
> on all Unix platforms on the other. This makes Link.gmk basically consists of
> two parts, each in it own half of if statements, and the few common parts
On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie wrote:
> There is not much overlap on how linking is done on Windows on one hand, and
> on all Unix platforms on the other. This makes Link.gmk basically consists of
> two parts, each in it own half of if statements, and the few common parts
> There is not much overlap on how linking is done on Windows on one hand, and
> on all Unix platforms on the other. This makes Link.gmk basically consists of
> two parts, each in it own half of if statements, and the few common parts are
> artificially shoehorned in to fit both sides.
>
> The
This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
`COMPAT` locale data was introduced for applications' migratory purposes
transitioning to `CLDR`. It is becoming a technical debt and now is the time to
remove it (we've been emitting a warning at JVM startup since
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
On Fri, 23 Feb 2024 15:18:11 GMT, Magnus Ihse Bursie wrote:
> At the end of a COMPARE_BUILD run with a patch file, the build tries to
> revert the patch to restore the workspace as it was. On some versions of
> patch, this fails if one or more files were deleted, causing the makefile to
>
On Fri, 23 Feb 2024 15:18:11 GMT, Magnus Ihse Bursie wrote:
> At the end of a COMPARE_BUILD run with a patch file, the build tries to
> revert the patch to restore the workspace as it was. On some versions of
> patch, this fails if one or more files were deleted, causing the makefile to
>
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
There is not much overlap on how linking is done on Windows on one hand, and on
all Unix platforms on the other. This makes Link.gmk basically consists of two
parts, each in it own half of if statements, and the few common parts are
artificially shoehorned in to fit both sides.
The code will
The idea of setting up general "toolchains" in the native build was good, but
it turned out that we really only need a single toolchain, with a single twist:
if it should use CC or CPP to link. This is better described by a specific
argument to SetupNativeCompilation, LANG := C++ or LANG := C
At the end of a COMPARE_BUILD run with a patch file, the build tries to revert
the patch to restore the workspace as it was. On some versions of patch, this
fails if one or more files were deleted, causing the makefile to abort just
before the actual comparison. :-(
Reverting the patch is just
On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
> have no need for mapfiles anymore in the JDK project. The mapfile handling
> was inherited from the old build system and is just messy. We should remove
On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
> have no need for mapfiles anymore in the JDK project. The mapfile handling
> was inherited from the old build system and is just messy. We should remove
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234),
On Thu, 22 Feb 2024 13:36:23 GMT, Magnus Ihse Bursie wrote:
> I just realized I could keep an extremely simplified linker script
> ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the
> exported symbols, and keeping `__bss_start` and friends local. This further
> minimizes
On Thu, 22 Feb 2024 15:26:34 GMT, Magnus Ihse Bursie wrote:
>> I see, seems like it's an unfortunate situation where a fix is hard or even
>> impossible. If we file a gcc bug for it now, it'll get fixed in some
>> insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to
>>
Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
have no need for mapfiles anymore in the JDK project. The mapfile handling was
inherited from the old build system and is just messy. We should remove it to
make the linking process more clear.
Note that this PR is
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, even if that behavior seemed odd.
>
> Now let's try to fix
On Fri, 23 Feb 2024 08:18:17 GMT, Daniel Jeliński wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use #pragma instead of HIDDEN define
>
> src/hotspot/share/oops/accessBackend.cpp line 40:
>
>> 38: #if
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234),
On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie wrote:
> > We had the PR in our SAP internal build/test queue, so issues seen with it.
>
> What issues did you see? Or was that a typo for "no issues"?
Sorry Magnus, tests were fine no issues were observed.
-
PR Comment:
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234),
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in
> 2013. Even back then the use of mapfiles in
On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie wrote:
> Just to confirm: this PR passes tier 1-5.
We had the PR in our SAP internal build/test queue, so issues seen with it.
-
PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277
On Fri, 23 Feb 2024 11:41:04 GMT, Magnus Ihse Bursie wrote:
>> cc @karianna @gdams, is there a Windows/AArch64 owner?
>>
>>> Or maybe it's time to retire the Windows/aarch64 port
>>
>> I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it
>> a few more years I
On Fri, 23 Feb 2024 11:06:04 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any
On Fri, 23 Feb 2024 11:35:19 GMT, Bernhard Urban-Forster
wrote:
>> Ah, right, there is a Windows/aarch64 port. Forgot about it. :(
>>
>> I don't know who maintains/cares about that port anymore. Pinging @mo-beck
>> @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you
>>
On Fri, 23 Feb 2024 11:11:19 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
>>
>>> 120: }
>>> 121:
>>> 122: void das1(uintptr_t insn) {
>>
>> Doesn't this need to be exported for debugging on Windows-Aarch64?
>
> Ah, right, there is a
On Thu, 22 Feb 2024 22:18:59 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove jvmci globals
>
> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
>
>> 120: }
>> 121:
>> 122:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, even if that behavior seemed odd.
>
> Now let's try to fix
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234),
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234),
39 matches
Mail list logo
