Re: RFR [9]: 8050142: Optimize java.util.Formatter

Sorry about that; maybe I should've renamed the field c to conv instead, but I think I need to be conservative now and will revert the name changes. New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3 Changing usage of given locale or any semantic change is really out-of-scope he

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

SecureRandom is unfortunatelly pretty complex. It is interpreting the seed url in some way (the configuration you mentioned behave very special since Java 6) , it is mixing seed and continues data and it reorders the implementations used. JEP 123 intended to clear things, but getInstanceStrong()

RE: RFR [9]: 8050142: Optimize java.util.Formatter

Claes, Maybe change (or not): -throw new UnknownFormatConversionException(String.valueOf(c)); +throw new UnknownFormatConversionException(String.valueOf(conv)); I haven't examined it too deeply but it seems odd that some of those print methods don't use the given locale when converting cas

Re: Stream.concat

On Jul 14, 2014, at 5:00 PM, Remi Forax wrote: > and imagine the case where you know the size of a stream returned by flatMap, > in that case, > you may want to split before pumping the values of the stream. > Since you don't know the characteristics of the flat mapped streams until you get th

[9] RFR (M): 8050200: Make LambdaForm intrinsics detection more robust

http://cr.openjdk.java.net/~vlivanov/8050200/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050200 Replace pattern matching sequences of LambdaForm names during compilation with explicit marks on MethodHandles. Intrinsic ID is associated with a method handle using DelegatingMethodHandle.

Re: ThreadLocalRandom clinit troubles

Hi Sean, Alex Here's a sum-up post: http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010700.html Regards, Peter On 07/14/2014 04:44 PM, Sean Mullan wrote: I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz

Re: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes

I haven't seen any one with jdk9 reviewer status comment on this And although it looks OK to me I'm not responsible for any of the areas it covers, so it does need an official nod .. -phil. On 7/12/2014 7:38 AM, Otávio Gonçalves de Santana wrote: http://cr.openjdk.java.net/~prr/8049892.1/ O

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi, final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2 Thanks in advance for reviews. I also need a volunteer to sponsor this. :-) /Claes On 07/14/2014 04:21 PM, Claes Redestad wrote: Yes, might be worth addressing just for correctness/readability. /Claes On 07/14/20

