Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Alan Bateman
Alan.Bateman at oracle.com
Sun Jul 28 21:18:17 UTC 2013
On 25/07/2013 09:17, Rob McKenna wrote:
> Thanks a lot Erik,
>
> I've added the dependency to the makefile here:
>
> http://cr.openjdk.java.net/~robm/5049299/webrev.05/
> <http://cr.openjdk.java.net/%7Erobm/5049299/webrev.05/>
>
> Is it ok between the ifeq block?
>
> Alan,
>
> I've altered the launchMechanism code to use valueOf (and lower case
> names) - much cleaner, thanks for that. I've also limited each
> platform to supported mechanisms only. With the new layout I don't
> believe a separate test is needed here. (the default is now
> posix_spawn/vfork and Basic.java has been altered to run with fork too)
>
> -Rob
Thanks Rob, I've taken another pass over the latest webrev and I think
the finish line is close.
The launchMechanism determination is much cleaner now (thanks). For
consistency the enum values should probably be in uppercase and so this
means you'll need to uppercase the property value to use valueOf.
It would be nice if launchMechanism were final too (which you do by
having the privileged action be of type LaunchMechanism rather than Void).
The comment in UNIXProcess.java.bsd references vfork/exec which I assume
is copied from the Linux version and should be removed.
Did you consider having forkAndExec take the helper as a parameter? Just
wonder if this would be cleaner than having to use JNI to grab the field
value.
It's usually best to use sprintnf rather than sprintf (in spawnChild) to
avoid any concerns (or static analysis tools) that wonder about buffer
overflow.
Style nit in the C code is that many places have spurious space between
the function name and the parentheses.
A pre-existing bug (only noticed because it has moved from
UNIXProcess_md.c to childproc.c) is that close is not restartable.
The comment in in makefiles/CompileLauncher.gmk references the old
build, is that needed?
So overall I don't see any issues, it would be really good to stress
this to make sure that we aren't leaking file descriptors. I don't know
if we have an existing test that would help with that.
One final comment is that the new files seems to have the pure GPL
comment, I assume you will add the GPL+ Classpath Exception comment
before you push this.
-Alan.
More information about the core-libs-dev
mailing list