<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, May 15, 2025 at 8:00 PM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 15/05/2025 17:52, Thomas Stüfe wrote:<br>
> :<br>
><br>
> However,  we also could just get rid of vfork. That would simplify <br>
> things alot. We have moved to posix_spawn-by-default with JDK 13 in <br>
> 2019 (<a href="https://bugs.openjdk.org/browse/JDK-8213192" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8213192</a>). That is a long <br>
> time ago; probably long enough to ween all customers off vfork use.<br>
><br>
> What do people think?<br>
><br>
<br>
I haven't see any complaints or JBS issues since the change in JDK 13.  <br>
It's possible that there deployments running with <br>
jdk.lang.Process.launchMechanism set to vfork but my guess is that this <br>
configuration knob isn't widely known. If there are deployments doing <br>
this then there must be some reason, and I think we would have heard <br>
about it via a JBS issue by now.<br>
<br>
I checked the JDK release notes.  The property was documented in the JDK <br>
12 release notes. The release note in JDK 13 about the move to <br>
posix_spawn didn't name the property to go back to vfork.<br>
<br>
So my initial reaction is that removing vfork would not be disruptive.<br>
<br>
-Alan<br>
<br>
<br></blockquote><div><br></div><div>Thank you, Alan. I will prepare a patch and a CSR.</div><div><br></div><div>/Thomas</div><div> </div></div></div>