Re: RFR: 8184692: add Pattern.asMatchPredicate

> On Apr 4, 2018, at 10:47 AM, Vivek Theeyarath > wrote: > > Hi All, > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184692 > > Webrev : http://cr.openjdk.java.net/~vtheeyarath/8184692/webrev.00/ > Like with your other

Re: RFR: 8164781: Pattern.asPredicate specification is incomplete

> On Apr 5, 2018, at 3:34 AM, Vivek Theeyarath > wrote: > >>> >>> Hi, >>> I have incorporated the changes as per the feedback and here is the >>> updated webrev . >>> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>> Bug:

Re: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode

> On Apr 5, 2018, at 12:04 AM, Ivan Gerasimov wrote: > > Hello! > > Yet another HashMap that can be preallocated more accurately. > > Currently, the map is created as the following: >// Initial capacity of # values is sufficient to avoid resizes >

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

On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote: > Would proposing to introduce thread exit hooks be reasonable? Or is > everyone going to freak out? :-) The hooks can be either per-Thread or even > per-ThreadLocal. And it's OK if the hooks can only be used within

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

Hi Tony, On 6/04/2018 7:45 AM, 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 If it's in a ThreadLocal then aren't you just asking for thread-locals to be cleared at

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

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 a thread starts, lives long enough for its

Re: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode

Thanks for review Claes! On 4/5/18 6:03 AM, Claes Redestad wrote: Hi, looks ok, but the cost/benefit ration of adding a standalone regression test for every such inefficiency seems dubious to me. Could we group these together, somewhere? Yes, I agree that this kind of tests should be

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

Looks good, thanks for doing this!. Kumar On 4/4/2018 5:09 PM, Andrey Nazarov wrote: On 22 Mar 2018, at 07:18, Kumar Srinivasan wrote: David, Why would the VM emit these warnings if the deprecated vm flag is not being used ? Andrey, As for the reviews I am

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

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 jimage ("lib/modules") file handle being inherited,

RFR: jsr166 jdk integration 2018-04

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8200728: Docs (Comparison of Stack and Deque methods) for Deque is not correct' src/main/java/util/Deque.java http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/Deque-Stack/index.html

RFR [10] 8194554: filterArguments runs multiple filters in the wrong order

Hi, Please review this jdk10 backport. Original JDK 11 bug: https://bugs.openjdk.java.net/browse/JDK-8194554 Original JDK 11 fix: http://hg.openjdk.java.net/jdk/jdk/rev/050352ed64d5 Please note the discussion in JBS comments about the issue. It seems to include the more verbose

Re: RFR: 8201178: Remove sun.nio.cs.FastCharsetProvider

On 05/04/2018 14:42, Claes Redestad wrote: Hi, since JDK-8073152 sun.nio.cs.FastCharsetProvider is unused and can be removed. Patch: hg rm src/java.base/share/classes/sun/nio/cs/FastCharsetProvider.java Bug: https://bugs.openjdk.java.net/browse/JDK-8201178 I don't see any references to it

RFR: 8201178: Remove sun.nio.cs.FastCharsetProvider

Hi, since JDK-8073152 sun.nio.cs.FastCharsetProvider is unused and can be removed. Patch: hg rm src/java.base/share/classes/sun/nio/cs/FastCharsetProvider.java Bug: https://bugs.openjdk.java.net/browse/JDK-8201178 Thanks! /Claes

Re: RFR: 8164781: Pattern.asPredicate specification is incomplete

Hi Vivek, Can we do something to make the first sentence less confusing? How about: * Creates a predicate that tests a given input string for a subsequence that matches this pattern. -or- * Creates a predicate that tests if this pattern is found in a given input string. Thanks, Roger On

Re: RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode

Hi, looks ok, but the cost/benefit ration of adding a standalone regression test for every such inefficiency seems dubious to me. Could we group these together, somewhere? Bonus startup points if you rewrote so that AccessMode.values() is only called once, since it clones the backing

RE: RFR: 8164781: Pattern.asPredicate specification is incomplete

>> >> Hi, >> I have incorporated the changes as per the feedback and here is the >> updated webrev . >> http://cr.openjdk.java.net/~rraghavan/8164781/webrev.02/ . >>Bug: https://bugs.openjdk.java.net/browse/JDK-8164781 >> >+1 Thanks Paul >I know it’s picky, but would you mind sticking

Re: RFR: Export InitializeEncoding for JVM access

Hi Roger, The OpenJ9 VM implementation provides its own java.lang.System, which performs similar type early-on VM initialization to the OpenJDK core library classes. The basic reason for invoking the method is to initialize the platform encoding either called from a related core library method,

RFR 8200788 : Optimal initial capacity of java.lang.VarHandle.AccessMode.methodNameToAccessMode

Hello! Yet another HashMap that can be preallocated more accurately. Currently, the map is created as the following: // Initial capacity of # values is sufficient to avoid resizes // for the smallest table size (32) methodNameToAccessMode = new

Re: RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory

Hi Martin! Ah bummer! Missing @modules java.base/java.util:open in the test. Sorry about that. Let me fix it with the fix for a similar issue JDK-8200788 that I've just filed. With kind regards, Ivan On 4/4/18 9:24 PM, Martin Buchholz wrote: Hi Ivan, I'm seeing [2018-04-04 20:56:11,999]