Re: RFR: JDK-8074579 Use more efficient and readable way of checking PKZIP signatures

Err... #define PKZIP_SIGNATURE_AT(p, b2, b3) \ (((p)[0] == 'P') & ((p)[1] == 'K') & ((p)[2] == b2) & ((p)[3] == b3))

RE: [concurrency-interest] Why not "weakNanoTime" for jdk9?

The VM uses whatever high-resolution "clock" the OS provides it. If experience shows that clock is not monotonic when it is meant to be then we added internal guards to ensure time doesn't go backwards (which means sometimes it stands still which has its own issues). As time goes by and things like

Compression acceleration for Java

Hi All, This is a request for support in JVM to use system zlib or alternative implementations of zlib. Compression is heavily used in Java based big data, genomics and middleware applications. There are many products in market today which help in compression performance either through softwar

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

Nevermind, sorry somehow I missed the previous emails in the thread. On Friday, March 6, 2015 3:57 PM, Ben Manes wrote: I'd recommend that the exception thrown should be an IllegalStateException. This is documented in ConcurrentHashMap's computeIfAbsent as, * @throws IllegalStateException if

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

I'd recommend that the exception thrown should be an IllegalStateException. This is documented in ConcurrentHashMap's computeIfAbsent as, * @throws IllegalStateException if the computation detectably * attempts a recursive update to this map that would * otherwise never complete

Re: Why not "weakNanoTime" for jdk9?

> Am 07.03.2015 um 00:27 schrieb Aleksey Shipilev : > > I disagree on this premise. In the absence of proper API for CPU > affinity and CPU frequency control, we *do* need monotonicity and > linearity guarantees. +1 on that. The problem is that there is nothing like CPU affinity out of the box

Re: Why not "weakNanoTime" for jdk9?

Hi guys, On 03/06/2015 11:14 PM, Andrew Haley wrote: > On 03/06/2015 07:35 PM, Martin Buchholz wrote: >> We all know that nanoTime has problems. It would really help if you list what problems weakNanoTime is supposed to solve. > Many (most?) users of nanoTime, >> especially for benchmarking or

Re: [9] RFR of 8074460: Always print seeds used in [Splittable]Random instances in java.math tests

Looks good; thanks, -Joe On 3/6/2015 12:03 PM, Brian Burkhalter wrote: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8074460 Patch: http://cr.openjdk.java.net/~bpb/8074460/webrev.00/ Summary: Create a utility class which creates a pseudorandom number gen

Re: Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics

Wow, this looks excellent. I send a summary to panama-dev, FYI: http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/98.html That note has some discussion of atomicity which you might want to incorporate when you write the javadoc. — John On Mar 6, 2015, at 10:50 AM, Andrew Haley

Re: RFR: JDK-8074579 Use more efficient and readable way of checking PKZIP signatures

On Fri, Mar 6, 2015 at 1:37 PM, Xueming Shen wrote: > On 03/06/2015 12:46 PM, Martin Buchholz wrote: > >> Hi jar/zip maintainers, >> >> Here's an easy improvement. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/ < >> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/PKsig/> >

Re: RFR: JDK-8074577 Modernize Unsafe internal javadoc

On Mar 6, 2015, at 12:51 PM, Martin Buchholz wrote: > > A boring code review: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-javadoc-style/ > https://bugs.openjdk.java.net/browse/JDK-8074577 (Yawn.) Reviewed. — John P.S. Thanks.

Re: RFR: JDK-8074579 Use more efficient and readable way of checking PKZIP signatures

On 03/06/2015 12:46 PM, Martin Buchholz wrote: Hi jar/zip maintainers, Here's an easy improvement. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/ https://bugs.openjdk.java.net/browse/JDK-8074579 Looks fine, assume the

RFR: JDK-8074577 Modernize Unsafe internal javadoc

A boring code review: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-javadoc-style/ https://bugs.openjdk.java.net/browse/JDK-8074577

RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

A wee code review fer ya: https://bugs.openjdk.java.net/browse/JDK-8074578 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/

RFR: JDK-8074579 Use more efficient and readable way of checking PKZIP signatures

