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
On Fri, 12 Apr 2024 10:07:48 GMT, Claes Redestad wrote:
> I guess Lilliput adds some hard or soft limit on the number of classes loaded?
Yes, we are concerned with that, especially for a possible future where
Lilliput is the sole default. Atm we can address about 4 million classes. There
are t
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-noth
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> There are a few trade-offs at play here which influence the choice of
> threshold. The simple high arity strategy will for example not see any reuse
> of LambdaForms but strictly always generate a class per indy callsite, which
> means w
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote:
> DeCapo Benchmark Results (3 runs) :
>
> Before :
> = DaCapo 9.12 h2 PASSED in 281402 msec =
> = DaCapo 9.12 h2 PASSED in 269818 msec =
> = DaCapo 9.12 h2 PASSED in 279279 msec =
>
> After:
> = DaCapo 9.12 h2 PAS
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
Seems reasonable.
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17156#
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote:
> Tests using ProcessTools.executeProcess gets the following output written to
> stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
On Fri, 24 Nov 2023 09:51:07 GMT, Daniel Jeliński wrote:
>> test/failure_handler/src/share/conf/windows.properties line 60:
>>
>>> 58:
>>> 59: native.core.app=cdb
>>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p
>>
>> Just to double check that this is the right option. `/ma` terminates
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote:
> The recent cdb versions do not support `.dump /f`:
>
> *
> * .dump /f is not supported on a user mode process. *
> *
On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote:
> Following test fails due to missing pthread attributes on AIX :
> java/foreign/TestUpcallAsync.java
> java/foreign/stackwalk/TestAsyncStackWalk.java
> java/foreign/loaderLookup/TestLoaderLookupJNI.java
> java/foreign/enablenativeaccess/TestEnabl
On Fri, 13 Oct 2023 03:23:04 GMT, xpbob wrote:
> Big data processes often experience situations where the direct memory oom
> process is alive but not serving properly. If the direct memory is oom, code
> can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java.
On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system
>> lead to double pids in the child list; at least intermitt
On Thu, 12 Oct 2023 09:33:24 GMT, Joachim Kern wrote:
>> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 89:
>>
>>> 87:
>>> 88: do { // Block to break out of on Exception
>>> 89: pids = (*env)->GetLongArrayElements(env, jarray, NULL);
>>
>> Nit, I'd move these invocat
On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system
>> lead to double pids in the child list; at least intermitt
On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system
>> lead to double pids in the child list; at least intermitt
On Mon, 9 Oct 2023 15:15:52 GMT, Joachim Kern wrote:
> Previously the implementation based on the /proc file system lead to double
> pids in the child list; at least intermittent. Using the API getprocs64()
> instead I was able to eliminate those double pids (and increase the
> performance by
On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern wrote:
>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX
>> in TreeTest.test5.
>>
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [2] but found [3]
>> at org.test
On Tue, 29 Aug 2023 12:10:34 GMT, Matthias Baesken wrote:
>> We have some failures in TreeTest.java where the expected number of child
>> processes is differing from what we really get. It would be good to have
>> more output to analyze these cases.
>
> Matthias Baesken has updated the pull req
On Tue, 29 Aug 2023 07:51:59 GMT, Matthias Baesken wrote:
> We have some failures in TreeTest.java where the expected number of child
> processes is differing from what we really get. It would be good to have more
> output to analyze these cases.
Looks good. Small nit inline.
test/jdk/java/la
On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf wrote:
> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part
> of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use
> the
> JDK's version of `Metrics` in GraalVM. See the bug for details
On Fri, 7 Jul 2023 13:27:47 GMT, Roger Riggs wrote:
>> Hi all,
>>
>> Clean backport for JDK-83210265.
>>
>> Thanks!
>
> Marked as reviewed by rriggs (Reviewer).
Thank you @RogerRiggs !
-
PR Comment: https://git.openjdk.org/jdk21/pull/103#issuecomment-1625435021
On Thu, 6 Jul 2023 19:42:08 GMT, Thomas Stuefe wrote:
> Hi all,
>
> Clean backport for JDK-83210265.
>
> Thanks!
This pull request has now been integrated.
Changeset: 6ef80168
Author: Thomas Stuefe
URL:
https://git.openjdk.org/jdk21/commit/6ef801683844e5cc06804d510
Hi all,
Clean backport for JDK-83210265.
Thanks!
-
Commit messages:
- Backport 47d00a4cbeff5d757dda9c660dfd2385c02a57d7
Changes: https://git.openjdk.org/jdk21/pull/103/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=103&range=00
Issue: https://bugs.openjdk.org/browse/J
On Wed, 21 Jun 2023 07:55:31 GMT, David Holmes wrote:
>> I'm not aware of any other uses either; its not intended to be used outside
>> of ProcessImpl especially since the addition of the new protocol to
>> communicate parameters and confirm launching of the child.
>
> This curiosity has been p
On Tue, 20 Jun 2023 18:36:40 GMT, Volker Simonis wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback Volker and Roger
>
> Still good :)
Thanks @simonis and @RogerRiggs !
--
On Sat, 17 Jun 2023 18:24:54 GMT, Thomas Stuefe wrote:
> Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1]
>
> jspawnhelper uses argv[0] to receive the fd string from the parent. That
> breaks with conventions and trips over certain tools like binfmt_misc.
>
n.
>
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
feedback Volker and Roger
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14531/files
- new:
On Tue, 20 Jun 2023 15:00:29 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> correct comment
>
> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 13
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe wrote:
>> Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1]
>>
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That
>> breaks with conventions and trips over certain tools like
On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe wrote:
>> Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1]
>>
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That
>> breaks with conventions and trips over certain tools like
n.
>
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
correct comment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14531/files
- new: https://
Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1]
jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks
with conventions and trips over certain tools like binfmt_misc.
For details, see linked ML discussion.
[1] https://mail.openjdk.org/pipermail/core
On Tue, 30 May 2023 13:19:37 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Sat, 27 May 2023 11:25:41 GMT, Thomas Stuefe wrote:
>> This one is not just to get rid of a warning. We get real test errors
>> because malloc gets replaced by vec_malloc in log tags.
>
>> This one is not just to get rid of a warning. We get real test errors
>> b
On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote:
> This one is not just to get rid of a warning. We get real test errors because
> malloc gets replaced by vec_malloc in log tags.
That does not invalidate my argument, nor does it answer my question. Those
test errors could be also fixed by
On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Wed, 24 May 2023 14:30:10 GMT, Volker Simonis wrote:
>>> > Sorry, but I don't understand this argument. If we do a short read we
>>> > will work with corrupted ChildStuff and SpawnInfo
>>> > structures. This can in the extreme case execute arbitrary code (e.g. if
>>> > ChildStuff.argv is not
On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe wrote:
> Trivial fix for a small problem.
>
> jspawnhelper gets handed several file descriptors as arguments. The buffer
> size for this string is too small (7 chars per fd) to print out every
> conceivable int. This will overun t
On Thu, 18 May 2023 13:46:54 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
still
> printable within the limits of this buffer. It is possible to get more fds
> per process, but only via kernel patch. But we still should not rely on that.
> And there is also still MacOS using the same mechanism.
Thomas Stuefe has updated the pull request with a new targe
On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe wrote:
> Trivial fix for a small problem.
>
> jspawnhelper gets handed several file descriptors as arguments. The buffer
> size for this string is too small (7 chars per fd) to print out every
> conceivable int. This will overun t
On Wed, 17 May 2023 16:12:15 GMT, Volker Simonis wrote:
>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
>>
>>> 488: pid_t resultPid;
>>> 489: int i, offset, rval, bufsize, magic;
>>> 490: char *buf, buf1[24];
>>
>> Since you are here could you please increase buffer
On Wed, 17 May 2023 16:00:23 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
Trivial fix for a small problem.
jspawnhelper gets handed several file descriptors as arguments. The buffer size
for this string is too small (7 chars per fd) to print out every conceivable
int. This will overun the buffer if we happen to have fds larger than (printed
size) 7 characters. This c
On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar wrote:
> s390x needs to be recognised as `S390`. After
> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was
> getting this PluginException:
>
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
>
1 - 100 of 174 matches
Mail list logo
