On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken wrote:
> Currently jcmd command GC.heap_dump only works with an additionally provided
> file name.
> Syntax : GC.heap_dump [options]
>
> In case the JVM has the XX - flag HeapDumpPath set, we should support an
> add
On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote:
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|
On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote:
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|
.java:1597)
>
>
> Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not
> seem to have it on our Alpine Linux test system.
> So better avoid the check because it is based on false assumptions.
Matthias Baesken has updated the pull reques
On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote:
> The change of JDK-8294960 has brought an increase of required metaspace for
> this test on AIX which seems to go beyond 23m in most cases. So I propose
> another slight increment.
>
> Why AIX needs more metaspace compared to other
On Tue, 9 Jul 2024 12:52:34 GMT, Thomas Stuefe wrote:
> Checked and Alpine processes have a [heap] segment. Could you try that?
Yes there is an entry [heap] in the file column of the lengthy table.
Do you think this is present on all Linux platforms? If I replace the vdso
with [heap] maybe
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
>
On Mon, 8 Jul 2024 14:24:12 GMT, Severin Gehwolf wrote:
> @MBaesken Since you've noticed the failing test in your CI could you please
> verify the issue is gone with this? I don't have an Alpine Linux setup to
> easily test this exclusion. Thanks!
Hi Severin, sure ! I put it into our
Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
serviceability/dcmd/vm/SystemDumpMapTest.java
Missing patterns in dump:
0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
+(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\]
test SystemDumpMapTest.jmx(): failure
On Thu, 20 Jun 2024 11:58:23 GMT, Matthias Baesken wrote:
> The following issue has been observed when running
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorThreadTest (and some
> other :tier1 tests)
> on Linux with ubsan enabled binaries :
>
> test/hotspot/jt
On Thu, 20 Jun 2024 11:58:23 GMT, Matthias Baesken wrote:
> The following issue has been observed when running
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorThreadTest (and some
> other :tier1 tests)
> on Linux with ubsan enabled binaries :
>
> test/hotspot/jt
The following issue has been observed when running
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorThreadTest (and some
other :tier1 tests)
on Linux with ubsan enabled binaries :
test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.cpp:518:9:
runtime error: null pointer
On Tue, 11 Jun 2024 13:00:44 GMT, Matthias Baesken wrote:
> When running HS :tier1 tests with ubsan-enabled binaries, the following issue
> is reported :
> test
> serviceability/jvmti/FollowReferences/FieldIndices/FieldIndicesTest.jtr
>
> test/hotspot/jtreg/se
On Tue, 11 Jun 2024 13:00:44 GMT, Matthias Baesken wrote:
> When running HS :tier1 tests with ubsan-enabled binaries, the following issue
> is reported :
> test
> serviceability/jvmti/FollowReferences/FieldIndices/FieldIndicesTest.jtr
>
> test/hotspot/jtreg/se
When running HS :tier1 tests with ubsan-enabled binaries, the following issue
is reported :
test
serviceability/jvmti/FollowReferences/FieldIndices/FieldIndicesTest.jtr
test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp:276:11:
runtime error: null
On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote:
> With ubsan enabled binaries we run into the following issue in HS :tier4
> tests :
> e.g.
> vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr
>
> /jdk/test/hotspot/jtreg/vmTestba
On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote:
> With ubsan enabled binaries we run into the following issue in HS :tier4
> tests :
> e.g.
> vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr
>
> /jdk/test/hotspot/jtreg/vmTestba
With ubsan enabled binaries we run into the following issue in HS :tier4 tests :
e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr
/jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16:
runtime error: null pointer passed as argument 2, which is
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robu
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robu
When running with ubsan - enabled binaries (--enable-ubsan),
in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
are detected in get_object_monitor_usage .
// null out memory for robustness
memset(ret.waiters, 0, ret.waiter_count * sizeof(jthread *));
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
On Wed, 10 Apr 2024 04:34:53 GMT, Chris Plummer wrote:
> One other thing I just realized is that if we go through with this change,
> then we can't in the future change VM.heap_dump so it can be used without any
> filename (make it use a default filename when no filename is specified).
>
On Mon, 8 Apr 2024 06:47:09 GMT, Matthias Baesken wrote:
> If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?
I could open a separate JBS issue (or issues) for scenario 4 and 5 , if this is
desired.
-
PR Comment: https://git.openjdk.org/jdk/pull/18
On Fri, 5 Apr 2024 22:47:55 GMT, Alex Menkov wrote:
> I don't have strong opinion if it's good to have default file path for `jcmd
> GC.heap_dump`, just some thoughts. We have several ways to heap dump:
>
> 1. `-XX:+HeapDumpOnOutOfMemoryError`
> 2. `-XX:+HeapDumpBeforeFullGC`,
On Fri, 5 Apr 2024 08:57:09 GMT, Sandra Payne wrote:
> Many customers may see such a change as a regression, as they rely on
> separation of location for heap dumps generated by the > JVM at OOME and heap
> dumps manually pulled by various other processes attaching to the JVM.
With this
On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer wrote:
> There's still the question of whether or not it is even appropriate to have
> -XX options taking the place of jcmd options.
Some people (like our cloud support colleagues and also some who commented)
would like this approach, some find
On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer wrote:
> There's also a question of whether currently missing doc updates for
> HeapDumpGzipLevel should be made part of this PR
> because it complicates back porting.
It should most likely be a separate PR (the title of this one does not match,
On Thu, 28 Mar 2024 07:02:16 GMT, Thomas Stuefe wrote:
> Wouldn't this just be a case of changing a flag description? As luck has it,
> the flag already has a generic name that is not tied to OOMs.
Yes it is some work on documentation (but seems some doc work needs to be done
anyway because
On Wed, 27 Mar 2024 23:33:18 GMT, Chris Plummer wrote:
> I did get feedback from a couple of our support engineers. One felt it was of
> no real benefit as it was just as easy to provide the > filename as an
> argument to the jcmd.
That might be true for this support engineer, but not for
On Wed, 27 Mar 2024 23:26:14 GMT, Chris Plummer wrote:
>
> Backporting also came to mind since the trouble shooting guide would need to
> be updated for each Oracle version this PR is backported to. And yes,
> HeapDumpGzipLevel docs need to match the actual implementation. I'm not sure
> if
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
adjust java.1 man page
-
On Tue, 26 Mar 2024 21:42:15 GMT, Chris Plummer wrote:
> A docs CR will need to be filed to get it updated (and I see it is already
> appears out-of-date w.r.t. HeapDumpGzipLevel)
Sorry maybe it is maybe obvious for you but where should I open a "docs CR",
would that be a separate JBS issue
On Mon, 25 Mar 2024 13:26:12 GMT, Matthias Baesken wrote:
> We still have quite a lot of OS400 / pase related coding in the hotspot AIX
> codebase. But this does not work and was never supported in OpenJDK. So we
> can remove this.
This pull request has now been integrated.
On Tue, 26 Mar 2024 14:18:34 GMT, Matthias Baesken wrote:
>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX
>> codebase. But this does not work and was never supported in OpenJDK. So we
>> can remove this.
>
> Matthias Baesken has
On Mon, 25 Mar 2024 13:26:12 GMT, Matthias Baesken wrote:
> We still have quite a lot of OS400 / pase related coding in the hotspot AIX
> codebase. But this does not work and was never supported in OpenJDK. So we
> can remove this.
Hi Christoph, I adjusted/removed the
> We still have quite a lot of OS400 / pase related coding in the hotspot AIX
> codebase. But this does not work and was never supported in OpenJDK. So we
> can remove this.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last
On Tue, 26 Mar 2024 09:27:01 GMT, Christoph Langer wrote:
>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX
>> codebase. But this does not work and was never supported in OpenJDK. So we
>> can remove this.
>
> src/hotspot/os/aix/os_aix.cpp line 626:
>
>> 624:
>>
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
suggestions from Chris for diagnosti
On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
We still have quite a lot of OS400 / pase related coding in the hotspot AIX
codebase. But this does not work and was never supported in OpenJDK. So we can
remove this.
-
Commit messages:
- JDK-8328930
Changes: https://git.openjdk.org/jdk/pull/18471/files
Webrev:
On Thu, 21 Mar 2024 16:44:29 GMT, Chris Plummer wrote:
> I'd like to consult with a couple of people at Oracle who unfortunately are
> out of town until Monday. Can this PR wait until next week?
That's fine, no need to rush it into jdk-head this week.
-
PR Comment:
On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
> IIUC no actual failures are observed other than those pertaining to
> AssertWXAtThreadSync
We saw sporadic crashes in our jtreg (maybe also jck?) runs; only **_later_**
we enabled AssertWXAtThreadSync for more checking.
-
On Tue, 19 Mar 2024 10:13:16 GMT, Matthias Baesken wrote:
>> So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
>> See the `level` variable in `HeapDumpDCmd::execute` . Yeah you are probably
>> right we should make it consistent.
>
>> If -X
On Sat, 16 Mar 2024 12:50:05 GMT, Matthias Baesken wrote:
>> src/hotspot/share/services/diagnosticCommand.cpp line 475:
>>
>>> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
>>> 474:DCmdWithParser(output, heap),
On Fri, 15 Mar 2024 19:22:58 GMT, Chris Plummer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adjust jcmd manpage, help and globals comment
>
> src/hotspot/share/services/
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust jcmd manpage, help and globals co
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
change is on to is enabled
---
On Fri, 15 Mar 2024 08:35:56 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
> to switch to `WXWrite` before transitioning to the vm.
>
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>
On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassL
On Fri, 15 Mar 2024 08:00:50 GMT, Yi Yang wrote:
> Maybe `dump` and `dump_to`
Why not, I renamed the method to dump_to .
-
PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1999165924
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
rename dump_to_heapdump_path
---
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
fix COPYRIGHT info in HeapDumpJcmdPresetP
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled`
> to switch to `WXWrite` before transitioning to the vm.
>
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>
On Thu, 14 Mar 2024 13:43:09 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
add test HeapDumpJcmdPresetPat
On Wed, 13 Mar 2024 16:40:33 GMT, Richard Reingruber wrote:
> @MBaesken found 2 more locations in jvmti that need switching to `WXWrite`
>
> JvmtiExport::get_jvmti_interface GetCarrierThread
>
> Both use `ThreadInVMfromNative`.
Should we address those 2 more findings in this PR ? Or open a
On Thu, 14 Mar 2024 09:13:03 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should suppor
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust text related to HeapDumpPath in
On Thu, 14 Mar 2024 02:39:28 GMT, Yi Yang wrote:
> Looks reasonable, this is a harmless change, but the name
> `dump_to_heapdump_path` looks too details(and somewhat strange) to me
Do you maybe have a good suggestion for a new name ?
-
PR Comment:
On Fri, 8 Mar 2024 10:12:06 GMT, Matthias Baesken wrote:
> There are a number of places remaining in the linux/macOS native JDK codebase
> where we use the RESTARTABLE macro with close, but this is unwanted on
> Linux/macOS.
This pull request has now been integrated.
Changeset:
On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken wrote:
>> There are a number of places remaining in the linux/macOS native JDK
>> codebase where we use the RESTARTABLE macro with close, but this is unwanted
>> on Linux/macOS.
>
> Matthias Baesken has updated the pu
On Tue, 12 Mar 2024 13:27:13 GMT, Kevin Walls wrote:
>That's not necessarily wrong, and may not be serious enough to refuse
>-overwrite when using HeapDumpPath, but we want to
>find a way of making things clear (I was not going to suggest separate
>sequence numbers... 8-) )
Thanks for
On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls wrote:
>Does dump_to_heapdump_path() not print the ("Dumping heap to %s ...", path)
>message?
>That seems important when the user isn't specifying it directly.
The path is already printed, here is an example (the JVM with pid 219447 was
started
; directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the
> path is intended/recommended for usage also in the jcmd case.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
alloc_and_create_heapdump_pathname adjust
On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls wrote:
>jcmd GC.heap_dump has the overwrite flag.
>OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.
There is (with this patch) still just one sequence number and it is incremented
by all invocations of
On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken wrote:
> Currently jcmd command GC.heap_dump only works with an additionally provided
> file name.
> Syntax : GC.heap_dump [options]
>
> In case the JVM has the XX - flag HeapDumpPath set, we should support an
> add
On Tue, 12 Mar 2024 06:12:53 GMT, David Holmes wrote:
> This seems fine to me, but please ensure someone from serviceability also
> approves it.
>
Hi David, thanks for the review !
Someone from Serviceability Group interested to comment/review ?
-
PR Comment:
On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken wrote:
>> There are a number of places remaining in the linux/macOS native JDK
>> codebase where we use the RESTARTABLE macro with close, but this is unwanted
>> on Linux/macOS.
>
> Matthias Baesken has updated the pu
> There are a number of places remaining in the linux/macOS native JDK codebase
> where we use the RESTARTABLE macro with close, but this is unwanted on
> Linux/macOS.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revisi
On Fri, 8 Mar 2024 10:24:54 GMT, Alan Bateman wrote:
>> There are a number of places remaining in the linux/macOS native JDK
>> codebase where we use the RESTARTABLE macro with close, but this is unwanted
>> on Linux/macOS.
>
> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line
There are a number of places remaining in the linux/macOS native JDK codebase
where we use the RESTARTABLE macro with close, but this is unwanted on
Linux/macOS.
-
Commit messages:
- JDK-8327468
Changes: https://git.openjdk.org/jdk/pull/18164/files
Webrev:
On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
This pull request has now been integrated.
Changeset:
On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman wrote:
> Latest version looks good to me. As have been pointed out, there at least 2
> files where the copyright header was updated but there are no changes, I
> assume left over from previous iterations. I assume the RESTARTABLE-close in
>
On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust COPYRIGHT year info
>
> src/java.base/unix/native/libjava/childpro
On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Introduce windows jni_util_md.h
>
> src/java.base/share/native/libjava/jni_ut
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> introduce unix jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> src/java.base/share/native/libjava/jni_util.h line 243:
>
>> 241:
We define the RESTARTABLE macro again and again at a lot of places in the JDK
native codebase. This could be centralized to avoid repeating it again and
again !
-
Commit messages:
- JDK-8327444
Changes: https://git.openjdk.org/jdk/pull/18132/files
Webrev:
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote:
>>> I hope finally the AIX part of this PR is done.
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>> build/test queue.
>
>>
>> Thanks for the AIX related effort ;
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
On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote:
>
> Thanks for the AIX related effort ; I put it again into our internal
> build/test queue.
With the latest commit the build again fails on AIX with this error
/jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
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
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
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/Buffere
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 requ
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
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote:
> The get_total_or_available_swap_space_size coding misses AIX support, we only
> return 0. This should be enhanced.
> The perfstat API can be used, see
> https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-
On Thu, 25 Jan 2024 14:25:51 GMT, Thomas Stuefe wrote:
> Do we need the cast? perfstat_memory_total_t members are all 64-bit, no?
>
> Also, can we shorten this to:
>
> ```
> return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096;
> ```
Hi Thomas, I see no types defined
On Thu, 25 Jan 2024 14:11:35 GMT, Kevin Walls wrote:
> I can't try this and don't use AIX, but it looks good. It follows the same
> pattern as the other AIX cases in the file.
>
> Although the others (e.g. line 200) don't throw_internal_error if the call
> returns -1, they just return -1. You
The get_total_or_available_swap_space_size coding misses AIX support, we only
return 0. This should be enhanced.
The perfstat API can be used, see
https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface
.
-
Commit messages:
- JDK-8324637
Changes:
1 - 100 of 227 matches
Mail list logo