Hi jar/zip maintainers, Here's an easy improvement. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/ https://bugs.openjdk.java.net/browse/JDK-8074579

Re: Why not "weakNanoTime" for jdk9?

On 03/06/2015 07:35 PM, Martin Buchholz wrote: > We all know that nanoTime has problems. Many (most?) users of nanoTime, > especially for benchmarking or concurrent algorithms, don't really care > about the monotonicity guarantee and just want a "best-effort" > "as-efficient-as-possible" version o

[9] RFR of 8074460: Always print seeds used in [Splittable]Random instances in java.math tests

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8074460 Patch: http://cr.openjdk.java.net/~bpb/8074460/webrev.00/ Summary: Create a utility class which creates a pseudorandom number generator (PRNG) and retains the seed. Use this class in java.math tests whic

Why not "weakNanoTime" for jdk9?

We all know that nanoTime has problems. Many (most?) users of nanoTime, especially for benchmarking or concurrent algorithms, don't really care about the monotonicity guarantee and just want a "best-effort" "as-efficient-as-possible" version of nanoTime. Sure, some algorithms in java.util.concurr

RE: JEP 102 Process Updates revised API draft

Hi Chris, Since getPid can throw UOE that means that compareTo could now throw UOE. Jason > Subject: Re: JEP 102 Process Updates revised API draft > From: chris.hega...@oracle.com > Date: Fri, 6 Mar 2015 11:59:28 + > To: roger.ri...@oracle.com

Re: RFC: Adding ConcurrentModificationException for HashMap.computeIfAbsent(), and JDK-8071667

Hi. I'm picking this back up now. In Map/HashMap, there are already two methods that accept lambdas and throw a CME: forEach(BiConsumer) replaceAll(BiFunction) The Map interface documents these methods to state that "Exceptions are relayed to the caller", and has an @throws CME tag "if a

Re: JEP 102 Process Updates revised API draft

Hi Chris, Thanks for the comments. On 3/6/2015 6:59 AM, Chris Hegarty wrote: Roger, I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition. Some comments, most of which I stuffed into a webrev based on your branch, http://cr.openjdk.java.

Re: Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics

I've tried to so everything I've been asked. If this version passes muster with everyone I'll Javadoc all the public methods and fields and put it up for RFA next week. I guess it's going to need a lot of testing and security analysis. I added versions of all {put,get} methods with the boolean b

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 2015-03-04 14:31, Erik Joelsson wrote: Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for de

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 2015-03-04 17:30, Alan Bateman wrote: On 04/03/2015 15:03, Magnus Ihse Bursie wrote: I believe all warnings are important to check! Unfortunately, this has not been done for a lot of warnings for a lot of time. :( Right, although in the past we had some areas close to be cleared of warnings,

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

On 03/06/2015 02:30 PM, Staffan Larsen wrote: I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed. Thanks, /Staffan I see no problem, quite the opposite, please backport i

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed. Thanks, /Staffan

Re: RFR 8073692: (cs) Inconsistent docs for CharsetDecoder.replaceWith and CharsetEncoder.replaceWith

Thanks! On 05.03.2015 20:48, Martin Buchholz wrote: Looks good to me! On Thu, Mar 5, 2015 at 7:12 AM, Ivan Gerasimov mailto:ivan.gerasi...@oracle.com>> wrote: Hello! It was noticed, that the javadoc for CharsetDecoder#replaceWith is missing the words about constraints on the len

libjli, get_cpuid() implementation missing for MacOs, breaks libjli.so build in slowdebug

Hi all, I see a build error when building the libjli on MacOs with slowdebug: Undefined symbols for architecture x86_64: "_get_cpuid", referenced from: _hyperthreading_support in ergo_i586.o _logical_processors_per_package in ergo_i586.o ld: symbol(s) not found for architecture x86_

Re: JEP 102 Process Updates revised API draft

Roger, I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition. Some comments, most of which I stuffed into a webrev based on your branch, http://cr.openjdk.java.net/~chegar/process_comments/webrev/ 1) ProcessHandle.compareTo() can drop the C