[8u60] RFR: 8078470: [Linux] Replace syscall use in os::fork_and_exec with glibc fork() and execve()
david.holmes at oracle.com
Thu Apr 23 07:50:56 UTC 2015
On 23/04/2015 5:24 PM, Thomas Stüfe wrote:
> Hi David
> - would it be possible to use vfork() instead of fork()? Might increase
> the chance of fork() succeeding in out-of-memory scenarios. The way
> fork/execve is used here is simple enough for vfork().
I'm reluctant to use vfork() as it is an unknown. The use of fork() has
been trialled by Google with no problem.
> - would it be possible to print out errno in case fork fails?
> Regards, Thomas
> On Thu, Apr 23, 2015 at 8:40 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8078470/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8078470
> For historical reasons, dating back to LinuxThreads,
> os::fork_and_exec uses direct syscalls to perform fork and execve
> functions. The fork syscall has been deprecated on linux for quite
> some time and some distributions are now shipping with deprecated
> syscalls removed - this results in a ENOSYS error and the "OnError"
> commands that utilize os::fork_and_exec no longer work.
> The problem was discussed here:
> It seems the concerns surrounding direct use of glibc fork() and
> exec() are no longer legitimate and Martin Buchholz reports that
> Google replaced the syscalls with glibc calls some time ago and have
> not had any problems. So we propose to apply the same change
> uniformly on Linux.
> This is initially going into 8u60 via jdk8u-hs-dev due to time
> constraints on the 8u60 schedule, and an internal limitation
> preventing me from pushing this to 9 right now. But it will be
> "backported" to 9 ASAP.
More information about the hotspot-dev