On 9/03/2026 9:44 pm, Baesken, Matthias wrote:
Hi Kevi, opt:ref can eliminate some dead code (maybe that’s why the Windows
binaries were rather small for some time) .
https://learn.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=msvc-170
“When /OPT:REF is enabled, LINK removes unreferenced packaged functions
and data, known as COMDATs. This optimization is known as transitive COMDAT
elimination”
We use this linker flag , see
https://github.com/openjdk/jdk/blob/5e588085e9c333e9ad8e48dd7c60e665d30e278d/make/autoconf/flags-ldflags.m4#L95
and used it for some time see jdk21u-dev :
https://github.com/openjdk/jdk21u-dev/blob/f95246eb2c3c76fa8aafacd5f699fed92ef2b4ce/make/autoconf/flags-ldflags.m4#L90
* I see also David's comment that it was the "debug" symbol specifically
that clashed in a test. If there's no reason to change/prefix all the debug-time utils
that that's great.
*
If it is just about this single helper , we can rename just this one ; I think
most developers would be fine with this.
I'm not sure where this conclusion is coming from. The case in question
was about "debug" but as stated earlier and/or in the JBS issue this is
potentially an issue for any symbol exported from one of the JDK
libraries that clashes with a symbol from the application native code.
David
-----
Best regards, Matthias
From: Kevin Walls <[email protected]>
Sent: Monday, 9 March 2026 12:34
To: Baesken, Matthias <[email protected]>; Erik Joelsson
<[email protected]>; [email protected]
Subject: Re: [External] : RE: Exporting debug helpers and 8375311: Some builds
are missing debug helpers and exporting debug-helpers
Hi - I only wanted to mention JDK-8264593 as it's part of the history, and I
think we should be able to have code in the JVM that is not called. (because it
might be called by some other route). But I think that change was long before
other issues were seen. At the time I thought the default visibility on
Windows was a problem. (I don't think we were using /OPT:REF and don't see it
today with a quick search.)
I see also David's comment that it was the "debug" symbol specifically that
clashed in a test. If there's no reason to change/prefix all the debug-time utils that
that's great.
________________________________
From: Baesken, Matthias
<[email protected]<mailto:[email protected]>>
Sent: Monday, March 9, 2026 11:12 AM
To: Kevin Walls <[email protected]<mailto:[email protected]>>; Erik Joelsson
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: [External] : RE: Exporting debug helpers and 8375311: Some builds
are missing debug helpers and exporting debug-helpers
Hi Matthias -
I did https://bugs.openjdk.org/browse/JDK-8264593 which "promoted" the debug
utils into product builds, and made them available on Windows. So I'm in favour of them
existing, and being available!
Yes maybe they need better names if the short debug utils have clashed with
something else in the past, maybe it was a clash with some native test.
Maybe JVM_dbg_pp, JVM_dbg_blob, etc..? (We already have dbg_is_safe). I don't
see it spelled out exactly what the clash was.
Hi Kevin, your JBS issue JDK-8264593 states : “For Windows, JNIEXPORT is also
needed to make the symbols visible.” .
Is it really about visibility on Windows , or is the more aggressive
/OPT:REF or other linker options on Windows eliminating those symbols
without being exported (that saves them from elimination) ?
(on Linux we had such issues too with LTGC or LTO linker options, that’s why I
exported them on UNIX too)
The very short names of the debug – helpers like help, flush , pp, nm from
the debug helpers are probably also problematic on Windows, but seems no one
ever complained ?
Best regards, Matthias
