Re: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup

Reviewed; it's good. The javadoc text doesn't need to predict the future; it just needs to document the present specification. So the sentence that begins "This constraint allows for the future possibility…" is not really necessary. It's certainly not normative. — John On Apr 6, 2018, at 5:15

RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup

Hi, Please review this patch to constrain constant dynamic bootstrap methods to methods whose first parameter type is MethodHandles.Lookup. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/

RFR: 8178867: tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java failed to clean up files

Hi, Please review fix in Jlink test. The fix is to close the Stream which works with a file system. Review: http://cr.openjdk.java.net/~anazarov/JDK-8178867/webrev.01 JBS: https://bugs.openjdk.java.net/browse/JDK-8178867 —Thanks, And

Use iterator() in AbstractList.equals() instead of listIterator()

iterator() has chances to be slightly more efficient than listIterator(). At very least AbstractList's own ListItr implementation contains one more implicit field referencing the base class, so objects of AbstractList.ListItr are often 8 bytes bigger than objects of AbstractList.Itr.

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

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 fork+exec). File descriptor 3 is indeed deep magic, u

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

> The update to osSupport_Windows.cpp looks okay. I think it would be > useful to discuss the osSupport_unix.cpp change further as the > childproc code is supported to close the file descriptors. childproc code uses some dark magic to figure which files to close. At the moment, closeDescriptors(

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

On 02/04/2018 22:50, Alexander Miloslavskiy 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 can also replace embedded JRE. However, due to jim

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

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? Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.co

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

— Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote: >> ThreadLocal clearing > > Could you clarify what you mean by ThreadLocal clearing? I mean calling

Re: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java

Thanks Lance, Paul, I will refactor the code, update in place: http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ And I am retesting. Thanks, Roger On 4/6/2018 12:15 PM, Paul Sandoz wrote: On Apr 6, 2018, at 6:50 AM, Roger Riggs wrote: Please review an intermittent test bug

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

On 06/04/2018 15:08, Tony Printezis wrote: Hi Alan, Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is why I proposed some type of exit hook (maybe I overthought this?). But that’d be OK, could make this change a lot simpler. :-) And, yes, I came across the issue of no

Re: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java

Hi Roger, I think what you have is OK. Best Lance > On Apr 6, 2018, at 9:50 AM, Roger Riggs wrote: > > Please review an intermittent test bug/cleanup improvement that places > temporary > files in the directory that is auto-cleaned by jtreg. > > Webrev: > http://cr.openjdk.java.net/~rrigg

Re: RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java

> On Apr 6, 2018, at 6:50 AM, Roger Riggs wrote: > > Please review an intermittent test bug/cleanup improvement that places > temporary > files in the directory that is auto-cleaned by jtreg. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ > Looks ok, while y

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

On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote: >> ThreadLocal clearing > > Could you clarify what you mean by ThreadLocal clearing? I mean calling ThreadLocal#remove(). > I like the suggestion to add an overridable exit() method to ThreadLocal. If > you want to avoid calling user code by

Re: RFR: Export InitializeEncoding for JVM access

Hi Andrew, Would it be sufficient to export the InitializeEncoding entry point? Introducing a JNU_xx name may imply a level of support that is unwarranted since it is part of system initialization and may change as needed by the implementation. Simply exporting it would put it on par with Can

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

Was there a reason why this was not introduced in the first place? Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 6, 2018 at 8:49:17 AM, Peter Levart (peter.lev...@gmail.com) wrote: On 04/06/2018 10:02 AM, Alan Bateman wrote: > On 05/04/2018 22:45, Tony Printez

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

Hi Alan, Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is why I proposed some type of exit hook (maybe I overthought this?). But that’d be OK, could make this change a lot simpler. :-) And, yes, I came across the issue of not being able to query whether a ThreadLocal exis

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

Hi David, Thanks for your thoughts. Please see inline. — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On April 5, 2018 at 6:24:11 PM, David Lloyd (david.ll...@redhat.com) wrote: On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote: > Would proposing to introduce thread exit h

RFR 8200706: Better cleanup for open/test/jdk/java/lang/ProcessBuilder/DestroyTest.java

Please review an intermittent test bug/cleanup improvement that places temporary files in the directory that is auto-cleaned by jtreg. Webrev:  http://cr.openjdk.java.net/~rriggs/webrev-clean-destroy-8200706/ Thanks, Roger

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

Hi David, ThreadLocals getting cleared is not enough. The threadLocals field is cleared by Thread::exit: private void exit() { ... threadLocals = null; ... } but this doesn’t really do anything. The GC has to run, find the direct buffer in the ThreadLocal unreacha

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

On 04/06/2018 10:02 AM, Alan Bateman wrote: On 05/04/2018 22:45, Tony Printezis wrote: Hi all, 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 intervals. I assume this is due to a threa

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

On 05/04/2018 22:45, Tony Printezis wrote: Hi all, 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 intervals. I assume this is due to a thread pool dynamically resizing itself. Let's say