May 2012 - core-libs-dev

Codereview request for 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H
by Xueming Shen 02 May '12

02 May '12

Hi Here are the webrev and blenderrev for the proposed change to add 5 new regex constructs \R \v \V \h \V. \R: recommended by Unicode Regex TR#18 for matching all line ending characters and sequences, is equivalent to ( \u000D\u000A | [\u000A\u000B\u000C\u000D\u0085\u2028\u2029] ) \h, \v, \H and \V: matches any character considered to (not) be horizontal/vertical whitespace. Webrev: http://cr.openjdk.java.net/~sherman/7014640/blenderrev.html Blenderrev: http://cr.openjdk.java.net/~sherman/7014640/blenderrev.html new Pattern api http://cr.openjdk.java.net/~sherman/7014640/Pattern.html Here are couple notes regarding the spec/implementation. (1) \v was implemented as \u000B ('\013'), but not documented (did not appear in our API doc as one supported construct, such as \t \r \n...). To define \v as a "general" construct for all vertical whitespace characters might trigger some compatibility concerns (more characters are now matched by \v). But given this is a never documented implementation detail and the \u000B is still being matched by \v, I would consider this as an acceptable behavior change. (2) a predefined character class can appear inside another character class, for example you can have [...\v...], however, since it represents a "class" of character, so it can't be a start or end code point of a range inside a class, so you can have [a-b], but you can't have [\h-...] or [...-\h] (exception will be thrown). But for \v, since it was implemented as \u000B (VT), you were able to put it as a start or end value of a range, I feel it'd be better still keep it the way it worked before, so [\v-\v] works and will match the VT in this implementation. (3) The newly added \h\v\H\V constructs are all "Unicode version" of character classes, the rest of the "predefined character class" family (\d\D\s\S\w\W) are ASCII only, you will have to turn on flag UNICODE_CHARACTER_CLASS to get the Unicode version of these constructs. This is kinda of inconsistent. Perl's corresponding constructs work in a similar way, all Perl's \d\D\s\S \w\W\v\V\h\H work in Unicode version, and to have a \a modifier to turn the \d\D\s\S\w\W back to ASCII mode but not for \h\v\H\V. We had the discussion back into JDK7 regarding the ASCII vs Unicode for these constructs, the decision then was to keep these predefined character classes (and POSIX character classes) ASCII by default, to have a flag UNICODE_CHARACTER_CLASS to turn them into Unicode version. Given there is NOT an ASCII version in Perl and we didn't have ASCII version in Java regex to trigger compatibility concern, I feel it might be better to just have a simple Unicode version of \h\v\H\V. (4)\R is not a character class, since it matched \r\n. This one will need to go through ccc process. Thanks, -Sherman

2 2

hg: jdk8/tl/jdk: 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary
by mandy.chung＠oracle.com 02 May '12

02 May '12

Changeset: 46e0bd218fcc Author: mchung Date: 2012-05-01 19:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e0bd218fcc 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Reviewed-by: alanb, mullan, prr ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/nio/ch/Util.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java

1 0

hg: jdk8/tl/jdk: 2 new changesets
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: 9e82ac15ab80 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e82ac15ab80 Added tag jdk8-b36 for changeset 45da9cb055ee ! .hgtags Changeset: 6c9c3d7ce9e2 Author: lana Date: 2012-05-01 11:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c9c3d7ce9e2 Merge

1 0

hg: jdk8/tl/langtools: Added tag jdk8-b36 for changeset 94bbaa67686f
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: 5891b38985e8 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5891b38985e8 Added tag jdk8-b36 for changeset 94bbaa67686f ! .hgtags

1 0

hg: jdk8/tl/jaxp: Added tag jdk8-b36 for changeset cfd288fe1d3e
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: c388369cf4da Author: katleman Date: 2012-04-26 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c388369cf4da Added tag jdk8-b36 for changeset cfd288fe1d3e ! .hgtags

1 0

hg: jdk8/tl/hotspot: Added tag jdk8-b36 for changeset 50b4400ca1ec
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: bfcf92bfefb8 Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfcf92bfefb8 Added tag jdk8-b36 for changeset 50b4400ca1ec ! .hgtags

1 0

hg: jdk8/tl/jaxws: Added tag jdk8-b36 for changeset 89b36c658e39
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: b05a948db1b6 Author: katleman Date: 2012-04-26 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b05a948db1b6 Added tag jdk8-b36 for changeset 89b36c658e39 ! .hgtags

