On Wed, 30 Apr 2025 13:04:18 GMT, Matthias Baesken wrote:
> Seems the currently used ATTRIBUTE_NO_UBSAN does not handle the exclusion of
> float divisions by zero.
> At least this is the case on AIX.
>
> (seen in the jtreg test java/lang/Math/PowTests.java )
LGTM
-
Marked as revi
On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote:
> In the JDK launcher, there is a codepath which would set/modify the
> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
>
On Fri, 14 Mar 2025 15:41:56 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
On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern wrote:
>> Looks like this variable is misspelled (missing "S").
>>
>> DEPS := $(STATIC_LIB_FILE), \
>>
>> Also note that by default log level INFO is not printed. You would need to
>> run the build wi
On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added needed include
>
> make/StaticLibs.gmk line 117:
>
>> 115:
is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of
> this, $JDK/../lib, seems to be a remnant of times when there was a jre
> subfolder in a JDK deployment. So it should likely be removed.
Joachim Kern has updated the pull request incrementally with one additional
commit since the las
On Thu, 20 Mar 2025 14:30:58 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-833
is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of
> this, $JDK/../lib, seems to be a remnant of times when there was a jre
> subfolder in a JDK deployment. So it should likely be removed.
Joachim Kern has updated the pull request incrementally with one additional
commit since the la
In the JDK launcher, there is a codepath which would set/modify the
LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
contains a libjvm.so.
The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/
On Fri, 14 Mar 2025 11:47:44 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
to
> program a working comparison. It only works if B is empty meaning the test is
> not called by jtreg with a preset `LD_LIBRARY_PATH`
>
> Unfortunately we now have to call all tests with a given runtime search path
> provided in `LD_LIBRARY_PATH`.
> So my proposal is to
to
> program a working comparison. It only works if B is empty meaning the test is
> not called by jtreg with a preset `LD_LIBRARY_PATH`
>
> Unfortunately we now have to call all tests with a given runtime search path
> provided in `LD_LIBRARY_PATH`.
> So my proposal is to
to
> program a working comparison. It only works if B is empty meaning the test is
> not called by jtreg with a preset `LD_LIBRARY_PATH`
>
> Unfortunately we now have to call all tests with a given runtime search path
> provided in `LD_LIBRARY_PATH`.
> So my proposal is to
to
> program a working comparison. It only works if B is empty meaning the test is
> not called by jtreg with a preset `LD_LIBRARY_PATH`
>
> Unfortunately we now have to call all tests with a given runtime search path
> provided in `LD_LIBRARY_PATH`.
> So my proposal is to
to
> program a working comparison. It only works if B is empty meaning the test is
> not called by jtreg with a preset `LD_LIBRARY_PATH`
>
> Unfortunately we now have to call all tests with a given runtime search path
> provided in `LD_LIBRARY_PATH`.
> So my proposal is to
On Fri, 14 Mar 2025 15:41:56 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
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
foll
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
foll
On Fri, 14 Mar 2025 11:47:44 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
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
ad
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
fo
On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson wrote:
>> The problem seems to be that `$(generate_export_list)` is empty and I do not
>> know why.
>
> Looks like this variable is misspelled (missing "S").
>
> DEPS := $(STATIC_LIB_FILE), \
>
> Also note that by default log level INFO is not pr
On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern wrote:
>> make/StaticLibs.gmk line 116:
>>
>>> 114: #DEPS := $(STATIC_LIB_FILE), \
>>> 115: #OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>>> 116: #COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp,
On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson 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.
>>
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.
Now with this change we can enable the statically linked launcher target
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 with crude workarounds, which even
do not work in any case. So we sk
On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
On Mon, 20 Jan 2025 17:01:10 GMT, Daniel Fuchs wrote:
> > > The problem is, that such IBM links do not work very long. In one or a
> > > view years this link again might point to nirvana.
> >
> >
> > Should we remove it instead then?
>
> I would be OK with just dropping the link.
I would kee
On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates a total of 12 links to external
>> documentation or references in `java.base` to use https instead of plain
>> text http.
>>
>> Links in `java.security` and `share/data/tzdata` are excluded f
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 and MacOS
> alread
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
On Thu, 9 Jan 2025 10:29:32 GMT, Martin Doerr wrote:
>> Joachim Kern has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - remove extra white space
>> - omit unused variable
>
> src/java.base/aix/native/
efore, such a test makes little sense in principle.
>
> The AIX-specific cause of the problem lies in the API used to get the cpu
> time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The
> /proc directory is only present on AIX for portability reasons. The data in
> i
On Wed, 8 Jan 2025 13:41:52 GMT, Matthias Baesken 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).
OK agree, but in a separate PR. Could you please create
On Wed, 8 Jan 2025 12:21:21 GMT, Matthias Baesken wrote:
> > The /proc//psinfo file is evaluated to obtain the cpu time
>
> Do you mean` /proc//psinfo` ?
Strange, the < pid > is there, but not displayed, maybe interpreted as special
characters.
I let the string interpreted as code. This helps.
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 turned out that it was wrong.
We can see an exception like:
java.l
On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern wrote:
> Since ~ end of March, after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>
> stdout: [];
> stderr: [Error: could not find libjava.so
) ? The libjli.so is gone on AIX after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this
> also the image discovery based on GetApplicationHomeFromDll which uses
> libjli.so .
>
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar.
&
) ? The libjli.so is gone on AIX after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this
> also the image discovery based on GetApplicationHomeFromDll which uses
> libjli.so .
>
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar.
&
) ? The libjli.so is gone on AIX after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this
> also the image discovery based on GetApplicationHomeFromDll which uses
> libjli.so .
>
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar.
&
) ? The libjli.so is gone on AIX after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this
> also the image discovery based on GetApplicationHomeFromDll which uses
> libjli.so .
>
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar.
&
On Mon, 29 Apr 2024 15:57:02 GMT, Alan Bateman wrote:
> This looks like it's adding code to search LD_LIBRARY_PATH on Linux/macOS
> too, did you mean to do that?
Hi Alan, this first commit of the PR is just a question if Linux/macOS want to
participate in this 3rd method. For them it's just a
Since ~ end of March, after
[JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
stdout: [];
stderr: [Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.
]
exitValue = 2
java.lang.RuntimeExcep
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request increment
On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Mon, 11 Mar 2024 08:59:03 GMT, Joachim Kern wrote:
>> make/autoconf/flags-cflags.m4 line 687:
>>
>>> 685: PICFLAG="-fPIC"
>>> 686: PIEFLAG="-fPIE"
>>> 687: elif test "x$TOOLCHAIN_TYPE" = xclang && tes
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Fri, 8 Mar 2024 15:31:18 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/flags-cflags.m4 line 687:
>
>> 685: PICFLAG="-fPIC"
>> 686
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesy
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvf
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-th
On Thu, 5 Oct 2023 10:02:05 GMT, Joachim Kern wrote:
> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
> in TreeTest.test5.
> The reason is: Previously the implementation based on the /proc file system
> lead to double pids in the child list; at least
On Thu, 12 Oct 2023 06:30:33 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cosmetic changes 2
>
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c lin
On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system
>> lead to double pids in
d I was able to eliminate those double pids (and increase
> the performance by a factor of 4). Otherwise we would have to add an
> algorithm to filter out the doubles after creating the raw list.
Joachim Kern has updated the pull request incrementally with one additional
commit since the las
On Wed, 11 Oct 2023 13:52:54 GMT, Roger Riggs wrote:
>> Probably keep the function without split into 2 functions, but just adjust
>> the comment a bit as Thomas suggested ?
>
> The callers in ProcessHandlerImpl depend on knowing the parent pid for each
> process.
> They are used to find the
On Wed, 11 Oct 2023 11:22:21 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cosmetic changes 2
>
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix
d I was able to eliminate those double pids (and increase
> the performance by a factor of 4). Otherwise we would have to add an
> algorithm to filter out the doubles after creating the raw list.
Joachim Kern has updated the pull request incrementally with one additional
commit si
On Tue, 10 Oct 2023 09:36:47 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system
>> lead to double pids in
.SuiteRunner.privateRun(SuiteRunner.java:337)
> at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> at org.testng.TestNG.runSu
On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>>
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [
at org.testng.TestNG.runSuites(TestNG.java:1069)
> at org.testng.TestNG.run(TestNG.java:1037)
> at
> com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
> at
> com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
> at
> java.base/jd
We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in
TreeTest.test5.
test TreeTest.test5(): failure
java.lang.AssertionError: expected direct children expected [2] but found [3]
at org.testng.Assert.fail(Assert.java:99)
at org.testng.Assert.failNotEquals
68 matches
Mail list logo
