Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range [v2]
> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently > fail when run with `-Xcomp`. This happens when the compilation of methods on > the worker threads interleaves with the 2 calls on the main thread to > `mbean.getThreadCpuTime` to get the CPU time for all worker threads. > > The way the test is currently written, the worker threads are all usually > waiting on a shared monitor when the 2 timings are taken. That is, in a > successful run, the delta between the timings is always 0. When `-Xcomp` > compilations kick in at the "wrong" time or take sufficiently long, the > expected delta of 100 nanoseconds is easily exceeded. > > It does not make sense to run a timing test with such a small expected delta > with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: fix date in header - Changes: - all: https://git.openjdk.org/jdk/pull/17675/files - new: https://git.openjdk.org/jdk/pull/17675/files/4ff2f7cd..a3bc2653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17675=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17675=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Fri, 2 Feb 2024 06:55:19 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 incrementally with one > additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > 363: #else > 364: // Make sure we link to the 64-bit version of the functions > 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) - PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475642841
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Fri, 2 Feb 2024 06:55:19 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 incrementally with one > additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX make/modules/jdk.hotspot.agent/Lib.gmk line 31: > 29: > 30: ifeq ($(call isTargetOs, linux), true) > 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 We have two choices to feel a bit more comfortable: 1) We unconditionally `static_assert` in a few places for large `off_t`, or 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > 92: return IOS_UNSUPPORTED_CASE; > 93: > 94: loff_t offset = (loff_t)position; Is this `loff_t` for the benefit of `copy_file_range`? - PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475635336 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475636686
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Fri, 2 Feb 2024 06:55:19 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 incrementally with one > additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign. > > Can you confirm that you've run tier1-4 at least? Some of the library code > > that is changed here is not tested in the lower tiers. > > I have run tier1-4 now, and it passes (bar the tests that are currently > failing in mainline). However, this only tests 64-bit builds, and these > changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is > more of a sanity check that I did not inadvertenly broke any 64-bit code. > > To really test that this works properly, a 32-bit linux with an assortment of > operations on > 2GB files would be needed. To the best of my knowledge, we > have no such test environment available, and I could not even try to think of > how to create such a test setup that does anything useful. (That is, if I > even were to spend any time on creating new tests for 32-bit platforms...) Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine. Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK. I'll leave comments inline for the rest. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote: >>> @MBaesken So my fix in >>> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) >>> did not help? Maybe then it is some other system library that drags in >>> `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way >>> too much that it does not need, so we can surely strip it of even more >>> standard includes if that is what is required to fix this. >> >> >> Unfortunately it did not help. > >> @MBaesken How annoying. :( I have now tried to remove _all_ system includes >> from `debug_util.h`. Can you please try again building debug on AIX, to see >> if it works without the `#undef` in `BufferedRenderPipe.c`? > > The AIX (fast)debug build still fails . @MBaesken Ok, I officially give up. :-( I added your patch from https://github.com/openjdk/jdk/pull/17538#issuecomment-1918699480. I agree that it is not elegant, but at least it works. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923062901
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
> 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 incrementally with one additional commit since the last revision: Add kludge to BufferedRenderPipe.c for AIX - Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/eb92119e..3c404183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17538=06 - incr: https://webrevs.openjdk.org/?repo=jdk=17538=05-06 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538
Re: RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes [v2]
On Thu, 1 Feb 2024 01:38:21 GMT, Alex Menkov wrote:
>> The fix adds new test for FollowReferences JVMTI function to verify
>> correctness of reported field indexes.
>
> Alex Menkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> feedback
Nice test, thank you for developing it!
Looks good.
test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp
line 512:
> 510: JNIEXPORT jboolean JNICALL
> 511: Java_FieldIndicesTest_testFailed(JNIEnv *env, jclass cls) {
> 512: return test_failed ? JNI_TRUE : JNI_FALSE;
The indent for native files has to be 2, not 4. Even though there are still
some tests with wrong indents I'd suggest for new files to follow this rule.
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17580#pullrequestreview-1858460187
PR Review Comment: https://git.openjdk.org/jdk/pull/17580#discussion_r1475611992
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote: > I just suggest double-checking on the current maintenance procedures for the > java.util.concurrent code. @jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/). - PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074
Re: RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range
On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote: > The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently > fail when run with `-Xcomp`. This happens when the compilation of methods on > the worker threads interleaves with the 2 calls on the main thread to > `mbean.getThreadCpuTime` to get the CPU time for all worker threads. > > The way the test is currently written, the worker threads are all usually > waiting on a shared monitor when the 2 timings are taken. That is, in a > successful run, the delta between the timings is always 0. When `-Xcomp` > compilations kick in at the "wrong" time or take sufficiently long, the > expected delta of 100 nanoseconds is easily exceeded. > > It does not make sense to run a timing test with such a small expected delta > with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. Excluding Xcomp mode seems the most practical/expedient solution. Please update the 2023 copyright year to 2024. Thanks. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17675#pullrequestreview-1858173944
Re: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3]
On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov wrote: >> FilteredFieldStream used by heap walking functions to iterate through >> klass/superclasses/interfaces fields are known to have poor performance (see >> [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). >> Heap walking API implementation is the last user of the klasses. >> The fix reworks iteration through klass/superclasses/interfaces fields and >> drops FilteredFieldStream-related code. >> Additionally removed/updated includes of reflectionUtils.hpp. >> >> Testing: >> - tier1..4; >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different >> heap walking functions); >> - new test from #17580 (now the test runs several times faster). > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > jcheck Looks good. - Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1858174309
Re: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3]
On Thu, 1 Feb 2024 18:56:37 GMT, Alex Menkov wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 453:
>>
>>> 451: InstanceKlass* super_klass = ik->java_super();
>>> 452: if (super_klass != nullptr) {
>>> 453: start_index += add_instance_fields(super_klass, start_index);
>>
>> Does hotspot have any rules against potentially very deep recursion that can
>> overflow the stack?
>
> I looked at hotspot code and don't see "implementation limits" for level of
> inheritance, so it looks like a valid concern.
> Need to reimplement this without recursion.
Fixed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1475451497
Re: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v3]
> FilteredFieldStream used by heap walking functions to iterate through > klass/superclasses/interfaces fields are known to have poor performance (see > [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and > drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different > heap walking functions); > - new test from #17580 (now the test runs several times faster). Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: jcheck - Changes: - all: https://git.openjdk.org/jdk/pull/17661/files - new: https://git.openjdk.org/jdk/pull/17661/files/c064abdf..d6ab43b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17661=02 - incr: https://webrevs.openjdk.org/?repo=jdk=17661=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661 PR: https://git.openjdk.org/jdk/pull/17661
Re: RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage
On Fri, 2 Feb 2024 00:44:00 GMT, Serguei Spitsyn wrote:
> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
> spec.
> The function returns the following structure:
>
>
> typedef struct {
> jthread owner;
> jint entry_count;
> jint waiter_count;
> jthread* waiters;
> jint notify_waiter_count;
> jthread* notify_waiters;
> } jvmtiMonitorUsage;
>
>
> The following four fields are defined this way:
>
> waiter_count [jint] The number of threads waiting to own this monitor
> waiters [jthread*] The waiter_count waiting threads
> notify_waiter_count [jint] The number of threads waiting to be notified by
> this monitor
> notify_waiters [jthread*] The notify_waiter_count threads waiting to be
> notified
>
> The `waiters` has to include all threads waiting to enter the monitor or to
> re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in
> `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in
> `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor
> in `Object.wait()` which is wrong.
> This update makes it right.
>
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is
> based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep
> the existing behavior of this command.
>
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the
> `GetObjectMonitorUsage()` correct behavior:
>
> jvmti/GetObjectMonitorUsage/objmonusage001
> jvmti/GetObjectMonitorUsage/objmonusage003
>
>
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>
>
>
> A JCK bug will be filed and the tests have to be added into the JCK problem
> list located in the closed repository by a separate sub-task before
> integration of this update.
>
> Also, please see and review the related CSR:
> [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect
> implementation of JVM TI GetObjectMonitorUsage
>
> Testing:
> - tested with mach5 tiers 1-6
src/hotspot/share/prims/jvmtiEnvBase.cpp line 1553:
> 1551: Handle th(current_thread, get_vthread_or_thread_oop(w));
> 1552: if (java_lang_Thread::get_thread_status(w->threadObj()) ==
> 1553: JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER) {
I don't think this is possible. `BLOCKED_ON_MONITOR_ENTER` is only set after
the target has been removed from the wait-set and added to the cxq queue - see
`ObjectMonitor::INotify`. As per the comment just above:
// If the thread was found on the ObjectWaiter list, then
// it has not been notified.
which means it can't be trying to acquire the monitor either.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1475436352
RFR: 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
spec.
The function returns the following structure:
typedef struct {
jthread owner;
jint entry_count;
jint waiter_count;
jthread* waiters;
jint notify_waiter_count;
jthread* notify_waiters;
} jvmtiMonitorUsage;
The following four fields are defined this way:
waiter_count [jint] The number of threads waiting to own this monitor
waiters [jthread*] The waiter_count waiting threads
notify_waiter_count [jint] The number of threads waiting to be notified by
this monitor
notify_waiters [jthread*] The notify_waiter_count threads waiting to be
notified
The `waiters` has to include all threads waiting to enter the monitor or to
re-enter it in `Object.wait()`.
The implementation also includes the threads waiting to be notified in
`Object.wait()` which is wrong.
The `notify_waiters` has to include all threads waiting to be notified in
`Object.wait()`.
The implementation also includes the threads waiting to re-enter the monitor in
`Object.wait()` which is wrong.
This update makes it right.
The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is
based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep
the existing behavior of this command.
The follwoing JVMTI vmTestbase tests are fixed to adopt to the
`GetObjectMonitorUsage()` correct behavior:
jvmti/GetObjectMonitorUsage/objmonusage001
jvmti/GetObjectMonitorUsage/objmonusage003
The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
A JCK bug will be filed and the tests have to be added into the JCK problem
list located in the closed repository by a separate sub-task before integration
of this update.
Also, please see and review the related CSR:
[8324677](https://bugs.openjdk.org/browse/JDK-8324677) Specification
clarification needed for JVM TI GetObjectMonitorUsage
Testing:
- tested with mach5 tiers 1-6
-
Commit messages:
- 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
Changes: https://git.openjdk.org/jdk/pull/17680/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17680=00
Issue: https://bugs.openjdk.org/browse/JDK-8324677
Stats: 25 lines in 5 files changed: 10 ins; 0 del; 15 mod
Patch: https://git.openjdk.org/jdk/pull/17680.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680
PR: https://git.openjdk.org/jdk/pull/17680
Re: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream [v2]
> FilteredFieldStream used by heap walking functions to iterate through > klass/superclasses/interfaces fields are known to have poor performance (see > [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details). > Heap walking API implementation is the last user of the klasses. > The fix reworks iteration through klass/superclasses/interfaces fields and > drops FilteredFieldStream-related code. > Additionally removed/updated includes of reflectionUtils.hpp. > > Testing: > - tier1..4; > - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different > heap walking functions); > - new test from #17580 (now the test runs several times faster). Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: remove recursion - Changes: - all: https://git.openjdk.org/jdk/pull/17661/files - new: https://git.openjdk.org/jdk/pull/17661/files/5edae77e..c064abdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17661=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17661=00-01 Stats: 43 lines in 1 file changed: 18 ins; 23 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661 PR: https://git.openjdk.org/jdk/pull/17661
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to jdk.javadoc look fine. - Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131
Re: RFR: 8325055: Rename Injector.h [v2]
On Wed, 31 Jan 2024 15:15:16 GMT, Kim Barrett wrote: >> Please review this trivial change that renames the file >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional > commit since the last revision: > > fix name in README Marked as reviewed by amenkov (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17656#pullrequestreview-1857623975
Integrated: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow
On Thu, 18 Jan 2024 02:17:56 GMT, Chris Plummer wrote: > I noticed that "clhsdb jstack" seemed to hang when I attached to process with > a somewhat large heap. It had taken over 10 minutes when I finally decided to > have a look at the SA process (using bin/jstack), which came up with the > following in the stack: > > > at > sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ObjectHeap.java:117) > at > sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ConcurrentLocksPrinter.java:70) > at > sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ConcurrentLocksPrinter.java:36) > at > sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/StackTrace.java:71) > > > This code is meant to print information about j.u.c. locks. It it works by > searching the entire java heap for instances of AbstractOwnableSynchronizer. > This is a very expensive operation because it means not only does SA need to > read in the entire java heap, but it needs to create a Klass mirror for every > heap object so it can determine its type. > > Our testing doesn't seem to run into this slowness problem because "clhsdb > jstack" only iterates over the heap if AbstractOwnableSynchronizer has been > loaded, which it won't be if no j.u.c. locks have been created. This seems to > be the case wherever we use "clhsdb jstack" in testing. We do have some tests > that likely result in j.u.c locks, but they all use "jhsdb jstack", which > doesn't have this issue (it requires use of the --locks argument to enable > printing of j.u.c locks). > > This issue was already called out in > [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am > proposing that "clhsdb jstack" not include j.u.c lock scanning by default, > and add the -l argument to enable it. This will make it similar to > bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a > --locks argument (which maps internally to the Jstack.java -l argument). > > The same changes are also being made to "clhsdb pstack". > > Tested with all tier1, tier2, and tier5 svc tests. This pull request has now been integrated. Changeset: 192349ee Author:Chris Plummer URL: https://git.openjdk.org/jdk/commit/192349eee4b6d50f16d44969eb882875c67d651d Stats: 228 lines in 10 files changed: 204 ins; 1 del; 23 mod 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow Reviewed-by: kevinw, amenkov - PR: https://git.openjdk.org/jdk/pull/17479
Re: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v4]
On Wed, 31 Jan 2024 23:07:16 GMT, Chris Plummer wrote: >> I noticed that "clhsdb jstack" seemed to hang when I attached to process >> with a somewhat large heap. It had taken over 10 minutes when I finally >> decided to have a look at the SA process (using bin/jstack), which came up >> with the following in the stack: >> >> >> at >> sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ObjectHeap.java:117) >> at >> sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ConcurrentLocksPrinter.java:70) >> at >> sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/ConcurrentLocksPrinter.java:36) >> at >> sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent@23-internal](jdk.hotspot.agent@23-internal)/StackTrace.java:71) >> >> >> This code is meant to print information about j.u.c. locks. It it works by >> searching the entire java heap for instances of AbstractOwnableSynchronizer. >> This is a very expensive operation because it means not only does SA need to >> read in the entire java heap, but it needs to create a Klass mirror for >> every heap object so it can determine its type. >> >> Our testing doesn't seem to run into this slowness problem because "clhsdb >> jstack" only iterates over the heap if AbstractOwnableSynchronizer has been >> loaded, which it won't be if no j.u.c. locks have been created. This seems >> to be the case wherever we use "clhsdb jstack" in testing. We do have some >> tests that likely result in j.u.c locks, but they all use "jhsdb jstack", >> which doesn't have this issue (it requires use of the --locks argument to >> enable printing of j.u.c locks). >> >> This issue was already called out in >> [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am >> proposing that "clhsdb jstack" not include j.u.c lock scanning by default, >> and add the -l argument to enable it. This will make it similar to >> bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has >> a --locks argument (which maps internally to the Jstack.java -l argument). >> >> The same changes are also being made to "clhsdb pstack". >> >> Tested with all tier1, tier2, and tier5 svc tests. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > simplify regex passed to String.split(). Thanks for the reviews Kevin and Alex! - PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1922065831
Re: RFR: 8325055: Rename Injector.h [v2]
On Thu, 1 Feb 2024 07:12:08 GMT, David Holmes wrote: > Seems fine. Thanks Trivial? - PR Comment: https://git.openjdk.org/jdk/pull/17656#issuecomment-1922036034
Re: RFR: JDK-8318566: Heap walking functions should not use FilteredFieldStream
On Wed, 31 Jan 2024 23:24:22 GMT, Chris Plummer wrote:
>> FilteredFieldStream used by heap walking functions to iterate through
>> klass/superclasses/interfaces fields are known to have poor performance (see
>> [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walking API implementation is the last user of the klasses.
>> The fix reworks iteration through klass/superclasses/interfaces fields and
>> drops FilteredFieldStream-related code.
>> Additionally removed/updated includes of reflectionUtils.hpp.
>>
>> Testing:
>> - tier1..4;
>> - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different
>> heap walking functions);
>> - new test from #17580 (now the test runs several times faster).
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 453:
>
>> 451: InstanceKlass* super_klass = ik->java_super();
>> 452: if (super_klass != nullptr) {
>> 453: start_index += add_instance_fields(super_klass, start_index);
>
> Does hotspot have any rules against potentially very deep recursion that can
> overflow the stack?
I looked at hotspot code and don't see "implementation limits" for level of
inheritance, so it looks like a valid concern.
Need to reimplement this without recursion.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1474976858
RFR: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range
The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently fail when run with `-Xcomp`. This happens when the compilation of methods on the worker threads interleaves with the 2 calls on the main thread to `mbean.getThreadCpuTime` to get the CPU time for all worker threads. The way the test is currently written, the worker threads are all usually waiting on a shared monitor when the 2 timings are taken. That is, in a successful run, the delta between the timings is always 0. When `-Xcomp` compilations kick in at the "wrong" time or take sufficiently long, the expected delta of 100 nanoseconds is easily exceeded. It does not make sense to run a timing test with such a small expected delta with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present. - Commit messages: - disable ThreadCpuTimeArray with xcomp Changes: https://git.openjdk.org/jdk/pull/17675/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17675=00 Issue: https://bugs.openjdk.org/browse/JDK-8325137 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17675/head:pull/17675 PR: https://git.openjdk.org/jdk/pull/17675
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code. - Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. lgtm; all look good - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote: > Can you confirm that you've run tier1-4 at least? Some of the library code > that is changed here is not tested in the lower tiers. I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921697168
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to >> admit it does not look very nice). >> >> >> diff --git >> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in >> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) >> did not help? Maybe then it is some other system library that drags in >> `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way >> too much that it does not need, so we can surely strip it of even more >> standard includes if that is what is required to fix this. > > > Unfortunately it did not help. > @MBaesken How annoying. :( I have now tried to remove _all_ system includes > from `debug_util.h`. Can you please try again building debug on AIX, to see > if it works without the `#undef` in `BufferedRenderPipe.c`? The AIX (fast)debug build still fails . - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks good to me. I looked through all the changes. - Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v6]
> 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 with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - Restore AIX dirent64 et al defines - Rollback AIX changes since they are now tracked in JDK-8324834 - Remove superfluous setting of FOB64 - Replace all foo64() with foo() for large-file functions in the JDK - 8324539: Do not use LFS64 symbols in JDK libs - Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17538=05 Stats: 233 lines in 23 files changed: 14 ins; 105 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to >> admit it does not look very nice). >> >> >> diff --git >> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in >> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) >> did not help? Maybe then it is some other system library that drags in >> `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way >> too much that it does not need, so we can surely strip it of even more >> standard includes if that is what is required to fix this. > > > Unfortunately it did not help. @MBaesken How annoying. :( I have now tried to remove *all* system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921455438
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v5]
> 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 incrementally with one additional commit since the last revision: Remove all system includes from debug_util.h - Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/d6c64bc4..6e9ec631 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17538=04 - incr: https://webrevs.openjdk.org/?repo=jdk=17538=03-04 Stats: 10 lines in 4 files changed: 6 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie 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 seven >> additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to > admit it does not look very nice). > > > diff --git > a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 > @MBaesken So my fix in > [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) > did not help? Maybe then it is some other system library that drags in > `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way > too much that it does not need, so we can surely strip it of even more > standard includes if that is what is required to fix this. Unfortunately it did not help. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368
Re: RFR: 8325109: Sort method modifiers in canonical order
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few > do not involve `static` but instead puts `final` or `abstract` in the correct > place. > > I have deliberately stayed away from `default` in this PR, since they should > probably get a more thorough treatment, see > https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue. - PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
On Thu, 1 Feb 2024 09:42:00 GMT, Suchismith Roy wrote: >> In addition, the nullptr check is important to avoid undefined behavior when >> passing `pointer_to_dot` to any string function. > > Ok. So then may be we can return a nullptr and do a log_info(os) with the > correct error report ? @tstuefe @TheRealMDoerr I'd probably use `log_info(library)`. - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474449287
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Tue, 30 Jan 2024 14:15:57 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 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 seven additional > commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs I skimmed through the changes and they look okay. Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921189429
RFR: 8325109: Sort method modifiers in canonical order
This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. - Commit messages: - 8325109: Sort method modifiers in canonical order Changes: https://git.openjdk.org/jdk/pull/17670/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17670=00 Issue: https://bugs.openjdk.org/browse/JDK-8325109 Stats: 61 lines in 39 files changed: 0 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/17670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17670/head:pull/17670 PR: https://git.openjdk.org/jdk/pull/17670
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library ibm_16_am.a shared archive >> file on AIX. >> Hence we are providing a function which will additionally search for .a file >> on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional > commit since the last revision: > > spelling I'm busy with FOSDEM this week and probably next. Will look at this end of next week or the week after. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1921004805
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]
On Thu, 1 Feb 2024 04:17:41 GMT, Martin Doerr wrote: >> An assertion is only used for debug builds. Such an error should be handled >> in product builds as well. I think an attempt to load an invalid library >> should simply fail. You may add logging if needed. >> @tstuefe: Do you agree or have another proposal to handle such errors? > > In addition, the nullptr check is important to avoid undefined behavior when > passing `pointer_to_dot` to any string function. Ok. So then may be we can return a nullptr and do a log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474128334
Re: RFR: 8324845: management.properties text "interface name" is misleading [v2]
On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls wrote: >> We have the text "host-or-interface-name" describing the >> com.sun.management.jmxremote.host property in management.properties, but >> interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts. >> It should just say it needs to be a host name or address. >> >> This change only affects comment text in a properties file. >> >> (We don't currently mention this property in other docs, e.g. in the M >> guide.) > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > text update Thanks for the reviews! - PR Comment: https://git.openjdk.org/jdk/pull/17615#issuecomment-1920859573
Integrated: 8324845: management.properties text "interface name" is misleading
On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls wrote: > We have the text "host-or-interface-name" describing the > com.sun.management.jmxremote.host property in management.properties, but > interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts. > It should just say it needs to be a host name or address. > > This change only affects comment text in a properties file. > > (We don't currently mention this property in other docs, e.g. in the M > guide.) This pull request has now been integrated. Changeset: d9331bfd Author:Kevin Walls URL: https://git.openjdk.org/jdk/commit/d9331bfd49461c08e165e8f202cbbf88cc0ecec1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8324845: management.properties text "interface name" is misleading Reviewed-by: mchung, alanb - PR: https://git.openjdk.org/jdk/pull/17615
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie 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 seven >> additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to > admit it does not look very nice). > > > diff --git > a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1920844523