[9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers

http://cr.openjdk.java.net/~vlivanov/8050057/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050057 Cache MethodHandle reinvokers per basic type. For BoundMethodHandles, rebinding is no-op unless underlying LF is too complex (see BMH::tooComplex() for details). Also, introduced Delegating

[9] RFR (XS): 8050174: Support overriding of isInvokeSpecial flag in WrappedMember

http://cr.openjdk.java.net/~vlivanov/8050174/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050174 Support overriding of isInvokeSpecial flag in WrappedMember. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by:

Re: Stream.concat

On 07/14/2014 01:37 PM, Paul Sandoz wrote: On Jul 14, 2014, at 12:57 PM, Remi Forax wrote: On 07/14/2014 12:51 PM, Paul Sandoz wrote: On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: I was not able to find the answer to my question in the archive, why Stream.concat is not implemented like t

Re: ThreadLocalRandom clinit troubles

I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz wrote: Thanks to Peter for digging into the secure seed generator classes and coming up with a patch. Openjdk security folks, please review. I confess to getting lost when

[9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050173 Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. Also, some cleanups: * rewrote MH.viewAsType on top of MH.copyWith; * extended

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Yes, might be worth addressing just for correctness/readability. /Claes On 07/14/2014 03:02 PM, Ivan Gerasimov wrote: A very minor one: 2704 if (Character.isUpperCase(conv)) 2705 f.add(Flags.UPPERCASE); 2706 c = Character.toLowerCase(conv); m

[9] RFR (M): 8050166: Get rid of some package-private methods on arguments in j.l.i.MethodHandle

http://cr.openjdk.java.net/~vlivanov/8050166/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050166 Get rid of the following methods in j.l.i.MethodHandle: * convertArguments(MethodType newType) * bindArgument(int pos, BasicType basicType, Object value) * bindReceiver(Object receiver)

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi Andrej, while the change seems reasonable, I can't find any usage of %a/%A in the JDK and haven't even covered it in my micros. :-) Also, it could be further improved with 8041972 to turn: 3533 String exp = res.substring(idx + 1); 3534

Re: [9] RFR (M): 8050053: Improve caching of different invokers

Thank you, Paul. Best regards, Vladimir Ivanov On 7/14/14 5:34 PM, Paul Sandoz wrote: On Jul 11, 2014, at 6:35 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050053 Improve sharing of different invokers: basic, gen

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

Paul, thanks! Small update: http://cr.openjdk.java.net/~vlivanov/8050052/prepared_forms/ Updated version: http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ Best regards, Vladimir Ivanov On 7/14/14 4:57 PM, Paul Sandoz wrote: On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov wrote: http

Re: [9] RFR (M): 8050053: Improve caching of different invokers

On Jul 11, 2014, at 6:35 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050053/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050053 > > Improve sharing of different invokers: basic, generic & exact invokers, > uninitialized call site invoker and NamedFunction invoker

Re: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

Hi Jeff, Home grown loops are not the best way of micro-benchmarking (have done it myself and learned it). JIT can sometimes optimize the code so aggressively that performance differences you obtain from such benchmarks just show that your concrete program can be optimized better and not that

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi Claes, it looks good. And I have one minor improvement. Take look at the following lines of the method FormatSpecifier#hexDouble(double, int): 3532 // Get exponent and append at the end. 3533 String exp = res.substring(idx + 1); 3534

Re: RFR [9]: 8050142: Optimize java.util.Formatter

A very minor one: 2704 if (Character.isUpperCase(conv)) 2705 f.add(Flags.UPPERCASE); 2706 c = Character.toLowerCase(conv); maybe 2704 if (Character.isUpperCase(conv)) { 2705 f.add(Flags.UPPERCASE); 2706

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

On Jul 11, 2014, at 6:18 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8050052 > > Numerous small code cleanups in java.lang.invoke package. > > Testing: jtreg, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 07/14/2014 02:17 PM, Claes Redestad wrote: If you're in a really hyper-optimizing mood, you could also eliminate construction of ArrayList in parse(): http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.02/ Have you measured this to have a real effect? I'm not convinced it woul

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi again, updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1 changes: - specify capacity on line 2931 as suggested by Andrej Golovnin - exp.append("0") -> exp.append('0') on line 3781 - merged append+justify into appendJustified as suggested by Peter Levart - replaced th

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi Peter, On 2014-07-14 14:05, Peter Levart wrote: On 07/14/2014 01:29 PM, Claes Redestad wrote: Hi Peter, On 2014-07-14 13:25, Peter Levart wrote: On 07/14/2014 12:07 PM, Claes Redestad wrote: Hi, please review this patch which optimizes away some allocations from java.util.Formatter and

Re: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

Hi been watching this fascinating discussion - seeing Jeff's benchmark today, was wondering if there isn't already at least one benchmark written with JMH? Wouldn't it make sense to make that part of the submission, as a standard practice in refactoring like this? Regards, Patrick On Mon, Jul

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 07/14/2014 01:29 PM, Claes Redestad wrote: Hi Peter, On 2014-07-14 13:25, Peter Levart wrote: On 07/14/2014 12:07 PM, Claes Redestad wrote: Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting Stri

RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI

Hi everyone, Could you please review my change for JDK-8048175? http://cr.openjdk.java.net/~prappo/8048175/webrev.00/ Summary 1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and javax.net.SocketFactory which are available since 1.4 2. com.sun.jndi.toolkit.corba.CorbaUti

Re: Stream.concat

On Jul 14, 2014, at 12:57 PM, Remi Forax wrote: > > On 07/14/2014 12:51 PM, Paul Sandoz wrote: >> On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: >> >>> I was not able to find the answer to my question in the archive, >>> why Stream.concat is not implemented like this ? >>> >>> @SafeVarargs

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi Peter, On 2014-07-14 13:25, Peter Levart wrote: On 07/14/2014 12:07 PM, Claes Redestad wrote: Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev:

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi, good suggestions, I'll incorporate them. /Claes On 2014-07-14 13:08, Andrej Golovnin wrote: Hi Claes, in the method Formatter$FormatSpecifier#justify(String) you can pre-calculate the capacity of the StringBuilder to avoid array copying, e.g. instead of 2931 StringBuilder

Re: RFR [9]: 8050142: Optimize java.util.Formatter

On 07/14/2014 12:07 PM, Claes Redestad wrote: Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.

Re: RFR [9]: 8050142: Optimize java.util.Formatter

Hi Claes, in the method Formatter$FormatSpecifier#justify(String) you can pre-calculate the capacity of the StringBuilder to avoid array copying, e.g. instead of 2931 StringBuilder sb = new StringBuilder(); use this one: 2931 StringBuilder sb = new StringBuilder(s.length

Re: Stream.concat

On 07/14/2014 12:51 PM, Paul Sandoz wrote: On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: I was not able to find the answer to my question in the archive, why Stream.concat is not implemented like this ? @SafeVarargs public static Stream concat(Stream... streams) { return Arrays.str

Re: Stream.concat

On Jul 12, 2014, at 5:41 PM, Remi Forax wrote: > I was not able to find the answer to my question in the archive, > why Stream.concat is not implemented like this ? > > @SafeVarargs > public static Stream concat(Stream... streams) { >return Arrays.stream(streams).flatMap(Function.identit

RFR [9]: 8050142: Optimize java.util.Formatter

Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 bug: https://bugs.openjdk.java.net/browse/JD

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

On 07/14/2014 07:03 AM, David Holmes wrote: On 12/07/2014 3:56 AM, Remi Forax wrote: On 07/11/2014 06:18 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8050052 I've found myself writing the very same code as MethodH

Re: [9] RFR (M): 8049555: Move varargsArray from sun.invoke.util package to java.lang.invoke

Paul, Igor, thanks for review. Best regards, Vladimir Ivanov On 7/11/14 4:24 PM, Paul Sandoz wrote: On Jul 11, 2014, at 2:21 PM, Vladimir Ivanov wrote: Igor, thanks for the hint! Yes, much better. Updated version: http://cr.openjdk.java.net/~vlivanov/8049555/webrev.01/ +1 Paul.