Re: Supporting alternative toolchains on Windows

[Julian Waters]

I meant in toolchain.m4, which allows gcc for macOS

best regards,
Julian

On Sat, Mar 12, 2022 at 4:32 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2022-03-11 20:02, Julian Waters wrote:
>
> I understand the concerns, seems like I grossly underestimated the
> complexity such a task would entail. Though I would say the following can
> only really be known if it's already been implemented:
>
> Most likely there will be strange bugs with anything that requires
> OS interaction (like dll loading and whatsnot)
>
> To my knowledge the versions of said compilers that link against the
> universal CRT utilize exactly the same Windows APIs (And corresponding
> dlls) for OS related stuff that Visual C++ itself uses (Minus vcruntime,
> which is specific to MSVC), without any POSIX compatibility layers on top.
> I've tried rewiring the build system incrementally in the meantime on my
> end to see what areas would be of interest and it's now failing when
> hitting POSIX specific includes during make, hinting that (At least for
> gcc) compatibility has been traded for full native support for Windows APIs
> within the compiler, which may mitigate any issues slightly (That's also
> why I suggested initially to only allow for versions that link against the
> ucrt without any compatibility layers- Cygwin's toolchains which link
> against newlib and old MinGW binaries which link against msvcrt would just
> be an unnecessary headache). That said, whether aforementioned bugs will
> actually surface should the attempt be successful I don't really know yet
>
> Actually, I would seriously assume that any other compiler than VS
> on Windows will give much worse results.
> The VS compiler is battle-hardened. gcc and clang are only used by
> a very small enthusiastic hobbyist minority.
>
> The Windows ports of both compilers do keep the same optimizations and
> code generation quality as they do on other platforms from what I know
> though, it's mainly the linkers that have been modified to generate the PE
> format instead of the ELF on Linux. I digress, I don't have any results to
> show for this yet
>
> I'm not sure I get the part about macOS strictly mapping to clang. Isn't
> there the option to swap to using gcc for macOS?
>
> No, Apple removed that option years ago.
>
> /Magnus
>
>
> best regards,
> Julian
>
> On Sat, Mar 12, 2022 at 1:50 AM Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>>
>>
>> On 2022-03-11 14:34, Julian Waters wrote:
>>
>> Darn, seems like it'll be much harder than I expected. Since multiple
>> toolchains are supported for macOS and Linux, I assumed a slight patch
>> would help get it to work on Windows. Looking through the stuff in make
>> though, it appears a lot of the build system implicitly expects the
>> compiler for Windows to always be Visual C++, which doesn't really help
>> that much (Though the fact that we can exclude many versions of gcc, such
>> as Cygwin's and old MinGW binaries helps a lot). The build process for the
>> newer Windows ports of gcc are surprisingly similar to Visual C++ though
>> (Eg rc can be swapped out for windres) so this might hopefully be something
>> I can try exploring in the future (Gonna look a bit harder at make and
>> write what I can find back to this mailing list in the meantime). It'd be
>> interesting if benchmarks of the JVM compiled with different compilers on
>> Windows can be compared side by side on the off chance this becomes a
>> reality though
>>
>>
>> In theory OS and compiler toolchain are separate things. In practice, in
>> the JDK, they are not. There is basically a 1-to-1 mapping between
>> toolchain and OS:
>> Windows <-> Visual Studio
>> macOS <-> XCode/clang
>> linux <-> gcc
>>
>> (The one possible exception is that clang on linux is probably feasible.)
>>
>> After years and years on this, all kinds of assumptions has been
>> hard-coded, even if people try to do the right thing. But sometimes it is
>> not clear if you are checking for toolchain or os; perhaps when linking
>> with a specific library, or setting some define.
>>
>> Any attempt to change this is, as I said, a *huge* undertaking. *And*
>> there will be tons of negative consequences for the code base as a whole,
>> when trying to differentiate between toolchain and OS. So this will need to
>> be seriously considered.
>>
>> /Magnus
>>
>>
>> best regards,
>> Julian
>>
>> On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
>> magnus.ihse.bur...@oracle.com> wrote:
>>
>>> On 2022-03-11 12:55, Julian Waters wrote:
>>>
>>> > Hi all,
>>> >
>>> > How feasible would it be/much effort would it require to support
>>> compiling
>>> > with alternate toolchains on Windows besides Visual C++ (like the
>>> Windows
>>> > ports of clang and gcc) if we restrict the allowed toolchains to only
>>> those
>>> > that link against the ucrt? (Toolchains linking against the dated
>>> msvcrt
>>> > would present too many issues to work with)
>>>
>>> 

Re: RFR: 8283062: Uninitialized warnings in libgtest with GCC 11.2

[Jie Fu]

On Sat, 12 Mar 2022 03:26:29 GMT, Mikael Vidstedt  wrote:

> Background, from JBS:
> 
> In file included from 
> googletest-release-1.8.1/googletest/src/gtest-all.cc:42: 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc: In function 
> 'bool testing::internal::StackGrowsDown()': 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1224:24: error: 
> 'dummy' may be used uninitialized [-Werror=maybe-uninitialized] 
>  1224 | StackLowerThanAddress(, ); 
>   | ~^ 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1214:13: note: by 
> argument 1 of type 'const void*' to 'void 
> testing::internal::StackLowerThanAddress(const void*, bool*)' declared here 
>  1214 | static void StackLowerThanAddress(const void* ptr, bool* result) { 
>   | ^ 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1222:7: note: 
> 'dummy' declared here 
>  1222 | int dummy;
> 
> 
> Details:
> 
> Since googletest is external code this change disable the relevant warning.
> 
> Testing:
> 
> tier1, builds-tier{2,3,4,5}

Looks reasonable to me.

-

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7798

RFR: 8283062: Uninitialized warnings in libgtest with GCC 11.2

[Mikael Vidstedt]

Background, from JBS:

In file included from googletest-release-1.8.1/googletest/src/gtest-all.cc:42: 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc: In function 'bool 
testing::internal::StackGrowsDown()': 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1224:24: error: 
'dummy' may be used uninitialized [-Werror=maybe-uninitialized] 
 1224 | StackLowerThanAddress(, ); 
  | ~^ 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1214:13: note: by 
argument 1 of type 'const void*' to 'void 
testing::internal::StackLowerThanAddress(const void*, bool*)' declared here 
 1214 | static void StackLowerThanAddress(const void* ptr, bool* result) { 
  | ^ 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1222:7: note: 
'dummy' declared here 
 1222 | int dummy;


Details:

Since googletest is external code this change disable the relevant warning.

Testing:

tier1, builds-tier{2,3,4,5}

-

Commit messages:
 - 8283062: Uninitialized warnings in libgtest with GCC 11.2

Changes: https://git.openjdk.java.net/jdk/pull/7798/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7798=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283062
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7798/head:pull/7798

PR: https://git.openjdk.java.net/jdk/pull/7798

RFR: JDK-8236128: Allow jpackage create installers for services

[Alexey Semenyuk]

Implementation of [JDK-8275062: "Allow jpackage create installers for 
services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
 CSR

-

Commit messages:
 - Whitespace cleanup
 - Whitespace cleanup
 - JDK-8236128: Allow jpackage create installers for services
 - Sync l10n files. Fix copyright year
 - Minor formatting fix
 - Merge fix
 - Merge fixed
 - Merge branch 'master' into JDK-8236128
 - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk 
into JDK-8236128
 - Bugfix
 - ... and 110 more: 
https://git.openjdk.java.net/jdk/compare/cd234f5d...0ff8e9aa

Changes: https://git.openjdk.java.net/jdk/pull/7793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7793=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236128
  Stats: 2769 lines in 64 files changed: 2508 ins; 121 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7793/head:pull/7793

PR: https://git.openjdk.java.net/jdk/pull/7793

Re: Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 20:02, Julian Waters wrote:
I understand the concerns, seems like I grossly underestimated the 
complexity such a task would entail. Though I would say the following 
can only really be known if it's already been implemented:


        Most likely there will be strange bugs with anything that 
requires OS interaction (like dll loading and whatsnot)


To my knowledge the versions of said compilers that link against the 
universal CRT utilize exactly the same Windows APIs (And corresponding 
dlls) for OS related stuff that Visual C++ itself uses (Minus 
vcruntime, which is specific to MSVC), without any POSIX compatibility 
layers on top. I've tried rewiring the build system incrementally in 
the meantime on my end to see what areas would be of interest and it's 
now failing when hitting POSIX specific includes during make, hinting 
that (At least for gcc) compatibility has been traded for full native 
support for Windows APIs within the compiler, which may mitigate any 
issues slightly (That's also why I suggested initially to only allow 
for versions that link against the ucrt without any compatibility 
layers- Cygwin's toolchains which link against newlib and old MinGW 
binaries which link against msvcrt would just be an unnecessary 
headache). That said, whether aforementioned bugs will actually 
surface should the attempt be successful I don't really know yet


        Actually, I would seriously assume that any other compiler 
than VS on Windows will give much worse results.
        The VS compiler is battle-hardened. gcc and clang are only 
used by a very small enthusiastic hobbyist minority.


The Windows ports of both compilers do keep the same optimizations and 
code generation quality as they do on other platforms from what I know 
though, it's mainly the linkers that have been modified to generate 
the PE format instead of the ELF on Linux. I digress, I don't have any 
results to show for this yet


I'm not sure I get the part about macOS strictly mapping to clang. 
Isn't there the option to swap to using gcc for macOS?

No, Apple removed that option years ago.

/Magnus


best regards,
Julian

On Sat, Mar 12, 2022 at 1:50 AM Magnus Ihse Bursie 
 wrote:




On 2022-03-11 14:34, Julian Waters wrote:

Darn, seems like it'll be much harder than I expected. Since
multiple toolchains are supported for macOS and Linux, I assumed
a slight patch would help get it to work on Windows. Looking
through the stuff in make though, it appears a lot of the build
system implicitly expects the compiler for Windows to always be
Visual C++, which doesn't really help that much (Though the fact
that we can exclude many versions of gcc, such as Cygwin's and
old MinGW binaries helps a lot). The build process for the newer
Windows ports of gcc are surprisingly similar to Visual C++
though (Eg rc can be swapped out for windres) so this might
hopefully be something I can try exploring in the future (Gonna
look a bit harder at make and write what I can find back to this
mailing list in the meantime). It'd be interesting if benchmarks
of the JVM compiled with different compilers on Windows can be
compared side by side on the off chance this becomes a reality though


In theory OS and compiler toolchain are separate things. In
practice, in the JDK, they are not. There is basically a 1-to-1
mapping between toolchain and OS:
Windows <-> Visual Studio
macOS <-> XCode/clang
linux <-> gcc

(The one possible exception is that clang on linux is probably
feasible.)

After years and years on this, all kinds of assumptions has been
hard-coded, even if people try to do the right thing. But
sometimes it is not clear if you are checking for toolchain or os;
perhaps when linking with a specific library, or setting some define.

Any attempt to change this is, as I said, a *huge* undertaking.
*And* there will be tons of negative consequences for the code
base as a whole, when trying to differentiate between toolchain
and OS. So this will need to be seriously considered.

/Magnus



best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie
 wrote:

On 2022-03-11 12:55, Julian Waters wrote:

> Hi all,
>
> How feasible would it be/much effort would it require to
support compiling
> with alternate toolchains on Windows besides Visual C++
(like the Windows
> ports of clang and gcc) if we restrict the allowed
toolchains to only those
> that link against the ucrt? (Toolchains linking against the
dated msvcrt
> would present too many issues to work with)

That'd be a huge undertaking. And any such patch would only
be accepted
into the code base if the organization behinded appeared
trustworthy in
their long-term commitment to keeping it 

Re: Supporting alternative toolchains on Windows

[Julian Waters]

I understand the concerns, seems like I grossly underestimated the
complexity such a task would entail. Though I would say the following can
only really be known if it's already been implemented:

Most likely there will be strange bugs with anything that requires
OS interaction (like dll loading and whatsnot)

To my knowledge the versions of said compilers that link against the
universal CRT utilize exactly the same Windows APIs (And corresponding
dlls) for OS related stuff that Visual C++ itself uses (Minus vcruntime,
which is specific to MSVC), without any POSIX compatibility layers on top.
I've tried rewiring the build system incrementally in the meantime on my
end to see what areas would be of interest and it's now failing when
hitting POSIX specific includes during make, hinting that (At least for
gcc) compatibility has been traded for full native support for Windows APIs
within the compiler, which may mitigate any issues slightly (That's also
why I suggested initially to only allow for versions that link against the
ucrt without any compatibility layers- Cygwin's toolchains which link
against newlib and old MinGW binaries which link against msvcrt would just
be an unnecessary headache). That said, whether aforementioned bugs will
actually surface should the attempt be successful I don't really know yet

Actually, I would seriously assume that any other compiler than VS
on Windows will give much worse results.
The VS compiler is battle-hardened. gcc and clang are only used by
a very small enthusiastic hobbyist minority.

The Windows ports of both compilers do keep the same optimizations and code
generation quality as they do on other platforms from what I know though,
it's mainly the linkers that have been modified to generate the PE format
instead of the ELF on Linux. I digress, I don't have any results to show
for this yet

I'm not sure I get the part about macOS strictly mapping to clang. Isn't
there the option to swap to using gcc for macOS?

best regards,
Julian

On Sat, Mar 12, 2022 at 1:50 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
>
> On 2022-03-11 14:34, Julian Waters wrote:
>
> Darn, seems like it'll be much harder than I expected. Since multiple
> toolchains are supported for macOS and Linux, I assumed a slight patch
> would help get it to work on Windows. Looking through the stuff in make
> though, it appears a lot of the build system implicitly expects the
> compiler for Windows to always be Visual C++, which doesn't really help
> that much (Though the fact that we can exclude many versions of gcc, such
> as Cygwin's and old MinGW binaries helps a lot). The build process for the
> newer Windows ports of gcc are surprisingly similar to Visual C++ though
> (Eg rc can be swapped out for windres) so this might hopefully be something
> I can try exploring in the future (Gonna look a bit harder at make and
> write what I can find back to this mailing list in the meantime). It'd be
> interesting if benchmarks of the JVM compiled with different compilers on
> Windows can be compared side by side on the off chance this becomes a
> reality though
>
>
> In theory OS and compiler toolchain are separate things. In practice, in
> the JDK, they are not. There is basically a 1-to-1 mapping between
> toolchain and OS:
> Windows <-> Visual Studio
> macOS <-> XCode/clang
> linux <-> gcc
>
> (The one possible exception is that clang on linux is probably feasible.)
>
> After years and years on this, all kinds of assumptions has been
> hard-coded, even if people try to do the right thing. But sometimes it is
> not clear if you are checking for toolchain or os; perhaps when linking
> with a specific library, or setting some define.
>
> Any attempt to change this is, as I said, a *huge* undertaking. *And*
> there will be tons of negative consequences for the code base as a whole,
> when trying to differentiate between toolchain and OS. So this will need to
> be seriously considered.
>
> /Magnus
>
>
> best regards,
> Julian
>
> On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> On 2022-03-11 12:55, Julian Waters wrote:
>>
>> > Hi all,
>> >
>> > How feasible would it be/much effort would it require to support
>> compiling
>> > with alternate toolchains on Windows besides Visual C++ (like the
>> Windows
>> > ports of clang and gcc) if we restrict the allowed toolchains to only
>> those
>> > that link against the ucrt? (Toolchains linking against the dated msvcrt
>> > would present too many issues to work with)
>>
>> That'd be a huge undertaking. And any such patch would only be accepted
>> into the code base if the organization behinded appeared trustworthy in
>> their long-term commitment to keeping it working.
>>
>> /Magnus
>>
>>
>>
>

Re: RFR: 8283017: GHA: Workflows break with update release versions

[Magnus Ihse Bursie]

On Fri, 11 Mar 2022 09:27:55 GMT, Aleksey Shipilev  wrote:

> Current GHA workflow only takes `VERSION_FEATURE` to deduce the bundle names, 
> which means the test jobs in GHA workflows are unable to run when update 
> releases have versions beyond just 11, 17, 18. 
> 
> For example, in JDK 18u GHA runs, build step produce:
> 
> 
> Creating jdk-18.0.1-internal+0_linux-x64_bin.tar.gz
> Creating jdk-18.0.1-internal+0_linux-x64_bin-symbols.tar.gz
> Creating jdk-18.0.1-internal+0_linux-x64_bin-tests-demos.tar.gz
> 
> 
> Persist step fails to find it:
> 
> 
> Warning: No files were found with the provided path: 
> jdk/build/linux-x64/bundles/jdk-18-internal+0_linux-x64_bin.tar.gz
> 
> 
> ...because it looks for "18", not "18.0.1".
> 
> 17u and 11u hacked the GHA workflow to get tests to work (see 
> [JDK-8276130](https://bugs.openjdk.java.net/browse/JDK-8276130)), but this 
> would keep breaking in update releases as 19.0.1, 20.0.1, etc. fork out of 
> the mainline. We should instead fix that in the mainline workflow config.
> 
> Additional testing:
>  - [x] GHA passes with "fake" 19.0.1
>  - [ ] GHA passes with "normal" 19

Marked as reviewed by ihse (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7785

Re: Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 18:18, Thomas Stüfe wrote:

As Dalibor wrote, I would not expect too many performance surprises.


Actually, I would seriously assume that any other compiler than VS on 
Windows will give much worse results. The VS compiler is 
battle-hardened. Gcc and clang is only used by a very small enthusiastic 
hobbyist minority. There is no reason to believe it will be even close 
to optimized. Most likely there will be strange bugs with anything that 
requires OS interaction (like dll loading and whatsnot), even if the 
basic code generation part of the compiler should be identical for all 
OSes running on the same CPU.




That said, a more pragmatic approach may be to create a shim layer for 
visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe" 
that translate VC++ options and paths to whatever toolchain you like. 
That way you don't have to touch the OpenJDK make at all. I know it 
works in principle since I have such a thing in the past, albeit for a 
different product and a different target toolchain.


But there is oh so much to "convert" in that case. Just try grepping for 
"pragma" in hotspot, for a start. :)


I seriously do not believe this approach would be any ounce simpler, at 
least not for the JDK.


I did actually start to try to get a "hybrid" mode working, where the 
Visual Studio CL compiler would be run using wine on linux. (This was 
previously not allowed by MS licence, but they changed it some years 
ago.) That'd had allowed for linux users to cross-compile to Windows, 
and make a quick check that you did not break the build. But even this 
small step -- keeping the Windows compiler, but running in a linux 
environment -- turned out to be so full of tricky details that I gave up 
on it.


/Magnus



I would not be surprised if such a thing exists already. It seems such 
an obvious idea.


Cheers, Thomas

On Fri, Mar 11, 2022 at 2:35 PM Julian Waters 
 wrote:


Darn, seems like it'll be much harder than I expected. Since multiple
toolchains are supported for macOS and Linux, I assumed a slight patch
would help get it to work on Windows. Looking through the stuff in
make
though, it appears a lot of the build system implicitly expects the
compiler for Windows to always be Visual C++, which doesn't really
help
that much (Though the fact that we can exclude many versions of
gcc, such
as Cygwin's and old MinGW binaries helps a lot). The build process
for the
newer Windows ports of gcc are surprisingly similar to Visual C++
though
(Eg rc can be swapped out for windres) so this might hopefully be
something
I can try exploring in the future (Gonna look a bit harder at make and
write what I can find back to this mailing list in the meantime).
It'd be
interesting if benchmarks of the JVM compiled with different
compilers on
Windows can be compared side by side on the off chance this becomes a
reality though

best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2022-03-11 12:55, Julian Waters wrote:
>
> > Hi all,
> >
> > How feasible would it be/much effort would it require to support
> compiling
> > with alternate toolchains on Windows besides Visual C++ (like
the Windows
> > ports of clang and gcc) if we restrict the allowed toolchains
to only
> those
> > that link against the ucrt? (Toolchains linking against the
dated msvcrt
> > would present too many issues to work with)
>
> That'd be a huge undertaking. And any such patch would only be
accepted
> into the code base if the organization behinded appeared
trustworthy in
> their long-term commitment to keeping it working.
>
> /Magnus
>
>
>

Re: Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 14:34, Julian Waters wrote:
Darn, seems like it'll be much harder than I expected. Since multiple 
toolchains are supported for macOS and Linux, I assumed a slight patch 
would help get it to work on Windows. Looking through the stuff in 
make though, it appears a lot of the build system implicitly expects 
the compiler for Windows to always be Visual C++, which doesn't really 
help that much (Though the fact that we can exclude many versions of 
gcc, such as Cygwin's and old MinGW binaries helps a lot). The build 
process for the newer Windows ports of gcc are surprisingly similar to 
Visual C++ though (Eg rc can be swapped out for windres) so this might 
hopefully be something I can try exploring in the future (Gonna look a 
bit harder at make and write what I can find back to this mailing list 
in the meantime). It'd be interesting if benchmarks of the JVM 
compiled with different compilers on Windows can be compared side by 
side on the off chance this becomes a reality though


In theory OS and compiler toolchain are separate things. In practice, in 
the JDK, they are not. There is basically a 1-to-1 mapping between 
toolchain and OS:

Windows <-> Visual Studio
macOS <-> XCode/clang
linux <-> gcc

(The one possible exception is that clang on linux is probably feasible.)

After years and years on this, all kinds of assumptions has been 
hard-coded, even if people try to do the right thing. But sometimes it 
is not clear if you are checking for toolchain or os; perhaps when 
linking with a specific library, or setting some define.


Any attempt to change this is, as I said, a *huge* undertaking. *And* 
there will be tons of negative consequences for the code base as a 
whole, when trying to differentiate between toolchain and OS. So this 
will need to be seriously considered.


/Magnus



best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie 
 wrote:


On 2022-03-11 12:55, Julian Waters wrote:

> Hi all,
>
> How feasible would it be/much effort would it require to support
compiling
> with alternate toolchains on Windows besides Visual C++ (like
the Windows
> ports of clang and gcc) if we restrict the allowed toolchains to
only those
> that link against the ucrt? (Toolchains linking against the
dated msvcrt
> would present too many issues to work with)

That'd be a huge undertaking. And any such patch would only be
accepted
into the code base if the organization behinded appeared
trustworthy in
their long-term commitment to keeping it working.

/Magnus

Re: Supporting alternative toolchains on Windows

[Dalibor Topic]

On 11.03.2022 18:18, Thomas Stüfe wrote:

As Dalibor wrote, I would not expect too many performance surprises.

That said, a more pragmatic approach may be to create a shim layer for
visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe" that
translate VC++ options and paths to whatever toolchain you like. That way
you don't have to touch the OpenJDK make at all. I know it works in
principle since I have such a thing in the past, albeit for a different
product and a different target toolchain.

I would not be surprised if such a thing exists already. It seems such an
obvious idea.


For clang there is https://clang.llvm.org/docs/UsersManual.html#clang-cl 
but I have not tried it myself. But then again the linker step might be 
problematic.


cheers,
dalibor topic



Cheers, Thomas

On Fri, Mar 11, 2022 at 2:35 PM Julian Waters 
wrote:


Darn, seems like it'll be much harder than I expected. Since multiple
toolchains are supported for macOS and Linux, I assumed a slight patch
would help get it to work on Windows. Looking through the stuff in make
though, it appears a lot of the build system implicitly expects the
compiler for Windows to always be Visual C++, which doesn't really help
that much (Though the fact that we can exclude many versions of gcc, such
as Cygwin's and old MinGW binaries helps a lot). The build process for the
newer Windows ports of gcc are surprisingly similar to Visual C++ though
(Eg rc can be swapped out for windres) so this might hopefully be something
I can try exploring in the future (Gonna look a bit harder at make and
write what I can find back to this mailing list in the meantime). It'd be
interesting if benchmarks of the JVM compiled with different compilers on
Windows can be compared side by side on the off chance this becomes a
reality though

best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:


On 2022-03-11 12:55, Julian Waters wrote:


Hi all,

How feasible would it be/much effort would it require to support

compiling

with alternate toolchains on Windows besides Visual C++ (like the

Windows

ports of clang and gcc) if we restrict the allowed toolchains to only

those

that link against the ucrt? (Toolchains linking against the dated

msvcrt

would present too many issues to work with)


That'd be a huge undertaking. And any such patch would only be accepted
into the code base if the organization behinded appeared trustworthy in
their long-term commitment to keeping it working.

/Magnus







--
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

Re: Supporting alternative toolchains on Windows

[Thomas Stüfe]

As Dalibor wrote, I would not expect too many performance surprises.

That said, a more pragmatic approach may be to create a shim layer for
visual studio compiler and linker, e.g. a fake "cl.exe" and "link.exe" that
translate VC++ options and paths to whatever toolchain you like. That way
you don't have to touch the OpenJDK make at all. I know it works in
principle since I have such a thing in the past, albeit for a different
product and a different target toolchain.

I would not be surprised if such a thing exists already. It seems such an
obvious idea.

Cheers, Thomas

On Fri, Mar 11, 2022 at 2:35 PM Julian Waters 
wrote:

> Darn, seems like it'll be much harder than I expected. Since multiple
> toolchains are supported for macOS and Linux, I assumed a slight patch
> would help get it to work on Windows. Looking through the stuff in make
> though, it appears a lot of the build system implicitly expects the
> compiler for Windows to always be Visual C++, which doesn't really help
> that much (Though the fact that we can exclude many versions of gcc, such
> as Cygwin's and old MinGW binaries helps a lot). The build process for the
> newer Windows ports of gcc are surprisingly similar to Visual C++ though
> (Eg rc can be swapped out for windres) so this might hopefully be something
> I can try exploring in the future (Gonna look a bit harder at make and
> write what I can find back to this mailing list in the meantime). It'd be
> interesting if benchmarks of the JVM compiled with different compilers on
> Windows can be compared side by side on the off chance this becomes a
> reality though
>
> best regards,
> Julian
>
> On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
> > On 2022-03-11 12:55, Julian Waters wrote:
> >
> > > Hi all,
> > >
> > > How feasible would it be/much effort would it require to support
> > compiling
> > > with alternate toolchains on Windows besides Visual C++ (like the
> Windows
> > > ports of clang and gcc) if we restrict the allowed toolchains to only
> > those
> > > that link against the ucrt? (Toolchains linking against the dated
> msvcrt
> > > would present too many issues to work with)
> >
> > That'd be a huge undertaking. And any such patch would only be accepted
> > into the code base if the organization behinded appeared trustworthy in
> > their long-term commitment to keeping it working.
> >
> > /Magnus
> >
> >
> >
>

Re: RFR: 8283017: GHA: Workflows break with update release versions

[Erik Joelsson]

On Fri, 11 Mar 2022 09:27:55 GMT, Aleksey Shipilev  wrote:

> Current GHA workflow only takes `VERSION_FEATURE` to deduce the bundle names, 
> which means the test jobs in GHA workflows are unable to run.
> 
> See for example JDK 18u GHA run:
> 
> Build step produce:
> 
> 
> Creating jdk-18.0.1-internal+0_linux-x64_bin.tar.gz
> Creating jdk-18.0.1-internal+0_linux-x64_bin-symbols.tar.gz
> Creating jdk-18.0.1-internal+0_linux-x64_bin-tests-demos.tar.gz
> 
> 
> Persist step fails to find it:
> 
> 
> Warning: No files were found with the provided path: 
> jdk/build/linux-x64/bundles/jdk-18-internal+0_linux-x64_bin.tar.gz
> 
> 
> ...because it looks for "18", not "18.0.1".
> 
> 17u and 11u hacked the GHA workflow to get tests to work (see 
> [JDK-8276130](https://bugs.openjdk.java.net/browse/JDK-8276130)), but this 
> would keep breaking in update releases as 19.0.1, 20.0.1, etc. fork out of 
> the mainline. We should instead fix that in the mainline workflow config.
> 
> Additional testing:
>  - [x] GHA passes with "fake" 19.0.1
>  - [ ] GHA passes with "normal" 19

Marked as reviewed by erikj (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7785

RFR: 8283017: GHA: Workflows break with update release versions

[Aleksey Shipilev]

Current GHA workflow only takes `VERSION_FEATURE` to deduce the bundle names, 
which means the test jobs in GHA workflows are unable to run.

See for example JDK 18u GHA run:

Build step produce:


Creating jdk-18.0.1-internal+0_linux-x64_bin.tar.gz
Creating jdk-18.0.1-internal+0_linux-x64_bin-symbols.tar.gz
Creating jdk-18.0.1-internal+0_linux-x64_bin-tests-demos.tar.gz


Persist step fails to find it:


Warning: No files were found with the provided path: 
jdk/build/linux-x64/bundles/jdk-18-internal+0_linux-x64_bin.tar.gz


...because it looks for "18", not "18.0.1".

17u and 11u hacked the GHA workflow to get tests to work (see 
[JDK-8276130](https://bugs.openjdk.java.net/browse/JDK-8276130)), but this 
would keep breaking in update releases as 19.0.1, 20.0.1, etc. fork out of the 
mainline. We should instead fix that in the mainline workflow config.

Additional testing:
 - [x] GHA passes with "fake" 19.0.1
 - [ ] GHA passes with "normal" 19

-

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7785/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7785=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283017
  Stats: 29 lines in 1 file changed: 18 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7785.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7785/head:pull/7785

PR: https://git.openjdk.java.net/jdk/pull/7785

Re: Supporting alternative toolchains on Windows

[Dalibor Topic]

On 11.03.2022 14:34, Julian Waters wrote:

Darn, seems like it'll be much harder than I expected. Since multiple
toolchains are supported for macOS and Linux, I assumed a slight patch
would help get it to work on Windows. Looking through the stuff in make
though, it appears a lot of the build system implicitly expects the
compiler for Windows to always be Visual C++, which doesn't really help
that much (Though the fact that we can exclude many versions of gcc, such
as Cygwin's and old MinGW binaries helps a lot). The build process for the
newer Windows ports of gcc are surprisingly similar to Visual C++ though
(Eg rc can be swapped out for windres) so this might hopefully be something
I can try exploring in the future (Gonna look a bit harder at make and
write what I can find back to this mailing list in the meantime). It'd be
interesting if benchmarks of the JVM compiled with different compilers on
Windows can be compared side by side on the off chance this becomes a
reality though


I wouldn't necessarily expect large differences between builds compiled 
with different C/C++ compilers on industry benchmarks like SpecJBB, 
since the JVM will spend most of its time executing code it JIT-compiled 
itself.


I think more interesting from a developer/CI perspective would be 
potential differences in compilation speed, but I would naively assume 
those to be dominated by the linker, rather than the compiler itself.


cheers,
dalibor topic



best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:


On 2022-03-11 12:55, Julian Waters wrote:


Hi all,

How feasible would it be/much effort would it require to support

compiling

with alternate toolchains on Windows besides Visual C++ (like the Windows
ports of clang and gcc) if we restrict the allowed toolchains to only

those

that link against the ucrt? (Toolchains linking against the dated msvcrt
would present too many issues to work with)


That'd be a huge undertaking. And any such patch would only be accepted
into the code base if the organization behinded appeared trustworthy in
their long-term commitment to keeping it working.

/Magnus





--
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

Re: Supporting alternative toolchains on Windows

[Julian Waters]

Darn, seems like it'll be much harder than I expected. Since multiple
toolchains are supported for macOS and Linux, I assumed a slight patch
would help get it to work on Windows. Looking through the stuff in make
though, it appears a lot of the build system implicitly expects the
compiler for Windows to always be Visual C++, which doesn't really help
that much (Though the fact that we can exclude many versions of gcc, such
as Cygwin's and old MinGW binaries helps a lot). The build process for the
newer Windows ports of gcc are surprisingly similar to Visual C++ though
(Eg rc can be swapped out for windres) so this might hopefully be something
I can try exploring in the future (Gonna look a bit harder at make and
write what I can find back to this mailing list in the meantime). It'd be
interesting if benchmarks of the JVM compiled with different compilers on
Windows can be compared side by side on the off chance this becomes a
reality though

best regards,
Julian

On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2022-03-11 12:55, Julian Waters wrote:
>
> > Hi all,
> >
> > How feasible would it be/much effort would it require to support
> compiling
> > with alternate toolchains on Windows besides Visual C++ (like the Windows
> > ports of clang and gcc) if we restrict the allowed toolchains to only
> those
> > that link against the ucrt? (Toolchains linking against the dated msvcrt
> > would present too many issues to work with)
>
> That'd be a huge undertaking. And any such patch would only be accepted
> into the code base if the organization behinded appeared trustworthy in
> their long-term commitment to keeping it working.
>
> /Magnus
>
>
>

Re: Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 12:55, Julian Waters wrote:


Hi all,

How feasible would it be/much effort would it require to support compiling
with alternate toolchains on Windows besides Visual C++ (like the Windows
ports of clang and gcc) if we restrict the allowed toolchains to only those
that link against the ucrt? (Toolchains linking against the dated msvcrt
would present too many issues to work with)


That'd be a huge undertaking. And any such patch would only be accepted 
into the code base if the organization behinded appeared trustworthy in 
their long-term commitment to keeping it working.


/Magnus

Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v5]

[Christian Hagedorn]

On Mon, 28 Feb 2022 16:22:25 GMT, Christian Hagedorn  
wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err 
>> files), it only prints the method with its parameters and a relative offset 
>> in the method:
>> 
>> Stack: [0x7f6e01739000,0x7f6e0183a000],  sp=0x7f6e01838110,  
>> free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, 
>> bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  
>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, 
>> JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were 
>> called from and sometimes almost impossible when there are multiple 
>> invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line 
>> number) to the native stack traces on Linux similar to what's already done 
>> on Windows (see 
>> [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x7f34fca18000,0x7f34fcb19000],  sp=0x7f34fcb17110,  
>> free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  
>> (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, 
>> bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  
>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  
>> (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  
>> (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, 
>> JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  
>> (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  
>> (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in 
>> DWARF - a standardized debugging format. This patch adds support for DWARF 
>> 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with 
>> x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still 
>> experimental and not generated for HotSpot. However, newer GCC version may 
>> soon generate DWARF 5 by default in which case this parser either needs to 
>> be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: 
>> https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. 
>> However, I tried to explain the steps from the DWARF spec directly in the 
>> code (method names, comments etc.). This allows to follow the code without 
>> the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more 
>> detail how a DWARF file is structured and how the parsing algorithm works to 
>> get to the filename and line number information. There are more class 
>> comments throughout the `elf.hpp` file about how different DWARF sections 
>> are structured and how the parsing algorithm needs to fetch the required 
>> information. Therefore, I will not repeat the exact workings of the 
>> algorithm here but refer to the code comments. I've tried to add as much 
>> information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code 
>> is almost always executed when already processing a VM error. Instead, the 
>> DWARF parser aims to just exit gracefully and possibly omit source 
>> information for a stack frame instead of risking to stop writing the hs_err 
>> file when an assertion would have failed. To debug failures, `-Xlog:dwarf` 
>> can be used with `info`, `debug` or `trace` which provides logging messages 
>> throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test 
>> reads the created hs_err files to check if the DWARF parsing could correctly 
>> find the filename and line number. For normal HotSpot files, I could not 
>> check against hardcoded 

Supporting alternative toolchains on Windows

[Julian Waters]

Hi all,

How feasible would it be/much effort would it require to support compiling
with alternate toolchains on Windows besides Visual C++ (like the Windows
ports of clang and gcc) if we restrict the allowed toolchains to only those
that link against the ucrt? (Toolchains linking against the dated msvcrt
would present too many issues to work with)

best regards,
Julian

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

[Thomas Stuefe]

On Fri, 11 Mar 2022 08:28:32 GMT, Ioi Lam  wrote:

>> Is reproducibility also a topic for users calling -Xdump with custom JNI 
>> coding? Or maybe having the VM instrumented somehow? Since it seems such an 
>> easy fix, I would prevent attaching too. At least the user would get a clear 
>> error message.
>
>> Is reproducibility also a topic for users calling -Xdump with custom JNI 
>> coding? Or maybe having the VM instrumented somehow? Since it seems such an 
>> easy fix, I would prevent attaching too. At least the user would get a clear 
>> error message.
> 
> It's impossible to execute arbitrary Java code when running "java 
> -Xshare:dump", so this means there's no way to load a JNI library when 
> creating a *static* CDS archive. The loading of JVMTI agents is also not 
> supported. So this is not a case we need to handle. 
> 
> During *dynamic* CDS dumps, arbitrary Java code can execute, but we don't 
> have a requirement for the *dynamic* CDS archive to be deterministic (at 
> least not for now).

Thanks for that clarification. Never mind then :)

-

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v5]

[Thomas Schatzl]

On Mon, 28 Feb 2022 16:22:25 GMT, Christian Hagedorn  
wrote:

>> When printing the native stack trace on Linux (mostly done for hs_err 
>> files), it only prints the method with its parameters and a relative offset 
>> in the method:
>> 
>> Stack: [0x7f6e01739000,0x7f6e0183a000],  sp=0x7f6e01838110,  
>> free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, 
>> bool, DirectiveSet*)+0xec
>> V  [libjvm.so+0x8303ef]  
>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, 
>> JavaThread*)+0x69
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
>> 
>> This makes it sometimes difficult to see where exactly the methods were 
>> called from and sometimes almost impossible when there are multiple 
>> invocations of the same method within one method.
>> 
>> This patch improves this by providing source information (filename + line 
>> number) to the native stack traces on Linux similar to what's already done 
>> on Windows (see 
>> [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
>> 
>> Stack: [0x7f34fca18000,0x7f34fcb19000],  sp=0x7f34fcb17110,  
>> free space=1020k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  
>> (c1_Compilation.cpp:607)
>> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, 
>> bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
>> V  [libjvm.so+0x8303ef]  
>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  
>> (compileBroker.cpp:2291)
>> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  
>> (compileBroker.cpp:1966)
>> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, 
>> JavaThread*)+0x69  (compilerThread.cpp:59)
>> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  
>> (thread.cpp:1297)
>> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
>> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
>> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  
>> (os_linux.cpp:705)
>> 
>> For Linux, we need to parse the debug symbols which are generated by GCC in 
>> DWARF - a standardized debugging format. This patch adds support for DWARF 
>> 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with 
>> x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still 
>> experimental and not generated for HotSpot. However, newer GCC version may 
>> soon generate DWARF 5 by default in which case this parser either needs to 
>> be extended or the build of HotSpot configured to only emit DWARF 4. 
>> 
>> The code follows the parsing steps described in the official DWARF 4 spec: 
>> https://dwarfstd.org/doc/DWARF4.pdf
>> I added references to the corresponding sections throughout the code. 
>> However, I tried to explain the steps from the DWARF spec directly in the 
>> code (method names, comments etc.). This allows to follow the code without 
>> the need to actually deep dive into the spec. 
>> 
>> The comments at the `Dwarf` class in the `elf.hpp` file explain in more 
>> detail how a DWARF file is structured and how the parsing algorithm works to 
>> get to the filename and line number information. There are more class 
>> comments throughout the `elf.hpp` file about how different DWARF sections 
>> are structured and how the parsing algorithm needs to fetch the required 
>> information. Therefore, I will not repeat the exact workings of the 
>> algorithm here but refer to the code comments. I've tried to add as much 
>> information as possible to improve the readability.
>> 
>> Generally, I've tried to stay away from adding any assertions as this code 
>> is almost always executed when already processing a VM error. Instead, the 
>> DWARF parser aims to just exit gracefully and possibly omit source 
>> information for a stack frame instead of risking to stop writing the hs_err 
>> file when an assertion would have failed. To debug failures, `-Xlog:dwarf` 
>> can be used with `info`, `debug` or `trace` which provides logging messages 
>> throughout parsing. 
>> 
>> **Testing:**
>> Apart from manual testing, I've added two kinds of tests:
>> - A JTreg test: Spawns new VMs to let them crash in various ways. The test 
>> reads the created hs_err files to check if the DWARF parsing could correctly 
>> find the filename and line number. For normal HotSpot files, I could not 
>> check against hardcoded 

Integrated: JDK-8282700: Properly handle several --without options during configure

[Julian Waters]

On Sat, 5 Mar 2022 12:44:36 GMT, Julian Waters  wrote:

> Some of the --without options are not properly handled and will crash when 
> processed (For example, --without-version-string), in other cases the 
> --without-* option will actually silently produce incorrect results instead 
> of actually doing what --without-* implies (For example, --without-build-user 
> and all the --with-vendor-* options). The most elegant way to solve this 
> would simply be to handle such cases and display warnings when they're 
> encountered (or if the option is critical to the build process, throwing an 
> error)
> 
> Even if it doesn't make sense to pass said option however, it should display 
> a warning instead of letting configure exit with a confusing error when it's 
> run

This pull request has now been integrated.

Changeset: cab9def1
Author:Julian Waters 
Committer: Magnus Ihse Bursie 
URL:   
https://git.openjdk.java.net/jdk/commit/cab9def1c1ab28b0b1a8cf268d0853f6e2bfa77f
Stats: 18 lines in 1 file changed: 5 ins; 0 del; 13 mod

8282700: Properly handle several --without options during configure

Reviewed-by: ihse

-

PR: https://git.openjdk.java.net/jdk/pull/7713

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

[Ioi Lam]

On Fri, 11 Mar 2022 07:13:35 GMT, Thomas Stuefe  wrote:

> Is reproducibility also a topic for users calling -Xdump with custom JNI 
> coding? Or maybe having the VM instrumented somehow? Since it seems such an 
> easy fix, I would prevent attaching too. At least the user would get a clear 
> error message.

It's impossible to execute arbitrary Java code when running "java 
-Xshare:dump", so this means there's no way to load a JNI library when creating 
a *static* CDS archive. The loading of JVMTI agents is also not supported. So 
this is not a case we need to handle. 

During *dynamic* CDS dumps, arbitrary Java code can execute, but we don't have 
a requirement for the *dynamic* CDS archive to be deterministic (at least not 
for now).

-

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: 8282507: Add LICENSE file for hsdis

[Magnus Ihse Bursie]

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao  wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

As an engineer and not a lawyer, these are definitely muddy waters to me. I'm 
trying to get an understanding of the process, but I'm not used to navigating 
those parts of the organization. But from what I've found out so far, it do 
seem that if you insist on going through with this, we'd need to get legal 
approval. Which would be a ton of hassle for me. :( So I implore you to 
reconsider this PR.

And no, hsdis is not the only part of OpenJDK with another license than GPL+CE. 
The entire hotspot code base, and all tests, are licensed under GPL. But afaic 
the GPL, GPL+CE and UPL covers all code that is created by the OpenJDK project. 
This is not a legal guarantee, though, it's just my current understanding of 
the situation.

And thank you for pointing out 
src/java.desktop/share/native/libsplashscreen/libpng/LICENSE. I'll bring it up 
with our resident 3rd party license expert. :-)

With all that said, if you were to rename the file hsdis-license.txt, I would 
not have any objection. My sole concern here is that the name "LICENSE" sounds 
so broad that a lawyer, in the way that lawyers sometime do :), might be able 
to misinterpret this as applying to anything else than hsdis. With a clearer 
name, that worry disappears. So if you can accept that name instead, I don't 
have any more objections. The factual licensing of hsdis under UPL is not in 
dispute.

-

PR: https://git.openjdk.java.net/jdk/pull/7649