6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux

Thomas Stüfe thomas.stuefe at gmail.com
Mon Oct 22 20:14:12 UTC 2018

Hi David,

On Mon, Oct 22, 2018 at 9:00 PM David Lloyd <david.lloyd at redhat.com> wrote:
> On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> > Hi all,
> [...]
> > So far I have not read a single technical reason in this thread why
> > vfork needs to be abandoned now
> Note that my patch does not abandon vfork.  It does not even change
> the default exec strategy away from vfork, nor does it cause any
> obstacle to your proposed change.  It only adds the ability for users
> to opt in to the existing posix_spawn implementation on Linux.  It's
> just a first step, in whatever direction we might be going, which is
> far from decided.  As you and Martin have both implied, it's a good
> idea to be very cautious in this area.
> > The current posix_spawn() implementation was added to glibc with glibc 2.24. So, what was the state of posix_spawn() before that version? Is it safe to use, does it do the right thing, or will we encounter regressions?
> I certainly have not suggested making posix_spawn be the default on
> Linux at this time.  But if we don't make it at least a possible
> option, it cannot be tested *at all*, by anyone, unless they're
> adventurous enough to hack OpenJDK themselves.  The questions you ask
> can not be answered without at least making it a choice.
> There are many reasonable paths that can be taken after this patch is
> merged (if it is):
> • It could stop here and keep the status quo; users who have trouble
> with the current implementation can try out posix_spawn
> • The Linux port could be modified similarly to your proposal to use
> the existing jspawnhelper infrastructure with vfork on Linux, while
> still allowing posix_spawn to be manually selected
> • The Linux port could be modified to use posix_spawn if
> gnu_get_libc_version(3) and/or other run-time probes return an
> acceptable value, using vfork (either the original or your modified
> approach) otherwise, still allowing posix_spawn to be manually
> selected
> Other possibilities exist as well.  Nothing in this email thread
> (AFAICT) invalidates your basic proposal, other than perhaps the
> observation that your proposal has similarities to the existing
> jspawnhelper path, so that could possibly be utilized.  This patch
> only *increases* our possible future choices; it does not impose any
> restrictions.

I understand. Sorry for being stubborn. I have spent so much time
debugging Runtime.exec() problems in the past that I am very paranoid
about changes. Bugs in the Runtime.exec() layer tend to be so very
hard to analyze.

That said, as I wrote in my earlier mail, I think using posix_spawn()
may be fine. If I understand the glibc coding correctly, we are good
down to glibc 2.4, which is quite old. This will also save me a lot of
work, since upstreaming our patch would have been a real pain. It is
tightly interwoven with other proprietary components and would have
effectively been a rewrite.

So I think yes, your patch is fine. Lets get it in and test it.

Best Regards, Thomas

> --
> - DML

More information about the core-libs-dev mailing list