break
that one too, so I decided to not remove the liveness check.
On Wed, Jul 16, 2025 at 7:26 AM Thomas Stüfe
wrote:
> Thanks, Roger, I will proceed with removing the old workaround then.
>
> On Tue, Jul 15, 2025 at 5:05 PM Roger Riggs
> wrote:
>
>> Hi Thomas,
>>
&
s no confusion about matching expectations.
> I agree that removing it is preferred.
>
> Roger
>
>
> On 7/15/25 10:44 AM, Thomas Stüfe wrote:
> > Hi,
> >
> > I am currently working on removing (eventually) the vfork mode. Before
> > we can do this, we need a bit b
Hi,
I am currently working on removing (eventually) the vfork mode. Before we
can do this, we need a bit better error diagnostics. I do this by gently
improving the error handling throughout the code, so that we can generate
IOExceptions based on more exact knowledge.
While working at this, I re-
17, 2025 at 8:41 AM Thomas Stüfe
wrote:
> Side note, I did not find any tests for the VFORK mode. Even the FORK mode
> seems not that well covered ( we only seem to run
> java/lang/ProcessBuilder/Basic.java in FORK mode)
>
> On Fri, May 16, 2025 at 6:59 PM Thomas Stüfe
> wro
Side note, I did not find any tests for the VFORK mode. Even the FORK mode
seems not that well covered ( we only seem to run
java/lang/ProcessBuilder/Basic.java in FORK mode)
On Fri, May 16, 2025 at 6:59 PM Thomas Stüfe
wrote:
> I am fine with waiting past 25, though the continued existence
continued acceptance, of the VFORK mode)
On Fri, May 16, 2025 at 6:20 PM Joseph D. Darcy
wrote:
> I concur that this work is better down early in JDK 26.
>
> Thanks,
>
> -Joe
>
> On 5/16/2025 12:26 AM, Thomas Stüfe wrote:
>
> Okay, moved the release version to 26.
>
>
Okay, moved the release version to 26.
Could one of you (you or @Roger Riggs ) review the
CSR if you have the cycles to spare?
https://bugs.openjdk.org/browse/JDK-8357090
Thanks!
On Fri, May 16, 2025 at 7:56 AM Alan Bateman
wrote:
> On 16/05/2025 05:10, Thomas Stüfe wrote:
>
>
>
On Thu, May 15, 2025 at 8:00 PM Alan Bateman
wrote:
>
>
> On 15/05/2025 17:52, Thomas Stüfe wrote:
> > :
> >
> > However, we also could just get rid of vfork. That would simplify
> > things alot. We have moved to posix_spawn-by-default with JDK 13 in
> >
Hi,
I am currently working on child process issues and again noticed how
inherently dangerous the vfork mode is.
The child process can damage or kill the parent process if bad things
happen in the time window between vfork and exec, when we prepare the
target binary execution. For a non-exclusive
Hi David,
On Fri, May 9, 2025 at 8:44 AM David Holmes wrote:
> Hi Thomas,
>
> On 29/04/2025 7:04 pm, Thomas Stüfe wrote:
> > Hi,
> >
> > I would like to gauge opinions on whether the following scenario is a
> > bug to fix or whether to accept it as standar
libjvm.so gets embedded into a custom launcher, which
already had set SIG_IGN for SIGPIPE, the JVM will replace that handler with
its own, resulting in child processes running with SIG_DFL.
This seems a bit arbitrary to me and seems to support the view that this
behavior is not intended.
> -
Hi,
I would like to gauge opinions on whether the following scenario is a bug
to fix or whether to accept it as standard behavior.
---
A customer has the following problem:
- The JVM invokes a third-party JNI library that sets the signal
disposition of SIGPIPE to SIG_IGN (Boo! in this case, it
Hi Archie,
Note that we have a script for that; see
make/scripts/update_copyright_year.sh . I use it a lot. Sonia recently
enhanced it. It even has an option to update copyrights for foreign
companies.
Calling it from the source root usually works well, it only still struggles
with large merge co
here:
> https://github.com/openjdk/jdk/blob/959a61fdd483c9523764b9ba0972f59ca06db0ee/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L139
>
> -DJ
>
> On 6/17/2023 16:43, Thomas Stüfe wrote:
>
> Mind testing https://github.com/openjdk/jdk/pull/14531 ?
>
> On Sat, Jun 17, 2023 at 8:20 PM Th
Mind testing https://github.com/openjdk/jdk/pull/14531 ?
On Sat, Jun 17, 2023 at 8:20 PM Thomas Stüfe
wrote:
> Hi Daniel,
>
> thank you for that thorough analysis. I opened
> https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.
>
> Looking at the code, this should
Hi Daniel,
thank you for that thorough analysis. I opened
https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.
Looking at the code, this should be easy to fix, we would not even have to
fix jspawnhelper itself, just its spawn point.
I did a small patch which seemed to work. But this
I always meant to ask, why is it that we chose to dedicate the beginning of
> the memory chunk to NMT, and not the end?
>
> If we used the end, then in this case with an unbalanced malloc/free, we
> would still be OK.
>
> The end seems more natural to me and either way we need to track the size,
>
ink that is realistic anymore. I am
> > fine with postponing my work in favor of a baseline discussion, but so
> > far there is very little discussion about this topic.
> >
> > How should I proceed?
> >
> > Thanks, Thomas
> >
> >
> >
> > O
re. I am fine with postponing my work in favor of a baseline
discussion, but so far there is very little discussion about this topic.
How should I proceed?
Thanks, Thomas
On Wed, Nov 9, 2022 at 8:12 AM Thomas Stüfe wrote:
> Hi Alan,
>
> (replaced hotspot-runtime-dev with hotspot-dev,
Hi Carter, Stefan,
thank you, I think it is good to have this discussion, it is important.
Side note, the discussion steered away from my original question - whether
to instrument the JDK with NMT. I still would love to discuss that, too.
About opening NMT up for user consumption, that is of cou
ov 6, 2022 at 9:31 AM Alan Bateman wrote:
> On 04/11/2022 16:54, Thomas Stüfe wrote:
> > Hi all,
> >
> > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360;
> > I was preparing the final PR [1], but then Alan did ask me to discuss
> > this on core-l
Hi all,
I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; I
was preparing the final PR [1], but then Alan did ask me to discuss this on
core-libs first.
Backstory:
NMT tracks hotspot native allocations but does not cover the JDK libraries
(small exception: Unsafe.AllocateMem
>
>
> > >
> > > I see your point. I dislike crashes, especially ones they can be
> > > reliably triggered from outside. You never can be sure about the
> > > security implications either.
> > >
> > > If you dislike ignoring the signal, and since the default action for
> > > SIGUSR1+2 is process ter
23 matches
Mail list logo