1 0

hg: jdk8/tl/corba: 2 new changesets
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: 83fac66442cf Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/83fac66442cf Added tag jdk8-b36 for changeset a5a61f259961 ! .hgtags Changeset: 4a653e435441 Author: lana Date: 2012-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4a653e435441 Merge

1 0

hg: jdk8/tl: Added tag jdk8-b36 for changeset 6a6ba0a07f33
by lana.steuck＠oracle.com 01 May '12

01 May '12

Changeset: 47aa0ddc9126 Author: katleman Date: 2012-04-26 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/47aa0ddc9126 Added tag jdk8-b36 for changeset 6a6ba0a07f33 ! .hgtags

1 0

Remove the assert in Integer.valueOf()
by Rémi Forax 01 May '12

01 May '12

Hi guys, I've found a case where assert is harmful because it doesn't play well with Hotspot inlining heuristic. I'm currently playing with a lambda modified implementation of java.util and as you see below Integer.valueOf is considered as too big by Hotspot to be inlined. 79 2 b lambda.perf.Iterables::filterMapReduce (72 bytes) @ 4 java.util.AbstractList::iterator (10 bytes) inline (hot) @ 6 java.util.AbstractList$Itr::<init> (6 bytes) unloaded signature classes @ 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) @ 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) ! @ 16 java.util.AbstractList$Itr::next (45 bytes) inline (hot) @ 1 java.util.AbstractList$Itr::checkForComodification (23 bytes) inline (hot) @ 14 java.util.Arrays$ArrayList::get (7 bytes) inline (hot) @ 29 lambda.perf.Test$1::accept (9 bytes) inline (hot) @ 5 lambda.perf.Test$1::accept (13 bytes) inline (hot) @ 1 java.lang.Integer::intValue (5 bytes) inline (hot) @ 45 lambda.perf.Test$2::map (9 bytes) inline (hot) @ 5 lambda.perf.Test$2::map (2 bytes) inline (hot) @ 52 lambda.perf.Test$3::apply (13 bytes) inline (hot) @ 9 lambda.perf.Test$3::apply (13 bytes) inline (hot) @ 1 java.lang.Integer::intValue (5 bytes) inline (hot) @ 5 java.lang.Integer::intValue (5 bytes) inline (hot) @ 9 java.lang.Integer::valueOf (54 bytes) too big @ 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) @ 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) but the code of Integer.valueOf doesn't seem too big: public static Integer valueOf(int i) { assert IntegerCache.high >= 127; if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); } The issue is that Hotspot also count the bytecodes related to assert in its inlining heuristic. If the assert is commented, the inlining tree is good. 88 2 b lambda.perf.Iterables::filterMapReduce (72 bytes) @ 4 java.util.AbstractList::iterator (10 bytes) inline (hot) @ 6 java.util.AbstractList$Itr::<init> (6 bytes) unloaded signature classes @ 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) @ 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) ! @ 16 java.util.AbstractList$Itr::next (45 bytes) inline (hot) @ 1 java.util.AbstractList$Itr::checkForComodification (23 bytes) inline (hot) @ 14 java.util.Arrays$ArrayList::get (7 bytes) inline (hot) @ 29 lambda.perf.Test$1::accept (9 bytes) inline (hot) @ 5 lambda.perf.Test$1::accept (13 bytes) inline (hot) @ 1 java.lang.Integer::intValue (5 bytes) inline (hot) @ 45 lambda.perf.Test$2::map (9 bytes) inline (hot) @ 5 lambda.perf.Test$2::map (2 bytes) inline (hot) @ 52 lambda.perf.Test$3::apply (13 bytes) inline (hot) @ 9 lambda.perf.Test$3::apply (13 bytes) inline (hot) @ 1 java.lang.Integer::intValue (5 bytes) inline (hot) @ 5 java.lang.Integer::intValue (5 bytes) inline (hot) @ 9 java.lang.Integer::valueOf (32 bytes) inline (hot) @ 28 java.lang.Integer::<init> (10 bytes) call site not reached @ 61 java.util.AbstractList$Itr::hasNext (20 bytes) inline (hot) @ 8 java.util.Arrays$ArrayList::size (6 bytes) inline (hot) Given that Integer.valueOf() is a method used very often and that if the inlining fails, the escape analysis will not remove the allocation, I think it's a good idea to comment this assert. cheers, Rémi

7 17