fopen vs. os::fopen and automatic closing of the file on exec

[Baesken, Matthias]

Hi  Leo / Thomas / David,
 Not sure if it is a small  or “medium” gain ,  but after the discussion so far I think it makes sense to use  os::fopen in HS code  where possible
 (  what (f)open does in the  jdk C coding is a different thing, we might dicuss this on corelibs-dev  in more detail ).

I opened
https://bugs.openjdk.java.net/browse/JDK-8238161

use os::fopen in HS code where possible


Best regards, Matthias




Hi Leo,

On Tue, Jan 28, 2020 at 4:37 PM Leo Korinth <leo.korinth at oracle.com<mailto:leo.korinth at oracle.com>> wrote:
...

Something that is not obvious is that on unix-like operating systems,
ProcessImpl_md.c tries to close (most) open files between fork and exec.
That is not the case for Windows (I opened
https://bugs.openjdk.java.net/browse/JDK-8202720 for this). Thus (if I
understand correctly) the impact on unix-like operating systems will be
less for adding this support than it is for Windows. os::fopen was
created to solve a specific bug on windows (logging), and was renamed to
the more generic os::fopen during review.

Just a note, it is still possible for file descriptors to escape into child processes since you cannot guarantee that all forks happen via Runtime.exec():
- native third party code may fork.
- hotspot may fork to run tools for error reporting

Also note that the code which closes fds in Runtime.exec() may in theory fail to close all fds.

So I think Matthias makes sense on Posix platforms.

I guess most uses of ::fopen /should/ use the more restricted os::fopen,
but the gain would probably be small.

Thanks,
Leo