On Tue, 23 Sep 2025 14:42:30 GMT, Joachim Kern wrote:
>> The new tests
>> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#fork
>> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#posix_spawn
>> fail on AIX.
>> The tests were added with
>> [JDK-8210549](https://bugs.openjdk.org/browse/JDK-
On Mon, 22 Sep 2025 15:40:06 GMT, Joachim Kern wrote:
>> The new tests
>> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#fork
>> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#posix_spawn
>> fail on AIX.
>> The tests were added with
>> [JDK-8210549](https://bugs.openjdk.org/browse/JDK-
On Mon, 15 Sep 2025 11:13:56 GMT, Joachim Kern wrote:
> The new tests
> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#fork
> java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#posix_spawn
> fail on AIX.
> The tests were added with
> [JDK-8210549](https://bugs.openjdk.org/browse/JDK-821054
On Mon, 22 Sep 2025 13:31:36 GMT, Matthias Baesken wrote:
> > Hi Thomas, fcntl(4, F_CLOSEM, 0); closes all open descriptors >=4. Its a
> > special AIX feature linux does not have i guess.
>
> Might be worth pointing out in the comment above.
:-) Yes, that is a quite important part and easily m
On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote:
>> While investigating
>> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the
>> timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on
>> Linux.
>>
>> The reason is that the test performs a
On Fri, 29 Aug 2025 09:00:20 GMT, Stefan Karlsson wrote:
>> While investigating
>> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the
>> timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on
>> Linux.
>>
>> The reason is that the test performs a
On Thu, 28 Aug 2025 07:46:36 GMT, Stefan Karlsson wrote:
> While investigating
> [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the
> timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on
> Linux.
>
> The reason is that the test performs a `fcnt
On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe wrote:
> A customer reported an error where a well-known system library, upon loading
> into the JVM process (via a longish indirect dependency chain), changed the
> signal disposition of the process for SIGPIPE to SIG_IGN. This gets
On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix comments about closeDescriptors
>
> It looks like I created a merge conflict by askin
On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs wrote:
> It looks like I created a merge conflict by asking to fix these. Another PR
> https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time
> the other PR had not started). The least chaos may be created by backing out
> those
od ad-hoc analysis tool as well as a point where we add more tests
> for other signals, should we ever need to. This patch, however, is
> deliberately restricted to just fixing SIGPIPE.
Thomas Stuefe has updated the pull request with a new target base due to a
merge or a rebase. The pull r
od ad-hoc analysis tool as well as a point where we add more tests
> for other signals, should we ever need to. This patch, however, is
> deliberately restricted to just fixing SIGPIPE.
Thomas Stuefe has updated the pull request incrementally with one additional
comm
On Thu, 7 Aug 2025 05:41:45 GMT, Thomas Stuefe wrote:
>> A customer reported an error where a well-known system library, upon loading
>> into the JVM process (via a longish indirect dependency chain), changed the
>> signal disposition of the process for SIGPIPE to
On Wed, 6 Aug 2025 14:04:38 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Feedback Roger
>
> src/java.base/unix/native/libjava/childproc.c line 429:
&g
od ad-hoc analysis tool as well as a point where we add more tests
> for other signals, should we ever need to. This patch, however, is
> deliberately restricted to just fixing SIGPIPE.
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last r
A customer reported an error where a well-known system library, upon loading
into the JVM process (via a longish indirect dependency chain), changed the
signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited
down to child processes, where it caused child processes to not r
On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe wrote:
> Hi, please consider the following patch.
>
> This patch replaces the existing close-file-descriptors-logic we follow
> before exec'ing a target binary: instead of explicitly closing the file
> descriptors, we mark t
On Tue, 17 Jun 2025 05:56:15 GMT, Thomas Stuefe wrote:
>> Hi, please consider the following patch.
>>
>> This patch replaces the existing close-file-descriptors-logic we follow
>> before exec'ing a target binary: instead of explicitly closing the file
>> d
On Mon, 16 Jun 2025 18:32:15 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into
>> JDK-8210
On Mon, 16 Jun 2025 18:32:15 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into
>> JDK-8210
d that with this patch, we close all file descriptors. I also
> verified the fallback path (where we brute-force-iterate all descriptors up
> to _SC_OPEN_MAX).
>
> I ran manually all tests from test/jdk/java/base/Process*, and verified that
> these tests run as part of the GHAs, wh
d that with this patch, we close all file descriptors. I also
> verified the fallback path (where we brute-force-iterate all descriptors up
> to _SC_OPEN_MAX).
>
> I ran manually all tests from test/jdk/java/base/Process*, and verified that
> these tests run as part of the
(for JDK 26)
Note: This PR is a continuation of the old PR here:
https://github.com/openjdk/jdk/pull/25260; had to close the old one since I had
Skara problems after the JDK25 split-off.
See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the
ratio behind this removal.
Pat
On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe wrote:
> Not for JDK 25
>
> See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the
> ratio behind this removal.
>
> Patch
>
> - removes all code handling the VFORK mode.
> - removes or rewrites
On Thu, 29 May 2025 14:18:49 GMT, Roger Riggs wrote:
>> Thomas Stuefe 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 two addi
On Sat, 24 May 2025 05:49:43 GMT, Thomas Stuefe wrote:
> See bug description. We now unblock all signals in both FORK and POSIX_SPAWN
> launch modes. This fixes the problem and makes the behavior consistent across
> these two modes.
>
> I left the VFORK mode alone since I bel
d that with this patch, we close all file descriptors. I also
> verified the fallback path (where we brute-force-iterate all descriptors up
> to _SC_OPEN_MAX).
>
> I ran manually all tests from test/jdk/java/base/Process*, and verified that
> these tests run as part of the GHA
d that with this patch, we close all file descriptors. I also
> verified the fallback path (where we brute-force-iterate all descriptors up
> to _SC_OPEN_MAX).
>
> I ran manually all tests from test/jdk/java/base/Process*, and verified that
> these tests run as part of the GHA
o JDK 25; the fix is small
> and clean enough to not worry me.
Thomas Stuefe 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 two additional
commits sin
See bug description. We now unblock all signals in both FORK and POSIX_SPAWN
launch modes. This fixes the problem and makes the behavior consistent across
these two modes.
I left the VFORK mode alone since I believe the signal state is still shared
with the parent. One more reason to get rid of
On Wed, 21 May 2025 19:10:49 GMT, Roger Riggs wrote:
>> Hi, please consider the following patch.
>>
>> This patch replaces the existing close-file-descriptors-logic we follow
>> before exec'ing a target binary: instead of explicitly closing the file
>> descriptors, we mark them as CLOEXEC. Tha
On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote:
> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the
> suggestion to use VFORK in jspawnhelper misbehaves. But
> [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK!
> So the warning mess
On Mon, 19 May 2025 12:23:07 GMT, Thomas Stuefe wrote:
> Hi, please consider the following patch.
>
> This patch replaces the existing close-file-descriptors-logic we follow
> before exec'ing a target binary: instead of explicitly closing the file
> descriptors, we mark t
On Sat, 17 May 2025 06:49:37 GMT, Thomas Stuefe wrote:
> For the ratio behind this please see the companion CSR:
> https://bugs.openjdk.org/browse/JDK-8357180.
>
> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>
> This patch just writes a deprecation
On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote:
>> For the ratio behind this please see the companion CSR:
>> https://bugs.openjdk.org/browse/JDK-8357180.
>>
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>>
>> This patch just wr
Hi, please consider the following patch.
This patch replaces the existing close-file-descriptors-logic we follow before
exec'ing a target binary: instead of explicitly closing the file descriptors,
we mark them as CLOEXEC. That simplifies the logic: it gets rid of the awkward
tiptoeing around t
On Mon, 19 May 2025 15:58:17 GMT, Alan Bateman wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use string block
>
> src/java.base/unix/classes/java/lang/Proces
rty (preferred) or use FORK mode
> instead (-Djdk.lang.Process.launchMechanism=FORK).
> ...
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
use string block
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25282/files
- new: https
For the ratio behind this please see the companion CSR:
https://bugs.openjdk.org/browse/JDK-8357180.
We plan to deprecate this in JDK 25 and to remove it in JDK 26.
This patch just writes a deprecation message to stderr:
08:46:38 thomas@starfish java -Djdk.lang.Process.launchMechanism=VFORK
S
On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe wrote:
> Not for JDK 25
>
> See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the
> ratio behind this removal.
>
> Patch
>
> - removes all code handling the VFORK mode.
> - removes or rewrites
See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the
ratio behind this removal.
Patch
- removes all code handling the VFORK mode.
- removes or rewrites comments explaining use of vfork by the JVM.
- we now print out an error message to stderr if the user still specifies
On Wed, 14 May 2025 00:32:08 GMT, David Holmes wrote:
>> Hmm, glibc keeps it very vague in the vfork() manpage, stating that "On some
>> implementations, vfork() is equivalent to fork()." AIX manpage says just
>> "The vfork subroutine is supported as a compatibility interface for older
>> Berk
On Tue, 13 May 2025 12:47:39 GMT, Thomas Stuefe wrote:
>> Er? This is news to me. Where do you see this? I see we only pass the
>> `helperpath` (carrying `jspawnhelper` path only to `POSIX_SPAWN` mode:
>>
>>
>> static pid_t
>> startChild(JNIEnv *env, jobjec
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Tue, 13 May 2025 10:26:51 GMT, Aleksey Shipilev wrote:
>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 346:
>>
>>> 344: if (ret != EINVAL)
>>> 345: detail = tmpbuf;
>>> 346: }
>>
>> Pre-existing, possibly as follow-up:
>>
>> I wonder whether we can do mor
On Tue, 13 May 2025 09:13:58 GMT, Aleksey Shipilev wrote:
>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 377:
>>
>>> 375: throwIOExceptionImpl(env, errnum, defaultDetail, "");
>>> 376: }
>>> 377: }
>>
>> Why only for POSIX_SPAWN? We use jspawnhelper also for fork/vfork+exec.
On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Wed, 30 Apr 2025 17:26:09 GMT, Aleksey Shipilev wrote:
> @tstuefe -- I know you love `jspawnhelper` bugs, want to take a look?
Love is a strong word :-)
I missed this one. I will take a look.
-
PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2853797278
On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl wrote:
> Hi all,
>
> please review this change that implements (currently Draft) JEP: G1:
> Improve Application Throughput with a More Efficient Write-Barrier.
>
> The reason for posting this early is that this is a large change, and the JEP
On Tue, 4 Feb 2025 22:59:55 GMT, Shaojin Wen wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fx comments
>
> Thanks @RogerRiggs, your suggestion is great, I have fixed it, please help me
> review it again.
> > @we
On Tue, 4 Feb 2025 13:43:08 GMT, Shaojin Wen wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip coder change
>
>> ```java
>> StringBuilder buf = new StringBuilder();
>> buf.append('中');
>>
>> final Count
On Tue, 4 Feb 2025 00:59:57 GMT, Shaojin Wen wrote:
>> The following code can reproduce the problem, writing out of bounds causes
>> JVM Crash
>>
>>
>>StringBuilder buf = new StringBuilder();
>> buf.append('中');
>>
>> final CountDownLatch latch = new CountDownLatch(10);
>> Run
On Tue, 21 Jan 2025 06:51:10 GMT, Thomas Stuefe wrote:
>>> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for
>>> process handling. I suggest removing the "unofficial" link, it does not
>>> include useful information at this point
On Mon, 20 Jan 2025 19:34:53 GMT, Thomas Stuefe wrote:
>> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for
>> process handling.
>> I suggest removing the "unofficial" link, it does not include useful
>> information at this point and is fr
On Mon, 20 Jan 2025 17:13:19 GMT, Roger Riggs wrote:
> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process
> handling. I suggest removing the "unofficial" link, it does not include
> useful information at this point and is fragile.
>
> The current behavior always sett
On Wed, 23 Oct 2024 05:08:47 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore wrote:
> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause
> excess dependency checking for c2 compiled code and shows a performance
> regression in a new JMH performance test for MethodHandles (to be checked in
> at a
On Tue, 4 Jun 2024 13:02:18 GMT, Alexey Semenyuk wrote:
>> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
>> launcher instead of raw Executor. This makes MainClassTest test run app
>> launchers with retries. This change addresses the primary issue.
>>
>> Fix inconsi
On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Thu, 7 Nov 2024 12:48:12 GMT, Afshin Zafari wrote:
>> - `VMATree` is used instead of `SortedLinkList` in new class
>> `VirtualMemoryTrackerWithTree`.
>> - A wrapper/helper `RegionTree` is made around VMATree to make some calls
>> easier.
>> - Both old and new versions exist in the code a
On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A
> future me chasing
On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe wrote:
> > I think you may be throwing the baby out with the bath water when it comes
> > to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> > anything that states `__stdcall` is ONLY for 32-bit!
On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters wrote:
> I think you may be throwing the baby out with the bath water when it comes to
> `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> anything that states `__stdcall` is ONLY for 32-bit!
stdcall and cdecl are 32-bit Wi
On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote:
> > Can we get rid of `JNICALL` too, please?
> > Or would that change be too big?
>
> There's >1000 in java.base, lots more elsewhere, so it would be a lot of
> files and would hide the core changes. So maybe for a follow-up PR that does
> t
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore wrote:
>> This change stores InstanceKlass for interface and abstract classes in the
>> non-class metaspace, since class metaspace will have limits on number of
>> classes that can be represented when Lilliput changes go in. Classes that
>> h
On Thu, 29 Aug 2024 12:08:37 GMT, Coleen Phillimore wrote:
>> This change stores InstanceKlass for interface and abstract classes in the
>> non-class metaspace, since class metaspace will have limits on number of
>> classes that can be represented when Lilliput changes go in. Classes that
>>
On Tue, 27 Aug 2024 15:38:24 GMT, Thomas Stuefe wrote:
>>> I don't think the costs for two address comparisons matter, not with the
>>> comparatively few deallocations that happen (few hundreds or few thousand).
>>> If deallocate is hot, we are using metaspace
On Thu, 29 Aug 2024 11:37:19 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp
>> line 79:
>>
>>> 77:
>>> 78: static bool can_compress_element(const Klass* klass) {
>>> 79: return Metaspace::is_in_class_space(klass) &&
>>
>> Su
On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore wrote:
>> This change stores InstanceKlass for interface and abstract classes in the
>> non-class metaspace, since class metaspace will have limits on number of
>> classes that can be represented when Lilliput changes go in. Classes that
>>
On Mon, 26 Aug 2024 13:57:16 GMT, Coleen Phillimore wrote:
> > I don't think the costs for two address comparisons matter, not with the
> > comparatively few deallocations that happen (few hundreds or few thousand).
> > If deallocate is hot, we are using metaspace wrong.
>
> MethodData does a
On Fri, 23 Aug 2024 20:46:39 GMT, Coleen Phillimore wrote:
>> This change stores InstanceKlass for interface and abstract classes in the
>> non-class metaspace, since class metaspace will have limits on number of
>> classes that can be represented when Lilliput changes go in. Classes that
>>
On Fri, 23 Aug 2024 19:26:46 GMT, Coleen Phillimore wrote:
> Yes, is_in_klass_space was just to direct where to deallocate the metaspace
> pointer. In your patch isn't the contains metaspace call still very slow? Or
> I suppose for class space, it's not because it's a fixed space. But it's not
On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore wrote:
> This change stores InstanceKlass for interface and abstract classes in the
> non-class metaspace, since class metaspace will have limits on number of
> classes that can be represented when Lilliput changes go in. Classes that
> have
On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore wrote:
> This change stores InstanceKlass for interface and abstract classes in the
> non-class metaspace, since class metaspace will have limits on number of
> classes that can be represented when Lilliput changes go in. Classes that
> have
On Wed, 17 Jul 2024 14:02:01 GMT, Thomas Stuefe wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright headers
>
> src/hotspot/share/code/codeCache.cpp line 1800
On Wed, 17 Jul 2024 14:02:31 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
>> enabling jcmd diagnostic commands that issue an output file to accept the
>> `%p` pattern in the file name and substitute it for the PID.
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
> propos
On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [JDK-808](https://bugs.openjdk.org/browse/JDK-808)
> enabling `javap -system` to handle internal class names.
>
> Thanks,
> Sonia
+1
-
Marked as reviewed by stuefe (Reviewer
On Wed, 26 Jun 2024 07:54:16 GMT, Alan Bateman wrote:
> > Question, what is the noreg-hard label used for?
>
> It's the label to mean that it's too hard or impossible write a regression
> test. It is documented in the [JBS label
> dictionary](https://openjdk.org/guide/#jbs-label-dictionary) bu
On Tue, 25 Jun 2024 19:49:07 GMT, Chen Liang wrote:
> Technically javap accepts both notations of `a.b.C` and `a/b/C.class` and
> accepts both `.` and `$` as inner class separators. So this is fine. However
> it's hard to verify that the jdk in `--system` is really used, so I put a
> noreg-har
On Thu, 20 Jun 2024 12:06:43 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>> memory/c
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Okay. Any idea what fixed the test?
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19691#pullrequestreview-2115358
On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall
On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes wrote:
> > "To use these functions safely with plain chars (or signed chars), the
> > argument should first be converted to unsigned char"
>
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't
> actually do anything. Ev
On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall ensu
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Decreasing diff size addressing unnecessary changes
>
> Hi all,
>
> I think there's some consensus
On Tue, 4 Jun 2024 13:34:30 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Mon, 13 May 2024 18:01:25 GMT, Sonia Zaldana Calles
wrote:
> > This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI
> > functions GetStaticMethodID, GetMethodID and NewObject return NULL with a
> > pending exception when they fail. So I would expect
> > CHECK_EXCEPTI
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles
wrote:
> > This may be food for another RFE, to keep this patch minimal. But a good
> > solution, to me, would be like this:
> >
> > * have the same logic for return codes (1 = error, 0 = success) to ease
> > understanding
> > * have clear
On Mon, 6 May 2024 19:06:10 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Sat, 13 Apr 2024 18:29:59 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf 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 conta
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>> memory/c
On Tue, 16 Apr 2024 07:55:26 GMT, Thomas Stuefe wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue link
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue link
1 - 100 of 222 matches
Mail list logo
