Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On Fri, Apr 6, 2018 at 1:02 AM, Alan Bateman wrote: > On 05/04/2018 22:45, Tony Printezis wrote: > >> >> We recently hit another interesting issue with the NIO thread-local >> DirectByteBuffer cache. One of our services seems to create and drop >> threads at regular

Re: 8194734 : Handle to jimage file inherited into child processes (win)

> I'm hoping that JDK core libraries overall do a better job of reusing > the code in e.g. > src/hotspot/os/linux/os_linux:os::open > somehow, that actually gets the CLOEXEC bit right. os::open is exactly what was used in libjimage before the bug was introduced. I already described it in my

Re: 8194734 : Handle to jimage file inherited into child processes (win)

I'm hoping that JDK core libraries overall do a better job of reusing the code in e.g. src/hotspot/os/linux/os_linux:os::open somehow, that actually gets the CLOEXEC bit right. On Sun, Apr 8, 2018 at 11:56 AM, Alexander Miloslavskiy < alexandr.miloslavs...@gmail.com> wrote: > I'm still only half

Re: 8194734 : Handle to jimage file inherited into child processes (win)

I'm still only half paying attention, but I agree with Alexander that the low-level infrastructure in libjimage is fishy.  The rule should be that file descriptors created by the JDK should have the CLOEXEC bit on. But even if the CLOEXEC bit was forgotten, the subprocess code should still

Re: 8194734 : Handle to jimage file inherited into child processes (win)

On Mon, Apr 2, 2018 at 2:50 PM, Alexander Miloslavskiy < alexandr.miloslavs...@gmail.com> wrote: > The problem in this bug is that jimage file is mistakenly opened with > "inherit by child processes" flag. In our case, the child process is > started with Runtime.exec() and serves as updater that

Re: 8194734 : Handle to jimage file inherited into child processes (win)

> The only surprise is that it doesn't close as it shouldn't need the > file descriptor after it mmapped. Indeed, both on Windows and Unix file descriptor can be closed after mapping. On the other hand, ImageFileReader is not prepared for that. See

Re: 8194734 : Handle to jimage file inherited into child processes (win)

> STDERR_FILENO is 2 so I'm curious which error reporting pipe is bring > discussed here. We're discussing line 365 of childproc.c http://hg.openjdk.java.net/jdk/jdk/file/8bdf2b5f472d/src/java.base/unix/native/libjava/childproc.c

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

On 06/04/2018 18:17, Tony Printezis wrote: Hi Alan, Ah, I hadn’t realized that there’s already some tight coupling between Thread and nio. OK, I’ll just call into sun.nio directly and see what the reviewers say. :-) Is there a CR for this already? Or should I create one? I think it should

Re: 8194734 : Handle to jimage file inherited into child processes (win)

On 06/04/2018 22:01, Martin Buchholz wrote: History: The design on Unix was that all file descriptors greater than 3 are closed on fork and before exec. But regardless of that, we should try to set the CLOEXEC bit on all our file descriptor (who knows, there might be native code that does

Re: RFR of JDK-8188897: java/rmi/registry/reexport/Reexport.java failed with Port already in use

Hi Roger, I have changed to not use RegistryVM at all, please review the patch: http://cr.openjdk.java.net/~mli/8188897/webrev.02/ Thank you -Hamlin On 04/04/2018 10:15 PM, Roger Riggs wrote: Hi Hamlin, Reexport.java: I think this change to use a separate process for the 2nd registry