RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8076458, java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout. webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.00/ Thank you -Hamlin

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

I've finally found some time to return to this and have a new version of the patch which looks more promising: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ This uses memcpy to read/write the native data and the preliminary benchmark numbers on linux/x64 shows the

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 24/01/2016 17:10, Peter Levart wrote: Hi, I had an idea recently on how to expedite the collection of an object. It is simple - just don't let it live long. Here's a concept prototype: http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java The overhead of the

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

The changes look fine to me also Chris. Regards, Sean. On 22/01/16 14:49, Chris Hegarty wrote: On 21/01/16 22:55, Felix Yang wrote: Hi Chris, your fix is cool. I will assign the bug to you:) a comment on this fix. The test changed system SecurityManager and it is not executed with

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 01/25/2016 02:31 PM, Alan Bateman wrote: On 24/01/2016 17:10, Peter Levart wrote: Hi, I had an idea recently on how to expedite the collection of an object. It is simple - just don't let it live long. Here's a concept prototype:

Re: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as

Ping again - would somebody find some time to review those, please? Thanks M. On 11/01/16 12:14, Miroslav Kos wrote: Ping ... anybody? On 22/12/15 14:44, Miroslav Kos wrote: Hi everybody, I'd like to ask for reviewing following patch. It fixes two issues: JBS:

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 15:47, Alan Bateman wrote: On 25/01/2016 15:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different home-grown versions of command line option-parsing code. Where possible, new and existing tools in the JDK should

Re: ClassFileTransformer does not apply to anonymous classes

Hi Vladmir, hello Remi, what bothers me about instrumenting a lambda expression's target method is the difficulty of locating the method that contains the code and setting it into context. This is a lot of work to do since one needs to first locate any invokedynamic call sites and interpret the

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

I assume your goal here is to get the resources released with the next newgen collections (following a close()), rather than wait for an oldgen (if the resource was held by an old object). That's a cool thing. With that in mind, you can replace the repeated periodic polling/flipping/allocation

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 15:39, Claes Redestad wrote: +1 Thanks for looking at this Claes. module-info.java missing? No. There is an update to modules.xml. This is all that is required in jdk9/dev, for now. "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

Hi Chris, Are there any tests that can be included? Roger On 1/25/2016 10:39 AM, Claes Redestad wrote: +1 module-info.java missing? "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be a better name for the module? /Claes On 2016-01-25 16:38,

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

Hi Chris, On 1/25/2016 10:45 AM, Chris Hegarty wrote: On 25/01/16 15:39, Claes Redestad wrote: "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be a better name for the module? For consistency, I took the same terse approach applied to the

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 15:45, Roger Riggs wrote: Hi Chris, Are there any tests that can be included? No, I am not planning to add specific tests for JOpt Simple. The tools that eventually use it, should provide sufficient testing. -Chris. Roger On 1/25/2016 10:39 AM, Claes Redestad wrote: +1

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 22/01/2016 23:10, Steve Drach wrote: Hi Alan, et. al., I’ve released a new webrev that addresses all the issues you raised. http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html Specifically: For Release

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/2016 15:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different home-grown versions of command line option-parsing code. Where possible, new and existing tools in the JDK should consider using JOpt Simple. JOpt Simple

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/2016 15:45, Chris Hegarty wrote: : "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be a better name for the module? For consistency, I took the same terse approach applied to the jdk.internal.le module. Right, and the module name is

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/2016 16:09, Chris Hegarty wrote: Bringing this into jdk9/dev in the advance looks good. One thing, should we add a README so that we know exactly which version of JOpt Simple this is? Good idea Alan. Added and webrev updated in-place. Thanks, that should make it easy to identify.

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8141452/webrev.00/ -- Thanks and Regards, Nadeesh TV On 1/25/2016 9:01 PM, Stephen Colebourne wrote: Typo "TimeUnitequivalent" Otherwise looks good. thanks Stephen On 25 January 2016 at 15:25, nadeesh tv

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi Stephen, Nadeesh, TimeUnit.toChronoUnit is a static method. It seems redundant to have to pass an instance to a static method of its type. cu = TimeUnit.toChronoUnit(TimeUnit.SECONDS); Instead of: TimeUnit tu = TimeUnit.SECONDS; ChronoUnit cu = tu.toChronoUnit(); Minor

RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi all, Please review a fix for conversion between Chronounit and Timeunit Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452 webrev: http://cr.openjdk.java.net/~ntv/8141452/webrev.00/ -- Thanks and Regards, Nadeesh TV

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

+1 module-info.java missing? "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be a better name for the module? /Claes On 2016-01-25 16:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK has several

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

On 25/01/2016 15:27, Peter Levart wrote: But let me ask something. Doesn't GC processing require (at least in some phases) that user threads be stopped in a safepoint? What happens when a user thread is blocked by kernel on memory access? Such thread can't be stopped in a safepoint.

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Typo "TimeUnitequivalent" Otherwise looks good. thanks Stephen On 25 January 2016 at 15:25, nadeesh tv wrote: > Hi all, > > Please review a fix for conversion between Chronounit and Timeunit > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452 > > webrev:

RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different home-grown versions of command line option-parsing code. Where possible, new and existing tools in the JDK should consider using JOpt Simple. JOpt Simple is being used in a number of tools in project

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 16:16, Alan Bateman wrote: On 25/01/2016 16:09, Chris Hegarty wrote: Bringing this into jdk9/dev in the advance looks good. One thing, should we add a README so that we know exactly which version of JOpt Simple this is? Good idea Alan. Added and webrev updated in-place.

Re: RFR:8146218: Producing streams in java.time?

The proposed change looks fine with me. sherman On 1/23/16 1:40 PM, Roger Riggs wrote: Hi, Looks good. I would want to verify that it is defined such that if it later needs to be abstracted up to ChronoLocalDate and apply to compatible Chronologies and respective local dates such as

Re: Stream.limit parallel ordered performance

2016-01-24 12:36 GMT+01:00 Tagir F. Valeev : > Hello! > > I'm investigating Stream.limit() performance for parallel ordered > streams when no SUBSIZED optimization is performed. > > Consider the following code, for example: > > AtomicInteger counter = new AtomicInteger(); >

Re: API review of VarHandles

Hi Doug, I somehow missed your reply and just now noticed it after Martin's last email quoted it -- thanks for elaborating. The new name is required because opaque is only "like" C++ > memory_order_relaxed. > See the jmm-dev list discussions last year for details, but annoyingly, > Java normal

Re: API review of VarHandles

On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea wrote: > On 01/22/2016 04:51 AM, Andrew Haley wrote: >> >> On 22/01/16 00:01, Vitaly Davidovich wrote: >>> >>> I think the get/setOpaque methods need a bit more explanation ("opaque" >>> is >>> an odd naming choice, IMO).

Re: API review of VarHandles

This is my first attempt to understand java.lang.invoke. It seems like a new alien world, non-java-like. I'll need to rebuild my internal performance model of java code, perhaps by staring at jit compiled code. I expect new APIs for atomic variable access to appear in j.u.c.atomic, not

Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Hi, as I was using the xslt EnvironmentCheck class in my private testcase and recognizing it didn't exist anymore in JDK 9, I stumbled over this thread from last July below. I understand that you want to clean up and remove unnecessary code but I found the class quite useful as it would some

Re: Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Hi Christoph, What did you use from the class? As in the discussion, many of the information are either inaccurate or irrelevant in the JDK (vs as a standalone impl). Thanks, Joe On 1/25/2016 3:49 PM, Langer, Christoph wrote: Hi, as I was using the xslt EnvironmentCheck class in my

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

I already regret touching crufty old Vector, but it had the same bug to fix, and more surprisingly the same sort of performance improvement from doing the obvious port. So ... Stuart, please review also http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/

Re: OpenJDK8: java.util.stream.Stream.onClose

> On 23 Jan 2016, at 10:50, Timo Kinnunen wrote: > > Hi, > > The pipeline stages don’t really need to mutate themselves (as they can > mutate the Stream if needed). So they should be shareable between Streams, > alleviating some of cost of creating new copies of a