September 2014 - core-libs-dev

RFR: 5043030 (reflect) unnecessary object creation in reflection
by Andrej Golovnin 11 Sep '14

11 Sep '14

Hi Joe, I have prepared a patch for the issue JDK-5043030. The patch consists of two parts: one for jdk and one for hotspot. You can find the webrevs here: JDK-patch: https://db.tt/7DYph0OH Hotspot-patch: https://db.tt/hHsN0yn4 The JDK-patch has two tests to verify the changes. Please review it and I hope you can sponsor it. Best regards, Andrej Golovnin

4 24

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow
by Claes Redestad 11 Sep '14

11 Sep '14

On 09/10/2014 04:38 PM, mark.reinhold(a)oracle.com wrote: >> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/ > Looks fine, but when an exception declaration is on its own line then > the opening brace of the method should be on its own line too, as in > the original: > > protected Class<?> findClass(final String name) > throws ClassNotFoundException > { Original had weird 5 space indentation though: http://cr.openjdk.java.net/~redestad/8057936/webrev.6/ Will need a sponsor for this, if it looks good to everyone. /Claes > > - Mark

5 6

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net
by Mike Duigou 10 Sep '14

10 Sep '14

On Aug 14 2014, at 06:39 , Alan Bateman <Alan.Bateman(a)oracle.com> wrote: > On 14/08/2014 14:23, Claes Redestad wrote: >> How about methods only taking beginIndex? Integer.parseInt("x: 10000000", 3, 10)? I guess these could to be dropped >> to avoid ambiguity and instead allow for variations where radix can be left out. >> >> I think there are two alternatives to the current implementation: >> - only keep parseInt(CharSequence s, int beginIndex, int endIndex, int radix) > That's my preference Looking at the examples I agree that providing only this one method is probably the least error prone option. Mike > and core-libs-dev would be the place to move the discussion. > > -Alan. > > >> - optional radix: parseInt(CharSequence s, int beginIndex, int endIndex), parseInt(CharSequence s, int beginIndex, int endIndex, int radix) >> >> (Should this discussion be moved to core-libs-dev?) >> >> /Claes >

3 2

[9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods
by Claes Redestad 10 Sep '14

10 Sep '14

Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/ discussion:http://mail.openjdk.java.net/pipermail/net-dev/2014-August/00862… Changes: - Removethe following methods: Integer::parseInt(CharSequence s, int radix, int beginIndex) Integer::parseUnsignedInt(CharSequence s, int radix, int beginIndex) Long::parseLong(CharSequence s, int radix, int beginIndex) Long::parseUnsignedLong(CharSequence s, int radix, int beginIndex) - Move radix parameter to the end in the following methods: Integer::parseInt(CharSequence s, int radix, int beginIndex, int endIndex) Integer::parseUnsignedInt(CharSequence s, int radix, int beginIndex, int endIndex) Long::parseLong(CharSequence s, int radix, int beginIndex, int endIndex) Long::parseUnsignedLong(CharSequence s, int radix, int beginIndex, int endIndex) - Change all places in the code where the methods already have been adopted - Add some tests for parseUnsignedInt/-Long - Ensure that when parsing fails the correct index is reported in the exception /Claes

3 3

RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow
by Claes Redestad 10 Sep '14

10 Sep '14

Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/ /Claes

6 11

RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some gzipped files (zlib 1.2.8 port)
by Seán Coffey 09 Sep '14

09 Sep '14

I'd like to port the zlib v1.2.8 libraries to JDK 7u. Currently, 7u uses zlib v1.2.3 libraries. 8u20 was recently upgraded to 1.2.8. zlib fixes since 1.2.3 can be found at http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/raw_files/new/… While porting, I noticed that the Program.gmk had a bad reference in it to zlib 1.1.3 (JDK6 version) - I've corrected that to 1.2.8 for now but question if the extra INCLUDE directive is even needed. bug report : https://bugs.openjdk.java.net/browse/JDK-8044725 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/ regards, Sean.

2 2

[9] RFR (S): 8057657: Annotate LambdaForm parameters with types
by Vladimir Ivanov 09 Sep '14

09 Sep '14

http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057657 Add ability to annotate LambdaForm parameters with their types. Type info could be useful during LambdaForm compilation to produce better bytecode. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

2 3

[9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor more extensively
by Vladimir Ivanov 09 Sep '14

09 Sep '14

http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8057922 Introduce more sharing on LambdaForm level by rewriting most of the MH combinators using LambdaFormEditor. The new code is guarded by USE_LAMBDA_FORM_EDITOR flag and turned off by default because it introduces significant peak performance regression on Octane benchmark. I'm working on the fix. Original implementation will be removed once performance degradation is fixed. Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa", COMPILE_THRESHOLD={0,30}, and USE_LAMBDA_FORM_EDITOR={true,false}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

2 3

Replace concat String to append in StringBuilder parameters
by Otávio Gonçalves de Santana 09 Sep '14

09 Sep '14

*Motivation:* Make another append instead of concat String inside of append parameter in StringBuilder class. To avoid an extra StringBuilder created for the purpose of concatenating. So it will save memory and will faster than concat String. Doing a code to benchMark[1], the result is: Benchmark Mode Samples Mean Mean error Units m.StringBuilderConcatBenchMark.stringBuilder thrpt 10 6317444.705 108673.584 ops/s m.StringBuilderConcatBenchMark.stringBuilderWithConcat thrpt 10 3354554.435 68353.924 ops/s The webrev of all code is: https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_builder_concat… <https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_builder_concat…> [1] @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class StringBuilderConcatBenchMark { private static final String F = "!!!!"; private static final String E = " running in Java "; private static final String D = " in the code "; private static final String C = " to try impact "; private static final String B = " with some text "; private static final String A = "Doing a test"; @GenerateMicroBenchmark public void stringBuilder(BlackHole bh) { bh.consume(createBuilder(A, B, C, D, E, F)); } @GenerateMicroBenchmark public void stringBuilderWithConcat(BlackHole bh) { bh.consume(createBuilderWithConcat(A, B, C, D, E, F)); } private StringBuilder createBuilder(String... values) { StringBuilder text = new StringBuilder(); text.append(values[0]).append(values[1]) .append(values[2]).append(values[3]) .append(values[4]).append(values[5]); return text; } private StringBuilder createBuilderWithConcat(String... values) { StringBuilder text = new StringBuilder(); text.append(values[0] + values[1]) .append(values[2] + values[3]) .append(values[4]+ values[5]); return text; } } -- Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava <http://about.me/otaviojava>* 55 (11) 98255-3513

17 69

[9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks
by Vladimir Ivanov 09 Sep '14

09 Sep '14

http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057656 There are some corner cases which MT.isCastableTo() & MT.isConvertibleTo() don't treat right (e.g. int->String converstion of return type in MT.isCastableTo()). Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

2 4