On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Fri, 11 Apr 2025 07:11:19 GMT, Matthias Baesken wrote:
>> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove
>> it and make it UNIX-only (there are still a few remaining usages).
>
> Matthias Baesken has updated the pull request incrementally with
On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken wrote:
> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove
> it and make it UNIX-only (there are still a few remaining usages).
This pull request has now been integrated.
Changeset: b5d2e254
Author:Ma
> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove
> it and make it UNIX-only (there a still a few remaining usages).
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust COPYRIGHT
On Thu, 10 Apr 2025 15:42:06 GMT, Alan Bateman wrote:
> I think this looks okay, can you update the copyright header dates before you
> integrate.
Sure, I adjusted the copyright header dates.
-
PR Comment: https://git.openjdk.org/jdk/pull/24563#issuecomment-2796041681
JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove it
and make it UNIX-only (there a still a few remaining usages).
-
Commit messages:
- JDK-8354189
Changes: https://git.openjdk.org/jdk/pull/24563/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=245
On Fri, 28 Mar 2025 17:04:03 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Fri, 28 Mar 2025 10:52:55 GMT, Christoph Langer wrote:
> I think it is wrong to completely remove point 4. You should rather remove
> the term "on Solaris". The thing itself is still tested in testNoSymLink().
Yes just remove Solaris not the whole comment (on the other hand, is the
symlink
On Thu, 27 Mar 2025 14:15:12 GMT, Joachim Kern wrote:
>> The test `testEcoFriendly()` checks if the launcher pollutes the
>> `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does
>> not make sense to make this test somehow passing w
On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
>
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
On Fri, 14 Mar 2025 12:45:23 GMT, Matthias Baesken wrote:
> > What testing have you run?
>
> I put it into our testing queue, this runs jtreg tier 1 - 4 and some more
> stuff over the weekend on all our platforms.
No issues were seen with the patch in the mentioned tests.
--
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
On Fri, 14 Mar 2025 11:34:08 GMT, Magnus Ihse Bursie wrote:
> What testing have you run?
I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff
over the weekend on all our platforms.
-
PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724577
On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
most likely not needed any more and could be removed.
The removal (on Linux) brings the lib optimization level de facto from LOW to
HIGH.
-
Commit messages:
- JDK-8352015
Changes: https://git.openjdk.org/
On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken wrote:
>> While testing a bit with a minimal JVM, it has been noticed that some
>> java/lang jtreg tests use jfr but do not declare it with a "requires
>> vm.hasJFR" ; that leads to test errors in a JVM setup with n
On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Thu, 27 Feb 2025 21:40:23 GMT, Magnus Ihse Bursie wrote:
> If you want to see that implemented, the first step is to open an enhancement
> issue on JBS.
For now I would probably be happy with fixing/adding the 'requires' statements
of the tests, where they are missing.
This would allow jtre
On Thu, 27 Feb 2025 15:11:49 GMT, Magnus Ihse Bursie wrote:
> No, there is nothing for that. There is a conceptual leap between determining
> how to compile hotspot and how to decide which modules to include in the
> image, and is not at all clear how you would want to integrate these two.
> L
On Thu, 27 Feb 2025 09:12:10 GMT, Matthias Baesken wrote:
> when I list the modules of the minimal JVM I see a number of modules that
> will most likely not work because the related JVM features are not present
>
> ```
> images/jdk/bin/java --list-modules
> ...
> jdk.
On Wed, 26 Feb 2025 15:47:52 GMT, Matthias Baesken wrote:
> While testing a bit with a minimal JVM, it has been noticed that some
> java/lang jtreg tests use jfr but do not declare it with a "requires
> vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
Th
On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken wrote:
>> While testing a bit with a minimal JVM, it has been noticed that some
>> java/lang jtreg tests use jfr but do not declare it with a "requires
>> vm.hasJFR" ; that leads to test errors in a JVM setup with n
> While testing a bit with a minimal JVM, it has been noticed that some
> java/lang jtreg tests use jfr but do not declare it with a "requires
> vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
Matthias Baesken has updated the pull request incrementally
On Thu, 27 Feb 2025 08:49:43 GMT, Alan Bateman wrote:
>> A minimal JVM (**--with-jvm-features=minimal --with-jvm-variants=minimal**)
>> is tested. This contains no JFR in Hotspot.
>> If you configure the build without JVM feature JFR (like minimal) , the
>> tests need the correct requires tag
On Thu, 27 Feb 2025 08:36:58 GMT, Alan Bateman wrote:
>> While testing a bit with a minimal JVM, it has been noticed that some
>> java/lang jtreg tests use jfr but do not declare it with a "requires
>> vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> test/jdk/java/lang/Th
While testing a bit with a minimal JVM, it has been noticed that some java/lang
jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that
leads to test errors in a JVM setup with no JFR .
-
Commit messages:
- JDK-8350786
Changes: https://git.openjdk.org/jdk/pull
On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Mon, 27 Jan 2025 22:03:41 GMT, Alexey Semenyuk wrote:
> Rework pointer arithmetic to avoid null pointer
Marked as reviewed by mbaesken (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23320#pullrequestreview-2577374445
ualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
>
> In the discussion in the JBS bug it was found that a retry option in` launch
> `should be added.
Mat
ualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at
> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
>
> In the discussion in the JBS bug it was found that a retry option in` launch
> `should be added.
Mat
On Tue, 21 Jan 2025 19:06:40 GMT, Chris Plummer wrote:
> launch() should take an allowRetry argument and only retry if true.
Are you talking about `public static void launch(String expectedMessage,
String... toolArgs)` ?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/2321
We were running into this error :
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
address 0x34144e30 (expected type JavaThread, CompilerThread,
MonitorDeflationThread, AttachListenerThrea
On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote:
> This PR reverts the fix from
> [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it
> increases the runtime of the test a lot.
> Instead a full gc is requested via the whitebox api. This solves the issues
> (see bug
On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote:
>> During code review of
>> [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments
>> were made after the PR integrated. This follow-up patch cleans this up and
>> adds a unit test for the `JimageDiffGenerator` class.
On Sat, 28 Dec 2024 18:43:30 GMT, Martin Doerr wrote:
> [JDK-8317545](https://bugs.openjdk.org/browse/JDK-8317545) introduced code
> for supporting 4 Byte aligned doubles:
> https://github.com/openjdk/jdk/blob/60e0730a3ba26180d0eb2cd278e389c3e70fec5f/src/java.base/share/classes/jdk/internal/for
On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote:
> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
> implementation that was shared between Solaris and AIX. Linux
On Fri, 10 Jan 2025 11:22:31 GMT, Matthias Baesken wrote:
>> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
>> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
>> implementation that was shared between Solaris and AI
moval of the Solaris port,
> these two functions can be removed in favor of inline implementations of
> os_getParentPidAndTimings and os_getCmdlineAndUserInfo in
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c.
Matthias Baesken has updated the pull request incrementally with o
On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote:
> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
> implementation that was shared between Solaris and AIX. Linux
moval of the Solaris port,
> these two functions can be removed in favor of inline implementations of
> os_getParentPidAndTimings and os_getCmdlineAndUserInfo in
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c.
Matthias Baesken has updated the pull request incrementally with o
The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in
src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an
implementation that was shared between Solaris and AIX. Linux and MacOS already
had specific implementations. After the removal of the Solaris po
On Wed, 8 Jan 2025 12:47:58 GMT, Joachim Kern wrote:
> Seems, that we were the only remainding users of
> unix_getParentPidAndTimings(). Should I remove the orphant?
I would be in favor of removing it (in this PR or separate).
-
PR Comment: https://git.openjdk.org/jdk/pull/22966#
On Wed, 8 Jan 2025 11:53:43 GMT, Joachim Kern wrote:
> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on
> AIX. The test exclusion was removed through
> [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the
> assumption the problem was gone. But it turne
On Fri, 3 Jan 2025 21:33:17 GMT, Alexey Semenyuk wrote:
>> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the
>> test's work directory doesn't support DOS file names.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a
> merge or a rebase. Th
On Fri, 3 Jan 2025 10:29:31 GMT, Matthias Baesken wrote:
> When starting :tier1 jdk jtreg tests with
> /jtreg_latest/bin/jtreg
> this error is show when running ubsanized binaries on macOS aarch64 (XCode
> 13.1 and 15.4 show this)
>
> src/java.base/unix/native/libjava/Proce
On Fri, 3 Jan 2025 10:29:31 GMT, Matthias Baesken wrote:
> When starting :tier1 jdk jtreg tests with
> /jtreg_latest/bin/jtreg
> this error is show when running ubsanized binaries on macOS aarch64 (XCode
> 13.1 and 15.4 show this)
>
> src/java.base/unix/native/libjava/Proce
When starting :tier1 jdk jtreg tests with
/jtreg_latest/bin/jtreg
this error is show when running ubsanized binaries on macOS aarch64 (XCode 13.1
and 15.4 show this)
src/java.base/unix/native/libjava/ProcessImpl_md.c:561:40: runtime error:
applying zero offset to null pointer
#0 0x102a6552c
On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote:
> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the
> test's work directory doesn't support DOS file names.
After adding it to our build/test queue, this fails with
#section:build
--messages:(3/144)-
On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote:
> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the
> test's work directory doesn't support DOS file names.
> alexeysemenyukoracle
I added the patch to our build/test queue .
-
PR Comment: https://g
On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote:
> Please review this fairly simple change to improve how the
> `JimageDiffGenerator` works. The original implementation is pretty naive and
> read all bytes into memory and then compared them. This improved version only
> reads bytes on
On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote:
> Please review this fairly simple change to improve how the
> `JimageDiffGenerator` works. The original implementation is pretty naive and
> read all bytes into memory and then compared them. This improved version only
> reads bytes on
On Fri, 15 Nov 2024 09:18:27 GMT, Matthias Baesken wrote:
> On AIX we run into errors below, for example in test
> tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug
> binaries, opt worked :
>
> jlink options: --output java-base-with-opts-jlink-tm
On Mon, 18 Nov 2024 08:26:20 GMT, Matthias Baesken wrote:
>> On AIX we run into errors below, for example in test
>> tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug
>> binaries, opt worked :
>>
>> jlink options: --output java-base-wit
st.java:62)
> at AddOptionsTest.main(AddOptionsTest.java:49)
> at
> java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
> at
> java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
> at
> java.base/java.lang.
On Fri, 15 Nov 2024 10:50:47 GMT, Severin Gehwolf wrote:
> Where you able to reproduce outside of testing?
No, it failed only in our central test environment, not for single runs of one
of these tests with jtreg in my local AIX dev env .
But the central tests use fastdebug and I use locally mos
On AIX we run into errors below, for example in test
tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug
binaries, opt worked :
jlink options: --output java-base-with-opts-jlink-tmp --add-modules
jdk.jlink,java.base --generate-linkable-runtime
--keep-packaged-modules=ja
On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk wrote:
> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app
> image on macOS.
Hi Aleksei, with your patch added I see so far no errors any more related to
InOutPathTest
On Wed, 6 Nov 2024 11:45:23 GMT, mjschwaiger wrote:
>> Windows Server 2025 will be releases in a few months.
>> The OS detection code of the JVM/JDK should recognize the new Windows server
>> 2025 version.
>> (currently Windows server 2022 is printed , that is wrong)
>>
>> The build numbers of
On Mon, 23 Sep 2024 06:38:45 GMT, Matthias Baesken wrote:
>> Windows Server 2025 will be releases in a few months.
>> The OS detection code of the JVM/JDK should recognize the new Windows server
>> 2025 version.
>> (currently Windows server 2022 is printed , that is
On Tue, 5 Nov 2024 22:42:13 GMT, Alexey Semenyuk wrote:
> can you try this fix in your environment?
Sure, I added the patch to our build/test queue .
-
PR Comment: https://git.openjdk.org/jdk/pull/21909#issuecomment-2458923465
On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken wrote:
> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with
> 'expect' .
This pull request has now been integrated.
Changeset: 415d8151
Author:Matthias Baesken
URL:
https://git.openjd
On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken wrote:
> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with
> 'expect' .
Thanks for the reviews !
-
PR Comment: https://git.openjdk.org/jdk/pull/21678#issuecomment-2437045742
Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .
-
Commit messages:
- JDK-8342938
Changes: https://git.openjdk.org/jdk/pull/21678/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21678&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be
On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove ubsan changes from jni_md.h
>
> jni_util.h is used across all modules but
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the
On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes wrote:
> jni_util.h is used across all modules but it is located in
> `java.base/share/native/libjava` not `java.base/unix/native/libjava`.
>
> I think you could probably place ub.h along-side jni_util.h in that directory.
Hi David, are you fine w
On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken wrote:
> There are a few warnings as errors occurring when building on Linux with
> clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
This p
On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken wrote:
>> There are a few warnings as errors occurring when building on Linux with
>> clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-833915
On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken wrote:
> There are a few warnings as errors occurring when building on Linux with
> clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
I broug
> There are a few warnings as errors occurring when building on Linux with
> clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
Matthias Baesken has updated the pull request incrementally
On Wed, 9 Oct 2024 07:26:41 GMT, Julian Waters wrote:
> Might be a good idea to have rslt commented out
Why not; Chris what do you say ?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793282296
hange adds a macro ATTRIBUTE_NO_UBSAN similar to what we already use in
> Hotspot coding.
Matthias Baesken 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 four addi
On Tue, 8 Oct 2024 16:30:36 GMT, Chris Plummer wrote:
>> There are a few warnings as errors occurring when building on Linux with
>> clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> src/jdk.hotspot.agent/li
There are a few warnings as errors occurring when building on Linux with clang
(clang15). Mostly these are some kind of 'unused' warnings.
Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
-
Commit messages:
- JDK-8341722
Changes: https://git.openjdk.org/jdk/pull/21
On Tue, 8 Oct 2024 10:54:09 GMT, Magnus Ihse Bursie wrote:
>The UBSan functionality is well supported, as such, in the build system. As
>you say, actually building and running a JDK with
> UBSan functionality is not trivial. This just means that we are unlikely to
> e.g. run it continuously on
On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes wrote:
> I think you could probably place ub.h along-side jni_util.h in that directory.
I moved the header to the better location.
-
PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2393323469
hange adds a macro ATTRIBUTE_NO_UBSAN similar to what we already use in
> Hotspot coding.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
move ub.h to a better location
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21184
On Wed, 2 Oct 2024 09:38:41 GMT, David Holmes wrote:
> > So maybe src/java.base/unix/native/libjava
>
> That is header files for libjava.
>
> This is why I said it would be hard to find a shared location where this can
> be used across different modules - because there presently isn't one.
In
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((
On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken wrote:
>> `jni_md.h` is shipped as part of every JDK distribution - this change does
>> NOT belong in that file.
>
>> `jni_md.h` is shipped as part of every JDK distribution - this change does
>> NOT belong in that fi
On Tue, 1 Oct 2024 12:22:34 GMT, Aleksey Shipilev wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> __attribute__ ((format (printf, 1, 2))).'
>>
hange adds a macro ATTRIBUTE_NO_UBSAN similar to what we already use in
> Hotspot coding.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
remove ubsan changes from jni_md.h
-
Changes:
- all: https://git.openjdk.org/jdk/pul
This fixes a format string issue.
In the error report it was reported : 'The compiler should be able to catch
this if JLI_ReportErrorMessageSys was declared with something like
__attribute__ ((format (printf, 1, 2))).'
Should we maybe adjust JLI_ReportErrorMessageSys , JLI_ReportErrorMessage a
On Sun, 29 Sep 2024 22:16:47 GMT, David Holmes wrote:
> `jni_md.h` is shipped as part of every JDK distribution - this change does
> NOT belong in that file.
Hi David, should I introduce a separate ub.hpp (similar to what we have in
Hotspot) ?
-
PR Comment: https://git.openjdk.o
On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> _
t JLI_ReportErrorMessageSys , JLI_ReportErrorMessage
> and related functions/methods using a format string so that such errors can
> be found already at build time ?
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
use blank in outpu
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be
On Thu, 26 Sep 2024 21:25:07 GMT, Phil Race wrote:
> build team have indicated they do not support --enable-ubsan
What 'build team' are you talking about ? Some Oracle internal build team?
The ubsan support came in 2023, so nothing new (change was from Justin King)
https://github.com/openjdk/jd
On Thu, 26 Sep 2024 11:51:19 GMT, Matthias Baesken wrote:
> The exclusions should work (similar to HS) for the whole JDK C codebase.
Maybe we can offer a separate header ub.hpp next to jni_md.h that contains the
macro/attribute stuff.
Similar to sanitizers/ub.hpp in HS. This header is t
On Thu, 26 Sep 2024 10:41:25 GMT, Julian Waters wrote:
> jni_md.h seems like a pretty big sledgehammer for something that seems to
> only be in one file, for just java.desktop. Is this macro planned to be used
> outside of java.desktop?
Yes I have a couple (currently 2) more I would like to ex
There is some old awt/2d coding where warnings occur when running with ubsan
enabled binaries.
However at most of these locations the coding should work (at least on our
supported platform set) so the warnings can be disabled at least for now.
The change adds a macro ATTRIBUTE_NO_UBSAN similar
On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken wrote:
> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any
> more for a very long time in OpenJDK.
This pull request has now been integrated.
Changeset: 9176f681
Author:Matthias Baesken
URL:
1 - 100 of 446 matches
Mail list logo
