RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

Hi, MemberName::hashCode is exercised during startup of jake, and is currently implemented using Objects.hash(...), which allocates Object[]s and boxes bytes. Inlining this makes this slightly more efficient before the JIT kicks in, but more measurably allows initialization of

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

On 05/11/2015 17:10, Steve Drach wrote: Hi, Here’s a new webrev that addresses the issues Paul brought up. The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when

Re: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

Wang Weijun, > The function is rather new in the latest Solaris beta [1] and it's > preferred to reading from /dev/random. There are already people > suggest adding it to Linux. If I use simply using dlsym then it will > automatically work on all current and future platforms. In fact, I > was

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/08/2015 02:43 PM, Claes Redestad wrote: Hi, indy eagerly creates and initializes all integral type caches (Byte$ByteCache, Short$ShortCache) which has a small, measurable impact to jake startup and footprint. Exposing ZERO constants from Byte, Character, etc which are guaranteed to be

RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

Hi, i wanted to start a discussion/review-process some time ago, see the second-try below. Is there someone who wants to discuss/review/sponsor these changes? Else, should i link my result as reference into the JBS? For the two other affected mailing-lists/repos (macos-port-dev[0],net-dev[1])

RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Hi, indy eagerly creates and initializes all integral type caches (Byte$ByteCache, Short$ShortCache) which has a small, measurable impact to jake startup and footprint. Exposing ZERO constants from Byte, Character, etc which are guaranteed to be identical to what's returned from each

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/08/2015 04:43 PM, Claes Redestad wrote: > Hi, > > indy eagerly creates and initializes all integral type caches > (Byte$ByteCache, Short$ShortCache) which has a small, measurable > impact to jake startup and footprint. Exposing ZERO constants from Byte, > Character, etc which are guaranteed

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/08/2015 06:08 PM, Peter Levart wrote: On 11/08/2015 02:43 PM, Claes Redestad wrote: Hi, indy eagerly creates and initializes all integral type caches (Byte$ByteCache, Short$ShortCache) which has a small, measurable impact to jake startup and footprint. Exposing ZERO constants from

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

On 08/11/2015 19:36, Paul Sandoz wrote: : I was wondering if it might be possible to consider this a mostly internal contract since the URL class loading functionality (URLClassPath.java) creates such URLs for processing by JarURLConnection in some code paths (getResourceAsStream IIRC).

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

On 11/08/2015 03:30 PM, Claes Redestad wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8141677 > webrev: http://cr.openjdk.java.net/~redestad/8141677/webrev.01/ The approach looks sensible. The implementation deserves a comment why Objects.hash is not used, because it is tempting to fold

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

It's worth considering, but j.l.reflect is already initialized by this point in jake and I saw no real difference in heap dumps or class loading order between this and an experiment where the ZERO constants were simply made public. Adding methods to JavaLangAccess has its own overheads to

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

> On 8 Nov 2015, at 16:51, Alan Bateman wrote: > > On 05/11/2015 17:10, Steve Drach wrote: >> Hi, >> >> Here’s a new webrev that addresses the issues Paul brought up. The >> versioned entry cache has been removed, the search space has been reduced, >> the

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Michael, You see, switch2 is on par with explicit for 0 and 1 args. switch10 probably suffers from to-many-bytecodes-per-method syndrome. I tried to shorten your switch2 and switch10 methods by delegating to explicit/varargs methods: @SafeVarargs static List varargs_switch2(E... ea)

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

> On 8 Nov 2015, at 21:21, Alan Bateman wrote: > > On 08/11/2015 19:36, Paul Sandoz wrote: >> : >> >> I was wondering if it might be possible to consider this a mostly internal >> contract since the URL class loading functionality (URLClassPath.java) >> creates such

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 2015-11-08 20:40, Peter Levart wrote: On 11/08/2015 06:46 PM, Claes Redestad wrote: It's worth considering, but j.l.reflect is already initialized by this point in jake and I saw no real difference in heap dumps or class loading order between this and an experiment where the ZERO

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Peter, You're right. I see the same thing running that locally. Nice work! As a sanity check, I changed the code to mirror what I think it would look like in practice, and to make sure that structure didn't change any JIT optimizations. The code is attached. 1. use

Re: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

> On Nov 8, 2015, at 7:18 PM, Dmitry Samersoff > wrote: > > Wang Weijun, > >> The function is rather new in the latest Solaris beta [1] and it's >> preferred to reading from /dev/random. There are already people >> suggest adding it to Linux. If I use simply

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

I think the mailing list stripped my attachments, so I put it up on github: https://github.com/michaelhixson/jmh-benchmark-listof -Michael On Sun, Nov 8, 2015 at 2:55 PM, Michael Hixson wrote: > Hi Peter, > > You're right. I see the same thing running that locally.

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

On 11/06/2015 02:23 AM, David Holmes wrote: Before I look at the code, what is the status of the "Open Issues" referenced in the JEP? Also the JDK changes need to be reviewed on core-libs-dev and in particular must be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz) Martin

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Hi Doug, On 9/11/2015 9:31 AM, Doug Lea wrote: On 11/06/2015 02:23 AM, David Holmes wrote: Before I look at the code, what is the status of the "Open Issues" referenced in the JEP? Also the JDK changes need to be reviewed on core-libs-dev and in particular must be seen by the jsr166