From sundararajan.athijegannathan at oracle.com Mon Apr 1 12:40:29 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 01 Apr 2013 12:40:29 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130401124040.A9CF9484FA@hg.openjdk.java.net> Changeset: 41a212ea8c0c Author: sundar Date: 2013-03-28 20:48 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/41a212ea8c0c 8010924: Dealing with undefined property gets you a fatal stack Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8010924.js Changeset: e2ea7a29b9c1 Author: lagergren Date: 2013-03-29 08:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e2ea7a29b9c1 8010995: The bug ID 8010710 accidentally got two digits transposed in the checkin and unit test name Reviewed-by: hannesw, sundar + test/script/basic/JDK-8010710.js + test/script/basic/JDK-8010710.js.EXPECTED - test/script/basic/JDK-8017010.js - test/script/basic/JDK-8017010.js.EXPECTED Changeset: 704f3083af8a Author: sundar Date: 2013-03-29 18:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/704f3083af8a 8011063: With older ant, we get the error "The type doesn't support nested text data ("${run.te...jvmargs}")." Reviewed-by: hannesw, ksrini ! make/build.xml Changeset: a094fc010120 Author: jlaskey Date: 2013-03-31 08:19 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a094fc010120 8011095: PropertyHashMap.rehash() does not grow enough Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java From Thomas.Salter at unisys.com Mon Apr 1 14:30:01 2013 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 1 Apr 2013 09:30:01 -0500 Subject: JDK-8002283 WeakHashMap Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3013671E7F07D@USEA-EXCH7.na.uis.unisys.com> We've upgraded to 7u21 and now we're seeing the same initialization problem as reported in bug JDK-8002283, except this time with WeakHashMap instead of HashMap. The same workaround of explicitly initializing WeakHashMap in System.initializeSystemClass has gotten us around the issue. Here's the stack trace. Exception in thread "main" java.lang.ExceptionInInitializerError at java.util.WeakHashMap.(WeakHashMap.java:277) at java.util.WeakHashMap.(WeakHashMap.java:297) at java.lang.reflect.Proxy.(Proxy.java:240) at java.lang.Class.checkMemberAccess(Class.java:2190) at java.lang.Class.getDeclaredField(Class.java:1898) at java.util.concurrent.atomic.AtomicReference.(AtomicReference.java:55) at java.security.Policy.(Policy.java:121) at java.security.AccessControlContext.getDebug(AccessControlContext.java:98) at java.security.AccessController.checkPermission(AccessController.java:537) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:706) at java.nio.channels.spi.SelectorProvider.loadProviderFromProperty(SelectorProvider.java:88) at java.nio.channels.spi.SelectorProvider.access$000(SelectorProvider.java:69) at java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:171) at java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:169) at java.security.AccessController.doPrivileged(Native Method) at java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.java:168) at java.lang.System.inheritedChannel(System.java:242) at sun.rmi.server.Activation$2.run(Activation.java:1927) at sun.rmi.server.Activation$2.run(Activation.java:1925) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.server.Activation.main(Activation.java:1924) Caused by: java.lang.NullPointerException at java.security.Policy.isSet(Policy.java:132) at java.security.AccessControlContext.getDebug(AccessControlContext.java:98) at java.security.AccessController.checkPermission(AccessController.java:537) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:706) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:4) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:49) at java.security.AccessController.doPrivileged(Native Method) at java.util.WeakHashMap$Holder.(WeakHashMap.java:210) ... 23 more ? Tom Salter? |? Software Engineer? |? Java & Middleware Development Unisys? |? 2476 Swedesford Road? |? Malvern, PA? 19355 From Alan.Bateman at oracle.com Mon Apr 1 16:13:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Apr 2013 17:13:32 +0100 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> Message-ID: <5159B22C.7030000@oracle.com> On 28/03/2013 15:59, Paul Sandoz wrote: > Hi, > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096 > > Webrev: > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ > > Spec diff: > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff/overview-summary.html > > Relevant JavaDoc generated from lambda repo (required for viewing @apiNote, @implSpec, @implNote declarations): > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/ > > Note: some of the JavaDoc generated from the lambda repo may contain additional methods or specification that is relevant to the stream framework. > Just a few small comments from a quick pass over the webrev. The @return for the Array.spliterator methods reads "A spliterator from an array", maybe this should be "the array". For Iterable.forEach (and the Spliterator methods that take a Consumer) then you might consider "Errors or runtime exceptions" rather than "Exceptions" so that it is clear that an Error thrown by the action's accept method will be propagated too. The class description for the PrimitiveIterator.OfXXX classes is the one-liner "Specialization for XXX elements". It might be nicer to have this as "A Spliterator specialized for XXX elements". Will you change the Tripwire utility class to use the platform logger before you push this? Another thing on Tripwire is that the property lookup will probably fail if the class is initalized with application code on the stack and there is a security manager set. I think this will need to be changed to get the property value in a privileged blocked. The copyright header on the tests is normally the GPL header (no "Classpath" exception). I assume you'll fix this before pushing. One question on the spliteratorDataProvider - what is the issue with IdentityHashMap or do we know yet? -Alan. From vladimir.voskresensky at oracle.com Mon Apr 1 16:10:10 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky - Oracle) Date: Mon, 01 Apr 2013 20:10:10 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <5156C697.8060003@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> <5156C697.8060003@oracle.com> Message-ID: <5159B162.4080805@oracle.com> Jesper, Minor comment: it's better to have env variable named IDE_ALT_BOOTDIR instead of IDE_JAVAPATH to give analogy with the old well known meaning. Vladimir. On 03/30/13 03:03 PM, Vladimir Voskresensky wrote: > Jesper, > > It looks good and works for me on Linux_64. > > Some comments for others: > before running IDE specify IDE_JAVAPATH env variable if want to navigate into > some java/include files (value is the same as previously was known as > ALT_BOOTDIR): > #export IDE_JAVAPATH=/opt/jdk/latest7 > after opening project, make sure you are switched to Linux configuration > > Thanks! > Vladimir. > > On 03/27/2013 08:04 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> A new webrev is now available. The issues reported from the first review >> should be fixed and the project now contains configurations for both Linux_64 >> and Mac_64. >> >> To select configuration there is a dropdown menu next to the build button. >> >> http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ >> >> Thanks, >> /Jesper >> >> >> Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the entire >>> OpenJDK project. To clarify: One project that contains the entire OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK is >>> fairly >>> fast and even though I personally mostly work in the HotSpot tree, I tend to >>> always clone and build the entire JDK forest. I find this to have several >>> benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and Solaris >>> configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I think a >>> change like this should go in. Let me know if you think something else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper > From mike.duigou at oracle.com Mon Apr 1 19:00:35 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 01 Apr 2013 19:00:35 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20130401190036.0E1F648505@hg.openjdk.java.net> Changeset: fc1e08c2bb27 Author: mduigou Date: 2013-04-01 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fc1e08c2bb27 8010267: Add test-clean for cleaning of testoutput directory from output directory. Add depedency on test-clean to clean Reviewed-by: mchung, tbell ! common/makefiles/Main.gmk Changeset: 26a4456cb19e Author: jgish Date: 2013-03-26 13:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/26a4456cb19e 8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied Summary: use hg export --git to produce proper patch file Reviewed-by: mduigou ! make/scripts/webrev.ksh From mike.duigou at oracle.com Mon Apr 1 19:15:59 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 01 Apr 2013 19:15:59 +0000 Subject: hg: jdk8/tl/jdk: 8010268: Remove dependence upon clean target from jdk/test/Makefile prep target Message-ID: <20130401191621.12C1C48506@hg.openjdk.java.net> Changeset: b590bd37a6d0 Author: mduigou Date: 2013-04-01 12:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b590bd37a6d0 8010268: Remove dependence upon clean target from jdk/test/Makefile prep target Reviewed-by: tbell, mchung ! test/Makefile From Alan.Bateman at oracle.com Mon Apr 1 19:28:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Apr 2013 20:28:59 +0100 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <51532DF4.9020701@oracle.com> References: <51532DF4.9020701@oracle.com> Message-ID: <5159DFFB.7080805@oracle.com> On 27/03/2013 17:35, Mandy Chung wrote: > This is the JDK change for JEP 176: JEP 176: Mechanical Checking of > Caller-Sensitive Methods [1]. Christian has posted the webrev for the > hotspot VM change a couple weeks ago [2]. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ > > While it touches many files, the fix is simple and straight-forward > for review. I went through the latest webrev.01 and this looks very good. I guess I was initially surprised to see @CS on some of the AccessController.doPrivileged methods as these usages aren't checked (although they are caller sensitive). Did you consider adding a constant, JVM_DEPTH (-1) or some name like that, to jvm.h for the depth parameter? I see Reflection.isCallerSensitive uses isExtClassLoader, we'll probably have to re-visit this in the future. Doug and Chris are on this list but might not have seen that this updates AtomicXXXXFieldUpdaters. They need to be aware of this for future merges. On the tests, does GetCallerClassTest really need to check the stack trace? It seems unnecessary. One thing on the shell test (I read exchange about jtreg boot class path support) is that it needs the GPL header. I was surprised to see CallerSensitiveFinder in the webrev and I'm curious how long it takes to run. -Alan. From mike.duigou at oracle.com Mon Apr 1 20:19:58 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 1 Apr 2013 13:19:58 -0700 Subject: RFR: JDK-8011187 : http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ Message-ID: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> Hello all; Another changeset for review in the series "JDK-8009683 Running regression tests with make". Many of the targets in jdk/test/Makefile are currently unused or were never used. These targets will be removed: perftest packtest vmsqe_* jck* I have checked with Kelky O'Hair and Kumar Srinivasan and received confirmation that they do not believe the targets are being used by anyone. A webrev of the removal: http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ Mike From dan.xu at oracle.com Mon Apr 1 22:16:57 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 01 Apr 2013 15:16:57 -0700 Subject: Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native Message-ID: <515A0759.5070602@oracle.com> Hi All, In this fix, I have updated files in JDK libraries to use @Native annotation instead of @GenerateNativeHeader to mark classes that contain no native methods but constants used by native codes. @GenerateNativeHeader was added earlier in the development for JDK8."This has proved problematic for some core classes with respect to Jigsaw, since the use of such an annotation creates a compile-time dependency from the base module to the module containing javax.tools, and the base module should not have any dependencies." After switching to @Native annotation, the dependency problem will be solved as java.lang.annotation.Native is in the proposed base module. In addition, the annotation has been refined not to be on the class level but on the constants themselves, which also makes the generated header files much cleaner. This effort is part of JDK-8000404. After jdk libraries uptaking the annotation changes, @GenerateNativeHeader annotation will be removed completely. CCC: http://ccc.us.oracle.com/8000404 webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ Thanks for your feedback! -Dan From mandy.chung at oracle.com Mon Apr 1 23:25:27 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 01 Apr 2013 16:25:27 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5159DFFB.7080805@oracle.com> References: <51532DF4.9020701@oracle.com> <5159DFFB.7080805@oracle.com> Message-ID: <515A1767.7000606@oracle.com> On 4/1/13 12:28 PM, Alan Bateman wrote: > On 27/03/2013 17:35, Mandy Chung wrote: >> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of >> Caller-Sensitive Methods [1]. Christian has posted the webrev for >> the hotspot VM change a couple weeks ago [2]. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ >> >> While it touches many files, the fix is simple and straight-forward >> for review. > I went through the latest webrev.01 and this looks very good. > > I guess I was initially surprised to see @CS on some of the > AccessController.doPrivileged methods as these usages aren't checked > (although they are caller sensitive). > These few methods are the special case that their usage are not checked. This raises a good point how we could enforce the check and whether it's appropriate to check in JVM_DoPrivileged. I will file a bug to follow up this separately if you are okay. > Did you consider adding a constant, JVM_DEPTH (-1) or some name like > that, to jvm.h for the depth parameter? Chris and I both agree it's a good thing to define this constant in jvm.h. I have made the change in the jdk side and will file a bug to update that in the hotspot repo. > > I see Reflection.isCallerSensitive uses isExtClassLoader, we'll > probably have to re-visit this in the future. > Yes. > Doug and Chris are on this list but might not have seen that this > updates AtomicXXXXFieldUpdaters. They need to be aware of this for > future merges. > > On the tests, does GetCallerClassTest really need to check the stack > trace? It seems unnecessary. > The stack trace check tries to catch if InternalError is thrown for other reason. Such regression might be rare but I prefer to perform an appropriate check while the test can reliably run. > One thing on the shell test (I read exchange about jtreg boot class > path support) is that it needs the GPL header. > Fixed. > I was surprised to see CallerSensitiveFinder in the webrev and I'm > curious how long it takes to run. > This is one discussion point I'd like to have. I was debating myself initially if this test should be enabled or not. What I found it takes 5-14 sec. Some sample timing on the jprt machines: linux_i586 jdk_lang took 14 mins and CallerSensitiveFinder took 8.5 sec macosx_x64 jdk_lang took 20.5 mins and CallerSensitiveFinder took 14.5 sec solaris_i586 jdk_lang took 15.5 mins and CallerSensitiveFinder took 10 sec windows_x64 jdk_lang took 16.5 mins and CallerSensitiveFinder took 10 sec We discussed tagging stress tests or long running tests so that they can be run on demand. I think this test would also be appropriate to be run in post-build hudson job, kind of tests. Mandy From john.r.rose at oracle.com Tue Apr 2 00:24:00 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 1 Apr 2013 17:24:00 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <51532DF4.9020701@oracle.com> References: <51532DF4.9020701@oracle.com> Message-ID: <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: > This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev for the hotspot VM change a couple weeks ago [2]. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ This is very good work. It makes certain aspects of the system much easier to understand. I have reviewed it all, with the following comments: The transform moves caller sensitivity into a clearly visible position. In many cases, the call to Reflection.getCallerClass now precedes the check of the security manager. For some customer codes, this may cause a performance regression, although it will probably be in the noise in most cases. If necessary, we can replace some uses of R.getCC() by something like (S.getSecurityManager() == null ? null : R.getCC()), recovering the original laziness of the stack check. This won't be necessary everywhere. Note that the server compiler can usually remove the stack walk. We may need to put something similar into the client compiler. In the case of the reflective calls (Field, Constructor, Method), the check of the caller class is gated by both AccessibleObject.override and quickCheckMemberAccess, and you have preserved this for Constructor and Method (which are probably the most important performance case). Consider gating it also for Field, as noted below. Per-file comments: -- Class.java (See below about checking for checkMemberAccess override.) -- ClassLoader.java Did you consider using Class.cast to get a runtime check instead of @SuppressWarnings("unchecked")? -- MethodHandleNatives.java Was this deletion intentional or was it something Eclipse or Netbeans did? -import static java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP; Good cleanups! You can remove this since rAPC is static (error in original code): case "registerAsParallelCapable": return canBeCalledVirtual(mem, java.lang.ClassLoader.class); Note that the subsequent call to canBeCalledVirtual will disqualify mem because it is static. -- MethodHandles.Lookup Now that stack walking is out of the picture, make all the constructors private, and remove this scary comment: > *

> * Also, don't make it private, lest javac interpose > * an access$N method. I like this comment, and the manual inlining technique (in this very special case): // Inlined SecurityManager.checkMemberAccess Since it tends to get lost in the previous comment block, I suggest you put it after the open brace of the inlined body. Also, both parameters should be inlined at the top of the block, not just "which", so the rest of the block can a more or less verbatim copy. + { // Inlined SecurityManager.checkMemberAccess + final Class clazz = refc/defc; + final int which = Member.PUBLIC/PRIVATE; As previously noted, smgr.getClass() == SecurityManager.class is too strict. Suggest hoisting the nasty logic into a boolean, and using it twice: boolean standardCMA = (smgr.getClass() == SecurityManager.class); if (!standardCMA) try { standardCMA = smgr.getClass().getDeclaredMethod("checkMemberAccess", ...).getDeclaringClass() == SecurityManager.class; } catch (ReflectiveOperationException ex) { throw new InternalError(ex); } if (standardCMA) { // // Inlined SecurityManager.checkMemberAccess final Class clazz = refc/defc; final int which = Member.PUBLIC/PRIVATE; ... } else { smgr.checkMemberAccess(...); } (And a similar comment for Class.java.) Lots of trouble for a corner case! -- Field.java Consider making R.getCC more lazy as follows: + return getFieldAccessor(obj, needsMemberAccessCheck() ? Reflection.getCallerClass() : clazz).get(obj); + private boolean needsMemberAccessCheck() { + return !override && !Reflection.quickCheckMemberAccess(clazz, modifiers); + } (This might affect the performance of serialization.) -- CallerSensitiveFinder.java This is a remarkable test. Does it statically determine whether the annotations are missing? Does it process all of rt.jar? How long does it take to complete? And (I have to ask, though I'm sure the answer will be yes) have you run it on broken inputs (such as boot.GetCallerClass.missingCallerSensitiveAnnotation) and verified that it barks at them? From mike.duigou at oracle.com Tue Apr 2 02:00:07 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 1 Apr 2013 19:00:07 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: Hello all; I have posted an updated version of the empty ArrayList and HashMap patch. http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. Mike On Mar 26 2013, at 17:25 , Mike Duigou wrote: > Hello all; > > This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. > > This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ > > We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. > > The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). > > Mike From mike.duigou at oracle.com Tue Apr 2 03:17:29 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 02 Apr 2013 03:17:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130402031813.776CC48519@hg.openjdk.java.net> Changeset: 0cccdb9a9a4c Author: mduigou Date: 2013-04-01 20:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c 7143928: Optimize empty HashMap and ArrayList Reviewed-by: mduigou Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/HashMap.java + test/java/util/Map/BasicSerialization.java Changeset: 5ee837ba093a Author: mduigou Date: 2013-04-01 20:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ee837ba093a 8011187: Remove obsolete/unused targets from jdk/test/Makefile Reviewed-by: ohair ! test/Makefile From Mike.Duigou at oracle.COM Tue Apr 2 03:43:25 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Mon, 1 Apr 2013 20:43:25 -0700 Subject: RFR : JDK-8011199 : Backout of JDK-7143928 Message-ID: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> Hello all; Unfortunately while pushing another changeset I accidentally pushed JDK-7143928 as well. Since the review is not complete (and sufficient testing has not been completed) this change needs to be backed out. I have created an "hg backout -r 0cccdb9a9a4c" changeset of http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c and would like to push it as JDK-8011199. I will create a new bug to complete the review of JDK-7143928 patch. If these proposed corrections seem reasonable I can proceed. I apologize for any inconvenience this error causes. Mike From david.holmes at oracle.com Tue Apr 2 04:02:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Apr 2013 14:02:49 +1000 Subject: RFR : JDK-8011199 : Backout of JDK-7143928 In-Reply-To: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> References: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> Message-ID: <515A5869.1000406@oracle.com> Hi Mike, I need to see the actual proposed changeset to Review it. Thanks, David On 2/04/2013 1:43 PM, Mike Duigou wrote: > Hello all; > > Unfortunately while pushing another changeset I accidentally pushed JDK-7143928 as well. Since the review is not complete (and sufficient testing has not been completed) this change needs to be backed out. > > I have created an "hg backout -r 0cccdb9a9a4c" changeset of http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c and would like to push it as JDK-8011199. I will create a new bug to complete the review of JDK-7143928 patch. > > If these proposed corrections seem reasonable I can proceed. I apologize for any inconvenience this error causes. > > Mike > From Mike.Duigou at oracle.com Tue Apr 2 04:08:11 2013 From: Mike.Duigou at oracle.com (Mike Duigou) Date: Mon, 1 Apr 2013 21:08:11 -0700 Subject: RFR : JDK-8011199 : Backout of JDK-7143928 In-Reply-To: <515A5869.1000406@oracle.com> References: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> <515A5869.1000406@oracle.com> Message-ID: <8A1B89F2-A4AE-4F6F-BA4D-C239B154769D@oracle.com> The changeset is now available as a webrev at: http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/ Thanks, Mike On Apr 1 2013, at 21:02 , David Holmes wrote: > Hi Mike, > > I need to see the actual proposed changeset to Review it. > > Thanks, > David > > On 2/04/2013 1:43 PM, Mike Duigou wrote: >> Hello all; >> >> Unfortunately while pushing another changeset I accidentally pushed JDK-7143928 as well. Since the review is not complete (and sufficient testing has not been completed) this change needs to be backed out. >> >> I have created an "hg backout -r 0cccdb9a9a4c" changeset of http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c and would like to push it as JDK-8011199. I will create a new bug to complete the review of JDK-7143928 patch. >> >> If these proposed corrections seem reasonable I can proceed. I apologize for any inconvenience this error causes. >> >> Mike >> From joe.darcy at oracle.com Tue Apr 2 04:10:22 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 01 Apr 2013 21:10:22 -0700 Subject: RFR : JDK-8011199 : Backout of JDK-7143928 In-Reply-To: <8A1B89F2-A4AE-4F6F-BA4D-C239B154769D@oracle.com> References: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> <515A5869.1000406@oracle.com> <8A1B89F2-A4AE-4F6F-BA4D-C239B154769D@oracle.com> Message-ID: <515A5A2E.2090305@oracle.com> Sounds like a reasonable plan to me; approved to go back. -Joe On 04/01/2013 09:08 PM, Mike Duigou wrote: > The changeset is now available as a webrev at: > > http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/ > > Thanks, > > Mike > > On Apr 1 2013, at 21:02 , David Holmes wrote: > >> Hi Mike, >> >> I need to see the actual proposed changeset to Review it. >> >> Thanks, >> David >> >> On 2/04/2013 1:43 PM, Mike Duigou wrote: >>> Hello all; >>> >>> Unfortunately while pushing another changeset I accidentally pushed JDK-7143928 as well. Since the review is not complete (and sufficient testing has not been completed) this change needs to be backed out. >>> >>> I have created an "hg backout -r 0cccdb9a9a4c" changeset of http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c and would like to push it as JDK-8011199. I will create a new bug to complete the review of JDK-7143928 patch. >>> >>> If these proposed corrections seem reasonable I can proceed. I apologize for any inconvenience this error causes. >>> >>> Mike >>> From mike.duigou at oracle.com Tue Apr 2 04:14:16 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 02 Apr 2013 04:14:16 +0000 Subject: hg: jdk8/tl: 8011178: improve common/bin/hgforest.sh python detection (MacOS) Message-ID: <20130402041417.22B3D4851A@hg.openjdk.java.net> Changeset: 760074bec012 Author: mduigou Date: 2013-04-01 21:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/760074bec012 8011178: improve common/bin/hgforest.sh python detection (MacOS) Reviewed-by: ohair ! common/bin/hgforest.sh From david.holmes at oracle.com Tue Apr 2 04:17:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Apr 2013 14:17:04 +1000 Subject: RFR : JDK-8011199 : Backout of JDK-7143928 In-Reply-To: <8A1B89F2-A4AE-4F6F-BA4D-C239B154769D@oracle.com> References: <329C9793-7053-4511-98CC-A467EF1B3C87@oracle.COM> <515A5869.1000406@oracle.com> <8A1B89F2-A4AE-4F6F-BA4D-C239B154769D@oracle.com> Message-ID: <515A5BC0.4030802@oracle.com> On 2/04/2013 2:08 PM, Mike Duigou wrote: > The changeset is now available as a webrev at: > > http://cr.openjdk.java.net/~mduigou/JDK-8011199/0/webrev/ Thanks Mike - looks like a clean reversal. Reviewed. David ----- > Thanks, > > Mike > > On Apr 1 2013, at 21:02 , David Holmes wrote: > >> Hi Mike, >> >> I need to see the actual proposed changeset to Review it. >> >> Thanks, >> David >> >> On 2/04/2013 1:43 PM, Mike Duigou wrote: >>> Hello all; >>> >>> Unfortunately while pushing another changeset I accidentally pushed JDK-7143928 as well. Since the review is not complete (and sufficient testing has not been completed) this change needs to be backed out. >>> >>> I have created an "hg backout -r 0cccdb9a9a4c" changeset of http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cccdb9a9a4c and would like to push it as JDK-8011199. I will create a new bug to complete the review of JDK-7143928 patch. >>> >>> If these proposed corrections seem reasonable I can proceed. I apologize for any inconvenience this error causes. >>> >>> Mike >>> > From mike.duigou at oracle.com Tue Apr 2 04:20:48 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 02 Apr 2013 04:20:48 +0000 Subject: hg: jdk8/tl/jdk: 8011199: Backout changeset JDK-7143928 (0cccdb9a9a4c) Message-ID: <20130402042108.134384851B@hg.openjdk.java.net> Changeset: de228734b742 Author: mduigou Date: 2013-04-01 20:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de228734b742 8011199: Backout changeset JDK-7143928 (0cccdb9a9a4c) Reviewed-by: darcy, dholmes ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/HashMap.java - test/java/util/Map/BasicSerialization.java From mike.duigou at oracle.com Tue Apr 2 04:44:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 1 Apr 2013 21:44:29 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Hello all; Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ It is currently unchanged from the last posted changeset for 7143928. Mike On Apr 1 2013, at 19:00 , Mike Duigou wrote: > Hello all; > > I have posted an updated version of the empty ArrayList and HashMap patch. > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ > > This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. > > For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. > > Mike > > On Mar 26 2013, at 17:25 , Mike Duigou wrote: > >> Hello all; >> >> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. >> >> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. >> >> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ >> >> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. >> >> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). >> >> Mike > From martinrb at google.com Tue Apr 2 05:24:28 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Apr 2013 22:24:28 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: Overall, this kind of change seems barely worth doing. --- This change: // Let gc do its work - for (int i = 0; i < size; i++) - elementData[i] = null; + Arrays.fill(elementData, null); changes the performance of clear from O(size) to O(capacity), which is bad, and unrelated to the "empty collection optimization". --- + if(elementData == EMPTY_ELEMENTDATA) { Please use standard jdk style - space after keywords such as "if". --- 183 public void ensureCapacity(int minCapacity) { 184 if (minCapacity > 0) 185 ensureExplicitCapacity(minCapacity); 186 } 187 188 private void ensureCapacityInternal(int minCapacity) { 189 if(elementData == EMPTY_ELEMENTDATA) { 190 minCapacity = Math.max(10, minCapacity); 191 } 192 193 ensureExplicitCapacity(minCapacity); 194 } It looks to me like, if the user does x = new ArrayList(); x.ensureCapacity(2); then the capacity will be 2, not 10, an observable change from the previous implementation, and sort-of contradicting the spec of ArrayList() --- 604 Arrays.fill(elementData, newSize, size, null); In performance-critical code I would avoid Arrays.fill because it adds a bit of overhead (unless it's intrinsified, which I don't think it is). --- If we are willing to make small incompatible changes, how about when serializing, storing capacity as the size, so that reconstituted ArrayLists are pre-trimmed to size? --- I still believe that with the help of the gc team, one can cook up a trim-to-size when gc-ing fix, but that's going to be very hard to implement. --- On Mon, Apr 1, 2013 at 7:00 PM, Mike Duigou wrote: > Hello all; > > I have posted an updated version of the empty ArrayList and HashMap patch. > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ > > This revised implementation introduces *no new fields* to either class. > For ArrayList the lazy allocation of the backing array occurs only if the > list is created at default size. According to our performance analysis > team, approximately 85% of ArrayList instances are created at default size > so this optimization will be valid for an overwhelming majority of cases. > > For HashMap, creative use is made of the threshold field to track the > requested initial size until the bucket array is needed. On the read side > the empty map case is tested with isEmpty(). On the write size a comparison > of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket > array. In readObject there's a little more work to try to choose an > efficient initial capacity. > > Mike > > On Mar 26 2013, at 17:25 , Mike Duigou wrote: > > > Hello all; > > > > This is a review for optimization work that came out of internal > analysis of Oracle's Java applications. It's based upon analysis that shows > that in large applications as much as 10% of maps and lists are initialized > but never receive any entries. A smaller number spend a large proportion of > their lifetime empty. We've found similar results across other workloads as > well. This patch is not a substitute for pre-sizing your collections and > maps--doing so will *always* have better results. > > > > This patch extends HashMap and ArrayList to provide special handling for > newly created instances that avoids creating the backing array until > needed. There is a very small additional cost for detecting when to inflate > the map or list that is measurable in interpreted tests but disappears in > JITed code. > > > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ > > > > We expect that should this code prove successful in Java 8 it will be > backported to Java 7 updates. > > > > The unit test may appear to be somewhat unrelated. It was created after > resolving a bug in an early version of this patch to detect the issue > encountered (LinkedHashMap.init() was not being called in readObject() when > the map was empty). > > > > Mike > > From bourges.laurent at gmail.com Tue Apr 2 07:27:01 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 2 Apr 2013 09:27:01 +0200 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: > --- > > 604 Arrays.fill(elementData, newSize, size, null); > > In performance-critical code I would avoid Arrays.fill because it adds a > bit of overhead (unless it's intrinsified, which I don't think it is). > Last week, I sent few benchmarks I did on array cleaning (zero fill) comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... Arrays.fill is the winner (always faster than arraycopy which use native code) by 10 - 20% ! I suspect aggressive hotspot optimizations (native code ?) because I agree Arrays.fill looks like a stupid for-loop ! Does somebody have clues explaining the Arrays.fill performance ? Is there an alternative way to clear an array giving the best possible performance (like c memset) ? it could be useful to have in JDK a native array fill implementation (System.fill ?) if it gives better performance. Laurent From Alan.Bateman at oracle.com Tue Apr 2 07:48:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 08:48:51 +0100 Subject: RFR: JDK-8011187 : http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ In-Reply-To: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> References: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> Message-ID: <515A8D63.3070703@oracle.com> On 01/04/2013 21:19, Mike Duigou wrote: > Hello all; > > Another changeset for review in the series "JDK-8009683 Running regression tests with make". Many of the targets in jdk/test/Makefile are currently unused or were never used. These targets will be removed: > > perftest > packtest > vmsqe_* > jck* > > I have checked with Kelky O'Hair and Kumar Srinivasan and received confirmation that they do not believe the targets are being used by anyone. A webrev of the removal: > > http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ > > Mike Looks fine to me too, I'm pretty sure these targets were never used after the initial experimentation that Kelly did. -Alan. From chris.hegarty at oracle.com Tue Apr 2 07:59:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 02 Apr 2013 08:59:22 +0100 Subject: RFR: JDK-8011187 : http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ In-Reply-To: <515A8D63.3070703@oracle.com> References: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> <515A8D63.3070703@oracle.com> Message-ID: <515A8FDA.5020407@oracle.com> Looks fine to me too. I remember being confused by these targets before, nice to see this clean up. -Chris On 04/02/2013 08:48 AM, Alan Bateman wrote: > On 01/04/2013 21:19, Mike Duigou wrote: >> Hello all; >> >> Another changeset for review in the series "JDK-8009683 Running >> regression tests with make". Many of the targets in jdk/test/Makefile >> are currently unused or were never used. These targets will be removed: >> >> perftest >> packtest >> vmsqe_* >> jck* >> >> I have checked with Kelky O'Hair and Kumar Srinivasan and received >> confirmation that they do not believe the targets are being used by >> anyone. A webrev of the removal: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ >> >> Mike > Looks fine to me too, I'm pretty sure these targets were never used > after the initial experimentation that Kelly did. > > -Alan. From Alan.Bateman at oracle.com Tue Apr 2 08:12:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 09:12:49 +0100 Subject: Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515A9301.7030800@oracle.com> On 01/04/2013 23:16, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for > JDK8."This has proved problematic for some core classes with respect > to Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In > addition, the annotation has been refined not to be on the class level > but on the constants themselves, which also makes the generated header > files much cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan This is great work - thank you for doing this. As the majority of the changed code is in the 2d/awt/client area then I hope that you will get timely reviews from those areas. The main thing with a change like this is that the changes build on all platforms and I've know you've verified that. I skimmed through the webrev and don't see anything obviously wrong. I focused mostly on the non-client code and they all look right. It's interesting that @GenerateNativeHeader was added to several classes with native methods, I don't know why that was the case. I was also unaware that we had Haskell code in the build. So thumbs up from me. I assume you or Jon will remove GenerateNativeHeader from the langtools repository once your changes are pushed. -Alan From paul.sandoz at oracle.com Tue Apr 2 08:23:46 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 2 Apr 2013 10:23:46 +0200 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: <5159B22C.7030000@oracle.com> References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> <5159B22C.7030000@oracle.com> Message-ID: Hi Alan, Thanks for taking a look. On Apr 1, 2013, at 6:13 PM, Alan Bateman wrote: > On 28/03/2013 15:59, Paul Sandoz wrote: >> Hi, >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096 >> >> Webrev: >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ >> >> Spec diff: >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff/overview-summary.html >> >> Relevant JavaDoc generated from lambda repo (required for viewing @apiNote, @implSpec, @implNote declarations): >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/ >> >> Note: some of the JavaDoc generated from the lambda repo may contain additional methods or specification that is relevant to the stream framework. >> > Just a few small comments from a quick pass over the webrev. > > The @return for the Array.spliterator methods reads "A spliterator from an array", maybe this should be "the array". > OK. > For Iterable.forEach (and the Spliterator methods that take a Consumer) then you might consider "Errors or runtime exceptions" rather than "Exceptions" so that it is clear that an Error thrown by the action's accept method will be propagated too. > I thought that might be redundant but there is sometimes confusion around what things can be thrown from methods that don't declare they throw anything so it is probably worth being explicit. > The class description for the PrimitiveIterator.OfXXX classes is the one-liner "Specialization for XXX elements". It might be nicer to have this as "A Spliterator specialized for XXX elements". > > Will you change the Tripwire utility class to use the platform logger before you push this? > Yes. > Another thing on Tripwire is that the property lookup will probably fail if the class is initalized with application code on the stack and there is a security manager set. I think this will need to be changed to get the property value in a privileged blocked. > Ah! > The copyright header on the tests is normally the GPL header (no "Classpath" exception). I assume you'll fix this before pushing. > OK, grr i always forget that (makes it harder to have an automated template in the IDE when creating a new class). > One question on the spliteratorDataProvider - what is the issue with IdentityHashMap or do we know yet? > I do not. I will need to update the equivalent test-ng test since the IdentityHashMap occasionally fails. (Keeping duplicates at the moment because it is very convenient to run the lambda test-ng tests.) Paul. From Alan.Bateman at oracle.com Tue Apr 2 08:27:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 09:27:19 +0100 Subject: Review JDK-8010837 - TEST_BUG: java/io/FileInputStream/LargeFileAvailable.java fails intermittently In-Reply-To: <51572752.8000208@oracle.com> References: <5151F719.6030503@oracle.com> <51571F99.8000103@oracle.com> <51572752.8000208@oracle.com> Message-ID: <515A9667.3070901@oracle.com> On 30/03/2013 17:56, Dan Xu wrote: > I see. So we will need clarify the spec and make corresponding > changes. I think as long as we don't trigger exceptions and just > return 0 will be backward-compatible, right? > > -Dan I've created 8011136 to track the issues. We need to be careful of course and work through the implications. I think for available() that returning 0 should be okay. The skip(negative) issue is harder as the long standing behavior is not unreasonable but it conflicts with the behavior specified by both InputStream.skip and FileInputStream.skip. -Alan. From staffan.larsen at oracle.com Tue Apr 2 08:33:19 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 02 Apr 2013 08:33:19 +0000 Subject: hg: jdk8/tl/jdk: 8009558: linked_md.c::dll_build_name can get stuck in an infinite loop Message-ID: <20130402083347.4586448521@hg.openjdk.java.net> Changeset: f1b89d4cce82 Author: sla Date: 2013-04-02 10:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1b89d4cce82 8009558: linked_md.c::dll_build_name can get stuck in an infinite loop Reviewed-by: alanb, sspitsyn ! src/share/back/export/sys.h ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_md.h ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c From pdoubleya at gmail.com Tue Apr 2 09:12:49 2013 From: pdoubleya at gmail.com (Patrick Wright) Date: Tue, 2 Apr 2013 11:12:49 +0200 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourg?s wrote: > > --- > > > > 604 Arrays.fill(elementData, newSize, size, null); > > > > In performance-critical code I would avoid Arrays.fill because it adds a > > bit of overhead (unless it's intrinsified, which I don't think it is). > > > > Last week, I sent few benchmarks I did on array cleaning (zero fill) > comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... > Arrays.fill is the winner (always faster than arraycopy which use native > code) by 10 - 20% ! > I suspect aggressive hotspot optimizations (native code ?) because I agree > Arrays.fill looks like a stupid for-loop ! > > Does somebody have clues explaining the Arrays.fill performance ? > There was at least one round of optimization done by the HotSpot team in mid-2010 - "This adds new logic to recognize fill idioms and convert them into a call to an optimized fill routine. Loop predication creates easily matched loops that are simply replaced with calls to the new assembly stubs. Currently only 1,2 and 4 byte primitive types are supported. Objects and longs/double will be supported in a later putback. Tested with runthese, nsk and ctw plus jbb2005. " see http://openjdk.5641.n7.nabble.com/review-M-for-4809552-Optimize-Arrays-fill-td10322.html Looks like the change was part of 6u23 http://download.java.net/jdk6/6u23/promoted/b03/changes/JDK6u23.b03.list.html Could not find anything more recent than that (on a quick mail search) Cheers Patrick From vicente.romero at oracle.com Tue Apr 2 09:53:46 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 02 Apr 2013 09:53:46 +0000 Subject: hg: jdk8/tl/langtools: 4965689: class literal code wastes a byte Message-ID: <20130402095356.8E89248524@hg.openjdk.java.net> Changeset: 29c6984a1673 Author: vromero Date: 2013-04-02 10:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/29c6984a1673 4965689: class literal code wastes a byte Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java + test/tools/javac/T4965689/ClassLiteralWastesByteTest.java From Alan.Bateman at oracle.com Tue Apr 2 11:07:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 12:07:43 +0100 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: <515ABBFF.80203@oracle.com> On 02/04/2013 05:44, Mike Duigou wrote: > Hello all; > > Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ > > It is currently unchanged from the last posted changeset for 7143928. > > Mike > I skimmed through the webrev as lazily creating the backing arrays will be help in some environments. For ArrayList then it might be good to add a constant DEFAULT_INITIAL_CAPACITY or some such to avoid repeating the specified default. I agree with Martin's comment that ArrayList.clear will now clear elementData.length elements rather than size so I assume you'll address that. I also agree with Martin on keeping the coding style consistent, particularly the missing space in "if(", and missing braces in places such as HashMap.writeObject. For ArrayList.readObject then you read the array length in as "initialCapacity" which I think is a bit confusing given the current semantics. An alternative is to just not change readObject unless there is evidence that it is common to reconstitute empty ArrayLists. For HashMap.indexFor then I assume this isn't an assert because it is used early in the VM startup. This should probably be changed to InternalError and the message needs to be changed too. Do you envisage usage of inflateTable in LinkedHashMap? I'm wondering why it isn't private. HashMap.writeObject - the update to the @serialData text will change the wording emitting in the javadoc. I mention this as I think you are planning to push this to jdk7u at some point. I don't have time to go through the test in detail at this time but it looks like it has the original bug number and I assume that will need to change now. -Alan. From anthony.petrov at oracle.com Tue Apr 2 12:07:38 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Apr 2013 16:07:38 +0400 Subject: Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515ACA0A.4000809@oracle.com> Hi Dan, Changes to awt code look fine to me. -- best regards, Anthony On 4/2/2013 2:16, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for JDK8. > "This has proved problematic for some core classes with respect to > Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In addition, > the annotation has been refined not to be on the class level but on the > constants themselves, which also makes the generated header files much > cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan From chris.hegarty at oracle.com Tue Apr 2 12:37:20 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 02 Apr 2013 13:37:20 +0100 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> Message-ID: <515AD100.5040103@oracle.com> Nice work Paul, some small comments. - new javadocs tags, @implSpec, @apiNote, etc. I really like the use of implSpec to define the behavior of this implementations default methods. There is probably a separate thread, but any idea when these will be generated in the javadoc, not just the lambda docs? - Iterator.remove @since 1.8? I see there is a conflict here between when the method was originally added and its default - Spliterator class level examples are not showing in the specdiff. Are these really API Notes? Maybe they are. -Chris. On 03/28/2013 03:59 PM, Paul Sandoz wrote: > Hi, > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010096 > > Webrev: > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ > > Spec diff: > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/specdiff/overview-summary.html > > Relevant JavaDoc generated from lambda repo (required for viewing @apiNote, @implSpec, @implNote declarations): > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/ > > Note: some of the JavaDoc generated from the lambda repo may contain additional methods or specification that is relevant to the stream framework. > > -- > > To enable bulk operations, in parallel, on a data source it is required that such a source efficiently partition itself into smaller parts, where parts are processed concurrently, and each part is traversed sequentially. > > A new data interface is required that defines the contract for efficient partitioning and traversal. > > Collections need to implement that new data interface so the JSR-335 stream library can support bulk operations on common collection implementations, such as List/Set and arrays, in addition to other forms of data source e.g. third party collections. > > java.util.Spliterator, and primitive specializations of, is the key data interface that enables partitioning and traversal. JSR-335 java.util.stream.Stream instances will be constructed from spliterators. > > Collection is extended to define the default method spliterator(). Implementations are expected to override this method. The default implementation utilizes the collection's iterator and size to provide a spliterator implementation that permits limited parallism. Default overriding implementations are also provided for List, Set and SortedSet that support additional properties associated with those collections. > > Together with Spliterator some implementations are provided for creating Spliterator instances from data sources that are iterators and arrays. > > Note: Optimal spliterator implementations for many collection implementations in java.util and java.util.concurrent are present in the lambda repository and will duly make their way into TL after this webrev has been reviewed and pushed. > > -- > > Once this webrev is reviewed and pushed then the Stream API can follow, and then the fun really begins :-) > > The class com.sun.tools.jdi/EventSetImpl has been modified but is likely to change when spliterator implementations are pushed. This class cannot decide if it wants to be a List or a Set!! The compiler cannot work out if the default implementation of spliterator() for List or Set should apply. When the concrete collection implementations of spliterator arrive this class will not need to implement spliterator() and will inherit the implementation from ArrayList (implementations on classes always win over default implementations on interfaces). > > Unfortunately to build TL with this patch applied requires one also apply: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fbcafacf92ef > > Which i suspect was lost in the wash and should have been pushed to TL a while ago. Will follow up with Robert on that one. > > A JPRT of TL with both patches applied did not show any abnormal test failures. > > Paul. > From Alan.Bateman at oracle.com Tue Apr 2 12:59:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 13:59:23 +0100 Subject: Review Request 8007035: Deprecate SecurityManager.checkMemberAccess In-Reply-To: <51550285.9050706@oracle.com> References: <51550285.9050706@oracle.com> Message-ID: <515AD62B.4030604@oracle.com> On 29/03/2013 02:55, Mandy Chung wrote: > Sean, John, Joe, > > Can you review this fix todeprecatesthe > |SecurityManager.checkMemberAccess| > method as proposed in http://openjdk.java.net/jeps/176? > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/webrev.00 > I went through the webrev except for the MethodHandles update and it mostly looks good to me. I agree that checkMemberAccess should be deprecated. In the @deprecated comment then it should probably say that it will be changed in the future to check AllPermission. It would be inconsistent to throw SecurityException for the fully trusted case. A minor comment checkMemberAccess L2064-2065 where it might be nicer as: if (while != Member.PUBLIC && ccl != ...). -Alan. From sundararajan.athijegannathan at oracle.com Tue Apr 2 13:22:08 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 02 Apr 2013 13:22:08 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130402132211.2FF5F4852C@hg.openjdk.java.net> Changeset: 3e4369fb810b Author: hannesw Date: 2013-04-02 13:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3e4369fb810b 8011219: Regression with recent PropertyMap history changes Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 5362d96d5915 Author: sundar Date: 2013-04-02 17:40 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5362d96d5915 8011209: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.length is not 0 Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + test/script/basic/JDK-8011209.js From paul.sandoz at oracle.com Tue Apr 2 13:34:06 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 2 Apr 2013 15:34:06 +0200 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: <515AD100.5040103@oracle.com> References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> <515AD100.5040103@oracle.com> Message-ID: On Apr 2, 2013, at 2:37 PM, Chris Hegarty wrote: > Nice work Paul, some small comments. > > - new javadocs tags, @implSpec, @apiNote, etc. I really like the use of > implSpec to define the behavior of this implementations default > methods. There is probably a separate thread, but any idea when these > will be generated in the javadoc, not just the lambda docs? > I do not know, Mike is the one who is very likely to know more. > - Iterator.remove @since 1.8? I see there is a conflict here between > when the method was originally added and its default > Right, that is most likely a mistake. How can we express that the default method is there since 1.8? > - Spliterator class level examples are not showing in the specdiff. > Are these really API Notes? Maybe they are. > The examples are non-normative so i think such docs can be categorized under @apiNote. See here for generated JavaDoc from the lambda repo: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/api/java/util/Spliterator.html Paul. From Alan.Bateman at oracle.com Tue Apr 2 14:39:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 15:39:08 +0100 Subject: Codereview Request for 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding In-Reply-To: <515370C1.3040104@oracle.com> References: <515370C1.3040104@oracle.com> Message-ID: <515AED8C.2090204@oracle.com> On 27/03/2013 22:20, Xueming Shen wrote: > Hi, > > Please help review the fix for the following two bugs: > > (1) 8007379: Base64.getMimeDecoder().decode() throws IAE for a > non-base64 character after padding > We fixed the similar issue in 8006530, it appears there is "yet > another" corner case > to close here. As described in the bug report, the calculation for > output buffer size > for such case is incorrect when decoding in mime mode. The proposed > change > should fix the problem. > > (2) 8008925: Base64.getMimeDecoder().decode() does not ignore padding > chars > The change is to clarify the specification that "the padding > character(s) is not > required for decoding. BUT, if the padding character(s) does appear, > they must > be correctly encoded." > > http://cr.openjdk.java.net/~sherman/8007379_8008925/webrev These corner cases are a pain. The implementation changes look fine to me. For the javadoc change then I suggest "But if" --> "If" "otherwise the IllegalArgumentException will be thrown" --> "otherwise {@code IllegalArgumentException} is thrown during decoding". -Alan. From Alan.Bateman at oracle.com Tue Apr 2 14:41:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 15:41:31 +0100 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515A1767.7000606@oracle.com> References: <51532DF4.9020701@oracle.com> <5159DFFB.7080805@oracle.com> <515A1767.7000606@oracle.com> Message-ID: <515AEE1B.6070405@oracle.com> On 02/04/2013 00:25, Mandy Chung wrote: > > These few methods are the special case that their usage are not > checked. This raises a good point how we could enforce the check and > whether it's appropriate to check in JVM_DoPrivileged. I will file a > bug to follow up this separately if you are okay. Thanks. > >> >> On the tests, does GetCallerClassTest really need to check the stack >> trace? It seems unnecessary. >> > > > The stack trace check tries to catch if InternalError is thrown for > other reason. Such regression might be rare but I prefer to perform > an appropriate check while the test can reliably run. Okay, my comment that mostly that this checking seem a bit over-the-top. > : > >> I was surprised to see CallerSensitiveFinder in the webrev and I'm >> curious how long it takes to run. >> > > This is one discussion point I'd like to have. I was debating myself > initially if this test should be enabled or not. What I found it > takes 5-14 sec. > Some sample timing on the jprt machines: > linux_i586 jdk_lang took 14 mins and CallerSensitiveFinder took 8.5 > sec > macosx_x64 jdk_lang took 20.5 mins and CallerSensitiveFinder took > 14.5 sec > solaris_i586 jdk_lang took 15.5 mins and CallerSensitiveFinder took > 10 sec > windows_x64 jdk_lang took 16.5 mins and CallerSensitiveFinder took > 10 sec > > We discussed tagging stress tests or long running tests so that they > can be run on demand. I think this test would also be appropriate to > be run in post-build hudson job, kind of tests. The duration is a lot less than I expected and I don't object to including it, it just seem more like something to run post-build as your suggest. -Alan. From xueming.shen at oracle.com Tue Apr 2 16:12:09 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 02 Apr 2013 09:12:09 -0700 Subject: Codereview Request for 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding In-Reply-To: <515AED8C.2090204@oracle.com> References: <515370C1.3040104@oracle.com> <515AED8C.2090204@oracle.com> Message-ID: <515B0359.5000404@oracle.com> Thanks Alan! Wording has been updated as suggested. http://cr.openjdk.java.net/~sherman/8007379_8008925/webrev/src/share/classes/java/util/Base64.java.sdiff.html -Sherman On 04/02/2013 07:39 AM, Alan Bateman wrote: > On 27/03/2013 22:20, Xueming Shen wrote: >> Hi, >> >> Please help review the fix for the following two bugs: >> >> (1) 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding >> We fixed the similar issue in 8006530, it appears there is "yet another" corner case >> to close here. As described in the bug report, the calculation for output buffer size >> for such case is incorrect when decoding in mime mode. The proposed change >> should fix the problem. >> >> (2) 8008925: Base64.getMimeDecoder().decode() does not ignore padding chars >> The change is to clarify the specification that "the padding character(s) is not >> required for decoding. BUT, if the padding character(s) does appear, they must >> be correctly encoded." >> >> http://cr.openjdk.java.net/~sherman/8007379_8008925/webrev > These corner cases are a pain. The implementation changes look fine to me. > > For the javadoc change then I suggest > > "But if" --> "If" > > "otherwise the IllegalArgumentException will be thrown" --> "otherwise {@code IllegalArgumentException} is thrown during decoding". > > -Alan. From mark.reinhold at oracle.com Tue Apr 2 17:16:40 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 02 Apr 2013 10:16:40 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <515ABBFF.80203@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com>, , <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com>, <515ABBFF.80203@oracle.com> Message-ID: <20130402101640.743746@eggemoggin.niobe.net> 2013/4/1 21:07 -0700, alan.bateman at oracle.com: > ... > > I also agree with Martin on keeping the coding style consistent, > particularly the missing space in "if(", and missing braces in places > such as HashMap.writeObject. On the topic of style, please also change private static final Object EMPTY_ELEMENTDATA[] = new Object[0]; to private static final Object[] EMPTY_ELEMENTDATA = new Object[0]; in HashMap.java. - Mark From xueming.shen at oracle.com Tue Apr 2 17:15:01 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 02 Apr 2013 17:15:01 +0000 Subject: hg: jdk8/tl/jdk: 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding; ... Message-ID: <20130402171523.B78214853D@hg.openjdk.java.net> Changeset: e6c3b8e74e50 Author: sherman Date: 2013-04-02 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6c3b8e74e50 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding 8008925: Base64.getMimeDecoder().decode() does not ignore padding chars Summary: updated implementation and spec for corner cases. Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From joe.darcy at oracle.com Tue Apr 2 17:33:46 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 02 Apr 2013 10:33:46 -0700 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> <515AD100.5040103@oracle.com> Message-ID: <515B167A.1070300@oracle.com> On 04/02/2013 06:34 AM, Paul Sandoz wrote: > On Apr 2, 2013, at 2:37 PM, Chris Hegarty wrote: >> Nice work Paul, some small comments. >> >> - new javadocs tags, @implSpec, @apiNote, etc. I really like the use of >> implSpec to define the behavior of this implementations default >> methods. There is probably a separate thread, but any idea when these >> will be generated in the javadoc, not just the lambda docs? >> > I do not know, Mike is the one who is very likely to know more. > > >> - Iterator.remove @since 1.8? I see there is a conflict here between >> when the method was originally added and its default >> > Right, that is most likely a mistake. How can we express that the default method is there since 1.8? > > That cannot the expressed in @since tags, but it is duly recorded by the JCK signature tests. There are other kinds of evolutions the @since tags cannot capture, such as a class being retrofitted to implement an interface in a release after the interface was added. -Joe From xueming.shen at oracle.com Tue Apr 2 17:52:15 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 02 Apr 2013 10:52:15 -0700 Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods In-Reply-To: <515317EB.8020207@oracle.com> References: <515317EB.8020207@oracle.com> Message-ID: <515B1ACF.705@oracle.com> Thanks Mark for looking into this issue. The change itself looks fine. Though I'm a little concerned whether the performance cost (need to do an additional linemax > 0 check inside the 'while" loop) is really worth it. Maybe an alternative is to simply set the linemax to -1 if it's 0? such as public static Encoder getEncoder(int lineLength, byte[] lineSeparator) { Objects.requireNonNull(lineSeparator); int[] base64 = Decoder.fromBase64; for (byte b : lineSeparator) { if (base64[b & 0xff] != -1) throw new IllegalArgumentException( "Illegal base64 line separator character 0x" + Integer.toString(b, 16)); } if (lineLength == 0) lineLength = -1; return new Encoder(false, lineSeparator, lineLength >> 2 << 2); } And given it actually become a "normal" RFC4648 if the lineLength <=0, maybe we should simply eliminate this "option" by changing the spec to say "throw IAE if lineLength <=0", go use BAse64.getEncoder() if lineSeparator is not needed. -Sherman On 03/27/2013 09:01 AM, Mark Sheppard wrote: > Hi, > please oblige and review the webrev below as a fix for the issue raised in JDK-8007799 > > http://cr.openjdk.java.net/~msheppar/8007799/webrev.00/ > > Description: > "Specification for the method > java.util.Base64.getEncoder(int lineLength, byte[] lineSeparator) > > says: > Parameters: > lineLength - the length of each output line (rounded down to nearest multiple of 4). If lineLength <= 0 the output will not be separated in lines > > However if a zero line length is specified encoding methods wrap() and encode(ByteBuffer src, ByteBuffer dst, int bytesOut) return encoded string which starts from the given line separator. " > > the patch adds a check for linemax > 0 whenever a line separator might be added, and adds an new test case. > > regards > Mark From martinrb at google.com Tue Apr 2 17:55:35 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 10:55:35 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: Thanks for the research. It seems like hotspot is recognizing and optimizing fill loops, rather than intrinsifying calls to Arrays.fill itself (good!). Anyways, I'd still like the "simple" fill loops in ArrayList to stay unchanged. Using Arrays.fill is only slightly more readable. There would be more of a case for fill if it was an actual array class instance method. On Tue, Apr 2, 2013 at 2:12 AM, Patrick Wright wrote: > On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourg?s > wrote: > > > > --- > > > > > > 604 Arrays.fill(elementData, newSize, size, null); > > > > > > In performance-critical code I would avoid Arrays.fill because it adds > a > > > bit of overhead (unless it's intrinsified, which I don't think it is). > > > > > > > Last week, I sent few benchmarks I did on array cleaning (zero fill) > > comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... > > Arrays.fill is the winner (always faster than arraycopy which use native > > code) by 10 - 20% ! > > I suspect aggressive hotspot optimizations (native code ?) because I > agree > > Arrays.fill looks like a stupid for-loop ! > > > > Does somebody have clues explaining the Arrays.fill performance ? > > > > There was at least one round of optimization done by the HotSpot team in > mid-2010 - > "This adds new logic to recognize fill idioms and convert them into a > call to an optimized fill routine. Loop predication creates easily > matched loops that are simply replaced with calls to the new assembly > stubs. Currently only 1,2 and 4 byte primitive types are supported. > Objects and longs/double will be supported in a later putback. Tested > with runthese, nsk and ctw plus jbb2005. " > > see > > http://openjdk.5641.n7.nabble.com/review-M-for-4809552-Optimize-Arrays-fill-td10322.html > > Looks like the change was part of 6u23 > > http://download.java.net/jdk6/6u23/promoted/b03/changes/JDK6u23.b03.list.html > > Could not find anything more recent than that (on a quick mail search) > > Cheers > Patrick > From mike.duigou at oracle.com Tue Apr 2 18:24:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 11:24:20 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: <468F37D2-BA43-46F8-86A9-DD9FB7469A07@oracle.com> On Apr 2 2013, at 10:55 , Martin Buchholz wrote: > Thanks for the research. > It seems like hotspot is recognizing and optimizing fill loops, rather than > intrinsifying calls to Arrays.fill itself (good!). Why wouldn't doing both be better? > Anyways, I'd still like the "simple" fill loops in ArrayList to stay > unchanged. Using Arrays.fill is only slightly more readable. Part of the goal of the change was to make the intent clearer. I'll improve the comments instead. > There would > be more of a case for fill if it was an actual array class instance method. Maybe for Java 9.... Mike > > > > On Tue, Apr 2, 2013 at 2:12 AM, Patrick Wright wrote: > >> On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourg?s >> wrote: >> >>>> --- >>>> >>>> 604 Arrays.fill(elementData, newSize, size, null); >>>> >>>> In performance-critical code I would avoid Arrays.fill because it adds >> a >>>> bit of overhead (unless it's intrinsified, which I don't think it is). >>>> >>> >>> Last week, I sent few benchmarks I did on array cleaning (zero fill) >>> comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... >>> Arrays.fill is the winner (always faster than arraycopy which use native >>> code) by 10 - 20% ! >>> I suspect aggressive hotspot optimizations (native code ?) because I >> agree >>> Arrays.fill looks like a stupid for-loop ! >>> >>> Does somebody have clues explaining the Arrays.fill performance ? >>> >> >> There was at least one round of optimization done by the HotSpot team in >> mid-2010 - >> "This adds new logic to recognize fill idioms and convert them into a >> call to an optimized fill routine. Loop predication creates easily >> matched loops that are simply replaced with calls to the new assembly >> stubs. Currently only 1,2 and 4 byte primitive types are supported. >> Objects and longs/double will be supported in a later putback. Tested >> with runthese, nsk and ctw plus jbb2005. " >> >> see >> >> http://openjdk.5641.n7.nabble.com/review-M-for-4809552-Optimize-Arrays-fill-td10322.html >> >> Looks like the change was part of 6u23 >> >> http://download.java.net/jdk6/6u23/promoted/b03/changes/JDK6u23.b03.list.html >> >> Could not find anything more recent than that (on a quick mail search) >> >> Cheers >> Patrick >> From martinrb at google.com Tue Apr 2 18:33:41 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 11:33:41 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <468F37D2-BA43-46F8-86A9-DD9FB7469A07@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <468F37D2-BA43-46F8-86A9-DD9FB7469A07@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 11:24 AM, Mike Duigou wrote: > > On Apr 2 2013, at 10:55 , Martin Buchholz wrote: > > > Thanks for the research. > > It seems like hotspot is recognizing and optimizing fill loops, rather > than > > intrinsifying calls to Arrays.fill itself (good!). > > Why wouldn't doing both be better? > > If hotspot recognizes and optimizes fill loops, Arrays.fill is optimized "for free". > > Anyways, I'd still like the "simple" fill loops in ArrayList to stay > > unchanged. Using Arrays.fill is only slightly more readable. > > Part of the goal of the change was to make the intent clearer. I'll > improve the comments instead. ArrayList is one of those classes that are important for educational reasons. Studying it will be part of many peoples' university education. So I applaud efforts to improve clarity. But I think the fill loops are sufficiently clear as they stand. From ivan.gerasimov at oracle.com Tue Apr 2 18:53:09 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 02 Apr 2013 22:53:09 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() Message-ID: <515B2915.60402@oracle.com> Hello everybody! Please review my proposal for the CopyOnWriteArrayList.addIfAbsent() method optimization. http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html Here is the original function body: ------------------------------------------------ Object[] elements = getArray(); int len = elements.length; Object[] newElements = new Object[len + 1]; <-- allocate new array in advance for (int i = 0; i < len; ++i) { if (eq(e, elements[i])) <-- check whether e is null on every iteration return false; // exit, throwing away copy else newElements[i] = elements[i]; <-- copy elements one by one } newElements[len] = e; setArray(newElements); ------------------------------------------------ The proposed change is to reuse CopyOnWriteArrayList.indexOf() function to check if e is already in the array. If the check passed, new array is allocated withArrays.copyOf(). It uses native System.arraycopy(), which is probably faster than copying elements in the loop. Sincerely yours, Ivan From martinrb at google.com Tue Apr 2 19:05:32 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 12:05:32 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B2915.60402@oracle.com> References: <515B2915.60402@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 11:53 AM, Ivan Gerasimov wrote: > Hello everybody! > > Please review my proposal for the CopyOnWriteArrayList.**addIfAbsent() > method optimization. > > http://washi.ru.oracle.com/~**igerasim/webrevs/8011215/**webrev/index.html This URL is not readable by external reviewers. The "master" version of CopyOnWriteArrayList is here: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup From mandy.chung at oracle.com Tue Apr 2 19:07:43 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 02 Apr 2013 12:07:43 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> Message-ID: <515B2C7F.1030508@oracle.com> On 4/1/13 5:24 PM, John Rose wrote: > On Mar 27, 2013, at 10:35 AM, Mandy Chung > wrote: > >> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of >> Caller-Sensitive Methods [1]. Christian has posted the webrev for >> the hotspot VM change a couple weeks ago [2]. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ >> > > This is very good work. It makes certain aspects of the system much > easier to understand. > > I have reviewed it all, with the following comments: > Thanks for the review. > The transform moves caller sensitivity into a clearly visible > position. In many cases, the call to Reflection.getCallerClass now > precedes the check of the security manager. For some customer codes, > this may cause a performance regression, although it will probably be > in the noise in most cases. Agree. I have restored the cases that should find caller class lazily. > If necessary, we can replace some uses of R.getCC() by something like > (S.getSecurityManager() == null ? null : R.getCC()), recovering the > original laziness of the stack check. This won't be necessary > everywhere. Note that the server compiler can usually remove the > stack walk. We may need to put something similar into the client > compiler. > > In the case of the reflective calls (Field, Constructor, Method), the > check of the caller class is gated by both AccessibleObject.override > and quickCheckMemberAccess, and you have preserved this for > Constructor and Method (which are probably the most important > performance case). Consider gating it also for Field, as noted below. > > Per-file comments: > > -- Class.java > > (See below about checking for checkMemberAccess override.) > Done. > -- ClassLoader.java > > Did you consider using Class.cast to get a runtime check instead of > @SuppressWarnings("unchecked")? > Good point - I have modified it to do runtime check using Class.asSubclass. > -- MethodHandleNatives.java > > Was this deletion intentional or was it something Eclipse or Netbeans did? > -import static java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP; > It was unintentional and I fixed it differently when I realized the reference of IMPL_LOOKUP. I now have restored to the original import static to be consistent with other files. > Good cleanups! > > You can remove this since rAPC is static (error in original code): > case "registerAsParallelCapable": > return canBeCalledVirtual(mem, java.lang.ClassLoader.class); > Done. > Note that the subsequent call to canBeCalledVirtual will disqualify > mem because it is static. > Yes. > -- MethodHandles.Lookup > > Now that stack walking is out of the picture, make all the > constructors private, and remove this scary comment: >> *

>> * Also, don't make it private, lest javac interpose >> * an access$N method. > Done. > I like this comment, and the manual inlining technique (in this very > special case): > // Inlined SecurityManager.checkMemberAccess > Since it tends to get lost in the previous comment block, I suggest > you put it after the open brace of the inlined body. > > Also, both parameters should be inlined at the top of the block, not > just "which", so the rest of the block can a more or less verbatim copy. > > + { // Inlined SecurityManager.checkMemberAccess > + final Class clazz = refc/defc; > + final int which = Member.PUBLIC/PRIVATE; > I considered that too and made the change. I actually took out the redundant check (which != PUBLIC) since we know the value. > As previously noted, smgr.getClass() == SecurityManager.class is too > strict. Suggest hoisting the nasty logic into a boolean, and using it > twice: > > boolean standardCMA = (smgr.getClass() == SecurityManager.class); > if (!standardCMA) try { > standardCMA = smgr.getClass().getDeclaredMethod("checkMemberAccess", > ...).getDeclaringClass() == SecurityManager.class; > } catch (ReflectiveOperationException ex) { throw new InternalError(ex); } > > if (standardCMA) { // // Inlined SecurityManager.checkMemberAccess > final Class clazz = refc/defc; > final int which = Member.PUBLIC/PRIVATE; > ... > } else { > smgr.checkMemberAccess(...); > } > OK. I modified a little. For subclass case, I can simply check if Class.getDeclaredMethod finds the method; if exists, it's overrided; otherwise, NoSuchMethodException thrown indicates using the standard one. > (And a similar comment for Class.java.) > Done. > Lots of trouble for a corner case! > > -- Field.java > > Consider making R.getCC more lazy as follows: > > + return getFieldAccessor(obj, needsMemberAccessCheck() ? > Reflection.getCallerClass() : clazz).get(obj); > > + private boolean needsMemberAccessCheck() { > + return !override && !Reflection.quickCheckMemberAccess(clazz, > modifiers); > + } > > (This might affect the performance of serialization.) > > > -- CallerSensitiveFinder.java > > This is a remarkable test. Does it statically determine whether the > annotations are missing? Yes - that's the purpose to catch if any use of Reflection.getCallerClass() but not missing @CS annotation. > Does it process all of rt.jar? How long does it take to complete? > It processes all JRE classes (i.e. rt.jar, jar files in JAVA_HOME/lib and JAVA_HOME/lib/ext). I have made it done the minimal necessary work only. It takes 6 seconds on my MacMini (2GHz core i7 and 8GB memory) to parse 24243 classes. It takes 5-14 seconds on the jprt machines and here are some sample timing: linux_i586 jdk_lang took 14 mins and CallerSensitiveFinder took 8.5 sec macosx_x64 jdk_lang took 20.5 mins and CallerSensitiveFinder took 14.5 sec solaris_i586 jdk_lang took 15.5 mins and CallerSensitiveFinder took 10 sec windows_x64 jdk_lang took 16.5 mins and CallerSensitiveFinder took 10 sec > And (I have to ask, though I'm sure the answer will be yes) have you > run it on broken inputs (such as > boot.GetCallerClass.missingCallerSensitiveAnnotation) and verified > that it barks at them? > I ran it on an older JDK that calls Reflection.getCallerClass(int) and no @sun.reflect.CallerSensitive exist. The test is currently tailored-made to only parses JRE classes. I can easily extend it to parse additional classes like boot.GetCallerClass that is a good test case to this tool itself. Will do so. I'll post a new webrev once I finish the testing. thanks for the detailed review. Mandy From mike.duigou at oracle.com Tue Apr 2 19:16:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 12:16:21 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: <4C5DB9CB-A716-492C-B9FB-B15D7DB05EB6@oracle.com> On Apr 1 2013, at 22:24 , Martin Buchholz wrote: (Other changes accepted as suggested) > If we are willing to make small incompatible changes, how about when serializing, storing capacity as the size, so that reconstituted ArrayLists are pre-trimmed to size? Yes, I found it strange that clone() returns a trimmed copy and serialization preserved capacity. Recording size as capacity would be a difference but not an incompatibility (objects serialized by both old and new implementations could be deserialized correctly by old and new). > --- > > I still believe that with the help of the gc team, one can cook up a trim-to-size when gc-ing fix, but that's going to be very hard to implement. I'm saving my VM RFEs for split arrays, huge arrays, sparse arrays and array pinning. :-) Mike > > --- > > > > > On Mon, Apr 1, 2013 at 7:00 PM, Mike Duigou wrote: > Hello all; > > I have posted an updated version of the empty ArrayList and HashMap patch. > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ > > This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. > > For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. > > Mike > > On Mar 26 2013, at 17:25 , Mike Duigou wrote: > > > Hello all; > > > > This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. > > > > This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. > > > > http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ > > > > We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. > > > > The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). > > > > Mike > > From mike.duigou at oracle.com Tue Apr 2 19:24:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 12:24:46 -0700 Subject: RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> Message-ID: <5AF7AEAD-8591-4595-B883-5BA50D43171D@oracle.com> Thanks for the pointer. I had remembered reading this changeset and it has motivated to use Arrays.fill but I could not have found it. Mike On Apr 2 2013, at 02:12 , Patrick Wright wrote: > On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourg?s > wrote: > >>> --- >>> >>> 604 Arrays.fill(elementData, newSize, size, null); >>> >>> In performance-critical code I would avoid Arrays.fill because it adds a >>> bit of overhead (unless it's intrinsified, which I don't think it is). >>> >> >> Last week, I sent few benchmarks I did on array cleaning (zero fill) >> comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... >> Arrays.fill is the winner (always faster than arraycopy which use native >> code) by 10 - 20% ! >> I suspect aggressive hotspot optimizations (native code ?) because I agree >> Arrays.fill looks like a stupid for-loop ! >> >> Does somebody have clues explaining the Arrays.fill performance ? >> > > There was at least one round of optimization done by the HotSpot team in > mid-2010 - > "This adds new logic to recognize fill idioms and convert them into a > call to an optimized fill routine. Loop predication creates easily > matched loops that are simply replaced with calls to the new assembly > stubs. Currently only 1,2 and 4 byte primitive types are supported. > Objects and longs/double will be supported in a later putback. Tested > with runthese, nsk and ctw plus jbb2005. " > > see > http://openjdk.5641.n7.nabble.com/review-M-for-4809552-Optimize-Arrays-fill-td10322.html > > Looks like the change was part of 6u23 > http://download.java.net/jdk6/6u23/promoted/b03/changes/JDK6u23.b03.list.html > > Could not find anything more recent than that (on a quick mail search) > > Cheers > Patrick From philip.race at oracle.com Tue Apr 2 19:37:05 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 02 Apr 2013 12:37:05 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515B3361.6080503@oracle.com> The addition of @Native to various lines in SunGraphics2D.java look to have pushed them >80 chars and it looks to me as if previously the author took some care to limit it. Moreover the indentation of the comment block `on lines 127-130 is no longer aligned. Maybe it would be easier for that case to put the annotation on the line above as in @Native static final int FOO ... Otherwise looks OK, looks like you found files that had @GenerateNativeHeaders that didn't need it and cleaned those up, and in native sources removed unneeded header file imports too. I do have a background question about how it works. There is an implication here that only the constants with @native might be included in generated header files. Is that true ? Whereas if a class has native method declarations, then it doesn't need these annotations, but you get all constants in the header file. Is that right ? -phil. On 4/1/13 3:16 PM, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for > JDK8."This has proved problematic for some core classes with respect > to Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In > addition, the annotation has been refined not to be on the class level > but on the constants themselves, which also makes the generated header > files much cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan From mike.duigou at oracle.com Tue Apr 2 20:20:28 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 13:20:28 -0700 Subject: RFR JDK-8010096 : Initial java.util.Spliterator putback In-Reply-To: <515B167A.1070300@oracle.com> References: <09A8DF98-6FF6-452E-8150-E86D9113E580@oracle.com> <515AD100.5040103@oracle.com> <515B167A.1070300@oracle.com> Message-ID: <92EB3451-309B-4AD8-BD68-DC1DEAB081C5@oracle.com> On Apr 2 2013, at 10:33 , Joe Darcy wrote: > On 04/02/2013 06:34 AM, Paul Sandoz wrote: >> On Apr 2, 2013, at 2:37 PM, Chris Hegarty wrote: >>> Nice work Paul, some small comments. >>> >>> - new javadocs tags, @implSpec, @apiNote, etc. I really like the use of >>> implSpec to define the behavior of this implementations default >>> methods. There is probably a separate thread, but any idea when these >>> will be generated in the javadoc, not just the lambda docs? >>> >> I do not know, Mike is the one who is very likely to know more. I am waiting for resolution of "JDK-8008768 : Using {@inheritDoc} in simple tag defined via -tag fails" to move forward with this. Mike From ivan.gerasimov at oracle.com Tue Apr 2 20:38:02 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 00:38:02 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> Message-ID: <515B41AA.3040703@oracle.com> > Please review my proposal for the > CopyOnWriteArrayList.addIfAbsent() method optimization. > > http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html > > > > This URL is not readable by external reviewers. The webrev has been copied here: http://cr.openjdk.java.net/~coffeys/webrev.8011215.ivan/ > The "master" version of CopyOnWriteArrayList is here: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup > Thanks for the link! I see that the code in the master version is identical to the one I've been working on. So the optimization still could be applied. Sincerely, Ivan From martinrb at google.com Tue Apr 2 20:55:21 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 13:55:21 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B41AA.3040703@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> Message-ID: Thanks for this change. There is a tradeoff here. If the element is never present, then the older code might be a little faster, because we can avoid re-traversing the array. Otherwise, the new code is better. I prefer it your way (I hate unneeded allocation), but the code was intentionally written the other way. Let's hear from Doug... Martin On Tue, Apr 2, 2013 at 1:38 PM, Ivan Gerasimov wrote: > > Please review my proposal for the CopyOnWriteArrayList.addIfAbsent() >> method optimization. >> >> http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html > > > This URL is not readable by external reviewers. > > > The webrev has been copied here: > http://cr.openjdk.java.net/~coffeys/webrev.8011215.ivan/ > > > The "master" version of CopyOnWriteArrayList is here: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup > > Thanks for the link! > I see that the code in the master version is identical to the one I've > been working on. > So the optimization still could be applied. > > Sincerely, > Ivan > From lana.steuck at oracle.com Tue Apr 2 20:59:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:36 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20130402205937.7BC784854F@hg.openjdk.java.net> Changeset: e2057191f6da Author: omajid Date: 2013-03-18 10:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e2057191f6da 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: 29153d0df68f Author: omajid Date: 2013-03-19 11:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/29153d0df68f 8010277: Configure doesn't fail when Xrender.h is missing Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 466685ba01bf Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/466685ba01bf Added tag jdk8-b82 for changeset 29153d0df68f ! .hgtags Changeset: d409b4cdb74f Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d409b4cdb74f Added tag jdk8-b83 for changeset 466685ba01bf ! .hgtags Changeset: 477d18509ecb Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/477d18509ecb Merge Changeset: a1bb1a0df1fa Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a1bb1a0df1fa Merge Changeset: bcbdbcfe7ed8 Author: lana Date: 2013-04-02 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bcbdbcfe7ed8 Merge From lana.steuck at oracle.com Tue Apr 2 20:59:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:39 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20130402205945.DDEE748550@hg.openjdk.java.net> Changeset: a45bb25a67c7 Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags Changeset: 14f1babaf548 Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/14f1babaf548 Added tag jdk8-b83 for changeset a45bb25a67c7 ! .hgtags Changeset: 7d7a009d5fbd Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7d7a009d5fbd Merge Changeset: 928f8b888deb Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/928f8b888deb Merge From lana.steuck at oracle.com Tue Apr 2 20:59:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:45 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130402205955.249BF48551@hg.openjdk.java.net> Changeset: a46d69a1a8ec Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a46d69a1a8ec Added tag jdk8-b82 for changeset d5a58291f09a ! .hgtags Changeset: f5f40094ffcc Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f5f40094ffcc Added tag jdk8-b83 for changeset a46d69a1a8ec ! .hgtags From lana.steuck at oracle.com Tue Apr 2 20:59:48 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:48 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20130402205955.88ADE48552@hg.openjdk.java.net> Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags Changeset: fbbdef940138 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fbbdef940138 Added tag jdk8-b83 for changeset 053d7c55dc82 ! .hgtags Changeset: db8a33cb22b8 Author: lana Date: 2013-03-26 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/db8a33cb22b8 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 999cc1bf5520 Author: lana Date: 2013-04-01 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/999cc1bf5520 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 9b845033c888 Author: lana Date: 2013-04-02 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9b845033c888 Merge From lana.steuck at oracle.com Tue Apr 2 20:59:48 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:48 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20130402210001.4E26748553@hg.openjdk.java.net> Changeset: a1dcc0d83da1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a1dcc0d83da1 Added tag jdk8-b82 for changeset d8d8032d02d7 ! .hgtags Changeset: 54c29eb352e7 Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/54c29eb352e7 Added tag jdk8-b83 for changeset a1dcc0d83da1 ! .hgtags Changeset: 2476e1f2afa5 Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2476e1f2afa5 Merge Changeset: 5773e3fc8380 Author: lana Date: 2013-04-01 21:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5773e3fc8380 Merge From lana.steuck at oracle.com Tue Apr 2 21:00:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 21:00:01 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130402210020.C46F748554@hg.openjdk.java.net> Changeset: 22ba3f92d4ae Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags Changeset: 35cef52b0023 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/35cef52b0023 Added tag jdk8-b83 for changeset 22ba3f92d4ae ! .hgtags Changeset: 28e466e9cd34 Author: lana Date: 2013-03-26 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/28e466e9cd34 Merge - src/share/classes/com/sun/tools/javac/Server.java - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties - src/share/classes/javax/lang/model/type/AnnotatedType.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: cfb65ca92082 Author: lana Date: 2013-04-01 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfb65ca92082 Merge - src/share/classes/com/sun/tools/javac/Server.java - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties - src/share/classes/javax/lang/model/type/AnnotatedType.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: 46d2f144ebbd Author: lana Date: 2013-04-02 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46d2f144ebbd Merge From lana.steuck at oracle.com Tue Apr 2 20:59:59 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 20:59:59 +0000 Subject: hg: jdk8/tl/hotspot: 53 new changesets Message-ID: <20130402210214.7FD7848555@hg.openjdk.java.net> Changeset: 4f7380dca47e Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: 7ae04e71af90 Author: amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 39432a1cefdd Author: minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author: coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author: zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author: zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author: dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author: sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author: sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/686916dc0439 8009457: SA: A small fix on "scanoops" command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java Changeset: 9960dce2024f Author: kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author: kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author: morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b4ce9870fd6 8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp Summary: add guarantee() to add_generation_memory_pool() Reviewed-by: kvn, twisti ! src/share/vm/services/memoryService.cpp Changeset: 0a2deac0bbfb Author: morris Date: 2013-03-16 07:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a2deac0bbfb 8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp Summary: add guarantee() to oop_result inlines Reviewed-by: kvn, twisti ! src/cpu/x86/vm/frame_x86.inline.hpp Changeset: 9ef47379df20 Author: morris Date: 2013-03-16 07:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ef47379df20 8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Summary: add null check to signal handler Reviewed-by: dcubed ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 8552f0992748 Author: kmo Date: 2013-03-15 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8552f0992748 8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers Reviewed-by: coleenp, roland Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java Changeset: 592f9722c72e Author: kmo Date: 2013-03-16 21:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/592f9722c72e Merge Changeset: 4efac99a998b Author: iignatyev Date: 2013-03-18 04:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4efac99a998b 8008211: Some of WB tests on compiler fail Reviewed-by: kvn, vlivanov ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: a5de0cc2f91c Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5de0cc2f91c 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 578d9044c463 Author: roland Date: 2013-03-18 09:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/578d9044c463 Merge Changeset: be4d5c6c1f79 Author: neliasso Date: 2013-03-19 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be4d5c6c1f79 8010121: Remove definition of ShouldNotReachHere2(msg) Reviewed-by: kvn, stefank, rbackman, twisti Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: f15df3af32c5 Author: morris Date: 2013-03-19 07:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f15df3af32c5 8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp Summary: add guarantee() to DoScheduling() Reviewed-by: twisti, kvn ! src/share/vm/opto/output.cpp Changeset: 75a28f465a12 Author: morris Date: 2013-03-19 07:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75a28f465a12 8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: add NULL checks for compiler name Reviewed-by: twisti, kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 80208f353616 Author: kvn Date: 2013-03-19 10:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80208f353616 8010222: 8007439 disabled inlining of cold accessor methods Summary: added missing parenthesis Reviewed-by: jrose ! src/share/vm/opto/bytecodeInfo.cpp Changeset: 2eef6d34833b Author: morris Date: 2013-03-19 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2eef6d34833b 8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp Summary: add guarantee() checks to merge_state_into_bb() Reviewed-by: kvn ! src/share/vm/oops/generateOopMap.cpp Changeset: 3b9368710f08 Author: morris Date: 2013-03-19 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b9368710f08 8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp Summary: add guarantee() checks Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 1275835a4ccc Author: morris Date: 2013-03-19 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1275835a4ccc Merge Changeset: 41340544e182 Author: morris Date: 2013-03-20 06:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41340544e182 8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp Summary: add guarantee() to set_to_interpreted() Reviewed-by: kvn ! src/share/vm/code/compiledIC.cpp Changeset: 2dec1d9bfbe1 Author: morris Date: 2013-03-20 06:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dec1d9bfbe1 8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp Summary: add guarantee() to get_instance_klass_for_declared_method_holder() Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp Changeset: 653d0346aa80 Author: morris Date: 2013-03-20 06:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/653d0346aa80 8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp Summary: add guarantee() to disqualify_method() Reviewed-by: kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: a59625d96f71 Author: morris Date: 2013-03-20 07:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a59625d96f71 8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp Summary: add guarantee() to insert_pre_post_loops() Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 98f3af397705 Author: twisti Date: 2013-03-20 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98f3af397705 8006965: remove test_gamma and add dedicated test_* targets instead Reviewed-by: kvn, jcoomes ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make - make/test/Queens.java Changeset: 589aa23334ea Author: morris Date: 2013-03-21 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/589aa23334ea 8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp Summary: added guarantee() to pd_address_in_code() Reviewed-by: kvn ! src/cpu/x86/vm/relocInfo_x86.cpp Changeset: c3c64a973559 Author: morris Date: 2013-03-21 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3c64a973559 8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp Summary: added guarantee() to print_entry_on() Reviewed-by: kvn ! src/share/vm/oops/constantPool.cpp Changeset: 3536ea6bc4df Author: morris Date: 2013-03-21 21:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3536ea6bc4df Merge - make/test/Queens.java Changeset: 79af1312fc2c Author: mgerdin Date: 2013-03-14 10:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79af1312fc2c 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap Reviewed-by: jmasa, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp Changeset: 3c226052f7dc Author: tschatzl Date: 2013-03-14 09:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c226052f7dc 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Summary: Use the correct collector to retrieve accumulated gen1 trace time Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp Changeset: 19f9fabd94cc Author: stefank Date: 2013-03-18 09:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19f9fabd94cc Merge ! src/share/vm/memory/metaspace.cpp Changeset: fa08949fe0cb Author: johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: e864cc14ca75 Author: johnc Date: 2013-03-19 00:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e864cc14ca75 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 1179172e9ec9 Author: johnc Date: 2013-03-19 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1179172e9ec9 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 7f0cb32dd233 Author: mgerdin Date: 2013-03-21 09:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f0cb32dd233 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity" Reviewed-by: jmasa, johnc ! src/share/vm/memory/metaspace.cpp Changeset: 47902e9acb3a Author: stefank Date: 2013-03-22 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/47902e9acb3a Merge ! src/share/vm/memory/metaspace.cpp Changeset: 5855e849c7e6 Author: stefank Date: 2013-03-22 12:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5855e849c7e6 Merge Changeset: 499ccc15bbc8 Author: bpittore Date: 2013-03-15 15:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/499ccc15bbc8 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp Changeset: 9e62e72c59cc Author: bobv Date: 2013-03-17 06:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e62e72c59cc Merge Changeset: 3be6a41ad358 Author: dholmes Date: 2013-03-18 19:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3be6a41ad358 8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: twisti, collins, bobv, jwilhelm ! make/jprt.properties Changeset: 804663118c1f Author: jprovino Date: 2013-03-22 10:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/804663118c1f Merge Changeset: aca25026e2a4 Author: vladidan Date: 2013-03-22 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aca25026e2a4 Merge Changeset: e3a41fc02348 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3a41fc02348 Merge - make/test/Queens.java Changeset: 1c8db54ee9f3 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c8db54ee9f3 Added tag hs25-b24 for changeset e3a41fc02348 ! .hgtags Changeset: e614fc564ded Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e614fc564ded Added tag jdk8-b83 for changeset 1c8db54ee9f3 ! .hgtags From lana.steuck at oracle.com Tue Apr 2 21:01:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 02 Apr 2013 21:01:15 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20130402210528.BEE2748556@hg.openjdk.java.net> Changeset: 624bcb480006 Author: omajid Date: 2013-03-18 10:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624bcb480006 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: cdcd4512c6f1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdcd4512c6f1 Added tag jdk8-b82 for changeset 624bcb480006 ! .hgtags Changeset: 6782f2c46bca Author: wetmore Date: 2013-03-21 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6782f2c46bca 8009517: new code changes causing errors in old build (-Werror) environment Reviewed-by: mduigou ! make/com/sun/org/apache/xml/Makefile ! make/javax/others/Makefile Changeset: ac519af51769 Author: dcherepanov Date: 2013-03-27 08:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac519af51769 Merge Changeset: 8cc500af2454 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cc500af2454 Added tag jdk8-b83 for changeset ac519af51769 ! .hgtags Changeset: 07acfb90700b Author: malenkov Date: 2013-03-14 12:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07acfb90700b 8000183: 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch, serb ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: d4e1c5803a59 Author: alexsch Date: 2013-03-15 17:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4e1c5803a59 8009221: [macosx] Two closed/javax/swing regression tests fail on MacOSX. Reviewed-by: serb, alexp + test/javax/swing/JMenu/4515762/bug4515762.java + test/javax/swing/JRootPane/4670486/bug4670486.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 2725b8a783e7 Author: lana Date: 2013-03-15 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2725b8a783e7 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: 4bf5a5a72664 Author: serb Date: 2013-03-18 22:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bf5a5a72664 8000435: [macosx] Button painting error under Java 7 on Mac Reviewed-by: denis, alexsch ! src/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java Changeset: af6049edac00 Author: kshefov Date: 2013-03-19 17:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af6049edac00 8009881: TEST_BUG: javax/swing/JTree/8004298/bug8004298.java should be modified Reviewed-by: serb, alexsch ! test/javax/swing/JTree/8004298/bug8004298.java Changeset: 4e15c3e56315 Author: kshefov Date: 2013-03-20 14:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e15c3e56315 8009880: TEST_BUG: Test java/beans/Introspector/TestTypeResolver.java should be modified again Reviewed-by: malenkov, alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 87001c7bb678 Author: alitvinov Date: 2013-03-20 20:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87001c7bb678 6550588: java.awt.Desktop cannot open file with Windows UNC filename Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WDesktopPeer.java ! src/windows/native/sun/windows/awt_Desktop.cpp + test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java Changeset: ef948ef2b58f Author: alexsch Date: 2013-03-21 16:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef948ef2b58f 8007146: [macosx] Setting a display mode crashes JDK under VNC Reviewed-by: serb ! src/macosx/native/sun/awt/CGraphicsDevice.m + test/java/awt/GraphicsDevice/CheckDisplayModes.java Changeset: a275acd8bcae Author: denis Date: 2013-03-22 19:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a275acd8bcae 7123476: DesktopOpenTests:When enter the file path and click the open button,it crash Reviewed-by: art, anthony ! make/sun/xawt/FILES_c_unix.gmk ! makefiles/CompileNativeLibraries.gmk ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c + src/solaris/native/sun/xawt/gnome_interface.c + src/solaris/native/sun/xawt/gnome_interface.h Changeset: 15a2599f470f Author: lana Date: 2013-03-26 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15a2599f470f Merge ! makefiles/CompileNativeLibraries.gmk Changeset: 543d0fbc962e Author: lana Date: 2013-03-26 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/543d0fbc962e Merge - make/com/sun/servicetag/Makefile ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/sun/tools/jstat/gcPermCapacityOutput1.awk - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh Changeset: ea7d0f49e5dd Author: lana Date: 2013-04-01 21:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea7d0f49e5dd Merge - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/sun/tools/jstat/gcPermCapacityOutput1.awk - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh Changeset: 7fbae9125437 Author: lana Date: 2013-04-02 11:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fbae9125437 Merge From ivan.gerasimov at oracle.com Tue Apr 2 21:11:58 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 01:11:58 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> Message-ID: <515B499E.3090401@oracle.com> > Thanks for this change. There is a tradeoff here. If the element is > never present, then the older code might be a little faster, because > we can avoid re-traversing the array. Otherwise, the new code is better. I've done a little testing on my side. I used Integer as an underlying type and set length of the array to the values from 1 to 100. My code shows a little performance gain - approximately 9%. I understand it may not be there for all cases, but at least for some cases it is there. > I prefer it your way (I hate unneeded allocation), but the code was > intentionally written the other way. Let's hear from Doug... > > Martin > > > On Tue, Apr 2, 2013 at 1:38 PM, Ivan Gerasimov > > wrote: > > >> Please review my proposal for the >> CopyOnWriteArrayList.addIfAbsent() method optimization. >> >> http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html >> >> >> >> This URL is not readable by external reviewers. > > The webrev has been copied here: > http://cr.openjdk.java.net/~coffeys/webrev.8011215.ivan/ > > > >> The "master" version of CopyOnWriteArrayList is here: >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup >> > Thanks for the link! > I see that the code in the master version is identical to the one > I've been working on. > So the optimization still could be applied. > > Sincerely, > Ivan > > From Ulf.Zibis at CoSoCo.de Tue Apr 2 21:17:25 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 02 Apr 2013 23:17:25 +0200 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B499E.3090401@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> Message-ID: <515B4AE5.4060104@CoSoCo.de> Hi, maybe the old code wins for looong arrays, so there could be a threshold to decide between old and new code: -Ulf Am 02.04.2013 23:11, schrieb Ivan Gerasimov: > >> Thanks for this change. There is a tradeoff here. If the element is never present, then the >> older code might be a little faster, because we can avoid re-traversing the array. Otherwise, >> the new code is better. > > I've done a little testing on my side. > I used Integer as an underlying type and set length of the array to the values from 1 to 100. > My code shows a little performance gain - approximately 9%. > I understand it may not be there for all cases, but at least for some cases it is there. > >> I prefer it your way (I hate unneeded allocation), but the code was intentionally written the >> other way. Let's hear from Doug... >> >> Martin >> >> >> On Tue, Apr 2, 2013 at 1:38 PM, Ivan Gerasimov > > wrote: >> >> >>> Please review my proposal for the >>> CopyOnWriteArrayList.addIfAbsent() method optimization. >>> >>> http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html >>> >>> >>> >>> This URL is not readable by external reviewers. >> >> The webrev has been copied here: >> http://cr.openjdk.java.net/~coffeys/webrev.8011215.ivan/ >> >> >> >>> The "master" version of CopyOnWriteArrayList is here: >>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup >>> >> Thanks for the link! >> I see that the code in the master version is identical to the one >> I've been working on. >> So the optimization still could be applied. >> >> Sincerely, >> Ivan >> >> > > From martinrb at google.com Tue Apr 2 21:17:25 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 14:17:25 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B499E.3090401@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> Message-ID: Have you benchmarked the case where the element is never present? (with the usual caveats about micro-benchmarking - perhaps use google caliper?) On Tue, Apr 2, 2013 at 2:11 PM, Ivan Gerasimov wrote: > > I've done a little testing on my side. > I used Integer as an underlying type and set length of the array to the > values from 1 to 100. > My code shows a little performance gain - approximately 9%. > I understand it may not be there for all cases, but at least for some > cases it is there. > > From ivan.gerasimov at oracle.com Tue Apr 2 21:34:50 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 01:34:50 +0400 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> Message-ID: <515B4EFA.9030207@oracle.com> Thank you Stanimir! My main goal was to get rid of early and possibly unneeded memory allocation. I thought that System.arraycopy() would somehow compensate the need to traverse the array twice. However testing shows that my code works a bit faster at least when dealing with Integer arrays of size from 1 to 100. Sincerely, Ivan On 02.04.2013 23:25, Stanimir Simeonoff wrote: > The current version is cache oblivious. In any case for smaller arrays > (like COW) System.arrayCopy won't yield any noticeable difference. > Also, iirc System.arrayCopy places a memory barrier which in the COW > case is unneeded. > > Stanimir > > > On Tue, Apr 2, 2013 at 9:53 PM, Ivan Gerasimov > > wrote: > > Hello everybody! > > Please review my proposal for the > CopyOnWriteArrayList.addIfAbsent() method optimization. > > http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html > > > Here is the original function body: > ------------------------------------------------ > Object[] elements = getArray(); > int len = elements.length; > Object[] newElements = new Object[len + 1]; <-- allocate new > array in advance > for (int i = 0; i < len; ++i) { > if (eq(e, elements[i])) <-- check whether > e is null on every iteration > return false; // exit, throwing away copy > else > newElements[i] = elements[i]; <-- copy elements > one by one > } > newElements[len] = e; > setArray(newElements); > ------------------------------------------------ > The proposed change is to reuse CopyOnWriteArrayList.indexOf() > function to check if e is already in the array. > If the check passed, new array is allocated withArrays.copyOf(). > It uses native System.arraycopy(), which is probably faster than > copying elements in the loop. > > Sincerely yours, > Ivan > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > From lowasser at google.com Tue Apr 2 21:49:09 2013 From: lowasser at google.com (Louis Wasserman) Date: Tue, 2 Apr 2013 14:49:09 -0700 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B4EFA.9030207@oracle.com> References: <515B2915.60402@oracle.com> <515B4EFA.9030207@oracle.com> Message-ID: Can we see the implementation of your benchmark? Accurate benchmarking is extremely nontrivial. On Tue, Apr 2, 2013 at 2:34 PM, Ivan Gerasimov wrote: > Thank you Stanimir! > > My main goal was to get rid of early and possibly unneeded memory > allocation. > I thought that System.arraycopy() would somehow compensate the need to > traverse the array twice. > However testing shows that my code works a bit faster at least when > dealing with Integer arrays of size from 1 to 100. > > Sincerely, > Ivan > > On 02.04.2013 23:25, Stanimir Simeonoff wrote: > >> The current version is cache oblivious. In any case for smaller arrays >> (like COW) System.arrayCopy won't yield any noticeable difference. >> Also, iirc System.arrayCopy places a memory barrier which in the COW case >> is unneeded. >> >> Stanimir >> >> >> >> On Tue, Apr 2, 2013 at 9:53 PM, Ivan Gerasimov > ivan.gerasimov at oracle.**com >> wrote: >> >> Hello everybody! >> >> Please review my proposal for the >> CopyOnWriteArrayList.**addIfAbsent() method optimization. >> >> http://washi.ru.oracle.com/~**igerasim/webrevs/8011215/** >> webrev/index.html >> > webrev/index.html >> > >> >> >> Here is the original function body: >> ------------------------------**------------------ >> Object[] elements = getArray(); >> int len = elements.length; >> Object[] newElements = new Object[len + 1]; <-- allocate new >> array in advance >> for (int i = 0; i < len; ++i) { >> if (eq(e, elements[i])) <-- check whether >> e is null on every iteration >> return false; // exit, throwing away copy >> else >> newElements[i] = elements[i]; <-- copy elements >> one by one >> } >> newElements[len] = e; >> setArray(newElements); >> ------------------------------**------------------ >> The proposed change is to reuse CopyOnWriteArrayList.indexOf() >> function to check if e is already in the array. >> If the check passed, new array is allocated withArrays.copyOf(). >> It uses native System.arraycopy(), which is probably faster than >> copying elements in the loop. >> >> Sincerely yours, >> Ivan >> >> ______________________________**_________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.**oswego.edu >> >> > >> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest >> >> >> > -- Louis Wasserman From peter.levart at gmail.com Tue Apr 2 22:00:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 03 Apr 2013 00:00:57 +0200 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515B2C7F.1030508@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> Message-ID: <515B5519.6020603@gmail.com> On 04/02/2013 09:07 PM, Mandy Chung wrote: > On 4/1/13 5:24 PM, John Rose wrote: >> On Mar 27, 2013, at 10:35 AM, Mandy Chung > > wrote: >> >>> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of >>> Caller-Sensitive Methods [1]. Christian has posted the webrev for >>> the hotspot VM change a couple weeks ago [2]. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ >>> >> >> This is very good work. It makes certain aspects of the system much >> easier to understand. >> >> I have reviewed it all, with the following comments: >> > Thanks for the review. >> The transform moves caller sensitivity into a clearly visible >> position. In many cases, the call to Reflection.getCallerClass now >> precedes the check of the security manager. For some customer codes, >> this may cause a performance regression, although it will probably be >> in the noise in most cases. > > Agree. I have restored the cases that should find caller class lazily. > >> If necessary, we can replace some uses of R.getCC() by something like >> (S.getSecurityManager() == null ? null : R.getCC()), recovering the >> original laziness of the stack check. This won't be necessary >> everywhere. Note that the server compiler can usually remove the >> stack walk. We may need to put something similar into the client >> compiler. >> >> In the case of the reflective calls (Field, Constructor, Method), the >> check of the caller class is gated by both AccessibleObject.override >> and quickCheckMemberAccess, and you have preserved this for >> Constructor and Method (which are probably the most important >> performance case). Consider gating it also for Field, as noted below. >> >> Per-file comments: >> >> -- Class.java >> >> (See below about checking for checkMemberAccess override.) >> > > Done. >> -- ClassLoader.java >> >> Did you consider using Class.cast to get a runtime check instead of >> @SuppressWarnings("unchecked")? >> > > Good point - I have modified it to do runtime check using > Class.asSubclass. >> -- MethodHandleNatives.java >> >> Was this deletion intentional or was it something Eclipse or Netbeans >> did? >> -import static java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP; >> > It was unintentional and I fixed it differently when I realized the > reference of IMPL_LOOKUP. I now have restored to the original import > static to be consistent with other files. > >> Good cleanups! >> >> You can remove this since rAPC is static (error in original code): >> case "registerAsParallelCapable": >> return canBeCalledVirtual(mem, >> java.lang.ClassLoader.class); >> > > Done. > >> Note that the subsequent call to canBeCalledVirtual will disqualify >> mem because it is static. >> > > Yes. >> -- MethodHandles.Lookup >> >> Now that stack walking is out of the picture, make all the >> constructors private, and remove this scary comment: >>> *

>>> * Also, don't make it private, lest javac interpose >>> * an access$N method. >> > Done. > >> I like this comment, and the manual inlining technique (in this very >> special case): >> // Inlined SecurityManager.checkMemberAccess >> Since it tends to get lost in the previous comment block, I suggest >> you put it after the open brace of the inlined body. >> >> Also, both parameters should be inlined at the top of the block, not >> just "which", so the rest of the block can a more or less verbatim copy. >> >> + { // Inlined SecurityManager.checkMemberAccess >> + final Class clazz = refc/defc; >> + final int which = Member.PUBLIC/PRIVATE; >> > > I considered that too and made the change. I actually took out the > redundant check (which != PUBLIC) since we know the value. > >> As previously noted, smgr.getClass() == SecurityManager.class is too >> strict. Suggest hoisting the nasty logic into a boolean, and using >> it twice: >> >> boolean standardCMA = (smgr.getClass() == SecurityManager.class); >> if (!standardCMA) try { >> standardCMA = >> smgr.getClass().getDeclaredMethod("checkMemberAccess", >> ...).getDeclaringClass() == SecurityManager.class; >> } catch (ReflectiveOperationException ex) { throw new >> InternalError(ex); } >> >> if (standardCMA) { // // Inlined SecurityManager.checkMemberAccess >> final Class clazz = refc/defc; >> final int which = Member.PUBLIC/PRIVATE; >> ... >> } else { >> smgr.checkMemberAccess(...); >> } >> > > OK. I modified a little. For subclass case, I can simply check if > Class.getDeclaredMethod finds the method; if exists, it's overrided; > otherwise, NoSuchMethodException thrown indicates using the standard one. Hi Mandy, There could be: public class SM1 extends SecurityManager { @Override public void checkMemberAccess(Class clazz, int which) {... and: public class SM2 extends SM1 { ... // no checkMemberAccess override now if if you take SM2.class.getDeclaredMethod("checkMemberAccess", ...) it will throw NoSuchMethodException, but the method is overriden in SM1. So I think it's better to use what John suggested (although not using getDeclaredMethod, but getMethod instead): smgr.getClass().getMethod("checkMemberAccess", ...).getDeclaringClass() == SecurityManager.class Regards, Peter > >> (And a similar comment for Class.java.) >> > Done. > >> Lots of trouble for a corner case! >> >> -- Field.java >> >> Consider making R.getCC more lazy as follows: >> >> + return getFieldAccessor(obj, needsMemberAccessCheck() ? >> Reflection.getCallerClass() : clazz).get(obj); >> >> + private boolean needsMemberAccessCheck() { >> + return !override && !Reflection.quickCheckMemberAccess(clazz, >> modifiers); >> + } >> >> (This might affect the performance of serialization.) >> >> >> -- CallerSensitiveFinder.java >> >> This is a remarkable test. Does it statically determine whether the >> annotations are missing? > > Yes - that's the purpose to catch if any use of > Reflection.getCallerClass() but not missing @CS annotation. > >> Does it process all of rt.jar? How long does it take to complete? >> > > It processes all JRE classes (i.e. rt.jar, jar files in JAVA_HOME/lib > and JAVA_HOME/lib/ext). > > I have made it done the minimal necessary work only. It takes 6 > seconds on my MacMini (2GHz core i7 and 8GB memory) to parse 24243 > classes. It takes 5-14 seconds on the jprt machines and here are some > sample timing: > linux_i586 jdk_lang took 14 mins and CallerSensitiveFinder took 8.5 > sec > macosx_x64 jdk_lang took 20.5 mins and CallerSensitiveFinder took > 14.5 sec > solaris_i586 jdk_lang took 15.5 mins and CallerSensitiveFinder took > 10 sec > windows_x64 jdk_lang took 16.5 mins and CallerSensitiveFinder took > 10 sec > >> And (I have to ask, though I'm sure the answer will be yes) have you >> run it on broken inputs (such as >> boot.GetCallerClass.missingCallerSensitiveAnnotation) and verified >> that it barks at them? >> > I ran it on an older JDK that calls Reflection.getCallerClass(int) and > no @sun.reflect.CallerSensitive exist. > > The test is currently tailored-made to only parses JRE classes. I can > easily extend it to parse additional classes like boot.GetCallerClass > that is a good test case to this tool itself. Will do so. > > I'll post a new webrev once I finish the testing. > > thanks for the detailed review. > Mandy From mike.duigou at oracle.com Tue Apr 2 22:08:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 02 Apr 2013 22:08:19 +0000 Subject: hg: jdk8/tl: 8011342: hgforest.sh : 'python --version' not supported on older python Message-ID: <20130402220819.8E4BC4855B@hg.openjdk.java.net> Changeset: 7320922b694e Author: mduigou Date: 2013-04-02 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7320922b694e 8011342: hgforest.sh : 'python --version' not supported on older python Reviewed-by: wetmore ! common/bin/hgforest.sh From mark.sheppard at oracle.com Tue Apr 2 22:20:56 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 02 Apr 2013 23:20:56 +0100 Subject: RFR-8008118 In-Reply-To: <20130328191027.22BC597129@rebar.astron.com> References: <20130328191027.22BC597129@rebar.astron.com> Message-ID: <515B59C8.1010905@oracle.com> Hi Martin, are there any concerns that the string literal "." might be on the stack and not in data segment or heap? In previous exchanges the static const char *const cwd was declared to put it in read only memory. Also, is it assured that the returned parentPathv will never be de-allocated? I don't see parentPathv exposed beyond // that of UNIXProcess_md.c, at least not directly. regards Mark On 28/03/2013 19:10, christos at zoulas.com wrote: > On Mar 28, 11:12am, martinrb at google.com (Martin Buchholz) wrote: > -- Subject: Re: RFR-8008118 > > | My apologies for unrelenting perfectionism - I noticed that we can: > | - colocate the pathv and path in one malloc'ed chunk > | - can discard xstrdup > | - can iterate through path with only one char* pointer. > | > | Making this code even cleaner, more concise and efficient. > > > - for (i = 0; i < count; i++, p++) { > - pathv[i] = ((*p == ':') || (*p == '\0')) ? "." : p; > - while (! ((*p == ':') || (*p == '\0'))) > - p++; > - *p = '\0'; > - } > - pathv[count] = NULL; > > + for (i = 0; (pathv[i] = strsep(&p, ":")) != NULL; i++) > + if (!pathv[i][0]) > + pathv[i] = "."; > > christos From ivan.gerasimov at oracle.com Tue Apr 2 22:25:31 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 02:25:31 +0400 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B4EFA.9030207@oracle.com> Message-ID: <515B5ADB.7070607@oracle.com> Sure! Attached please find an archive with the tests. Actually they are quite naive - they simply run the code snippet in loop for several hundreds times. Sincerely, Ivan On 03.04.2013 1:49, Louis Wasserman wrote: > Can we see the implementation of your benchmark? Accurate > benchmarking is extremely nontrivial. > > > On Tue, Apr 2, 2013 at 2:34 PM, Ivan Gerasimov > > wrote: > > Thank you Stanimir! > > My main goal was to get rid of early and possibly unneeded memory > allocation. > I thought that System.arraycopy() would somehow compensate the > need to traverse the array twice. > However testing shows that my code works a bit faster at least > when dealing with Integer arrays of size from 1 to 100. > > Sincerely, > Ivan > > On 02.04.2013 23:25, Stanimir Simeonoff wrote: > > The current version is cache oblivious. In any case for > smaller arrays (like COW) System.arrayCopy won't yield any > noticeable difference. > Also, iirc System.arrayCopy places a memory barrier which in > the COW case is unneeded. > > Stanimir > > > > On Tue, Apr 2, 2013 at 9:53 PM, Ivan Gerasimov > > >> wrote: > > Hello everybody! > > Please review my proposal for the > CopyOnWriteArrayList.addIfAbsent() method optimization. > > http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html > > > > > > > Here is the original function body: > ------------------------------------------------ > Object[] elements = getArray(); > int len = elements.length; > Object[] newElements = new Object[len + 1]; <-- > allocate new > array in advance > for (int i = 0; i < len; ++i) { > if (eq(e, elements[i])) <-- check whether > e is null on every iteration > return false; // exit, throwing away copy > else > newElements[i] = elements[i]; <-- copy elements > one by one > } > newElements[len] = e; > setArray(newElements); > ------------------------------------------------ > The proposed change is to reuse CopyOnWriteArrayList.indexOf() > function to check if e is already in the array. > If the check passed, new array is allocated > withArrays.copyOf(). > It uses native System.arraycopy(), which is probably > faster than > copying elements in the loop. > > Sincerely yours, > Ivan > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > > > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > > > > > -- > Louis Wasserman From mandy.chung at oracle.com Tue Apr 2 22:25:08 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 02 Apr 2013 15:25:08 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515B5519.6020603@gmail.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> Message-ID: <515B5AC4.2090902@oracle.com> On 4/2/13 3:00 PM, Peter Levart wrote: > Hi Mandy, > > There could be: > > public class SM1 extends SecurityManager { > @Override > public void checkMemberAccess(Class clazz, int which) {... > > and: > > public class SM2 extends SM1 { ... // no checkMemberAccess override > > now if if you take SM2.class.getDeclaredMethod("checkMemberAccess", > ...) it will throw NoSuchMethodException, but the method is overriden in > SM1. So I think it's better to use what John suggested (although not > using getDeclaredMethod, but getMethod instead): > > smgr.getClass().getMethod("checkMemberAccess", > ...).getDeclaringClass() == SecurityManager.class Are you concerned the overhead of an exception thrown that we should avoid? Mandy From mike.duigou at oracle.com Tue Apr 2 22:28:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 15:28:25 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <515ABBFF.80203@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <515ABBFF.80203@oracle.com> Message-ID: On Apr 2 2013, at 04:07 , Alan Bateman wrote: > On 02/04/2013 05:44, Mike Duigou wrote: >> Hello all; >> >> Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ >> >> It is currently unchanged from the last posted changeset for 7143928. >> >> Mike >> > I skimmed through the webrev as lazily creating the backing arrays will be help in some environments. > > For ArrayList.readObject then you read the array length in as "initialCapacity" which I think is a bit confusing given the current semantics. An alternative is to just not change readObject unless there is evidence that it is common to reconstitute empty ArrayLists. I've gone with making ArrayList.writeObject/readObject behave like clone(). They remain forward and backwards compatible with existing impls. > For HashMap.indexFor then I assume this isn't an assert because it is used early in the VM startup. Correct. > This should probably be changed to InternalError and the message needs to be changed too. It will be removed. :-) I had put this in for my testing. > > Do you envisage usage of inflateTable in LinkedHashMap? I'm wondering why it isn't private. I wasn't sure when I wrote it. I will make it private. > HashMap.writeObject - the update to the @serialData text will change the wording emitting in the javadoc. The "must be a power of 2" is actually an existing but previously undocumented requirement. I will file a CCC case for this. > I mention this as I think you are planning to push this to jdk7u at some point. Even though it's been a requirement for the life of this class I won't attempt to push this change to jdk7u. > I don't have time to go through the test in detail at this time but it looks like it has the original bug number and I assume that will need to change now. Correct. It will be changed. Transitioning it now. Mike From martinrb at google.com Tue Apr 2 22:29:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 15:29:55 -0700 Subject: RFR-8008118 In-Reply-To: <515B59C8.1010905@oracle.com> References: <20130328191027.22BC597129@rebar.astron.com> <515B59C8.1010905@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 3:20 PM, Mark Sheppard wrote: > Hi Martin, > are there any concerns that the string literal "." might be on the stack > and not in data segment or heap? > Nope. > > Also, is it assured that the returned parentPathv will never be > de-allocated? I don't see parentPathv exposed beyond ** > that of UNIXProcess_md.c, at least not directly. > It is not visible anywhere else. It's "permanently" allocated. Those of you thinking about shutting down and restarting a JVM within the same process will cringe - this is one of many "little leaks" in such an unsupported scenario. From ivan.gerasimov at oracle.com Tue Apr 2 22:33:10 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 02:33:10 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> Message-ID: <515B5CA6.1040006@oracle.com> On 03.04.2013 1:17, Martin Buchholz wrote: > Have you benchmarked the case where the element is never present? That's the only case I've tested. If the element were in the array, my code would obviously win. > (with the usual caveats about micro-benchmarking - perhaps use google > caliper?) The tests I wrote are quite simple - they just run a code snippet for several hundreds of times. I've just sent and archive with the tests in reply to the other message in the thread. > > On Tue, Apr 2, 2013 at 2:11 PM, Ivan Gerasimov > > wrote: > > > I've done a little testing on my side. > I used Integer as an underlying type and set length of the array > to the values from 1 to 100. > My code shows a little performance gain - approximately 9%. > I understand it may not be there for all cases, but at least for > some cases it is there. > From lowasser at google.com Tue Apr 2 22:36:33 2013 From: lowasser at google.com (Louis Wasserman) Date: Tue, 2 Apr 2013 15:36:33 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B5CA6.1040006@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B5CA6.1040006@oracle.com> Message-ID: I would be deeply suspicious of benchmarks that naive, especially for benchmarks like this that involve lots of allocation -- you're most likely benchmarking the GC, not the actual operation. On Tue, Apr 2, 2013 at 3:33 PM, Ivan Gerasimov wrote: > > On 03.04.2013 1:17, Martin Buchholz wrote: > >> Have you benchmarked the case where the element is never present? >> > That's the only case I've tested. > If the element were in the array, my code would obviously win. > > > (with the usual caveats about micro-benchmarking - perhaps use google >> caliper?) >> > The tests I wrote are quite simple - they just run a code snippet for > several hundreds of times. > I've just sent and archive with the tests in reply to the other message in > the thread. > > > >> On Tue, Apr 2, 2013 at 2:11 PM, Ivan Gerasimov > ivan.gerasimov at oracle.**com >> wrote: >> >> >> I've done a little testing on my side. >> I used Integer as an underlying type and set length of the array >> to the values from 1 to 100. >> My code shows a little performance gain - approximately 9%. >> I understand it may not be there for all cases, but at least for >> some cases it is there. >> >> > -- Louis Wasserman From christos at zoulas.com Tue Apr 2 22:43:34 2013 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 2 Apr 2013 18:43:34 -0400 Subject: RFR-8008118 In-Reply-To: <515B59C8.1010905@oracle.com> from Mark Sheppard (Apr 2, 11:20pm) Message-ID: <20130402224334.7F7B297129@rebar.astron.com> On Apr 2, 11:20pm, mark.sheppard at oracle.com (Mark Sheppard) wrote: -- Subject: Re: RFR-8008118 | Hi Martin, | are there any concerns that the string literal "." might be on the | stack and not in data segment or heap? | In previous exchanges the static const char *const cwd was declared to | put it in read only memory. Constant string literal end up in the text or ro data segment. | Also, is it assured that the returned parentPathv will never be | de-allocated? I don't see parentPathv exposed beyond // | that of UNIXProcess_md.c, at least not directly. The parent can deal with freeing it I guess. christos From martinrb at google.com Tue Apr 2 22:45:26 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 15:45:26 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B5CA6.1040006@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B5CA6.1040006@oracle.com> Message-ID: Ivan's code has my blessing without any more benchmarking efforts. Let's still wait to hear from Doug. From ivan.gerasimov at oracle.com Tue Apr 2 22:45:13 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 02:45:13 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B4AE5.4060104@CoSoCo.de> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> Message-ID: <515B5F79.9090603@oracle.com> Thank you, Ulf! > maybe the old code wins for looong arrays, so there could be a > threshold to decide between old and new code: I've modified the benchmark code to test arrays with 90'000 to 100'000 elements. (Previously was testing 1 to 100 elements.) The performance gain turns out to be even more significant. On my machine tests show that with that many elements the new code runs 40% faster. Honestly, I didn't expect that. I thought my code might be a bit slower and hoped that not much slower. Sincerely, Ivan > > > Am 02.04.2013 23:11, schrieb Ivan Gerasimov: >> >>> Thanks for this change. There is a tradeoff here. If the element >>> is never present, then the older code might be a little faster, >>> because we can avoid re-traversing the array. Otherwise, the new >>> code is better. >> >> I've done a little testing on my side. >> I used Integer as an underlying type and set length of the array to >> the values from 1 to 100. >> My code shows a little performance gain - approximately 9%. >> I understand it may not be there for all cases, but at least for some >> cases it is there. >> >>> I prefer it your way (I hate unneeded allocation), but the code was >>> intentionally written the other way. Let's hear from Doug... >>> >>> Martin >>> >>> >>> On Tue, Apr 2, 2013 at 1:38 PM, Ivan Gerasimov >>> > wrote: >>> >>> >>>> Please review my proposal for the >>>> CopyOnWriteArrayList.addIfAbsent() method optimization. >>>> >>>> http://washi.ru.oracle.com/~igerasim/webrevs/8011215/webrev/index.html >>>> >>>> >>>> >>>> >>>> This URL is not readable by external reviewers. >>> >>> The webrev has been copied here: >>> http://cr.openjdk.java.net/~coffeys/webrev.8011215.ivan/ >>> >>> >>> >>>> The "master" version of CopyOnWriteArrayList is here: >>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=markup >>>> >>>> >>> Thanks for the link! >>> I see that the code in the master version is identical to the one >>> I've been working on. >>> So the optimization still could be applied. >>> >>> Sincerely, >>> Ivan >>> >>> >> >> > > > From martinrb at google.com Tue Apr 2 22:47:54 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Apr 2013 15:47:54 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B5F79.9090603@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 3:45 PM, Ivan Gerasimov wrote: > Thank you, Ulf! > > > maybe the old code wins for looong arrays, so there could be a threshold >> to decide between old and new code: >> > > I've modified the benchmark code to test arrays with 90'000 to 100'000 > elements. (Previously was testing 1 to 100 elements.) > The performance gain turns out to be even more significant. > On my machine tests show that with that many elements the new code runs > 40% faster. > > Honestly, I didn't expect that. I thought my code might be a bit slower > and hoped that not much slower. > Yeah, that's a bit surprising. Perhaps because you're avoiding the branch of testing object for null on each iteration? From mike.duigou at oracle.com Tue Apr 2 22:50:38 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 15:50:38 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: Hello again; I have updated the patch with the received review feedback. The revised webrev is here: http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ The important changes in this revision: - The behaviour of the readObject/writeObject serialization for both classes now more closely mirrors the behaviour of clone(). For ArrayList this means that the deserialized list has a capacity the same as the size. ie. as if trimToSize() was called. For HashMap, the opposite is true, the capacity is the same as was in effect when the object was serialized. (HashMap also tries to protect itself from nonsensical/harmful input). The implementation changes to serialization preserve forward and backward compatibility--all serialized objects are compatible with all implementations. I will file a spec change request for the addition of ", a power of 2" to the @serialData tag for this existing but previously unstated requirement. - Use of Arrays.fill has been reverted. I did change one fill case so that the loop can be optimized. (size field was being updated with each iteration). I very slightly expanded the docs. This is starting to look like a nice set of changes. Mike On Apr 1 2013, at 21:44 , Mike Duigou wrote: > Hello all; > > Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ > > It is currently unchanged from the last posted changeset for 7143928. > > Mike > > On Apr 1 2013, at 19:00 , Mike Duigou wrote: > >> Hello all; >> >> I have posted an updated version of the empty ArrayList and HashMap patch. >> >> http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ >> >> This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. >> >> For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. >> >> Mike >> >> On Mar 26 2013, at 17:25 , Mike Duigou wrote: >> >>> Hello all; >>> >>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. >>> >>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ >>> >>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. >>> >>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). >>> >>> Mike >> > From lowasser at google.com Tue Apr 2 23:00:26 2013 From: lowasser at google.com (Louis Wasserman) Date: Tue, 2 Apr 2013 16:00:26 -0700 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B5CA6.1040006@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 3:36 PM, Louis Wasserman wrote: > I would be deeply suspicious of benchmarks that naive, especially for > benchmarks like this that involve lots of allocation -- you're most likely > benchmarking the GC, not the actual operation. > Sorry, let me clarify: can you test how much GC is happening here, and what proportion of the benchmark time is being taken by GC either way? The difficulty with benchmarking things like this is that the GC behavior of a pure benchmark that does lots of allocation tends to be nothing at all like the GC behavior of that same operation in the middle of a real application doing lots of other things. I'd be perfectly comfortable with this change justified on the grounds of avoiding unnecessary allocation, but it can be dangerous to make generalizations like "this is X% faster" when a substantial fraction of one run or the other is just the GC running. From mark.sheppard at oracle.com Tue Apr 2 23:19:58 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 03 Apr 2013 00:19:58 +0100 Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods In-Reply-To: <515B1ACF.705@oracle.com> References: <515317EB.8020207@oracle.com> <515B1ACF.705@oracle.com> Message-ID: <515B679E.4080007@oracle.com> Hi Sherman, I didn't think "outside the box" on this one, but was a bit mechanical with the fix. Your latter two options are appealing: returning Encoder.RFC4648 or throwing an exception. In fact your second option of using the Base64.getEncoder(), ignoring the line separator and returning the RFC4648 encoder, solves the issue neatly, and you can leave the spec as is :-) As such: public static Encoder getEncoder(int lineLength, byte[] lineSeparator) { if (lineLength <= 0) { return Encoder.RFC4648; } Objects.requireNonNull(lineSeparator); int[] base64 = Decoder.fromBase64; for (byte b : lineSeparator) { if (base64[b & 0xff] != -1) throw new IllegalArgumentException( "Illegal base64 line separator character 0x" + Integer.toString(b, 16)); } return new Encoder(false, lineSeparator, lineLength >> 2 << 2); } will do the job nicely. While throwing an exception will ensure a single point of access to the RFC4648 Encoder, and mean the getEncoder(int, byte[]) is providing a genuine alternative Encoder to the three "build in" Encoders. Thus, eliminating the lineLength <=0 option makes sense. The former has least impact as a fix. The latter makes more sense when you think about it. Whichever you favour and I'll make the change. regards Mark On 02/04/2013 18:52, Xueming Shen wrote: > Thanks Mark for looking into this issue. > > The change itself looks fine. Though I'm a little concerned whether > the performance cost (need to do an additional linemax > 0 check > inside the 'while" loop) is really worth it. Maybe an alternative is > to simply set the linemax to -1 if it's 0? such as > > public static Encoder getEncoder(int lineLength, byte[] > lineSeparator) { > Objects.requireNonNull(lineSeparator); > int[] base64 = Decoder.fromBase64; > for (byte b : lineSeparator) { > if (base64[b & 0xff] != -1) > throw new IllegalArgumentException( > "Illegal base64 line separator character 0x" + > Integer.toString(b, 16)); > } > if (lineLength == 0) > lineLength = -1; > return new Encoder(false, lineSeparator, lineLength >> 2 << 2); > } > > And given it actually become a "normal" RFC4648 if the lineLength <=0, > maybe > we should simply eliminate this "option" by changing the spec to say > "throw > IAE if lineLength <=0", go use BAse64.getEncoder() if lineSeparator is > not needed. > > -Sherman > > > On 03/27/2013 09:01 AM, Mark Sheppard wrote: >> Hi, >> please oblige and review the webrev below as a fix for the issue >> raised in JDK-8007799 >> >> http://cr.openjdk.java.net/~msheppar/8007799/webrev.00/ >> >> Description: >> "Specification for the method >> java.util.Base64.getEncoder(int lineLength, byte[] lineSeparator) >> >> says: >> Parameters: >> lineLength - the length of each output line (rounded down to >> nearest multiple of 4). If lineLength <= 0 the output will not be >> separated in lines >> >> However if a zero line length is specified encoding methods wrap() >> and encode(ByteBuffer src, ByteBuffer dst, int bytesOut) return >> encoded string which starts from the given line separator. " >> >> the patch adds a check for linemax > 0 whenever a line separator >> might be added, and adds an new test case. >> >> regards >> Mark > From joe.darcy at oracle.com Tue Apr 2 23:27:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 02 Apr 2013 23:27:03 +0000 Subject: hg: jdk8/tl/jdk: 8004979: java.lang.reflect.Modifier.toString should include "default" Message-ID: <20130402232725.B0F894855F@hg.openjdk.java.net> Changeset: b4f68aca1000 Author: darcy Date: 2013-04-02 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f68aca1000 8004979: java.lang.reflect.Modifier.toString should include "default" Reviewed-by: mduigou ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! test/java/lang/reflect/Method/GenericStringTest.java From ivan.gerasimov at oracle.com Tue Apr 2 23:28:29 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 03 Apr 2013 03:28:29 +0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B5CA6.1040006@oracle.com> Message-ID: <515B699D.6020008@oracle.com> Thank you, Louis. Yes, you're probably right. I might want to get familiar with caliper mentioned earlier, or something else like that. However, I'd like to note that in the tests exactly the same amount of allocations were made for both versions of code. The difference in the code is around these allocations. On 03.04.2013 2:36, Louis Wasserman wrote: > I would be deeply suspicious of benchmarks that naive, especially for > benchmarks like this that involve lots of allocation -- you're most > likely benchmarking the GC, not the actual operation. > > > On Tue, Apr 2, 2013 at 3:33 PM, Ivan Gerasimov > > wrote: > > > On 03.04.2013 1:17, Martin Buchholz wrote: > > Have you benchmarked the case where the element is never present? > > That's the only case I've tested. > If the element were in the array, my code would obviously win. > > > (with the usual caveats about micro-benchmarking - perhaps use > google caliper?) > > The tests I wrote are quite simple - they just run a code snippet > for several hundreds of times. > I've just sent and archive with the tests in reply to the other > message in the thread. > > > > On Tue, Apr 2, 2013 at 2:11 PM, Ivan Gerasimov > > >> wrote: > > > I've done a little testing on my side. > I used Integer as an underlying type and set length of the > array > to the values from 1 to 100. > My code shows a little performance gain - approximately 9%. > I understand it may not be there for all cases, but at > least for > some cases it is there. > > > > > > -- > Louis Wasserman From vitalyd at gmail.com Tue Apr 2 23:43:15 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 2 Apr 2013 19:43:15 -0400 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> Message-ID: I actually like Ivan's version as well. The diff in perf may also be due to uneliminated range checks in current code - loop bounds is stored in local but unclear whether jit can still trace through and determine that it's always within bounds. Also the store into new array may get hit if, again, jit doesn't figure it out - would have to look at disassembly. The Arrays.copyOf() intrinsic obviously will avoid range checks. Also unclear whether the branch in the loop body kills certain optimizations, so Ivan's code, despite walking the array twice (possibly), is easier to optimize aggressively to the point where it may become a memory bandwidth limited operation (for very large sizes). Sent from my phone On Apr 2, 2013 6:48 PM, "Martin Buchholz" wrote: > On Tue, Apr 2, 2013 at 3:45 PM, Ivan Gerasimov >wrote: > > > Thank you, Ulf! > > > > > > maybe the old code wins for looong arrays, so there could be a threshold > >> to decide between old and new code: > >> > > > > I've modified the benchmark code to test arrays with 90'000 to 100'000 > > elements. (Previously was testing 1 to 100 elements.) > > The performance gain turns out to be even more significant. > > On my machine tests show that with that many elements the new code runs > > 40% faster. > > > > Honestly, I didn't expect that. I thought my code might be a bit slower > > and hoped that not much slower. > > > > Yeah, that's a bit surprising. Perhaps because you're avoiding the branch > of testing object for null on each iteration? > From mandy.chung at oracle.com Wed Apr 3 02:56:12 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 02 Apr 2013 19:56:12 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515B5AC4.2090902@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> Message-ID: <515B9A4C.9030006@oracle.com> Here is the updated webrev per John's and Alan's comments: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/ In MethodHandles.java, it calls Class.getDeclaredMethod method to determine if a SecurityManager subclass overrides checkMemberAccess. It's called only if security manager is installed and it's a subclass. If it calls Class.getMethod instead, it will look up its superclasses and find the one in SecurityManager.class. For the case when the subclass doesn't override CMA, the difference in overhead will be throwing an exception vs. looking up CMA from the subclass and its superclasses and create the Method instance. I don't have the performance number to compare. This would be rare case and I tend to think instantiating and throwing an exception would be comparable to the reflection machinery. This check will go away when 8007035 is fixed that will deprecate SecurityManager.checkMemberAccess [1] and I'm fine going either way. FYI. 7198429 has been used for the hotspot changeset and will be resolved when it's integrated to jdk8/hotspot repo. The jdk changeset will be using 8010117, a subtask for 7198429, as specified in @bug tags in the tests. Mandy [1] http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/16885e702c88 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-March/015547.html On 4/2/2013 3:25 PM, Mandy Chung wrote: > On 4/2/13 3:00 PM, Peter Levart wrote: >> Hi Mandy, >> >> There could be: >> >> public class SM1 extends SecurityManager { >> @Override >> public void checkMemberAccess(Class clazz, int which) {... >> >> and: >> >> public class SM2 extends SM1 { ... // no checkMemberAccess override >> >> now if if you take SM2.class.getDeclaredMethod("checkMemberAccess", >> ...) it will throw NoSuchMethodException, but the method is overriden in >> SM1. So I think it's better to use what John suggested (although not >> using getDeclaredMethod, but getMethod instead): >> >> smgr.getClass().getMethod("checkMemberAccess", >> ...).getDeclaringClass() == SecurityManager.class > > Are you concerned the overhead of an exception thrown that we should > avoid? > > Mandy From john.r.rose at oracle.com Wed Apr 3 04:25:27 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Apr 2013 21:25:27 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515B5AC4.2090902@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> Message-ID: So getDM has a bug and getM is correct wrt inheritance. Thanks Peter! -- John (on my iPhone) On Apr 2, 2013, at 3:25 PM, Mandy Chung wrote: > > Are you concerned the overhead of an exception thrown that we should avoid? From joe.darcy at oracle.com Wed Apr 3 07:27:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 03 Apr 2013 00:27:31 -0700 Subject: Code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and java.lang.reflect.Type Message-ID: <515BD9E3.5050303@oracle.com> Hello, This is combined code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and getTypeName to java.lang.reflect.Type 6992705 (reflect) Include modifiers to Class's toGenericString() http://cr.openjdk.java.net/~darcy/6298888.0/ In brief, a "toGenericString" method is added to java.lang.Class, analogous to the toGenericString methods in Field, Method, and Constructor. A default method for "getTypeName" is added to java.lang.reflect Type, which allows the code used to implement toGenericString to be cleaned up. There is some general maintenance on this area as well. In particular, the correct specification change intended to be done as part of 8004979: java.lang.reflect.Modifier.toString should include "default" http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f68aca1000 is included; the "default" modifier should appear after "abstract" and not at the very end of the modifier list. Thanks, -Joe From peter.levart at gmail.com Wed Apr 3 07:39:59 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 03 Apr 2013 09:39:59 +0200 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515B5AC4.2090902@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> Message-ID: <515BDCCF.1080003@gmail.com> On 04/03/2013 12:25 AM, Mandy Chung wrote: > On 4/2/13 3:00 PM, Peter Levart wrote: >> Hi Mandy, >> >> There could be: >> >> public class SM1 extends SecurityManager { >> @Override >> public void checkMemberAccess(Class clazz, int which) {... >> >> and: >> >> public class SM2 extends SM1 { ... // no checkMemberAccess override >> >> now if if you take SM2.class.getDeclaredMethod("checkMemberAccess", >> ...) it will throw NoSuchMethodException, but the method is overriden in >> SM1. So I think it's better to use what John suggested (although not >> using getDeclaredMethod, but getMethod instead): >> >> smgr.getClass().getMethod("checkMemberAccess", >> ...).getDeclaringClass() == SecurityManager.class > > Are you concerned the overhead of an exception thrown that we should > avoid? Hi Mandy, No, I was not thinking of performance. Just the correctness. Class.getDeclaredMethod(name, ...) only considers methods "declared" by the class (not inherited from a superclass - directy or indirectly). But you could have, like in example above, a hierarchy: SM2 extends SM1 extends SecurityManager where SM1 overrides the method in SecurityManager and SM2 doesn't. Now if you try SM2.class.getDeclaredMethod(), you will get NoSuchMethodException, but that does not mean the method is not overriden - it is in class SM1. You could use getDeclaredMethod on the class and all superclasses until reaching SecurityManager to find out if the method is overriden, but it's fortunate that the method is public and so Class.getMethod(name, ...) can be used which does exactly that and already considers inheritance and overriding and returns the most specific method in the hierarchy. Explicit search using getDeclaredMethod() could skip searching the method in SecurityManager class though, but: - negative answer via exception is slow - getMethod() only searches among public methods (which are separately cached in special array) and can therefore be faster if there is relatively large share of non-public methods declared in the class being searched. Here's a quick micro-benchmark for the common case (only one level of subclassing the SecurityManager) and both variants (the method is overriden in SecurityManager subclass or not): ############################################################## # Java: 1.8.0-internal-peter_2013_01_16_13_44-b00 # VM: OpenJDK 64-Bit Server VM 25.0-b14 (mixed mode) # OS: Linux 3.7.9-104.fc17.x86_64 (amd64) # CPUs: 8 (virtual) # #------------------------------------------------------------- # GetDeclaredMethodOverridenSearch: run duration: 3,000 ms # # Warm up: # 1 threads, Tavg = 327.59 ns/op (? = 0.00 ns/op) [ 327.59] # 1 threads, Tavg = 326.06 ns/op (? = 0.00 ns/op) [ 326.06] # Measure: 1 threads, Tavg = 325.18 ns/op (? = 0.00 ns/op) [ 325.18] # #------------------------------------------------------------- # GetPublicMethodOverridenSearch: run duration: 3,000 ms # # Warm up: # 1 threads, Tavg = 325.69 ns/op (? = 0.00 ns/op) [ 325.69] # 1 threads, Tavg = 329.67 ns/op (? = 0.00 ns/op) [ 329.67] # Measure: 1 threads, Tavg = 325.88 ns/op (? = 0.00 ns/op) [ 325.88] # #------------------------------------------------------------- # GetDeclaredMethodNotOverridenSearch: run duration: 3,000 ms # # Warm up: # 1 threads, Tavg = 1,405.84 ns/op (? = 0.00 ns/op) [ 1,405.84] # 1 threads, Tavg = 1,371.14 ns/op (? = 0.00 ns/op) [ 1,371.14] # Measure: 1 threads, Tavg = 1,358.02 ns/op (? = 0.00 ns/op) [ 1,358.02] # #------------------------------------------------------------- # GetPublicMethodNotOverridenSearch: run duration: 3,000 ms # # Warm up: # 1 threads, Tavg = 557.50 ns/op (? = 0.00 ns/op) [ 557.50] # 1 threads, Tavg = 553.05 ns/op (? = 0.00 ns/op) [ 553.05] # Measure: 1 threads, Tavg = 554.59 ns/op (? = 0.00 ns/op) [ 554.59] # #------------------------------------------------------------- # END. ############################################################## Here's the source of the test: public class MethodSearchTest extends TestRunner { static final Class[] paramTypes = {Class.class, int.class}; static class SMOverriden extends SecurityManager { @Override public void checkMemberAccess(Class clazz, int which) { } } static class SMNotOverriden extends SecurityManager { } public static class GetDeclaredMethodOverridenSearch extends Test { @Override protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) { while (loop.nextIteration()) { try { SMOverriden.class.getDeclaredMethod("checkMemberAccess", paramTypes); devNull1.yield(true); } catch (NoSuchMethodException e) { devNull1.yield(false); } } } } public static class GetPublicMethodOverridenSearch extends Test { @Override protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) { while (loop.nextIteration()) { try { devNull1.yield(SMOverriden.class.getMethod("checkMemberAccess", paramTypes).getDeclaringClass() != SecurityManager.class); } catch (NoSuchMethodException e) { throw new Error(e); } } } } public static class GetDeclaredMethodNotOverridenSearch extends Test { @Override protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) { while (loop.nextIteration()) { try { SMNotOverriden.class.getDeclaredMethod("checkMemberAccess", paramTypes); devNull1.yield(true); } catch (NoSuchMethodException e) { devNull1.yield(false); } } } } public static class GetPublicMethodNotOverridenSearch extends Test { @Override protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, DevNull devNull3, DevNull devNull4, DevNull devNull5) { while (loop.nextIteration()) { try { devNull1.yield(SMNotOverriden.class.getMethod("checkMemberAccess", paramTypes).getDeclaringClass() != SecurityManager.class); } catch (NoSuchMethodException e) { throw new Error(e); } } } } public static void main(String[] args) throws Exception { startTests(); doTest(GetDeclaredMethodOverridenSearch.class, 3000L, 1, 1, 1); doTest(GetPublicMethodOverridenSearch.class, 3000L, 1, 1, 1); doTest(GetDeclaredMethodNotOverridenSearch.class, 3000L, 1, 1, 1); doTest(GetPublicMethodNotOverridenSearch.class, 3000L, 1, 1, 1); endTests(); } } Regards, Peter > > Mandy From Alan.Bateman at oracle.com Wed Apr 3 08:03:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Apr 2013 09:03:49 +0100 Subject: RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515B699D.6020008@oracle.com> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B5CA6.1040006@oracle.com> <515B699D.6020008@oracle.com> Message-ID: <515BE265.4070400@oracle.com> On 03/04/2013 00:28, Ivan Gerasimov wrote: > Thank you, Louis. > > Yes, you're probably right. > I might want to get familiar with caliper mentioned earlier, or > something else like that. One other tool to also be aware of is the Java Microbenchmark Harness [1]. Aleksey Shipilev recently contributed this to the OpenJDK Code Tools Project. -Alan [1] http://openjdk.java.net/projects/code-tools/jmh/ From peter.levart at gmail.com Wed Apr 3 08:26:42 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 03 Apr 2013 10:26:42 +0200 Subject: Code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and java.lang.reflect.Type In-Reply-To: <515BD9E3.5050303@oracle.com> References: <515BD9E3.5050303@oracle.com> Message-ID: <515BE7C2.9020101@gmail.com> Hi Joe, Why not using StringBuilder instead of StringBuffer in Class.toGenericString ? Regards, Peter On 04/03/2013 09:27 AM, Joe Darcy wrote: > Hello, > > This is combined code review request for > > 6298888 (reflect) Add toGenericString to java.lang.Class and > getTypeName to java.lang.reflect.Type > 6992705 (reflect) Include modifiers to Class's toGenericString() > http://cr.openjdk.java.net/~darcy/6298888.0/ > > In brief, a "toGenericString" method is added to java.lang.Class, > analogous to the toGenericString methods in Field, Method, and > Constructor. A default method for "getTypeName" is added to > java.lang.reflect Type, which allows the code used to implement > toGenericString to be cleaned up. > > There is some general maintenance on this area as well. In particular, > the correct specification change intended to be done as part of > > 8004979: java.lang.reflect.Modifier.toString should include "default" > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f68aca1000 > > is included; the "default" modifier should appear after "abstract" and > not at the very end of the modifier list. > > Thanks, > > -Joe From bourges.laurent at gmail.com Wed Apr 3 09:01:22 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 3 Apr 2013 11:01:22 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: Thanks for your valueable feedback! Here is the current status of my patch alpha version: >> http://jmmc.fr/~bourgesl/share/java2d-pisces/ >> >> There is still a lot to be done: clean-up, stats, pisces class instance >> recycling (renderer, stroker ...) and of course sizing correctly initial >> arrays (dirty or clean) in the RendererContext (thread local storage). >> For performance reasons, I am using now RendererContext members first >> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays). >> > > Thank you Laurent, those are some nice speedups. > I think it can still be improved: I hope to make it as fast as ductus or maybe more (I have several idea for aggressive optimizations) but the main improvement consist in reusing memory (like C / C++ does) to avoid wasted memory / GC overhead in concurrent environment. > About the thread local storage, that is a sensible choice for highly > concurrent systems, at the same time, web containers normally complain about > orphaned thread locals created by an application and not cleaned up. > Not sure if ones created at the core libs level get special treatment, but > in general, I guess it would be nice to have some way to clean them up. > You're right that's why my patch is not ready ! I chose ThreadLocal for simplicity and clarity but I see several issues: 1/ Web container: ThreadLocal must be clean up when stopping an application to avoid memory leaks (application becomes unloadable due to classloader leaks) 2/ ThreadLocal access is the fastest way to get the RendererContext as it does not require any lock (unsynchronized); As I get the RendererContext once per rendering request, I think the ThreadLocal can be replaced by a thread-safe ConcurrentLinkedQueue but it may become a performance bootleneck 3/ Using a ConcurrentLinkedQueue requires an efficient / proper cache eviction to free memory (Weak or Soft references ?) or using statistics (last usage timestamp, usage counts) Any other idea (core-libs) to have an efficient thread context in a web container ? I'm not familiar with the API, but is there any way to clean them up when > the graphics2d gets disposed of? > The RenderingEngine is instanciated by the JVM once and I do not see in the RenderingEngine interface any way to perform callbacks for warmup / cleanup ... nor access to the Graphics RenderingHints (other RFE for tuning purposes) > A web application has no guarantee to see the same thread ever again > during his life, so thread locals have to be cleaned right away. > I advocate ThreadLocal can lead to wasted memory as only few concurrent threads can really use their RendererContext instance while others can simply answer web requests => let's use a ConcurrentLinkedQueue with a proper cache eviction. > > Either that, or see if there is any way to store the array caches in a > global structure backed by a concurrent collection to reduce/eliminate > contention. > Yes, it is a interesting alternative to benchmark. Regards, Laurent From dl at cs.oswego.edu Wed Apr 3 10:35:27 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 3 Apr 2013 06:35:27 -0400 (EDT) Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> Message-ID: <34160.38.123.136.254.1364985327.squirrel@altair.cs.oswego.edu> A few quick notes while travelling: This was designed to perform best in the case of possibly contended updates when the element is absent, by avoiding retraversal, and thus minimizing lock hold times in the common case. (When not common, it can be guarded by a contains check.) However even in this case, it is possible that a retraversal via arraycopy could be faster because it can use optimized cheaper writes (fewer card marks). I'll recheck this on enough machines to make a better assessment of impact withing a few days. -Doug > CPU will predict but compiler may not optimize loop aggressively with the > branch there; e.g. if you unroll, you'll bloat code size by having a > branch > on each element, and then you can hit icache misses. > > Arrays.copyOf is intrinsic so should have perf similar to > System.arrayCopy. > > Sent from my phone > On Apr 2, 2013 7:51 PM, "Stanimir Simeonoff" wrote: > >> >> On Wed, Apr 3, 2013 at 1:47 AM, Martin Buchholz >> wrote: >> >>> >>> >>> >>> On Tue, Apr 2, 2013 at 3:45 PM, Ivan Gerasimov >>> >> > wrote: >>> >>>> Thank you, Ulf! >>>> >>>> >>>> maybe the old code wins for looong arrays, so there could be a >>>>> threshold to decide between old and new code: >>>>> >>>> >>>> I've modified the benchmark code to test arrays with 90'000 to 100'000 >>>> elements. (Previously was testing 1 to 100 elements.) >>>> The performance gain turns out to be even more significant. >>>> On my machine tests show that with that many elements the new code >>>> runs >>>> 40% faster. >>>> >>>> Honestly, I didn't expect that. I thought my code might be a bit >>>> slower >>>> and hoped that not much slower. >>>> >>> >>> Yeah, that's a bit surprising. Perhaps because you're avoiding the >>> branch of testing object for null on each iteration? >>> >>> The branch would be perfectly predicted by the CPU, so it cannot be >>> that. >> System.arraycopy would be much better for larger arrays as it uses SSE >> extensions to copy but normally COW structures would not have so many >> elements. >> btw, the 2 pass version benefits of low memory footprint equals() (and >> all >> in L2 cache). Basically if you don't get cache trashing Arrays.copy >> would >> be the better one. >> >> Stanimir >> >> >>> _______________________________________________ >>> Concurrency-interest mailing list >>> Concurrency-interest at cs.oswego.edu >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>> >>> >> >> _______________________________________________ >> Concurrency-interest mailing list >> Concurrency-interest at cs.oswego.edu >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > From Alan.Bateman at oracle.com Wed Apr 3 11:14:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Apr 2013 12:14:41 +0100 Subject: 8011373: Property java.runtime.profile should be removed (left-over code) Message-ID: <515C0F21.8080302@oracle.com> I need a reviewer for a trivial change to remove code that sets the property java.runtime.profile during initialization. This is a left-over experimental code from the jdk8/profiles forest that I should have removed before the changes were pushed to the build forest. Thanks, Alan. diff --git a/src/share/classes/sun/misc/Version.java.template b/src/share/classes/sun/misc/Version.java.template --- a/src/share/classes/sun/misc/Version.java.template +++ b/src/share/classes/sun/misc/Version.java.template @@ -52,8 +52,6 @@ System.setProperty("java.version", java_version); System.setProperty("java.runtime.version", java_runtime_version); System.setProperty("java.runtime.name", java_runtime_name); - if (java_profile_name.length() > 0) - System.setProperty("java.runtime.profile", java_profile_name); } private static boolean versionsInitialized = false; From lance.andersen at oracle.com Wed Apr 3 11:27:14 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 3 Apr 2013 07:27:14 -0400 Subject: 8011373: Property java.runtime.profile should be removed (left-over code) In-Reply-To: <515C0F21.8080302@oracle.com> References: <515C0F21.8080302@oracle.com> Message-ID: <09E08608-EEDB-4F44-AC5E-4A7B36165784@oracle.com> +1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On Apr 3, 2013, at 7:14 AM, Alan Bateman wrote: > > I need a reviewer for a trivial change to remove code that sets the property java.runtime.profile during initialization. This is a left-over experimental code from the jdk8/profiles forest that I should have removed before the changes were pushed to the build forest. > > Thanks, > Alan. > > diff --git a/src/share/classes/sun/misc/Version.java.template b/src/share/classes/sun/misc/Version.java.template > --- a/src/share/classes/sun/misc/Version.java.template > +++ b/src/share/classes/sun/misc/Version.java.template > @@ -52,8 +52,6 @@ > System.setProperty("java.version", java_version); > System.setProperty("java.runtime.version", java_runtime_version); > System.setProperty("java.runtime.name", java_runtime_name); > - if (java_profile_name.length() > 0) > - System.setProperty("java.runtime.profile", java_profile_name); > } > > private static boolean versionsInitialized = false; From alan.bateman at oracle.com Wed Apr 3 12:19:34 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 03 Apr 2013 12:19:34 +0000 Subject: hg: jdk8/tl/jdk: 8011234: Performance regression with ftp protocol when uploading in image mode Message-ID: <20130403122041.335594858A@hg.openjdk.java.net> Changeset: c534937f6e94 Author: alanb Date: 2013-04-03 13:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c534937f6e94 8011234: Performance regression with ftp protocol when uploading in image mode Reviewed-by: chegar ! src/share/classes/sun/net/ftp/impl/FtpClient.java From david.holmes at oracle.com Wed Apr 3 12:27:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Apr 2013 22:27:35 +1000 Subject: 8011373: Property java.runtime.profile should be removed (left-over code) In-Reply-To: <515C0F21.8080302@oracle.com> References: <515C0F21.8080302@oracle.com> Message-ID: <515C2037.6030501@oracle.com> Looks good. David On 3/04/2013 9:14 PM, Alan Bateman wrote: > > I need a reviewer for a trivial change to remove code that sets the > property java.runtime.profile during initialization. This is a left-over > experimental code from the jdk8/profiles forest that I should have > removed before the changes were pushed to the build forest. > > Thanks, > Alan. > > diff --git a/src/share/classes/sun/misc/Version.java.template > b/src/share/classes/sun/misc/Version.java.template > --- a/src/share/classes/sun/misc/Version.java.template > +++ b/src/share/classes/sun/misc/Version.java.template > @@ -52,8 +52,6 @@ > System.setProperty("java.version", java_version); > System.setProperty("java.runtime.version", java_runtime_version); > System.setProperty("java.runtime.name", java_runtime_name); > - if (java_profile_name.length() > 0) > - System.setProperty("java.runtime.profile", java_profile_name); > } > > private static boolean versionsInitialized = false; From Alan.Bateman at oracle.com Wed Apr 3 12:41:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Apr 2013 13:41:18 +0100 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <20130328201656.E120C48477@hg.openjdk.java.net> References: <20130328201656.E120C48477@hg.openjdk.java.net> Message-ID: <515C236E.8050600@oracle.com> On 28/03/2013 20:16, mandy.chung at oracle.com wrote: > Changeset: e433ed08b733 > Author: mchung > Date: 2013-03-28 13:14 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 > > 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level > Reviewed-by: mchung > Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com > > ! src/share/classes/sun/util/logging/PlatformLogger.java > ! test/sun/util/logging/PlatformLoggerTest.java It seems that FX doesn't like this good work. Caused by: java.lang.NoSuchMethodError: sun.util.logging.PlatformLogger.getLevel()I at com.sun.javafx.css.parser.CSSParser.(CSSParser.java:164) at com.sun.javafx.css.StyleManager.loadStylesheetUnPrivileged(StyleManager.java:854) at com.sun.javafx.css.StyleManager.loadStylesheet(StyleManager.java:674) at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1050) at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1020) at com.sun.javafx.application.PlatformImpl$10.run(PlatformImpl.java:525) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:522) at com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:474) at javafx.scene.control.Control.(Control.java:82) at helloworld.HelloWorld.start(HelloWorld.java:14) at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:772) at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260) at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223) at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:220) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:220) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:94) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39) at com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101) ... 1 more From alan.bateman at oracle.com Wed Apr 3 12:44:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 03 Apr 2013 12:44:17 +0000 Subject: hg: jdk8/tl/jdk: 8011373: Property java.runtime.profile should be removed (left-over code) Message-ID: <20130403124438.CA8174858B@hg.openjdk.java.net> Changeset: eb8f7bc6f964 Author: alanb Date: 2013-04-03 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb8f7bc6f964 8011373: Property java.runtime.profile should be removed (left-over code) Reviewed-by: lancea, dholmes ! src/share/classes/sun/misc/Version.java.template From bourges.laurent at gmail.com Wed Apr 3 12:46:46 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 3 Apr 2013 14:46:46 +0200 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <515C236E.8050600@oracle.com> References: <20130328201656.E120C48477@hg.openjdk.java.net> <515C236E.8050600@oracle.com> Message-ID: Does JavaFX belong to OpenJDK projects (*openjfx/8) *? How do I build the complete OpenJDK (javafx, java web start ...) ? Laurent 2013/4/3 Alan Bateman > On 28/03/2013 20:16, mandy.chung at oracle.com wrote: > > Changeset: e433ed08b733 > Author: mchung > Date: 2013-03-28 13:14 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 > > 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level > Reviewed-by: mchung > Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com > > ! src/share/classes/sun/util/logging/PlatformLogger.java > ! test/sun/util/logging/PlatformLoggerTest.java > > It seems that FX doesn't like this good work. > > Caused by: java.lang.NoSuchMethodError: sun.util.logging.PlatformLogger.getLevel()I > at com.sun.javafx.css.parser.CSSParser.(CSSParser.java:164) > at com.sun.javafx.css.StyleManager.loadStylesheetUnPrivileged(StyleManager.java:854) > at com.sun.javafx.css.StyleManager.loadStylesheet(StyleManager.java:674) > at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1050) > at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1020) > at com.sun.javafx.application.PlatformImpl$10.run(PlatformImpl.java:525) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:522) > at com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:474) > at javafx.scene.control.Control.(Control.java:82) > at helloworld.HelloWorld.start(HelloWorld.java:14) > at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:772) > at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260) > at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223) > at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:220) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:220) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:94) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39) > at com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101) > ... 1 more > > > > From peter.levart at gmail.com Wed Apr 3 13:29:43 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 03 Apr 2013 15:29:43 +0200 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <515C236E.8050600@oracle.com> References: <20130328201656.E120C48477@hg.openjdk.java.net> <515C236E.8050600@oracle.com> Message-ID: <515C2EC7.8020104@gmail.com> On 04/03/2013 02:41 PM, Alan Bateman wrote: > On 28/03/2013 20:16, mandy.chung at oracle.com wrote: >> Changeset: e433ed08b733 >> Author: mchung >> Date: 2013-03-28 13:14 -0700 >> URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 >> >> 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level >> Reviewed-by: mchung >> Contributed-by:peter.levart at gmail.com,bourges.laurent at gmail.com >> >> ! src/share/classes/sun/util/logging/PlatformLogger.java >> ! test/sun/util/logging/PlatformLoggerTest.java > It seems that FX doesn't like this good work. Hm, The change was designed to be largely source-level compatible, but not binary-level. Is this JavaFX 8? Is it going to be re-compiled with recent JDK8? Is JavaFX 8 supposed to be compatible with both JDK7 and JDK8 ? If PlatformLogger API is supposed to be binary-compatible with non-JDK code, then we must revert this change and apply the binary-compatible one that uses switch statement. Regards, Peter > Caused by: java.lang.NoSuchMethodError: sun.util.logging.PlatformLogger.getLevel()I > at com.sun.javafx.css.parser.CSSParser.(CSSParser.java:164) > at com.sun.javafx.css.StyleManager.loadStylesheetUnPrivileged(StyleManager.java:854) > at com.sun.javafx.css.StyleManager.loadStylesheet(StyleManager.java:674) > at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1050) > at com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1020) > at com.sun.javafx.application.PlatformImpl$10.run(PlatformImpl.java:525) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:522) > at com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:474) > at javafx.scene.control.Control.(Control.java:82) > at helloworld.HelloWorld.start(HelloWorld.java:14) > at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:772) > at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260) > at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223) > at com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:220) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:220) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:94) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39) > at com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101) > ... 1 more > > From Alan.Bateman at oracle.com Wed Apr 3 14:01:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Apr 2013 15:01:11 +0100 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <515C2EC7.8020104@gmail.com> References: <20130328201656.E120C48477@hg.openjdk.java.net> <515C236E.8050600@oracle.com> <515C2EC7.8020104@gmail.com> Message-ID: <515C3627.5090906@oracle.com> On 03/04/2013 14:29, Peter Levart wrote: > : > > The change was designed to be largely source-level compatible, but not > binary-level. Is this JavaFX 8? Is it going to be re-compiled with > recent JDK8? Is JavaFX 8 supposed to be compatible with both JDK7 and > JDK8 ? > > If PlatformLogger API is supposed to be binary-compatible with non-JDK > code, then we must revert this change and apply the binary-compatible > one that uses switch statement. > I don't know what their expectation is but as the builds aren't integrated then I would expect at least some mix 'n match. Mandy might have more context. I think (but I'm not certain) that FX has been using the PlatformLogger for performance/startup reasons but I'm not certain if there is an "agreement" to provide both source and binary compatibility going forward. -Alan. From dan.xu at oracle.com Wed Apr 3 14:53:41 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 03 Apr 2013 07:53:41 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515B3361.6080503@oracle.com> References: <515A0759.5070602@oracle.com> <515B3361.6080503@oracle.com> Message-ID: <515C4275.80503@oracle.com> Hi Phil, Thank you for your good comments. Please see my answers below. On 04/02/2013 12:37 PM, Phil Race wrote: > The addition of @Native to various lines in SunGraphics2D.java look to > have pushed them >80 chars > and it looks to me as if previously the author took some care to limit > it. Moreover the indentation > of the comment block `on lines 127-130 is no longer aligned. > > Maybe it would be easier for that case to put the annotation on the > line above as in > @Native > static final int FOO ... > I use a program to automatically scan and modify files. And the length program is not noticed. I will fix the format issue. > > Otherwise looks OK, looks like you found files that had > @GenerateNativeHeaders that > didn't need it and cleaned those up, and in native sources removed > unneeded header > file imports too. > > I do have a background question about how it works. > There is an implication here that only the constants with @native might > be included in generated header files. Is that true ? > > Whereas if a class has native method declarations, then it doesn't need > these annotations, but you get all constants in the header file. Is > that right ? > If a class has native method declarations, then we don't need add anything. It will automatically generate the header file with all constants. If a class contains no native methods but have constants interested by native codes, then we need annotations. Previously, we use @GenerateNativeHeader. But now we need replace them with @Native. @Native works on the field level. Only constants annotated with @native will be added as an entry in the generated native header file. (But we currently have a bug on this. It generates a header file with all constants no matter a constant has @Native or not. It will be fixed soon.) In my change, I only add @Native annotation to constants interested by native codes. And if no such kind of constants and native methods declared, the fix does the clean-up and removes unnecessary header imports. Thanks! -Dan > -phil. > > On 4/1/13 3:16 PM, Dan Xu wrote: >> Hi All, >> >> In this fix, I have updated files in JDK libraries to use @Native >> annotation instead of @GenerateNativeHeader to mark classes that >> contain no native methods but constants used by native codes. >> >> @GenerateNativeHeader was added earlier in the development for >> JDK8."This has proved problematic for some core classes with respect >> to Jigsaw, since the use of such an annotation creates a compile-time >> dependency from the base module to the module containing javax.tools, >> and the base module should not have any dependencies." After >> switching to @Native annotation, the dependency problem will be >> solved as java.lang.annotation.Native is in the proposed base module. >> In addition, the annotation has been refined not to be on the class >> level but on the constants themselves, which also makes the generated >> header files much cleaner. >> >> This effort is part of JDK-8000404. After jdk libraries uptaking the >> annotation changes, @GenerateNativeHeader annotation will be removed >> completely. >> >> CCC: http://ccc.us.oracle.com/8000404 >> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ >> >> Thanks for your feedback! >> >> -Dan > From mandy.chung at oracle.com Wed Apr 3 14:59:34 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Apr 2013 07:59:34 -0700 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <515C3627.5090906@oracle.com> References: <20130328201656.E120C48477@hg.openjdk.java.net> <515C236E.8050600@oracle.com> <515C2EC7.8020104@gmail.com> <515C3627.5090906@oracle.com> Message-ID: <515C43D6.1040000@oracle.com> On 4/3/2013 7:01 AM, Alan Bateman wrote: > On 03/04/2013 14:29, Peter Levart wrote: >> : >> >> The change was designed to be largely source-level compatible, but >> not binary-level. Is this JavaFX 8? Is it going to be re-compiled >> with recent JDK8? Is JavaFX 8 supposed to be compatible with both >> JDK7 and JDK8 ? >> >> If PlatformLogger API is supposed to be binary-compatible with >> non-JDK code, then we must revert this change and apply the >> binary-compatible one that uses switch statement. >> > I don't know what their expectation is but as the builds aren't > integrated then I would expect at least some mix 'n match. Mandy might > have more context. I think (but I'm not certain) that FX has been > using the PlatformLogger for performance/startup reasons but I'm not > certain if there is an "agreement" to provide both source and binary > compatibility going forward. It depends on whether JavaFX 8 needs to run on older JDK. I believe not and I'll follow up with the FX team about this and update you. Alan - thanks for finding this out and filing the bug (8011380) Thanks Mandy From peter.levart at gmail.com Wed Apr 3 15:28:14 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 03 Apr 2013 17:28:14 +0200 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level In-Reply-To: <515C43D6.1040000@oracle.com> References: <20130328201656.E120C48477@hg.openjdk.java.net> <515C236E.8050600@oracle.com> <515C2EC7.8020104@gmail.com> <515C3627.5090906@oracle.com> <515C43D6.1040000@oracle.com> Message-ID: <515C4A8E.8000700@gmail.com> On 04/03/2013 04:59 PM, Mandy Chung wrote: > On 4/3/2013 7:01 AM, Alan Bateman wrote: >> On 03/04/2013 14:29, Peter Levart wrote: >>> : >>> >>> The change was designed to be largely source-level compatible, but >>> not binary-level. Is this JavaFX 8? Is it going to be re-compiled >>> with recent JDK8? Is JavaFX 8 supposed to be compatible with both >>> JDK7 and JDK8 ? >>> >>> If PlatformLogger API is supposed to be binary-compatible with >>> non-JDK code, then we must revert this change and apply the >>> binary-compatible one that uses switch statement. >>> >> I don't know what their expectation is but as the builds aren't >> integrated then I would expect at least some mix 'n match. Mandy >> might have more context. I think (but I'm not certain) that FX has >> been using the PlatformLogger for performance/startup reasons but I'm >> not certain if there is an "agreement" to provide both source and >> binary compatibility going forward. > > It depends on whether JavaFX 8 needs to run on older JDK. I believe > not and I'll follow up with the FX team about this and update you. > > Alan - thanks for finding this out and filing the bug (8011380) Another question is whether currently released JavaFX (2.2.7) or any older version is already using PlatformLogger and what if someone wants to just upgrade to JDK8 and keep using older JavaFX... Regards, Peter > Thanks > Mandy > From Alan.Bateman at oracle.com Wed Apr 3 15:54:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Apr 2013 16:54:26 +0100 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: <515C50B2.30108@oracle.com> On 02/04/2013 23:50, Mike Duigou wrote: > Hello again; > > I have updated the patch with the received review feedback. The revised webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > The important changes in this revision: > > - The behaviour of the readObject/writeObject serialization for both classes now more closely mirrors the behaviour of clone(). For ArrayList this means that the deserialized list has a capacity the same as the size. ie. as if trimToSize() was called. For HashMap, the opposite is true, the capacity is the same as was in effect when the object was serialized. (HashMap also tries to protect itself from nonsensical/harmful input). The implementation changes to serialization preserve forward and backward compatibility--all serialized objects are compatible with all implementations. I will file a spec change request for the addition of ", a power of 2" to the @serialData tag for this existing but previously unstated requirement. > > - Use of Arrays.fill has been reverted. I did change one fill case so that the loop can be optimized. (size field was being updated with each iteration). I very slightly expanded the docs. > > This is starting to look like a nice set of changes. > > Mike This does looks much nicer. For ArrayList.ensureCapacity then it might be useful to include a comment to make it clear that it's a no-op when the ArrayList is created with the default and ensureCapacity(n), for n < 10. I had to read it a few times to satisfy myself that it's right. One thing that I'm not sure about is HashMap.readObject using the bucket count from the serialized stream. We can't predict all usages of course but this has the potential for the table to be much bigger than we need. Otherwise I think this looks okay to me. I didn't quite get the reason for splitting out the update to the @serialData description but maybe you want to separate the changes to make it easy to backport. -Alan. From mandy.chung at oracle.com Wed Apr 3 15:56:17 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Apr 2013 08:56:17 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515BDCCF.1080003@gmail.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> <515BDCCF.1080003@gmail.com> Message-ID: <515C5121.9050501@oracle.com> Peter, Thanks. I misread your example and missed the fact that SM2 extends SM1. After seeing John's reply, I reread the example and realized the correctness issue you try to point out. I'll revise it and send out a new webrev. Mandy On 4/3/2013 12:39 AM, Peter Levart wrote: > On 04/03/2013 12:25 AM, Mandy Chung wrote: >> On 4/2/13 3:00 PM, Peter Levart wrote: >>> Hi Mandy, >>> >>> There could be: >>> >>> public class SM1 extends SecurityManager { >>> @Override >>> public void checkMemberAccess(Class clazz, int which) {... >>> >>> and: >>> >>> public class SM2 extends SM1 { ... // no checkMemberAccess override >>> >>> now if if you take SM2.class.getDeclaredMethod("checkMemberAccess", >>> ...) it will throw NoSuchMethodException, but the method is >>> overriden in >>> SM1. So I think it's better to use what John suggested (although not >>> using getDeclaredMethod, but getMethod instead): >>> >>> smgr.getClass().getMethod("checkMemberAccess", >>> ...).getDeclaringClass() == SecurityManager.class >> >> Are you concerned the overhead of an exception thrown that we should >> avoid? > > Hi Mandy, > > No, I was not thinking of performance. Just the correctness. > Class.getDeclaredMethod(name, ...) only considers methods "declared" > by the class (not inherited from a superclass - directy or > indirectly). But you could have, like in example above, a hierarchy: > SM2 extends SM1 extends SecurityManager where SM1 overrides the method > in SecurityManager and SM2 doesn't. Now if you try > SM2.class.getDeclaredMethod(), you will get NoSuchMethodException, but > that does not mean the method is not overriden - it is in class SM1. > > You could use getDeclaredMethod on the class and all superclasses > until reaching SecurityManager to find out if the method is overriden, > but it's fortunate that the method is public and so > Class.getMethod(name, ...) can be used which does exactly that and > already considers inheritance and overriding and returns the most > specific method in the hierarchy. Explicit search using > getDeclaredMethod() could skip searching the method in SecurityManager > class though, but: > > - negative answer via exception is slow > - getMethod() only searches among public methods (which are separately > cached in special array) and can therefore be faster if there is > relatively large share of non-public methods declared in the class > being searched. > > Here's a quick micro-benchmark for the common case (only one level of > subclassing the SecurityManager) and both variants (the method is > overriden in SecurityManager subclass or not): > > ############################################################## > # Java: 1.8.0-internal-peter_2013_01_16_13_44-b00 > # VM: OpenJDK 64-Bit Server VM 25.0-b14 (mixed mode) > # OS: Linux 3.7.9-104.fc17.x86_64 (amd64) > # CPUs: 8 (virtual) > # > #------------------------------------------------------------- > # GetDeclaredMethodOverridenSearch: run duration: 3,000 ms > # > # Warm up: > # 1 threads, Tavg = 327.59 ns/op (? = 0.00 ns/op) [ 327.59] > # 1 threads, Tavg = 326.06 ns/op (? = 0.00 ns/op) [ 326.06] > # Measure: > 1 threads, Tavg = 325.18 ns/op (? = 0.00 ns/op) [ 325.18] > # > #------------------------------------------------------------- > # GetPublicMethodOverridenSearch: run duration: 3,000 ms > # > # Warm up: > # 1 threads, Tavg = 325.69 ns/op (? = 0.00 ns/op) [ 325.69] > # 1 threads, Tavg = 329.67 ns/op (? = 0.00 ns/op) [ 329.67] > # Measure: > 1 threads, Tavg = 325.88 ns/op (? = 0.00 ns/op) [ 325.88] > # > #------------------------------------------------------------- > # GetDeclaredMethodNotOverridenSearch: run duration: 3,000 ms > # > # Warm up: > # 1 threads, Tavg = 1,405.84 ns/op (? = 0.00 ns/op) [ 1,405.84] > # 1 threads, Tavg = 1,371.14 ns/op (? = 0.00 ns/op) [ 1,371.14] > # Measure: > 1 threads, Tavg = 1,358.02 ns/op (? = 0.00 ns/op) [ 1,358.02] > # > #------------------------------------------------------------- > # GetPublicMethodNotOverridenSearch: run duration: 3,000 ms > # > # Warm up: > # 1 threads, Tavg = 557.50 ns/op (? = 0.00 ns/op) [ 557.50] > # 1 threads, Tavg = 553.05 ns/op (? = 0.00 ns/op) [ 553.05] > # Measure: > 1 threads, Tavg = 554.59 ns/op (? = 0.00 ns/op) [ 554.59] > # > #------------------------------------------------------------- > # END. > ############################################################## > > > Here's the source of the test: > > > public class MethodSearchTest extends TestRunner { > > static final Class[] paramTypes = {Class.class, int.class}; > > static class SMOverriden extends SecurityManager { > @Override > public void checkMemberAccess(Class clazz, int which) { > } > } > > static class SMNotOverriden extends SecurityManager { > } > > public static class GetDeclaredMethodOverridenSearch extends Test { > @Override > protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, > DevNull devNull3, DevNull devNull4, DevNull devNull5) { > while (loop.nextIteration()) { > try { > SMOverriden.class.getDeclaredMethod("checkMemberAccess", paramTypes); > devNull1.yield(true); > } > catch (NoSuchMethodException e) { > devNull1.yield(false); > } > } > } > } > > public static class GetPublicMethodOverridenSearch extends Test { > @Override > protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, > DevNull devNull3, DevNull devNull4, DevNull devNull5) { > while (loop.nextIteration()) { > try { > devNull1.yield(SMOverriden.class.getMethod("checkMemberAccess", > paramTypes).getDeclaringClass() != SecurityManager.class); > } > catch (NoSuchMethodException e) { > throw new Error(e); > } > } > } > } > > public static class GetDeclaredMethodNotOverridenSearch extends Test { > @Override > protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, > DevNull devNull3, DevNull devNull4, DevNull devNull5) { > while (loop.nextIteration()) { > try { > SMNotOverriden.class.getDeclaredMethod("checkMemberAccess", paramTypes); > devNull1.yield(true); > } > catch (NoSuchMethodException e) { > devNull1.yield(false); > } > } > } > } > > public static class GetPublicMethodNotOverridenSearch extends Test { > @Override > protected void doLoop(Loop loop, DevNull devNull1, DevNull devNull2, > DevNull devNull3, DevNull devNull4, DevNull devNull5) { > while (loop.nextIteration()) { > try { > devNull1.yield(SMNotOverriden.class.getMethod("checkMemberAccess", > paramTypes).getDeclaringClass() != SecurityManager.class); > } > catch (NoSuchMethodException e) { > throw new Error(e); > } > } > } > } > > public static void main(String[] args) throws Exception { > startTests(); > doTest(GetDeclaredMethodOverridenSearch.class, 3000L, 1, 1, 1); > doTest(GetPublicMethodOverridenSearch.class, 3000L, 1, 1, 1); > doTest(GetDeclaredMethodNotOverridenSearch.class, 3000L, 1, 1, 1); > doTest(GetPublicMethodNotOverridenSearch.class, 3000L, 1, 1, 1); > endTests(); > } > } > > > Regards, Peter > >> >> Mandy > From kellyohair at gmail.com Tue Apr 2 01:12:29 2013 From: kellyohair at gmail.com (O'Hair Kelly) Date: Mon, 1 Apr 2013 18:12:29 -0700 Subject: RFR: JDK-8011187 : http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ In-Reply-To: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> References: <8AC4000F-2F94-4CFC-ACF6-FFEB4DC4A714@oracle.com> Message-ID: <577AB702-64A8-4564-B852-3CCDEC18E6D5@gmail.com> Looks fine. -kto On Apr 1, 2013, at 1:19 PM, Mike Duigou wrote: > Hello all; > > Another changeset for review in the series "JDK-8009683 Running regression tests with make". Many of the targets in jdk/test/Makefile are currently unused or were never used. These targets will be removed: > > perftest > packtest > vmsqe_* > jck* > > I have checked with Kelky O'Hair and Kumar Srinivasan and received confirmation that they do not believe the targets are being used by anyone. A webrev of the removal: > > http://cr.openjdk.java.net/~mduigou/JDK-8011187/0/webrev/ > > Mike From lance.andersen at oracle.com Wed Apr 3 16:15:12 2013 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 3 Apr 2013 12:15:12 -0400 Subject: Review request for 8011393 - javadoc typo in SerialClob.truncate Message-ID: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> Hi all Need a reviewer for the correction of the following typo in SerialClob.java which is bug 8011393 hg diff SerialClob.java diff -r e6c3b8e74e50 src/share/classes/javax/sql/rowset/serial/SerialClob.java --- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java Tue Apr 02 10:12:20 2013 -0700 +++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java Wed Apr 03 12:06:01 2013 -0400 @@ -508,7 +508,7 @@ * * @param length the length, in bytes, to which the CLOB * value should be truncated - * @throws SerialLException if there is an error accessing the + * @throws SerialException if there is an error accessing the * CLOB value; * if the {@code free} method had been previously called on this object */ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Wed Apr 3 16:38:02 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 03 Apr 2013 09:38:02 -0700 Subject: Code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and java.lang.reflect.Type In-Reply-To: <515BE7C2.9020101@gmail.com> References: <515BD9E3.5050303@oracle.com> <515BE7C2.9020101@gmail.com> Message-ID: <515C5AEA.3060007@oracle.com> Hi Peter, On 04/03/2013 01:26 AM, Peter Levart wrote: > Hi Joe, > > Why not using StringBuilder instead of StringBuffer in > Class.toGenericString ? No reason. Thanks for catching this; I'll use StringBuilder in the final push. Thanks, -Joe > > Regards, Peter > > On 04/03/2013 09:27 AM, Joe Darcy wrote: >> Hello, >> >> This is combined code review request for >> >> 6298888 (reflect) Add toGenericString to java.lang.Class and >> getTypeName to java.lang.reflect.Type >> 6992705 (reflect) Include modifiers to Class's toGenericString() >> http://cr.openjdk.java.net/~darcy/6298888.0/ >> >> In brief, a "toGenericString" method is added to java.lang.Class, >> analogous to the toGenericString methods in Field, Method, and >> Constructor. A default method for "getTypeName" is added to >> java.lang.reflect Type, which allows the code used to implement >> toGenericString to be cleaned up. >> >> There is some general maintenance on this area as well. In >> particular, the correct specification change intended to be done as >> part of >> >> 8004979: java.lang.reflect.Modifier.toString should include >> "default" >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f68aca1000 >> >> is included; the "default" modifier should appear after "abstract" >> and not at the very end of the modifier list. >> >> Thanks, >> >> -Joe > From joe.darcy at oracle.com Wed Apr 3 16:44:10 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 03 Apr 2013 09:44:10 -0700 Subject: Review request for 8011393 - javadoc typo in SerialClob.truncate In-Reply-To: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> References: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> Message-ID: <515C5C5A.7050701@oracle.com> Lance, Looks fine; approved. Cheers, -Joe On 04/03/2013 09:15 AM, Lance Andersen - Oracle wrote: > Hi all > > Need a reviewer for the correction of the following typo in SerialClob.java which is bug 8011393 > > > hg diff SerialClob.java > diff -r e6c3b8e74e50 src/share/classes/javax/sql/rowset/serial/SerialClob.java > --- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java Tue Apr 02 10:12:20 2013 -0700 > +++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java Wed Apr 03 12:06:01 2013 -0400 > @@ -508,7 +508,7 @@ > * > * @param length the length, in bytes, to which the CLOB > * value should be truncated > - * @throws SerialLException if there is an error accessing the > + * @throws SerialException if there is an error accessing the > * CLOB value; > * if the {@code free} method had been previously called on this object > */ > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From lance.andersen at oracle.com Wed Apr 3 16:48:02 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 03 Apr 2013 16:48:02 +0000 Subject: hg: jdk8/tl/jdk: 8011393: Typo in javadoc for SerialClob.truncate Message-ID: <20130403164823.05E3048593@hg.openjdk.java.net> Changeset: 27ae4f9c7826 Author: lancea Date: 2013-04-03 12:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27ae4f9c7826 8011393: Typo in javadoc for SerialClob.truncate Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/serial/SerialClob.java From naoto.sato at oracle.com Wed Apr 3 17:33:05 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 03 Apr 2013 17:33:05 +0000 Subject: hg: jdk8/tl/jdk: 7091601: Arabic Locale: can not set type of digit in application level Message-ID: <20130403173325.7041448597@hg.openjdk.java.net> Changeset: 9a6ef3391f32 Author: naoto Date: 2013-04-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a6ef3391f32 7091601: Arabic Locale: can not set type of digit in application level Reviewed-by: okutsu ! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java From mandy.chung at oracle.com Wed Apr 3 17:49:04 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Apr 2013 10:49:04 -0700 Subject: Review request for 8011393 - javadoc typo in SerialClob.truncate In-Reply-To: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> References: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> Message-ID: <515C6B90.80902@oracle.com> Looks fine. You may want to use {@code CLOB} to replace ... Mandy On 4/3/2013 9:15 AM, Lance Andersen - Oracle wrote: > Hi all > > Need a reviewer for the correction of the following typo in SerialClob.java which is bug 8011393 > > > hg diff SerialClob.java > diff -r e6c3b8e74e50 src/share/classes/javax/sql/rowset/serial/SerialClob.java > --- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java Tue Apr 02 10:12:20 2013 -0700 > +++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java Wed Apr 03 12:06:01 2013 -0400 > @@ -508,7 +508,7 @@ > * > * @param length the length, in bytes, to which the CLOB > * value should be truncated > - * @throws SerialLException if there is an error accessing the > + * @throws SerialException if there is an error accessing the > * CLOB value; > * if the {@code free} method had been previously called on this object > */ > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From mandy.chung at oracle.com Wed Apr 3 18:49:28 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Apr 2013 11:49:28 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> Message-ID: <515C79B8.1070201@oracle.com> This version has corrected to use Class.getMethod to determine if the checkMemberAccess method is overridden in the subclass: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/ thanks Mandy On 4/2/2013 9:25 PM, John Rose wrote: > So getDM has a bug and getM is correct wrt inheritance. Thanks Peter! From joe.darcy at oracle.com Wed Apr 3 19:27:27 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 03 Apr 2013 19:27:27 +0000 Subject: hg: jdk8/tl/langtools: 8011052: Add DEFAULT to javax.lang.model.Modifier Message-ID: <20130403192732.5A9ED48599@hg.openjdk.java.net> Changeset: 0d47e6131490 Author: darcy Date: 2013-04-03 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d47e6131490 8011052: Add DEFAULT to javax.lang.model.Modifier Reviewed-by: abuckley, jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/javax/lang/model/element/Modifier.java ! test/tools/javac/processing/model/element/TestExecutableElement.java From jeroen at sumatra.nl Wed Apr 3 19:52:14 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 3 Apr 2013 19:52:14 +0000 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <515C79B8.1070201@oracle.com> References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> , <515C79B8.1070201@oracle.com> Message-ID: Hi, Thanks for this. This is a really great change. I reviewed the changes and my only comment is that there is a typo in java/lang/reflect/Field.java ("scurity"). Somewhat unrelated (but relevant for my implementation of CallerSensitive), but would it be possible to mark java.lang.Runtime as final, or at least make the CallerSensitive methods final? The interaction between CallerSensitive and method overriding is non trivial, so IMO it is best avoided. Thanks, Jeroen ________________________________________ From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Mandy Chung [mandy.chung at oracle.com] Sent: Wednesday, April 03, 2013 8:49 PM To: John Rose Cc: Christian Thalinger; core-libs-dev Subject: Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK This version has corrected to use Class.getMethod to determine if the checkMemberAccess method is overridden in the subclass: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/ thanks Mandy On 4/2/2013 9:25 PM, John Rose wrote: > So getDM has a bug and getM is correct wrt inheritance. Thanks Peter! From lance.andersen at oracle.com Wed Apr 3 20:16:03 2013 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 3 Apr 2013 16:16:03 -0400 Subject: Review request for 8011393 - javadoc typo in SerialClob.truncate In-Reply-To: <515C6B90.80902@oracle.com> References: <267AB508-7BB4-4B00-B55F-4675E8B4349A@oracle.com> <515C6B90.80902@oracle.com> Message-ID: <02A77C7C-3863-4508-A4C1-E660AC36E395@oracle.com> Hi Mandy, Thank you for the suggestion and the review. I have been making some of those changes as I have been going forward. I agree, that would be better to use {@code} and will look to continue to clean those things up. Would be great if we had an automated tool to help as I am sure there is a lot of code that could be cleaned up besides JDBC :-) Thank you again. Best Lance On Apr 3, 2013, at 1:49 PM, Mandy Chung wrote: > Looks fine. You may want to use {@code CLOB} to replace ... > > Mandy > > On 4/3/2013 9:15 AM, Lance Andersen - Oracle wrote: >> Hi all >> >> Need a reviewer for the correction of the following typo in SerialClob.java which is bug 8011393 >> >> >> hg diff SerialClob.java >> diff -r e6c3b8e74e50 src/share/classes/javax/sql/rowset/serial/SerialClob.java >> --- a/src/share/classes/javax/sql/rowset/serial/SerialClob.java Tue Apr 02 10:12:20 2013 -0700 >> +++ b/src/share/classes/javax/sql/rowset/serial/SerialClob.java Wed Apr 03 12:06:01 2013 -0400 >> @@ -508,7 +508,7 @@ >> * >> * @param length the length, in bytes, to which the CLOB >> * value should be truncated >> - * @throws SerialLException if there is an error accessing the >> + * @throws SerialException if there is an error accessing the >> * CLOB value; >> * if the {@code free} method had been previously called on this object >> */ >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From john.r.rose at oracle.com Wed Apr 3 21:56:27 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 3 Apr 2013 14:56:27 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> , <515C79B8.1070201@oracle.com> Message-ID: On Apr 3, 2013, at 12:52 PM, Jeroen Frijters wrote: > Thanks for this. This is a really great change. > > I reviewed the changes and my only comment is that there is a typo in java/lang/reflect/Field.java ("scurity"). Thanks! > Somewhat unrelated (but relevant for my implementation of CallerSensitive), but would it be possible to mark java.lang.Runtime as final, or at least make the CallerSensitive methods final? > > The interaction between CallerSensitive and method overriding is non trivial, so IMO it is best avoided. That is very true. We are working on separating those two patterns. Making Runtime and/or Runtime.load* final is an API change, which is harder to do than an implementation change. Given that Runtime. is private, it seems to me that there is no way to execute an override of those load methods, even if one could (deviously) load a subclass into the JVM. It would be valid behavior, I think, for the JVM to quietly refuse to override them, because there would be no way to observe the refusal. Note that the technique of a private method is the recommended way to prevent instantiation of subclasses, and is used throughout the JDK. This should be sufficient to prevent undesired interactions with @CS and overrides. What do you think? ? John From brent.christian at oracle.com Wed Apr 3 22:26:43 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 03 Apr 2013 15:26:43 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: <515CACA3.5020601@oracle.com> A couple small things: HashMap: It might be nice to have a comment or two on the new, dual-purpose of 'threshold': perhaps in the comments for inflateTable(), and/or at the field declaration. ArrayList: Is there an extra set of ()'s around (minCapacity > DEFAULT_CAPACITY) ? Thanks, -Brent On 4/2/13 3:50 PM, Mike Duigou wrote: > Hello again; > > I have updated the patch with the received review feedback. The revised webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > The important changes in this revision: > > - The behaviour of the readObject/writeObject serialization for both classes now more closely mirrors the behaviour of clone(). For ArrayList this means that the deserialized list has a capacity the same as the size. ie. as if trimToSize() was called. For HashMap, the opposite is true, the capacity is the same as was in effect when the object was serialized. (HashMap also tries to protect itself from nonsensical/harmful input). The implementation changes to serialization preserve forward and backward compatibility--all serialized objects are compatible with all implementations. I will file a spec change request for the addition of ", a power of 2" to the @serialData tag for this existing but previously unstated requirement. > > - Use of Arrays.fill has been reverted. I did change one fill case so that the loop can be optimized. (size field was being updated with each iteration). I very slightly expanded the docs. > > This is starting to look like a nice set of changes. > > Mike > > On Apr 1 2013, at 21:44 , Mike Duigou wrote: > >> Hello all; >> >> Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ >> >> It is currently unchanged from the last posted changeset for 7143928. >> >> Mike >> >> On Apr 1 2013, at 19:00 , Mike Duigou wrote: >> >>> Hello all; >>> >>> I have posted an updated version of the empty ArrayList and HashMap patch. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ >>> >>> This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. >>> >>> For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. >>> >>> Mike >>> >>> On Mar 26 2013, at 17:25 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. >>>> >>>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ >>>> >>>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. >>>> >>>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). >>>> >>>> Mike >>> >> > From mike.duigou at oracle.com Thu Apr 4 00:00:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 3 Apr 2013 17:00:39 -0700 Subject: RFR : 8010948 : Add conversion functional interfaces Message-ID: <968AAA46-6AAE-4113-9CED-448F3E86EA6A@oracle.com> Hello all; Another set of functional interfaces for review for the soon-to-be-arriving-in-TL-repo lambda libraries. http://cr.openjdk.java.net/~mduigou/JDK-8010948/0/webrev/ These interfaces are Functions between the core primitive types (double, int, long) used by the lambda libraries. Methods providing the equivalent of the widening and narrowing primitive conversions may be added in a later patch. Mike From mike.duigou at oracle.com Thu Apr 4 03:03:17 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 04 Apr 2013 03:03:17 +0000 Subject: hg: jdk8/tl: 8011350: hgforest.sh uses non-POSIX sh features that may fail with some shells Message-ID: <20130404030317.61E35485B0@hg.openjdk.java.net> Changeset: 575f2ca947ab Author: mduigou Date: 2013-04-03 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/575f2ca947ab 8011350: hgforest.sh uses non-POSIX sh features that may fail with some shells Reviewed-by: tbell, katleman, dholmes ! common/bin/hgforest.sh From mandy.chung at oracle.com Thu Apr 4 04:52:06 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 03 Apr 2013 21:52:06 -0700 Subject: Review request: 8011380: FX dependency on PlatformLogger broken Message-ID: <515D06F6.5050500@oracle.com> Peter, Laurent, History and details are described below. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ I add back the getLevel(int), setLevel(int) and isLoggable(int) methods but marked deprecated and also revert the static final variables to resolve the regression. They can be removed when JavaFX transitions to use the Level enums (I'll file one issue for FX to use PlatformLogger.Level and one for core-libs to remove the deprecated methods). The performance overhead is likely small since it's direct mapping from int to the Level enum that was used in one of your previous performance measurement. Laurent - you have a patch to add isLoggable calls in the awt/swing code. Can you check if there is any noticeable performance difference? I also take the opportunity to reconsider what JavaLoggerProxy.getLevel() should return when it's a custom Level. Use of logging is expected not to cause any fatal error to the running application. The previous patch throwing IAE needs to be fixed. I propose to return the first Level.intValue() >= the custom level value since the level value is used to evaluate if it's loggable. History and details: JavaFX 8 has converted to use sun.util.logging.PlatformLogger (https://javafx-jira.kenai.com/browse/RT-24458). I was involved in the early discussion but wasn't aware of the decision made. Thanks to Alan for catching this regression out before it's integrated to jdk8. jfxrt.jar is cobundled with jdk8 during the installer build step. My build doesn't build installer and thus we didn't see this regression. I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no reference to sun.util.logging. I have a method finder tool (planning to include it in jdk8) to search for use of PlatformLogger.getLevel and it did find 2 references from jdk8/lib/ext/jfxrt.jar. JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build (https://javafx-jira.kenai.com/browse/RT-27794) soon (currently it's built with JDK 7). As soon as JavaFX code are changed to reference PlatformLogger.Level enum instead, we can remove the deprecated methods and change the PlatformLogger constants. JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to it. In any case, JavaFX 2.2.x only runs either bundled with a corresponding JDK 7u release, or as a standalone library for JDK 6 only. Thanks Mandy From jeroen at sumatra.nl Thu Apr 4 06:00:28 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 4 Apr 2013 06:00:28 +0000 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> , <515C79B8.1070201@oracle.com> Message-ID: John Rose wrote: > Making Runtime and/or Runtime.load* final is an API change, which is > harder to do than an implementation change. I worry about compatibility a lot and my (selfish) reasoning is that it is better for the CCC to break someones code (there has to be someone somewhere that uses a subclass of Runtime, in combination with Unsafe.allocateInstance()) than for my implementation specific behavior to break the code. I remembered that making the methods final isn't sufficient, because then they can still implement an interface method, which is also not great. Note that this isn't a critical issue for me. Most code uses the static methods in System anyway and my current code also doesn't special case Runtime (meaning that it will use the normal stack walk mechanism). > Given that Runtime. is private, it seems to me that there is no > way to execute an override of those load methods, even if one could > (deviously) load a subclass into the JVM. It would be valid behavior, I > think, for the JVM to quietly refuse to override them, because there > would be no way to observe the refusal. Not for Java programs, but there are a lot of Java-like programs that assume the reference implementation. > Note that the technique of a private method is the recommended > way to prevent instantiation of subclasses, and is used throughout the > JDK. Given the ability to create constructorless subclasses, it really should be combined with making the class final. My current rules for @CallerID (which unlike @CallerSensitive is not just about semantics, but also about implementation strategy) allow it only to be used on static methods and instance methods in final classes (in theory constructors would also be allowed, but I didn't implement that since I didn't encounter any that were worthwhile). An implicit rule is that a @CallerID instance methods may not implement an interface method. Another thought that occurred to me was that there should probably be a test that goes through rt.jar and makes sure no ACC_BRIDGE or ACC_SYNTHETIC methods call @CallerSensitive methods. Regards, Jeroen From peter.levart at gmail.com Thu Apr 4 07:52:03 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 04 Apr 2013 09:52:03 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515D06F6.5050500@oracle.com> References: <515D06F6.5050500@oracle.com> Message-ID: <515D3123.1040406@gmail.com> HI Mandy, On 04/04/2013 06:52 AM, Mandy Chung wrote: > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > I add back the getLevel(int), setLevel(int) and isLoggable(int) > methods but marked deprecated and also revert the static final > variables to resolve the regression. They can be removed when JavaFX > transitions to use the Level enums (I'll file one issue for FX to use > PlatformLogger.Level and one for core-libs to remove the deprecated > methods). The performance overhead is likely small since it's direct > mapping from int to the Level enum that was used in one of your > previous performance measurement. I think that it is not strictly necessary to restore the PlatformLogger static final fields back to int type. They are compile-time constants and so are already "baked" into the classes compiled with older version of PlatformLogger. Am I right? The only problem I see if fields are kept as Level type is when JFX is compiled with JDK8 and then run on JDK7... But changing them temporarily back to int is a conservative approach and I support it. > > Laurent - you have a patch to add isLoggable calls in the awt/swing > code. Can you check if there is any noticeable performance difference? > > I also take the opportunity to reconsider what > JavaLoggerProxy.getLevel() should return when it's a custom Level. Use > of logging is expected not to cause any fatal error to the running > application. The previous patch throwing IAE needs to be fixed. I > propose to return the first Level.intValue() >= the custom level value > since the level value is used to evaluate if it's loggable. That's a good compromise. > > History and details: > JavaFX 8 has converted to use sun.util.logging.PlatformLogger > (https://javafx-jira.kenai.com/browse/RT-24458). I was involved in the > early discussion but wasn't aware of the decision made. Thanks to Alan > for catching this regression out before it's integrated to jdk8. > jfxrt.jar is cobundled with jdk8 during the installer build step. My > build doesn't build installer and thus we didn't see this regression. > > I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 > references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no > reference to sun.util.logging. > > I have a method finder tool (planning to include it in jdk8) to search > for use of PlatformLogger.getLevel and it did find 2 references from > jdk8/lib/ext/jfxrt.jar. > > JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build > (https://javafx-jira.kenai.com/browse/RT-27794) soon (currently it's > built with JDK 7). As soon as JavaFX code are changed to reference > PlatformLogger.Level enum instead, we can remove the deprecated > methods and change the PlatformLogger constants. What do you think of deprecating the PlatformLogger constants altogether (regardless of their type). The code using them could be migrated to use PlatformLogger.Level enum members directly and if "PlatformLogger.Level.INFO" looks to verbose, static imports can help or there could be some more helper methods added to PlatformLogger that would minimize the need to access the constants like: isInfoLoggable(); isWarningLoggable(); ... Regards, Peter > > JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to > it. In any case, JavaFX 2.2.x only runs either bundled with a > corresponding JDK 7u release, or as a standalone library for JDK 6 only. > > Thanks > Mandy > From bourges.laurent at gmail.com Thu Apr 4 08:15:41 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 4 Apr 2013 10:15:41 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515D3123.1040406@gmail.com> References: <515D06F6.5050500@oracle.com> <515D3123.1040406@gmail.com> Message-ID: Mandy, Peter, here are my comments: On 04/04/2013 06:52 AM, Mandy Chung wrote: > > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > I add back the getLevel(int), setLevel(int) and isLoggable(int) methods > but marked deprecated and also revert the static final variables to resolve > the regression. They can be removed when JavaFX transitions to use the > Level enums (I'll file one issue for FX to use PlatformLogger.Level and one > for core-libs to remove the deprecated methods). The performance overhead > is likely small since it's direct mapping from int to the Level enum that > was used in one of your previous performance measurement. > > Look OK for me; the Level valueOf(int level) is back and is basically an efficient switch case that performs well (performance overhead is minor). I hope other projects will be built again soon to remove such workarrounds. > > I think that it is not strictly necessary to restore the PlatformLogger > static final fields back to int type. They are compile-time constants and > so are already "baked" into the classes compiled with older version of > PlatformLogger. Am I right? The only problem I see if fields are kept as > Level type is when JFX is compiled with JDK8 and then run on JDK7... But > changing them temporarily back to int is a conservative approach and I > support it. > I think you're right: static constants are copied into class bytecode; maybe the old API (int level in method signatures) could be kept and marked deprecated but the class will become quite big (double API: one with int and one with Level) !! > > > Laurent - you have a patch to add isLoggable calls in the awt/swing code. > Can you check if there is any noticeable performance difference? > > The awt patch consists in adding missing isLoggable statements to avoid object creation (string concatenations) and method calls (Component.toString() ...). Maybe I should also check that calls to log(msg, varargs) are using isLoggable() tests to avoid Object[] creation due to varargs: what is your opinion ? > > I also take the opportunity to reconsider what JavaLoggerProxy.getLevel() > should return when it's a custom Level. Use of logging is expected not to > cause any fatal error to the running application. The previous patch > throwing IAE needs to be fixed. I propose to return the first > Level.intValue() >= the custom level value since the level value is used to > evaluate if it's loggable. > > > That's a good compromise. > I think custom logger are ILLEGAL in the PlatformLogger API and must be discarded. Maybe comments should explain such design decision and returning an IllegalStateException is OK for me. > > > History and details: > JavaFX 8 has converted to use sun.util.logging.PlatformLogger ( > https://javafx-jira.kenai.com/browse/RT-24458). I was involved in the > early discussion but wasn't aware of the decision made. Thanks to Alan for > catching this regression out before it's integrated to jdk8. jfxrt.jar is > cobundled with jdk8 during the installer build step. My build doesn't > build installer and thus we didn't see this regression. > > I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 > references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no > reference to sun.util.logging. > > I have a method finder tool (planning to include it in jdk8) to search for > use of PlatformLogger.getLevel and it did find 2 references from > jdk8/lib/ext/jfxrt.jar. > > Personally I doubt getLevel() method is useful: why not use isLoggable() instead !! maybe getLevel() should become @deprecated too. > > JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build ( > https://javafx-jira.kenai.com/browse/RT-27794) soon (currently it's built > with JDK 7). As soon as JavaFX code are changed to reference > PlatformLogger.Level enum instead, we can remove the deprecated methods and > change the PlatformLogger constants. > > Great, any idea about their roadmap ? do you think other projects are also depending on PlatformLogger (JMX ...) and may be impacted ? > > What do you think of deprecating the PlatformLogger constants altogether > (regardless of their type). The code using them could be migrated to use > PlatformLogger.Level enum members directly and if " > PlatformLogger.Level.INFO" looks to verbose, static imports can help or > there could be some more helper methods added to PlatformLogger that would > minimize the need to access the constants like: > > isInfoLoggable(); > isWarningLoggable(); > ... > It starts to mimic log4j / slf4j / logback syntax I love but I think it will change so many files that I think it is a waste of time for now. I vote for adding such useful shortcuts in the new API but not change other methods. Cheers, Laurent From bourges.laurent at gmail.com Thu Apr 4 11:47:44 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 4 Apr 2013 13:47:44 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> Message-ID: Dear all, I just realized there is another problem with PlatformLogger log statements: XBaseWindow: public boolean grabInput() { grabLog.fine("Grab input on {0}", this); ... } This calls the PlatformLogger.fine( varargs): public void fine(String msg, Object... params) { logger.doLog(FINE, msg, params); } Doing so, the JVM creates a new Object[] instance to provide params as varargs. I would recommend using isLoggable() test to avoid such waste if the log is disabled (fine, finer, finest ...). Do you want me to provide a new patch related to this problem ? Does somebody have an idea to automatically analyze the JDK code and detect missing isLoggable statements ... Regards, Laurent 2013/4/3 Laurent Bourg?s > Anthony, > > could you tell me once it is in the OpenJDK8 repository ? > I would then perform again profiling tests to check if there is no more > missing isLoggable() statements. > > Once JMX and other projects switch to PlatformLogger, I could check again. > > Maybe I could write a small java code checker (pmd rule) to test if there > is missing isLoggable() statements wrapping PlatformLogger log statements. > Any idea about how to reuse java parser to do so ? > > Regards, > > Laurent > > 2013/4/2 Anthony Petrov > >> Looks fine to me as well. Thanks for fixing this, Laurent. >> >> Let's wait a couple more days in case Net or Swing folks want to review >> the fix. After that I'll push it to the repository. >> >> -- >> best regards, >> Anthony >> >> >> On 4/2/2013 15:35, Laurent Bourg?s wrote: >> >>> Here is the updated patch: >>> http://jmmc.fr/~bourgesl/**share/webrev-8010297.2/ >>> >>> Fixed inconsistencies between FINE / FINER log statements: >>> - XScrollbarPeer >>> - XWindowPeer >>> >>> Laurent >>> >>> 2013/4/2 Anthony Petrov >> anthony.petrov at oracle.**com >> >>> >>> >>> 1. Sergey: I believe this is for purposes of better formating the >>> log output and making it more readable by separating or highlighting >>> some sections. I don't think this should be changed. >>> >>> 2. Laurent: can you please address this issue and send us a new >>> patch? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>> On 4/1/2013 16:08, Sergey Bylokhov wrote: >>> >>> >>> Hi, Anthony >>> Only two comments: >>> 1 Why we need some special text in the log output like "***" and >>> "###" >>> 2 XScrollbarPeer.java: >>> >>> + if (log.isLoggable(__**PlatformLogger.FINEST)) { >>> >>> + log.finer("KeyEvent on scrollbar: " + event); >>> + } >>> >>> >>> >>> On 4/1/13 12:20 PM, Anthony Petrov wrote: >>> >>> Awt, Swing, Net engineers, >>> >>> Could anyone review the fix please? For your convenience: >>> >>> Bug: http://bugs.sun.com/view_bug._**_do?bug_id=8010297 >>> >>> > >>> >>> Fix: >>> http://cr.openjdk.java.net/~__**anthony/8-55-isLoggable-__** >>> 8010297.0/ >>> >> 8010297.0/ >>> > >>> >>> -- best regards, >>> Anthony >>> >>> On 3/22/2013 2:26, Anthony Petrov wrote: >>> >>> Hi Laurent, >>> >>> The fix looks great to me. Thank you very much. >>> >>> We still need at least one review, though. Hopefully >>> net-dev@ and/or swing-dev@ folks might help us out a >>> bit. >>> >>> -- best regards, >>> Anthony >>> >>> On 3/20/2013 15:10, Anthony Petrov wrote: >>> >>> Hi Laurent, >>> >>> Thanks for the patch. I've filed a bug at: >>> http://bugs.sun.com/view_bug._**_do?bug_id=8010297 >>> >>> >>> > >>> (should be available in a day or two) >>> >>> and published a webrev generated from your patch at: >>> http://cr.openjdk.java.net/~__** >>> anthony/8-55-isLoggable-__**8010297.0/ >>> >> 7Eanthony/8-55-isLoggable-**8010297.0/ >>> > >>> >>> >>> I'm also copying swing-dev@ and net-dev@ because the >>> fix affects those areas too. I myself will review >>> the fix a bit later but am sending it now for other >>> folks to take a look at it. >>> >>> On 3/19/2013 15:29, Laurent Bourg?s wrote: >>> >>> I am sorry I started modifying PlatformLogger >>> and reverted changes to this class as it is >>> another topic to be discussed later: isLoggable >>> performance and waste due to HashMap>> Level> leads to Integer allocations (boxing). >>> >>> >>> I saw your message to core-libs-dev@, so I just >>> dropped all changes to the PlatformLogger from this >>> patch. >>> >>> Finally, I have another question related to the >>> WrapperGenerator class: it generates a lot of >>> empty log statements (XEvent): >>> >>> log >>> >> repository.grepcode.com/java/_**_root/jdk/openjdk/6-b14/sun/__** >>> awt/X11/XWrapperBase.java#__**XWrapperBase.0log >>> >> repository.grepcode.com/java/**root/jdk/openjdk/6-b14/sun/** >>> awt/X11/XWrapperBase.java#**XWrapperBase.0log >>> >>.finest >>> >> repository.grepcode.com/java/_**_root/jdk/openjdk/6-b14/java/_** >>> _util/logging/Logger.java#__**Logger.finest%28java.lang.__**String%29 >>> >> repository.grepcode.com/java/**root/jdk/openjdk/6-b14/java/** >>> util/logging/Logger.java#**Logger.finest%28java.lang.**String%29 >>> >>(""); >>> >>> >>> Is it really useful to have such statements ? I >>> would keep logs with non empty messages only. >>> >>> See WrapperGenerator:753: >>> String s_log = >>> (generateLog?"log.finest(\"\")**__;":""); >>> >>> >>> >>> I believe they're used for log formatting purposes >>> to separate numerous events in a log (e.g. think of >>> mouse-move events - there can be hundreds of them in >>> a raw). >>> >>> >>> Please note that the hg export format is not that >>> useful unless you're assigned an OpenJDK id already >>> (please see Dalibor's message for details) because I >>> can't import it directly. So for the time being you >>> could send just raw patches (i.e. the output of hg >>> diff only - and there's no need to commit your >>> changes in this case). Also, please note that the >>> mailing lists strip attachments. The reason I got it >>> is because I was listed in To: of your message. So >>> when sending patches you can: >>> 1) post them inline, or >>> 2) attach them and add a person to To: of your >>> message, or >>> 3) upload them somewhere on the web. >>> However, it would be best if you could generate a >>> webrev for your changes and upload it somewhere. >>> Currently this is the standard format for reviewing >>> fixes in OpenJDK. >>> >>> -- best regards, >>> Anthony >>> >>> >>> Regards, >>> Laurent >>> >>> >>> >>> 2013/3/19 Laurent Bourg?s >>> >> >>> > >>> >> >>> >>> >>> >>> >>> Hi antony, >>> >>> FYI I started reviewing and fixing all >>> PlatformLogger use cases (not >>> too many as I thought first) mainly used by >>> awt / swing projects to >>> provide you a patch on latest JDK8 source >>> code: >>> >>> I am adding the log level check when it is >>> missing: >>> if (...log.isLoggable(__**PlatformLogger.xxx)) >>> { >>> >>> log... >>> } >>> >>> I will not change the String + operations to >>> use the message format >>> syntax in this patch. >>> >>> Do you accept such patch / proposed >>> contribution ? >>> >>> Regards, >>> Laurent >>> >>> >>> 2013/3/18 Laurent Bourg?s >>> >> >>> > >>> >> >>> >>> >>> >>> >>> Hi antony, >>> >>> 2 different things: >>> 1/ PlatformLogger was patched (doLog >>> method) to avoid string >>> operations (message formatting) for >>> disabled logs (patch >>> submiited on JDK8 and JDK7u): >>> >>> http://mail.openjdk.java.net/_**_pipermail/jdk7u-dev/2012-__** >>> April/002751.html >>> >>> >> pipermail/jdk7u-dev/2012-**April/002751.html >>> > >>> >>> >>> 2/ I looked 2 hours ago on JDK7u AND >>> JDK8 source codes and both >>> still have: >>> - log statements WITHOUT log level check >>> : if >>> (log.isLoggable(__** >>> PlatformLogger.FINE)) >>> >>> log.fine(...); >>> - string operations (+) in log calls >>> that could be improved >>> using the message format syntax (String >>> + args): for example, >>> avoid using PlatformLogger.fine(String + >>> ...) in favor of using >>> PlatformLogger.fine(String msg, >>> Object... params) >>> >>> I reported in my previous mail several >>> cases where the >>> isLoggable() call is missing and leads >>> to useless String >>> operations but also method calls >>> (Component.paramString() for >>> example). >>> >>> Finally, I also provided other possible >>> cases (using grep); >>> maybe there is a better alternative to >>> find all occurences of >>> String operations in log calls. >>> >>> Regards, >>> Laurent >>> >>> 2013/3/18 Anthony Petrov >>> >> >>> > >>> >> >>> >>> >>> >>> >>> Hi Laurent, >>> >>> Normally we fix an issue in JDK 8 >>> first, and then back-port >>> the fix to a 7u release. You're >>> saying that in JDK 8 the >>> problem isn't reproducible anymore. >>> Can you please >>> investigate (using the Mercurial >>> history log) what exact fix >>> resolved it in JDK 8? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 03/18/13 15:09, Laurent Bourg?s >>> wrote: >>> >>> Dear all, >>> >>> I run recently netbeans profiler >>> on my swing application >>> (Aspro2: >>> http://www.jmmc.fr/aspro) under >>> linux x64 platform and I >>> figured out >>> that a lot of char[] instances >>> are coming from String + >>> operator called >>> by sun.awt.X11 code. >>> >>> I looked at PlatformLogger >>> source code but found not way >>> to disable it >>> completely: maybe an empty >>> logger implementation could >>> be interesting to >>> be used during profiling or >>> normal use (not debugging). >>> Apparently JDK8 provides some >>> patchs to avoid String >>> creation when the >>> logger is disabled (level). >>> >>> However, I looked also to the >>> sun.awt code (jdk7u >>> repository) to see the >>> origin of the string allocations: >>> XDecoratedPeer: >>> public void >>> handleFocusEvent(XEvent xev) { >>> ... >>> * >>> focusLog.finer("Received focus event on shell: >>> " + xfe); >>> * } >>> >>> public boolean >>> requestWindowFocus(long time, >>> boolean timeProvided) { >>> ... >>> * >>> focusLog.finest("Real native focused >>> window: " + >>> realNativeFocusedWindow + >>> "\nKFM's focused window: " + >>> focusedWindow); >>> *... >>> * >>> focusLog.fine("Requesting focus to " + (this == >>> toFocus ? "this >>> window" : toFocus)); >>> *... >>> } >>> >>> XBaseWindow: >>> public void xSetBounds(int >>> x, int y, int width, int >>> height) { >>> ... >>> * insLog.fine("Setting >>> bounds on " + this + " to >>> (" + x + ", " + >>> y + "), " + width + "x" + >>> height); >>> *} >>> >>> XNetProtocol: >>> boolean doStateProtocol() { >>> ... >>> * >>> stateLog.finer("____**doStateProtocol() returns " + >>> >>> res); >>> *} >>> >>> XSystemTrayPeer: >>> XSystemTrayPeer(SystemTray >>> target) { >>> ... >>> * log.fine(" check if >>> system tray is available. >>> selection owner: >>> " + selection_owner); >>> *} >>> void >>> addTrayIcon(XTrayIconPeer tiPeer) throws >>> AWTException { >>> ... >>> * log.fine(" send >>> SYSTEM_TRAY_REQUEST_DOCK >>> message to owner: " + >>> selection_owner); >>> *} >>> >>> XFramePeer: >>> public void >>> handlePropertyNotify(XEvent xev) { >>> ... >>> >>> stateLog.finer("State is the same: " + state); >>> } >>> >>> However I only give here few >>> cases but certainly others >>> are still >>> present in the source code; >>> maybe findbugs or netbeans >>> warnings could >>> help you finding all of them. >>> >>> I advocate the amount of waste >>> (GC) is not very >>> important but String >>> conversion are also calling >>> several toString() methods >>> that can be >>> costly (event, Frame, window ...) >>> >>> Finally, I ran few grep commands >>> on the sun.awt.X11 code >>> (jdk7u) and you >>> can look at them to see all >>> string + operations related >>> to log statements. >>> >>> PS: I may help fixing the source >>> code but I have no idea >>> how to >>> collaborate (provide a patch ?) >>> >>> Regards, >>> Laurent Bourg?s >>> >>> >>> >>> >>> >>> >>> -- Best regards, Sergey. >>> >>> >>> > From anthony.petrov at oracle.com Thu Apr 4 12:05:03 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 04 Apr 2013 16:05:03 +0400 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> Message-ID: <515D6C6F.30104@oracle.com> Yes, this makes sense. Do you want to update your fix for 8010297 to include these changes as well? -- best regards, Anthony On 04/04/13 15:47, Laurent Bourg?s wrote: > Dear all, > > I just realized there is another problem with PlatformLogger log statements: > XBaseWindow: > public boolean grabInput() { > grabLog.fine("Grab input on {0}", this); > ... > } > > This calls the PlatformLogger.fine( varargs): > public void fine(String msg, Object... params) { > logger.doLog(FINE, msg, params); > } > > Doing so, the JVM creates a new Object[] instance to provide params as > varargs. > > I would recommend using isLoggable() test to avoid such waste if the log > is disabled (fine, finer, finest ...). > > Do you want me to provide a new patch related to this problem ? > > Does somebody have an idea to automatically analyze the JDK code and > detect missing isLoggable statements ... > > Regards, > Laurent > > 2013/4/3 Laurent Bourg?s > > > Anthony, > > could you tell me once it is in the OpenJDK8 repository ? > I would then perform again profiling tests to check if there is no > more missing isLoggable() statements. > > Once JMX and other projects switch to PlatformLogger, I could check > again. > > Maybe I could write a small java code checker (pmd rule) to test if > there is missing isLoggable() statements wrapping PlatformLogger log > statements. Any idea about how to reuse java parser to do so ? > > Regards, > > Laurent > > 2013/4/2 Anthony Petrov > > > Looks fine to me as well. Thanks for fixing this, Laurent. > > Let's wait a couple more days in case Net or Swing folks want to > review the fix. After that I'll push it to the repository. > > -- > best regards, > Anthony > > > On 4/2/2013 15:35, Laurent Bourg?s wrote: > > Here is the updated patch: > http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ > > > Fixed inconsistencies between FINE / FINER log statements: > - XScrollbarPeer > - XWindowPeer > > Laurent > > 2013/4/2 Anthony Petrov > >> > > > 1. Sergey: I believe this is for purposes of better > formating the > log output and making it more readable by separating or > highlighting > some sections. I don't think this should be changed. > > 2. Laurent: can you please address this issue and send > us a new patch? > > -- > best regards, > Anthony > > > On 4/1/2013 16:08, Sergey Bylokhov wrote: > > > Hi, Anthony > Only two comments: > 1 Why we need some special text in the log output > like "***" and > "###" > 2 XScrollbarPeer.java: > > + if > (log.isLoggable(____PlatformLogger.FINEST)) { > > + log.finer("KeyEvent on scrollbar: " + > event); > + } > > > > On 4/1/13 12:20 PM, Anthony Petrov wrote: > > Awt, Swing, Net engineers, > > Could anyone review the fix please? For your > convenience: > > Bug: > http://bugs.sun.com/view_bug.____do?bug_id=8010297 > > > > > Fix: > http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ > > > > > -- best regards, > Anthony > > On 3/22/2013 2:26, Anthony Petrov wrote: > > Hi Laurent, > > The fix looks great to me. Thank you very much. > > We still need at least one review, though. > Hopefully > net-dev@ and/or swing-dev@ folks might help > us out a bit. > > -- best regards, > Anthony > > On 3/20/2013 15:10, Anthony Petrov wrote: > > Hi Laurent, > > Thanks for the patch. I've filed a bug at: > http://bugs.sun.com/view_bug.____do?bug_id=8010297 > > > > > (should be available in a day or two) > > and published a webrev generated from > your patch at: > http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ > > > > > > I'm also copying swing-dev@ and > net-dev@ because the > fix affects those areas too. I myself > will review > the fix a bit later but am sending it > now for other > folks to take a look at it. > > On 3/19/2013 15:29, Laurent Bourg?s wrote: > > I am sorry I started modifying > PlatformLogger > and reverted changes to this class > as it is > another topic to be discussed > later: isLoggable > performance and waste due to > HashMap Level> leads to Integer allocations > (boxing). > > > I saw your message to core-libs-dev@, > so I just > dropped all changes to the > PlatformLogger from this > patch. > > Finally, I have another question > related to the > WrapperGenerator class: it > generates a lot of > empty log statements (XEvent): > > log > > >>.finest > > >>(""); > > > Is it really useful to have such > statements ? I > would keep logs with non empty > messages only. > > See WrapperGenerator:753: > String s_log = > > (generateLog?"log.finest(\"\")____;":""); > > > > I believe they're used for log > formatting purposes > to separate numerous events in a log > (e.g. think of > mouse-move events - there can be > hundreds of them in > a raw). > > > Please note that the hg export format > is not that > useful unless you're assigned an > OpenJDK id already > (please see Dalibor's message for > details) because I > can't import it directly. So for the > time being you > could send just raw patches (i.e. the > output of hg > diff only - and there's no need to > commit your > changes in this case). Also, please > note that the > mailing lists strip attachments. The > reason I got it > is because I was listed in To: of your > message. So > when sending patches you can: > 1) post them inline, or > 2) attach them and add a person to To: > of your > message, or > 3) upload them somewhere on the web. > However, it would be best if you could > generate a > webrev for your changes and upload it > somewhere. > Currently this is the standard format > for reviewing > fixes in OpenJDK. > > -- best regards, > Anthony > > > Regards, > Laurent > > > > 2013/3/19 Laurent Bourg?s > > > > ____com > > >>> > > Hi antony, > > FYI I started reviewing and > fixing all > PlatformLogger use cases (not > too many as I thought first) > mainly used by > awt / swing projects to > provide you a patch on latest > JDK8 source code: > > I am adding the log level check > when it is > missing: > if > (...log.isLoggable(____PlatformLogger.xxx)) { > > log... > } > > I will not change the String + > operations to > use the message format > syntax in this patch. > > Do you accept such patch / proposed > contribution ? > > Regards, > Laurent > > > 2013/3/18 Laurent Bourg?s > > > > ____com > > >>> > > Hi antony, > > 2 different things: > 1/ PlatformLogger was > patched (doLog > method) to avoid string > operations (message > formatting) for > disabled logs (patch > submiited on JDK8 and JDK7u): > http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html > > > > > > > 2/ I looked 2 hours ago on > JDK7u AND > JDK8 source codes and both > still have: > - log statements WITHOUT > log level check > : if > > (log.isLoggable(____PlatformLogger.FINE)) > > log.fine(...); > - string operations (+) in > log calls > that could be improved > using the message format > syntax (String > + args): for example, > avoid using > PlatformLogger.fine(String + > ...) in favor of using > PlatformLogger.fine(String msg, > Object... params) > > I reported in my previous > mail several > cases where the > isLoggable() call is > missing and leads > to useless String > operations but also method > calls > (Component.paramString() for > example). > > Finally, I also provided > other possible > cases (using grep); > maybe there is a better > alternative to > find all occurences of > String operations in log calls. > > Regards, > Laurent > > 2013/3/18 Anthony Petrov > > > > ____com > > >>> > > Hi Laurent, > > Normally we fix an > issue in JDK 8 > first, and then back-port > the fix to a 7u > release. You're > saying that in JDK 8 the > problem isn't > reproducible anymore. > Can you please > investigate (using the > Mercurial > history log) what exact fix > resolved it in JDK 8? > > -- > best regards, > Anthony > > On 03/18/13 15:09, > Laurent Bourg?s > wrote: > > Dear all, > > I run recently > netbeans profiler > on my swing application > (Aspro2: > http://www.jmmc.fr/aspro) under > linux x64 platform and I > figured out > that a lot of > char[] instances > are coming from String + > operator called > by sun.awt.X11 code. > > I looked at > PlatformLogger > source code but found not way > to disable it > completely: maybe > an empty > logger implementation could > be interesting to > be used during > profiling or > normal use (not debugging). > Apparently JDK8 > provides some > patchs to avoid String > creation when the > logger is disabled > (level). > > However, I looked > also to the > sun.awt code (jdk7u > repository) to see the > origin of the > string allocations: > XDecoratedPeer: > public void > handleFocusEvent(XEvent xev) { > ... > * > focusLog.finer("Received focus event on shell: > " + xfe); > * } > > public boolean > requestWindowFocus(long time, > boolean timeProvided) { > ... > * > focusLog.finest("Real native focused > window: " + > > realNativeFocusedWindow + > "\nKFM's focused window: " + > focusedWindow); > *... > * > focusLog.fine("Requesting focus to " + (this == > toFocus ? "this > window" : toFocus)); > *... > } > > XBaseWindow: > public void > xSetBounds(int > x, int y, int width, int > height) { > ... > * > insLog.fine("Setting > bounds on " + this + " to > (" + x + ", " + > y + "), " + width + > "x" + height); > *} > > XNetProtocol: > boolean > doStateProtocol() { > ... > * > stateLog.finer("______doStateProtocol() returns " + > > res); > *} > > XSystemTrayPeer: > > XSystemTrayPeer(SystemTray > target) { > ... > * log.fine(" > check if > system tray is available. > selection owner: > " + selection_owner); > *} > void > addTrayIcon(XTrayIconPeer tiPeer) > throws > AWTException { > ... > * log.fine(" > send > SYSTEM_TRAY_REQUEST_DOCK > message to owner: " + > selection_owner); > *} > > XFramePeer: > public void > handlePropertyNotify(XEvent xev) { > ... > > stateLog.finer("State is the same: " + state); > } > > However I only give > here few > cases but certainly others > are still > present in the > source code; > maybe findbugs or netbeans > warnings could > help you finding > all of them. > > I advocate the > amount of waste > (GC) is not very > important but String > conversion are also > calling > several toString() methods > that can be > costly (event, > Frame, window ...) > > Finally, I ran few > grep commands > on the sun.awt.X11 code > (jdk7u) and you > can look at them to > see all > string + operations related > to log statements. > > PS: I may help > fixing the source > code but I have no idea > how to > collaborate > (provide a patch ?) > > Regards, > Laurent Bourg?s > > > > > > > -- Best regards, Sergey. > > > > From bourges.laurent at gmail.com Thu Apr 4 12:08:29 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 4 Apr 2013 14:08:29 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <515D6C6F.30104@oracle.com> References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> Message-ID: Ok, I can provide an updated patch after finding / fixing all usages. Probably in 1 or 2 days, Laurent 2013/4/4 Anthony Petrov > Yes, this makes sense. Do you want to update your fix for 8010297 to > include these changes as well? > > -- > best regards, > Anthony > > > On 04/04/13 15:47, Laurent Bourg?s wrote: > >> Dear all, >> >> I just realized there is another problem with PlatformLogger log >> statements: >> XBaseWindow: >> public boolean grabInput() { >> grabLog.fine("Grab input on {0}", this); >> ... >> } >> >> This calls the PlatformLogger.fine( varargs): >> public void fine(String msg, Object... params) { >> logger.doLog(FINE, msg, params); >> } >> >> Doing so, the JVM creates a new Object[] instance to provide params as >> varargs. >> >> I would recommend using isLoggable() test to avoid such waste if the log >> is disabled (fine, finer, finest ...). >> >> Do you want me to provide a new patch related to this problem ? >> >> Does somebody have an idea to automatically analyze the JDK code and >> detect missing isLoggable statements ... >> >> Regards, >> Laurent >> >> 2013/4/3 Laurent Bourg?s > >> >> >> >> Anthony, >> >> could you tell me once it is in the OpenJDK8 repository ? >> I would then perform again profiling tests to check if there is no >> more missing isLoggable() statements. >> >> Once JMX and other projects switch to PlatformLogger, I could check >> again. >> >> Maybe I could write a small java code checker (pmd rule) to test if >> there is missing isLoggable() statements wrapping PlatformLogger log >> statements. Any idea about how to reuse java parser to do so ? >> >> Regards, >> >> Laurent >> >> 2013/4/2 Anthony Petrov > >> >> >> >> Looks fine to me as well. Thanks for fixing this, Laurent. >> >> Let's wait a couple more days in case Net or Swing folks want to >> review the fix. After that I'll push it to the repository. >> >> -- >> best regards, >> Anthony >> >> >> On 4/2/2013 15:35, Laurent Bourg?s wrote: >> >> Here is the updated patch: >> http://jmmc.fr/~bourgesl/__**share/webrev-8010297.2/ >> >> > >> >> >> Fixed inconsistencies between FINE / FINER log statements: >> - XScrollbarPeer >> - XWindowPeer >> >> Laurent >> >> 2013/4/2 Anthony Petrov > >> > >> > >> >> >>> >> >> >> 1. Sergey: I believe this is for purposes of better >> formating the >> log output and making it more readable by separating or >> highlighting >> some sections. I don't think this should be changed. >> >> 2. Laurent: can you please address this issue and send >> us a new patch? >> >> -- >> best regards, >> Anthony >> >> >> On 4/1/2013 16:08, Sergey Bylokhov wrote: >> >> >> Hi, Anthony >> Only two comments: >> 1 Why we need some special text in the log output >> like "***" and >> "###" >> 2 XScrollbarPeer.java: >> >> + if >> (log.isLoggable(____**PlatformLogger.FINEST)) { >> >> >> + log.finer("KeyEvent on scrollbar: " + >> event); >> + } >> >> >> >> On 4/1/13 12:20 PM, Anthony Petrov wrote: >> >> Awt, Swing, Net engineers, >> >> Could anyone review the fix please? For your >> convenience: >> >> Bug: >> http://bugs.sun.com/view_bug._**___do?bug_id=8010297 >> >> > >> >> >> >> >> >> >> Fix: >> http://cr.openjdk.java.net/~__** >> __anthony/8-55-isLoggable-____**8010297.0/ >> > **8010297.0/ >> > >> > **8010297.0/ >> > 8010297.0/ >> >> >> >> -- best regards, >> Anthony >> >> On 3/22/2013 2:26, Anthony Petrov wrote: >> >> Hi Laurent, >> >> The fix looks great to me. Thank you very >> much. >> >> We still need at least one review, though. >> Hopefully >> net-dev@ and/or swing-dev@ folks might help >> us out a bit. >> >> -- best regards, >> Anthony >> >> On 3/20/2013 15:10, Anthony Petrov wrote: >> >> Hi Laurent, >> >> Thanks for the patch. I've filed a bug >> at: >> http://bugs.sun.com/view_bug._**___do?bug_id=8010297 >> >> > >> >> >> >> >> >> >> (should be available in a day or two) >> >> and published a webrev generated from >> your patch at: >> http://cr.openjdk.java.net/~__** >> __anthony/8-55-isLoggable-____**8010297.0/ >> > **8010297.0/ >> > >> > **8010297.0/ >> > 8010297.0/ >> >> >> >> >> I'm also copying swing-dev@ and >> net-dev@ because the >> fix affects those areas too. I myself >> will review >> the fix a bit later but am sending it >> now for other >> folks to take a look at it. >> >> On 3/19/2013 15:29, Laurent Bourg?s >> wrote: >> >> I am sorry I started modifying >> PlatformLogger >> and reverted changes to this class >> as it is >> another topic to be discussed >> later: isLoggable >> performance and waste due to >> HashMap> Level> leads to Integer allocations >> (boxing). >> >> >> I saw your message to core-libs-dev@, >> so I just >> dropped all changes to the >> PlatformLogger from this >> patch. >> >> Finally, I have another question >> related to the >> WrapperGenerator class: it >> generates a lot of >> empty log statements (XEvent): >> >> log >> > repository.grepcode.com/java/_**___root/jdk/openjdk/6-b14/sun/** >> ____awt/X11/XWrapperBase.java#**____XWrapperBase.0log >> > *_root/jdk/openjdk/6-b14/sun/__**awt/X11/XWrapperBase.java#__** >> XWrapperBase.0log >> > >> >> > *_root/jdk/openjdk/6-b14/sun/__**awt/X11/XWrapperBase.java#__** >> XWrapperBase.0log >> > root/jdk/openjdk/6-b14/sun/**awt/X11/XWrapperBase.java#** >> XWrapperBase.0log >> >>>.finest >> > repository.grepcode.com/java/_**___root/jdk/openjdk/6-b14/** >> java/____util/logging/Logger.**java#____Logger.finest%28java.** >> lang.____String%29 >> > *_root/jdk/openjdk/6-b14/java/_**_util/logging/Logger.java#__** >> Logger.finest%28java.lang.__**String%29 >> > >> >> > *_root/jdk/openjdk/6-b14/java/_**_util/logging/Logger.java#__** >> Logger.finest%28java.lang.__**String%29 >> > root/jdk/openjdk/6-b14/java/**util/logging/Logger.java#** >> Logger.finest%28java.lang.**String%29 >> >>>(""); >> >> >> Is it really useful to have such >> statements ? I >> would keep logs with non empty >> messages only. >> >> See WrapperGenerator:753: >> String s_log = >> >> (generateLog?"log.finest(\"\")**____;":""); >> >> >> >> >> I believe they're used for log >> formatting purposes >> to separate numerous events in a log >> (e.g. think of >> mouse-move events - there can be >> hundreds of them in >> a raw). >> >> >> Please note that the hg export format >> is not that >> useful unless you're assigned an >> OpenJDK id already >> (please see Dalibor's message for >> details) because I >> can't import it directly. So for the >> time being you >> could send just raw patches (i.e. the >> output of hg >> diff only - and there's no need to >> commit your >> changes in this case). Also, please >> note that the >> mailing lists strip attachments. The >> reason I got it >> is because I was listed in To: of your >> message. So >> when sending patches you can: >> 1) post them inline, or >> 2) attach them and add a person to To: >> of your >> message, or >> 3) upload them somewhere on the web. >> However, it would be best if you could >> generate a >> webrev for your changes and upload it >> somewhere. >> Currently this is the standard format >> for reviewing >> fixes in OpenJDK. >> >> -- best regards, >> Anthony >> >> >> Regards, >> Laurent >> >> >> >> 2013/3/19 Laurent Bourg?s >> > com > >> > >> >> >> > ____com >> >> > >> >>>> >> >> Hi antony, >> >> FYI I started reviewing and >> fixing all >> PlatformLogger use cases (not >> too many as I thought first) >> mainly used by >> awt / swing projects to >> provide you a patch on latest >> JDK8 source code: >> >> I am adding the log level check >> when it is >> missing: >> if >> (...log.isLoggable(____**PlatformLogger.xxx)) { >> >> >> log... >> } >> >> I will not change the String + >> operations to >> use the message format >> syntax in this patch. >> >> Do you accept such patch / >> proposed >> contribution ? >> >> Regards, >> Laurent >> >> >> 2013/3/18 Laurent Bourg?s >> > com > >> > >> >> >> > ____com >> >> > >> >>>> >> >> Hi antony, >> >> 2 different things: >> 1/ PlatformLogger was >> patched (doLog >> method) to avoid string >> operations (message >> formatting) for >> disabled logs (patch >> submiited on JDK8 and JDK7u): >> http://mail.openjdk.java.net/_** >> ___pipermail/jdk7u-dev/2012-__**__April/002751.html >> > **April/002751.html >> > >> >> >> > **April/002751.html >> > April/002751.html >> >> >> >> >> 2/ I looked 2 hours ago on >> JDK7u AND >> JDK8 source codes and both >> still have: >> - log statements WITHOUT >> log level check >> : if >> >> (log.isLoggable(____**PlatformLogger.FINE)) >> >> >> log.fine(...); >> - string operations (+) in >> log calls >> that could be improved >> using the message format >> syntax (String >> + args): for example, >> avoid using >> PlatformLogger.fine(String + >> ...) in favor of using >> PlatformLogger.fine(String >> msg, >> Object... params) >> >> I reported in my previous >> mail several >> cases where the >> isLoggable() call is >> missing and leads >> to useless String >> operations but also method >> calls >> (Component.paramString() for >> example). >> >> Finally, I also provided >> other possible >> cases (using grep); >> maybe there is a better >> alternative to >> find all occurences of >> String operations in log >> calls. >> >> Regards, >> Laurent >> >> 2013/3/18 Anthony Petrov >> > com > >> > >> >> >> > ____com >> >> > >> >>>> >> >> Hi Laurent, >> >> Normally we fix an >> issue in JDK 8 >> first, and then back-port >> the fix to a 7u >> release. You're >> saying that in JDK 8 the >> problem isn't >> reproducible anymore. >> Can you please >> investigate (using the >> Mercurial >> history log) what exact fix >> resolved it in JDK 8? >> >> -- >> best regards, >> Anthony >> >> On 03/18/13 15:09, >> Laurent Bourg?s >> wrote: >> >> Dear all, >> >> I run recently >> netbeans profiler >> on my swing application >> (Aspro2: >> http://www.jmmc.fr/aspro) under >> linux x64 platform and I >> figured out >> that a lot of >> char[] instances >> are coming from String + >> operator called >> by sun.awt.X11 code. >> >> I looked at >> PlatformLogger >> source code but found not way >> to disable it >> completely: maybe >> an empty >> logger implementation could >> be interesting to >> be used during >> profiling or >> normal use (not debugging). >> Apparently JDK8 >> provides some >> patchs to avoid String >> creation when the >> logger is disabled >> (level). >> >> However, I looked >> also to the >> sun.awt code (jdk7u >> repository) to see >> the >> origin of the >> string allocations: >> XDecoratedPeer: >> public void >> handleFocusEvent(XEvent xev) { >> ... >> * >> focusLog.finer("Received focus event on shell: >> " + xfe); >> * } >> >> public boolean >> requestWindowFocus(long time, >> boolean >> timeProvided) { >> ... >> * >> focusLog.finest("Real native focused >> window: " + >> >> realNativeFocusedWindow + >> "\nKFM's focused window: " + >> focusedWindow); >> *... >> * >> focusLog.fine("Requesting focus to " + (this == >> toFocus ? "this >> window" : toFocus)); >> *... >> } >> >> XBaseWindow: >> public void >> xSetBounds(int >> x, int y, int width, int >> height) { >> ... >> * >> insLog.fine("Setting >> bounds on " + this + " to >> (" + x + ", " + >> y + "), " + width + >> "x" + height); >> *} >> >> XNetProtocol: >> boolean >> doStateProtocol() { >> ... >> * >> stateLog.finer("______**doStateProtocol() >> returns " + >> >> >> res); >> *} >> >> XSystemTrayPeer: >> >> XSystemTrayPeer(SystemTray >> target) { >> ... >> * log.fine(" >> check if >> system tray is available. >> selection owner: >> " + selection_owner); >> *} >> void >> addTrayIcon(XTrayIconPeer tiPeer) >> throws >> AWTException { >> ... >> * log.fine(" >> send >> SYSTEM_TRAY_REQUEST_DOCK >> message to owner: " + >> selection_owner); >> *} >> >> XFramePeer: >> public void >> handlePropertyNotify(XEvent xev) { >> ... >> >> stateLog.finer("State is the same: " + >> state); >> } >> >> However I only give >> here few >> cases but certainly others >> are still >> present in the >> source code; >> maybe findbugs or netbeans >> warnings could >> help you finding >> all of them. >> >> I advocate the >> amount of waste >> (GC) is not very >> important but String >> conversion are also >> calling >> several toString() methods >> that can be >> costly (event, >> Frame, window ...) >> >> Finally, I ran few >> grep commands >> on the sun.awt.X11 code >> (jdk7u) and you >> can look at them to >> see all >> string + operations related >> to log statements. >> >> PS: I may help >> fixing the source >> code but I have no idea >> how to >> collaborate >> (provide a patch ?) >> >> Regards, >> Laurent Bourg?s >> >> >> >> >> >> >> -- Best regards, Sergey. >> >> >> >> >> From bourges.laurent at gmail.com Thu Apr 4 13:44:48 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 4 Apr 2013 15:44:48 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: I updated both patched pisces code and benchmarks: http://jmmc.fr/~bourgesl/share/java2d-pisces/ Few results comparing ThreadLocal vs ConcurrentLinkedQueue usage: OpenJDK 8 PATCH ThreadLocal mode: Testing file /home/bourgesl/libs/openjdk/mapbench/test/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 2671 ms 2 threads and 20 loops per thread, time: 3239 ms 4 threads and 20 loops per thread, time: 6043 ms OpenJDK 8 PATCH ConcurrentLinkedQueue mode: Testing file /home/bourgesl/libs/openjdk/mapbench/test/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 2779 ms 2 threads and 20 loops per thread, time: 3416 ms 4 threads and 20 loops per thread, time: 6153 ms Oracle JDK8 Ductus: Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 1894 ms 2 threads and 20 loops per thread, time: 3905 ms 4 threads and 20 loops per thread, time: 7485 ms OpenJDK 8 PATCH ThreadLocal mode: Testing file /home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser 1 threads and 20 loops per thread, time: 24211 ms 2 threads and 20 loops per thread, time: 30955 ms *4 threads and 20 loops per thread, time: 67715 ms* OpenJDK 8 PATCH ConcurrentLinkedQueue mode: Testing file /home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser 1 threads and 20 loops per thread, time: 25984 ms 2 threads and 20 loops per thread, time: 33131 ms *4 threads and 20 loops per thread, time: 75343 ms * Oracle JDK8 Ductus: Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213} 1 threads and 20 loops per thread, time: 20911 ms 2 threads and 20 loops per thread, time: 39297 ms 4 threads and 20 loops per thread, time: 103392 ms ConcurrentLinkedQueue add a small overhead but not too much vs ThreadLocal. Is it possible to test efficiently if the current thread is EDT then I could use ThreadLocal for EDT at least ? it must be very fast because getThreadContext() is called once per rendering operation so it is a performance bottleneck. For example: Testing file /home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser TL: 4 threads and 20 loops per thread, time: 67715 ms CLQ: 4 threads and 20 loops per thread, time: 75343 ms Changes: - use ThreadLocal or ConcurrentLinkedQueue to get a renderer context (vars / cache) - use first RendererContext (dirty / clean arrays) members instead of using IntArrayCache / FloatArrayCache for performance reasons (dedicated to large dynamic arrays) TBD: - recycle pisces class i.e. keep only one instance per class (Renderer, Stroker ...) to avoid totally GC overhead (several thousands per MapBench test). Moreover, these are very small objects / short lived i.e. l so it should stay in ThreadLocalAllocator (TLAB) but when I use verbose:gc or jmap -histo these are present and represents megabytes: [bourgesl at jmmc-laurent ~]$ jmap -histo:live 21628 | grep pisces 5: 50553 6470784 sun.java2d.pisces.Renderer 9: 29820 3578400 sun.java2d.pisces.Stroker 11: 49795 3186880 sun.java2d.pisces.PiscesCache 12: 49794 1991760 sun.java2d.pisces.PiscesTileGenerator 13: 49793 1991720 sun.java2d.pisces.Renderer$ScanlineIterator 14: 29820 1431360 sun.java2d.pisces.PiscesRenderingEngine$NormalizingPathIterator 52: 40 1280 sun.java2d.pisces.IntArrayCache 94: 20 640 sun.java2d.pisces.FloatArrayCache 121: 8 320 [Lsun.java2d.pisces.IntArrayCache; 127: 4 320 sun.java2d.pisces.RendererContext 134: 4 256 sun.java2d.pisces.Curve 154: 4 160 [Lsun.java2d.pisces.FloatArrayCache; 155: 4 160 sun.java2d.pisces.RendererContext$RendererData 156: 4 160 sun.java2d.pisces.RendererContext$StrokerData 157: 4 160 sun.java2d.pisces.Stroker$PolyStack 208: 3 72 sun.java2d.pisces.PiscesRenderingEngine$NormMode 256: 1 32 [Lsun.java2d.pisces.PiscesRenderingEngine$NormMode; 375: 1 16 sun.java2d.pisces.PiscesRenderingEngine 376: 1 16 sun.java2d.pisces.RendererContext$1 Regards, Laurent 2013/4/3 Laurent Bourg?s > Thanks for your valueable feedback! > > Here is the current status of my patch alpha version: >>> http://jmmc.fr/~bourgesl/share/java2d-pisces/ >>> >>> There is still a lot to be done: clean-up, stats, pisces class instance >>> recycling (renderer, stroker ...) and of course sizing correctly initial >>> arrays (dirty or clean) in the RendererContext (thread local storage). >>> For performance reasons, I am using now RendererContext members first >>> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays). >>> >> >> Thank you Laurent, those are some nice speedups. >> > I think it can still be improved: I hope to make it as fast as ductus or > maybe more (I have several idea for aggressive optimizations) but the main > improvement consist in reusing memory (like C / C++ does) to avoid wasted > memory / GC overhead in concurrent environment. > > >> About the thread local storage, that is a sensible choice for highly >> concurrent systems, at the same time, web containers normally complain about >> orphaned thread locals created by an application and not cleaned up. >> Not sure if ones created at the core libs level get special treatment, >> but in general, I guess it would be nice to have some way to clean them up. >> > > You're right that's why my patch is not ready ! > > I chose ThreadLocal for simplicity and clarity but I see several issues: > 1/ Web container: ThreadLocal must be clean up when stopping an > application to avoid memory leaks (application becomes unloadable due to > classloader leaks) > 2/ ThreadLocal access is the fastest way to get the RendererContext as it > does not require any lock (unsynchronized); As I get the RendererContext > once per rendering request, I think the ThreadLocal can be replaced by a > thread-safe ConcurrentLinkedQueue but it may become a > performance bootleneck > 3/ Using a ConcurrentLinkedQueue requires an efficient / > proper cache eviction to free memory (Weak or Soft references ?) or using > statistics (last usage timestamp, usage counts) > > Any other idea (core-libs) to have an efficient thread context in a web > container ? > > I'm not familiar with the API, but is there any way to clean them up when >> the graphics2d gets disposed of? >> > > The RenderingEngine is instanciated by the JVM once and I do not see in > the RenderingEngine interface any way to perform callbacks for warmup / > cleanup ... nor access to the Graphics RenderingHints (other RFE for tuning > purposes) > > >> A web application has no guarantee to see the same thread ever again >> during his life, so thread locals have to be cleaned right away. >> > > I advocate ThreadLocal can lead to wasted memory as only few concurrent > threads can really use their RendererContext instance while others can > simply answer web requests => let's use a > ConcurrentLinkedQueue with a proper cache eviction. > > >> >> Either that, or see if there is any way to store the array caches in a >> global structure backed by a concurrent collection to reduce/eliminate >> contention. >> > > Yes, it is a interesting alternative to benchmark. > > Regards, > Laurent > From peter.levart at gmail.com Thu Apr 4 15:34:09 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 04 Apr 2013 17:34:09 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515D06F6.5050500@oracle.com> References: <515D06F6.5050500@oracle.com> Message-ID: <515D9D71.80407@gmail.com> Hi Mandy, Laurent, What do you think of this variation (changed just PlatformLogger, other files exactly equal to your webrev): http://dl.dropbox.com/u/101777488/jdk8-tl/PlatformLogger/webrev.enumapi.02/index.html Moved the nearest >= intValue search to PlatformLogger.Level.valueOf(int) since it is used also by deprecated API. With this change the same logic is used for mapping from j.u.l.Level to PlatformLogger.Level in all cases. I wonder if PlatformLogger.Level.intValue() should be exposed as public API. Currently it is used by the test (which is not in the same package). But this could be circumvented with reflection. I only see the use of it if we also make the PlatformLogger.Level.valueOf(int) public with anticipation of enabling PlatformLogger to use custom PlatformLogger.Level(s) like j.u.logging. This extension could be performed compatibly by transforming Level enum into a plain class like j.u.l.Level. But until then, I don't see the use of Level.intValue() as a public API. What do you think? Regards, Peter On 04/04/2013 06:52 AM, Mandy Chung wrote: > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > I add back the getLevel(int), setLevel(int) and isLoggable(int) > methods but marked deprecated and also revert the static final > variables to resolve the regression. They can be removed when JavaFX > transitions to use the Level enums (I'll file one issue for FX to use > PlatformLogger.Level and one for core-libs to remove the deprecated > methods). The performance overhead is likely small since it's direct > mapping from int to the Level enum that was used in one of your > previous performance measurement. > > Laurent - you have a patch to add isLoggable calls in the awt/swing > code. Can you check if there is any noticeable performance difference? > > I also take the opportunity to reconsider what > JavaLoggerProxy.getLevel() should return when it's a custom Level. Use > of logging is expected not to cause any fatal error to the running > application. The previous patch throwing IAE needs to be fixed. I > propose to return the first Level.intValue() >= the custom level value > since the level value is used to evaluate if it's loggable. > > History and details: > JavaFX 8 has converted to use sun.util.logging.PlatformLogger > (https://javafx-jira.kenai.com/browse/RT-24458). I was involved in the > early discussion but wasn't aware of the decision made. Thanks to Alan > for catching this regression out before it's integrated to jdk8. > jfxrt.jar is cobundled with jdk8 during the installer build step. My > build doesn't build installer and thus we didn't see this regression. > > I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 > references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no > reference to sun.util.logging. > > I have a method finder tool (planning to include it in jdk8) to search > for use of PlatformLogger.getLevel and it did find 2 references from > jdk8/lib/ext/jfxrt.jar. > > JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build > (https://javafx-jira.kenai.com/browse/RT-27794) soon (currently it's > built with JDK 7). As soon as JavaFX code are changed to reference > PlatformLogger.Level enum instead, we can remove the deprecated > methods and change the PlatformLogger constants. > > JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to > it. In any case, JavaFX 2.2.x only runs either bundled with a > corresponding JDK 7u release, or as a standalone library for JDK 6 only. > > Thanks > Mandy > From chris.hegarty at oracle.com Thu Apr 4 15:36:52 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 04 Apr 2013 16:36:52 +0100 Subject: RFR 8005696: Add CompletableFuture - JEP 155 In-Reply-To: <51534CAF.9000006@cs.oswego.edu> References: <5142070C.6000709@oracle.com> <51430D6B.4060601@cs.oswego.edu> <5143258A.9020906@oracle.com> <5147206B.4060001@cs.oswego.edu> <51489817.7070809@oracle.com> <514D8D32.1020104@cs.oswego.edu> <51534CAF.9000006@cs.oswego.edu> Message-ID: <515D9E14.8010509@oracle.com> This is finally ready for integration. Going once... going twice... Updated webrev and specdiff: http://cr.openjdk.java.net/~chegar/8005696/ver.02/ Doug, I just finalized the jtreg test, and found a small issue. Please find below a suggested change (included in the webrev), and a small test to demonstrate. Since the jtreg test reproduces the problem, the small test is just for your convenience to validate the change, etc. >: cvs diff -u -U5 CompletableFuture.java Index: CompletableFuture.java =================================================================== RCS file: /home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CompletableFuture.java,v retrieving revision 1.80 diff -u -U 5 -r1.80 CompletableFuture.java --- CompletableFuture.java 1 Apr 2013 20:16:05 -0000 1.80 +++ CompletableFuture.java 4 Apr 2013 13:34:58 -0000 @@ -2812,12 +2812,15 @@ } if (dst == null) dst = new CompletableFuture(); } } - if (e == null && ex != null) + if (ex != null) { + if (dst == null) + dst = new CompletableFuture(); dst.internalComplete(null, ex); + } } helpPostComplete(); dst.helpPostComplete(); return dst; } Here is a test to reproduce: :> cat ThenCompose.java import java.util.concurrent.CompletableFuture; public class ThenCompose { public static void main(String[] args) throws Exception { CompletableFuture cf1 = CompletableFuture.supplyAsync(() -> { throw new RuntimeException(); }); CompletableFuture cf2 = cf1.thenCompose((x) -> { return new CompletableFuture(); }); } } :> /export/home/chris/repos/jdk8/tl/cf/build/solaris-sparc-normal-server-release/jdk/bin/java ThenCompose Exception in thread "main" java.lang.NullPointerException at java.util.concurrent.CompletableFuture.doCompose(CompletableFuture.java:2847) at java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2756) at ThenCompose.main(ThenCompose.java:8) lection -Chris. On 03/27/2013 07:46 PM, Doug Lea wrote: > On 03/23/13 07:08, Doug Lea wrote: >> >> There was a signature mismatch between the public >> public static CompletableFuture anyOf(CompletableFuture... >> cfs) >> and the internal method performing most of the work: >> private static CompletableFuture anyTree(...) >> ("" and "" are subtly different.) > > Thanks to Martin especially for knocking some sense into me > about this. The type signature *was* incompatible, but > changing to rather the made this updated > version less useful (it could only return indication, not > result). So it is now updated with a signature-correct > version of anyOf with its original semantics. > > Additionally, while being slightly disruptive anyway: > This class was lacking a little convenience method found in > other Future-based frameworks that surely will be requested. > So now added: > > /** > * Returns a new CompletableFuture that is already completed with > * the given value. > * > * @param value the value > * @return the completed CompletableFuture > */ > public static CompletableFuture completedFuture(U value) From bourges.laurent at gmail.com Thu Apr 4 15:51:08 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 4 Apr 2013 17:51:08 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515D9D71.80407@gmail.com> References: <515D06F6.5050500@oracle.com> <515D9D71.80407@gmail.com> Message-ID: Well done: binary search to find the closest matching level ! However, I still do not see any concrete use case for custom Levels in such closed API as PlatformLogger is: KISS, please ! I mean as PlatformLogger is only used (available) to JDK and related projects, is there any RFE or will to use custom JUL levels here ? Laurent 2013/4/4 Peter Levart > Hi Mandy, Laurent, > > What do you think of this variation (changed just PlatformLogger, other > files exactly equal to your webrev): > > http://dl.dropbox.com/u/**101777488/jdk8-tl/** > PlatformLogger/webrev.enumapi.**02/index.html > > Moved the nearest >= intValue search to PlatformLogger.Level.valueOf(**int) > since it is used also by deprecated API. With this change the same logic is > used for mapping from j.u.l.Level to PlatformLogger.Level in all cases. > > I wonder if PlatformLogger.Level.intValue(**) should be exposed as public > API. Currently it is used by the test (which is not in the same package). > But this could be circumvented with reflection. I only see the use of it if > we also make the PlatformLogger.Level.valueOf(**int) public with > anticipation of enabling PlatformLogger to use custom > PlatformLogger.Level(s) like j.u.logging. This extension could be performed > compatibly by transforming Level enum into a plain class like j.u.l.Level. > But until then, I don't see the use of Level.intValue() as a public API. > What do you think? > > Regards, Peter > > > On 04/04/2013 06:52 AM, Mandy Chung wrote: > >> Peter, Laurent, >> >> History and details are described below. >> >> Webrev at: >> http://cr.openjdk.java.net/~**mchung/jdk8/webrevs/8011380/**webrev.00/ >> >> I add back the getLevel(int), setLevel(int) and isLoggable(int) methods >> but marked deprecated and also revert the static final variables to resolve >> the regression. They can be removed when JavaFX transitions to use the >> Level enums (I'll file one issue for FX to use PlatformLogger.Level and one >> for core-libs to remove the deprecated methods). The performance overhead >> is likely small since it's direct mapping from int to the Level enum that >> was used in one of your previous performance measurement. >> >> Laurent - you have a patch to add isLoggable calls in the awt/swing code. >> Can you check if there is any noticeable performance difference? >> >> I also take the opportunity to reconsider what JavaLoggerProxy.getLevel() >> should return when it's a custom Level. Use of logging is expected not to >> cause any fatal error to the running application. The previous patch >> throwing IAE needs to be fixed. I propose to return the first >> Level.intValue() >= the custom level value since the level value is used to >> evaluate if it's loggable. >> >> History and details: >> JavaFX 8 has converted to use sun.util.logging.**PlatformLogger ( >> https://javafx-jira.kenai.**com/browse/RT-24458). >> I was involved in the early discussion but wasn't aware of the decision >> made. Thanks to Alan for catching this regression out before it's >> integrated to jdk8. jfxrt.jar is cobundled with jdk8 during the installer >> build step. My build doesn't build installer and thus we didn't see this >> regression. >> >> I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 >> references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no >> reference to sun.util.logging. >> >> I have a method finder tool (planning to include it in jdk8) to search >> for use of PlatformLogger.getLevel and it did find 2 references from >> jdk8/lib/ext/jfxrt.jar. >> >> JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build ( >> https://javafx-jira.kenai.**com/browse/RT-27794) >> soon (currently it's built with JDK 7). As soon as JavaFX code are changed >> to reference PlatformLogger.Level enum instead, we can remove the >> deprecated methods and change the PlatformLogger constants. >> >> JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to >> it. In any case, JavaFX 2.2.x only runs either bundled with a >> corresponding JDK 7u release, or as a standalone library for JDK 6 only. >> >> Thanks >> Mandy >> >> > From martinrb at google.com Thu Apr 4 17:32:57 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 4 Apr 2013 10:32:57 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: On Tue, Apr 2, 2013 at 3:50 PM, Mike Duigou wrote: > > - T I will file a spec change request for the addition of ", a power of 2" > to the @serialData tag for this existing but previously unstated > requirement. > Hi Mike, I think changing the serialization spec is a mistake. There are a bunch of collection classes that use power-of-two backing arrays, but it's clearly the intent of the authors that this be an implementation detail. As often happens, implementation details get accidentally exposed ("leaked") in a serial form. Here we see that the size of the backing array is embedded in the serial form. There is an incompatibility between the OpenJDK HashMap implementation and other implementations that don't use power-of-two backing arrays (which may not exist) but the right fix is to make the OpenJDK implementation more resilient to the input serial form. Treat the backing array size as merely a hint. If it's not a power of two, make it so! That is, remove the "previously unstated requirement". From mandy.chung at oracle.com Thu Apr 4 21:58:21 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 04 Apr 2013 14:58:21 -0700 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515D06F6.5050500@oracle.com> References: <515D06F6.5050500@oracle.com> Message-ID: <515DF77D.3020306@oracle.com> Alan - can you review this change? I have changed Level.valueOf(int) to return the nearest Level as Peter suggests using binary search: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.01/ I want to push the changeset tomorrow since we need this fix before the TL integration. Several questions were brought up and I'm answering them in one shot: 1. The PlatformLogger static final fields have to retain the same since existing code can call: int level = PlatformLogger.FINE; logger.setLevel(level); There is also native code accessing PlatformLogger fields (will need to investigate more). Once we fix this type of incompatibility references, we can change them. Or we could remove these static final constants completely but it's less preferable since it touches many of the JDK files. I would keep these static fields as a shortcut. 2. New convenient methods (isInfoLoggable, isWarningLoggable) to minimize the dependency to the constants It's not a problem to have the dependencies. This is an issue this time since we were not aware of such dependency. The isLoggable method is simple enough. 3. 3 methods with two versions (one with int and one with Level parameter) As I said, I'll file a bug to remove the 3 deprecated methods in jdk8. I'm certain I can do so but just take some time to synchronize the changes. 4. It's true that you can set a PlatformLogger with a custom level via PlatformLogger API. But you can access a platform logger using java.util.logging API. Logger.getLogger("sun.awt.someLogger").setLevel(MyLevel.CUSTOM_LEVEL); PlatformLogger.getLevel() has to return some thing. Laurent suggests to remove (deprecate) PlatformLogger.getLevel() or level() method. I have to understand how the FX code uses getLevel(). We have to keep it due to the regression and for testing. For API perspective, having a method to find what level it's at is reasonable. Since we now have a clean solution to deal with custom level, I don't see any issue keeping it. 5. JavaFX 8 is likely to switch to build with JDK8 in a few weeks (really soon). 6. Level.intValue() public or not It mirrors java.util.logging.Level but may be able to do without it. Let's leave it public for now until FX converts to use the new code. I can clean this up at the same time. Mandy On 4/3/13 9:52 PM, Mandy Chung wrote: > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > I add back the getLevel(int), setLevel(int) and isLoggable(int) > methods but marked deprecated and also revert the static final > variables to resolve the regression. They can be removed when JavaFX > transitions to use the Level enums (I'll file one issue for FX to use > PlatformLogger.Level and one for core-libs to remove the deprecated > methods). The performance overhead is likely small since it's direct > mapping from int to the Level enum that was used in one of your > previous performance measurement. > > Laurent - you have a patch to add isLoggable calls in the awt/swing > code. Can you check if there is any noticeable performance difference? > > I also take the opportunity to reconsider what > JavaLoggerProxy.getLevel() should return when it's a custom Level. Use > of logging is expected not to cause any fatal error to the running > application. The previous patch throwing IAE needs to be fixed. I > propose to return the first Level.intValue() >= the custom level value > since the level value is used to evaluate if it's loggable. > > History and details: > JavaFX 8 has converted to use sun.util.logging.PlatformLogger > (https://javafx-jira.kenai.com/browse/RT-24458). I was involved in the > early discussion but wasn't aware of the decision made. Thanks to > Alan for catching this regression out before it's integrated to jdk8. > jfxrt.jar is cobundled with jdk8 during the installer build step. My > build doesn't build installer and thus we didn't see this regression. > > I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 > references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no > reference to sun.util.logging. > > I have a method finder tool (planning to include it in jdk8) to search > for use of PlatformLogger.getLevel and it did find 2 references from > jdk8/lib/ext/jfxrt.jar. > > JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build > (https://javafx-jira.kenai.com/browse/RT-27794) soon (currently it's > built with JDK 7). As soon as JavaFX code are changed to reference > PlatformLogger.Level enum instead, we can remove the deprecated > methods and change the PlatformLogger constants. > > JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to > it. In any case, JavaFX 2.2.x only runs either bundled with a > corresponding JDK 7u release, or as a standalone library for JDK 6 only. > > Thanks > Mandy > From dan.xu at oracle.com Thu Apr 4 22:40:00 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 04 Apr 2013 22:40:00 +0000 Subject: hg: jdk8/tl/jdk: 8000406: change files using @GenerateNativeHeader to use @Native Message-ID: <20130404224011.D941748073@hg.openjdk.java.net> Changeset: 7b1189bf1d7b Author: dxu Date: 2013-04-04 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b1189bf1d7b 8000406: change files using @GenerateNativeHeader to use @Native Summary: Use @Native annotation to mark constants interested by native codes Reviewed-by: alanb, anthony, prr ! src/macosx/classes/apple/laf/JRSUIConstants.java ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java ! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/core/native/Invoke.m ! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m ! src/macosx/native/sun/awt/PrinterView.m ! src/share/classes/java/awt/Adjustable.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/Image.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/SystemColor.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Transparency.java ! src/share/classes/java/awt/color/ColorSpace.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/datatransfer/StringSelection.java ! src/share/classes/java/awt/dnd/DnDConstants.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/AdjustmentEvent.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/FocusEvent.java ! src/share/classes/java/awt/event/InputMethodEvent.java ! src/share/classes/java/awt/event/MouseWheelEvent.java ! src/share/classes/java/awt/event/WindowEvent.java ! src/share/classes/java/awt/geom/PathIterator.java ! src/share/classes/java/awt/image/AffineTransformOp.java ! src/share/classes/java/awt/image/ConvolveOp.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/ImageObserver.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/print/PageFormat.java ! src/share/classes/java/awt/print/Pageable.java ! src/share/classes/java/awt/print/Printable.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunHints.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/RenderBuffer.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java ! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java ! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java ! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/java2d/d3d/D3DContext.java ! src/windows/classes/sun/java2d/d3d/D3DPaints.java ! src/windows/native/sun/java2d/d3d/D3DContext.h ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_List.h ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PopupMenu.h ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_Toolkit.cpp From sadhak001 at gmail.com Thu Apr 4 22:57:10 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 4 Apr 2013 23:57:10 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test Message-ID: Hi all, During #TestFest in London last month we hacked away on jtreg and tests in the OpenJDK. Myself and another participant managed to change two unit tests. I haven't looked for a sponsor in the past so I'm fairly new to the process, hence my email on the list is to request for someone to review, and process these patches further. I'm a committer (signed OCA). Here's details of the changes made to the tests under the .*./jdk8_tl/jdk*folders: 1) *test/java/lang/ref/Basic.java.patch* - changed to not use Thread.sleep() any more rather use the java.util.concurrent.CountdownLatch functionality 2) *test/java/lang/Runtime/exec/LotsOfOutput.java.patch* - refactor-ing and tidy-ing of existing code (removing string literals and replacing with constants, etc...) Please let me know what you would like me to do next with these patches. Regards, mani -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From sadhak001 at gmail.com Thu Apr 4 23:07:22 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 5 Apr 2013 00:07:22 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: Message-ID: Hi all, I'd like to rectify that I;m a contributor (and not a committer as mentioned earlier), so I don't have access to the webrev system but would love to have these patches hosted on them when a sponsor becomes available. Cheers, mani On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar wrote: > Hi all, > > During #TestFest in London last month we hacked away on jtreg and tests in > the OpenJDK. Myself and another participant managed to change two unit > tests. I haven't looked for a sponsor in the past so I'm fairly new to the > process, hence my email on the list is to request for someone to review, > and process these patches further. I'm a committer (signed OCA). > > Here's details of the changes made to the tests under the .*./jdk8_tl/jdk*folders: > > 1) *test/java/lang/ref/Basic.java.patch* - changed to not use > Thread.sleep() any more rather use the java.util.concurrent.CountdownLatch > functionality > 2) *test/java/lang/Runtime/exec/LotsOfOutput.java.patch* - refactor-ing > and tidy-ing of existing code (removing string literals and replacing with > constants, etc...) > > Please let me know what you would like me to do next with these patches. > > Regards, > mani > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From david.holmes at oracle.com Fri Apr 5 00:38:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Apr 2013 10:38:41 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: Message-ID: <515E1D11.6090801@oracle.com> Hi Mani, Attachments get stripped so you will need to inline the patches in your email to the list. Thanks, David On 5/04/2013 9:07 AM, Mani Sarkar wrote: > Hi all, > > I'd like to rectify that I;m a contributor (and not a committer as > mentioned earlier), so I don't have access to the webrev system but would > love to have these patches hosted on them when a sponsor becomes available. > > Cheers, > mani > > On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar wrote: > >> Hi all, >> >> During #TestFest in London last month we hacked away on jtreg and tests in >> the OpenJDK. Myself and another participant managed to change two unit >> tests. I haven't looked for a sponsor in the past so I'm fairly new to the >> process, hence my email on the list is to request for someone to review, >> and process these patches further. I'm a committer (signed OCA). >> >> Here's details of the changes made to the tests under the .*./jdk8_tl/jdk*folders: >> >> 1) *test/java/lang/ref/Basic.java.patch* - changed to not use >> Thread.sleep() any more rather use the java.util.concurrent.CountdownLatch >> functionality >> 2) *test/java/lang/Runtime/exec/LotsOfOutput.java.patch* - refactor-ing >> and tidy-ing of existing code (removing string literals and replacing with >> constants, etc...) >> >> Please let me know what you would like me to do next with these patches. >> >> Regards, >> mani >> >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.com >> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project:* https://github.com/MutabilityDetector >> *Devoxx UK 2013 was a grand success:* >> http://www.devoxx.com/display/UK13/Home >> *Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!* >> > > > From sadhak001 at gmail.com Fri Apr 5 00:55:31 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 5 Apr 2013 01:55:31 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <515E1D11.6090801@oracle.com> References: <515E1D11.6090801@oracle.com> Message-ID: Thanks David, Here are the patches, let me know if they have come in fine: 1) test/java/lang/ref/Basic.**java.patch - changed to not use Thread.sleep() any more rather use the java.util.concurrent.**CountdownLatch functionality Authors: Mani (sadhak001 at gmail.com) and Edward Yue Shung Wong ( edward.ys.wong at gmail.com) ------------x--------------- diff -r 38e1821c4472 test/java/lang/ref/Basic.java --- a/test/java/lang/ref/Basic.java Wed Mar 06 18:35:51 2013 +0100 +++ b/test/java/lang/ref/Basic.java Sat Mar 23 14:51:25 2013 +0000 @@ -29,7 +29,7 @@ import java.lang.ref.*; import java.util.Vector; - +import java.util.concurrent.CountDownLatch; public class Basic { @@ -64,22 +64,22 @@ fork(new Runnable() { public void run() { System.err.println("References: W " + rw.get() - + ", W2 " + rw2.get() - + ", P " + rp.get() - + ", P2 " + rp2.get()); + + ", W2 " + rw2.get() + + ", P " + rp.get() + + ", P2 " + rp2.get()); } }); } - static void createNoise() throws InterruptedException { + static void createNoise(final CountDownLatch cdl) throws InterruptedException { fork(new Runnable() { public void run() { keep.addElement(new PhantomReference(new Object(), q2)); + createNoiseHasFinishedAddingToKeep(cdl); } }); } - public static void main(String[] args) throws Exception { fork(new Runnable() { @@ -97,13 +97,16 @@ int ndq = 0; boolean prevFinalized = false; - outer: + outer: for (int i = 1;; i++) { Reference r; - createNoise(); + CountDownLatch inQueueWaitLatch = new CountDownLatch(1); + createNoise(inQueueWaitLatch); + System.err.println("GC " + i); - Thread.sleep(10); + waitUntilCreateNoiseHasFinished(inQueueWaitLatch); + System.gc(); System.runFinalization(); @@ -137,7 +140,7 @@ if (ndq != 3) { throw new Exception("Expected to dequeue 3 reference objects," - + " but only got " + ndq); + + " but only got " + ndq); } if (! Basic.finalized) { @@ -146,4 +149,13 @@ } + + private static void createNoiseHasFinishedAddingToKeep(CountDownLatch cdl) { + cdl.countDown(); + } + + private static void waitUntilCreateNoiseHasFinished(CountDownLatch cdl) throws InterruptedException { + cdl.await(); + } + } ------------x---------------- 2) test/java/lang/Runtime/exec/**LotsOfOutput.java.patch - refactor-ing and tidy-ing of existing code (removing string literals and replacing with constants, etc...) Author: Edward Yue Shung Wong (edward.ys.wong at gmail.com) ------------x---------------- diff -r 38e1821c4472 test/java/lang/Runtime/exec/LotsOfOutput.java --- a/test/java/lang/Runtime/exec/LotsOfOutput.java Wed Mar 06 18:35:51 2013 +0100 +++ b/test/java/lang/Runtime/exec/LotsOfOutput.java Sat Mar 23 15:48:46 2013 +0000 @@ -33,17 +33,24 @@ public class LotsOfOutput { static final String CAT = "/usr/bin/cat"; - public static void main(String[] args) throws Exception{ - if (File.separatorChar == '\\' || // Windows - !new File(CAT).exists()) // no cat + static final int MEMORY_GROWTH_LIMIT = 1000000; + + public static void main(String[] args) throws Exception { + if (isWindowsOrCatNotAvailable()) { return; + } + Process p = Runtime.getRuntime().exec(CAT + " /dev/zero"); long initMemory = Runtime.getRuntime().totalMemory(); - for (int i=1; i< 10; i++) { + for (int i = 1; i < 10; i++) { Thread.sleep(100); - if (Runtime.getRuntime().totalMemory() > initMemory + 1000000) - throw new Exception("Process consumes memory."); + if (Runtime.getRuntime().totalMemory() > initMemory + MEMORY_GROWTH_LIMIT) + throw new Exception("Runtime memory has grown more than: " + MEMORY_GROWTH_LIMIT); } } + + private static boolean isWindowsOrCatNotAvailable() { + return File.separatorChar == '\\' || !new File(CAT).exists(); + } } ------------x---------------- Any queries please let me know. Thanks. Regards, mani On Fri, Apr 5, 2013 at 1:38 AM, David Holmes wrote: > Hi Mani, > > Attachments get stripped so you will need to inline the patches in your > email to the list. > > Thanks, > David > > > On 5/04/2013 9:07 AM, Mani Sarkar wrote: > >> Hi all, >> >> I'd like to rectify that I;m a contributor (and not a committer as >> mentioned earlier), so I don't have access to the webrev system but would >> love to have these patches hosted on them when a sponsor becomes >> available. >> >> Cheers, >> mani >> >> On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar wrote: >> >> Hi all, >>> >>> During #TestFest in London last month we hacked away on jtreg and tests >>> in >>> the OpenJDK. Myself and another participant managed to change two unit >>> tests. I haven't looked for a sponsor in the past so I'm fairly new to >>> the >>> process, hence my email on the list is to request for someone to review, >>> and process these patches further. I'm a committer (signed OCA). >>> >>> Here's details of the changes made to the tests under the >>> .*./jdk8_tl/jdk*folders: >>> >>> 1) *test/java/lang/ref/Basic.**java.patch* - changed to not use >>> >>> Thread.sleep() any more rather use the java.util.concurrent.** >>> CountdownLatch >>> functionality >>> 2) *test/java/lang/Runtime/exec/**LotsOfOutput.java.patch* - >>> refactor-ing >>> >>> and tidy-ing of existing code (removing string literals and replacing >>> with >>> constants, etc...) >>> >>> Please let me know what you would like me to do next with these patches. >>> >>> Regards, >>> mani >>> >>> -- >>> *Twitter:* @theNeomatrix369 >>> *Blog:* http://neomatrix369.wordpress.**com >>> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project:* https://github.com/**MutabilityDetector >>> *Devoxx UK 2013 was a grand success:* >>> http://www.devoxx.com/display/**UK13/Home >>> *Don't chase success, rather aim for "Excellence", and success will come >>> chasing after you!* >>> >>> >> >> >> -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From david.holmes at oracle.com Fri Apr 5 01:07:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Apr 2013 11:07:49 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> Message-ID: <515E23E5.5090802@oracle.com> Hi Mani, Patches came through ok. I would not add the extra methods around the cdl.await() and cdl.countDown() as they just obscure things in my opinion. But that aside the latch is not needed. The fork() method starts a thread and joins it. So when createNoise() returns we already know for certain that the "noise has been created". What the sleep is doing is giving the GC a chance to run. David On 5/04/2013 10:55 AM, Mani Sarkar wrote: > Thanks David, > > Here are the patches, let me know if they have come in fine: > > 1) test/java/lang/ref/Basic.__java.patch - changed to not use > > Thread.sleep() any more rather use the java.util.concurrent.__CountdownLatch > functionality > Authors: Mani (sadhak001 at gmail.com ) and > Edward Yue Shung Wong (edward.ys.wong at gmail.com > ) > ------------x--------------- > diff -r 38e1821c4472 test/java/lang/ref/Basic.java > --- a/test/java/lang/ref/Basic.javaWed Mar 06 18:35:51 2013 +0100 > +++ b/test/java/lang/ref/Basic.javaSat Mar 23 14:51:25 2013 +0000 > @@ -29,7 +29,7 @@ > import java.lang.ref.*; > import java.util.Vector; > - > +import java.util.concurrent.CountDownLatch; > public class Basic { > @@ -64,22 +64,22 @@ > fork(new Runnable() { > public void run() { > System.err.println("References: W " + rw.get() > - + ", W2 " + rw2.get() > - + ", P " + rp.get() > - + ", P2 " + rp2.get()); > + + ", W2 " + rw2.get() > + + ", P " + rp.get() > + + ", P2 " + rp2.get()); > } > }); > } > - static void createNoise() throws InterruptedException { > + static void createNoise(final CountDownLatch cdl) throws > InterruptedException { > fork(new Runnable() { > public void run() { > keep.addElement(new PhantomReference(new Object(), q2)); > + createNoiseHasFinishedAddingToKeep(cdl); > } > }); > } > - > public static void main(String[] args) throws Exception { > fork(new Runnable() { > @@ -97,13 +97,16 @@ > int ndq = 0; > boolean prevFinalized = false; > - outer: > + outer: > for (int i = 1;; i++) { > Reference r; > - createNoise(); > + CountDownLatch inQueueWaitLatch = new CountDownLatch(1); > + createNoise(inQueueWaitLatch); > + > System.err.println("GC " + i); > - Thread.sleep(10); > + waitUntilCreateNoiseHasFinished(inQueueWaitLatch); > + > System.gc(); > System.runFinalization(); > @@ -137,7 +140,7 @@ > if (ndq != 3) { > throw new Exception("Expected to dequeue 3 reference objects," > - + " but only got " + ndq); > + + " but only got " + ndq); > } > if (! Basic.finalized) { > @@ -146,4 +149,13 @@ > } > + > + private static void > createNoiseHasFinishedAddingToKeep(CountDownLatch cdl) { > + cdl.countDown(); > + } > + > + private static void waitUntilCreateNoiseHasFinished(CountDownLatch > cdl) throws InterruptedException { > + cdl.await(); > + } > + > } > ------------x---------------- > 2) test/java/lang/Runtime/exec/__LotsOfOutput.java.patch - refactor-ing > and tidy-ing of existing code (removing string literals and replacing > with constants, etc...) > > Author: Edward Yue Shung Wong (edward.ys.wong at gmail.com > ) > ------------x---------------- > diff -r 38e1821c4472 test/java/lang/Runtime/exec/LotsOfOutput.java > --- a/test/java/lang/Runtime/exec/LotsOfOutput.javaWed Mar 06 18:35:51 > 2013 +0100 > +++ b/test/java/lang/Runtime/exec/LotsOfOutput.javaSat Mar 23 15:48:46 > 2013 +0000 > @@ -33,17 +33,24 @@ > public class LotsOfOutput { > static final String CAT = "/usr/bin/cat"; > - public static void main(String[] args) throws Exception{ > - if (File.separatorChar == '\\' || // Windows > - !new File(CAT).exists()) // no cat > + static final int MEMORY_GROWTH_LIMIT = 1000000; > + > + public static void main(String[] args) throws Exception { > + if (isWindowsOrCatNotAvailable()) { > return; > + } > + > Process p = Runtime.getRuntime().exec(CAT + " /dev/zero"); > long initMemory = Runtime.getRuntime().totalMemory(); > - for (int i=1; i< 10; i++) { > + for (int i = 1; i < 10; i++) { > Thread.sleep(100); > - if (Runtime.getRuntime().totalMemory() > initMemory + 1000000) > - throw new Exception("Process consumes memory."); > + if (Runtime.getRuntime().totalMemory() > initMemory + > MEMORY_GROWTH_LIMIT) > + throw new Exception("Runtime memory has grown more > than: " + MEMORY_GROWTH_LIMIT); > } > } > + > + private static boolean isWindowsOrCatNotAvailable() { > + return File.separatorChar == '\\' || !new File(CAT).exists(); > + } > } > ------------x---------------- > > Any queries please let me know. > > Thanks. > > Regards, > mani > > On Fri, Apr 5, 2013 at 1:38 AM, David Holmes > wrote: > > Hi Mani, > > Attachments get stripped so you will need to inline the patches in > your email to the list. > > Thanks, > David > > > On 5/04/2013 9:07 AM, Mani Sarkar wrote: > > Hi all, > > I'd like to rectify that I;m a contributor (and not a committer as > mentioned earlier), so I don't have access to the webrev system > but would > love to have these patches hosted on them when a sponsor becomes > available. > > Cheers, > mani > > On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar > > wrote: > > Hi all, > > During #TestFest in London last month we hacked away on > jtreg and tests in > the OpenJDK. Myself and another participant managed to > change two unit > tests. I haven't looked for a sponsor in the past so I'm > fairly new to the > process, hence my email on the list is to request for > someone to review, > and process these patches further. I'm a committer (signed OCA). > > Here's details of the changes made to the tests under the > .*./jdk8_tl/jdk*folders: > > 1) *test/java/lang/ref/Basic.__java.patch* - changed to not use > > Thread.sleep() any more rather use the > java.util.concurrent.__CountdownLatch > functionality > 2) *test/java/lang/Runtime/exec/__LotsOfOutput.java.patch* - > refactor-ing > > and tidy-ing of existing code (removing string literals and > replacing with > constants, etc...) > > Please let me know what you would like me to do next with > these patches. > > Regards, > mani > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.__com > > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr > programs) > *Meet-a-Project:* https://github.com/__MutabilityDetector > > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/__UK13/Home > > *Don't chase success, rather aim for "Excellence", and > success will come > chasing after you!* > > > > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From sadhak001 at gmail.com Fri Apr 5 01:27:54 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 5 Apr 2013 02:27:54 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <515E23E5.5090802@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> Message-ID: Hi David, I'll reply in more detail later but to respond to your comment on: > I would not add the extra methods around the cdl.await() and cdl.countDown() as they just obscure things In general its meant to do the opposite. We come across a lot of code that does not express intent, and the purpose of encapsulating such blocks (even if its a single line) is to make the flow verbose and readable - I have seen similar code-snippets in the Hotspot (C/C++ codebase) making it easy to follow what is going on. One of the things I picked up from TestFest was to make the tests more legible, logical and easy to maintain and scale - it was our intent when we changed this test. I'll come back with responses for your other comments. Cheers mani On Fri, Apr 5, 2013 at 2:07 AM, David Holmes wrote: > Hi Mani, > > Patches came through ok. > > I would not add the extra methods around the cdl.await() and > cdl.countDown() as they just obscure things in my opinion. But that aside > the latch is not needed. The fork() method starts a thread and joins it. So > when createNoise() returns we already know for certain that the "noise has > been created". What the sleep is doing is giving the GC a chance to run. > > David > > > On 5/04/2013 10:55 AM, Mani Sarkar wrote: > >> Thanks David, >> >> Here are the patches, let me know if they have come in fine: >> >> 1) test/java/lang/ref/Basic.__**java.patch - changed to not use >> >> Thread.sleep() any more rather use the java.util.concurrent.__** >> CountdownLatch >> functionality >> Authors: Mani (sadhak001 at gmail.com ) and >> >> Edward Yue Shung Wong (edward.ys.wong at gmail.com >> >) >> >> ------------x--------------- >> diff -r 38e1821c4472 test/java/lang/ref/Basic.java >> --- a/test/java/lang/ref/Basic.**javaWed Mar 06 18:35:51 2013 +0100 >> +++ b/test/java/lang/ref/Basic.**javaSat Mar 23 14:51:25 2013 +0000 >> >> @@ -29,7 +29,7 @@ >> import java.lang.ref.*; >> import java.util.Vector; >> - >> +import java.util.concurrent.**CountDownLatch; >> public class Basic { >> @@ -64,22 +64,22 @@ >> fork(new Runnable() { >> public void run() { >> System.err.println("**References: W " + rw.get() >> - + ", W2 " + rw2.get() >> - + ", P " + rp.get() >> - + ", P2 " + rp2.get()); >> + + ", W2 " + rw2.get() >> + + ", P " + rp.get() >> + + ", P2 " + rp2.get()); >> } >> }); >> } >> - static void createNoise() throws InterruptedException { >> + static void createNoise(final CountDownLatch cdl) throws >> InterruptedException { >> fork(new Runnable() { >> public void run() { >> keep.addElement(new PhantomReference(new Object(), q2)); >> + createNoiseHasFinishedAddingTo**Keep(cdl); >> } >> }); >> } >> - >> public static void main(String[] args) throws Exception { >> fork(new Runnable() { >> @@ -97,13 +97,16 @@ >> int ndq = 0; >> boolean prevFinalized = false; >> - outer: >> + outer: >> for (int i = 1;; i++) { >> Reference r; >> - createNoise(); >> + CountDownLatch inQueueWaitLatch = new CountDownLatch(1); >> + createNoise(inQueueWaitLatch); >> + >> System.err.println("GC " + i); >> - Thread.sleep(10); >> + waitUntilCreateNoiseHasFinishe**d(inQueueWaitLatch); >> + >> System.gc(); >> System.runFinalization(); >> @@ -137,7 +140,7 @@ >> if (ndq != 3) { >> throw new Exception("Expected to dequeue 3 reference >> objects," >> - + " but only got " + ndq); >> + + " but only got " + ndq); >> } >> if (! Basic.finalized) { >> @@ -146,4 +149,13 @@ >> } >> + >> + private static void >> createNoiseHasFinishedAddingTo**Keep(CountDownLatch cdl) { >> + cdl.countDown(); >> + } >> + >> + private static void waitUntilCreateNoiseHasFinishe**d(CountDownLatch >> cdl) throws InterruptedException { >> + cdl.await(); >> + } >> + >> } >> ------------x---------------- >> 2) test/java/lang/Runtime/exec/__**LotsOfOutput.java.patch - refactor-ing >> >> and tidy-ing of existing code (removing string literals and replacing >> with constants, etc...) >> >> Author: Edward Yue Shung Wong (edward.ys.wong at gmail.com >> >) >> >> ------------x---------------- >> diff -r 38e1821c4472 test/java/lang/Runtime/exec/**LotsOfOutput.java >> --- a/test/java/lang/Runtime/exec/**LotsOfOutput.javaWed Mar 06 18:35:51 >> 2013 +0100 >> +++ b/test/java/lang/Runtime/exec/**LotsOfOutput.javaSat Mar 23 15:48:46 >> >> 2013 +0000 >> @@ -33,17 +33,24 @@ >> public class LotsOfOutput { >> static final String CAT = "/usr/bin/cat"; >> - public static void main(String[] args) throws Exception{ >> - if (File.separatorChar == '\\' || // Windows >> - !new File(CAT).exists()) // no cat >> + static final int MEMORY_GROWTH_LIMIT = 1000000; >> + >> + public static void main(String[] args) throws Exception { >> + if (isWindowsOrCatNotAvailable()) { >> return; >> + } >> + >> Process p = Runtime.getRuntime().exec(CAT + " /dev/zero"); >> long initMemory = Runtime.getRuntime().**totalMemory(); >> - for (int i=1; i< 10; i++) { >> + for (int i = 1; i < 10; i++) { >> Thread.sleep(100); >> - if (Runtime.getRuntime().**totalMemory() > initMemory + >> 1000000) >> - throw new Exception("Process consumes memory."); >> + if (Runtime.getRuntime().**totalMemory() > initMemory + >> MEMORY_GROWTH_LIMIT) >> + throw new Exception("Runtime memory has grown more >> than: " + MEMORY_GROWTH_LIMIT); >> } >> } >> + >> + private static boolean isWindowsOrCatNotAvailable() { >> + return File.separatorChar == '\\' || !new File(CAT).exists(); >> + } >> } >> ------------x---------------- >> >> Any queries please let me know. >> >> Thanks. >> >> Regards, >> mani >> >> On Fri, Apr 5, 2013 at 1:38 AM, David Holmes > >> wrote: >> >> Hi Mani, >> >> Attachments get stripped so you will need to inline the patches in >> your email to the list. >> >> Thanks, >> David >> >> >> On 5/04/2013 9:07 AM, Mani Sarkar wrote: >> >> Hi all, >> >> I'd like to rectify that I;m a contributor (and not a committer as >> mentioned earlier), so I don't have access to the webrev system >> but would >> love to have these patches hosted on them when a sponsor becomes >> available. >> >> Cheers, >> mani >> >> On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar >> > wrote: >> >> Hi all, >> >> During #TestFest in London last month we hacked away on >> jtreg and tests in >> the OpenJDK. Myself and another participant managed to >> change two unit >> tests. I haven't looked for a sponsor in the past so I'm >> fairly new to the >> process, hence my email on the list is to request for >> someone to review, >> and process these patches further. I'm a committer (signed >> OCA). >> >> Here's details of the changes made to the tests under the >> .*./jdk8_tl/jdk*folders: >> >> 1) *test/java/lang/ref/Basic.__**java.patch* - changed to >> not use >> >> >> Thread.sleep() any more rather use the >> java.util.concurrent.__**CountdownLatch >> functionality >> 2) *test/java/lang/Runtime/exec/_**_LotsOfOutput.java.patch* >> - >> >> refactor-ing >> >> and tidy-ing of existing code (removing string literals and >> replacing with >> constants, etc...) >> >> Please let me know what you would like me to do next with >> these patches. >> >> Regards, >> mani >> >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.**__com >> >> >> > >> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr >> programs) >> *Meet-a-Project:* https://github.com/__**MutabilityDetector >> >> >> > >> *Devoxx UK 2013 was a grand success:* >> http://www.devoxx.com/display/**__UK13/Home >> >> >> > >> *Don't chase success, rather aim for "Excellence", and >> success will come >> chasing after you!* >> >> >> >> >> >> >> >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.**com >> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project:* https://github.com/**MutabilityDetector >> *Devoxx UK 2013 was a grand success:* >> http://www.devoxx.com/display/**UK13/Home >> */Don't chase success, rather aim for "Excellence", and success will >> come chasing after you!/* >> > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From david.holmes at oracle.com Fri Apr 5 01:40:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Apr 2013 11:40:46 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> Message-ID: <515E2B9E.3040607@oracle.com> On 5/04/2013 11:27 AM, Mani Sarkar wrote: > Hi David, > > I'll reply in more detail later but to respond to your comment on: > > > I would not add the extra methods around the cdl.await() and > cdl.countDown() as they just obscure things > In general its meant to do the opposite. We come across a lot of code > that does not express intent, and the purpose of encapsulating such > blocks (even if its a single line) is to make the flow verbose and > readable - I have seen similar code-snippets in the Hotspot (C/C++ > codebase) making it easy to follow what is going on. One of the things I > picked up from TestFest was to make the tests more legible, logical and > easy to maintain and scale - it was our intent when we changed this test. Sorry, createNoiseHasFinishedAddingToKeep is certainly verbose but not readable. This would be much more readable: Countdownlatch noiseComplete = new ... createNoise(noiseComplete); ... noiseComplete.await(); and: static void createNoise(final CountDownLatch complete) throws InterruptedException { ... complete.countDown(); } just giving the latch a meaningful name is sufficient to convey intent. Note: in this example a Semaphore is probably a better choice than a CountDownLatch. Cheers, David > I'll come back with responses for your other comments. > > Cheers > mani > > On Fri, Apr 5, 2013 at 2:07 AM, David Holmes > wrote: > > Hi Mani, > > Patches came through ok. > > I would not add the extra methods around the cdl.await() and > cdl.countDown() as they just obscure things in my opinion. But that > aside the latch is not needed. The fork() method starts a thread and > joins it. So when createNoise() returns we already know for certain > that the "noise has been created". What the sleep is doing is giving > the GC a chance to run. > > David > > > On 5/04/2013 10:55 AM, Mani Sarkar wrote: > > Thanks David, > > Here are the patches, let me know if they have come in fine: > > 1) test/java/lang/ref/Basic.____java.patch - changed to not use > > Thread.sleep() any more rather use the > java.util.concurrent.____CountdownLatch > functionality > Authors: Mani (sadhak001 at gmail.com > >) and > > Edward Yue Shung Wong (edward.ys.wong at gmail.com > > >) > > ------------x--------------- > diff -r 38e1821c4472 test/java/lang/ref/Basic.java > --- a/test/java/lang/ref/Basic.__javaWed Mar 06 18:35:51 2013 +0100 > +++ b/test/java/lang/ref/Basic.__javaSat Mar 23 14:51:25 2013 +0000 > > @@ -29,7 +29,7 @@ > import java.lang.ref.*; > import java.util.Vector; > - > +import java.util.concurrent.__CountDownLatch; > public class Basic { > @@ -64,22 +64,22 @@ > fork(new Runnable() { > public void run() { > System.err.println("__References: W " + rw.get() > - + ", W2 " + rw2.get() > - + ", P " + rp.get() > - + ", P2 " + rp2.get()); > + + ", W2 " + rw2.get() > + + ", P " + rp.get() > + + ", P2 " + rp2.get()); > } > }); > } > - static void createNoise() throws InterruptedException { > + static void createNoise(final CountDownLatch cdl) throws > InterruptedException { > fork(new Runnable() { > public void run() { > keep.addElement(new PhantomReference(new > Object(), q2)); > + createNoiseHasFinishedAddingTo__Keep(cdl); > } > }); > } > - > public static void main(String[] args) throws Exception { > fork(new Runnable() { > @@ -97,13 +97,16 @@ > int ndq = 0; > boolean prevFinalized = false; > - outer: > + outer: > for (int i = 1;; i++) { > Reference r; > - createNoise(); > + CountDownLatch inQueueWaitLatch = new > CountDownLatch(1); > + createNoise(inQueueWaitLatch); > + > System.err.println("GC " + i); > - Thread.sleep(10); > + waitUntilCreateNoiseHasFinishe__d(inQueueWaitLatch); > + > System.gc(); > System.runFinalization(); > @@ -137,7 +140,7 @@ > if (ndq != 3) { > throw new Exception("Expected to dequeue 3 > reference objects," > - + " but only got " + ndq); > + + " but only got " + ndq); > } > if (! Basic.finalized) { > @@ -146,4 +149,13 @@ > } > + > + private static void > createNoiseHasFinishedAddingTo__Keep(CountDownLatch cdl) { > + cdl.countDown(); > + } > + > + private static void > waitUntilCreateNoiseHasFinishe__d(CountDownLatch > cdl) throws InterruptedException { > + cdl.await(); > + } > + > } > ------------x---------------- > 2) test/java/lang/Runtime/exec/____LotsOfOutput.java.patch - > refactor-ing > > and tidy-ing of existing code (removing string literals and > replacing > with constants, etc...) > > Author: Edward Yue Shung Wong (edward.ys.wong at gmail.com > > >) > > ------------x---------------- > diff -r 38e1821c4472 test/java/lang/Runtime/exec/__LotsOfOutput.java > --- a/test/java/lang/Runtime/exec/__LotsOfOutput.javaWed Mar 06 > 18:35:51 > 2013 +0100 > +++ b/test/java/lang/Runtime/exec/__LotsOfOutput.javaSat Mar 23 > 15:48:46 > > 2013 +0000 > @@ -33,17 +33,24 @@ > public class LotsOfOutput { > static final String CAT = "/usr/bin/cat"; > - public static void main(String[] args) throws Exception{ > - if (File.separatorChar == '\\' || // Windows > - !new File(CAT).exists()) // no cat > + static final int MEMORY_GROWTH_LIMIT = 1000000; > + > + public static void main(String[] args) throws Exception { > + if (isWindowsOrCatNotAvailable()) { > return; > + } > + > Process p = Runtime.getRuntime().exec(CAT + " > /dev/zero"); > long initMemory = Runtime.getRuntime().__totalMemory(); > - for (int i=1; i< 10; i++) { > + for (int i = 1; i < 10; i++) { > Thread.sleep(100); > - if (Runtime.getRuntime().__totalMemory() > > initMemory + 1000000) > - throw new Exception("Process consumes memory."); > + if (Runtime.getRuntime().__totalMemory() > initMemory + > MEMORY_GROWTH_LIMIT) > + throw new Exception("Runtime memory has grown more > than: " + MEMORY_GROWTH_LIMIT); > } > } > + > + private static boolean isWindowsOrCatNotAvailable() { > + return File.separatorChar == '\\' || !new > File(CAT).exists(); > + } > } > ------------x---------------- > > Any queries please let me know. > > Thanks. > > Regards, > mani > > On Fri, Apr 5, 2013 at 1:38 AM, David Holmes > > >> wrote: > > Hi Mani, > > Attachments get stripped so you will need to inline the > patches in > your email to the list. > > Thanks, > David > > > On 5/04/2013 9:07 AM, Mani Sarkar wrote: > > Hi all, > > I'd like to rectify that I;m a contributor (and not a > committer as > mentioned earlier), so I don't have access to the > webrev system > but would > love to have these patches hosted on them when a > sponsor becomes > available. > > Cheers, > mani > > On Thu, Apr 4, 2013 at 11:57 PM, Mani Sarkar > > >> wrote: > > Hi all, > > During #TestFest in London last month we hacked away on > jtreg and tests in > the OpenJDK. Myself and another participant managed to > change two unit > tests. I haven't looked for a sponsor in the past > so I'm > fairly new to the > process, hence my email on the list is to request for > someone to review, > and process these patches further. I'm a committer > (signed OCA). > > Here's details of the changes made to the tests > under the > .*./jdk8_tl/jdk*folders: > > 1) *test/java/lang/ref/Basic.____java.patch* - > changed to not use > > > Thread.sleep() any more rather use the > java.util.concurrent.____CountdownLatch > functionality > 2) > *test/java/lang/Runtime/exec/____LotsOfOutput.java.patch* - > > refactor-ing > > and tidy-ing of existing code (removing string > literals and > replacing with > constants, etc...) > > Please let me know what you would like me to do > next with > these patches. > > Regards, > mani > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.____com > > > > *JUG activity:* LJC Advocate (@adoptopenjdk & > @adoptajsr > programs) > *Meet-a-Project:* > https://github.com/____MutabilityDetector > > > > > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/____UK13/Home > > > > > *Don't chase success, rather aim for "Excellence", and > success will come > chasing after you!* > > > > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.__com > > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/__MutabilityDetector > > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/__UK13/Home > > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From valerie.peng at oracle.com Fri Apr 5 03:06:38 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 05 Apr 2013 03:06:38 +0000 Subject: hg: jdk8/tl/jdk: 7155720: PKCS11 minor issues in native code Message-ID: <20130405030650.EEF7F48098@hg.openjdk.java.net> Changeset: 7d4e30730f80 Author: valeriep Date: 2013-04-04 20:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d4e30730f80 7155720: PKCS11 minor issues in native code Summary: Added OOM handling to address the two issues found by parfait. Reviewed-by: weijun ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c From bourges.laurent at gmail.com Fri Apr 5 08:55:14 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 5 Apr 2013 10:55:14 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515DF77D.3020306@oracle.com> References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> Message-ID: Mandy, I would like to add few performance advices in the PlatformLogger Javadoc: " NOTE: For performance reasons, PlatformLogger usages should take care of avoiding useless / wasted object creation and method calls related to * disabled* log statements: Always use isLoggable(level) wrapping logs at levels (FINEST, FINER, FINE, CONFIG): Bad practices: - string concat: log.fine("message" + value); // means StringBuilder(message).append(String.valueOf(value)).toString(): 2 objects created and value.toString() called - varags: log.fine("message {0}", this); // create an Object[] Best practices: if (log.isLoggable(PlatformLogger.FINE) { log.fine("message" + value); } if (log.isLoggable(PlatformLogger.FINE) { log.fine("message {0}", this); } " What is your opinion ? Thanks for the given explanations and I hope that this patch will be submitted soon to JDK8 repository. Laurent 2013/4/4 Mandy Chung > Alan - can you review this change? > > I have changed Level.valueOf(int) to return the nearest Level as Peter > suggests using binary search: > http://cr.openjdk.java.net/~**mchung/jdk8/webrevs/8011380/**webrev.01/ > > I want to push the changeset tomorrow since we need this fix before the TL > integration. > > Several questions were brought up and I'm answering them in one shot: > 1. The PlatformLogger static final fields have to retain the same since > existing code can call: > int level = PlatformLogger.FINE; > logger.setLevel(level); > > There is also native code accessing PlatformLogger fields (will need to > investigate more). Once we fix this type of incompatibility references, we > can change them. Or we could remove these static final constants > completely but it's less preferable since it touches many of the JDK files. > I would keep these static fields as a shortcut. > > 2. New convenient methods (isInfoLoggable, isWarningLoggable) to minimize > the dependency to the constants > > It's not a problem to have the dependencies. This is an issue this time > since we were not aware of such dependency. The isLoggable method is > simple enough. > > 3. 3 methods with two versions (one with int and one with Level parameter) > > As I said, I'll file a bug to remove the 3 deprecated methods in jdk8. I'm > certain I can do so but just take some time to synchronize the changes. > > 4. It's true that you can set a PlatformLogger with a custom level via > PlatformLogger API. But you can access a platform logger using > java.util.logging API. > > Logger.getLogger("sun.awt.**someLogger").setLevel(MyLevel.** > CUSTOM_LEVEL); > > PlatformLogger.getLevel() has to return some thing. Laurent suggests to > remove (deprecate) PlatformLogger.getLevel() or level() method. I have to > understand how the FX code uses getLevel(). We have to keep it due to the > regression and for testing. For API perspective, having a method to find > what level it's at is reasonable. Since we now have a clean solution to > deal with custom level, I don't see any issue keeping it. > > 5. JavaFX 8 is likely to switch to build with JDK8 in a few weeks (really > soon). > > 6. Level.intValue() public or not > > It mirrors java.util.logging.Level but may be able to do without it. > Let's leave it public for now until FX converts to use the new code. I > can clean this up at the same time. > > Mandy > > > > On 4/3/13 9:52 PM, Mandy Chung wrote: > >> Peter, Laurent, >> >> History and details are described below. >> >> Webrev at: >> http://cr.openjdk.java.net/~**mchung/jdk8/webrevs/8011380/**webrev.00/ >> >> I add back the getLevel(int), setLevel(int) and isLoggable(int) methods >> but marked deprecated and also revert the static final variables to resolve >> the regression. They can be removed when JavaFX transitions to use the >> Level enums (I'll file one issue for FX to use PlatformLogger.Level and one >> for core-libs to remove the deprecated methods). The performance overhead >> is likely small since it's direct mapping from int to the Level enum that >> was used in one of your previous performance measurement. >> >> Laurent - you have a patch to add isLoggable calls in the awt/swing code. >> Can you check if there is any noticeable performance difference? >> >> I also take the opportunity to reconsider what JavaLoggerProxy.getLevel() >> should return when it's a custom Level. Use of logging is expected not to >> cause any fatal error to the running application. The previous patch >> throwing IAE needs to be fixed. I propose to return the first >> Level.intValue() >= the custom level value since the level value is used to >> evaluate if it's loggable. >> >> History and details: >> JavaFX 8 has converted to use sun.util.logging.**PlatformLogger ( >> https://javafx-jira.kenai.**com/browse/RT-24458). >> I was involved in the early discussion but wasn't aware of the decision >> made. Thanks to Alan for catching this regression out before it's >> integrated to jdk8. jfxrt.jar is cobundled with jdk8 during the installer >> build step. My build doesn't build installer and thus we didn't see this >> regression. >> >> I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that shows 112 >> references to PlatformLogger and on jdk7/lib/jfxrt.jar that shows no >> reference to sun.util.logging. >> >> I have a method finder tool (planning to include it in jdk8) to search >> for use of PlatformLogger.getLevel and it did find 2 references from >> jdk8/lib/ext/jfxrt.jar. >> >> JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build ( >> https://javafx-jira.kenai.**com/browse/RT-27794) >> soon (currently it's built with JDK 7). As soon as JavaFX code are changed >> to reference PlatformLogger.Level enum instead, we can remove the >> deprecated methods and change the PlatformLogger constants. >> >> JavaFX 2.2.x doesn't use sun.util.logging and so this has no impact to >> it. In any case, JavaFX 2.2.x only runs either bundled with a >> corresponding JDK 7u release, or as a standalone library for JDK 6 only. >> >> Thanks >> Mandy >> >> > From bourges.laurent at gmail.com Fri Apr 5 12:20:20 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 5 Apr 2013 14:20:20 +0200 Subject: AAShapePipe concurrency & memory waste Message-ID: Dear java2d members, I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage: - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile() - excessive memory usage (byte[] for tile, int[] and rectangle): at each call to renderPath / renderTiles, several small objects are created (never cached) that leads to hundreds megabytes that GC must deal with Here are profiling screenshots: - 4 threads drawing on their own buffered image (MapBench test): http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png - excessive int[] / Rectangle creation: http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png Here is the proposed patch: http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/ I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max). As its memory footprint is very small, I recommend using ThreadLocal. Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ? Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ? I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache ) Regards, Laurent From dl at cs.oswego.edu Fri Apr 5 12:27:40 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 05 Apr 2013 08:27:40 -0400 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <34160.38.123.136.254.1364985327.squirrel@altair.cs.oswego.edu> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> <34160.38.123.136.254.1364985327.squirrel@altair.cs.oswego.edu> Message-ID: <515EC33C.7090604@cs.oswego.edu> On 04/03/13 06:35, Doug Lea wrote: > This was designed to perform best in the case of possibly contended > updates when the element is absent, by avoiding retraversal, and > thus minimizing lock hold times in the common case. (When not common, > it can be guarded by a contains check.) However even in this case, > it is possible that a retraversal via arraycopy could be faster > because it can use optimized cheaper writes (fewer card marks). Yes, by a little. A simple but reliable performance test is now at http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/COWALAddIfAbsentLoops.java?view=log The simplest change allowing this (below) also appears to be among the fastest. Running across various machines and settings (GC, client/server), it seems to be between 5% and 15% faster. This is a smaller difference than in Ivan's tests, that didn't include lock and contention effects. I committed jsr166 version. We'll need to sync this up with with openjdk tl someday, but might as well wait until other updates for Spliterators/streams are ready to integrate. -Doug *** CopyOnWriteArrayList.java.~1.100.~ Tue Mar 12 19:59:08 2013 --- CopyOnWriteArrayList.java Fri Apr 5 08:03:29 2013 *************** *** 579,595 **** final ReentrantLock lock = this.lock; lock.lock(); try { - // Copy while checking if already present. - // This wins in the most common case where it is not present Object[] elements = getArray(); int len = elements.length; - Object[] newElements = new Object[len + 1]; for (int i = 0; i < len; ++i) { if (eq(e, elements[i])) ! return false; // exit, throwing away copy ! else ! newElements[i] = elements[i]; } newElements[len] = e; setArray(newElements); return true; --- 579,591 ---- final ReentrantLock lock = this.lock; lock.lock(); try { Object[] elements = getArray(); int len = elements.length; for (int i = 0; i < len; ++i) { if (eq(e, elements[i])) ! return false; } + Object[] newElements = Arrays.copyOf(elements, len + 1); newElements[len] = e; setArray(newElements); return true; From Alan.Bateman at oracle.com Fri Apr 5 12:46:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Apr 2013 13:46:13 +0100 Subject: Code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and java.lang.reflect.Type In-Reply-To: <515C5AEA.3060007@oracle.com> References: <515BD9E3.5050303@oracle.com> <515BE7C2.9020101@gmail.com> <515C5AEA.3060007@oracle.com> Message-ID: <515EC795.9010506@oracle.com> On 03/04/2013 17:38, Joe Darcy wrote: > Hi Peter, > > On 04/03/2013 01:26 AM, Peter Levart wrote: >> Hi Joe, >> >> Why not using StringBuilder instead of StringBuffer in >> Class.toGenericString ? > > No reason. Thanks for catching this; I'll use StringBuilder in the > final push. Modifier.toString can probably be updated too. I looked through the changes and they look okay to me. For the toGenericString javadoc then "formatted as a list" might be better than "formatted as list". -Alan From Lance.Andersen at oracle.com Fri Apr 5 14:19:38 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 5 Apr 2013 10:19:38 -0400 Subject: netbeans shared.xml jtreg and javadoc.options properties Message-ID: Hi all, While finishing up the netbeans JDBC project, I tried to run the jtreg target and received the following error; /Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/make/netbeans/common/shared.xml:289: A source file is missing :/Users/lance/Documents/hg-workspaces/jdk8/jdbc-jdk/jdk/build/windows-x86_64/jtreg/JDBC42/JTreport/report.html at org.apache.tools.ant.taskdefs.MakeUrl.validateFile(MakeUrl.java:227) at org.apache.tools.ant.taskdefs.MakeUrl.execute(MakeUrl.java:246) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor86.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:487) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:283) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:541) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153) BUILD FAILED (total time: 26 seconds) I changed common/shared.xml from hg diff shared.xml diff -r 5d0c891264bf make/netbeans/common/shared.xml --- a/make/netbeans/common/shared.xml Mon Mar 25 14:29:13 2013 +0000 +++ b/make/netbeans/common/shared.xml Fri Apr 05 10:10:50 2013 -0400 @@ -276,7 +276,7 @@ - + @@ -338,7 +338,7 @@ - Which allows the jtreg tests to run and pull up the report. It also allows the javadocs to be generated Is there any reason I should not check in the above change into openjdk8? Also, the javadoc.options property is not set by default but can be set in the individual build.properties. Should this match what is specified in the jdk make files, or at least include -Xdoclint:none as the makefiles do? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From bourges.laurent at gmail.com Fri Apr 5 14:32:00 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 5 Apr 2013 16:32:00 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: Dear all, Here is my first pisces (beta) patch (webrev): http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ I succeed in fixing memory usage by having only 1 pisces instance (Renderer, stroker, iterator ...) per RendererContext (GC friendly). Impressive results between small and large drawings: dc_boulder_2013-13-30-06-13-17.ser dc_shp_alllayers_2013-00-30-07-00-47.ser JVM 1T 2T 4T 1T 2T 4T OpenJDK8 Patch Beta 2556 3190 5106 22952 26552 46010 OpenJDK8 Ref 3982 4852 8842 55889 77691 141981 Oracle JDK8 (ductus) 1894 3905 7485 20911 39297 103392 Patch / REF *155,79%* *152,10%* *173,17%* *243,50%* *292,60%* *308,59%* Patch / Ductus 74,10% *122,41%* *146,59%* 91,11% *148,00%* *224,72%* Low mem tests: -Xmx128m to maximize GC overhead http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_PATCH_V1.log (beta) http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_REF.log http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_OracleDuctus.log Andrea, I modify the MapBench to perform explicit GC between tests (+ creating graphics / image out of the test loop): http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/ Note: these results were performed with the AAShapePipe proposed patch (small impact). Is there somebody interested to enhance Pisces renderer code and support me as sponsor ? Look at PiscesConst to enable/disable several flags (useThreadLocal, doChecks to check array cleanup ...); please ask me if you have any question. TBD: - cleanup / statistics / profile cpu performance ... - enhance Dasher / Stroker to deal with shape out or partially out the clipping area. Cheers, Laurent From Alan.Bateman at oracle.com Fri Apr 5 15:08:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Apr 2013 16:08:51 +0100 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515DF77D.3020306@oracle.com> References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> Message-ID: <515EE903.3050600@oracle.com> On 04/04/2013 22:58, Mandy Chung wrote: > Alan - can you review this change? > > I have changed Level.valueOf(int) to return the nearest Level as Peter > suggests using binary search: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.01/ > > I want to push the changeset tomorrow since we need this fix before > the TL integration. This looks fine. It's conservative in that it brings us back to the status quo and give FX time to change. -Alan From mandy.chung at oracle.com Fri Apr 5 15:38:03 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 05 Apr 2013 08:38:03 -0700 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> Message-ID: <515EEFDB.5010801@oracle.com> Laurent, I believe this was mentioned somewhere in j.u.logging. A better solution may be to take java.util.function.Supplier parameter that constructs the log message lazily (see http://download.java.net/jdk8/docs/api/java/util/logging/Logger.html#fine(java.util.function.Supplier). I can file a RFE to investigate the use of Supplier as in j.u.l.Logger. Thanks Mandy On 4/5/2013 1:55 AM, Laurent Bourg?s wrote: > Mandy, > > I would like to add few performance advices in the PlatformLogger Javadoc: > " > NOTE: For performance reasons, PlatformLogger usages should take care > of avoiding useless / wasted object creation and method calls related > to *disabled* log statements: > Always use isLoggable(level) wrapping logs at levels (FINEST, FINER, > FINE, CONFIG): > > Bad practices: > - string concat: > log.fine("message" + value); // means > StringBuilder(message).append(String.valueOf(value)).toString(): 2 > objects created and value.toString() called > - varags: > log.fine("message {0}", this); // create an Object[] > > Best practices: > if (log.isLoggable(PlatformLogger.FINE) { > log.fine("message" + value); > } > > if (log.isLoggable(PlatformLogger.FINE) { > log.fine("message {0}", this); > } > " > > What is your opinion ? > > Thanks for the given explanations and I hope that this patch will be > submitted soon to JDK8 repository. > > Laurent > > 2013/4/4 Mandy Chung > > > Alan - can you review this change? > > I have changed Level.valueOf(int) to return the nearest Level as > Peter suggests using binary search: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.01/ > > > I want to push the changeset tomorrow since we need this fix > before the TL integration. > > Several questions were brought up and I'm answering them in one shot: > 1. The PlatformLogger static final fields have to retain the same > since existing code can call: > int level = PlatformLogger.FINE; > logger.setLevel(level); > > There is also native code accessing PlatformLogger fields (will > need to investigate more). Once we fix this type of > incompatibility references, we can change them. Or we could > remove these static final constants completely but it's less > preferable since it touches many of the JDK files. I would keep > these static fields as a shortcut. > > 2. New convenient methods (isInfoLoggable, isWarningLoggable) to > minimize the dependency to the constants > > It's not a problem to have the dependencies. This is an issue > this time since we were not aware of such dependency. The > isLoggable method is simple enough. > > 3. 3 methods with two versions (one with int and one with Level > parameter) > > As I said, I'll file a bug to remove the 3 deprecated methods in > jdk8. I'm certain I can do so but just take some time to > synchronize the changes. > > 4. It's true that you can set a PlatformLogger with a custom level > via PlatformLogger API. But you can access a platform logger > using java.util.logging API. > > > Logger.getLogger("sun.awt.someLogger").setLevel(MyLevel.CUSTOM_LEVEL); > > PlatformLogger.getLevel() has to return some thing. Laurent > suggests to remove (deprecate) PlatformLogger.getLevel() or > level() method. I have to understand how the FX code uses > getLevel(). We have to keep it due to the regression and for > testing. For API perspective, having a method to find what level > it's at is reasonable. Since we now have a clean solution to deal > with custom level, I don't see any issue keeping it. > > 5. JavaFX 8 is likely to switch to build with JDK8 in a few weeks > (really soon). > > 6. Level.intValue() public or not > > It mirrors java.util.logging.Level but may be able to do without > it. Let's leave it public for now until FX converts to use the > new code. I can clean this up at the same time. > > Mandy > > > > On 4/3/13 9:52 PM, Mandy Chung wrote: > > Peter, Laurent, > > History and details are described below. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011380/webrev.00/ > > > I add back the getLevel(int), setLevel(int) and > isLoggable(int) methods but marked deprecated and also revert > the static final variables to resolve the regression. They can > be removed when JavaFX transitions to use the Level enums > (I'll file one issue for FX to use PlatformLogger.Level and > one for core-libs to remove the deprecated methods). The > performance overhead is likely small since it's direct mapping > from int to the Level enum that was used in one of your > previous performance measurement. > > Laurent - you have a patch to add isLoggable calls in the > awt/swing code. Can you check if there is any noticeable > performance difference? > > I also take the opportunity to reconsider what > JavaLoggerProxy.getLevel() should return when it's a custom > Level. Use of logging is expected not to cause any fatal error > to the running application. The previous patch throwing IAE > needs to be fixed. I propose to return the first > Level.intValue() >= the custom level value since the level > value is used to evaluate if it's loggable. > > History and details: > JavaFX 8 has converted to use sun.util.logging.PlatformLogger > (https://javafx-jira.kenai.com/browse/RT-24458). I was > involved in the early discussion but wasn't aware of the > decision made. Thanks to Alan for catching this regression > out before it's integrated to jdk8. jfxrt.jar is cobundled > with jdk8 during the installer build step. My build doesn't > build installer and thus we didn't see this regression. > > I ran jdeps on jdk8/lib/ext/jfxrt.jar (windows-i586) that > shows 112 references to PlatformLogger and on > jdk7/lib/jfxrt.jar that shows no reference to sun.util.logging. > > I have a method finder tool (planning to include it in jdk8) > to search for use of PlatformLogger.getLevel and it did find 2 > references from jdk8/lib/ext/jfxrt.jar. > > JavaFX 8 is going to upgrade to use JDK 8 for JavaFX build > (https://javafx-jira.kenai.com/browse/RT-27794) soon > (currently it's built with JDK 7). As soon as JavaFX code are > changed to reference PlatformLogger.Level enum instead, we can > remove the deprecated methods and change the PlatformLogger > constants. > > JavaFX 2.2.x doesn't use sun.util.logging and so this has no > impact to it. In any case, JavaFX 2.2.x only runs either > bundled with a corresponding JDK 7u release, or as a > standalone library for JDK 6 only. > > Thanks > Mandy > > > From bourges.laurent at gmail.com Fri Apr 5 16:02:16 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 5 Apr 2013 18:02:16 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515EEFDB.5010801@oracle.com> References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> <515EEFDB.5010801@oracle.com> Message-ID: Mandy, I agree it should be well known; but I fixed several cases in awt/net code where isLoggable() calls were missing. I think it is quite cheap to remind good practices in the PlatformLogger / jul Logger javadoc ... PS: maybe some quality control tools could check such missing tests (PMD can do it)... I believe this was mentioned somewhere in j.u.logging. A better solution > may be to take java.util.function.Supplier parameter that constructs the > log message lazily (see > http://download.java.net/jdk8/docs/api/java/util/logging/Logger.html#fine(java.util.function.Supplier). > I can file a RFE to investigate the use of Supplier as in j.u.l.Logger. > Very interesting feature, but I am still not aware of such JDK 8 features (lambda) ... it seems nice but maybe the syntax will be more complicated / verbose than our usual log statements: log.fine(""...) Laurent > > On 4/5/2013 1:55 AM, Laurent Bourg?s wrote: > > Mandy, > > I would like to add few performance advices in the PlatformLogger Javadoc: > " > NOTE: For performance reasons, PlatformLogger usages should take care of > avoiding useless / wasted object creation and method calls related to * > disabled* log statements: > Always use isLoggable(level) wrapping logs at levels (FINEST, FINER, FINE, > CONFIG): > > Bad practices: > - string concat: > log.fine("message" + value); // means > StringBuilder(message).append(String.valueOf(value)).toString(): 2 objects > created and value.toString() called > - varags: > log.fine("message {0}", this); // create an Object[] > > Best practices: > if (log.isLoggable(PlatformLogger.FINE) { > log.fine("message" + value); > } > > if (log.isLoggable(PlatformLogger.FINE) { > log.fine("message {0}", this); > } > " > > What is your opinion ? > > Thanks for the given explanations and I hope that this patch will be > submitted soon to JDK8 repository. > > Laurent > > From mandy.chung at oracle.com Fri Apr 5 17:32:19 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 05 Apr 2013 10:32:19 -0700 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> <515EEFDB.5010801@oracle.com> Message-ID: <515F0AA3.9030804@oracle.com> Laurent, I believe the awt/net code started logging in 1.4 and 1.5 using j.u.logging that was really early taker before the performance overhead was considered. I filed a bug 8011557: improve the logging documentation to advice on performance consideration as we may want to mention this in the tutorial or other docs as well. This should belong to java.util.logging instead of sun.util.logging. Having a second thought, Supplier may not address the memory overhead concern you raise. Worth considering any API improvement to address both the runtime and memory concern. It would also be helpful if IDE and code analysis tool can hint the developers of such pattern. Mandy P.S. I'll be pushing the changeset today. On 4/5/2013 9:02 AM, Laurent Bourg?s wrote: > Mandy, > > I agree it should be well known; but I fixed several cases in awt/net > code where isLoggable() calls were missing. > > I think it is quite cheap to remind good practices in the > PlatformLogger / jul Logger javadoc ... > > PS: maybe some quality control tools could check such missing tests > (PMD can do it)... > > I believe this was mentioned somewhere in j.u.logging. A better > solution may be to take java.util.function.Supplier parameter that > constructs the log message lazily (see > http://download.java.net/jdk8/docs/api/java/util/logging/Logger.html#fine(java.util.function.Supplier) > . > I can file a RFE to investigate the use of Supplier as in > j.u.l.Logger. > > > Very interesting feature, but I am still not aware of such JDK 8 > features (lambda) ... it seems nice but maybe the syntax will be more > complicated / verbose than our usual log statements: > log.fine(""...) > > Laurent > > > > On 4/5/2013 1:55 AM, Laurent Bourg?s wrote: >> Mandy, >> >> I would like to add few performance advices in the PlatformLogger >> Javadoc: >> " >> NOTE: For performance reasons, PlatformLogger usages should take >> care of avoiding useless / wasted object creation and method >> calls related to *disabled* log statements: >> Always use isLoggable(level) wrapping logs at levels (FINEST, >> FINER, FINE, CONFIG): >> >> Bad practices: >> - string concat: >> log.fine("message" + value); // means >> StringBuilder(message).append(String.valueOf(value)).toString(): >> 2 objects created and value.toString() called >> - varags: >> log.fine("message {0}", this); // create an Object[] >> >> Best practices: >> if (log.isLoggable(PlatformLogger.FINE) { >> log.fine("message" + value); >> } >> >> if (log.isLoggable(PlatformLogger.FINE) { >> log.fine("message {0}", this); >> } >> " >> >> What is your opinion ? >> >> Thanks for the given explanations and I hope that this patch will >> be submitted soon to JDK8 repository. >> >> Laurent > > From brian.goetz at oracle.com Fri Apr 5 17:41:22 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 05 Apr 2013 13:41:22 -0400 Subject: Code review request: JDK-8008670 (partial java.util.stream implementation), again In-Reply-To: <51267293.4060203@oracle.com> References: <51267293.4060203@oracle.com> Message-ID: <515F0CC2.3000803@oracle.com> I have updated this webrev, now at: http://cr.openjdk.java.net/~briangoetz/JDK-8008670.3/webrev/ These are all nonpublic implementation-only files (no public APIs) that do not depend on the public Stream APIs. These can go back as soon as the changes to Map and Spliterator are put back. On 2/21/2013 2:16 PM, Brian Goetz wrote: > At: > http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ > > there is a webrev of a subset of the implementation of java.util.stream, > for review. These are all new files. None of these are public classes; > they are internal interfaces for the Stream library, as well as some > implementation classes. This is about half the classes in the Streams > package. > > (The webrev includes changes to Map, but those are being reviewed > separately, so just ignore those.) > > We're asking people to focus their review on both the quality of API > specification for these internal APIs, and the quality of implementation > of the specified classes. It may not be obvious how some of these work > until you've seen the rest of it, but do what you can. > From mandy.chung at oracle.com Fri Apr 5 17:40:51 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 05 Apr 2013 17:40:51 +0000 Subject: hg: jdk8/tl/jdk: 8011380: FX dependency on PlatformLogger broken by 8010309 Message-ID: <20130405174105.0354E480E1@hg.openjdk.java.net> Changeset: b62a76763bf3 Author: mchung Date: 2013-04-05 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b62a76763bf3 8011380: FX dependency on PlatformLogger broken by 8010309 Reviewed-by: alanb ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java From mark.reinhold at oracle.com Fri Apr 5 18:08:24 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 5 Apr 2013 11:08:24 -0700 (PDT) Subject: JEP 180: Handle Frequent HashMap Collisions with Balanced Trees Message-ID: <20130405180824.036DC1733@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/180 - Mark From joe.darcy at oracle.com Fri Apr 5 18:39:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 05 Apr 2013 11:39:36 -0700 Subject: Code review request for 6298888 (reflect) Add toGenericString to java.lang.Class and java.lang.reflect.Type In-Reply-To: <515EC795.9010506@oracle.com> References: <515BD9E3.5050303@oracle.com> <515BE7C2.9020101@gmail.com> <515C5AEA.3060007@oracle.com> <515EC795.9010506@oracle.com> Message-ID: <515F1A68.6090601@oracle.com> On 04/05/2013 05:46 AM, Alan Bateman wrote: > On 03/04/2013 17:38, Joe Darcy wrote: >> Hi Peter, >> >> On 04/03/2013 01:26 AM, Peter Levart wrote: >>> Hi Joe, >>> >>> Why not using StringBuilder instead of StringBuffer in >>> Class.toGenericString ? >> >> No reason. Thanks for catching this; I'll use StringBuilder in the >> final push. > Modifier.toString can probably be updated too. Will do. > > I looked through the changes and they look okay to me. For the > toGenericString javadoc then "formatted as a list" might be better > than "formatted as list". > > I'll correct that as well. Thanks Alan, -Joe From kurchi.subhra.hazra at oracle.com Fri Apr 5 19:04:08 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 05 Apr 2013 19:04:08 +0000 Subject: hg: jdk8/tl/jdk: 5001942: Missings SOCKS support for direct connections Message-ID: <20130405190422.233D7480EE@hg.openjdk.java.net> Changeset: b702977e7212 Author: khazra Date: 2013-04-05 12:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b702977e7212 5001942: Missings SOCKS support for direct connections Summary: Add support for socksNonProxyHosts Reviewed-by: chegar, khazra Contributed-by: Christos Zoulas ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! test/java/net/Socks/SocksProxyVersion.java From jeannette.hung at oracle.com Fri Apr 5 19:21:14 2013 From: jeannette.hung at oracle.com (Jeannette Hung) Date: Fri, 5 Apr 2013 12:21:14 -0700 Subject: JEP 180: Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <20130405180824.036DC1733@eggemoggin.niobe.net> References: <20130405180824.036DC1733@eggemoggin.niobe.net> Message-ID: thanks, Mark! On Apr 5, 2013, at 11:08 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/180 > > - Mark From fweimer at redhat.com Fri Apr 5 20:15:20 2013 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 05 Apr 2013 22:15:20 +0200 Subject: JEP 180: Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <20130405180824.036DC1733@eggemoggin.niobe.net> References: <20130405180824.036DC1733@eggemoggin.niobe.net> Message-ID: <515F30D8.9030002@redhat.com> Opt-in via Comparable seems rather risky to me. It's not just potential divergence between equals() and compareTo(), which the Comparable specification explicitly allows. At the very least, you'd have to add totally separate balanced trees for each class of key objects. -- Florian Weimer / Red Hat Product Security Team From jim.gish at oracle.com Fri Apr 5 21:18:04 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 05 Apr 2013 17:18:04 -0400 Subject: RFR: 8006036, (process) cleanup code in java/lang/Runtime/exec/WinCommand.java Message-ID: <515F3F8C.1040400@oracle.com> Please review trivial change to add back in delete of test files on test completion. http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/ Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From Lance.Andersen at oracle.com Fri Apr 5 21:21:13 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 5 Apr 2013 17:21:13 -0400 Subject: RFR: 8006036, (process) cleanup code in java/lang/Runtime/exec/WinCommand.java In-Reply-To: <515F3F8C.1040400@oracle.com> References: <515F3F8C.1040400@oracle.com> Message-ID: looks ok On Apr 5, 2013, at 5:18 PM, Jim Gish wrote: > Please review trivial change to add back in delete of test files on test completion. > > http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/ > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Fri Apr 5 21:27:53 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 5 Apr 2013 14:27:53 -0700 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: <515EC33C.7090604@cs.oswego.edu> References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> <34160.38.123.136.254.1364985327.squirrel@altair.cs.oswego.edu> <515EC33C.7090604@cs.oswego.edu> Message-ID: I'm still advocating an optimistic approach, that does not hold the lock during the first traversal of the array snapshot. This is much faster when cache hits are the norm (or equals methods are expensive), which I would hope would be the common case, and only slightly slower when all adds are cache misses. public boolean addIfAbsent(E e) { Object[] snapshot = getArray(); int len = snapshot.length; for (int i = 0; i < len; i++) if (eq(e, snapshot[i])) return false; return addIfAbsent(e, snapshot); } private boolean addIfAbsent(E e, Object[] snapshot) { final ReentrantLock lock = this.lock; lock.lock(); try { Object[] current = getArray(); int len = current.length; if (snapshot != current) { // Optimize for contending with another addIfAbsent int common = Math.min(snapshot.length, len); for (int i = 0; i < common; i++) if (current[i] != snapshot[i] && eq(e, current[i])) return false; for (int i = common; i < len; i++) if (eq(e, current[i])) return false; } Object[] newElements = Arrays.copyOf(current, len + 1); newElements[len] = e; setArray(newElements); return true; } finally { lock.unlock(); } } On Fri, Apr 5, 2013 at 5:27 AM, Doug Lea
wrote: > On 04/03/13 06:35, Doug Lea wrote: > >> This was designed to perform best in the case of possibly contended >> updates when the element is absent, by avoiding retraversal, and >> thus minimizing lock hold times in the common case. (When not common, >> it can be guarded by a contains check.) However even in this case, >> it is possible that a retraversal via arraycopy could be faster >> because it can use optimized cheaper writes (fewer card marks). >> > > Yes, by a little. > A simple but reliable performance test is now at > http://gee.cs.oswego.edu/cgi-**bin/viewcvs.cgi/jsr166/src/**test/loops/** > COWALAddIfAbsentLoops.java?**view=log > > The simplest change allowing this (below) also appears to > be among the fastest. Running across various machines and > settings (GC, client/server), it seems to be between 5% and 15% > faster. This is a smaller difference than in Ivan's tests, > that didn't include lock and contention effects. > > I committed jsr166 version. We'll need to sync this up with > with openjdk tl someday, but might as well wait until > other updates for Spliterators/streams are ready to integrate. > > -Doug > > *** CopyOnWriteArrayList.java.~1.**100.~ Tue Mar 12 19:59:08 2013 > --- CopyOnWriteArrayList.java Fri Apr 5 08:03:29 2013 > *************** > *** 579,595 **** > final ReentrantLock lock = this.lock; > lock.lock(); > try { > - // Copy while checking if already present. > - // This wins in the most common case where it is not present > > Object[] elements = getArray(); > int len = elements.length; > - Object[] newElements = new Object[len + 1]; > > for (int i = 0; i < len; ++i) { > if (eq(e, elements[i])) > ! return false; // exit, throwing away copy > ! else > ! newElements[i] = elements[i]; > > } > newElements[len] = e; > setArray(newElements); > return true; > --- 579,591 ---- > final ReentrantLock lock = this.lock; > lock.lock(); > try { > > Object[] elements = getArray(); > int len = elements.length; > for (int i = 0; i < len; ++i) { > if (eq(e, elements[i])) > ! return false; > } > + Object[] newElements = Arrays.copyOf(elements, len + 1); > > newElements[len] = e; > setArray(newElements); > return true; > > From jim.gish at oracle.com Fri Apr 5 21:29:26 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 05 Apr 2013 17:29:26 -0400 Subject: RFR: 8006036, (process) cleanup code in java/lang/Runtime/exec/WinCommand.java In-Reply-To: References: <515F3F8C.1040400@oracle.com> Message-ID: <515F4236.7060003@oracle.com> Thank you. Could someone push it for me please. Cheers, Jim On 04/05/2013 05:21 PM, Lance Andersen - Oracle wrote: > looks ok > On Apr 5, 2013, at 5:18 PM, Jim Gish wrote: > >> Please review trivial change to add back in delete of test files on test completion. >> >> http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/ >> >> Thanks, >> Jim >> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From lance.andersen at oracle.com Fri Apr 5 21:56:03 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 5 Apr 2013 17:56:03 -0400 Subject: RFR: 8006036, (process) cleanup code in java/lang/Runtime/exec/WinCommand.java In-Reply-To: <515F4236.7060003@oracle.com> References: <515F3F8C.1040400@oracle.com> <515F4236.7060003@oracle.com> Message-ID: <3F230B07-8C28-4FE4-BE5E-AFBC3AF583FD@oracle.com> I can look to do this Monday for you for Sunday eve I am away from my primary system right now Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On Apr 5, 2013, at 5:29 PM, Jim Gish wrote: > Thank you. Could someone push it for me please. > > Cheers, > Jim > > On 04/05/2013 05:21 PM, Lance Andersen - Oracle wrote: >> looks ok >> On Apr 5, 2013, at 5:18 PM, Jim Gish wrote: >> >>> Please review trivial change to add back in delete of test files on test completion. >>> >>> http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/ >>> >>> Thanks, >>> Jim >>> >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com >>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > From dan.xu at oracle.com Fri Apr 5 22:35:03 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 05 Apr 2013 15:35:03 -0700 Subject: Review Request: JDK-8011602 - jobjc build failure on Mac Message-ID: <515F5197.1060006@oracle.com> Hi All, Please review the change to fix the build issue on mac platformat http://cr.openjdk.java.net/~dxu/8011602/webrev/.It removes the un-necessary @Native annotation from src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. Therefore, the objc compilation will not dependon the new java.lang.annotation.Native interfacethat is only introduced in jdk8. For the normalbuild process, even though @Native annotationis added to many other java classes to replace @GenerateNativeHeader, the langtool has the capability to handle that when building with jdk7. But on Mac platform, objc compilation is a special process, where the magic of langtool to handle new jdk8 interface in old jdk7 cannot be applied. Since Coder.java already has a native method, getNativeFFITypePtrForCode(), declared, @Native is notnecessary to be present, and it is safe to remove them. The other change in file, src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format correction. I have tested this fix in jprt with boot jdk as jdk7 across all platforms. Thanks! webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/ -Dan From mandy.chung at oracle.com Fri Apr 5 23:15:06 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 05 Apr 2013 16:15:06 -0700 Subject: Review Request: JDK-8011602 - jobjc build failure on Mac In-Reply-To: <515F5197.1060006@oracle.com> References: <515F5197.1060006@oracle.com> Message-ID: <515F5AFA.5060703@oracle.com> Thumbs up. Thanks for fixing it quickly. The macosx jobjc build has its own special build logic that brought some surprise when I merged it with jigsaw at one time. Mandy On 4/5/2013 3:35 PM, Dan Xu wrote: > Hi All, > > Please review the change to fix the build issue on mac platformat > http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the > un-necessary @Native annotation from > src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. > Therefore, the objc compilation will not dependon the new > java.lang.annotation.Native interfacethat is only introduced in jdk8. > > For the normal build process, even though @Native annotationis added > to many other java classes to replace @GenerateNativeHeader, the > langtool has the capability to handle that when building with jdk7. > But on Mac platform, objc compilation is a special process, where the > magic of langtool to handle new jdk8 interface in old jdk7 cannot be > applied. Since Coder.java already has a native method, > getNativeFFITypePtrForCode(), declared, @Native is not necessary to be > present, and it is safe to remove them. The other change in file, > src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format > correction. I have tested this fix in jprt with boot jdk as jdk7 > across all platforms. Thanks! > > webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/ > > -Dan From dan.xu at oracle.com Fri Apr 5 23:21:47 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 05 Apr 2013 16:21:47 -0700 Subject: Review Request: JDK-8011602 - jobjc build failure on Mac In-Reply-To: <515F5AFA.5060703@oracle.com> References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com> Message-ID: <515F5C8B.7050605@oracle.com> Right. Even the generated native headers from jobjc are saved into its own directory. Thank you for your review! -Dan On 04/05/2013 04:15 PM, Mandy Chung wrote: > Thumbs up. Thanks for fixing it quickly. The macosx jobjc build has > its own special build logic that brought some surprise when I merged > it with jigsaw at one time. > > Mandy > > On 4/5/2013 3:35 PM, Dan Xu wrote: >> Hi All, >> >> Please review the change to fix the build issue on mac platformat >> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the >> un-necessary @Native annotation from >> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. >> Therefore, the objc compilation will not dependon the new >> java.lang.annotation.Native interfacethat is only introduced in jdk8. >> >> For the normal build process, even though @Native annotationis added >> to many other java classes to replace @GenerateNativeHeader, the >> langtool has the capability to handle that when building with jdk7. >> But on Mac platform, objc compilation is a special process, where the >> magic of langtool to handle new jdk8 interface in old jdk7 cannot be >> applied. Since Coder.java already has a native method, >> getNativeFFITypePtrForCode(), declared, @Native is not necessary to >> be present, and it is safe to remove them. The other change in file, >> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format >> correction. I have tested this fix in jprt with boot jdk as jdk7 >> across all platforms. Thanks! >> >> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/ >> >> -Dan > From vitalyd at gmail.com Fri Apr 5 23:35:16 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 5 Apr 2013 19:35:16 -0400 Subject: [concurrency-interest] RFR [8011215] optimization of CopyOnWriteArrayList.addIfAbsent() In-Reply-To: References: <515B2915.60402@oracle.com> <515B41AA.3040703@oracle.com> <515B499E.3090401@oracle.com> <515B4AE5.4060104@CoSoCo.de> <515B5F79.9090603@oracle.com> <34160.38.123.136.254.1364985327.squirrel@altair.cs.oswego.edu> <515EC33C.7090604@cs.oswego.edu> Message-ID: When you say it's slightly slower for cache misses, what numbers are we talking about? Personally, I don't see a reason to further optimize for cache hits - are we really saying that's the common usage of COWAL? I'd find that hard to believe. At some point, it's probably better to simply externalize this policy via constructor hint or subclass or whatever rather than catering to both sides in shared code. Sent from my phone On Apr 5, 2013 5:28 PM, "Martin Buchholz" wrote: > I'm still advocating an optimistic approach, that does not hold the lock > during the first traversal of the array snapshot. This is much faster when > cache hits are the norm (or equals methods are expensive), which I would > hope would be the common case, and only slightly slower when all adds are > cache misses. > > public boolean addIfAbsent(E e) { > Object[] snapshot = getArray(); > int len = snapshot.length; > for (int i = 0; i < len; i++) > if (eq(e, snapshot[i])) > return false; > return addIfAbsent(e, snapshot); > } > > private boolean addIfAbsent(E e, Object[] snapshot) { > final ReentrantLock lock = this.lock; > lock.lock(); > try { > Object[] current = getArray(); > int len = current.length; > if (snapshot != current) { > // Optimize for contending with another addIfAbsent > int common = Math.min(snapshot.length, len); > for (int i = 0; i < common; i++) > if (current[i] != snapshot[i] && eq(e, current[i])) > return false; > for (int i = common; i < len; i++) > if (eq(e, current[i])) > return false; > } > Object[] newElements = Arrays.copyOf(current, len + 1); > newElements[len] = e; > setArray(newElements); > return true; > } finally { > lock.unlock(); > } > } > > > > On Fri, Apr 5, 2013 at 5:27 AM, Doug Lea
wrote: > > > On 04/03/13 06:35, Doug Lea wrote: > > > >> This was designed to perform best in the case of possibly contended > >> updates when the element is absent, by avoiding retraversal, and > >> thus minimizing lock hold times in the common case. (When not common, > >> it can be guarded by a contains check.) However even in this case, > >> it is possible that a retraversal via arraycopy could be faster > >> because it can use optimized cheaper writes (fewer card marks). > >> > > > > Yes, by a little. > > A simple but reliable performance test is now at > > > http://gee.cs.oswego.edu/cgi-**bin/viewcvs.cgi/jsr166/src/**test/loops/** > > COWALAddIfAbsentLoops.java?**view=log< > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/COWALAddIfAbsentLoops.java?view=log > > > > > > The simplest change allowing this (below) also appears to > > be among the fastest. Running across various machines and > > settings (GC, client/server), it seems to be between 5% and 15% > > faster. This is a smaller difference than in Ivan's tests, > > that didn't include lock and contention effects. > > > > I committed jsr166 version. We'll need to sync this up with > > with openjdk tl someday, but might as well wait until > > other updates for Spliterators/streams are ready to integrate. > > > > -Doug > > > > *** CopyOnWriteArrayList.java.~1.**100.~ Tue Mar 12 19:59:08 2013 > > --- CopyOnWriteArrayList.java Fri Apr 5 08:03:29 2013 > > *************** > > *** 579,595 **** > > final ReentrantLock lock = this.lock; > > lock.lock(); > > try { > > - // Copy while checking if already present. > > - // This wins in the most common case where it is not > present > > > > Object[] elements = getArray(); > > int len = elements.length; > > - Object[] newElements = new Object[len + 1]; > > > > for (int i = 0; i < len; ++i) { > > if (eq(e, elements[i])) > > ! return false; // exit, throwing away copy > > ! else > > ! newElements[i] = elements[i]; > > > > } > > newElements[len] = e; > > setArray(newElements); > > return true; > > --- 579,591 ---- > > final ReentrantLock lock = this.lock; > > lock.lock(); > > try { > > > > Object[] elements = getArray(); > > int len = elements.length; > > for (int i = 0; i < len; ++i) { > > if (eq(e, elements[i])) > > ! return false; > > } > > + Object[] newElements = Arrays.copyOf(elements, len + 1); > > > > newElements[len] = e; > > setArray(newElements); > > return true; > > > > > From lana.steuck at oracle.com Fri Apr 5 23:49:07 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:07 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20130405234907.B29F5480FD@hg.openjdk.java.net> Changeset: 15c1642967c9 Author: andrew Date: 2013-04-02 13:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/15c1642967c9 8009988: build-infra: Fix configure output for zip debuginfo check Summary: No output from zip debuginfo option when default is used. Reviewed-by: tbell ! common/autoconf/autogen.sh ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: f3cdfb3d360d Author: omajid Date: 2013-04-02 14:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f3cdfb3d360d 8011278: Allow using a system-installed giflib Reviewed-by: andrew, prr ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 01f631f89fa3 Author: katleman Date: 2013-04-02 15:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/01f631f89fa3 Merge Changeset: a0fa9e93efee Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a0fa9e93efee Added tag jdk8-b84 for changeset 01f631f89fa3 ! .hgtags Changeset: 11c057460b91 Author: lana Date: 2013-04-05 14:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/11c057460b91 Merge From lana.steuck at oracle.com Fri Apr 5 23:49:14 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:14 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b84 for changeset f5f40094ffcc Message-ID: <20130405234917.9AD4148100@hg.openjdk.java.net> Changeset: 41b50e2c5ea3 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/41b50e2c5ea3 Added tag jdk8-b84 for changeset f5f40094ffcc ! .hgtags From lana.steuck at oracle.com Fri Apr 5 23:49:05 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:05 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b84 for changeset 928f8b888deb Message-ID: <20130405234906.77F60480FC@hg.openjdk.java.net> Changeset: 9583a6431596 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9583a6431596 Added tag jdk8-b84 for changeset 928f8b888deb ! .hgtags From lana.steuck at oracle.com Fri Apr 5 23:49:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:11 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130405234913.149B1480FE@hg.openjdk.java.net> Changeset: e0378f0a50da Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e0378f0a50da Added tag jdk8-b84 for changeset 999cc1bf5520 ! .hgtags Changeset: d82bc6ba3981 Author: lana Date: 2013-04-05 14:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d82bc6ba3981 Merge From lana.steuck at oracle.com Fri Apr 5 23:49:14 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:14 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130405234921.2151E48101@hg.openjdk.java.net> Changeset: 4a48f3173534 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a48f3173534 Added tag jdk8-b84 for changeset cfb65ca92082 ! .hgtags Changeset: e06dc8345d9c Author: lana Date: 2013-04-05 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e06dc8345d9c Merge From lana.steuck at oracle.com Fri Apr 5 23:49:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:21 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130405235022.C39B848102@hg.openjdk.java.net> Changeset: b68094f8263f Author: erikj Date: 2013-03-28 09:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b68094f8263f 8010908: Images target failes when configured with --disable-zip-debug-info Reviewed-by: tbell ! makefiles/Images.gmk Changeset: 9c76ea43d491 Author: omajid Date: 2013-04-02 14:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c76ea43d491 8011278: Allow using a system-installed giflib Reviewed-by: andrew, prr ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: 7b4721e4edb4 Author: katleman Date: 2013-04-02 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b4721e4edb4 Merge ! makefiles/CompileNativeLibraries.gmk Changeset: 43da85020921 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43da85020921 Added tag jdk8-b84 for changeset 7b4721e4edb4 ! .hgtags Changeset: ba231ac2890a Author: lana Date: 2013-04-05 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba231ac2890a Merge From lana.steuck at oracle.com Fri Apr 5 23:49:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:21 +0000 Subject: hg: jdk8/tl/hotspot: 35 new changesets Message-ID: <20130405235029.E3DFB48103@hg.openjdk.java.net> Changeset: 59a41e1357ab Author: amurillo Date: 2013-03-23 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59a41e1357ab 8010498: new hotspot build - hs25-b25 Reviewed-by: jcoomes ! make/hotspot_version Changeset: eca90b8a06eb Author: rdurbin Date: 2013-03-19 11:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eca90b8a06eb 7030610: runtime/6878713/Test6878713.sh fails Error. failed to clean up files after test 7123945: runtime/6878713/Test6878713.sh require about 2G of native memory, swaps and times out Summary: Add new diagnostic option -XX:MallocMaxTestWords=NNN and fix Test6878713.sh. Reviewed-by: dcubed, coleenp, dholmes, iklam ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! test/runtime/6878713/Test6878713.sh Changeset: a649f6511c04 Author: ctornqvi Date: 2013-03-20 08:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a649f6511c04 8010084: Race in runtime/NMT/BaselineWithParameter.java Summary: Added a waitFor() on the process Reviewed-by: mgerdin, sla, zgu ! test/runtime/NMT/BaselineWithParameter.java Changeset: 91bf0bdae37b Author: coleenp Date: 2013-03-20 08:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91bf0bdae37b 8008217: CDS: Class data sharing limits the malloc heap on Solaris Summary: In 64bit VM move CDS archive address to 32G on all platforms using new flag SharedBaseAddress. In 32bit VM set CDS archive address to 3Gb on Linux and let other OSs pick the address. Reviewed-by: kvn, dcubed, zgu, hseigel ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2c7663baeb67 Author: acorn Date: 2013-03-20 11:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c7663baeb67 8010017: lambda: reflection get(Declared)Methods support for default methods. Summary: Don't expose vm generated overpass (bridges to default methods). Reviewed-by: dholmes, fparain ! src/share/vm/prims/jvm.cpp Changeset: 79259e97a072 Author: acorn Date: 2013-03-20 12:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79259e97a072 Merge Changeset: 1feda2e9f044 Author: ctornqvi Date: 2013-03-20 20:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1feda2e9f044 8007982: some runtime/CommandLine/ tests fail on 32-bit platforms Summary: Changed tests to use platform independent flags Reviewed-by: collins, hseigel, zgu ! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java ! test/runtime/CommandLine/FlagWithInvalidValue.java ! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java Changeset: 81d1b58c078f Author: rdurbin Date: 2013-03-20 20:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81d1b58c078f 8010396: checking MallocMaxTestWords in testMalloc() function is redundant Summary: Remove redundant checks in testMalloc and add assert. Reviewed-by: dcubed, coleenp, dholmes ! src/share/vm/runtime/os.cpp Changeset: e7081eb7e786 Author: dcubed Date: 2013-03-20 20:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7081eb7e786 Merge Changeset: 06db4c0afbf3 Author: zgu Date: 2013-03-20 09:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06db4c0afbf3 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT 8009777: NMT: add new NMT dcmd to control auto shutdown option Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation Reviewed-by: dcubed, coleenp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 0ac03fef364f Author: zgu Date: 2013-03-21 06:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ac03fef364f Merge ! src/share/vm/runtime/globals.hpp Changeset: 14509df4cd63 Author: iklam Date: 2013-03-21 20:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/14509df4cd63 8010389: After fix for 7107135 a failed dlopen() call results in a VM crash Summary: Call dlerror() in VM thread as necessary. Reviewed-by: coleenp, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp + test/runtime/8010389/VMThreadDlopen.java Changeset: 6574f999e0cf Author: dcubed Date: 2013-03-23 22:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6574f999e0cf Merge ! src/share/vm/memory/metaspace.cpp Changeset: c342fbdf8a70 Author: ctornqvi Date: 2013-03-24 09:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c342fbdf8a70 8008454: test/runtime/NMT/PrintNMTStatistics is broken Summary: Added @run tag so that it actually runs the test, also fixed broken command line and incorrect parsing. Also reviewed by gerard.ziemski at oracle.com Reviewed-by: mgerdin, zgu ! test/runtime/NMT/PrintNMTStatistics.java Changeset: 9c8e53c7bed0 Author: ctornqvi Date: 2013-03-24 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c8e53c7bed0 Merge - make/test/Queens.java Changeset: 729be16a470b Author: hseigel Date: 2013-03-25 08:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/729be16a470b 8010667: Non-zero padding is not allowed in splitverifier for tableswitch/lookupswitch instructions. Summary: Don't check the padding bits if class file version is >= 51. Reviewed-by: kvn, dholmes, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b8deb3205b51 Author: bharadwaj Date: 2013-03-25 09:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8deb3205b51 8009552: test/vm/verifier/TestStaticIF.java failing with hs25.0-b Summary: Remove support for verification of class files with version 52 and above from type inference verifier. Reviewed-by: acorn, hseigel ! src/share/vm/classfile/verifier.cpp - test/runtime/8007736/TestStaticIF.java Changeset: 1916ca1dec2f Author: rbackman Date: 2013-03-26 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1916ca1dec2f 8009382: Add JVM_Get{Field|Method}TypeAnnotations Reviewed-by: dcubed, rbackman Contributed-by: Joel Borggren-Franck ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 36376b540a98 Author: hseigel Date: 2013-03-26 09:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36376b540a98 8009595: The UseSplitVerifier option needs to be deprecated. Summary: Put UseSplitVerifier option on the deprecated list. Reviewed-by: dcubed, kmo, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a8016373a893 Author: hseigel Date: 2013-03-26 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a8016373a893 Merge Changeset: 6b748c9e1845 Author: zgu Date: 2013-03-26 14:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b748c9e1845 8010651: create.bat still builds the kernel Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows Reviewed-by: coleenp, sla ! make/windows/build.make ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/product.make ! make/windows/makefiles/vm.make - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java Changeset: 85192022ba8c Author: zgu Date: 2013-03-26 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85192022ba8c Merge - test/runtime/8007736/TestStaticIF.java Changeset: 23f2d309e855 Author: zgu Date: 2013-03-26 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23f2d309e855 Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw Changeset: 7f16d1812865 Author: tamao Date: 2013-03-20 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f16d1812865 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Summary: Remove the related assertions becasue they do not hold here. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp Changeset: dbd5837b342f Author: ehelin Date: 2013-03-22 16:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dbd5837b342f 8000754: NPG: Implement a MemoryPool MXBean for Metaspace Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: 338b3a9e29b5 Author: stefank Date: 2013-03-25 11:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/338b3a9e29b5 Merge ! src/share/vm/services/memoryService.cpp Changeset: 42e370795a39 Author: ehelin Date: 2013-03-27 10:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42e370795a39 8010818: NPG: Remove metaspace memory pools Reviewed-by: mgerdin, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp - test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: aeb22fdaa14c Author: brutisso Date: 2013-03-28 09:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aeb22fdaa14c Merge ! src/share/vm/runtime/arguments.cpp Changeset: 728b89404e34 Author: jprovino Date: 2013-03-21 10:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/728b89404e34 8009904: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm Summary: jvmtiClassFileReconstituter.cpp needs to be added to the list of files to exclude when JVMTI is excluded from the jvm Reviewed-by: dholmes, sspitsyn ! make/excludeSrc.make Changeset: 7ca101eef24a Author: jprovino Date: 2013-03-23 14:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ca101eef24a Merge Changeset: 04d6d4322c6a Author: collins Date: 2013-03-27 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04d6d4322c6a 8009152: A number of jtreg tests need review/improvement Summary: Added a new test_env.txt file to capture common shell variable. Added concept of COMPILEJAVA for use when TESTJAVA is a JRE. If COMPILEJAVA not set then TESTJAVA will be the default with assumption it is a JDK. Reviewed-by: kvn, brutisso, coleenp ! test/compiler/5091921/Test6890943.sh ! test/compiler/5091921/Test7005594.sh ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158804/Test7158804.sh ! test/runtime/7162488/Test7162488.sh + test/test_env.sh Changeset: d1897e7e0488 Author: collins Date: 2013-03-28 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1897e7e0488 Merge ! test/runtime/6878713/Test6878713.sh Changeset: 8d0f263a370c Author: amurillo Date: 2013-03-28 19:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d0f263a370c Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw - test/runtime/8007736/TestStaticIF.java Changeset: af788b85010e Author: amurillo Date: 2013-03-28 19:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af788b85010e Added tag hs25-b25 for changeset 8d0f263a370c ! .hgtags Changeset: ac242ddfa319 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac242ddfa319 Added tag jdk8-b84 for changeset af788b85010e ! .hgtags From david.holmes at oracle.com Fri Apr 5 23:51:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 06 Apr 2013 09:51:35 +1000 Subject: Review Request: JDK-8011602 - jobjc build failure on Mac In-Reply-To: <515F5C8B.7050605@oracle.com> References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com> <515F5C8B.7050605@oracle.com> Message-ID: <515F6387.8010305@oracle.com> Dan, Looks okay to me - glad there was a simple solution. Still wondering why this didn't get picked up during JPRT testing though ?? Thanks, David On 6/04/2013 9:21 AM, Dan Xu wrote: > Right. Even the generated native headers from jobjc are saved into its > own directory. > > Thank you for your review! > > -Dan > > > On 04/05/2013 04:15 PM, Mandy Chung wrote: >> Thumbs up. Thanks for fixing it quickly. The macosx jobjc build has >> its own special build logic that brought some surprise when I merged >> it with jigsaw at one time. >> >> Mandy >> >> On 4/5/2013 3:35 PM, Dan Xu wrote: >>> Hi All, >>> >>> Please review the change to fix the build issue on mac platformat >>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the >>> un-necessary @Native annotation from >>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. >>> Therefore, the objc compilation will not dependon the new >>> java.lang.annotation.Native interfacethat is only introduced in jdk8. >>> >>> For the normal build process, even though @Native annotationis added >>> to many other java classes to replace @GenerateNativeHeader, the >>> langtool has the capability to handle that when building with jdk7. >>> But on Mac platform, objc compilation is a special process, where the >>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be >>> applied. Since Coder.java already has a native method, >>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to >>> be present, and it is safe to remove them. The other change in file, >>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format >>> correction. I have tested this fix in jprt with boot jdk as jdk7 >>> across all platforms. Thanks! >>> >>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/ >>> >>> -Dan >> > From lana.steuck at oracle.com Fri Apr 5 23:49:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 05 Apr 2013 23:49:11 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b84 for changeset 5773e3fc8380 Message-ID: <20130405234914.B36BF480FF@hg.openjdk.java.net> Changeset: 8c0b6bccfe47 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8c0b6bccfe47 Added tag jdk8-b84 for changeset 5773e3fc8380 ! .hgtags From dan.xu at oracle.com Sat Apr 6 00:06:54 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 05 Apr 2013 17:06:54 -0700 Subject: Review Request: JDK-8011602 - jobjc build failure on Mac In-Reply-To: <515F6387.8010305@oracle.com> References: <515F5197.1060006@oracle.com> <515F5AFA.5060703@oracle.com> <515F5C8B.7050605@oracle.com> <515F6387.8010305@oracle.com> Message-ID: <515F671E.3060308@oracle.com> Hi David, Thanks for your review. When I tested it in JPRT run, I added "-boot jdk1.8.0" to use jdk8 as the boot jdk. I did not realize that being able to build with jdk7 is a requirement. I will push the fix now. Thanks! -Dan On 04/05/2013 04:51 PM, David Holmes wrote: > Dan, > > Looks okay to me - glad there was a simple solution. > > Still wondering why this didn't get picked up during JPRT testing > though ?? > > Thanks, > David > > On 6/04/2013 9:21 AM, Dan Xu wrote: >> Right. Even the generated native headers from jobjc are saved into its >> own directory. >> >> Thank you for your review! >> >> -Dan >> >> >> On 04/05/2013 04:15 PM, Mandy Chung wrote: >>> Thumbs up. Thanks for fixing it quickly. The macosx jobjc build has >>> its own special build logic that brought some surprise when I merged >>> it with jigsaw at one time. >>> >>> Mandy >>> >>> On 4/5/2013 3:35 PM, Dan Xu wrote: >>>> Hi All, >>>> >>>> Please review the change to fix the build issue on mac platformat >>>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the >>>> un-necessary @Native annotation from >>>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java. >>>> Therefore, the objc compilation will not dependon the new >>>> java.lang.annotation.Native interfacethat is only introduced in jdk8. >>>> >>>> For the normal build process, even though @Native annotationis added >>>> to many other java classes to replace @GenerateNativeHeader, the >>>> langtool has the capability to handle that when building with jdk7. >>>> But on Mac platform, objc compilation is a special process, where the >>>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be >>>> applied. Since Coder.java already has a native method, >>>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to >>>> be present, and it is safe to remove them. The other change in file, >>>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format >>>> correction. I have tested this fix in jprt with boot jdk as jdk7 >>>> across all platforms. Thanks! >>>> >>>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/ >>>> >>>> -Dan >>> >> From dan.xu at oracle.com Sat Apr 6 00:16:12 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Sat, 06 Apr 2013 00:16:12 +0000 Subject: hg: jdk8/tl/jdk: 8011602: jobjc build failure on Mac Message-ID: <20130406001624.93A0A48104@hg.openjdk.java.net> Changeset: 785f3a04ee05 Author: dxu Date: 2013-04-05 17:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/785f3a04ee05 8011602: jobjc build failure on Mac Summary: Remove @Native annotation from macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java Reviewed-by: mchung, dholmes ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/share/classes/sun/java2d/opengl/OGLContext.java From joe.darcy at oracle.com Sat Apr 6 01:20:25 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 06 Apr 2013 01:20:25 +0000 Subject: hg: jdk8/tl/jdk: 8011590: More tests for core reflection modeling of default methods Message-ID: <20130406012036.C972048107@hg.openjdk.java.net> Changeset: 16f63a94c231 Author: darcy Date: 2013-04-05 18:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16f63a94c231 8011590: More tests for core reflection modeling of default methods Reviewed-by: mduigou + test/java/lang/reflect/Method/DefaultMethodModeling.java From bourges.laurent at gmail.com Sat Apr 6 07:17:55 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Sat, 6 Apr 2013 09:17:55 +0200 Subject: Review request: 8011380: FX dependency on PlatformLogger broken In-Reply-To: <515F0AA3.9030804@oracle.com> References: <515D06F6.5050500@oracle.com> <515DF77D.3020306@oracle.com> <515EEFDB.5010801@oracle.com> <515F0AA3.9030804@oracle.com> Message-ID: Mandy, I believe the awt/net code started logging in 1.4 and 1.5 using j.u.logging > that was really early taker before the performance overhead was considered. > > I filed a bug 8011557: improve the logging documentation to advice on > performance consideration as we may want to mention this in the tutorial or > other docs as well. This should belong to java.util.logging instead of > sun.util.logging. > That's a good idea to update both javadoc (JUL, PlatformLogger) and maybe the java code convention related to OpenJDK code. I insist on pointing this performance issue in the PlatformLogger class too because it belongs to JDK and I expect it to be as fast as possible ! Moreover, it would be very great if openjdk's build can perform code quality tests and report such incorrect JUL / PlatformLogger usages. Any idea to do so ? > > Having a second thought, Supplier may not address the memory overhead > concern you raise. Worth considering any API improvement to address both > the runtime and memory concern. > I looked at JDK8 Logger doc and Supplier may help (but maybe the underlying implementation may be slow or create objects too): "A set of methods alternatively take a "msgSupplier" instead of a "msg" argument. These methods take a Supplier function which is invoked to construct the desired log message only when the message actually is to be logged based on the effective log level thus eliminating unnecessary message construction. For example, if the developer wants to log system health status for diagnosis, with the String-accepting version, the code would look like: class DiagnosisMessages { static String systemHealthStatus() { // collect system health information ... } } ... logger.log(Level.FINER, DiagnosisMessages.systemHealthStatus()); *With the above code, the health status is collected unnecessarily even when the log level FINER is disabled. With the Supplier-accepting version as below, the status will only be collected when the log level FINER is enabled. * * logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);* " > It would also be helpful if IDE and code analysis tool can hint the > developers of such pattern. > Netbeans has a warning saying "string concatenation in log statements" but it does not propose to fix it by adding proper isLoggable statement: maybe we should submit a RFE to netbeans project ? http://wiki.netbeans.org/Java_Hints#Logging "*String concatenation in logger* It is not performance efficient to concatenate strings in logger messages. It is better to use a template message with placeholders that are replaced by concrete values only when the message is really going to be logged. *Since NetBeans 6.9* " Cheers, Laurent > Mandy > P.S. I'll be pushing the changeset today. > > > On 4/5/2013 9:02 AM, Laurent Bourg?s wrote: > > Mandy, > > I agree it should be well known; but I fixed several cases in awt/net code > where isLoggable() calls were missing. > > I think it is quite cheap to remind good practices in the PlatformLogger / > jul Logger javadoc ... > > PS: maybe some quality control tools could check such missing tests (PMD > can do it)... > > I believe this was mentioned somewhere in j.u.logging. A better >> solution may be to take java.util.function.Supplier parameter that >> constructs the log message lazily (see >> http://download.java.net/jdk8/docs/api/java/util/logging/Logger.html#fine(java.util.function.Supplier). >> I can file a RFE to investigate the use of Supplier as in j.u.l.Logger. >> > > Very interesting feature, but I am still not aware of such JDK 8 features > (lambda) ... it seems nice but maybe the syntax will be more complicated / > verbose than our usual log statements: > log.fine(""...) > > Laurent > > >> >> On 4/5/2013 1:55 AM, Laurent Bourg?s wrote: >> >> Mandy, >> >> I would like to add few performance advices in the PlatformLogger Javadoc: >> " >> NOTE: For performance reasons, PlatformLogger usages should take care of >> avoiding useless / wasted object creation and method calls related to * >> disabled* log statements: >> Always use isLoggable(level) wrapping logs at levels (FINEST, FINER, >> FINE, CONFIG): >> >> Bad practices: >> - string concat: >> log.fine("message" + value); // means >> StringBuilder(message).append(String.valueOf(value)).toString(): 2 objects >> created and value.toString() called >> - varags: >> log.fine("message {0}", this); // create an Object[] >> >> Best practices: >> if (log.isLoggable(PlatformLogger.FINE) { >> log.fine("message" + value); >> } >> >> if (log.isLoggable(PlatformLogger.FINE) { >> log.fine("message {0}", this); >> } >> " >> >> What is your opinion ? >> >> Thanks for the given explanations and I hope that this patch will be >> submitted soon to JDK8 repository. >> >> Laurent >> >> > > From mike.duigou at oracle.com Sat Apr 6 22:02:17 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 6 Apr 2013 15:02:17 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> Message-ID: <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> Hello all; Another, and hopefully the final, update to the webrev for this issue. The revised webrev is here: http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ The important changes in this revision: - I've removed the serialData change in HashMap. The implementation now reads the capacity and gracefully handles non-power of 2 values. - I'm not entirely convinced that having serialization emulate clone() for capacity handling is the best answer. I might also want to change clone() to size it's result based upon the number of mappings in the source rather its the capacity. Anybody have strong feelings about this to suggest one behaviour is obviously better? Any other final thoughts? Mike On Apr 2 2013, at 15:50 , Mike Duigou wrote: > Hello again; > > I have updated the patch with the received review feedback. The revised webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > The important changes in this revision: > > - The behaviour of the readObject/writeObject serialization for both classes now more closely mirrors the behaviour of clone(). For ArrayList this means that the deserialized list has a capacity the same as the size. ie. as if trimToSize() was called. For HashMap, the opposite is true, the capacity is the same as was in effect when the object was serialized. (HashMap also tries to protect itself from nonsensical/harmful input). The implementation changes to serialization preserve forward and backward compatibility--all serialized objects are compatible with all implementations. I will file a spec change request for the addition of ", a power of 2" to the @serialData tag for this existing but previously unstated requirement. > > - Use of Arrays.fill has been reverted. I did change one fill case so that the loop can be optimized. (size field was being updated with each iteration). I very slightly expanded the docs. > > This is starting to look like a nice set of changes. > > Mike > > On Apr 1 2013, at 21:44 , Mike Duigou wrote: > >> Hello all; >> >> Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ >> >> It is currently unchanged from the last posted changeset for 7143928. >> >> Mike >> >> On Apr 1 2013, at 19:00 , Mike Duigou wrote: >> >>> Hello all; >>> >>> I have posted an updated version of the empty ArrayList and HashMap patch. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ >>> >>> This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. >>> >>> For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. >>> >>> Mike >>> >>> On Mar 26 2013, at 17:25 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. >>>> >>>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ >>>> >>>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. >>>> >>>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). >>>> >>>> Mike >>> >> > From sadhak001 at gmail.com Sat Apr 6 23:37:08 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sun, 7 Apr 2013 00:37:08 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <515E2B9E.3040607@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> Message-ID: Hi David, Sorry for not getting back earlier. Here's the changes to /jdk8_tl/jdk/test/java/lang/ref/Basic.java that you suggested earlier. -------------------x--------------------- diff -r 16f63a94c231 test/java/lang/ref/Basic.java --- a/test/java/lang/ref/Basic.java Fri Apr 05 18:20:12 2013 -0700 +++ b/test/java/lang/ref/Basic.java Sun Apr 07 00:27:55 2013 +0100 @@ -29,7 +29,7 @@ import java.lang.ref.*; import java.util.Vector; - +import java.util.concurrent.CountDownLatch; public class Basic { @@ -71,10 +71,11 @@ }); } - static void createNoise() throws InterruptedException { + static void createNoise(final CountDownLatch complete) throws InterruptedException { fork(new Runnable() { public void run() { keep.addElement(new PhantomReference(new Object(), q2)); + complete.countDown(); } }); } @@ -101,9 +102,11 @@ for (int i = 1;; i++) { Reference r; - createNoise(); ++ CountDownLatch noiseComplete = new CountDownLatch(1); ++ createNoise(noiseComplete); + System.err.println("GC " + i); - Thread.sleep(10); + noiseComplete.await(); System.gc(); System.runFinalization(); -------------------x--------------------- Its still implemented with CountdownLatch, but as you suggest we implement the above via Semaphore it will have to be the next version from me - CountdownLatch was suggested by many at the TestFest last month but personally I benefit from getting exposed to different techniques. I'll back to you with a solution applied using Semaphore. Cheers, mani On Fri, Apr 5, 2013 at 2:40 AM, David Holmes wrote: > On 5/04/2013 11:27 AM, Mani Sarkar wrote: > >> Hi David, >> >> I'll reply in more detail later but to respond to your comment on: >> >> > I would not add the extra methods around the cdl.await() and >> cdl.countDown() as they just obscure things >> In general its meant to do the opposite. We come across a lot of code >> that does not express intent, and the purpose of encapsulating such >> blocks (even if its a single line) is to make the flow verbose and >> readable - I have seen similar code-snippets in the Hotspot (C/C++ >> codebase) making it easy to follow what is going on. One of the things I >> picked up from TestFest was to make the tests more legible, logical and >> easy to maintain and scale - it was our intent when we changed this test. >> > > Sorry, createNoiseHasFinishedAddingTo**Keep is certainly verbose but not > readable. This would be much more readable: > > Countdownlatch noiseComplete = new ... > createNoise(noiseComplete); > ... > noiseComplete.await(); > > and: > > static void createNoise(final CountDownLatch complete) throws > InterruptedException { > ... > complete.countDown(); > } > > just giving the latch a meaningful name is sufficient to convey intent. > > Note: in this example a Semaphore is probably a better choice than a > CountDownLatch. > > Cheers, > David > > I'll come back with responses for your other comments. >> >> Cheers >> mani >> > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From bourges.laurent at gmail.com Sun Apr 7 17:11:23 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Sun, 7 Apr 2013 19:11:23 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> Message-ID: Hi I started fixing All PlatformlLogger "bad" usages and I am fixing also many jul Logger usages without isLoggable ... That represents a lot of changes and a very boring job. I think sending a webrew tomorrow. Laurent Le 4 avr. 2013 14:08, "Laurent Bourg?s" a ?crit : > Ok, I can provide an updated patch after finding / fixing all usages. > > Probably in 1 or 2 days, > > Laurent > > 2013/4/4 Anthony Petrov > >> Yes, this makes sense. Do you want to update your fix for 8010297 to >> include these changes as well? >> >> -- >> best regards, >> Anthony >> >> >> On 04/04/13 15:47, Laurent Bourg?s wrote: >> >>> Dear all, >>> >>> I just realized there is another problem with PlatformLogger log >>> statements: >>> XBaseWindow: >>> public boolean grabInput() { >>> grabLog.fine("Grab input on {0}", this); >>> ... >>> } >>> >>> This calls the PlatformLogger.fine( varargs): >>> public void fine(String msg, Object... params) { >>> logger.doLog(FINE, msg, params); >>> } >>> >>> Doing so, the JVM creates a new Object[] instance to provide params as >>> varargs. >>> >>> I would recommend using isLoggable() test to avoid such waste if the log >>> is disabled (fine, finer, finest ...). >>> >>> Do you want me to provide a new patch related to this problem ? >>> >>> Does somebody have an idea to automatically analyze the JDK code and >>> detect missing isLoggable statements ... >>> >>> Regards, >>> Laurent >>> >>> 2013/4/3 Laurent Bourg?s >> >> >>> >>> >>> Anthony, >>> >>> could you tell me once it is in the OpenJDK8 repository ? >>> I would then perform again profiling tests to check if there is no >>> more missing isLoggable() statements. >>> >>> Once JMX and other projects switch to PlatformLogger, I could check >>> again. >>> >>> Maybe I could write a small java code checker (pmd rule) to test if >>> there is missing isLoggable() statements wrapping PlatformLogger log >>> statements. Any idea about how to reuse java parser to do so ? >>> >>> Regards, >>> >>> Laurent >>> >>> 2013/4/2 Anthony Petrov >> >> >>> >>> >>> Looks fine to me as well. Thanks for fixing this, Laurent. >>> >>> Let's wait a couple more days in case Net or Swing folks want to >>> review the fix. After that I'll push it to the repository. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>> On 4/2/2013 15:35, Laurent Bourg?s wrote: >>> >>> Here is the updated patch: >>> http://jmmc.fr/~bourgesl/__**share/webrev-8010297.2/ >>> >>> > >>> >>> >>> Fixed inconsistencies between FINE / FINER log statements: >>> - XScrollbarPeer >>> - XWindowPeer >>> >>> Laurent >>> >>> 2013/4/2 Anthony Petrov >> >>> > >>> >> >>> >>> >>> >>> >>> >>> 1. Sergey: I believe this is for purposes of better >>> formating the >>> log output and making it more readable by separating or >>> highlighting >>> some sections. I don't think this should be changed. >>> >>> 2. Laurent: can you please address this issue and send >>> us a new patch? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>> On 4/1/2013 16:08, Sergey Bylokhov wrote: >>> >>> >>> Hi, Anthony >>> Only two comments: >>> 1 Why we need some special text in the log output >>> like "***" and >>> "###" >>> 2 XScrollbarPeer.java: >>> >>> + if >>> (log.isLoggable(____**PlatformLogger.FINEST)) { >>> >>> >>> + log.finer("KeyEvent on scrollbar: " + >>> event); >>> + } >>> >>> >>> >>> On 4/1/13 12:20 PM, Anthony Petrov wrote: >>> >>> Awt, Swing, Net engineers, >>> >>> Could anyone review the fix please? For your >>> convenience: >>> >>> Bug: >>> http://bugs.sun.com/view_bug._**___do?bug_id=8010297 >>> >>> > >>> >>> >>> >>> >> >>> >>> Fix: >>> http://cr.openjdk.java.net/~__** >>> __anthony/8-55-isLoggable-____**8010297.0/ >>> >> 7E__anthony/8-55-isLoggable-__**8010297.0/ >>> > >>> >> _7Eanthony/8-55-isLoggable-__**8010297.0/ >>> >> 8010297.0/ >>> >> >>> >>> -- best regards, >>> Anthony >>> >>> On 3/22/2013 2:26, Anthony Petrov wrote: >>> >>> Hi Laurent, >>> >>> The fix looks great to me. Thank you very >>> much. >>> >>> We still need at least one review, though. >>> Hopefully >>> net-dev@ and/or swing-dev@ folks might help >>> us out a bit. >>> >>> -- best regards, >>> Anthony >>> >>> On 3/20/2013 15:10, Anthony Petrov wrote: >>> >>> Hi Laurent, >>> >>> Thanks for the patch. I've filed a bug >>> at: >>> http://bugs.sun.com/view_bug._**___do?bug_id=8010297 >>> >>> > >>> >>> >>> >>> >>> >> >>> (should be available in a day or two) >>> >>> and published a webrev generated from >>> your patch at: >>> http://cr.openjdk.java.net/~__** >>> __anthony/8-55-isLoggable-____**8010297.0/ >>> >> 7E__anthony/8-55-isLoggable-__**8010297.0/ >>> > >>> >> _7Eanthony/8-55-isLoggable-__**8010297.0/ >>> >> 8010297.0/ >>> >> >>> >>> >>> I'm also copying swing-dev@ and >>> net-dev@ because the >>> fix affects those areas too. I myself >>> will review >>> the fix a bit later but am sending it >>> now for other >>> folks to take a look at it. >>> >>> On 3/19/2013 15:29, Laurent Bourg?s >>> wrote: >>> >>> I am sorry I started modifying >>> PlatformLogger >>> and reverted changes to this class >>> as it is >>> another topic to be discussed >>> later: isLoggable >>> performance and waste due to >>> HashMap>> Level> leads to Integer allocations >>> (boxing). >>> >>> >>> I saw your message to core-libs-dev@, >>> so I just >>> dropped all changes to the >>> PlatformLogger from this >>> patch. >>> >>> Finally, I have another question >>> related to the >>> WrapperGenerator class: it >>> generates a lot of >>> empty log statements (XEvent): >>> >>> log >>> >> repository.grepcode.com/java/_**___root/jdk/openjdk/6-b14/sun/** >>> ____awt/X11/XWrapperBase.java#**____XWrapperBase.0log >>> >> **_root/jdk/openjdk/6-b14/sun/__**awt/X11/XWrapperBase.java#__** >>> XWrapperBase.0log >>> > >>> >>> >> **_root/jdk/openjdk/6-b14/sun/__**awt/X11/XWrapperBase.java#__** >>> XWrapperBase.0log >>> >> root/jdk/openjdk/6-b14/sun/**awt/X11/XWrapperBase.java#** >>> XWrapperBase.0log >>> >>>.finest >>> >> repository.grepcode.com/java/_**___root/jdk/openjdk/6-b14/** >>> java/____util/logging/Logger.**java#____Logger.finest%28java.** >>> lang.____String%29 >>> >> **_root/jdk/openjdk/6-b14/java/_**_util/logging/Logger.java#__** >>> Logger.finest%28java.lang.__**String%29 >>> > >>> >>> >> **_root/jdk/openjdk/6-b14/java/_**_util/logging/Logger.java#__** >>> Logger.finest%28java.lang.__**String%29 >>> >> root/jdk/openjdk/6-b14/java/**util/logging/Logger.java#** >>> Logger.finest%28java.lang.**String%29 >>> >>>(""); >>> >>> >>> Is it really useful to have such >>> statements ? I >>> would keep logs with non empty >>> messages only. >>> >>> See WrapperGenerator:753: >>> String s_log = >>> >>> (generateLog?"log.finest(\"\")**____;":""); >>> >>> >>> >>> >>> I believe they're used for log >>> formatting purposes >>> to separate numerous events in a log >>> (e.g. think of >>> mouse-move events - there can be >>> hundreds of them in >>> a raw). >>> >>> >>> Please note that the hg export format >>> is not that >>> useful unless you're assigned an >>> OpenJDK id already >>> (please see Dalibor's message for >>> details) because I >>> can't import it directly. So for the >>> time being you >>> could send just raw patches (i.e. the >>> output of hg >>> diff only - and there's no need to >>> commit your >>> changes in this case). Also, please >>> note that the >>> mailing lists strip attachments. The >>> reason I got it >>> is because I was listed in To: of your >>> message. So >>> when sending patches you can: >>> 1) post them inline, or >>> 2) attach them and add a person to To: >>> of your >>> message, or >>> 3) upload them somewhere on the web. >>> However, it would be best if you could >>> generate a >>> webrev for your changes and upload it >>> somewhere. >>> Currently this is the standard format >>> for reviewing >>> fixes in OpenJDK. >>> >>> -- best regards, >>> Anthony >>> >>> >>> Regards, >>> Laurent >>> >>> >>> >>> 2013/3/19 Laurent Bourg?s >>> >> com > >>> >> >>> >> >>> >> ____com >>> >>> >> >>> >>>> >>> >>> Hi antony, >>> >>> FYI I started reviewing and >>> fixing all >>> PlatformLogger use cases (not >>> too many as I thought first) >>> mainly used by >>> awt / swing projects to >>> provide you a patch on latest >>> JDK8 source code: >>> >>> I am adding the log level check >>> when it is >>> missing: >>> if >>> (...log.isLoggable(____**PlatformLogger.xxx)) { >>> >>> >>> log... >>> } >>> >>> I will not change the String + >>> operations to >>> use the message format >>> syntax in this patch. >>> >>> Do you accept such patch / >>> proposed >>> contribution ? >>> >>> Regards, >>> Laurent >>> >>> >>> 2013/3/18 Laurent Bourg?s >>> >> com > >>> >> >>> >> >>> >> ____com >>> >>> >> >>> >>>> >>> >>> Hi antony, >>> >>> 2 different things: >>> 1/ PlatformLogger was >>> patched (doLog >>> method) to avoid string >>> operations (message >>> formatting) for >>> disabled logs (patch >>> submiited on JDK8 and >>> JDK7u): >>> http://mail.openjdk.java.net/_** >>> ___pipermail/jdk7u-dev/2012-__**__April/002751.html >>> >> __pipermail/jdk7u-dev/2012-__**April/002751.html >>> > >>> >>> >>> >> __pipermail/jdk7u-dev/2012-__**April/002751.html >>> >> April/002751.html >>> >> >>> >>> >>> 2/ I looked 2 hours ago on >>> JDK7u AND >>> JDK8 source codes and both >>> still have: >>> - log statements WITHOUT >>> log level check >>> : if >>> >>> (log.isLoggable(____**PlatformLogger.FINE)) >>> >>> >>> log.fine(...); >>> - string operations (+) in >>> log calls >>> that could be improved >>> using the message format >>> syntax (String >>> + args): for example, >>> avoid using >>> PlatformLogger.fine(String + >>> ...) in favor of using >>> PlatformLogger.fine(String >>> msg, >>> Object... params) >>> >>> I reported in my previous >>> mail several >>> cases where the >>> isLoggable() call is >>> missing and leads >>> to useless String >>> operations but also method >>> calls >>> (Component.paramString() for >>> example). >>> >>> Finally, I also provided >>> other possible >>> cases (using grep); >>> maybe there is a better >>> alternative to >>> find all occurences of >>> String operations in log >>> calls. >>> >>> Regards, >>> Laurent >>> >>> 2013/3/18 Anthony Petrov >>> >> com > >>> >> >>> >> >>> >> ____com >>> >>> >> >>> >>>> >>> >>> Hi Laurent, >>> >>> Normally we fix an >>> issue in JDK 8 >>> first, and then back-port >>> the fix to a 7u >>> release. You're >>> saying that in JDK 8 the >>> problem isn't >>> reproducible anymore. >>> Can you please >>> investigate (using the >>> Mercurial >>> history log) what exact fix >>> resolved it in JDK 8? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 03/18/13 15:09, >>> Laurent Bourg?s >>> wrote: >>> >>> Dear all, >>> >>> I run recently >>> netbeans profiler >>> on my swing application >>> (Aspro2: >>> http://www.jmmc.fr/aspro) under >>> linux x64 platform and I >>> figured out >>> that a lot of >>> char[] instances >>> are coming from String + >>> operator called >>> by sun.awt.X11 code. >>> >>> I looked at >>> PlatformLogger >>> source code but found not way >>> to disable it >>> completely: maybe >>> an empty >>> logger implementation could >>> be interesting to >>> be used during >>> profiling or >>> normal use (not debugging). >>> Apparently JDK8 >>> provides some >>> patchs to avoid String >>> creation when the >>> logger is disabled >>> (level). >>> >>> However, I looked >>> also to the >>> sun.awt code (jdk7u >>> repository) to see >>> the >>> origin of the >>> string allocations: >>> XDecoratedPeer: >>> public void >>> handleFocusEvent(XEvent xev) { >>> ... >>> * >>> focusLog.finer("Received focus event on shell: >>> " + xfe); >>> * } >>> >>> public boolean >>> requestWindowFocus(long time, >>> boolean >>> timeProvided) { >>> ... >>> * >>> focusLog.finest("Real native focused >>> window: " + >>> >>> realNativeFocusedWindow + >>> "\nKFM's focused window: " + >>> focusedWindow); >>> *... >>> * >>> focusLog.fine("Requesting focus to " + (this == >>> toFocus ? "this >>> window" : toFocus)); >>> *... >>> } >>> >>> XBaseWindow: >>> public void >>> xSetBounds(int >>> x, int y, int width, int >>> height) { >>> ... >>> * >>> insLog.fine("Setting >>> bounds on " + this + " to >>> (" + x + ", " + >>> y + "), " + width + >>> "x" + height); >>> *} >>> >>> XNetProtocol: >>> boolean >>> doStateProtocol() { >>> ... >>> * >>> stateLog.finer("______**doStateProtocol() >>> returns " + >>> >>> >>> res); >>> *} >>> >>> XSystemTrayPeer: >>> >>> XSystemTrayPeer(SystemTray >>> target) { >>> ... >>> * log.fine(" >>> check if >>> system tray is available. >>> selection owner: >>> " + selection_owner); >>> *} >>> void >>> addTrayIcon(XTrayIconPeer tiPeer) >>> throws >>> AWTException { >>> ... >>> * log.fine(" >>> send >>> SYSTEM_TRAY_REQUEST_DOCK >>> message to owner: " >>> + >>> selection_owner); >>> *} >>> >>> XFramePeer: >>> public void >>> handlePropertyNotify(XEvent xev) { >>> ... >>> >>> stateLog.finer("State is the same: " + >>> state); >>> } >>> >>> However I only give >>> here few >>> cases but certainly others >>> are still >>> present in the >>> source code; >>> maybe findbugs or netbeans >>> warnings could >>> help you finding >>> all of them. >>> >>> I advocate the >>> amount of waste >>> (GC) is not very >>> important but String >>> conversion are also >>> calling >>> several toString() methods >>> that can be >>> costly (event, >>> Frame, window ...) >>> >>> Finally, I ran few >>> grep commands >>> on the sun.awt.X11 code >>> (jdk7u) and you >>> can look at them to >>> see all >>> string + operations related >>> to log statements. >>> >>> PS: I may help >>> fixing the source >>> code but I have no idea >>> how to >>> collaborate >>> (provide a patch ?) >>> >>> Regards, >>> Laurent Bourg?s >>> >>> >>> >>> >>> >>> >>> -- Best regards, Sergey. >>> >>> >>> >>> >>> > From david.holmes at oracle.com Mon Apr 8 02:00:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Apr 2013 12:00:43 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> Message-ID: <516224CB.7070807@oracle.com> On 7/04/2013 9:37 AM, Mani Sarkar wrote: > Hi David, > > Sorry for not getting back earlier. Here's the changes to > /jdk8_tl/jdk/test/java/lang/ref/Basic.java that you suggested earlier. Okay but what about my comment that the latch usage is completely unnecessary in the first place ?? David ----- > -------------------x--------------------- > > diff -r 16f63a94c231 test/java/lang/ref/Basic.java > --- a/test/java/lang/ref/Basic.javaFri Apr 05 18:20:12 2013 -0700 > +++ b/test/java/lang/ref/Basic.javaSun Apr 07 00:27:55 2013 +0100 > @@ -29,7 +29,7 @@ > import java.lang.ref.*; > import java.util.Vector; > - > +import java.util.concurrent.CountDownLatch; > public class Basic { > @@ -71,10 +71,11 @@ > }); > } > - static void createNoise() throws InterruptedException { > + static void createNoise(final CountDownLatch complete) throws > InterruptedException { > fork(new Runnable() { > public void run() { > keep.addElement(new PhantomReference(new Object(), q2)); > + complete.countDown(); > } > }); > } > @@ -101,9 +102,11 @@ > for (int i = 1;; i++) { > Reference r; > - createNoise(); > ++ CountDownLatch noiseComplete = new CountDownLatch(1); > ++ createNoise(noiseComplete); > + > System.err.println("GC " + i); > - Thread.sleep(10); > + noiseComplete.await(); > System.gc(); > System.runFinalization(); > -------------------x--------------------- > > Its still implemented with CountdownLatch, but as you suggest we > implement the above via Semaphore it will have to be the next version > from me - CountdownLatch was suggested by many at the TestFest last > month but personally I benefit from getting exposed to different > techniques. I'll back to you with a solution applied using Semaphore. > > Cheers, > mani > > On Fri, Apr 5, 2013 at 2:40 AM, David Holmes > wrote: > > On 5/04/2013 11:27 AM, Mani Sarkar wrote: > > Hi David, > > I'll reply in more detail later but to respond to your comment on: > > > I would not add the extra methods around the cdl.await() and > cdl.countDown() as they just obscure things > In general its meant to do the opposite. We come across a lot of > code > that does not express intent, and the purpose of encapsulating such > blocks (even if its a single line) is to make the flow verbose and > readable - I have seen similar code-snippets in the Hotspot (C/C++ > codebase) making it easy to follow what is going on. One of the > things I > picked up from TestFest was to make the tests more legible, > logical and > easy to maintain and scale - it was our intent when we changed > this test. > > > Sorry, createNoiseHasFinishedAddingTo__Keep is certainly verbose but > not readable. This would be much more readable: > > Countdownlatch noiseComplete = new ... > createNoise(noiseComplete); > ... > noiseComplete.await(); > > and: > > static void createNoise(final CountDownLatch complete) throws > InterruptedException { > ... > complete.countDown(); > } > > just giving the latch a meaningful name is sufficient to convey intent. > > Note: in this example a Semaphore is probably a better choice than a > CountDownLatch. > > Cheers, > David > > I'll come back with responses for your other comments. > > Cheers > mani > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From huizhe.wang at oracle.com Mon Apr 8 07:39:40 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 08 Apr 2013 00:39:40 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 Message-ID: <5162743C.9030606@oracle.com> Hi Lance, Alan, As I mentioned, I'd like to propose an integration of JAXP 1.5 into JDK8. JAXP 1.5 adds a new feature to control connections. Here's the webrev: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ Thanks, Joe From bourges.laurent at gmail.com Mon Apr 8 07:48:28 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Mon, 8 Apr 2013 09:48:28 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: Andrea, Any feedback from anybody else ? Here are J2D Bench results: http://jmmc.fr/~bourgesl/share/java2d-pisces/j2DBench/ Depending on the test, performance gains varies from 20% to 100% ! I think it could be nice if you can perform tests (regression and benchmarks using MapBench, J2DBench, Java2D demos). I still have to enhance cleanup / tuning my code (stats, initial array sizes ...) and cache eviction (memory cleanup) using Weak references or manual cleanup using timestamps ... To test regression, I propose you to enhance your MapBench class to save image results (randomly in tests) and compare them after the test run (image diff) even when multiple threads are in use. If you apply my patch, take care of the following main settings: useThreadLocal should be disabled in a web container (to avoid too much memory waste): a RendererContext represents ~ 2Mb: rowAARLE = new int[INITIAL_Y_ARRAY][INITIAL_ARRAY]; // ~2Mb +1 to avoid recycling such shared arrays PiscesConst: /** use ThreadLocal or ConcurrentLinkedQueue to get the thread RendererContext */ static final boolean useThreadLocal = true; Initial RendererContext array capacity: // +1 to avoid recycling such shared arrays static final int INITIAL_ARRAY = 256 + 1; static final int INITIAL_Y_ARRAY = 2048 + 1; static final int INITIAL_LARGE_ARRAY = 16384 + 1; // large Laurent 2013/4/7 Andrea Aime > On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourg?s > wrote: > >> Dear all, >> >> Here is my first pisces (beta) patch (webrev): >> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ >> >> I succeed in fixing memory usage by having only 1 pisces instance >> (Renderer, stroker, iterator ...) per RendererContext (GC friendly). >> >> Impressive results between small and large drawings: >> > > Good stuff. Is there anything I can do to help? I do have an up to date > version of JDK 8 sources on my disk, maybe I could > try to apply the patch and take it for a spin in a real GeoServer and see > how it goes. > > By the way, wondering, is there any other benchmark to try out? > A possibly interesting one is this, where the author re-coded some > selected methods of Graphics2D for maximum performance > (but sometimes lower antialiasing quality) and created a applet to compare > the results in a number of synthetic test cases: > http://www.randelshofer.ch/oop/graphics/ > > Cheers > Andrea > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for more > information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > From peter.levart at gmail.com Mon Apr 8 09:00:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 08 Apr 2013 11:00:29 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> Message-ID: <5162872D.8060004@gmail.com> On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: > > Hi > > I started fixing All PlatformlLogger "bad" usages and I am fixing also > many jul Logger usages without isLoggable ... > That represents a lot of changes and a very boring job. > > I think sending a webrew tomorrow. > Hi Laurent, Since you're already deep in the task, you might have a rough feeling what part of such unguarded log statements are of the following type: logger.[fine,info,...]("a message with {0} and {1} placeholders", someArg1, someArg2); where someArg1, ... are some values that are already present in the context of the logging statement and don't have to be computed just for satisfying the logging (not even boxing). Such usages could be effectively optimized by adding some overloaded methods to PlatformLogger that take 1, 2, 3, ... arguments: class PlatformLogger { ... public void finest(String msg, Object param1) { if (isLoggable(Level.FINEST)) { loggerProxy.doLog(Level.FINEST, msg, param1); } } public void finest(String msg, Object param1, Object param2) { if (isLoggable(Level.FINEST)) { loggerProxy.doLog(Level.FINEST, msg, param1, param2); } } public void finest(String msg, Object param1, Object param2, Object param3) { if (isLoggable(Level.FINEST)) { loggerProxy.doLog(Level.FINEST, msg, param1, param2, param3); } } ... This would effectively guard creation of the arguments array with an isLoggable check for some common usages, eliminating the need to explicitly guard such statements. Of course, the user would have to be aware of when such unguarded logging statement is without overhead and when not... How do you feel about such API extension? Regards, Peter > Laurent > > Le 4 avr. 2013 14:08, "Laurent Bourg?s" > a ?crit : > > Ok, I can provide an updated patch after finding / fixing all usages. > > Probably in 1 or 2 days, > > Laurent > > 2013/4/4 Anthony Petrov > > > Yes, this makes sense. Do you want to update your fix for > 8010297 to include these changes as well? > > -- > best regards, > Anthony > > > On 04/04/13 15:47, Laurent Bourg?s wrote: > > Dear all, > > I just realized there is another problem with > PlatformLogger log statements: > XBaseWindow: > public boolean grabInput() { > grabLog.fine("Grab input on {0}", this); > ... > } > > This calls the PlatformLogger.fine( varargs): > public void fine(String msg, Object... params) { > logger.doLog(FINE, msg, params); > } > > Doing so, the JVM creates a new Object[] instance to > provide params as > varargs. > > I would recommend using isLoggable() test to avoid such > waste if the log > is disabled (fine, finer, finest ...). > > Do you want me to provide a new patch related to this > problem ? > > Does somebody have an idea to automatically analyze the > JDK code and > detect missing isLoggable statements ... > > Regards, > Laurent > > 2013/4/3 Laurent Bourg?s > >> > > > Anthony, > > could you tell me once it is in the OpenJDK8 repository ? > I would then perform again profiling tests to check if > there is no > more missing isLoggable() statements. > > Once JMX and other projects switch to PlatformLogger, > I could check > again. > > Maybe I could write a small java code checker (pmd > rule) to test if > there is missing isLoggable() statements wrapping > PlatformLogger log > statements. Any idea about how to reuse java parser to > do so ? > > Regards, > > Laurent > > 2013/4/2 Anthony Petrov > >> > > > Looks fine to me as well. Thanks for fixing this, > Laurent. > > Let's wait a couple more days in case Net or Swing > folks want to > review the fix. After that I'll push it to the > repository. > > -- > best regards, > Anthony > > > On 4/2/2013 15:35, Laurent Bourg?s wrote: > > Here is the updated patch: > http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ > > > > > > Fixed inconsistencies between FINE / FINER log > statements: > - XScrollbarPeer > - XWindowPeer > > Laurent > > 2013/4/2 Anthony Petrov > > > > __com > > >>> > > > 1. Sergey: I believe this is for purposes > of better > formating the > log output and making it more readable by > separating or > highlighting > some sections. I don't think this should > be changed. > > 2. Laurent: can you please address this > issue and send > us a new patch? > > -- > best regards, > Anthony > > > On 4/1/2013 16:08, Sergey Bylokhov wrote: > > > Hi, Anthony > Only two comments: > 1 Why we need some special text in > the log output > like "***" and > "###" > 2 XScrollbarPeer.java: > > + if > (log.isLoggable(____PlatformLogger.FINEST)) { > > > + log.finer("KeyEvent on > scrollbar: " + > event); > + } > > > > On 4/1/13 12:20 PM, Anthony Petrov wrote: > > Awt, Swing, Net engineers, > > Could anyone review the fix > please? For your > convenience: > > Bug: > http://bugs.sun.com/view_bug.____do?bug_id=8010297 > > > > > > > Fix: > http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ > > > > > > > > > -- best regards, > Anthony > > On 3/22/2013 2:26, Anthony Petrov > wrote: > > Hi Laurent, > > The fix looks great to me. > Thank you very much. > > We still need at least one > review, though. > Hopefully > net-dev@ and/or swing-dev@ > folks might help > us out a bit. > > -- best regards, > Anthony > > On 3/20/2013 15:10, Anthony > Petrov wrote: > > Hi Laurent, > > Thanks for the patch. > I've filed a bug at: > http://bugs.sun.com/view_bug.____do?bug_id=8010297 > > > > > > > (should be available in a > day or two) > > and published a webrev > generated from > your patch at: > http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ > > > > > > > > > > I'm also copying > swing-dev@ and > net-dev@ because the > fix affects those areas > too. I myself > will review > the fix a bit later but > am sending it > now for other > folks to take a look at it. > > On 3/19/2013 15:29, > Laurent Bourg?s wrote: > > I am sorry I started > modifying > PlatformLogger > and reverted changes > to this class > as it is > another topic to be > discussed > later: isLoggable > performance and waste > due to > HashMap Level> leads to > Integer allocations > (boxing). > > > I saw your message to > core-libs-dev@, > so I just > dropped all changes to the > PlatformLogger from this > patch. > > Finally, I have > another question > related to the > WrapperGenerator class: it > generates a lot of > empty log statements > (XEvent): > > log > > > > > > > > >>.finest > > > > > > > > >>(""); > > > Is it really useful > to have such > statements ? I > would keep logs with > non empty > messages only. > > See WrapperGenerator:753: > String s_log = > > (generateLog?"log.finest(\"\")____;":""); > > > > > I believe they're used > for log > formatting purposes > to separate numerous > events in a log > (e.g. think of > mouse-move events - there > can be > hundreds of them in > a raw). > > > Please note that the hg > export format > is not that > useful unless you're > assigned an > OpenJDK id already > (please see Dalibor's > message for > details) because I > can't import it directly. > So for the > time being you > could send just raw > patches (i.e. the > output of hg > diff only - and there's > no need to > commit your > changes in this case). > Also, please > note that the > mailing lists strip > attachments. The > reason I got it > is because I was listed > in To: of your > message. So > when sending patches you can: > 1) post them inline, or > 2) attach them and add a > person to To: > of your > message, or > 3) upload them somewhere > on the web. > However, it would be best > if you could > generate a > webrev for your changes > and upload it > somewhere. > Currently this is the > standard format > for reviewing > fixes in OpenJDK. > > -- best regards, > Anthony > > > Regards, > Laurent > > > > 2013/3/19 Laurent Bourg?s > > > > __com > >> > . > .>____com > > __com > >>>> > > Hi antony, > > FYI I started > reviewing and > fixing all > PlatformLogger use > cases (not > too many as I > thought first) > mainly used by > awt / swing projects to > provide you a > patch on latest > JDK8 source code: > > I am adding the > log level check > when it is > missing: > if > (...log.isLoggable(____PlatformLogger.xxx)) { > > > log... > } > > I will not change > the String + > operations to > use the message format > syntax in this patch. > > Do you accept > such patch / proposed > contribution ? > > Regards, > Laurent > > > 2013/3/18 Laurent > Bourg?s > > > > __com > >> > . > .>____com > > __com > >>>> > > Hi antony, > > 2 different > things: > 1/ > PlatformLogger was > patched (doLog > method) to avoid string > operations (message > formatting) for > disabled logs (patch > submiited on > JDK8 and JDK7u): > http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html > > > > > > > > > > > > 2/ I looked 2 > hours ago on > JDK7u AND > JDK8 source codes and > both > still have: > - log > statements WITHOUT > log level check > : if > > (log.isLoggable(____PlatformLogger.FINE)) > > > log.fine(...); > - string > operations (+) in > log calls > that could be improved > using the > message format > syntax (String > + args): for example, > avoid using > PlatformLogger.fine(String + > ...) in favor of using > PlatformLogger.fine(String msg, > Object... params) > > I reported in > my previous > mail several > cases where the > isLoggable() call is > missing and leads > to useless String > operations but also method > calls > (Component.paramString() for > example). > > Finally, I also provided > other possible > cases (using grep); > maybe there > is a better > alternative to > find all occurences of > String > operations in log calls. > > Regards, > Laurent > > 2013/3/18 Anthony Petrov > > > > __com > >> > . > .>____com > > __com > >>>> > > Hi Laurent, > > Normally we fix an > issue in JDK 8 > first, and then back-port > the fix > to a 7u > release. You're > saying that in JDK 8 the > problem isn't > reproducible anymore. > Can you please > investigate (using the > Mercurial > history log) what > exact fix > resolved it in JDK 8? > > -- > best regards, > Anthony > > On > 03/18/13 15:09, > Laurent Bourg?s > wrote: > > Dear all, > > I run recently > netbeans profiler > on my swing application > (Aspro2: > http://www.jmmc.fr/aspro) under > linux x64 platform and I > figured out > that a lot of > char[] instances > are coming from String + > operator called > by sun.awt.X11 code. > > I looked at > PlatformLogger > source code but found > not way > to disable it > completely: maybe > an empty > logger implementation > could > be interesting to > be used during > profiling or > normal use (not > debugging). > Apparently JDK8 > provides some > patchs to avoid String > creation when the > logger is disabled > (level). > > However, I looked > also to the > sun.awt code (jdk7u > repository) to see the > origin of the > string allocations: > XDecoratedPeer: > public void > handleFocusEvent(XEvent xev) { > ... > * > focusLog.finer("Received focus > event on shell: > " + xfe); > * } > > public boolean > requestWindowFocus(long time, > boolean timeProvided) { > ... > * > focusLog.finest("Real native > focused > window: " + > > realNativeFocusedWindow + > "\nKFM's focused window: " + > focusedWindow); > *... > * > focusLog.fine("Requesting focus > to " + (this == > toFocus ? "this > window" : toFocus)); > *... > } > > XBaseWindow: > public void > xSetBounds(int > x, int y, int width, int > height) { > ... > * > insLog.fine("Setting > bounds on " + this + " to > (" + x + ", " + > y + "), " + width + > "x" + height); > *} > > XNetProtocol: > boolean > doStateProtocol() { > ... > * > > stateLog.finer("______doStateProtocol() returns " + > > > res); > *} > > XSystemTrayPeer: > > XSystemTrayPeer(SystemTray > target) { > ... > * log.fine(" > check if > system tray is available. > selection owner: > " + selection_owner); > *} > void > addTrayIcon(XTrayIconPeer tiPeer) > throws > AWTException { > ... > * log.fine(" > send > SYSTEM_TRAY_REQUEST_DOCK > message to owner: " + > selection_owner); > *} > > XFramePeer: > public void > handlePropertyNotify(XEvent xev) { > ... > > stateLog.finer("State is the > same: " + state); > } > > However I only give > here few > cases but certainly > others > are still > present in the > source code; > maybe findbugs or > netbeans > warnings could > help you finding > all of them. > > I advocate the > amount of waste > (GC) is not very > important but String > conversion are also > calling > several toString() > methods > that can be > costly (event, > Frame, window ...) > > Finally, I ran few > grep commands > on the sun.awt.X11 code > (jdk7u) and you > can look at them to > see all > string + operations > related > to log statements. > > PS: I may help > fixing the source > code but I have no idea > how to > collaborate > (provide a patch ?) > > Regards, > Laurent Bourg?s > > > > > > > -- Best regards, Sergey. > > > > > From sadhak001 at gmail.com Mon Apr 8 09:39:30 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 8 Apr 2013 10:39:30 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <516224CB.7070807@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> Message-ID: Hi David, Here's the version of *jdk8_tl/jdk/**test/java/lang/ref/Basic.java*implemented using a Semaphore: ----------------x------------- diff -r 16f63a94c231 test/java/lang/ref/Basic.java --- a/test/java/lang/ref/Basic.java Fri Apr 05 18:20:12 2013 -0700 +++ b/test/java/lang/ref/Basic.java Sun Apr 07 11:06:17 2013 +0100 @@ -29,7 +29,7 @@ import java.lang.ref.*; import java.util.Vector; - +import java.util.concurrent.Semaphore; public class Basic { @@ -71,10 +71,11 @@ }); } - static void createNoise() throws InterruptedException { + static void createNoise(final Semaphore complete) throws InterruptedException { fork(new Runnable() { public void run() { keep.addElement(new PhantomReference(new Object(), q2)); + complete.release(); } }); } @@ -101,9 +102,12 @@ for (int i = 1;; i++) { Reference r; - createNoise(); - System.err.println("GC " + i); - Thread.sleep(10); + final Semaphore noiseComplete = new Semaphore(1); + noiseComplete.acquire(); + + createNoise(noiseComplete); + + System.err.println("GC " + i); System.gc(); System.runFinalization(); ----------------x------------- After running the test the first time I added temporary logging statements between the blocks of code that dealt with the Semaphore and got the below results: *----------System.out:(12/444)----------* *> Semaphore created.* *> Semaphore acquired.* *>> Inside createnoise(): before adding an element.* *>> Inside createnoise(): after adding an element.* *>> Inside createnoise(): Semaphore released.* *> After createnoise() is called.* *> Semaphore created.* *> Semaphore acquired.* *>> Inside createnoise(): before adding an element.* *>> Inside createnoise(): after adding an element.* *>> Inside createnoise(): Semaphore released.* *> After createnoise() is called.* What is the principle difference between CountdownLatch and Semaphore and why is a later more applicable in this context than the former? The mehanism by which they handle the two threads appears the same to me, could you please explain to satisfy my concurrency curiosity. Regards, mani On Mon, Apr 8, 2013 at 3:00 AM, David Holmes wrote: > On 7/04/2013 9:37 AM, Mani Sarkar wrote: > >> Hi David, >> >> Sorry for not getting back earlier. Here's the changes to >> /jdk8_tl/jdk/test/java/lang/**ref/Basic.java that you suggested earlier. >> > > Okay but what about my comment that the latch usage is completely > unnecessary in the first place ?? > > David > ----- > > -------------------x----------**----------- >> >> diff -r 16f63a94c231 test/java/lang/ref/Basic.java >> --- a/test/java/lang/ref/Basic.**javaFri Apr 05 18:20:12 2013 -0700 >> +++ b/test/java/lang/ref/Basic.**javaSun Apr 07 00:27:55 2013 +0100 >> >> @@ -29,7 +29,7 @@ >> import java.lang.ref.*; >> import java.util.Vector; >> - >> +import java.util.concurrent.**CountDownLatch; >> public class Basic { >> @@ -71,10 +71,11 @@ >> }); >> } >> - static void createNoise() throws InterruptedException { >> + static void createNoise(final CountDownLatch complete) throws >> InterruptedException { >> fork(new Runnable() { >> public void run() { >> keep.addElement(new PhantomReference(new Object(), q2)); >> + complete.countDown(); >> } >> }); >> } >> @@ -101,9 +102,11 @@ >> for (int i = 1;; i++) { >> Reference r; >> - createNoise(); >> ++ CountDownLatch noiseComplete = new CountDownLatch(1); >> ++ createNoise(noiseComplete); >> + >> System.err.println("GC " + i); >> - Thread.sleep(10); >> + noiseComplete.await(); >> System.gc(); >> System.runFinalization(); >> -------------------x----------**----------- >> >> Its still implemented with CountdownLatch, but as you suggest we >> implement the above via Semaphore it will have to be the next version >> from me - CountdownLatch was suggested by many at the TestFest last >> month but personally I benefit from getting exposed to different >> techniques. I'll back to you with a solution applied using Semaphore. >> >> Cheers, >> mani >> >> On Fri, Apr 5, 2013 at 2:40 AM, David Holmes > >> wrote: >> >> On 5/04/2013 11:27 AM, Mani Sarkar wrote: >> >> Hi David, >> >> I'll reply in more detail later but to respond to your comment on: >> >> > I would not add the extra methods around the cdl.await() and >> cdl.countDown() as they just obscure things >> In general its meant to do the opposite. We come across a lot of >> code >> that does not express intent, and the purpose of encapsulating >> such >> blocks (even if its a single line) is to make the flow verbose and >> readable - I have seen similar code-snippets in the Hotspot (C/C++ >> codebase) making it easy to follow what is going on. One of the >> things I >> picked up from TestFest was to make the tests more legible, >> logical and >> easy to maintain and scale - it was our intent when we changed >> this test. >> >> >> Sorry, createNoiseHasFinishedAddingTo**__Keep is certainly verbose >> but >> >> not readable. This would be much more readable: >> >> Countdownlatch noiseComplete = new ... >> createNoise(noiseComplete); >> ... >> noiseComplete.await(); >> >> and: >> >> static void createNoise(final CountDownLatch complete) throws >> InterruptedException { >> ... >> complete.countDown(); >> } >> >> just giving the latch a meaningful name is sufficient to convey >> intent. >> >> Note: in this example a Semaphore is probably a better choice than a >> CountDownLatch. >> >> Cheers, >> David >> >> I'll come back with responses for your other comments. >> >> Cheers >> mani >> >> >> >> >> -- >> *Twitter:* @theNeomatrix369 >> *Blog:* http://neomatrix369.wordpress.**com >> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project:* https://github.com/**MutabilityDetector >> *Devoxx UK 2013 was a grand success:* >> http://www.devoxx.com/display/**UK13/Home >> */Don't chase success, rather aim for "Excellence", and success will >> come chasing after you!/* >> > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From bourges.laurent at gmail.com Mon Apr 8 10:06:53 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Mon, 8 Apr 2013 12:06:53 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <5162872D.8060004@gmail.com> References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> Message-ID: Peter, Mandy, I think it would be great to make PlatformLogger very similar to Logger API: I mean JUL Logger already has only 1 convenient method with 1 param so it may be great to have the same API in PlatformLogger too: maybe extend it to 2 or 3 params ... Peter, could you look at the API differences between Logger / PlatformLogger to make PlatformLogger API more similar to JUL Logger ? Laurent 2013/4/8 Peter Levart > On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: > > Hi > > I started fixing All PlatformlLogger "bad" usages and I am fixing also > many jul Logger usages without isLoggable ... > That represents a lot of changes and a very boring job. > > I think sending a webrew tomorrow. > > > Hi Laurent, > > Since you're already deep in the task, you might have a rough feeling what > part of such unguarded log statements are of the following type: > > logger.[fine,info,...]("a message with {0} and {1} placeholders", > someArg1, someArg2); > > where someArg1, ... are some values that are already present in the > context of the logging statement and don't have to be computed just for > satisfying the logging (not even boxing). Such usages could be effectively > optimized by adding some overloaded methods to PlatformLogger that take 1, > 2, 3, ... arguments: > > class PlatformLogger { > > ... > > public void finest(String msg, Object param1) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1); > } > } > > public void finest(String msg, Object param1, Object param2) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2); > } > } > > public void finest(String msg, Object param1, Object param2, Object > param3) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2, param3); > } > } > > ... > > This would effectively guard creation of the arguments array with an > isLoggable check for some common usages, eliminating the need to explicitly > guard such statements. Of course, the user would have to be aware of when > such unguarded logging statement is without overhead and when not... > > How do you feel about such API extension? > > > Regards, Peter > > > > Laurent > Le 4 avr. 2013 14:08, "Laurent Bourg?s" a > ?crit : > >> Ok, I can provide an updated patch after finding / fixing all usages. >> >> Probably in 1 or 2 days, >> >> Laurent >> >> 2013/4/4 Anthony Petrov >> >>> Yes, this makes sense. Do you want to update your fix for 8010297 to >>> include these changes as well? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>> On 04/04/13 15:47, Laurent Bourg?s wrote: >>> >>>> Dear all, >>>> >>>> I just realized there is another problem with PlatformLogger log >>>> statements: >>>> XBaseWindow: >>>> public boolean grabInput() { >>>> grabLog.fine("Grab input on {0}", this); >>>> ... >>>> } >>>> >>>> This calls the PlatformLogger.fine( varargs): >>>> public void fine(String msg, Object... params) { >>>> logger.doLog(FINE, msg, params); >>>> } >>>> >>>> Doing so, the JVM creates a new Object[] instance to provide params as >>>> varargs. >>>> >>>> I would recommend using isLoggable() test to avoid such waste if the log >>>> is disabled (fine, finer, finest ...). >>>> >>>> Do you want me to provide a new patch related to this problem ? >>>> >>>> Does somebody have an idea to automatically analyze the JDK code and >>>> detect missing isLoggable statements ... >>>> >>>> Regards, >>>> Laurent >>>> >>>> 2013/4/3 Laurent Bourg?s >>> > >>>> >>>> >>>> Anthony, >>>> >>>> could you tell me once it is in the OpenJDK8 repository ? >>>> I would then perform again profiling tests to check if there is no >>>> more missing isLoggable() statements. >>>> >>>> Once JMX and other projects switch to PlatformLogger, I could check >>>> again. >>>> >>>> Maybe I could write a small java code checker (pmd rule) to test if >>>> there is missing isLoggable() statements wrapping PlatformLogger log >>>> statements. Any idea about how to reuse java parser to do so ? >>>> >>>> Regards, >>>> >>>> Laurent >>>> >>>> 2013/4/2 Anthony Petrov >>> > >>>> >>>> >>>> Looks fine to me as well. Thanks for fixing this, Laurent. >>>> >>>> Let's wait a couple more days in case Net or Swing folks want to >>>> review the fix. After that I'll push it to the repository. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>> On 4/2/2013 15:35, Laurent Bourg?s wrote: >>>> >>>> Here is the updated patch: >>>> http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ >>>> >>>> >>>> >>>> Fixed inconsistencies between FINE / FINER log statements: >>>> - XScrollbarPeer >>>> - XWindowPeer >>>> >>>> Laurent >>>> >>>> 2013/4/2 Anthony Petrov >>> >>>> >>> >>>> >> >>>> >>>> >>>> 1. Sergey: I believe this is for purposes of better >>>> formating the >>>> log output and making it more readable by separating or >>>> highlighting >>>> some sections. I don't think this should be changed. >>>> >>>> 2. Laurent: can you please address this issue and send >>>> us a new patch? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>> On 4/1/2013 16:08, Sergey Bylokhov wrote: >>>> >>>> >>>> Hi, Anthony >>>> Only two comments: >>>> 1 Why we need some special text in the log output >>>> like "***" and >>>> "###" >>>> 2 XScrollbarPeer.java: >>>> >>>> + if >>>> (log.isLoggable(____PlatformLogger.FINEST)) { >>>> >>>> >>>> + log.finer("KeyEvent on scrollbar: " + >>>> event); >>>> + } >>>> >>>> >>>> >>>> On 4/1/13 12:20 PM, Anthony Petrov wrote: >>>> >>>> Awt, Swing, Net engineers, >>>> >>>> Could anyone review the fix please? For your >>>> convenience: >>>> >>>> Bug: >>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>> >>>> >>>> >>> > >>>> >>>> Fix: >>>> >>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>> < >>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>> < >>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>> < >>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>> >>>> -- best regards, >>>> Anthony >>>> >>>> On 3/22/2013 2:26, Anthony Petrov wrote: >>>> >>>> Hi Laurent, >>>> >>>> The fix looks great to me. Thank you very >>>> much. >>>> >>>> We still need at least one review, though. >>>> Hopefully >>>> net-dev@ and/or swing-dev@ folks might >>>> help >>>> us out a bit. >>>> >>>> -- best regards, >>>> Anthony >>>> >>>> On 3/20/2013 15:10, Anthony Petrov wrote: >>>> >>>> Hi Laurent, >>>> >>>> Thanks for the patch. I've filed a bug >>>> at: >>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>> >>>> >>>> >>>> >>> > >>>> (should be available in a day or two) >>>> >>>> and published a webrev generated from >>>> your patch at: >>>> >>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>> < >>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>> < >>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>> < >>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>> >>>> >>>> I'm also copying swing-dev@ and >>>> net-dev@ because the >>>> fix affects those areas too. I myself >>>> will review >>>> the fix a bit later but am sending it >>>> now for other >>>> folks to take a look at it. >>>> >>>> On 3/19/2013 15:29, Laurent Bourg?s >>>> wrote: >>>> >>>> I am sorry I started modifying >>>> PlatformLogger >>>> and reverted changes to this class >>>> as it is >>>> another topic to be discussed >>>> later: isLoggable >>>> performance and waste due to >>>> HashMap>>> Level> leads to Integer allocations >>>> (boxing). >>>> >>>> >>>> I saw your message to core-libs-dev@, >>>> so I just >>>> dropped all changes to the >>>> PlatformLogger from this >>>> patch. >>>> >>>> Finally, I have another question >>>> related to the >>>> WrapperGenerator class: it >>>> generates a lot of >>>> empty log statements (XEvent): >>>> >>>> log >>>> < >>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/sun/____awt/X11/XWrapperBase.java#____XWrapperBase.0log >>>> < >>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log> >>>> >>>> >>>> < >>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log >>>> < >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/awt/X11/XWrapperBase.java#XWrapperBase.0log >>>> >>>.finest >>>> < >>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/java/____util/logging/Logger.java#____Logger.finest%28java.lang.____String%29 >>>> < >>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29> >>>> >>>> >>>> < >>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29 >>>> < >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/logging/Logger.java#Logger.finest%28java.lang.String%29 >>>> >>>(""); >>>> >>>> >>>> Is it really useful to have such >>>> statements ? I >>>> would keep logs with non empty >>>> messages only. >>>> >>>> See WrapperGenerator:753: >>>> String s_log = >>>> >>>> (generateLog?"log.finest(\"\")____;":""); >>>> >>>> >>>> >>>> >>>> I believe they're used for log >>>> formatting purposes >>>> to separate numerous events in a log >>>> (e.g. think of >>>> mouse-move events - there can be >>>> hundreds of them in >>>> a raw). >>>> >>>> >>>> Please note that the hg export format >>>> is not that >>>> useful unless you're assigned an >>>> OpenJDK id already >>>> (please see Dalibor's message for >>>> details) because I >>>> can't import it directly. So for the >>>> time being you >>>> could send just raw patches (i.e. the >>>> output of hg >>>> diff only - and there's no need to >>>> commit your >>>> changes in this case). Also, please >>>> note that the >>>> mailing lists strip attachments. The >>>> reason I got it >>>> is because I was listed in To: of your >>>> message. So >>>> when sending patches you can: >>>> 1) post them inline, or >>>> 2) attach them and add a person to To: >>>> of your >>>> message, or >>>> 3) upload them somewhere on the web. >>>> However, it would be best if you could >>>> generate a >>>> webrev for your changes and upload it >>>> somewhere. >>>> Currently this is the standard format >>>> for reviewing >>>> fixes in OpenJDK. >>>> >>>> -- best regards, >>>> Anthony >>>> >>>> >>>> Regards, >>>> Laurent >>>> >>>> >>>> >>>> 2013/3/19 Laurent Bourg?s >>>> >>> bourges.laurent at gmail.com> >>>> >>> > >>>> >>> ____com >>>> >>>> >>> >>> >>>> >>>> Hi antony, >>>> >>>> FYI I started reviewing and >>>> fixing all >>>> PlatformLogger use cases (not >>>> too many as I thought first) >>>> mainly used by >>>> awt / swing projects to >>>> provide you a patch on latest >>>> JDK8 source code: >>>> >>>> I am adding the log level check >>>> when it is >>>> missing: >>>> if >>>> (...log.isLoggable(____PlatformLogger.xxx)) { >>>> >>>> >>>> log... >>>> } >>>> >>>> I will not change the String + >>>> operations to >>>> use the message format >>>> syntax in this patch. >>>> >>>> Do you accept such patch / >>>> proposed >>>> contribution ? >>>> >>>> Regards, >>>> Laurent >>>> >>>> >>>> 2013/3/18 Laurent Bourg?s >>>> >>> bourges.laurent at gmail.com> >>>> >>> > >>>> >>> ____com >>>> >>>> >>> >>> >>>> >>>> Hi antony, >>>> >>>> 2 different things: >>>> 1/ PlatformLogger was >>>> patched (doLog >>>> method) to avoid string >>>> operations (message >>>> formatting) for >>>> disabled logs (patch >>>> submiited on JDK8 and >>>> JDK7u): >>>> >>>> http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html >>>> < >>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html> >>>> >>>> >>>> >>>> < >>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html >>>> < >>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-April/002751.html >>>> >> >>>> >>>> >>>> 2/ I looked 2 hours ago on >>>> JDK7u AND >>>> JDK8 source codes and both >>>> still have: >>>> - log statements WITHOUT >>>> log level check >>>> : if >>>> >>>> (log.isLoggable(____PlatformLogger.FINE)) >>>> >>>> >>>> log.fine(...); >>>> - string operations (+) in >>>> log calls >>>> that could be improved >>>> using the message format >>>> syntax (String >>>> + args): for example, >>>> avoid using >>>> PlatformLogger.fine(String + >>>> ...) in favor of using >>>> PlatformLogger.fine(String >>>> msg, >>>> Object... params) >>>> >>>> I reported in my previous >>>> mail several >>>> cases where the >>>> isLoggable() call is >>>> missing and leads >>>> to useless String >>>> operations but also method >>>> calls >>>> (Component.paramString() for >>>> example). >>>> >>>> Finally, I also provided >>>> other possible >>>> cases (using grep); >>>> maybe there is a better >>>> alternative to >>>> find all occurences of >>>> String operations in log >>>> calls. >>>> >>>> Regards, >>>> Laurent >>>> >>>> 2013/3/18 Anthony Petrov >>>> >>> anthony.petrov at oracle.com> >>>> >>> > >>>> >>> ____com >>>> >>>> >>> >>> >>>> >>>> Hi Laurent, >>>> >>>> Normally we fix an >>>> issue in JDK 8 >>>> first, and then back-port >>>> the fix to a 7u >>>> release. You're >>>> saying that in JDK 8 the >>>> problem isn't >>>> reproducible anymore. >>>> Can you please >>>> investigate (using the >>>> Mercurial >>>> history log) what exact fix >>>> resolved it in JDK 8? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 03/18/13 15:09, >>>> Laurent Bourg?s >>>> wrote: >>>> >>>> Dear all, >>>> >>>> I run recently >>>> netbeans profiler >>>> on my swing application >>>> (Aspro2: >>>> http://www.jmmc.fr/aspro) under >>>> linux x64 platform and I >>>> figured out >>>> that a lot of >>>> char[] instances >>>> are coming from String + >>>> operator called >>>> by sun.awt.X11 >>>> code. >>>> >>>> I looked at >>>> PlatformLogger >>>> source code but found not way >>>> to disable it >>>> completely: maybe >>>> an empty >>>> logger implementation could >>>> be interesting to >>>> be used during >>>> profiling or >>>> normal use (not debugging). >>>> Apparently JDK8 >>>> provides some >>>> patchs to avoid String >>>> creation when the >>>> logger is disabled >>>> (level). >>>> >>>> However, I looked >>>> also to the >>>> sun.awt code (jdk7u >>>> repository) to see >>>> the >>>> origin of the >>>> string allocations: >>>> XDecoratedPeer: >>>> public void >>>> handleFocusEvent(XEvent xev) { >>>> ... >>>> * >>>> focusLog.finer("Received focus event on shell: >>>> " + xfe); >>>> * } >>>> >>>> public boolean >>>> requestWindowFocus(long time, >>>> boolean >>>> timeProvided) { >>>> ... >>>> * >>>> focusLog.finest("Real native focused >>>> window: " + >>>> >>>> realNativeFocusedWindow + >>>> "\nKFM's focused window: " + >>>> focusedWindow); >>>> *... >>>> * >>>> focusLog.fine("Requesting focus to " + (this == >>>> toFocus ? "this >>>> window" : >>>> toFocus)); >>>> *... >>>> } >>>> >>>> XBaseWindow: >>>> public void >>>> xSetBounds(int >>>> x, int y, int width, int >>>> height) { >>>> ... >>>> * >>>> insLog.fine("Setting >>>> bounds on " + this + " to >>>> (" + x + ", " + >>>> y + "), " + width + >>>> "x" + height); >>>> *} >>>> >>>> XNetProtocol: >>>> boolean >>>> doStateProtocol() { >>>> ... >>>> * >>>> stateLog.finer("______doStateProtocol() >>>> returns " + >>>> >>>> >>>> res); >>>> *} >>>> >>>> XSystemTrayPeer: >>>> >>>> XSystemTrayPeer(SystemTray >>>> target) { >>>> ... >>>> * log.fine(" >>>> check if >>>> system tray is available. >>>> selection owner: >>>> " + selection_owner); >>>> *} >>>> void >>>> addTrayIcon(XTrayIconPeer tiPeer) >>>> throws >>>> AWTException { >>>> ... >>>> * log.fine(" >>>> send >>>> SYSTEM_TRAY_REQUEST_DOCK >>>> message to owner: >>>> " + >>>> selection_owner); >>>> *} >>>> >>>> XFramePeer: >>>> public void >>>> handlePropertyNotify(XEvent xev) { >>>> ... >>>> >>>> stateLog.finer("State is the same: " + >>>> state); >>>> } >>>> >>>> However I only give >>>> here few >>>> cases but certainly others >>>> are still >>>> present in the >>>> source code; >>>> maybe findbugs or netbeans >>>> warnings could >>>> help you finding >>>> all of them. >>>> >>>> I advocate the >>>> amount of waste >>>> (GC) is not very >>>> important but >>>> String >>>> conversion are also >>>> calling >>>> several toString() methods >>>> that can be >>>> costly (event, >>>> Frame, window ...) >>>> >>>> Finally, I ran few >>>> grep commands >>>> on the sun.awt.X11 code >>>> (jdk7u) and you >>>> can look at them to >>>> see all >>>> string + operations related >>>> to log statements. >>>> >>>> PS: I may help >>>> fixing the source >>>> code but I have no idea >>>> how to >>>> collaborate >>>> (provide a patch ?) >>>> >>>> Regards, >>>> Laurent Bourg?s >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- Best regards, Sergey. >>>> >>>> >>>> >>>> >>>> >> > From Alan.Bateman at oracle.com Mon Apr 8 10:07:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Apr 2013 11:07:24 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> Message-ID: <516296DC.9050302@oracle.com> On 08/04/2013 10:39, Mani Sarkar wrote: > Hi David, > > Here's the version of > *jdk8_tl/jdk/**test/java/lang/ref/Basic.java*implemented using a > Semaphore: > Hi Mani, Is there a handshake really needed here? From a quick look at the test then it looks to me that fork (used by createNoise) does a Thread.join so it waiting until the task is complete before it returns. -Alan From sadhak001 at gmail.com Mon Apr 8 10:53:00 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 8 Apr 2013 11:53:00 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <516296DC.9050302@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> Message-ID: We initially introduced CountdownLatch and now Semaphore, to replace the Thread.sleep(10) which took place before - what appears to be a forced GC (am I right?): System.err.println("GC " + i); System.gc(); System.runFinalization(); As the threads join at the ends of the other, then we can do away with the Semaphore but how would we simulate the 10ms pause before the forced GC - is that necessary? Can we still use Semaphores to implement pauses? Cheers, mani On Mon, Apr 8, 2013 at 11:07 AM, Alan Bateman wrote: > On 08/04/2013 10:39, Mani Sarkar wrote: > >> Hi David, >> >> Here's the version of >> *jdk8_tl/jdk/**test/java/lang/**ref/Basic.java*implemented using a >> Semaphore: >> >> Hi Mani, > > Is there a handshake really needed here? From a quick look at the test > then it looks to me that fork (used by createNoise) does a Thread.join so > it waiting until the task is complete before it returns. > > -Alan > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From david.holmes at oracle.com Mon Apr 8 11:20:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Apr 2013 21:20:13 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> Message-ID: <5162A7ED.1020009@oracle.com> Mani, Please go back to my original response. As Alan has just re-stated we do not need a latch or a semaphore here because we already do a join on the thread. As I have said the sleep is to allow the GC a chance to run (eg finalizer and/or reference processor thread). David On 8/04/2013 8:53 PM, Mani Sarkar wrote: > We initially introduced CountdownLatch and now Semaphore, to replace the > Thread.sleep(10) which took place before - what appears to be a forced GC > (am I right?): > > System.err.println("GC " + i); > System.gc(); > System.runFinalization(); > > As the threads join at the ends of the other, then we can do away with the > Semaphore but how would we simulate the 10ms pause before the forced GC - > is that necessary? Can we still use Semaphores to implement pauses? > > Cheers, > mani > > On Mon, Apr 8, 2013 at 11:07 AM, Alan Bateman wrote: > >> On 08/04/2013 10:39, Mani Sarkar wrote: >> >>> Hi David, >>> >>> Here's the version of >>> *jdk8_tl/jdk/**test/java/lang/**ref/Basic.java*implemented using a >>> Semaphore: >>> >>> Hi Mani, >> >> Is there a handshake really needed here? From a quick look at the test >> then it looks to me that fork (used by createNoise) does a Thread.join so >> it waiting until the task is complete before it returns. >> >> -Alan >> > > > From david.holmes at oracle.com Mon Apr 8 11:22:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Apr 2013 21:22:01 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> Message-ID: <5162A859.2050008@oracle.com> On 8/04/2013 7:39 PM, Mani Sarkar wrote: > Hi David, > > Here's the version of > *jdk8_tl/jdk/**test/java/lang/ref/Basic.java*implemented using a > Semaphore: > > ----------------x------------- > diff -r 16f63a94c231 test/java/lang/ref/Basic.java > --- a/test/java/lang/ref/Basic.java Fri Apr 05 18:20:12 2013 -0700 > +++ b/test/java/lang/ref/Basic.java Sun Apr 07 11:06:17 2013 +0100 > @@ -29,7 +29,7 @@ > > import java.lang.ref.*; > import java.util.Vector; > - > +import java.util.concurrent.Semaphore; > > public class Basic { > > @@ -71,10 +71,11 @@ > }); > } > > - static void createNoise() throws InterruptedException { > + static void createNoise(final Semaphore complete) throws > InterruptedException { > fork(new Runnable() { > public void run() { > keep.addElement(new PhantomReference(new Object(), q2)); > + complete.release(); > } > }); > } > @@ -101,9 +102,12 @@ > for (int i = 1;; i++) { > Reference r; > > - createNoise(); > - System.err.println("GC " + i); > - Thread.sleep(10); > + final Semaphore noiseComplete = new Semaphore(1); > + noiseComplete.acquire(); > + > + createNoise(noiseComplete); This is wrong. You would want: final Semaphore noiseComplete = new Semaphore(0); createNoise(noiseComplete); noiseComplete.acquire(); but again this is not needed at all. David ------ > + > + System.err.println("GC " + i); > System.gc(); > System.runFinalization(); > ----------------x------------- > > After running the test the first time I added temporary logging statements > between the blocks of code that dealt with the Semaphore and got the below > results: > > *----------System.out:(12/444)----------* > *> Semaphore created.* > *> Semaphore acquired.* > *>> Inside createnoise(): before adding an element.* > *>> Inside createnoise(): after adding an element.* > *>> Inside createnoise(): Semaphore released.* > *> After createnoise() is called.* > *> Semaphore created.* > *> Semaphore acquired.* > *>> Inside createnoise(): before adding an element.* > *>> Inside createnoise(): after adding an element.* > *>> Inside createnoise(): Semaphore released.* > *> After createnoise() is called.* > > What is the principle difference between CountdownLatch and Semaphore and > why is a later more applicable in this context than the former? The > mehanism by which they handle the two threads appears the same to me, could > you please explain to satisfy my concurrency curiosity. > > Regards, > mani > > On Mon, Apr 8, 2013 at 3:00 AM, David Holmes wrote: > >> On 7/04/2013 9:37 AM, Mani Sarkar wrote: >> >>> Hi David, >>> >>> Sorry for not getting back earlier. Here's the changes to >>> /jdk8_tl/jdk/test/java/lang/**ref/Basic.java that you suggested earlier. >>> >> >> Okay but what about my comment that the latch usage is completely >> unnecessary in the first place ?? >> >> David >> ----- >> >> -------------------x----------**----------- >>> >>> diff -r 16f63a94c231 test/java/lang/ref/Basic.java >>> --- a/test/java/lang/ref/Basic.**javaFri Apr 05 18:20:12 2013 -0700 >>> +++ b/test/java/lang/ref/Basic.**javaSun Apr 07 00:27:55 2013 +0100 >>> >>> @@ -29,7 +29,7 @@ >>> import java.lang.ref.*; >>> import java.util.Vector; >>> - >>> +import java.util.concurrent.**CountDownLatch; >>> public class Basic { >>> @@ -71,10 +71,11 @@ >>> }); >>> } >>> - static void createNoise() throws InterruptedException { >>> + static void createNoise(final CountDownLatch complete) throws >>> InterruptedException { >>> fork(new Runnable() { >>> public void run() { >>> keep.addElement(new PhantomReference(new Object(), q2)); >>> + complete.countDown(); >>> } >>> }); >>> } >>> @@ -101,9 +102,11 @@ >>> for (int i = 1;; i++) { >>> Reference r; >>> - createNoise(); >>> ++ CountDownLatch noiseComplete = new CountDownLatch(1); >>> ++ createNoise(noiseComplete); >>> + >>> System.err.println("GC " + i); >>> - Thread.sleep(10); >>> + noiseComplete.await(); >>> System.gc(); >>> System.runFinalization(); >>> -------------------x----------**----------- >>> >>> Its still implemented with CountdownLatch, but as you suggest we >>> implement the above via Semaphore it will have to be the next version >>> from me - CountdownLatch was suggested by many at the TestFest last >>> month but personally I benefit from getting exposed to different >>> techniques. I'll back to you with a solution applied using Semaphore. >>> >>> Cheers, >>> mani >>> >>> On Fri, Apr 5, 2013 at 2:40 AM, David Holmes >> >> wrote: >>> >>> On 5/04/2013 11:27 AM, Mani Sarkar wrote: >>> >>> Hi David, >>> >>> I'll reply in more detail later but to respond to your comment on: >>> >>> > I would not add the extra methods around the cdl.await() and >>> cdl.countDown() as they just obscure things >>> In general its meant to do the opposite. We come across a lot of >>> code >>> that does not express intent, and the purpose of encapsulating >>> such >>> blocks (even if its a single line) is to make the flow verbose and >>> readable - I have seen similar code-snippets in the Hotspot (C/C++ >>> codebase) making it easy to follow what is going on. One of the >>> things I >>> picked up from TestFest was to make the tests more legible, >>> logical and >>> easy to maintain and scale - it was our intent when we changed >>> this test. >>> >>> >>> Sorry, createNoiseHasFinishedAddingTo**__Keep is certainly verbose >>> but >>> >>> not readable. This would be much more readable: >>> >>> Countdownlatch noiseComplete = new ... >>> createNoise(noiseComplete); >>> ... >>> noiseComplete.await(); >>> >>> and: >>> >>> static void createNoise(final CountDownLatch complete) throws >>> InterruptedException { >>> ... >>> complete.countDown(); >>> } >>> >>> just giving the latch a meaningful name is sufficient to convey >>> intent. >>> >>> Note: in this example a Semaphore is probably a better choice than a >>> CountDownLatch. >>> >>> Cheers, >>> David >>> >>> I'll come back with responses for your other comments. >>> >>> Cheers >>> mani >>> >>> >>> >>> >>> -- >>> *Twitter:* @theNeomatrix369 >>> *Blog:* http://neomatrix369.wordpress.**com >>> *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project:* https://github.com/**MutabilityDetector >>> *Devoxx UK 2013 was a grand success:* >>> http://www.devoxx.com/display/**UK13/Home >>> */Don't chase success, rather aim for "Excellence", and success will >>> come chasing after you!/* >>> >> > > From bourges.laurent at gmail.com Mon Apr 8 11:32:01 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Mon, 8 Apr 2013 13:32:01 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> Message-ID: Anthony, here is an updated patch concerning both PlatformLogger and Logger 'bad' usages: http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ It impacts now awt, swing, JMX, security, network, and apache xml. Thanks for the review, Laurent 2013/4/8 Laurent Bourg?s > Peter, Mandy, > > I think it would be great to make PlatformLogger very similar to Logger > API: > I mean JUL Logger already has only 1 convenient method with 1 param so it > may be great to have the same API in PlatformLogger too: maybe extend it to > 2 or 3 params ... > > Peter, could you look at the API differences between Logger / > PlatformLogger to make PlatformLogger API more similar to JUL Logger ? > > Laurent > > > 2013/4/8 Peter Levart > >> On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: >> >> Hi >> >> I started fixing All PlatformlLogger "bad" usages and I am fixing also >> many jul Logger usages without isLoggable ... >> That represents a lot of changes and a very boring job. >> >> I think sending a webrew tomorrow. >> >> >> Hi Laurent, >> >> Since you're already deep in the task, you might have a rough feeling >> what part of such unguarded log statements are of the following type: >> >> logger.[fine,info,...]("a message with {0} and {1} placeholders", >> someArg1, someArg2); >> >> where someArg1, ... are some values that are already present in the >> context of the logging statement and don't have to be computed just for >> satisfying the logging (not even boxing). Such usages could be effectively >> optimized by adding some overloaded methods to PlatformLogger that take 1, >> 2, 3, ... arguments: >> >> class PlatformLogger { >> >> ... >> >> public void finest(String msg, Object param1) { >> if (isLoggable(Level.FINEST)) { >> loggerProxy.doLog(Level.FINEST, msg, param1); >> } >> } >> >> public void finest(String msg, Object param1, Object param2) { >> if (isLoggable(Level.FINEST)) { >> loggerProxy.doLog(Level.FINEST, msg, param1, param2); >> } >> } >> >> public void finest(String msg, Object param1, Object param2, Object >> param3) { >> if (isLoggable(Level.FINEST)) { >> loggerProxy.doLog(Level.FINEST, msg, param1, param2, param3); >> } >> } >> >> ... >> >> This would effectively guard creation of the arguments array with an >> isLoggable check for some common usages, eliminating the need to explicitly >> guard such statements. Of course, the user would have to be aware of when >> such unguarded logging statement is without overhead and when not... >> >> How do you feel about such API extension? >> >> >> Regards, Peter >> >> >> >> Laurent >> Le 4 avr. 2013 14:08, "Laurent Bourg?s" a >> ?crit : >> >>> Ok, I can provide an updated patch after finding / fixing all usages. >>> >>> Probably in 1 or 2 days, >>> >>> Laurent >>> >>> 2013/4/4 Anthony Petrov >>> >>>> Yes, this makes sense. Do you want to update your fix for 8010297 to >>>> include these changes as well? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>> On 04/04/13 15:47, Laurent Bourg?s wrote: >>>> >>>>> Dear all, >>>>> >>>>> I just realized there is another problem with PlatformLogger log >>>>> statements: >>>>> XBaseWindow: >>>>> public boolean grabInput() { >>>>> grabLog.fine("Grab input on {0}", this); >>>>> ... >>>>> } >>>>> >>>>> This calls the PlatformLogger.fine( varargs): >>>>> public void fine(String msg, Object... params) { >>>>> logger.doLog(FINE, msg, params); >>>>> } >>>>> >>>>> Doing so, the JVM creates a new Object[] instance to provide params as >>>>> varargs. >>>>> >>>>> I would recommend using isLoggable() test to avoid such waste if the >>>>> log >>>>> is disabled (fine, finer, finest ...). >>>>> >>>>> Do you want me to provide a new patch related to this problem ? >>>>> >>>>> Does somebody have an idea to automatically analyze the JDK code and >>>>> detect missing isLoggable statements ... >>>>> >>>>> Regards, >>>>> Laurent >>>>> >>>>> 2013/4/3 Laurent Bourg?s >>>> > >>>>> >>>>> >>>>> Anthony, >>>>> >>>>> could you tell me once it is in the OpenJDK8 repository ? >>>>> I would then perform again profiling tests to check if there is no >>>>> more missing isLoggable() statements. >>>>> >>>>> Once JMX and other projects switch to PlatformLogger, I could check >>>>> again. >>>>> >>>>> Maybe I could write a small java code checker (pmd rule) to test if >>>>> there is missing isLoggable() statements wrapping PlatformLogger >>>>> log >>>>> statements. Any idea about how to reuse java parser to do so ? >>>>> >>>>> Regards, >>>>> >>>>> Laurent >>>>> >>>>> 2013/4/2 Anthony Petrov >>>> > >>>>> >>>>> >>>>> Looks fine to me as well. Thanks for fixing this, Laurent. >>>>> >>>>> Let's wait a couple more days in case Net or Swing folks want >>>>> to >>>>> review the fix. After that I'll push it to the repository. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>> On 4/2/2013 15:35, Laurent Bourg?s wrote: >>>>> >>>>> Here is the updated patch: >>>>> http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ >>>>> >>>>> >>>>> >>>>> Fixed inconsistencies between FINE / FINER log statements: >>>>> - XScrollbarPeer >>>>> - XWindowPeer >>>>> >>>>> Laurent >>>>> >>>>> 2013/4/2 Anthony Petrov >>>> >>>>> >>>> >>>>> >> >>>>> >>>>> >>>>> 1. Sergey: I believe this is for purposes of better >>>>> formating the >>>>> log output and making it more readable by separating >>>>> or >>>>> highlighting >>>>> some sections. I don't think this should be changed. >>>>> >>>>> 2. Laurent: can you please address this issue and send >>>>> us a new patch? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>> On 4/1/2013 16:08, Sergey Bylokhov wrote: >>>>> >>>>> >>>>> Hi, Anthony >>>>> Only two comments: >>>>> 1 Why we need some special text in the log output >>>>> like "***" and >>>>> "###" >>>>> 2 XScrollbarPeer.java: >>>>> >>>>> + if >>>>> (log.isLoggable(____PlatformLogger.FINEST)) { >>>>> >>>>> >>>>> + log.finer("KeyEvent on scrollbar: " + >>>>> event); >>>>> + } >>>>> >>>>> >>>>> >>>>> On 4/1/13 12:20 PM, Anthony Petrov wrote: >>>>> >>>>> Awt, Swing, Net engineers, >>>>> >>>>> Could anyone review the fix please? For your >>>>> convenience: >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>>> >>>>> >>>>> >>>> > >>>>> >>>>> Fix: >>>>> >>>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>>> < >>>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>>> < >>>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>>> < >>>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>>> >>>>> -- best regards, >>>>> Anthony >>>>> >>>>> On 3/22/2013 2:26, Anthony Petrov wrote: >>>>> >>>>> Hi Laurent, >>>>> >>>>> The fix looks great to me. Thank you very >>>>> much. >>>>> >>>>> We still need at least one review, though. >>>>> Hopefully >>>>> net-dev@ and/or swing-dev@ folks might >>>>> help >>>>> us out a bit. >>>>> >>>>> -- best regards, >>>>> Anthony >>>>> >>>>> On 3/20/2013 15:10, Anthony Petrov wrote: >>>>> >>>>> Hi Laurent, >>>>> >>>>> Thanks for the patch. I've filed a >>>>> bug at: >>>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>>> >>>>> >>>>> >>>>> >>>> > >>>>> (should be available in a day or two) >>>>> >>>>> and published a webrev generated from >>>>> your patch at: >>>>> >>>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>>> < >>>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>>> < >>>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>>> < >>>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>>> >>>>> >>>>> I'm also copying swing-dev@ and >>>>> net-dev@ because the >>>>> fix affects those areas too. I myself >>>>> will review >>>>> the fix a bit later but am sending it >>>>> now for other >>>>> folks to take a look at it. >>>>> >>>>> On 3/19/2013 15:29, Laurent Bourg?s >>>>> wrote: >>>>> >>>>> I am sorry I started modifying >>>>> PlatformLogger >>>>> and reverted changes to this class >>>>> as it is >>>>> another topic to be discussed >>>>> later: isLoggable >>>>> performance and waste due to >>>>> HashMap>>>> Level> leads to Integer >>>>> allocations >>>>> (boxing). >>>>> >>>>> >>>>> I saw your message to core-libs-dev@, >>>>> so I just >>>>> dropped all changes to the >>>>> PlatformLogger from this >>>>> patch. >>>>> >>>>> Finally, I have another question >>>>> related to the >>>>> WrapperGenerator class: it >>>>> generates a lot of >>>>> empty log statements (XEvent): >>>>> >>>>> log >>>>> < >>>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/sun/____awt/X11/XWrapperBase.java#____XWrapperBase.0log >>>>> < >>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log> >>>>> >>>>> >>>>> < >>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log >>>>> < >>>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/awt/X11/XWrapperBase.java#XWrapperBase.0log >>>>> >>>.finest >>>>> < >>>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/java/____util/logging/Logger.java#____Logger.finest%28java.lang.____String%29 >>>>> < >>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29> >>>>> >>>>> >>>>> < >>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29 >>>>> < >>>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/logging/Logger.java#Logger.finest%28java.lang.String%29 >>>>> >>>(""); >>>>> >>>>> >>>>> Is it really useful to have such >>>>> statements ? I >>>>> would keep logs with non empty >>>>> messages only. >>>>> >>>>> See WrapperGenerator:753: >>>>> String s_log = >>>>> >>>>> (generateLog?"log.finest(\"\")____;":""); >>>>> >>>>> >>>>> >>>>> >>>>> I believe they're used for log >>>>> formatting purposes >>>>> to separate numerous events in a log >>>>> (e.g. think of >>>>> mouse-move events - there can be >>>>> hundreds of them in >>>>> a raw). >>>>> >>>>> >>>>> Please note that the hg export format >>>>> is not that >>>>> useful unless you're assigned an >>>>> OpenJDK id already >>>>> (please see Dalibor's message for >>>>> details) because I >>>>> can't import it directly. So for the >>>>> time being you >>>>> could send just raw patches (i.e. the >>>>> output of hg >>>>> diff only - and there's no need to >>>>> commit your >>>>> changes in this case). Also, please >>>>> note that the >>>>> mailing lists strip attachments. The >>>>> reason I got it >>>>> is because I was listed in To: of your >>>>> message. So >>>>> when sending patches you can: >>>>> 1) post them inline, or >>>>> 2) attach them and add a person to To: >>>>> of your >>>>> message, or >>>>> 3) upload them somewhere on the web. >>>>> However, it would be best if you could >>>>> generate a >>>>> webrev for your changes and upload it >>>>> somewhere. >>>>> Currently this is the standard format >>>>> for reviewing >>>>> fixes in OpenJDK. >>>>> >>>>> -- best regards, >>>>> Anthony >>>>> >>>>> >>>>> Regards, >>>>> Laurent >>>>> >>>>> >>>>> >>>>> 2013/3/19 Laurent Bourg?s >>>>> >>>> bourges.laurent at gmail.com> >>>>> >>>> > >>>>> >>>> ____com >>>>> >>>>> >>>> >>> >>>>> >>>>> Hi antony, >>>>> >>>>> FYI I started reviewing and >>>>> fixing all >>>>> PlatformLogger use cases (not >>>>> too many as I thought first) >>>>> mainly used by >>>>> awt / swing projects to >>>>> provide you a patch on latest >>>>> JDK8 source code: >>>>> >>>>> I am adding the log level >>>>> check >>>>> when it is >>>>> missing: >>>>> if >>>>> (...log.isLoggable(____PlatformLogger.xxx)) { >>>>> >>>>> >>>>> log... >>>>> } >>>>> >>>>> I will not change the String + >>>>> operations to >>>>> use the message format >>>>> syntax in this patch. >>>>> >>>>> Do you accept such patch / >>>>> proposed >>>>> contribution ? >>>>> >>>>> Regards, >>>>> Laurent >>>>> >>>>> >>>>> 2013/3/18 Laurent Bourg?s >>>>> >>>> bourges.laurent at gmail.com> >>>>> >>>> > >>>>> >>>> ____com >>>>> >>>>> >>>> >>> >>>>> >>>>> Hi antony, >>>>> >>>>> 2 different things: >>>>> 1/ PlatformLogger was >>>>> patched (doLog >>>>> method) to avoid string >>>>> operations (message >>>>> formatting) for >>>>> disabled logs (patch >>>>> submiited on JDK8 and >>>>> JDK7u): >>>>> >>>>> http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html >>>>> < >>>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html> >>>>> >>>>> >>>>> >>>>> < >>>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html >>>>> < >>>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-April/002751.html >>>>> >> >>>>> >>>>> >>>>> 2/ I looked 2 hours ago on >>>>> JDK7u AND >>>>> JDK8 source codes and both >>>>> still have: >>>>> - log statements WITHOUT >>>>> log level check >>>>> : if >>>>> >>>>> (log.isLoggable(____PlatformLogger.FINE)) >>>>> >>>>> >>>>> log.fine(...); >>>>> - string operations (+) in >>>>> log calls >>>>> that could be improved >>>>> using the message format >>>>> syntax (String >>>>> + args): for example, >>>>> avoid using >>>>> PlatformLogger.fine(String + >>>>> ...) in favor of using >>>>> >>>>> PlatformLogger.fine(String msg, >>>>> Object... params) >>>>> >>>>> I reported in my previous >>>>> mail several >>>>> cases where the >>>>> isLoggable() call is >>>>> missing and leads >>>>> to useless String >>>>> operations but also method >>>>> calls >>>>> (Component.paramString() for >>>>> example). >>>>> >>>>> Finally, I also provided >>>>> other possible >>>>> cases (using grep); >>>>> maybe there is a better >>>>> alternative to >>>>> find all occurences of >>>>> String operations in log >>>>> calls. >>>>> >>>>> Regards, >>>>> Laurent >>>>> >>>>> 2013/3/18 Anthony Petrov >>>>> >>>> anthony.petrov at oracle.com> >>>>> >>>> > >>>>> >>>> ____com >>>>> >>>>> >>>> >>> >>>>> >>>>> Hi Laurent, >>>>> >>>>> Normally we fix an >>>>> issue in JDK 8 >>>>> first, and then back-port >>>>> the fix to a 7u >>>>> release. You're >>>>> saying that in JDK 8 the >>>>> problem isn't >>>>> reproducible anymore. >>>>> Can you please >>>>> investigate (using the >>>>> Mercurial >>>>> history log) what exact fix >>>>> resolved it in JDK 8? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 03/18/13 15:09, >>>>> Laurent Bourg?s >>>>> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> I run recently >>>>> netbeans profiler >>>>> on my swing application >>>>> (Aspro2: >>>>> http://www.jmmc.fr/aspro) under >>>>> linux x64 platform and I >>>>> figured out >>>>> that a lot of >>>>> char[] instances >>>>> are coming from String + >>>>> operator called >>>>> by sun.awt.X11 >>>>> code. >>>>> >>>>> I looked at >>>>> PlatformLogger >>>>> source code but found not way >>>>> to disable it >>>>> completely: maybe >>>>> an empty >>>>> logger implementation could >>>>> be interesting to >>>>> be used during >>>>> profiling or >>>>> normal use (not debugging). >>>>> Apparently JDK8 >>>>> provides some >>>>> patchs to avoid String >>>>> creation when the >>>>> logger is disabled >>>>> (level). >>>>> >>>>> However, I looked >>>>> also to the >>>>> sun.awt code (jdk7u >>>>> repository) to >>>>> see the >>>>> origin of the >>>>> string allocations: >>>>> XDecoratedPeer: >>>>> public void >>>>> handleFocusEvent(XEvent xev) { >>>>> ... >>>>> * >>>>> focusLog.finer("Received focus event on shell: >>>>> " + xfe); >>>>> * } >>>>> >>>>> public >>>>> boolean >>>>> requestWindowFocus(long time, >>>>> boolean >>>>> timeProvided) { >>>>> ... >>>>> * >>>>> focusLog.finest("Real native focused >>>>> window: " + >>>>> >>>>> realNativeFocusedWindow + >>>>> "\nKFM's focused window: " + >>>>> focusedWindow); >>>>> *... >>>>> * >>>>> focusLog.fine("Requesting focus to " + (this >>>>> == >>>>> toFocus ? "this >>>>> window" : >>>>> toFocus)); >>>>> *... >>>>> } >>>>> >>>>> XBaseWindow: >>>>> public void >>>>> xSetBounds(int >>>>> x, int y, int width, int >>>>> height) { >>>>> ... >>>>> * >>>>> insLog.fine("Setting >>>>> bounds on " + this + " to >>>>> (" + x + ", " + >>>>> y + "), " + width >>>>> + >>>>> "x" + height); >>>>> *} >>>>> >>>>> XNetProtocol: >>>>> boolean >>>>> doStateProtocol() { >>>>> ... >>>>> * >>>>> stateLog.finer("______doStateProtocol() >>>>> returns " + >>>>> >>>>> >>>>> res); >>>>> *} >>>>> >>>>> XSystemTrayPeer: >>>>> >>>>> XSystemTrayPeer(SystemTray >>>>> target) { >>>>> ... >>>>> * >>>>> log.fine(" >>>>> check if >>>>> system tray is available. >>>>> selection owner: >>>>> " + selection_owner); >>>>> *} >>>>> void >>>>> addTrayIcon(XTrayIconPeer tiPeer) >>>>> throws >>>>> AWTException { >>>>> ... >>>>> * >>>>> log.fine(" >>>>> send >>>>> SYSTEM_TRAY_REQUEST_DOCK >>>>> message to owner: >>>>> " + >>>>> selection_owner); >>>>> *} >>>>> >>>>> XFramePeer: >>>>> public void >>>>> handlePropertyNotify(XEvent xev) { >>>>> ... >>>>> >>>>> stateLog.finer("State is the same: " + >>>>> state); >>>>> } >>>>> >>>>> However I only >>>>> give >>>>> here few >>>>> cases but certainly others >>>>> are still >>>>> present in the >>>>> source code; >>>>> maybe findbugs or netbeans >>>>> warnings could >>>>> help you finding >>>>> all of them. >>>>> >>>>> I advocate the >>>>> amount of waste >>>>> (GC) is not very >>>>> important but >>>>> String >>>>> conversion are >>>>> also >>>>> calling >>>>> several toString() methods >>>>> that can be >>>>> costly (event, >>>>> Frame, window ...) >>>>> >>>>> Finally, I ran few >>>>> grep commands >>>>> on the sun.awt.X11 code >>>>> (jdk7u) and you >>>>> can look at them >>>>> to >>>>> see all >>>>> string + operations related >>>>> to log statements. >>>>> >>>>> PS: I may help >>>>> fixing the source >>>>> code but I have no idea >>>>> how to >>>>> collaborate >>>>> (provide a patch ?) >>>>> >>>>> Regards, >>>>> Laurent Bourg?s >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- Best regards, Sergey. >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> > From peter.levart at gmail.com Mon Apr 8 11:49:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 08 Apr 2013 13:49:16 +0200 Subject: Proxy.isProxyClass scalability In-Reply-To: <5106A397.1060203@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> Message-ID: <5162AEBC.7040901@gmail.com> Hi Alan, Is this still being considered? Recently there were some changes in the j.l.r.Proxy (the @CallerSensitive annotation), so my final webrev of the patch will have to be rebased. Do you still think we should not add new fields to ClassLoader? I have some ideas how to do it without adding a field to ClassLoader but for the price of some additional space overhead for each Proxy class produced. On the other hand I think that in the future, more platform-internal data structures would want to be "attached" to ClassLoaders so perhaps a single ConcurrentHashMap per ClassLoader could be re-used for different purposes by using distinct (never-equal) keys for each purpose (fox example, the lambda metafactory currently does not do any caching for it's own spun SAM proxy classes or CallSite objects, but could benefit quite a bit from doing so). Regards, Peter On 01/28/2013 05:13 PM, Peter Levart wrote: > Hi Alan, > > I prepared the variant with lazy initialization of ConcurrentHashMaps > per ClassLoader and performance measurements show no differences. So > here's this variant: > > * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html > > I also checked the ClassLoader layout and as it happens the additional > pointer slot increases the ClassLoader object size by 8 bytes in both > addressing modes: 32bit and 64bit. But that's a small overhead > compared to for example the deep-size of AppClassLoader at the > beginning of the main method: 14648 bytes (32bit) / 22432 bytes (64bit). > > Regards, Peter > > On 01/28/2013 01:57 PM, Peter Levart wrote: >> On 01/28/2013 12:49 PM, Alan Bateman wrote: >>> On 25/01/2013 17:55, Peter Levart wrote: >>>> >>>> : >>>> >>>> The solution is actually very simple. I just want to validate my >>>> reasoning before jumping to implement it: >>>> >>>> - for solving scalability of getProxyClass cache, a field with a >>>> reference to ConcurrentHashMap, Class>>> Proxy>> is added to j.l.ClassLoader >>>> - for solving scalability of isProxyClass, a field with a reference >>>> to ConcurrentHashMap, Boolean> is added to >>>> j.l.ClassLoader >>> I haven't had time to look very closely as your more recent changes >>> (you are clearly doing very good work here). The only thing I wonder >>> if whether it would be possible to avoid adding to ClassLoader. I >>> can't say what percentage of frameworks and applications use proxies >>> but it would be nice if the impact on applications that don't use >>> proxies is zero. >> Hi Alan, >> >> Hm, well. Any application that uses run-time annotations, is >> implicitly using Proxies. But I agree that there are applications >> that don't use either. Such applications usually don't use many >> ClassLoaders either. Applications that use many ClassLoaders are >> typically application servers or applications written for modular >> systems (such as OSGI or NetBeans) and all those applications are >> also full of runtime annotations nowadays. So a typical application >> that does not use neither Proxies nor runtime annotations is composed >> of bootstrap classloader, AppClassLoader and ExtClassLoader. The >> ConcurrentHashMap for the bootstrap classloader is hosted by >> j.l.r.Proxy class and is only initialized when the j.l.r.Proxy class >> is initialized - so in this case never. The overhead for such >> applications is therefore an empty ConcurrentHashMap instance plus >> the overhead for a pointer slot in the ClassLoader object multiplied >> by the number of ClassLoaders (typically 2). An empty >> ConcurrentHashMap in JDK8 is only pre-allocating a single internal >> Segment: >> >> java.util.concurrent.ConcurrentHashMap at 642b6fc7(48 bytes) { >> keySet: null >> values: null >> hashSeed: int >> segmentMask: int >> segmentShift: int >> segments: >> java.util.concurrent.ConcurrentHashMap$Segment[16]@8e1dfb1(80 bytes) { >> java.util.concurrent.ConcurrentHashMap$Segment at 2524e205(40 bytes) { >> sync: >> java.util.concurrent.locks.ReentrantLock$NonfairSync at 17feafba(32 >> bytes) { >> exclusiveOwnerThread: null >> head: null >> tail: null >> state: int >> }->(32 deep bytes) >> table: >> java.util.concurrent.ConcurrentHashMap$HashEntry[2]@1c3aacb4(24 bytes) { >> null >> null >> }->(24 deep bytes) >> count: int >> modCount: int >> threshold: int >> loadFactor: float >> }->(96 deep bytes) >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> }->(176 deep bytes) >> keySet: null >> entrySet: null >> values: null >> }->(224 deep bytes) >> >> ...therefore the overhead is approx. 224+4 = 228 bytes (on 32 bit >> pointer environments) per ClassLoader. In typical application (with 2 >> ClassLoader objects) this amounts to approx. 456 bytes. >> >> Is 456 bytes overhead too much? >> >> If it is, I could do lazy initialization of per-classloader CHM >> instances, but then the fast-path would incur a little additional >> penalty (not to be taken seriously though). >> >> Regards, Peter >> >> P.S. I was inspecting the ClassValue internal implementation. This is >> a very nice piece of Java code. Without using any Unsafe magic, it >> provides a perfect performant an scalable map of lazily initialized >> independent data structures associated with Class instances. There's >> nothing special about ClassValue/ClassValueMap that would tie it to >> Class instances. In fact I think the ClassValueMap could be made >> generic so it could be reused for implementing a ClasLoaderValue, for >> example. This would provide a more performant and scalable >> alternative to using WeakHashMap wrapped by >> synchronized wrappers for other uses. >> If anything like that happens in the future, the proposed patch can >> be quickly adapted to using that infrastructure instead of a direct >> reference in the ClassLoader. >> >>> >>> -Alan >> > From sadhak001 at gmail.com Mon Apr 8 11:59:55 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 8 Apr 2013 12:59:55 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <5162A7ED.1020009@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> <5162A7ED.1020009@oracle.com> Message-ID: Thanks Alan, David for your feedback. So effectively you are saying the Thread.sleep(10) is fine in the test and does not need to be re-written using any of the concurrency library methods. Cheers, mani On Mon, Apr 8, 2013 at 12:20 PM, David Holmes wrote: > Mani, > > Please go back to my original response. As Alan has just re-stated we do > not need a latch or a semaphore here because we already do a join on the > thread. As I have said the sleep is to allow the GC a chance to run (eg > finalizer and/or reference processor thread). > > David > > > On 8/04/2013 8:53 PM, Mani Sarkar wrote: > >> We initially introduced CountdownLatch and now Semaphore, to replace the >> Thread.sleep(10) which took place before - what appears to be a forced GC >> (am I right?): >> >> System.err.println("GC " + i); >> System.gc(); >> System.runFinalization(); >> >> As the threads join at the ends of the other, then we can do away with the >> Semaphore but how would we simulate the 10ms pause before the forced GC - >> is that necessary? Can we still use Semaphores to implement pauses? >> >> Cheers, >> mani >> >> On Mon, Apr 8, 2013 at 11:07 AM, Alan Bateman ** >> wrote: >> >> On 08/04/2013 10:39, Mani Sarkar wrote: >>> >>> Hi David, >>>> >>>> Here's the version of >>>> *jdk8_tl/jdk/**test/java/lang/****ref/Basic.java*implemented using a >>>> Semaphore: >>>> >>>> Hi Mani, >>>> >>> >>> Is there a handshake really needed here? From a quick look at the test >>> then it looks to me that fork (used by createNoise) does a Thread.join so >>> it waiting until the task is complete before it returns. >>> >>> -Alan >>> >>> >> >> >> -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From Alan.Bateman at oracle.com Mon Apr 8 12:24:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Apr 2013 13:24:03 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5162743C.9030606@oracle.com> References: <5162743C.9030606@oracle.com> Message-ID: <5162B6E3.3090508@oracle.com> On 08/04/2013 08:39, huizhe wang wrote: > Hi Lance, Alan, > > As I mentioned, I'd like to propose an integration of JAXP 1.5 into > JDK8. JAXP 1.5 adds a new feature to control connections. > > Here's the webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ > > Thanks, > Joe I've done a first pass over the spec/javadoc changes (not the implementation yet). Are you planning to add @since to each of the new constants in XMLConstants? For the new properties then it specifies that a "a runtime exception" will be thrown. Can this be more specific? The URI scheme is specified in terms of the obsolete RFC 2396 whereas I think it just needs to be a String that is equal (ignoring case) to the protocol of the connection that is attempting. For jaxp.properties then it reads "and property XXX is specified". I'd probably change this to "the property". For the existing FEATURE_SECURE_PROCESSING then "accordance with the letter" is a bit unusual, I would be "the letter" could be dropped. For each of the factories then it specifies that all implementation are required to support the new property but this would seem to invalidate all existing provider implementations. I don't think providers are versioned so all I can suggest is that this be worded to make it clear that all implementations that implement JAXP 1.5 or newer support this property. A small comment is that there seems to have been previous attempts to keep some of the files at 80 or thereabouts columns. The new javadoc requires a bit of horizontal scrolling. -Alan. From Alan.Bateman at oracle.com Mon Apr 8 12:52:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Apr 2013 13:52:46 +0100 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> Message-ID: <5162BD9E.2050803@oracle.com> On 06/04/2013 23:02, Mike Duigou wrote: > Hello all; > > Another, and hopefully the final, update to the webrev for this issue. The revised webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > The important changes in this revision: > > - I've removed the serialData change in HashMap. The implementation now reads the capacity and gracefully handles non-power of 2 values. > > - I'm not entirely convinced that having serialization emulate clone() for capacity handling is the best answer. I might also want to change clone() to size it's result based upon the number of mappings in the source rather its the capacity. Anybody have strong feelings about this to suggest one behaviour is obviously better? > > Any other final thoughts? > > Mike > I think this is the webrev: http://cr.openjdk.java.net/~mduigou/JDK-8011200/2/webrev/ It's impossible to predict what the usage will be after you reconstitute. Personally I think it's better to leave it as is, meaning the rounded-up size as otherwise you might reconstitute to a capacity that is much more than you might ever need. I didn't notice in the previous revisions but roundUpToPowerOf2 can assign "rounded" twice (it probably doesn't happen when it gets compiled at runtime but still looks a bit odd). The test still have the bug issue number. -Alan From maurizio.cimadamore at oracle.com Mon Apr 8 15:00:24 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Apr 2013 15:00:24 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130408150038.7437348141@hg.openjdk.java.net> Changeset: b71a61d39cf7 Author: mcimadamore Date: 2013-04-08 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b71a61d39cf7 8010922: Cleanup: add support for ad-hoc method check logic Summary: Support pluggable method checkers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: b54122b9372d Author: mcimadamore Date: 2013-04-08 15:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b54122b9372d 8010823: DefaultMethodTest.testReflectCall fails with new lambda VM Summary: Fix lambda test Reviewed-by: jjg ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: e9d986381414 Author: mcimadamore Date: 2013-04-08 15:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9d986381414 8010404: Lambda debugging: redundant LineNumberTable entry for lambda capture Summary: Ignore indy entries in LineNumberTable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 94a202228ec2 Author: mcimadamore Date: 2013-04-08 15:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94a202228ec2 8009131: Overload: javac should discard methods that lead to errors in lambdas with implicit parameter types Summary: Lambdas that have errors in their bodies should make enclosing overload resolution fail Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/BadArgTypesInLambda.java ! test/tools/javac/lambda/BadRecovery.out ! test/tools/javac/lambda/TargetType01.java - test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType43.out + test/tools/javac/lambda/TargetType66.java + test/tools/javac/lambda/TargetType66.out Changeset: c635a966ce84 Author: mcimadamore Date: 2013-04-08 15:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c635a966ce84 8010822: Intersection type cast for functional expressions does not follow spec EDR Summary: Remove support for marker interfaces; redefine intersection type casts to be order-independent Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/diags/examples/NotAnInterfaceComponent.java - test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java ! test/tools/javac/lambda/Intersection01.java - test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java From Alan.Bateman at oracle.com Mon Apr 8 15:05:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Apr 2013 16:05:51 +0100 Subject: JAX-WS update coming soon In-Reply-To: <514AEEBE.9050406@oracle.com> References: <514AEEBE.9050406@oracle.com> Message-ID: <5162DCCF.9030503@oracle.com> On 21/03/2013 11:27, Alan Bateman wrote: > > Just a heads-up that there is a JAX-WS update coming for jdk8. > Miroslav Kos will be sending a webrev soon with the changes that > update what we have in jdk8 from 2.2.7-b09 to 2.2.9-b13922. Miroslav has put a webrev with the changes here: http://cr.openjdk.java.net/~mkos/8010393/webrev.01/ Miroslav - can you briefly summarize the changes so that folks know what is coming? One minor update is that I needed to modify a make file to ensure that a new .xml gets packaged into resources.jar. -Alan diff --git a/makefiles/BuildJaxws.gmk b/makefiles/BuildJaxws.gmk --- a/makefiles/BuildJaxws.gmk +++ b/makefiles/BuildJaxws.gmk @@ -55,7 +55,8 @@ BIN:=$(JAXWS_OUTPUTDIR)/jaxws_classes,\ COPY:=.xsd,\ COPY_FILES:=$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java \ - $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java,\ + $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java \ + $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml,\ ADD_JAVAC_FLAGS=-cp $(OUTPUT_ROOT)/jaxp/dist/lib/classes.jar)) $(JAXWS_OUTPUTDIR)/jaxws_classes/META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin: \ @@ -98,7 +99,7 @@ $(eval $(call SetupArchive,ARCHIVE_JAXWS,$(BUILD_JAXWS) $(BUILD_JAF) $(TARGET_PROP_FILES),\ SRCS:=$(JAXWS_OUTPUTDIR)/jaxws_classes $(JAXWS_OUTPUTDIR)/jaf_classes,\ - SUFFIXES:=.class .properties .xsd .java \ + SUFFIXES:=.class .properties .xsd .xml .java \ com.sun.mirror.apt.AnnotationProcessorFactory \ com.sun.tools.internal.xjc.Plugin,\ JAR:=$(JAXWS_OUTPUTDIR)/dist/lib/classes.jar)) From miroslav.kos at oracle.com Mon Apr 8 16:05:01 2013 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 08 Apr 2013 18:05:01 +0200 Subject: JAX-WS update coming soon In-Reply-To: <5162DCCF.9030503@oracle.com> References: <514AEEBE.9050406@oracle.com> <5162DCCF.9030503@oracle.com> Message-ID: <5162EAAD.3060808@oracle.com> On 04/08/2013 05:05 PM, Alan Bateman wrote: > On 21/03/2013 11:27, Alan Bateman wrote: >> >> Just a heads-up that there is a JAX-WS update coming for jdk8. >> Miroslav Kos will be sending a webrev soon with the changes that >> update what we have in jdk8 from 2.2.7-b09 to 2.2.9-b13922. > Miroslav has put a webrev with the changes here: > > http://cr.openjdk.java.net/~mkos/8010393/webrev.01/ > > Miroslav - can you briefly summarize the changes so that folks know > what is coming? The change set contains all the changes between versions 2.2.7-b09 and the current development version, which is 2.2.9-b12941. There are no big changes, it contains just bug fixes required by upper stacks (metro, glassfish, weblogic) and minor refactorings. Attached is a list of fixed issues. Thanks Miran > > One minor update is that I needed to modify a make file to ensure that > a new .xml gets packaged into resources.jar. > > -Alan > > > diff --git a/makefiles/BuildJaxws.gmk b/makefiles/BuildJaxws.gmk > --- a/makefiles/BuildJaxws.gmk > +++ b/makefiles/BuildJaxws.gmk > @@ -55,7 +55,8 @@ > BIN:=$(JAXWS_OUTPUTDIR)/jaxws_classes,\ > COPY:=.xsd,\ > COPY_FILES:=$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java > \ > - > $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java,\ > + > $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java > \ > + > $(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml,\ > ADD_JAVAC_FLAGS=-cp $(OUTPUT_ROOT)/jaxp/dist/lib/classes.jar)) > > $(JAXWS_OUTPUTDIR)/jaxws_classes/META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin: > \ > @@ -98,7 +99,7 @@ > > $(eval $(call SetupArchive,ARCHIVE_JAXWS,$(BUILD_JAXWS) $(BUILD_JAF) > $(TARGET_PROP_FILES),\ > SRCS:=$(JAXWS_OUTPUTDIR)/jaxws_classes > $(JAXWS_OUTPUTDIR)/jaf_classes,\ > - SUFFIXES:=.class .properties .xsd .java \ > + SUFFIXES:=.class .properties .xsd .xml .java \ > com.sun.mirror.apt.AnnotationProcessorFactory \ > com.sun.tools.internal.xjc.Plugin,\ > JAR:=$(JAXWS_OUTPUTDIR)/dist/lib/classes.jar)) > -------------- next part -------------- Displaying issues *1* to *71* of *71* matching issues. as at: *08/Apr/1303:52 PM* *Key* *Summary* Make JAX-WS run on J2SE 5.0 httpproxy username and password not supported wsgen fails to resolve all 'service implementation bean' methods jaxws should pass encoding option to jaxb wsimport authFile URL containing passwords should support encoded/escaped characters... Allow wild card matching to allow the same user:password for all urls with the same host name com.sun.xml.ws.api.model.wsdl.WSDLModel.WSDLParser.parse error in parsering wsdl:message/wsdl:part defines "type" (not "element") IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions: MemberSubmissionEndpointReference$Address and W3CEndpointReference$Address Basic Authentication with wsimport does not allow @ in username wsa:to header of ack message changed to annonymous when the request message has no replyTo Back Compatible issue, for method: com.sun.xml.ws.server.EndpointFactory.verifyImplementorClass HttpAdapter send empty response message even when the message is null given that the endpointAddress of Packet is not null unable to delete .war file after wsimport completed Error listenerStart Sep 27, 2012 12:02:48 AM org.apache.catalina.core.StandardContext start consider updating dependencies move build from ant to maven disableCaptureStackTrace vs captureStackTrace RI Http Adapter should send common response instead of soapfault if the http status code is 403, according to WS-I BP 1.1 ClassCast exception when wsimport task run in a forked mode missing SoapAction in http header and ineffective warning in the logfile replace tools/resourcegen with resourcegen from istack-commons Issue with two or more web services in the same war when pointing to wsdls in different META-INF/wsdl subdirs where the wsdl files themselves are the same. Need to use Filer when generating files wsimport command will throw NullPointerException when no difination of like "xmlns:undns="http://test"" in WSDL file. wsimport Ant tasks causes NoClassDefFoundError from many places from within some java app DUPLICATE TO AND RELATESTO HEADERS IN ASYNC RESPONSE Annotation processing fails due to different ClassType objects for java.lang.String the address of member submission version's addressing element in wsdl will not be rewrited by the actual one Reading from BindingProvider's RequestContext causes "SOAPAction" http header to go blank Exception [EclipseLink-50063] (Eclipse Persistence Services - 2.3.1.v20111103-r10319): org.eclipse.persistence.exceptions.JAXBException NPE at com.sun.xml.internal.ws.wsdl.writer.W3CAddressingWSDLGeneratorExtension.addOperationInputExtension(W3CAddressingWSDLGeneratorExtension.java:72 Setting HTTP Cookie for the second time to BindingProvider.RequestContext is not overriding the old Cookie The documentation in http://jax-ws.java.net/2.2.5/docs/wsgenant.html is incorrect EndpointInterface annotation generated based on wsdl for old addressing space are wrong ws implementation class is not generated if -s and -d options differ BridgeWrapper swallows possible JAXBException [Regression]Some tests in handler framework are failing.These tests are passing against glassfish 3.1.1 Add additional webservice client annotations via GeneratorExtension mechanism in ServiceGenerator [Bug9269121] UNABLE TO SEND THE MAIL IN THE SERVER ENV USING JAVAX MAILS JAX-WS 2.2.* BUG with Content-type having action paramter as Mandatory WsimportTool override the Authenticator singleton [7433013] jax-ws server impl does not deserialize attachment headers into attachmentpart. [Bug 8770868] jaxws ws-sc webservice invocation failed for wstxioexception:invalid null. [Bug 9270193] ws-tx outbound call to was results in abort with transaction does not exist msg. Duplicate addressing headers created as a result of addressing policy and custom code Bug 9356487 - STRESS: ATOMIC TRANSACTIONS THROW ILLEGALARGUMENTEXCEPTION [Bug 8147693] [CR369142] SOAP MESSAGE BODY ATTRIBUTE MISSING WHEN DEALING WITH CLIENT SIDE HANDLER IN JAX-WS WebServiceAP needs to read 'no overwrite' and ' no webservice' flags from AnnotationProcessorEnvironment [Bug 8171121] [cr372855] [jaxws-wcf interop] wrong namespace url of wsa membersubmission policy assertion. [Bug8252660] BEHAVIOR CHANGED IN SOAPMessage.getSOAPHeader() METHOD [Bug 7447078] jaxws web service fail to deploy if method contain enum array and generic types. [Bug9948515] ServerMgr throws NPE in off-server env MTOM disabled when using SOAPHandler [Bug 8105514] NPE in SOAP11Fault [Bug 8146200] [Bug 8155176] [Bug 8164909] [Bug 8162399] cts jaxws21 - npe in provider test [3] [Bug 8110976] TOOLING CAN'T PROCESS A TOP-DOWN JAX-WS SERVICE WHEN THE WSDL HAS NESTED COMPLEX TYPES WS-Addressing doesn't work as it had on previous releases Endpoint.publish with 0.0.0.0 as host causes NPE in Endpoint.stop Reusing a JAXBRIContext causes a NPE the second time it is used Dump HTTP Packets to a Logger instead of System.out Document MTOM limitations WsImport fails if wsdl:message/wsdl:part defines "type" (not "element") Incorrect encoding of action parameter in MIME multipart/related entity body's Content-Type header WsGen output not correctly redirected Generate Additional Constructor For WebServiceClient Service wsimport Ant task not showing WSDLParseExceptions by default wsimport Ant task should support version="true" attribute Make WSServletDelegate class public Generate default webservice implementation when using wsimport tool to parse a WSDL wsimport does not support jaxb plugins better error messages on network failures From andrea.aime at geo-solutions.it Sun Apr 7 19:11:18 2013 From: andrea.aime at geo-solutions.it (Andrea Aime) Date: Sun, 7 Apr 2013 21:11:18 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourg?s wrote: > Dear all, > > Here is my first pisces (beta) patch (webrev): > http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ > > I succeed in fixing memory usage by having only 1 pisces instance > (Renderer, stroker, iterator ...) per RendererContext (GC friendly). > > Impressive results between small and large drawings: > Good stuff. Is there anything I can do to help? I do have an up to date version of JDK 8 sources on my disk, maybe I could try to apply the patch and take it for a spin in a real GeoServer and see how it goes. By the way, wondering, is there any other benchmark to try out? A possibly interesting one is this, where the author re-coded some selected methods of Graphics2D for maximum performance (but sometimes lower antialiasing quality) and created a applet to compare the results in a number of synthetic test cases: http://www.randelshofer.ch/oop/graphics/ Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- From mike.duigou at oracle.com Mon Apr 8 18:07:02 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 8 Apr 2013 11:07:02 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map Message-ID: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Hello all; This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ 8004518: Add in-place operations to Map forEach() replaceAll() 8010122: Add atomic operations to Map getOrDefault() putIfAbsent() * remove(K, V) replace(K, V) replace(K, V, V) compute() * merge() * computeIfAbsent() * computeIfPresent() * The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. Mike From jonathan.gibbons at oracle.com Mon Apr 8 18:54:49 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 08 Apr 2013 18:54:49 +0000 Subject: hg: jdk8/tl/langtools: 8011676: Instances of Tokens.Comment should not be defined in inner classes Message-ID: <20130408185451.D3CA34814F@hg.openjdk.java.net> Changeset: b402b93cbe38 Author: jjg Date: 2013-04-08 11:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b402b93cbe38 8011676: Instances of Tokens.Comment should not be defined in inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java From jonathan.gibbons at oracle.com Mon Apr 8 18:57:44 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 08 Apr 2013 18:57:44 +0000 Subject: hg: jdk8/tl/langtools: 8011677: EndPosTables should avoid hidden references to Parser Message-ID: <20130408185747.039BD48150@hg.openjdk.java.net> Changeset: 3f3cc8d3f13c Author: jjg Date: 2013-04-08 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3f3cc8d3f13c 8011677: EndPosTables should avoid hidden references to Parser Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java From lance.andersen at oracle.com Mon Apr 8 19:29:53 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 08 Apr 2013 19:29:53 +0000 Subject: hg: jdk8/tl/jdk: 8006036: (process) cleanup code in java/lang/Runtime/exec/WinCommand.java Message-ID: <20130408193015.1247848153@hg.openjdk.java.net> Changeset: 04617e462512 Author: lancea Date: 2013-04-08 15:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04617e462512 8006036: (process) cleanup code in java/lang/Runtime/exec/WinCommand.java Reviewed-by: lancea Contributed-by: Jim Gish ! test/java/lang/Runtime/exec/WinCommand.java From mandy.chung at oracle.com Mon Apr 8 19:52:02 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 08 Apr 2013 12:52:02 -0700 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> Message-ID: <51631FE2.6090200@oracle.com> Peter, Laurent, Peter's idea is a good one to add a couple of convenient methods to take Object parameters that will avoid the creation of array instances. I'd also like to know what variants being used in the jdk to determine the pros and cons of the alternatives (this issue also applies to java.util.logging). It was intentional to have PlatformLogger define only the useful methods necessary for jdk use. The goal of PlatformLogger was to provide a light-weight utility for jdk to log debugging messages and eliminate the dependency to java.util.logging and avoid the unnecessary j.u.logging initialization (as disabled by default). It was not a goal for PlatformLogger to be an exact mirror as java.util.logging.Logger. My advice is to tune PlatformLogger to provide API that helps the platform implementation while avoid bloating the API. Since you are touching some jdk files that use java.util.logging, would you like to contribute to convert them to use PlatformLogger: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233 It's perfectly fine to convert only some of them if not all. Jim Gish is the owner of logging and will check with him if he has cycles to work with you on this. Thanks Mandy On 4/8/13 3:06 AM, Laurent Bourg?s wrote: > Peter, Mandy, > > I think it would be great to make PlatformLogger very similar to > Logger API: > I mean JUL Logger already has only 1 convenient method with 1 param so > it may be great to have the same API in PlatformLogger too: maybe > extend it to 2 or 3 params ... > > Peter, could you look at the API differences between Logger / > PlatformLogger to make PlatformLogger API more similar to JUL Logger ? > > Laurent > > 2013/4/8 Peter Levart > > > On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: >> >> Hi >> >> I started fixing All PlatformlLogger "bad" usages and I am fixing >> also many jul Logger usages without isLoggable ... >> That represents a lot of changes and a very boring job. >> >> I think sending a webrew tomorrow. >> > > Hi Laurent, > > Since you're already deep in the task, you might have a rough > feeling what part of such unguarded log statements are of the > following type: > > logger.[fine,info,...]("a message with {0} and {1} placeholders", > someArg1, someArg2); > > where someArg1, ... are some values that are already present in > the context of the logging statement and don't have to be computed > just for satisfying the logging (not even boxing). Such usages > could be effectively optimized by adding some overloaded methods > to PlatformLogger that take 1, 2, 3, ... arguments: > > class PlatformLogger { > > ... > > public void finest(String msg, Object param1) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1); > } > } > > public void finest(String msg, Object param1, Object param2) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2); > } > } > > public void finest(String msg, Object param1, Object param2, > Object param3) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2, > param3); > } > } > > ... > > This would effectively guard creation of the arguments array with > an isLoggable check for some common usages, eliminating the need > to explicitly guard such statements. Of course, the user would > have to be aware of when such unguarded logging statement is > without overhead and when not... > > How do you feel about such API extension? > > > Regards, Peter > From xueming.shen at oracle.com Mon Apr 8 19:51:50 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 08 Apr 2013 12:51:50 -0700 Subject: ReviewRequest 8011172: JJSR 310: DateTime API Updates II, Message-ID: <51631FD6.6090800@oracle.com> Hi, JSR 310 has continued to refine and update the java.time API. Please help review the proposed changeset as showed in webrev: http://cr.openjdk.java.net/~sherman/8011172/webrev/ In addition to general javadoc improvements, the changes include: java.time * Duration - added a static from(temporalAmount) method to simplify conversions from other amounts * Renamed the toString(Formatter) method to format(Formatter) in all classes * Period - added a static from(temporalAmount) method to simplify conversions * ZoneId - - Added getAvailableZoneIds method, a simpler mechanism than going to the provider - Added normalized() method to ease conversion to a fixed offset - renamed predefined static fields of timezone names java.time.chrono * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime - changed xxx_COMPARATORs to static methods returning the Time Line Order comparators - Added a from(TemporalAcessor) method to ease conversions * Chronology - Added method to create a Date from EpochDay (And in each calendar subclass) - Added resolveDate to allow resolving date components by the Chronology - Serialization fixes - Replaced raw return types with wildcard type * Era - Removed factory methods and getChronology - they did not work correctly in all cases - Declared Era as a functional interface * Hijrah calendar variations - - Supporting the Umm alQura calendar * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra making the enums public * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method to return the concrete Era type. java.time.format * DateTimeFormatter - - Added fields for the predefined formatters (moved from DateTimeFormatters class) - Updated patterns to be CLDR compatible - Moved documentation for the pattern letters to the class javadoc - Added support for Zone default and conversion * DateTimeFormatterBuilder - Updated documentation of patterns and corresponding equivalents to builder methods. - Added a method to append the localized offset. java.time.temporal * Adjusters - class removed; all static adjusters moved to static methods in TemporalAdjuster * ChronoField - - Renamed EPOCH_MONTH to PROLEPTIC_MONTH - Added getDisplayName - for locale specific field name * Queries - class removed; all static query method moved to static methods in TemporalQuery * TemporalField - added getDisplayName method * UnsupportedTemporalTypeException - new subtype of DateTimeException to reflect no support for a unit or field * WeekFields - Added fields for week and year of week-Based-Years to match CLDR fields "Y", "W" From peter.levart at gmail.com Mon Apr 8 21:09:30 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 08 Apr 2013 23:09:30 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <5163320A.5020106@gmail.com> Hi Mike, It's unfortunate that getOrDefault() is specified so that it can't be implemented atomically in terms of existent (non-default) ConcurrentMap methods, so platform ConcurrentMap implementations will have atomic implementation and others will have to catch-up first. I hope this will not be a cause of any concurrency bugs. The javadoc for computeIfPresent seems to be inconsistent: 826 * If the value for the specified key is present and non-null, 827 * attempts to compute a new mapping given the key and its current 828 * mapped value. 829 * 830 *

If the function returns {@code null}, the mapping is removed (*or* 831 **remains absent if initially absent*). If the function itself throws an 832 * (unchecked) exception, the exception is rethrown, and the current mapping 833 * is left unchanged. I think the situation described *in bold* is non-existent. Regards, Peter On 04/08/2013 08:07 PM, Mike Duigou wrote: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > 8004518: Add in-place operations to Map > forEach() > replaceAll() > > 8010122: Add atomic operations to Map > getOrDefault() > putIfAbsent() * > remove(K, V) > replace(K, V) > replace(K, V, V) > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * > > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike > From martinrb at google.com Mon Apr 8 23:03:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 Apr 2013 16:03:24 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <5162BD9E.2050803@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <5162BD9E.2050803@oracle.com> Message-ID: Style: spaces around "=" + private static final int DEFAULT_CAPACITY= 10; --- It's a matter of taste whether to remove the temp var oldCapacity. I believe it was coded intentionally. public void trimToSize() { modCount++; - int oldCapacity = elementData.length; - if (size < oldCapacity) { + if (size < elementData.length) { elementData = Arrays.copyOf(elementData, size); } --- 754 throws java.io.IOException, ClassNotFoundException { 755 elementData = EMPTY_ELEMENTDATA; Your indentation is off. --- Because "threshold" is a serialized field, its javadoc is part of the public interface of this class, and hence cannot refer to implementation details like EMPTY_TABLE. 161 /** 162 * The next size value at which to resize (capacity * load factor). If 163 * table == EMPTY_TABLE then this is the initial capacity at which the 164 * table will be created when inflated. 165 * @serial 166 */ 167 int threshold;** * http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.HashMap * * * --- Consider making roundUpToPowerOf2 public. Best Implementation is not obvious. I would probably write a loop with core x = x & (x - 1) until get to zero. 274 private static int roundUpToPowerOf2(int number) { 275 int rounded = number >= MAXIMUM_CAPACITY 276 ? MAXIMUM_CAPACITY 277 : (rounded = Integer.highestOneBit(number)) != 0 278 ? (Integer.bitCount(number) > 1) ? rounded << 1 : rounded 279 : 1; 280 281 return rounded; 282 } --- I think it's a mistake to "optimize" for the empty case in code like this: 694 public boolean containsValue(Object value) { 695 if (isEmpty()) { 696 return false; 697 } 698 From martinrb at google.com Mon Apr 8 23:11:32 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 Apr 2013 16:11:32 -0700 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> <5162A7ED.1020009@oracle.com> Message-ID: Some very high level comments. I think it's perfectly fine to use CountDownLatch to wait for events, as is done in many jsr166 tests. For the tricky problem of waiting for GC, see GcFinalization https://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java From david.holmes at oracle.com Mon Apr 8 23:28:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 09:28:48 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> <5162A7ED.1020009@oracle.com> Message-ID: <516352B0.5070307@oracle.com> On 8/04/2013 9:59 PM, Mani Sarkar wrote: > Thanks Alan, David for your feedback. > > So effectively you are saying the Thread.sleep(10) is fine in the test > and does not need to be re-written using any of the concurrency library > methods. As I wrote back in one of my earliest emails: "that aside the latch is not needed. The fork() method starts a thread and joins it. So when createNoise() returns we already know for certain that the "noise has been created". What the sleep is doing is giving the GC a chance to run. " The sleep has nothing to do with synchronizing with the "noise" thread. And synchronization with the "noise" thread is already handled perfectly correctly. David ----- > > Cheers, > mani > > On Mon, Apr 8, 2013 at 12:20 PM, David Holmes > wrote: > > Mani, > > Please go back to my original response. As Alan has just re-stated > we do not need a latch or a semaphore here because we already do a > join on the thread. As I have said the sleep is to allow the GC a > chance to run (eg finalizer and/or reference processor thread). > > David > > > On 8/04/2013 8:53 PM, Mani Sarkar wrote: > > We initially introduced CountdownLatch and now Semaphore, to > replace the > Thread.sleep(10) which took place before - what appears to be a > forced GC > (am I right?): > > System.err.println("GC " + i); > System.gc(); > System.runFinalization(); > > As the threads join at the ends of the other, then we can do > away with the > Semaphore but how would we simulate the 10ms pause before the > forced GC - > is that necessary? Can we still use Semaphores to implement pauses? > > Cheers, > mani > > On Mon, Apr 8, 2013 at 11:07 AM, Alan Bateman > >__wrote: > > On 08/04/2013 10:39, Mani Sarkar wrote: > > Hi David, > > Here's the version of > *jdk8_tl/jdk/**test/java/lang/__**ref/Basic.java*implemented > using a > Semaphore: > > Hi Mani, > > > Is there a handshake really needed here? From a quick look > at the test > then it looks to me that fork (used by createNoise) does a > Thread.join so > it waiting until the task is complete before it returns. > > -Alan > > > > > > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From sadhak001 at gmail.com Mon Apr 8 23:41:44 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 9 Apr 2013 00:41:44 +0100 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: <516352B0.5070307@oracle.com> References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> <5162A7ED.1020009@oracle.com> <516352B0.5070307@oracle.com> Message-ID: Is there no better way of waiting rather than using the Thread.sleep(n) method, I think you will agree that using sleep isn't the most elegant way to do things. I did run the patch without sleep, and it executed perfectly well - just curious about the use of Thread.sleep(n) in general, nothing specific to this change itself. When should/can it be used and when not? Cheers, mani On Tue, Apr 9, 2013 at 12:28 AM, David Holmes wrote: > On 8/04/2013 9:59 PM, Mani Sarkar wrote: > >> Thanks Alan, David for your feedback. >> >> So effectively you are saying the Thread.sleep(10) is fine in the test >> and does not need to be re-written using any of the concurrency library >> methods. >> > > As I wrote back in one of my earliest emails: > > "that aside the latch is not needed. The fork() method starts a thread and > joins it. So when createNoise() returns we already know for certain that > the "noise has been created". What the sleep is doing is giving the GC a > chance to run. " > > The sleep has nothing to do with synchronizing with the "noise" thread. > And synchronization with the "noise" thread is already handled perfectly > correctly. > > David > ----- > > >> -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Devoxx UK 2013 was a grand success:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From martinrb at google.com Mon Apr 8 23:43:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 Apr 2013 16:43:33 -0700 Subject: RFR: Optimize StringBuilder.append(null) In-Reply-To: <5153E3F6.30700@univ-mlv.fr> References: <5153826E.6070007@univ-mlv.fr> <5153E3F6.30700@univ-mlv.fr> Message-ID: On Wed, Mar 27, 2013 at 11:32 PM, Remi Forax wrote: > On 03/28/2013 07:29 AM, Martin Buchholz wrote: > > The declaration saves 50 bytes of bytecode. >> > > I don't understand ? > Copying a field into a method local results in fewer bytes of bytecode, which may tickle hotspot into inlining the method for you. Although it's hard to demonstrate this. From martinrb at google.com Mon Apr 8 23:48:10 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 Apr 2013 16:48:10 -0700 Subject: RFR: Optimize StringBuilder.append(null) In-Reply-To: <5154821D.2010909@oracle.com> References: <5153826E.6070007@univ-mlv.fr> <5154821D.2010909@oracle.com> Message-ID: On Thu, Mar 28, 2013 at 10:47 AM, Jim Gish wrote: > Thanks, Martin, > > We've all heard of code "smells" -- I hereby dub this a code "chuckle" :-) > > The change looks good to me otherwise as well. > Committed - thanks for the reviews! From martinrb at google.com Mon Apr 8 23:47:27 2013 From: martinrb at google.com (martinrb at google.com) Date: Mon, 08 Apr 2013 23:47:27 +0000 Subject: hg: jdk8/tl/jdk: 8010849: (str) Optimize StringBuilder.append(null) Message-ID: <20130408234749.660974815F@hg.openjdk.java.net> Changeset: 3db793b080d8 Author: martin Date: 2013-04-08 16:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3db793b080d8 8010849: (str) Optimize StringBuilder.append(null) Summary: Append 4 chars instead of the string "null" Reviewed-by: mduigou, forax, jgish ! src/share/classes/java/lang/AbstractStringBuilder.java From stevenschlansker at gmail.com Mon Apr 8 23:54:32 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 8 Apr 2013 16:54:32 -0700 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? Message-ID: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> Today I encountered "java.lang.IllegalArgumentException: Self-suppression not permitted" from Throwable.addSuppressed. My first surprise is that the try-with-resources block can throw this exception; it is very confusing to have auto-generated code throw exceptions. But beyond that, it is impossible to figure out *which* exception caused the problem. If you have multiple resources acquired in the try-with-resources, it could be any of them. Would it be reasonable to change public final synchronized void addSuppressed(Throwable exception) { if (exception == this) throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); to public final synchronized void addSuppressed(Throwable exception) { if (exception == this) throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, this); so that when you get this exception it at least points to one of the throw sites that actually caused the problem? Otherwise the only stack trace you have is in auto-generated code and you are left scratching your head, wondering where it came from. I believe this would increase the debuggability of the try-with-resources construct and there's no immediately obvious downside. I'm not the only one who was confused by this behavior: http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co From david.holmes at oracle.com Mon Apr 8 23:58:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 09:58:49 +1000 Subject: Looking for a sponsor to review changes made to two unit tests under jdk/test In-Reply-To: References: <515E1D11.6090801@oracle.com> <515E23E5.5090802@oracle.com> <515E2B9E.3040607@oracle.com> <516224CB.7070807@oracle.com> <516296DC.9050302@oracle.com> <5162A7ED.1020009@oracle.com> <516352B0.5070307@oracle.com> Message-ID: <516359B9.2070401@oracle.com> On 9/04/2013 9:41 AM, Mani Sarkar wrote: > Is there no better way of waiting rather than using the Thread.sleep(n) > method, I think you will agree that using sleep isn't the most elegant > way to do things. No it isn't elegant but there is no explicit way to synchronize with the GC activity, so generally all you can do is add a sleep to allow "sufficient" time for the things to happen. For finalization you can do more because you can synchronize with the finalizer itself. David > I did run the patch without sleep, and it executed perfectly well - just > curious about the use of Thread.sleep(n) in general, nothing specific to > this change itself. > > When should/can it be used and when not? > > Cheers, > mani > > On Tue, Apr 9, 2013 at 12:28 AM, David Holmes > wrote: > > On 8/04/2013 9:59 PM, Mani Sarkar wrote: > > Thanks Alan, David for your feedback. > > So effectively you are saying the Thread.sleep(10) is fine in > the test > and does not need to be re-written using any of the concurrency > library > methods. > > > As I wrote back in one of my earliest emails: > > "that aside the latch is not needed. The fork() method starts a > thread and joins it. So when createNoise() returns we already know > for certain that the "noise has been created". What the sleep is > doing is giving the GC a chance to run. " > > The sleep has nothing to do with synchronizing with the "noise" > thread. And synchronization with the "noise" thread is already > handled perfectly correctly. > > David > ----- > > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project:* https://github.com/MutabilityDetector > *Devoxx UK 2013 was a grand success:* > http://www.devoxx.com/display/UK13/Home > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From joe.darcy at oracle.com Tue Apr 9 00:06:34 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 09 Apr 2013 00:06:34 +0000 Subject: hg: jdk8/tl/jdk: 6298888: Add toGenericString to j.l.Class and getTypeName to j.l.reflect.Type; ... Message-ID: <20130409000646.31EEC48161@hg.openjdk.java.net> Changeset: 3e5a18c3e599 Author: darcy Date: 2013-04-08 17:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e5a18c3e599 6298888: Add toGenericString to j.l.Class and getTypeName to j.l.reflect.Type 6992705: Include modifiers in Class.toGenericString() Summary: Class.toGenericString and supporting changes; additional reviews by Peter Levart Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/java/lang/reflect/Type.java + test/java/lang/Class/GenericStringTest.java From Ulf.Zibis at CoSoCo.de Tue Apr 9 00:08:51 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 09 Apr 2013 02:08:51 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <51635C13.808@CoSoCo.de> Hi Mike, Comments for j.u.Map: To my savour the variant belongs to the left hand side of a comparison, e.g.: if (v = get(key) != null) Instead 501 return (null != (v = get(key))) 502 ? v 503 : containsKey(key) ? null : defaultValue; I would code 501 return ((v = get(key) != null) || containsKey(key)) ? v : defaultValue; Use consistent formatted code examples in javadoc. I like the style from lines 558 to 561, but e.g. from line 601 to 605: - 2 spaces before 

- indentation should be 4
- line break before }
Why you use both, {@code...} and ... ? For performance reasons, I think you should reverse the order of the if expressions here: 673 if (!Objects.equals(get(key), value) || !containsKey(key)) ... because otherwise map lookup too often becomes executed twice, via contains() + get(). Not negate the comparison term, e.g.: 1053 if (value == null) 1054 return null; 1055 if ((oldValue = putIfAbsent(key, value)) == null) 1056 return value; -Ulf Am 08.04.2013 20:07, schrieb Mike Duigou: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > 8004518: Add in-place operations to Map > forEach() > replaceAll() > > 8010122: Add atomic operations to Map > getOrDefault() > putIfAbsent() * > remove(K, V) > replace(K, V) > replace(K, V, V) > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * > > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike > From david.holmes at oracle.com Tue Apr 9 02:22:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 12:22:24 +1000 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <51637B60.5080905@oracle.com> Hi Mike, Looking only at Map itself for now. On 9/04/2013 4:07 AM, Mike Duigou wrote: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ General style issues: - spaces after keyword ie "if (x == null)" not "if(x == null)" - comparisons against constants/null put the constant/null on the right ie "if (x == null)" not "if (null == x)" (where has our style guide gone? I can't find it on internal or external wikis :( ) > 8004518: Add in-place operations to Map > forEach() > replaceAll() Both of those contain the boilerplate text: *

The default implementation makes no guarantees about * synchronization or atomicity properties of this method. Any * class overriding this method must specify its concurrency * properties. In particular, all implementations of * subinterface {@link java.util.concurrent.ConcurrentMap} * must ensure that this operation is performed atomically. but these methods are not, and can not be, atomic in ConcurrentMap forEach and replaceAll are very similar in terms of taking and applying a "operation" to each entry, yet their descriptions use a completely different style. forEach describes thing in general terms while replaceAll talks about calling the functions' apply method with the current entry's key and value. I would suggest for replaceAll: "Replaces each entry's value with the result of invoking the given function on that entry, in the order entries are returned by an entry set iterator, until all entries have been processed or the function throws an exception." This is also makes "replace" the subject rather than "apply". forEach doesn't declare the IllegalStateException that getKey and getValue can throw. Some/many of the @throws text has obviously been copied from the Map.Entry methods eg: * @throws ClassCastException if the class of the specified value * prevents it from being stored in the backing map but when put into Map itself they should not be referring to "the backing map" as there is no "backing map". Further we have inconsistent terminology being used, eg getOrDefault has: * @throws ClassCastException if the key is of an inappropriate type for * this map and then there is a third variant in other methods: * @throws ClassCastException if the class of the specified key or value * prevents it from being stored in this map * (optional) These should all have the same basic wording, differing only in key/value. > 8010122: Add atomic operations to Map Meaning "backport some operations from ConcurrentMap" - they aren't actually atomic in Map. > getOrDefault() No comment > putIfAbsent() * The default implementation throws ConcurrentModificationException but this is not declared in the spec. > remove(K, V) > replace(K, V) > replace(K, V, V) No comments > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * The following generally apply to this group of methods. As Peter already stated the spec: *

If the function returns {@code null}, the mapping is removed (or * remains absent if initially absent). is somewhat unclear. The parenthesized part is not connected to the function returning null or otherwise; as the function won't be called. I find the spec for these rather confusing from a concurrency perspective - this non-concurrent interface seems to be trying to say too much about how a concurrent interface should specify behaviour. Why does it need to say: * In concurrent contexts, the default implementation may retry * these steps when multiple threads attempt updates. ? Note computeIfAbsent does not say the same thing. The @implSpec does not match the actual implementation. It looks to me like these implementations are trying to cater for concurrent situations - hence the loop. That's okay but then the implSpec should identify that fact. 980 * be of use when combining multiple mapped values for a key. For 981 * example. to either create or append a {@code String msg} to a Period after example should be a comma. Cheers, David > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike > > From david.holmes at oracle.com Tue Apr 9 04:27:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 14:27:34 +1000 Subject: Define JNIEXPORT as visibility default with GCC? In-Reply-To: <516373BE.1030703@oracle.com> References: <511CAE4C.2000002@redhat.com> <4974FD20-B6DD-40F5-A7E9-B78F09E9C2A1@oracle.com> <511D5A8F.7050403@redhat.com> <511E0BD7.4040603@oracle.com> <511E667D.2000700@redhat.com> <51215FE5.1080405@oracle.com> <5121F60C.5040004@redhat.com> <51241726.2040102@oracle.com> <0ED8D7F6-1541-46C0-81AE-46FA0CBFE423@oracle.com> <512FC497.9080400@oracle.com> <513A2E8C.8090009@oracle.com> <516373BE.1030703@oracle.com> Message-ID: <516398B6.6030101@oracle.com> I've bcc'd jdk8-dev and re-added core-libs and hotspot-runtime as that is where the original thread was. David On 9/04/2013 11:49 AM, Coleen Phillimore wrote: > > Hi Martin, > > I'm sorry, I lost track of this and thought it was already pushed. The > jni_md.h changes look good but I don't really understand why the awt > changes were made, or what they do. Since the jdk doesn't usually push > using JPRT, I'm afraid to push this directly myself without a review > from someone from jdk8-dev at openjdk.com. I have cc'ed them. I think > someone from the tools and libraries group should review and push this. > > Thanks, > Coleen > > On 4/8/2013 7:35 PM, Martin Buchholz wrote: >> friendly ping. I'd like to have an approve to push this (or have >> someone jprt for me). >> >> >> On Mon, Mar 11, 2013 at 4:57 PM, Martin Buchholz > > wrote: >> >> The latest version of my webrev is here: >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ >> >> It includes this line: >> >> Reviewed-by: coleenp, ddehaven, dcubed >> >> >> Ok to push? >> >> >> >> On Fri, Mar 8, 2013 at 10:31 AM, Coleen Phillmore >> > > wrote: >> >> >> The hotspot definitions of JNIEXPORT don't match in all the >> files to the JDK definition. I think a hotspot bug should be >> filed to fix the jni_.h definitions which now none of >> them match. After someone in core-libs checks this in, we'll >> update the hotspot files to match the final version and retest >> -fvisibility=hidden. >> >> I don't remember why the JDK version wasn't fixed with the >> original -fvisibility=hidden work. >> >> Coleen >> >> >> On 2/28/2013 3:56 PM, Daniel D. Daugherty wrote: >> >> On 2/28/13 11:57 AM, David DeHaven wrote: >> >> Has a bug been filed for this? -DrD- >> >> >> As mentioned earlier in this thread... >> >> Dan >> >> >> >> On 2/19/13 5:21 PM, Daniel D. Daugherty wrote: >> >> I couldn't find a 'jdk' repo relevant bug for this >> issue so I filed: >> >> 8008509: 6588413 changed JNIEXPORT visibility for >> GCC on HSX, jdk's >> jni_md.h needs similar change >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008509 >> https://jbs.oracle.com/bugs/browse/JDK-8008509 >> >> Coleen did the original work on 6588413 so I added her >> to the "interest >> list" for the new bug. The need for an update to the >> jdk repo's jni_md.h >> file was raised during the code review for 6588413, >> but that detail appears >> to have been dropped. >> >> Dan >> >> >> >> > From bourges.laurent at gmail.com Tue Apr 9 07:37:48 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 9 Apr 2013 09:37:48 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <51631FE2.6090200@oracle.com> References: <51471A46.4000901@oracle.com> <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> Message-ID: Mandy, first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u) as it fixes many problems: - string concatenations - object creations (Object[] or other objects given as params) - method calls in log statements In a second step, I can help somebody migrating JUL usages to PlatformLogger but it requires PlatformLogger API changes (logp to give class and method names)... Other comments below: > > Peter's idea is a good one to add a couple of convenient methods to take > Object parameters that will avoid the creation of array instances. I'd > also like to know what variants being used in the jdk to determine the pros > and cons of the alternatives (this issue also applies to java.util.logging). > 50% of given object parameters are created via method calls so it will not be enough. Moreover, I prefer having always isLoggable() calls to avoid me looking and understanding special cases (more than 2 args or no string concat ...); besides, it would be easier to implement code checks testing missing isLoggable() calls vs conditional and specific checks (string concat, more then 2 args, method calls ...) Finally, I prefer having shorter and clearer method names like isFine(), isFinest() instead of isLoggable(PlatformLogger.FINE) that is quite "ugly" ... > It was intentional to have PlatformLogger define only the useful methods > necessary for jdk use. The goal of PlatformLogger was to provide a > light-weight utility for jdk to log debugging messages and eliminate the > dependency to java.util.logging and avoid the unnecessary j.u.logging > initialization (as disabled by default). It was not a goal for > PlatformLogger to be an exact mirror as java.util.logging.Logger. My > advice is to tune PlatformLogger to provide API that helps the platform > implementation while avoid bloating the API. > Agreed. Maybe JUL Logger.logp(classname, methodname) usages should be rewritten to use PlatformLogger.getCallerInfo() instead: // Returns the caller's class and method's name; best effort // if cannot infer, return the logger's name. private String getCallerInfo() { String sourceClassName = null; String sourceMethodName = null; * JavaLangAccess access = SharedSecrets.getJavaLangAccess(); * Throwable throwable = new Throwable(); int depth = access.getStackTraceDepth(throwable); String logClassName = "sun.util.logging.PlatformLogger"; boolean lookingForLogger = true; for (int ix = 0; ix < depth; ix++) { // Calling getStackTraceElement directly prevents the VM // from paying the cost of building the entire stack frame. StackTraceElement frame = access.getStackTraceElement(throwable, ix); String cname = frame.getClassName(); if (lookingForLogger) { // Skip all frames until we have found the first logger frame. if (cname.equals(logClassName)) { lookingForLogger = false; } } else { if (!cname.equals(logClassName)) { // We've found the relevant frame. sourceClassName = cname; sourceMethodName = frame.getMethodName(); break; } } } if (sourceClassName != null) { return sourceClassName + " " + sourceMethodName; } else { return name; } } } > > Since you are touching some jdk files that use java.util.logging, would > you like to contribute to convert them to use PlatformLogger: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233 > > It's perfectly fine to convert only some of them if not all. > I want to help but as you said it should be done in collaboration because it requires API changes (JMX, RMI ...) but I prefer after this patch is reviewed and submitted and in coming weeks. > > Jim Gish is the owner of logging and will check with him if he has cycles > to work with you on this. > Great. Cheers, Laurent From scolebourne at joda.org Tue Apr 9 09:53:50 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Apr 2013 10:53:50 +0100 Subject: Scope modifiers in interfaces [was Default methods on Map] Message-ID: As far as I can tell, there are three different styles being used for "public" modifiers in interfaces now: 1) no use of "public" 2) use of "public" only on default methods 3) use of "pubilc" on default and abstract methods (I can't recall seeing any static methods on interfaces outside of JSR-310 yet) Type 1: http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/stream/Collector.java Type 2: http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/BiConsumer.java Type 3: http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntSupplier.java http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntPredicate.java I find this inconsistency troubling. Its time for a firm recommendation to be made as to Oracle's preferred coding standard. I'm of the opinion that moving code to #3, explicit use of "public" will serve Java better in the long run. I find #1 particularly troubling, as it means a default method (which looks very like a normal method) looks like it is package scoped when I read the source code. (this affects the Map changes webrev) Stephen On 8 April 2013 19:07, Mike Duigou wrote: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > 8004518: Add in-place operations to Map > forEach() > replaceAll() > > 8010122: Add atomic operations to Map > getOrDefault() > putIfAbsent() * > remove(K, V) > replace(K, V) > replace(K, V, V) > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * > > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike > From Alan.Bateman at oracle.com Tue Apr 9 10:49:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Apr 2013 11:49:11 +0100 Subject: ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51631FD6.6090800@oracle.com> References: <51631FD6.6090800@oracle.com> Message-ID: <5163F227.5070109@oracle.com> On 08/04/2013 20:51, Xueming Shen wrote: > Hi, > > JSR 310 has continued to refine and update the java.time API. > Please help review the proposed changeset as showed in webrev: > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ I skimmed through the changes (not a detailed review, there's way too much and I don't have time at the moment). I focused mostly on the zoneId -> TZ mapping and the initialization of the HashMap because that is hurting jdk8 startup since JSR-310 was pushed. The approach looks good to me and it's good to have this regression (probably mostly) resolved. In ZoneInfoFile then I don't see how load(DataInputStream) can throw CNFE (I might have missed something) so maybe that could be removed and the exception handling in the static initializer cleaned up. In passing, I see Duration.between(Temporal,Temporal) using exceptions for control flow but perhaps it's so rare that it's not an issue. A typo in passing in ResolverStyle's javadoc: "will perform the a sensible default". -Alan. From david.holmes at oracle.com Tue Apr 9 11:57:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 21:57:42 +1000 Subject: Scope modifiers in interfaces [was Default methods on Map] In-Reply-To: References: Message-ID: <51640236.4080003@oracle.com> Stephen, On 9/04/2013 7:53 PM, Stephen Colebourne wrote: > As far as I can tell, there are three different styles being used for > "public" modifiers in interfaces now: > > 1) no use of "public" > 2) use of "public" only on default methods > 3) use of "pubilc" on default and abstract methods > (I can't recall seeing any static methods on interfaces outside of JSR-310 yet) > > Type 1: > http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/stream/Collector.java > > Type 2: > http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/BiConsumer.java > > Type 3: > http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntSupplier.java > http://hg.openjdk.java.net/lambda/lambda/jdk/file/b6a9eaeb0f16/src/share/classes/java/util/function/IntPredicate.java All of the lambda-related work has now moved (or is moving) to #1. No public on interface methods as has been the recommendation since day one. > I find this inconsistency troubling. Its time for a firm > recommendation to be made as to Oracle's preferred coding standard. I agree because I see that java.time is using #2. > I'm of the opinion that moving code to #3, explicit use of "public" > will serve Java better in the long run. I find #1 particularly > troubling, as it means a default method (which looks very like a > normal method) looks like it is package scoped when I read the source > code. If/when non-public methods are allowed in interfaces then we should probably make things explicit, in my opinion. I don't find anything troubling about not having public of interface methods - default or abstract. David ----- > (this affects the Map changes webrev) > Stephen > > > > On 8 April 2013 19:07, Mike Duigou wrote: >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >> >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() >> >> 8010122: Add atomic operations to Map >> getOrDefault() >> putIfAbsent() * >> remove(K, V) >> replace(K, V) >> replace(K, V, V) >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * >> >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike >> From david.holmes at oracle.com Tue Apr 9 12:00:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Apr 2013 22:00:56 +1000 Subject: ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51631FD6.6090800@oracle.com> References: <51631FD6.6090800@oracle.com> Message-ID: <516402F8.5020302@oracle.com> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar file or not; if not then it should not be built using CreateJars.gmk and shouldn't listed on the JAR variables in profile-includes.txt David On 9/04/2013 5:51 AM, Xueming Shen wrote: > Hi, > > JSR 310 has continued to refine and update the java.time API. > Please help review the proposed changeset as showed in webrev: > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > In addition to general javadoc improvements, the changes include: > > java.time > > * Duration - added a static from(temporalAmount) method to simplify > conversions from other amounts > * Renamed the toString(Formatter) method to format(Formatter) in all > classes > * Period - added a static from(temporalAmount) method to simplify > conversions > * ZoneId - > - Added getAvailableZoneIds method, a simpler mechanism than going > to the provider > - Added normalized() method to ease conversion to a fixed offset > - renamed predefined static fields of timezone names > > java.time.chrono > > * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime > - changed xxx_COMPARATORs to static methods returning the Time Line > Order comparators > - Added a from(TemporalAcessor) method to ease conversions > * Chronology > - Added method to create a Date from EpochDay (And in each > calendar subclass) > - Added resolveDate to allow resolving date components by the > Chronology > - Serialization fixes > - Replaced raw return types with wildcard type > * Era > - Removed factory methods and getChronology - they did not work > correctly in all cases > - Declared Era as a functional interface > * Hijrah calendar variations - > - Supporting the Umm alQura calendar > * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra > making the enums public > * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method > to return the concrete Era type. > > java.time.format > > * DateTimeFormatter - > - Added fields for the predefined formatters > (moved from DateTimeFormatters class) > - Updated patterns to be CLDR compatible > - Moved documentation for the pattern letters to the class javadoc > - Added support for Zone default and conversion > * DateTimeFormatterBuilder > - Updated documentation of patterns and corresponding equivalents > to builder methods. > - Added a method to append the localized offset. > > java.time.temporal > > * Adjusters - class removed; all static adjusters moved to static methods > in TemporalAdjuster > * ChronoField - > - Renamed EPOCH_MONTH to PROLEPTIC_MONTH > - Added getDisplayName - for locale specific field name > * Queries - class removed; all static query method moved to static methods > in TemporalQuery > * TemporalField - added getDisplayName method > * UnsupportedTemporalTypeException - new subtype of DateTimeException > to reflect no support for a unit or field > * WeekFields - Added fields for week and year of week-Based-Years to match > CLDR fields "Y", "W" From scolebourne at joda.org Tue Apr 9 12:28:13 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 9 Apr 2013 13:28:13 +0100 Subject: Scope modifiers in interfaces [was Default methods on Map] In-Reply-To: <51640236.4080003@oracle.com> References: <51640236.4080003@oracle.com> Message-ID: While I disagree with the choice made (one of Java's strengths is a little bit of extra verbosity), I am happy if it is consistent. Based on the links I provided, clearly Project Lambda has a long way to go to meet that consistency, so it clearly hasn't been a firm recommendation up until now. java.time will of course be adapted to match. Stephen On 9 April 2013 12:57, David Holmes wrote: > All of the lambda-related work has now moved (or is moving) to #1. No public > on interface methods as has been the recommendation since day one. > >> I find this inconsistency troubling. Its time for a firm >> recommendation to be made as to Oracle's preferred coding standard. > > > I agree because I see that java.time is using #2. > > >> I'm of the opinion that moving code to #3, explicit use of "public" >> will serve Java better in the long run. I find #1 particularly >> troubling, as it means a default method (which looks very like a >> normal method) looks like it is package scoped when I read the source >> code. > > > If/when non-public methods are allowed in interfaces then we should probably > make things explicit, in my opinion. I don't find anything troubling about > not having public of interface methods - default or abstract. > > David > ----- > > >> (this affects the Map changes webrev) >> Stephen >> >> >> >> On 8 April 2013 19:07, Mike Duigou wrote: >>> >>> Hello all; >>> >>> This is a combined review for the new default methods on the >>> java.util.Map interface being added for the JSR-335 lambda libraries. The >>> reviews are being combined because they share a common unit test. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>> >>> 8004518: Add in-place operations to Map >>> forEach() >>> replaceAll() >>> >>> 8010122: Add atomic operations to Map >>> getOrDefault() >>> putIfAbsent() * >>> remove(K, V) >>> replace(K, V) >>> replace(K, V, V) >>> compute() * >>> merge() * >>> computeIfAbsent() * >>> computeIfPresent() * >>> >>> The * operations treat null values as being absent. (ie. the same as >>> there being no mapping for the specified key). >>> >>> The default implementations provided in Map are overridden in HashMap for >>> performance purposes, in Hashtable for atomicity and performance purposes >>> and in Collections for atomicity. >>> >>> Mike >>> > From bourges.laurent at gmail.com Tue Apr 9 13:02:17 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 9 Apr 2013 15:02:17 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements Message-ID: Dear Java2D members, Could someone review the following webrev concerning Java2D Pisces to enhance its performance and reduce its memory footprint (RendererContext stored in thread local or concurrent queue): http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ FYI I fixed file headers in this patch and signed my OCA 3 weeks ago. Remaining work: - cleanup (comments ...) - statistics to perform auto-tuning - cache / memory cleanup (SoftReference ?): use hints or System properties to adapt it to use cases - another problem: fix clipping performance in Dasher / Stroker for segments out of bounds Could somebody support me ? ie help me working on these tasks or just to discuss on Pisces algorithm / implementation ? Best regards, Laurent Bourg?s From anthony.petrov at oracle.com Tue Apr 9 13:08:35 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 09 Apr 2013 17:08:35 +0400 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> Message-ID: <516412D3.90907@oracle.com> Hi Laurent, Thanks for all your hard work! The fix looks fine to me. I'm also CC'ing jdk8-dev@ to let other teams review the changes in their areas. I've only reviewed the AWT part of the fix. -- best regards, Anthony On 4/8/2013 15:32, Laurent Bourg?s wrote: > Anthony, > > here is an updated patch concerning both PlatformLogger and Logger 'bad' > usages: > http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ > > It impacts now awt, swing, JMX, security, network, and apache xml. > > Thanks for the review, > Laurent > > 2013/4/8 Laurent Bourg?s > > > Peter, Mandy, > > I think it would be great to make PlatformLogger very similar to > Logger API: > I mean JUL Logger already has only 1 convenient method with 1 param > so it may be great to have the same API in PlatformLogger too: maybe > extend it to 2 or 3 params ... > > Peter, could you look at the API differences between Logger / > PlatformLogger to make PlatformLogger API more similar to JUL Logger ? > > Laurent > > > 2013/4/8 Peter Levart > > > On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: >> >> Hi >> >> I started fixing All PlatformlLogger "bad" usages and I am >> fixing also many jul Logger usages without isLoggable ... >> That represents a lot of changes and a very boring job. >> >> I think sending a webrew tomorrow. >> > > Hi Laurent, > > Since you're already deep in the task, you might have a rough > feeling what part of such unguarded log statements are of the > following type: > > logger.[fine,info,...]("a message with {0} and {1} > placeholders", someArg1, someArg2); > > where someArg1, ... are some values that are already present in > the context of the logging statement and don't have to be > computed just for satisfying the logging (not even boxing). Such > usages could be effectively optimized by adding some overloaded > methods to PlatformLogger that take 1, 2, 3, ... arguments: > > class PlatformLogger { > > ... > > public void finest(String msg, Object param1) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1); > } > } > > public void finest(String msg, Object param1, Object param2) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2); > } > } > > public void finest(String msg, Object param1, Object param2, > Object param3) { > if (isLoggable(Level.FINEST)) { > loggerProxy.doLog(Level.FINEST, msg, param1, param2, > param3); > } > } > > ... > > This would effectively guard creation of the arguments array > with an isLoggable check for some common usages, eliminating the > need to explicitly guard such statements. Of course, the user > would have to be aware of when such unguarded logging statement > is without overhead and when not... > > How do you feel about such API extension? > > > Regards, Peter > > > >> Laurent >> >> Le 4 avr. 2013 14:08, "Laurent Bourg?s" >> > >> a ?crit : >> >> Ok, I can provide an updated patch after finding / fixing >> all usages. >> >> Probably in 1 or 2 days, >> >> Laurent >> >> 2013/4/4 Anthony Petrov > > >> >> Yes, this makes sense. Do you want to update your fix >> for 8010297 to include these changes as well? >> >> -- >> best regards, >> Anthony >> >> >> On 04/04/13 15:47, Laurent Bourg?s wrote: >> >> Dear all, >> >> I just realized there is another problem with >> PlatformLogger log statements: >> XBaseWindow: >> public boolean grabInput() { >> grabLog.fine("Grab input on {0}", this); >> ... >> } >> >> This calls the PlatformLogger.fine( varargs): >> public void fine(String msg, Object... params) { >> logger.doLog(FINE, msg, params); >> } >> >> Doing so, the JVM creates a new Object[] instance >> to provide params as >> varargs. >> >> I would recommend using isLoggable() test to avoid >> such waste if the log >> is disabled (fine, finer, finest ...). >> >> Do you want me to provide a new patch related to >> this problem ? >> >> Does somebody have an idea to automatically >> analyze the JDK code and >> detect missing isLoggable statements ... >> >> Regards, >> Laurent >> >> 2013/4/3 Laurent Bourg?s >> > >> > >> >> >> >> Anthony, >> >> could you tell me once it is in the OpenJDK8 >> repository ? >> I would then perform again profiling tests to >> check if there is no >> more missing isLoggable() statements. >> >> Once JMX and other projects switch to >> PlatformLogger, I could check >> again. >> >> Maybe I could write a small java code checker >> (pmd rule) to test if >> there is missing isLoggable() statements >> wrapping PlatformLogger log >> statements. Any idea about how to reuse java >> parser to do so ? >> >> Regards, >> >> Laurent >> >> 2013/4/2 Anthony Petrov >> > >> > >> >> >> >> Looks fine to me as well. Thanks for >> fixing this, Laurent. >> >> Let's wait a couple more days in case Net >> or Swing folks want to >> review the fix. After that I'll push it to >> the repository. >> >> -- >> best regards, >> Anthony >> >> >> On 4/2/2013 15:35, Laurent Bourg?s wrote: >> >> Here is the updated patch: >> >> http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ >> >> >> >> >> >> Fixed inconsistencies between FINE / >> FINER log statements: >> - XScrollbarPeer >> - XWindowPeer >> >> Laurent >> >> 2013/4/2 Anthony Petrov >> > >> > > >> > __com >> >> > >>> >> >> >> 1. Sergey: I believe this is for >> purposes of better >> formating the >> log output and making it more >> readable by separating or >> highlighting >> some sections. I don't think this >> should be changed. >> >> 2. Laurent: can you please >> address this issue and send >> us a new patch? >> >> -- >> best regards, >> Anthony >> >> >> On 4/1/2013 16:08, Sergey >> Bylokhov wrote: >> >> >> Hi, Anthony >> Only two comments: >> 1 Why we need some special >> text in the log output >> like "***" and >> "###" >> 2 XScrollbarPeer.java: >> >> + if >> >> (log.isLoggable(____PlatformLogger.FINEST)) { >> >> >> + >> log.finer("KeyEvent on scrollbar: " + >> event); >> + } >> >> >> >> On 4/1/13 12:20 PM, Anthony >> Petrov wrote: >> >> Awt, Swing, Net engineers, >> >> Could anyone review the >> fix please? For your >> convenience: >> >> Bug: >> >> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >> >> >> >> >> > >> > >> >> Fix: >> >> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >> >> >> >> >> > >> > >> >> -- best regards, >> Anthony >> >> On 3/22/2013 2:26, >> Anthony Petrov wrote: >> >> Hi Laurent, >> >> The fix looks great >> to me. Thank you very much. >> >> We still need at >> least one review, though. >> Hopefully >> net-dev@ and/or >> swing-dev@ folks might help >> us out a bit. >> >> -- >> best regards, >> Anthony >> >> On 3/20/2013 15:10, >> Anthony Petrov wrote: >> >> Hi Laurent, >> >> Thanks for the >> patch. I've filed a bug at: >> >> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >> >> >> >> >> >> > >> > >> (should be >> available in a day or two) >> >> and published a >> webrev generated from >> your patch at: >> >> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >> >> >> >> >> > >> > >> >> >> I'm also copying >> swing-dev@ and >> net-dev@ because the >> fix affects those >> areas too. I myself >> will review >> the fix a bit >> later but am sending it >> now for other >> folks to take a >> look at it. >> >> On 3/19/2013 >> 15:29, Laurent Bourg?s wrote: >> >> I am sorry I >> started modifying >> PlatformLogger >> and reverted >> changes to this class >> as it is >> another topic >> to be discussed >> later: isLoggable >> performance >> and waste due to >> HashMap> Level> leads >> to Integer allocations >> (boxing). >> >> >> I saw your >> message to core-libs-dev@, >> so I just >> dropped all >> changes to the >> PlatformLogger from this >> patch. >> >> Finally, I >> have another question >> related to the >> >> WrapperGenerator class: it >> generates a lot of >> empty log >> statements (XEvent): >> >> log >> >> > >> >> >> >> >> > >> >>.finest >> >> > >> >> >> >> >> > >> >>(""); >> >> >> Is it really >> useful to have such >> statements ? I >> would keep >> logs with non empty >> messages only. >> >> See >> WrapperGenerator:753: >> >> String s_log = >> >> (generateLog?"log.finest(\"\")____;":""); >> >> >> >> >> I believe they're >> used for log >> formatting purposes >> to separate >> numerous events in a log >> (e.g. think of >> mouse-move events >> - there can be >> hundreds of them in >> a raw). >> >> >> Please note that >> the hg export format >> is not that >> useful unless >> you're assigned an >> OpenJDK id already >> (please see >> Dalibor's message for >> details) because I >> can't import it >> directly. So for the >> time being you >> could send just >> raw patches (i.e. the >> output of hg >> diff only - and >> there's no need to >> commit your >> changes in this >> case). Also, please >> note that the >> mailing lists >> strip attachments. The >> reason I got it >> is because I was >> listed in To: of your >> message. So >> when sending >> patches you can: >> 1) post them >> inline, or >> 2) attach them >> and add a person to To: >> of your >> message, or >> 3) upload them >> somewhere on the web. >> However, it would >> be best if you could >> generate a >> webrev for your >> changes and upload it >> somewhere. >> Currently this is >> the standard format >> for reviewing >> fixes in OpenJDK. >> >> -- >> best regards, >> Anthony >> >> >> Regards, >> Laurent >> >> >> >> 2013/3/19 >> Laurent Bourg?s >> > >> > > >> > __com >> > >> >> > . >> > .>____com >> >> > __com >> > >>>> >> >> Hi antony, >> >> FYI I >> started reviewing and >> fixing all >> >> PlatformLogger use cases (not >> too many >> as I thought first) >> mainly used by >> awt / swing >> projects to >> provide >> you a patch on latest >> JDK8 source code: >> >> I am >> adding the log level check >> when it is >> missing: >> if >> >> (...log.isLoggable(____PlatformLogger.xxx)) { >> >> >> log... >> } >> >> I will >> not change the String + >> operations to >> use the >> message format >> syntax in >> this patch. >> >> Do you >> accept such patch / proposed >> contribution ? >> >> Regards, >> Laurent >> >> >> 2013/3/18 >> Laurent Bourg?s >> > >> > > >> > __com >> > >> >> > . >> > .>____com >> >> > __com >> > >>>> >> >> Hi >> antony, >> >> 2 >> different things: >> 1/ >> PlatformLogger was >> patched (doLog >> method) to >> avoid string >> >> operations (message >> formatting) for >> disabled logs >> (patch >> >> submiited on JDK8 and JDK7u): >> >> http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html >> >> >> >> >> >> >> > >> > >> >> >> 2/ I >> looked 2 hours ago on >> JDK7u AND >> JDK8 source >> codes and both >> still >> have: >> - log >> statements WITHOUT >> log level check >> : if >> >> (log.isLoggable(____PlatformLogger.FINE)) >> >> >> log.fine(...); >> - >> string operations (+) in >> log calls >> that could be >> improved >> using >> the message format >> syntax (String >> + args): for >> example, >> avoid >> using >> PlatformLogger.fine(String + >> ...) in favor >> of using >> >> PlatformLogger.fine(String msg, >> Object... params) >> >> I >> reported in my previous >> mail several >> cases where the >> >> isLoggable() call is >> missing and leads >> to useless String >> >> operations but also method >> calls >> >> (Component.paramString() for >> example). >> >> >> Finally, I also provided >> other possible >> cases (using >> grep); >> maybe >> there is a better >> alternative to >> find all >> occurences of >> >> String operations in log calls. >> >> Regards, >> Laurent >> >> >> 2013/3/18 Anthony Petrov >> > >> > > >> > __com >> > >> >> > . >> > .>____com >> >> > __com >> > >>>> >> >> >> Hi Laurent, >> >> >> Normally we fix an >> issue in JDK 8 >> first, and >> then back-port >> >> the fix to a 7u >> release. You're >> saying that >> in JDK 8 the >> >> problem isn't >> reproducible anymore. >> Can you please >> >> investigate (using the >> Mercurial >> history log) >> what exact fix >> >> resolved it in JDK 8? >> >> -- >> >> best regards, >> >> Anthony >> >> >> On 03/18/13 15:09, >> Laurent Bourg?s >> wrote: >> >> >> Dear all, >> >> >> I run recently >> netbeans profiler >> on my swing >> application >> >> (Aspro2: >> http://www.jmmc.fr/aspro) under >> linux x64 >> platform and I >> >> figured out >> >> that a lot of >> char[] instances >> are coming >> from String + >> >> operator called >> >> by sun.awt.X11 code. >> >> >> I looked at >> PlatformLogger >> source code >> but found not way >> >> to disable it >> >> completely: maybe >> an empty >> logger >> implementation could >> >> be interesting to >> >> be used during >> profiling or >> normal use >> (not debugging). >> >> Apparently JDK8 >> provides some >> patchs to >> avoid String >> >> creation when the >> >> logger is disabled >> (level). >> >> >> However, I looked >> also to the >> sun.awt code >> (jdk7u >> >> repository) to see the >> >> origin of the >> string allocations: >> >> XDecoratedPeer: >> >> public void >> >> handleFocusEvent(XEvent xev) { >> >> ... >> * >> focusLog.finer("Received >> focus event on shell: >> " + xfe); >> >> * } >> >> >> public boolean >> >> requestWindowFocus(long time, >> >> boolean timeProvided) { >> >> ... >> * >> focusLog.finest("Real >> native focused >> >> window: " + >> >> realNativeFocusedWindow + >> "\nKFM's focused window: " + >> focusedWindow); >> >> *... >> * >> focusLog.fine("Requesting >> focus to " + (this == >> >> toFocus ? "this >> >> window" : toFocus)); >> >> *... >> } >> >> >> XBaseWindow: >> >> public void >> xSetBounds(int >> x, int y, int >> width, int >> >> height) { >> >> ... >> * >> insLog.fine("Setting >> bounds on " + >> this + " to >> >> (" + x + ", " + >> >> y + "), " + width + >> "x" + height); >> >> *} >> >> >> XNetProtocol: >> >> boolean >> doStateProtocol() { >> >> ... >> * >> >> stateLog.finer("______doStateProtocol() returns " + >> >> >> >> res); >> >> *} >> >> >> XSystemTrayPeer: >> >> XSystemTrayPeer(SystemTray >> target) { >> >> ... >> >> * log.fine(" >> check if >> system tray >> is available. >> >> selection owner: >> " + selection_owner); >> >> *} >> >> void >> >> addTrayIcon(XTrayIconPeer tiPeer) >> throws >> >> AWTException { >> >> ... >> >> * log.fine(" >> send >> >> SYSTEM_TRAY_REQUEST_DOCK >> >> message to owner: " + >> >> selection_owner); >> >> *} >> >> >> XFramePeer: >> >> public void >> >> handlePropertyNotify(XEvent xev) { >> >> ... >> >> stateLog.finer("State >> is the same: " + state); >> } >> >> >> However I only give >> here few >> cases but >> certainly others >> >> are still >> >> present in the >> source code; >> maybe >> findbugs or netbeans >> >> warnings could >> >> help you finding >> all of them. >> >> >> I advocate the >> amount of waste >> (GC) is not very >> >> important but String >> >> conversion are also >> calling >> several >> toString() methods >> >> that can be >> >> costly (event, >> Frame, window ...) >> >> >> Finally, I ran few >> grep commands >> on the >> sun.awt.X11 code >> >> (jdk7u) and you >> >> can look at them to >> see all >> string + >> operations related >> >> to log statements. >> >> >> PS: I may help >> fixing the source >> code but I >> have no idea >> >> how to >> >> collaborate >> (provide a patch ?) >> >> >> Regards, >> >> Laurent Bourg?s >> >> >> >> >> >> >> -- Best regards, Sergey. >> >> >> >> >> > > > From sundararajan.athijegannathan at oracle.com Tue Apr 9 13:38:17 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 09 Apr 2013 13:38:17 +0000 Subject: hg: jdk8/tl/nashorn: 20 new changesets Message-ID: <20130409133832.487BF4817A@hg.openjdk.java.net> Changeset: af6fc67aa73d Author: jlaskey Date: 2013-04-02 11:37 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/af6fc67aa73d 8011233: Create a Nashorn shell for JavaFX Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! make/build.xml ! make/project.properties + tools/fxshell/jdk/nashorn/tools/FXShell.java Changeset: be5d2e472e22 Author: jlaskey Date: 2013-04-02 11:38 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/be5d2e472e22 Merge Changeset: 159dbe2e02eb Author: sundar Date: 2013-04-02 20:42 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/159dbe2e02eb 8011237: Object.isExtensible(Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get) should be false Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + test/script/basic/JDK-8011237.js Changeset: e9af5451d2d1 Author: sundar Date: 2013-04-02 23:01 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e9af5451d2d1 8011274: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.hasOwnProperty("prototype") should be false Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + test/script/basic/JDK-8011274.js Changeset: e63b20d4f08a Author: sundar Date: 2013-04-03 11:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e63b20d4f08a 8011357: Array.prototype.slice and Array.prototype.splice should not call user defined valueOf of start, end arguments more than once Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8011357.js Changeset: 51da1afbab26 Author: attila Date: 2013-04-03 11:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/51da1afbab26 8011362: Overloaded method resolution foiled by nulls Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java + test/script/basic/JDK-8011362.js + test/script/basic/JDK-8011362.js.EXPECTED + test/src/jdk/nashorn/test/models/Jdk8011362TestSubject.java Changeset: b4191da366be Author: sundar Date: 2013-04-03 15:27 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b4191da366be 8011365: Array.prototype.join and Array.prototype.toString do not throw TypeError on null, undefined Reviewed-by: attila, hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java ! test/script/basic/JDK-8011362.js.EXPECTED + test/script/basic/JDK-8011365.js Changeset: 4f7d7576e8c4 Author: hannesw Date: 2013-04-03 12:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4f7d7576e8c4 8007774: Enable code cache again Reviewed-by: lagergren, attila, sundar ! src/jdk/nashorn/internal/runtime/resources/Options.properties Changeset: 82fed56d8dce Author: sundar Date: 2013-04-03 20:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/82fed56d8dce 8011382: Data prototype methods and constructor do not call user defined toISOString, valueOf methods per spec. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8011382.js Changeset: a5a8ddc2e028 Author: sundar Date: 2013-04-04 10:24 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a5a8ddc2e028 8011394: RegExp.prototype.test() does not call valueOf on lastIndex property as per the spec. Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8011394.js Changeset: 0548c134b9ac Author: sundar Date: 2013-04-04 13:54 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0548c134b9ac 8011421: When using Object.defineProperty on arrays, PropertyDescriptor's property accessors are invoked multiple times Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8011421.js Changeset: f638f2f094f7 Author: jlaskey Date: 2013-04-04 09:05 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f638f2f094f7 8011540: PropertyMap histories should not begin with empty map Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 069923cc9de5 Author: jlaskey Date: 2013-04-04 09:06 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/069923cc9de5 Merge Changeset: 18df6640e63f Author: sundar Date: 2013-04-04 18:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18df6640e63f 8011543: "".split(undefined,{valueOf:function(){throw 2}}) does not throw exception Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8011543.js Changeset: 5eb1427b6a6d Author: attila Date: 2013-04-04 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5eb1427b6a6d 8011544: Allow subclassing Java classes from script without creating instances Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/runtime/linker/AdaptationException.java + src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java + src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/javaclassoverrides.js + test/script/basic/javaclassoverrides.js.EXPECTED Changeset: 73e1270b240c Author: attila Date: 2013-04-04 15:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73e1270b240c Merge Changeset: 349360cc1df5 Author: sundar Date: 2013-04-04 20:46 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/349360cc1df5 8011552: Arrays with missing elements are not properly sorted Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8011552.js Changeset: 050fd5696bcb Author: attila Date: 2013-04-04 18:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/050fd5696bcb 8011555: Invalid class name in with block with JavaImporter causes MH type mismatch Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8011555.js + test/script/basic/JDK-8011555.js.EXPECTED Changeset: 1c29dc809de2 Author: hannesw Date: 2013-04-05 19:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1c29dc809de2 8009230: Nashorn rejects extended RegExp syntax accepted by all major JS engines Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8009230.js + test/script/basic/JDK-8009230.js.EXPECTED Changeset: 437861485ffa Author: jlaskey Date: 2013-04-09 08:36 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/437861485ffa Merge From alan.bateman at oracle.com Tue Apr 9 14:52:44 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 09 Apr 2013 14:52:44 +0000 Subject: hg: jdk8/tl/jaxws: 8010393: Update JAX-WS RI to 2.2.9-b12941 Message-ID: <20130409145248.3FE2A4817B@hg.openjdk.java.net> Changeset: 0989ad8c0860 Author: alanb Date: 2013-04-09 14:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/0989ad8c0860 8010393: Update JAX-WS RI to 2.2.9-b12941 Reviewed-by: alanb, erikj Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com ! makefiles/BuildJaxws.gmk + src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyle.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyleFeature.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/Databinding.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingFactory.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingMode.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/JavaCallInfo.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLGenerator.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLResolver.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BasePropertySet.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ContentType.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/DistributedPropertySet.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContext.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/PropertySet.java + src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ReadOnlyPropertyException.java + src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java + src/share/jaxws_classes/com/oracle/webservices/internal/impl/internalspi/encoding/StreamDecoder.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ExistingAnnotationsType.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaMethod.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaParam.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaWsdlMappingType.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ObjectFactory.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingParameterStyle.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingStyle.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingUse.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/Util.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/WebParamMode.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAction.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAddressing.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlBindingType.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlFaultAction.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlHandlerChain.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlMTOM.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlOneway.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlRequestWrapper.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlResponseWrapper.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlSOAPBinding.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlServiceMode.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebEndpoint.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebFault.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebMethod.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebParam.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebResult.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebService.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceClient.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceProvider.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceRef.java + src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.java ! src/share/jaxws_classes/com/sun/istack/internal/Builder.java ! src/share/jaxws_classes/com/sun/istack/internal/ByteArrayDataSource.java ! src/share/jaxws_classes/com/sun/istack/internal/FinalArrayList.java ! src/share/jaxws_classes/com/sun/istack/internal/FragmentContentHandler.java ! src/share/jaxws_classes/com/sun/istack/internal/Interned.java ! src/share/jaxws_classes/com/sun/istack/internal/NotNull.java ! src/share/jaxws_classes/com/sun/istack/internal/Nullable.java ! src/share/jaxws_classes/com/sun/istack/internal/Pool.java ! src/share/jaxws_classes/com/sun/istack/internal/SAXException2.java ! src/share/jaxws_classes/com/sun/istack/internal/SAXParseException2.java ! src/share/jaxws_classes/com/sun/istack/internal/XMLStreamException2.java ! src/share/jaxws_classes/com/sun/istack/internal/XMLStreamReaderToContentHandler.java ! src/share/jaxws_classes/com/sun/istack/internal/localization/Localizable.java ! src/share/jaxws_classes/com/sun/istack/internal/localization/LocalizableMessage.java ! src/share/jaxws_classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java ! src/share/jaxws_classes/com/sun/istack/internal/localization/Localizer.java + src/share/jaxws_classes/com/sun/istack/internal/localization/NullLocalizable.java ! src/share/jaxws_classes/com/sun/istack/internal/logging/Logger.java ! src/share/jaxws_classes/com/sun/istack/internal/package-info.java + src/share/jaxws_classes/com/sun/istack/internal/tools/DefaultAuthenticator.java ! src/share/jaxws_classes/com/sun/istack/internal/tools/MaskingClassLoader.java ! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java ! src/share/jaxws_classes/com/sun/istack/internal/tools/SecureLoader.java ! src/share/jaxws_classes/com/sun/istack/internal/tools/package-info.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMX.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMXGlassfish.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMXUtil.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/BootAMXMBean.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/MBeanListener.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/arc/Stability.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/arc/Taxonomy.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/PluginPoint.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProvider.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderInfo.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderManager.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderManagerDelegate.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeListener.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeParam.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeProvider.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/AverageRangeStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/BoundaryStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/BoundedRangeStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/CountStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/RangeStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/Statistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/Stats.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/StringStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/TimeStatistic.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/annotations/Reset.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatsImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java ! src/share/jaxws_classes/com/sun/tools/etc/META-INF/services/com.sun.tools.internal.xjc.Plugin ! src/share/jaxws_classes/com/sun/tools/internal/jxc/ConfigReader.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/NGCCRuntimeEx.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/SchemaGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/SchemaGeneratorFacade.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/SecureLoader.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/AnnotationParser.java + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/SchemaGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/SecureLoader.java + src/share/jaxws_classes/com/sun/tools/internal/jxc/api/JXC.java + src/share/jaxws_classes/com/sun/tools/internal/jxc/api/impl/j2s/JAXBModelImpl.java + src/share/jaxws_classes/com/sun/tools/internal/jxc/api/impl/j2s/JavaCompilerImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/Invoker.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/ToolVersion.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/WsGen.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/WsImport.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/TJavaGeneratorExtension.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/WsgenExtension.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/WsgenProtocol.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensible.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtension.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLOperation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLParserContext.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/ProcessorException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/CustomExceptionGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorBase.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorExtension.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorUtil.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/JavaGeneratorExtensionFacade.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/JwsImplGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/Names.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/SeiGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/ServiceGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/W3CAddressingJavaGeneratorExtension.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AbstractType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AsyncOperation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AsyncOperationType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Block.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ExtendedModelVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Fault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/HeaderFault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Message.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Model.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelObject.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelProperties.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Operation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Parameter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Port.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Request.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Response.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Service.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/exporter/ExternalObject.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaArrayType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaInterface.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaMethod.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaParameter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaSimpleType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaStructureMember.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaStructureType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBElementMember.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBMapping.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBModel.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBProperty.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBStructuredType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBTypeAndAnnotation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBTypeVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/RpcLitMember.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/RpcLitStructure.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/Util.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/JavaSimpleTypeCreator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/Modeler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/ModelerConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/ModelerException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/AnnotationProcessorContext.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/FaultInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/MakeSafeTypeVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/MemberInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/ModelBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeModeler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeMoniker.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeMonikerFactory.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAp.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WrapperInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/AccessorElement.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ClassNameAllocatorImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ConsoleErrorReporter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/JAXBModelBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ModelerUtils.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/PseudoSchemaBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModeler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModelerBase.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/ClassNameCollector.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/DirectoryUtil.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/IndentingWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ConfigurationMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/JavacompilerMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ModelMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ModelerMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ProcessorMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/UtilMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WsdlMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_de.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_es.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_it.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/spi/WSToolsObjectFactory.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/spi/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/ClassNameInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/ForkEntityResolver.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSDLFetcher.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSDLParseException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSToolsObjectFactoryImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/AbortException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/AuthInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/BadCommandLineException.java - src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/ErrorReceiver.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/ErrorReceiverFilter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/FilerCodeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Plugin.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WSCodeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenOptions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportListener.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/plugin/at_generated/PluginImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Binding.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingFault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingInput.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingOperation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingOutput.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Definitions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Documentation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Fault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Import.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Input.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Kinds.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Message.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/MessagePart.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Operation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/OperationStyle.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Output.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Port.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/PortType.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Service.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Types.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocument.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocumentVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocumentVisitorBase.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPAddress.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPBinding.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPOperation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPUrlEncoded.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPUrlReplacement.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/CustomName.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/Exception.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBinding.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBindingsConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/Parameter.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEContent.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEMultipartRelated.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEPart.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEXml.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaKinds.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAP12Binding.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAP12Constants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPAddress.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPBinding.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPBody.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPFault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPHeader.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPHeaderFault.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPOperation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPStyle.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPUse.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/AbstractDocument.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Defining.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/DuplicateEntityException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Elemental.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Entity.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityAction.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityReferenceAction.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityReferenceValidator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensibilityHelper.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionVisitor.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionVisitorBase.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExternalEntityReference.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/GlobalEntity.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/GloballyKnown.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Identifiable.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Kind.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/NoSuchEntityException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ParserListener.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/QNameAction.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/TWSDLParserContextImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/WSDLLocation.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/AbstractExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/AbstractReferenceFinderImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Constants.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestParser.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestScanner.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/HTTPExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/InternalizationLogic.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Internalizer.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/JAXWSBindingExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MIMEExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MemberSubmissionAddressingExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MetadataFinder.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/NamespaceContextImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Policy12ExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Policy15ExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAP12ExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAPEntityReferenceValidator.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAPExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Util.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/VersionChecker.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingMetadataExtensionHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WSDLInternalizationLogic.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WSDLParser.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WhitespaceStripper.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/ClassLoaderBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/Driver.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/Messages.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/ModelLoader.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SecureLoader.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/XJCFacade.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/XJC.java - src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java - src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/s2j/SchemaCompilerImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/s2j/TypeAndAnnotationImpl.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties - src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java - src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlIsSetWriter.java - src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlLocationWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/DualObjectFactoryGenerator.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractFieldWithVar.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CArrayInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/TypeUtil.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIUserConversion.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMBuilder.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/Internalizer.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/SCDBasedBindingSet.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/AnnotationParserFactoryImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/DomHandlerEx.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_zh_TW.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_zh_TW.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/util/DOMUtils.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_de.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_es.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_fr.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_it.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_ja.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_ko.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_pt_BR.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_zh_CN.properties + src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/util/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/InternalAccessorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/WhiteSpaceProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/impl/NameConverter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/impl/NameUtil.java + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/SAX2DOMEx.java + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/util/SecureLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/ContextFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/PropertyInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/Ref.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ArrayInfoImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilderI.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ReferencePropertyInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ParameterizedTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/SecureLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/util/ArrayInfoUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/LeafBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/SwaRefAdapterMarker.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java - src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ListElementProperty.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementLeafProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DomLoader.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallerImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_de.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_es.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_it.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/package-info.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/Header.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MultipartDataSource.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParseException.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/SharedInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/UniqueValue.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64DecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64EncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BEncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/LineInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QDecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QEncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPDecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPEncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUDecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUEncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocument.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/TreeException.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/Base64.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_de.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_es.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_it.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LogDomainConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/MimeHeadersUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/NamespaceContextIterator.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/SAAJUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/TeeInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java ! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/ASCIIUtility.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/BASE64DecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Chunk.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/ChunkInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/CleanUpExecutorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Data.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataFile.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DecodingException.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FileData.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Header.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/InternetHeaders.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/LineInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEEvent.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParsingException.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEPart.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MimeUtility.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/PropUtil.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/QPDecoderStream.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/UUDecoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamReaderEx.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java - src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/NamespaceContexHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/Closeable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/EPRSDDocumentFilter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/EndpointReferenceUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/ProblemAction.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/ProblemHeaderQName.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CAddressingConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CAddressingMetadataConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CWsaClientTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CWsaServerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WSEPRExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaActionUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaClientTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaPropertyBag.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaServerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelperImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/ActionNotSupportedException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/InvalidAddressingHeaderException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/MissingAddressingHeaderException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingFeatureConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPolicyMapConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPolicyValidator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPrefixMapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionAddressingConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaClientTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaServerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/ProblemAction.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/ProblemHeaderQName.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/WsaTubeHelperImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/BindingID.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/BindingIDFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/Cancelable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/Component.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentEx.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentRegistry.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentsFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/DistributedPropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/EndpointAddress.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureConstructor.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureListValidator.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureListValidatorAnnotation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ImpliesWebServiceFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/PropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ResourceLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/SOAPVersion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ServiceSharedFeatureMarker.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSBinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSDLLocator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSFeatureList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WebServiceFeatureFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/AddressingPropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/AddressingVersion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/EPRHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/NonAnonymousResponseProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/OneWayFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/OutboundReferenceParameterHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/WSEndpointReference.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ClientPipelineHook.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/SelectOptimalEncodingFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ServiceInterceptor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ServiceInterceptorFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ThrowableInPacketCompletionFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/WSPortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/EndpointCreationAttributes.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/ManagedEndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/Reconfigurable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagedClientAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagedServiceAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagementAssertion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/ClientCallBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/Databinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingConfig.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/EndpointCallBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/JavaCallInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/MappingInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/MetadataReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/SoapBodyStyle.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/WSDLGenInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/fastinfoset/FastInfosetFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ha/HaInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ha/StickyFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/handler/MessageHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/handler/MessageHandlerContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AddressingUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Attachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AttachmentEx.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AttachmentSet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/ExceptionHasMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/FilterMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Header.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/HeaderList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Headers.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Message.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageContextFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageHeaders.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageMetadata.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageWrapper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageWritable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/SuppressAutomaticWSARequestHeadersFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJMessageHeaders.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SaajStaxWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/InputStreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/StreamBasedMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/XMLStreamReaderMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/CheckedException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/ExceptionType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/JavaMethod.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/MEP.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/Parameter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/ParameterBinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/SEIModel.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/WSDLOperationMapping.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/soap/SOAPBinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLDescriptorKind.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFeaturedObject.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLInput.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLObject.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPart.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPartDescriptor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ClientPipeAssemblerContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ClientTubeAssemblerContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Codecs.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ContentType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Engine.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Fiber.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/NextAction.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Pipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipeCloner.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipelineAssembler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipelineAssemblerFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/SOAPBindingCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ServerPipeAssemblerContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ServerTubeAssemblerContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/StreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Stubs.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/SyncStartForAsyncFeature.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ThrowableContainerPropertySet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TransportPipeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TransportTubeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Tube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubeCloner.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubelineAssembler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubelineAssemblerFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterPipeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterTubeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractPipeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractTubeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/PipeAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/AlternativeSelector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelTranslator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelUnmarshaller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/PolicyResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/PolicyResolverFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/SourceModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ValidationProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/subject/BindingSubject.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractServerAsyncTransport.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Adapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AsyncProvider.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AsyncProviderCallback.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/BoundEndpoint.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ContainerResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/DocumentAddressResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointAwareCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointComponent.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointData.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointReferenceExtensionContributor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/HttpEndpoint.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolverAnnotation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Invoker.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/LazyMOMProvider.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Module.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/PortAddressResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ProviderInvokerTubeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ResourceInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocument.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocumentFilter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ServerPipelineHook.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ServiceDefinition.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/TransportBackChannel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WSEndpoint.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WSWebServiceContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WebModule.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WebServiceContextDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/MetaDataResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/MetadataResolverFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/PolicyWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/ServiceDescriptor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/XMLEntityResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGenExtnContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/DefaultClientTubelineAssemblyContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/DefaultServerTubelineAssemblyContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigLoader.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigName.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigNameImpl.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroTubelineAssembler.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubeCreator.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubelineAssemblyContextImpl.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubelineAssemblyController.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/ClientTubelineAssemblyContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/ServerTubelineAssemblyContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyContext.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyContextUpdater.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyDecorator.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/AddressingTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/BasicTransportTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/HandlerTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/MonitoringTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/MustUnderstandTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/TerminalTubeFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/ValidationTubeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/BindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/FeatureListUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/HTTPBindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/SOAPBindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/AsyncInvoker.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/AsyncResponseImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/BindingProviderProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientContainer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientTransportException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ContentNegotiation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/HandlerConfiguration.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/HandlerConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/RequestContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ResponseContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ResponseContextReceiver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SCAnnotations.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SEIPortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SenderException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DataSourceDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/JAXBDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/MessageDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/PacketDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/RESTSourceDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/SOAPMessageDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/SOAPSourceDispatch.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/AsyncMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/BodyBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/CallbackMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MessageFiller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/PollingMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ResponseBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/StubAsyncHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/StubHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueGetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueGetterFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueSetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueSetterFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/pacakge-info.java + src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementAssertionCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementPolicyValidator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementPrefixMapper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/config/metro/dev/FeatureReader.java + src/share/jaxws_classes/com/sun/xml/internal/ws/config/metro/util/ParserUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingProviderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/BridgeWrapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextWrapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/MarshallerBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/RawAccessorWrapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/WrapperBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/BindingTypeFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/EPRRecipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/HttpConfigFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/JAXBContextFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/JAXWSProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressing.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressingFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionEndpointReference.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SchemaValidation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SchemaValidationFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/Serialization.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SerializationFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/ServerSideException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingAttachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingAttachmentFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/UsesJAXBContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/UsesJAXBContextFeature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/ValidationErrorHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/WSBindingProvider.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/package-info.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/LoggingDumpTube.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumping.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingFeature.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingTube.java + src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingTubeFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ContentType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ContentTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/DataHandlerDataSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/DataSourceStreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/HasEncoding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/HeaderTokenizer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ImageDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MIMEPartStreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MimeCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MimeMultipartParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ParameterList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/RootOnlyCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/SOAPBindingCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StringDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/SwACodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/XMLHTTPBindingCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/XmlDataContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetMIMETypes.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamReaderRecyclable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAP11Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAP12Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingPolicyValidator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingPrefixMapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/FastInfosetFeatureConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/MtomFeatureConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/MtomPolicyMapConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/SelectOptimalEncodingFeatureConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/DeserializationException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SOAP12Constants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SOAPConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SerializationException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SerializerConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/streaming/SOAP12NamespaceConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/streaming/SOAPNamespaceConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLPropertyBag.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/CodeType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/DetailType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ExceptionBean.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ReasonType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAP11Fault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAP12Fault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ServerSOAPFaultException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SubcodeType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/TextType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientLogicalHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientMessageHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientSOAPHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerChainsModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/LogicalMessageContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/LogicalMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageHandlerContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageUpdatableContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/PortInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/SOAPHandlerProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/SOAPMessageContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerLogicalHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerMessageHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerSOAPHandlerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/XMLHandlerProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractHeaderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AttachmentSetImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AttachmentUnmarshallerImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/ByteArrayAttachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DOMHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DOMMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DataHandlerAttachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/EmptyMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/FaultDetailHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/FaultMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/JAXBAttachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/MimeAttachmentSet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/PayloadElementSniffer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/ProblemActionHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/RelatesToHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/RootElementSniffer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/StringHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/XMLReaderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/AttachmentMarshallerImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBBridgeSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBDispatchMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/MarshallerBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/PayloadSourceMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/ProtocolSourceMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/SourceUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/OutboundStreamHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/PayloadStreamReaderMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamAttachment.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader11.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader12.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/AbstractSEIModelImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/AbstractWrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/CheckedExceptionImpl.java + src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/FieldSignature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/Injector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ParameterImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ReflectAnnotationReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModelerException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/SOAPSEIModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperParameter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/soap/SOAPBindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractFeaturedObjectImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractObjectImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLDirectProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartDescriptorImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java + src/share/jaxws_classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassAdapter.java + src/share/jaxws_classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerEndpointScope.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerMessageScope.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerOperationScope.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerServiceScope.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/DefaultPolicyResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyMapBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/SafePolicyReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/WSDLBoundFaultContainer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/spi/PolicyFeatureConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/spi/PolicyMapConfigurator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/ClientMUTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/MUTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/MessageCreationException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/ServerMUTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/VersionMismatchException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/xml/XMLMessageException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/AddressingMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/BindingApiMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ClientMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/DispatchMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/EncodingMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/HandlerMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/HttpserverMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ManagementMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ModelerMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/PolicyMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ProviderApiMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/SenderMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ServerMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/SoapMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/TubelineassemblyMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/UtilMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsdlmodelMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/XmlmessageMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_zh_TW.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/tubelineassembly.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_zh_TW.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/MetroConfig.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/ObjectFactory.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubeFactoryConfig.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubeFactoryList.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineDefinition.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineFeature.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineFeatureReader.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineMapping.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/Tubelines.java + src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/AbstractMultiInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/AbstractWebServiceContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/DefaultResourceInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/DraconianValidationErrorHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointAwareTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointMessageContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/InvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/MonitorBase.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/MonitorRootService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerPropertyConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerRtException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServiceDefinitionImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SingletonResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/UnsupportedMediaException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSDLGenResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointMOMProxy.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/AsyncProviderInvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/MessageProviderArgumentBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderArgumentsBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderEndpointModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderInvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/SOAPProviderArgumentBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/SyncProviderInvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/XMLProviderArgumentBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointArgumentsBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointResponseMessageBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointValueSetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/Invoker.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/InvokerSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/InvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/MessageFiller.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/SEIInvokerTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/TieHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/ValueGetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContextFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/DatabindingException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/DatabindingProvider.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/FieldGetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/FieldSetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/JAXBWrapperAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/MethodGetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/MethodSetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/OldBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyGetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyGetterBase.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertySetter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertySetterBase.java + src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/RepeatedElementBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/TypeInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperAccessor.java + src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperComposite.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/XMLBridge.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/Attributes.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/DOMStreamReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/MtomStreamWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/PrefixFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/PrefixFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/SourceReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/TidyXMLStreamReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLReaderException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/DeferredTransportPipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/Headers.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/DeploymentDescriptorParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapterList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpMetadataPublisher.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/ResourceLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/WSHTTPConnection.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransport.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpResponseProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/HttpEndpoint.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/PortableConnectionImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/PortableHttpHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerAdapterList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerContainer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/WSHttpHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ASCIIUtility.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ByteArrayBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ByteArrayDataSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/CompletedFuture.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Constants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/DOMUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/FastInfosetReflection.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/FastInfosetUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/HandlerAnnotationInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/InjectionPlan.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/JAXWSUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/MetadataUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NamespaceSupport.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NoCloseInputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NoCloseOutputStream.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Pool.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/QNameMap.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadAllStream.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadOnlyPropertyException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/RuntimeVersion.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ServiceConfigurationError.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ServiceFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/StreamUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/StringUtils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/UtilException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Version.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/VersionUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/exception/JAXWSExceptionBase.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/exception/LocatableWebServiceException.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizable.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableImpl.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessage.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessageFactory.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizer.java - src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/NullLocalizable.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/DumpTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/StandalonePipeAssembler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/StandaloneTubeAssembler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_de.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_es.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_fr.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_it.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_ja.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_ko.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_pt_BR.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_zh_CN.properties + src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/CDATA.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/ContentHandlerToXMLStreamWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/DummyLocation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamedNodeMapIterator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NodeListIterator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/StAXResult.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/StAXSource.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderFilter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToXMLStreamWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamWriterFilter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationSignature.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/DispatchException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/OperationDispatcher.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/SDDocumentResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/SOAPActionBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/WSDLOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/EntityResolverWrapper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/ErrorHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/InaccessibleWSDLException.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MIMEConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MexEntityResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/ParserUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/SOAPConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLConstants.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/DocumentLocationResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/TXWContentHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/UsingAddressing.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingMetadataWSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingWSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGeneratorExtensionFacade.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLPatcher.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Binding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/BindingOperationType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Definitions.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Documented.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Fault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/FaultType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Message.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/OpenAtts.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Operation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/ParamType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Part.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Port.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/PortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Service.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/StartWithExtensionsType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Types.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Address.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Binding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Operation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/Body.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/BodyType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/Header.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/HeaderFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPAddress.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPBinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/Body.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/BodyType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/Header.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/HeaderFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPAddress.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPBinding.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/package-info.java ! src/share/jaxws_classes/javax/annotation/Generated.java ! src/share/jaxws_classes/javax/annotation/PostConstruct.java ! src/share/jaxws_classes/javax/annotation/PreDestroy.java ! src/share/jaxws_classes/javax/annotation/Resource.java ! src/share/jaxws_classes/javax/annotation/Resources.java ! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java ! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java ! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java ! src/share/jaxws_classes/javax/xml/bind/Marshaller.java ! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlInlineBinaryData.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMimeType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/jaxws_classes/javax/xml/soap/AttachmentPart.java ! src/share/jaxws_classes/javax/xml/soap/Detail.java ! src/share/jaxws_classes/javax/xml/soap/DetailEntry.java ! src/share/jaxws_classes/javax/xml/soap/FactoryFinder.java ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeader.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeaders.java ! src/share/jaxws_classes/javax/xml/soap/Name.java ! src/share/jaxws_classes/javax/xml/soap/Node.java ! src/share/jaxws_classes/javax/xml/soap/SAAJMetaFactory.java ! src/share/jaxws_classes/javax/xml/soap/SAAJResult.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBody.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBodyElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnection.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnectionFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConstants.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElementFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPEnvelope.java ! src/share/jaxws_classes/javax/xml/soap/SOAPException.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFault.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFaultElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeader.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeaderElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPMessage.java ! src/share/jaxws_classes/javax/xml/soap/SOAPPart.java ! src/share/jaxws_classes/javax/xml/soap/Text.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceRefs.java ! src/share/jaxws_classes/javax/xml/ws/handler/Handler.java ! src/share/jaxws_classes/javax/xml/ws/soap/AddressingFeature.java ! src/share/jaxws_classes/javax/xml/ws/soap/MTOMFeature.java ! src/share/jaxws_classes/javax/xml/ws/spi/FactoryFinder.java ! src/share/jaxws_classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java From Lance.Andersen at oracle.com Tue Apr 9 14:55:47 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 9 Apr 2013 10:55:47 -0400 Subject: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans Message-ID: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com> Hi, This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ Best lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From alan.bateman at oracle.com Tue Apr 9 14:54:43 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 09 Apr 2013 14:54:43 +0000 Subject: hg: jdk8/tl/jdk: 8010393: Update JAX-WS RI to 2.2.9-b12941 Message-ID: <20130409145502.C83F34817C@hg.openjdk.java.net> Changeset: 57e9eaeca323 Author: alanb Date: 2013-04-09 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57e9eaeca323 8010393: Update JAX-WS RI to 2.2.9-b12941 Reviewed-by: mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows From xueming.shen at oracle.com Tue Apr 9 15:08:35 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Apr 2013 08:08:35 -0700 Subject: ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <516402F8.5020302@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> Message-ID: <51642EF3.1040701@oracle.com> On 4/9/13 5:00 AM, David Holmes wrote: > I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar > file or not; if not then it should not be built using CreateJars.gmk > and shouldn't listed on the JAR variables in profile-includes.txt tzdb.dat now is NOT a jar file for performance (decompression slows down startup). So which gmk file is the best fit for this kind of "file building"? We may be able to update it to the appropriate place with a follow up push. -Sherman > > David > > On 9/04/2013 5:51 AM, Xueming Shen wrote: >> Hi, >> >> JSR 310 has continued to refine and update the java.time API. >> Please help review the proposed changeset as showed in webrev: >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> In addition to general javadoc improvements, the changes include: >> >> java.time >> >> * Duration - added a static from(temporalAmount) method to simplify >> conversions from other amounts >> * Renamed the toString(Formatter) method to format(Formatter) in all >> classes >> * Period - added a static from(temporalAmount) method to simplify >> conversions >> * ZoneId - >> - Added getAvailableZoneIds method, a simpler mechanism than going >> to the provider >> - Added normalized() method to ease conversion to a fixed offset >> - renamed predefined static fields of timezone names >> >> java.time.chrono >> >> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >> - changed xxx_COMPARATORs to static methods returning the Time Line >> Order comparators >> - Added a from(TemporalAcessor) method to ease conversions >> * Chronology >> - Added method to create a Date from EpochDay (And in each >> calendar subclass) >> - Added resolveDate to allow resolving date components by the >> Chronology >> - Serialization fixes >> - Replaced raw return types with wildcard type >> * Era >> - Removed factory methods and getChronology - they did not work >> correctly in all cases >> - Declared Era as a functional interface >> * Hijrah calendar variations - >> - Supporting the Umm alQura calendar >> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >> making the enums public >> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >> to return the concrete Era type. >> >> java.time.format >> >> * DateTimeFormatter - >> - Added fields for the predefined formatters >> (moved from DateTimeFormatters class) >> - Updated patterns to be CLDR compatible >> - Moved documentation for the pattern letters to the class javadoc >> - Added support for Zone default and conversion >> * DateTimeFormatterBuilder >> - Updated documentation of patterns and corresponding equivalents >> to builder methods. >> - Added a method to append the localized offset. >> >> java.time.temporal >> >> * Adjusters - class removed; all static adjusters moved to static >> methods >> in TemporalAdjuster >> * ChronoField - >> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >> - Added getDisplayName - for locale specific field name >> * Queries - class removed; all static query method moved to static >> methods >> in TemporalQuery >> * TemporalField - added getDisplayName method >> * UnsupportedTemporalTypeException - new subtype of DateTimeException >> to reflect no support for a unit or field >> * WeekFields - Added fields for week and year of week-Based-Years to >> match >> CLDR fields "Y", "W" From Ulf.Zibis at CoSoCo.de Tue Apr 9 15:26:07 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 09 Apr 2013 17:26:07 +0200 Subject: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans In-Reply-To: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com> References: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com> Message-ID: <5164330F.3010604@CoSoCo.de> Hi, there is a little indentation error in build.xml in line 42. -Ulf Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle: > Hi, > > This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc > > As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 > > The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ > > Best > lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From Lance.Andersen at oracle.com Tue Apr 9 15:58:39 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 9 Apr 2013 11:58:39 -0400 Subject: review request: 8011620 adding free form netbeans project for jdbc to jdk/make/netbeans In-Reply-To: <5164330F.3010604@CoSoCo.de> References: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com> <5164330F.3010604@CoSoCo.de> Message-ID: Thank you ulf, I made the change in my workspace so that it will be accommodated as part of the putback Best Lance On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote: > Hi, > > there is a little indentation error in build.xml in line 42. > > -Ulf > > Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle: >> Hi, >> >> This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc >> >> As part of this change, I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8 >> >> The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/ >> >> Best >> lance >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From zhong.j.yu at gmail.com Tue Apr 9 16:30:26 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 9 Apr 2013 11:30:26 -0500 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? In-Reply-To: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> References: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> Message-ID: On Mon, Apr 8, 2013 at 6:54 PM, Steven Schlansker < stevenschlansker at gmail.com> wrote: > Today I encountered "java.lang.IllegalArgumentException: Self-suppression > not permitted" from Throwable.addSuppressed. > > My first surprise is that the try-with-resources block can throw this > exception; it is very confusing to have auto-generated code throw > exceptions. But beyond that, it is impossible to figure out *which* > exception caused the problem. If you have multiple resources acquired in > the try-with-resources, it could be any of them. > > Would it be reasonable to change > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > > to > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, > this); > > so that when you get this exception it at least points to one of the throw > sites that actually caused the problem? Otherwise the only stack trace you > have is in auto-generated code and you are left scratching your head, > wondering where it came from. I believe this would increase the > debuggability of the try-with-resources construct and there's no > immediately obvious downside. > > I'm not the only one who was confused by this behavior: > > http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co > > > Reusing exception is probably not a good idea - unless the exception is immutable, i.e. enableSuppression=writableStackTrace=true. Interestingly, even for an immutable exception, `e.addSuppressed(e)` isn't allowed. I think that it should be allowed. Zhong Yu From chris.hegarty at oracle.com Tue Apr 9 16:30:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 09 Apr 2013 16:30:34 +0000 Subject: hg: jdk8/tl/jdk: 8005696: Add CompletableFuture Message-ID: <20130409163047.BA1434817F@hg.openjdk.java.net> Changeset: 50bc8e085a09 Author: chegar Date: 2013-04-09 17:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50bc8e085a09 8005696: Add CompletableFuture Reviewed-by: chegar, martin ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CompletableFuture.java + src/share/classes/java/util/concurrent/CompletionException.java + test/java/util/concurrent/CompletableFuture/Basic.java From stevenschlansker at gmail.com Tue Apr 9 16:54:34 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 9 Apr 2013 09:54:34 -0700 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? In-Reply-To: References: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> Message-ID: <54AC68B4-C1A6-4F6B-84A2-C5C9B6F6F3B1@gmail.com> On Apr 9, 2013, at 9:30 AM, Zhong Yu wrote: > > > > On Mon, Apr 8, 2013 at 6:54 PM, Steven Schlansker wrote: > Today I encountered "java.lang.IllegalArgumentException: Self-suppression not permitted" from Throwable.addSuppressed. > > My first surprise is that the try-with-resources block can throw this exception; it is very confusing to have auto-generated code throw exceptions. But beyond that, it is impossible to figure out *which* exception caused the problem. If you have multiple resources acquired in the try-with-resources, it could be any of them. > > Would it be reasonable to change > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > > to > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, this); > > so that when you get this exception it at least points to one of the throw sites that actually caused the problem? Otherwise the only stack trace you have is in auto-generated code and you are left scratching your head, wondering where it came from. I believe this would increase the debuggability of the try-with-resources construct and there's no immediately obvious downside. > > I'm not the only one who was confused by this behavior: > http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co > > > Reusing exception is probably not a good idea - unless the exception is immutable, i.e. enableSuppression=writableStackTrace=true. > I agree, but there is (library) code out there that does this -- the code that caused the problem wasn't even mine. My suggestion has no cost unless you happen to trigger it, and then it helps you find who is causing trouble. > Interestingly, even for an immutable exception, `e.addSuppressed(e)` isn't allowed. I think that it should be allowed. > > Zhong Yu From james.graham at oracle.com Tue Apr 9 17:14:23 2013 From: james.graham at oracle.com (Jim Graham) Date: Tue, 09 Apr 2013 10:14:23 -0700 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: Message-ID: <51644C6F.1070404@oracle.com> Hi Laurent, Quick questions - which benchmarks were run before/after? I see a lot of benchmark running in your Pisces improvement thread, but but none here. Also, this should be tested on multiple platforms, preferably Linux, Windows and Mac to see how it is affected by differences in the platform runtimes and threading (hopefully minimal). Finally, Hotspot is supposed to deal very well for small thread-local allocations like the int[4] and Rectangle2D that you optimized. Was it necessary to cache those at all? I'm sure the statistics for the allocations show up in a memory profile, but that doesn't mean it is costing us anything - ideally such small allocations are as fast as free and having to deal with caching them in a context will actually lose performance. It may be that the tile caching saved enough that it might have masked unnecessary or detrimental changes for the smaller objects... ...jim On 4/5/2013 5:20 AM, Laurent Bourg?s wrote: > Dear java2d members, > > I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage: > - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile() > - excessive memory usage (byte[] for tile, int[] and rectangle): at each call to renderPath / renderTiles, several small objects are created (never cached) that leads to hundreds megabytes that GC must deal with > > Here are profiling screenshots: > - 4 threads drawing on their own buffered image (MapBench test): > http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png > > - excessive int[] / Rectangle creation: > http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png > http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png > > Here is the proposed patch: > http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/ > > I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max). > As its memory footprint is very small, I recommend using ThreadLocal. > > Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ? > > Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ? > I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache ) > > Regards, > Laurent From bourges.laurent at gmail.com Tue Apr 9 17:34:48 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 9 Apr 2013 19:34:48 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <51644C6F.1070404@oracle.com> References: <51644C6F.1070404@oracle.com> Message-ID: Dear Jim, I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated ! The main question is: how to know how GC / hotspot deals with such small allocations ? Is there any JVM flag to enable to see real allocations as does jmap -histo. > > Quick questions - which benchmarks were run before/after? I see a lot of > benchmark running in your Pisces improvement thread, but but none here. > Agreed; I can try running j2dBench on this fix only. I generally run Andrea's MapBench as I appeared more complex and using multiple threads. > Also, this should be tested on multiple platforms, preferably Linux, > Windows and Mac to see how it is affected by differences in the platform > runtimes and threading (hopefully minimal). > It appears more difficult for me: I can use at work a mac 10.8 and I can run Windows XP within virtual box (but it is not very representative). Don't you have at oracle any test platform to perform such tests / benchmark ? > Finally, Hotspot is supposed to deal very well for small thread-local > allocations like the int[4] and Rectangle2D that you optimized. Was it > necessary to cache those at all? I'm sure the statistics for the > allocations show up in a memory profile, but that doesn't mean it is > costing us anything - ideally such small allocations are as fast as free > and having to deal with caching them in a context will actually lose > performance. It may be that the tile caching saved enough that it might > have masked unnecessary or detrimental changes for the smaller objects... I repeat my question: how can I know at runtime how hotspot optimizes AAShapePipe code (allocations ...) ? Does hotspot can do stack allocation ? is it explained somewhere (allocation size threshold) ? Maybe verbose:gc output may help ? Finally I spent a lot of time on pisces renderer and running MapBench to show performance gains. Thanks for your interesting feedback, Laurent On 4/5/2013 5:20 AM, Laurent Bourg?s wrote: > Dear java2d members, > > I figured out some troubles in java2d.pipe.AAShapePipe related to both > concurrency & memory usage: > - concurrency issue related to static theTile field: only 1 tile is cached > so a new byte[] is created for other threads at each call to renderTile() > - excessive memory usage (byte[] for tile, int[] and rectangle): at each > call to renderPath / renderTiles, several small objects are created (never > cached) that leads to hundreds megabytes that GC must deal with > > Here are profiling screenshots: > - 4 threads drawing on their own buffered image (MapBench test): > http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**byte_tile.png > > - excessive int[] / Rectangle creation: > http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**int_bbox.png > http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_** > rectangle_bbox.png > > Here is the proposed patch: > http://jmmc.fr/~bourgesl/**share/AAShapePipe/webrev-1/ > > I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue > (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K > max). > As its memory footprint is very small, I recommend using ThreadLocal. > > Is it necessary to use Soft/Weak reference to avoid excessive memory usage > for such cache ? > > Is there any class dedicated to such cache (ThreadLocal with cache > eviction or ConcurrentLinkedQueue using WeakReference ?) ? > I think it could be very useful at the JDK level to have such feature (ie > a generic "GC friendly"cache ) > > Regards, > Laurent > From james.graham at oracle.com Tue Apr 9 17:44:43 2013 From: james.graham at oracle.com (Jim Graham) Date: Tue, 09 Apr 2013 10:44:43 -0700 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> Message-ID: <5164538B.9080804@oracle.com> Hi Laurent, The allocations will always show up on a heap profiler, I don't know of any way of having them not show up if they are stack allocated, but I don't think that stack allocation is the issue here - small allocations come out of a fast generation that costs almost nothing to allocate from and nearly nothing to clean up. They are actually getting allocated and GC'd, but the process is optimized. The only way to tell is to benchmark and see which changes make a difference and which are in the noise (or, in some odd counter-intuitive cases, counter-productive)... ...jim On 4/9/2013 10:34 AM, Laurent Bourg?s wrote: > Dear Jim, > > I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated ! > > The main question is: how to know how GC / hotspot deals with such small allocations ? Is there any JVM flag to enable to see real allocations as does jmap -histo. > > > Quick questions - which benchmarks were run before/after? I see a lot of benchmark running in your Pisces improvement thread, but but none here. > > > Agreed; I can try running j2dBench on this fix only. I generally run Andrea's MapBench as I appeared more complex and using multiple threads. > > Also, this should be tested on multiple platforms, preferably Linux, Windows and Mac to see how it is affected by differences in the platform runtimes and threading (hopefully minimal). > > > It appears more difficult for me: I can use at work a mac 10.8 and I can run Windows XP within virtual box (but it is not very representative). > > Don't you have at oracle any test platform to perform such tests / benchmark ? > > Finally, Hotspot is supposed to deal very well for small thread-local allocations like the int[4] and Rectangle2D that you optimized. Was it necessary to cache those at all? I'm sure the statistics for the allocations show up in a memory profile, but that doesn't mean it is costing us anything - ideally such small allocations are as fast as free and having to deal with caching them in a context will actually lose performance. It may be that the tile caching saved enough that it might have masked unnecessary or detrimental changes for the smaller objects... > > > I repeat my question: how can I know at runtime how hotspot optimizes AAShapePipe code (allocations ...) ? Does hotspot can do stack allocation ? is it explained somewhere (allocation size threshold) ? > > Maybe verbose:gc output may help ? > > Finally I spent a lot of time on pisces renderer and running MapBench to show performance gains. > > Thanks for your interesting feedback, > > Laurent > > On 4/5/2013 5:20 AM, Laurent Bourg?s wrote: > > Dear java2d members, > > I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage: > - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile() > - excessive memory usage (byte[] for tile, int[] and rectangle): at each call to renderPath / renderTiles, several small objects are created (never cached) that leads to hundreds megabytes that GC must deal with > > Here are profiling screenshots: > - 4 threads drawing on their own buffered image (MapBench test): > http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___byte_tile.png > > - excessive int[] / Rectangle creation: > http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___int_bbox.png > http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___rectangle_bbox.png > > Here is the proposed patch: > http://jmmc.fr/~bourgesl/__share/AAShapePipe/webrev-1/ > > I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max). > As its memory footprint is very small, I recommend using ThreadLocal. > > Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ? > > Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ? > I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache ) > > Regards, > Laurent > > From mandy.chung at oracle.com Tue Apr 9 21:10:40 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 09 Apr 2013 14:10:40 -0700 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> Message-ID: <516483D0.2080404@oracle.com> On 4/9/13 12:37 AM, Laurent Bourg?s wrote: > Mandy, > > first I would like to have the given patch applied to OpenJDK 8 (+ > JDK7u) as it fixes many problems: > - string concatenations > - object creations (Object[] or other objects given as params) > - method calls in log statements > This is the patch you refer to: http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ I agree that we should separate the fix to reduce the memory usage from the fix to convert JUL to PlatformLogger. I skimmed on your patch - awt/swing uses PlatformLogger and your change looks fine. You have also got Anthony's approval. Other component security, jmx, snmp, etc are using JUL. I would suggest to fix the use of PlatformLogger in your first patch and AWT/Swing is the main area that 8010297 is concerned about so that you can resolve 8010297 soon. If you want to move ahead to fix use of JUL, you can send your patch to serviceability-dev at openjdk.java.net and security-dev at openjdk.java.net for the other areas to review and sponsor. Hope this helps. Mandy > In a second step, I can help somebody migrating JUL usages to > PlatformLogger but it requires PlatformLogger API changes (logp to > give class and method names)... > > Other comments below: > > > Peter's idea is a good one to add a couple of convenient methods > to take Object parameters that will avoid the creation of array > instances. I'd also like to know what variants being used in the > jdk to determine the pros and cons of the alternatives (this issue > also applies to java.util.logging). > > > 50% of given object parameters are created via method calls so it will > not be enough. > > Moreover, I prefer having always isLoggable() calls to avoid me > looking and understanding special cases (more than 2 args or no string > concat ...); besides, it would be easier to implement code checks > testing missing isLoggable() calls vs conditional and specific checks > (string concat, more then 2 args, method calls ...) > > Finally, I prefer having shorter and clearer method names like > isFine(), isFinest() instead of isLoggable(PlatformLogger.FINE) that > is quite "ugly" ... > > It was intentional to have PlatformLogger define only the useful > methods necessary for jdk use. The goal of PlatformLogger was to > provide a light-weight utility for jdk to log debugging messages > and eliminate the dependency to java.util.logging and avoid the > unnecessary j.u.logging initialization (as disabled by default). > It was not a goal for PlatformLogger to be an exact mirror as > java.util.logging.Logger. My advice is to tune PlatformLogger to > provide API that helps the platform implementation while avoid > bloating the API. > > > Agreed. > > Maybe JUL Logger.logp(classname, methodname) usages should be > rewritten to use PlatformLogger.getCallerInfo() instead: > // Returns the caller's class and method's name; best effort > // if cannot infer, return the logger's name. > private String getCallerInfo() { > String sourceClassName = null; > String sourceMethodName = null; > > * JavaLangAccess access = SharedSecrets.getJavaLangAccess(); > * Throwable throwable = new Throwable(); > int depth = access.getStackTraceDepth(throwable); > > String logClassName = "sun.util.logging.PlatformLogger"; > boolean lookingForLogger = true; > for (int ix = 0; ix < depth; ix++) { > // Calling getStackTraceElement directly prevents the VM > // from paying the cost of building the entire stack > frame. > StackTraceElement frame = > access.getStackTraceElement(throwable, ix); > String cname = frame.getClassName(); > if (lookingForLogger) { > // Skip all frames until we have found the first > logger frame. > if (cname.equals(logClassName)) { > lookingForLogger = false; > } > } else { > if (!cname.equals(logClassName)) { > // We've found the relevant frame. > sourceClassName = cname; > sourceMethodName = frame.getMethodName(); > break; > } > } > } > > if (sourceClassName != null) { > return sourceClassName + " " + sourceMethodName; > } else { > return name; > } > } > } > > > Since you are touching some jdk files that use java.util.logging, > would you like to contribute to convert them to use PlatformLogger: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233 > > It's perfectly fine to convert only some of them if not all. > > > I want to help but as you said it should be done in collaboration > because it requires API changes (JMX, RMI ...) but I prefer after this > patch is reviewed and submitted and in coming weeks. > > > Jim Gish is the owner of logging and will check with him if he has > cycles to work with you on this. > > > Great. > > Cheers, > Laurent > From joe.darcy at oracle.com Tue Apr 9 21:12:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 09 Apr 2013 14:12:36 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) Message-ID: <51648444.2010808@oracle.com> Hello, Please review my changes for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) http://cr.openjdk.java.net/~darcy/8011800.0/ which add a new method to java.util.Objects to take a Supplier rather than a String. Patch inline below. Thanks, -Joe --- old/src/share/classes/java/util/Objects.java 2013-04-09 14:08:34.000000000 -0700 +++ new/src/share/classes/java/util/Objects.java 2013-04-09 14:08:33.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,6 +25,8 @@ package java.util; +import java.util.function.Supplier; + /** * This class consists of {@code static} utility methods for operating * on objects. These utilities include {@code null}-safe or {@code @@ -226,4 +228,31 @@ throw new NullPointerException(message); return obj; } + + /** + * Checks that the specified object reference is not {@code null} and + * throws a customized {@link NullPointerException} if it is. + * + *

Compared to the sibling method {@link requireNonNull(Object, + * String}, this methods allows creation of the message to be + * deferred until after the null check is made. Note that if the + * supplier is provided via a lambda expression, there can be an + * overhead involved in creating the supplier. Therefore, while + * this method may confer a net performance advantage in the + * non-null case, it is most likely to do so if creating the + * message string is expensive. + * + * @param obj the object reference to check for nullity + * @param messageSupplier supplier of the detail message to be + * used in the event that a {@code NullPointerException} is thrown + * @param the type of the reference + * @return {@code obj} if not {@code null} + * @throws NullPointerException if {@code obj} is {@code null} + * @since 1.8 + */ + public static T requireNonNull(T obj, Supplier messageSupplier) { + if (obj == null) + throw new NullPointerException(messageSupplier.get()); + return obj; + } } --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,7 +23,7 @@ /* * @test - * @bug 6797535 6889858 6891113 + * @bug 6797535 6889858 6891113 8011800 * @summary Basic tests for methods in java.util.Objects * @author Joseph D. Darcy */ @@ -166,17 +166,17 @@ try { s = Objects.requireNonNull("pants"); if (s != "pants") { - System.err.printf("1-arg non-null failed to return its arg"); + System.err.printf("1-arg requireNonNull failed to return its arg"); errors++; } } catch (NullPointerException e) { - System.err.printf("1-arg nonNull threw unexpected NPE"); + System.err.printf("1-arg requireNonNull threw unexpected NPE"); errors++; } try { s = Objects.requireNonNull(null); - System.err.printf("1-arg nonNull failed to throw NPE"); + System.err.printf("1-arg requireNonNull failed to throw NPE"); errors++; } catch (NullPointerException e) { // Expected @@ -186,17 +186,40 @@ try { s = Objects.requireNonNull("pants", "trousers"); if (s != "pants") { - System.err.printf("2-arg nonNull failed to return its arg"); + System.err.printf("2-arg requireNonNull failed to return its arg"); errors++; } } catch (NullPointerException e) { - System.err.printf("2-arg nonNull threw unexpected NPE"); + System.err.printf("2-arg requireNonNull threw unexpected NPE"); errors++; } try { s = Objects.requireNonNull(null, "pantaloons"); - System.err.printf("2-arg nonNull failed to throw NPE"); + System.err.printf("2-arg requireNonNull failed to throw NPE"); + errors++; + } catch (NullPointerException e) { + if (e.getMessage() != "pantaloons") { + System.err.printf("2-arg requireNonNull threw NPE w/ bad detail msg"); + errors++; + } + } + + // Test supplier rvariant + try { + s = Objects.requireNonNull("pants", () -> "trousers"); + if (s != "pants") { + System.err.printf("Supplier requireNonNull failed to return its arg"); + errors++; + } + } catch (NullPointerException e) { + System.err.printf("Supplier nonNull threw unexpected NPE"); + errors++; + } + + try { + s = Objects.requireNonNull(null, () -> "pantaloons"); + System.err.printf("Suppiler requireNonNull failed to throw NPE"); errors++; } catch (NullPointerException e) { if (e.getMessage() != "pantaloons") { From bhavesh.x.patel at oracle.com Tue Apr 9 22:42:02 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Tue, 09 Apr 2013 22:42:02 +0000 Subject: hg: jdk8/tl/langtools: 8005091: javadoc should be able to return the receiver type Message-ID: <20130409224206.2B19D48196@hg.openjdk.java.net> Changeset: eb134c8e931d Author: bpatel Date: 2013-04-09 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/eb134c8e931d 8005091: javadoc should be able to return the receiver type Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java + test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassExtends.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassParameters.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodReturnType.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodTypeParameters.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Parameters.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Receivers.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Throws.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/TypeParameters.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Varargs.java + test/com/sun/javadoc/testTypeAnnotations/typeannos/Wildcards.java From mike.duigou at oracle.com Tue Apr 9 23:07:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 9 Apr 2013 16:07:21 -0700 Subject: RFR : 8010948 : Add conversion functional interfaces In-Reply-To: <968AAA46-6AAE-4113-9CED-448F3E86EA6A@oracle.com> References: <968AAA46-6AAE-4113-9CED-448F3E86EA6A@oracle.com> Message-ID: <6A3CDB0E-038F-415F-980C-9BEBA5B4C34A@oracle.com> Any further comment on these? Technically they are adequately reviewed as I have reviewed them and am submitting them on behalf of Brian Goetz. I would prefer to know that at least one other set of eyes has looked at them though. Mike On Apr 3 2013, at 17:00 , Mike Duigou wrote: > Hello all; > > Another set of functional interfaces for review for the soon-to-be-arriving-in-TL-repo lambda libraries. > > http://cr.openjdk.java.net/~mduigou/JDK-8010948/0/webrev/ > > These interfaces are Functions between the core primitive types (double, int, long) used by the lambda libraries. Methods providing the equivalent of the widening and narrowing primitive conversions may be added in a later patch. > > Mike From pbenedict at apache.org Tue Apr 9 23:10:46 2013 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 9 Apr 2013 18:10:46 -0500 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) Message-ID: If obj is null and the supplier is also null, you will not get an NPE with the expected message. Since it's kind of odd to get an NPE constructing an NPE, I think: @throws NullPointerException if {@code obj} is {@code null} should be changed to: @throws NullPointerException if {@code obj} or {@code supplier} are {@code null} From pbenedict at apache.org Tue Apr 9 23:14:48 2013 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 9 Apr 2013 18:14:48 -0500 Subject: RFR : 8010948 : Add conversion functional interfaces Message-ID: Mike, It would be nice if the class javadocs would have @see tags to classes in the same family. For example, DoubleToIntFunction could have a @see to DoubleToLongFunction, etc. This way a developer viewing of one class can easily figure out which close cousins exist. Paul From david.holmes at oracle.com Tue Apr 9 23:14:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 09:14:52 +1000 Subject: Scope modifiers in interfaces [was Default methods on Map] In-Reply-To: References: <51640236.4080003@oracle.com> Message-ID: <5164A0EC.9050905@oracle.com> On 9/04/2013 10:28 PM, Stephen Colebourne wrote: > While I disagree with the choice made (one of Java's strengths is a > little bit of extra verbosity), I am happy if it is consistent. Based > on the links I provided, clearly Project Lambda has a long way to go > to meet that consistency, so it clearly hasn't been a firm > recommendation up until now. The examples you gave have all been fixed within the last couple of weeks. If you still see some please point them out but my searching shows that the only use of "public default" in the lambda repos is from java.time and: ./share/classes/java/security/Principal.java: public default boolean implies(Subject subject) { ./share/classes/java/security/KeyStore.java: public default Set getAttributes() { ./share/classes/javax/security/auth/Destroyable.java: public default void destroy() throws DestroyFailedException { ./share/classes/javax/security/auth/Destroyable.java: public default boolean isDestroyed() { > java.time will of course be adapted to match. Terrific. Thanks, David > > Stephen > > > On 9 April 2013 12:57, David Holmes wrote: >> All of the lambda-related work has now moved (or is moving) to #1. No public >> on interface methods as has been the recommendation since day one. >> >>> I find this inconsistency troubling. Its time for a firm >>> recommendation to be made as to Oracle's preferred coding standard. >> >> >> I agree because I see that java.time is using #2. >> >> >>> I'm of the opinion that moving code to #3, explicit use of "public" >>> will serve Java better in the long run. I find #1 particularly >>> troubling, as it means a default method (which looks very like a >>> normal method) looks like it is package scoped when I read the source >>> code. >> >> >> If/when non-public methods are allowed in interfaces then we should probably >> make things explicit, in my opinion. I don't find anything troubling about >> not having public of interface methods - default or abstract. >> >> David >> ----- >> >> >>> (this affects the Map changes webrev) >>> Stephen >>> >>> >>> >>> On 8 April 2013 19:07, Mike Duigou wrote: >>>> >>>> Hello all; >>>> >>>> This is a combined review for the new default methods on the >>>> java.util.Map interface being added for the JSR-335 lambda libraries. The >>>> reviews are being combined because they share a common unit test. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>> >>>> 8004518: Add in-place operations to Map >>>> forEach() >>>> replaceAll() >>>> >>>> 8010122: Add atomic operations to Map >>>> getOrDefault() >>>> putIfAbsent() * >>>> remove(K, V) >>>> replace(K, V) >>>> replace(K, V, V) >>>> compute() * >>>> merge() * >>>> computeIfAbsent() * >>>> computeIfPresent() * >>>> >>>> The * operations treat null values as being absent. (ie. the same as >>>> there being no mapping for the specified key). >>>> >>>> The default implementations provided in Map are overridden in HashMap for >>>> performance purposes, in Hashtable for atomicity and performance purposes >>>> and in Collections for atomicity. >>>> >>>> Mike >>>> >> From mike.duigou at oracle.com Tue Apr 9 23:55:53 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 9 Apr 2013 16:55:53 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <5162BD9E.2050803@oracle.com> Message-ID: <9FAFC88F-1FF1-4ED9-BEE2-2F0D8E2EFA42@oracle.com> On Apr 8 2013, at 16:03 , Martin Buchholz wrote: > Style: spaces around "=" > + private static final int DEFAULT_CAPACITY= 10; I apologize for these minor style problems in this and my other patches. I am really loathe to run any kind of automated source reformatting tool on JDK source. Unfortunately there are a variety of styles sued within the JDK sources and the value of having minimal diffs is too great to contemplate global restyling. I am happy to correct any style or other errors I make and don't notice myself. > --- > > It's a matter of taste whether to remove the temp var oldCapacity. I believe it was coded intentionally. > public void trimToSize() { > modCount++; > - int oldCapacity = elementData.length; > - if (size < oldCapacity) { > + if (size < elementData.length) { > elementData = Arrays.copyOf(elementData, size); > } I assumed that oldCapacity was a remnant of a previous implementation prior to the introduction of Arrays.copyOf(). It didn't seem to be worth retaining even for explanatory value. > --- > > Because "threshold" is a serialized field, its javadoc is part of the public interface of this class, and hence cannot refer to implementation details like EMPTY_TABLE. > 161 /** > 162 * The next size value at which to resize (capacity * load factor). If > 163 * table == EMPTY_TABLE then this is the initial capacity at which the > 164 * table will be created when inflated. > 165 * @serial > 166 */ > 167 int threshold; > http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.HashMap > > > --- > > Consider making roundUpToPowerOf2 public. I assume you mean as part of some utility class like Integer? Reasonable and increases the chances that some VM engineer will come along and optimize it. Not sure what should be done about negative numbers. This likely comes too late for Java 8 though. (I know I probably don't have time). > > Best Implementation is not obvious. I would probably write a loop with core > x = x & (x - 1) > until get to zero. > 274 private static int roundUpToPowerOf2(int number) { > 275 int rounded = number >= MAXIMUM_CAPACITY > 276 ? MAXIMUM_CAPACITY > 277 : (rounded = Integer.highestOneBit(number)) != 0 > 278 ? (Integer.bitCount(number) > 1) ? rounded << 1 : rounded > 279 : 1; > 280 > 281 return rounded; > 282 } The Integer operations are Hotspot intrinsics. This version is coded so that there are no loops. The previous looping implementation was criticized in an earlier review. It may be better to convert this to the Hacker's Delight 3-3 implementation From david.holmes at oracle.com Wed Apr 10 00:13:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 10:13:49 +1000 Subject: ReviewRequest 8011172: JJSR 310: DateTime API Updates II, In-Reply-To: <51642EF3.1040701@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> Message-ID: <5164AEBD.1070003@oracle.com> Hi Sherman, On 10/04/2013 1:08 AM, Xueming Shen wrote: > On 4/9/13 5:00 AM, David Holmes wrote: >> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >> file or not; if not then it should not be built using CreateJars.gmk >> and shouldn't listed on the JAR variables in profile-includes.txt > > tzdb.dat now is NOT a jar file for performance (decompression slows down > startup). So which gmk file is the best fit for this kind of "file building"? We > may be able to update it to the appropriate place with a follow up push. So given it is no longer a jar file, the target in the CreateJars.gmk $(IMAGES_OUTPUTDIR)/lib/tzdb.dat: $(JDK_OUTPUTDIR)/lib/tzdb.dat $(install-file) should not be needed. The generic copying routine in Images.gmk: # Find all files to copy from $(JDK_OUTPUTDIR)/lib # Jar files are not expected to be here ALL_JDKOUT_LIB_LIST := $(call not-containing,_the.,$(filter-out %.jar,\ $(call CacheFind,$(JDK_OUTPUTDIR)/lib))) should now pick it up by default. David > -Sherman > >> >> David >> >> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>> Hi, >>> >>> JSR 310 has continued to refine and update the java.time API. >>> Please help review the proposed changeset as showed in webrev: >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>> >>> In addition to general javadoc improvements, the changes include: >>> >>> java.time >>> >>> * Duration - added a static from(temporalAmount) method to simplify >>> conversions from other amounts >>> * Renamed the toString(Formatter) method to format(Formatter) in all >>> classes >>> * Period - added a static from(temporalAmount) method to simplify >>> conversions >>> * ZoneId - >>> - Added getAvailableZoneIds method, a simpler mechanism than going >>> to the provider >>> - Added normalized() method to ease conversion to a fixed offset >>> - renamed predefined static fields of timezone names >>> >>> java.time.chrono >>> >>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>> - changed xxx_COMPARATORs to static methods returning the Time Line >>> Order comparators >>> - Added a from(TemporalAcessor) method to ease conversions >>> * Chronology >>> - Added method to create a Date from EpochDay (And in each >>> calendar subclass) >>> - Added resolveDate to allow resolving date components by the >>> Chronology >>> - Serialization fixes >>> - Replaced raw return types with wildcard type >>> * Era >>> - Removed factory methods and getChronology - they did not work >>> correctly in all cases >>> - Declared Era as a functional interface >>> * Hijrah calendar variations - >>> - Supporting the Umm alQura calendar >>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>> making the enums public >>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>> to return the concrete Era type. >>> >>> java.time.format >>> >>> * DateTimeFormatter - >>> - Added fields for the predefined formatters >>> (moved from DateTimeFormatters class) >>> - Updated patterns to be CLDR compatible >>> - Moved documentation for the pattern letters to the class javadoc >>> - Added support for Zone default and conversion >>> * DateTimeFormatterBuilder >>> - Updated documentation of patterns and corresponding equivalents >>> to builder methods. >>> - Added a method to append the localized offset. >>> >>> java.time.temporal >>> >>> * Adjusters - class removed; all static adjusters moved to static >>> methods >>> in TemporalAdjuster >>> * ChronoField - >>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>> - Added getDisplayName - for locale specific field name >>> * Queries - class removed; all static query method moved to static >>> methods >>> in TemporalQuery >>> * TemporalField - added getDisplayName method >>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>> to reflect no support for a unit or field >>> * WeekFields - Added fields for week and year of week-Based-Years to >>> match >>> CLDR fields "Y", "W" > From mike.duigou at oracle.com Wed Apr 10 00:19:45 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 9 Apr 2013 17:19:45 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <5162BD9E.2050803@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <5162BD9E.2050803@oracle.com> Message-ID: <0D804DA5-82CD-4947-BC8D-B816A55C97F9@oracle.com> On Apr 8 2013, at 05:52 , Alan Bateman wrote: > I think this is the webrev: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/2/webrev/ > > It's impossible to predict what the usage will be after you reconstitute. I agree completely. We should have a consistent policy for both deserialization and clone(). > Personally I think it's better to leave it as is, meaning the rounded-up size as otherwise you might reconstitute to a capacity that is much more than you might ever need. This is my feeling as well. I especially wonder about the extra space of clone()ed maps. Seems like a good opportunity for savings. > > I didn't notice in the previous revisions but roundUpToPowerOf2 can assign "rounded" twice (it probably doesn't happen when it gets compiled at runtime but still looks a bit odd). All in the name of optimization. > > The test still have the bug issue number. Sorry for not correcting this in earlier revs. > -Alan > From Mike.Duigou at oracle.COM Wed Apr 10 01:00:49 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Tue, 9 Apr 2013 18:00:49 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <51648444.2010808@oracle.com> References: <51648444.2010808@oracle.com> Message-ID: <8B7A7DEA-26A9-4304-901F-2D32250A563E@oracle.COM> Are we convinced that the capture cost of the lambdas likely to be used as suppliers is generally (*) better than the string construction that using a Supplier would avoid? (*) I say "generally" because I am certain examples could be found in which either is clearly better. Mike On Apr 9 2013, at 14:12 , Joe Darcy wrote: > Hello, > > Please review my changes for > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > http://cr.openjdk.java.net/~darcy/8011800.0/ > > which add a new method to java.util.Objects to take a Supplier rather than a String. > > Patch inline below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/Objects.java 2013-04-09 14:08:34.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java 2013-04-09 14:08:33.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,8 @@ > > package java.util; > > +import java.util.function.Supplier; > + > /** > * This class consists of {@code static} utility methods for operating > * on objects. These utilities include {@code null}-safe or {@code > @@ -226,4 +228,31 @@ > throw new NullPointerException(message); > return obj; > } > + > + /** > + * Checks that the specified object reference is not {@code null} and > + * throws a customized {@link NullPointerException} if it is. > + * > + *

Compared to the sibling method {@link requireNonNull(Object, > + * String}, this methods allows creation of the message to be > + * deferred until after the null check is made. Note that if the > + * supplier is provided via a lambda expression, there can be an > + * overhead involved in creating the supplier. Therefore, while > + * this method may confer a net performance advantage in the > + * non-null case, it is most likely to do so if creating the > + * message string is expensive. > + * > + * @param obj the object reference to check for nullity > + * @param messageSupplier supplier of the detail message to be > + * used in the event that a {@code NullPointerException} is thrown > + * @param the type of the reference > + * @return {@code obj} if not {@code null} > + * @throws NullPointerException if {@code obj} is {@code null} > + * @since 1.8 > + */ > + public static T requireNonNull(T obj, Supplier messageSupplier) { > + if (obj == null) > + throw new NullPointerException(messageSupplier.get()); > + return obj; > + } > } > --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 > +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 6797535 6889858 6891113 > + * @bug 6797535 6889858 6891113 8011800 > * @summary Basic tests for methods in java.util.Objects > * @author Joseph D. Darcy > */ > @@ -166,17 +166,17 @@ > try { > s = Objects.requireNonNull("pants"); > if (s != "pants") { > - System.err.printf("1-arg non-null failed to return its arg"); > + System.err.printf("1-arg requireNonNull failed to return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("1-arg nonNull threw unexpected NPE"); > + System.err.printf("1-arg requireNonNull threw unexpected NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null); > - System.err.printf("1-arg nonNull failed to throw NPE"); > + System.err.printf("1-arg requireNonNull failed to throw NPE"); > errors++; > } catch (NullPointerException e) { > // Expected > @@ -186,17 +186,40 @@ > try { > s = Objects.requireNonNull("pants", "trousers"); > if (s != "pants") { > - System.err.printf("2-arg nonNull failed to return its arg"); > + System.err.printf("2-arg requireNonNull failed to return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("2-arg nonNull threw unexpected NPE"); > + System.err.printf("2-arg requireNonNull threw unexpected NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null, "pantaloons"); > - System.err.printf("2-arg nonNull failed to throw NPE"); > + System.err.printf("2-arg requireNonNull failed to throw NPE"); > + errors++; > + } catch (NullPointerException e) { > + if (e.getMessage() != "pantaloons") { > + System.err.printf("2-arg requireNonNull threw NPE w/ bad detail msg"); > + errors++; > + } > + } > + > + // Test supplier rvariant > + try { > + s = Objects.requireNonNull("pants", () -> "trousers"); > + if (s != "pants") { > + System.err.printf("Supplier requireNonNull failed to return its arg"); > + errors++; > + } > + } catch (NullPointerException e) { > + System.err.printf("Supplier nonNull threw unexpected NPE"); > + errors++; > + } > + > + try { > + s = Objects.requireNonNull(null, () -> "pantaloons"); > + System.err.printf("Suppiler requireNonNull failed to throw NPE"); > errors++; > } catch (NullPointerException e) { > if (e.getMessage() != "pantaloons") { > From mike.duigou at oracle.com Wed Apr 10 01:17:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 9 Apr 2013 18:17:23 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> Message-ID: <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Hello all; Another update to the webrev incorporating feedback from Alan and Martin. http://cr.openjdk.java.net/~mduigou/JDK-8011200/3/webrev/ - The key change in this revision is that the capacity of both cloned() and deserialized instances is determined by the number of entries NOT the capacity of the source HashMap. As Alan says, we don't know how the clone or deserialized instance is going to be used. Without maintaining the original user specified initial capacity we're possibly better off not allocating excessive bucket table. Mike On Apr 6 2013, at 15:02 , Mike Duigou wrote: > Hello all; > > Another, and hopefully the final, update to the webrev for this issue. The revised webrev is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > The important changes in this revision: > > - I've removed the serialData change in HashMap. The implementation now reads the capacity and gracefully handles non-power of 2 values. > > - I'm not entirely convinced that having serialization emulate clone() for capacity handling is the best answer. I might also want to change clone() to size it's result based upon the number of mappings in the source rather its the capacity. Anybody have strong feelings about this to suggest one behaviour is obviously better? > > Any other final thoughts? > > Mike > > On Apr 2 2013, at 15:50 , Mike Duigou wrote: > >> Hello again; >> >> I have updated the patch with the received review feedback. The revised webrev is here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ >> >> The important changes in this revision: >> >> - The behaviour of the readObject/writeObject serialization for both classes now more closely mirrors the behaviour of clone(). For ArrayList this means that the deserialized list has a capacity the same as the size. ie. as if trimToSize() was called. For HashMap, the opposite is true, the capacity is the same as was in effect when the object was serialized. (HashMap also tries to protect itself from nonsensical/harmful input). The implementation changes to serialization preserve forward and backward compatibility--all serialized objects are compatible with all implementations. I will file a spec change request for the addition of ", a power of 2" to the @serialData tag for this existing but previously unstated requirement. >> >> - Use of Arrays.fill has been reverted. I did change one fill case so that the loop can be optimized. (size field was being updated with each iteration). I very slightly expanded the docs. >> >> This is starting to look like a nice set of changes. >> >> Mike >> >> On Apr 1 2013, at 21:44 , Mike Duigou wrote: >> >>> Hello all; >>> >>> Last night while pushing another changeset I accidentally pushed a changeset for JKD-7143928. Since the review and testing was not complete on this issue I have backed out that changeset and created a new bug number to continue development. The new webrev to complete the review is: >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ >>> >>> It is currently unchanged from the last posted changeset for 7143928. >>> >>> Mike >>> >>> On Apr 1 2013, at 19:00 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> I have posted an updated version of the empty ArrayList and HashMap patch. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ >>>> >>>> This revised implementation introduces *no new fields* to either class. For ArrayList the lazy allocation of the backing array occurs only if the list is created at default size. According to our performance analysis team, approximately 85% of ArrayList instances are created at default size so this optimization will be valid for an overwhelming majority of cases. >>>> >>>> For HashMap, creative use is made of the threshold field to track the requested initial size until the bucket array is needed. On the read side the empty map case is tested with isEmpty(). On the write size a comparison of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket array. In readObject there's a little more work to try to choose an efficient initial capacity. >>>> >>>> Mike >>>> >>>> On Mar 26 2013, at 17:25 , Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> This is a review for optimization work that came out of internal analysis of Oracle's Java applications. It's based upon analysis that shows that in large applications as much as 10% of maps and lists are initialized but never receive any entries. A smaller number spend a large proportion of their lifetime empty. We've found similar results across other workloads as well. This patch is not a substitute for pre-sizing your collections and maps--doing so will *always* have better results. >>>>> >>>>> This patch extends HashMap and ArrayList to provide special handling for newly created instances that avoids creating the backing array until needed. There is a very small additional cost for detecting when to inflate the map or list that is measurable in interpreted tests but disappears in JITed code. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ >>>>> >>>>> We expect that should this code prove successful in Java 8 it will be backported to Java 7 updates. >>>>> >>>>> The unit test may appear to be somewhat unrelated. It was created after resolving a bug in an early version of this patch to detect the issue encountered (LinkedHashMap.init() was not being called in readObject() when the map was empty). >>>>> >>>>> Mike >>>> >>> >> > From joe.darcy at oracle.com Wed Apr 10 01:22:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 09 Apr 2013 18:22:03 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <8B7A7DEA-26A9-4304-901F-2D32250A563E@oracle.COM> References: <51648444.2010808@oracle.com> <8B7A7DEA-26A9-4304-901F-2D32250A563E@oracle.COM> Message-ID: <5164BEBB.1030207@oracle.com> On 04/09/2013 06:00 PM, Mike Duigou wrote: > Are we convinced that the capture cost of the lambdas likely to be used as suppliers is generally (*) better than the string construction that using a Supplier would avoid? > > (*) I say "generally" because I am certain examples could be found in which either is clearly better. I know I've hesitated to use the existing requireNonNull method with a custom message at times because of having to always pay the string construction cost. I think the supplier passed as a lambda combination is on the right side of likely vm optimization attention in the JDK 8 train. -Joe > > Mike > > On Apr 9 2013, at 14:12 , Joe Darcy wrote: > >> Hello, >> >> Please review my changes for >> >> 8011800: Add java.util.Objects.requireNonNull(T, Supplier) >> http://cr.openjdk.java.net/~darcy/8011800.0/ >> >> which add a new method to java.util.Objects to take a Supplier rather than a String. >> >> Patch inline below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/util/Objects.java 2013-04-09 14:08:34.000000000 -0700 >> +++ new/src/share/classes/java/util/Objects.java 2013-04-09 14:08:33.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -25,6 +25,8 @@ >> >> package java.util; >> >> +import java.util.function.Supplier; >> + >> /** >> * This class consists of {@code static} utility methods for operating >> * on objects. These utilities include {@code null}-safe or {@code >> @@ -226,4 +228,31 @@ >> throw new NullPointerException(message); >> return obj; >> } >> + >> + /** >> + * Checks that the specified object reference is not {@code null} and >> + * throws a customized {@link NullPointerException} if it is. >> + * >> + *

Compared to the sibling method {@link requireNonNull(Object, >> + * String}, this methods allows creation of the message to be >> + * deferred until after the null check is made. Note that if the >> + * supplier is provided via a lambda expression, there can be an >> + * overhead involved in creating the supplier. Therefore, while >> + * this method may confer a net performance advantage in the >> + * non-null case, it is most likely to do so if creating the >> + * message string is expensive. >> + * >> + * @param obj the object reference to check for nullity >> + * @param messageSupplier supplier of the detail message to be >> + * used in the event that a {@code NullPointerException} is thrown >> + * @param the type of the reference >> + * @return {@code obj} if not {@code null} >> + * @throws NullPointerException if {@code obj} is {@code null} >> + * @since 1.8 >> + */ >> + public static T requireNonNull(T obj, Supplier messageSupplier) { >> + if (obj == null) >> + throw new NullPointerException(messageSupplier.get()); >> + return obj; >> + } >> } >> --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 >> +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 14:08:34.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -23,7 +23,7 @@ >> >> /* >> * @test >> - * @bug 6797535 6889858 6891113 >> + * @bug 6797535 6889858 6891113 8011800 >> * @summary Basic tests for methods in java.util.Objects >> * @author Joseph D. Darcy >> */ >> @@ -166,17 +166,17 @@ >> try { >> s = Objects.requireNonNull("pants"); >> if (s != "pants") { >> - System.err.printf("1-arg non-null failed to return its arg"); >> + System.err.printf("1-arg requireNonNull failed to return its arg"); >> errors++; >> } >> } catch (NullPointerException e) { >> - System.err.printf("1-arg nonNull threw unexpected NPE"); >> + System.err.printf("1-arg requireNonNull threw unexpected NPE"); >> errors++; >> } >> >> try { >> s = Objects.requireNonNull(null); >> - System.err.printf("1-arg nonNull failed to throw NPE"); >> + System.err.printf("1-arg requireNonNull failed to throw NPE"); >> errors++; >> } catch (NullPointerException e) { >> // Expected >> @@ -186,17 +186,40 @@ >> try { >> s = Objects.requireNonNull("pants", "trousers"); >> if (s != "pants") { >> - System.err.printf("2-arg nonNull failed to return its arg"); >> + System.err.printf("2-arg requireNonNull failed to return its arg"); >> errors++; >> } >> } catch (NullPointerException e) { >> - System.err.printf("2-arg nonNull threw unexpected NPE"); >> + System.err.printf("2-arg requireNonNull threw unexpected NPE"); >> errors++; >> } >> >> try { >> s = Objects.requireNonNull(null, "pantaloons"); >> - System.err.printf("2-arg nonNull failed to throw NPE"); >> + System.err.printf("2-arg requireNonNull failed to throw NPE"); >> + errors++; >> + } catch (NullPointerException e) { >> + if (e.getMessage() != "pantaloons") { >> + System.err.printf("2-arg requireNonNull threw NPE w/ bad detail msg"); >> + errors++; >> + } >> + } >> + >> + // Test supplier rvariant >> + try { >> + s = Objects.requireNonNull("pants", () -> "trousers"); >> + if (s != "pants") { >> + System.err.printf("Supplier requireNonNull failed to return its arg"); >> + errors++; >> + } >> + } catch (NullPointerException e) { >> + System.err.printf("Supplier nonNull threw unexpected NPE"); >> + errors++; >> + } >> + >> + try { >> + s = Objects.requireNonNull(null, () -> "pantaloons"); >> + System.err.printf("Suppiler requireNonNull failed to throw NPE"); >> errors++; >> } catch (NullPointerException e) { >> if (e.getMessage() != "pantaloons") { >> From david.holmes at oracle.com Wed Apr 10 02:38:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 12:38:01 +1000 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <51648444.2010808@oracle.com> References: <51648444.2010808@oracle.com> Message-ID: <5164D089.5080602@oracle.com> Hi Joe, On 10/04/2013 7:12 AM, Joe Darcy wrote: > Hello, > > Please review my changes for > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > http://cr.openjdk.java.net/~darcy/8011800.0/ > > which add a new method to java.util.Objects to take a Supplier > rather than a String. I'm not sure the discussion of the potential cost of a lambda expression really belongs in the API docs for this method. David ----- > Patch inline below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:33.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,8 @@ > > package java.util; > > +import java.util.function.Supplier; > + > /** > * This class consists of {@code static} utility methods for operating > * on objects. These utilities include {@code null}-safe or {@code > @@ -226,4 +228,31 @@ > throw new NullPointerException(message); > return obj; > } > + > + /** > + * Checks that the specified object reference is not {@code null} and > + * throws a customized {@link NullPointerException} if it is. > + * > + *

Compared to the sibling method {@link requireNonNull(Object, > + * String}, this methods allows creation of the message to be > + * deferred until after the null check is made. Note that if the > + * supplier is provided via a lambda expression, there can be an > + * overhead involved in creating the supplier. Therefore, while > + * this method may confer a net performance advantage in the > + * non-null case, it is most likely to do so if creating the > + * message string is expensive. > + * > + * @param obj the object reference to check for nullity > + * @param messageSupplier supplier of the detail message to be > + * used in the event that a {@code NullPointerException} is thrown > + * @param the type of the reference > + * @return {@code obj} if not {@code null} > + * @throws NullPointerException if {@code obj} is {@code null} > + * @since 1.8 > + */ > + public static T requireNonNull(T obj, Supplier > messageSupplier) { > + if (obj == null) > + throw new NullPointerException(messageSupplier.get()); > + return obj; > + } > } > --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 6797535 6889858 6891113 > + * @bug 6797535 6889858 6891113 8011800 > * @summary Basic tests for methods in java.util.Objects > * @author Joseph D. Darcy > */ > @@ -166,17 +166,17 @@ > try { > s = Objects.requireNonNull("pants"); > if (s != "pants") { > - System.err.printf("1-arg non-null failed to return its > arg"); > + System.err.printf("1-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("1-arg nonNull threw unexpected NPE"); > + System.err.printf("1-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null); > - System.err.printf("1-arg nonNull failed to throw NPE"); > + System.err.printf("1-arg requireNonNull failed to throw NPE"); > errors++; > } catch (NullPointerException e) { > // Expected > @@ -186,17 +186,40 @@ > try { > s = Objects.requireNonNull("pants", "trousers"); > if (s != "pants") { > - System.err.printf("2-arg nonNull failed to return its > arg"); > + System.err.printf("2-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("2-arg nonNull threw unexpected NPE"); > + System.err.printf("2-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null, "pantaloons"); > - System.err.printf("2-arg nonNull failed to throw NPE"); > + System.err.printf("2-arg requireNonNull failed to throw NPE"); > + errors++; > + } catch (NullPointerException e) { > + if (e.getMessage() != "pantaloons") { > + System.err.printf("2-arg requireNonNull threw NPE w/ > bad detail msg"); > + errors++; > + } > + } > + > + // Test supplier rvariant > + try { > + s = Objects.requireNonNull("pants", () -> "trousers"); > + if (s != "pants") { > + System.err.printf("Supplier requireNonNull failed to > return its arg"); > + errors++; > + } > + } catch (NullPointerException e) { > + System.err.printf("Supplier nonNull threw unexpected NPE"); > + errors++; > + } > + > + try { > + s = Objects.requireNonNull(null, () -> "pantaloons"); > + System.err.printf("Suppiler requireNonNull failed to throw > NPE"); > errors++; > } catch (NullPointerException e) { > if (e.getMessage() != "pantaloons") { > From david.holmes at oracle.com Wed Apr 10 02:48:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 12:48:45 +1000 Subject: RFR : 8010948 : Add conversion functional interfaces In-Reply-To: <6A3CDB0E-038F-415F-980C-9BEBA5B4C34A@oracle.com> References: <968AAA46-6AAE-4113-9CED-448F3E86EA6A@oracle.com> <6A3CDB0E-038F-415F-980C-9BEBA5B4C34A@oracle.com> Message-ID: <5164D30D.9080102@oracle.com> On 10/04/2013 9:07 AM, Mike Duigou wrote: > Any further comment on these? > > Technically they are adequately reviewed as I have reviewed them and am submitting them on behalf of Brian Goetz. I would prefer to know that at least one other set of eyes has looked at them though. I looked - no comments. :) Cheers, David > Mike > > On Apr 3 2013, at 17:00 , Mike Duigou wrote: > >> Hello all; >> >> Another set of functional interfaces for review for the soon-to-be-arriving-in-TL-repo lambda libraries. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010948/0/webrev/ >> >> These interfaces are Functions between the core primitive types (double, int, long) used by the lambda libraries. Methods providing the equivalent of the widening and narrowing primitive conversions may be added in a later patch. >> >> Mike > From martinrb at google.com Wed Apr 10 02:56:37 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Apr 2013 19:56:37 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: Mike, thanks. I don't see anything wrong in this version, although the ongoing complexification and special-case-ification (with attendant risk of bugs) of ArrayList and HashMap, the two most didactically important classes, continue to bother me. This change continues to feel marginal. Anyways, this is OK with me if it's OK with Alan. The original code that shifts by one every time has a certain elegance, and because it's rare to need more than one doubling, is also hard to beat performance-wise. 546 while (newCapacity < targetCapacity) 547 newCapacity <<= 1; --- should there be an "else" added in the code below? 563 if (table == EMPTY_TABLE) { 564 inflateTable(Math.max((int) (numKeysToBeAdded * loadFactor), threshold)); 565 } 566 567 /* 568 * Expand the map if the map if the number of mappings to be added 569 * is greater than or equal to threshold. This is conservative; the 570 * obvious condition is (m.size() + size) >= threshold, but this 571 * condition could result in a map with twice the appropriate capacity, 572 * if the keys to be added overlap with the keys already in this map. 573 * By using the conservative calculation, we subject ourself 574 * to at most one extra resize. 575 */ 576 if (numKeysToBeAdded > threshold) { --- There are now so many "if (isEmpty())" checks that I wonder again whether it would be better to use a null for the empty table, since null checks are closer to free. --- Style: """ Inflates the table. """ 285 * Inflate the table --- 288 // Find a power of 2 >= initialCapacity There's no "initialCapacity" variable here. On Tue, Apr 9, 2013 at 6:17 PM, Mike Duigou wrote: > Hello all; > > Another update to the webrev incorporating feedback from Alan and Martin. > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/3/webrev/ > > - The key change in this revision is that the capacity of both cloned() > and deserialized instances is determined by the number of entries NOT the > capacity of the source HashMap. As Alan says, we don't know how the clone > or deserialized instance is going to be used. Without maintaining the > original user specified initial capacity we're possibly better off not > allocating excessive bucket table. > > Mike > > > > On Apr 6 2013, at 15:02 , Mike Duigou wrote: > > > Hello all; > > > > Another, and hopefully the final, update to the webrev for this issue. > The revised webrev is here: > > > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > > > > The important changes in this revision: > > > > - I've removed the serialData change in HashMap. The implementation now > reads the capacity and gracefully handles non-power of 2 values. > > > > - I'm not entirely convinced that having serialization emulate clone() > for capacity handling is the best answer. I might also want to change > clone() to size it's result based upon the number of mappings in the source > rather its the capacity. Anybody have strong feelings about this to suggest > one behaviour is obviously better? > > > > Any other final thoughts? > > > > Mike > > > > On Apr 2 2013, at 15:50 , Mike Duigou wrote: > > > >> Hello again; > >> > >> I have updated the patch with the received review feedback. The revised > webrev is here: > >> > >> http://cr.openjdk.java.net/~mduigou/JDK-8011200/1/webrev/ > >> > >> The important changes in this revision: > >> > >> - The behaviour of the readObject/writeObject serialization for both > classes now more closely mirrors the behaviour of clone(). For ArrayList > this means that the deserialized list has a capacity the same as the size. > ie. as if trimToSize() was called. For HashMap, the opposite is true, the > capacity is the same as was in effect when the object was serialized. > (HashMap also tries to protect itself from nonsensical/harmful input). The > implementation changes to serialization preserve forward and backward > compatibility--all serialized objects are compatible with all > implementations. I will file a spec change request for the addition of ", a > power of 2" to the @serialData tag for this existing but previously > unstated requirement. > >> > >> - Use of Arrays.fill has been reverted. I did change one fill case so > that the loop can be optimized. (size field was being updated with each > iteration). I very slightly expanded the docs. > >> > >> This is starting to look like a nice set of changes. > >> > >> Mike > >> > >> On Apr 1 2013, at 21:44 , Mike Duigou wrote: > >> > >>> Hello all; > >>> > >>> Last night while pushing another changeset I accidentally pushed a > changeset for JKD-7143928. Since the review and testing was not complete on > this issue I have backed out that changeset and created a new bug number to > continue development. The new webrev to complete the review is: > >>> > >>> http://cr.openjdk.java.net/~mduigou/JDK-8011200/0/webrev/ > >>> > >>> It is currently unchanged from the last posted changeset for 7143928. > >>> > >>> Mike > >>> > >>> On Apr 1 2013, at 19:00 , Mike Duigou wrote: > >>> > >>>> Hello all; > >>>> > >>>> I have posted an updated version of the empty ArrayList and HashMap > patch. > >>>> > >>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/ > >>>> > >>>> This revised implementation introduces *no new fields* to either > class. For ArrayList the lazy allocation of the backing array occurs only > if the list is created at default size. According to our performance > analysis team, approximately 85% of ArrayList instances are created at > default size so this optimization will be valid for an overwhelming > majority of cases. > >>>> > >>>> For HashMap, creative use is made of the threshold field to track the > requested initial size until the bucket array is needed. On the read side > the empty map case is tested with isEmpty(). On the write size a comparison > of (table == EMPTY_TABLE) is used to detect the need to inflate the bucket > array. In readObject there's a little more work to try to choose an > efficient initial capacity. > >>>> > >>>> Mike > >>>> > >>>> On Mar 26 2013, at 17:25 , Mike Duigou wrote: > >>>> > >>>>> Hello all; > >>>>> > >>>>> This is a review for optimization work that came out of internal > analysis of Oracle's Java applications. It's based upon analysis that shows > that in large applications as much as 10% of maps and lists are initialized > but never receive any entries. A smaller number spend a large proportion of > their lifetime empty. We've found similar results across other workloads as > well. This patch is not a substitute for pre-sizing your collections and > maps--doing so will *always* have better results. > >>>>> > >>>>> This patch extends HashMap and ArrayList to provide special handling > for newly created instances that avoids creating the backing array until > needed. There is a very small additional cost for detecting when to inflate > the map or list that is measurable in interpreted tests but disappears in > JITed code. > >>>>> > >>>>> http://cr.openjdk.java.net/~mduigou/JDK-7143928/0/webrev/ > >>>>> > >>>>> We expect that should this code prove successful in Java 8 it will > be backported to Java 7 updates. > >>>>> > >>>>> The unit test may appear to be somewhat unrelated. It was created > after resolving a bug in an early version of this patch to detect the issue > encountered (LinkedHashMap.init() was not being called in readObject() when > the map was empty). > >>>>> > >>>>> Mike > >>>> > >>> > >> > > > > From joe.darcy at oracle.com Wed Apr 10 06:06:16 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 09 Apr 2013 23:06:16 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <5164D089.5080602@oracle.com> References: <51648444.2010808@oracle.com> <5164D089.5080602@oracle.com> Message-ID: <51650158.70307@oracle.com> Hi David, On 04/09/2013 07:38 PM, David Holmes wrote: > Hi Joe, > > On 10/04/2013 7:12 AM, Joe Darcy wrote: >> Hello, >> >> Please review my changes for >> >> 8011800: Add java.util.Objects.requireNonNull(T, Supplier) >> http://cr.openjdk.java.net/~darcy/8011800.0/ >> >> which add a new method to java.util.Objects to take a Supplier >> rather than a String. > > I'm not sure the discussion of the potential cost of a lambda > expression really belongs in the API docs for this method. The cautionary note could be summarized / expanded as "make sure you think this is a good idea." Off-list, Brian expressed some concerns similar to the ones Mike raised about whether or not the method could be an attractive nuisance if overused so I think some kind of warning is warranted if the method is included. -Joe > > David > ----- > >> Patch inline below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/util/Objects.java 2013-04-09 >> 14:08:34.000000000 -0700 >> +++ new/src/share/classes/java/util/Objects.java 2013-04-09 >> 14:08:33.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -25,6 +25,8 @@ >> >> package java.util; >> >> +import java.util.function.Supplier; >> + >> /** >> * This class consists of {@code static} utility methods for operating >> * on objects. These utilities include {@code null}-safe or {@code >> @@ -226,4 +228,31 @@ >> throw new NullPointerException(message); >> return obj; >> } >> + >> + /** >> + * Checks that the specified object reference is not {@code >> null} and >> + * throws a customized {@link NullPointerException} if it is. >> + * >> + *

Compared to the sibling method {@link requireNonNull(Object, >> + * String}, this methods allows creation of the message to be >> + * deferred until after the null check is made. Note that if the >> + * supplier is provided via a lambda expression, there can be an >> + * overhead involved in creating the supplier. Therefore, while >> + * this method may confer a net performance advantage in the >> + * non-null case, it is most likely to do so if creating the >> + * message string is expensive. >> + * >> + * @param obj the object reference to check for nullity >> + * @param messageSupplier supplier of the detail message to be >> + * used in the event that a {@code NullPointerException} is thrown >> + * @param the type of the reference >> + * @return {@code obj} if not {@code null} >> + * @throws NullPointerException if {@code obj} is {@code null} >> + * @since 1.8 >> + */ >> + public static T requireNonNull(T obj, Supplier >> messageSupplier) { >> + if (obj == null) >> + throw new NullPointerException(messageSupplier.get()); >> + return obj; >> + } >> } >> --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 >> 14:08:34.000000000 -0700 >> +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 >> 14:08:34.000000000 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -23,7 +23,7 @@ >> >> /* >> * @test >> - * @bug 6797535 6889858 6891113 >> + * @bug 6797535 6889858 6891113 8011800 >> * @summary Basic tests for methods in java.util.Objects >> * @author Joseph D. Darcy >> */ >> @@ -166,17 +166,17 @@ >> try { >> s = Objects.requireNonNull("pants"); >> if (s != "pants") { >> - System.err.printf("1-arg non-null failed to return its >> arg"); >> + System.err.printf("1-arg requireNonNull failed to >> return its arg"); >> errors++; >> } >> } catch (NullPointerException e) { >> - System.err.printf("1-arg nonNull threw unexpected NPE"); >> + System.err.printf("1-arg requireNonNull threw unexpected >> NPE"); >> errors++; >> } >> >> try { >> s = Objects.requireNonNull(null); >> - System.err.printf("1-arg nonNull failed to throw NPE"); >> + System.err.printf("1-arg requireNonNull failed to throw >> NPE"); >> errors++; >> } catch (NullPointerException e) { >> // Expected >> @@ -186,17 +186,40 @@ >> try { >> s = Objects.requireNonNull("pants", "trousers"); >> if (s != "pants") { >> - System.err.printf("2-arg nonNull failed to return its >> arg"); >> + System.err.printf("2-arg requireNonNull failed to >> return its arg"); >> errors++; >> } >> } catch (NullPointerException e) { >> - System.err.printf("2-arg nonNull threw unexpected NPE"); >> + System.err.printf("2-arg requireNonNull threw unexpected >> NPE"); >> errors++; >> } >> >> try { >> s = Objects.requireNonNull(null, "pantaloons"); >> - System.err.printf("2-arg nonNull failed to throw NPE"); >> + System.err.printf("2-arg requireNonNull failed to throw >> NPE"); >> + errors++; >> + } catch (NullPointerException e) { >> + if (e.getMessage() != "pantaloons") { >> + System.err.printf("2-arg requireNonNull threw NPE w/ >> bad detail msg"); >> + errors++; >> + } >> + } >> + >> + // Test supplier rvariant >> + try { >> + s = Objects.requireNonNull("pants", () -> "trousers"); >> + if (s != "pants") { >> + System.err.printf("Supplier requireNonNull failed to >> return its arg"); >> + errors++; >> + } >> + } catch (NullPointerException e) { >> + System.err.printf("Supplier nonNull threw unexpected NPE"); >> + errors++; >> + } >> + >> + try { >> + s = Objects.requireNonNull(null, () -> "pantaloons"); >> + System.err.printf("Suppiler requireNonNull failed to throw >> NPE"); >> errors++; >> } catch (NullPointerException e) { >> if (e.getMessage() != "pantaloons") { >> From peter.levart at gmail.com Wed Apr 10 07:20:04 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Apr 2013 09:20:04 +0200 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <51648444.2010808@oracle.com> References: <51648444.2010808@oracle.com> Message-ID: <516512A4.4070107@gmail.com> Hi Joe, This is similar to recent addition to j.u.l.Logger, which is ok. No matter how lambda construction is optimized, if it captures any non-constant arguments, new object will always be constructed (unless perhaps JIT could optimize this away using escape analysis). Myself I often find that the following overloads could also be useful: public static T requireNonNull(T obj, String messageFormat, Object arg1); public static T requireNonNull(T obj, String messageFormat, Object arg1, Object arg2); public static T requireNonNull(T obj, String messageFormat, Object arg1, Object arg2, Object arg3); ... ...this is for example useful when you check the return value from a method or function and want to message some context (arguments passed to method/function) with the NPE... Regards, Peter On 04/09/2013 11:12 PM, Joe Darcy wrote: > Hello, > > Please review my changes for > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > http://cr.openjdk.java.net/~darcy/8011800.0/ > > which add a new method to java.util.Objects to take a Supplier > rather than a String. > > Patch inline below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:33.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,8 @@ > > package java.util; > > +import java.util.function.Supplier; > + > /** > * This class consists of {@code static} utility methods for operating > * on objects. These utilities include {@code null}-safe or {@code > @@ -226,4 +228,31 @@ > throw new NullPointerException(message); > return obj; > } > + > + /** > + * Checks that the specified object reference is not {@code null} > and > + * throws a customized {@link NullPointerException} if it is. > + * > + *

Compared to the sibling method {@link requireNonNull(Object, > + * String}, this methods allows creation of the message to be > + * deferred until after the null check is made. Note that if the > + * supplier is provided via a lambda expression, there can be an > + * overhead involved in creating the supplier. Therefore, while > + * this method may confer a net performance advantage in the > + * non-null case, it is most likely to do so if creating the > + * message string is expensive. > + * > + * @param obj the object reference to check for nullity > + * @param messageSupplier supplier of the detail message to be > + * used in the event that a {@code NullPointerException} is thrown > + * @param the type of the reference > + * @return {@code obj} if not {@code null} > + * @throws NullPointerException if {@code obj} is {@code null} > + * @since 1.8 > + */ > + public static T requireNonNull(T obj, Supplier > messageSupplier) { > + if (obj == null) > + throw new NullPointerException(messageSupplier.get()); > + return obj; > + } > } > --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 6797535 6889858 6891113 > + * @bug 6797535 6889858 6891113 8011800 > * @summary Basic tests for methods in java.util.Objects > * @author Joseph D. Darcy > */ > @@ -166,17 +166,17 @@ > try { > s = Objects.requireNonNull("pants"); > if (s != "pants") { > - System.err.printf("1-arg non-null failed to return > its arg"); > + System.err.printf("1-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("1-arg nonNull threw unexpected NPE"); > + System.err.printf("1-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null); > - System.err.printf("1-arg nonNull failed to throw NPE"); > + System.err.printf("1-arg requireNonNull failed to throw > NPE"); > errors++; > } catch (NullPointerException e) { > // Expected > @@ -186,17 +186,40 @@ > try { > s = Objects.requireNonNull("pants", "trousers"); > if (s != "pants") { > - System.err.printf("2-arg nonNull failed to return its > arg"); > + System.err.printf("2-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("2-arg nonNull threw unexpected NPE"); > + System.err.printf("2-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null, "pantaloons"); > - System.err.printf("2-arg nonNull failed to throw NPE"); > + System.err.printf("2-arg requireNonNull failed to throw > NPE"); > + errors++; > + } catch (NullPointerException e) { > + if (e.getMessage() != "pantaloons") { > + System.err.printf("2-arg requireNonNull threw NPE w/ > bad detail msg"); > + errors++; > + } > + } > + > + // Test supplier rvariant > + try { > + s = Objects.requireNonNull("pants", () -> "trousers"); > + if (s != "pants") { > + System.err.printf("Supplier requireNonNull failed to > return its arg"); > + errors++; > + } > + } catch (NullPointerException e) { > + System.err.printf("Supplier nonNull threw unexpected NPE"); > + errors++; > + } > + > + try { > + s = Objects.requireNonNull(null, () -> "pantaloons"); > + System.err.printf("Suppiler requireNonNull failed to > throw NPE"); > errors++; > } catch (NullPointerException e) { > if (e.getMessage() != "pantaloons") { > From bourges.laurent at gmail.com Wed Apr 10 08:14:12 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 10 Apr 2013 10:14:12 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> Message-ID: Andrea, I am running benchmarks on my laptop (i7 - 2 core 2.8Ghz + HT => 4 virtual cpus) on linux 64 (fedora 14). Note: I always use cpufrequtils to set the cpu governor to performance and use fixed frequency = 2.8Ghz: [bourgesl at jmmc-laurent ~]$ uname -a Linux jmmc-laurent.obs.ujf-grenoble.fr 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 2013/4/10 Andrea Aime > On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourg?s > wrote: > >> Also, this should be tested on multiple platforms, preferably Linux, >> Windows and Mac to see how it is affected by differences in the platform >> runtimes and threading (hopefully minimal). >> >> It appears more difficult for me: I can use at work a mac 10.8 and I can >> run Windows XP within virtual box (but it is not very representative). >> > > I believe I can run MapBench on my Linux 64bit box during the next > weekend, that would add a platform, and one were the > server side behavior is enabled by default. And hopefully run the other > benchmark as well. > I also run j2DBench but I can try also Java2D.demos to perform regression tests. > > Laurent, have you made any changes to MapBench since I've sent it to you? > Yes I fixed a bit (cached BasicStroke, reused BufferedImage / Graphics) and added explicit GC before tests (same initial conditions): http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/ Look at MapBench-src.zipfor test changes. Thanks for your efforts, Laurent From Sergey.Bylokhov at oracle.com Wed Apr 10 08:26:33 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Apr 2013 08:26:33 -0000 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> Message-ID: <524E7BA0.3060206@oracle.com> Hi, Laurent. The changes in awt/swing area looks good. On 4/8/13 3:32 PM, Laurent Bourg?s wrote: > Anthony, > > here is an updated patch concerning both PlatformLogger and Logger 'bad' > usages: > http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ > > It impacts now awt, swing, JMX, security, network, and apache xml. > > Thanks for the review, > Laurent > > 2013/4/8 Laurent Bourg?s > >> Peter, Mandy, >> >> I think it would be great to make PlatformLogger very similar to Logger >> API: >> I mean JUL Logger already has only 1 convenient method with 1 param so it >> may be great to have the same API in PlatformLogger too: maybe extend it to >> 2 or 3 params ... >> >> Peter, could you look at the API differences between Logger / >> PlatformLogger to make PlatformLogger API more similar to JUL Logger ? >> >> Laurent >> >> >> 2013/4/8 Peter Levart >> >>> On 04/07/2013 07:11 PM, Laurent Bourg?s wrote: >>> >>> Hi >>> >>> I started fixing All PlatformlLogger "bad" usages and I am fixing also >>> many jul Logger usages without isLoggable ... >>> That represents a lot of changes and a very boring job. >>> >>> I think sending a webrew tomorrow. >>> >>> >>> Hi Laurent, >>> >>> Since you're already deep in the task, you might have a rough feeling >>> what part of such unguarded log statements are of the following type: >>> >>> logger.[fine,info,...]("a message with {0} and {1} placeholders", >>> someArg1, someArg2); >>> >>> where someArg1, ... are some values that are already present in the >>> context of the logging statement and don't have to be computed just for >>> satisfying the logging (not even boxing). Such usages could be effectively >>> optimized by adding some overloaded methods to PlatformLogger that take 1, >>> 2, 3, ... arguments: >>> >>> class PlatformLogger { >>> >>> ... >>> >>> public void finest(String msg, Object param1) { >>> if (isLoggable(Level.FINEST)) { >>> loggerProxy.doLog(Level.FINEST, msg, param1); >>> } >>> } >>> >>> public void finest(String msg, Object param1, Object param2) { >>> if (isLoggable(Level.FINEST)) { >>> loggerProxy.doLog(Level.FINEST, msg, param1, param2); >>> } >>> } >>> >>> public void finest(String msg, Object param1, Object param2, Object >>> param3) { >>> if (isLoggable(Level.FINEST)) { >>> loggerProxy.doLog(Level.FINEST, msg, param1, param2, param3); >>> } >>> } >>> >>> ... >>> >>> This would effectively guard creation of the arguments array with an >>> isLoggable check for some common usages, eliminating the need to explicitly >>> guard such statements. Of course, the user would have to be aware of when >>> such unguarded logging statement is without overhead and when not... >>> >>> How do you feel about such API extension? >>> >>> >>> Regards, Peter >>> >>> >>> >>> Laurent >>> Le 4 avr. 2013 14:08, "Laurent Bourg?s" a >>> ?crit : >>> >>>> Ok, I can provide an updated patch after finding / fixing all usages. >>>> >>>> Probably in 1 or 2 days, >>>> >>>> Laurent >>>> >>>> 2013/4/4 Anthony Petrov >>>> >>>>> Yes, this makes sense. Do you want to update your fix for 8010297 to >>>>> include these changes as well? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>> On 04/04/13 15:47, Laurent Bourg?s wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I just realized there is another problem with PlatformLogger log >>>>>> statements: >>>>>> XBaseWindow: >>>>>> public boolean grabInput() { >>>>>> grabLog.fine("Grab input on {0}", this); >>>>>> ... >>>>>> } >>>>>> >>>>>> This calls the PlatformLogger.fine( varargs): >>>>>> public void fine(String msg, Object... params) { >>>>>> logger.doLog(FINE, msg, params); >>>>>> } >>>>>> >>>>>> Doing so, the JVM creates a new Object[] instance to provide params as >>>>>> varargs. >>>>>> >>>>>> I would recommend using isLoggable() test to avoid such waste if the >>>>>> log >>>>>> is disabled (fine, finer, finest ...). >>>>>> >>>>>> Do you want me to provide a new patch related to this problem ? >>>>>> >>>>>> Does somebody have an idea to automatically analyze the JDK code and >>>>>> detect missing isLoggable statements ... >>>>>> >>>>>> Regards, >>>>>> Laurent >>>>>> >>>>>> 2013/4/3 Laurent Bourg?s >>>>> > >>>>>> >>>>>> >>>>>> Anthony, >>>>>> >>>>>> could you tell me once it is in the OpenJDK8 repository ? >>>>>> I would then perform again profiling tests to check if there is no >>>>>> more missing isLoggable() statements. >>>>>> >>>>>> Once JMX and other projects switch to PlatformLogger, I could check >>>>>> again. >>>>>> >>>>>> Maybe I could write a small java code checker (pmd rule) to test if >>>>>> there is missing isLoggable() statements wrapping PlatformLogger >>>>>> log >>>>>> statements. Any idea about how to reuse java parser to do so ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Laurent >>>>>> >>>>>> 2013/4/2 Anthony Petrov >>>>> > >>>>>> >>>>>> >>>>>> Looks fine to me as well. Thanks for fixing this, Laurent. >>>>>> >>>>>> Let's wait a couple more days in case Net or Swing folks want >>>>>> to >>>>>> review the fix. After that I'll push it to the repository. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> >>>>>> On 4/2/2013 15:35, Laurent Bourg?s wrote: >>>>>> >>>>>> Here is the updated patch: >>>>>> http://jmmc.fr/~bourgesl/__share/webrev-8010297.2/ >>>>>> >>>>>> >>>>>> >>>>>> Fixed inconsistencies between FINE / FINER log statements: >>>>>> - XScrollbarPeer >>>>>> - XWindowPeer >>>>>> >>>>>> Laurent >>>>>> >>>>>> 2013/4/2 Anthony Petrov >>>>> >>>>>> >>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> 1. Sergey: I believe this is for purposes of better >>>>>> formating the >>>>>> log output and making it more readable by separating >>>>>> or >>>>>> highlighting >>>>>> some sections. I don't think this should be changed. >>>>>> >>>>>> 2. Laurent: can you please address this issue and send >>>>>> us a new patch? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> >>>>>> On 4/1/2013 16:08, Sergey Bylokhov wrote: >>>>>> >>>>>> >>>>>> Hi, Anthony >>>>>> Only two comments: >>>>>> 1 Why we need some special text in the log output >>>>>> like "***" and >>>>>> "###" >>>>>> 2 XScrollbarPeer.java: >>>>>> >>>>>> + if >>>>>> (log.isLoggable(____PlatformLogger.FINEST)) { >>>>>> >>>>>> >>>>>> + log.finer("KeyEvent on scrollbar: " + >>>>>> event); >>>>>> + } >>>>>> >>>>>> >>>>>> >>>>>> On 4/1/13 12:20 PM, Anthony Petrov wrote: >>>>>> >>>>>> Awt, Swing, Net engineers, >>>>>> >>>>>> Could anyone review the fix please? For your >>>>>> convenience: >>>>>> >>>>>> Bug: >>>>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>>>> >>>>>> >>>>>> >>>>> > >>>>>> >>>>>> Fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>>>> < >>>>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>>>> < >>>>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>>>> < >>>>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>>>> >>>>>> -- best regards, >>>>>> Anthony >>>>>> >>>>>> On 3/22/2013 2:26, Anthony Petrov wrote: >>>>>> >>>>>> Hi Laurent, >>>>>> >>>>>> The fix looks great to me. Thank you very >>>>>> much. >>>>>> >>>>>> We still need at least one review, though. >>>>>> Hopefully >>>>>> net-dev@ and/or swing-dev@ folks might >>>>>> help >>>>>> us out a bit. >>>>>> >>>>>> -- best regards, >>>>>> Anthony >>>>>> >>>>>> On 3/20/2013 15:10, Anthony Petrov wrote: >>>>>> >>>>>> Hi Laurent, >>>>>> >>>>>> Thanks for the patch. I've filed a >>>>>> bug at: >>>>>> http://bugs.sun.com/view_bug.____do?bug_id=8010297 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> > >>>>>> (should be available in a day or two) >>>>>> >>>>>> and published a webrev generated from >>>>>> your patch at: >>>>>> >>>>>> http://cr.openjdk.java.net/~____anthony/8-55-isLoggable-____8010297.0/ >>>>>> < >>>>>> http://cr.openjdk.java.net/%7E__anthony/8-55-isLoggable-__8010297.0/> >>>>>> < >>>>>> http://cr.openjdk.java.net/%__7Eanthony/8-55-isLoggable-__8010297.0/ >>>>>> < >>>>>> http://cr.openjdk.java.net/%7Eanthony/8-55-isLoggable-8010297.0/>> >>>>>> >>>>>> >>>>>> I'm also copying swing-dev@ and >>>>>> net-dev@ because the >>>>>> fix affects those areas too. I myself >>>>>> will review >>>>>> the fix a bit later but am sending it >>>>>> now for other >>>>>> folks to take a look at it. >>>>>> >>>>>> On 3/19/2013 15:29, Laurent Bourg?s >>>>>> wrote: >>>>>> >>>>>> I am sorry I started modifying >>>>>> PlatformLogger >>>>>> and reverted changes to this class >>>>>> as it is >>>>>> another topic to be discussed >>>>>> later: isLoggable >>>>>> performance and waste due to >>>>>> HashMap>>>>> Level> leads to Integer >>>>>> allocations >>>>>> (boxing). >>>>>> >>>>>> >>>>>> I saw your message to core-libs-dev@, >>>>>> so I just >>>>>> dropped all changes to the >>>>>> PlatformLogger from this >>>>>> patch. >>>>>> >>>>>> Finally, I have another question >>>>>> related to the >>>>>> WrapperGenerator class: it >>>>>> generates a lot of >>>>>> empty log statements (XEvent): >>>>>> >>>>>> log >>>>>> < >>>>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/sun/____awt/X11/XWrapperBase.java#____XWrapperBase.0log >>>>>> < >>>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log> >>>>>> >>>>>> >>>>>> < >>>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/sun/__awt/X11/XWrapperBase.java#__XWrapperBase.0log >>>>>> < >>>>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/awt/X11/XWrapperBase.java#XWrapperBase.0log >>>>>>>>> .finest >>>>>> < >>>>>> http://grepcode.com/file/____repository.grepcode.com/java/____root/jdk/openjdk/6-b14/java/____util/logging/Logger.java#____Logger.finest%28java.lang.____String%29 >>>>>> < >>>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29> >>>>>> >>>>>> >>>>>> < >>>>>> http://grepcode.com/file/__repository.grepcode.com/java/__root/jdk/openjdk/6-b14/java/__util/logging/Logger.java#__Logger.finest%28java.lang.__String%29 >>>>>> < >>>>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/logging/Logger.java#Logger.finest%28java.lang.String%29 >>>>>>>>> (""); >>>>>> >>>>>> Is it really useful to have such >>>>>> statements ? I >>>>>> would keep logs with non empty >>>>>> messages only. >>>>>> >>>>>> See WrapperGenerator:753: >>>>>> String s_log = >>>>>> >>>>>> (generateLog?"log.finest(\"\")____;":""); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I believe they're used for log >>>>>> formatting purposes >>>>>> to separate numerous events in a log >>>>>> (e.g. think of >>>>>> mouse-move events - there can be >>>>>> hundreds of them in >>>>>> a raw). >>>>>> >>>>>> >>>>>> Please note that the hg export format >>>>>> is not that >>>>>> useful unless you're assigned an >>>>>> OpenJDK id already >>>>>> (please see Dalibor's message for >>>>>> details) because I >>>>>> can't import it directly. So for the >>>>>> time being you >>>>>> could send just raw patches (i.e. the >>>>>> output of hg >>>>>> diff only - and there's no need to >>>>>> commit your >>>>>> changes in this case). Also, please >>>>>> note that the >>>>>> mailing lists strip attachments. The >>>>>> reason I got it >>>>>> is because I was listed in To: of your >>>>>> message. So >>>>>> when sending patches you can: >>>>>> 1) post them inline, or >>>>>> 2) attach them and add a person to To: >>>>>> of your >>>>>> message, or >>>>>> 3) upload them somewhere on the web. >>>>>> However, it would be best if you could >>>>>> generate a >>>>>> webrev for your changes and upload it >>>>>> somewhere. >>>>>> Currently this is the standard format >>>>>> for reviewing >>>>>> fixes in OpenJDK. >>>>>> >>>>>> -- best regards, >>>>>> Anthony >>>>>> >>>>>> >>>>>> Regards, >>>>>> Laurent >>>>>> >>>>>> >>>>>> >>>>>> 2013/3/19 Laurent Bourg?s >>>>>> >>>>> bourges.laurent at gmail.com> >>>>>> >>>>> > >>>>>> >>>>> ____com >>>>>> >>>>>> >>>>> >>> >>>>>> >>>>>> Hi antony, >>>>>> >>>>>> FYI I started reviewing and >>>>>> fixing all >>>>>> PlatformLogger use cases (not >>>>>> too many as I thought first) >>>>>> mainly used by >>>>>> awt / swing projects to >>>>>> provide you a patch on latest >>>>>> JDK8 source code: >>>>>> >>>>>> I am adding the log level >>>>>> check >>>>>> when it is >>>>>> missing: >>>>>> if >>>>>> (...log.isLoggable(____PlatformLogger.xxx)) { >>>>>> >>>>>> >>>>>> log... >>>>>> } >>>>>> >>>>>> I will not change the String + >>>>>> operations to >>>>>> use the message format >>>>>> syntax in this patch. >>>>>> >>>>>> Do you accept such patch / >>>>>> proposed >>>>>> contribution ? >>>>>> >>>>>> Regards, >>>>>> Laurent >>>>>> >>>>>> >>>>>> 2013/3/18 Laurent Bourg?s >>>>>> >>>>> bourges.laurent at gmail.com> >>>>>> >>>>> > >>>>>> >>>>> ____com >>>>>> >>>>>> >>>>> >>> >>>>>> >>>>>> Hi antony, >>>>>> >>>>>> 2 different things: >>>>>> 1/ PlatformLogger was >>>>>> patched (doLog >>>>>> method) to avoid string >>>>>> operations (message >>>>>> formatting) for >>>>>> disabled logs (patch >>>>>> submiited on JDK8 and >>>>>> JDK7u): >>>>>> >>>>>> http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2012-____April/002751.html >>>>>> < >>>>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html> >>>>>> >>>>>> >>>>>> >>>>>> < >>>>>> http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2012-__April/002751.html >>>>>> < >>>>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-April/002751.html >>>>>> >>>>>> 2/ I looked 2 hours ago on >>>>>> JDK7u AND >>>>>> JDK8 source codes and both >>>>>> still have: >>>>>> - log statements WITHOUT >>>>>> log level check >>>>>> : if >>>>>> >>>>>> (log.isLoggable(____PlatformLogger.FINE)) >>>>>> >>>>>> >>>>>> log.fine(...); >>>>>> - string operations (+) in >>>>>> log calls >>>>>> that could be improved >>>>>> using the message format >>>>>> syntax (String >>>>>> + args): for example, >>>>>> avoid using >>>>>> PlatformLogger.fine(String + >>>>>> ...) in favor of using >>>>>> >>>>>> PlatformLogger.fine(String msg, >>>>>> Object... params) >>>>>> >>>>>> I reported in my previous >>>>>> mail several >>>>>> cases where the >>>>>> isLoggable() call is >>>>>> missing and leads >>>>>> to useless String >>>>>> operations but also method >>>>>> calls >>>>>> (Component.paramString() for >>>>>> example). >>>>>> >>>>>> Finally, I also provided >>>>>> other possible >>>>>> cases (using grep); >>>>>> maybe there is a better >>>>>> alternative to >>>>>> find all occurences of >>>>>> String operations in log >>>>>> calls. >>>>>> >>>>>> Regards, >>>>>> Laurent >>>>>> >>>>>> 2013/3/18 Anthony Petrov >>>>>> >>>>> anthony.petrov at oracle.com> >>>>>> >>>>> > >>>>>> >>>>> ____com >>>>>> >>>>>> >>>>> >>> >>>>>> >>>>>> Hi Laurent, >>>>>> >>>>>> Normally we fix an >>>>>> issue in JDK 8 >>>>>> first, and then back-port >>>>>> the fix to a 7u >>>>>> release. You're >>>>>> saying that in JDK 8 the >>>>>> problem isn't >>>>>> reproducible anymore. >>>>>> Can you please >>>>>> investigate (using the >>>>>> Mercurial >>>>>> history log) what exact fix >>>>>> resolved it in JDK 8? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 03/18/13 15:09, >>>>>> Laurent Bourg?s >>>>>> wrote: >>>>>> >>>>>> Dear all, >>>>>> >>>>>> I run recently >>>>>> netbeans profiler >>>>>> on my swing application >>>>>> (Aspro2: >>>>>> http://www.jmmc.fr/aspro) under >>>>>> linux x64 platform and I >>>>>> figured out >>>>>> that a lot of >>>>>> char[] instances >>>>>> are coming from String + >>>>>> operator called >>>>>> by sun.awt.X11 >>>>>> code. >>>>>> >>>>>> I looked at >>>>>> PlatformLogger >>>>>> source code but found not way >>>>>> to disable it >>>>>> completely: maybe >>>>>> an empty >>>>>> logger implementation could >>>>>> be interesting to >>>>>> be used during >>>>>> profiling or >>>>>> normal use (not debugging). >>>>>> Apparently JDK8 >>>>>> provides some >>>>>> patchs to avoid String >>>>>> creation when the >>>>>> logger is disabled >>>>>> (level). >>>>>> >>>>>> However, I looked >>>>>> also to the >>>>>> sun.awt code (jdk7u >>>>>> repository) to >>>>>> see the >>>>>> origin of the >>>>>> string allocations: >>>>>> XDecoratedPeer: >>>>>> public void >>>>>> handleFocusEvent(XEvent xev) { >>>>>> ... >>>>>> * >>>>>> focusLog.finer("Received focus event on shell: >>>>>> " + xfe); >>>>>> * } >>>>>> >>>>>> public >>>>>> boolean >>>>>> requestWindowFocus(long time, >>>>>> boolean >>>>>> timeProvided) { >>>>>> ... >>>>>> * >>>>>> focusLog.finest("Real native focused >>>>>> window: " + >>>>>> >>>>>> realNativeFocusedWindow + >>>>>> "\nKFM's focused window: " + >>>>>> focusedWindow); >>>>>> *... >>>>>> * >>>>>> focusLog.fine("Requesting focus to " + (this >>>>>> == >>>>>> toFocus ? "this >>>>>> window" : >>>>>> toFocus)); >>>>>> *... >>>>>> } >>>>>> >>>>>> XBaseWindow: >>>>>> public void >>>>>> xSetBounds(int >>>>>> x, int y, int width, int >>>>>> height) { >>>>>> ... >>>>>> * >>>>>> insLog.fine("Setting >>>>>> bounds on " + this + " to >>>>>> (" + x + ", " + >>>>>> y + "), " + width >>>>>> + >>>>>> "x" + height); >>>>>> *} >>>>>> >>>>>> XNetProtocol: >>>>>> boolean >>>>>> doStateProtocol() { >>>>>> ... >>>>>> * >>>>>> stateLog.finer("______doStateProtocol() >>>>>> returns " + >>>>>> >>>>>> >>>>>> res); >>>>>> *} >>>>>> >>>>>> XSystemTrayPeer: >>>>>> >>>>>> XSystemTrayPeer(SystemTray >>>>>> target) { >>>>>> ... >>>>>> * >>>>>> log.fine(" >>>>>> check if >>>>>> system tray is available. >>>>>> selection owner: >>>>>> " + selection_owner); >>>>>> *} >>>>>> void >>>>>> addTrayIcon(XTrayIconPeer tiPeer) >>>>>> throws >>>>>> AWTException { >>>>>> ... >>>>>> * >>>>>> log.fine(" >>>>>> send >>>>>> SYSTEM_TRAY_REQUEST_DOCK >>>>>> message to owner: >>>>>> " + >>>>>> selection_owner); >>>>>> *} >>>>>> >>>>>> XFramePeer: >>>>>> public void >>>>>> handlePropertyNotify(XEvent xev) { >>>>>> ... >>>>>> >>>>>> stateLog.finer("State is the same: " + >>>>>> state); >>>>>> } >>>>>> >>>>>> However I only >>>>>> give >>>>>> here few >>>>>> cases but certainly others >>>>>> are still >>>>>> present in the >>>>>> source code; >>>>>> maybe findbugs or netbeans >>>>>> warnings could >>>>>> help you finding >>>>>> all of them. >>>>>> >>>>>> I advocate the >>>>>> amount of waste >>>>>> (GC) is not very >>>>>> important but >>>>>> String >>>>>> conversion are >>>>>> also >>>>>> calling >>>>>> several toString() methods >>>>>> that can be >>>>>> costly (event, >>>>>> Frame, window ...) >>>>>> >>>>>> Finally, I ran few >>>>>> grep commands >>>>>> on the sun.awt.X11 code >>>>>> (jdk7u) and you >>>>>> can look at them >>>>>> to >>>>>> see all >>>>>> string + operations related >>>>>> to log statements. >>>>>> >>>>>> PS: I may help >>>>>> fixing the source >>>>>> code but I have no idea >>>>>> how to >>>>>> collaborate >>>>>> (provide a patch ?) >>>>>> >>>>>> Regards, >>>>>> Laurent Bourg?s >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Best regards, Sergey. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Best regards, Sergey. From Ulf.Zibis at CoSoCo.de Wed Apr 10 08:47:25 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 10 Apr 2013 10:47:25 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <5165271D.6040904@CoSoCo.de> Hi all, when I see all the extensions on interfaces via the new default construct, I still have the feeling, such entities should be seen and named as "normal" abstract classes. This would additionally allow protected and private members, which otherwise can be a cumbersome restriction. To be compatible to legacy code, IMO it would be enough to extend the usage of keyword "implements" for abstract classes. I'm aware, that there should be some restrictions on such abstract classes to be manageable as interfaces, but not as strict as for current interface default method approach. In fact, the interface default methods is the introduction of multi-inheritance in Java throug the backdoor, so why not give it a prominent full featured place and handle and name it as such? Is there anybody willing to discuss the reasonable for the "lousy" makeshift as I see the default method construct: - verbose ugly syntax - cumbersome restrictions - unnecessary complicated priority rules: - - some of the priority collisions could be handled by simply distinguishing between e.g. "implements Map" and "extends Map" From the call site view, I'm not aware, if it would make any difference, having e.g. j.u.Map as interface or abstract class: Map myMap = new HashMap(); myMap.doSomething(); Regards, -Ulf From bourges.laurent at gmail.com Wed Apr 10 08:58:39 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 10 Apr 2013 10:58:39 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <5164538B.9080804@oracle.com> References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> Message-ID: Dear Jim, 2013/4/9 Jim Graham > > The allocations will always show up on a heap profiler, I don't know of > any way of having them not show up if they are stack allocated, but I don't > think that stack allocation is the issue here - small allocations come out > of a fast generation that costs almost nothing to allocate from and nearly > nothing to clean up. They are actually getting allocated and GC'd, but the > process is optimized. > > The only way to tell is to benchmark and see which changes make a > difference and which are in the noise (or, in some odd counter-intuitive > cases, counter-productive)... > > ...jim > I advocate I like GC because it avoids in Java dealing with pointers like C/C++ does; however, I prefer GC clean real garbage (application...) than wasted memory: I prefer not count on GC when I can avoid wasting memory that gives GC more work = reduce useless garbage (save the planet) ! Moreover, GC and / or Thread local allocation (TLAB) seems to have more overhead than you think = "fast generation that costs almost nothing to allocate from and nearly nothing to clean up". Here are my micro-benchmark results related to int[4] allocation where I mimic the AAShapePipe.fillParallelogram() method: Patch Ref Gain 5,96 8,27 138,76% 7,31 14,96 204,65% 10,65 20,4 191,55% 15,44 29,83 193,20% Test environment: Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus) JVM settings: -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m -Xmx128m Benchmark code (using Peter Levart microbench classes): http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/ My conclusion is: "nothing" > zero (allocation + cleanup) and it is very noticeable in multi threading tests. I advocate that I use a dirty int[4] array (no cleanup) but it is not necessary : maybe the performance gain come from that reason. Finally here is the output with -XX:+PrintTLAB flag: TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 20 waste 1,2% gc: 323712B slow: 600B fast: 0B TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 waste 7,9% gc: 745568B slow: 176B fast: 0B TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 15 waste 3,1% gc: 618464B slow: 448B fast: 0B TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 waste 0,0% gc: 0B slow: 232B fast: 0B TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 1 waste 27,5% gc: 369088B slow: 0B fast: 0B TLAB totals: thrds: 5 refills: 50 max: 20 slow allocs: 0 max 0 waste: 3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B max: 0B I would have expected that TLAB can recycle all useless int[4] arrays as fast as possible => waste = 100% ??? *Is there any bug in TLAB (core-libs) ? Should I send such issue to hotspot team ? * *Test using ThreadLocal AAShapePipeContext:* { AAShapePipeContext ctx = getThreadContext(); int abox[] = ctx.abox; // use array: // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, abox); abox[0] = 7; abox[1] = 11; abox[2] = 13; abox[3] = 17; // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox); devNull1.yield(abox); if (!useThreadLocal) { restoreContext(ctx); } } -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] #------------------------------------------------------------- # ContextGetInt4: run duration: 10 000 ms # # Warm up: # 4 threads, Tavg = 13,84 ns/op (? = 0,23 ns/op), Total ops = 2889056179 [ 13,93 (717199825), 13,87 (720665624), 13,48 (741390545), 14,09 (709800185)] # 4 threads, Tavg = 14,25 ns/op (? = 0,57 ns/op), Total ops = 2811615084 [ 15,21 (658351236), 14,18 (706254551), 13,94 (718202949), 13,74 (728806348)] cleanup (explicit Full GC) ... cleanup done. # Measure: *1 threads, Tavg = 5,96 ns/op (? = 0,00 ns/op), Total ops = 1678357614 [ 5,96 (1678357614)] 2 threads, Tavg = 7,33 ns/op (? = 0,03 ns/op), Total ops = 2729723450 [ 7,31 (1369694121), 7,36 (1360029329)] 3 threads, Tavg = 10,65 ns/op (? = 2,73 ns/op), Total ops = 2817154340 [ 13,24 (755190111), 13,23 (755920429), 7,66 (1306043800)] **4 threads, Tavg = 15,44 ns/op (? = 3,33 ns/op), Total ops = 2589897733 [ 17,05 (586353618), 19,23 (519345153), 17,88 (559401974), 10,81 *(924796988)] # << JVM END *Test using standard int[4] allocation:* { int abox[] = new int[4]; // use array: // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, abox); abox[0] = 7; abox[1] = 11; abox[2] = 13; abox[3] = 17; // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox); devNull1.yield(abox); } -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] #------------------------------------------------------------- # GetInt4: run duration: 10 000 ms # # Warm up: # 4 threads, Tavg = 31,07 ns/op (? = 0,60 ns/op), Total ops = 1287292142 [ 30,26 (330475567), 31,92 (313328449), 31,27 (319805520), 30,89 (323682606)] # 4 threads, Tavg = 30,94 ns/op (? = 0,33 ns/op), Total ops = 1293000783 [ 30,92 (323382193), 30,61 (326730340), 31,48 (317621402), 30,74 (325266848)] cleanup (explicit Full GC) ... cleanup done. # Measure: *1 threads, Tavg = 8,27 ns/op (? = 0,00 ns/op), Total ops = 1209213909 [ 8,27 (1209213909)] 2 threads, Tavg = 14,96 ns/op (? = 0,04 ns/op), Total ops = 1337024734 [ 15,00 (666659967), 14,92 (670364767)] 3 threads, Tavg = 20,40 ns/op (? = 1,03 ns/op), Total ops = 1470560922 [ 21,21 (471592958), 19,00 (526302911), 21,16 (472665053)] **4 threads, Tavg = 29,83 ns/op (? = 1,82 ns/op), Total ops = 1340065128 [ 31,17 (320806983), 31,58 (316358130), 26,94 (370806790), 30,11 *(332093225)] # << JVM END Best regards, Laurent From bourges.laurent at gmail.com Wed Apr 10 09:01:48 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 10 Apr 2013 11:01:48 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <516483D0.2080404@oracle.com> References: <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> Message-ID: Anthony or Mandy, Could you ask JMX / Security groups for me to review my patch ? I am currently not registered to these mailing lists. Do you ask me to split the patch in two part: PlatformLogger on one side and Logger on the other side ? Laurent 2013/4/9 Mandy Chung > On 4/9/13 12:37 AM, Laurent Bourg?s wrote: > > Mandy, > > first I would like to have the given patch applied to OpenJDK 8 (+ JDK7u) > as it fixes many problems: > - string concatenations > - object creations (Object[] or other objects given as params) > - method calls in log statements > > This is the patch you refer to: > http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ > > I agree that we should separate the fix to reduce the memory usage from > the fix to convert JUL to PlatformLogger. I skimmed on your patch - > awt/swing uses PlatformLogger and your change looks fine. You have also > got Anthony's approval. Other component security, jmx, snmp, etc are using > JUL. I would suggest to fix the use of PlatformLogger in your first patch > and AWT/Swing is the main area that 8010297 is concerned about so that you > can resolve 8010297 soon. > > If you want to move ahead to fix use of JUL, you can send your patch to > serviceability-dev at openjdk.java.net and security-dev at openjdk.java.net for > the other areas to review and sponsor. > > Hope this helps. > Mandy > > > In a second step, I can help somebody migrating JUL usages to > PlatformLogger but it requires PlatformLogger API changes (logp to give > class and method names)... > > Other comments below: > >> >> Peter's idea is a good one to add a couple of convenient methods to take >> Object parameters that will avoid the creation of array instances. I'd >> also like to know what variants being used in the jdk to determine the pros >> and cons of the alternatives (this issue also applies to java.util.logging). >> > > 50% of given object parameters are created via method calls so it will not > be enough. > > Moreover, I prefer having always isLoggable() calls to avoid me looking > and understanding special cases (more than 2 args or no string concat ...); > besides, it would be easier to implement code checks testing missing > isLoggable() calls vs conditional and specific checks (string concat, more > then 2 args, method calls ...) > > Finally, I prefer having shorter and clearer method names like isFine(), > isFinest() instead of isLoggable(PlatformLogger.FINE) that is quite "ugly" > ... > > >> It was intentional to have PlatformLogger define only the useful methods >> necessary for jdk use. The goal of PlatformLogger was to provide a >> light-weight utility for jdk to log debugging messages and eliminate the >> dependency to java.util.logging and avoid the unnecessary j.u.logging >> initialization (as disabled by default). It was not a goal for >> PlatformLogger to be an exact mirror as java.util.logging.Logger. My >> advice is to tune PlatformLogger to provide API that helps the platform >> implementation while avoid bloating the API. >> > > Agreed. > > Maybe JUL Logger.logp(classname, methodname) usages should be rewritten to > use PlatformLogger.getCallerInfo() instead: > // Returns the caller's class and method's name; best effort > // if cannot infer, return the logger's name. > private String getCallerInfo() { > String sourceClassName = null; > String sourceMethodName = null; > > * JavaLangAccess access = SharedSecrets.getJavaLangAccess(); > * Throwable throwable = new Throwable(); > int depth = access.getStackTraceDepth(throwable); > > String logClassName = "sun.util.logging.PlatformLogger"; > boolean lookingForLogger = true; > for (int ix = 0; ix < depth; ix++) { > // Calling getStackTraceElement directly prevents the VM > // from paying the cost of building the entire stack frame. > StackTraceElement frame = > access.getStackTraceElement(throwable, ix); > String cname = frame.getClassName(); > if (lookingForLogger) { > // Skip all frames until we have found the first > logger frame. > if (cname.equals(logClassName)) { > lookingForLogger = false; > } > } else { > if (!cname.equals(logClassName)) { > // We've found the relevant frame. > sourceClassName = cname; > sourceMethodName = frame.getMethodName(); > break; > } > } > } > > if (sourceClassName != null) { > return sourceClassName + " " + sourceMethodName; > } else { > return name; > } > } > } > > >> >> Since you are touching some jdk files that use java.util.logging, would >> you like to contribute to convert them to use PlatformLogger: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233 >> >> It's perfectly fine to convert only some of them if not all. >> > > I want to help but as you said it should be done in collaboration because > it requires API changes (JMX, RMI ...) but I prefer after this patch is > reviewed and submitted and in coming weeks. > > >> >> Jim Gish is the owner of logging and will check with him if he has cycles >> to work with you on this. >> > > Great. > > Cheers, > Laurent > > > From Ulf.Zibis at CoSoCo.de Wed Apr 10 09:25:02 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 10 Apr 2013 11:25:02 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <51652FEE.1030400@CoSoCo.de> Hi again, please consider to add hash() to interface Map, as an additional performance opportunity, see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862 It was rejected with: implement a wrapper class for the "key" to customize its hash() & equals() methods Unfortunately my earlier comment on this appears to be lost by migration to Jira, so here again: Instantiating a wrapper object for each key contradicts the purpose of performance tuning and additionally increases memory footprint. -Ulf Am 08.04.2013 20:07, schrieb Mike Duigou: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > 8004518: Add in-place operations to Map > forEach() > replaceAll() > > 8010122: Add atomic operations to Map > getOrDefault() > putIfAbsent() * > remove(K, V) > replace(K, V) > replace(K, V, V) > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * > > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike > From peter.levart at gmail.com Wed Apr 10 10:17:58 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Apr 2013 12:17:58 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> Message-ID: <51653C56.1010306@gmail.com> Hi Laurent, Could you disable tiered compilation for performance tests? Tiered compilation is usually a source of jitter in the results. Pass -XX:-TieredCompilation to the VM. Regards, Peter On 04/10/2013 10:58 AM, Laurent Bourg?s wrote: > Dear Jim, > > 2013/4/9 Jim Graham > > > > The allocations will always show up on a heap profiler, I don't > know of any way of having them not show up if they are stack > allocated, but I don't think that stack allocation is the issue > here - small allocations come out of a fast generation that costs > almost nothing to allocate from and nearly nothing to clean up. > They are actually getting allocated and GC'd, but the process is > optimized. > > The only way to tell is to benchmark and see which changes make a > difference and which are in the noise (or, in some odd > counter-intuitive cases, counter-productive)... > > ...jim > > > I advocate I like GC because it avoids in Java dealing with pointers > like C/C++ does; however, I prefer GC clean real garbage > (application...) than wasted memory: > I prefer not count on GC when I can avoid wasting memory that gives GC > more work = reduce useless garbage (save the planet) ! > > Moreover, GC and / or Thread local allocation (TLAB) seems to have > more overhead than you think = "fast generation that costs almost > nothing to allocate from and nearly nothing to clean up". > > Here are my micro-benchmark results related to int[4] allocation where > I mimic the AAShapePipe.fillParallelogram() method: > Patch Ref Gain > 5,96 8,27 138,76% > 7,31 14,96 204,65% > 10,65 20,4 191,55% > 15,44 29,83 193,20% > > > Test environment: > Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus) > JVM settings: > -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m -Xmx128m > > Benchmark code (using Peter Levart microbench classes): > http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/ > > > My conclusion is: "nothing" > zero (allocation + cleanup) and it is > very noticeable in multi threading tests. > > I advocate that I use a dirty int[4] array (no cleanup) but it is not > necessary : maybe the performance gain come from that reason. > > > Finally here is the output with -XX:+PrintTLAB flag: > TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB > slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: > 20 waste 1,2% gc: 323712B slow: 600B fast: 0B > TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB > slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 > waste 7,9% gc: 745568B slow: 176B fast: 0B > TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB > slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: > 15 waste 3,1% gc: 618464B slow: 448B fast: 0B > TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB > slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 > waste 0,0% gc: 0B slow: 232B fast: 0B > TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB > slow allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 1 > waste 27,5% gc: 369088B slow: 0B fast: 0B > TLAB totals: thrds: 5 refills: 50 max: 20 slow allocs: 0 max 0 > waste: 3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B > max: 0B > > I would have expected that TLAB can recycle all useless int[4] arrays > as fast as possible => waste = 100% ??? > > *Is there any bug in TLAB (core-libs) ? > Should I send such issue to hotspot team ? > * > > *Test using ThreadLocal AAShapePipeContext:* > { > AAShapePipeContext ctx = getThreadContext(); > int abox[] = ctx.abox; > > // use array: > // mimic: AATileGenerator aatg = > renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, > abox); > abox[0] = 7; > abox[1] = 11; > abox[2] = 13; > abox[3] = 17; > > // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, > abox); > devNull1.yield(abox); > > if (!useThreadLocal) { > restoreContext(ctx); > } > } > > -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 > -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags > -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers > -XX:+UseCompressedOops -XX:+UseParallelGC > >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] > #------------------------------------------------------------- > # ContextGetInt4: run duration: 10 000 ms > # > # Warm up: > # 4 threads, Tavg = 13,84 ns/op (? = 0,23 ns/op), > Total ops = 2889056179 [ 13,93 (717199825), 13,87 > (720665624), 13,48 (741390545), 14,09 (709800185)] > # 4 threads, Tavg = 14,25 ns/op (? = 0,57 ns/op), > Total ops = 2811615084 [ 15,21 (658351236), 14,18 > (706254551), 13,94 (718202949), 13,74 (728806348)] > cleanup (explicit Full GC) ... > cleanup done. > # Measure: > *1 threads, Tavg = 5,96 ns/op (? = 0,00 ns/op), Total ops = > 1678357614 [ 5,96 (1678357614)] > 2 threads, Tavg = 7,33 ns/op (? = 0,03 ns/op), Total ops = > 2729723450 [ 7,31 (1369694121), 7,36 (1360029329)] > 3 threads, Tavg = 10,65 ns/op (? = 2,73 ns/op), Total ops = > 2817154340 [ 13,24 (755190111), 13,23 (755920429), 7,66 > (1306043800)] > **4 threads, Tavg = 15,44 ns/op (? = 3,33 ns/op), Total ops = > 2589897733 [ 17,05 (586353618), 19,23 (519345153), 17,88 > (559401974), 10,81 *(924796988)] > # > << JVM END > > *Test using standard int[4] allocation:* > { > int abox[] = new int[4]; > > // use array: > // mimic: AATileGenerator aatg = > renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, > abox); > abox[0] = 7; > abox[1] = 11; > abox[2] = 13; > abox[3] = 17; > > // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, > abox); > devNull1.yield(abox); > } > > -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 > -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags > -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers > -XX:+UseCompressedOops -XX:+UseParallelGC > >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] > #------------------------------------------------------------- > # GetInt4: run duration: 10 000 ms > # > # Warm up: > # 4 threads, Tavg = 31,07 ns/op (? = 0,60 ns/op), > Total ops = 1287292142 [ 30,26 (330475567), 31,92 > (313328449), 31,27 (319805520), 30,89 (323682606)] > # 4 threads, Tavg = 30,94 ns/op (? = 0,33 ns/op), > Total ops = 1293000783 [ 30,92 (323382193), 30,61 > (326730340), 31,48 (317621402), 30,74 (325266848)] > cleanup (explicit Full GC) ... > cleanup done. > # Measure: > *1 threads, Tavg = 8,27 ns/op (? = 0,00 ns/op), Total ops = > 1209213909 [ 8,27 (1209213909)] > 2 threads, Tavg = 14,96 ns/op (? = 0,04 ns/op), Total ops = > 1337024734 [ 15,00 (666659967), 14,92 (670364767)] > 3 threads, Tavg = 20,40 ns/op (? = 1,03 ns/op), Total ops = > 1470560922 [ 21,21 (471592958), 19,00 (526302911), 21,16 > (472665053)] > **4 threads, Tavg = 29,83 ns/op (? = 1,82 ns/op), Total ops = > 1340065128 [ 31,17 (320806983), 31,58 (316358130), 26,94 > (370806790), 30,11 *(332093225)] > # > << JVM END > > Best regards, > Laurent > From anthony.petrov at oracle.com Wed Apr 10 11:19:00 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 10 Apr 2013 15:19:00 +0400 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5149990F.6030408@oracle.com> <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> Message-ID: <51654AA4.30208@oracle.com> Laurent, I'm not subscribed to those mailing list, too. So you could send/forward your review request to the lists yourself - no difference here. Note that I tried sending your message to net-dev@ in the past, and even contacted the maintainer of the mailing list via a private email, but I never got any response and my messages never got accepted. That's the reason I've CC'ed jdk8-dev@ yesterday... -- best regards, Anthony On 4/10/2013 13:01, Laurent Bourg?s wrote: > Anthony or Mandy, > Could you ask JMX / Security groups for me to review my patch ? > > I am currently not registered to these mailing lists. > > Do you ask me to split the patch in two part: PlatformLogger on one side > and Logger on the other side ? > > Laurent > > 2013/4/9 Mandy Chung > > > On 4/9/13 12:37 AM, Laurent Bourg?s wrote: >> Mandy, >> >> first I would like to have the given patch applied to OpenJDK 8 (+ >> JDK7u) as it fixes many problems: >> - string concatenations >> - object creations (Object[] or other objects given as params) >> - method calls in log statements >> > This is the patch you refer to: > http://jmmc.fr/~bourgesl/share/webrev-8010297.3/ > > > I agree that we should separate the fix to reduce the memory usage > from the fix to convert JUL to PlatformLogger. I skimmed on your > patch - awt/swing uses PlatformLogger and your change looks fine. > You have also got Anthony's approval. Other component security, > jmx, snmp, etc are using JUL. I would suggest to fix the use of > PlatformLogger in your first patch and AWT/Swing is the main area > that 8010297 is concerned about so that you can resolve 8010297 soon. > > If you want to move ahead to fix use of JUL, you can send your patch > to serviceability-dev at openjdk.java.net > and > security-dev at openjdk.java.net > for the other areas to review and sponsor. > > Hope this helps. > Mandy > > >> In a second step, I can help somebody migrating JUL usages to >> PlatformLogger but it requires PlatformLogger API changes (logp to >> give class and method names)... >> >> Other comments below: >> >> >> Peter's idea is a good one to add a couple of convenient >> methods to take Object parameters that will avoid the creation >> of array instances. I'd also like to know what variants being >> used in the jdk to determine the pros and cons of the >> alternatives (this issue also applies to java.util.logging). >> >> >> 50% of given object parameters are created via method calls so it >> will not be enough. >> >> Moreover, I prefer having always isLoggable() calls to avoid me >> looking and understanding special cases (more than 2 args or no >> string concat ...); besides, it would be easier to implement code >> checks testing missing isLoggable() calls vs conditional and >> specific checks (string concat, more then 2 args, method calls ...) >> >> Finally, I prefer having shorter and clearer method names like >> isFine(), isFinest() instead of isLoggable(PlatformLogger.FINE) >> that is quite "ugly" ... >> >> >> It was intentional to have PlatformLogger define only the >> useful methods necessary for jdk use. The goal of >> PlatformLogger was to provide a light-weight utility for jdk >> to log debugging messages and eliminate the dependency to >> java.util.logging and avoid the unnecessary j.u.logging >> initialization (as disabled by default). It was not a goal >> for PlatformLogger to be an exact mirror as >> java.util.logging.Logger. My advice is to tune PlatformLogger >> to provide API that helps the platform implementation while >> avoid bloating the API. >> >> >> Agreed. >> >> Maybe JUL Logger.logp(classname, methodname) usages should be >> rewritten to use PlatformLogger.getCallerInfo() instead: >> // Returns the caller's class and method's name; best effort >> // if cannot infer, return the logger's name. >> private String getCallerInfo() { >> String sourceClassName = null; >> String sourceMethodName = null; >> >> * JavaLangAccess access = >> SharedSecrets.getJavaLangAccess(); >> * Throwable throwable = new Throwable(); >> int depth = access.getStackTraceDepth(throwable); >> >> String logClassName = "sun.util.logging.PlatformLogger"; >> boolean lookingForLogger = true; >> for (int ix = 0; ix < depth; ix++) { >> // Calling getStackTraceElement directly prevents >> the VM >> // from paying the cost of building the entire >> stack frame. >> StackTraceElement frame = >> access.getStackTraceElement(throwable, ix); >> String cname = frame.getClassName(); >> if (lookingForLogger) { >> // Skip all frames until we have found the >> first logger frame. >> if (cname.equals(logClassName)) { >> lookingForLogger = false; >> } >> } else { >> if (!cname.equals(logClassName)) { >> // We've found the relevant frame. >> sourceClassName = cname; >> sourceMethodName = frame.getMethodName(); >> break; >> } >> } >> } >> >> if (sourceClassName != null) { >> return sourceClassName + " " + sourceMethodName; >> } else { >> return name; >> } >> } >> } >> >> >> >> Since you are touching some jdk files that use >> java.util.logging, would you like to contribute to convert >> them to use PlatformLogger: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233 >> >> It's perfectly fine to convert only some of them if not all. >> >> >> I want to help but as you said it should be done in collaboration >> because it requires API changes (JMX, RMI ...) but I prefer after >> this patch is reviewed and submitted and in coming weeks. >> >> >> >> Jim Gish is the owner of logging and will check with him if he >> has cycles to work with you on this. >> >> >> Great. >> >> Cheers, >> Laurent >> > > From bourges.laurent at gmail.com Wed Apr 10 11:20:23 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 10 Apr 2013 13:20:23 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <51653C56.1010306@gmail.com> References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <51653C56.1010306@gmail.com> Message-ID: Peter, 1/ I modified your TestRunner class to print total ops and perform explicit GC before runTests: http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/ 2/ I applied your advice but it does not change much: -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] #------------------------------------------------------------- # ContextGetInt4: run duration: 10 000 ms # # Warm up: # 4 threads, Tavg = 13,84 ns/op (? = 0,23 ns/op), Total ops = 2889056179 [ 13,93 (717199825), 13,87 (720665624), 13,48 (741390545), 14,09 (709800185)] # 4 threads, Tavg = 14,25 ns/op (? = 0,57 ns/op), Total ops = 2811615084 [ 15,21 (658351236), 14,18 (706254551), 13,94 (718202949), 13,74 (728806348)] cleanup (explicit Full GC) ... cleanup done. # Measure: 1 threads, Tavg = 5,96 ns/op (? = 0,00 ns/op), Total ops = 1678357614 [ 5,96 (1678357614)] 2 threads, Tavg = 7,33 ns/op (? = 0,03 ns/op), Total ops = 2729723450 [ 7,31 (1369694121), 7,36 (1360029329)] 3 threads, Tavg = 10,65 ns/op (? = 2,73 ns/op), Total ops = 2817154340 [ 13,24 (755190111), 13,23 (755920429), 7,66 (1306043800)] 4 threads, Tavg = 15,44 ns/op (? = 3,33 ns/op), Total ops = 2589897733 [ 17,05 (586353618), 19,23 (519345153), 17,88 (559401974), 10,81 (924796988)] -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -XX:-TieredCompilation -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] #------------------------------------------------------------- # GetInt4: run duration: 10 000 ms # # Warm up: # 4 threads, Tavg = 31,56 ns/op (? = 0,43 ns/op), Total ops = 1267295706 [ 31,30 (319512554), 31,02 (322293333), 32,12 (311334550), 31,82 (314155269)] # 4 threads, Tavg = 30,75 ns/op (? = 1,81 ns/op), Total ops = 1302123211 [ 32,21 (310949394), 32,37 (309275124), 27,87 (359125007), 31,01 (322773686)] cleanup (explicit Full GC) ... cleanup done. # Measure: 1 threads, Tavg = 8,36 ns/op (? = 0,00 ns/op), Total ops = 1196238323 [ 8,36 (1196238323)] 2 threads, Tavg = 14,95 ns/op (? = 0,04 ns/op), Total ops = 1337648720 [ 15,00 (666813210), 14,91 (670835510)] 3 threads, Tavg = 20,65 ns/op (? = 0,99 ns/op), Total ops = 1453119707 [ 19,57 (511100480), 21,97 (455262170), 20,54 (486757057)] 4 threads, Tavg = 30,76 ns/op (? = 0,54 ns/op), Total ops = 1301090278 [ 31,51 (317527231), 30,79 (324921525), 30,78 (325063322), 29,99 (333578200)] # << JVM END 3/ I tried several heap settings: without Xms/Xmx ... but it has almost no effect. *Should I play with TLAB resize / initial size ? or different GC collector (G1 ...) ? Does anybody can explain me what PrintTLAB mean ?* Laurent 2013/4/10 Peter Levart > Hi Laurent, > > Could you disable tiered compilation for performance tests? Tiered > compilation is usually a source of jitter in the results. Pass > -XX:-TieredCompilation to the VM. > > Regards, Peter > > > > On 04/10/2013 10:58 AM, Laurent Bourg?s wrote: > > Dear Jim, > > 2013/4/9 Jim Graham > >> >> The allocations will always show up on a heap profiler, I don't know of >> any way of having them not show up if they are stack allocated, but I don't >> think that stack allocation is the issue here - small allocations come out >> of a fast generation that costs almost nothing to allocate from and nearly >> nothing to clean up. They are actually getting allocated and GC'd, but the >> process is optimized. >> >> The only way to tell is to benchmark and see which changes make a >> difference and which are in the noise (or, in some odd counter-intuitive >> cases, counter-productive)... >> >> ...jim >> > > I advocate I like GC because it avoids in Java dealing with pointers like > C/C++ does; however, I prefer GC clean real garbage (application...) than > wasted memory: > I prefer not count on GC when I can avoid wasting memory that gives GC > more work = reduce useless garbage (save the planet) ! > > Moreover, GC and / or Thread local allocation (TLAB) seems to have more > overhead than you think = "fast generation that costs almost nothing to > allocate from and nearly nothing to clean up". > > Here are my micro-benchmark results related to int[4] allocation where I > mimic the AAShapePipe.fillParallelogram() method: > Patch Ref Gain 5,96 8,27 138,76% 7,31 14,96 204,65% 10,65 20,4 > 191,55% 15,44 29,83 193,20% > Test environment: > Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus) > JVM settings: > -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m -Xmx128m > > Benchmark code (using Peter Levart microbench classes): > http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/ > > My conclusion is: "nothing" > zero (allocation + cleanup) and it is very > noticeable in multi threading tests. > > I advocate that I use a dirty int[4] array (no cleanup) but it is not > necessary : maybe the performance gain come from that reason. > > > Finally here is the output with -XX:+PrintTLAB flag: > TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB slow > allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 20 > waste 1,2% gc: 323712B slow: 600B fast: 0B > TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB slow > allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 waste > 7,9% gc: 745568B slow: 176B fast: 0B > TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB slow > allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 15 > waste 3,1% gc: 618464B slow: 448B fast: 0B > TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB slow > allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 7 waste > 0,0% gc: 0B slow: 232B fast: 0B > TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB slow > allocs: 0 refill waste: 20992B alloc: 1,00000 65600KB refills: 1 waste > 27,5% gc: 369088B slow: 0B fast: 0B > TLAB totals: thrds: 5 refills: 50 max: 20 slow allocs: 0 max 0 waste: > 3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B max: 0B > > I would have expected that TLAB can recycle all useless int[4] arrays as > fast as possible => waste = 100% ??? > > *Is there any bug in TLAB (core-libs) ? > Should I send such issue to hotspot team ? > * > > *Test using ThreadLocal AAShapePipeContext:* > { > AAShapePipeContext ctx = getThreadContext(); > int abox[] = ctx.abox; > > // use array: > // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y, > dx1, dy1, dx2, dy2, 0, 0, clip, abox); > abox[0] = 7; > abox[1] = 11; > abox[2] = 13; > abox[3] = 17; > > // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox); > devNull1.yield(abox); > > if (!useThreadLocal) { > restoreContext(ctx); > } > } > > -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 > -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal > -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC > >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] > #------------------------------------------------------------- > # ContextGetInt4: run duration: 10 000 ms > # > # Warm up: > # 4 threads, Tavg = 13,84 ns/op (? = 0,23 ns/op), Total > ops = 2889056179 [ 13,93 (717199825), 13,87 (720665624), 13,48 > (741390545), 14,09 (709800185)] > # 4 threads, Tavg = 14,25 ns/op (? = 0,57 ns/op), Total > ops = 2811615084 [ 15,21 (658351236), 14,18 (706254551), 13,94 > (718202949), 13,74 (728806348)] > cleanup (explicit Full GC) ... > cleanup done. > # Measure: > *1 threads, Tavg = 5,96 ns/op (? = 0,00 ns/op), Total ops = > 1678357614 [ 5,96 (1678357614)] > 2 threads, Tavg = 7,33 ns/op (? = 0,03 ns/op), Total ops = > 2729723450 [ 7,31 (1369694121), 7,36 (1360029329)] > 3 threads, Tavg = 10,65 ns/op (? = 2,73 ns/op), Total ops = > 2817154340 [ 13,24 (755190111), 13,23 (755920429), 7,66 > (1306043800)] > **4 threads, Tavg = 15,44 ns/op (? = 3,33 ns/op), Total ops = > 2589897733 [ 17,05 (586353618), 19,23 (519345153), 17,88 > (559401974), 10,81 *(924796988)] > # > << JVM END > > *Test using standard int[4] allocation:* > { > int abox[] = new int[4]; > > // use array: > // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y, > dx1, dy1, dx2, dy2, 0, 0, clip, abox); > abox[0] = 7; > abox[1] = 11; > abox[2] = 13; > abox[3] = 17; > > // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox); > devNull1.yield(abox); > } > > -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 > -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal > -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC > >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24] > #------------------------------------------------------------- > # GetInt4: run duration: 10 000 ms > # > # Warm up: > # 4 threads, Tavg = 31,07 ns/op (? = 0,60 ns/op), Total > ops = 1287292142 [ 30,26 (330475567), 31,92 (313328449), 31,27 > (319805520), 30,89 (323682606)] > # 4 threads, Tavg = 30,94 ns/op (? = 0,33 ns/op), Total > ops = 1293000783 [ 30,92 (323382193), 30,61 (326730340), 31,48 > (317621402), 30,74 (325266848)] > cleanup (explicit Full GC) ... > cleanup done. > # Measure: > *1 threads, Tavg = 8,27 ns/op (? = 0,00 ns/op), Total ops = > 1209213909 [ 8,27 (1209213909)] > 2 threads, Tavg = 14,96 ns/op (? = 0,04 ns/op), Total ops = > 1337024734 [ 15,00 (666659967), 14,92 (670364767)] > 3 threads, Tavg = 20,40 ns/op (? = 1,03 ns/op), Total ops = > 1470560922 [ 21,21 (471592958), 19,00 (526302911), 21,16 > (472665053)] > **4 threads, Tavg = 29,83 ns/op (? = 1,82 ns/op), Total ops = > 1340065128 [ 31,17 (320806983), 31,58 (316358130), 26,94 > (370806790), 30,11 *(332093225)] > # > << JVM END > > Best regards, > Laurent > > > From david.holmes at oracle.com Wed Apr 10 11:32:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2013 21:32:45 +1000 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <5165271D.6040904@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <5165271D.6040904@CoSoCo.de> Message-ID: <51654DDD.5020804@oracle.com> Ulf, The discussions you refer to have been happening over a number of years. We are way past that point now. The key point is that default methods do not introduce multiple-inheritance of state, which is where the MI problems lie, and why we would not want to add MI and use abstract classes. Regards, David On 10/04/2013 6:47 PM, Ulf Zibis wrote: > Hi all, > > when I see all the extensions on interfaces via the new default > construct, I still have the feeling, such entities should be seen and > named as "normal" abstract classes. This would additionally allow > protected and private members, which otherwise can be a cumbersome > restriction. > To be compatible to legacy code, IMO it would be enough to extend the > usage of keyword "implements" for abstract classes. I'm aware, that > there should be some restrictions on such abstract classes to be > manageable as interfaces, but not as strict as for current interface > default method approach. > > In fact, the interface default methods is the introduction of > multi-inheritance in Java throug the backdoor, so why not give it a > prominent full featured place and handle and name it as such? > > Is there anybody willing to discuss the reasonable for the "lousy" > makeshift as I see the default method construct: > - verbose ugly syntax > - cumbersome restrictions > - unnecessary complicated priority rules: > - - some of the priority collisions could be handled by simply > distinguishing between e.g. "implements Map" and "extends Map" > > From the call site view, I'm not aware, if it would make any > difference, having e.g. j.u.Map as interface or abstract class: > Map myMap = new HashMap(); > myMap.doSomething(); > > > Regards, > > -Ulf > From vicente.romero at oracle.com Wed Apr 10 11:35:23 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 10 Apr 2013 11:35:23 +0000 Subject: hg: jdk8/tl/langtools: 8011432: javac, compiler regression iterable + captured type Message-ID: <20130410113528.CF196481AF@hg.openjdk.java.net> Changeset: a4be2c2fe0a1 Author: vromero Date: 2013-04-10 12:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a4be2c2fe0a1 8011432: javac, compiler regression iterable + captured type Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java From Alan.Bateman at oracle.com Wed Apr 10 12:01:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Apr 2013 13:01:34 +0100 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <51648444.2010808@oracle.com> References: <51648444.2010808@oracle.com> Message-ID: <5165549E.20502@oracle.com> On 09/04/2013 22:12, Joe Darcy wrote: > Hello, > > Please review my changes for > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > http://cr.openjdk.java.net/~darcy/8011800.0/ > > which add a new method to java.util.Objects to take a Supplier > rather than a String. > > Patch inline below. > > Thanks, > > -Joe > A typo in the javadoc "this methods allows" -> "this method allows". A subjective comment, but I would drop the word "sibling" from the statement. A minor nit with the @param spilling over into a second line is that it might be clearer to indent it so that it's clear where the next tag starts. I see the existing requiresNonNull are inconsistent on this point. The uninteresting Supplier is null case isn't specified, perhaps this is deliberate? A typo in the test at line 208, "rvariant" -> "variant". Also the printed message at line 226 when you get don't pantaloons should say "Supplier" rather than "2-arg". -Alan. From forax at univ-mlv.fr Wed Apr 10 12:02:25 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Apr 2013 14:02:25 +0200 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <51648444.2010808@oracle.com> References: <51648444.2010808@oracle.com> Message-ID: <516554D1.4070807@univ-mlv.fr> On 04/09/2013 11:12 PM, Joe Darcy wrote: > Hello, > > Please review my changes for > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > http://cr.openjdk.java.net/~darcy/8011800.0/ > > which add a new method to java.util.Objects to take a Supplier > rather than a String. > > Patch inline below. > > Thanks, > > -Joe It's premature in my opinion to introduce this kind of method in the API. The cost of creating a lambda the first time is actually even worst as the one of loading an inner class. Objects.requireNonNull should be a quick check, not something that involve to load a new class. It's true that the JIT will optimize the lambda creation but there are lot of codes that are never JITed, typically less than 20% of the code of a program is JITed. Adding this API will slow down the startup time of a program, Java is known to be slow at startup, in fact, the VM is not that slow, the JDK and the application are slow to startup. It's not a good idea to provide a way to make the startup of an application slower that it needs to be. R?mi > > --- old/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/src/share/classes/java/util/Objects.java 2013-04-09 > 14:08:33.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -25,6 +25,8 @@ > > package java.util; > > +import java.util.function.Supplier; > + > /** > * This class consists of {@code static} utility methods for operating > * on objects. These utilities include {@code null}-safe or {@code > @@ -226,4 +228,31 @@ > throw new NullPointerException(message); > return obj; > } > + > + /** > + * Checks that the specified object reference is not {@code null} > and > + * throws a customized {@link NullPointerException} if it is. > + * > + *

Compared to the sibling method {@link requireNonNull(Object, > + * String}, this methods allows creation of the message to be > + * deferred until after the null check is made. Note that if the > + * supplier is provided via a lambda expression, there can be an > + * overhead involved in creating the supplier. Therefore, while > + * this method may confer a net performance advantage in the > + * non-null case, it is most likely to do so if creating the > + * message string is expensive. > + * > + * @param obj the object reference to check for nullity > + * @param messageSupplier supplier of the detail message to be > + * used in the event that a {@code NullPointerException} is thrown > + * @param the type of the reference > + * @return {@code obj} if not {@code null} > + * @throws NullPointerException if {@code obj} is {@code null} > + * @since 1.8 > + */ > + public static T requireNonNull(T obj, Supplier > messageSupplier) { > + if (obj == null) > + throw new NullPointerException(messageSupplier.get()); > + return obj; > + } > } > --- old/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > +++ new/test/java/util/Objects/BasicObjectsTest.java 2013-04-09 > 14:08:34.000000000 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 6797535 6889858 6891113 > + * @bug 6797535 6889858 6891113 8011800 > * @summary Basic tests for methods in java.util.Objects > * @author Joseph D. Darcy > */ > @@ -166,17 +166,17 @@ > try { > s = Objects.requireNonNull("pants"); > if (s != "pants") { > - System.err.printf("1-arg non-null failed to return > its arg"); > + System.err.printf("1-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("1-arg nonNull threw unexpected NPE"); > + System.err.printf("1-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null); > - System.err.printf("1-arg nonNull failed to throw NPE"); > + System.err.printf("1-arg requireNonNull failed to throw > NPE"); > errors++; > } catch (NullPointerException e) { > // Expected > @@ -186,17 +186,40 @@ > try { > s = Objects.requireNonNull("pants", "trousers"); > if (s != "pants") { > - System.err.printf("2-arg nonNull failed to return its > arg"); > + System.err.printf("2-arg requireNonNull failed to > return its arg"); > errors++; > } > } catch (NullPointerException e) { > - System.err.printf("2-arg nonNull threw unexpected NPE"); > + System.err.printf("2-arg requireNonNull threw unexpected > NPE"); > errors++; > } > > try { > s = Objects.requireNonNull(null, "pantaloons"); > - System.err.printf("2-arg nonNull failed to throw NPE"); > + System.err.printf("2-arg requireNonNull failed to throw > NPE"); > + errors++; > + } catch (NullPointerException e) { > + if (e.getMessage() != "pantaloons") { > + System.err.printf("2-arg requireNonNull threw NPE w/ > bad detail msg"); > + errors++; > + } > + } > + > + // Test supplier rvariant > + try { > + s = Objects.requireNonNull("pants", () -> "trousers"); > + if (s != "pants") { > + System.err.printf("Supplier requireNonNull failed to > return its arg"); > + errors++; > + } > + } catch (NullPointerException e) { > + System.err.printf("Supplier nonNull threw unexpected NPE"); > + errors++; > + } > + > + try { > + s = Objects.requireNonNull(null, () -> "pantaloons"); > + System.err.printf("Suppiler requireNonNull failed to > throw NPE"); > errors++; > } catch (NullPointerException e) { > if (e.getMessage() != "pantaloons") { > From peter.levart at gmail.com Wed Apr 10 12:35:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Apr 2013 14:35:24 +0200 Subject: Proxy.isProxyClass scalability In-Reply-To: <5106A397.1060203@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> Message-ID: <51655C8C.8050809@gmail.com> Hi Alan, I have prepared new webrev of the patch rebased to current tip of jdk8/tl repo: https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html I noticed there were quite a few changes to the j.l.r.Proxy in the meanwhile regarding new security checks. But @CallerSensitive changes seem not to have been pushed yet. Anyway, I have also simplified the caching logic a bit so that it's now easier to reason about it's correctness. I have re-run the performance benchmarks that are still very favourable: https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results.txt Proxy.getProxyClass(): is almost 15x faster single-threaded with same or even slightly better scalability Proxy.isProxyClass() == true: is about 9x faster for single-threaded execution and much more scalable Proxy.isProxyClass() == false: is about 1600x faster single-threaded and infinitely scalable Annotation.equals(): is 1.6x faster single-threaded and much more scalable I also devised an alternative caching mechanism with scalability in mind which uses WeakReferences for keys (for example ClassLoader) and values (for example Class) that could be used in this situation in case adding a field to ClassLoader is not an option: https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/WeakCache.java Regards, Peter On 01/28/2013 05:13 PM, Peter Levart wrote: > Hi Alan, > > I prepared the variant with lazy initialization of ConcurrentHashMaps > per ClassLoader and performance measurements show no differences. So > here's this variant: > > * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html > > I also checked the ClassLoader layout and as it happens the additional > pointer slot increases the ClassLoader object size by 8 bytes in both > addressing modes: 32bit and 64bit. But that's a small overhead > compared to for example the deep-size of AppClassLoader at the > beginning of the main method: 14648 bytes (32bit) / 22432 bytes (64bit). > > Regards, Peter > > On 01/28/2013 01:57 PM, Peter Levart wrote: >> On 01/28/2013 12:49 PM, Alan Bateman wrote: >>> On 25/01/2013 17:55, Peter Levart wrote: >>>> >>>> : >>>> >>>> The solution is actually very simple. I just want to validate my >>>> reasoning before jumping to implement it: >>>> >>>> - for solving scalability of getProxyClass cache, a field with a >>>> reference to ConcurrentHashMap, Class>>> Proxy>> is added to j.l.ClassLoader >>>> - for solving scalability of isProxyClass, a field with a reference >>>> to ConcurrentHashMap, Boolean> is added to >>>> j.l.ClassLoader >>> I haven't had time to look very closely as your more recent changes >>> (you are clearly doing very good work here). The only thing I wonder >>> if whether it would be possible to avoid adding to ClassLoader. I >>> can't say what percentage of frameworks and applications use proxies >>> but it would be nice if the impact on applications that don't use >>> proxies is zero. >> Hi Alan, >> >> Hm, well. Any application that uses run-time annotations, is >> implicitly using Proxies. But I agree that there are applications >> that don't use either. Such applications usually don't use many >> ClassLoaders either. Applications that use many ClassLoaders are >> typically application servers or applications written for modular >> systems (such as OSGI or NetBeans) and all those applications are >> also full of runtime annotations nowadays. So a typical application >> that does not use neither Proxies nor runtime annotations is composed >> of bootstrap classloader, AppClassLoader and ExtClassLoader. The >> ConcurrentHashMap for the bootstrap classloader is hosted by >> j.l.r.Proxy class and is only initialized when the j.l.r.Proxy class >> is initialized - so in this case never. The overhead for such >> applications is therefore an empty ConcurrentHashMap instance plus >> the overhead for a pointer slot in the ClassLoader object multiplied >> by the number of ClassLoaders (typically 2). An empty >> ConcurrentHashMap in JDK8 is only pre-allocating a single internal >> Segment: >> >> java.util.concurrent.ConcurrentHashMap at 642b6fc7(48 bytes) { >> keySet: null >> values: null >> hashSeed: int >> segmentMask: int >> segmentShift: int >> segments: >> java.util.concurrent.ConcurrentHashMap$Segment[16]@8e1dfb1(80 bytes) { >> java.util.concurrent.ConcurrentHashMap$Segment at 2524e205(40 bytes) { >> sync: >> java.util.concurrent.locks.ReentrantLock$NonfairSync at 17feafba(32 >> bytes) { >> exclusiveOwnerThread: null >> head: null >> tail: null >> state: int >> }->(32 deep bytes) >> table: >> java.util.concurrent.ConcurrentHashMap$HashEntry[2]@1c3aacb4(24 bytes) { >> null >> null >> }->(24 deep bytes) >> count: int >> modCount: int >> threshold: int >> loadFactor: float >> }->(96 deep bytes) >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> null >> }->(176 deep bytes) >> keySet: null >> entrySet: null >> values: null >> }->(224 deep bytes) >> >> ...therefore the overhead is approx. 224+4 = 228 bytes (on 32 bit >> pointer environments) per ClassLoader. In typical application (with 2 >> ClassLoader objects) this amounts to approx. 456 bytes. >> >> Is 456 bytes overhead too much? >> >> If it is, I could do lazy initialization of per-classloader CHM >> instances, but then the fast-path would incur a little additional >> penalty (not to be taken seriously though). >> >> Regards, Peter >> >> P.S. I was inspecting the ClassValue internal implementation. This is >> a very nice piece of Java code. Without using any Unsafe magic, it >> provides a perfect performant an scalable map of lazily initialized >> independent data structures associated with Class instances. There's >> nothing special about ClassValue/ClassValueMap that would tie it to >> Class instances. In fact I think the ClassValueMap could be made >> generic so it could be reused for implementing a ClasLoaderValue, for >> example. This would provide a more performant and scalable >> alternative to using WeakHashMap wrapped by >> synchronized wrappers for other uses. >> If anything like that happens in the future, the proposed patch can >> be quickly adapted to using that infrastructure instead of a direct >> reference in the ClassLoader. >> >>> >>> -Alan >> > From paul.sandoz at oracle.com Wed Apr 10 13:50:36 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Apr 2013 15:50:36 +0200 Subject: RFR JDK-8011426: java.util collection Spliterator implementations Message-ID: Hi, Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011426/webrev/ This is dependent on [1]. -- Note that for some reason the webrev script creates the jdk changeset file for my complete hg patch queue and not from the revision i specify. Anyone know how to change that? Paul. [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ From paul.sandoz at oracle.com Wed Apr 10 13:56:37 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Apr 2013 15:56:37 +0200 Subject: RFR JDK-8011427: java.util.concurrent collection Spliterator implementations Message-ID: <5E609919-54FE-4949-A65A-C51DBB7E4409@oracle.com> Hi, Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util.concurrent. More precisely it represents updates from JSR 166 for collection classes that implement spliterators: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011427/webrev/ This is dependent on [1]. -- Like the previous webrev for collections in java.util this webrev contains the jdk changset file for my complete hg patch queue and not from the revision i specify. Also, i am getting errors such as: /usr/bin/awk: limited to 50 pat,pat statements at source line 89 source file /tmp/87498.file1 when generating HTML diff files for ConcurrentHashMap.java and ConcurrentSkipListMap.java. Anyone know how to resolve that? Paul. [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ From peter.levart at gmail.com Wed Apr 10 15:03:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Apr 2013 17:03:05 +0200 Subject: RFR JDK-8011427: java.util.concurrent collection Spliterator implementations In-Reply-To: <5E609919-54FE-4949-A65A-C51DBB7E4409@oracle.com> References: <5E609919-54FE-4949-A65A-C51DBB7E4409@oracle.com> Message-ID: <51657F29.6040702@gmail.com> On 04/10/2013 03:56 PM, Paul Sandoz wrote: > Hi, > > Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util.concurrent. More precisely it represents updates from JSR 166 for collection classes that implement spliterators: > > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011427/webrev/ > > This is dependent on [1]. > > -- > > Like the previous webrev for collections in java.util this webrev contains the jdk changset file for my complete hg patch queue and not from the revision i specify. > > Also, i am getting errors such as: > > /usr/bin/awk: limited to 50 pat,pat statements at source line 89 source file /tmp/87498.file1 > > when generating HTML diff files for ConcurrentHashMap.java and ConcurrentSkipListMap.java. > > Anyone know how to resolve that? Hi Paul, Use Linux. I mean "gawk" has no such limitation. ;-) Regards, Peter > > Paul. > > > [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ From mandy.chung at oracle.com Wed Apr 10 15:33:49 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Apr 2013 08:33:49 -0700 Subject: Proxy.isProxyClass scalability In-Reply-To: <51655C8C.8050809@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> Message-ID: <5165865D.9050702@oracle.com> On 4/10/2013 5:35 AM, Peter Levart wrote: > Hi Alan, > > I have prepared new webrev of the patch rebased to current tip of > jdk8/tl repo: > > https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html > > > I noticed there were quite a few changes to the j.l.r.Proxy in the > meanwhile regarding new security checks. But @CallerSensitive changes > seem not to have been pushed yet. > This has been waiting for the VM support which is now in jdk8/hotspot. Once TL is synced up jdk8 master (soon be this week), I'll push the changes. > Anyway, I have also simplified the caching logic a bit so that it's > now easier to reason about it's correctness. I have re-run the > performance benchmarks that are still very favourable: > > https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results.txt > > > Proxy.getProxyClass(): is almost 15x faster single-threaded with same > or even slightly better scalability > Proxy.isProxyClass() == true: is about 9x faster for single-threaded > execution and much more scalable > Proxy.isProxyClass() == false: is about 1600x faster single-threaded > and infinitely scalable > Annotation.equals(): is 1.6x faster single-threaded and much more > scalable That's great improvement. I have another patch in Proxy coming out for review soon. When I get several urgent things on my plate done, I'll take a look at your patch and get back to you this week hopefully. Mandy > > I also devised an alternative caching mechanism with scalability in > mind which uses WeakReferences for keys (for example ClassLoader) and > values (for example Class) that could be used in this situation in > case adding a field to ClassLoader is not an option: > > https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/WeakCache.java > > > > Regards, Peter > > > On 01/28/2013 05:13 PM, Peter Levart wrote: >> Hi Alan, >> >> I prepared the variant with lazy initialization of ConcurrentHashMaps >> per ClassLoader and performance measurements show no differences. So >> here's this variant: >> >> * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html >> >> I also checked the ClassLoader layout and as it happens the >> additional pointer slot increases the ClassLoader object size by 8 >> bytes in both addressing modes: 32bit and 64bit. But that's a small >> overhead compared to for example the deep-size of AppClassLoader at >> the beginning of the main method: 14648 bytes (32bit) / 22432 bytes >> (64bit). >> >> Regards, Peter >> >> On 01/28/2013 01:57 PM, Peter Levart wrote: >>> On 01/28/2013 12:49 PM, Alan Bateman wrote: >>>> On 25/01/2013 17:55, Peter Levart wrote: >>>>> >>>>> : >>>>> >>>>> The solution is actually very simple. I just want to validate my >>>>> reasoning before jumping to implement it: >>>>> >>>>> - for solving scalability of getProxyClass cache, a field with a >>>>> reference to ConcurrentHashMap, Class>>>> Proxy>> is added to j.l.ClassLoader >>>>> - for solving scalability of isProxyClass, a field with a >>>>> reference to ConcurrentHashMap, Boolean> is >>>>> added to j.l.ClassLoader >>>> I haven't had time to look very closely as your more recent changes >>>> (you are clearly doing very good work here). The only thing I >>>> wonder if whether it would be possible to avoid adding to >>>> ClassLoader. I can't say what percentage of frameworks and >>>> applications use proxies but it would be nice if the impact on >>>> applications that don't use proxies is zero. >>> Hi Alan, >>> >>> Hm, well. Any application that uses run-time annotations, is >>> implicitly using Proxies. But I agree that there are applications >>> that don't use either. Such applications usually don't use many >>> ClassLoaders either. Applications that use many ClassLoaders are >>> typically application servers or applications written for modular >>> systems (such as OSGI or NetBeans) and all those applications are >>> also full of runtime annotations nowadays. So a typical application >>> that does not use neither Proxies nor runtime annotations is >>> composed of bootstrap classloader, AppClassLoader and >>> ExtClassLoader. The ConcurrentHashMap for the bootstrap classloader >>> is hosted by j.l.r.Proxy class and is only initialized when the >>> j.l.r.Proxy class is initialized - so in this case never. The >>> overhead for such applications is therefore an empty >>> ConcurrentHashMap instance plus the overhead for a pointer slot in >>> the ClassLoader object multiplied by the number of ClassLoaders >>> (typically 2). An empty ConcurrentHashMap in JDK8 is only >>> pre-allocating a single internal Segment: >>> >>> java.util.concurrent.ConcurrentHashMap at 642b6fc7(48 bytes) { >>> keySet: null >>> values: null >>> hashSeed: int >>> segmentMask: int >>> segmentShift: int >>> segments: >>> java.util.concurrent.ConcurrentHashMap$Segment[16]@8e1dfb1(80 bytes) { >>> java.util.concurrent.ConcurrentHashMap$Segment at 2524e205(40 bytes) { >>> sync: >>> java.util.concurrent.locks.ReentrantLock$NonfairSync at 17feafba(32 >>> bytes) { >>> exclusiveOwnerThread: null >>> head: null >>> tail: null >>> state: int >>> }->(32 deep bytes) >>> table: >>> java.util.concurrent.ConcurrentHashMap$HashEntry[2]@1c3aacb4(24 >>> bytes) { >>> null >>> null >>> }->(24 deep bytes) >>> count: int >>> modCount: int >>> threshold: int >>> loadFactor: float >>> }->(96 deep bytes) >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> null >>> }->(176 deep bytes) >>> keySet: null >>> entrySet: null >>> values: null >>> }->(224 deep bytes) >>> >>> ...therefore the overhead is approx. 224+4 = 228 bytes (on 32 bit >>> pointer environments) per ClassLoader. In typical application (with >>> 2 ClassLoader objects) this amounts to approx. 456 bytes. >>> >>> Is 456 bytes overhead too much? >>> >>> If it is, I could do lazy initialization of per-classloader CHM >>> instances, but then the fast-path would incur a little additional >>> penalty (not to be taken seriously though). >>> >>> Regards, Peter >>> >>> P.S. I was inspecting the ClassValue internal implementation. This >>> is a very nice piece of Java code. Without using any Unsafe magic, >>> it provides a perfect performant an scalable map of lazily >>> initialized independent data structures associated with Class >>> instances. There's nothing special about ClassValue/ClassValueMap >>> that would tie it to Class instances. In fact I think the >>> ClassValueMap could be made generic so it could be reused for >>> implementing a ClasLoaderValue, for example. This would provide a >>> more performant and scalable alternative to using >>> WeakHashMap wrapped by synchronized wrappers for >>> other uses. >>> If anything like that happens in the future, the proposed patch can >>> be quickly adapted to using that infrastructure instead of a direct >>> reference in the ClassLoader. >>> >>>> >>>> -Alan >>> >> > From Ulf.Zibis at CoSoCo.de Wed Apr 10 17:19:42 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 10 Apr 2013 19:19:42 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <51654DDD.5020804@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <5165271D.6040904@CoSoCo.de> <51654DDD.5020804@oracle.com> Message-ID: <51659F2E.8060905@CoSoCo.de> Thanks David, Am 10.04.2013 13:32, schrieb David Holmes: > Ulf, > > The discussions you refer to have been happening over a number of years. We are way past that > point now. Yes, it's a pity, that I haven't followed those discussions early enough. Theoretically, Java 8 is not final now, but I understand, that changing this now would be a BIG work. > > The key point is that default methods do not introduce multiple-inheritance of state, which is > where the MI problems lie, and why we would not want to add MI and use abstract classes. Yes, that's what I meant with some restrictions on abstract classes to be "implementable", they should be stateless, at least for the first round. My main concern was about the complicated/ugly syntax and priority priority rules on the default method approach. Thanks for your feedback, -Ulf > > Regards, > David > > > > On 10/04/2013 6:47 PM, Ulf Zibis wrote: >> Hi all, >> >> when I see all the extensions on interfaces via the new default >> construct, I still have the feeling, such entities should be seen and >> named as "normal" abstract classes. This would additionally allow >> protected and private members, which otherwise can be a cumbersome >> restriction. >> To be compatible to legacy code, IMO it would be enough to extend the >> usage of keyword "implements" for abstract classes. I'm aware, that >> there should be some restrictions on such abstract classes to be >> manageable as interfaces, but not as strict as for current interface >> default method approach. >> >> In fact, the interface default methods is the introduction of >> multi-inheritance in Java throug the backdoor, so why not give it a >> prominent full featured place and handle and name it as such? >> >> Is there anybody willing to discuss the reasonable for the "lousy" >> makeshift as I see the default method construct: >> - verbose ugly syntax >> - cumbersome restrictions >> - unnecessary complicated priority rules: >> - - some of the priority collisions could be handled by simply >> distinguishing between e.g. "implements Map" and "extends Map" >> >> From the call site view, I'm not aware, if it would make any >> difference, having e.g. j.u.Map as interface or abstract class: >> Map myMap = new HashMap(); >> myMap.doSomething(); >> >> >> Regards, >> >> -Ulf >> > From john.zavgren at oracle.com Wed Apr 10 17:54:34 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Wed, 10 Apr 2013 13:54:34 -0400 Subject: RFR-8008118 In-Reply-To: <20130329135908.9CACE97129@rebar.astron.com> References: <20130329135908.9CACE97129@rebar.astron.com> Message-ID: <5165A75A.9090309@oracle.com> Greetings: There is a new webrev image available for your inspection that fixes all identified bugs: http://cr.openjdk.java.net/~jzavgren/8008118/webrev.07/ Your comments are welcome. Thanks! John On 03/29/2013 09:59 AM, christos at zoulas.com wrote: > On Mar 28, 8:42pm, martinrb at google.com (Martin Buchholz) wrote: > -- Subject: Re: RFR-8008118 > > | Latest webrev does it this way: > | > | for (i = 0; i < count; i++) { > | char *q = p + strcspn(p, ":"); > | pathv[i] = (p == q) ? "." : p; > | *q = '\0'; > | p = q + 1; > | } > > I prefer to have loops where the sentinel is the actual condition instead > of something computed independently, but that's fine too. > > christos > > PS: Can we please add strsep(3) to solaris at some point? Everyone else > relevant seems to have it. -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From henry.jen at oracle.com Wed Apr 10 18:00:01 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 10 Apr 2013 11:00:01 -0700 Subject: RFR: 8010279 - Comparators should throw NPE on null argument Message-ID: <5165A8A1.7090407@oracle.com> Hi, The bug is reported on lambda repo, part of the fix involved code already integrated into TL/master, thus need help on review and commit. Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ Simple changes in the code, with a little restructure of jtreg test to fit convention. Cheers, Henry From Alan.Bateman at oracle.com Wed Apr 10 18:09:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Apr 2013 19:09:53 +0100 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: <5165A8A1.7090407@oracle.com> References: <5165A8A1.7090407@oracle.com> Message-ID: <5165AAF1.3000800@oracle.com> On 10/04/2013 19:00, Henry Jen wrote: > Hi, > > The bug is reported on lambda repo, part of the fix involved code > already integrated into TL/master, thus need help on review and commit. > > Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ > > Simple changes in the code, with a little restructure of jtreg test to > fit convention. > > Cheers, > Henry Looks okay to me. Rather than adding T8010279.java then you could just add to the existing unit test with a testNulls if you want. -Alan From mike.duigou at oracle.com Wed Apr 10 18:12:50 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 11:12:50 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: On Apr 9 2013, at 19:56 , Martin Buchholz wrote: > Mike, thanks. > > I don't see anything wrong in this version, although the ongoing complexification and special-case-ification (with attendant risk of bugs) of ArrayList and HashMap, the two most didactically important classes, continue to bother me. This change continues to feel marginal. It was surprising to find just how many ArrayList and HashMap instances were empty and/or never used. Unfortunately it's harder to globally fix applications than it is to and special case code to ArrayList and HashMap. > Anyways, this is OK with me if it's OK with Alan. > > The original code that shifts by one every time has a certain elegance, and because it's rare to need more than one doubling, is also hard to beat performance-wise. > > 546 while (newCapacity < targetCapacity) > 547 newCapacity <<= 1; I will restore it. > There are now so many "if (isEmpty())" checks that I wonder again whether it would be better to use a null for the empty table, since null checks are closer to free. The use of an empty array rather than null was suggested by John Rose who said: > I recommend an empty array rather than null as a sentinel value for two reasons: > > 1. The JVM prefers to merge null checks into load or store instructions (so-called "implicit null checks") because it removes an explicit branch. But it only does so if the probability of nulls is zero or very low. But using null as a sentinel for common states (e.g., empty collection) defeats this optimization. > > 2. For power-of-two sized structures (HashMap) we can optimize away an array range check in the presence of a zero-length check. > > Since most uses of a variable-sized collection load and test the array length, the sentinel check can easily be overloaded onto this test. If null is not used, then the (safety-mandated) null check is (usually) merged into the load of the length. If the table is power-of-two-sized, then only the zero check remains, and the array range check may be removed. This is thought to be the best code for a frequent load from a possibly-empty collection. > > Mike asked, "what about empty collection?" This is a reasonable thing to use, but it has a cost. The JVM uses inline caches and type profiles to simplify its optimized code; these techniques "win" when at a given use point (individual call to Map.get, for example) there is only one class present, even if the interface is totally general. (This is the so-called "monomorphic" case.) If the application uses (say) only HashMaps for both empty and non-empty maps, then this optimization can win big. It can be broken, on the other hand, if the application begins to use one other type for some other case (such as empty maps). In these cases, it is better to overload the "am I empty?" test on some other loaded value, such as a null or (better) an array length. Mike From martinrb at google.com Wed Apr 10 18:14:37 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 11:14:37 -0700 Subject: RFR-8008118 In-Reply-To: <5165A75A.9090309@oracle.com> References: <20130329135908.9CACE97129@rebar.astron.com> <5165A75A.9090309@oracle.com> Message-ID: I am happy with the latest webrev - ship it! Thanks, John! On Wed, Apr 10, 2013 at 10:54 AM, John Zavgren wrote: > Greetings: > > There is a new webrev image available for your inspection that fixes all > identified bugs: > http://cr.openjdk.java.net/~jzavgren/8008118/webrev.07/ > > Your comments are welcome. > > Thanks! > John > > > On 03/29/2013 09:59 AM, christos at zoulas.com wrote: > > On Mar 28, 8:42pm, martinrb at google.com (Martin Buchholz) wrote: > -- Subject: Re: RFR-8008118 > > | Latest webrev does it this way: > | > | for (i = 0; i < count; i++) { > | char *q = p + strcspn(p, ":"); > | pathv[i] = (p == q) ? "." : p; > | *q = '\0'; > | p = q + 1; > | } > > I prefer to have loops where the sentinel is the actual condition instead > of something computed independently, but that's fine too. > > christos > > PS: Can we please add strsep(3) to solaris at some point? Everyone else > relevant seems to have it. > > > > -- > John Zavgrenjohn.zavgren at oracle.com603-821-0904 > US-Burlington-MA > > From mike.duigou at oracle.com Wed Apr 10 18:20:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 11:20:44 -0700 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: <5165A8A1.7090407@oracle.com> References: <5165A8A1.7090407@oracle.com> Message-ID: Looks OK to me. Mike On Apr 10 2013, at 11:00 , Henry Jen wrote: > Hi, > > The bug is reported on lambda repo, part of the fix involved code > already integrated into TL/master, thus need help on review and commit. > > Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ > > Simple changes in the code, with a little restructure of jtreg test to > fit convention. > > Cheers, > Henry From christos at zoulas.com Wed Apr 10 18:24:46 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 10 Apr 2013 14:24:46 -0400 Subject: RFR-8008118 In-Reply-To: <5165A75A.9090309@oracle.com> from John Zavgren (Apr 10, 1:54pm) Message-ID: <20130410182446.3FE2497129@rebar.astron.com> On Apr 10, 1:54pm, john.zavgren at oracle.com (John Zavgren) wrote: -- Subject: Re: RFR-8008118 | Your comments are welcome. 1. We did we switch from NEW() to xmalloc()? Why is the xmalloc cast needed? 2. I would not declare pathv "const char **", but "char **", and then cast the return if needed. This will make life easier in the future if we decide to turn on warnings about const-castaways. Otherwise LGTM. christos From forax at univ-mlv.fr Wed Apr 10 18:24:49 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Apr 2013 20:24:49 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <51659F2E.8060905@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <5165271D.6040904@CoSoCo.de> <51654DDD.5020804@oracle.com> <51659F2E.8060905@CoSoCo.de> Message-ID: <5165AE71.8040909@univ-mlv.fr> On 04/10/2013 07:19 PM, Ulf Zibis wrote: > Thanks David, > > Am 10.04.2013 13:32, schrieb David Holmes: >> Ulf, >> >> The discussions you refer to have been happening over a number of >> years. We are way past that point now. > > Yes, it's a pity, that I haven't followed those discussions early > enough. Theoretically, Java 8 is not final now, but I understand, that > changing this now would be a BIG work. > >> >> The key point is that default methods do not introduce >> multiple-inheritance of state, which is where the MI problems lie, >> and why we would not want to add MI and use abstract classes. > > Yes, that's what I meant with some restrictions on abstract classes to > be "implementable", they should be stateless, at least for the first > round. My main concern was about the complicated/ugly syntax and > priority priority rules on the default method approach. interface + default methods are conceptually what is known as traits(*), you can see them as interface + method with code or as abstract class without state, it's the same thing. Now, if you want traits in Java, you have 3 choices: add a new kind of type, trait, introduce a stateless abstract class or add default methods to interface. All these changes require to change the VM, so all of them are *big* changes. The lambda expert group studies each solution and adding default methods to interface is the path that creates less problems, that why it was chosen. > > Thanks for your feedback, > > -Ulf R?mi * for Scalaist, Scala traits are not traits or at least not traits as usually defined, the usual definition says that a trait is stateless. > > >> >> Regards, >> David >> >> >> >> On 10/04/2013 6:47 PM, Ulf Zibis wrote: >>> Hi all, >>> >>> when I see all the extensions on interfaces via the new default >>> construct, I still have the feeling, such entities should be seen and >>> named as "normal" abstract classes. This would additionally allow >>> protected and private members, which otherwise can be a cumbersome >>> restriction. >>> To be compatible to legacy code, IMO it would be enough to extend the >>> usage of keyword "implements" for abstract classes. I'm aware, that >>> there should be some restrictions on such abstract classes to be >>> manageable as interfaces, but not as strict as for current interface >>> default method approach. >>> >>> In fact, the interface default methods is the introduction of >>> multi-inheritance in Java throug the backdoor, so why not give it a >>> prominent full featured place and handle and name it as such? >>> >>> Is there anybody willing to discuss the reasonable for the "lousy" >>> makeshift as I see the default method construct: >>> - verbose ugly syntax >>> - cumbersome restrictions >>> - unnecessary complicated priority rules: >>> - - some of the priority collisions could be handled by simply >>> distinguishing between e.g. "implements Map" and "extends Map" >>> >>> From the call site view, I'm not aware, if it would make any >>> difference, having e.g. j.u.Map as interface or abstract class: >>> Map myMap = new HashMap(); >>> myMap.doSomething(); >>> >>> >>> Regards, >>> >>> -Ulf >>> >> > From forax at univ-mlv.fr Wed Apr 10 18:26:21 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Apr 2013 20:26:21 +0200 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: References: <5165A8A1.7090407@oracle.com> Message-ID: <5165AECD.4070902@univ-mlv.fr> On 04/10/2013 08:20 PM, Mike Duigou wrote: > Looks OK to me. > > Mike Ok for me too. R?mi > > On Apr 10 2013, at 11:00 , Henry Jen wrote: > >> Hi, >> >> The bug is reported on lambda repo, part of the fix involved code >> already integrated into TL/master, thus need help on review and commit. >> >> Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ >> >> Simple changes in the code, with a little restructure of jtreg test to >> fit convention. >> >> Cheers, >> Henry From andrea.aime at geo-solutions.it Wed Apr 10 08:24:04 2013 From: andrea.aime at geo-solutions.it (Andrea Aime) Date: Wed, 10 Apr 2013 10:24:04 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> Message-ID: On Wed, Apr 10, 2013 at 10:14 AM, Laurent Bourg?s wrote: > Andrea, > I am running benchmarks on my laptop (i7 - 2 core 2.8Ghz + HT => 4 virtual > cpus) on linux 64 (fedora 14). > Note: I always use cpufrequtils to set the cpu governor to performance and > use fixed frequency = 2.8Ghz: > [bourgesl at jmmc-laurent ~]$ uname -a > Linux jmmc-laurent.obs.ujf-grenoble.fr 2.6.35.14-106.fc14.x86_64 #1 SMP > Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > > Yes, I did the same when I initially run the MapBench on JDK 7 vs OpenJDK 7 (governor settings wise). Since you are already running on that platform, maybe I can try to cover Linux 32 bit instead, I also have a notebook with that setup. >> Laurent, have you made any changes to MapBench since I've sent it to you? >> > > Yes I fixed a bit (cached BasicStroke, reused BufferedImage / Graphics) > and added explicit GC before tests (same initial conditions): > http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/ > > Look at MapBench-src.zipfor test changes. > Thanks Cheers Andrea -- == GeoServer training in Milan, 6th & 7th June 2013! Visit http://geoserver.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- From martinrb at google.com Wed Apr 10 18:54:15 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 11:54:15 -0700 Subject: RFR-8008118 In-Reply-To: <20130410182446.3FE2497129@rebar.astron.com> References: <5165A75A.9090309@oracle.com> <20130410182446.3FE2497129@rebar.astron.com> Message-ID: On Wed, Apr 10, 2013 at 11:24 AM, Christos Zoulas wrote: > On Apr 10, 1:54pm, john.zavgren at oracle.com (John Zavgren) wrote: > -- Subject: Re: RFR-8008118 > > | Your comments are welcome. > > 1. We did we switch from NEW() to xmalloc()? Why is the xmalloc cast > needed? > NEW is for allocating homogeneous arrays, but here the memory block is being used for both chars and pointers. > 2. I would not declare pathv "const char **", but "char **", and then > cast the return if needed. This will make life easier in the future > if we decide to turn on warnings about const-castaways. > > I believe the current code doesn't cast away const and doesn't write to const. The only cast is to the return from xmalloc, which is expected. What might a compiler warn about? > Otherwise LGTM. > > christos > From Sergey.Bylokhov at oracle.com Wed Apr 10 19:19:21 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Apr 2013 19:19:21 -0000 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> Message-ID: <524F14A3.6080909@oracle.com> Hi, Laurent. I am not an expert here but just my 50 cents. This optimization shall take place only if it is really hotspot. But if it is a really hotspot - probably it would be better to remove these array/object allocation at all and use plane bytes? I see that some methods which take it as argument doesn't use them. And most of the time we pass AATileGenerator and abox[] to the same methods, so it could be merged? Also I suggest to use jmh for java micrbenchmarks. http://openjdk.java.net/projects/code-tools/jmh So your test will be: http://cr.openjdk.java.net/~serb/AAShapePipeBenchmark.java -- Best regards, Sergey. From Ulf.Zibis at CoSoCo.de Wed Apr 10 19:42:02 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 10 Apr 2013 21:42:02 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <5165AE71.8040909@univ-mlv.fr> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <5165271D.6040904@CoSoCo.de> <51654DDD.5020804@oracle.com> <51659F2E.8060905@CoSoCo.de> <5165AE71.8040909@univ-mlv.fr> Message-ID: <5165C08A.1040003@CoSoCo.de> Am 10.04.2013 20:24, schrieb Remi Forax: > interface + default methods are conceptually what is known as traits(*), > you can see them as interface + method with code or as abstract class without state, > it's the same thing. Thanks, that's what I wanted to make sure. > Now, if you want traits in Java, you have 3 choices: add a new kind of type, trait, > introduce a stateless abstract class or add default methods to interface. > All these changes require to change the VM, so all of them are *big* changes. > The lambda expert group studies each solution and adding default methods > to interface is the path that creates less problems, that why it was chosen. Thanks R?mi, that's the info I was missing, you really considered abstract classes in your studies :-) -Ulf From bourges.laurent at gmail.com Wed Apr 10 19:46:33 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Wed, 10 Apr 2013 21:46:33 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <524F14A3.6080909@oracle.com> References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> Message-ID: Sergey, I am not an expert here but just my 50 cents. > This optimization shall take place only if it is really hotspot. But if it > is a really hotspot - probably it would be better to remove these > array/object allocation at all and use plane bytes? > Java2D calls AAShapePipe for each shape (line, rectangle ...) rendering so it is an hotspot for me for big drawings as it will depends on the drawing complexity (for example, Andrea MapBench can produce maps having more than 100 000 shapes per image ...) > I see that some methods which take it as argument doesn't use them. And > most of the time we pass AATileGenerator and abox[] to the same methods, so > it could be merged? > For now I did not want to modify the AAShapePipe signatures: abox[] is filled by AATileGenerator implementations (ductus, pisces, others) in order to have the shape bounds and render only tiles covering this area. > > Also I suggest to use jmh for java micrbenchmarks. > http://openjdk.java.net/**projects/code-tools/jmh > So your test will be: > http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java > Thanks, I will try it asap Laurent > > > > -- > Best regards, Sergey. > > From christos at zoulas.com Wed Apr 10 20:30:32 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 10 Apr 2013 16:30:32 -0400 Subject: RFR-8008118 In-Reply-To: from Martin Buchholz (Apr 10, 11:54am) Message-ID: <20130410203032.68B2697129@rebar.astron.com> On Apr 10, 11:54am, martinrb at google.com (Martin Buchholz) wrote: -- Subject: Re: RFR-8008118 | > 1. We did we switch from NEW() to xmalloc()? Why is the xmalloc cast | > needed? | | NEW is for allocating homogeneous arrays, but here the memory block is | being used for both chars and pointers. I did not know that. Why the cast though? xmalloc() returns void *, no? Extraneous casts are bad because they hide conversion errors. For example, if you don't have the xmalloc prototype in scope, without the cast you get a warning of casting integer to pointer of different size. With the cast you get the wrong data assigned to the pointer. | > 2. I would not declare pathv "const char **", but "char **", and then | > cast the return if needed. This will make life easier in the future | > if we decide to turn on warnings about const-castaways. | > | > | I believe the current code doesn't cast away const and doesn't write to | const. The only cast is to the return from xmalloc, which is expected. | What might a compiler warn about? It is casting away const before the memcpy: + p = (char *) pathv + pathvsize; Try to compile with -Wcast-qual. christos From martinrb at google.com Wed Apr 10 20:44:18 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 13:44:18 -0700 Subject: RFR-8008118 In-Reply-To: <20130410203032.68B2697129@rebar.astron.com> References: <20130410203032.68B2697129@rebar.astron.com> Message-ID: Christos, I think you may have overlooked the subtlety that pathv is *not* a const pointer - it just looks like one. cat cast.c && echo --- && gcc -Wall -Wcast-qual cast.c #include #include int main(int argc, char *argv[]) { const char **p = (const char **) malloc(5); char *q = (char *)p + 3; printf("%p %p\n", p, q); return 0; } On Wed, Apr 10, 2013 at 1:30 PM, Christos Zoulas wrote: > On Apr 10, 11:54am, martinrb at google.com (Martin Buchholz) wrote: > -- Subject: Re: RFR-8008118 > > | > 1. We did we switch from NEW() to xmalloc()? Why is the xmalloc cast > | > needed? > | > | NEW is for allocating homogeneous arrays, but here the memory block is > | being used for both chars and pointers. > > I did not know that. Why the cast though? xmalloc() returns void *, no? > Extraneous casts are bad because they hide conversion errors. For example, > if you don't have the xmalloc prototype in scope, without the cast you > get a warning of casting integer to pointer of different size. With > the cast you get the wrong data assigned to the pointer. > > | > 2. I would not declare pathv "const char **", but "char **", and then > | > cast the return if needed. This will make life easier in the future > | > if we decide to turn on warnings about const-castaways. > | > > | > > | I believe the current code doesn't cast away const and doesn't write to > | const. The only cast is to the return from xmalloc, which is expected. > | What might a compiler warn about? > > It is casting away const before the memcpy: > > + p = (char *) pathv + pathvsize; > > Try to compile with -Wcast-qual. > > christos > From joe.darcy at oracle.com Wed Apr 10 20:58:10 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 10 Apr 2013 13:58:10 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <5165549E.20502@oracle.com> References: <51648444.2010808@oracle.com> <5165549E.20502@oracle.com> Message-ID: <5165D262.1020305@oracle.com> Hello, On 04/10/2013 05:01 AM, Alan Bateman wrote: > On 09/04/2013 22:12, Joe Darcy wrote: >> Hello, >> >> Please review my changes for >> >> 8011800: Add java.util.Objects.requireNonNull(T, Supplier) >> http://cr.openjdk.java.net/~darcy/8011800.0/ >> >> which add a new method to java.util.Objects to take a >> Supplier rather than a String. >> >> Patch inline below. >> >> Thanks, >> >> -Joe >> > A typo in the javadoc "this methods allows" -> "this method allows". > > A subjective comment, but I would drop the word "sibling" from the > statement. > > A minor nit with the @param spilling over into a second line is that > it might be clearer to indent it so that it's clear where the next tag > starts. I see the existing requiresNonNull are inconsistent on this > point. > > The uninteresting Supplier is null case isn't specified, perhaps this > is deliberate? That is deliberate. Instead of a body like if (obj == null) throw new NullPointerException(messageSupplier.get()); return obj; I briefly considered something more elaborate like if (obj == null) throw new NullPointerException(requireNonNull(messageSupplier.get(), "snarky comment")); return obj; but I figured if you pass in a null message supplier, you get what you deserve and it wasn't worth the extra cost of bloating the method body and interfering with inlining. > > A typo in the test at line 208, "rvariant" -> "variant". > > Also the printed message at line 226 when you get don't pantaloons > should say "Supplier" rather than "2-arg". > I've reworded the specification: /** * Checks that the specified object reference is not {@code null} and * throws a customized {@link NullPointerException} if it is. * *

Unlike the method {@link requireNonNull(Object, String}, * this method allows creation of the message to be deferred until * after the null check is made. While this may confer a * performance advantage in the non-null case, when deciding to * call this method care should be taken that the costs of * creating the message supplier are less than the cost of just * creating the string message directly. * * @param obj the object reference to check for nullity * @param messageSupplier supplier of the detail message to be * used in the event that a {@code NullPointerException} is thrown * @param the type of the reference * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} * @since 1.8 */ and cleaned up the regression tests to use lambda expressions. New webrev at http://cr.openjdk.java.net/~darcy/8011800.1/ Thanks, -Joe From mike.duigou at oracle.com Wed Apr 10 21:00:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 14:00:20 -0700 Subject: RFR : 8010948 : Add conversion functional interfaces In-Reply-To: References: Message-ID: <2D1C2587-AD0B-4633-BF1E-7D467C2C38E7@oracle.com> I have added two @see to every interface, the reverse function and the function converting from the other primitive type to the same type. ie. in IntToDoubleFunction I add @see for LongToDoubleFunction and DoubleToIntFunction. Mike On Apr 9 2013, at 16:14 , Paul Benedict wrote: > Mike, > > It would be nice if the class javadocs would have @see tags to classes in > the same family. For example, DoubleToIntFunction could have a @see to > DoubleToLongFunction, etc. This way a developer viewing of one class can > easily figure out which close cousins exist. > > Paul From christos at zoulas.com Wed Apr 10 21:07:35 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 10 Apr 2013 17:07:35 -0400 Subject: RFR-8008118 In-Reply-To: from Martin Buchholz (Apr 10, 1:44pm) Message-ID: <20130410210735.5441F97129@rebar.astron.com> On Apr 10, 1:44pm, martinrb at google.com (Martin Buchholz) wrote: -- Subject: Re: RFR-8008118 | Christos, I think you may have overlooked the subtlety that pathv is *not* | a const pointer - it just looks like one. | Yes, indeed; you are right! christos From mandy.chung at oracle.com Wed Apr 10 21:10:15 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Apr 2013 14:10:15 -0700 Subject: Incorrect arguments is passed to sun.misc.Perf#createLong In-Reply-To: <5164007C.5040408@ysfactory.dip.jp> References: <5164007C.5040408@ysfactory.dip.jp> Message-ID: <5165D537.2040403@oracle.com> Hi Yasumasa, I'm adding core-libs and bcc serviceability-dev to move this thread to core-libs for sun.misc.PerfCounter discussion. On 4/9/2013 4:50 AM, Yasu wrote: > Hi, > > I'm trying to create entry from Java program to hsperfdata through > sun.misc.PerfCounter . First of all, sun.misc.PerfCounter is a private API that is not supported and may be changed and removed in any future release. I'm curious how you create a counter in hsperfdata through sun.misc.PerfCounter. The constructor is private. > However, I cannot watch the updated value in my entry through the > jstat with interval option. > > I guess this cause is that wrong arguments are passed from > PerfCounter# to Perf#createLong . > Indeed - it's a bug that calls Perf.createLong with the incorrect parameters. I have filed a bug (8011934). Have you signed the OCA [1]? Thanks Mandy [1] http://openjdk.java.net/contribute/ > sun.misc.PerfCounter: > --------- > private PerfCounter(String name, int type) { > this.name = name; > ByteBuffer bb = perf.createLong(name, U_None, type, 0L); > bb.order(ByteOrder.nativeOrder()); > this.lb = bb.asLongBuffer(); > } > --------- > > sun.misc.Perf: > --------- > public native ByteBuffer createLong(String name, int variability, > int units, long value); > --------- > > "type" in constructor of PerfCounter means "variability". > So "type" should be set to 2nd argument in perf.createLong() > > perf.createLong() should be called as following: > --------- > ByteBuffer bb = perf.createLong(name, type, U_None, 0L); > --------- > > > I've applied a patch which is attached in this email, it's works fine. > > > Thanks, > > Yasumasa From martinrb at google.com Wed Apr 10 21:26:48 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 14:26:48 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: I'm willing to accept John as an authority on hotspot optimization. I'm surprised that null checks aren't more close to free in part because recent jsr166 code has been introducing more explicit null checks, sometimes in code where the reference being checked is "known" not to be null. Martin On Wed, Apr 10, 2013 at 11:12 AM, Mike Duigou wrote: > > On Apr 9 2013, at 19:56 , Martin Buchholz wrote: > The use of an empty array rather than null was suggested by John Rose who > said: > > I recommend an empty array rather than null as a sentinel value for two > reasons: > > 1. The JVM prefers to merge null checks into load or store instructions > (so-called "implicit null checks") because it removes an explicit branch. > But it only does so if the probability of nulls is zero or very low. But > using null as a sentinel for common states (e.g., empty collection) defeats > this optimization. > > 2. For power-of-two sized structures (HashMap) we can optimize away an > array range check in the presence of a zero-length check. > > Since most uses of a variable-sized collection load and test the array > length, the sentinel check can easily be overloaded onto this test. If null > is not used, then the (safety-mandated) null check is (usually) merged into > the load of the length. If the table is power-of-two-sized, then only the > zero check remains, and the array range check may be removed. This is > thought to be the best code for a frequent load from a possibly-empty > collection. > > Mike asked, "what about empty collection?" This is a reasonable thing to > use, but it has a cost. The JVM uses inline caches and type profiles to > simplify its optimized code; these techniques "win" when at a given use > point (individual call to Map.get, for example) there is only one class > present, even if the interface is totally general. (This is the so-called > "monomorphic" case.) If the application uses (say) only HashMaps for both > empty and non-empty maps, then this optimization can win big. It can be > broken, on the other hand, if the application begins to use one other type > for some other case (such as empty maps). In these cases, it is better to > overload the "am I empty?" test on some other loaded value, such as a null > or (better) an array length. > > > Mike > From mike.duigou at oracle.com Wed Apr 10 22:05:26 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 10 Apr 2013 22:05:26 +0000 Subject: hg: jdk8/tl/jdk: 8010948: Add conversion functional interfaces Message-ID: <20130410220617.7F6D9481D3@hg.openjdk.java.net> Changeset: 863da64214e8 Author: mduigou Date: 2013-04-10 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/863da64214e8 8010948: Add conversion functional interfaces Reviewed-by: mduigou, dholmes Contributed-by: Brian Goetz + src/share/classes/java/util/function/DoubleToIntFunction.java + src/share/classes/java/util/function/DoubleToLongFunction.java + src/share/classes/java/util/function/IntToDoubleFunction.java + src/share/classes/java/util/function/IntToLongFunction.java + src/share/classes/java/util/function/LongToDoubleFunction.java + src/share/classes/java/util/function/LongToIntFunction.java From dl at cs.oswego.edu Wed Apr 10 22:49:01 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 10 Apr 2013 18:49:01 -0400 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: <5165EC5D.4060406@cs.oswego.edu> On 04/10/13 17:26, Martin Buchholz wrote: > I'm willing to accept John as an authority on hotspot optimization. > I'm surprised that null checks aren't more close to free in part because recent > jsr166 code has been introducing more explicit null checks, sometimes in code > where the reference being checked is "known" not to be null. > Some are cheap. Some aren't. Always measure. -Doug From Sergey.Bylokhov at oracle.com Wed Apr 10 22:59:53 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 11 Apr 2013 02:59:53 +0400 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> Message-ID: <5165EEE9.1050006@oracle.com> On 4/10/13 11:46 PM, Laurent Bourg?s wrote: >> I see that some methods which take it as argument doesn't use them. And >> most of the time we pass AATileGenerator and abox[] to the same methods, so >> it could be merged? >> > For now I did not want to modify the AAShapePipe signatures: abox[] is > filled by AATileGenerator implementations (ductus, pisces, others) in order > to have the shape bounds and render only tiles covering this area. You still have to check all the places, where these objects are filled and used, and refactoring is a good start, no? Otherwise, how can you prove that these arrays are used as you would expect, These arrays could be stored like the cache or re-used for other purpose(if someone don't want to create new arrays). Probably it will be good to split all your changes / to a few CR. - cleanup - Some small changes which gave us most speedup - all other things. ?? > >> Also I suggest to use jmh for java micrbenchmarks. >> http://openjdk.java.net/**projects/code-tools/jmh >> So your test will be: >> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java >> > Thanks, > I will try it asap > > Laurent > >> >> -- >> Best regards, Sergey. >> >> -- Best regards, Sergey. From forax at univ-mlv.fr Wed Apr 10 23:18:23 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 11 Apr 2013 01:18:23 +0200 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: <5165F33F.9050705@univ-mlv.fr> On 04/10/2013 11:26 PM, Martin Buchholz wrote: > I'm willing to accept John as an authority on hotspot optimization. > I'm surprised that null checks aren't more close to free in part because > recent jsr166 code has been introducing more explicit null checks, > sometimes in code where the reference being checked is "known" not to be > null. > > Martin null check that are never null are free when the interpreter has never (or rarely) sees a null at a specific callsite because in that case, the JIT doesn't generate a null check and let the CPU/MMU do a fault (the VM has a signal handler to be able to come back from death :) If you set a field to null, the profiler will see the null and will not use this optimization, that why in this case, it's better to have an empty array instead of null. BTW, the nullcheck in assembler cost you almost nothing anyway but the jump associated with it has a cost. Modern CPUs do not like to jump. R?mi > > > On Wed, Apr 10, 2013 at 11:12 AM, Mike Duigou wrote: > >> On Apr 9 2013, at 19:56 , Martin Buchholz wrote: >> The use of an empty array rather than null was suggested by John Rose who >> said: >> >> I recommend an empty array rather than null as a sentinel value for two >> reasons: >> >> 1. The JVM prefers to merge null checks into load or store instructions >> (so-called "implicit null checks") because it removes an explicit branch. >> But it only does so if the probability of nulls is zero or very low. But >> using null as a sentinel for common states (e.g., empty collection) defeats >> this optimization. >> >> 2. For power-of-two sized structures (HashMap) we can optimize away an >> array range check in the presence of a zero-length check. >> >> Since most uses of a variable-sized collection load and test the array >> length, the sentinel check can easily be overloaded onto this test. If null >> is not used, then the (safety-mandated) null check is (usually) merged into >> the load of the length. If the table is power-of-two-sized, then only the >> zero check remains, and the array range check may be removed. This is >> thought to be the best code for a frequent load from a possibly-empty >> collection. >> >> Mike asked, "what about empty collection?" This is a reasonable thing to >> use, but it has a cost. The JVM uses inline caches and type profiles to >> simplify its optimized code; these techniques "win" when at a given use >> point (individual call to Map.get, for example) there is only one class >> present, even if the interface is totally general. (This is the so-called >> "monomorphic" case.) If the application uses (say) only HashMaps for both >> empty and non-empty maps, then this optimization can win big. It can be >> broken, on the other hand, if the application begins to use one other type >> for some other case (such as empty maps). In these cases, it is better to >> overload the "am I empty?" test on some other loaded value, such as a null >> or (better) an array length. >> >> >> Mike >> From vitalyd at gmail.com Wed Apr 10 23:33:30 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 10 Apr 2013 19:33:30 -0400 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <5165F33F.9050705@univ-mlv.fr> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> <5165F33F.9050705@univ-mlv.fr> Message-ID: The null check jumps should be taken care of by branch prediction; as long as they're predictable, penalty on OOO CPU is minimal. So modern CPUs don't like mispredicted branches I'd say, not just any jump. On Apr 10, 2013 7:23 PM, "Remi Forax" wrote: > On 04/10/2013 11:26 PM, Martin Buchholz wrote: > >> I'm willing to accept John as an authority on hotspot optimization. >> I'm surprised that null checks aren't more close to free in part because >> recent jsr166 code has been introducing more explicit null checks, >> sometimes in code where the reference being checked is "known" not to be >> null. >> >> Martin >> > > null check that are never null are free when the interpreter has never (or > rarely) sees a null > at a specific callsite because in that case, the JIT doesn't generate a > null check and > let the CPU/MMU do a fault (the VM has a signal handler to be able to come > back from death :) > > If you set a field to null, the profiler will see the null and will not > use this optimization, > that why in this case, it's better to have an empty array instead of null. > BTW, the nullcheck in assembler cost you almost nothing anyway but the jump > associated with it has a cost. Modern CPUs do not like to jump. > > R?mi > > >> >> On Wed, Apr 10, 2013 at 11:12 AM, Mike Duigou > >wrote: >> >> On Apr 9 2013, at 19:56 , Martin Buchholz wrote: >>> The use of an empty array rather than null was suggested by John Rose who >>> said: >>> >>> I recommend an empty array rather than null as a sentinel value for two >>> reasons: >>> >>> 1. The JVM prefers to merge null checks into load or store instructions >>> (so-called "implicit null checks") because it removes an explicit branch. >>> But it only does so if the probability of nulls is zero or very low. But >>> using null as a sentinel for common states (e.g., empty collection) >>> defeats >>> this optimization. >>> >>> 2. For power-of-two sized structures (HashMap) we can optimize away an >>> array range check in the presence of a zero-length check. >>> >>> Since most uses of a variable-sized collection load and test the array >>> length, the sentinel check can easily be overloaded onto this test. If >>> null >>> is not used, then the (safety-mandated) null check is (usually) merged >>> into >>> the load of the length. If the table is power-of-two-sized, then only the >>> zero check remains, and the array range check may be removed. This is >>> thought to be the best code for a frequent load from a possibly-empty >>> collection. >>> >>> Mike asked, "what about empty collection?" This is a reasonable thing to >>> use, but it has a cost. The JVM uses inline caches and type profiles to >>> simplify its optimized code; these techniques "win" when at a given use >>> point (individual call to Map.get, for example) there is only one class >>> present, even if the interface is totally general. (This is the so-called >>> "monomorphic" case.) If the application uses (say) only HashMaps for both >>> empty and non-empty maps, then this optimization can win big. It can be >>> broken, on the other hand, if the application begins to use one other >>> type >>> for some other case (such as empty maps). In these cases, it is better to >>> overload the "am I empty?" test on some other loaded value, such as a >>> null >>> or (better) an array length. >>> >>> >>> Mike >>> >>> > From joe.darcy at oracle.com Wed Apr 10 23:38:42 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 10 Apr 2013 23:38:42 +0000 Subject: hg: jdk8/tl/jdk: 8011930: Long.parseLong(String, int) has inaccurate limit on radix for using 'L' Message-ID: <20130410233913.050A3481DD@hg.openjdk.java.net> Changeset: b0458dd21ba6 Author: darcy Date: 2013-04-10 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0458dd21ba6 8011930: Long.parseLong(String, int) has inaccurate limit on radix for using 'L' Reviewed-by: smarks ! src/share/classes/java/lang/Long.java From martinrb at google.com Wed Apr 10 23:49:06 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 16:49:06 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> <5165F33F.9050705@univ-mlv.fr> Message-ID: Whether or not we use null or an empty array as a sentinel value, we will need to make a special check for empty on most operations, and that will not be predictable if empty collection operations are common. The empty collection optimization is a strange sort of compression algorithm. From james.graham at oracle.com Thu Apr 11 00:06:24 2013 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Apr 2013 17:06:24 -0700 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <5165EEE9.1050006@oracle.com> References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> <5165EEE9.1050006@oracle.com> Message-ID: <5165FE80.9040408@oracle.com> I'm pretty familiar with all of this code and there aren't any places that save the tile array that I remember. The embedded code that Pisces was taken from had some caching of alpha arrays, but we didn't use or keep that when we converted it for use in the JDK... It occurs to me that since you are collecting the various pieces of information into an object to store in the thread local storage, perhaps we should convert to a paradigm where an entire Tile Generation sequence uses that object "TileState?" as its main way to communicate info around the various stages. Thus, you don't really need an int[4] to store the 4 parameters, they could be stored directly in the TileState object. This would require more sweeping changes to the pipeline, but it might make the code a bit more readable (and make the hits to convert over more moot as they would be improving readability and give more focus to the relationships between all of the various bits of data). Then it simply becomes a matter of managing the lifetime and allocation of the TileState objects which is a minor update to the newly refactored code. ...jim On 4/10/13 3:59 PM, Sergey Bylokhov wrote: > On 4/10/13 11:46 PM, Laurent Bourg?s wrote: >>> I see that some methods which take it as argument doesn't use them. And >>> most of the time we pass AATileGenerator and abox[] to the same >>> methods, so >>> it could be merged? >>> >> For now I did not want to modify the AAShapePipe signatures: abox[] is >> filled by AATileGenerator implementations (ductus, pisces, others) in >> order >> to have the shape bounds and render only tiles covering this area. > You still have to check all the places, where these objects are filled > and used, and refactoring is a good start, no? > Otherwise, how can you prove that these arrays are used as you would > expect, These arrays could be stored like the cache or re-used for other > purpose(if someone don't want to create new arrays). > Probably it will be good to split all your changes / to a few CR. > - cleanup > - Some small changes which gave us most speedup > - all other things. > ?? >> >>> Also I suggest to use jmh for java micrbenchmarks. >>> http://openjdk.java.net/**projects/code-tools/jmh >>> >>> So your test will be: >>> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java >>> >>> >> Thanks, >> I will try it asap >> >> Laurent >> >>> >>> -- >>> Best regards, Sergey. >>> >>> > > From martinrb at google.com Thu Apr 11 00:40:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Apr 2013 17:40:52 -0700 Subject: Add getChars to CharSequence Message-ID: I've often wished that CharSequence had getChars methods, as many of the concrete implementations already do. In jdk8 with default methods, this is possible! This will make some of the String code a little nicer and more efficient. Here's a preliminary patch in this direction, that overlaps with some of the work done in 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ If we have consensus that this is a good idea, I can flesh this out. From mike.duigou at oracle.com Thu Apr 11 00:47:37 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 17:47:37 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: Message-ID: <31501FEF-7963-43E0-A357-16812C2165AA@oracle.com> Seems like a nice extension to me. Mike On Apr 10 2013, at 17:40 , Martin Buchholz wrote: > I've often wished that CharSequence had getChars methods, as many of the concrete implementations already do. > In jdk8 with default methods, this is possible! > This will make some of the String code a little nicer and more efficient. > > Here's a preliminary patch in this direction, that overlaps with some of the work done in > > 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent > Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ > > If we have consensus that this is a good idea, I can flesh this out. From yasu at ysfactory.dip.jp Thu Apr 11 01:59:31 2013 From: yasu at ysfactory.dip.jp (Yasu) Date: Thu, 11 Apr 2013 10:59:31 +0900 Subject: Incorrect arguments is passed to sun.misc.Perf#createLong In-Reply-To: <5165D537.2040403@oracle.com> References: <5164007C.5040408@ysfactory.dip.jp> <5165D537.2040403@oracle.com> Message-ID: <51661903.2060107@ysfactory.dip.jp> Hi Mandy, On 4:59, Mandy Chung wrote: > Hi Yasumasa, > > I'm adding core-libs and bcc serviceability-dev to move this thread to core-libs for sun.misc.PerfCounter discussion. > > On 4/9/2013 4:50 AM, Yasu wrote: >> Hi, >> >> I'm trying to create entry from Java program to hsperfdata through sun.misc.PerfCounter . > > First of all, sun.misc.PerfCounter is a private API that is not supported and may be changed and removed in any future release. I'm curious how you create a counter in hsperfdata through sun.misc.PerfCounter. The constructor is private. I've understood that sun.* packages is private API. I use PerfCounter with reflection API ( setAccessible(true) ) . >> However, I cannot watch the updated value in my entry through the jstat with interval option. >> >> I guess this cause is that wrong arguments are passed from PerfCounter# to Perf#createLong . >> > > Indeed - it's a bug that calls Perf.createLong with the incorrect parameters. I have filed a bug (8011934). Thanks! > Have you signed the OCA [1]? Yes. I already sent OCA with my signature. Thanks, Yasumasa > Thanks > Mandy > [1] http://openjdk.java.net/contribute/ > >> sun.misc.PerfCounter: >> --------- >> private PerfCounter(String name, int type) { >> this.name = name; >> ByteBuffer bb = perf.createLong(name, U_None, type, 0L); >> bb.order(ByteOrder.nativeOrder()); >> this.lb = bb.asLongBuffer(); >> } >> --------- >> >> sun.misc.Perf: >> --------- >> public native ByteBuffer createLong(String name, int variability, >> int units, long value); >> --------- >> >> "type" in constructor of PerfCounter means "variability". >> So "type" should be set to 2nd argument in perf.createLong() >> >> perf.createLong() should be called as following: >> --------- >> ByteBuffer bb = perf.createLong(name, type, U_None, 0L); >> --------- >> >> >> I've applied a patch which is attached in this email, it's works fine. >> >> >> Thanks, >> >> Yasumasa From mike.duigou at oracle.com Thu Apr 11 02:10:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 19:10:31 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <5163320A.5020106@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <5163320A.5020106@gmail.com> Message-ID: On Apr 8 2013, at 14:09 , Peter Levart wrote: > Hi Mike, > > It's unfortunate that getOrDefault() is specified so that it can't be implemented atomically in terms of existent (non-default) ConcurrentMap methods, so platform ConcurrentMap implementations will have atomic implementation and others will have to catch-up first. I hope this will not be a cause of any concurrency bugs. The only solution I can see is to provide a default in ConcurrentMap that uses only get() and documents that implementations supporting null values will will need to override the default. I will include this in the updated webrev. This may not be as radical as it sounds. Doug has said that he knows of no ConcurrentMap implementations that support null keys/values. (Why would anyone want to) > The javadoc for computeIfPresent seems to be inconsistent: > > 826 * If the value for the specified key is present and non-null, > 827 * attempts to compute a new mapping given the key and its current > 828 * mapped value. > 829 * > 830 *

If the function returns {@code null}, the mapping is removed (or > 831 * remains absent if initially absent). If the function itself throws an > 832 * (unchecked) exception, the exception is rethrown, and the current mapping > 833 * is left unchanged. > > I think the situation described in bold is non-existent. Corrected. > > Regards, Peter > > > On 04/08/2013 08:07 PM, Mike Duigou wrote: >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >> >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() >> >> 8010122: Add atomic operations to Map >> getOrDefault() >> putIfAbsent() * >> remove(K, V) >> replace(K, V) >> replace(K, V, V) >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * >> >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike >> > From joe.darcy at oracle.com Thu Apr 11 02:41:53 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 10 Apr 2013 19:41:53 -0700 Subject: JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516554D1.4070807@univ-mlv.fr> References: <51648444.2010808@oracle.com> <516554D1.4070807@univ-mlv.fr> Message-ID: <516622F1.2080803@oracle.com> On 4/10/2013 5:02 AM, Remi Forax wrote: > On 04/09/2013 11:12 PM, Joe Darcy wrote: >> Hello, >> >> Please review my changes for >> >> 8011800: Add java.util.Objects.requireNonNull(T, Supplier) >> http://cr.openjdk.java.net/~darcy/8011800.0/ >> >> which add a new method to java.util.Objects to take a >> Supplier rather than a String. >> >> Patch inline below. >> >> Thanks, >> >> -Joe > > It's premature in my opinion to introduce this kind of method in the API. > The cost of creating a lambda the first time is actually even worst as > the one > of loading an inner class. Objects.requireNonNull should be a quick > check, > not something that involve to load a new class. > > It's true that the JIT will optimize the lambda creation but there are > lot of codes > that are never JITed, typically less than 20% of the code of a program > is JITed. > > Adding this API will slow down the startup time of a program, > Java is known to be slow at startup, in fact, the VM is not that slow, > the JDK and > the application are slow to startup. It's not a good idea to provide a > way > to make the startup of an application slower that it needs to be. Acting as legal counsel for Objects.requireNonNull(T, Supplier), I submit a plea of "not guilty" to the charge of slowing down Java startup. First, the method isn't in the JDK yet. Second, even if it were in the JDK, it would first have to be used in a startup-critical way. Third, the method contains a disclaimer warning against misuse. -Joe From weijun.wang at oracle.com Thu Apr 11 02:59:04 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 11 Apr 2013 02:59:04 +0000 Subject: hg: jdk8/tl/jdk: 8005460: [findbugs] Probably returned array should be cloned Message-ID: <20130411025917.18A59481E7@hg.openjdk.java.net> Changeset: 6f8e1428f7c3 Author: weijun Date: 2013-04-11 10:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f8e1428f7c3 8005460: [findbugs] Probably returned array should be cloned Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/PrincipalName.java + test/sun/security/krb5/name/Immutable.java From weijun.wang at oracle.com Thu Apr 11 03:10:24 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 11 Apr 2013 03:10:24 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130411031047.92AE5481E8@hg.openjdk.java.net> Changeset: 0ab22e58d151 Author: weijun Date: 2013-04-11 11:09 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ab22e58d151 8011867: Accept unknown PKCS #9 attributes Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java + test/sun/security/pkcs/pkcs9/UnknownAttribute.java Changeset: 1c3fff140324 Author: weijun Date: 2013-04-11 11:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c3fff140324 8011745: Unknown CertificateChoices Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs/PKCS7.java From mike.duigou at oracle.com Thu Apr 11 03:20:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 20:20:14 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <51635C13.808@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51635C13.808@CoSoCo.de> Message-ID: On Apr 8 2013, at 17:08 , Ulf Zibis wrote: > Hi Mike, > > Comments for j.u.Map: > > To my savour the variant belongs to the left hand side of a comparison, e.g.: > if (v = get(key) != null) Yeah, you caught me. Almost everyone hates these "Yoda conditions" (http://wiert.me/2010/05/25/yoda-conditions-from-stackoverflow-new-programming-jargon-you-coined/). I am unwilling and probably unable to change my personal use of them but will use the "normal" form whenever anyone objects. Incidentally the last time I introduced an "unintentional assignment" bug was fixing one of these.... > Instead > 501 return (null != (v = get(key))) > 502 ? v > 503 : containsKey(key) ? null : defaultValue; > I would code > 501 return ((v = get(key) != null) || containsKey(key)) ? v : defaultValue; done. > > Use consistent formatted code examples in javadoc. I like the style from lines 558 to 561, but e.g. from line 601 to 605: > - 2 spaces before 

> - indentation should be 4
> - line break before }
Things got a little sloppy while they were changing frequently. I will cleanup. > > Why you use both, {@code...} and ... ? legacy. We're trying to use {@code } in new work but only convert existing when it's convenient. The main reason for not doing a global replacement is that we all value concise diffs and replacing everywhere would generate significant noise. > For performance reasons, I think you should reverse the order of the if expressions here: > 673 if (!Objects.equals(get(key), value) || !containsKey(key)) > ... because otherwise map lookup too often becomes executed twice, via contains() + get(). Yes, this is clearly better. > Not negate the comparison term, e.g.: > 1053 if (value == null) > 1054 return null; > 1055 if ((oldValue = putIfAbsent(key, value)) == null) > 1056 return value; Done. > > -Ulf > > > Am 08.04.2013 20:07, schrieb Mike Duigou: >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >> >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() >> >> 8010122: Add atomic operations to Map >> getOrDefault() >> putIfAbsent() * >> remove(K, V) >> replace(K, V) >> replace(K, V, V) >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * >> >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike >> > From yuka.kamiya at oracle.com Thu Apr 11 03:24:23 2013 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 11 Apr 2013 03:24:23 +0000 Subject: hg: jdk8/tl/jdk: 8009638: Wrong comment for PL in LocaleISOData, 1989 forward Poland is Republic of Poland Message-ID: <20130411032434.8C318481E9@hg.openjdk.java.net> Changeset: 006a7a576fe9 Author: peytoia Date: 2013-04-11 12:22 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/006a7a576fe9 8009638: Wrong comment for PL in LocaleISOData, 1989 forward Poland is Republic of Poland Reviewed-by: okutsu ! src/share/classes/java/util/LocaleISOData.java From robert.field at oracle.com Thu Apr 11 04:24:21 2013 From: robert.field at oracle.com (Robert Field) Date: Wed, 10 Apr 2013 21:24:21 -0700 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) Message-ID: <51663AF5.5000807@oracle.com> Currently blocking lambda library pushes. Internal class reader used by rmic does not support new constant pool constant types: CONSTANT_METHODHANDLE = 15; CONSTANT_METHODTYPE = 16; CONSTANT_INVOKEDYNAMIC = 18; Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011805 Webrev: http://cr.openjdk.java.net/~rfield/8011805/ From mike.duigou at oracle.com Thu Apr 11 04:32:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 21:32:31 -0700 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) In-Reply-To: <51663AF5.5000807@oracle.com> References: <51663AF5.5000807@oracle.com> Message-ID: - License on test is the wrong one. Tests don't have classpath exemption. - The initial block comment with @test doesn't have the normal leading * on each line. - The commented out part mentioning testWrite should just be removed along with unreferenced code. Looks otherwise fine to me. Mike On Apr 10 2013, at 21:24 , Robert Field wrote: > Currently blocking lambda library pushes. Internal class reader used by rmic does not support new constant pool constant types: > > CONSTANT_METHODHANDLE = 15; > > CONSTANT_METHODTYPE = 16; > > CONSTANT_INVOKEDYNAMIC = 18; > > > Please review the fix for CR: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011805 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8011805/ From mike.duigou at oracle.com Thu Apr 11 04:41:47 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 21:41:47 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <51637B60.5080905@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> Message-ID: On Apr 8 2013, at 19:22 , David Holmes wrote: > Hi Mike, > > Looking only at Map itself for now. > > On 9/04/2013 4:07 AM, Mike Duigou wrote: >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > General style issues: > > - spaces after keyword ie "if (x == null)" not "if(x == null)" Fixed. I am sorry this keeps coming up. I am loathe to run an automatic formatter on any JDK code. > - comparisons against constants/null put the constant/null on the right ie "if (x == null)" not "if (null == x)" Do I shall. > > (where has our style guide gone? I can't find it on internal or external wikis :( ) This one? http://www.oracle.com/technetwork/java/codeconv-138413.html I am unaware of any other guide that's official policy. > >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() > > Both of those contain the boilerplate text: > > *

The default implementation makes no guarantees about > * synchronization or atomicity properties of this method. Any > * class overriding this method must specify its concurrency > * properties. In particular, all implementations of > * subinterface {@link java.util.concurrent.ConcurrentMap} > * must ensure that this operation is performed atomically. > > but these methods are not, and can not be, atomic in ConcurrentMap I've altered the text to incorporate your suggestions. It now read: *

The default implementation makes no guarantees about synchronization * or atomicity properties of this method. Any class which wishes to provide * specific synchronization, atomicity or concurrency behaviour should * override this method. I would like to use this same text on the other methods as well. > > forEach and replaceAll are very similar in terms of taking and applying a "operation" to each entry, yet their descriptions use a completely different style. Written by different people independently. > forEach describes thing in general terms while replaceAll talks about calling the functions' apply method with the current entry's key and value. I would suggest for replaceAll: > > "Replaces each entry's value with the result of invoking the given function on that entry, in the order entries are returned by an entry set iterator, until all entries have been processed or the function throws an exception." > > This is also makes "replace" the subject rather than "apply". Yes, reads better to me. > > forEach doesn't declare the IllegalStateException that getKey and getValue can throw. Since forEach isn't supposed to mutate the map this shouldn't happen. It could only happen through concurrent modification. I've added a catch of the IllegalStateException and throw CME with the ISE as the cause to both forEach and replaceAll. > Some/many of the @throws text has obviously been copied from the Map.Entry methods eg: > > * @throws ClassCastException if the class of the specified value > * prevents it from being stored in the backing map > > but when put into Map itself they should not be referring to "the backing map" as there is no "backing map". Further we have inconsistent terminology being used, eg getOrDefault has: > > * @throws ClassCastException if the key is of an inappropriate type for > * this map > > and then there is a third variant in other methods: > > * @throws ClassCastException if the class of the specified key or value > * prevents it from being stored in this map > * (optional) > > These should all have the same basic wording, differing only in key/value. agreed. The third variant is now used consistently. > >> 8010122: Add atomic operations to Map > > Meaning "backport some operations from ConcurrentMap" - they aren't actually atomic in Map. OK. > >> getOrDefault() > > No comment > >> putIfAbsent() * > > The default implementation throws ConcurrentModificationException but this is not declared in the spec. fixed > >> remove(K, V) >> replace(K, V) >> replace(K, V, V) > > No comments > >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * > > The following generally apply to this group of methods. > > As Peter already stated the spec: > > *

If the function returns {@code null}, the mapping is removed (or > * remains absent if initially absent). > > is somewhat unclear. The parenthesized part is not connected to the function returning null or otherwise; as the function won't be called. Corrected. > I find the spec for these rather confusing from a concurrency perspective - this non-concurrent interface seems to be trying to say too much about how a concurrent interface should specify behaviour. Why does it need to say: > > * In concurrent contexts, the default implementation may retry > * these steps when multiple threads attempt updates. For default on Map I am starting to think that throwing that CME rather than looping is the right choice. The retry behaviour seems to be counter the basic behaviour of non-concurrent implementations. The retry behaviour will just hide usage that's otherwise unsafe when used with non-concurrent implementations. The concurrent implementations don't use these defaults so there's no problem switching to throwing CME. Opinions? > ? Note computeIfAbsent does not say the same thing. It doesn't attempt to loop. > > The @implSpec does not match the actual implementation. It looks to me like these implementations are trying to cater for concurrent situations - hence the loop. That's okay but then the implSpec should identify that fact. Corrected several of the impl descriptions. > 980 * be of use when combining multiple mapped values for a key. For > 981 * example. to either create or append a {@code String msg} to a > > Period after example should be a comma. fixed. > > Cheers, > David > >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike >> >> From david.holmes at oracle.com Thu Apr 11 05:06:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2013 15:06:49 +1000 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> Message-ID: <516644E9.9080907@oracle.com> Hi Mike, Comments inline and trimmed ... On 11/04/2013 2:41 PM, Mike Duigou wrote: > On Apr 8 2013, at 19:22 , David Holmes wrote: >> (where has our style guide gone? I can't find it on internal or external wikis :( ) > > This one? http://www.oracle.com/technetwork/java/codeconv-138413.html > > I am unaware of any other guide that's official policy. I thought we had both OpenJDK style guidelines and internal ones. May be confusing with hotspot ones. >>> 8004518: Add in-place operations to Map >>> forEach() >>> replaceAll() >> >> Both of those contain the boilerplate text: >> >> *

The default implementation makes no guarantees about >> * synchronization or atomicity properties of this method. Any >> * class overriding this method must specify its concurrency >> * properties. In particular, all implementations of >> * subinterface {@link java.util.concurrent.ConcurrentMap} >> * must ensure that this operation is performed atomically. >> >> but these methods are not, and can not be, atomic in ConcurrentMap > > I've altered the text to incorporate your suggestions. It now read: > > *

The default implementation makes no guarantees about synchronization > * or atomicity properties of this method. Any class which wishes to provide > * specific synchronization, atomicity or concurrency behaviour should > * override this method. > > I would like to use this same text on the other methods as well. I'm okay with that, but you should check with whomever thought it necessary to call out the ConcurrentMap situation. ConcurrentMap will need to override these just to add the spec that they are atomic. >> forEach doesn't declare the IllegalStateException that getKey and getValue can throw. > > Since forEach isn't supposed to mutate the map this shouldn't happen. It could only happen through concurrent modification. I've added a catch of the IllegalStateException and throw CME with the ISE as the cause to both forEach and replaceAll. Not sure I see the distinction. These are Map methods so regardless of which method is involved you will only get the IllegalStateException if there is concurrent modification. Hence to me forEach and replaceAll should behave the same way, for example. >> Some/many of the @throws text has obviously been copied from the Map.Entry methods eg: >> >> * @throws ClassCastException if the class of the specified value >> * prevents it from being stored in the backing map >> >> but when put into Map itself they should not be referring to "the backing map" as there is no "backing map". Further we have inconsistent terminology being used, eg getOrDefault has: >> >> * @throws ClassCastException if the key is of an inappropriate type for >> * this map >> >> and then there is a third variant in other methods: >> >> * @throws ClassCastException if the class of the specified key or value >> * prevents it from being stored in this map >> * (optional) >> >> These should all have the same basic wording, differing only in key/value. > > agreed. The third variant is now used consistently. Why do we need the xref to "optional" ? Is throwing CCE optional? Other Collection methods don't flag it as optional. >>> compute() * >>> merge() * >>> computeIfAbsent() * >>> computeIfPresent() * >> >> The following generally apply to this group of methods. > >> I find the spec for these rather confusing from a concurrency perspective - this non-concurrent interface seems to be trying to say too much about how a concurrent interface should specify behaviour. Why does it need to say: >> >> * In concurrent contexts, the default implementation may retry >> * these steps when multiple threads attempt updates. > > For default on Map I am starting to think that throwing that CME rather than looping is the right choice. The retry behaviour seems to be counter the basic behaviour of non-concurrent implementations. The retry behaviour will just hide usage that's otherwise unsafe when used with non-concurrent implementations. > > The concurrent implementations don't use these defaults so there's no problem switching to throwing CME. > > Opinions? I had assumed the loops only existed because you wanted to use them as ConcurrentMap defaults too! If that is not the case then these methods should not loop/retry but just throw CME, in my opinion. Thanks, David From mike.duigou at oracle.com Thu Apr 11 05:21:52 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 22:21:52 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516644E9.9080907@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> <516644E9.9080907@oracle.com> Message-ID: <11D478B1-826A-4AFE-AC68-65F78911F2FE@oracle.com> On Apr 10 2013, at 22:06 , David Holmes wrote: > Hi Mike, > > Comments inline and trimmed ... Additional trimming applied. > On 11/04/2013 2:41 PM, Mike Duigou wrote: >> On Apr 8 2013, at 19:22 , David Holmes wrote: >>>> 8004518: Add in-place operations to Map >>>> forEach() >>>> replaceAll() >>> >>> Both of those contain the boilerplate text: >>> >>> *

The default implementation makes no guarantees about >>> * synchronization or atomicity properties of this method. Any >>> * class overriding this method must specify its concurrency >>> * properties. In particular, all implementations of >>> * subinterface {@link java.util.concurrent.ConcurrentMap} >>> * must ensure that this operation is performed atomically. >>> >>> but these methods are not, and can not be, atomic in ConcurrentMap >> >> I've altered the text to incorporate your suggestions. It now read: >> >> *

The default implementation makes no guarantees about synchronization >> * or atomicity properties of this method. Any class which wishes to provide >> * specific synchronization, atomicity or concurrency behaviour should >> * override this method. >> >> I would like to use this same text on the other methods as well. > > I'm okay with that, but you should check with whomever thought it necessary to call out the ConcurrentMap situation. ConcurrentMap will need to override these just to add the spec that they are atomic. I shall. ConcurrentMap already mentions that it's operations are atomic. The Concurrent.getOrDefault() default implementation doesn't appear to need a comment. > >>> forEach doesn't declare the IllegalStateException that getKey and getValue can throw. >> >> Since forEach isn't supposed to mutate the map this shouldn't happen. It could only happen through concurrent modification. I've added a catch of the IllegalStateException and throw CME with the ISE as the cause to both forEach and replaceAll. > > Not sure I see the distinction. These are Map methods so regardless of which method is involved you will only get the IllegalStateException if there is concurrent modification. Hence to me forEach and replaceAll should behave the same way, for example. OK, check the webrev when I post it. They are now consistent. > >>> Some/many of the @throws text has obviously been copied from the Map.Entry methods eg: >>> >>> * @throws ClassCastException if the class of the specified value >>> * prevents it from being stored in the backing map >>> >>> but when put into Map itself they should not be referring to "the backing map" as there is no "backing map". Further we have inconsistent terminology being used, eg getOrDefault has: >>> >>> * @throws ClassCastException if the key is of an inappropriate type for >>> * this map >>> >>> and then there is a third variant in other methods: >>> >>> * @throws ClassCastException if the class of the specified key or value >>> * prevents it from being stored in this map >>> * (optional) >>> >>> These should all have the same basic wording, differing only in key/value. >> >> agreed. The third variant is now used consistently. > > Why do we need the xref to "optional" ? Is throwing CCE optional? Other Collection methods don't flag it as optional. Since this method is applied to collections who's underlying implementation may or may not throw CCE we have to document that it's optional. Without the "optional" it would be required to throw the CCE in the described condition and we can't guarantee that the map will do that. > >>>> compute() * >>>> merge() * >>>> computeIfAbsent() * >>>> computeIfPresent() * >>> >>> The following generally apply to this group of methods. >> >>> I find the spec for these rather confusing from a concurrency perspective - this non-concurrent interface seems to be trying to say too much about how a concurrent interface should specify behaviour. Why does it need to say: >>> >>> * In concurrent contexts, the default implementation may retry >>> * these steps when multiple threads attempt updates. >> >> For default on Map I am starting to think that throwing that CME rather than looping is the right choice. The retry behaviour seems to be counter the basic behaviour of non-concurrent implementations. The retry behaviour will just hide usage that's otherwise unsafe when used with non-concurrent implementations. >> >> The concurrent implementations don't use these defaults so there's no problem switching to throwing CME. >> >> Opinions? > > I had assumed the loops only existed because you wanted to use them as ConcurrentMap defaults too! If that is not the case then these methods should not loop/retry but just throw CME, in my opinion. Correction (of my previous statement). ConcurrentMap reabstracts only the defaults for putIfAbsent, remove(Object,Object), replace(K,V), replace(K,V,V). The defaults are used compute, computeIfAbsent, computeIfPresent and merge. I am inclined to move these implementations as defaults to ConcurrentMap and replace the defaults in Map with ones that throw CME. Mike. From mike.duigou at oracle.com Thu Apr 11 05:42:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 10 Apr 2013 22:42:49 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: I've posted an updated webrev with the review comments I have received. http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ One important point to consider: - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. Thoughts? Mike On Apr 8 2013, at 11:07 , Mike Duigou wrote: > Hello all; > > This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ > > 8004518: Add in-place operations to Map > forEach() > replaceAll() > > 8010122: Add atomic operations to Map > getOrDefault() > putIfAbsent() * > remove(K, V) > replace(K, V) > replace(K, V, V) > compute() * > merge() * > computeIfAbsent() * > computeIfPresent() * > > The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). > > The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. > > Mike From peter.levart at gmail.com Thu Apr 11 06:23:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 Apr 2013 08:23:29 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> Message-ID: <516656E1.4040101@gmail.com> On 04/11/2013 06:41 AM, Mike Duigou wrote: > >> General style issues: >> >> - spaces after keyword ie "if (x == null)" not "if(x == null)" > Fixed. I am sorry this keeps coming up. I am loathe to run an automatic formatter on any JDK code. > Hi Mike, I find IDEA's feature very useful. It can reformat just the selection, not touching anything else. Peter From peter.levart at gmail.com Thu Apr 11 06:31:43 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 Apr 2013 08:31:43 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516644E9.9080907@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> <516644E9.9080907@oracle.com> Message-ID: <516658CF.9000100@gmail.com> On 04/11/2013 07:06 AM, David Holmes wrote: >>> I find the spec for these rather confusing from a concurrency >>> perspective - this non-concurrent interface seems to be trying to >>> say too much about how a concurrent interface should specify >>> behaviour. Why does it need to say: >>> >>> * In concurrent contexts, the default implementation may retry >>> * these steps when multiple threads attempt updates. >> >> For default on Map I am starting to think that throwing that CME >> rather than looping is the right choice. The retry behaviour seems to >> be counter the basic behaviour of non-concurrent implementations. The >> retry behaviour will just hide usage that's otherwise unsafe when >> used with non-concurrent implementations. >> >> The concurrent implementations don't use these defaults so there's no >> problem switching to throwing CME. >> >> Opinions? > > I had assumed the loops only existed because you wanted to use them as > ConcurrentMap defaults too! If that is not the case then these methods > should not loop/retry but just throw CME, in my opinion. That's better, yes. But then new methods (not part of existing ConcurrentMap API) should be overriden with defaults that do the looping in ConcurrentMap interface. We still want those methods to behave atomically in ConcurrentMaps that don't implement their own atomic variants. Regards, Peter > > Thanks, > David From peter.levart at gmail.com Thu Apr 11 08:46:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 Apr 2013 10:46:29 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <51667865.1050103@gmail.com> On 04/11/2013 07:42 AM, Mike Duigou wrote: > I've posted an updated webrev with the review comments I have received. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ > > One important point to consider: > > - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. > > Thoughts? > > Mike Hi Mike, Yes, that's much better. Just copy those methods to ConcurrentMap and replace them in Map with simplified variants. I suggest implementing each of them only in terms of existing (non-default) Map methods, so that their behaviour is stable in case any of them is selectively overriden. For example, like the following: default V putIfAbsent(K key, V value) { V oldValue = get(key); if (oldValue == null && put(key, value) != null) { throw new ConcurrentModificationException(); } return oldValue; } default V computeIfAbsent(K key, Function mappingFunction) { V oldValue = get(key), newValue; if (oldValue == null && (newValue = mappingFunction.apply(key)) != null) { if (put(key, newValue) != null) { throw new ConcurrentModificationException(); } return newValue; } else { return oldValue; } } default V computeIfPresent(K key, BiFunction remappingFunction) { V oldValue = get(key); if (oldValue != null) { V newValue = remappingFunction.apply(key, oldValue); if (newValue != null) { if (put(key, newValue) != oldValue) { throw new ConcurrentModificationException(); } } else if (remove(key) != oldValue) { throw new ConcurrentModificationException(); } return newValue; } return oldValue; } default V compute(K key, BiFunction remappingFunction) { V oldValue = get(key); V newValue = remappingFunction.apply(key, oldValue); if (newValue != null) { if (put(key, newValue) != oldValue) { throw new ConcurrentModificationException(); } } else if (*oldValue != null* && remove(key) != oldValue) { throw new ConcurrentModificationException(); } return newValue; } default V merge(K key, V value, BiFunction remappingFunction) { V oldValue = get(key); V newValue = oldValue == null ? value : remappingFunction.apply(oldValue, value); if (newValue != null) { if (put(key, newValue) != oldValue) { throw new ConcurrentModificationException(); } } else if (*oldValue != null* && remove(key) != oldValue) { throw new ConcurrentModificationException(); } return newValue; } A subtle spec. question is whether the bold "*oldValue != null*" condition in compute() and merge() is to be kept or removed . So if the null return from the remappingFunction tries to remove the null value in possible old mapping or not (the looping variants do not remove it). That's a subtle divergence of looping atomic implementation from the spec., which currently says: *

If the function returns {@code null}, the mapping is removed (or * remains absent if initially absent). So either we change the spec. to say that the possible mapping to null value remains if function returns null, or we must explicitly state in ConcurrentMap's overriden default method that it is not entirely by the spec. A less subtle question is whether in general the spec. and the implementation for new default methods in Map should be kept in-sync with the implementation of their overriden counterparts in ConcurrentMap as far as null values in existent mappings are concerned (all other aspects of nulls be same). You suggested that for ConcurrentMap.getOrDefault() the implementation could diverge from the spec. to allow atomic implementation with a note in javadoc that any ConcurrentMap implementation that allows null values (which is currently non-existent) should override the method and implement it by the spec. In other words, the javadoc for default implementation of ConcurrentMap.getOrDefault() would explicitly state that it is *not* implemented by the spec. as far null values in existent mappings is concerned. If we accept this "divergence" of default implementation from the spec. (which does not affect existent ConcurrentMap implementations in any way) then such subtle differences are permissible, otherwise we should tailor the spec. so that it can be obeyed by both Map and ConcurrentMap default implementations. The most important aspect I think is that all default methods in ConcurrentMap be atomic. The existent null values aspect is not more important than atomicity. I also just noticed the following: Map.putIfAbsent: 627 * @return the previous value associated with the specified key, or 628 **{@code 1}* if there was no mapping for the key. 629 * (A null return can also indicate that the map 630 * previously associated null with the key, 631 * if the implementation supports null values.) "1"? Regards, Peter > > On Apr 8 2013, at 11:07 , Mike Duigou wrote: > >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >> >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() >> >> 8010122: Add atomic operations to Map >> getOrDefault() >> putIfAbsent() * >> remove(K, V) >> replace(K, V) >> replace(K, V, V) >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * >> >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike From vladimir.voskresensky at oracle.com Thu Apr 11 11:13:42 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky - Oracle) Date: Thu, 11 Apr 2013 15:13:42 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <5159B162.4080805@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> <5156C697.8060003@oracle.com> <5159B162.4080805@oracle.com> Message-ID: <51669AE6.3010201@oracle.com> Hi Jesper, Just interested in the progress with review/push :-) Any news? Thanks, Vladimir. On 04/ 1/13 08:10 PM, Vladimir Voskresensky - Oracle wrote: > Jesper, > > Minor comment: it's better to have env variable named IDE_ALT_BOOTDIR instead > of IDE_JAVAPATH to give analogy with the old well known meaning. > > Vladimir. > > On 03/30/13 03:03 PM, Vladimir Voskresensky wrote: >> Jesper, >> >> It looks good and works for me on Linux_64. >> >> Some comments for others: >> before running IDE specify IDE_JAVAPATH env variable if want to navigate into >> some java/include files (value is the same as previously was known as >> ALT_BOOTDIR): >> #export IDE_JAVAPATH=/opt/jdk/latest7 >> after opening project, make sure you are switched to Linux configuration >> >> Thanks! >> Vladimir. >> >> On 03/27/2013 08:04 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> A new webrev is now available. The issues reported from the first review >>> should be fixed and the project now contains configurations for both >>> Linux_64 and Mac_64. >>> >>> To select configuration there is a dropdown menu next to the build button. >>> >>> http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ >>> >>> Thanks, >>> /Jesper >>> >>> >>> Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >>>> Hi, >>>> >>>> Sorry for cross posting, but I think this could be useful for several areas. >>>> >>>> I would like to add Solaris Studio / NetBeans project files for the entire >>>> OpenJDK project. To clarify: One project that contains the entire OpenJDK. >>>> >>>> >>>> With the new build infrastructure in JDK 8 building the entire OpenJDK is >>>> fairly >>>> fast and even though I personally mostly work in the HotSpot tree, I tend to >>>> always clone and build the entire JDK forest. I find this to have several >>>> benefits. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>>> >>>> The configuration in this project is currently Mac only. Linux and Solaris >>>> configurations are also planned. >>>> >>>> The webrev is made from the jdk8/build repository which is where I think a >>>> change like this should go in. Let me know if you think something else. >>>> >>>> >>>> >>>> To use this project (once pushed): >>>> >>>> 1. Clone your favorite repository >>>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>>> >>>> 2. Get the whole forest >>>> cd hotspot-gc >>>> sh get_source.sh >>>> >>>> 3. Configure >>>> sh configure >>>> >>>> 4. Open Solaris studio / NetBeans and load the project. >>>> The project in located in the common directory. >>>> >>>> >>>> Thanks, >>>> /Jesper >> From Ulf.Zibis at CoSoCo.de Thu Apr 11 11:33:42 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 11 Apr 2013 13:33:42 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51635C13.808@CoSoCo.de> Message-ID: <51669F96.2000701@CoSoCo.de> Am 11.04.2013 05:20, schrieb Mike Duigou: > On Apr 8 2013, at 17:08 , Ulf Zibis wrote: > >> Why you use both, {@code...} and ... ? > legacy. We're trying to use {@code } in new work but only convert existing when it's convenient. The main reason for not doing a global replacement is that we all value concise diffs and replacing everywhere would generate significant noise. Agreed, but I meant lines of new code e.g. 610... 660... etc. Thanks for your feedback, -Ulf From Ulf.Zibis at CoSoCo.de Thu Apr 11 11:46:30 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 11 Apr 2013 13:46:30 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516656E1.4040101@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <51637B60.5080905@oracle.com> <516656E1.4040101@gmail.com> Message-ID: <5166A296.9070103@CoSoCo.de> Am 11.04.2013 08:23, schrieb Peter Levart: > Hi Mike, > > I find IDEA's feature very useful. It can reformat just the selection, not touching anything else. NetBeans IDE too :-) -Ulf From Alan.Bateman at oracle.com Thu Apr 11 11:51:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 12:51:26 +0100 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) In-Reply-To: <51663AF5.5000807@oracle.com> References: <51663AF5.5000807@oracle.com> Message-ID: <5166A3BE.10607@oracle.com> On 11/04/2013 05:24, Robert Field wrote: > Currently blocking lambda library pushes. Internal class reader used by > rmic does not support new constant pool constant types: > > CONSTANT_METHODHANDLE = 15; > > CONSTANT_METHODTYPE = 16; > > CONSTANT_INVOKEDYNAMIC = 18; > > > Please review the fix for CR: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011805 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8011805/ > The changes looks fine but I agree with Mike's comments on the test. One other comment on the test is that it looks like ClassConstantChecker opens the class file but never closes it. Ideally all tests would clean-up/close resources before they complete as otherwise it causes problems in some execution modes. -Alan. From dmitry.samersoff at oracle.com Thu Apr 11 12:23:55 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Apr 2013 16:23:55 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51531883.7070903@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> Message-ID: <5166AB5B.5050403@oracle.com> Jesper, Is it correct that this this project is for native part of JDK only? If yes - is it possible to rename it to OpenJDK_Native or create common/netbeans/native/OpenJDK to avoid any misunderstanding and future name conflicts? I hope sometimes OpenJDK_java project appears as well. -Dmitry On 2013-03-27 20:04, Jesper Wilhelmsson wrote: > Hi, > > A new webrev is now available. The issues reported from the first review > should be fixed and the project now contains configurations for both > Linux_64 and Mac_64. > > To select configuration there is a dropdown menu next to the build button. > > http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ > > Thanks, > /Jesper > > > Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several >> areas. >> >> I would like to add Solaris Studio / NetBeans project files for the >> entire >> OpenJDK project. To clarify: One project that contains the entire >> OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK >> is fairly >> fast and even though I personally mostly work in the HotSpot tree, I >> tend to >> always clone and build the entire JDK forest. I find this to have >> several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and >> Solaris >> configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I >> think a >> change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From vladimir.voskresensky at oracle.com Thu Apr 11 13:00:17 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky) Date: Thu, 11 Apr 2013 17:00:17 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <5166AB5B.5050403@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> <5166AB5B.5050403@oracle.com> Message-ID: <5166B3E1.1060104@oracle.com> Dmitry, On 04/11/2013 04:23 PM, Dmitry Samersoff wrote: > Jesper, > > Is it correct that this this project is for native part of JDK only? Yes, it is project around C/C++ part of OpenJDK, but it's build command creates full jdk image (i.e. with all java parts as well): ${MAKE} -f Makefile LOG=debug images > > If yes - is it possible to rename it to OpenJDK_Native or create > common/netbeans/native/OpenJDK to avoid any misunderstanding and future > name conflicts? what about simpler layout: common/native_project (or make/native_project) otherwise developer have to go several levels down: common, netbeans, native, OpenJDK Thanks, Vladimir. > > I hope sometimes OpenJDK_java project appears as well. > > -Dmitry > > On 2013-03-27 20:04, Jesper Wilhelmsson wrote: >> Hi, >> >> A new webrev is now available. The issues reported from the first review >> should be fixed and the project now contains configurations for both >> Linux_64 and Mac_64. >> >> To select configuration there is a dropdown menu next to the build button. >> >> http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ >> >> Thanks, >> /Jesper >> >> >> Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several >>> areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the >>> entire >>> OpenJDK project. To clarify: One project that contains the entire >>> OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK >>> is fairly >>> fast and even though I personally mostly work in the HotSpot tree, I >>> tend to >>> always clone and build the entire JDK forest. I find this to have >>> several benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and >>> Solaris >>> configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I >>> think a >>> change like this should go in. Let me know if you think something else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper > From Alan.Bateman at oracle.com Thu Apr 11 13:03:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 14:03:43 +0100 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> Message-ID: <5166B4AF.30902@oracle.com> On 10/04/2013 19:12, Mike Duigou wrote: > On Apr 9 2013, at 19:56 , Martin Buchholz wrote: > >> Mike, thanks. >> >> I don't see anything wrong in this version, although the ongoing complexification and special-case-ification (with attendant risk of bugs) of ArrayList and HashMap, the two most didactically important classes, continue to bother me. This change continues to feel marginal. > It was surprising to find just how many ArrayList and HashMap instances were empty and/or never used. Unfortunately it's harder to globally fix applications than it is to and special case code to ArrayList and HashMap. Right and I wonder if the performance folks could share some of the data that they have gathered on this. In any case, I think this patch is looking good now, assuming this is the near-to-final version: http://cr.openjdk.java.net/~mduigou/JDK-8011200/4/webrev/ One remaining point that I'm a bit uneasy about is ArrayList.writeObject writing out the size rather than the array length. It is specified to be the array backing the ArrayList. It's now ignored by readObject (which is good) but reconstituting on an older/other JDK release will/may reconstitute to the trimmed size. -Alan. From bourges.laurent at gmail.com Thu Apr 11 13:07:59 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 11 Apr 2013 15:07:59 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: <5165FE80.9040408@oracle.com> References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> <5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com> Message-ID: Jim and Sergey, 1/ Here are few benchmarks (based on mapBench again) running several modified versions of AAShapePipe: http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ - ref: 1 threads and 20 loops per thread, time: 3742 ms 2 threads and 20 loops per thread, time: 4756 ms 4 threads and 20 loops per thread, time: 8528 ms 1 threads and 20 loops per thread, time: 56264 ms 2 threads and 20 loops per thread, time: 75566 ms 4 threads and 20 loops per thread, time: 141546 ms - int4: 1 threads and 20 loops per thread, time: 3653 ms 2 threads and 20 loops per thread, time: 4684 ms 4 threads and 20 loops per thread, time: 8291 ms 1 threads and 20 loops per thread, time: 55950 ms 2 threads and 20 loops per thread, time: 74796 ms 4 threads and 20 loops per thread, time: 139924 ms - byte[]: 1 threads and 20 loops per thread, time: 3795 ms 2 threads and 20 loops per thread, time: 4605 ms 4 threads and 20 loops per thread, time: 8246 ms 1 threads and 20 loops per thread, time: 54961 ms 2 threads and 20 loops per thread, time: 72768 ms 4 threads and 20 loops per thread, time: 139430 ms - int4 / byte[] / rectangle cached in TileState: 1 threads and 20 loops per thread, time: 3610 ms 2 threads and 20 loops per thread, time: 4481 ms 4 threads and 20 loops per thread, time: 8225 ms 1 threads and 20 loops per thread, time: 54651 ms 2 threads and 20 loops per thread, time: 74516 ms 4 threads and 20 loops per thread, time: 140153 ms So you may be right, results are varying depending on the optimizations (int4, byte or all) ! Maybe I should test different versions on optimized pisces renderer ... Here is an updated patch: http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/ 2/ Thanks for your comments: actually a refactoring is possible to use a (shared) TileState instance replacing int[] bbox, rectangle bbox): - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox) it is very interesting here to propose an extensible tile state: maybe created by the renderer engine to cache other data ? - Rectangle and Rectangle2D are only used as the shape s and device rectangle given to CompositePipe.startSequence(): public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, int[] abox); Changing this interface may become difficult: AlphaColorPipe.java: 41: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, OK, [s, dev, abox] unused AlphaPaintPipe.java 81: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, create a paint context: PaintContext paintContext = sg.paint.createContext(sg.getDeviceColorModel(), devR, s.getBounds2D(), sg.cloneTransform(), sg.getRenderingHints()); GeneralCompositePipe.java: 62: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, abox unused and create a paint context: PaintContext paintContext = sg.paint.createContext(model, devR, s.getBounds2D(), sg.cloneTransform(), hints); SpanClipRenderer.java 68: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, Forward to another composite pipe return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox)); It could be possible to use TileState into PaintContext interface / fix implementations but it may become a tricky change (API change). What do you think ? Laurent 2013/4/11 Jim Graham > I'm pretty familiar with all of this code and there aren't any places that > save the tile array that I remember. The embedded code that Pisces was > taken from had some caching of alpha arrays, but we didn't use or keep that > when we converted it for use in the JDK... > > It occurs to me that since you are collecting the various pieces of > information into an object to store in the thread local storage, perhaps we > should convert to a paradigm where an entire Tile Generation sequence uses > that object "TileState?" as its main way to communicate info around the > various stages. Thus, you don't really need an int[4] to store the 4 > parameters, they could be stored directly in the TileState object. This > would require more sweeping changes to the pipeline, but it might make the > code a bit more readable (and make the hits to convert over more moot as > they would be improving readability and give more focus to the > relationships between all of the various bits of data). Then it simply > becomes a matter of managing the lifetime and allocation of the TileState > objects which is a minor update to the newly refactored code. > > ...jim > > On 4/10/13 3:59 PM, Sergey Bylokhov wrote: > > On 4/10/13 11:46 PM, Laurent Bourg?s wrote: >> >>> I see that some methods which take it as argument doesn't use them. And >>>> most of the time we pass AATileGenerator and abox[] to the same >>>> methods, so >>>> it could be merged? >>>> >>>> For now I did not want to modify the AAShapePipe signatures: abox[] is >>> filled by AATileGenerator implementations (ductus, pisces, others) in >>> order >>> to have the shape bounds and render only tiles covering this area. >>> >> You still have to check all the places, where these objects are filled >> and used, and refactoring is a good start, no? >> Otherwise, how can you prove that these arrays are used as you would >> expect, These arrays could be stored like the cache or re-used for other >> purpose(if someone don't want to create new arrays). >> Probably it will be good to split all your changes / to a few CR. >> - cleanup >> - Some small changes which gave us most speedup >> - all other things. >> ?? >> >>> >>> Also I suggest to use jmh for java micrbenchmarks. >>>> http://openjdk.java.net/****projects/code-tools/jmh >>>> >>>> > >>>> >>>> So your test will be: >>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java >>>> ** >>>> > >>>> >>>> >>>> Thanks, >>> I will try it asap >>> >>> Laurent >>> >>> >>>> -- >>>> Best regards, Sergey. >>>> >>>> >>>> >> >> From Alan.Bateman at oracle.com Thu Apr 11 13:14:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 14:14:30 +0100 Subject: RFR-8008118 In-Reply-To: References: <20130329135908.9CACE97129@rebar.astron.com> <5165A75A.9090309@oracle.com> Message-ID: <5166B736.7070902@oracle.com> On 10/04/2013 19:14, Martin Buchholz wrote: > I am happy with the latest webrev - ship it! Thanks, John! > > I agree, new version is so much better. Chris - are you sponsoring this one? -Alan. From bourges.laurent at gmail.com Thu Apr 11 13:19:56 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 11 Apr 2013 15:19:56 +0200 Subject: Fwd: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <514B8919.70705@oracle.com> <51594369.1050504@oracle.com> <515978A0.2050202@oracle.com> <515AA1D3.30004@oracle.com> <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> Message-ID: Anthony, Mandy, here the 4th patch: http://jmmc.fr/~bourgesl/share/webrev-8010297.4/ It only contains awt / swing / net classes that use PlatformLogger (no code modification). Laurent From chris.hegarty at oracle.com Thu Apr 11 13:28:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Apr 2013 14:28:32 +0100 Subject: RFR-8008118 In-Reply-To: <5166B736.7070902@oracle.com> References: <20130329135908.9CACE97129@rebar.astron.com> <5165A75A.9090309@oracle.com> <5166B736.7070902@oracle.com> Message-ID: <5166BA80.3060603@oracle.com> On 04/11/2013 02:14 PM, Alan Bateman wrote: > On 10/04/2013 19:14, Martin Buchholz wrote: >> I am happy with the latest webrev - ship it! Thanks, John! >> >> > I agree, new version is so much better. > > Chris - are you sponsoring this one? > > -Alan. In the quite lengthly discussion for this issue we seem to have missed a small change from the original review, /* ASCII Decimal representation uses 2.4 times as many bits as binary. */ errmsg = NEW(char, strlen(format) + strlen(detail) + 3 * sizeof(errnum)); + if (errmsg == NULL) + return; + -Chris. From bourges.laurent at gmail.com Thu Apr 11 13:29:56 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 11 Apr 2013 15:29:56 +0200 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> <5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com> Message-ID: Last idea: I will enhance Andrea's mapBench benchmark to have statistics per threads: number of loops, avg, min, max, stddev; I guess that the total bench time is not so representative as the thread pool can distribute the work load differently at each test => statistics will help to have better timing / comparison between bench runs. Regards, Laurent 2013/4/11 Laurent Bourg?s > Jim and Sergey, > > 1/ Here are few benchmarks (based on mapBench again) running several > modified versions of AAShapePipe: > http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ > - ref: > 1 threads and 20 loops per thread, time: 3742 ms > 2 threads and 20 loops per thread, time: 4756 ms > 4 threads and 20 loops per thread, time: 8528 ms > > 1 threads and 20 loops per thread, time: 56264 ms > 2 threads and 20 loops per thread, time: 75566 ms > 4 threads and 20 loops per thread, time: 141546 ms > > - int4: > 1 threads and 20 loops per thread, time: 3653 ms > 2 threads and 20 loops per thread, time: 4684 ms > 4 threads and 20 loops per thread, time: 8291 ms > > 1 threads and 20 loops per thread, time: 55950 ms > 2 threads and 20 loops per thread, time: 74796 ms > 4 threads and 20 loops per thread, time: 139924 ms > > - byte[]: > 1 threads and 20 loops per thread, time: 3795 ms > 2 threads and 20 loops per thread, time: 4605 ms > 4 threads and 20 loops per thread, time: 8246 ms > > 1 threads and 20 loops per thread, time: 54961 ms > 2 threads and 20 loops per thread, time: 72768 ms > 4 threads and 20 loops per thread, time: 139430 ms > > - int4 / byte[] / rectangle cached in TileState: > 1 threads and 20 loops per thread, time: 3610 ms > 2 threads and 20 loops per thread, time: 4481 ms > 4 threads and 20 loops per thread, time: 8225 ms > > 1 threads and 20 loops per thread, time: 54651 ms > 2 threads and 20 loops per thread, time: 74516 ms > 4 threads and 20 loops per thread, time: 140153 ms > > So you may be right, results are varying depending on the optimizations > (int4, byte or all) ! > Maybe I should test different versions on optimized pisces renderer ... > > Here is an updated patch: > http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/ > > > 2/ Thanks for your comments: actually a refactoring is possible to use a > (shared) TileState instance replacing int[] bbox, rectangle bbox): > - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox) > > it is very interesting here to propose an extensible tile state: maybe > created by the renderer engine to cache other data ? > > - Rectangle and Rectangle2D are only used as the shape s and device > rectangle given to CompositePipe.startSequence(): > public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > int[] abox); > > Changing this interface may become difficult: > AlphaColorPipe.java: > > 41: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > OK, [s, dev, abox] unused > > AlphaPaintPipe.java > > 81: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > create a paint context: > PaintContext paintContext = > sg.paint.createContext(sg.getDeviceColorModel(), > devR, > s.getBounds2D(), > sg.cloneTransform(), > sg.getRenderingHints()); > > GeneralCompositePipe.java: > > 62: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > abox unused and create a paint context: > PaintContext paintContext = > sg.paint.createContext(model, devR, s.getBounds2D(), > sg.cloneTransform(), > hints); > > SpanClipRenderer.java > > 68: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > Forward to another composite pipe > return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox)); > > It could be possible to use TileState into PaintContext interface / fix > implementations but it may become a tricky change (API change). > > What do you think ? > > Laurent > > > 2013/4/11 Jim Graham > >> I'm pretty familiar with all of this code and there aren't any places >> that save the tile array that I remember. The embedded code that Pisces >> was taken from had some caching of alpha arrays, but we didn't use or keep >> that when we converted it for use in the JDK... >> >> It occurs to me that since you are collecting the various pieces of >> information into an object to store in the thread local storage, perhaps we >> should convert to a paradigm where an entire Tile Generation sequence uses >> that object "TileState?" as its main way to communicate info around the >> various stages. Thus, you don't really need an int[4] to store the 4 >> parameters, they could be stored directly in the TileState object. This >> would require more sweeping changes to the pipeline, but it might make the >> code a bit more readable (and make the hits to convert over more moot as >> they would be improving readability and give more focus to the >> relationships between all of the various bits of data). Then it simply >> becomes a matter of managing the lifetime and allocation of the TileState >> objects which is a minor update to the newly refactored code. >> >> ...jim >> >> On 4/10/13 3:59 PM, Sergey Bylokhov wrote: >> >> On 4/10/13 11:46 PM, Laurent Bourg?s wrote: >>> >>>> I see that some methods which take it as argument doesn't use them. And >>>>> most of the time we pass AATileGenerator and abox[] to the same >>>>> methods, so >>>>> it could be merged? >>>>> >>>>> For now I did not want to modify the AAShapePipe signatures: abox[] is >>>> filled by AATileGenerator implementations (ductus, pisces, others) in >>>> order >>>> to have the shape bounds and render only tiles covering this area. >>>> >>> You still have to check all the places, where these objects are filled >>> and used, and refactoring is a good start, no? >>> Otherwise, how can you prove that these arrays are used as you would >>> expect, These arrays could be stored like the cache or re-used for other >>> purpose(if someone don't want to create new arrays). >>> Probably it will be good to split all your changes / to a few CR. >>> - cleanup >>> - Some small changes which gave us most speedup >>> - all other things. >>> ?? >>> >>>> >>>> Also I suggest to use jmh for java micrbenchmarks. >>>>> http://openjdk.java.net/****projects/code-tools/jmh >>>>> >>>>> > >>>>> >>>>> So your test will be: >>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java >>>>> ** >>>>> > >>>>> >>>>> >>>>> Thanks, >>>> I will try it asap >>>> >>>> Laurent >>>> >>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>>> >>>>> >>> >>> > From Alan.Bateman at oracle.com Thu Apr 11 13:36:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 14:36:39 +0100 Subject: Add getChars to CharSequence In-Reply-To: References: Message-ID: <5166BC67.7070703@oracle.com> On 11/04/2013 01:40, Martin Buchholz wrote: > I've often wished that CharSequence had getChars methods, as many of > the concrete implementations already do. > In jdk8 with default methods, this is possible! > This will make some of the String code a little nicer and more efficient. > > Here's a preliminary patch in this direction, that overlaps with some > of the work done in > > 6206780: (str) Forwarding append methods in String{Buffer,Builder} are > inconsistent > Summary: update StringBuilder & StringBuffer to consistently handle > forwarding to AbstractStringBuilder. Some additional cleanup (removal > of refs to sub-classes from AbstractStringBuilder) > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ > > > If we have consensus that this is a good idea, I can flesh this out. It's come up a few times and I agree it's worth trying out. You should probably add CharBuffer to the list to look at it. At least for the 3-arg getChars, then it will need consideration as to whether it works as relative bulk get (which it would if not overridden). Also the 5-args getChars will treat srcBegin/srcEnd as relative to the current position as it stands. -Alan From mandy.chung at oracle.com Thu Apr 11 15:25:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Apr 2013 08:25:24 -0700 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> Message-ID: <5166D5E4.3040305@oracle.com> Laurent, On 4/11/13 6:19 AM, Laurent Bourg?s wrote: > Anthony, Mandy, > > here the 4th patch: > http://jmmc.fr/~bourgesl/share/webrev-8010297.4/ Thanks for addressing the memory overhead concern and keeping this fix for clients of PlatformLogger. Looks good and I saw that you caught several existing bugs calling isLoggable with a mismatched level. I'd really like to see if we can avoid the boilerplate "if (isLoggable(...)) logger.fine(....)" and help ease of development and I file a RFE (8012006). src/solaris/classes/sun/awt/X11/XListPeer.java Nit: line 1906 you remove isLoggable call here. Was it intentional (as it doesn't call concatenate any string?)? I think it's better to use the pattern consistently. Approved and no need to regenerate a new webrev if you fix the above nit. thanks Mandy > It only contains awt / swing / net classes that use PlatformLogger (no code > modification). > > Laurent From mike.duigou at oracle.com Thu Apr 11 15:30:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 11 Apr 2013 08:30:44 -0700 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: <5166B4AF.30902@oracle.com> References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> <5166B4AF.30902@oracle.com> Message-ID: On Apr 11 2013, at 06:03 , Alan Bateman wrote: > On 10/04/2013 19:12, Mike Duigou wrote: >> On Apr 9 2013, at 19:56 , Martin Buchholz wrote: >> >>> Mike, thanks. >>> >>> I don't see anything wrong in this version, although the ongoing complexification and special-case-ification (with attendant risk of bugs) of ArrayList and HashMap, the two most didactically important classes, continue to bother me. This change continues to feel marginal. >> It was surprising to find just how many ArrayList and HashMap instances were empty and/or never used. Unfortunately it's harder to globally fix applications than it is to and special case code to ArrayList and HashMap. > Right and I wonder if the performance folks could share some of the data that they have gathered on this. I started this review cycle with high level numbers for a wide variety of Java applications that the performance team looked at. Across these applications 1.4%(?2.9%) of HashMaps were forever empty and a similar percentage spent a large portion of their lifetime empty. For ArrayList the numbers were 1.0%(?2.6%) are forever empty and a larger percentage spent much of their life empty. As a percentage of heap space the empty instances account for about 1%. For some applications the numbers are much worse. Of the empty instances 85% were created at default size. > In any case, I think this patch is looking good now, assuming this is the near-to-final version: > > http://cr.openjdk.java.net/~mduigou/JDK-8011200/4/webrev/ Correct. I am running it through final pre-integration tests now. Some performance testing has been done on the second review version of this patch (the last before removing initialCapacity fields unfortunately) which shows no performance regressions across our reference workloads and a few significant improvements (a GC benchmark). > > One remaining point that I'm a bit uneasy about is ArrayList.writeObject writing out the size rather than the array length. It is specified to be the array backing the ArrayList. It's now ignored by readObject (which is good) but reconstituting on an older/other JDK release will/may reconstitute to the trimmed size. It's not harmful that it does so. This effectively forces the trimming behaviour in all deserialization cases. Mike From bourges.laurent at gmail.com Thu Apr 11 15:43:38 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 11 Apr 2013 17:43:38 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <5166D5E4.3040305@oracle.com> References: <515ACB0A.30101@oracle.com> <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> Message-ID: Mandy, I'd really like to see if we can avoid the boilerplate "if (isLoggable(...)) logger.fine(....)" and help ease of development and I file a RFE (8012006). Agreed but there is no easy way to have clear code and performance: - maybe JDK 8 Supplier may help - or a shorter syntax: logger.isDebug() or testing its effective level directly: if (logger.isDebug) - annotation syntax: @logCheck() but it is not straightforward to guess the correct level of the log statement ... I don't understand if I should fix it or not ? src/solaris/classes/sun/awt/X11/XListPeer.java > Nit: line 1906 you remove isLoggable call here. Was it intentional (as it > doesn't call concatenate any string?)? I think it's better to use the > pattern consistently. > it's a mistake (cookie). > Approved and no need to regenerate a new webrev if you fix the above nit. > To fix it, I need to send you files as a new webrev ? Laurent From mandy.chung at oracle.com Thu Apr 11 15:52:47 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Apr 2013 08:52:47 -0700 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> Message-ID: <5166DC4F.8090206@oracle.com> On 4/11/13 8:43 AM, Laurent Bourg?s wrote: > > I don't understand if I should fix it or not ? > > src/solaris/classes/sun/awt/X11/XListPeer.java > Nit: line 1906 you remove isLoggable call here. Was it > intentional (as it doesn't call concatenate any string?)? I think > it's better to use the pattern consistently. > > > it's a mistake (cookie). Please fix it. > Approved and no need to regenerate a new webrev if you fix the > above nit. > > > To fix it, I need to send you files as a new webrev ? Anthony is going to sponsor for you and I think he asks for a webrev. So please send the latest webrev with this fix then. Mandy > > Laurent > From martinrb at google.com Thu Apr 11 16:00:39 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Apr 2013 09:00:39 -0700 Subject: RFR-8008118 In-Reply-To: <5166BA80.3060603@oracle.com> References: <20130329135908.9CACE97129@rebar.astron.com> <5165A75A.9090309@oracle.com> <5166B736.7070902@oracle.com> <5166BA80.3060603@oracle.com> Message-ID: Agreed. When I worked on this, I was only looking at the more difficult one. The NULL check for errmsg should be merged back in. On Thu, Apr 11, 2013 at 6:28 AM, Chris Hegarty wrote: > On 04/11/2013 02:14 PM, Alan Bateman wrote: > >> On 10/04/2013 19:14, Martin Buchholz wrote: >> >>> I am happy with the latest webrev - ship it! Thanks, John! >>> >>> >>> I agree, new version is so much better. >> >> Chris - are you sponsoring this one? >> >> -Alan. >> > > > In the quite lengthly discussion for this issue we seem to have missed a > small change from the original review, > > /* ASCII Decimal representation uses 2.4 times as many bits as binary. > */ > errmsg = NEW(char, strlen(format) + strlen(detail) + 3 * > sizeof(errnum)); > + if (errmsg == NULL) > + return; > + > > -Chris. > From chris.hegarty at oracle.com Thu Apr 11 16:04:54 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Apr 2013 17:04:54 +0100 Subject: RFR-8008118 In-Reply-To: References: <20130329135908.9CACE97129@rebar.astron.com> <5165A75A.9090309@oracle.com> <5166B736.7070902@oracle.com> <5166BA80.3060603@oracle.com> Message-ID: <5166DF26.9020004@oracle.com> On 04/11/2013 05:00 PM, Martin Buchholz wrote: > Agreed. When I worked on this, I was only looking at the more difficult > one. The NULL check for errmsg should be merged back in. John, If you merge back in this small change, then I can sponsor the change into jdk8/tl/jdk for you. Please also provide the 'Reviewed-by' & 'Contributed-by' values for the changeset. It is not obvious ;-) You could probably take this offline, and then just mail the 'hg export'. -Chris. > > > On Thu, Apr 11, 2013 at 6:28 AM, Chris Hegarty > wrote: > > On 04/11/2013 02:14 PM, Alan Bateman wrote: > > On 10/04/2013 19:14, Martin Buchholz wrote: > > I am happy with the latest webrev - ship it! Thanks, John! > > > I agree, new version is so much better. > > Chris - are you sponsoring this one? > > -Alan. > > > > In the quite lengthly discussion for this issue we seem to have > missed a small change from the original review, > > /* ASCII Decimal representation uses 2.4 times as many bits as > binary. */ > errmsg = NEW(char, strlen(format) + strlen(detail) + 3 * > sizeof(errnum)); > + if (errmsg == NULL) > + return; > + > > -Chris. > > From bourges.laurent at gmail.com Thu Apr 11 16:08:06 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 11 Apr 2013 18:08:06 +0200 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: <5166DC4F.8090206@oracle.com> References: <515D6C6F.30104@oracle.com> <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> <5166DC4F.8090206@oracle.com> Message-ID: Anthony, Here is the updated webrev: http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ Laurent 2013/4/11 Mandy Chung > On 4/11/13 8:43 AM, Laurent Bourg?s wrote: > > > I don't understand if I should fix it or not ? > > src/solaris/classes/sun/awt/X11/XListPeer.java >> Nit: line 1906 you remove isLoggable call here. Was it intentional (as >> it doesn't call concatenate any string?)? I think it's better to use the >> pattern consistently. >> > > it's a mistake (cookie). > > > Please fix it. > > > > >> Approved and no need to regenerate a new webrev if you fix the above nit. >> > > To fix it, I need to send you files as a new webrev ? > > > Anthony is going to sponsor for you and I think he asks for a webrev. So > please send the latest webrev with this fix then. > > Mandy > > > Laurent > > > From mandy.chung at oracle.com Thu Apr 11 16:11:23 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Apr 2013 09:11:23 -0700 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> <5166DC4F.8090206@oracle.com> Message-ID: <5166E0AB.5040207@oracle.com> On 4/11/13 9:08 AM, Laurent Bourg?s wrote: > Anthony, > > Here is the updated webrev: > http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ > Great. Ship it! Mandy > > > Laurent > > 2013/4/11 Mandy Chung > > > On 4/11/13 8:43 AM, Laurent Bourg?s wrote: >> >> I don't understand if I should fix it or not ? >> >> src/solaris/classes/sun/awt/X11/XListPeer.java >> Nit: line 1906 you remove isLoggable call here. Was it >> intentional (as it doesn't call concatenate any string?)? I >> think it's better to use the pattern consistently. >> >> >> it's a mistake (cookie). > > Please fix it. > > >> Approved and no need to regenerate a new webrev if you fix >> the above nit. >> >> >> To fix it, I need to send you files as a new webrev ? > > Anthony is going to sponsor for you and I think he asks for a > webrev. So please send the latest webrev with this fix then. > > Mandy > >> >> Laurent >> > > From Sergey.Bylokhov at oracle.com Thu Apr 11 17:01:37 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 11 Apr 2013 21:01:37 +0400 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> <5166DC4F.8090206@oracle.com> Message-ID: <5166EC71.9020502@oracle.com> Hello. New version looks fine to me. On 4/11/13 8:08 PM, Laurent Bourg?s wrote: > Anthony, > > Here is the updated webrev: > http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ > > > Laurent > > 2013/4/11 Mandy Chung > >> On 4/11/13 8:43 AM, Laurent Bourg?s wrote: >> >> >> I don't understand if I should fix it or not ? >> >> src/solaris/classes/sun/awt/X11/XListPeer.java >>> Nit: line 1906 you remove isLoggable call here. Was it intentional (as >>> it doesn't call concatenate any string?)? I think it's better to use the >>> pattern consistently. >>> >> it's a mistake (cookie). >> >> >> Please fix it. >> >> >> >> >>> Approved and no need to regenerate a new webrev if you fix the above nit. >>> >> To fix it, I need to send you files as a new webrev ? >> >> >> Anthony is going to sponsor for you and I think he asks for a webrev. So >> please send the latest webrev with this fix then. >> >> Mandy >> >> >> Laurent >> >> >> -- Best regards, Sergey. From martinrb at google.com Thu Apr 11 17:14:07 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Apr 2013 10:14:07 -0700 Subject: Add getChars to CharSequence In-Reply-To: <5166BC67.7070703@oracle.com> References: <5166BC67.7070703@oracle.com> Message-ID: On Thu, Apr 11, 2013 at 6:36 AM, Alan Bateman wrote: > On 11/04/2013 01:40, Martin Buchholz wrote: > >> I've often wished that CharSequence had getChars methods, as many of the >> concrete implementations already do. >> In jdk8 with default methods, this is possible! >> This will make some of the String code a little nicer and more efficient. >> >> Here's a preliminary patch in this direction, that overlaps with some of >> the work done in >> >> 6206780: (str) Forwarding append methods in String{Buffer,Builder} are >> inconsistent >> Summary: update StringBuilder & StringBuffer to consistently handle >> forwarding to AbstractStringBuilder. Some additional cleanup (removal of >> refs to sub-classes from AbstractStringBuilder) >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**getChars/< >> http://cr.openjdk.java.net/%**7Emartin/webrevs/openjdk8/**getChars/ >> > >> >> >> If we have consensus that this is a good idea, I can flesh this out. >> > It's come up a few times and I agree it's worth trying out. > > You should probably add CharBuffer to the list to look at it. At least for > the 3-arg getChars, then it will need consideration as to whether it works > as relative bulk get (which it would if not overridden). Also the 5-args > getChars will treat srcBegin/srcEnd as relative to the current position as > it stands. I thought about this a bit. getChars should be consistent with charAt, which does not move position and is relative to position. From Ulf.Zibis at CoSoCo.de Thu Apr 11 17:17:13 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 11 Apr 2013 19:17:13 +0200 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <5166B3E1.1060104@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> <5166AB5B.5050403@oracle.com> <5166B3E1.1060104@oracle.com> Message-ID: <5166F019.9010904@CoSoCo.de> Am 11.04.2013 15:00, schrieb Vladimir Voskresensky: >> If yes - is it possible to rename it to OpenJDK_Native or create >> common/netbeans/native/OpenJDK to avoid any misunderstanding and future >> name conflicts? > what about simpler layout: > common/native_project > (or make/native_project) > otherwise developer have to go several levels down: common, netbeans, native, OpenJDK I think "netbeans" should not be dropped in the path, as there are other concurrent IDE's in the world. I also see the possibility of an extra path: ide/netbeans/... tools/netbeans/... devtools/netbeans/... ... The latter could be used for different development help tools, e.g. webrev -Ulf From Ulf.Zibis at CoSoCo.de Thu Apr 11 19:55:08 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 11 Apr 2013 21:55:08 +0200 Subject: Add getChars to CharSequence In-Reply-To: References: Message-ID: <5167151C.6090601@CoSoCo.de> Hi Martin, great idea! Regarding the exception handling... You should reuse getCharsOutOfBounds() from AbstractStringBuilder in String. Also IMO the exception messages need some "corporate design"; e.g. in some cases the string "srcBegin > srcEnd" is returned, in other cases the int value of srcEnd - srcBegin, very messy. Resolved that, I'm sure you would need less, maybe only 1, package private method to build the exceptions argument. Anyway as those methods all need some CPU time to execute normally, I'm not sure if it's worth to save 1 comparison by outsourcing. Additionally having getCharsOutOfBounds as source for the exceptions cause/stacktrace could lead to some confusion. In interface CharSequence, the javadocs are missing. -Ulf Am 11.04.2013 02:40, schrieb Martin Buchholz: > I've often wished that CharSequence had getChars methods, as many of the > concrete implementations already do. > In jdk8 with default methods, this is possible! > This will make some of the String code a little nicer and more efficient. > > Here's a preliminary patch in this direction, that overlaps with some of > the work done in > > 6206780: (str) Forwarding append methods in String{Buffer,Builder} are > inconsistent > Summary: update StringBuilder & StringBuffer to consistently handle > forwarding to AbstractStringBuilder. Some additional cleanup (removal of > refs to sub-classes from AbstractStringBuilder) > > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ > > If we have consensus that this is a good idea, I can flesh this out. > From mike.duigou at oracle.com Thu Apr 11 20:03:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 11 Apr 2013 13:03:23 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> Message-ID: <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> Another revision incorporating primarily documentation feedback. http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. Mike On Apr 10 2013, at 22:42 , Mike Duigou wrote: > I've posted an updated webrev with the review comments I have received. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ > > One important point to consider: > > - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. > > Thoughts? > > Mike > > On Apr 8 2013, at 11:07 , Mike Duigou wrote: > >> Hello all; >> >> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >> >> 8004518: Add in-place operations to Map >> forEach() >> replaceAll() >> >> 8010122: Add atomic operations to Map >> getOrDefault() >> putIfAbsent() * >> remove(K, V) >> replace(K, V) >> replace(K, V, V) >> compute() * >> merge() * >> computeIfAbsent() * >> computeIfPresent() * >> >> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >> >> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >> >> Mike > From martinrb at google.com Thu Apr 11 20:37:05 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Apr 2013 13:37:05 -0700 Subject: Add getChars to CharSequence In-Reply-To: <5167151C.6090601@CoSoCo.de> References: <5167151C.6090601@CoSoCo.de> Message-ID: Alan, please file an rfe for us: Add default methods CharSequence.getChars to match String and StringBuilder. Ulf et al: The exception messages for out of bounds checks are maddeningly inconsistent. Are y'all OK with making them consistent and maximally informative? something like "start = %d, end = %d, length = %d". Throwing SIIOBE(srcEnd - srcBegin) as is currently done is confusing. Martin On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis wrote: > Hi Martin, > > great idea! > > Regarding the exception handling... > > You should reuse getCharsOutOfBounds() from AbstractStringBuilder in > String. > Also IMO the exception messages need some "corporate design"; e.g. in some > cases the string "srcBegin > srcEnd" is returned, in other cases the int > value of srcEnd - srcBegin, very messy. > Resolved that, I'm sure you would need less, maybe only 1, package private > method to build the exceptions argument. > > Anyway as those methods all need some CPU time to execute normally, I'm > not sure if it's worth to save 1 comparison by outsourcing. > Additionally having getCharsOutOfBounds as source for the exceptions > cause/stacktrace could lead to some confusion. > > In interface CharSequence, the javadocs are missing. > > -Ulf > > > Am 11.04.2013 02:40, schrieb Martin Buchholz: > > I've often wished that CharSequence had getChars methods, as many of the >> concrete implementations already do. >> In jdk8 with default methods, this is possible! >> This will make some of the String code a little nicer and more efficient. >> >> Here's a preliminary patch in this direction, that overlaps with some of >> the work done in >> >> 6206780: (str) Forwarding append methods in String{Buffer,Builder} are >> inconsistent >> Summary: update StringBuilder & StringBuffer to consistently handle >> forwarding to AbstractStringBuilder. Some additional cleanup (removal of >> refs to sub-classes from AbstractStringBuilder) >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**getChars/ >> >> If we have consensus that this is a good idea, I can flesh this out. >> >> > From Alan.Bateman at oracle.com Thu Apr 11 20:47:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 21:47:45 +0100 Subject: Add getChars to CharSequence In-Reply-To: References: <5166BC67.7070703@oracle.com> Message-ID: <51672171.3000103@oracle.com> On 11/04/2013 18:14, Martin Buchholz wrote: > > : > > I thought about this a bit. getChars should be consistent with > charAt, which does not move position and is relative to position. This is probably right although I think we'll need the spec overridden in CharBuffer to make this clear. You might be thinking of providing an implementation there anyway to avoid checking the position at each char. -Alan. From joe.darcy at oracle.com Thu Apr 11 20:48:21 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 11 Apr 2013 13:48:21 -0700 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? In-Reply-To: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> References: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> Message-ID: <51672195.7060909@oracle.com> Hello, I've filed 8012044: Give more information about self-suppression from Throwable.addSuppressed for this issue; it should be viewable on bugs.sun.com within a day or so. Cheers, -Joe On 04/08/2013 04:54 PM, Steven Schlansker wrote: > Today I encountered "java.lang.IllegalArgumentException: Self-suppression not permitted" from Throwable.addSuppressed. > > My first surprise is that the try-with-resources block can throw this exception; it is very confusing to have auto-generated code throw exceptions. But beyond that, it is impossible to figure out *which* exception caused the problem. If you have multiple resources acquired in the try-with-resources, it could be any of them. > > Would it be reasonable to change > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > > to > > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, this); > > so that when you get this exception it at least points to one of the throw sites that actually caused the problem? Otherwise the only stack trace you have is in auto-generated code and you are left scratching your head, wondering where it came from. I believe this would increase the debuggability of the try-with-resources construct and there's no immediately obvious downside. > > I'm not the only one who was confused by this behavior: > http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co > > From Alan.Bateman at oracle.com Thu Apr 11 20:49:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Apr 2013 21:49:28 +0100 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> Message-ID: <516721D8.9090604@oracle.com> On 11/04/2013 21:37, Martin Buchholz wrote: > Alan, please file an rfe for us: Add default methods > CharSequence.getChars to match String and StringBuilder. There are several to choose from, here's one of the long longing requests: 6813523: (str) Add method CharSequence.getChars() as StringBuilder.getChars() We can change the synopsis. -Alan From xueming.shen at oracle.com Thu Apr 11 20:47:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 13:47:01 -0700 Subject: Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime Message-ID: <51672145.3080504@oracle.com> Hi As part of the JSR310 Date/Time project, following methods are proposed to be added into java.nio.file.attribute.FileTime to interoperate with the new JSR310 time class Instant. public static FileTime from(Instant instant); public Instant toInstant(); http://cr.openjdk.java.net/~sherman/8011647/webrev Here are some notes regarding the changes. (1) With its design, the FileTime can store the time point on the time-line further in the future and further in the past than the Instant. To be consistent with the spec and implementation of existing to(TimeUnit)/ toMillis(), the proposed toInstant() saturates to the Instant.MIN/MAX when converting from a FileTime object that is beyond the supported time range of Instant (instead of throwing a "conversion failure" exception, such as a DateTimeException). Time points beyond the Instant range are not interesting in practical cases. (2) The internal supporting class DaysAndNanos is replaced by using the threeten Instant class directly. As the direct consequence, the hashCode() for those time points beyond the Instant.MIN/MAX range will be "compromised/saturated" into the hashCode value of Instant.MIN/MAX. As mentioned in (1), since those time points are not the interest of the FileTime class in real world use scenario, so we believe this is an acceptable compromise. The hashCode/equal contract still holds, though the usages of those "extra time points" may trigger worse performance. (3) compareTo() still provides correct ordering for all supported "time points", including those beyond Instant.MIN/MAX range. (4) toString() has been rewritten to use the threeten LocalDateTime class together with the "home-made" formatting code for better performance. Differences of the spec/implementation of FileTime and JSR310 date/time class listed below prevents us from using the new JSR310 formatter to format the FileTime directly. a) FileTime uses "old" ISO8601 version, in which it dis-allows the '0000' for proleptic year 0, while the JSR310 formats "0000" (which is supported in new version of 8601), so the format for all BCE years are different. b) LocalTime formats the "ss" part optionally. It appears to takes the "it is acceptable to omit lower order time elements..." alternative, while the "ss" part is mandated in FileTime toString(), even the second part is 0. c) FileTime formats the "fraction of second" part as "decimal fraction" while LocalTime uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips any tailing zero, but LocalDate does not if it fits into the 3-dit unit. Two addition tests have been used to provide more confidence for the "compatibility" and performance. http://cr.openjdk.java.net/~sherman/8011647/TestFileTime.java http://cr.openjdk.java.net/~sherman/8011647/TestFileTimeBM.java It is also suggested that it might be convenient for FileTime to implement java.time.TemporalAccessor, so the FileTime can be directly formatted by the JSR310 formatter. This is not included in this proposal. I may consider to add this in a later round of update. Thanks, -Sherman From martinrb at google.com Thu Apr 11 20:56:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Apr 2013 13:56:33 -0700 Subject: Add getChars to CharSequence In-Reply-To: <51672171.3000103@oracle.com> References: <5166BC67.7070703@oracle.com> <51672171.3000103@oracle.com> Message-ID: On Thu, Apr 11, 2013 at 1:47 PM, Alan Bateman wrote: > On 11/04/2013 18:14, Martin Buchholz wrote: > >> >> : >> >> I thought about this a bit. getChars should be consistent with charAt, >> which does not move position and is relative to position. >> > This is probably right although I think we'll need the spec overridden in > CharBuffer to make this clear. Agreed. > You might be thinking of providing an implementation there anyway to avoid > checking the position at each char. Right. We probably want to override in almost every performance-sensitive concrete implementation. From martinrb at google.com Thu Apr 11 21:12:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Apr 2013 14:12:52 -0700 Subject: Add getChars to CharSequence In-Reply-To: <5167151C.6090601@CoSoCo.de> References: <5167151C.6090601@CoSoCo.de> Message-ID: On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis wrote: > > Anyway as those methods all need some CPU time to execute normally, I'm > not sure if it's worth to save 1 comparison by outsourcing. > Saving one comparison is worth doing in any case in these performance-critical methods. "Out-lining" the creation of the detail message is a standard refactoring that is known to make hotspot happy. > Additionally having getCharsOutOfBounds as source for the exceptions > cause/stacktrace could lead to some confusion. > Let's use this sane exception detail: private String outOfBoundsMsg(int srcBegin, int srcEnd) { return "srcBegin = " + srcBegin + ", srcEnd = " + srcEnd + ", length() = " + count; } From robert.field at oracle.com Thu Apr 11 21:23:26 2013 From: robert.field at oracle.com (Robert Field) Date: Thu, 11 Apr 2013 14:23:26 -0700 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) In-Reply-To: <51663AF5.5000807@oracle.com> References: <51663AF5.5000807@oracle.com> Message-ID: <516729CE.9050806@oracle.com> Thank you Mike, Alan, and Brian for your reviews, and others for your assistance. Updated webrev: http://cr.openjdk.java.net/~rfield/8011805_2 Changes are all in the test: * Removed unused testWrite and related code. * Used correct copyright. * Added finally clauses which close file and clean-up. * Simplified code, removing rmic copied code. * Fixed @test comment format. -Robert On 04/10/13 21:24, Robert Field wrote: > Currently blocking lambda library pushes. Internal class reader used by > rmic does not support new constant pool constant types: > > CONSTANT_METHODHANDLE = 15; > > CONSTANT_METHODTYPE = 16; > > CONSTANT_INVOKEDYNAMIC = 18; > > > Please review the fix for CR: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011805 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8011805/ > From james.graham at oracle.com Thu Apr 11 21:42:16 2013 From: james.graham at oracle.com (Jim Graham) Date: Thu, 11 Apr 2013 14:42:16 -0700 Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste In-Reply-To: References: <51644C6F.1070404@oracle.com> <5164538B.9080804@oracle.com> <524F14A3.6080909@oracle.com> <5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com> Message-ID: <51672E38.10307@oracle.com> Hi Laurent, Yes, these kinds of minor optimizations (i.e. optimizations that don't make a clear 2x type of savings) can be frustrating at times. It looks like there is potential for a decent return there if we can find the right change. Sometimes rearranging a couple of things that don't look like they are saving work can somehow trip the runtime into executing the code more efficiently. I skimmed through your thoughts at the bottom. It occurred to me after I sent that idea out that sometimes we use int[] because we have to hand the values to native for return values and there is no easy way to return 4 values from a native method. An array is simplest because it can be loaded with answers via a single JNI call. 4 fields in a class would require 4xJNI.SetField calls. It might have better payoff if we can cache renderer state there as well which gets into subclassing. Also, doing this right may have to be done by someone here at Oracle because it may involve modifying the Ductus pipeline to match (it's been a while and I don't remember if we open sourced the code that interfaces Ductus to the RenderingEngine interfaces...?) ...jim On 4/11/13 6:07 AM, Laurent Bourg?s wrote: > Jim and Sergey, > > 1/ Here are few benchmarks (based on mapBench again) running several > modified versions of AAShapePipe: > http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ > - ref: > 1 threads and 20 loops per thread, time: 3742 ms > 2 threads and 20 loops per thread, time: 4756 ms > 4 threads and 20 loops per thread, time: 8528 ms > > 1 threads and 20 loops per thread, time: 56264 ms > 2 threads and 20 loops per thread, time: 75566 ms > 4 threads and 20 loops per thread, time: 141546 ms > > - int4: > 1 threads and 20 loops per thread, time: 3653 ms > 2 threads and 20 loops per thread, time: 4684 ms > 4 threads and 20 loops per thread, time: 8291 ms > > 1 threads and 20 loops per thread, time: 55950 ms > 2 threads and 20 loops per thread, time: 74796 ms > 4 threads and 20 loops per thread, time: 139924 ms > > - byte[]: > 1 threads and 20 loops per thread, time: 3795 ms > 2 threads and 20 loops per thread, time: 4605 ms > 4 threads and 20 loops per thread, time: 8246 ms > > 1 threads and 20 loops per thread, time: 54961 ms > 2 threads and 20 loops per thread, time: 72768 ms > 4 threads and 20 loops per thread, time: 139430 ms > > - int4 / byte[] / rectangle cached in TileState: > 1 threads and 20 loops per thread, time: 3610 ms > 2 threads and 20 loops per thread, time: 4481 ms > 4 threads and 20 loops per thread, time: 8225 ms > > 1 threads and 20 loops per thread, time: 54651 ms > 2 threads and 20 loops per thread, time: 74516 ms > 4 threads and 20 loops per thread, time: 140153 ms > > So you may be right, results are varying depending on the optimizations > (int4, byte or all) ! > Maybe I should test different versions on optimized pisces renderer ... > > Here is an updated patch: > http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/ > > > 2/ Thanks for your comments: actually a refactoring is possible to use a > (shared) TileState instance replacing int[] bbox, rectangle bbox): > - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox) > > it is very interesting here to propose an extensible tile state: maybe > created by the renderer engine to cache other data ? > > - Rectangle and Rectangle2D are only used as the shape s and device > rectangle given to CompositePipe.startSequence(): > public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > int[] abox); > > Changing this interface may become difficult: > AlphaColorPipe.java: > 41: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > OK, [s, dev, abox] unused > > AlphaPaintPipe.java > 81: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > create a paint context: > PaintContext paintContext = > sg.paint.createContext(sg.getDeviceColorModel(), > devR, > s.getBounds2D(), > sg.cloneTransform(), > sg.getRenderingHints()); > > GeneralCompositePipe.java: > 62: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > abox unused and create a paint context: > PaintContext paintContext = > sg.paint.createContext(model, devR, s.getBounds2D(), > sg.cloneTransform(), > hints); > > SpanClipRenderer.java > 68: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR, > Forward to another composite pipe > return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox)); > > It could be possible to use TileState into PaintContext interface / fix > implementations but it may become a tricky change (API change). > > What do you think ? > > Laurent > > 2013/4/11 Jim Graham > >> I'm pretty familiar with all of this code and there aren't any places that >> save the tile array that I remember. The embedded code that Pisces was >> taken from had some caching of alpha arrays, but we didn't use or keep that >> when we converted it for use in the JDK... >> >> It occurs to me that since you are collecting the various pieces of >> information into an object to store in the thread local storage, perhaps we >> should convert to a paradigm where an entire Tile Generation sequence uses >> that object "TileState?" as its main way to communicate info around the >> various stages. Thus, you don't really need an int[4] to store the 4 >> parameters, they could be stored directly in the TileState object. This >> would require more sweeping changes to the pipeline, but it might make the >> code a bit more readable (and make the hits to convert over more moot as >> they would be improving readability and give more focus to the >> relationships between all of the various bits of data). Then it simply >> becomes a matter of managing the lifetime and allocation of the TileState >> objects which is a minor update to the newly refactored code. >> >> ...jim >> >> On 4/10/13 3:59 PM, Sergey Bylokhov wrote: >> >> On 4/10/13 11:46 PM, Laurent Bourg?s wrote: >>> >>>> I see that some methods which take it as argument doesn't use them. And >>>>> most of the time we pass AATileGenerator and abox[] to the same >>>>> methods, so >>>>> it could be merged? >>>>> >>>>> For now I did not want to modify the AAShapePipe signatures: abox[] is >>>> filled by AATileGenerator implementations (ductus, pisces, others) in >>>> order >>>> to have the shape bounds and render only tiles covering this area. >>>> >>> You still have to check all the places, where these objects are filled >>> and used, and refactoring is a good start, no? >>> Otherwise, how can you prove that these arrays are used as you would >>> expect, These arrays could be stored like the cache or re-used for other >>> purpose(if someone don't want to create new arrays). >>> Probably it will be good to split all your changes / to a few CR. >>> - cleanup >>> - Some small changes which gave us most speedup >>> - all other things. >>> ?? >>> >>>> >>>> Also I suggest to use jmh for java micrbenchmarks. >>>>> http://openjdk.java.net/****projects/code-tools/jmh >>>>> >>>>>> >>>>> >>>>> So your test will be: >>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java >>>>> ** >>>>>> >>>>> >>>>> >>>>> Thanks, >>>> I will try it asap >>>> >>>> Laurent >>>> >>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>>> >>>>> >>> >>> > From forax at univ-mlv.fr Thu Apr 11 21:45:43 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 11 Apr 2013 23:45:43 +0200 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) In-Reply-To: <516729CE.9050806@oracle.com> References: <51663AF5.5000807@oracle.com> <516729CE.9050806@oracle.com> Message-ID: <51672F07.5080708@univ-mlv.fr> On 04/11/2013 11:23 PM, Robert Field wrote: > Thank you Mike, Alan, and Brian for your reviews, and others for your > assistance. > > Updated webrev: > > http://cr.openjdk.java.net/~rfield/8011805_2 > > Changes are all in the test: > > * Removed unused testWrite and related code. > * Used correct copyright. > * Added finally clauses which close file and clean-up. > * Simplified code, removing rmic copied code. > * Fixed @test comment format. > > -Robert Hi Robert, in BinaryConstantPool, using a local variable when writing the constant pool constants makes the code easier to read, IMO. case CONSTANT_METHODHANDLE: case CONSTANT_METHODTYPE: case CONSTANT_INVOKEDYNAMIC: { byte[] array = (byte[])x; out.write(array, 0, array.length); break; } otherwise, thumb up. R?mi > > On 04/10/13 21:24, Robert Field wrote: >> Currently blocking lambda library pushes. Internal class reader used by >> rmic does not support new constant pool constant types: >> >> CONSTANT_METHODHANDLE = 15; >> >> CONSTANT_METHODTYPE = 16; >> >> CONSTANT_INVOKEDYNAMIC = 18; >> >> >> Please review the fix for CR: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011805 >> >> Webrev: >> >> http://cr.openjdk.java.net/~rfield/8011805/ >> > From forax at univ-mlv.fr Thu Apr 11 22:03:40 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 12 Apr 2013 00:03:40 +0200 Subject: RFR JDK-8011200 (was 7143928) : (coll) Optimize for Empty ArrayList and HashMap In-Reply-To: References: <634FBCCB-EB8D-4251-843C-C75F6583E869@oracle.com> <950FAE2E-2AD3-4F64-9122-7BB3373295FA@oracle.com> <4CE4DAD4-5A5B-4542-B480-8DE65328C139@oracle.com> <21596AAC-4000-4AB5-B390-1C947687B7C7@oracle.com> <5165F33F.9050705@univ-mlv.fr> Message-ID: <5167333C.3030805@univ-mlv.fr> On 04/11/2013 01:33 AM, Vitaly Davidovich wrote: > > The null check jumps should be taken care of by branch prediction; as > long as they're predictable, penalty on OOO CPU is minimal. So modern > CPUs don't like mispredicted branches I'd say, not just any jump. > yes :) R?mi > On Apr 10, 2013 7:23 PM, "Remi Forax" > wrote: > > On 04/10/2013 11:26 PM, Martin Buchholz wrote: > > I'm willing to accept John as an authority on hotspot > optimization. > I'm surprised that null checks aren't more close to free in > part because > recent jsr166 code has been introducing more explicit null checks, > sometimes in code where the reference being checked is "known" > not to be > null. > > Martin > > > null check that are never null are free when the interpreter has > never (or rarely) sees a null > at a specific callsite because in that case, the JIT doesn't > generate a null check and > let the CPU/MMU do a fault (the VM has a signal handler to be able > to come back from death :) > > If you set a field to null, the profiler will see the null and > will not use this optimization, > that why in this case, it's better to have an empty array instead > of null. > BTW, the nullcheck in assembler cost you almost nothing anyway but > the jump > associated with it has a cost. Modern CPUs do not like to jump. > > R?mi > > > > On Wed, Apr 10, 2013 at 11:12 AM, Mike Duigou > >wrote: > > On Apr 9 2013, at 19:56 , Martin Buchholz wrote: > The use of an empty array rather than null was suggested > by John Rose who > said: > > I recommend an empty array rather than null as a sentinel > value for two > reasons: > > 1. The JVM prefers to merge null checks into load or store > instructions > (so-called "implicit null checks") because it removes an > explicit branch. > But it only does so if the probability of nulls is zero or > very low. But > using null as a sentinel for common states (e.g., empty > collection) defeats > this optimization. > > 2. For power-of-two sized structures (HashMap) we can > optimize away an > array range check in the presence of a zero-length check. > > Since most uses of a variable-sized collection load and > test the array > length, the sentinel check can easily be overloaded onto > this test. If null > is not used, then the (safety-mandated) null check is > (usually) merged into > the load of the length. If the table is > power-of-two-sized, then only the > zero check remains, and the array range check may be > removed. This is > thought to be the best code for a frequent load from a > possibly-empty > collection. > > Mike asked, "what about empty collection?" This is a > reasonable thing to > use, but it has a cost. The JVM uses inline caches and > type profiles to > simplify its optimized code; these techniques "win" when > at a given use > point (individual call to Map.get, for example) there is > only one class > present, even if the interface is totally general. (This > is the so-called > "monomorphic" case.) If the application uses (say) only > HashMaps for both > empty and non-empty maps, then this optimization can win > big. It can be > broken, on the other hand, if the application begins to > use one other type > for some other case (such as empty maps). In these cases, > it is better to > overload the "am I empty?" test on some other loaded > value, such as a null > or (better) an array length. > > > Mike > > From Ulf.Zibis at CoSoCo.de Thu Apr 11 22:15:12 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 12 Apr 2013 00:15:12 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> Message-ID: <516735F0.6080705@CoSoCo.de> Am 11.04.2013 22:03, schrieb Mike Duigou: > Another revision incorporating primarily documentation feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ There is still a yoda style in ConcurrentMap line 72, HashMap line 361 To be in line with old habits, please remove space after casts. See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 Collections: lines 1442... + 3900... , indentation for follow up line should be 8 Map: lines 599..600 bad indentation Use consistent formatted code examples in javadoc. I like the style from lines 567 to 570, but e.g. from line 622 to 626: - 2 spaces before 

- indentation should be 4
- line break before }
-Ulf From jim.gish at oracle.com Thu Apr 11 22:33:41 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 11 Apr 2013 18:33:41 -0400 Subject: RFR: String.join(), StringJoiner additions Message-ID: <51673A45.8060908@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ These are changes that we made in lambda that we're now bringing into JDK8. I've made a couple of additions - making StringJoiner final and adding a couple of constructors to set the emptyOutput chars. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From john.r.rose at oracle.com Thu Apr 11 23:25:34 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Apr 2013 16:25:34 -0700 Subject: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <51532DF4.9020701@oracle.com> <07BCD649-AB70-455B-9BEC-90473E0C4CDE@oracle.com> <515B2C7F.1030508@oracle.com> <515B5519.6020603@gmail.com> <515B5AC4.2090902@oracle.com> , <515C79B8.1070201@oracle.com> Message-ID: <2C9A6D44-299D-4167-9AC0-BDC95FA7BBBE@oracle.com> On Apr 3, 2013, at 11:00 PM, Jeroen Frijters wrote: > Given the ability to create constructorless subclasses, it really should be combined with making the class final. > > My current rules for @CallerID (which unlike @CallerSensitive is not just about semantics, but also about implementation strategy) allow it only to be used on static methods and instance methods in final classes (in theory constructors would also be allowed, but I didn't implement that since I didn't encounter any that were worthwhile). Yes, making the class final fixes the interface problem, and in a portable way. It doesn't fix the ACC_SYNTHETIC problem. > An implicit rule is that a @CallerID instance methods may not implement an interface method. Another way to skin that cat is to have the JVM refuse to populate an i-table (or non-HotSpot equivalent) with CallerID. It could populate the table entry with the thing that throws an AME or ICCE when a signature fails to match. In effect, there would be an extra signature match enforced on such calls. > Another thought that occurred to me was that there should probably be a test that goes through rt.jar and makes sure no ACC_BRIDGE or ACC_SYNTHETIC methods call @CallerSensitive methods. That's an excellent point. Similar cat-skinning idea: The check could be done at link time, and throw something like ICCE. (These are all JVM-centric ideas; that's the biggest hammer in my own toolkit.) ? John From joe.darcy at oracle.com Fri Apr 12 01:19:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 11 Apr 2013 18:19:30 -0700 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed Message-ID: <51676122.4020802@oracle.com> Hello, Please review the patch below to address 8012044: Give more information about self-suppression from Throwable.addSuppressed http://cr.openjdk.java.net/~darcy/8012044.0/ Thanks, -Joe diff -r 006a7a576fe9 src/share/classes/java/lang/Throwable.java --- a/src/share/classes/java/lang/Throwable.java Thu Apr 11 12:22:23 2013 +0900 +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 11 18:16:38 2013 -0700 @@ -1039,7 +1039,7 @@ */ public final synchronized void addSuppressed(Throwable exception) { if (exception == this) - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); if (exception == null) throw new NullPointerException(NULL_CAUSE_MESSAGE); diff -r 006a7a576fe9 test/java/lang/Throwable/SuppressedExceptions.java --- a/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 12:22:23 2013 +0900 +++ b/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 18:16:38 2013 -0700 @@ -26,7 +26,7 @@ /* * @test - * @bug 6911258 6962571 6963622 6991528 7005628 + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 * @summary Basic tests of suppressed exceptions * @author Joseph D. Darcy */ @@ -48,7 +48,9 @@ throwable.addSuppressed(throwable); throw new RuntimeException("IllegalArgumentException for self-suppresion not thrown."); } catch (IllegalArgumentException iae) { - ; // Expected + // Expected to be here + if (iae.getCause() != throwable) + throw new RuntimeException("Bad cause after self-suppresion."); } } -Joe From lana.steuck at oracle.com Fri Apr 12 03:10:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:36 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130412031044.31B7948238@hg.openjdk.java.net> Changeset: 2c9acb17f41a Author: katleman Date: 2013-04-11 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2c9acb17f41a Added tag jdk8-b85 for changeset 4a48f3173534 ! .hgtags Changeset: d13af7751456 Author: lana Date: 2013-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d13af7751456 Merge From lana.steuck at oracle.com Fri Apr 12 03:10:34 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:34 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b85 for changeset 41b50e2c5ea3 Message-ID: <20130412031039.5D19248236@hg.openjdk.java.net> Changeset: ca71ec37b2ef Author: katleman Date: 2013-04-11 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ca71ec37b2ef Added tag jdk8-b85 for changeset 41b50e2c5ea3 ! .hgtags From lana.steuck at oracle.com Fri Apr 12 03:10:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:44 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130412031146.140B748239@hg.openjdk.java.net> Changeset: e22961ea91bd Author: erikj Date: 2013-04-05 09:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e22961ea91bd 8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar' Reviewed-by: tbell ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcSwing.gmk ! makefiles/SignJars.gmk ! makefiles/Tools.gmk Changeset: fddd158b872a Author: omajid Date: 2013-04-08 14:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fddd158b872a 8011388: Support building zero and zeroshark with the new build Reviewed-by: andrew, dholmes, erikj Contributed-by: Omair Majid , Roman Kennke ! makefiles/Profiles.gmk Changeset: 296676d534c5 Author: katleman Date: 2013-04-09 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/296676d534c5 Merge Changeset: 081327aac5be Author: katleman Date: 2013-04-11 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/081327aac5be Added tag jdk8-b85 for changeset 296676d534c5 ! .hgtags Changeset: e62a707a77d8 Author: lana Date: 2013-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e62a707a77d8 Merge From lana.steuck at oracle.com Fri Apr 12 03:10:34 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:34 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130412031042.A4EC648237@hg.openjdk.java.net> Changeset: 26c840af7720 Author: katleman Date: 2013-04-11 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/26c840af7720 Added tag jdk8-b85 for changeset 8c0b6bccfe47 ! .hgtags Changeset: 28886cb008bb Author: lana Date: 2013-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/28886cb008bb Merge From lana.steuck at oracle.com Fri Apr 12 03:10:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:33 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b85 for changeset 9583a6431596 Message-ID: <20130412031034.DA89D48234@hg.openjdk.java.net> Changeset: 44a8ce4a759f Author: katleman Date: 2013-04-11 09:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/44a8ce4a759f Added tag jdk8-b85 for changeset 9583a6431596 ! .hgtags From lana.steuck at oracle.com Fri Apr 12 03:10:34 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:34 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130412031036.EDC2B48235@hg.openjdk.java.net> Changeset: aed0529f5f5d Author: katleman Date: 2013-04-11 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aed0529f5f5d Added tag jdk8-b85 for changeset e0378f0a50da ! .hgtags Changeset: 480b90430d29 Author: lana Date: 2013-04-11 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/480b90430d29 Merge From lana.steuck at oracle.com Fri Apr 12 03:10:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:33 +0000 Subject: hg: jdk8/tl: 10 new changesets Message-ID: <20130412031034.98C9748233@hg.openjdk.java.net> Changeset: 52d1b385a4ed Author: erikj Date: 2013-04-04 09:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52d1b385a4ed 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure Reviewed-by: tbell, alanb ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 2d4156e077fa Author: erikj Date: 2013-04-04 09:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2d4156e077fa 8011372: Remove -p from cp in IdleCompilation.gmk Reviewed-by: pliden, tbell ! common/makefiles/IdlCompilation.gmk Changeset: 3b8ffb80db0f Author: erikj Date: 2013-04-05 09:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3b8ffb80db0f 8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar' Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk Changeset: 653ff6bcf0b1 Author: omajid Date: 2013-04-08 14:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/653ff6bcf0b1 8011388: Support building zero and zeroshark with the new build Reviewed-by: andrew, dholmes, erikj Contributed-by: Omair Majid , Roman Kennke ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: 2f43964043c2 Author: erikj Date: 2013-04-09 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f43964043c2 8006288: build-infra: Use solaris nm and not gnm on solaris Reviewed-by: tbell ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 2ef28c12d649 Author: erikj Date: 2013-04-09 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2ef28c12d649 8010465: Can't enable sjavac when building in jprt. Reviewed-by: ohair, tbell ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Jprt.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk Changeset: a09e9c9ca963 Author: tbell Date: 2013-04-09 13:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a09e9c9ca963 8011348: use of which in common/autoconf/autogen.sh is not portable Reviewed-by: erikj, katleman, mduigou ! common/autoconf/autogen.sh Changeset: 7fc358f59436 Author: katleman Date: 2013-04-09 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7fc358f59436 Merge Changeset: 44bc9bc4da4d Author: katleman Date: 2013-04-11 09:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/44bc9bc4da4d Added tag jdk8-b85 for changeset 7fc358f59436 ! .hgtags Changeset: 7da551071fe8 Author: lana Date: 2013-04-11 19:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7da551071fe8 Merge ! common/makefiles/Main.gmk From lana.steuck at oracle.com Fri Apr 12 03:10:59 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 12 Apr 2013 03:10:59 +0000 Subject: hg: jdk8/tl/hotspot: 62 new changesets Message-ID: <20130412031259.0F58A4823A@hg.openjdk.java.net> Changeset: d26674db4d91 Author: amurillo Date: 2013-03-28 19:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d26674db4d91 8011022: new hotspot build - hs25-b26 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0c3ee6f1fa23 Author: coleenp Date: 2013-03-27 08:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c3ee6f1fa23 8009531: Crash when redefining class with annotated method Summary: Neglected to copy the annotations in clone_with_new_data when they were moved to ConstMethod. Reviewed-by: acorn, sspitsyn, dcubed ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp Changeset: aa758f0c5b1c Author: hseigel Date: 2013-03-27 11:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa758f0c5b1c 8010833: Test7116786.java is failing on most configs after fix for 8010667 Summary: Update test to recognize that non-zero pad bytes for lookupswitch/tablewsitch opcodes are now valid. Reviewed-by: dcubed, twisti, kvn, coleenp, dholmes ! test/runtime/7116786/Test7116786.java Changeset: b601102d00c8 Author: hseigel Date: 2013-03-27 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b601102d00c8 Merge Changeset: cd3089a56438 Author: acorn Date: 2013-03-27 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd3089a56438 8009731: Confusing error message for loader constraint violation Summary: Fix text, overwritten type and holder for resolved method Reviewed-by: coleenp, dcubed, minqi, dholmes ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: 53f4040e809c Author: acorn Date: 2013-03-27 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53f4040e809c Merge Changeset: b5bae74160b7 Author: zgu Date: 2013-03-27 15:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5bae74160b7 8010474: [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp Summary: Fixed functions that miss return values Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memTracker.hpp Changeset: 26e0c03da92c Author: zgu Date: 2013-03-27 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26e0c03da92c Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw Changeset: f044c45bee68 Author: zgu Date: 2013-03-27 22:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f044c45bee68 Merge Changeset: 1b90c7607451 Author: minqi Date: 2013-03-27 17:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b90c7607451 2178143: JVM crashes if the number of bound CPUs changed during runtime Summary: Supply a new flag -XX:+AssumeMP to workaround the problem. With the flag is turned on, assume VM run on MP platform so is_MP() will return true that sync calls will not skip away. Reviewed-by: dholmes, acorn, dcubed, jmasa Contributed-by: yumin.qi at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: d7adf726b18a Author: minqi Date: 2013-03-28 00:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d7adf726b18a Merge Changeset: c0f9217203b2 Author: dcubed Date: 2013-03-29 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0f9217203b2 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d886ac1dfd36 Author: coleenp Date: 2013-03-31 21:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d886ac1dfd36 8010723: fatal error: acquiring lock Metaspace allocation lock/5 out of order Summary: Avoid holding SystemDictionary_lock while calling Klass::remove_unshareable_info Reviewed-by: coleenp, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/systemDictionary.cpp Changeset: e458120c6e1a Author: sla Date: 2013-03-28 15:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e458120c6e1a 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM Reviewed-by: sspitsyn, zgu Contributed-by: peter.allwin at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java Changeset: ede380e13960 Author: mgerdin Date: 2013-04-02 11:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ede380e13960 8009763: Add WB test for String.intern() Summary: Add convenience method in StringTable, add WhiteBox method and simple sanity test Reviewed-by: mgerdin, zgu Contributed-by: leonid.mesnik at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/prims/whitebox.cpp + test/runtime/interned/SanityTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 8c03fc47511d Author: iklam Date: 2013-04-01 14:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c03fc47511d 8011048: Possible reading from unmapped memory in UTF8::as_quoted_ascii() Summary: Pass utf_length parameter to UTF8::as_quoted_ascii() Reviewed-by: dcubed, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp Changeset: a4e8dac9db8c Author: zgu Date: 2013-04-02 07:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4e8dac9db8c Merge Changeset: 2e093b564241 Author: mgerdin Date: 2013-03-28 10:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e093b564241 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine Summary: Keep a counter of how many times we were stalled by the GC locker, add a diagnostic flag which sets the limit. Reviewed-by: brutisso, ehelin, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754c24457b20 Author: tschatzl Date: 2013-03-27 19:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/754c24457b20 7112912: Message "Error occurred during initialization of VM" on boxes with lots of RAM Summary: Ergonomics now also takes available virtual memory into account when deciding for a heap size. The helper method to determine the maximum allocatable memory block now uses the appropriate OS specific calls to retrieve available virtual memory for the java process. In 32 bit environments this method now also searches for the maximum actually reservable amount of memory. Merge previously separate implementations for Linux/BSD/Solaris into a single method. Reviewed-by: jmasa, tamao ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: 24ef5fb05e0f Author: johnc Date: 2013-03-29 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24ef5fb05e0f 8010463: G1: Crashes with -UseTLAB and heap verification Summary: Some parts of the G1 heap can only be walked during a safepoint. Skip verifying these parts of the heap when verifying during JVM startup. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/thread.cpp + test/gc/TestVerifyBeforeGCDuringStartup.java Changeset: 8bf6338972ce Author: ehelin Date: 2013-03-23 09:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bf6338972ce 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" Reviewed-by: brutisso, sla, ctornqvi ! test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: cc5b5976d72c Author: tschatzl Date: 2013-04-02 10:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc5b5976d72c 8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose Summary: Use GC_locker::is_active_and_needs_gc() instead of GC_locker::is_active() for providing information about the reason of heap expansion. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp Changeset: 15c04fe93c18 Author: mgerdin Date: 2013-04-03 09:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15c04fe93c18 Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/8007736/TestStaticIF.java Changeset: 0c039865ef2b Author: mgerdin Date: 2013-04-04 19:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c039865ef2b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: 46f6f063b272 Author: roland Date: 2013-03-21 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46f6f063b272 7153771: array bound check elimination for c1 Summary: when possible optimize out array bound checks, inserting predicates when needed. Reviewed-by: never, kvn, twisti Contributed-by: thomaswue ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Optimizer.cpp + src/share/vm/c1/c1_RangeCheckElimination.cpp + src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/runtime/globals.hpp Changeset: a57fc14f798a Author: roland Date: 2013-03-21 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a57fc14f798a Merge Changeset: e370f63dc5b1 Author: bharadwaj Date: 2013-03-22 07:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e370f63dc5b1 8009539: JVM crash when run lambda testng tests Summary: Ensure class pointer is non-null before dereferencing it to check if it is loaded. Reviewed-by: kvn ! src/share/vm/opto/parse2.cpp Changeset: 360ce06580b8 Author: bharadwaj Date: 2013-03-22 13:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/360ce06580b8 Merge Changeset: 3c786355ffb4 Author: morris Date: 2013-03-23 06:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c786355ffb4 8009026: [parfait] Null pointer deference in hotspot/src/share/vm/code/nmethod.cpp Summary: add guarantee() to nmethod constructor and checks to ensure CodeCache has space before allocation Reviewed-by: kvn ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp Changeset: 818a1ac7da7a Author: morris Date: 2013-03-24 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/818a1ac7da7a Merge Changeset: 16885e702c88 Author: twisti Date: 2013-03-25 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16885e702c88 7198429: need checked categorization of caller-sensitive methods in the JDK Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp Changeset: b808febcad9a Author: neliasso Date: 2013-03-26 10:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b808febcad9a 8010281: Remove code that is never executed Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/ifg.cpp Changeset: 30f42e691e70 Author: kvn Date: 2013-03-26 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30f42e691e70 8004640: C2 assert failure in memnode.cpp: NULL+offs not RAW address Summary: always transform AddP nodes in IdealKit by calling _gvn.transform(). Reviewed-by: roland, twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: d595e8ddadd9 Author: roland Date: 2013-03-29 17:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d595e8ddadd9 8010934: assert failure in c1_LinearScan.cpp: "asumption: non-Constant instructions have only virtual operands" Summary: incorrect code to skip some ArrayLength instructions in LIRGenerator Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_RangeCheckElimination.cpp Changeset: cd9ad42dfde0 Author: bharadwaj Date: 2013-03-29 20:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd9ad42dfde0 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp Changeset: 6b19fe41b577 Author: kmo Date: 2013-03-30 08:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b19fe41b577 8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros Summary: Improve EC_TRACE and RC_TRACE* to use the do-while(0) trick for statement-like macro Reviewed-by: sspitsyn, dcubed ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp Changeset: 53028d751155 Author: neliasso Date: 2013-04-02 09:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53028d751155 7034299: Faulty winsock initialization code Reviewed-by: dholmes, sla, ctornqvi ! src/os/windows/vm/os_windows.cpp Changeset: e961c11b85fe Author: kvn Date: 2013-04-03 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e961c11b85fe 8011102: Clear AVX registers after return from JNI call Summary: Execute vzeroupper instruction after JNI call and on exits in jit compiled code which use 256bit vectors. Reviewed-by: roland ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 0a8c2ea3902d Author: rasbold Date: 2013-04-03 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a8c2ea3902d 8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Summary: Fix shorten_branches() to accurately count an initial nop that may be inserted in a block that starts with a safepoint. Reviewed-by: kvn ! src/share/vm/opto/output.cpp Changeset: 70c52efb2cbd Author: neliasso Date: 2013-04-04 09:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70c52efb2cbd 8006008: Memory leak in hotspot/src/share/vm/adlc/archDesc.cpp Reviewed-by: roland, kvn Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/adlc/archDesc.cpp Changeset: 6c4abd4a9595 Author: roland Date: 2013-04-04 09:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c4abd4a9595 8010399: Test8009761.java "Failed: init recursive calls: 5498. After deopt 5494". Summary: test from 8009761 shouldn't be run with -Xcomp Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: 9125a548c1eb Author: roland Date: 2013-04-04 02:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9125a548c1eb Merge Changeset: 573cf206e381 Author: neliasso Date: 2013-04-04 09:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/573cf206e381 8006014: Memory leak in hotspot/src/share/vm/adlc/dfa.cpp Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/adlc/dfa.cpp Changeset: bab5cbf74b5f Author: kvn Date: 2013-04-04 12:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bab5cbf74b5f 8011198: LP64 setting is not preserved on Solaris after 8006965 Summary: Fixed incremental build makefiles generated by buildtree.make. Consolidated unix build.sh. Reviewed-by: twisti - make/bsd/build.sh ! make/bsd/makefiles/buildtree.make + make/build.sh - make/linux/build.sh ! make/linux/makefiles/buildtree.make - make/solaris/build.sh ! make/solaris/makefiles/buildtree.make ! src/os/posix/launcher/launcher.script Changeset: 0ca3dd0ffaba Author: bharadwaj Date: 2013-04-04 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ca3dd0ffaba Merge - make/bsd/build.sh - make/linux/build.sh - make/solaris/build.sh ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp Changeset: a947f40fb536 Author: amurillo Date: 2013-04-04 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a947f40fb536 Merge - make/bsd/build.sh - make/linux/build.sh - make/solaris/build.sh Changeset: 42fe530cd478 Author: amurillo Date: 2013-04-04 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42fe530cd478 Added tag hs25-b26 for changeset a947f40fb536 ! .hgtags Changeset: 5dcfeb396fed Author: katleman Date: 2013-04-11 09:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5dcfeb396fed Added tag jdk8-b85 for changeset 42fe530cd478 ! .hgtags Changeset: dcdeb150988c Author: amurillo Date: 2013-04-04 21:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcdeb150988c 8011584: new hotspot build - hs25-b27 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b890cd4da64 Author: ctornqvi Date: 2013-04-03 21:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b890cd4da64 8009125: Add NMT tests for Virtual Memory operations Summary: Tests added for Reserve/Commit/Uncommit/Unreserve operations Reviewed-by: zgu, mgerdin ! src/share/vm/prims/whitebox.cpp - test/runtime/NMT/AllocTestType.java + test/runtime/NMT/MallocTestType.java + test/runtime/NMT/ThreadedMallocTestType.java + test/runtime/NMT/ThreadedVirtualAllocTestType.java + test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/OutputAnalyzerTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 8554c55669b0 Author: hseigel Date: 2013-04-04 08:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8554c55669b0 8010943: guarantee(length == 0) failed: invalid method ordering length Summary: Add DumpSharedSpaces to IF condition to handle verify during -Xshare:dump. Reviewed-by: coleenp, zgu ! src/share/vm/oops/instanceKlass.cpp Changeset: bad3bed4b323 Author: ccheung Date: 2013-03-29 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bad3bed4b323 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c Summary: a simple fix to add FileList_free(fl) before returning NULL. Reviewed-by: zgu, coleenp, minqi ! src/share/tools/launcher/wildcard.c Changeset: 17bf4d428955 Author: ccheung Date: 2013-04-03 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17bf4d428955 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp Reviewed-by: zgu, iklam ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: cc32ccaaf47f Author: mikael Date: 2013-04-04 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc32ccaaf47f 8003310: Enable -Wunused-function when compiling with gcc Summary: Add the -Wunused-function flag and remove a number of unused functions. Reviewed-by: dholmes, coleenp, kvn ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4c8bb5e4f68f Author: zgu Date: 2013-04-05 12:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8bb5e4f68f 8011161: NMT: Memory leak when encountering out of memory error while initializing memory snapshot Summary: Fix memory leaks when NMT fails to initialize snapshot and worker thread Reviewed-by: dcubed, ccheung, rdurbin ! src/share/vm/services/memTracker.cpp Changeset: 8be1318fbe77 Author: dcubed Date: 2013-04-05 10:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8be1318fbe77 Merge ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp - test/runtime/NMT/AllocTestType.java Changeset: 46d24f112c27 Author: dcubed Date: 2013-04-05 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46d24f112c27 Merge - make/bsd/build.sh - make/linux/build.sh - make/solaris/build.sh Changeset: 4b7cf00ccb08 Author: ccheung Date: 2013-04-05 11:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b7cf00ccb08 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp Reviewed-by: zgu, coleenp, hseigel, dholmes ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp Changeset: b933e75e7cbe Author: zgu Date: 2013-04-05 23:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b933e75e7cbe Merge Changeset: 09b0d3e9ba6c Author: bharadwaj Date: 2013-04-09 08:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09b0d3e9ba6c 8011671: JCK tests on static interface methods fail under b84: Illegal type at constant pool entry 5 Summary: Restore incorrect removal of support for static interface method verification in Java 8 Reviewed-by: kvn, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: 9b4a6a172a8a Author: amurillo Date: 2013-04-11 01:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b4a6a172a8a Added tag hs25-b27 for changeset 09b0d3e9ba6c ! .hgtags Changeset: 511e334ee345 Author: amurillo Date: 2013-04-11 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/511e334ee345 Merge ! .hgtags - test/runtime/NMT/AllocTestType.java From zhong.j.yu at gmail.com Fri Apr 12 03:58:12 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 11 Apr 2013 22:58:12 -0500 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <51676122.4020802@oracle.com> References: <51676122.4020802@oracle.com> Message-ID: It doesn't feel very right to say the exception is the "cause" of the IAE. If the user code reuses an exception instance "x", as reported by OP, there is a possibility that the IAE is later added as a suppressed exception to "x", forming a loop x->IAE->x. Zhong Yu On Thu, Apr 11, 2013 at 8:19 PM, Joe Darcy wrote: > Hello, > > Please review the patch below to address > > 8012044: Give more information about self-suppression from > Throwable.addSuppressed > http://cr.openjdk.java.net/~darcy/8012044.0/ > > Thanks, > > -Joe > > diff -r 006a7a576fe9 src/share/classes/java/lang/Throwable.java > --- a/src/share/classes/java/lang/Throwable.java Thu Apr 11 12:22:23 2013 > +0900 > +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 11 18:16:38 2013 > -0700 > @@ -1039,7 +1039,7 @@ > */ > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, > exception); > > if (exception == null) > throw new NullPointerException(NULL_CAUSE_MESSAGE); > diff -r 006a7a576fe9 test/java/lang/Throwable/SuppressedExceptions.java > --- a/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 12:22:23 2013 +0900 > +++ b/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 18:16:38 2013 -0700 > @@ -26,7 +26,7 @@ > > /* > * @test > - * @bug 6911258 6962571 6963622 6991528 7005628 > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > * @summary Basic tests of suppressed exceptions > * @author Joseph D. Darcy > */ > @@ -48,7 +48,9 @@ > throwable.addSuppressed(throwable); > throw new RuntimeException("IllegalArgumentException for > self-suppresion not thrown."); > } catch (IllegalArgumentException iae) { > - ; // Expected > + // Expected to be here > + if (iae.getCause() != throwable) > + throw new RuntimeException("Bad cause after > self-suppresion."); > } > } > > > -Joe From zhong.j.yu at gmail.com Fri Apr 12 04:04:03 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 11 Apr 2013 23:04:03 -0500 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? In-Reply-To: <54AC68B4-C1A6-4F6B-84A2-C5C9B6F6F3B1@gmail.com> References: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> <54AC68B4-C1A6-4F6B-84A2-C5C9B6F6F3B1@gmail.com> Message-ID: On Tue, Apr 9, 2013 at 11:54 AM, Steven Schlansker wrote: > > On Apr 9, 2013, at 9:30 AM, Zhong Yu wrote: > >> >> >> >> On Mon, Apr 8, 2013 at 6:54 PM, Steven Schlansker wrote: >> Today I encountered "java.lang.IllegalArgumentException: Self-suppression not permitted" from Throwable.addSuppressed. >> >> My first surprise is that the try-with-resources block can throw this exception; it is very confusing to have auto-generated code throw exceptions. But beyond that, it is impossible to figure out *which* exception caused the problem. If you have multiple resources acquired in the try-with-resources, it could be any of them. >> >> Would it be reasonable to change >> >> public final synchronized void addSuppressed(Throwable exception) { >> if (exception == this) >> throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); >> >> to >> >> public final synchronized void addSuppressed(Throwable exception) { >> if (exception == this) >> throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, this); >> >> so that when you get this exception it at least points to one of the throw sites that actually caused the problem? Otherwise the only stack trace you have is in auto-generated code and you are left scratching your head, wondering where it came from. I believe this would increase the debuggability of the try-with-resources construct and there's no immediately obvious downside. >> >> I'm not the only one who was confused by this behavior: >> http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co >> >> >> Reusing exception is probably not a good idea - unless the exception is immutable, i.e. enableSuppression=writableStackTrace=true. >> > > I agree, but there is (library) code out there that does this -- the code that caused the problem wasn't even mine. The library should be told to fix the bug. It is really serious, for example, more and more suppressed exceptions can be added to this reused/shared/cached exception, causing memory leak. A mutable exception simply cannot be shared, otherwise there will be multiple exception handler trying to mutate it. Zhong Yu > My suggestion has no cost unless you happen to trigger it, and then it helps you find who is causing trouble. > >> Interestingly, even for an immutable exception, `e.addSuppressed(e)` isn't allowed. I think that it should be allowed. >> >> Zhong Yu > From xueming.shen at oracle.com Fri Apr 12 05:46:31 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 22:46:31 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51642EF3.1040701@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> Message-ID: <51679FB7.6050904@oracle.com> David, webrev has been updated to removed the tzdb.dat from the CreateJars.gmk as suggested. http://cr.openjdk.java.net/~sherman/8011172/webrev/ Thanks! -Sherman On 04/09/2013 08:08 AM, Xueming Shen wrote: > On 4/9/13 5:00 AM, David Holmes wrote: >> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar file or not; if not then it should not be built using CreateJars.gmk and shouldn't listed on the JAR variables in profile-includes.txt > > tzdb.dat now is NOT a jar file for performance (decompression slows down startup). > So which gmk file is the best fit for this kind of "file building"? We may be able to > update it to the appropriate place with a follow up push. > > -Sherman > >> >> David >> >> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>> Hi, >>> >>> JSR 310 has continued to refine and update the java.time API. >>> Please help review the proposed changeset as showed in webrev: >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>> >>> In addition to general javadoc improvements, the changes include: >>> >>> java.time >>> >>> * Duration - added a static from(temporalAmount) method to simplify >>> conversions from other amounts >>> * Renamed the toString(Formatter) method to format(Formatter) in all >>> classes >>> * Period - added a static from(temporalAmount) method to simplify >>> conversions >>> * ZoneId - >>> - Added getAvailableZoneIds method, a simpler mechanism than going >>> to the provider >>> - Added normalized() method to ease conversion to a fixed offset >>> - renamed predefined static fields of timezone names >>> >>> java.time.chrono >>> >>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>> - changed xxx_COMPARATORs to static methods returning the Time Line >>> Order comparators >>> - Added a from(TemporalAcessor) method to ease conversions >>> * Chronology >>> - Added method to create a Date from EpochDay (And in each >>> calendar subclass) >>> - Added resolveDate to allow resolving date components by the >>> Chronology >>> - Serialization fixes >>> - Replaced raw return types with wildcard type >>> * Era >>> - Removed factory methods and getChronology - they did not work >>> correctly in all cases >>> - Declared Era as a functional interface >>> * Hijrah calendar variations - >>> - Supporting the Umm alQura calendar >>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>> making the enums public >>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>> to return the concrete Era type. >>> >>> java.time.format >>> >>> * DateTimeFormatter - >>> - Added fields for the predefined formatters >>> (moved from DateTimeFormatters class) >>> - Updated patterns to be CLDR compatible >>> - Moved documentation for the pattern letters to the class javadoc >>> - Added support for Zone default and conversion >>> * DateTimeFormatterBuilder >>> - Updated documentation of patterns and corresponding equivalents >>> to builder methods. >>> - Added a method to append the localized offset. >>> >>> java.time.temporal >>> >>> * Adjusters - class removed; all static adjusters moved to static methods >>> in TemporalAdjuster >>> * ChronoField - >>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>> - Added getDisplayName - for locale specific field name >>> * Queries - class removed; all static query method moved to static methods >>> in TemporalQuery >>> * TemporalField - added getDisplayName method >>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>> to reflect no support for a unit or field >>> * WeekFields - Added fields for week and year of week-Based-Years to match >>> CLDR fields "Y", "W" > From david.holmes at oracle.com Fri Apr 12 05:57:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2013 15:57:15 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51679FB7.6050904@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> Message-ID: <5167A23B.3080607@oracle.com> Hi Sherman, On 12/04/2013 3:46 PM, Xueming Shen wrote: > David, > > webrev has been updated to removed the tzdb.dat from the CreateJars.gmk > as suggested. > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ In profile-includes.txt this change is wrong: ** 77,88 **** security/blacklist \ security/cacerts \ security/java.policy \ security/java.security \ security/local_policy.jar \ ! security/trusted.libraries \ ! tzdb.jar PROFILE_1_JRE_OTHER_FILES := \ COPYRIGHT \ LICENSE \ README \ --- 77,87 ---- security/blacklist \ security/cacerts \ security/java.policy \ security/java.security \ security/local_policy.jar \ ! security/trusted.libraries we need tzdb.dat listed here. Thanks, David > Thanks! > -Sherman > > On 04/09/2013 08:08 AM, Xueming Shen wrote: >> On 4/9/13 5:00 AM, David Holmes wrote: >>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>> file or not; if not then it should not be built using CreateJars.gmk >>> and shouldn't listed on the JAR variables in profile-includes.txt >> >> tzdb.dat now is NOT a jar file for performance (decompression slows >> down startup). >> So which gmk file is the best fit for this kind of "file building"? We >> may be able to >> update it to the appropriate place with a follow up push. >> >> -Sherman >> >>> >>> David >>> >>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>> Hi, >>>> >>>> JSR 310 has continued to refine and update the java.time API. >>>> Please help review the proposed changeset as showed in webrev: >>>> >>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>> >>>> In addition to general javadoc improvements, the changes include: >>>> >>>> java.time >>>> >>>> * Duration - added a static from(temporalAmount) method to simplify >>>> conversions from other amounts >>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>> classes >>>> * Period - added a static from(temporalAmount) method to simplify >>>> conversions >>>> * ZoneId - >>>> - Added getAvailableZoneIds method, a simpler mechanism than going >>>> to the provider >>>> - Added normalized() method to ease conversion to a fixed offset >>>> - renamed predefined static fields of timezone names >>>> >>>> java.time.chrono >>>> >>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>> - changed xxx_COMPARATORs to static methods returning the Time Line >>>> Order comparators >>>> - Added a from(TemporalAcessor) method to ease conversions >>>> * Chronology >>>> - Added method to create a Date from EpochDay (And in each >>>> calendar subclass) >>>> - Added resolveDate to allow resolving date components by the >>>> Chronology >>>> - Serialization fixes >>>> - Replaced raw return types with wildcard type >>>> * Era >>>> - Removed factory methods and getChronology - they did not work >>>> correctly in all cases >>>> - Declared Era as a functional interface >>>> * Hijrah calendar variations - >>>> - Supporting the Umm alQura calendar >>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>> making the enums public >>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>> to return the concrete Era type. >>>> >>>> java.time.format >>>> >>>> * DateTimeFormatter - >>>> - Added fields for the predefined formatters >>>> (moved from DateTimeFormatters class) >>>> - Updated patterns to be CLDR compatible >>>> - Moved documentation for the pattern letters to the class javadoc >>>> - Added support for Zone default and conversion >>>> * DateTimeFormatterBuilder >>>> - Updated documentation of patterns and corresponding equivalents >>>> to builder methods. >>>> - Added a method to append the localized offset. >>>> >>>> java.time.temporal >>>> >>>> * Adjusters - class removed; all static adjusters moved to static >>>> methods >>>> in TemporalAdjuster >>>> * ChronoField - >>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>> - Added getDisplayName - for locale specific field name >>>> * Queries - class removed; all static query method moved to static >>>> methods >>>> in TemporalQuery >>>> * TemporalField - added getDisplayName method >>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>> to reflect no support for a unit or field >>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>> match >>>> CLDR fields "Y", "W" >> > From xueming.shen at oracle.com Fri Apr 12 06:27:51 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Apr 2013 23:27:51 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167A23B.3080607@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> Message-ID: <5167A967.9000704@oracle.com> Good catch. webrev updated. It appears none of the tests catched this error, if I just build the jdk normally (?), either local fresh new build and jprt job. http://cr.openjdk.java.net/~sherman/8011172/webrev/ -Sherman. On 4/11/13 10:57 PM, David Holmes wrote: > Hi Sherman, > > On 12/04/2013 3:46 PM, Xueming Shen wrote: >> David, >> >> webrev has been updated to removed the tzdb.dat from the CreateJars.gmk >> as suggested. >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > In profile-includes.txt this change is wrong: > > ** 77,88 **** > security/blacklist \ > security/cacerts \ > security/java.policy \ > security/java.security \ > security/local_policy.jar \ > ! security/trusted.libraries \ > ! tzdb.jar > > PROFILE_1_JRE_OTHER_FILES := \ > COPYRIGHT \ > LICENSE \ > README \ > --- 77,87 ---- > security/blacklist \ > security/cacerts \ > security/java.policy \ > security/java.security \ > security/local_policy.jar \ > ! security/trusted.libraries > > we need tzdb.dat listed here. > > Thanks, > David > >> Thanks! >> -Sherman >> >> On 04/09/2013 08:08 AM, Xueming Shen wrote: >>> On 4/9/13 5:00 AM, David Holmes wrote: >>>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>>> file or not; if not then it should not be built using CreateJars.gmk >>>> and shouldn't listed on the JAR variables in profile-includes.txt >>> >>> tzdb.dat now is NOT a jar file for performance (decompression slows >>> down startup). >>> So which gmk file is the best fit for this kind of "file building"? We >>> may be able to >>> update it to the appropriate place with a follow up push. >>> >>> -Sherman >>> >>>> >>>> David >>>> >>>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> JSR 310 has continued to refine and update the java.time API. >>>>> Please help review the proposed changeset as showed in webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>>> >>>>> In addition to general javadoc improvements, the changes include: >>>>> >>>>> java.time >>>>> >>>>> * Duration - added a static from(temporalAmount) method to simplify >>>>> conversions from other amounts >>>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>>> classes >>>>> * Period - added a static from(temporalAmount) method to simplify >>>>> conversions >>>>> * ZoneId - >>>>> - Added getAvailableZoneIds method, a simpler mechanism than >>>>> going >>>>> to the provider >>>>> - Added normalized() method to ease conversion to a fixed offset >>>>> - renamed predefined static fields of timezone names >>>>> >>>>> java.time.chrono >>>>> >>>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>>> - changed xxx_COMPARATORs to static methods returning the Time >>>>> Line >>>>> Order comparators >>>>> - Added a from(TemporalAcessor) method to ease conversions >>>>> * Chronology >>>>> - Added method to create a Date from EpochDay (And in each >>>>> calendar subclass) >>>>> - Added resolveDate to allow resolving date components by the >>>>> Chronology >>>>> - Serialization fixes >>>>> - Replaced raw return types with wildcard type >>>>> * Era >>>>> - Removed factory methods and getChronology - they did not work >>>>> correctly in all cases >>>>> - Declared Era as a functional interface >>>>> * Hijrah calendar variations - >>>>> - Supporting the Umm alQura calendar >>>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>>> making the enums public >>>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>>> to return the concrete Era type. >>>>> >>>>> java.time.format >>>>> >>>>> * DateTimeFormatter - >>>>> - Added fields for the predefined formatters >>>>> (moved from DateTimeFormatters class) >>>>> - Updated patterns to be CLDR compatible >>>>> - Moved documentation for the pattern letters to the class >>>>> javadoc >>>>> - Added support for Zone default and conversion >>>>> * DateTimeFormatterBuilder >>>>> - Updated documentation of patterns and corresponding >>>>> equivalents >>>>> to builder methods. >>>>> - Added a method to append the localized offset. >>>>> >>>>> java.time.temporal >>>>> >>>>> * Adjusters - class removed; all static adjusters moved to static >>>>> methods >>>>> in TemporalAdjuster >>>>> * ChronoField - >>>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>>> - Added getDisplayName - for locale specific field name >>>>> * Queries - class removed; all static query method moved to static >>>>> methods >>>>> in TemporalQuery >>>>> * TemporalField - added getDisplayName method >>>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>>> to reflect no support for a unit or field >>>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>>> match >>>>> CLDR fields "Y", "W" >>> >> From peter.levart at gmail.com Fri Apr 12 07:01:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 12 Apr 2013 09:01:34 +0200 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <51676122.4020802@oracle.com> References: <51676122.4020802@oracle.com> Message-ID: <5167B14E.1000405@gmail.com> Hi Joe, There were certainly debates about why self-suppression is not a good thing when project Coin's try-with-resources has been developed, but I don't quite remember the reason why it was designed this way. Couldn't the logic just make the self-suppression a no-op? The addSuppressed was designed for (quoting from javadoc): "...there are situations where two independent exceptions can be thrown in sibling code blocks, in particular in the try block of a try-with-resources statement and the compiler-generated finally block which closes the resource. In these situations, only one of the thrown exceptions can be propagated..." Now if those "two independent exceptions" are actually the same exception, there's no "dilemma"... Regards, Peter On 04/12/2013 03:19 AM, Joe Darcy wrote: > Hello, > > Please review the patch below to address > > 8012044: Give more information about self-suppression from > Throwable.addSuppressed > http://cr.openjdk.java.net/~darcy/8012044.0/ > > Thanks, > > -Joe > > diff -r 006a7a576fe9 src/share/classes/java/lang/Throwable.java > --- a/src/share/classes/java/lang/Throwable.java Thu Apr 11 > 12:22:23 2013 +0900 > +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 11 > 18:16:38 2013 -0700 > @@ -1039,7 +1039,7 @@ > */ > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > - throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > + throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > if (exception == null) > throw new NullPointerException(NULL_CAUSE_MESSAGE); > diff -r 006a7a576fe9 test/java/lang/Throwable/SuppressedExceptions.java > --- a/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 12:22:23 2013 +0900 > +++ b/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 18:16:38 2013 -0700 > @@ -26,7 +26,7 @@ > > /* > * @test > - * @bug 6911258 6962571 6963622 6991528 7005628 > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > * @summary Basic tests of suppressed exceptions > * @author Joseph D. Darcy > */ > @@ -48,7 +48,9 @@ > throwable.addSuppressed(throwable); > throw new RuntimeException("IllegalArgumentException for > self-suppresion not thrown."); > } catch (IllegalArgumentException iae) { > - ; // Expected > + // Expected to be here > + if (iae.getCause() != throwable) > + throw new RuntimeException("Bad cause after > self-suppresion."); > } > } > > > -Joe From david.holmes at oracle.com Fri Apr 12 07:09:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2013 17:09:54 +1000 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167A967.9000704@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> Message-ID: <5167B342.3050305@oracle.com> On 12/04/2013 4:27 PM, Xueming Shen wrote: > Good catch. webrev updated. It appears none of the tests catched this > error, if I just build the > jdk normally (?), either local fresh new build and jprt job. > > http://cr.openjdk.java.net/~sherman/8011172/webrev/ A "profiles" build would have been affected by it. David > -Sherman. > > On 4/11/13 10:57 PM, David Holmes wrote: >> Hi Sherman, >> >> On 12/04/2013 3:46 PM, Xueming Shen wrote: >>> David, >>> >>> webrev has been updated to removed the tzdb.dat from the CreateJars.gmk >>> as suggested. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> In profile-includes.txt this change is wrong: >> >> ** 77,88 **** >> security/blacklist \ >> security/cacerts \ >> security/java.policy \ >> security/java.security \ >> security/local_policy.jar \ >> ! security/trusted.libraries \ >> ! tzdb.jar >> >> PROFILE_1_JRE_OTHER_FILES := \ >> COPYRIGHT \ >> LICENSE \ >> README \ >> --- 77,87 ---- >> security/blacklist \ >> security/cacerts \ >> security/java.policy \ >> security/java.security \ >> security/local_policy.jar \ >> ! security/trusted.libraries >> >> we need tzdb.dat listed here. >> >> Thanks, >> David >> >>> Thanks! >>> -Sherman >>> >>> On 04/09/2013 08:08 AM, Xueming Shen wrote: >>>> On 4/9/13 5:00 AM, David Holmes wrote: >>>>> I find it troubling the tzdb.jar is now tzdb.dat - either it is a jar >>>>> file or not; if not then it should not be built using CreateJars.gmk >>>>> and shouldn't listed on the JAR variables in profile-includes.txt >>>> >>>> tzdb.dat now is NOT a jar file for performance (decompression slows >>>> down startup). >>>> So which gmk file is the best fit for this kind of "file building"? We >>>> may be able to >>>> update it to the appropriate place with a follow up push. >>>> >>>> -Sherman >>>> >>>>> >>>>> David >>>>> >>>>> On 9/04/2013 5:51 AM, Xueming Shen wrote: >>>>>> Hi, >>>>>> >>>>>> JSR 310 has continued to refine and update the java.time API. >>>>>> Please help review the proposed changeset as showed in webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >>>>>> >>>>>> In addition to general javadoc improvements, the changes include: >>>>>> >>>>>> java.time >>>>>> >>>>>> * Duration - added a static from(temporalAmount) method to simplify >>>>>> conversions from other amounts >>>>>> * Renamed the toString(Formatter) method to format(Formatter) in all >>>>>> classes >>>>>> * Period - added a static from(temporalAmount) method to simplify >>>>>> conversions >>>>>> * ZoneId - >>>>>> - Added getAvailableZoneIds method, a simpler mechanism than >>>>>> going >>>>>> to the provider >>>>>> - Added normalized() method to ease conversion to a fixed offset >>>>>> - renamed predefined static fields of timezone names >>>>>> >>>>>> java.time.chrono >>>>>> >>>>>> * ChronoLocalDate, ChronoLocalDateTime, ChonoZonedDateTime >>>>>> - changed xxx_COMPARATORs to static methods returning the Time >>>>>> Line >>>>>> Order comparators >>>>>> - Added a from(TemporalAcessor) method to ease conversions >>>>>> * Chronology >>>>>> - Added method to create a Date from EpochDay (And in each >>>>>> calendar subclass) >>>>>> - Added resolveDate to allow resolving date components by the >>>>>> Chronology >>>>>> - Serialization fixes >>>>>> - Replaced raw return types with wildcard type >>>>>> * Era >>>>>> - Removed factory methods and getChronology - they did not work >>>>>> correctly in all cases >>>>>> - Declared Era as a functional interface >>>>>> * Hijrah calendar variations - >>>>>> - Supporting the Umm alQura calendar >>>>>> * Added HijrahEra, IsoEra, JapaneseEra, MinguEra, ThaiBuddhistEra >>>>>> making the enums public >>>>>> * MinguoDate, ThaiBuddhistDate, HijrahDate - Added getEra method >>>>>> to return the concrete Era type. >>>>>> >>>>>> java.time.format >>>>>> >>>>>> * DateTimeFormatter - >>>>>> - Added fields for the predefined formatters >>>>>> (moved from DateTimeFormatters class) >>>>>> - Updated patterns to be CLDR compatible >>>>>> - Moved documentation for the pattern letters to the class >>>>>> javadoc >>>>>> - Added support for Zone default and conversion >>>>>> * DateTimeFormatterBuilder >>>>>> - Updated documentation of patterns and corresponding >>>>>> equivalents >>>>>> to builder methods. >>>>>> - Added a method to append the localized offset. >>>>>> >>>>>> java.time.temporal >>>>>> >>>>>> * Adjusters - class removed; all static adjusters moved to static >>>>>> methods >>>>>> in TemporalAdjuster >>>>>> * ChronoField - >>>>>> - Renamed EPOCH_MONTH to PROLEPTIC_MONTH >>>>>> - Added getDisplayName - for locale specific field name >>>>>> * Queries - class removed; all static query method moved to static >>>>>> methods >>>>>> in TemporalQuery >>>>>> * TemporalField - added getDisplayName method >>>>>> * UnsupportedTemporalTypeException - new subtype of DateTimeException >>>>>> to reflect no support for a unit or field >>>>>> * WeekFields - Added fields for week and year of week-Based-Years to >>>>>> match >>>>>> CLDR fields "Y", "W" >>>> >>> > From joel.franck at oracle.com Fri Apr 12 10:07:52 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Fri, 12 Apr 2013 10:07:52 +0000 Subject: hg: jdk8/tl/langtools: 7015104: use new subtype of TypeSymbol for type parameters Message-ID: <20130412100758.E71FE48270@hg.openjdk.java.net> Changeset: 137994c189e5 Author: jfranck Date: 2013-04-12 12:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/137994c189e5 7015104: use new subtype of TypeSymbol for type parameters Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java ! test/tools/javac/types/TypeHarness.java From paul.sandoz at oracle.com Fri Apr 12 10:31:51 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 12 Apr 2013 12:31:51 +0200 Subject: RFR JDK-8011427: java.util.concurrent collection Spliterator implementations In-Reply-To: <51657F29.6040702@gmail.com> References: <5E609919-54FE-4949-A65A-C51DBB7E4409@oracle.com> <51657F29.6040702@gmail.com> Message-ID: On Apr 10, 2013, at 5:03 PM, Peter Levart wrote: > On 04/10/2013 03:56 PM, Paul Sandoz wrote: >> Hi, >> >> Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util.concurrent. More precisely it represents updates from JSR 166 for collection classes that implement spliterators: >> >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011427/webrev/ >> >> This is dependent on [1]. >> >> -- >> >> Like the previous webrev for collections in java.util this webrev contains the jdk changset file for my complete hg patch queue and not from the revision i specify. >> >> Also, i am getting errors such as: >> >> /usr/bin/awk: limited to 50 pat,pat statements at source line 89 source file /tmp/87498.file1 >> >> when generating HTML diff files for ConcurrentHashMap.java and ConcurrentSkipListMap.java. >> >> Anyone know how to resolve that? > > Hi Paul, > > Use Linux. I mean "gawk" has no such limitation. ;-) > Thanks, i installed gawk via mac port, which fixed the errors. I updated the webrev, which now includes the previously omitted ConcurrentSkipListSet and some recent updates from 166 to CopyOnWriteArraySet, CopyOnWriteArrayList, and ConcurrentHashMap. Paul. From anthony.petrov at oracle.com Fri Apr 12 10:38:27 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 12 Apr 2013 14:38:27 +0400 Subject: sun.awt.X11 logs still using String + (waste) In-Reply-To: References: <5162872D.8060004@gmail.com> <51631FE2.6090200@oracle.com> <516483D0.2080404@oracle.com> <516527B3.6050702@oracle.com> <5165840C.7010705@oracle.com> <5165BAB2.6030208@oracle.com> <5165C470.7040606@oracle.com> <5166D5E4.3040305@oracle.com> <5166DC4F.8090206@oracle.com> Message-ID: <5167E423.90209@oracle.com> Thanks Laurent. The fix looks fine to me, too. I've just pushed it to the repository: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4490ef60ecd3 Currently it's in the AWT forest. I expect it to be integrated to the Master JDK8 repository in a week or two. -- best regards, Anthony On 4/11/2013 20:08, Laurent Bourg?s wrote: > Anthony, > > Here is the updated webrev: > http://jmmc.fr/~bourgesl/share/webrev-8010297.5/ > > > Laurent > > 2013/4/11 Mandy Chung > >> On 4/11/13 8:43 AM, Laurent Bourg?s wrote: >> >> >> I don't understand if I should fix it or not ? >> >> src/solaris/classes/sun/awt/X11/XListPeer.java >>> Nit: line 1906 you remove isLoggable call here. Was it intentional (as >>> it doesn't call concatenate any string?)? I think it's better to use the >>> pattern consistently. >>> >> it's a mistake (cookie). >> >> >> Please fix it. >> >> >> >> >>> Approved and no need to regenerate a new webrev if you fix the above nit. >>> >> To fix it, I need to send you files as a new webrev ? >> >> >> Anthony is going to sponsor for you and I think he asks for a webrev. So >> please send the latest webrev with this fix then. >> >> Mandy >> >> >> Laurent >> >> >> From Dmitry.Degrave at oracle.com Fri Apr 12 10:48:09 2013 From: Dmitry.Degrave at oracle.com (Dmeetry Degrave) Date: Fri, 12 Apr 2013 14:48:09 +0400 Subject: RFR: [corba] 4504275, 8011986 - two issues with generated code Message-ID: <5167E669.2090505@oracle.com> Hi all, I'm looking for a review for two ancient issues in idlj. First is an issue with uncompilable java code generated for unions with boolean discriminator. 4504275: CORBA boolean type unions do not generate compilable code from idlj bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504275 fix: http://cr.openjdk.java.net/~dmeetry/4504275/webrev.0/ Second (is not available on bugs.sun.com atm) is an issue with generated read/write union helper methods that throw org.omg.CORBA.BAD_OPERATION in cases when boolean discriminator's value isn't matched, which is wrong. 8011986: [corba] idlj generates read/write union helper methods that throw wrong exception in some cases bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011986 fix: http://cr.openjdk.java.net/~dmeetry/8011986/webrev.0/ Both fixes are intended for jdk7 and 8. thanks, dmeetry From jason_mehrens at hotmail.com Fri Apr 12 12:45:52 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 12 Apr 2013 07:45:52 -0500 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <51676122.4020802@oracle.com> References: <51676122.4020802@oracle.com> Message-ID: Joe, Should this same logic be applied to the exceptions thrown from initCause? Seems like that would be consistent with this change. Jason > Date: Thu, 11 Apr 2013 18:19:30 -0700 > From: joe.darcy at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed > > Hello, > > Please review the patch below to address > > 8012044: Give more information about self-suppression from > Throwable.addSuppressed > http://cr.openjdk.java.net/~darcy/8012044.0/ > > Thanks, > > -Joe > > diff -r 006a7a576fe9 src/share/classes/java/lang/Throwable.java > --- a/src/share/classes/java/lang/Throwable.java Thu Apr 11 12:22:23 > 2013 +0900 > +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 11 18:16:38 > 2013 -0700 > @@ -1039,7 +1039,7 @@ > */ > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > + throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > if (exception == null) > throw new NullPointerException(NULL_CAUSE_MESSAGE); > diff -r 006a7a576fe9 test/java/lang/Throwable/SuppressedExceptions.java > --- a/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 12:22:23 2013 +0900 > +++ b/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > 18:16:38 2013 -0700 > @@ -26,7 +26,7 @@ > > /* > * @test > - * @bug 6911258 6962571 6963622 6991528 7005628 > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > * @summary Basic tests of suppressed exceptions > * @author Joseph D. Darcy > */ > @@ -48,7 +48,9 @@ > throwable.addSuppressed(throwable); > throw new RuntimeException("IllegalArgumentException for > self-suppresion not thrown."); > } catch (IllegalArgumentException iae) { > - ; // Expected > + // Expected to be here > + if (iae.getCause() != throwable) > + throw new RuntimeException("Bad cause after > self-suppresion."); > } > } > > > -Joe From Alan.Bateman at oracle.com Fri Apr 12 12:55:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 13:55:36 +0100 Subject: Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51672145.3080504@oracle.com> References: <51672145.3080504@oracle.com> Message-ID: <51680448.6020303@oracle.com> On 11/04/2013 21:47, Xueming Shen wrote: > Hi > > As part of the JSR310 Date/Time project, following methods are proposed > to be added into java.nio.file.attribute.FileTime to interoperate with > the > new JSR310 time class Instant. > > public static FileTime from(Instant instant); > public Instant toInstant(); > > http://cr.openjdk.java.net/~sherman/8011647/webrev Sherman and I chatted about adding from(Instant)/toInstant() a few times over the last week so most of my comments are already included. Overall I think it has worked out well, just unfortunate that there is a bit of extra complexity because FileTime supports a wider time-line and we also went with the XML schema deviation from (older?) ISO 8601 for year 0000. In practical terms these aren't of course interesting for file times. In terms of API then from(Instant)/toInstant() are simple and I don't think we have an urgent need for FileTimes to be directly formatted. On toString then FileTime doesn't require that trailing zeros be stripped from the fraction of a second. If it is better to use 3-digit units that it is okay. Also if this is something that we got wrong in FileTime then we could change the spec without any compatibility impact. Values outside of MIN/MAX aren't too interesting so hashCode using Instant hashCode should be fine. I had to read compareTo a few times to convince myself that it correctly orders FileTimes where one is created from an Instant and the other from a value outside of MIN/MAX. It might be useful to expand the comment to explain this further. Thanks for expanding the existing test. A minor point at line 117 is that you don't need "Random r" as there is rand already. The pre-existing tests loop over TimeUnit.values() rather than EnumSet.allOf(TimeUnit.class). In eqTime then it prints to System.out where the rest of the test prints to System.err before throwing the exception. That's all I have. -Alan From Alan.Bateman at oracle.com Fri Apr 12 13:30:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 14:30:48 +0100 Subject: RFR 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries (including invokedynamic) In-Reply-To: <516729CE.9050806@oracle.com> References: <51663AF5.5000807@oracle.com> <516729CE.9050806@oracle.com> Message-ID: <51680C88.1060509@oracle.com> On 11/04/2013 22:23, Robert Field wrote: > Thank you Mike, Alan, and Brian for your reviews, and others for your > assistance. > > Updated webrev: > > http://cr.openjdk.java.net/~rfield/8011805_2 > > Changes are all in the test: > > * Removed unused testWrite and related code. > * Used correct copyright. > * Added finally clauses which close file and clean-up. > * Simplified code, removing rmic copied code. > * Fixed @test comment format. > > -Robert Thanks for sorting out these issues, looks okay to me now. -Alan From Alan.Bateman at oracle.com Fri Apr 12 15:02:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 16:02:56 +0100 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51673A45.8060908@oracle.com> References: <51673A45.8060908@oracle.com> Message-ID: <51682220.6010009@oracle.com> On 11/04/2013 23:33, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ > > > These are changes that we made in lambda that we're now bringing into > JDK8. > > I've made a couple of additions - making StringJoiner final and adding > a couple of constructors to set the emptyOutput chars. > > Thanks, > Jim > One question on the bug numbers. Are you proposing to use all three? I assume that at least 7175206 is not needed for the push to jdk8. Just a few comments on String.join (which overall, it nice and simple). The javadoc doesn't make it obvious that the elements can include null, are you planning to make that clear? A minor nit in the first example there is there is a space before the closing parentheses. It looks to be a bit odd to have one of the @see tags before the @throws and the other after it. In one method the @return wraps around without indenting, in the other method the first @param is nicely indented but the second one is pushed in by extra space. The examples in the second String.join can probably use diamond. I don't know how this looks in the generated javadoc but might be clearer to put each of the strings.add on their own lines. There is also inconsistencies with spaces and parentheses in these examples. I see you proposing to put the test for String.join in test/java/lang/StringTest.java but that is inconsistent with the current organization. I realize this is TestNG test that is not in the unnamed package but test/java/lang is just too high up in the tree for a specific test. Also "StringTest" is a bit general a name given that it is specific to String.join. The usual copyright header for tests is the pure GPL header. I plan to look at StringJoiner in more detail later. -Alan From xueming.shen at oracle.com Fri Apr 12 15:01:08 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 12 Apr 2013 15:01:08 +0000 Subject: hg: jdk8/tl/jdk: 8011172: JSR 310 DateTime API Updates II Message-ID: <20130412150133.0EC5C48280@hg.openjdk.java.net> Changeset: f4d50e8cc9e2 Author: sherman Date: 2013-04-12 07:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4d50e8cc9e2 8011172: JSR 310 DateTime API Updates II Summary: Integration of JSR310 Date/Time API update Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com ! make/java/java/Makefile ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/sun/text/FILES_java.gmk ! make/sun/tzdb/Makefile ! make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataTZDB.gmk ! makefiles/profile-includes.txt ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java - src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/time/chrono/HijrahEra.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/Parsed.java + src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/format/TextStyle.java - src/share/classes/java/time/temporal/Adjusters.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java - src/share/classes/java/time/temporal/Queries.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalAdjusters.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java + src/share/classes/java/time/temporal/TemporalQueries.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/TemporalUnit.java + src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/FormatData.java + src/share/classes/sun/text/resources/JavaTimeSupplementary.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java ! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/de/FormatData_de_AT.java ! src/share/classes/sun/text/resources/de/FormatData_de_CH.java ! src/share/classes/sun/text/resources/de/FormatData_de_DE.java ! src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/el/FormatData_el_CY.java ! src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java ! src/share/classes/sun/text/resources/en/FormatData_en.java ! src/share/classes/sun/text/resources/en/FormatData_en_AU.java ! src/share/classes/sun/text/resources/en/FormatData_en_CA.java ! src/share/classes/sun/text/resources/en/FormatData_en_GB.java ! src/share/classes/sun/text/resources/en/FormatData_en_IE.java ! src/share/classes/sun/text/resources/en/FormatData_en_IN.java ! src/share/classes/sun/text/resources/en/FormatData_en_MT.java ! src/share/classes/sun/text/resources/en/FormatData_en_NZ.java ! src/share/classes/sun/text/resources/en/FormatData_en_PH.java ! src/share/classes/sun/text/resources/en/FormatData_en_SG.java ! src/share/classes/sun/text/resources/en/FormatData_en_US.java ! src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java + src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/es/FormatData_es_AR.java ! src/share/classes/sun/text/resources/es/FormatData_es_BO.java ! src/share/classes/sun/text/resources/es/FormatData_es_CL.java ! src/share/classes/sun/text/resources/es/FormatData_es_CO.java ! src/share/classes/sun/text/resources/es/FormatData_es_CR.java ! src/share/classes/sun/text/resources/es/FormatData_es_DO.java ! src/share/classes/sun/text/resources/es/FormatData_es_EC.java ! src/share/classes/sun/text/resources/es/FormatData_es_ES.java ! src/share/classes/sun/text/resources/es/FormatData_es_GT.java ! src/share/classes/sun/text/resources/es/FormatData_es_HN.java ! src/share/classes/sun/text/resources/es/FormatData_es_MX.java ! src/share/classes/sun/text/resources/es/FormatData_es_NI.java ! src/share/classes/sun/text/resources/es/FormatData_es_PA.java ! src/share/classes/sun/text/resources/es/FormatData_es_PE.java ! src/share/classes/sun/text/resources/es/FormatData_es_PR.java ! src/share/classes/sun/text/resources/es/FormatData_es_PY.java ! src/share/classes/sun/text/resources/es/FormatData_es_SV.java ! src/share/classes/sun/text/resources/es/FormatData_es_US.java ! src/share/classes/sun/text/resources/es/FormatData_es_UY.java ! src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java ! src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java ! src/share/classes/sun/text/resources/ga/FormatData_ga.java ! src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java ! src/share/classes/sun/text/resources/in/FormatData_in.java ! src/share/classes/sun/text/resources/in/FormatData_in_ID.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/it/FormatData_it_CH.java ! src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java + src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java ! src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java ! src/share/classes/sun/text/resources/no/FormatData_no.java ! src/share/classes/sun/text/resources/no/FormatData_no_NO.java ! src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java ! src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java + src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java ! src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java + src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java + src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java + src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java + src/share/classes/sun/util/resources/ParallelListResourceBundle.java ! src/share/lib/calendars.properties + src/share/lib/hijrah-config-umalqura.properties ! test/java/time/tck/java/time/AbstractDateTimeTest.java ! test/java/time/tck/java/time/TCKClock.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java - test/java/time/tck/java/time/TestChronology.java ! test/java/time/tck/java/time/TestIsoChronology.java ! test/java/time/tck/java/time/chrono/CopticChronology.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/CopticEra.java + test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java + test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/TCKHijrahChronology.java + test/java/time/tck/java/time/chrono/TCKHijrahEra.java + test/java/time/tck/java/time/chrono/TCKIsoChronology.java + test/java/time/tck/java/time/chrono/TCKIsoEra.java + test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java + test/java/time/tck/java/time/chrono/TCKJapaneseEra.java + test/java/time/tck/java/time/chrono/TCKMinguoChronology.java + test/java/time/tck/java/time/chrono/TCKMinguoEra.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java + test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java + test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java ! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java + test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java ! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java + test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/TestClock_System.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/TestLocalDate.java ! test/java/time/test/java/time/TestLocalDateTime.java ! test/java/time/test/java/time/TestLocalTime.java ! test/java/time/test/java/time/TestMonthDay.java ! test/java/time/test/java/time/TestOffsetDateTime.java ! test/java/time/test/java/time/TestOffsetDateTime_instants.java ! test/java/time/test/java/time/TestPeriod.java ! test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/chrono/TestChronoLocalDate.java + test/java/time/test/java/time/chrono/TestChronologyPerf.java ! test/java/time/test/java/time/chrono/TestExampleCode.java ! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java + test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java ! test/java/time/test/java/time/chrono/TestServiceLoader.java + test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java + test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/AbstractTestPrinterParser.java ! test/java/time/test/java/time/format/MockIOExceptionAppendable.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestCharLiteralPrinter.java ! test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestPadPrinterDecorator.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestSettingsParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestStringLiteralPrinter.java ! test/java/time/test/java/time/format/TestTextParser.java ! test/java/time/test/java/time/format/TestTextPrinter.java ! test/java/time/test/java/time/format/TestZoneOffsetParser.java ! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/time/format/ZoneName.java ! test/java/time/test/java/time/temporal/MockFieldValue.java + test/java/time/test/java/time/temporal/TestChronoField.java ! test/java/time/test/java/time/temporal/TestChronoUnit.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java ! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java ! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java ! test/java/time/test/java/time/zone/TestFixedZoneRules.java ! test/java/time/test/java/util/TestFormatter.java ! test/java/util/Calendar/Bug8007038.java ! test/java/util/Calendar/CldrFormatNamesTest.java ! test/java/util/Calendar/JavatimeTest.java ! test/sun/text/resources/LocaleData ! test/sun/util/calendar/zi/TestZoneInfo310.java From Alan.Bateman at oracle.com Fri Apr 12 15:46:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 16:46:44 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <5167B342.3050305@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> Message-ID: <51682C64.7080600@oracle.com> On 12/04/2013 08:09, David Holmes wrote: > On 12/04/2013 4:27 PM, Xueming Shen wrote: >> Good catch. webrev updated. It appears none of the tests catched this >> error, if I just build the >> jdk normally (?), either local fresh new build and jprt job. >> >> http://cr.openjdk.java.net/~sherman/8011172/webrev/ > > A "profiles" build would have been affected by it. > > David Speaking of, hijrah-config-umalqura.properties will need to be added to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it gets copied into the profile images. Sorry I didn't spot thing until now. -Alan From xueming.shen at oracle.com Fri Apr 12 16:04:04 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 09:04:04 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51682C64.7080600@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> Message-ID: <51683074.5020502@oracle.com> Will add in a separate push/update. On 4/12/13 8:46 AM, Alan Bateman wrote: > On 12/04/2013 08:09, David Holmes wrote: >> On 12/04/2013 4:27 PM, Xueming Shen wrote: >>> Good catch. webrev updated. It appears none of the tests catched this >>> error, if I just build the >>> jdk normally (?), either local fresh new build and jprt job. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> A "profiles" build would have been affected by it. >> >> David > Speaking of, hijrah-config-umalqura.properties will need to be added > to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it > gets copied into the profile images. Sorry I didn't spot thing until now. > > -Alan From Alan.Bateman at oracle.com Fri Apr 12 16:17:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 17:17:47 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51683074.5020502@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> <51683074.5020502@oracle.com> Message-ID: <516833AB.1090506@oracle.com> On 12/04/2013 17:04, Xueming Shen wrote: > Will add in a separate push/update. I just checked it and the HijrahChronology fails to initialized as expected on profile builds. The attached sorts it out. -Alan. diff -r f4d50e8cc9e2 makefiles/profile-includes.txt --- a/makefiles/profile-includes.txt Fri Apr 12 07:57:35 2013 -0700 +++ b/makefiles/profile-includes.txt Fri Apr 12 17:04:10 2013 +0100 @@ -66,6 +66,7 @@ ext/sunec.jar \ ext/sunjce_provider.jar \ ext/sunpkcs11.jar \ + hijrah-config-umalqura.properties \ jce.jar \ jsse.jar \ logging.properties \ From xueming.shen at oracle.com Fri Apr 12 16:17:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 09:17:08 -0700 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51682C64.7080600@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> Message-ID: <51683384.5050401@oracle.com> Alan, please help review. http://cr.openjdk.java.net/~sherman/8012123/webrev/ -Sherman On 4/12/13 8:46 AM, Alan Bateman wrote: > On 12/04/2013 08:09, David Holmes wrote: >> On 12/04/2013 4:27 PM, Xueming Shen wrote: >>> Good catch. webrev updated. It appears none of the tests catched this >>> error, if I just build the >>> jdk normally (?), either local fresh new build and jprt job. >>> >>> http://cr.openjdk.java.net/~sherman/8011172/webrev/ >> >> A "profiles" build would have been affected by it. >> >> David > Speaking of, hijrah-config-umalqura.properties will need to be added > to PROFILE_1_JRE_LIB_FILES in profiles-includes.txt to ensure that it > gets copied into the profile images. Sorry I didn't spot thing until now. > > -Alan From Alan.Bateman at oracle.com Fri Apr 12 16:19:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 17:19:34 +0100 Subject: [threeten-dev] ReviewRequest 8011172: JSR 310: DateTime API Updates II, In-Reply-To: <51683384.5050401@oracle.com> References: <51631FD6.6090800@oracle.com> <516402F8.5020302@oracle.com> <51642EF3.1040701@oracle.com> <51679FB7.6050904@oracle.com> <5167A23B.3080607@oracle.com> <5167A967.9000704@oracle.com> <5167B342.3050305@oracle.com> <51682C64.7080600@oracle.com> <51683384.5050401@oracle.com> Message-ID: <51683416.9090503@oracle.com> On 12/04/2013 17:17, Xueming Shen wrote: > Alan, please help review. > > http://cr.openjdk.java.net/~sherman/8012123/webrev/ > > -Sherman Looks good. -Alan From xueming.shen at oracle.com Fri Apr 12 16:56:43 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 12 Apr 2013 16:56:43 +0000 Subject: hg: jdk8/tl/jdk: 8012123: hijrah-config-umalqura.properties is missing from makefiles/profile-includes.txt Message-ID: <20130412165714.4DFDD48288@hg.openjdk.java.net> Changeset: 035a61c9f981 Author: sherman Date: 2013-04-12 09:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/035a61c9f981 8012123: hijrah-config-umalqura.properties is missing from makefiles/profile-includes.txt Summary: added the hijrah-config-umalqura.properties into the list Reviewed-by: alanb ! makefiles/profile-includes.txt From robert.field at oracle.com Fri Apr 12 17:03:55 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 12 Apr 2013 17:03:55 +0000 Subject: hg: jdk8/tl/jdk: 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries Message-ID: <20130412170424.79E5E4828A@hg.openjdk.java.net> Changeset: e2cd40d7567c Author: rfield Date: 2013-04-12 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2cd40d7567c 8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries Reviewed-by: mduigou, alanb ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/sun/tools/java/BinaryConstantPool.java ! src/share/classes/sun/tools/java/RuntimeConstants.java + test/sun/tools/java/CFCTest.java From xueming.shen at oracle.com Fri Apr 12 17:28:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 10:28:45 -0700 Subject: Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51680448.6020303@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> Message-ID: <5168444D.10003@oracle.com> On 04/12/2013 05:55 AM, Alan Bateman wrote: > Sherman and I chatted about adding from(Instant)/toInstant() a few times over the last week so most of my comments are already included. > > Overall I think it has worked out well, just unfortunate that there is a bit of extra complexity because FileTime supports a wider time-line and we also went with the XML schema deviation from (older?) ISO 8601 for year 0000. In practical terms these aren't of course interesting for file times. > > In terms of API then from(Instant)/toInstant() are simple and I don't think we have an urgent need for FileTimes to be directly formatted. > > On toString then FileTime doesn't require that trailing zeros be stripped from the fraction of a second. If it is better to use 3-digit units that it is okay. Also if this is something that we got wrong in FileTime then we could change the spec without any compatibility impact. I'm not sure if the 3-digit unit fitting is "better" or not. But xml spec cited in the toString() API specifies that the "trailing zeros are optional" in its 3.2.3.1 "lexical representatin" section and "trailing zeros are prohibited..." in 3.2.3.2 "canonical representation" section. So I think trimming trailing zeros in FileTime.toString() is just fine. http://www.w3.org/TR/xmlschema-2/#deviantformats > > Values outside of MIN/MAX aren't too interesting so hashCode using Instant hashCode should be fine. I had to read compareTo a few times to convince myself that it correctly orders FileTimes where one is created from an Instant and the other from a value outside of MIN/MAX. It might be useful to expand the comment to explain this further. Added some wording. > > Thanks for expanding the existing test. A minor point at line 117 is that you don't need "Random r" as there is rand already. The pre-existing tests loop over TimeUnit.values() rather than EnumSet.allOf(TimeUnit.class). In eqTime then it prints to System.out where the rest of the test prints to System.err before throwing the exception. > Updated. http://cr.openjdk.java.net/~sherman/8011647/webrev/ Thanks! -Sherman From joe.darcy at oracle.com Fri Apr 12 17:35:40 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Apr 2013 10:35:40 -0700 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: References: <51676122.4020802@oracle.com> Message-ID: <516845EC.8090105@oracle.com> Hi Jason, Hmm. This is the current initCause implementation from JDK 8: public synchronized Throwable initCause(Throwable cause) { if (this.cause != this) throw new IllegalStateException("Can't overwrite cause"); if (cause == this) throw new IllegalArgumentException("Self-causation not permitted"); this.cause = cause; return this; } It wouldn't be unreasonable to change the second throw to if (cause == this) throw new IllegalArgumentException("Self-causation not permitted", cause); but I think there is less motivation to do so than in the addSuppressed case since addSuppressed gets called in compiler-generated code that isn't visible in the original sources. -Joe On 04/12/2013 05:45 AM, Jason Mehrens wrote: > Joe, > > Should this same logic be applied to the exceptions thrown from > initCause? Seems like that would be consistent with this change. > > Jason > > > Date: Thu, 11 Apr 2013 18:19:30 -0700 > > From: joe.darcy at oracle.com > > To: core-libs-dev at openjdk.java.net > > Subject: Code review request for 8012044: Give more information > about self-suppression from Throwable.addSuppressed > > > > Hello, > > > > Please review the patch below to address > > > > 8012044: Give more information about self-suppression from > > Throwable.addSuppressed > > http://cr.openjdk.java.net/~darcy/8012044.0/ > > > > Thanks, > > > > -Joe > > > > diff -r 006a7a576fe9 src/share/classes/java/lang/Throwable.java > > --- a/src/share/classes/java/lang/Throwable.java Thu Apr 11 12:22:23 > > 2013 +0900 > > +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 11 18:16:38 > > 2013 -0700 > > @@ -1039,7 +1039,7 @@ > > */ > > public final synchronized void addSuppressed(Throwable exception) { > > if (exception == this) > > - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > > + throw new > > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > > > if (exception == null) > > throw new NullPointerException(NULL_CAUSE_MESSAGE); > > diff -r 006a7a576fe9 test/java/lang/Throwable/SuppressedExceptions.java > > --- a/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > > 12:22:23 2013 +0900 > > +++ b/test/java/lang/Throwable/SuppressedExceptions.java Thu Apr 11 > > 18:16:38 2013 -0700 > > @@ -26,7 +26,7 @@ > > > > /* > > * @test > > - * @bug 6911258 6962571 6963622 6991528 7005628 > > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > > * @summary Basic tests of suppressed exceptions > > * @author Joseph D. Darcy > > */ > > @@ -48,7 +48,9 @@ > > throwable.addSuppressed(throwable); > > throw new RuntimeException("IllegalArgumentException for > > self-suppresion not thrown."); > > } catch (IllegalArgumentException iae) { > > - ; // Expected > > + // Expected to be here > > + if (iae.getCause() != throwable) > > + throw new RuntimeException("Bad cause after > > self-suppresion."); > > } > > } > > > > > > -Joe From coleen.phillimore at oracle.com Fri Apr 12 17:45:30 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 12 Apr 2013 13:45:30 -0400 Subject: RFR (S) 8009531: Crash when redefining class with annotated method Message-ID: <5168483A.9020304@oracle.com> Summary: Add annotations to the tests to verify bug above open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk The Hotspot change is in tl repository now. Also, this has been reviewed by the hotspot group. Thanks, Coleen From coleen.phillimore at oracle.com Fri Apr 12 18:01:48 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 12 Apr 2013 14:01:48 -0400 Subject: RFR (S) 8009531: Crash when redefining class with annotated method In-Reply-To: <5168483A.9020304@oracle.com> References: <5168483A.9020304@oracle.com> Message-ID: <51684C0C.30206@oracle.com> Can you reply to me as well as the mailing list since I'm not on this mailing list? thanks, Coleen -------- Original Message -------- Subject: RFR (S) 8009531: Crash when redefining class with annotated method Date: Fri, 12 Apr 2013 13:45:30 -0400 From: Coleen Phillimore Reply-To: coleen.phillimore at oracle.com Organization: Oracle Corporation To: core-libs-dev at openjdk.java.net Summary: Add annotations to the tests to verify bug above open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531 The Hotspot change is in tl repository now. Also, this has been reviewed by the hotspot group. Thanks, Coleen From Alan.Bateman at oracle.com Fri Apr 12 18:10:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 19:10:44 +0100 Subject: Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <5168444D.10003@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> <5168444D.10003@oracle.com> Message-ID: <51684E24.2090405@oracle.com> On 12/04/2013 18:28, Xueming Shen wrote: > > I'm not sure if the 3-digit unit fitting is "better" or not. But xml > spec cited in the > toString() API specifies that the "trailing zeros are optional" in its > 3.2.3.1 "lexical > representatin" section and "trailing zeros are prohibited..." in > 3.2.3.2 "canonical > representation" section. So I think trimming trailing zeros in > FileTime.toString() > is just fine. The deviation and reference to the XML scheme spec was intended to be deal with the issues of year 0000 and > 9999. I'm happy with dropping the trailing zeros, I just wasn't sure if you suggesting that it would have been better to use 3-digit unit that allow trailing zeros. > : > Updated. > > http://cr.openjdk.java.net/~sherman/8011647/webrev/ > Looks fine. The eqTime method is still printing to System.out in the test but it's not a big deal. -Alan From xueming.shen at oracle.com Fri Apr 12 18:16:27 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 12 Apr 2013 11:16:27 -0700 Subject: Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime In-Reply-To: <51684E24.2090405@oracle.com> References: <51672145.3080504@oracle.com> <51680448.6020303@oracle.com> <5168444D.10003@oracle.com> <51684E24.2090405@oracle.com> Message-ID: <51684F7B.7000308@oracle.com> On 04/12/2013 11:10 AM, Alan Bateman wrote: > On 12/04/2013 18:28, Xueming Shen wrote: >> >> I'm not sure if the 3-digit unit fitting is "better" or not. But xml spec cited in the >> toString() API specifies that the "trailing zeros are optional" in its 3.2.3.1 "lexical >> representatin" section and "trailing zeros are prohibited..." in 3.2.3.2 "canonical >> representation" section. So I think trimming trailing zeros in FileTime.toString() >> is just fine. > The deviation and reference to the XML scheme spec was intended to be deal with the issues of year 0000 and > 9999. I'm happy with dropping the trailing zeros, I just wasn't sure if you suggesting that it would have been better to use 3-digit unit that allow trailing zeros. > > >> : >> Updated. >> >> http://cr.openjdk.java.net/~sherman/8011647/webrev/ >> > Looks fine. The eqTime method is still printing to System.out in the test but it's not a big deal. > http://cr.openjdk.java.net/~sherman/8011647/webrev/ Missed this one. Updated. I think we are good to go. Thanks! -Sherman From jason_mehrens at hotmail.com Fri Apr 12 18:22:19 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 12 Apr 2013 13:22:19 -0500 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <516845EC.8090105@oracle.com> References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> Message-ID: The landmines are the retrofitted exception classes as shown here https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE is thrown it is going to suppress 'this' and 'cause'. It would be nice to see the given 'cause' show up in a log file when tracking down this type of bug. Date: Fri, 12 Apr 2013 10:35:40 -0700 From: joe.darcy at oracle.com To: jason_mehrens at hotmail.com CC: core-libs-dev at openjdk.java.net Subject: Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed Hi Jason, Hmm. This is the current initCause implementation from JDK 8: public synchronized Throwable initCause(Throwable cause) { if (this.cause != this) throw new IllegalStateException("Can't overwrite cause"); if (cause == this) throw new IllegalArgumentException("Self-causation not permitted"); this.cause = cause; return this; } It wouldn't be unreasonable to change the second throw to if (cause == this) throw new IllegalArgumentException("Self-causation not permitted", cause); but I think there is less motivation to do so than in the addSuppressed case since addSuppressed gets called in compiler-generated code that isn't visible in the original sources. -Joe From wangsheng.0376 at 163.com Fri Apr 12 13:50:21 2013 From: wangsheng.0376 at 163.com (wangsheng.0376) Date: Fri, 12 Apr 2013 21:50:21 +0800 (CST) Subject: Request for Review : CR#6924259: Remove String.count/String.offset Message-ID: <789455e.30104.13dfe82dcf4.Coremail.wangsheng.0376@163.com> hi, all, I agree with you to remove offset, today when I run following code in jdk7(sorry I forget the detail version), my code is like this: Pattern pattern = Pattern.compile(regex); Matcher matcher = pattern.match(content); while (matcher.find()) { String link = matcher.group(1); set.add(link);// set is a HashSet type } after I running for some time, I found that the 'set' object has memory leak, I found though 'link' is a part of 'content', but the value field in link variable is same as 'content' value field, difference is that the link offset field is not zero. So that mean the set(HashSet) is not store the 'link', it store the 'content' value field, it will cause the memory leak problem, So I am very happy to reomve the offset field. Best Regards =nazario.wang= From mandy.chung at oracle.com Fri Apr 12 18:36:50 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Apr 2013 11:36:50 -0700 Subject: Review request: 8004260: dynamic proxy class should have same class access as proxy interfaces Message-ID: <51685442.9090404@oracle.com> Dynamic proxy class is specified to be public, final, and not abstract. For a proxy class that implements a non-public interface, it will be in the same package as the non-public interface but the proxy class is accessible outside of the non-public interface's runtime package. This change will make dynamic proxy class to have the same Java language access as the proxy interfaces so that creating a proxy instance to implement a non-public interface will be guarded by the Java language access check. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8004260/webrev.00/ Specdiff at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8004260/specdiff/overview-summary.html This change also updates the spec to specify the permission checks by Proxy.getProxyClass and Proxy.newProxyInstance methods and removes the system properties which provide a workaround for 7u releases and not needed in jdk8. Thanks Mandy From mike.duigou at oracle.com Fri Apr 12 18:53:24 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 12 Apr 2013 18:53:24 +0000 Subject: hg: jdk8/tl/jdk: 8011200: (coll) Optimize empty HashMap and ArrayList Message-ID: <20130412185341.62A8D4828E@hg.openjdk.java.net> Changeset: 2e3cc7f599ca Author: mduigou Date: 2013-04-10 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e3cc7f599ca 8011200: (coll) Optimize empty HashMap and ArrayList Reviewed-by: mduigou, alanb, bchristi, martin Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/HashMap.java + test/java/util/Map/BasicSerialization.java From henry.jen at oracle.com Fri Apr 12 18:56:48 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 12 Apr 2013 11:56:48 -0700 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: <5165AAF1.3000800@oracle.com> References: <5165A8A1.7090407@oracle.com> <5165AAF1.3000800@oracle.com> Message-ID: <516858F0.7010607@oracle.com> On 04/10/2013 11:09 AM, Alan Bateman wrote: > On 10/04/2013 19:00, Henry Jen wrote: >> Hi, >> >> The bug is reported on lambda repo, part of the fix involved code >> already integrated into TL/master, thus need help on review and commit. >> >> Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ >> >> Simple changes in the code, with a little restructure of jtreg test to >> fit convention. >> >> Cheers, >> Henry > Looks okay to me. > > Rather than adding T8010279.java then you could just add to the existing > unit test with a testNulls if you want. > Test moved to testNulls and add a couple more test on nulls for other methods. Cheers, Henry From henry.jen at oracle.com Fri Apr 12 18:57:49 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 12 Apr 2013 11:57:49 -0700 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: <516858F0.7010607@oracle.com> References: <5165A8A1.7090407@oracle.com> <5165AAF1.3000800@oracle.com> <516858F0.7010607@oracle.com> Message-ID: <5168592D.5030506@oracle.com> On 04/12/2013 11:56 AM, Henry Jen wrote: > On 04/10/2013 11:09 AM, Alan Bateman wrote: >> On 10/04/2013 19:00, Henry Jen wrote: >>> Hi, >>> >>> The bug is reported on lambda repo, part of the fix involved code >>> already integrated into TL/master, thus need help on review and commit. >>> >>> Webrev at: http://cr.openjdk.java.net/~henryjen/tl/8010279.0/webrev/ >>> >>> Simple changes in the code, with a little restructure of jtreg test to >>> fit convention. >>> >>> Cheers, >>> Henry >> Looks okay to me. >> >> Rather than adding T8010279.java then you could just add to the existing >> unit test with a testNulls if you want. >> > > > Test moved to testNulls and add a couple more test on nulls for other > methods. > Forgot the link of updated webrev, http://cr.openjdk.java.net/~henryjen/tl/8010279.1/webrev/ Cheers, Henry From Alan.Bateman at oracle.com Fri Apr 12 19:01:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2013 20:01:20 +0100 Subject: RFR: 8010279 - Comparators should throw NPE on null argument In-Reply-To: <5168592D.5030506@oracle.com> References: <5165A8A1.7090407@oracle.com> <5165AAF1.3000800@oracle.com> <516858F0.7010607@oracle.com> <5168592D.5030506@oracle.com> Message-ID: <51685A00.6030207@oracle.com> On 12/04/2013 19:57, Henry Jen wrote: > : > Forgot the link of updated webrev, > > http://cr.openjdk.java.net/~henryjen/tl/8010279.1/webrev/ > > Cheers, > Henry > Much nicer with the the unit tests expanded to include testNulls. One thing you could do before pushing is just add 8010279 to the @bug tag. -Alan From xueming.shen at oracle.com Fri Apr 12 19:06:33 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 12 Apr 2013 19:06:33 +0000 Subject: hg: jdk8/tl/jdk: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime Message-ID: <20130412190647.34B9748292@hg.openjdk.java.net> Changeset: 6c935c5ac7ff Author: sherman Date: 2013-04-12 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c935c5ac7ff 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime Summary: added the toInstant()/from(Instant) to FileTime Reviewed-by: alanb ! src/share/classes/java/nio/file/attribute/FileTime.java ! test/java/nio/file/attribute/FileTime/Basic.java From joe.darcy at oracle.com Fri Apr 12 19:08:07 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Apr 2013 12:08:07 -0700 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> Message-ID: <51685B97.5010507@oracle.com> On 04/12/2013 11:22 AM, Jason Mehrens wrote: > The landmines are the retrofitted exception classes as shown here > https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and > https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE > is thrown it is going to suppress 'this' and 'cause'. It would be > nice to see the given 'cause' show up in a log file when tracking down > this type of bug. Okay; fair enough. Updated webrev covering initCause too at http://cr.openjdk.java.net/~darcy/8012044.1/ New patch below. (It is a bit of stretch to have this in initiCause by listed as the "cause" of the IllegalStateException; as an alternative, the IllegalStateException could have both this and the cause as suppressed exceptions.) Cheers, -Joe --- old/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 +++ new/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 @@ -452,10 +452,14 @@ * @since 1.4 */ public synchronized Throwable initCause(Throwable cause) { - if (this.cause != this) - throw new IllegalStateException("Can't overwrite cause"); + if (this.cause != this) { + IllegalStateException ise = + new IllegalStateException("Can't overwrite cause", this); + ise.addSuppressed(cause); + throw ise; + } if (cause == this) - throw new IllegalArgumentException("Self-causation not permitted"); + throw new IllegalArgumentException("Self-causation not permitted", this); this.cause = cause; return this; } @@ -1039,7 +1043,7 @@ */ public final synchronized void addSuppressed(Throwable exception) { if (exception == this) - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); if (exception == null) throw new NullPointerException(NULL_CAUSE_MESSAGE); --- old/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:49.000000000 -0700 +++ new/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:48.000000000 -0700 @@ -26,7 +26,7 @@ /* * @test - * @bug 6911258 6962571 6963622 6991528 7005628 + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 * @summary Basic tests of suppressed exceptions * @author Joseph D. Darcy */ @@ -40,6 +40,7 @@ serializationTest(); selfReference(); noModification(); + initCausePlumbing(); } private static void noSelfSuppression() { @@ -48,7 +49,9 @@ throwable.addSuppressed(throwable); throw new RuntimeException("IllegalArgumentException for self-suppresion not thrown."); } catch (IllegalArgumentException iae) { - ; // Expected + // Expected to be here + if (iae.getCause() != throwable) + throw new RuntimeException("Bad cause after self-suppresion."); } } @@ -208,4 +211,29 @@ super("The medium.", null, enableSuppression, true); } } + + private static void initCausePlumbing() { + Throwable t1 = new Throwable(); + Throwable t2 = new Throwable("message", t1); + Throwable t3 = new Throwable(); + + try { + t2.initCause(t3); + throw new RuntimeException("Shouldn't reach."); + } catch (IllegalStateException ise) { + if (ise.getCause() != t2) + throw new RuntimeException("Unexpected cause in ISE", ise); + Throwable[] suppressed = ise.getSuppressed(); + if (suppressed.length != 1 || suppressed[0] != t3) + throw new RuntimeException("Bad suppression in ISE", ise); + } + + try { + t3.initCause(t3); + throw new RuntimeException("Shouldn't reach."); + } catch (IllegalArgumentException iae) { + if (iae.getCause() != t3) + throw new RuntimeException("Unexpected cause in ISE", iae); + } + } } From xueming.shen at oracle.com Fri Apr 12 19:16:20 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 12 Apr 2013 19:16:20 +0000 Subject: hg: jdk8/tl/jdk: 8002390: (zipfs) Problems moving files between zip file systems Message-ID: <20130412191632.7B57848293@hg.openjdk.java.net> Changeset: 729ca1ef7c75 Author: sherman Date: 2013-04-12 12:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/729ca1ef7c75 8002390: (zipfs) Problems moving files between zip file systems Summary: fixed the corner cases in zipfs Reviewed-by: sherman Contributed-by: mark.sheppard at oracle.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From akhil.arora at oracle.com Fri Apr 12 19:50:38 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Fri, 12 Apr 2013 12:50:38 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> Message-ID: <5168658E.4050606@oracle.com> Hi Mike, a few small things - UnmodifiableMap.forEach is missing Objects.requireNonNull(action); EmptyMap.replaceAll(BiFunction) should just return instead of throwing UnsupportedOpEx particularly since EmptyList.replaceAll also returns silently after checking if function is null to fulfil the NPE contract Hashtable is missing a synchronized override of forEach CheckedMap.typeCheck(BiFunction) is missing from the patch (won't compile without it) On 04/11/2013 01:03 PM, Mike Duigou wrote: > Another revision incorporating primarily documentation feedback. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ > > I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. > > This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. > > Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. > > Mike > > > On Apr 10 2013, at 22:42 , Mike Duigou wrote: > >> I've posted an updated webrev with the review comments I have received. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >> >> One important point to consider: >> >> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >> >> Thoughts? >> >> Mike >> >> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >> >>> Hello all; >>> >>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>> >>> 8004518: Add in-place operations to Map >>> forEach() >>> replaceAll() >>> >>> 8010122: Add atomic operations to Map >>> getOrDefault() >>> putIfAbsent() * >>> remove(K, V) >>> replace(K, V) >>> replace(K, V, V) >>> compute() * >>> merge() * >>> computeIfAbsent() * >>> computeIfPresent() * >>> >>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>> >>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>> >>> Mike >> > From mike.duigou at oracle.com Fri Apr 12 19:53:55 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 12 Apr 2013 12:53:55 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <5168658E.4050606@oracle.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> Message-ID: Thanks for the corrections. I have incorporated all of these into the integration version of the patch. On Apr 12 2013, at 12:50 , Akhil Arora wrote: > Hi Mike, > > a few small things - > > UnmodifiableMap.forEach > is missing Objects.requireNonNull(action); Added. > > EmptyMap.replaceAll(BiFunction) > should just return instead of throwing UnsupportedOpEx > particularly since EmptyList.replaceAll also returns silently > after checking if function is null to fulfil the NPE contract I agree. > > Hashtable > is missing a synchronized override of forEach added. > > CheckedMap.typeCheck(BiFunction) > is missing from the patch (won't compile without it) Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. > > On 04/11/2013 01:03 PM, Mike Duigou wrote: >> Another revision incorporating primarily documentation feedback. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >> >> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >> >> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >> >> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >> >> Mike >> >> >> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >> >>> I've posted an updated webrev with the review comments I have received. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>> >>> One important point to consider: >>> >>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>> >>> Thoughts? >>> >>> Mike >>> >>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>> >>>> 8004518: Add in-place operations to Map >>>> forEach() >>>> replaceAll() >>>> >>>> 8010122: Add atomic operations to Map >>>> getOrDefault() >>>> putIfAbsent() * >>>> remove(K, V) >>>> replace(K, V) >>>> replace(K, V, V) >>>> compute() * >>>> merge() * >>>> computeIfAbsent() * >>>> computeIfPresent() * >>>> >>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>> >>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>> >>>> Mike >>> >> > From jim.gish at oracle.com Fri Apr 12 20:11:18 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 12 Apr 2013 16:11:18 -0400 Subject: RFR: 8010939 Deadlock in LogManager Message-ID: <51686A66.70107@oracle.com> Please review: http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock/ Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mandy.chung at oracle.com Fri Apr 12 21:31:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Apr 2013 14:31:16 -0700 Subject: Proxy.isProxyClass scalability In-Reply-To: <51655C8C.8050809@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> Message-ID: <51687D24.9070802@oracle.com> Hi Peter, Thank you for rebasing the patch. This is very good work and I hope to make time to work with you to get your patch to jdk8 over the next couple weeks. On 4/10/2013 5:35 AM, Peter Levart wrote: > Hi Alan, > > I have prepared new webrev of the patch rebased to current tip of > jdk8/tl repo: > > https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html > > [...] > > I also devised an alternative caching mechanism with scalability in > mind which uses WeakReferences for keys (for example ClassLoader) and > values (for example Class) that could be used in this situation in > case adding a field to ClassLoader is not an option: > I would also consider any alternative to avoid adding the proxyClassCache field in ClassLoader as Alan commented previously. My observation of the typical usage of proxies is to use the interface's class loader to define the proxy class. So is it necessary to maintain a per-loader cache? The per-loader cache maps from the interface names to a proxy class defined by one loader. I would think it's reasonable to assume the number of loaders to define proxy class with the same set of interfaces is small. What if we make the cache as "interface names" as the key to a set of proxy class suppliers that can have only one proxy class per one unique defining loader. If the proxy class is being generated i.e. ProxyClassFactory supplier, the loader is available for comparison. When there are more than one matching proxy classes, it would have to iterate all in the set. This alternative is sub-optimal than the per-loader cache. I'd be interested in your thought of this alternative and any rough idea of the performance difference with and without the per-loader cache approach for the annotation case. Coding convention: we use /** ... */ for javadoc and /*...*/ or // for comments. Your patch uses /**...*/ style as comments that need fixing. The style you have for try { } catch { } finally { } Mandy > https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/WeakCache.java > > > > Regards, Peter > > From mike.duigou at oracle.com Fri Apr 12 21:36:37 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 12 Apr 2013 14:36:37 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516735F0.6080705@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> Message-ID: On Apr 11 2013, at 15:15 , Ulf Zibis wrote: > Am 11.04.2013 22:03, schrieb Mike Duigou: >> Another revision incorporating primarily documentation feedback. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ > > There is still a yoda style in ConcurrentMap line 72, HashMap line 361 Fixed > To be in line with old habits, please remove space after casts. See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 I am not going to do this. > Collections: > lines 1442... + 3900... , indentation for follow up line should be 8 > > Map: > lines 599..600 bad indentation Corrected. > > Use consistent formatted code examples in javadoc. I like the style from lines 567 to 570, but e.g. from line 622 to 626: > - 2 spaces before 
> - indentation should be 4
> - line break before }
I had left these along in the previous round. Should be fixed now. Mike From mike.duigou at oracle.com Fri Apr 12 22:02:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 12 Apr 2013 15:02:21 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> Message-ID: I have updated the webrev with these changes and a few more. merge() required an update to it's specification to correctly account for null values. http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. Mike On Apr 12 2013, at 12:53 , Mike Duigou wrote: > Thanks for the corrections. I have incorporated all of these into the integration version of the patch. > > On Apr 12 2013, at 12:50 , Akhil Arora wrote: > >> Hi Mike, >> >> a few small things - >> >> UnmodifiableMap.forEach >> is missing Objects.requireNonNull(action); > > Added. > >> >> EmptyMap.replaceAll(BiFunction) >> should just return instead of throwing UnsupportedOpEx >> particularly since EmptyList.replaceAll also returns silently >> after checking if function is null to fulfil the NPE contract > > I agree. > >> >> Hashtable >> is missing a synchronized override of forEach > > added. > >> >> CheckedMap.typeCheck(BiFunction) >> is missing from the patch (won't compile without it) > > Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. > >> >> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>> Another revision incorporating primarily documentation feedback. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>> >>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>> >>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>> >>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>> >>> Mike >>> >>> >>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>> >>>> I've posted an updated webrev with the review comments I have received. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>> >>>> One important point to consider: >>>> >>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>> >>>> Thoughts? >>>> >>>> Mike >>>> >>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>> >>>>> 8004518: Add in-place operations to Map >>>>> forEach() >>>>> replaceAll() >>>>> >>>>> 8010122: Add atomic operations to Map >>>>> getOrDefault() >>>>> putIfAbsent() * >>>>> remove(K, V) >>>>> replace(K, V) >>>>> replace(K, V, V) >>>>> compute() * >>>>> merge() * >>>>> computeIfAbsent() * >>>>> computeIfPresent() * >>>>> >>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>> >>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>> >>>>> Mike >>>> >>> >> > > From mandy.chung at oracle.com Fri Apr 12 22:51:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Apr 2013 15:51:26 -0700 Subject: RFR: 8010939 Deadlock in LogManager In-Reply-To: <51686A66.70107@oracle.com> References: <51686A66.70107@oracle.com> Message-ID: <51688FEE.3070208@oracle.com> Hi Jim, Thanks for fixing this. On 4/12/2013 1:11 PM, Jim Gish wrote: > Please review: > http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock/ > The fix looks okay. I would recommend to move the call to manager.drainLoggerRefQueueBounded() back to LogManager.addLogger which was originally intended and make the two separate synchronized methods called at the entry point as it's described in the comments of the drainLoggerRefQueueBounded. You added a comment listing the bug ID. Our convention does not reference the bug numbers in the source unless it's absolute critical information to capture to help cross-referencing. I wouldn't want to see the bug numbers in the source that are fixed in the past 18 years :) Good that you have a test to reproduce the deadlock. A few comments: The thread should be daemon threads so that the test will terminate right away if there is a deadlock. L99: is this needed to reproduce the deadlock? Logger.getLogger has already called LogManager.addLogger to register the logger. L111: what exception is expected to be thrown and ignored by the test? L137,144 you can call ThreadMXBean.isSynchronizerUsageSupported() to test if monitoring of ownable synchronizer is supported instead of catch UOE. L154: you may just throw an exception and terminate the test. Better to rename your test to some informative name that will give some idea what it does. It should have @summary to give a summary of what it tests. There are several deadlock tests in test/java/util/logging. I like your framework and probably good to consolidate these deadlock tests but this is something for the future clean up - just to mention it. The LoggingDeadlocks*.java tests have the comments how the deadlock occurs that I find useful. It'll be good to add similar information in your new test. Some formatting nit: L97 a space after "i=0;" and an extra space is many places (e.g. L69-71, L128, 141, 156, etc: a space not needed in front of the first parameter after "(", a space of the last parameter before ")" not needed - L127, 134, 152, etc. thanks Mandy From stevenschlansker at gmail.com Fri Apr 12 23:30:57 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 12 Apr 2013 16:30:57 -0700 Subject: Throwable.addSuppressed error conditions -- use the exception as the cause? In-Reply-To: References: <3F486337-E102-43A9-A11C-188F822C23CA@gmail.com> <54AC68B4-C1A6-4F6B-84A2-C5C9B6F6F3B1@gmail.com> Message-ID: On Apr 11, 2013, at 9:04 PM, Zhong Yu wrote: > On Tue, Apr 9, 2013 at 11:54 AM, Steven Schlansker > wrote: >> >> I agree, but there is (library) code out there that does this -- the code that caused the problem wasn't even mine. > > The library should be told to fix the bug. It is really serious, for > example, more and more suppressed exceptions can be added to this > reused/shared/cached exception, causing memory leak. A mutable > exception simply cannot be shared, otherwise there will be multiple > exception handler trying to mutate it. I don't disagree. I only claim that the current state of things makes diagnosis very hard -- the throw site is lost, so you do not even know where the problem is. This needlessly complicates life, and can be caused in the wild by code that long predates Java 7, just by using the new try-with-resources construct. The "action at a distance" is what is painful. From joe.darcy at oracle.com Sat Apr 13 00:43:07 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Apr 2013 17:43:07 -0700 Subject: JDK 8 code review request for 8005042 Add Method.isDefault to core reflection In-Reply-To: <50D1825F.6090608@gmail.com> References: <50D0D55C.5040900@oracle.com> <50D0DE3F.6060604@oracle.com> <50D0EF1A.4080303@oracle.com> <50D10658.7010200@oracle.com> <50D10753.6060700@oracle.com> <50D10861.3000202@oracle.com> <50D1095B.4090805@oracle.com> <50D10BC3.3020504@oracle.com> <50D1825F.6090608@gmail.com> Message-ID: <5168AA1B.8090900@oracle.com> Following up on email from a few months ago.... On 12/19/2012 01:01 AM, Peter Levart wrote: > On 12/19/2012 01:35 AM, David Holmes wrote: >> On 19/12/2012 10:24 AM, Joe Darcy wrote: >>> On 12/18/2012 04:20 PM, David Holmes wrote: >>>> On 19/12/2012 10:16 AM, Joe Darcy wrote: >>>>> On 12/18/2012 04:12 PM, David Holmes wrote: >>>>>> On 19/12/2012 8:40 AM, Louis Wasserman wrote: >>>>>>> It's not 100% obvious to me whether this refers to a default >>>>>>> implementation >>>>>>> in an interface, a class which inherits that default implementation >>>>>>> and does not override it, or both. Is that worth clarifying in >>>>>>> the doc, >>>>>>> rather than forcing readers to check the JLS citation? >>>>>> >>>>>> The issue is where you obtained this Method reference from: >>>>>> >>>>>> - from the Interface? then it is a default method >>>>>> - from a class implementing the interface but not redefining the >>>>>> method? then it is a default method >>>>> >>>>> Actually, that is *now* how HotSpot represents this case in core >>>>> reflection at the moment. HotSpot uses a new method object to >>>>> represent >>>>> the default method woven into an implementing class. >>>> >>>> *now* -> *not* ?? >>> >>> Correct. >>> >>>> >>>> It may be a new Method object but getDeclaringClass() should give the >>>> interface class NOT the concrete class. That is currently the case for >>>> abstract interface methods. I hope it is the same for default methods! >>> >>> It is not at the moment, which is a bit surprising. >> >> Very surprising! I'd call that a major bug. > > Not only default methods, also abstract interface methods show-up in > the implementing class's declared methods. For example the following > test: > > public class DefaultMethodsTest { > public interface I { > void i(); > default void d() { } > } > > public abstract static class S { > public abstract void a(); > public void s() { } > } > > public abstract static class C extends S implements I { > public void c() { } > } > > public static void main(String[] args) { > for (Method m : C.class.getDeclaredMethods()) > System.out.println(m.getName()); > } > } > > > prints: > > c > i > d As of build 84 of JDK 8, this behavior has been corrected by the fix for JDK-8010017 lambda: reflection get(Declared)Methods support for concrete methods in interfaces The test program above will now just print c Test cases similar to the program above were subsequently pushed into the JDK repo under JDK-8011590 More tests for core reflection modeling of default methods Cheers, -Joe From rednaxelafx at gmail.com Sat Apr 13 01:51:00 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 13 Apr 2013 09:51:00 +0800 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <789455e.30104.13dfe82dcf4.Coremail.wangsheng.0376@163.com> References: <789455e.30104.13dfe82dcf4.Coremail.wangsheng.0376@163.com> Message-ID: Hi Nazario, That's a typical substring leak case. Matcher.group(n) eventually calls String.substring() to return the result. Before removing the count and offset fields in String, that'll return a String sharing the value char array, which may cause memory leaks if you hold on to a small substring of a large string. It's not your HashSet leaking memory, just the substring. - Kris On Fri, Apr 12, 2013 at 9:50 PM, wangsheng.0376 wrote: > hi, all, > > I agree with you to remove offset, today when I run following code in > jdk7(sorry I forget the detail version), my code is like this: > > > > > Pattern pattern = Pattern.compile(regex); > > Matcher matcher = pattern.match(content); > > while (matcher.find()) { > > String link = matcher.group(1); > > set.add(link);// set is a HashSet type > > } > > > > > after I running for some time, I found that the 'set' object has memory > leak, I found though 'link' is a part of 'content', but the value field in > link variable is same as 'content' value field, difference is that the link > offset field is not zero. > > So that mean the set(HashSet) is not store the 'link', it store the > 'content' value field, it will cause the memory leak problem, So I am very > happy to reomve the offset field. > > > > > Best Regards > > =nazario.wang= > From jason_mehrens at hotmail.com Sat Apr 13 02:29:32 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 12 Apr 2013 21:29:32 -0500 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <51685B97.5010507@oracle.com> References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> , <51685B97.5010507@oracle.com> Message-ID: Joe, You'll have guard ise.addSuppressed against null. Looks good otherwise. private static void initCauseNull() { Throwable t1 = new Throwable(); t1.initCause(null); try { t1.initCause(null); } catch(IllegalStateException expect) { } } Jason Date: Fri, 12 Apr 2013 12:08:07 -0700 From: joe.darcy at oracle.com To: jason_mehrens at hotmail.com CC: core-libs-dev at openjdk.java.net Subject: Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed On 04/12/2013 11:22 AM, Jason Mehrens wrote: The landmines are the retrofitted exception classes as shown here https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE is thrown it is going to suppress 'this' and 'cause'. It would be nice to see the given 'cause' show up in a log file when tracking down this type of bug. Okay; fair enough. Updated webrev covering initCause too at http://cr.openjdk.java.net/~darcy/8012044.1/ New patch below. (It is a bit of stretch to have this in initiCause by listed as the "cause" of the IllegalStateException; as an alternative, the IllegalStateException could have both this and the cause as suppressed exceptions.) Cheers, -Joe --- old/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 +++ new/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 @@ -452,10 +452,14 @@ * @since 1.4 */ public synchronized Throwable initCause(Throwable cause) { - if (this.cause != this) - throw new IllegalStateException("Can't overwrite cause"); + if (this.cause != this) { + IllegalStateException ise = + new IllegalStateException("Can't overwrite cause", this); + ise.addSuppressed(cause); + throw ise; + } if (cause == this) - throw new IllegalArgumentException("Self-causation not permitted"); + throw new IllegalArgumentException("Self-causation not permitted", this); this.cause = cause; return this; } @@ -1039,7 +1043,7 @@ */ public final synchronized void addSuppressed(Throwable exception) { if (exception == this) - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); if (exception == null) throw new NullPointerException(NULL_CAUSE_MESSAGE); --- old/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:49.000000000 -0700 +++ new/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:48.000000000 -0700 @@ -26,7 +26,7 @@ /* * @test - * @bug 6911258 6962571 6963622 6991528 7005628 + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 * @summary Basic tests of suppressed exceptions * @author Joseph D. Darcy */ @@ -40,6 +40,7 @@ serializationTest(); selfReference(); noModification(); + initCausePlumbing(); } private static void noSelfSuppression() { @@ -48,7 +49,9 @@ throwable.addSuppressed(throwable); throw new RuntimeException("IllegalArgumentException for self-suppresion not thrown."); } catch (IllegalArgumentException iae) { - ; // Expected + // Expected to be here + if (iae.getCause() != throwable) + throw new RuntimeException("Bad cause after self-suppresion."); } } @@ -208,4 +211,29 @@ super("The medium.", null, enableSuppression, true); } } + + private static void initCausePlumbing() { + Throwable t1 = new Throwable(); + Throwable t2 = new Throwable("message", t1); + Throwable t3 = new Throwable(); + + try { + t2.initCause(t3); + throw new RuntimeException("Shouldn't reach."); + } catch (IllegalStateException ise) { + if (ise.getCause() != t2) + throw new RuntimeException("Unexpected cause in ISE", ise); + Throwable[] suppressed = ise.getSuppressed(); + if (suppressed.length != 1 || suppressed[0] != t3) + throw new RuntimeException("Bad suppression in ISE", ise); + } + + try { + t3.initCause(t3); + throw new RuntimeException("Shouldn't reach."); + } catch (IllegalArgumentException iae) { + if (iae.getCause() != t3) + throw new RuntimeException("Unexpected cause in ISE", iae); + } + } } From jonathan.gibbons at oracle.com Sat Apr 13 03:14:50 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 13 Apr 2013 03:14:50 +0000 Subject: hg: jdk8/tl/jdk: 8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE Message-ID: <20130413031503.5EC1F482AF@hg.openjdk.java.net> Changeset: d8cae0195fe9 Author: henryjen Date: 2013-04-12 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8cae0195fe9 8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Comparators.java + test/java/util/Comparators/BasicTest.java - test/java/util/ComparatorsTest.java From robert.field at oracle.com Sat Apr 13 03:23:47 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sat, 13 Apr 2013 03:23:47 +0000 Subject: hg: jdk8/tl/jdk: 8012028: Metafactory-generated lambda classes should be final; ... Message-ID: <20130413032359.43196482B0@hg.openjdk.java.net> Changeset: 06dfdfa8c3e6 Author: rfield Date: 2013-04-12 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06dfdfa8c3e6 8012028: Metafactory-generated lambda classes should be final 8008941: isSynthetic() returns false for lambda instances Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaClassFinal.java + test/java/lang/invoke/lambda/LambdaClassSynthetic.java From vicente.romero at oracle.com Sat Apr 13 11:29:07 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 13 Apr 2013 11:29:07 +0000 Subject: hg: jdk8/tl/langtools: 8010659: Javac Crashes while building OpenJFX Message-ID: <20130413112914.2E981482B6@hg.openjdk.java.net> Changeset: 76537856a54e Author: vromero Date: 2013-04-13 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76537856a54e 8010659: Javac Crashes while building OpenJFX Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com + src/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java From chris.hegarty at oracle.com Sat Apr 13 15:59:30 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 13 Apr 2013 15:59:30 +0000 Subject: hg: jdk8/tl/jdk: 8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c Message-ID: <20130413160009.3BA85482B8@hg.openjdk.java.net> Changeset: 0111bab8dc35 Author: jzavgren Date: 2013-04-11 12:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0111bab8dc35 8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c Summary: Modified the path processing code so that it detects and handles out of memory errors. Reviewed-by: chegar, martin, christos, alanb, msheppar Contributed-by: john.zavgren at oracle.com ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/UNIXProcess_md.c From Ulf.Zibis at CoSoCo.de Sat Apr 13 16:34:03 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 13 Apr 2013 18:34:03 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> Message-ID: <516988FB.8070501@CoSoCo.de> Am 12.04.2013 23:36, schrieb Mike Duigou: > On Apr 11 2013, at 15:15 , Ulf Zibis wrote: > >> There is still a yoda style in ConcurrentMap line 72, HashMap line 361 > Fixed I still see no change in webrev 5 in HashMap line 361 > >> To be in line with old habits, please remove space after casts. See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 > I am not going to do this. Well in Hashtable, existing code doesn't have the space after cast. If you insert space in new code, you introduce an inconsistency in style. Even your new code is inconsistent, compare: HashTable line 917, 938, 984 etc. HashMap line 588 etc. Collections line 1402 etc. I also notice, you introduce a new style ? in for( ; ... ; ... ;) expressions with space before ';'. >> Collections: >> lines 1442... + 3900... , indentation for follow up line should be 8 There are still lines 976, 1062 >> Map: >> lines 599..600 bad indentation > Corrected. Hm, I see still 3 instead 4 spaces and also in lines 545..546 > >> Use consistent formatted code examples in javadoc. I like the style from lines 567 to 570, but e.g. from line 622 to 626: >> - 2 spaces before 
>> - indentation should be 4
>> - line break before }
> I had left these along in the previous round. Should be fixed now. Great, but see also code samples in ConcurrentMap. -Ulf From peter.levart at gmail.com Sat Apr 13 21:59:55 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 13 Apr 2013 23:59:55 +0200 Subject: Proxy.isProxyClass scalability In-Reply-To: <51687D24.9070802@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> <51687D24.9070802@oracle.com> Message-ID: <5169D55B.8040709@gmail.com> Hi Mandy, On 04/12/2013 11:31 PM, Mandy Chung wrote: > Hi Peter, > > Thank you for rebasing the patch. This is very good work and I hope to > make time to work with you to get your patch to jdk8 over the next > couple weeks. I hope I can be of assistance, > > On 4/10/2013 5:35 AM, Peter Levart wrote: >> Hi Alan, >> >> I have prepared new webrev of the patch rebased to current tip of >> jdk8/tl repo: >> >> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html >> >> > [...] >> >> I also devised an alternative caching mechanism with scalability in >> mind which uses WeakReferences for keys (for example ClassLoader) and >> values (for example Class) that could be used in this situation in >> case adding a field to ClassLoader is not an option: >> > > I would also consider any alternative to avoid adding the > proxyClassCache field in ClassLoader as Alan commented previously. > > My observation of the typical usage of proxies is to use the > interface's class loader to define the proxy class. So is it necessary > to maintain a per-loader cache? The per-loader cache maps from the > interface names to a proxy class defined by one loader. I would think > it's reasonable to assume the number of loaders to define proxy class > with the same set of interfaces is small. What if we make the cache > as "interface names" as the key to a set of proxy class suppliers that > can have only one proxy class per one unique defining loader. If the > proxy class is being generated i.e. ProxyClassFactory supplier, the > loader is available for comparison. When there are more than one > matching proxy classes, it would have to iterate all in the set. I would assume yes, proxy class for a particular set of interfaces is typically defined by one classloader only. But the API allows to specify different loaders as long as the interfaces implemented by proxy class are "visible" from the loader that defines the proxy class. If we're talking about interface names - as opposed to interfaces - then the possibility that a particular set of interface names would want to be used to define proxy classes with different loaders is even bigger, since an interface name can refer to different interfaces with same name (think of interfaces deployed as part of an app in an application server, say a set of annotations used by different apps but deployed as part of each individual app). The scheme you're proposing might be possible, though not simple: The factory Supplier would become a Function and would have to maintain it's own set of cached proxy classes. There would be a single ConcurrentMap, Function> to map sets of interface names to factory Functions, but the cached classes in a particular factory Function would still have to be weakly referenced. I see some difficulties in implementing such a scheme: - expunging cleared WeakReferences could only reliably clear the cache inside each factory Function but removing the entry from the map of factory Functions when last proxy class for a particular set of interface names is expunged would become a difficult task if not impossible with all the scalability constraints in mind (just thinking about concurrent requests into same factory Function where one is requesting new proxy class and the other is expunging cleared WeakReference which represents the last element in the set of cached proxy classes). - one of my past ideas of implementing scalable Proxy.isProxyClass() was to maintain a Set in each ClassLoader populated with all the proxy classes defined by a particular ClassLoader. Benchmarking such solution showed that Class.getClassLoader() is a peformance hog, so I scraped it in favor of ClassValue that is now incorporated in the patch. In order to "choose" the right proxy class from the set of proxy classes inside a particular factory Function, the Class.getClassLoader() method would have to be used, or entries would have to (weakly) reference a particular ClassLoader associated with each proxy class. Considering all that, such solution starts to look unappealing. It might even be more space-hungry then the presented WeakCache. WeakCache is currently the following: ConcurrentMap, WeakReference> another alternative would be: ConcurrentMap, ConcurrentMap>> ...which might need a little less space than WeakCache (only one WeakReference per proxy class + one per ClassLoader instead of two WeakReferences per proxy class) but would require two map lookups during fast-path retrieval. It might not be performance critical and the expunging could be performed easily too. Regards, Peter > > This alternative is sub-optimal than the per-loader cache. I'd be > interested in your thought of this alternative and any rough idea of > the performance difference with and without the per-loader cache > approach for the annotation case. > > Coding convention: we use /** ... */ for javadoc and /*...*/ or // for > comments. Your patch uses /**...*/ style as comments that need > fixing. The style you have for > try { > } > catch { > } > finally { > } > > Mandy > >> https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/WeakCache.java >> >> >> >> Regards, Peter >> >> > From bhavesh.x.patel at oracle.com Sun Apr 14 01:49:47 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sun, 14 Apr 2013 01:49:47 +0000 Subject: hg: jdk8/tl/langtools: 8009686: Generated javadoc documentation should be able to display type annotation on an array Message-ID: <20130414014954.9AC0B482C0@hg.openjdk.java.net> Changeset: f10cffab99b4 Author: bpatel Date: 2013-04-13 18:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f10cffab99b4 8009686: Generated javadoc documentation should be able to display type annotation on an array Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java From chris.hegarty at oracle.com Sun Apr 14 09:32:46 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 14 Apr 2013 10:32:46 +0100 Subject: RFR 8011799: CompletableFuture/Basic.java fails intermittently Message-ID: <516A77BE.8@oracle.com> Silly mistake in the test. Incorrectly assumes that one of the given CompletableFutures must be completed before applyToEitherXXX / acceptEitherXXX / runAfterEitherXXX / anyOf returns. The correct assertion is that one of the given CompletableFutures must be completed before the return CompletableFuture completes. With the given structure of the test this can be done by checking that one of the given CompletableFutures is complete after joining the returned CompletableFuture. http://cr.openjdk.java.net/~chegar/8011799/webrev.00/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html -Chris. From martinrb at google.com Sun Apr 14 14:55:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 14 Apr 2013 07:55:55 -0700 Subject: RFR 8011799: CompletableFuture/Basic.java fails intermittently In-Reply-To: <516A77BE.8@oracle.com> References: <516A77BE.8@oracle.com> Message-ID: Looks good. I've made the same mistake testing CompletableFuture. On Sun, Apr 14, 2013 at 2:32 AM, Chris Hegarty wrote: > Silly mistake in the test. Incorrectly assumes that one of the given > CompletableFutures must be completed before applyToEitherXXX / > acceptEitherXXX / runAfterEitherXXX / anyOf returns. The correct assertion > is that one of the given CompletableFutures must be completed before the > return CompletableFuture completes. > > With the given structure of the test this can be done by checking that one > of the given CompletableFutures is complete after joining the returned > CompletableFuture. > > http://cr.openjdk.java.net/~**chegar/8011799/webrev.00/** > webrev/test/java/util/**concurrent/CompletableFuture/** > Basic.java.udiff.html > > -Chris. > From Alan.Bateman at oracle.com Sun Apr 14 15:06:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 14 Apr 2013 16:06:52 +0100 Subject: RFR 8011799: CompletableFuture/Basic.java fails intermittently In-Reply-To: <516A77BE.8@oracle.com> References: <516A77BE.8@oracle.com> Message-ID: <516AC60C.6090803@oracle.com> On 14/04/2013 10:32, Chris Hegarty wrote: > Silly mistake in the test. Incorrectly assumes that one of the given > CompletableFutures must be completed before applyToEitherXXX / > acceptEitherXXX / runAfterEitherXXX / anyOf returns. The correct > assertion is that one of the given CompletableFutures must be > completed before the return CompletableFuture completes. > > With the given structure of the test this can be done by checking that > one of the given CompletableFutures is complete after joining the > returned CompletableFuture. > > http://cr.openjdk.java.net/~chegar/8011799/webrev.00/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html > > > -Chris. Looks good to me too. -Alan From Alan.Bateman at oracle.com Sun Apr 14 15:22:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 14 Apr 2013 16:22:33 +0100 Subject: RFR (S) 8009531: Crash when redefining class with annotated method In-Reply-To: <5168483A.9020304@oracle.com> References: <5168483A.9020304@oracle.com> Message-ID: <516AC9B9.8000304@oracle.com> On 12/04/2013 18:45, Coleen Phillimore wrote: > Summary: Add annotations to the tests to verify bug above > > open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk > > The Hotspot change is in tl repository now. Also, this has been > reviewed by the hotspot group. > > Thanks, > Coleen Just so I'm clear - this is really just adding -XX:+StressLdcRewrite and debug output to the tests rather than adding additional annotations, right? -Alan From chris.hegarty at oracle.com Sun Apr 14 17:05:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 14 Apr 2013 18:05:39 +0100 Subject: RFR 8011799: CompletableFuture/Basic.java fails intermittently In-Reply-To: References: <516A77BE.8@oracle.com> Message-ID: <8986B51D-CBFA-4D2E-9B21-01651F891CD7@oracle.com> Thanks Martin. -Chris On 14 Apr 2013, at 15:55, Martin Buchholz wrote: > Looks good. > > I've made the same mistake testing CompletableFuture. > > > On Sun, Apr 14, 2013 at 2:32 AM, Chris Hegarty wrote: >> Silly mistake in the test. Incorrectly assumes that one of the given CompletableFutures must be completed before applyToEitherXXX / acceptEitherXXX / runAfterEitherXXX / anyOf returns. The correct assertion is that one of the given CompletableFutures must be completed before the return CompletableFuture completes. >> >> With the given structure of the test this can be done by checking that one of the given CompletableFutures is complete after joining the returned CompletableFuture. >> >> http://cr.openjdk.java.net/~chegar/8011799/webrev.00/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html >> >> -Chris. > From chris.hegarty at oracle.com Sun Apr 14 17:06:18 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 14 Apr 2013 18:06:18 +0100 Subject: RFR 8011799: CompletableFuture/Basic.java fails intermittently In-Reply-To: <516AC60C.6090803@oracle.com> References: <516A77BE.8@oracle.com> <516AC60C.6090803@oracle.com> Message-ID: Thanks Alan. -Chris On 14 Apr 2013, at 16:06, Alan Bateman wrote: > On 14/04/2013 10:32, Chris Hegarty wrote: >> Silly mistake in the test. Incorrectly assumes that one of the given CompletableFutures must be completed before applyToEitherXXX / acceptEitherXXX / runAfterEitherXXX / anyOf returns. The correct assertion is that one of the given CompletableFutures must be completed before the return CompletableFuture completes. >> >> With the given structure of the test this can be done by checking that one of the given CompletableFutures is complete after joining the returned CompletableFuture. >> >> http://cr.openjdk.java.net/~chegar/8011799/webrev.00/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html >> >> -Chris. > Looks good to me too. > > -Alan From peter.levart at gmail.com Sun Apr 14 17:54:49 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 14 Apr 2013 19:54:49 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> Message-ID: <516AED69.8020105@gmail.com> Hi Mike, Just a nit: The order of boolean sub-expressions in Map.replace(key, oldValue, newValue): 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) ...would be more optimal if reversed (like in Map.remove(key, value)). Regards, Peter On 04/13/2013 12:02 AM, Mike Duigou wrote: > I have updated the webrev with these changes and a few more. > > merge() required an update to it's specification to correctly account for null values. > > http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ > > This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. > > Mike > > On Apr 12 2013, at 12:53 , Mike Duigou wrote: > >> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >> >> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >> >>> Hi Mike, >>> >>> a few small things - >>> >>> UnmodifiableMap.forEach >>> is missing Objects.requireNonNull(action); >> Added. >> >>> EmptyMap.replaceAll(BiFunction) >>> should just return instead of throwing UnsupportedOpEx >>> particularly since EmptyList.replaceAll also returns silently >>> after checking if function is null to fulfil the NPE contract >> I agree. >> >>> Hashtable >>> is missing a synchronized override of forEach >> added. >> >>> CheckedMap.typeCheck(BiFunction) >>> is missing from the patch (won't compile without it) >> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >> >>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>> Another revision incorporating primarily documentation feedback. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>> >>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>> >>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>> >>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>> >>>> Mike >>>> >>>> >>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>> >>>>> I've posted an updated webrev with the review comments I have received. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>> >>>>> One important point to consider: >>>>> >>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>> >>>>> Thoughts? >>>>> >>>>> Mike >>>>> >>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>> >>>>>> Hello all; >>>>>> >>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>> >>>>>> 8004518: Add in-place operations to Map >>>>>> forEach() >>>>>> replaceAll() >>>>>> >>>>>> 8010122: Add atomic operations to Map >>>>>> getOrDefault() >>>>>> putIfAbsent() * >>>>>> remove(K, V) >>>>>> replace(K, V) >>>>>> replace(K, V, V) >>>>>> compute() * >>>>>> merge() * >>>>>> computeIfAbsent() * >>>>>> computeIfPresent() * >>>>>> >>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>> >>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>> >>>>>> Mike From chris.hegarty at oracle.com Sun Apr 14 18:20:15 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 14 Apr 2013 18:20:15 +0000 Subject: hg: jdk8/tl/jdk: 8011799: CompletableFuture/Basic.java fails intermittently Message-ID: <20130414182102.37237482CC@hg.openjdk.java.net> Changeset: 5c406a747192 Author: chegar Date: 2013-04-14 19:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c406a747192 8011799: CompletableFuture/Basic.java fails intermittently Reviewed-by: martin, alanb ! test/java/util/concurrent/CompletableFuture/Basic.java From peter.levart at gmail.com Sun Apr 14 18:35:02 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 14 Apr 2013 20:35:02 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516AED69.8020105@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> <516AED69.8020105@gmail.com> Message-ID: <516AF6D6.7000404@gmail.com> On 04/14/2013 07:54 PM, Peter Levart wrote: > Hi Mike, > > Just a nit: The order of boolean sub-expressions in Map.replace(key, > oldValue, newValue): > > 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) > > ...would be more optimal if reversed (like in Map.remove(key, value)). > > Regards, Peter I think the most optimal is actually this: default boolean remove((Object key, Object value) { Object curValue = get(key); if (curValue == null && (value != null || !containsKey(key)) || curValue != value && !curValue.equals(value)) { return false; } remove(key); return true; } ...and the same for replace(key, oldValue, newValue)... Regards, Peter > > On 04/13/2013 12:02 AM, Mike Duigou wrote: >> I have updated the webrev with these changes and a few more. >> >> merge() required an update to it's specification to correctly account for null values. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ >> >> This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. >> >> Mike >> >> On Apr 12 2013, at 12:53 , Mike Duigou wrote: >> >>> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >>> >>> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >>> >>>> Hi Mike, >>>> >>>> a few small things - >>>> >>>> UnmodifiableMap.forEach >>>> is missing Objects.requireNonNull(action); >>> Added. >>> >>>> EmptyMap.replaceAll(BiFunction) >>>> should just return instead of throwing UnsupportedOpEx >>>> particularly since EmptyList.replaceAll also returns silently >>>> after checking if function is null to fulfil the NPE contract >>> I agree. >>> >>>> Hashtable >>>> is missing a synchronized override of forEach >>> added. >>> >>>> CheckedMap.typeCheck(BiFunction) >>>> is missing from the patch (won't compile without it) >>> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >>> >>>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>>> Another revision incorporating primarily documentation feedback. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>>> >>>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>>> >>>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>>> >>>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>>> >>>>> Mike >>>>> >>>>> >>>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>>> >>>>>> I've posted an updated webrev with the review comments I have received. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>>> >>>>>> One important point to consider: >>>>>> >>>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Mike >>>>>> >>>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>>> >>>>>>> Hello all; >>>>>>> >>>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>>> >>>>>>> 8004518: Add in-place operations to Map >>>>>>> forEach() >>>>>>> replaceAll() >>>>>>> >>>>>>> 8010122: Add atomic operations to Map >>>>>>> getOrDefault() >>>>>>> putIfAbsent() * >>>>>>> remove(K, V) >>>>>>> replace(K, V) >>>>>>> replace(K, V, V) >>>>>>> compute() * >>>>>>> merge() * >>>>>>> computeIfAbsent() * >>>>>>> computeIfPresent() * >>>>>>> >>>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>>> >>>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>>> >>>>>>> Mike > From david.holmes at oracle.com Mon Apr 15 00:18:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Apr 2013 10:18:19 +1000 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds Message-ID: <516B474B.8090404@oracle.com> Some background. The jvm.cfg file, for which there is a per-architecture committed file in the repository, controls which VM's (client, server, minimal) are known, which is the default, whether there are other aliases and whether ergonomic selection is used. Historically things were simple: - 64-bit platforms had server only - 32-bit platforms had client and server then we acknowledged that some platforms may be client only and we added some support (originally in the old build then converted to the new build) for dynamically creating a jvm.cfg for the case of building client only. Then the minimal VM was introduced and we potentially have three VMs to handle. To address this we initially added "-minimal KNOWN" to all the jvm.cfg files for platforms known to support the minimal VM - this was done under JDK-7198815 (and those changes are now reversed by this changeset.) The problem after minimal was introduced was that the logic for "building client only" didn't account for building minimal (only or combined with client) and we need support for not-building-server. And that is what this changeset does. This only affects 32-bit builds as there is no client nor minimal VM on 64-bit. The basic operation is as follows: - If building client+server then we use the committed jvm.cfg (which handles ergonomics if applicable), adding a "-minimal KNOWN" line if minimal is also selected; - Otherwise we dynamically generate a jvm.cfg for the set of VMs being built, using these simple rules: - if client or server are present they are default - if client and/or server is absent then the absent VM is aliased to the default VM in that config - if minimal is not selected then it is absent from the jvm.cfg (we do not add any aliases for minimal**). ** The alias mechanism is useful for deprecating legacy VM names, and has also made testing more convenient. However I think it is a flawed mechanism for testing and our internal test infrastructure is moving away from arbitrarily using -client/-server when actually running server/client. If you ask for the minimal VM and it is not available I think you should get an error not silent use of a different VM. (Note: this selection doesn't affect SE Embedded as it defines jvm.cfg files using it's own rules/preferences.) webrev: http://cr.openjdk.java.net/~dholmes/8010280/webrev/ Thanks, David From joe.darcy at oracle.com Mon Apr 15 02:36:09 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 14 Apr 2013 19:36:09 -0700 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> , <51685B97.5010507@oracle.com> Message-ID: <516B6799.1010206@oracle.com> On 04/12/2013 07:29 PM, Jason Mehrens wrote: > Joe, > You'll have guard ise.addSuppressed against null. Looks good otherwise. > > private static void initCauseNull() { > Throwable t1 = new Throwable(); > t1.initCause(null); > try { > t1.initCause(null); > } catch(IllegalStateException expect) { > } > } Right you are; check added and test updated in: http://cr.openjdk.java.net/~darcy/8012044.2/ Full patch to Throwable: --- old/src/share/classes/java/lang/Throwable.java 2013-04-14 19:33:23.000000000 -0700 +++ new/src/share/classes/java/lang/Throwable.java 2013-04-14 19:33:23.000000000 -0700 @@ -452,10 +452,15 @@ * @since 1.4 */ public synchronized Throwable initCause(Throwable cause) { - if (this.cause != this) - throw new IllegalStateException("Can't overwrite cause"); + if (this.cause != this) { + IllegalStateException ise = + new IllegalStateException("Can't overwrite cause", this); + if (cause != null) + ise.addSuppressed(cause); + throw ise; + } if (cause == this) - throw new IllegalArgumentException("Self-causation not permitted"); + throw new IllegalArgumentException("Self-causation not permitted", this); this.cause = cause; return this; } @@ -1039,7 +1044,7 @@ */ public final synchronized void addSuppressed(Throwable exception) { if (exception == this) - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); if (exception == null) throw new NullPointerException(NULL_CAUSE_MESSAGE); Cheers, -Joe > Jason > > Date: Fri, 12 Apr 2013 12:08:07 -0700 > From: joe.darcy at oracle.com > To: jason_mehrens at hotmail.com > CC: core-libs-dev at openjdk.java.net > Subject: Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed > On 04/12/2013 11:22 AM, Jason Mehrens wrote: > > The landmines are the retrofitted exception classes as shown here https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE is thrown it is going to suppress 'this' and 'cause'. It would be nice to see the given 'cause' show up in a log file when tracking down this type of bug. > Okay; fair enough. Updated webrev covering initCause too at > http://cr.openjdk.java.net/~darcy/8012044.1/ > New patch below. > (It is a bit of stretch to have this in initiCause by listed as the "cause" of the IllegalStateException; as an alternative, the IllegalStateException could have both this and the cause as suppressed exceptions.) > Cheers, > -Joe > --- old/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 > +++ new/src/share/classes/java/lang/Throwable.java 2013-04-12 12:03:48.000000000 -0700 > @@ -452,10 +452,14 @@ > * @since 1.4 > */ > public synchronized Throwable initCause(Throwable cause) { > - if (this.cause != this) > - throw new IllegalStateException("Can't overwrite cause"); > + if (this.cause != this) { > + IllegalStateException ise = > + new IllegalStateException("Can't overwrite cause", this); > + ise.addSuppressed(cause); > + throw ise; > + } > if (cause == this) > - throw new IllegalArgumentException("Self-causation not permitted"); > + throw new IllegalArgumentException("Self-causation not permitted", this); > this.cause = cause; > return this; > } > @@ -1039,7 +1043,7 @@ > */ > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > if (exception == null) > throw new NullPointerException(NULL_CAUSE_MESSAGE); > --- old/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:49.000000000 -0700 > +++ new/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 12:03:48.000000000 -0700 > @@ -26,7 +26,7 @@ > /* > * @test > - * @bug 6911258 6962571 6963622 6991528 7005628 > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > * @summary Basic tests of suppressed exceptions > * @author Joseph D. Darcy > */ > @@ -40,6 +40,7 @@ > serializationTest(); > selfReference(); > noModification(); > + initCausePlumbing(); > } > private static void noSelfSuppression() { > @@ -48,7 +49,9 @@ > throwable.addSuppressed(throwable); > throw new RuntimeException("IllegalArgumentException for self-suppresion not thrown."); > } catch (IllegalArgumentException iae) { > - ; // Expected > + // Expected to be here > + if (iae.getCause() != throwable) > + throw new RuntimeException("Bad cause after self-suppresion."); > } > } > @@ -208,4 +211,29 @@ > super("The medium.", null, enableSuppression, true); > } > } > + > + private static void initCausePlumbing() { > + Throwable t1 = new Throwable(); > + Throwable t2 = new Throwable("message", t1); > + Throwable t3 = new Throwable(); > + > + try { > + t2.initCause(t3); > + throw new RuntimeException("Shouldn't reach."); > + } catch (IllegalStateException ise) { > + if (ise.getCause() != t2) > + throw new RuntimeException("Unexpected cause in ISE", ise); > + Throwable[] suppressed = ise.getSuppressed(); > + if (suppressed.length != 1 || suppressed[0] != t3) > + throw new RuntimeException("Bad suppression in ISE", ise); > + } > + > + try { > + t3.initCause(t3); > + throw new RuntimeException("Shouldn't reach."); > + } catch (IllegalArgumentException iae) { > + if (iae.getCause() != t3) > + throw new RuntimeException("Unexpected cause in ISE", iae); > + } > + } > } From david.holmes at oracle.com Mon Apr 15 02:56:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Apr 2013 12:56:42 +1000 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <51685B97.5010507@oracle.com> References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> <51685B97.5010507@oracle.com> Message-ID: <516B6C6A.7050608@oracle.com> On 13/04/2013 5:08 AM, Joe Darcy wrote: > On 04/12/2013 11:22 AM, Jason Mehrens wrote: >> The landmines are the retrofitted exception classes as shown here >> https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and >> https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE >> is thrown it is going to suppress 'this' and 'cause'. It would be >> nice to see the given 'cause' show up in a log file when tracking down >> this type of bug. > > Okay; fair enough. Updated webrev covering initCause too at > > http://cr.openjdk.java.net/~darcy/8012044.1/ > > New patch below. > > (It is a bit of stretch to have this in initiCause by listed as the > "cause" of the IllegalStateException; as an alternative, the > IllegalStateException could have both this and the cause as suppressed > exceptions.) I don't think that is valid for initCause. If I call initCause twice in succession there need not even be any exception propagation in progress. The ISE that gets thrown is not suppressing anything. For setSuppressed this might make sense for the compiler generated sequences, but again if I just called setSuppressed with an invalid value, the ISE is not suppressing any existing exception. David ----- > Cheers, > > -Joe > > --- old/src/share/classes/java/lang/Throwable.java 2013-04-12 > 12:03:48.000000000 -0700 > +++ new/src/share/classes/java/lang/Throwable.java 2013-04-12 > 12:03:48.000000000 -0700 > @@ -452,10 +452,14 @@ > * @since 1.4 > */ > public synchronized Throwable initCause(Throwable cause) { > - if (this.cause != this) > - throw new IllegalStateException("Can't overwrite cause"); > + if (this.cause != this) { > + IllegalStateException ise = > + new IllegalStateException("Can't overwrite cause", this); > + ise.addSuppressed(cause); > + throw ise; > + } > if (cause == this) > - throw new IllegalArgumentException("Self-causation not > permitted"); > + throw new IllegalArgumentException("Self-causation not > permitted", this); > this.cause = cause; > return this; > } > @@ -1039,7 +1043,7 @@ > */ > public final synchronized void addSuppressed(Throwable exception) { > if (exception == this) > - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); > + throw new > IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); > > if (exception == null) > throw new NullPointerException(NULL_CAUSE_MESSAGE); > --- old/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 > 12:03:49.000000000 -0700 > +++ new/test/java/lang/Throwable/SuppressedExceptions.java 2013-04-12 > 12:03:48.000000000 -0700 > @@ -26,7 +26,7 @@ > > /* > * @test > - * @bug 6911258 6962571 6963622 6991528 7005628 > + * @bug 6911258 6962571 6963622 6991528 7005628 8012044 > * @summary Basic tests of suppressed exceptions > * @author Joseph D. Darcy > */ > @@ -40,6 +40,7 @@ > serializationTest(); > selfReference(); > noModification(); > + initCausePlumbing(); > } > > private static void noSelfSuppression() { > @@ -48,7 +49,9 @@ > throwable.addSuppressed(throwable); > throw new RuntimeException("IllegalArgumentException for > self-suppresion not thrown."); > } catch (IllegalArgumentException iae) { > - ; // Expected > + // Expected to be here > + if (iae.getCause() != throwable) > + throw new RuntimeException("Bad cause after > self-suppresion."); > } > } > > @@ -208,4 +211,29 @@ > super("The medium.", null, enableSuppression, true); > } > } > + > + private static void initCausePlumbing() { > + Throwable t1 = new Throwable(); > + Throwable t2 = new Throwable("message", t1); > + Throwable t3 = new Throwable(); > + > + try { > + t2.initCause(t3); > + throw new RuntimeException("Shouldn't reach."); > + } catch (IllegalStateException ise) { > + if (ise.getCause() != t2) > + throw new RuntimeException("Unexpected cause in ISE", > ise); > + Throwable[] suppressed = ise.getSuppressed(); > + if (suppressed.length != 1 || suppressed[0] != t3) > + throw new RuntimeException("Bad suppression in ISE", ise); > + } > + > + try { > + t3.initCause(t3); > + throw new RuntimeException("Shouldn't reach."); > + } catch (IllegalArgumentException iae) { > + if (iae.getCause() != t3) > + throw new RuntimeException("Unexpected cause in ISE", > iae); > + } > + } > } > From david.holmes at oracle.com Mon Apr 15 03:08:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Apr 2013 13:08:51 +1000 Subject: RFR (S) 8009531: Crash when redefining class with annotated method In-Reply-To: <5168483A.9020304@oracle.com> References: <5168483A.9020304@oracle.com> Message-ID: <516B6F43.5020301@oracle.com> Hi Coleen, On 13/04/2013 3:45 AM, Coleen Phillimore wrote: > Summary: Add annotations to the tests to verify bug above > > open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk > > The Hotspot change is in tl repository now. Also, this has been > reviewed by the hotspot group. Is the StressLdcRewrite essential to the test? (Aside: And why is that a product flag ??) Otherwise looks okay. David > Thanks, > Coleen From david.holmes at oracle.com Mon Apr 15 03:29:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Apr 2013 13:29:28 +1000 Subject: RFR (S) 8009531: Crash when redefining class with annotated method In-Reply-To: <516B6F43.5020301@oracle.com> References: <5168483A.9020304@oracle.com> <516B6F43.5020301@oracle.com> Message-ID: <516B7418.9080703@oracle.com> On 15/04/2013 1:08 PM, David Holmes wrote: > Hi Coleen, > > On 13/04/2013 3:45 AM, Coleen Phillimore wrote: >> Summary: Add annotations to the tests to verify bug above >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk >> >> The Hotspot change is in tl repository now. Also, this has been >> reviewed by the hotspot group. > > Is the StressLdcRewrite essential to the test? (Aside: And why is that a > product flag ??) > > Otherwise looks okay. Strike that. I missed what Alan pointed out. You are not actually adding the annotations. So why do we need the printlns? David > David > >> Thanks, >> Coleen From peter.levart at gmail.com Mon Apr 15 07:39:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 15 Apr 2013 09:39:23 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516AF6D6.7000404@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> <516AED69.8020105@gmail.com> <516AF6D6.7000404@gmail.com> Message-ID: <516BAEAB.4000604@gmail.com> Hi Mike, Another thing to note: Some new methods in HashMap need to call inflateTable(), since patch for 8011200 has already been pushed to tl... Regards, Peter On 04/14/2013 08:35 PM, Peter Levart wrote: > > On 04/14/2013 07:54 PM, Peter Levart wrote: >> Hi Mike, >> >> Just a nit: The order of boolean sub-expressions in Map.replace(key, >> oldValue, newValue): >> >> 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) >> >> ...would be more optimal if reversed (like in Map.remove(key, value)). >> >> Regards, Peter > > I think the most optimal is actually this: > > default boolean remove((Object key, Object value) { > Object curValue = get(key); > if (curValue == null && (value != null || !containsKey(key)) || > curValue != value && !curValue.equals(value)) { > return false; > } > remove(key); > return true; > } > > ...and the same for replace(key, oldValue, newValue)... > > Regards, Peter > >> >> On 04/13/2013 12:02 AM, Mike Duigou wrote: >>> I have updated the webrev with these changes and a few more. >>> >>> merge() required an update to it's specification to correctly account for null values. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ >>> >>> This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. >>> >>> Mike >>> >>> On Apr 12 2013, at 12:53 , Mike Duigou wrote: >>> >>>> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >>>> >>>> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> a few small things - >>>>> >>>>> UnmodifiableMap.forEach >>>>> is missing Objects.requireNonNull(action); >>>> Added. >>>> >>>>> EmptyMap.replaceAll(BiFunction) >>>>> should just return instead of throwing UnsupportedOpEx >>>>> particularly since EmptyList.replaceAll also returns silently >>>>> after checking if function is null to fulfil the NPE contract >>>> I agree. >>>> >>>>> Hashtable >>>>> is missing a synchronized override of forEach >>>> added. >>>> >>>>> CheckedMap.typeCheck(BiFunction) >>>>> is missing from the patch (won't compile without it) >>>> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >>>> >>>>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>>>> Another revision incorporating primarily documentation feedback. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>>>> >>>>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>>>> >>>>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>>>> >>>>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>>>> >>>>>>> I've posted an updated webrev with the review comments I have received. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>>>> >>>>>>> One important point to consider: >>>>>>> >>>>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>>>> >>>>>>>> Hello all; >>>>>>>> >>>>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>>>> >>>>>>>> 8004518: Add in-place operations to Map >>>>>>>> forEach() >>>>>>>> replaceAll() >>>>>>>> >>>>>>>> 8010122: Add atomic operations to Map >>>>>>>> getOrDefault() >>>>>>>> putIfAbsent() * >>>>>>>> remove(K, V) >>>>>>>> replace(K, V) >>>>>>>> replace(K, V, V) >>>>>>>> compute() * >>>>>>>> merge() * >>>>>>>> computeIfAbsent() * >>>>>>>> computeIfPresent() * >>>>>>>> >>>>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>>>> >>>>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>>>> >>>>>>>> Mike >> > From huizhe.wang at oracle.com Mon Apr 15 07:48:23 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Apr 2013 00:48:23 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5162B6E3.3090508@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> Message-ID: <516BB0C7.9090107@oracle.com> On 4/8/2013 5:24 AM, Alan Bateman wrote: > On 08/04/2013 08:39, huizhe wang wrote: >> Hi Lance, Alan, >> >> As I mentioned, I'd like to propose an integration of JAXP 1.5 into >> JDK8. JAXP 1.5 adds a new feature to control connections. >> >> Here's the webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ >> >> Thanks, >> Joe > I've done a first pass over the spec/javadoc changes (not the > implementation yet). Thanks. > > Are you planning to add @since to each of the new constants in > XMLConstants? Added. > > For the new properties then it specifies that a "a runtime exception" > will be thrown. Can this be more specific? They can't be in XMLConstants, but they are in the specific Factories. The properties may be supported by factories that may throw different exceptions. > > The URI scheme is specified in terms of the obsolete RFC 2396 whereas > I think it just needs to be a String that is equal (ignoring case) to > the protocol of the connection that is attempting. The reference to RFC 2396 is replaced with a detailed description. > > For jaxp.properties then it reads "and property XXX is specified". I'd > probably change this to "the property". Ok. > > For the existing FEATURE_SECURE_PROCESSING then "accordance with the > letter" is a bit unusual, I would be "the letter" could be dropped. Fixed. > > For each of the factories then it specifies that all implementation > are required to support the new property but this would seem to > invalidate all existing provider implementations. I don't think > providers are versioned so all I can suggest is that this be worded to > make it clear that all implementations that implement JAXP 1.5 or > newer support this property. Ok. > > A small comment is that there seems to have been previous attempts to > keep some of the files at 80 or thereabouts columns. The new javadoc > requires a bit of horizontal scrolling. Corrected. Webrevs updated: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ Thanks, Joe > > -Alan. From erik.joelsson at oracle.com Mon Apr 15 09:03:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Apr 2013 11:03:56 +0200 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516B474B.8090404@oracle.com> References: <516B474B.8090404@oracle.com> Message-ID: <516BC27C.2090909@oracle.com> Hello, It looks to me like you are covering the case of both server and client being true twice. How could line 319 ever evaluate to true? Otherwise it looks ok. /Erik On 2013-04-15 02:18, David Holmes wrote: > Some background. > > The jvm.cfg file, for which there is a per-architecture committed file > in the repository, controls which VM's (client, server, minimal) are > known, which is the default, whether there are other aliases and > whether ergonomic selection is used. > > Historically things were simple: > - 64-bit platforms had server only > - 32-bit platforms had client and server > > then we acknowledged that some platforms may be client only and we > added some support (originally in the old build then converted to the > new build) for dynamically creating a jvm.cfg for the case of building > client only. > > Then the minimal VM was introduced and we potentially have three VMs > to handle. To address this we initially added "-minimal KNOWN" to all > the jvm.cfg files for platforms known to support the minimal VM - this > was done under JDK-7198815 (and those changes are now reversed by this > changeset.) > > The problem after minimal was introduced was that the logic for > "building client only" didn't account for building minimal (only or > combined with client) and we need support for not-building-server. And > that is what this changeset does. > > This only affects 32-bit builds as there is no client nor minimal VM > on 64-bit. The basic operation is as follows: > > - If building client+server then we use the committed jvm.cfg (which > handles ergonomics if applicable), adding a "-minimal KNOWN" line if > minimal is also selected; > - Otherwise we dynamically generate a jvm.cfg for the set of VMs being > built, using these simple rules: > - if client or server are present they are default > - if client and/or server is absent then the absent VM is aliased to > the default VM in that config > - if minimal is not selected then it is absent from the jvm.cfg (we > do not add any aliases for minimal**). > > ** The alias mechanism is useful for deprecating legacy VM names, and > has also made testing more convenient. However I think it is a flawed > mechanism for testing and our internal test infrastructure is moving > away from arbitrarily using -client/-server when actually running > server/client. If you ask for the minimal VM and it is not available I > think you should get an error not silent use of a different VM. (Note: > this selection doesn't affect SE Embedded as it defines jvm.cfg files > using it's own rules/preferences.) > > webrev: > > http://cr.openjdk.java.net/~dholmes/8010280/webrev/ > > Thanks, > David From Alan.Bateman at oracle.com Mon Apr 15 09:22:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Apr 2013 10:22:05 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <516BB0C7.9090107@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> Message-ID: <516BC6BD.1090400@oracle.com> On 15/04/2013 08:48, Joe Wang wrote: > : > >> >> For the new properties then it specifies that a "a runtime exception" >> will be thrown. Can this be more specific? > > They can't be in XMLConstants, but they are in the specific Factories. > The properties may be supported by factories that may throw different > exceptions. I think it would be help if this were expanded to something like "a runtime exception that is specific to the context is thrown" and give an example so that it's clear what it saying. > > Webrevs updated: > http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ This looks much better. For now, I've stayed focused on the javadoc/spec for now as we have to get that right. The wording "\"jar\" plus the scheme portion" suggests it matches "jar" exactly and maybe this could be clearer because this is also case insensitive. @since on the new properties 1.7. I don't know if this should have 1.8 or JAXP 1.5. The intending of the
    and
  • looks a bit odd when the paragraphs aren't indented. This doesn't impact the generated javadoc of course, just looks odd in the source code. Otherwise I think the javadoc looks okay to me. -Alan From bourges.laurent at gmail.com Mon Apr 15 10:01:54 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Mon, 15 Apr 2013 12:01:54 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements In-Reply-To: References: Message-ID: Jim, Andrea, I updated MapBench to provide test statistics (avg, median, stddev, rms, med + stddev, min, max) and CSV output (tab separator): http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/ Here are the results (OpenJDK8 Ref vs Patched): http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 180,22% 181,08% 1186,01% 181,17% 185,92% 176,35% 170,36% boulder_17 2 20 183,15% 183,80% 162,68% 183,78% 183,17% 174,01% 169,89% boulder_17 4 20 216,62% 218,03% 349,31% 218,87% 226,68% 172,15% 167,54% shp_alllayers_47 1 20 243,90% 244,86% 537,92% 244,87% 246,39% 240,64% 231,00% shp_alllayers_47 2 20 286,42% 287,07% 294,87% 287,07% 287,23% 277,19% 272,23% shp_alllayers_47 4 20 303,08% 302,15% 168,19% 301,90% 295,90% 462,70% 282,41% PATCH: test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 110,196 109,244 0,529 109,246 109,773 108,197 129,327 boulder_17 2 40 127,916 127,363 3,899 127,423 131,262 125,262 151,561 boulder_17 4 80 213,085 212,268 14,988 212,796 227,256 155,512 334,407 shp_alllayers_47 1 20 1139,452 1134,858 5,971 1134,873 1140,829 1125,859 1235,746 shp_alllayers_47 2 40 1306,889 1304,598 28,157 1304,902 1332,755 1280,49 1420,351 shp_alllayers_47 4 80 2296,487 2303,81 112,816 2306,57 2416,626 1390,31 2631,455 REF: test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 198,591 197,816 6,274 197,916 204,091 190,805 220,319 boulder_17 2 40 234,272 234,09 6,343 234,176 240,433 217,967 257,485 boulder_17 4 80 461,579 462,8 52,354 465,751 515,153 267,712 560,254 shp_alllayers_47 1 20 2779,133 2778,823 32,119 2779,009 2810,943 2709,285 2854,557 shp_alllayers_47 2 40 3743,255 3745,111 83,027 3746,031 3828,138 3549,364 3866,612 shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698 6432,945 7431,541 Linux 64 server vm JVM: -Xms128m -Xmx128m (low mem) Laurent 2013/4/14 Andrea Aime > On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s > wrote: > >> Dear Java2D members, >> >> Could someone review the following webrev concerning Java2D Pisces to >> enhance its performance and reduce its memory footprint (RendererContext >> stored in thread local or concurrent queue): >> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ >> >> FYI I fixed file headers in this patch and signed my OCA 3 weeks ago. >> >> Remaining work: >> - cleanup (comments ...) >> - statistics to perform auto-tuning >> - cache / memory cleanup (SoftReference ?): use hints or System >> properties to adapt it to use cases >> - another problem: fix clipping performance in Dasher / Stroker for >> segments out of bounds >> >> Could somebody support me ? ie help me working on these tasks or just to >> discuss on Pisces algorithm / implementation ? >> > > Hi, > I would like to express my support for this patch. > Given that micro-benchmarks have already been run, I took the patch for a > spin in a large, real world benchmark instead, > the OSGeo WMS Shootout 2010 benchmark, for which you can see the results > here: > > http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010 > > The presentation is long, but suffice it to say all Java based > implementations took quite the beating due to the > poor scalability of Ductus with antialiased rendering of vector data (for > an executive summary just look > at slide 27 and slide 66, where GeoServer, Oracle MapViewer and > Constellation SDI were the > Java based ones) > > I took the same tests and run them again on my machine (different hardware > than the tests, don't try to compare > the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a > couple of weeks old) and the > same, but with Laurent's patches applied. > Here are the results, throughput (in maps generated per second) with the > load generator (JMeter) going > up from one client to 64 concurrent clients: > > *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces > renderer improvements* *Pisces renderer performance gain, %* 1 13,97 > 12,43 13,03 4,75% 2 22,08 20,60 20,77 0,81% 4 34,36 33,15 33,36 0,62% 8 > 39,39 40,51 41,71 2,96% 16 40,61 44,57 46,98 5,39% 32 41,41 44,73 48,16 > 7,66% 64 37,09 42,19 45,28 7,32% > > Well, first of all, congratulations to the JDK developers, don't know what > changed in JDK 8, but > GeoServer seems to like it quite a bit :-). > That said, Laurent's patch also gives a visible boost, especially when > several concurrent clients are > asking for the maps. > > Mind, as I said, this is no micro-benchmark, it is a real application > loading doing a lot of I/O > (from the operating system file cache), other processing before the data > reaches the rendering > pipeline, and then has to PNG encode the output BufferedImage (PNG > encoding being rather > expensive), so getting this speedup from just a change in the rendering > pipeline is significant. > > Long story short... personally I'd be very happy if this patch was going > to be integrated in Java 8 :-) > > Cheers > Andrea > > -- > == > GeoServer training in Milan, 6th & 7th June 2013! Visit > http://geoserver.geo-solutions.it for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > From david.holmes at oracle.com Mon Apr 15 11:22:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Apr 2013 21:22:00 +1000 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516BC27C.2090909@oracle.com> References: <516B474B.8090404@oracle.com> <516BC27C.2090909@oracle.com> Message-ID: <516BE2D8.2070105@oracle.com> On 15/04/2013 7:03 PM, Erik Joelsson wrote: > Hello, > > It looks to me like you are covering the case of both server and client > being true twice. How could line 319 ever evaluate to true? Otherwise it > looks ok. You are right - that was a leftover from an initial approach that only looked for client+server but excluded client+server+minimal. Back to the drawing board. Thanks, David > /Erik > > On 2013-04-15 02:18, David Holmes wrote: >> Some background. >> >> The jvm.cfg file, for which there is a per-architecture committed file >> in the repository, controls which VM's (client, server, minimal) are >> known, which is the default, whether there are other aliases and >> whether ergonomic selection is used. >> >> Historically things were simple: >> - 64-bit platforms had server only >> - 32-bit platforms had client and server >> >> then we acknowledged that some platforms may be client only and we >> added some support (originally in the old build then converted to the >> new build) for dynamically creating a jvm.cfg for the case of building >> client only. >> >> Then the minimal VM was introduced and we potentially have three VMs >> to handle. To address this we initially added "-minimal KNOWN" to all >> the jvm.cfg files for platforms known to support the minimal VM - this >> was done under JDK-7198815 (and those changes are now reversed by this >> changeset.) >> >> The problem after minimal was introduced was that the logic for >> "building client only" didn't account for building minimal (only or >> combined with client) and we need support for not-building-server. And >> that is what this changeset does. >> >> This only affects 32-bit builds as there is no client nor minimal VM >> on 64-bit. The basic operation is as follows: >> >> - If building client+server then we use the committed jvm.cfg (which >> handles ergonomics if applicable), adding a "-minimal KNOWN" line if >> minimal is also selected; >> - Otherwise we dynamically generate a jvm.cfg for the set of VMs being >> built, using these simple rules: >> - if client or server are present they are default >> - if client and/or server is absent then the absent VM is aliased to >> the default VM in that config >> - if minimal is not selected then it is absent from the jvm.cfg (we >> do not add any aliases for minimal**). >> >> ** The alias mechanism is useful for deprecating legacy VM names, and >> has also made testing more convenient. However I think it is a flawed >> mechanism for testing and our internal test infrastructure is moving >> away from arbitrarily using -client/-server when actually running >> server/client. If you ask for the minimal VM and it is not available I >> think you should get an error not silent use of a different VM. (Note: >> this selection doesn't affect SE Embedded as it defines jvm.cfg files >> using it's own rules/preferences.) >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8010280/webrev/ >> >> Thanks, >> David From jason_mehrens at hotmail.com Mon Apr 15 12:04:59 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 15 Apr 2013 07:04:59 -0500 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <516B6C6A.7050608@oracle.com> References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> <51685B97.5010507@oracle.com>,<516B6C6A.7050608@oracle.com> Message-ID: David, The last two paragraphs of Throwable.addSuppressed cover this. The first is your argument bellow and does not forbid anything it claims. The last paragraph explicitly enables this patch. Jason > Date: Mon, 15 Apr 2013 12:56:42 +1000 > From: david.holmes at oracle.com > To: joe.darcy at oracle.com > CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net > Subject: Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed > > On 13/04/2013 5:08 AM, Joe Darcy wrote: > > On 04/12/2013 11:22 AM, Jason Mehrens wrote: > >> The landmines are the retrofitted exception classes as shown here > >> https://netbeans.org/bugzilla/show_bug.cgi?id=150969 and > >> https://issues.jboss.org/browse/JBREM-552. Really, if the ISE or IAE > >> is thrown it is going to suppress 'this' and 'cause'. It would be > >> nice to see the given 'cause' show up in a log file when tracking down > >> this type of bug. > > > > Okay; fair enough. Updated webrev covering initCause too at > > > > http://cr.openjdk.java.net/~darcy/8012044.1/ > > > > New patch below. > > > > (It is a bit of stretch to have this in initiCause by listed as the > > "cause" of the IllegalStateException; as an alternative, the > > IllegalStateException could have both this and the cause as suppressed > > exceptions.) > > I don't think that is valid for initCause. If I call initCause twice in > succession there need not even be any exception propagation in progress. > The ISE that gets thrown is not suppressing anything. > > For setSuppressed this might make sense for the compiler generated > sequences, but again if I just called setSuppressed with an invalid > value, the ISE is not suppressing any existing exception. > > David From maurizio.cimadamore at oracle.com Mon Apr 15 13:20:52 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Apr 2013 13:20:52 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130415132111.D8504482EC@hg.openjdk.java.net> Changeset: b26f36a7ae3b Author: mcimadamore Date: 2013-04-15 14:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b26f36a7ae3b 8011383: Symbol.getModifiers omits ACC_ABSTRACT from interface with default methods Summary: Fixup for default method modifiers erroneously applies to class-level modifiers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/defaultMethods/DefaultMethodFlags.java Changeset: c430f1cde21c Author: mcimadamore Date: 2013-04-15 14:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c430f1cde21c 8011377: Javac crashes when multiple lambdas are defined in an array Summary: Wrong attribution environment used by DeferredAttr Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/lambda/TargetType71.java Changeset: 083c6b199e2f Author: mcimadamore Date: 2013-04-15 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/083c6b199e2f 8011376: Spurious checked exception errors in nested method call Summary: Fallback attribution logic doesn't work properly when lambda throws checked exceptions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/TargetType72.java Changeset: 6dacab087652 Author: mcimadamore Date: 2013-04-15 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6dacab087652 8011028: lang/INFR/infr001/infr00101md/infr00101md.java fails to compile after switch to JDK8-b82 Summary: Fix bug in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/lambda/TargetType69.java + test/tools/javac/lambda/TargetType70.java Changeset: c2315af9cc28 Author: mcimadamore Date: 2013-04-15 14:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c2315af9cc28 8011392: Missing checkcast when casting to intersection type Summary: javac should emit a checkcast for each additional target type specified in an intersection type cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/lambda/Intersection03.java Changeset: 950e8ac120f0 Author: mcimadamore Date: 2013-04-15 14:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/950e8ac120f0 8010923: Avoid redundant speculative attribution Summary: Add optimization to avoid speculative attribution for certain argument expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java From sundararajan.athijegannathan at oracle.com Mon Apr 15 13:46:14 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 15 Apr 2013 13:46:14 +0000 Subject: hg: jdk8/tl/nashorn: 9 new changesets Message-ID: <20130415134620.D3D9A482ED@hg.openjdk.java.net> Changeset: 635a93b61d34 Author: hannesw Date: 2013-04-10 14:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/635a93b61d34 8011714: Regexp decimal escape handling still not correct Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8011714.js + test/script/basic/JDK-8011714.js.EXPECTED Changeset: b4ea8678bf15 Author: hannesw Date: 2013-04-10 14:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b4ea8678bf15 8011749: Bugs with empty character class handling Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8011749.js + test/script/basic/JDK-8011749.js.EXPECTED Changeset: 8ae9ed1ac1e2 Author: hannesw Date: 2013-04-10 14:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8ae9ed1ac1e2 8011756: Wrong characters supported in RegExp \c escape Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8011756.js + test/script/basic/JDK-8011756.js.EXPECTED Changeset: 571e06d5d23c Author: sundar Date: 2013-04-11 13:20 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/571e06d5d23c 8011960: [2,1].sort(null) should throw TypeError Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8011960.js Changeset: 256bb030ce0a Author: sundar Date: 2013-04-11 15:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/256bb030ce0a 8011974: Comparator function returning negative and positive Infinity does not work as expected with Array.prototype.sort Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8011974.js Changeset: a3fc89d33072 Author: hannesw Date: 2013-04-11 12:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a3fc89d33072 8011980: Allow NUL character in character class Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8011980.js + test/script/basic/JDK-8011980.js.EXPECTED Changeset: ed4293ceec0e Author: hannesw Date: 2013-04-12 16:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ed4293ceec0e 8011884: Regexp literals are compiled twice Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java Changeset: 36e36a2d4312 Author: hannesw Date: 2013-04-12 16:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/36e36a2d4312 8011885: Switch to Joni as default Regexp engine Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java Changeset: e70e6b38826b Author: jlaskey Date: 2013-04-15 08:39 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e70e6b38826b Merge From chris.hegarty at oracle.com Mon Apr 15 14:09:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Apr 2013 15:09:05 +0100 Subject: 8012237: CompletableFuture/Basic.java still fails intermittently Message-ID: <516C0A01.40106@oracle.com> I missed three cases in the previous change [1]. That will teach me for working on the weekend ;-) A full audit of the use of the XxxEitherXxx methods in the test has been done, and there are still three particular checks that are possibly incorrect. The failure is not always seen as this is racy code. http://cr.openjdk.java.net/~chegar/8012237/webrev.00/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html Thanks, -Chris. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016013.html From daniel.fuchs at oracle.com Mon Apr 15 14:09:24 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Apr 2013 16:09:24 +0200 Subject: RFR: JDK-8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <516C0A14.1080408@oracle.com> Hi, This a fix for: JDK-8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently. The issue here is that com.sun.org.apache.xml.internal.serializer.Encodings tries to implement a double mapping: Java Charset Name => Preferred XML Mime Name and XML Mime Name => Java Charset Name from a specification that it reads from an Encoding.properties file. However, there can be several 'Java' names (aliases) corresponding to a given Charset, and there could also be several XML Mime Names, corresponding to that same charset. The Encodings.properties files uses 'Java Names' as keys, which it can map to one - or more - XML mime names, where the first XML name in the list stands for the 'preferred' mime name. The trouble is that some of the Java names present in the Encodings.properties files are not recognized by the Charset API, although some of the corresponding XML mime names, can be. This resulted in the creation of EncodingInfo objects whose charset name was not recognized by the Charset API. However, since there can be several Java Names specified with the same XML name, this did not always lead to errors: when 'converting' an XML name to a Java Name, if the first mapping picked up had a recognized Java Name - everything went well. If however - the first mapping picked up had an unrecognized Java Name, then this lead to failure to encode characters properly. Since the order in which the EncodingInfo where registered depended on the order of keys/values returned by HashMap/Properties - it could work in one run and fail in another. The proposed changeset is reworking the algorithm that creates EncodingInfo objects and perform the mapping Java Name <-> Mime Name: * Parse the whole line and consider both Java Names & Mime Names when trying to instantiate EncodingInfo objects for a Java Name, * Make sure the javaName recorded in EncodingInfo is one that is recognized by Charset.forName(). The changeset has a unit test (under jdk/test/javax/xml/jaxp) which 1. verifies that the Encodings.properties file has no inconsistencies 2. verifies the mapping implemented by Encodings.java - by calling Encodings.convertMime2JavaEncoding() and Encodings.getMimeEncoding() (skipping those names for which no charset could be loaded, as not all charset are necessarily available on all machines). -- daniel From pbenedict at apache.org Mon Apr 15 15:18:49 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 15 Apr 2013 10:18:49 -0500 Subject: Suggestion to improve profile/package in javadoc Message-ID: I was looking at b85 javadocs, and saw this at the page's top for a class: compact1, compact2, compact3 java.lang I don't think it's clear what is being shown. I understand it -- but I am following the feature closely. I recommend prefixing the data because the package is no longer the sole item: Profiles: compact1, compact2, compact3 Package: java.lang Paul From mike.duigou at oracle.com Mon Apr 15 16:25:24 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 09:25:24 -0700 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516B474B.8090404@oracle.com> References: <516B474B.8090404@oracle.com> Message-ID: Hi David; I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped to see the "classic" and "green" flags go away and some of the other legacy flags like "-hotspot" reduced to WARN. What's the difference between removing an entry completely and retaining it with "ERROR"? Additionally I don't like that aliases have differing definitions and some confusing ones like "-server ALIASED_TO -client". Is this necessary or just historically convenient? Mike On Apr 14 2013, at 17:18 , David Holmes wrote: > Some background. > > The jvm.cfg file, for which there is a per-architecture committed file in the repository, controls which VM's (client, server, minimal) are known, which is the default, whether there are other aliases and whether ergonomic selection is used. > > Historically things were simple: > - 64-bit platforms had server only > - 32-bit platforms had client and server > > then we acknowledged that some platforms may be client only and we added some support (originally in the old build then converted to the new build) for dynamically creating a jvm.cfg for the case of building client only. > > Then the minimal VM was introduced and we potentially have three VMs to handle. To address this we initially added "-minimal KNOWN" to all the jvm.cfg files for platforms known to support the minimal VM - this was done under JDK-7198815 (and those changes are now reversed by this changeset.) > > The problem after minimal was introduced was that the logic for "building client only" didn't account for building minimal (only or combined with client) and we need support for not-building-server. And that is what this changeset does. > > This only affects 32-bit builds as there is no client nor minimal VM on 64-bit. The basic operation is as follows: > > - If building client+server then we use the committed jvm.cfg (which handles ergonomics if applicable), adding a "-minimal KNOWN" line if minimal is also selected; > - Otherwise we dynamically generate a jvm.cfg for the set of VMs being built, using these simple rules: > - if client or server are present they are default > - if client and/or server is absent then the absent VM is aliased to the default VM in that config > - if minimal is not selected then it is absent from the jvm.cfg (we do not add any aliases for minimal**). > > ** The alias mechanism is useful for deprecating legacy VM names, and has also made testing more convenient. However I think it is a flawed mechanism for testing and our internal test infrastructure is moving away from arbitrarily using -client/-server when actually running server/client. If you ask for the minimal VM and it is not available I think you should get an error not silent use of a different VM. (Note: this selection doesn't affect SE Embedded as it defines jvm.cfg files using it's own rules/preferences.) > > webrev: > > http://cr.openjdk.java.net/~dholmes/8010280/webrev/ > > Thanks, > David From martinrb at google.com Mon Apr 15 16:32:59 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 09:32:59 -0700 Subject: 8012237: CompletableFuture/Basic.java still fails intermittently In-Reply-To: <516C0A01.40106@oracle.com> References: <516C0A01.40106@oracle.com> Message-ID: This looks good, in that it fixes the flakiness. I don't think we have tests yet that ensure Either completion when only one task completes. Consider writing one normal async supplier and one that waits on a latch; ensure that the Either future completes with the normal value, then trip the latch to allow the second one to finish. On Mon, Apr 15, 2013 at 7:09 AM, Chris Hegarty wrote: > I missed three cases in the previous change [1]. That will teach me for > working on the weekend ;-) > > A full audit of the use of the XxxEitherXxx methods in the test has been > done, and there are still three particular checks that are possibly > incorrect. The failure is not always seen as this is racy code. > > http://cr.openjdk.java.net/~**chegar/8012237/webrev.00/** > webrev/test/java/util/**concurrent/CompletableFuture/** > Basic.java.udiff.html > > Thanks, > -Chris. > > [1] http://mail.openjdk.java.net/**pipermail/core-libs-dev/2013-** > April/016013.html > From tom.hawtin at oracle.com Mon Apr 15 16:34:23 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 15 Apr 2013 17:34:23 +0100 Subject: JEP 180: Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <20130405180824.036DC1733@eggemoggin.niobe.net> References: <20130405180824.036DC1733@eggemoggin.niobe.net> Message-ID: <516C2C0F.8060308@oracle.com> On 05/04/2013 19:08, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/180 If you're using WeakHashMap with types that (may) override equals/hashCode you have bigger problems. You almost certainly want "identity" semantics (violating the java.util.Map contract) and quite possibly concurrency. Tom From chris.hegarty at oracle.com Mon Apr 15 17:03:24 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Apr 2013 18:03:24 +0100 Subject: 8012237: CompletableFuture/Basic.java still fails intermittently In-Reply-To: References: <516C0A01.40106@oracle.com> Message-ID: <516C32DC.4020309@oracle.com> On 15/04/2013 17:32, Martin Buchholz wrote: > This looks good, in that it fixes the flakiness. Thanks Martin. > I don't think we have tests yet that ensure Either completion when only > one task completes. > Consider writing one normal async supplier and one that waits on a > latch; ensure that the Either future completes with the normal value, > then trip the latch to allow the second one to finish. Great idea. Here you go: http://cr.openjdk.java.net/~chegar/8012237/webrev.01/webrev/test/java/util/concurrent/CompletableFuture/Basic.java.udiff.html -Chris. > > > On Mon, Apr 15, 2013 at 7:09 AM, Chris Hegarty > wrote: > > I missed three cases in the previous change [1]. That will teach me > for working on the weekend ;-) > > A full audit of the use of the XxxEitherXxx methods in the test has > been done, and there are still three particular checks that are > possibly incorrect. The failure is not always seen as this is racy code. > > http://cr.openjdk.java.net/~__chegar/8012237/webrev.00/__webrev/test/java/util/__concurrent/CompletableFuture/__Basic.java.udiff.html > > > Thanks, > -Chris. > > [1] > http://mail.openjdk.java.net/__pipermail/core-libs-dev/2013-__April/016013.html > > > From martinrb at google.com Mon Apr 15 17:32:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 10:32:45 -0700 Subject: 8012237: CompletableFuture/Basic.java still fails intermittently In-Reply-To: <516C32DC.4020309@oracle.com> References: <516C0A01.40106@oracle.com> <516C32DC.4020309@oracle.com> Message-ID: Thanks. This looks good. I might additionally: - rename "phaser" to something more evocative, like "cf3Done" - add a checkCompletedXXX for the tardy future after the phaser arrives - check that cf3 result does not change when tardy future completes. On Mon, Apr 15, 2013 at 10:03 AM, Chris Hegarty wrote: > On 15/04/2013 17:32, Martin Buchholz wrote: > >> This looks good, in that it fixes the flakiness. >> > > Thanks Martin. > > > I don't think we have tests yet that ensure Either completion when only >> one task completes. >> Consider writing one normal async supplier and one that waits on a >> latch; ensure that the Either future completes with the normal value, >> then trip the latch to allow the second one to finish. >> > > Great idea. Here you go: > > http://cr.openjdk.java.net/~**chegar/8012237/webrev.01/** > webrev/test/java/util/**concurrent/CompletableFuture/** > Basic.java.udiff.html > > -Chris. > > >> >> On Mon, Apr 15, 2013 at 7:09 AM, Chris Hegarty > >> wrote: >> >> I missed three cases in the previous change [1]. That will teach me >> for working on the weekend ;-) >> >> A full audit of the use of the XxxEitherXxx methods in the test has >> been done, and there are still three particular checks that are >> possibly incorrect. The failure is not always seen as this is racy >> code. >> >> http://cr.openjdk.java.net/~__**chegar/8012237/webrev.00/__** >> webrev/test/java/util/__**concurrent/CompletableFuture/_** >> _Basic.java.udiff.html >> >> > webrev/test/java/util/**concurrent/CompletableFuture/** >> Basic.java.udiff.html >> > >> >> Thanks, >> -Chris. >> >> [1] >> http://mail.openjdk.java.net/_**_pipermail/core-libs-dev/2013-** >> __April/016013.html >> > April/016013.html >> > >> >> >> From chris.hegarty at oracle.com Mon Apr 15 17:41:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Apr 2013 18:41:35 +0100 Subject: 8012237: CompletableFuture/Basic.java still fails intermittently In-Reply-To: References: <516C0A01.40106@oracle.com> <516C32DC.4020309@oracle.com> Message-ID: <516C3BCF.8040803@oracle.com> On 15/04/2013 18:32, Martin Buchholz wrote: > Thanks. This looks good. > > I might additionally: > - rename "phaser" to something more evocative, like "cf3Done" > - add a checkCompletedXXX for the tardy future after the phaser arrives > - check that cf3 result does not change when tardy future completes. Thanks Martin, I'll make these changes before the pushing. -Chris. > > > On Mon, Apr 15, 2013 at 10:03 AM, Chris Hegarty > > wrote: > > On 15/04/2013 17:32, Martin Buchholz wrote: > > This looks good, in that it fixes the flakiness. > > > Thanks Martin. > > > I don't think we have tests yet that ensure Either completion > when only > one task completes. > Consider writing one normal async supplier and one that waits on a > latch; ensure that the Either future completes with the normal > value, > then trip the latch to allow the second one to finish. > > > Great idea. Here you go: > > http://cr.openjdk.java.net/~__chegar/8012237/webrev.01/__webrev/test/java/util/__concurrent/CompletableFuture/__Basic.java.udiff.html > > > -Chris. > > > > On Mon, Apr 15, 2013 at 7:09 AM, Chris Hegarty > > >> wrote: > > I missed three cases in the previous change [1]. That will > teach me > for working on the weekend ;-) > > A full audit of the use of the XxxEitherXxx methods in the > test has > been done, and there are still three particular checks that are > possibly incorrect. The failure is not always seen as this > is racy code. > > http://cr.openjdk.java.net/~____chegar/8012237/webrev.00/____webrev/test/java/util/____concurrent/CompletableFuture/____Basic.java.udiff.html > > > > > > Thanks, > -Chris. > > [1] > http://mail.openjdk.java.net/____pipermail/core-libs-dev/2013-____April/016013.html > > > > > > From Alan.Bateman at oracle.com Mon Apr 15 17:46:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Apr 2013 18:46:30 +0100 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51682220.6010009@oracle.com> References: <51673A45.8060908@oracle.com> <51682220.6010009@oracle.com> Message-ID: <516C3CF6.6090502@oracle.com> On 12/04/2013 16:02, Alan Bateman wrote: > On 11/04/2013 23:33, Jim Gish wrote: >> Please review >> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ >> >> >> These are changes that we made in lambda that we're now bringing into >> JDK8. >> >> I've made a couple of additions - making StringJoiner final and >> adding a couple of constructors to set the emptyOutput chars. >> >> Thanks, >> Jim >> > : > > I plan to look at StringJoiner in more detail later. > Just to follow up with a few comments on StringJoiner. I don't know how "final" this is but I wonder if you've already experimented (and rejected) having a smaller set of constructors? I will guess that the most popular usage will be the simple 1-arg constructor to just specify the delimiter. There will likely be some cases where you want a prefix and suffix too. I bring this up because it seems a bit inconsistent to just have a setter for the default result when one could as easily have a method to set the prefix/suffix too. Clearly it would complicate the implementation a bit but it could be optimized for the case that these are set before any elements are added. Anyway, I'm not trying to re-open discussions on this, just trying to understand if what you are proposing is already close to final. On method names then "setEmptyOutput" doesn't seem quite right, I wonder if you've considered others, like setEmptyValue or setDefaultResult. Minor nits: - The javadoc for "add" starts with "add the supplied", should be "Add". - The @param in the 1-arg constructor is indented inconsistently to the other methods - The this(...) usage in the 3-arg constructor has spaces around it so it is inconsistent with the other usages. - In the class description it reads "Prior to adding something to the StringJoiner, {@code sj.toString()} will, by default, return {@code prefix+suffix}". This might be better as "Prior to adding elements to a StringJoiner, its toString() method, if invoked, will ...". - The comma in "For example," set expectations that there will be more text after the example but this isn't so. - As with the comments on String.join then I assume the test should have 1 bug number (not 3). Also to be consistent with the existing organization it would be better to move it down to test/java/util/StringJoiner (I know we have to come up with a solution for tests with package names). - The test has two @summary lines, I assume this is a mistake. - In terms of code coverage then it looks like the only method that is tested for NPE is setEmptyOutput. That's all I have. -Alan From martinrb at google.com Mon Apr 15 18:02:20 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 11:02:20 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51673A45.8060908@oracle.com> References: <51673A45.8060908@oracle.com> Message-ID: You are fiddling with the javadoc for getChars, which is an independent change. (I am also fiddling with getChars in another ongoing change). I don't think closing html tags for
  • are required in javadoc. If you are going to change the exception javadoc, then also change @exception to @throws. On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-** > 7172553/ < > http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/ > > > > These are changes that we made in lambda that we're now bringing into JDK8. > > I've made a couple of additions - making StringJoiner final and adding a > couple of constructors to set the emptyOutput chars. > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > From Alan.Bateman at oracle.com Mon Apr 15 18:13:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Apr 2013 19:13:18 +0100 Subject: Review request: 8004260: dynamic proxy class should have same class access as proxy interfaces In-Reply-To: <51685442.9090404@oracle.com> References: <51685442.9090404@oracle.com> Message-ID: <516C433E.1000405@oracle.com> On 12/04/2013 19:36, Mandy Chung wrote: > Dynamic proxy class is specified to be public, final, and not > abstract. For a proxy class that implements a non-public interface, > it will be in the same package as the non-public interface > but the proxy class is accessible outside of the non-public > interface's runtime package. This change will make dynamic proxy > class to have the same Java language access as the proxy interfaces > so that creating a proxy instance to implement a non-public interface > will be guarded by the Java language access check. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8004260/webrev.00/ > > Specdiff at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8004260/specdiff/overview-summary.html > > > This change also updates the spec to specify the permission checks > by Proxy.getProxyClass and Proxy.newProxyInstance methods and removes > the system properties which provide a workaround for 7u releases and > not needed in jdk8. > > Thanks > Mandy I went through the webrev and it looks good to me and good to get this aligned and specified clearly. A minor comment is that in the save for debugging code in generateProxyClass then you could use Files.write to write the class file in one method if you want. -Alan. From martinrb at google.com Mon Apr 15 18:14:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 11:14:14 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51673A45.8060908@oracle.com> References: <51673A45.8060908@oracle.com> Message-ID: Is "i+1" really preferred to "i + 1" ? I thought it was the reverse, and that "i+1" was merely tolerated. 1570 if (value[i] == hi && value[i+1] == lo) { --- 2425 * @throws NullPointerException If {@code delimiter} is {@code null} you also throw NPE for element null, but you didn't specify that. * * *---* On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-** > 7172553/ < > http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/ > > > > These are changes that we made in lambda that we're now bringing into JDK8. > > I've made a couple of additions - making StringJoiner final and adding a > couple of constructors to set the emptyOutput chars. > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > From martinrb at google.com Mon Apr 15 18:31:00 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 11:31:00 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51673A45.8060908@oracle.com> References: <51673A45.8060908@oracle.com> Message-ID: It is natural to compare StringJoiner with guava Joiner. http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Joiner.html Joiner is popular and has stood the test of time. Joiner designers chose not to include a prefix and suffix, presumably because that is an independent concern - it's not a "joining" activity. OTOH, I'm guessing you are trying to improve the performance of operations like List.toString. More efficient (single copy char[]) would be to collect all the sub-CharSequences in a CharSequence[], pre-compute the final length of the char[], allocate an array of exactly the required length, and create the final string directly from that using the package-private constructor (but in the unlikely event that a subsequence changed in size while concat'ing, be prepared to resize the array). On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-** > 7172553/ < > http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/ > > > > These are changes that we made in lambda that we're now bringing into JDK8. > > I've made a couple of additions - making StringJoiner final and adding a > couple of constructors to set the emptyOutput chars. > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > From mike.duigou at oracle.com Mon Apr 15 18:44:30 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 11:44:30 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516BAEAB.4000604@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> <516AED69.8020105@gmail.com> <516AF6D6.7000404@gmail.com> <516BAEAB.4000604@gmail.com> Message-ID: <89A2295D-5000-4CE9-9AED-CF0643E3E608@oracle.com> On Apr 15 2013, at 00:39 , Peter Levart wrote: > Hi Mike, > > Another thing to note: Some new methods in HashMap need to call inflateTable(), since patch for 8011200 has already been pushed to tl... Yes. I actually had an off-to-the-side patch which added these and tested with it last week. The missing checks are now in lambda repo and part of the 8010122 patch. Thanks. Mike > > Regards, Peter > > On 04/14/2013 08:35 PM, Peter Levart wrote: >> >> On 04/14/2013 07:54 PM, Peter Levart wrote: >>> Hi Mike, >>> >>> Just a nit: The order of boolean sub-expressions in Map.replace(key, oldValue, newValue): >>> >>> 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) >>> >>> ...would be more optimal if reversed (like in Map.remove(key, value)). >>> >>> Regards, Peter >> >> I think the most optimal is actually this: >> >> default boolean remove((Object key, Object value) { >> Object curValue = get(key); >> if (curValue == null && (value != null || !containsKey(key)) || >> curValue != value && !curValue.equals(value)) { >> return false; >> } >> remove(key); >> return true; >> } >> >> ...and the same for replace(key, oldValue, newValue)... >> >> Regards, Peter >> >>> >>> On 04/13/2013 12:02 AM, Mike Duigou wrote: >>>> I have updated the webrev with these changes and a few more. >>>> >>>> merge() required an update to it's specification to correctly account for null values. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ >>>> >>>> This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. >>>> >>>> Mike >>>> >>>> On Apr 12 2013, at 12:53 , Mike Duigou wrote: >>>> >>>>> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >>>>> >>>>> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> a few small things - >>>>>> >>>>>> UnmodifiableMap.forEach >>>>>> is missing Objects.requireNonNull(action); >>>>> Added. >>>>> >>>>>> EmptyMap.replaceAll(BiFunction) >>>>>> should just return instead of throwing UnsupportedOpEx >>>>>> particularly since EmptyList.replaceAll also returns silently >>>>>> after checking if function is null to fulfil the NPE contract >>>>> I agree. >>>>> >>>>>> Hashtable >>>>>> is missing a synchronized override of forEach >>>>> added. >>>>> >>>>>> CheckedMap.typeCheck(BiFunction) >>>>>> is missing from the patch (won't compile without it) >>>>> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >>>>> >>>>>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>>>>> Another revision incorporating primarily documentation feedback. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>>>>> >>>>>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>>>>> >>>>>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>>>>> >>>>>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>>>>> >>>>>>>> I've posted an updated webrev with the review comments I have received. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>>>>> >>>>>>>> One important point to consider: >>>>>>>> >>>>>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>>>>> >>>>>>>>> Hello all; >>>>>>>>> >>>>>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>>>>> >>>>>>>>> 8004518: Add in-place operations to Map >>>>>>>>> forEach() >>>>>>>>> replaceAll() >>>>>>>>> >>>>>>>>> 8010122: Add atomic operations to Map >>>>>>>>> getOrDefault() >>>>>>>>> putIfAbsent() * >>>>>>>>> remove(K, V) >>>>>>>>> replace(K, V) >>>>>>>>> replace(K, V, V) >>>>>>>>> compute() * >>>>>>>>> merge() * >>>>>>>>> computeIfAbsent() * >>>>>>>>> computeIfPresent() * >>>>>>>>> >>>>>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>>>>> >>>>>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>>>>> >>>>>>>>> Mike >>> >> > From mandy.chung at oracle.com Mon Apr 15 18:57:39 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Apr 2013 11:57:39 -0700 Subject: Review request: 8004260: dynamic proxy class should have same class access as proxy interfaces In-Reply-To: <516C433E.1000405@oracle.com> References: <51685442.9090404@oracle.com> <516C433E.1000405@oracle.com> Message-ID: <516C4DA3.8060803@oracle.com> On 4/15/13 11:13 AM, Alan Bateman wrote: > I went through the webrev and it looks good to me and good to get this > aligned and specified clearly. > thanks for the review. > A minor comment is that in the save for debugging code in > generateProxyClass then you could use Files.write to write the class > file in one method if you want. sure. I can clean that up before my push. Mandy From martinrb at google.com Mon Apr 15 19:21:18 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 12:21:18 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: References: <51673A45.8060908@oracle.com> Message-ID: On Mon, Apr 15, 2013 at 11:31 AM, Martin Buchholz wrote: > > OTOH, I'm guessing you are trying to improve the performance of operations > like List.toString. > More efficient (single copy char[]) would be to collect all the > sub-CharSequences in a CharSequence[], pre-compute the final length of the > char[], allocate an array of exactly the required length, and create the > final string directly from that using the package-private constructor (but > in the unlikely event that a subsequence changed in size while concat'ing, > be prepared to resize the array). > Proceeding further along this train of thought, I might start with AbstractCollection.toString() (and similar methods) and attempt to make it maximally efficient. Maybe add a method to JavaLangAccess to make a String directly from a perfectly sized array (as needed elsewhere?). Maybe create a StringBuilder-like class that works better for typical use cases? Software is hard. From martinrb at google.com Mon Apr 15 19:37:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 12:37:30 -0700 Subject: Use of super in type parameters Message-ID: CompletableFuture currently has a method like this: public CompletableFuture acceptEither (CompletableFuture other, Consumer block) { return doAcceptEither(other, block, null); } But that signature is not quite correct (not as general as it could be). The "correct" signature is public CompletableFuture acceptEither (CompletableFuture other, Consumer block) { return doAcceptEither(other, block, null); } but that fails to compile, because type parameters can only be constrained by extends, not super. Is implementing this on the radar? Angelika claims "lower bounds for type parameters make no sense" http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters ? but I am finding that hard to believe. Is she right? For comparison, the equivalent static method can be made to do what we want: public static CompletableFuture acceptEither (CompletableFuture f, CompletableFuture other, Consumer block) { return ... } From zhong.j.yu at gmail.com Mon Apr 15 19:50:31 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 15 Apr 2013 14:50:31 -0500 Subject: Use of super in type parameters In-Reply-To: References: Message-ID: I have encountered on stackoverflow.com several legit use cases of lower bound. And the other day Ali Lahijani raised the question that Stream.reduce(BinaryOperator) breaks convariance of Stream, and I thought that the root problem is lack of lower bound - the method would have had a better signature Stream Optional reduce(BinaryOperator accumulator) So I don't think there's a lack of use cases for lower bound. (But I have no idea how difficult it is to support it) Zhong Yu On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz wrote: > CompletableFuture currently has a method like this: > > public CompletableFuture acceptEither > (CompletableFuture other, > Consumer block) { > return doAcceptEither(other, block, null); > } > > But that signature is not quite correct (not as general as it could be). > The "correct" signature is > > public CompletableFuture acceptEither > (CompletableFuture other, > Consumer block) { > return doAcceptEither(other, block, null); > } > > but that fails to compile, because type parameters can only be constrained > by extends, not super. Is implementing this on the radar? Angelika claims > "lower bounds for type parameters make no sense" > http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters > ? > > but I am finding that hard to believe. Is she right? For comparison, the > equivalent static method can be made to do what we want: > > public static CompletableFuture acceptEither > (CompletableFuture f, > CompletableFuture other, > Consumer block) { > return ... > } From stevenschlansker at gmail.com Mon Apr 15 20:03:12 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 15 Apr 2013 13:03:12 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: References: <51673A45.8060908@oracle.com> Message-ID: On Apr 15, 2013, at 12:21 PM, Martin Buchholz wrote: > On Mon, Apr 15, 2013 at 11:31 AM, Martin Buchholz wrote: > >> >> OTOH, I'm guessing you are trying to improve the performance of operations >> like List.toString. >> More efficient (single copy char[]) would be to collect all the >> sub-CharSequences in a CharSequence[], pre-compute the final length of the >> char[], allocate an array of exactly the required length, and create the >> final string directly from that using the package-private constructor (but >> in the unlikely event that a subsequence changed in size while concat'ing, >> be prepared to resize the array). >> > > Proceeding further along this train of thought, I might start with > AbstractCollection.toString() (and similar methods) and attempt to make it > maximally efficient. > Maybe add a method to JavaLangAccess to make a String directly from a > perfectly sized array (as needed elsewhere?). Maybe create a > StringBuilder-like class that works better for typical use cases? For what it's worth, a patch that I contributed and Mike (and others) then rewrote contains this functionality already: http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/src/share/classes/sun/misc/JavaLangAccess.java.patch It's not merged yet though. From martinrb at google.com Mon Apr 15 20:36:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 15 Apr 2013 13:36:19 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: References: <51673A45.8060908@oracle.com> Message-ID: Thanks for the pointer. Yeah, that's one the pieces I think we should have to do an optimal job of rewriting collection toString methods. On Mon, Apr 15, 2013 at 1:03 PM, Steven Schlansker < stevenschlansker at gmail.com> wrote: > > On Apr 15, 2013, at 12:21 PM, Martin Buchholz wrote: > > > On Mon, Apr 15, 2013 at 11:31 AM, Martin Buchholz >wrote: > > > >> > >> OTOH, I'm guessing you are trying to improve the performance of > operations > >> like List.toString. > >> More efficient (single copy char[]) would be to collect all the > >> sub-CharSequences in a CharSequence[], pre-compute the final length of > the > >> char[], allocate an array of exactly the required length, and create the > >> final string directly from that using the package-private constructor > (but > >> in the unlikely event that a subsequence changed in size while > concat'ing, > >> be prepared to resize the array). > >> > > > > Proceeding further along this train of thought, I might start with > > AbstractCollection.toString() (and similar methods) and attempt to make > it > > maximally efficient. > > Maybe add a method to JavaLangAccess to make a String directly from a > > perfectly sized array (as needed elsewhere?). Maybe create a > > StringBuilder-like class that works better for typical use cases? > > For what it's worth, a patch that I contributed and Mike (and others) then > rewrote > contains this functionality already: > > > http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/src/share/classes/sun/misc/JavaLangAccess.java.patch > > It's not merged yet though. > > > From mike.duigou at oracle.com Mon Apr 15 21:06:01 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 14:06:01 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516988FB.8070501@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> <516988FB.8070501@CoSoCo.de> Message-ID: On Apr 13 2013, at 09:34 , Ulf Zibis wrote: > Am 12.04.2013 23:36, schrieb Mike Duigou: >> On Apr 11 2013, at 15:15 , Ulf Zibis wrote: >> >>> There is still a yoda style in ConcurrentMap line 72, HashMap line 361 >> Fixed > > I still see no change in webrev 5 in HashMap line 361 Now corrected. > >> >>> To be in line with old habits, please remove space after casts. See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 >> I am not going to do this. > > Well in Hashtable, existing code doesn't have the space after cast. If you insert space in new code, you introduce an inconsistency in style. It seems that, per your bug, everyone has given up hope that spacing after casts will be done consistently. I've corrected a few cases in new code but am not terribly concerned about this. > Even your new code is inconsistent, compare: That's because I'm not the only author. I get to fix it though, the glamourous life of a JDK janitor. :-) > HashTable line 917, 938, 984 etc. > HashMap line 588 etc. > Collections line 1402 etc. Should be more consistent now. I'm not willing to attempt correct this non-problem more broadly. > > I also notice, you introduce a new style ? in for( ; ... ; ... ;) expressions with space before ';'. Fixed in HashMap. I don't see this anywhere else. > >>> Collections: >>> lines 1442... + 3900... , indentation for follow up line should be 8 > > There are still lines 976, 1062 Of which file? According to http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/src/share/classes/java/util/Collections.java.html neither of those lines seems applicable. > >>> Map: >>> lines 599..600 bad indentation >> Corrected. > > Hm, I see still 3 instead 4 spaces and also in lines 545..546 Both corrected. > >> >>> Use consistent formatted code examples in javadoc. I like the style from lines 567 to 570, but e.g. from line 622 to 626: >>> - 2 spaces before 
    >>> - indentation should be 4
>>> - line break before }
    >> I had left these along in the previous round. Should be fixed now. > > Great, but see also code samples in ConcurrentMap. I'm not touching those. We are dependent upon syncs from JSR-166 repo for this class and don't want to introduce any extraneous changes. Try to convince Doug if you want. Mike From martinrb at google.com Mon Apr 15 21:12:42 2013 From: martinrb at google.com (martinrb at google.com) Date: Mon, 15 Apr 2013 21:12:42 +0000 Subject: hg: jdk8/tl/jdk: 8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change Message-ID: <20130415211304.5A67248309@hg.openjdk.java.net> Changeset: 4ed143ddbb8a Author: martin Date: 2013-04-15 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ed143ddbb8a 8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change Summary: Define JNIEXPORT to use "default" visibility where possible. Reviewed-by: coleenp, ddehaven, dcubed, anthony ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/npt/npt.h ! src/solaris/javavm/export/jni_md.h ! src/solaris/native/sun/awt/awt_LoadLibrary.c From mike.duigou at oracle.com Mon Apr 15 21:31:34 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 14:31:34 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516AF6D6.7000404@gmail.com> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> <516AED69.8020105@gmail.com> <516AF6D6.7000404@gmail.com> Message-ID: On Apr 14 2013, at 11:35 , Peter Levart wrote: > > On 04/14/2013 07:54 PM, Peter Levart wrote: >> Hi Mike, >> >> Just a nit: The order of boolean sub-expressions in Map.replace(key, oldValue, newValue): >> >> 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) >> >> ...would be more optimal if reversed (like in Map.remove(key, value)). >> >> Regards, Peter > > I think the most optimal is actually this: > > default boolean remove((Object key, Object value) { > Object curValue = get(key); > if (curValue == null && (value != null || !containsKey(key)) || > curValue != value && !curValue.equals(value)) { > return false; > } > remove(key); > return true; > } > > ...and the same for replace(key, oldValue, newValue)... In the current patch I've used: default boolean remove(Object key, Object value) { Object curValue = get(key); if (!Objects.equals(curValue, value) || (curValue == null && !containsKey(key))) { return false; } remove(key); return true; } and similar for replace(K,V,V) I rearranged it mostly so that calling containsKey is a last resort. Mike > > Regards, Peter > >> >> On 04/13/2013 12:02 AM, Mike Duigou wrote: >>> I have updated the webrev with these changes and a few more. >>> >>> merge() required an update to it's specification to correctly account for null values. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ >>> >>> This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. >>> >>> Mike >>> >>> On Apr 12 2013, at 12:53 , Mike Duigou wrote: >>> >>>> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >>>> >>>> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> a few small things - >>>>> >>>>> UnmodifiableMap.forEach >>>>> is missing Objects.requireNonNull(action); >>>> Added. >>>> >>>>> EmptyMap.replaceAll(BiFunction) >>>>> should just return instead of throwing UnsupportedOpEx >>>>> particularly since EmptyList.replaceAll also returns silently >>>>> after checking if function is null to fulfil the NPE contract >>>> I agree. >>>> >>>>> Hashtable >>>>> is missing a synchronized override of forEach >>>> added. >>>> >>>>> CheckedMap.typeCheck(BiFunction) >>>>> is missing from the patch (won't compile without it) >>>> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >>>> >>>>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>>>> Another revision incorporating primarily documentation feedback. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>>>> >>>>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>>>> >>>>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>>>> >>>>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>>>> >>>>>>> I've posted an updated webrev with the review comments I have received. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>>>> >>>>>>> One important point to consider: >>>>>>> >>>>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>>>> >>>>>>>> Hello all; >>>>>>>> >>>>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>>>> >>>>>>>> 8004518: Add in-place operations to Map >>>>>>>> forEach() >>>>>>>> replaceAll() >>>>>>>> >>>>>>>> 8010122: Add atomic operations to Map >>>>>>>> getOrDefault() >>>>>>>> putIfAbsent() * >>>>>>>> remove(K, V) >>>>>>>> replace(K, V) >>>>>>>> replace(K, V, V) >>>>>>>> compute() * >>>>>>>> merge() * >>>>>>>> computeIfAbsent() * >>>>>>>> computeIfPresent() * >>>>>>>> >>>>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>>>> >>>>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>>>> >>>>>>>> Mike >> > From mike.duigou at oracle.com Mon Apr 15 22:12:07 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 15:12:07 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <5168658E.4050606@oracle.com> <516AED69.8020105@gmail.com> <516AF6D6.7000404@gmail.com> Message-ID: <4A44D13B-0181-4091-9D1E-204324003BC5@oracle.com> Another updated webrev: http://cr.openjdk.java.net/~mduigou/JDK-8010122/6/webrev/ I've started pre-integration final testing on this patch and plan to push it tomorrow unless something significant comes up. Mike On Apr 15 2013, at 14:31 , Mike Duigou wrote: > > On Apr 14 2013, at 11:35 , Peter Levart wrote: > >> >> On 04/14/2013 07:54 PM, Peter Levart wrote: >>> Hi Mike, >>> >>> Just a nit: The order of boolean sub-expressions in Map.replace(key, oldValue, newValue): >>> >>> 740 if (!containsKey(key) || !Objects.equals(get(key), oldValue)) >>> >>> ...would be more optimal if reversed (like in Map.remove(key, value)). >>> >>> Regards, Peter >> >> I think the most optimal is actually this: >> >> default boolean remove((Object key, Object value) { >> Object curValue = get(key); >> if (curValue == null && (value != null || !containsKey(key)) || >> curValue != value && !curValue.equals(value)) { >> return false; >> } >> remove(key); >> return true; >> } >> >> ...and the same for replace(key, oldValue, newValue)... > > In the current patch I've used: > > default boolean remove(Object key, Object value) { > Object curValue = get(key); > if (!Objects.equals(curValue, value) || > (curValue == null && !containsKey(key))) { > return false; > } > remove(key); > return true; > } > > and similar for replace(K,V,V) > > I rearranged it mostly so that calling containsKey is a last resort. > > Mike > >> >> Regards, Peter >> >>> >>> On 04/13/2013 12:02 AM, Mike Duigou wrote: >>>> I have updated the webrev with these changes and a few more. >>>> >>>> merge() required an update to it's specification to correctly account for null values. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/ >>>> >>>> This version is currently undergoing final pre-integration testing. Unless additional problems are found or the testing fails this version will be integrated. >>>> >>>> Mike >>>> >>>> On Apr 12 2013, at 12:53 , Mike Duigou wrote: >>>> >>>>> Thanks for the corrections. I have incorporated all of these into the integration version of the patch. >>>>> >>>>> On Apr 12 2013, at 12:50 , Akhil Arora wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> a few small things - >>>>>> >>>>>> UnmodifiableMap.forEach >>>>>> is missing Objects.requireNonNull(action); >>>>> Added. >>>>> >>>>>> EmptyMap.replaceAll(BiFunction) >>>>>> should just return instead of throwing UnsupportedOpEx >>>>>> particularly since EmptyList.replaceAll also returns silently >>>>>> after checking if function is null to fulfil the NPE contract >>>>> I agree. >>>>> >>>>>> Hashtable >>>>>> is missing a synchronized override of forEach >>>>> added. >>>>> >>>>>> CheckedMap.typeCheck(BiFunction) >>>>>> is missing from the patch (won't compile without it) >>>>> Apparently I forgot a qrefresh before generating the webrev. I had this in my local copy as it's necessary. >>>>> >>>>>> On 04/11/2013 01:03 PM, Mike Duigou wrote: >>>>>>> Another revision incorporating primarily documentation feedback. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/2/webrev/ >>>>>>> >>>>>>> I've also included the java.util.Collections overrides for the default methods. All of these are performance enhancements--the semantics were already correct because the defaults use only public methods. >>>>>>> >>>>>>> This is likely, modulo formatting of the source examples, the version that will be pushed to TL on Friday unless somebody squawks. >>>>>>> >>>>>>> Moving the current compute, computeIfPresent, computeIfAbsent and merge defaults to ConcurrentMap and replacing the current Map defaults with versions that throw ConcurrentModificationException will likely be resolved in a future issue if the EG determines it to be important. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> On Apr 10 2013, at 22:42 , Mike Duigou wrote: >>>>>>> >>>>>>>> I've posted an updated webrev with the review comments I have received. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/1/webrev/ >>>>>>>> >>>>>>>> One important point to consider: >>>>>>>> >>>>>>>> - The current implementations of compute, computeIfPresent, computeIfAbsent, merge are implemented so that they can work correctly for ConcurrentMap instances. For non-concurrent implementations it might be better to fail and throw ConcurrentModification exception whenever concurrent modification is detected. For regular Map implementations the retry behaviour will only serve to mask errors. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> On Apr 8 2013, at 11:07 , Mike Duigou wrote: >>>>>>>> >>>>>>>>> Hello all; >>>>>>>>> >>>>>>>>> This is a combined review for the new default methods on the java.util.Map interface being added for the JSR-335 lambda libraries. The reviews are being combined because they share a common unit test. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8010122/0/webrev/ >>>>>>>>> >>>>>>>>> 8004518: Add in-place operations to Map >>>>>>>>> forEach() >>>>>>>>> replaceAll() >>>>>>>>> >>>>>>>>> 8010122: Add atomic operations to Map >>>>>>>>> getOrDefault() >>>>>>>>> putIfAbsent() * >>>>>>>>> remove(K, V) >>>>>>>>> replace(K, V) >>>>>>>>> replace(K, V, V) >>>>>>>>> compute() * >>>>>>>>> merge() * >>>>>>>>> computeIfAbsent() * >>>>>>>>> computeIfPresent() * >>>>>>>>> >>>>>>>>> The * operations treat null values as being absent. (ie. the same as there being no mapping for the specified key). >>>>>>>>> >>>>>>>>> The default implementations provided in Map are overridden in HashMap for performance purposes, in Hashtable for atomicity and performance purposes and in Collections for atomicity. >>>>>>>>> >>>>>>>>> Mike >>> >> > From mike.duigou at oracle.com Mon Apr 15 22:41:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 15:41:23 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: References: <51673A45.8060908@oracle.com> Message-ID: <4DAC3B94-5526-41CD-B87E-A560E2C6F2BE@oracle.com> On Apr 15 2013, at 13:03 , Steven Schlansker wrote: > > On Apr 15, 2013, at 12:21 PM, Martin Buchholz wrote: > >> On Mon, Apr 15, 2013 at 11:31 AM, Martin Buchholz wrote: >> >>> >>> OTOH, I'm guessing you are trying to improve the performance of operations >>> like List.toString. >>> More efficient (single copy char[]) would be to collect all the >>> sub-CharSequences in a CharSequence[], pre-compute the final length of the >>> char[], allocate an array of exactly the required length, and create the >>> final string directly from that using the package-private constructor (but >>> in the unlikely event that a subsequence changed in size while concat'ing, >>> be prepared to resize the array). >>> >> >> Proceeding further along this train of thought, I might start with >> AbstractCollection.toString() (and similar methods) and attempt to make it >> maximally efficient. >> Maybe add a method to JavaLangAccess to make a String directly from a >> perfectly sized array (as needed elsewhere?). Maybe create a >> StringBuilder-like class that works better for typical use cases? > > For what it's worth, a patch that I contributed and Mike (and others) then rewrote > contains this functionality already: > > http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/src/share/classes/sun/misc/JavaLangAccess.java.patch > > It's not merged yet though. It is not forgotten. :-) > From david.holmes at oracle.com Mon Apr 15 22:42:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Apr 2013 08:42:52 +1000 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: References: <516B474B.8090404@oracle.com> Message-ID: <516C826C.4020709@oracle.com> FYI updated webrev at same location, removing the dead code Erik spotted. http://cr.openjdk.java.net/~dholmes/8010280/webrev/ On 16/04/2013 2:25 AM, Mike Duigou wrote: > Hi David; > > I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped to see the "classic" and "green" flags go away and some of the other legacy flags like "-hotspot" reduced to WARN. What's the difference between removing an entry completely and retaining it with "ERROR"? Just the nature of the error message: > java -green Error: green VM not supported > java -blue Unrecognized option: -blue Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. I wasn't touching any of the legacy stuff - though if this needs to go to CCC I would suggest removing all the legacy entries. > Additionally I don't like that aliases have differing definitions and some confusing ones like "-server ALIASED_TO -client". Is this necessary or just historically convenient? I don't like aliases period! Historically (and this is very recent history) it was necessary to deal with the test suites being applied to a JDK with, eg, only client VM. Every test that specified -server would fail if the alias didn't exist (and as I stated we're moving away from that ie the tests don't set -client or -server but the complete test suite run does, and it knows what VM is under test. Personally I'd probably choose WARN for any VM not present. The problem is that the "right" thing depends on who is building what, and how they plan to use it. All I can do is define a not-unreasonable default policy. I also have a time constraint as I need to get this in before the 23rd to meet an internal deadline. I've attached all the generated versions below. Thanks, David :::::::::::::: linux-i586-client/jdk/lib/i386/jvm.cfg :::::::::::::: -client KNOWN -server ALIASED_TO -client -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR :::::::::::::: linux-i586-client-server/jdk/lib/i386/jvm.cfg :::::::::::::: # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License version 2 only, as # published by the Free Software Foundation. Oracle designates this # particular file as subject to the "Classpath" exception as provided # by Oracle in the LICENSE file that accompanied this code. # # This code is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # version 2 for more details (a copy is included in the LICENSE file that # accompanied this code). # # You should have received a copy of the GNU General Public License version # 2 along with this work; if not, write to the Free Software Foundation, # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. # # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA # or visit www.oracle.com if you need additional information or have any # questions. # # List of JVMs that can be used as an option to java, javac, etc. # Order is important -- first in this list is the default JVM. # NOTE that this both this file and its format are UNSUPPORTED and # WILL GO AWAY in a future release. # # You may also select a JVM in an arbitrary location with the # "-XXaltjvm=" option, but that too is unsupported # and may not be available in a future release. # -client IF_SERVER_CLASS -server -server KNOWN -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR :::::::::::::: linux-i586-client-server-minimal1/jdk/lib/i386/jvm.cfg :::::::::::::: # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License version 2 only, as # published by the Free Software Foundation. Oracle designates this # particular file as subject to the "Classpath" exception as provided # by Oracle in the LICENSE file that accompanied this code. # # This code is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # version 2 for more details (a copy is included in the LICENSE file that # accompanied this code). # # You should have received a copy of the GNU General Public License version # 2 along with this work; if not, write to the Free Software Foundation, # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. # # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA # or visit www.oracle.com if you need additional information or have any # questions. # # List of JVMs that can be used as an option to java, javac, etc. # Order is important -- first in this list is the default JVM. # NOTE that this both this file and its format are UNSUPPORTED and # WILL GO AWAY in a future release. # # You may also select a JVM in an arbitrary location with the # "-XXaltjvm=" option, but that too is unsupported # and may not be available in a future release. # -client IF_SERVER_CLASS -server -server KNOWN -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR -minimal KNOWN :::::::::::::: linux-i586-minimal1-client/jdk/lib/i386/jvm.cfg :::::::::::::: -client KNOWN -server ALIASED_TO -client -hotspot ALIASED_TO -client -minimal KNOWN -classic WARN -native ERROR -green ERROR :::::::::::::: linux-i586-minimal1/jdk/lib/i386/jvm.cfg :::::::::::::: -minimal KNOWN -server ALIASED_TO -minimal -client ALIASED_TO -minimal -hotspot ALIASED_TO -minimal -classic WARN -native ERROR -green ERROR :::::::::::::: linux-i586-minimal1-server/jdk/lib/i386/jvm.cfg :::::::::::::: -server KNOWN -client ALIASED_TO -server -hotspot ALIASED_TO -server -minimal KNOWN -classic WARN -native ERROR -green ERROR :::::::::::::: linux-i586-server-client-minimal1/jdk/lib/i386/jvm.cfg :::::::::::::: # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License version 2 only, as # published by the Free Software Foundation. Oracle designates this # particular file as subject to the "Classpath" exception as provided # by Oracle in the LICENSE file that accompanied this code. # # This code is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # version 2 for more details (a copy is included in the LICENSE file that # accompanied this code). # # You should have received a copy of the GNU General Public License version # 2 along with this work; if not, write to the Free Software Foundation, # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. # # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA # or visit www.oracle.com if you need additional information or have any # questions. # # List of JVMs that can be used as an option to java, javac, etc. # Order is important -- first in this list is the default JVM. # NOTE that this both this file and its format are UNSUPPORTED and # WILL GO AWAY in a future release. # # You may also select a JVM in an arbitrary location with the # "-XXaltjvm=" option, but that too is unsupported # and may not be available in a future release. # -client IF_SERVER_CLASS -server -server KNOWN -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR -minimal KNOWN :::::::::::::: linux-i586-server/jdk/lib/i386/jvm.cfg :::::::::::::: -server KNOWN -client ALIASED_TO -server -hotspot ALIASED_TO -server -classic WARN -native ERROR -green ERROR From mandy.chung at oracle.com Mon Apr 15 22:58:22 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Apr 2013 15:58:22 -0700 Subject: Proxy.isProxyClass scalability In-Reply-To: <5169D55B.8040709@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> <51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com> Message-ID: <516C860E.2050205@oracle.com> On 4/13/2013 2:59 PM, Peter Levart wrote: > >>> >>> I also devised an alternative caching mechanism with scalability in >>> mind which uses WeakReferences for keys (for example ClassLoader) >>> and values (for example Class) that could be used in this situation >>> in case adding a field to ClassLoader is not an option: >>> >> >> I would also consider any alternative to avoid adding the >> proxyClassCache field in ClassLoader as Alan commented previously. >> >> My observation of the typical usage of proxies is to use the >> interface's class loader to define the proxy class. So is it >> necessary to maintain a per-loader cache? The per-loader cache maps >> from the interface names to a proxy class defined by one loader. I >> would think it's reasonable to assume the number of loaders to define >> proxy class with the same set of interfaces is small. What if we >> make the cache as "interface names" as the key to a set of proxy >> class suppliers that can have only one proxy class per one unique >> defining loader. If the proxy class is being generated i.e. >> ProxyClassFactory supplier, the loader is available for comparison. >> When there are more than one matching proxy classes, it would have to >> iterate all in the set. > > I would assume yes, proxy class for a particular set of interfaces is > typically defined by one classloader only. But the API allows to > specify different loaders as long as the interfaces implemented by > proxy class are "visible" from the loader that defines the proxy > class. If we're talking about interface names - as opposed to > interfaces - then the possibility that a particular set of interface > names would want to be used to define proxy classes with different > loaders is even bigger, since an interface name can refer to different > interfaces with same name (think of interfaces deployed as part of an > app in an application server, say a set of annotations used by > different apps but deployed as part of each individual app). > Agree. I was tempted to consider making weak reference to the interface classes as the key but in any case the overhead of Class.getClassLoader() is still a performance hog. Let's move forward with the alternative you propose. > The scheme you're proposing might be possible, though not simple: The > factory Supplier would become a Function > and would have to maintain it's own set of cached proxy classes. There > would be a single ConcurrentMap, Function Class>> to map sets of interface names to factory Functions, but the > cached classes in a particular factory Function would still have to be > weakly referenced. I see some difficulties in implementing such a scheme: > - expunging cleared WeakReferences could only reliably clear the cache > inside each factory Function but removing the entry from the map of > factory Functions when last proxy class for a particular set of > interface names is expunged would become a difficult task if not > impossible with all the scalability constraints in mind (just thinking > about concurrent requests into same factory Function where one is > requesting new proxy class and the other is expunging cleared > WeakReference which represents the last element in the set of cached > proxy classes). > - one of my past ideas of implementing scalable Proxy.isProxyClass() > was to maintain a Set in each ClassLoader populated with all > the proxy classes defined by a particular ClassLoader. Benchmarking > such solution showed that Class.getClassLoader() is a peformance hog, > so I scraped it in favor of ClassValue that is now > incorporated in the patch. In order to "choose" the right proxy class > from the set of proxy classes inside a particular factory Function, > the Class.getClassLoader() method would have to be used, or entries > would have to (weakly) reference a particular ClassLoader associated > with each proxy class. > Thanks for reminding me your earlier prototype. I suspect the cost of Class.getClassLoader() is due to its lookup of the caller class every time it's called. > Considering all that, such solution starts to look unappealing. It > might even be more space-hungry then the presented WeakCache. > > WeakCache is currently the following: > > ConcurrentMap, > WeakReference> > > another alternative would be: > > ConcurrentMap, > ConcurrentMap>> > > ...which might need a little less space than WeakCache (only one > WeakReference per proxy class + one per ClassLoader instead of two > WeakReferences per proxy class) but would require two map lookups > during fast-path retrieval. It might not be performance critical and > the expunging could be performed easily too. > I am fine with either of these alternatives. As you noted, the latter one would save little bit of memory for the cases when several proxy classes are defined per loader e.g. one per each annotation type. Mandy From mike.duigou at oracle.com Mon Apr 15 23:04:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 16:04:35 -0700 Subject: RFR : 8010953: Add primitive summary statistics utils Message-ID: Hello all; Another review in the JSR-335 libraries series. These three classes provide a utility for conveniently finding count, sum, min, max and average of ints, longs or doubles. They can be used with existing code but will most likely be used with the Collectors utilities or directly with primitive or boxed streams. http://cr.openjdk.java.net/~mduigou/JDK-8010953/0/webrev/ Mike From Ulf.Zibis at CoSoCo.de Mon Apr 15 23:13:05 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 16 Apr 2013 01:13:05 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> <516988FB.8070501@CoSoCo.de> Message-ID: <516C8981.3070804@CoSoCo.de> Am 15.04.2013 23:06, schrieb Mike Duigou: > That's because I'm not the only author. I get to fix it though, the glamourous life of a JDK janitor. :-) ;-) >> HashTable line 917, 938, 984 etc. >> HashMap line 588 etc. >> Collections line 1402 etc. > Should be more consistent now. I'm not willing to attempt correct this non-problem more broadly. HashTable line 972, 992, 1011, 1035, 1064, 1099, etc. >>>> Collections: >>>> lines 1442... + 3900... , indentation for follow up line should be 8 >> There are still lines 976, 1062 > Of which file? According to http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/src/share/classes/java/util/Collections.java.html > > neither of those lines seems applicable. Oops I'm sorry, I meant lines 976, 1062 of Map. In Collections I've found additional inconsistent indentations, lines 2836, 2837, 2848, 2853, 2897 Old code: 262, 270, 292, 1248, 1304, 1528, 1580, 1611, 1784, 1873, 1995, 2036, 2092, 2304, 2414, 2460, 2694, 2760, 2770, 2819, 3032, 3071, 3118, 3155, 3164, 3214, 3273, 3318, 3322, 3358, 3397, 3446, 3559, 3633, 3756, 3790, 3809, 3832, 3867, 3965, 4014, 4070, 4109, 4133, 4301, 4381, 4413, 4445. -Ulf From joe.darcy at oracle.com Tue Apr 16 01:32:37 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 16 Apr 2013 01:32:37 +0000 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) Message-ID: <20130416013250.6528B4831D@hg.openjdk.java.net> Changeset: baaa706d7677 Author: darcy Date: 2013-04-15 18:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baaa706d7677 8011800: Add java.util.Objects.requireNonNull(T, Supplier) Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java From mike.duigou at oracle.com Tue Apr 16 03:39:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 15 Apr 2013 20:39:31 -0700 Subject: RFR JDK-8011426: java.util collection Spliterator implementations In-Reply-To: References: Message-ID: <2783EFA9-6C6A-4FB7-840C-63BC8103B581@oracle.com> I went back and started again with the 8010096 webrev. Spliterators:: - some implementations are private and some are package private. All package private? List/Set/Iterator/SortedSet:: - Include the same interface level @implSpec warning as Collection? Spliterator:: - "

    Spliterators also report ..." You may want to avoid the plural form since there's also a class of that name. Spliterator.NONNULL - "This applies, for example, to ...". I might like the name Spliterator.NONULLS better. Spliterator.IMMUTABLE - this name doesn't quite capture what's allowed and what's prohibited. An Arrays.asList() list is IMMUTABLE but elements can still be replaced in place. Collections.unmodifiableList(Array.asList(..)) is entirely immutable. Is the distinction ever important? - I guess the issue is that some of the flags describe characteristics of the source and some describe characteristics of the elements. - "A diagnostic warning that boxing of primitives values is occurring of can be requested by setting the boolean system property {@code org.openjdk.java.util.stream.tripwire} is to {@code true}." - Neither forEachREmaining on Iterator or tryAdvance on Spliterator say whether it's possible (or advisable) to continue advancing following an exception being thrown. Will calling again continue with the next element? The same element? Unspecified? Is calling again after an exception prohibited? - getExactSizeIfKnown() - use hasCharacteristics? - The note in CONCURRENT "Such a Spliterator is * inconsistent and no guarantees can be made about any computation using * that Spliterator." Is this necessary or just confusing. Users won't encounter this. - Same with the similar note in SUBSIZED. Mike On Apr 10 2013, at 06:50 , Paul Sandoz wrote: > Hi, > > Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util: > > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011426/webrev/ > > This is dependent on [1]. > > -- > > Note that for some reason the webrev script creates the jdk changeset file for my complete hg patch queue and not from the revision i specify. Anyone know how to change that? > > Paul. > > > [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/ From erik.joelsson at oracle.com Tue Apr 16 06:17:16 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 16 Apr 2013 08:17:16 +0200 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516C826C.4020709@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> Message-ID: <516CECEC.1060508@oracle.com> This looks good to me. /Erik On 2013-04-16 00:42, David Holmes wrote: > FYI updated webrev at same location, removing the dead code Erik spotted. > > http://cr.openjdk.java.net/~dholmes/8010280/webrev/ > > On 16/04/2013 2:25 AM, Mike Duigou wrote: >> Hi David; >> >> I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped >> to see the "classic" and "green" flags go away and some of the other >> legacy flags like "-hotspot" reduced to WARN. What's the difference >> between removing an entry completely and retaining it with "ERROR"? > > Just the nature of the error message: > > > java -green > Error: green VM not supported > > java -blue > Unrecognized option: -blue > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I wasn't touching any of the legacy stuff - though if this needs to go > to CCC I would suggest removing all the legacy entries. > >> Additionally I don't like that aliases have differing definitions and >> some confusing ones like "-server ALIASED_TO -client". Is this >> necessary or just historically convenient? > > I don't like aliases period! Historically (and this is very recent > history) it was necessary to deal with the test suites being applied > to a JDK with, eg, only client VM. Every test that specified -server > would fail if the alias didn't exist (and as I stated we're moving > away from that ie the tests don't set -client or -server but the > complete test suite run does, and it knows what VM is under test. > > Personally I'd probably choose WARN for any VM not present. > > The problem is that the "right" thing depends on who is building what, > and how they plan to use it. All I can do is define a not-unreasonable > default policy. I also have a time constraint as I need to get this in > before the 23rd to meet an internal deadline. > > I've attached all the generated versions below. > > Thanks, > David > > :::::::::::::: > linux-i586-client/jdk/lib/i386/jvm.cfg > :::::::::::::: > -client KNOWN > -server ALIASED_TO -client > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-client-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but > WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License > version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-client-server-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but > WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License > version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > -minimal KNOWN > :::::::::::::: > linux-i586-minimal1-client/jdk/lib/i386/jvm.cfg > :::::::::::::: > -client KNOWN > -server ALIASED_TO -client > -hotspot ALIASED_TO -client > -minimal KNOWN > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > -minimal KNOWN > -server ALIASED_TO -minimal > -client ALIASED_TO -minimal > -hotspot ALIASED_TO -minimal > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-minimal1-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > -server KNOWN > -client ALIASED_TO -server > -hotspot ALIASED_TO -server > -minimal KNOWN > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-server-client-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but > WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License > version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > -minimal KNOWN > :::::::::::::: > linux-i586-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > -server KNOWN > -client ALIASED_TO -server > -hotspot ALIASED_TO -server > -classic WARN > -native ERROR > -green ERROR > From david.holmes at oracle.com Tue Apr 16 10:10:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Apr 2013 20:10:17 +1000 Subject: RFR : 8010953: Add primitive summary statistics utils In-Reply-To: References: Message-ID: <516D2389.2050609@oracle.com> Hi Mike, On 16/04/2013 9:30 AM, Mike Duigou wrote: > Hello all; > > Another integration review in the JSR-335 libraries series. These three classes provide a utility for conveniently finding count, sum, min, max and average of ints, longs or doubles. They can be used with existing code but will most likely be used with the Collectors utilities or directly with primitive or boxed streams. > > http://cr.openjdk.java.net/~mduigou/JDK-8010953/1/webrev/ > > (this is an updated version of the webrev sent to core-libs-dev). A couple of minor nits: DoubleSummaryStatistics: getMin/getMax: The main doc should read the same as the @return. Presently the initial sentence: 120 * Returns the recorded value closest to {@code Double.NEGATIVE_INFINITY}, 121 * {@code Double.POSITIVE_INFINITY} if no values have been recorded or if 122 * any recorded value is NaN, then the result is NaN. if very difficult to read and parse. The @return is much simpler - just say minimum/maximum value recorded, rather than "value closest to ...". In all classes: minimal -> minimum maximal -> maximum David > Mike > From Alan.Bateman at oracle.com Tue Apr 16 10:25:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Apr 2013 11:25:02 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <20130416013250.6528B4831D@hg.openjdk.java.net> References: <20130416013250.6528B4831D@hg.openjdk.java.net> Message-ID: <516D26FE.5050904@oracle.com> Joe - it turns out that this breaks genstubs as java.util.function is not in the boot JDK. I think we may have to anti-delta this until a solution for genstubs is worked out. -Alan. On 16/04/2013 02:32, joe.darcy at oracle.com wrote: > Changeset: baaa706d7677 > Author: darcy > Date: 2013-04-15 18:31 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baaa706d7677 > > 8011800: Add java.util.Objects.requireNonNull(T, Supplier) > Reviewed-by: alanb, dholmes, mduigou > > ! src/share/classes/java/util/Objects.java > ! test/java/util/Objects/BasicObjectsTest.java > From chris.hegarty at oracle.com Tue Apr 16 10:47:33 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Apr 2013 11:47:33 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D26FE.5050904@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> Message-ID: <516D2C45.2030401@oracle.com> On 04/16/2013 11:25 AM, Alan Bateman wrote: > > Joe - it turns out that this breaks genstubs as java.util.function is > not in the boot JDK. I think we may have to anti-delta this until a > solution for genstubs is worked out. Here is a simple anti-delta patch, under 8012343: "Objects.requireNonNull(Object,Supplier) breaks genstubs build" http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ Once reviewed, I will push it. We can leave it to Joe and Jon to work out the more tricky genstubs issue ;-) -Chris. > > -Alan. > > On 16/04/2013 02:32, joe.darcy at oracle.com wrote: >> Changeset: baaa706d7677 >> Author: darcy >> Date: 2013-04-15 18:31 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baaa706d7677 >> >> 8011800: Add java.util.Objects.requireNonNull(T, Supplier) >> Reviewed-by: alanb, dholmes, mduigou >> >> ! src/share/classes/java/util/Objects.java >> ! test/java/util/Objects/BasicObjectsTest.java >> > From Alan.Bateman at oracle.com Tue Apr 16 11:02:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Apr 2013 12:02:18 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D2C45.2030401@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> Message-ID: <516D2FBA.9080203@oracle.com> On 16/04/2013 11:47, Chris Hegarty wrote: > > Here is a simple anti-delta patch, under 8012343: > "Objects.requireNonNull(Object,Supplier) breaks genstubs build" > > http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ > > Once reviewed, I will push it. We can leave it to Joe and Jon to work > out the more tricky genstubs issue ;-) > > -Chris. Bootstraping the build is complicated and I'm not 100% sure why a stub is generated for java.util.Objects, Jon will know. In the mean-time, the patch to anti-delta the change is fine. It's not nice to have to do this of course we need to get jdk8/tl building again. -Alan From chris.hegarty at oracle.com Tue Apr 16 11:33:51 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 11:33:51 +0000 Subject: hg: jdk8/tl/jdk: 8012343: Objects.requireNonNull(Object, Supplier) breaks genstubs build Message-ID: <20130416113404.E53A14832F@hg.openjdk.java.net> Changeset: 61cfbe08ce5d Author: chegar Date: 2013-04-16 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61cfbe08ce5d 8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build Reviewed-by: alanb ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java From chris.hegarty at oracle.com Tue Apr 16 11:45:47 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Apr 2013 12:45:47 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D2FBA.9080203@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> <516D2FBA.9080203@oracle.com> Message-ID: <516D39EB.9030907@oracle.com> On 04/16/2013 12:02 PM, Alan Bateman wrote: > On 16/04/2013 11:47, Chris Hegarty wrote: >> >> Here is a simple anti-delta patch, under 8012343: >> "Objects.requireNonNull(Object,Supplier) breaks genstubs build" >> >> http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ >> >> Once reviewed, I will push it. We can leave it to Joe and Jon to work >> out the more tricky genstubs issue ;-) >> >> -Chris. > Bootstraping the build is complicated and I'm not 100% sure why a stub > is generated for java.util.Objects, Jon will know. In the mean-time, the > patch to anti-delta the change is fine. It's not nice to have to do this > of course we need to get jdk8/tl building again. Pushed http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61cfbe08ce5d Apologies to Joe for the crude backout. On the positive side, now that jdk8/tl is buildable again, the pressure is off to find a solution for genstubs. -Chris. > > -Alan From paul.sandoz at oracle.com Tue Apr 16 11:51:27 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Apr 2013 13:51:27 +0200 Subject: RFR JDK-8011426: java.util collection Spliterator implementations In-Reply-To: <2783EFA9-6C6A-4FB7-840C-63BC8103B581@oracle.com> References: <2783EFA9-6C6A-4FB7-840C-63BC8103B581@oracle.com> Message-ID: <1E4FD153-F44E-46EF-9DD2-033AD0ECB420@oracle.com> Hi Mike, Thanks for looking at this. On Apr 16, 2013, at 5:39 AM, Mike Duigou wrote: > I went back and started again with the 8010096 webrev. > > Spliterators:: > > - some implementations are private and some are package private. All package private? > I don't think there is any need to make EmptySpliterator package private. All other static spliterator classes are package private, although not all of them are used by other classes in the same package. Arguably the right thing to do make such classes package private only if they are required to be so. > List/Set/Iterator/SortedSet:: > > - Include the same interface level @implSpec warning as Collection? > I don't think it applies to Iterator (or Iterable). For unmodifiable collections the caller is required to explicitly synchronize iteration since one could do: i.next() i.forEachRemaining(...) I would be inclined to leave it as is rather than repeat on all interfaces and implementations that can extended. > Spliterator:: > > - "

    Spliterators also report ..." You may want to avoid the plural form since there's also a class of that name. > OK, i changed this one. The plural is used in many other places too, but the context is clear enough for those i think. > Spliterator.NONNULL - "This applies, for example, to ...". I might like the name Spliterator.NONULLS better. > > Spliterator.IMMUTABLE - this name doesn't quite capture what's allowed and what's prohibited. It is about structural modification to the source: * Characteristic value signifying that the element source cannot be * structurally modified; that is, elements cannot be added, replaced, or * removed, so such changes cannot occur during traversal. A Spliterator > An Arrays.asList() list is IMMUTABLE but elements can still be replaced in place. Collections.unmodifiableList(Array.asList(..)) is entirely immutable. Is the distinction ever important? > Ah, well spotted, that is a bug in the implementation of Arrays.ArrayList implementation, it should not be IMMUTABLE, since we anyway cannot guarantee immutability of the backed array. I removed the declaration of IMMUTABLE. > - I guess the issue is that some of the flags describe characteristics of the source and some describe characteristics of the elements. > Yes, in this case IMMUTABLE really is about the source, since the elements themselves could be modified (just like for unmodifiable collections). > - "A diagnostic warning that boxing of primitives values is occurring of can be requested by setting the boolean system property {@code org.openjdk.java.util.stream.tripwire} is to {@code true}." > That is a little vague because it does not say how they occur. I changed to: * @implNote * If the boolean system property {@code org.openjdk.java.util.stream.tripwire} * is set to {@code true} then diagnostic warnings are reported if boxing of * primitive values occur when operating on primitive subtype specializations. > - Neither forEachREmaining on Iterator or tryAdvance on Spliterator say whether it's possible (or advisable) to continue advancing following an exception being thrown. Will calling again continue with the next element? The same element? Unspecified? Is calling again after an exception prohibited? > Undefined behaviour, a bit like if any unspecified runtime exception or error is thrown by the Iterator/Spliterator itself. Exceptions should not be used for flow control with forEachRemaining. We could say for Iterators: An error or runtime exception thrown by the action is relayed to the caller, and the results of further iteration are undefined. and for Spliterators: An error or runtime exception thrown by the action is relayed to the caller, and the results of further traversal or splitting are undefined. ? > - getExactSizeIfKnown() - use hasCharacteristics? > We could, it is marginally more efficient not to. > - The note in CONCURRENT "Such a Spliterator is > * inconsistent and no guarantees can be made about any computation using > * that Spliterator." Is this necessary or just confusing. Users won't encounter this. > > - Same with the similar note in SUBSIZED. > OK, Brian removed that. Paul. From chris.hegarty at oracle.com Tue Apr 16 12:15:06 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 12:15:06 +0000 Subject: hg: jdk8/tl/jdk: 8012237: CompletableFuture/Basic.java still fails intermittently Message-ID: <20130416121519.28F0048330@hg.openjdk.java.net> Changeset: e2a0e37b152c Author: chegar Date: 2013-04-16 12:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2a0e37b152c 8012237: CompletableFuture/Basic.java still fails intermittently Reviewed-by: martin ! test/java/util/concurrent/CompletableFuture/Basic.java From chris.hegarty at oracle.com Tue Apr 16 12:27:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 12:27:36 +0000 Subject: hg: jdk8/tl/jdk: 8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows Message-ID: <20130416122748.465FD48331@hg.openjdk.java.net> Changeset: 6135c60e77e5 Author: chegar Date: 2013-04-16 13:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6135c60e77e5 8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows Reviewed-by: alanb, dsamersoff ! src/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/windows/native/java/net/SocketInputStream.c ! test/java/net/Socket/asyncClose/Race.java From peter.levart at gmail.com Tue Apr 16 14:18:27 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Apr 2013 16:18:27 +0200 Subject: Proxy.isProxyClass scalability In-Reply-To: <516C860E.2050205@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> <51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com> <516C860E.2050205@oracle.com> Message-ID: <516D5DB3.3020102@gmail.com> Hi Mandy, I prepared a preview variant of j.l.r.Proxy using WeakCache (turned into an interface and a special FlattenedWeakCache implementation in anticipation to create another variant using two-levels of ConcurrentHashMaps for backing storage, but with same API) just to compare performance: https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.01/index.html As the values (Class objects of proxy classes) must be wrapped in a WeakReference, the same instance of WeakReference can be re-used as a key in another ConcurrentHashMap to implement quick look-up for Proxy.isProxyClass() method eliminating the need to use ClassValue, which is quite space-hungry. Comparing the performance, here's a summary of all 3 variants (original, patched using a field in ClassLoader and this variant): Summary (4 Cores x 2 Threads i7 CPU): Test Threads ns/op Original Patched (CL field) Patched (WeakCache) ======================= ======= ============== ================== =================== Proxy_getProxyClass 1 2,403.27 163.70 206.88 4 3,039.01 202.77 303.38 8 5,193.58 314.47 442.58 Proxy_isProxyClassTrue 1 95.02 10.78 41.85 4 2,266.29 10.80 42.32 8 4,782.29 20.53 72.29 Proxy_isProxyClassFalse 1 95.02 1.36 1.36 4 2,186.59 1.36 1.37 8 4,891.15 2.72 2.94 Annotation_equals 1 240.10 152.29 193.27 4 1,864.06 153.81 195.60 8 8,639.20 262.09 384.72 The improvement is still quite satisfactory, although a little slower than the direct-field variant. The scalability is the same as with direct-field variant. Space consumption of cache structure, calculated as deep-size of the structure, ignoring interned Strings, Class and ClassLoader objects unsing single non-bootstrap ClassLoader for defining the proxy classes and using 32 bit addressing is the following: original Proxy code: proxy size of delta to classes caches prev.ln. -------- -------- -------- 0 400 400 1 768 368 2 920 152 3 1072 152 4 1224 152 5 1376 152 6 1528 152 7 1680 152 8 1832 152 9 1984 152 10 2136 152 Proxy patched with the variant using FlattenedWeakCache, run on current JDK8/tl tip (still uses old ConcurrentHashMap implementation with segments): proxy size of delta to classes caches prev.ln. -------- -------- -------- 0 560 560 1 936 376 2 1312 376 3 1688 376 4 2064 376 5 2352 288 6 2728 376 7 3016 288 8 3392 376 9 3592 200 10 3872 280 ...and the same with current JDK8/lambda tip (using new segment-less ConcurrentHashMap): proxy size of delta to classes caches prev.ln. -------- -------- -------- 0 240 240 1 584 344 2 768 184 3 952 184 4 1136 184 5 1320 184 6 1504 184 7 1688 184 8 1872 184 9 2056 184 10 2240 184 So with new ConcurrentHashMap the patched Proxy uses about 32 bytes more per proxy class. Is this satisfactory or should we also try a variant with two-levels of ConcurrentHashMaps? Regards, Peter P.S. Comment to your comment in-line... On 04/16/2013 12:58 AM, Mandy Chung wrote: > > On 4/13/2013 2:59 PM, Peter Levart wrote: >> >>>> >>>> I also devised an alternative caching mechanism with scalability in >>>> mind which uses WeakReferences for keys (for example ClassLoader) >>>> and values (for example Class) that could be used in this situation >>>> in case adding a field to ClassLoader is not an option: >>>> >>> >>> I would also consider any alternative to avoid adding the >>> proxyClassCache field in ClassLoader as Alan commented previously. >>> >>> My observation of the typical usage of proxies is to use the >>> interface's class loader to define the proxy class. So is it >>> necessary to maintain a per-loader cache? The per-loader cache maps >>> from the interface names to a proxy class defined by one loader. I >>> would think it's reasonable to assume the number of loaders to >>> define proxy class with the same set of interfaces is small. What >>> if we make the cache as "interface names" as the key to a set of >>> proxy class suppliers that can have only one proxy class per one >>> unique defining loader. If the proxy class is being generated i.e. >>> ProxyClassFactory supplier, the loader is available for comparison. >>> When there are more than one matching proxy classes, it would have >>> to iterate all in the set. >> >> I would assume yes, proxy class for a particular set of interfaces is >> typically defined by one classloader only. But the API allows to >> specify different loaders as long as the interfaces implemented by >> proxy class are "visible" from the loader that defines the proxy >> class. If we're talking about interface names - as opposed to >> interfaces - then the possibility that a particular set of interface >> names would want to be used to define proxy classes with different >> loaders is even bigger, since an interface name can refer to >> different interfaces with same name (think of interfaces deployed as >> part of an app in an application server, say a set of annotations >> used by different apps but deployed as part of each individual app). >> > > Agree. I was tempted to consider making weak reference to the > interface classes as the key but in any case the overhead of > Class.getClassLoader() is still a performance hog. Let's move > forward with the alternative you propose. > >> The scheme you're proposing might be possible, though not simple: The >> factory Supplier would become a Function >> and would have to maintain it's own set of cached proxy classes. >> There would be a single ConcurrentMap, >> Function> to map sets of interface names to >> factory Functions, but the cached classes in a particular factory >> Function would still have to be weakly referenced. I see some >> difficulties in implementing such a scheme: >> - expunging cleared WeakReferences could only reliably clear the >> cache inside each factory Function but removing the entry from the >> map of factory Functions when last proxy class for a particular set >> of interface names is expunged would become a difficult task if not >> impossible with all the scalability constraints in mind (just >> thinking about concurrent requests into same factory Function where >> one is requesting new proxy class and the other is expunging cleared >> WeakReference which represents the last element in the set of cached >> proxy classes). >> - one of my past ideas of implementing scalable Proxy.isProxyClass() >> was to maintain a Set in each ClassLoader populated with all >> the proxy classes defined by a particular ClassLoader. Benchmarking >> such solution showed that Class.getClassLoader() is a peformance hog, >> so I scraped it in favor of ClassValue that is now >> incorporated in the patch. In order to "choose" the right proxy class >> from the set of proxy classes inside a particular factory Function, >> the Class.getClassLoader() method would have to be used, or entries >> would have to (weakly) reference a particular ClassLoader associated >> with each proxy class. >> > > Thanks for reminding me your earlier prototype. I suspect the cost of > Class.getClassLoader() is due to its lookup of the caller class every > time it's called. Even without SecurityManager installed the performance of native getClassLoader0 was a hog. I don't know why? Isn't there an implicit reference to defining ClassLoader from every Class object? > >> Considering all that, such solution starts to look unappealing. It >> might even be more space-hungry then the presented WeakCache. >> >> WeakCache is currently the following: >> >> ConcurrentMap, >> WeakReference> >> >> another alternative would be: >> >> ConcurrentMap, >> ConcurrentMap>> >> >> ...which might need a little less space than WeakCache (only one >> WeakReference per proxy class + one per ClassLoader instead of two >> WeakReferences per proxy class) but would require two map lookups >> during fast-path retrieval. It might not be performance critical and >> the expunging could be performed easily too. >> > > I am fine with either of these alternatives. As you noted, the latter > one would save little bit of memory for the cases when several proxy > classes are defined per loader e.g. one per each annotation type. > > Mandy From coleen.phillimore at oracle.com Tue Apr 16 14:18:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 16 Apr 2013 10:18:25 -0400 Subject: RFR (S) 8009531: Crash when redefining class with annotated method In-Reply-To: <516B7418.9080703@oracle.com> References: <5168483A.9020304@oracle.com> <516B6F43.5020301@oracle.com> <516B7418.9080703@oracle.com> Message-ID: <516D5DB1.7010206@oracle.com> On 04/14/2013 11:29 PM, David Holmes wrote: > On 15/04/2013 1:08 PM, David Holmes wrote: >> Hi Coleen, >> >> On 13/04/2013 3:45 AM, Coleen Phillimore wrote: >>> Summary: Add annotations to the tests to verify bug above >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk >>> >>> The Hotspot change is in tl repository now. Also, this has been >>> reviewed by the hotspot group. >> >> Is the StressLdcRewrite essential to the test? (Aside: And why is that a >> product flag ??) I don't know why it's a product flag. I added IgnoreUnrecognizedVMOptions in case it changes though. >> >> Otherwise looks okay. > > Strike that. I missed what Alan pointed out. You are not actually > adding the annotations. So why do we need the printlns? I added the printlns to make sure there are bytecodes to rewrite in the method. Coleen > > David > >> David >> >>> Thanks, >>> Coleen From jim.gish at oracle.com Tue Apr 16 15:13:11 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 16 Apr 2013 11:13:11 -0400 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: References: <51673A45.8060908@oracle.com> Message-ID: <516D6A87.2000606@oracle.com> On 04/15/2013 02:02 PM, Martin Buchholz wrote: > You are fiddling with the javadoc for getChars, which is an > independent change. (I am also fiddling with getChars in another > ongoing change). I don't think closing html tags for

  • are > required in javadoc. If you are going to change the exception > javadoc, then also change @exception to @throws. > The only reason I'm adding
    • is Alan insisted on it in a previous change I proposed :-) Jim > > On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish > wrote: > > Please review > http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ > > > These are changes that we made in lambda that we're now bringing > into JDK8. > > I've made a couple of additions - making StringJoiner final and > adding a couple of constructors to set the emptyOutput chars. > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From Alan.Bateman at oracle.com Tue Apr 16 15:50:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Apr 2013 16:50:40 +0100 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <516D6A87.2000606@oracle.com> References: <51673A45.8060908@oracle.com> <516D6A87.2000606@oracle.com> Message-ID: <516D7350.9020100@oracle.com> On 16/04/2013 16:13, Jim Gish wrote: > > On 04/15/2013 02:02 PM, Martin Buchholz wrote: >> You are fiddling with the javadoc for getChars, which is an >> independent change. (I am also fiddling with getChars in another >> ongoing change). I don't think closing html tags for
  • are >> required in javadoc. If you are going to change the exception >> javadoc, then also change @exception to @throws. >> > The only reason I'm adding
    • is Alan insisted on it in a previous > change I proposed :-) > I don't recall the full context but I have got confused by an early build of doclint where this was an issue. -Alan. From chris.hegarty at oracle.com Tue Apr 16 16:28:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Apr 2013 17:28:58 +0100 Subject: RFR : 8010953: Add primitive summary statistics utils In-Reply-To: References: Message-ID: <516D7C4A.30204@oracle.com> Looks fine to me Mike, Just a few minor inconsistencies in the @param and @return phrases, where the first word starts with a capital letter. I guess this should be lowercase for all. -Chris. On 04/16/2013 12:30 AM, Mike Duigou wrote: > Hello all; > > Another integration review in the JSR-335 libraries series. These three classes provide a utility for conveniently finding count, sum, min, max and average of ints, longs or doubles. They can be used with existing code but will most likely be used with the Collectors utilities or directly with primitive or boxed streams. > > http://cr.openjdk.java.net/~mduigou/JDK-8010953/1/webrev/ > > (this is an updated version of the webrev sent to core-libs-dev). > > Mike > From joe.darcy at oracle.com Tue Apr 16 16:35:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 16 Apr 2013 09:35:36 -0700 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D39EB.9030907@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> <516D2FBA.9080203@oracle.com> <516D39EB.9030907@oracle.com> Message-ID: <516D7DD8.5040508@oracle.com> Sorry for any inconvenience this has caused, but I'm a bit perplexed this changeset caused a problem for several reasons. First, I did a clean images build on linux with this changeset it all was well. Second, as I understand it, the Supplier type should be in compact1. -Joe On 04/16/2013 04:45 AM, Chris Hegarty wrote: > On 04/16/2013 12:02 PM, Alan Bateman wrote: >> On 16/04/2013 11:47, Chris Hegarty wrote: >>> >>> Here is a simple anti-delta patch, under 8012343: >>> "Objects.requireNonNull(Object,Supplier) breaks genstubs build" >>> >>> http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ >>> >>> Once reviewed, I will push it. We can leave it to Joe and Jon to work >>> out the more tricky genstubs issue ;-) >>> >>> -Chris. >> Bootstraping the build is complicated and I'm not 100% sure why a stub >> is generated for java.util.Objects, Jon will know. In the mean-time, the >> patch to anti-delta the change is fine. It's not nice to have to do this >> of course we need to get jdk8/tl building again. > > Pushed > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61cfbe08ce5d > > Apologies to Joe for the crude backout. On the positive side, now that > jdk8/tl is buildable again, the pressure is off to find a solution for > genstubs. > > -Chris. > >> >> -Alan From chris.hegarty at oracle.com Tue Apr 16 16:43:07 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Apr 2013 17:43:07 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D7DD8.5040508@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> <516D2FBA.9080203@oracle.com> <516D39EB.9030907@oracle.com> <516D7DD8.5040508@oracle.com> Message-ID: <516D7F9B.5030302@oracle.com> On 04/16/2013 05:35 PM, Joe Darcy wrote: > Sorry for any inconvenience this has caused, but I'm a bit perplexed > this changeset caused a problem for several reasons. > > First, I did a clean images build on linux with this changeset it all > was well. Second, as I understand it, the Supplier type should be in > compact1. If you are using jdk8 as a bootstrap then it will be ok. Maybe this explains why it built ok for you? langtools needs to build with jdk7. -Chris. > > -Joe > > On 04/16/2013 04:45 AM, Chris Hegarty wrote: >> On 04/16/2013 12:02 PM, Alan Bateman wrote: >>> On 16/04/2013 11:47, Chris Hegarty wrote: >>>> >>>> Here is a simple anti-delta patch, under 8012343: >>>> "Objects.requireNonNull(Object,Supplier) breaks genstubs build" >>>> >>>> http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ >>>> >>>> Once reviewed, I will push it. We can leave it to Joe and Jon to work >>>> out the more tricky genstubs issue ;-) >>>> >>>> -Chris. >>> Bootstraping the build is complicated and I'm not 100% sure why a stub >>> is generated for java.util.Objects, Jon will know. In the mean-time, the >>> patch to anti-delta the change is fine. It's not nice to have to do this >>> of course we need to get jdk8/tl building again. >> >> Pushed >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61cfbe08ce5d >> >> Apologies to Joe for the crude backout. On the positive side, now that >> jdk8/tl is buildable again, the pressure is off to find a solution for >> genstubs. >> >> -Chris. >> >>> >>> -Alan > From Alan.Bateman at oracle.com Tue Apr 16 16:46:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Apr 2013 17:46:20 +0100 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D7DD8.5040508@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> <516D2FBA.9080203@oracle.com> <516D39EB.9030907@oracle.com> <516D7DD8.5040508@oracle.com> Message-ID: <516D805C.7090702@oracle.com> On 16/04/2013 17:35, Joe Darcy wrote: > Sorry for any inconvenience this has caused, but I'm a bit perplexed > this changeset caused a problem for several reasons. > > First, I did a clean images build on linux with this changeset it all > was well. Second, as I understand it, the Supplier type should be in > compact1. > > -Joe > It creates a problems for langtools build (not images or profiles). The details are in langtools/makefiles/BuildLangtools.gmk. I'm not 100% sure why it creates a stub for java.util.Objects but it's this stub that won't compile with the boot JDK. -Alan. From joe.darcy at oracle.com Tue Apr 16 16:47:51 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 16 Apr 2013 09:47:51 -0700 Subject: hg: jdk8/tl/jdk: 8011800: Add java.util.Objects.requireNonNull(T, Supplier) In-Reply-To: <516D7F9B.5030302@oracle.com> References: <20130416013250.6528B4831D@hg.openjdk.java.net> <516D26FE.5050904@oracle.com> <516D2C45.2030401@oracle.com> <516D2FBA.9080203@oracle.com> <516D39EB.9030907@oracle.com> <516D7DD8.5040508@oracle.com> <516D7F9B.5030302@oracle.com> Message-ID: <516D80B7.3000800@oracle.com> On 04/16/2013 09:43 AM, Chris Hegarty wrote: > On 04/16/2013 05:35 PM, Joe Darcy wrote: >> Sorry for any inconvenience this has caused, but I'm a bit perplexed >> this changeset caused a problem for several reasons. >> >> First, I did a clean images build on linux with this changeset it all >> was well. Second, as I understand it, the Supplier type should be in >> compact1. > > If you are using jdk8 as a bootstrap then it will be ok. Maybe this > explains why it built ok for you? No; I use a recent JDK 7 update as the bootstrap. Langtools does now use methods in Objects, but not this new method. -Joe > > langtools needs to build with jdk7. > > -Chris. > >> >> -Joe >> >> On 04/16/2013 04:45 AM, Chris Hegarty wrote: >>> On 04/16/2013 12:02 PM, Alan Bateman wrote: >>>> On 16/04/2013 11:47, Chris Hegarty wrote: >>>>> >>>>> Here is a simple anti-delta patch, under 8012343: >>>>> "Objects.requireNonNull(Object,Supplier) breaks genstubs build" >>>>> >>>>> http://cr.openjdk.java.net/~chegar/8012343/webrev.00/webrev/ >>>>> >>>>> Once reviewed, I will push it. We can leave it to Joe and Jon to work >>>>> out the more tricky genstubs issue ;-) >>>>> >>>>> -Chris. >>>> Bootstraping the build is complicated and I'm not 100% sure why a stub >>>> is generated for java.util.Objects, Jon will know. In the >>>> mean-time, the >>>> patch to anti-delta the change is fine. It's not nice to have to do >>>> this >>>> of course we need to get jdk8/tl building again. >>> >>> Pushed >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61cfbe08ce5d >>> >>> Apologies to Joe for the crude backout. On the positive side, now that >>> jdk8/tl is buildable again, the pressure is off to find a solution for >>> genstubs. >>> >>> -Chris. >>> >>>> >>>> -Alan >> From kurchi.subhra.hazra at oracle.com Tue Apr 16 16:52:11 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 16 Apr 2013 09:52:11 -0700 Subject: Fwd: Latency in starting threads on Mac OS X In-Reply-To: <516D4AA2.9020701@javaspecialists.eu> References: <516D4AA2.9020701@javaspecialists.eu> Message-ID: <516D81BB.3090806@oracle.com> Forwarding to core-libs. - Kurchi -------- Original Message -------- Subject: Latency in starting threads on Mac OS X Date: Tue, 16 Apr 2013 15:57:06 +0300 From: Dr Heinz M. Kabutz Organization: JavaSpecialists.eu To: macosx-port-dev at openjdk.java.net Good day my fellow Mac OS X users! Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to demonstrate to my class how slow it was starting threads and how much better it is to use a FixedThreadPool. The question that I wanted to answer was: How many microseconds does it take on average to start a simple thread and what is the maximum time it could take? We all know that it can take in the milliseconds range to do the following: Thread t = new Thread(); // even without it actually doing anything t.start(); This is one of the reasons why the fixed thread pool only starts the threads as we submit jobs to it, since the up-front cost might not be worth the wait. But how long do you think the *maximum* was that I had to wait for t.start() to return? 100ms? 200ms? Actually, the longest I had to wait turned out to be about 250 seconds. Yes. That is *seconds*, not *milliseconds*. Just to start a single thread. This is most certainly a bug in the OpenJDK on Mac OS X. We did not see this behaviour on Linux nor on Windows 7. The bug started in OpenJDK 1.7.0_06. Prior to that it hardly ever took longer than 30ms to start a single thread. java version "1.7.0_05" heinz$ java ThreadLeakMac2 time = 1, threads = 4 time = 2, threads = 346 time = 4, threads = 7378 time = 7, threads = 9614 time = 12, threads = 10027 time = 14, threads = 10063 time = 17, threads = 26965 time = 38, threads = 27013 time = 39, threads = 452053 java version "1.7.0_06" heinz$ java ThreadLeakMac2 time = 1, threads = 6 time = 2, threads = 256 time = 6, threads = 373 *snip* time = 111, threads = 42592 time = 200, threads = 49419 time = 333, threads = 58976 *snip* time = 3245, threads = 202336 time = 3706, threads = 203702 *snip* time = 5835, threads = 267872 time = 6455, threads = 269238 time = 9170, threads = 270603 In my code, I make sure that the thread has stopped before creating the next one by calling join(). public class ThreadLeakMac2 { public static void main(String[] args) throws InterruptedException { long threads = 0; long max = 0; while(true) { long time = System.currentTimeMillis(); Thread thread = new Thread(); thread.start(); // should finish almost immediately time = System.currentTimeMillis() - time; thread.join(); // short delay, hopefully threads++; if (time> max) { max = time; System.out.println("time = " + time + ", threads = " + threads); } } } } This would be another nice test case for Alexey's concurrency stress test harness. (I also posted this to the concurrency-interest list.) Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From mike.duigou at oracle.com Tue Apr 16 17:25:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Apr 2013 10:25:44 -0700 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516C826C.4020709@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> Message-ID: <0C9BF3FD-FE57-4A19-A26E-846BDFDFC071@oracle.com> On Apr 15 2013, at 15:42 , David Holmes wrote: > On 16/04/2013 2:25 AM, Mike Duigou wrote: >> What's the difference between removing an entry completely and retaining it with "ERROR"? > > Just the nature of the error message: > > > java -green > Error: green VM not supported > > java -blue > Unrecognized option: -blue > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I wasn't touching any of the legacy stuff - though if this needs to go to CCC I would suggest removing all the legacy entries. OK. > >> Additionally I don't like that aliases have differing definitions and some confusing ones like "-server ALIASED_TO -client". Is this necessary or just historically convenient? > > I don't like aliases period! Historically (and this is very recent history) it was necessary to deal with the test suites being applied to a JDK with, eg, only client VM. Every test that specified -server would fail if the alias didn't exist (and as I stated we're moving away from that ie the tests don't set -client or -server but the complete test suite run does, and it knows what VM is under test. > > Personally I'd probably choose WARN for any VM not present. > > The problem is that the "right" thing depends on who is building what, and how they plan to use it. All I can do is define a not-unreasonable default policy. I also have a time constraint as I need to get this in before the 23rd to meet an internal deadline. Understood. Mike From mandy.chung at oracle.com Tue Apr 16 17:51:05 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Apr 2013 10:51:05 -0700 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516C826C.4020709@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> Message-ID: <516D8F89.90506@oracle.com> On 4/15/2013 3:42 PM, David Holmes wrote: > FYI updated webrev at same location, removing the dead code Erik spotted. > > http://cr.openjdk.java.net/~dholmes/8010280/webrev/ > Looks good to me. Nit: CopyFiles.gmk line 340 - you may want to remove the extra space to align with the next line. > I've attached all the generated versions below. Thanks for the generated files that are helpful for the review. Have you considered adding a simple sanity test, if not present, to validate jvm.cfg matches with the vm binaries bundled in JAVA_HOME? Just a thought and maybe you can file a RFE to add such a test later if you think it's a good idea. Mandy From mike.duigou at oracle.com Tue Apr 16 18:04:45 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Apr 2013 11:04:45 -0700 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: <516C8981.3070804@CoSoCo.de> References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> <516988FB.8070501@CoSoCo.de> <516C8981.3070804@CoSoCo.de> Message-ID: On Apr 15 2013, at 16:13 , Ulf Zibis wrote: > Am 15.04.2013 23:06, schrieb Mike Duigou: >> That's because I'm not the only author. I get to fix it though, the glamourous life of a JDK janitor. :-) > > ;-) > >>> HashTable line 917, 938, 984 etc. >>> HashMap line 588 etc. >>> Collections line 1402 etc. >> Should be more consistent now. I'm not willing to attempt correct this non-problem more broadly. > > HashTable line 972, 992, 1011, 1035, 1064, 1099, etc. These don't seem to line up with anything in either rev 5 or 6 of Hashtable source (or HashMap). > >>>>> Collections: >>>>> lines 1442... + 3900... , indentation for follow up line should be 8 >>> There are still lines 976, 1062 >> Of which file? According to http://cr.openjdk.java.net/~mduigou/JDK-8010122/5/webrev/src/share/classes/java/util/Collections.java.html >> >> neither of those lines seems applicable. > > Oops I'm sorry, I meant lines 976, 1062 of Map. Corrected. > In Collections I've found additional inconsistent indentations, lines 2836, 2837, 2848, 2853, 2897 Corrected. > Old code: 262, 270, 292, 1248, 1304, 1528, 1580, 1611, 1784, 1873, 1995, 2036, 2092, 2304, 2414, 2460, 2694, 2760, 2770, 2819, 3032, 3071, 3118, 3155, 3164, 3214, 3273, 3318, 3322, 3358, 3397, 3446, 3559, 3633, 3756, 3790, 3809, 3832, 3867, 3965, 4014, 4070, 4109, 4133, 4301, 4381, 4413, 4445. I am unwilling to change most of these. Thank you for your careful review. You definitely have sharper eyes than most for this kind of problem. Mike From mike.duigou at oracle.com Tue Apr 16 18:18:37 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 16 Apr 2013 18:18:37 +0000 Subject: hg: jdk8/tl/jdk: 8004518: Add in-place operations to Map; ... Message-ID: <20130416181924.D86F84833E@hg.openjdk.java.net> Changeset: e4e9f6455f3c Author: mduigou Date: 2013-04-16 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4e9f6455f3c 8004518: Add in-place operations to Map 8010122: Add defaults for ConcurrentMap operations to Map Reviewed-by: darcy, briangoetz, mduigou, dholmes, ulfzibis Contributed-by: Doug Lea
    , Henry Jen , Akhil Arora , Peter Levart , Mike Duigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java + test/java/util/Map/Defaults.java From mike.duigou at oracle.com Tue Apr 16 19:35:38 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Apr 2013 12:35:38 -0700 Subject: RFR : 8010953: Add primitive summary statistics utils In-Reply-To: <516D7C4A.30204@oracle.com> References: <516D7C4A.30204@oracle.com> Message-ID: <94F9EFA0-593A-48A6-933D-2E79C42BAD3C@oracle.com> On Apr 16 2013, at 09:28 , Chris Hegarty wrote: > Looks fine to me Mike, > > Just a few minor inconsistencies in the @param and @return phrases, where the first word starts with a capital letter. I guess this should be lowercase for all. Corrected. > -Chris. > > On 04/16/2013 12:30 AM, Mike Duigou wrote: >> Hello all; >> >> Another integration review in the JSR-335 libraries series. These three classes provide a utility for conveniently finding count, sum, min, max and average of ints, longs or doubles. They can be used with existing code but will most likely be used with the Collectors utilities or directly with primitive or boxed streams. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010953/1/webrev/ >> >> (this is an updated version of the webrev sent to core-libs-dev). >> >> Mike >> From mike.duigou at oracle.com Tue Apr 16 19:45:26 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Apr 2013 12:45:26 -0700 Subject: RFR : 8010953: Add primitive summary statistics utils In-Reply-To: <516D2389.2050609@oracle.com> References: <516D2389.2050609@oracle.com> Message-ID: <3E218825-9EE6-4F59-BC76-6424A6C67F19@oracle.com> On Apr 16 2013, at 03:10 , David Holmes wrote: > Hi Mike, > > On 16/04/2013 9:30 AM, Mike Duigou wrote: >> Hello all; >> >> Another integration review in the JSR-335 libraries series. These three classes provide a utility for conveniently finding count, sum, min, max and average of ints, longs or doubles. They can be used with existing code but will most likely be used with the Collectors utilities or directly with primitive or boxed streams. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8010953/1/webrev/ >> >> (this is an updated version of the webrev sent to core-libs-dev). > > A couple of minor nits: > > DoubleSummaryStatistics: > > getMin/getMax: > > The main doc should read the same as the @return. Presently the initial sentence: > > 120 * Returns the recorded value closest to {@code Double.NEGATIVE_INFINITY}, > 121 * {@code Double.POSITIVE_INFINITY} if no values have been recorded or if > 122 * any recorded value is NaN, then the result is NaN. > > if very difficult to read and parse. The @return is much simpler - just say minimum/maximum value recorded, rather than "value closest to ...". Done. (the "value closest to ..." text was copied from Math.min/max"). > > In all classes: > > minimal -> minimum > maximal -> maximum Done. > David > >> Mike >> From chris.hegarty at oracle.com Tue Apr 16 20:40:59 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 20:40:59 +0000 Subject: hg: jdk8/tl/hotspot: 2 new changesets Message-ID: <20130416204106.A31E14834A@hg.openjdk.java.net> Changeset: 3d641132f83b Author: twisti Date: 2013-02-26 16:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d641132f83b 8004336: Better handling of method handle intrinsic frames Reviewed-by: kvn, jrose, ahgross ! src/share/vm/opto/library_call.cpp Changeset: 124ca22437b1 Author: chegar Date: 2013-04-12 10:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/124ca22437b1 Merge ! src/share/vm/opto/library_call.cpp From chris.hegarty at oracle.com Tue Apr 16 20:42:53 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 20:42:53 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130416204300.57BAD4834C@hg.openjdk.java.net> Changeset: 10db50a26b39 Author: joehw Date: 2013-02-18 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/10db50a26b39 6657673: Issues with JAXP Reviewed-by: alanb, lancea, ahgross, mullan ! src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java ! src/com/sun/org/apache/bcel/internal/util/Class2HTML.java ! src/com/sun/org/apache/bcel/internal/util/ClassPath.java ! src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java + src/com/sun/org/apache/bcel/internal/util/SecuritySupport.java ! src/com/sun/org/apache/xalan/internal/res/XSLMessages.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/com/sun/org/apache/xalan/internal/xslt/Process.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java ! src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java ! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/com/sun/org/apache/xml/internal/res/XMLMessages.java ! src/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/com/sun/org/apache/xml/internal/resolver/Resolver.java ! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/com/sun/org/apache/xml/internal/serializer/Encodings.java ! src/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java ! src/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java ! src/com/sun/org/apache/xml/internal/serializer/utils/Messages.java ! src/com/sun/org/apache/xml/internal/utils/TreeWalker.java ! src/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java ! src/com/sun/org/apache/xpath/internal/res/XPATHMessages.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/javax/xml/datatype/FactoryFinder.java ! src/javax/xml/parsers/FactoryFinder.java ! src/javax/xml/stream/FactoryFinder.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java ! src/org/w3c/dom/bootstrap/DOMImplementationRegistry.java ! src/org/xml/sax/helpers/NewInstance.java ! src/org/xml/sax/helpers/ParserAdapter.java ! src/org/xml/sax/helpers/ParserFactory.java + src/org/xml/sax/helpers/SecuritySupport.java ! src/org/xml/sax/helpers/XMLReaderFactory.java Changeset: 3f9817b8b0e0 Author: chegar Date: 2013-04-12 10:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3f9817b8b0e0 Merge From chris.hegarty at oracle.com Tue Apr 16 20:43:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 16 Apr 2013 20:43:49 +0000 Subject: hg: jdk8/tl/jdk: 37 new changesets Message-ID: <20130416205113.B712E4834D@hg.openjdk.java.net> Changeset: c5ead5aa2e13 Author: bae Date: 2013-02-07 19:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5ead5aa2e13 8007014: Improve image handling Reviewed-by: prr, mschoene, jgodinez ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/BytePackedRaster.java ! src/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/safe_alloc.h + src/share/native/sun/awt/medialib/safe_math.h Changeset: c95973aac928 Author: malenkov Date: 2013-02-08 17:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c95973aac928 7200507: Refactor Introspector internals Reviewed-by: ahgross, art ! src/share/classes/java/beans/ThreadGroupContext.java + src/share/classes/java/beans/WeakIdentityMap.java Changeset: 210fb90ee33a Author: michaelm Date: 2013-02-13 10:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/210fb90ee33a 8000724: Improve networking serialization Summary: delegate InetAddress fields to a holder object Reviewed-by: alanb, chegar ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/native/java/net/InetAddress.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c Changeset: 5ffba58b541f Author: valeriep Date: 2013-02-26 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ffba58b541f 8000897: VM crash in CompileBroker Summary: Fixed to use the corresponding digest length when generating output. Reviewed-by: mullan ! src/share/classes/sun/security/provider/SHA2.java Changeset: 96890625ebdf Author: smarks Date: 2013-02-27 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96890625ebdf 8001040: Rework RMI model Reviewed-by: alanb, ahgross, coffeys, dmocek ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/security.policy ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java + test/java/rmi/server/RMIClassLoader/useCodebaseOnlyDefault/UseCodebaseOnlyDefault.java ! test/java/rmi/testlibrary/RMID.java Changeset: f12921c0b15b Author: dfuchs Date: 2013-03-14 13:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f12921c0b15b 8001322: Refactor deserialization Reviewed-by: mchung, skoivu, smarks ! src/share/classes/java/io/ObjectInputStream.java Changeset: bae4a15265d3 Author: dmocek Date: 2013-02-05 16:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bae4a15265d3 8001329: Augment RMI logging Reviewed-by: smarks, hawtin, alanb ! src/share/classes/java/rmi/server/LogStream.java Changeset: c876e9321616 Author: chegar Date: 2012-12-20 13:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c876e9321616 8003335: Better handling of Finalizer thread Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ref/Finalizer.java Changeset: 0c5c54303c92 Author: serb Date: 2013-02-15 13:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c5c54303c92 8004261: Improve input validation Reviewed-by: art, mschoene, amenkov ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/FastShortMessage.java ! src/share/classes/com/sun/media/sound/FastSysexMessage.java ! src/share/classes/com/sun/media/sound/MidiOutDevice.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java Changeset: 3d155555f809 Author: uta Date: 2013-02-22 17:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d155555f809 8005942: (process) Improved Runtime.exec Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ProcessBuilder.java ! src/windows/classes/java/lang/ProcessImpl.java Changeset: cf01f2847551 Author: dsamersoff Date: 2013-03-05 00:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf01f2847551 8006435: Improvements in JMX Summary: Improvements in JMX Reviewed-by: dfuchs, skoivu, alanb, mchung ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java Changeset: 4effe291c08b Author: prr Date: 2013-02-08 09:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4effe291c08b 8006795: Improve font warning messages Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/CMap.java Changeset: 9b4bee66fa24 Author: bae Date: 2013-02-19 11:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b4bee66fa24 8007617: Better validation of images Reviewed-by: prr, mschoene, jgodinez ! src/share/classes/sun/awt/image/ImageRepresentation.java ! src/share/native/sun/awt/image/awt_ImageRep.c Changeset: 620a08212c79 Author: bae Date: 2013-02-26 00:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/620a08212c79 8007667: Better image reading Reviewed-by: prr, jgodinez, mschoene ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 2deab0b85b82 Author: bae Date: 2013-02-26 01:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2deab0b85b82 8007918: Better image writing Reviewed-by: mschoene, prr, jgodinez ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: f7b331b8661f Author: chegar Date: 2013-03-03 10:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7b331b8661f 8009063: Improve reliability of ConcurrentHashMap Reviewed-by: alanb, ahgross ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 5c2c8fb0b885 Author: dfuchs Date: 2013-03-14 18:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c2c8fb0b885 8009305: Improve AWT data transfer Reviewed-by: art, skoivu, smarks, ant ! src/share/classes/sun/awt/datatransfer/TransferableProxy.java Changeset: af881cbec91e Author: uta Date: 2013-03-08 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af881cbec91e 8009463: Regression test test\java\lang\Runtime\exec\ArgWithSpaceAndFinalBackslash.java failing. Reviewed-by: alanb, ahgross ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 633fd0b99a8d Author: valeriep Date: 2013-03-11 20:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/633fd0b99a8d 8009610: Blacklist certificate used with malware. Summary: updated the black list and the reg test with the new cert. Reviewed-by: weijun ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: 37296d45a11e Author: lancea Date: 2013-03-18 13:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37296d45a11e 8009814: Better driver management Reviewed-by: alanb, skoivu ! src/share/classes/java/sql/DriverManager.java Changeset: fa919c17da9f Author: smarks Date: 2013-03-18 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fa919c17da9f 8009857: Problem with plugin Reviewed-by: jdn, mchung ! src/share/classes/sun/reflect/misc/MethodUtil.java Changeset: 4267ae18e13a Author: prr Date: 2013-02-15 13:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4267ae18e13a 8008249: Sync ICU into JDK Reviewed-by: bae, jgodinez ! make/sun/font/FILES_c.gmk ! src/share/native/sun/font/layout/ContextualGlyphInsertion.h + src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp + src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h + src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp + src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h ! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h + src/share/native/sun/font/layout/GXLayoutEngine2.cpp + src/share/native/sun/font/layout/GXLayoutEngine2.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicRearrangement.h + src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp + src/share/native/sun/font/layout/IndicRearrangementProcessor2.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h + src/share/native/sun/font/layout/LigatureSubstProc2.cpp + src/share/native/sun/font/layout/LigatureSubstProc2.h ! src/share/native/sun/font/layout/LigatureSubstitution.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MorphStateTables.h ! src/share/native/sun/font/layout/MorphTables.h + src/share/native/sun/font/layout/MorphTables2.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubst.h + src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp + src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h + src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp + src/share/native/sun/font/layout/SegmentArrayProcessor2.h + src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp + src/share/native/sun/font/layout/SegmentSingleProcessor2.h + src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp + src/share/native/sun/font/layout/SimpleArrayProcessor2.h + src/share/native/sun/font/layout/SingleTableProcessor2.cpp + src/share/native/sun/font/layout/SingleTableProcessor2.h + src/share/native/sun/font/layout/StateTableProcessor2.cpp + src/share/native/sun/font/layout/StateTableProcessor2.h ! src/share/native/sun/font/layout/StateTables.h + src/share/native/sun/font/layout/SubtableProcessor2.cpp + src/share/native/sun/font/layout/SubtableProcessor2.h + src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp + src/share/native/sun/font/layout/TrimmedArrayProcessor2.h Changeset: 43f2d3d715c5 Author: prr Date: 2013-02-26 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43f2d3d715c5 8004986: Better handling of glyph table 8004987: Improve font layout 8004994: Improve checking of glyph table Reviewed-by: srl, jgodinez ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc2.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor2.cpp ! src/share/native/sun/font/layout/StateTables.h Changeset: 32778f4f945f Author: prr Date: 2013-03-07 10:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32778f4f945f 8001031: Better font processing Reviewed-by: srl, vadim ! src/share/native/sun/font/FontInstanceAdapter.cpp ! src/share/native/sun/font/FontInstanceAdapter.h ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AlternateSubstSubtables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/ArabicShaping.h ! src/share/native/sun/font/layout/AttachmentPosnSubtables.h ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp ! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GXLayoutEngine2.cpp ! src/share/native/sun/font/layout/GXLayoutEngine2.h ! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp ! src/share/native/sun/font/layout/GlyphDefinitionTables.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphLookupTables.cpp ! src/share/native/sun/font/layout/GlyphLookupTables.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h ! src/share/native/sun/font/layout/HangulLayoutEngine.cpp ! src/share/native/sun/font/layout/HangulLayoutEngine.h ! src/share/native/sun/font/layout/ICUFeatures.h ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor2.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/LEScripts.h + src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.h ! src/share/native/sun/font/layout/LigatureSubstProc2.cpp ! src/share/native/sun/font/layout/LigatureSubstProc2.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/LookupTables.cpp ! src/share/native/sun/font/layout/LookupTables.h ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/Lookups.h ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables.h ! src/share/native/sun/font/layout/MorphTables2.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.h ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor2.h ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.h ! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor2.h ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.h ! src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor2.h ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.h ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h ! src/share/native/sun/font/layout/SingleTableProcessor.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.h ! src/share/native/sun/font/layout/SingleTableProcessor2.cpp ! src/share/native/sun/font/layout/SingleTableProcessor2.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor.h ! src/share/native/sun/font/layout/StateTableProcessor2.cpp ! src/share/native/sun/font/layout/StateTableProcessor2.h ! src/share/native/sun/font/layout/StateTables.h ! src/share/native/sun/font/layout/SubtableProcessor.cpp ! src/share/native/sun/font/layout/SubtableProcessor.h ! src/share/native/sun/font/layout/SubtableProcessor2.cpp ! src/share/native/sun/font/layout/SubtableProcessor2.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/TibetanLayoutEngine.cpp ! src/share/native/sun/font/layout/TibetanLayoutEngine.h ! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.h ! src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor2.h ! src/share/native/sun/font/layout/ValueRecords.h ! src/share/native/sun/font/sunFont.c Changeset: 7b03efca912f Author: malenkov Date: 2013-02-05 20:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b03efca912f 8006790: Improve checking for windows Reviewed-by: art, mschoene ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 4ea6d44a20a0 Author: mullan Date: 2013-03-27 10:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ea6d44a20a0 8003445: Adjust JAX-WS to focus on API Reviewed-by: vinnie, ahgross, mgrebac ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: c921d68edf08 Author: joehw Date: 2013-02-18 13:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c921d68edf08 6657673: Issues with JAXP Reviewed-by: alanb, lancea, ahgross, mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 6a09e4648cfb Author: mkos Date: 2013-03-07 07:19 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a09e4648cfb 8005432: Update access to JAX-WS Summary: newly restricted the whole package com.sun.xml.internal; fix reviewed also by Alexander Fomin Reviewed-by: mullan, skoivu ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 12ca12303c33 Author: raginip Date: 2013-03-27 21:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12ca12303c33 8007406: Improve accessibility of AccessBridge Reviewed-by: skoivu, mullan, ptbrunet ! src/share/lib/security/java.security-windows Changeset: 269b7955a885 Author: chegar Date: 2013-03-28 09:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/269b7955a885 8010944: Incorrectly separated package list in java.security-windows Reviewed-by: mullan ! src/share/lib/security/java.security-windows Changeset: 7c663f528ff6 Author: vlivanov Date: 2013-03-01 04:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c663f528ff6 8008140: Better method handle resolution Reviewed-by: jrose, twisti, jdn ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 0fb15205acb6 Author: bae Date: 2013-02-19 12:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fb15205acb6 8007675: Improve color conversion Reviewed-by: prr, mschoene, jgodinez ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java Changeset: b057eaf53935 Author: chegar Date: 2013-04-04 17:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b057eaf53935 Merge ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java Changeset: 5f46a666e06d Author: chegar Date: 2013-04-13 20:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f46a666e06d Merge ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/windows/classes/java/lang/ProcessImpl.java ! test/Makefile Changeset: 84df34924f67 Author: chegar Date: 2013-04-13 21:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84df34924f67 Merge - src/share/classes/java/time/chrono/HijrahDeviationReader.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java - test/java/time/tck/java/time/TestChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/util/ComparatorsTest.java Changeset: 9246b0fee2f2 Author: chegar Date: 2013-04-16 13:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9246b0fee2f2 Merge Changeset: 10fd3b4a77ae Author: chegar Date: 2013-04-16 21:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10fd3b4a77ae Merge From james.graham at oracle.com Tue Apr 16 21:16:47 2013 From: james.graham at oracle.com (Jim Graham) Date: Tue, 16 Apr 2013 14:16:47 -0700 Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements In-Reply-To: References: Message-ID: <516DBFBF.20504@oracle.com> If I'm reading this correctly, your patch is faster even for a single thread? That's great news. One of the problems we've had with replacing Ductus is that it has been faster in a single thread situation than the open source versions we've created. One of its drawbacks is that it had been designed to take advantage of some AA-accelerating hardware that never came to be. With the accelerator it would have been insanely fast, but hardware went in a different direction. The problem was that this early design goal caused the entire library to be built around an abstraction layer that allowed for a single "tile producer" internally (because there would be only one - insanely fast - hardware chip available) and the software version of the abstraction layer thus had a lot of native "static" data structures (there's only one of me, right?) that prevented MT access. It was probably solvable, but I'd be happier if someone could come up with a faster rasterizer, imagining that there must have been some sort of advancements in the nearly 2 decades since the original was written. If I'm misinterpreting and single thread is still slower than Ductus (or if it is still slower on some other platforms), then . Also, this is with the Java version, right? We got a decent 2x speedup in FX by porting the version of Open Pisces that you started with to C code (all except on Linux where we couldn't find the right gcc options to make it faster than Hotspot). So, we have yet to investigate a native version in the JDK which might provide even more gains... ...jim On 4/15/13 3:01 AM, Laurent Bourg?s wrote: > Jim, Andrea, > > I updated MapBench to provide test statistics (avg, median, stddev, rms, > med + stddev, min, max) and CSV output (tab separator): > http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/ > > > > Here are the results (OpenJDK8 Ref vs Patched): > http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log > http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log > > test threads ops Tavg Tmed stdDev rms Med+Stddev min max > boulder_17 1 20 180,22% 181,08% 1186,01% 181,17% 185,92% > 176,35% 170,36% > boulder_17 2 20 183,15% 183,80% 162,68% 183,78% 183,17% > 174,01% 169,89% > boulder_17 4 20 216,62% 218,03% 349,31% 218,87% 226,68% > 172,15% 167,54% > shp_alllayers_47 1 20 243,90% 244,86% 537,92% 244,87% 246,39% > 240,64% 231,00% > shp_alllayers_47 2 20 286,42% 287,07% 294,87% 287,07% 287,23% > 277,19% 272,23% > shp_alllayers_47 4 20 303,08% 302,15% 168,19% 301,90% 295,90% > 462,70% 282,41% > > > > PATCH: > test threads ops Tavg Tmed stdDev rms Med+Stddev min max > boulder_17 1 20 110,196 109,244 0,529 109,246 109,773 108,197 > 129,327 > boulder_17 2 40 127,916 127,363 3,899 127,423 131,262 125,262 > 151,561 > boulder_17 4 80 213,085 212,268 14,988 212,796 227,256 155,512 > 334,407 > shp_alllayers_47 1 20 1139,452 1134,858 5,971 1134,873 1140,829 > 1125,859 1235,746 > shp_alllayers_47 2 40 1306,889 1304,598 28,157 1304,902 > 1332,755 1280,49 1420,351 > shp_alllayers_47 4 80 2296,487 2303,81 112,816 2306,57 2416,626 > 1390,31 2631,455 > > > > REF: > test threads ops Tavg Tmed stdDev rms Med+Stddev min max > boulder_17 1 20 198,591 197,816 6,274 197,916 204,091 190,805 > 220,319 > boulder_17 2 40 234,272 234,09 6,343 234,176 240,433 217,967 > 257,485 > boulder_17 4 80 461,579 462,8 52,354 465,751 515,153 267,712 > 560,254 > shp_alllayers_47 1 20 2779,133 2778,823 32,119 2779,009 > 2810,943 2709,285 2854,557 > shp_alllayers_47 2 40 3743,255 3745,111 83,027 3746,031 > 3828,138 3549,364 3866,612 > shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698 > 6432,945 7431,541 > > > Linux 64 server vm > JVM: -Xms128m -Xmx128m (low mem) > > Laurent > > 2013/4/14 Andrea Aime > > > On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s > > wrote: > > Dear Java2D members, > > Could someone review the following webrev concerning Java2D > Pisces to enhance its performance and reduce its memory > footprint (RendererContext stored in thread local or concurrent > queue): > http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ > > > FYI I fixed file headers in this patch and signed my OCA 3 weeks > ago. > > Remaining work: > - cleanup (comments ...) > - statistics to perform auto-tuning > - cache / memory cleanup (SoftReference ?): use hints or System > properties to adapt it to use cases > - another problem: fix clipping performance in Dasher / Stroker > for segments out of bounds > > Could somebody support me ? ie help me working on these tasks or > just to discuss on Pisces algorithm / implementation ? > > > Hi, > I would like to express my support for this patch. > Given that micro-benchmarks have already been run, I took the patch > for a spin in a large, real world benchmark instead, > the OSGeo WMS Shootout 2010 benchmark, for which you can see the > results here: > http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010 > > The presentation is long, but suffice it to say all Java based > implementations took quite the beating due to the > poor scalability of Ductus with antialiased rendering of vector data > (for an executive summary just look > at slide 27 and slide 66, where GeoServer, Oracle MapViewer and > Constellation SDI were the > Java based ones) > > I took the same tests and run them again on my machine (different > hardware than the tests, don't try to compare > the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a > checkout a couple of weeks old) and the > same, but with Laurent's patches applied. > Here are the results, throughput (in maps generated per second) with > the load generator (JMeter) going > up from one client to 64 concurrent clients: > > *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces > renderer improvements* *Pisces renderer performance gain, %* > 1 13,97 12,43 13,03 4,75% > 2 22,08 20,60 20,77 0,81% > 4 34,36 33,15 33,36 0,62% > 8 39,39 40,51 41,71 2,96% > 16 40,61 44,57 46,98 5,39% > 32 41,41 44,73 48,16 7,66% > 64 37,09 42,19 45,28 7,32% > > > Well, first of all, congratulations to the JDK developers, don't > know what changed in JDK 8, but > GeoServer seems to like it quite a bit :-). > That said, Laurent's patch also gives a visible boost, especially > when several concurrent clients are > asking for the maps. > > Mind, as I said, this is no micro-benchmark, it is a real > application loading doing a lot of I/O > (from the operating system file cache), other processing before the > data reaches the rendering > pipeline, and then has to PNG encode the output BufferedImage (PNG > encoding being rather > expensive), so getting this speedup from just a change in the > rendering pipeline is significant. > > Long story short... personally I'd be very happy if this patch was > going to be integrated in Java 8 :-) > > Cheers > Andrea > > -- > == > GeoServer training in Milan, 6th & 7th June 2013! Visit > http://geoserver.geo-solutions.it > for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > From mike.duigou at oracle.com Tue Apr 16 22:50:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 16 Apr 2013 15:50:39 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <516D7350.9020100@oracle.com> References: <51673A45.8060908@oracle.com> <516D6A87.2000606@oracle.com> <516D7350.9020100@oracle.com> Message-ID: <7A07E10F-BC21-4A7E-9ED8-38F280E65AF2@oracle.com> On Apr 16 2013, at 08:50 , Alan Bateman wrote: > On 16/04/2013 16:13, Jim Gish wrote: >> >> On 04/15/2013 02:02 PM, Martin Buchholz wrote: >>> You are fiddling with the javadoc for getChars, which is an independent change. (I am also fiddling with getChars in another ongoing change). I don't think closing html tags for
  • are required in javadoc. If you are going to change the exception javadoc, then also change @exception to @throws. >>> >> The only reason I'm adding
    • is Alan insisted on it in a previous change I proposed :-) >> > I don't recall the full context but I have got confused by an early build of doclint where this was an issue. is required by XHTML but not by HTML. doclint was too aggressive about this in early builds. Having does no harm but it's not required. Mike > -Alan. From Ulf.Zibis at CoSoCo.de Tue Apr 16 23:21:23 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 17 Apr 2013 01:21:23 +0200 Subject: RFR: 8004518 & 8010122 : Default methods on Map In-Reply-To: References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com> <314D48CD-EE51-419A-A29B-DC4F4B1BC238@oracle.com> <516735F0.6080705@CoSoCo.de> <516988FB.8070501@CoSoCo.de> <516C8981.3070804@CoSoCo.de> Message-ID: <516DDCF3.6020406@CoSoCo.de> Am 16.04.2013 20:04, schrieb Mike Duigou: > On Apr 15 2013, at 16:13 , Ulf Zibis wrote: > >> HashTable line 972, 992, 1011, 1035, 1064, 1099, etc. > These don't seem to line up with anything in either rev 5 or 6 of Hashtable source (or HashMap). Oops again, these were numbers from rev. 2. I see, you have them corrected in rev. 6. :-) There only remains one in line 477. >> Oops I'm sorry, I meant lines 976, 1062 of Map. > Corrected. I don't see correction in rev. 6, now lines 982, 1068 Additionally lines 507, 508, 952..960 >> In Collections I've found additional inconsistent indentations, lines 2836, 2837, 2848, 2853, 2897 > Corrected. I don't see correction in rev. 6, now lines 2838, 2839, 2850, 2855, 2899(also space after casts) >> Old code: 262, 270, 292, 1248, 1304, 1528, 1580, 1611, 1784, 1873, 1995, 2036, 2092, 2304, 2414, 2460, 2694, 2760, 2770, 2819, 3032, 3071, 3118, 3155, 3164, 3214, 3273, 3318, 3322, 3358, 3397, 3446, 3559, 3633, 3756, 3790, 3809, 3832, 3867, 3965, 4014, 4070, 4109, 4133, 4301, 4381, 4413, 4445. > I am unwilling to change most of these. I agree, that's why I've written "old code". > Thank you for your careful review. You definitely have sharper eyes than most for this kind of problem. They instantly jump in my eye ;-) I first thought, there were few, but then ... I couldn't resist to *play* the full game ;-) Thanks for your time, -Ulf From david.holmes at oracle.com Wed Apr 17 01:27:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Apr 2013 11:27:41 +1000 Subject: Fwd: Latency in starting threads on Mac OS X In-Reply-To: <516D81BB.3090806@oracle.com> References: <516D4AA2.9020701@javaspecialists.eu> <516D81BB.3090806@oracle.com> Message-ID: <516DFA8D.4070808@oracle.com> As I've pointed out to Heinz on the concurrency-interest list there are a couple of flawed assumptions in his test: a) when you start() a new thread the OS scheduler may switch to it immediately (this depends on the scheduler semantics) b) Thread.join only signifies logical termination of the Java thread. The native thread still has to exit the VM and the OS and so can encounter additional bottlenecks that result in many more threads being existent than expected and which can interfere with the creation of new threads. I don't know specifically what may have changed between 7u5 and 7u6 in that regard but I think it would be a hotspot issue more than a libraries issue. I know 7u6 was the first version of JDK to fully support OS X. David On 17/04/2013 2:52 AM, Kurchi Subhra Hazra wrote: > Forwarding to core-libs. > > - Kurchi > > -------- Original Message -------- > Subject: Latency in starting threads on Mac OS X > Date: Tue, 16 Apr 2013 15:57:06 +0300 > From: Dr Heinz M. Kabutz > Organization: JavaSpecialists.eu > To: macosx-port-dev at openjdk.java.net > > > > Good day my fellow Mac OS X users! > > Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to > demonstrate to my class how slow it was starting threads and how much > better it is to use a FixedThreadPool. The question that I wanted to > answer was: How many microseconds does it take on average to start a > simple thread and what is the maximum time it could take? > > We all know that it can take in the milliseconds range to do the following: > > Thread t = new Thread(); // even without it actually doing anything > t.start(); > > This is one of the reasons why the fixed thread pool only starts the > threads as we submit jobs to it, since the up-front cost might not be > worth the wait. > > But how long do you think the *maximum* was that I had to wait for > t.start() to return? 100ms? 200ms? > > Actually, the longest I had to wait turned out to be about 250 seconds. > Yes. That is *seconds*, not *milliseconds*. Just to start a single > thread. > > This is most certainly a bug in the OpenJDK on Mac OS X. We did not see > this behaviour on Linux nor on Windows 7. > > The bug started in OpenJDK 1.7.0_06. Prior to that it hardly ever took > longer than 30ms to start a single thread. > > java version "1.7.0_05" > heinz$ java ThreadLeakMac2 > time = 1, threads = 4 > time = 2, threads = 346 > time = 4, threads = 7378 > time = 7, threads = 9614 > time = 12, threads = 10027 > time = 14, threads = 10063 > time = 17, threads = 26965 > time = 38, threads = 27013 > time = 39, threads = 452053 > > java version "1.7.0_06" > heinz$ java ThreadLeakMac2 > time = 1, threads = 6 > time = 2, threads = 256 > time = 6, threads = 373 > *snip* > time = 111, threads = 42592 > time = 200, threads = 49419 > time = 333, threads = 58976 > *snip* > time = 3245, threads = 202336 > time = 3706, threads = 203702 > *snip* > time = 5835, threads = 267872 > time = 6455, threads = 269238 > time = 9170, threads = 270603 > > In my code, I make sure that the thread has stopped before creating the > next one by calling join(). > > public class ThreadLeakMac2 { > public static void main(String[] args) throws InterruptedException { > long threads = 0; > long max = 0; > while(true) { > long time = System.currentTimeMillis(); > Thread thread = new Thread(); > thread.start(); // should finish almost immediately > time = System.currentTimeMillis() - time; > thread.join(); // short delay, hopefully > threads++; > if (time> max) { > max = time; > System.out.println("time = " + time + > ", threads = " + threads); > } > } > } > } > > This would be another nice test case for Alexey's concurrency stress > test harness. > > (I also posted this to the concurrency-interest list.) > > Regards > > Heinz From weijun.wang at oracle.com Wed Apr 17 02:16:02 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 17 Apr 2013 02:16:02 +0000 Subject: hg: jdk8/tl/jdk: 8011124: Make KerberosTime immutable Message-ID: <20130417021627.5E8C34836F@hg.openjdk.java.net> Changeset: a3cc4b8e217a Author: weijun Date: 2013-04-17 10:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3cc4b8e217a 8011124: Make KerberosTime immutable Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAppMessage.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReqEntry.java ! src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! test/sun/security/krb5/MicroTime.java From david.holmes at oracle.com Wed Apr 17 02:27:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Apr 2013 12:27:48 +1000 Subject: How to deal with a missing VM? (was Re: RFR 8010280: jvm.cfg needs updating for non-server builds) In-Reply-To: <516C826C.4020709@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> Message-ID: <516E08A4.6090000@oracle.com> This change to the jvm.cfg file needs to be put through our internal CCC process for approval. Given that, and that this is mostly about policy (not mechanism) and there is no absolute right answer just a not-unreasonable default, I thought I would solicit opinions on this. what should be the behaviour if you ask for a VM that could be, but isn't present? Options: a) Missing from jvm.cfg so VM error: Unrecognized option: -client Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. b) ERROR in jvm.cfg Error: client VM not supported c) WARN in jvm.cfg Warning: client VM not supported; VM will be used d) ALIAS to default (which is in effect a silent warning but with control over which VM to use) e) IGNORE (which seems to be a degenerate case of ALIAS as it just uses the default) Note that this has no affect on the Oracle JDK (SE or Embedded) as the committed jvm.cfg (possibly with '-minimal KNOWN' added) will be used. This is primarily about developer builds. Thanks, David On 16/04/2013 8:42 AM, David Holmes wrote: > FYI updated webrev at same location, removing the dead code Erik spotted. > > http://cr.openjdk.java.net/~dholmes/8010280/webrev/ > > On 16/04/2013 2:25 AM, Mike Duigou wrote: >> Hi David; >> >> I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped >> to see the "classic" and "green" flags go away and some of the other >> legacy flags like "-hotspot" reduced to WARN. What's the difference >> between removing an entry completely and retaining it with "ERROR"? > > Just the nature of the error message: > > > java -green > Error: green VM not supported > > java -blue > Unrecognized option: -blue > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I wasn't touching any of the legacy stuff - though if this needs to go > to CCC I would suggest removing all the legacy entries. > >> Additionally I don't like that aliases have differing definitions and >> some confusing ones like "-server ALIASED_TO -client". Is this >> necessary or just historically convenient? > > I don't like aliases period! Historically (and this is very recent > history) it was necessary to deal with the test suites being applied to > a JDK with, eg, only client VM. Every test that specified -server would > fail if the alias didn't exist (and as I stated we're moving away from > that ie the tests don't set -client or -server but the complete test > suite run does, and it knows what VM is under test. > > Personally I'd probably choose WARN for any VM not present. > > The problem is that the "right" thing depends on who is building what, > and how they plan to use it. All I can do is define a not-unreasonable > default policy. I also have a time constraint as I need to get this in > before the 23rd to meet an internal deadline. > > I've attached all the generated versions below. > > Thanks, > David > > :::::::::::::: > linux-i586-client/jdk/lib/i386/jvm.cfg > :::::::::::::: > -client KNOWN > -server ALIASED_TO -client > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-client-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-client-server-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > -minimal KNOWN > :::::::::::::: > linux-i586-minimal1-client/jdk/lib/i386/jvm.cfg > :::::::::::::: > -client KNOWN > -server ALIASED_TO -client > -hotspot ALIASED_TO -client > -minimal KNOWN > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > -minimal KNOWN > -server ALIASED_TO -minimal > -client ALIASED_TO -minimal > -hotspot ALIASED_TO -minimal > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-minimal1-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > -server KNOWN > -client ALIASED_TO -server > -hotspot ALIASED_TO -server > -minimal KNOWN > -classic WARN > -native ERROR > -green ERROR > :::::::::::::: > linux-i586-server-client-minimal1/jdk/lib/i386/jvm.cfg > :::::::::::::: > # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License version 2 only, as > # published by the Free Software Foundation. Oracle designates this > # particular file as subject to the "Classpath" exception as provided > # by Oracle in the LICENSE file that accompanied this code. > # > # This code is distributed in the hope that it will be useful, but WITHOUT > # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > # version 2 for more details (a copy is included in the LICENSE file that > # accompanied this code). > # > # You should have received a copy of the GNU General Public License version > # 2 along with this work; if not, write to the Free Software Foundation, > # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > # > # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > # or visit www.oracle.com if you need additional information or have any > # questions. > # > # List of JVMs that can be used as an option to java, javac, etc. > # Order is important -- first in this list is the default JVM. > # NOTE that this both this file and its format are UNSUPPORTED and > # WILL GO AWAY in a future release. > # > # You may also select a JVM in an arbitrary location with the > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > -client IF_SERVER_CLASS -server > -server KNOWN > -hotspot ALIASED_TO -client > -classic WARN > -native ERROR > -green ERROR > -minimal KNOWN > :::::::::::::: > linux-i586-server/jdk/lib/i386/jvm.cfg > :::::::::::::: > -server KNOWN > -client ALIASED_TO -server > -hotspot ALIASED_TO -server > -classic WARN > -native ERROR > -green ERROR > From david.holmes at oracle.com Wed Apr 17 02:34:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Apr 2013 12:34:40 +1000 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516D8F89.90506@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> <516D8F89.90506@oracle.com> Message-ID: <516E0A40.1010605@oracle.com> On 17/04/2013 3:51 AM, Mandy Chung wrote: > > On 4/15/2013 3:42 PM, David Holmes wrote: >> FYI updated webrev at same location, removing the dead code Erik spotted. >> >> http://cr.openjdk.java.net/~dholmes/8010280/webrev/ >> > > Looks good to me. Nit: CopyFiles.gmk line 340 - you may want to remove > the extra space to align with the next line. Thanks Mandy. >> I've attached all the generated versions below. > > Thanks for the generated files that are helpful for the review. Have you > considered adding a simple sanity test, if not present, to validate > jvm.cfg matches with the vm binaries bundled in JAVA_HOME? Just a > thought and maybe you can file a RFE to add such a test later if you > think it's a good idea. A "simple" sanity test? ;-) This would involve finding all the libjvm's in a JRE and extracting their names, then finding and reading the jvm.cfg file in the JRE, then invoking the VM with all the possible entries in jvm.cfg and using the version string to try and see if the right VM was selected (or the right error produced). That sounds like a pretty horrible test to write. :( I think noreg-hard is best for this one. :) Thanks, David > Mandy From mandy.chung at oracle.com Wed Apr 17 02:39:00 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Apr 2013 19:39:00 -0700 Subject: RFR 8010280: jvm.cfg needs updating for non-server builds In-Reply-To: <516E0A40.1010605@oracle.com> References: <516B474B.8090404@oracle.com> <516C826C.4020709@oracle.com> <516D8F89.90506@oracle.com> <516E0A40.1010605@oracle.com> Message-ID: <516E0B44.1080103@oracle.com> On 4/16/2013 7:34 PM, David Holmes wrote: > > A "simple" sanity test? ;-) This would involve finding all the > libjvm's in a JRE and extracting their names, then finding and reading > the jvm.cfg file in the JRE, then invoking the VM with all the > possible entries in jvm.cfg and using the version string to try and > see if the right VM was selected (or the right error produced). That > sounds like a pretty horrible test to write. :( I think noreg-hard is > best for this one. :) What I was thinking is a simple one to make sure that the jvm of the KNOWN entry does exist (that at least validates one part of the jvm.cfg :) In any case, your change is good to push. Mandy From mandy.chung at oracle.com Wed Apr 17 04:40:34 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 17 Apr 2013 04:40:34 +0000 Subject: hg: jdk8/tl/jdk: 8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive Message-ID: <20130417044046.88B1B48374@hg.openjdk.java.net> Changeset: da6addef956e Author: mchung Date: 2013-04-16 21:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da6addef956e 8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive Reviewed-by: jrose, alanb, twisti ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! make/java/java/reorder-i586 ! make/java/java/reorder-sparc ! make/java/java/reorder-sparcv9 ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjava/reorder-sparc ! makefiles/mapfiles/libjava/reorder-sparcv9 ! makefiles/mapfiles/libjava/reorder-x86 ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/misc/Unsafe.java + src/share/classes/sun/reflect/CallerSensitive.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/ClassLoader.c - src/share/native/java/lang/ResourceBundle.c ! src/share/native/java/lang/SecurityManager.c ! src/share/native/sun/reflect/Reflection.c ! test/Makefile + test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java + test/sun/reflect/CallerSensitive/MethodFinder.java + test/sun/reflect/CallerSensitive/MissingCallerSensitive.java + test/sun/reflect/Reflection/GetCallerClass.java + test/sun/reflect/Reflection/GetCallerClassTest.java + test/sun/reflect/Reflection/GetCallerClassTest.sh From heinz at javaspecialists.eu Wed Apr 17 05:03:55 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Wed, 17 Apr 2013 08:03:55 +0300 Subject: Fwd: Latency in starting threads on Mac OS X In-Reply-To: <516DFA8D.4070808@oracle.com> References: <516D4AA2.9020701@javaspecialists.eu> <516D81BB.3090806@oracle.com> <516DFA8D.4070808@oracle.com> Message-ID: <516E2D3B.2000507@javaspecialists.eu> "I know 7u6 was the first version of JDK to fully support OS X." I think that's the key to the puzzle, David! It is definitely an OS X issue. I didn't see this happen on any other platform. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz David Holmes wrote: > As I've pointed out to Heinz on the concurrency-interest list there > are a couple of flawed assumptions in his test: > > a) when you start() a new thread the OS scheduler may switch to it > immediately (this depends on the scheduler semantics) > > b) Thread.join only signifies logical termination of the Java thread. > The native thread still has to exit the VM and the OS and so can > encounter additional bottlenecks that result in many more threads > being existent than expected and which can interfere with the creation > of new threads. > > I don't know specifically what may have changed between 7u5 and 7u6 in > that regard but I think it would be a hotspot issue more than a > libraries issue. I know 7u6 was the first version of JDK to fully > support OS X. > > David > > On 17/04/2013 2:52 AM, Kurchi Subhra Hazra wrote: >> Forwarding to core-libs. >> >> - Kurchi >> >> -------- Original Message -------- >> Subject: Latency in starting threads on Mac OS X >> Date: Tue, 16 Apr 2013 15:57:06 +0300 >> From: Dr Heinz M. Kabutz >> Organization: JavaSpecialists.eu >> To: macosx-port-dev at openjdk.java.net >> >> >> >> Good day my fellow Mac OS X users! >> >> Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to >> demonstrate to my class how slow it was starting threads and how much >> better it is to use a FixedThreadPool. The question that I wanted to >> answer was: How many microseconds does it take on average to start a >> simple thread and what is the maximum time it could take? >> >> We all know that it can take in the milliseconds range to do the >> following: >> >> Thread t = new Thread(); // even without it actually doing anything >> t.start(); >> >> This is one of the reasons why the fixed thread pool only starts the >> threads as we submit jobs to it, since the up-front cost might not be >> worth the wait. >> >> But how long do you think the *maximum* was that I had to wait for >> t.start() to return? 100ms? 200ms? >> >> Actually, the longest I had to wait turned out to be about 250 seconds. >> Yes. That is *seconds*, not *milliseconds*. Just to start a single >> thread. >> >> This is most certainly a bug in the OpenJDK on Mac OS X. We did not see >> this behaviour on Linux nor on Windows 7. >> >> The bug started in OpenJDK 1.7.0_06. Prior to that it hardly ever took >> longer than 30ms to start a single thread. >> >> java version "1.7.0_05" >> heinz$ java ThreadLeakMac2 >> time = 1, threads = 4 >> time = 2, threads = 346 >> time = 4, threads = 7378 >> time = 7, threads = 9614 >> time = 12, threads = 10027 >> time = 14, threads = 10063 >> time = 17, threads = 26965 >> time = 38, threads = 27013 >> time = 39, threads = 452053 >> >> java version "1.7.0_06" >> heinz$ java ThreadLeakMac2 >> time = 1, threads = 6 >> time = 2, threads = 256 >> time = 6, threads = 373 >> *snip* >> time = 111, threads = 42592 >> time = 200, threads = 49419 >> time = 333, threads = 58976 >> *snip* >> time = 3245, threads = 202336 >> time = 3706, threads = 203702 >> *snip* >> time = 5835, threads = 267872 >> time = 6455, threads = 269238 >> time = 9170, threads = 270603 >> >> In my code, I make sure that the thread has stopped before creating the >> next one by calling join(). >> >> public class ThreadLeakMac2 { >> public static void main(String[] args) throws InterruptedException { >> long threads = 0; >> long max = 0; >> while(true) { >> long time = System.currentTimeMillis(); >> Thread thread = new Thread(); >> thread.start(); // should finish almost immediately >> time = System.currentTimeMillis() - time; >> thread.join(); // short delay, hopefully >> threads++; >> if (time> max) { >> max = time; >> System.out.println("time = " + time + >> ", threads = " + threads); >> } >> } >> } >> } >> >> This would be another nice test case for Alexey's concurrency stress >> test harness. >> >> (I also posted this to the concurrency-interest list.) >> >> Regards >> >> Heinz > From mandy.chung at oracle.com Wed Apr 17 05:10:45 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 17 Apr 2013 05:10:45 +0000 Subject: hg: jdk8/tl/nashorn: 8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive Message-ID: <20130417051046.6813448375@hg.openjdk.java.net> Changeset: 222a72df2f42 Author: mchung Date: 2013-04-16 22:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/222a72df2f42 8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive Reviewed-by: jrose, alanb, twisti, sundar ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/runtime/Context.java From mandy.chung at oracle.com Wed Apr 17 05:31:37 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Apr 2013 22:31:37 -0700 Subject: Proxy.isProxyClass scalability In-Reply-To: <516D5DB3.3020102@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> <51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com> <516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com> Message-ID: <516E33B9.50007@oracle.com> On 4/16/2013 7:18 AM, Peter Levart wrote: > Hi Mandy, > > I prepared a preview variant of j.l.r.Proxy using WeakCache (turned > into an interface and a special FlattenedWeakCache implementation in > anticipation to create another variant using two-levels of > ConcurrentHashMaps for backing storage, but with same API) just to > compare performance: > > https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.01/index.html > thanks for getting this prototype done quickly. > As the values (Class objects of proxy classes) must be wrapped in a > WeakReference, the same instance of WeakReference can be re-used as a > key in another ConcurrentHashMap to implement quick look-up for > Proxy.isProxyClass() method eliminating the need to use ClassValue, > which is quite space-hungry. > I also think maintaining another ConcurrentHashMap is a good replacement with the use of ClassValue to avoid its memory overhead. > Comparing the performance, here's a summary of all 3 variants > (original, patched using a field in ClassLoader and this variant): > > [...] > > The improvement is still quite satisfactory, although a little slower > than the direct-field variant. The scalability is the same as with > direct-field variant. > Agree - the improvement is quite good. > Space consumption of cache structure, calculated as deep-size of the > structure, ignoring interned Strings, Class and ClassLoader objects > unsing single non-bootstrap ClassLoader for defining the proxy classes > and using 32 bit addressing is the following: > > [...] > > So with new ConcurrentHashMap the patched Proxy uses about 32 bytes > more per proxy class. > > Is this satisfactory or should we also try a variant with two-levels > of ConcurrentHashMaps? > The overhead seems okay to trade off the scalability. Since you have prepared for doing another variant, it'd be good to compare two prototypes if this doesn't bring too much work :) I would imagine that there might be slight difference in your measurement when comparing with proxies defined by a single class loader but the code might be simpler (might not be if you keep the same API but different implementation). Regardless of which approach to use - you have added a general purpose WeakCache and the implementation class in the sun.misc package. While it's good to have such class for other jdk class to use, I am more comfortable in keeping it as a private class for proxy implementation to use. We need existing applications to migrate away from sun.misc and other private APIs to prepare for modularization. Nits: can you wrap the lines around 80 columns including comments? try-catch-finally statements need some formatting fixes. Our convention is to have 'catch', or 'finally' following the closing bracket '}' in the same line. Your editor breaks 'catch' or 'finally' into the next line. > > Even without SecurityManager installed the performance of native > getClassLoader0 was a hog. I don't know why? Isn't there an implicit > reference to defining ClassLoader from every Class object? That's right - it looks for the caller class only if the security manager is installed. The defining class loader is kept in the VM's Klass object (language-level Class instance representation in the VM) and there is no computation needed to obtain a defining class loader of a given Class object. I can only think of the Java <-> native transition overhead that could be one factor. Class.getClassLoader0 is not intrinsified. I'll find out (others on this mailing list may probably know). Mandy From dan.xu at oracle.com Wed Apr 17 06:36:06 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 16 Apr 2013 23:36:06 -0700 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <51401CA3.30407@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> Message-ID: <516E42D6.5020309@oracle.com> Hi Eric, Thanks for fixing the test failures. I recently reviewed your changes. And I like your idea to add a base dir to restrict the test only touching files/directories that are created by itself to avoid the interferences from the OS or other test activities. And in Line 341 of General.java, I notice you make the code return if it tries to test baseDir or its ascendant directories, which reduces the test coverage. Since GeneralWin32.java knows its max tree depth, I think you can make the baseDir deep enough in the prepared directory structure so that the test can still run inside the testing directories even if it visits the baseDir's ascendant directories. One idea is to make the max depth as a parameter of initTestData(), and this method can intelligently return an appropriate baseDir basing on it. After the above change, you can move the baseDir and userDir back to GeneralWin32.java to make the two classes loosely coupled. In the changes, the usages of NIO classes are not necessary. The test is against java.io packages, and it is better to keep it clean in case it might be used to test old jdk version which does not have NIO. Before the test ends, it is better to clean the testing files and directories which are created at the beginning. Thanks! -Dan On 03/12/2013 11:28 PM, Eric Wang wrote: > Hi, > > Please review the code change, I have updated the test to make sure > test only access files and directories created by itself. > http://cr.openjdk.java.net/~ewang/8009258/webrev.01/ > > Here is the execution result: > http://cr.openjdk.java.net/~ewang/8009258/GeneralWin32.jtr > > Thanks, > Eric > On 2013/3/5 1:39, Alan Bateman wrote: >> On 04/03/2013 17:32, Eric Wang wrote: >>> Hi, >>> >>> Please help to review fix below for bug 8009258 >>> , >>> TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently. >>> http://cr.openjdk.java.net/~ewang/8009258/webrev.00/ >>> >>> The File.canRead() method should not be used to check read >>> permission of a directory. >>> >>> Thanks, >>> Eric >> I wonder if it would be better to change this test so that it doesn't >> even attempt to poke around in these directories. I suggest this >> because there may be other activity going on at the same time. See >> also 8004096 where the test is running in agentvm mode and is >> straying into the directory used by another agent VM. >> >> -Alan > From daniel.fuchs at oracle.com Wed Apr 17 08:24:29 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 17 Apr 2013 08:24:29 +0000 Subject: hg: jdk8/tl: 8011347: JKD-8009824 has broken webrev with some ksh versions Message-ID: <20130417082430.0139548382@hg.openjdk.java.net> Changeset: b95c5c8ee60a Author: jgish Date: 2013-04-16 13:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b95c5c8ee60a 8011347: JKD-8009824 has broken webrev with some ksh versions Reviewed-by: mduigou ! make/scripts/webrev.ksh From Alan.Bateman at oracle.com Wed Apr 17 09:05:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Apr 2013 10:05:13 +0100 Subject: Fwd: Latency in starting threads on Mac OS X In-Reply-To: <516DFA8D.4070808@oracle.com> References: <516D4AA2.9020701@javaspecialists.eu> <516D81BB.3090806@oracle.com> <516DFA8D.4070808@oracle.com> Message-ID: <516E65C9.7020205@oracle.com> On 17/04/2013 02:27, David Holmes wrote: > : > > I don't know specifically what may have changed between 7u5 and 7u6 in > that regard but I think it would be a hotspot issue more than a > libraries issue. I know 7u6 was the first version of JDK to fully > support OS X. The Mac support went into 7u4 but Oracle builds didn't have all the (closed) deployment features until 7u6. Aside from the issues that you pointed out, it probably needs someone to look at it more closely to narrow this down a bit. -Alan From Alan.Bateman at oracle.com Wed Apr 17 09:15:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Apr 2013 10:15:57 +0100 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <516E42D6.5020309@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> <516E42D6.5020309@oracle.com> Message-ID: <516E684D.60401@oracle.com> On 17/04/2013 07:36, Dan Xu wrote: > : > > In the changes, the usages of NIO classes are not necessary. The test > is against java.io packages, and it is better to keep it clean in case > it might be used to test old jdk version which does not have NIO. > I briefly looked at it and I think the usage okay is because it just makes it easier to check the results and also to keep the directory walk from wandering into other parts of the file system. If it changed what was being tested then I would agree that it shouldn't be used. -Alan From vicente.romero at oracle.com Wed Apr 17 10:12:37 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 17 Apr 2013 10:12:37 +0000 Subject: hg: jdk8/tl/langtools: 8011181: javac, empty UTF8 entry generated for inner class Message-ID: <20130417101245.AEF7448386@hg.openjdk.java.net> Changeset: 49d32c84dfea Author: vromero Date: 2013-04-17 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/49d32c84dfea 8011181: javac, empty UTF8 entry generated for inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T8011181/EmptyUTF8ForInnerClassNameTest.java From mikael.auno at oracle.com Wed Apr 17 13:03:53 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 17 Apr 2013 15:03:53 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads Message-ID: <516E9DB9.8020009@oracle.com> Hi, I'd like some reviews on http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). The issue here is that when MethodExitReturnValuesTest hooks into MethodExit events through JDI it uses an exclude list to filter out classes from which it is not interested in these events. This is bound to break over and over again as new features are added to the JDK. I've changed the test to use an include list instead, containing only the handful of classes the test is actually interested in. Thanks, Mikael From peter.levart at gmail.com Wed Apr 17 14:18:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Apr 2013 16:18:50 +0200 Subject: Proxy.isProxyClass scalability In-Reply-To: <516E33B9.50007@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> <5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com> <51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com> <516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com> <516E33B9.50007@oracle.com> Message-ID: <516EAF4A.6040605@gmail.com> Hi Mandy, Here's the updated webrev: https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html This adds TwoLevelWeakCache to the scene with following performance compared to other alternatives: Summary (4 Cores x 2 Threads i7 CPU): Test Threads ns/op Original Patch(CL field) FlattenedWeakCache TwoLevelWeakCache ======================= ======= ============== =============== ================== ================= Proxy_getProxyClass 1 2,403.27 163.70 206.88 252.89 4 3,039.01 202.77 303.38 327.62 8 5,193.58 314.47 442.58 510.63 Proxy_isProxyClassTrue 1 95.02 10.78 41.85 42.03 4 2,266.29 10.80 42.32 42.07 8 4,782.29 20.53 72.29 69.25 Proxy_isProxyClassFalse 1 95.02 1.36 1.36 1.36 4 2,186.59 1.36 1.37 1.40 8 4,891.15 2.72 2.94 2.72 Annotation_equals 1 240.10 152.29 193.27 200.45 4 1,864.06 153.81 195.60 202.45 8 8,639.20 262.09 384.72 338.70 As expected, the Proxy.getProxyClass() is yet a little slower than with FlattenedWeakCache, but still much faster than original Proxy implementation. Another lookup in the ConcurrentHashMap and another indirection have a price, but we also get something in return - space. This is all obtained on latest lambda build (with new segment-less ConcurrentHashMap). I also added another ClassLoader to see what happens when the 2nd is added to the cache: # Original Proxy, 32 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 400 400 1 1 768 368 1 2 920 152 1 3 1072 152 1 4 1224 152 1 5 1376 152 1 6 1528 152 1 7 1680 152 1 8 1832 152 1 9 1984 152 1 10 2136 152 2 11 2456 320 2 12 2672 216 2 13 2824 152 2 14 2976 152 2 15 3128 152 2 16 3280 152 2 17 3432 152 2 18 3584 152 2 19 3736 152 2 20 3888 152 # Original Proxy, 64 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 632 632 1 1 1216 584 1 2 1448 232 1 3 1680 232 1 4 1912 232 1 5 2144 232 1 6 2376 232 1 7 2608 232 1 8 2840 232 1 9 3072 232 1 10 3304 232 2 11 3832 528 2 12 4192 360 2 13 4424 232 2 14 4656 232 2 15 4888 232 2 16 5120 232 2 17 5352 232 2 18 5584 232 2 19 5816 232 2 20 6048 232 # Patched Proxy (FlattenedWeakCache), 32 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 240 240 1 1 584 344 1 2 768 184 1 3 952 184 1 4 1136 184 1 5 1320 184 1 6 1504 184 1 7 1688 184 1 8 1872 184 1 9 2056 184 1 10 2240 184 2 11 2424 184 2 12 2736 312 2 13 2920 184 2 14 3104 184 2 15 3288 184 2 16 3472 184 2 17 3656 184 2 18 3840 184 2 19 4024 184 2 20 4208 184 # Patched Proxy (FlattenedWeakCache), 64 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 336 336 1 1 920 584 1 2 1200 280 1 3 1480 280 1 4 1760 280 1 5 2040 280 1 6 2320 280 1 7 2600 280 1 8 2880 280 1 9 3160 280 1 10 3440 280 2 11 3720 280 2 12 4256 536 2 13 4536 280 2 14 4816 280 2 15 5096 280 2 16 5376 280 2 17 5656 280 2 18 5936 280 2 19 6216 280 2 20 6496 280 # Patched Proxy (TwoLevelWeakCache), 32 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 240 240 1 1 752 512 1 2 896 144 1 3 1040 144 1 4 1184 144 1 5 1328 144 1 6 1472 144 1 7 1616 144 1 8 1760 144 1 9 1904 144 1 10 2048 144 2 11 2400 352 2 12 2608 208 2 13 2752 144 2 14 2896 144 2 15 3040 144 2 16 3184 144 2 17 3328 144 2 18 3472 144 2 19 3616 144 2 20 3760 144 # Patched Proxy (TwoLevelWeakCache), 64 bit addressing class proxy size of delta to loaders classes caches prev.ln. -------- -------- -------- -------- 0 0 336 336 1 1 1216 880 1 2 1440 224 1 3 1664 224 1 4 1888 224 1 5 2112 224 1 6 2336 224 1 7 2560 224 1 8 2784 224 1 9 3008 224 1 10 3232 224 2 11 3808 576 2 12 4160 352 2 13 4384 224 2 14 4608 224 2 15 4832 224 2 16 5056 224 2 17 5280 224 2 18 5504 224 2 19 5728 224 2 20 5952 224 So we loose approx. 32 bytes (32bit addresses) or 48 bytes (64 bit addresses) for each proxy class compared to original code when using FlattenedWeakCache, but we gain 8 bytes (32 bit or 64 bit addresses) for each proxy class cached compared to original code when using TwoLevelWeakCache. So which to favour, space or time? Other comments in-line... On 04/17/2013 07:31 AM, Mandy Chung wrote: > On 4/16/2013 7:18 AM, Peter Levart wrote: >> Hi Mandy, >> >> I prepared a preview variant of j.l.r.Proxy using WeakCache (turned >> into an interface and a special FlattenedWeakCache implementation in >> anticipation to create another variant using two-levels of >> ConcurrentHashMaps for backing storage, but with same API) just to >> compare performance: >> >> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.01/index.html >> > > > thanks for getting this prototype done quickly. > >> As the values (Class objects of proxy classes) must be wrapped in a >> WeakReference, the same instance of WeakReference can be re-used as a >> key in another ConcurrentHashMap to implement quick look-up for >> Proxy.isProxyClass() method eliminating the need to use ClassValue, >> which is quite space-hungry. >> > > I also think maintaining another ConcurrentHashMap is a good > replacement with the use of ClassValue to avoid its memory overhead. > >> Comparing the performance, here's a summary of all 3 variants >> (original, patched using a field in ClassLoader and this variant): >> >> [...] >> >> The improvement is still quite satisfactory, although a little slower >> than the direct-field variant. The scalability is the same as with >> direct-field variant. >> > > Agree - the improvement is quite good. > >> Space consumption of cache structure, calculated as deep-size of the >> structure, ignoring interned Strings, Class and ClassLoader objects >> unsing single non-bootstrap ClassLoader for defining the proxy >> classes and using 32 bit addressing is the following: >> >> [...] >> >> So with new ConcurrentHashMap the patched Proxy uses about 32 bytes >> more per proxy class. >> >> Is this satisfactory or should we also try a variant with two-levels >> of ConcurrentHashMaps? >> > > The overhead seems okay to trade off the scalability. > > Since you have prepared for doing another variant, it'd be good to > compare two prototypes if this doesn't bring too much work :) I would > imagine that there might be slight difference in your measurement when > comparing with proxies defined by a single class loader but the code > might be simpler (might not be if you keep the same API but different > implementation). With TwoLevelWeakCache, there is a "step" of 108 bytes (32bit addresses) when new ClassLoader is encoutered (new 2nd level ConcurrentHashMap is allocated and new entry added to 1st level CHM. There's no such "step" in FlattenedWeakCache (modulo the steps when the CHMs are itself resized). So we roughly have 108 bytes wasted for each new ClassLoader encountered with TwoLevelWeakCache vs. FlattenedWeakCache, but we also have 40 bytes spared for each proxy class cached. TwoLevelWeakCache starts to pay off if there are at least 3 proxy classes defined per ClassLoader in average. > > Regardless of which approach to use - you have added a general purpose > WeakCache and the implementation class in the sun.misc package. While > it's good to have such class for other jdk class to use, I am more > comfortable in keeping it as a private class for proxy implementation > to use. We need existing applications to migrate away from sun.misc > and other private APIs to prepare for modularization. What about package-private in java.lang.reflect? It makes Proxy itself much easier to read. When we decide which way to go, I can remove the interface and only leave a single package-private class... > > Nits: can you wrap the lines around 80 columns including comments? > try-catch-finally statements need some formatting fixes. Our > convention is to have 'catch', or 'finally' following the closing > bracket '}' in the same line. Your editor breaks 'catch' or 'finally' > into the next line. Fixed. Regards, Peter > >> >> Even without SecurityManager installed the performance of native >> getClassLoader0 was a hog. I don't know why? Isn't there an implicit >> reference to defining ClassLoader from every Class object? > > That's right - it looks for the caller class only if the security > manager is installed. The defining class loader is kept in the VM's > Klass object (language-level Class instance representation in the VM) > and there is no computation needed to obtain a defining class loader > of a given Class object. I can only think of the Java <-> native > transition overhead that could be one factor. Class.getClassLoader0 > is not intrinsified. I'll find out (others on this mailing list may > probably know). > > Mandy From jim.gish at oracle.com Wed Apr 17 14:55:46 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 17 Apr 2013 10:55:46 -0400 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <7A07E10F-BC21-4A7E-9ED8-38F280E65AF2@oracle.com> References: <51673A45.8060908@oracle.com> <516D6A87.2000606@oracle.com> <516D7350.9020100@oracle.com> <7A07E10F-BC21-4A7E-9ED8-38F280E65AF2@oracle.com> Message-ID: <516EB7F2.8060309@oracle.com> I'm going to rip out the then. It's an unnecessary burden. Thanks Jim On 04/16/2013 06:50 PM, Mike Duigou wrote: > On Apr 16 2013, at 08:50 , Alan Bateman wrote: > >> On 16/04/2013 16:13, Jim Gish wrote: >>> On 04/15/2013 02:02 PM, Martin Buchholz wrote: >>>> You are fiddling with the javadoc for getChars, which is an independent change. (I am also fiddling with getChars in another ongoing change). I don't think closing html tags for
  • are required in javadoc. If you are going to change the exception javadoc, then also change @exception to @throws. >>>> >>> The only reason I'm adding
    • is Alan insisted on it in a previous change I proposed :-) >>> >> I don't recall the full context but I have got confused by an early build of doclint where this was an issue. > is required by XHTML but not by HTML. doclint was too aggressive about this in early builds. > > Having does no harm but it's not required. > > Mike > >> -Alan. -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From vincent.x.ryan at oracle.com Wed Apr 17 15:00:19 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 17 Apr 2013 15:00:19 +0000 Subject: hg: jdk8/tl/jdk: 12 new changesets Message-ID: <20130417150401.ACF7B4839A@hg.openjdk.java.net> Changeset: 473ed4b94306 Author: vinnie Date: 2013-04-11 17:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/473ed4b94306 7171982: Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider Reviewed-by: vinnie, wetmore Contributed-by: Tony Scarpino ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherWithWrappingSpi.java ! src/share/classes/com/sun/crypto/provider/ConstructKeys.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java + test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java Changeset: a6ca7cd399b2 Author: vinnie Date: 2013-04-11 18:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ca7cd399b2 8001596: Incorrect condition check in PBKDF2KeyImpl.JAVA Reviewed-by: wetmore Contributed-by: Tony Scarpino ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java + test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java Changeset: 747a09471fd9 Author: erikj Date: 2013-04-11 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/747a09471fd9 8011812: JDK-8011278 breaks the old build Reviewed-by: tbell, wetmore ! make/sun/splashscreen/Makefile Changeset: 793e0072bfd6 Author: wetmore Date: 2013-04-11 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/793e0072bfd6 8012056: SunJCEInstance needs to run in it's own vm Reviewed-by: wetmore Contributed-by: anthony.scarpino at oracle.com ! test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java Changeset: d8d037a7569e Author: xuelei Date: 2013-04-11 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8d037a7569e 8011680: Re-integrate AEAD implementation of JSSE Summary: It is a re-merge of JDK-7030966. Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: ea7976ed9bc6 Author: wetmore Date: 2013-04-11 19:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea7976ed9bc6 Merge Changeset: 0f93bd5cc8d7 Author: wetmore Date: 2013-04-11 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f93bd5cc8d7 6425477: Better support for generation of high entropy random numbers Reviewed-by: xuelei, weijun, mullan ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java ! src/share/classes/sun/security/provider/SecureRandom.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/classes/sun/security/provider/NativePRNG.java ! src/solaris/classes/sun/security/provider/NativeSeedGenerator.java ! src/windows/classes/sun/security/mscapi/PRNG.java ! src/windows/classes/sun/security/provider/NativePRNG.java ! src/windows/classes/sun/security/provider/NativeSeedGenerator.java + test/sun/security/provider/SecureRandom/StrongSecureRandom.java + test/sun/security/provider/SecureRandom/StrongSeedReader.java Changeset: 5435f112e5ea Author: vinnie Date: 2013-04-12 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5435f112e5ea Merge - src/share/classes/java/time/chrono/HijrahDeviationReader.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java - test/java/time/tck/java/time/TestChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java Changeset: 6f80a6584fb9 Author: vinnie Date: 2013-04-16 01:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f80a6584fb9 Merge - test/java/util/ComparatorsTest.java Changeset: 29cbb4617c92 Author: vinnie Date: 2013-04-16 05:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29cbb4617c92 Merge Changeset: 13e18d3ac414 Author: vinnie Date: 2013-04-16 05:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13e18d3ac414 Merge Changeset: f90b7503019f Author: vinnie Date: 2013-04-17 02:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f90b7503019f Merge ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows - src/share/native/java/lang/ResourceBundle.c From alan.bateman at oracle.com Wed Apr 17 15:19:18 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 17 Apr 2013 15:19:18 +0000 Subject: hg: jdk8/tl/jdk: 8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win) Message-ID: <20130417151943.63D3F4839D@hg.openjdk.java.net> Changeset: 7ded74ffea36 Author: alanb Date: 2013-04-17 16:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ded74ffea36 8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win) Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeDispatcher.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java + test/java/nio/channels/FileChannel/InterruptDeadlock.java From daniel.fuchs at oracle.com Wed Apr 17 15:41:42 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Apr 2013 17:41:42 +0200 Subject: RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader Message-ID: <516EC2B6.2030302@oracle.com> Hi, These changes correspond to the changes that have been already reviewed under the umbrella name of JDK-7169894 (which was closed & cloned into JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl forest tip. So this is basically JDK-7169894, re-based & merged at the tip - with small additional editorial changes (like e.g. fixing the copyright years). The merging was not completely trivial - hence the new RFR. Previously reviewed changes can be browsed at [1]. best regards, -- daniel [1] previously reviewed webrevs From Alan.Bateman at oracle.com Wed Apr 17 16:30:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Apr 2013 17:30:05 +0100 Subject: RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader In-Reply-To: <516EC2B6.2030302@oracle.com> References: <516EC2B6.2030302@oracle.com> Message-ID: <516ECE0D.4080406@oracle.com> On 17/04/2013 16:41, Daniel Fuchs wrote: > Hi, > > These changes correspond to the changes that have been already reviewed > under the umbrella name of JDK-7169894 (which was closed & cloned into > JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl > forest tip. > > So this is basically JDK-7169894, re-based & merged at the tip - with > small additional editorial changes (like e.g. fixing the copyright > years). The merging was not completely trivial - hence the new > RFR. > > > > Previously reviewed changes can be browsed at [1]. > > best regards, > > -- daniel I've skimmed through the new webrev and it looks like the changes that we agreed over many iterations back in January. Are there any specific areas of the merge that need attention? (I didn't see any). Overall it's very good work and it will be nice to get this in. -Alan. From daniel.fuchs at oracle.com Wed Apr 17 16:49:33 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Apr 2013 18:49:33 +0200 Subject: RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader In-Reply-To: <516ECE0D.4080406@oracle.com> References: <516EC2B6.2030302@oracle.com> <516ECE0D.4080406@oracle.com> Message-ID: <516ED29D.9060809@oracle.com> On 4/17/13 6:30 PM, Alan Bateman wrote: > On 17/04/2013 16:41, Daniel Fuchs wrote: >> Hi, >> >> These changes correspond to the changes that have been already reviewed >> under the umbrella name of JDK-7169894 (which was closed & cloned into >> JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl >> forest tip. >> >> So this is basically JDK-7169894, re-based & merged at the tip - with >> small additional editorial changes (like e.g. fixing the copyright >> years). The merging was not completely trivial - hence the new >> RFR. >> >> >> >> Previously reviewed changes can be browsed at [1]. >> >> best regards, >> >> -- daniel > I've skimmed through the new webrev and it looks like the changes that > we agreed over many iterations back in January. Are there any specific > areas of the merge that need attention? (I didn't see any). Overall > it's very good work and it will be nice to get this in. Most of the merge troubles were in the FactoryFinder.java and XxxxFactoryFinder.java files - the merge was a bit difficult because some lines had changes in both parent and child - like method signature where a had been added to the return type in the child and a new argument had been added in the parent. In transform/FactoryFinder I had removed a boolean from the newInstance(...) methods - and that caused a merge issue too which had to be resolved carefully. (originally requested by Mandy who noticed that the method was always called with the same boolean value - and therefore did not need that boolean has argument). Merge in the other files was otherwise trivial. -- daniel > > -Alan. From roger.riggs at oracle.com Wed Apr 17 17:00:02 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 17 Apr 2013 13:00:02 -0400 Subject: Request for review of 8009648 Tests fail in -agentvm -concurrency mode Message-ID: <516ED512.6040500@oracle.com> As noted in 8009648: Tests fail in -agentvm -concurrency mode there are several tests that fail in agentvm mode, adding the directories with the sensitive tests to othervms.dir speeds up testing and the tests pass. Please review. http://cr.openjdk.java.net/~rriggs/webrev-testconcurrency/ From serguei.spitsyn at oracle.com Wed Apr 17 17:15:53 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Apr 2013 10:15:53 -0700 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <516E9DB9.8020009@oracle.com> References: <516E9DB9.8020009@oracle.com> Message-ID: <516ED8C9.4020100@oracle.com> Hi Mikael, It looks good. Thank you for figuring out how to make it more stable! BTW, the webrev frames mode does not work. Thanks, Serguei On 4/17/13 6:03 AM, Mikael Auno wrote: > Hi, I'd like some reviews on > http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for JDK-8009681 > (http://bugs.sun.com/view_bug.do?bug_id=8009681). > > The issue here is that when MethodExitReturnValuesTest hooks into > MethodExit events through JDI it uses an exclude list to filter out > classes from which it is not interested in these events. This is bound > to break over and over again as new features are added to the JDK. > I've changed the test to use an include list instead, containing only > the handful of classes the test is actually interested in. > > Thanks, > Mikael From joe.darcy at oracle.com Wed Apr 17 17:32:10 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 17 Apr 2013 10:32:10 -0700 Subject: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed In-Reply-To: <516B6799.1010206@oracle.com> References: <51676122.4020802@oracle.com> , <516845EC.8090105@oracle.com> , <51685B97.5010507@oracle.com> <516B6799.1010206@oracle.com> Message-ID: <516EDC9A.4070207@oracle.com> On 04/14/2013 07:36 PM, Joe Darcy wrote: > On 04/12/2013 07:29 PM, Jason Mehrens wrote: >> Joe, >> You'll have guard ise.addSuppressed against null. Looks good otherwise. >> >> private static void initCauseNull() { >> Throwable t1 = new Throwable(); >> t1.initCause(null); >> try { >> t1.initCause(null); >> } catch(IllegalStateException expect) { >> } >> } > > Right you are; check added and test updated in: > > http://cr.openjdk.java.net/~darcy/8012044.2/ > > Full patch to Throwable: [snip] One more iteration; I've changed the initCause logic to suppress both exceptions rather than using one as the cause: http://cr.openjdk.java.net/~darcy/8012044.2 Patch to throwable: --- old/src/share/classes/java/lang/Throwable.java 2013-04-14 19:33:23.000000000 -0700 +++ new/src/share/classes/java/lang/Throwable.java 2013-04-14 19:33:23.000000000 -0700 @@ -452,10 +452,15 @@ * @since 1.4 */ public synchronized Throwable initCause(Throwable cause) { - if (this.cause != this) - throw new IllegalStateException("Can't overwrite cause"); + if (this.cause != this) { + IllegalStateException ise = + new IllegalStateException("Can't overwrite cause", this); + if (cause != null) + ise.addSuppressed(cause); + throw ise; + } if (cause == this) - throw new IllegalArgumentException("Self-causation not permitted"); + throw new IllegalArgumentException("Self-causation not permitted", this); this.cause = cause; return this; } @@ -1039,7 +1044,7 @@ */ public final synchronized void addSuppressed(Throwable exception) { if (exception == this) - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE); + throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception); if (exception == null) throw new NullPointerException(NULL_CAUSE_MESSAGE); The suppression mechanism is typically, but not exclusively, used by the try-with-resources statement. Thanks, -Joe From Alan.Bateman at oracle.com Wed Apr 17 17:43:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Apr 2013 18:43:14 +0100 Subject: Request for review of 8009648 Tests fail in -agentvm -concurrency mode In-Reply-To: <516ED512.6040500@oracle.com> References: <516ED512.6040500@oracle.com> Message-ID: <516EDF32.5000601@oracle.com> On 17/04/2013 18:00, roger riggs wrote: > As noted in 8009648: Tests fail in -agentvm -concurrency mode > there are several tests that fail in agentvm mode, adding the directories > with the sensitive tests to othervms.dir speeds up testing and the > tests pass. > Please review. > > http://cr.openjdk.java.net/~rriggs/webrev-testconcurrency/ This looks good and I can sponsor it for you. -Alan. From dan.xu at oracle.com Wed Apr 17 18:12:34 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 17 Apr 2013 11:12:34 -0700 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <516E684D.60401@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> <516E42D6.5020309@oracle.com> <516E684D.60401@oracle.com> Message-ID: <516EE612.9010606@oracle.com> On 04/17/2013 02:15 AM, Alan Bateman wrote: > On 17/04/2013 07:36, Dan Xu wrote: >> : >> >> In the changes, the usages of NIO classes are not necessary. The test >> is against java.io packages, and it is better to keep it clean in >> case it might be used to test old jdk version which does not have NIO. >> > I briefly looked at it and I think the usage okay is because it just > makes it easier to check the results and also to keep the directory > walk from wandering into other parts of the file system. If it changed > what was being tested then I would agree that it shouldn't be used. > > -Alan > I see. My thought is that the relative path between baseDir and userDir can be calculated inside initTestData() when it constructs the baseDir. But I agree it is not an issue here. Thanks! -Dan From mike.duigou at oracle.com Wed Apr 17 18:56:12 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 17 Apr 2013 18:56:12 +0000 Subject: hg: jdk8/tl/jdk: 8010953: Add primitive summary statistics utils Message-ID: <20130417185626.00C89483B0@hg.openjdk.java.net> Changeset: d9f9040554d6 Author: mduigou Date: 2013-04-17 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9f9040554d6 8010953: Add primitive summary statistics utils Reviewed-by: mduigou, dholmes, chegar, darcy Contributed-by: Brian Goetz + src/share/classes/java/util/DoubleSummaryStatistics.java + src/share/classes/java/util/IntSummaryStatistics.java + src/share/classes/java/util/LongSummaryStatistics.java From mandy.chung at oracle.com Wed Apr 17 19:03:42 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 17 Apr 2013 19:03:42 +0000 Subject: hg: jdk8/tl/jdk: 8004260: dynamic proxy class should have the same Java language access as the proxy interfaces Message-ID: <20130417190354.A94B5483B1@hg.openjdk.java.net> Changeset: 73e3b474125e Author: mchung Date: 2013-04-17 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73e3b474125e 8004260: dynamic proxy class should have the same Java language access as the proxy interfaces Reviewed-by: alanb, jrose, jdn ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectPermission.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/tracing/ProviderSkeleton.java + test/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java + test/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java + test/java/lang/reflect/Proxy/nonPublicProxy/p/Bar.java + test/java/lang/reflect/Proxy/nonPublicProxy/p/Foo.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy From mike.duigou at oracle.com Wed Apr 17 19:15:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 17 Apr 2013 12:15:57 -0700 Subject: RFR: String.join(), StringJoiner additions In-Reply-To: <51673A45.8060908@oracle.com> References: <51673A45.8060908@oracle.com> Message-ID: String:: line 1253: This should use {@code } rather than . I think regular spaces are OK as well.   seems inappropriate. lines 2425/2467: elements may not be null either. I can tell you (or maybe it's just me) are itching to change : for (CharSequence cs: elements) { 2477 joiner.add(cs); 2478 } to: elements.forEach(joiner::add); StringJoiner:: -
    isn't needed around 
     as it's already a 
     you probably mean to do 


     {@code 
... 
}
    

for code samples.

- It would be nice if the empty output generation in three arg constructor could be suppressed unless needed. Perhaps a special (not null please!) sentinel value?

- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:

> Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 
> 
> These are changes that we made in lambda that we're now bringing into JDK8.
> 
> I've made a couple of additions - making StringJoiner final and adding a couple of constructors to set the emptyOutput chars.
> 
> Thanks,
>   Jim
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
> 



From brian.goetz at oracle.com  Wed Apr 17 19:26:39 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 17 Apr 2013 15:26:39 -0400
Subject: RFR: JDK-8011917 (java.util.stream.Collectors)
In-Reply-To: <51267293.4060203@oracle.com>
References: <51267293.4060203@oracle.com>
Message-ID: <516EF76F.4060703@oracle.com>

Single new source file at:
 
http://hg.openjdk.java.net/lambda/lambda/jdk/file/76ac19e61df1/src/share/classes/java/util/stream/Collectors.java

Doc at:
 
http://cr.openjdk.java.net/~briangoetz/JDK-8008682/api/java/util/stream/Collectors.html

for JDK-8011917 (Collectors class in java.util.stream).

(No webrev as there's just one new file.)



From coleen.phillimore at oracle.com  Wed Apr 17 19:24:48 2013
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 17 Apr 2013 19:24:48 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130417192514.78D70483B2@hg.openjdk.java.net>

Changeset: 7f9f69729934
Author:    coleenp
Date:      2013-04-17 12:50 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f9f69729934

8009531: Crash when redefining class with annotated method
Summary: Add code to annotated methods and command line flags to the tests to verify bug above
Reviewed-by: acorn, sspitsyn, dcubed, dholmes, alanb

! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 36f9e357b84b
Author:    coleenp
Date:      2013-04-17 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f9e357b84b

Merge




From lana.steuck at oracle.com  Wed Apr 17 19:34:52 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:34:52 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130417193505.68EBE483B7@hg.openjdk.java.net>

Changeset: 1f19b84efa6d
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f19b84efa6d

Merge

- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
- test/tools/javac/lambda/Intersection01.out
- test/tools/javac/lambda/TargetType01.out

Changeset: 94870c08391c
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94870c08391c

Merge




From lana.steuck at oracle.com  Wed Apr 17 19:34:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:34:39 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20130417193440.346BB483B5@hg.openjdk.java.net>

Changeset: 4c13b7994f38
Author:    lana
Date:      2013-04-16 08:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4c13b7994f38

Merge

! common/makefiles/Main.gmk

Changeset: 2600c8d8b619
Author:    lana
Date:      2013-04-17 10:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/2600c8d8b619

Merge




From lana.steuck at oracle.com  Wed Apr 17 19:34:44 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:34:44 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130417193447.5B5F7483B6@hg.openjdk.java.net>

Changeset: 35881a9d0fc2
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/35881a9d0fc2

Merge

- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: 44d8612e29b0
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/44d8612e29b0

Merge




From lana.steuck at oracle.com  Wed Apr 17 19:34:55 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:34:55 +0000
Subject: hg: jdk8/tl/hotspot: 19 new changesets
Message-ID: <20130417193538.AB2CC483B9@hg.openjdk.java.net>

Changeset: e437668ced9d
Author:    amurillo
Date:      2013-04-11 01:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68fe50d4f1d5
Author:    johnc
Date:      2013-04-05 10:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: 8617e38bb4cb
Author:    jmasa
Date:      2013-02-11 10:31 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 83f27710f5f7
Author:    brutisso
Date:      2013-04-08 07:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 63f57a8c5283
Author:    mgerdin
Date:      2013-04-09 15:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mesnik at oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh

Changeset: ba42fd5e00e6
Author:    mgerdin
Date:      2013-04-10 13:27 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 7b835924c31c
Author:    stefank
Date:      2013-04-10 14:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 480d934f62a8
Author:    mgerdin
Date:      2013-04-11 16:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 705ef39fcaa9
Author:    neliasso
Date:      2013-04-05 11:09 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: f67065f02409
Author:    bharadwaj
Date:      2013-04-08 07:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f67065f02409

8010913: compiler/6863420 often exceeds timeout
Summary: add longer timeout for jtreg, add internal timeout thread to prevent spurious timeouts
Reviewed-by: twisti, kvn
Contributed-by: drchase 

! test/compiler/6863420/Test.java

Changeset: b84fd7d73702
Author:    iignatyev
Date:      2013-04-09 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b84fd7d73702

8007288: Additional WB API for compiler's testing
Reviewed-by: kvn, vlivanov

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
+ test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
+ test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 84ab5667f290
Author:    roland
Date:      2013-04-10 09:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/84ab5667f290

8011706: specjvm2008 test xml.transform gets array bound exception with c1
Summary: loop invariant code motion may move load before store to the same field
Reviewed-by: kvn

! src/share/vm/c1/c1_ValueMap.cpp
+ test/compiler/8011706/Test8011706.java

Changeset: d79859ff6535
Author:    kmo
Date:      2013-04-11 07:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d79859ff6535

8011952: Missing ResourceMarks in TraceMethodHandles
Summary: add missing ResourceMark under TraceMethodHandles in LinkResolver
Reviewed-by: dholmes

! src/share/vm/interpreter/linkResolver.cpp

Changeset: 9befe2fce567
Author:    vlivanov
Date:      2013-04-11 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9befe2fce567

8011972: Field can be erroneously marked as contended when @Contended annotation isn't present
Reviewed-by: kvn, kmo, shade

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp

Changeset: b5db9d29062f
Author:    vlivanov
Date:      2013-04-11 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5db9d29062f

Merge


Changeset: 7a5aec879506
Author:    bharadwaj
Date:      2013-04-11 17:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a5aec879506

Merge

! src/share/vm/prims/whitebox.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 6d88a566d369
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d88a566d369

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 5201379fe487
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5201379fe487

Added tag hs25-b28 for changeset 6d88a566d369

! .hgtags

Changeset: 6c560f9ebb3e
Author:    lana
Date:      2013-04-17 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c560f9ebb3e

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java



From lana.steuck at oracle.com  Wed Apr 17 19:35:00 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:35:00 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20130417193507.1EAB5483B8@hg.openjdk.java.net>

Changeset: a5e7c2f093c9
Author:    lana
Date:      2013-04-16 08:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a5e7c2f093c9

Merge

- src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlIsSetWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlLocationWriter.java
- src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadOnlyPropertyException.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizable.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableImpl.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessage.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessageFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizer.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/NullLocalizable.java

Changeset: ebbd87e3a8b2
Author:    lana
Date:      2013-04-17 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ebbd87e3a8b2

Merge




From lana.steuck at oracle.com  Wed Apr 17 19:35:59 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 19:35:59 +0000
Subject: hg: jdk8/tl/jdk: 16 new changesets
Message-ID: <20130417193908.3AC1C483BA@hg.openjdk.java.net>

Changeset: 87c62f03bc07
Author:    jgodinez
Date:      2013-03-27 12:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87c62f03bc07

8010005: [parfait] Memory leak in jdk/src/macosx/native/sun/awt/CTextPipe.m
Reviewed-by: bae, prr
Contributed-by: jia-hong.chen at oracle.com

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 9d4f539e36b6
Author:    lana
Date:      2013-04-02 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d4f539e36b6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 2904672aed21
Author:    lana
Date:      2013-04-09 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2904672aed21

Merge


Changeset: 96750ebc769b
Author:    denis
Date:      2013-03-27 16:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96750ebc769b

7075105: WIN: Provide a way to format HTML on drop
Reviewed-by: uta, serb

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HtmlTransferable.java
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutAllHtmlFlavorsOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutOnlyAllHtmlFlavorOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutSelectionAndFragmentHtmlFlavorsOnClipboard.java

Changeset: 29570523b6cb
Author:    ant
Date:      2013-03-29 16:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29570523b6cb

8010375: sun.swing.JLightweightFrame should be implemented for XToolkit
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
+ src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: c23d58901aa6
Author:    lana
Date:      2013-04-02 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c23d58901aa6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 36cb7921bc98
Author:    mcherkas
Date:      2013-04-03 20:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36cb7921bc98

8011123: serialVersionUID of java.awt.dnd.InvalidDnDOperationException changed in JDK8-b82
Reviewed-by: anthony, serb

! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java

Changeset: 35da3878deef
Author:    mcherkas
Date:      2013-04-03 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35da3878deef

8010925: COPY AND PASTE TO AND FROM SIGNED APPLET FAILS AFTER FIRST INTERNAL COPY PRFRMD
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/native/sun/awt/CClipboard.m

Changeset: 2c36899500a0
Author:    pchelko
Date:      2013-04-05 18:29 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c36899500a0

8006941: [macosx] Deadlock in drag and drop
7199783: Setting cursor on DragSourceContext does not work on OSX
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.m
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
+ test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java

Changeset: 0b083b0e8e63
Author:    kshefov
Date:      2013-04-08 17:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b083b0e8e63

7153702: [TEST_BUG] [macosx] Synchronization problem in test javax/swing/JPopupMenu/6827786/bug6827786.java
Reviewed-by: serb, alexsch

! test/javax/swing/JPopupMenu/6827786/bug6827786.java

Changeset: 981142561d1b
Author:    lana
Date:      2013-04-09 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/981142561d1b

Merge


Changeset: f304311cfe9f
Author:    lana
Date:      2013-04-09 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f304311cfe9f

Merge

! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java

Changeset: 6e3763e737b0
Author:    lana
Date:      2013-04-16 08:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e3763e737b0

Merge


Changeset: a954e407680c
Author:    lana
Date:      2013-04-17 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a954e407680c

Merge


Changeset: 17dcb75682b7
Author:    lana
Date:      2013-04-17 12:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dcb75682b7

Merge


Changeset: 131686bea632
Author:    lana
Date:      2013-04-17 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131686bea632

Merge




From bourges.laurent at gmail.com  Wed Apr 17 20:14:13 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 17 Apr 2013 22:14:13 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
	Memory enhancements
In-Reply-To: <516DBFBF.20504@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
Message-ID: 

Jim,

thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...

Here are ductus results and comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/compareRef_Patch.ods

   test threads ops Tavg Tmed stdDev rms *Med+Stddev* min max  boulder_17 1
20 73,92% 69,34% 27,98% 69,34% *69,14%* 69,81% 146,89%  boulder_17 2 20
110,86% 110,48% 613,80% 112,01% *125,43%* 94,71% 136,35%  boulder_17 4 20
135,28% 135,86% 226,61% 136,46% *141,85%* 125,14% 111,32%  shp_alllayers_47
1 20 82,25% 82,49% 47,50% 82,48% *82,30%* 82,64% 78,08%  shp_alllayers_47 2
20 115,87% 115,67% 315,45% 115,85% *119,89%* 109,33% 128,71%
shp_alllayers_47 4 20 218,59% 218,76% 169,38% 218,65% *216,45%* 220,17%
206,17%
Ductus vs Patch
   *1* *80,74%*  *2* *120,69%*  *4* *205,92%*
Reminder: Ref vs Patch
   *1* *237,71%*  *2* *271,68%*  *4* *286,15%*

Note: I only have 2 cores + HT on my laptop and do not test with more
threads (64 like andrea).

2013/4/16 Jim Graham 

> If I'm reading this correctly, your patch is faster even for a single
> thread?  That's great news.
>

Not yet, but ductus is now only 20% faster than my patch and 20% and 2x
slower with 2 and 4 threads :
I still hope to beat it applying few more optimizations:
- Renderer.ScanLine iterator / Renderer.endRendering can be improved
- avoid few more array zero fill (reset) if possible
- adding statistics to better set initial array sizes ...
- use SunGraphics2D to hold an hard reference (temporarly) on
RendererContext (to avoid many ThreadLocal.get())
- cache eviction (WeakReference or SoftReference) ?

Why not use divide and conquer (thread pool) to boost single thread
rendering if the machine has more cpu cores ?
It would be helpful if the AATileGenerator has access to SunGraphics2D to
get rendering hints or share variables (cache ...)

For the moment, I did not modify the algorithms itself but I will do it to
enhance clipping (dasher segments / stroker) ...


> One of the problems we've had with replacing Ductus is that it has been
> faster in a single thread situation than the open source versions we've
> created.  One of its drawbacks is that it had been designed to take
> advantage of some AA-accelerating hardware that never came to be.  With the
> accelerator it would have been insanely fast, but hardware went in a
> different direction.  The problem was that this early design goal caused
> the entire library to be built around an abstraction layer that allowed for
> a single "tile producer" internally (because there would be only one -
> insanely fast - hardware chip available) and the software version of the
> abstraction layer thus had a lot of native "static" data structures
> (there's only one of me, right?) that prevented MT access.  It was probably
> solvable, but I'd be happier if someone could come up with a faster
> rasterizer, imagining that there must have been some sort of advancements
> in the nearly 2 decades since the original was written.
>
> If I'm misinterpreting and single thread is still slower than Ductus (or
> if it is still slower on some other platforms), then .
>

Not yet: slower than ductus by 20% but faster than current pisces by 2
times !


> Also, this is with the Java version, right?


Yes, my patch is pure java given as webrev:
        http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/


> We got a decent 2x speedup in FX by porting the version of Open Pisces
> that you started with to C code (all except on Linux where we couldn't find
> the right gcc options to make it faster than Hotspot).  So, we have yet to
> investigate a native version in the JDK which might provide even more
> gains...
>

Personally I prefer working on java code as hotspot can perform so much
optimizations for free and no pointers to deal with and more important:
concurrent primitives (thread local, collections) !

Laurent


>
> On 4/15/13 3:01 AM, Laurent Bourg?s wrote:
>
>> Jim, Andrea,
>>
>> I updated MapBench to provide test statistics (avg, median, stddev, rms,
>> med + stddev, min, max) and CSV output (tab separator):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/MapBench/
>> 
>> >
>>
>>
>>
>> Here are the results (OpenJDK8 Ref vs Patched):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/ref_det.**log
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/patch_det.**log
>>
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      180,22%         181,08%         1186,01%
>>        181,17%         185,92%
>> 176,35%         170,36%
>> boulder_17      2       20      183,15%         183,80%         162,68%
>>       183,78%         183,17%
>> 174,01%         169,89%
>> boulder_17      4       20      216,62%         218,03%         349,31%
>>       218,87%         226,68%
>> 172,15%         167,54%
>> shp_alllayers_47        1       20      243,90%         244,86%
>> 537,92%         244,87%         246,39%
>> 240,64%         231,00%
>> shp_alllayers_47        2       20      286,42%         287,07%
>> 294,87%         287,07%         287,23%
>> 277,19%         272,23%
>> shp_alllayers_47        4       20      303,08%         302,15%
>> 168,19%         301,90%         295,90%
>> 462,70%         282,41%
>>
>>
>>
>> PATCH:
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      110,196         109,244         0,529
>> 109,246         109,773         108,197
>> 129,327
>> boulder_17      2       40      127,916         127,363         3,899
>> 127,423         131,262         125,262
>> 151,561
>> boulder_17      4       80      213,085         212,268         14,988
>>  212,796         227,256         155,512
>> 334,407
>> shp_alllayers_47        1       20      1139,452        1134,858
>>  5,971   1134,873        1140,829
>> 1125,859        1235,746
>> shp_alllayers_47        2       40      1306,889        1304,598
>>  28,157  1304,902
>> 1332,755        1280,49         1420,351
>> shp_alllayers_47        4       80      2296,487        2303,81
>> 112,816         2306,57         2416,626
>> 1390,31         2631,455
>>
>>
>>
>> REF:
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      198,591         197,816         6,274
>> 197,916         204,091         190,805
>> 220,319
>> boulder_17      2       40      234,272         234,09  6,343   234,176
>>       240,433         217,967
>> 257,485
>> boulder_17      4       80      461,579         462,8   52,354  465,751
>>       515,153         267,712
>> 560,254
>> shp_alllayers_47        1       20      2779,133        2778,823
>>  32,119  2779,009
>> 2810,943        2709,285        2854,557
>> shp_alllayers_47        2       40      3743,255        3745,111
>>  83,027  3746,031
>> 3828,138        3549,364        3866,612
>> shp_alllayers_47        4       80      6960,23         6960,948
>>  189,75  6963,533        7150,698
>> 6432,945        7431,541
>>
>>
>> Linux 64 server vm
>> JVM: -Xms128m -Xmx128m (low mem)
>>
>> Laurent
>>
>> 2013/4/14 Andrea Aime > >>
>>
>>     On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s
>>
>>     >>
>> wrote:
>>
>>         Dear Java2D members,
>>
>>         Could someone review the following webrev concerning Java2D
>>         Pisces to enhance its performance and reduce its memory
>>         footprint (RendererContext stored in thread local or concurrent
>>         queue):
>>         http://jmmc.fr/~bourgesl/**share/java2d-pisces/webrev-1/
>>         
>> >
>>
>>
>>         FYI I fixed file headers in this patch and signed my OCA 3 weeks
>>         ago.
>>
>>         Remaining work:
>>         - cleanup (comments ...)
>>         - statistics to perform auto-tuning
>>         - cache / memory cleanup (SoftReference ?): use hints or System
>>         properties to adapt it to use cases
>>         - another problem: fix clipping performance in Dasher / Stroker
>>         for segments out of bounds
>>
>>         Could somebody support me ? ie help me working on these tasks or
>>         just to discuss on Pisces algorithm / implementation ?
>>
>>
>>     Hi,
>>     I would like to express my support for this patch.
>>     Given that micro-benchmarks have already been run, I took the patch
>>     for a spin in a large, real world benchmark instead,
>>     the OSGeo WMS Shootout 2010 benchmark, for which you can see the
>>     results here:
>>     http://www.slideshare.net/**gatewaygeomatics.com/wms-**
>> performance-shootout-2010
>>
>>     The presentation is long, but suffice it to say all Java based
>>     implementations took quite the beating due to the
>>     poor scalability of Ductus with antialiased rendering of vector data
>>     (for an executive summary just look
>>     at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
>>     Constellation SDI were the
>>     Java based ones)
>>
>>     I took the same tests and run them again on my machine (different
>>     hardware than the tests, don't try to compare
>>     the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a
>>     checkout a couple of weeks old) and the
>>     same, but with Laurent's patches applied.
>>     Here are the results, throughput (in maps generated per second) with
>>     the load generator (JMeter) going
>>     up from one client to 64 concurrent clients:
>>
>>     *Threads*   *JDK 1.7.0_17*  *OpenJDK 8, vanilla*    *OpenJDK 8 +
>> pisces
>>     renderer improvements*      *Pisces renderer performance gain, %*
>>
>>     1   13,97   12,43   13,03   4,75%
>>     2   22,08   20,60   20,77   0,81%
>>     4   34,36   33,15   33,36   0,62%
>>     8   39,39   40,51   41,71   2,96%
>>     16  40,61   44,57   46,98   5,39%
>>     32  41,41   44,73   48,16   7,66%
>>     64  37,09   42,19   45,28   7,32%
>>
>>
>>     Well, first of all, congratulations to the JDK developers, don't
>>     know what changed in JDK 8, but
>>     GeoServer seems to like it quite a bit :-).
>>     That said, Laurent's patch also gives a visible boost, especially
>>     when several concurrent clients are
>>     asking for the maps.
>>
>>     Mind, as I said, this is no micro-benchmark, it is a real
>>     application loading doing a lot of I/O
>>     (from the operating system file cache), other processing before the
>>     data reaches the rendering
>>     pipeline, and then has to PNG encode the output BufferedImage (PNG
>>     encoding being rather
>>     expensive), so getting this speedup from just a change in the
>>     rendering pipeline is significant.
>>
>>     Long story short... personally I'd be very happy if this patch was
>>     going to be integrated in Java 8 :-)
>>
>>     Cheers
>>     Andrea
>>
>>     --
>>     ==
>>     GeoServer training in Milan, 6th & 7th June 2013!  Visit
>>     http://geoserver.geo-**solutions.it
>>     >
>> for more information.
>>
>>     ==
>>
>>     Ing. Andrea Aime
>>     @geowolf
>>     Technical Lead
>>
>>     GeoSolutions S.A.S.
>>     Via Poggio alle Viti 1187
>>     55054  Massarosa (LU)
>>     Italy
>>     phone: +39 0584 962313
>>     fax: +39 0584 1660272
>>     mob: +39  339 8844549
>>
>>     http://www.geo-solutions.it
>>     http://twitter.com/**geosolutions_it
>>
>>     ------------------------------**-------------------------
>>
>>
>>


From jason_mehrens at hotmail.com  Wed Apr 17 21:03:20 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 17 Apr 2013 16:03:20 -0500
Subject: Code review request for 8012044: Give more information about
	self-suppression from Throwable.addSuppressed
In-Reply-To: <516EDC9A.4070207@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com>,<516EDC9A.4070207@oracle.com>
Message-ID: 

Joe,

The patch at http://cr.openjdk.java.net/~darcy/8012044.3/ looks good to me.  Thanks for working on this.

Jason
 
----------------------------------------
> Date: Wed, 17 Apr 2013 10:32:10 -0700
> From: joe.darcy at oracle.com
> To: jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net; David.Holmes at oracle.com
> Subject: Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed
>
> On 04/14/2013 07:36 PM, Joe Darcy wrote:
> > On 04/12/2013 07:29 PM, Jason Mehrens wrote:
> >> Joe,
> >> You'll have guard ise.addSuppressed against null. Looks good otherwise.
> >>
> >> private static void initCauseNull() {
> >> Throwable t1 = new Throwable();
> >> t1.initCause(null);
> >> try {
> >> t1.initCause(null);
> >> } catch(IllegalStateException expect) {
> >> }
> >> }
> >
> > Right you are; check added and test updated in:
> >
> > http://cr.openjdk.java.net/~darcy/8012044.2/
> >
> > Full patch to Throwable:
>
> [snip]
>
> One more iteration; I've changed the initCause logic to suppress both
> exceptions rather than using one as the cause:
>
> http://cr.openjdk.java.net/~darcy/8012044.2
>
> Patch to throwable:
>
> --- old/src/share/classes/java/lang/Throwable.java 2013-04-14
> 19:33:23.000000000 -0700
> +++ new/src/share/classes/java/lang/Throwable.java 2013-04-14
> 19:33:23.000000000 -0700
> @@ -452,10 +452,15 @@
> * @since 1.4
> */
> public synchronized Throwable initCause(Throwable cause) {
> - if (this.cause != this)
> - throw new IllegalStateException("Can't overwrite cause");
> + if (this.cause != this) {
> + IllegalStateException ise =
> + new IllegalStateException("Can't overwrite cause", this);
> + if (cause != null)
> + ise.addSuppressed(cause);
> + throw ise;
> + }
> if (cause == this)
> - throw new IllegalArgumentException("Self-causation not
> permitted");
> + throw new IllegalArgumentException("Self-causation not
> permitted", this);
> this.cause = cause;
> return this;
> }
> @@ -1039,7 +1044,7 @@
> */
> public final synchronized void addSuppressed(Throwable exception) {
> if (exception == this)
> - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
> + throw new
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>
> if (exception == null)
> throw new NullPointerException(NULL_CAUSE_MESSAGE);
>
> The suppression mechanism is typically, but not exclusively, used by the
> try-with-resources statement.
>
> Thanks,
>
> -Joe 		 	   		  

From philip.race at oracle.com  Wed Apr 17 21:06:17 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 Apr 2013 14:06:17 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory
	enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
Message-ID: <516F0EC9.50706@oracle.com>

 > whereas on Windows / Mac it is client compiler (c1).

For Mac we only have a 64 bit VM which SFAIK should be c2 as well,
yet in that case native was presumably still faster. So its also a matter
of factoring in how good the code is that is generated by the C compiler.

-phil.

On 4/17/2013 1:26 PM, Richard Bair wrote:
>>
>>
>>     Also, this is with the Java version, right? 
>>
>>
>> Yes, my patch is pure java given as webrev:
>> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ 
>> 
>>
>>     We got a decent 2x speedup in FX by porting the version of Open
>>     Pisces that you started with to C code (all except on Linux where
>>     we couldn't find the right gcc options to make it faster than
>>     Hotspot).  So, we have yet to investigate a native version in the
>>     JDK which might provide even more gains? 
>>
>
> Oleg did more analysis on this and it appears the reason hotspot on 
> Linux was faster than the C version was because on Linux it is -server 
> compiler (c2) whereas on Windows / Mac it is client compiler (c1). 
> Possibly using -server on windows / mac would also have hotspot 
> beating the C version, although that hasn't been tested.
>
> Richard
>



From mandy.chung at oracle.com  Wed Apr 17 21:26:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 Apr 2013 14:26:13 -0700
Subject: Incorrect arguments is passed to sun.misc.Perf#createLong
In-Reply-To: <51661903.2060107@ysfactory.dip.jp>
References: <5164007C.5040408@ysfactory.dip.jp> <5165D537.2040403@oracle.com>
	<51661903.2060107@ysfactory.dip.jp>
Message-ID: <516F1375.5080106@oracle.com>

Hi Yasumasa,

Thanks for the patch.  I'm going to sponsor your fix for 8011934 and 
will be pushing it shortly.
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011934/webrev.00/

Mandy

On 4/10/2013 6:59 PM, Yasu wrote:
> Hi Mandy,
>
> On 4:59, Mandy Chung wrote:
>> Hi Yasumasa,
>>
>> I'm adding core-libs and bcc serviceability-dev to move this thread 
>> to core-libs for sun.misc.PerfCounter discussion.
>>
>> On 4/9/2013 4:50 AM, Yasu wrote:
>>> Hi,
>>>
>>> I'm trying to create entry from Java program to hsperfdata through 
>>> sun.misc.PerfCounter .
>>
>> First of all, sun.misc.PerfCounter is a private API that is not 
>> supported and may be changed and removed in any future release. I'm 
>> curious how you create a counter in hsperfdata through 
>> sun.misc.PerfCounter. The constructor is private.
>
> I've understood that sun.* packages is private API.
> I use PerfCounter with reflection API ( setAccessible(true) )  .
>
>
>>> However, I cannot watch the updated value in my entry through the 
>>> jstat with interval option.
>>>
>>> I guess this cause is that wrong arguments are passed from 
>>> PerfCounter# to Perf#createLong .
>>>
>>
>> Indeed - it's a bug that calls Perf.createLong with the incorrect 
>> parameters. I have filed a bug (8011934).
>
> Thanks!
>
>
>> Have you signed the OCA [1]?
>
> Yes.
> I already sent OCA with my signature.
>
>
> Thanks,
>
> Yasumasa
>
>> Thanks
>> Mandy
>> [1] http://openjdk.java.net/contribute/
>>
>>> sun.misc.PerfCounter:
>>> ---------
>>> private PerfCounter(String name, int type) {
>>> this.name = name;
>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L);
>>> bb.order(ByteOrder.nativeOrder());
>>> this.lb = bb.asLongBuffer();
>>> }
>>> ---------
>>>
>>> sun.misc.Perf:
>>> ---------
>>> public native ByteBuffer createLong(String name, int variability,
>>> int units, long value);
>>> ---------
>>>
>>> "type" in constructor of PerfCounter means "variability".
>>> So "type" should be set to 2nd argument in perf.createLong()
>>>
>>> perf.createLong() should be called as following:
>>> ---------
>>> ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
>>> ---------
>>>
>>>
>>> I've applied a patch which is attached in this email, it's works fine.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>



From jim.gish at oracle.com  Wed Apr 17 21:49:11 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 17 Apr 2013 17:49:11 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
Message-ID: <516F18D7.4040308@oracle.com>

Here's an update: 
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 


Jim

On 04/17/2013 03:15 PM, Mike Duigou wrote:
> String::
>
> line 1253: This should use {@code } rather than . I think regular spaces are OK as well.   seems inappropriate.
>
> lines 2425/2467: elements may not be null either.
>
> I can tell you (or maybe it's just me) are itching to change :
>
> for (CharSequence cs: elements) {
> 2477             joiner.add(cs);
> 2478         }
>
> to:
>
> elements.forEach(joiner::add);
>
> StringJoiner::
>
> - 
     isn't needed around 
     as it's already a 
     you probably mean to do
>
> 
     {@code
> ...
> }
    
>
> for code samples.
>
> - It would be nice if the empty output generation in three arg constructor could be suppressed unless needed. Perhaps a special (not null please!) sentinel value?
>
> - Four arg constructor doesn't include emptyOutput in @throws NPE
>
>
> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>
>> Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 
>>
>> These are changes that we made in lambda that we're now bringing into JDK8.
>>
>> I've made a couple of additions - making StringJoiner final and adding a couple of constructors to set the emptyOutput chars.
>>
>> Thanks,
>>    Jim
>>
>> -- 
>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>> Oracle Java Platform Group | Core Libraries Team
>> 35 Network Drive
>> Burlington, MA 01803
>> jim.gish at oracle.com
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From martinrb at google.com  Wed Apr 17 21:53:09 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Apr 2013 14:53:09 -0700
Subject: Use of super in type parameters
In-Reply-To: 
References: 
	
Message-ID: 

With the coming of lambda, it is more likely that people will be creating
APIs with "not quite correct" generic types, as we are doing in
CompletableFuture.  Which is pretty bad for a feature that is designed
specifically to provide compile time safety.  It would be nice to at least
have an acknowledgment that there is a problem here, even if it will not be
fixed for this release.


On Mon, Apr 15, 2013 at 12:50 PM, Zhong Yu  wrote:

> I have encountered on stackoverflow.com several legit use cases of
> lower bound. And the other day Ali Lahijani raised the question that
> Stream.reduce(BinaryOperator) breaks convariance of Stream, and I
> thought that the root problem is lack of lower bound - the method
> would have had a better signature
>     Stream
>          Optional reduce(BinaryOperator accumulator)
> So I don't think there's a lack of use cases for lower bound. (But I
> have no idea how difficult it is to support it)
>
> Zhong Yu
>
>
> On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz 
> wrote:
> > CompletableFuture currently has a method like this:
> >
> >     public CompletableFuture acceptEither
> >         (CompletableFuture other,
> >          Consumer block) {
> >         return doAcceptEither(other, block, null);
> >     }
> >
> > But that signature is not quite correct (not as general as it could be).
> >  The "correct" signature is
> >
> >     public  CompletableFuture acceptEither
> >         (CompletableFuture other,
> >          Consumer block) {
> >         return doAcceptEither(other, block, null);
> >     }
> >
> > but that fails to compile, because type parameters can only be
> constrained
> > by extends, not super.  Is implementing this on the radar?  Angelika
> claims
> > "lower bounds for type parameters make no sense"
> >
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters
> > ?
> >
> > but I am finding that hard to believe.  Is she right? For comparison,
>  the
> > equivalent static method can be made to do what we want:
> >
> >     public static  CompletableFuture acceptEither
> >         (CompletableFuture f,
> >          CompletableFuture other,
> >          Consumer block) {
> >         return ...
> >     }
>


From martinrb at google.com  Wed Apr 17 22:07:43 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Apr 2013 15:07:43 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F18D7.4040308@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
Message-ID: 

I'm still wondering about whether a joiner utility should support a prefix
and suffix.  The obvious uses for this are collection class toString
methods, but we already know that we can and should implement those with a
single precise char[] construction, so should not use StringJoiner, or at
least not this StringJoiner implementation.  And if we're just talking
about pure convenience, it's hard to beat

"[" + String.join(...) + "]"


On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:

> Here's an update: http://cr.openjdk.java.net/~**
> jgish/Bugs-5015163-7172553/<
> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/
> >
>
> Jim
>
>
> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>
>> String::
>>
>> line 1253: This should use {@code } rather than . I think
>> regular spaces are OK as well.   seems inappropriate.
>>
>> lines 2425/2467: elements may not be null either.
>>
>> I can tell you (or maybe it's just me) are itching to change :
>>
>> for (CharSequence cs: elements) {
>> 2477             joiner.add(cs);
>> 2478         }
>>
>> to:
>>
>> elements.forEach(joiner::add);
>>
>> StringJoiner::
>>
>> - 
     isn't needed around 
     as it's already a 
     you
>> probably mean to do
>>
>> 
     {@code
>> ...
>> }
    
>>
>> for code samples.
>>
>> - It would be nice if the empty output generation in three arg
>> constructor could be suppressed unless needed. Perhaps a special (not null
>> please!) sentinel value?
>>
>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>
>>
>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>
>>  Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-*
>>> *7172553/<
>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/
>>> >
>>>
>>> These are changes that we made in lambda that we're now bringing into
>>> JDK8.
>>>
>>> I've made a couple of additions - making StringJoiner final and adding a
>>> couple of constructors to set the emptyOutput chars.
>>>
>>> Thanks,
>>>    Jim
>>>
>>> --
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.gish at oracle.com
>>>
>>>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
>
>


From jim.gish at oracle.com  Wed Apr 17 22:15:19 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 17 Apr 2013 18:15:19 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
Message-ID: <516F1EF7.8030001@oracle.com>

I'm open to this, but am interested in what others have to say, 
especially as it relates to other lambda features coming in.  Bear in 
mind that this is at least the third major round of reviews for these 
changes, the first round being a year ago on lambda-dev, when I first 
submitted them, and then they were distilled some more and greatly 
simplified by Henry Jen.

Thanks,
    Jim

On 04/17/2013 06:07 PM, Martin Buchholz wrote:
> I'm still wondering about whether a joiner utility should support a 
> prefix and suffix.  The obvious uses for this are collection class 
> toString methods, but we already know that we can and should implement 
> those with a single precise char[] construction, so should not use 
> StringJoiner, or at least not this StringJoiner implementation.  And 
> if we're just talking about pure convenience, it's hard to beat
>
> "[" + String.join(...) + "]"
>
>
> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  > wrote:
>
>     Here's an update:
>     http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
>     
>     
>
>     Jim
>
>
>     On 04/17/2013 03:15 PM, Mike Duigou wrote:
>
>         String::
>
>         line 1253: This should use {@code } rather than .
>         I think regular spaces are OK as well.   seems inappropriate.
>
>         lines 2425/2467: elements may not be null either.
>
>         I can tell you (or maybe it's just me) are itching to change :
>
>         for (CharSequence cs: elements) {
>         2477             joiner.add(cs);
>         2478         }
>
>         to:
>
>         elements.forEach(joiner::add);
>
>         StringJoiner::
>
>         - 
     isn't needed around 
     as it's already a
>         
     you probably mean to do
>
>         
     {@code
>         ...
>         }
    
>
>         for code samples.
>
>         - It would be nice if the empty output generation in three arg
>         constructor could be suppressed unless needed. Perhaps a
>         special (not null please!) sentinel value?
>
>         - Four arg constructor doesn't include emptyOutput in @throws NPE
>
>
>         On Apr 11 2013, at 15:33 , Jim Gish wrote:
>
>             Please review
>             http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/
>             
>             
>
>             These are changes that we made in lambda that we're now
>             bringing into JDK8.
>
>             I've made a couple of additions - making StringJoiner
>             final and adding a couple of constructors to set the
>             emptyOutput chars.
>
>             Thanks,
>                Jim
>
>             -- 
>             Jim Gish | Consulting Member of Technical Staff |
>             +1.781.442.0304 
>             Oracle Java Platform Group | Core Libraries Team
>             35 Network Drive
>             Burlington, MA 01803
>             jim.gish at oracle.com 
>
>
>     -- 
>     Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>     
>     Oracle Java Platform Group | Core Libraries Team
>     35 Network Drive
>     Burlington, MA 01803
>     jim.gish at oracle.com 
>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From brian.goetz at oracle.com  Wed Apr 17 22:38:58 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 17 Apr 2013 18:38:58 -0400
Subject: RFR: JDK-8012542 (Stream methods on Collection)
In-Reply-To: <51267293.4060203@oracle.com>
References: <51267293.4060203@oracle.com>
Message-ID: <516F2482.6030606@oracle.com>

Updated spec for Collection.spliterator; default methods for 
Collection.stream() and parallelStream().  Specialized implementations 
in subtypes will come in a separate putback.

Webrev at:

   http://cr.openjdk.java.net/~briangoetz/JDK-8012542/webrev/




From daniel.smith at oracle.com  Wed Apr 17 23:18:32 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 17 Apr 2013 17:18:32 -0600
Subject: Use of super in type parameters
In-Reply-To: 
References: 
Message-ID: 

On Apr 15, 2013, at 1:37 PM, Martin Buchholz  wrote:

> CompletableFuture currently has a method like this:
> 
>     public CompletableFuture acceptEither
>         (CompletableFuture other,
>          Consumer block) {
>         return doAcceptEither(other, block, null);
>     }
> 
> But that signature is not quite correct (not as general as it could be).  The "correct" signature is
> 
>     public  CompletableFuture acceptEither
>         (CompletableFuture other,
>          Consumer block) {
>         return doAcceptEither(other, block, null);
>     }
> 
> but that fails to compile, because type parameters can only be constrained by extends, not super.  Is implementing this on the radar?

My favorite example:
interface Optional {
   S get(S alternate);
}
Optional o = ...;
Number n = o.get(0.0);

We were _this_ close to adding this, or something like it, with Lambda.  In the end, it didn't make the cut.

The good news is that capture variables already have lower bounds, and inference in Java 8 has been enhanced quite a bit, such that it can mostly handle things like this.  So it seems like it would be a relatively modest task to support the feature someday.

>  Angelika claims
> "lower bounds for type parameters make no sense"
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters?
> 
> but I am finding that hard to believe.  Is she right?

Lots of people said a lot of wrong things about generics in the heady Java 5 days.  One or two of those things even ended up in the language spec. :-(  But no, "I can't think of why this would be useful" does not imply "this makes no sense."  (To be fair, I think we all make that leap from time to time.)

> For comparison,  the equivalent static method can be made to do what we want:
> 
>     public static  CompletableFuture acceptEither
>         (CompletableFuture f,
>          CompletableFuture other,
>          Consumer block) {
>         return ...
>     }

Yep, that's the workaround for now.  Or use a weaker signature for your instance method.  (Or both.)

On Apr 17, 2013, at 3:53 PM, Martin Buchholz  wrote:

> With the coming of lambda, it is more likely that people will be creating APIs with "not quite correct" generic types, as we are doing in CompletableFuture.  Which is pretty bad for a feature that is designed specifically to provide compile time safety.

True.  I've made that argument for other axed features as well -- we punt now, and solving the problem later will just be harder, due to further compatibility constraints.  Ultimately, it would be great to make everything perfect out of the gate; but that's not practical.  (And in fact, "out of the gate" in this case was 9 years ago.)  Besides, we have to have something fun to do next time. :-)

?Dan

From dan.xu at oracle.com  Wed Apr 17 23:51:11 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 16:51:11 -0700
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F347D.5030108@oracle.com>
References: <516F347D.5030108@oracle.com>
Message-ID: <516F356F.6010107@oracle.com>

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:
> Hi,
>
> As for the sourcecodes for mac platform, it has a special place 
> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I 
> wonder how those codes are builtand whether its compilation process 
> has any special handling. Thanks!
>
> -Dan



From mike.duigou at oracle.com  Wed Apr 17 23:51:40 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 17 Apr 2013 16:51:40 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
Message-ID: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>

Hello All;

Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:

@apiNote : Non-normative notes about the API. Usually used for examples.
@implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
@implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.

The tags are used primarily by default method implementations but will be used elsewhere as well. 

These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).

http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/

The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.






From zhong.j.yu at gmail.com  Thu Apr 18 00:11:50 2013
From: zhong.j.yu at gmail.com (Zhong Yu)
Date: Wed, 17 Apr 2013 19:11:50 -0500
Subject: Use of super in type parameters
In-Reply-To: 
References: 
	
	
Message-ID: 

On Wed, Apr 17, 2013 at 4:53 PM, Martin Buchholz  wrote:
> With the coming of lambda, it is more likely that people will be creating
> APIs with "not quite correct" generic types, as we are doing in

I believe that we can tweak generic signatures in APIs without
breaking calling codes. No API user really pays attention to all these
questions marks in a signature, he'll just go with instinct about
co/contravariances, deduced from the nature of the method, so his code
shouldn't break when the signature is changed for the better, because
the args he provides are all in the proper types.

For example, if a method signature is supposed to be
     foo(List, List)
but we declare it today as, regrettably,
    foo(List, List)
we don't really expect users to supply List and List where
S1!=S2. If a user does that, it conflicts with the implicit/explicit
contract of the method, the type system couldn't help to catch the
mistake today, but it's a bug regardless.

Zhong Yu

> CompletableFuture.  Which is pretty bad for a feature that is designed
> specifically to provide compile time safety.  It would be nice to at least
> have an acknowledgment that there is a problem here, even if it will not be
> fixed for this release.
>
>
> On Mon, Apr 15, 2013 at 12:50 PM, Zhong Yu  wrote:
>>
>> I have encountered on stackoverflow.com several legit use cases of
>> lower bound. And the other day Ali Lahijani raised the question that
>> Stream.reduce(BinaryOperator) breaks convariance of Stream, and I
>> thought that the root problem is lack of lower bound - the method
>> would have had a better signature
>>     Stream
>>          Optional reduce(BinaryOperator accumulator)
>> So I don't think there's a lack of use cases for lower bound. (But I
>> have no idea how difficult it is to support it)
>>
>> Zhong Yu
>>
>>
>> On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz 
>> wrote:
>> > CompletableFuture currently has a method like this:
>> >
>> >     public CompletableFuture acceptEither
>> >         (CompletableFuture other,
>> >          Consumer block) {
>> >         return doAcceptEither(other, block, null);
>> >     }
>> >
>> > But that signature is not quite correct (not as general as it could be).
>> >  The "correct" signature is
>> >
>> >     public  CompletableFuture acceptEither
>> >         (CompletableFuture other,
>> >          Consumer block) {
>> >         return doAcceptEither(other, block, null);
>> >     }
>> >
>> > but that fails to compile, because type parameters can only be
>> > constrained
>> > by extends, not super.  Is implementing this on the radar?  Angelika
>> > claims
>> > "lower bounds for type parameters make no sense"
>> >
>> > http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters
>> > ?
>> >
>> > but I am finding that hard to believe.  Is she right? For comparison,
>> > the
>> > equivalent static method can be made to do what we want:
>> >
>> >     public static  CompletableFuture acceptEither
>> >         (CompletableFuture f,
>> >          CompletableFuture other,
>> >          Consumer block) {
>> >         return ...
>> >     }
>
>


From david.holmes at oracle.com  Thu Apr 18 00:30:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 10:30:13 +1000
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F356F.6010107@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
Message-ID: <516F3E95.1050308@oracle.com>

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from /common/makefiles/NativeCompilation.gmk

HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:
> Adding core-libs-dev
>
> On 04/17/2013 04:47 PM, Dan Xu wrote:
>> Hi,
>>
>> As for the sourcecodes for mac platform, it has a special place
>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>> wonder how those codes are builtand whether its compilation process
>> has any special handling. Thanks!
>>
>> -Dan
>


From martinrb at google.com  Thu Apr 18 00:37:37 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Apr 2013 17:37:37 -0700
Subject: Use of super in type parameters
In-Reply-To: 
References: 
	
	
	
Message-ID: 

Thanks, all, for the history lesson.


From dan.xu at oracle.com  Thu Apr 18 00:50:20 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 17:50:20 -0700
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F3E95.1050308@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
	<516F3E95.1050308@oracle.com>
Message-ID: <516F434C.4030308@oracle.com>

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m 
source files, but also *.java files. If you check the build results in 
build/macosx-x86_64-normal-server-release/jdk folder, it contains some 
build results specific for jobjc, say gensrc_jobjc/, 
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.

So it must have some extra build steps to generate those jobjc results. 
And I wonder what they are and why they are special and not merged into 
the regular native compilation and java compilation processes. Thanks!

-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:
> Hi Dan,
>
> I don't quite understand the question but all native code building is 
> handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
> utilizes the set up from /common/makefiles/NativeCompilation.gmk
>
> HTH
>
> David
>
> On 18/04/2013 9:51 AM, Dan Xu wrote:
>> Adding core-libs-dev
>>
>> On 04/17/2013 04:47 PM, Dan Xu wrote:
>>> Hi,
>>>
>>> As for the sourcecodes for mac platform, it has a special place
>>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>>> wonder how those codes are builtand whether its compilation process
>>> has any special handling. Thanks!
>>>
>>> -Dan
>>



From dan.xu at oracle.com  Thu Apr 18 00:57:24 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 17 Apr 2013 17:57:24 -0700
Subject: RFR: JDK8011946 - java.util.Currency javadoc has broken link to
	iso.org
Message-ID: <516F44F4.2020300@oracle.com>

Hi All,

Here is ajava doc fix. I have changed the broken link and pointed it to 
the page for standard ISO 4217. Thanks!

Webrev: http://cr.openjdk.java.net/~dxu/8011946/webrev/
Bug: http://bugs.sun.com/view_bug.do?bug_id=8011946

-Dan



From brian.goetz at oracle.com  Thu Apr 18 01:10:01 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 17 Apr 2013 21:10:01 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F1EF7.8030001@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516F1EF7.8030001@oracle.com>
Message-ID: <516F47E9.7020001@oracle.com>

The motivation was indeed that it would support more efficient 
Collection.toString.  (But, I don't believe anything actually uses that 
feature right now, other than tests.)

Even if *our* implementations were not to use this because we had a 
better for-experts construction, I still think this is a useful feature 
that users classes may benefit from in their own toString methods.

On 4/17/2013 6:15 PM, Jim Gish wrote:
> I'm open to this, but am interested in what others have to say,
> especially as it relates to other lambda features coming in.  Bear in
> mind that this is at least the third major round of reviews for these
> changes, the first round being a year ago on lambda-dev, when I first
> submitted them, and then they were distilled some more and greatly
> simplified by Henry Jen.
>
> Thanks,
>     Jim
>
> On 04/17/2013 06:07 PM, Martin Buchholz wrote:
>> I'm still wondering about whether a joiner utility should support a
>> prefix and suffix.  The obvious uses for this are collection class
>> toString methods, but we already know that we can and should implement
>> those with a single precise char[] construction, so should not use
>> StringJoiner, or at least not this StringJoiner implementation.  And
>> if we're just talking about pure convenience, it's hard to beat
>>
>> "[" + String.join(...) + "]"
>>
>>
>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish > > wrote:
>>
>>     Here's an update:
>>     http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
>>     
>>     
>>
>>     Jim
>>
>>
>>     On 04/17/2013 03:15 PM, Mike Duigou wrote:
>>
>>         String::
>>
>>         line 1253: This should use {@code } rather than .
>>         I think regular spaces are OK as well.   seems
>> inappropriate.
>>
>>         lines 2425/2467: elements may not be null either.
>>
>>         I can tell you (or maybe it's just me) are itching to change :
>>
>>         for (CharSequence cs: elements) {
>>         2477             joiner.add(cs);
>>         2478         }
>>
>>         to:
>>
>>         elements.forEach(joiner::add);
>>
>>         StringJoiner::
>>
>>         - 
     isn't needed around 
     as it's already a
>>         
     you probably mean to do
>>
>>         
     {@code
>>         ...
>>         }
    
>>
>>         for code samples.
>>
>>         - It would be nice if the empty output generation in three arg
>>         constructor could be suppressed unless needed. Perhaps a
>>         special (not null please!) sentinel value?
>>
>>         - Four arg constructor doesn't include emptyOutput in @throws NPE
>>
>>
>>         On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>
>>             Please review
>>
>> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/
>>
>> 
>>
>> 
>>
>>             These are changes that we made in lambda that we're now
>>             bringing into JDK8.
>>
>>             I've made a couple of additions - making StringJoiner
>>             final and adding a couple of constructors to set the
>>             emptyOutput chars.
>>
>>             Thanks,
>>                Jim
>>
>>             --             Jim Gish | Consulting Member of Technical
>> Staff |
>>             +1.781.442.0304 
>>             Oracle Java Platform Group | Core Libraries Team
>>             35 Network Drive
>>             Burlington, MA 01803
>>             jim.gish at oracle.com 
>>
>>
>>     --     Jim Gish | Consulting Member of Technical Staff |
>> +1.781.442.0304
>>     
>>     Oracle Java Platform Group | Core Libraries Team
>>     35 Network Drive
>>     Burlington, MA 01803
>>     jim.gish at oracle.com 
>>
>>
>


From Roger.Riggs at Oracle.com  Thu Apr 18 01:20:10 2013
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 17 Apr 2013 21:20:10 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F18D7.4040308@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
Message-ID: <516F4A4A.4040906@Oracle.com>

Hi,

Can I suggest that the StringJoiner.toString() method explicitly append 
the suffix
to the existing StringBuilder.

  152         return (value != null ? value.toString() + suffix : emptyValue);

Currently it will go to the trouble of creating a String from the 
builder and then
transparently create another StringBuilder to do the concatenation.

  152         return (value != null ? value.append(suffix).toString() : emptyValue);

or something similar.

The overhead of StringJoiner supporting prefix and suffix is lower than 
doing it separately
in terms of object allocations and garbage and all places that would 
need write their
own code to do the concatenation.

Roger


On 4/17/13 5:49 PM, Jim Gish wrote:
> Here's an update: 
> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 
> 
>
> Jim
>
> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>> String::
>>
>> line 1253: This should use {@code } rather than . I 
>> think regular spaces are OK as well.   seems inappropriate.
>>
>> lines 2425/2467: elements may not be null either.
>>
>> I can tell you (or maybe it's just me) are itching to change :
>>
>> for (CharSequence cs: elements) {
>> 2477             joiner.add(cs);
>> 2478         }
>>
>> to:
>>
>> elements.forEach(joiner::add);
>>
>> StringJoiner::
>>
>> - 
     isn't needed around 
     as it's already a 
     you 
>> probably mean to do
>>
>> 
     {@code
>> ...
>> }
    
>>
>> for code samples.
>>
>> - It would be nice if the empty output generation in three arg 
>> constructor could be suppressed unless needed. Perhaps a special (not 
>> null please!) sentinel value?
>>
>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>
>>
>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>
>>> Please review 
>>> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 
>>> 
>>>
>>> These are changes that we made in lambda that we're now bringing 
>>> into JDK8.
>>>
>>> I've made a couple of additions - making StringJoiner final and 
>>> adding a couple of constructors to set the emptyOutput chars.
>>>
>>> Thanks,
>>>    Jim
>>>
>>> -- 
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.gish at oracle.com
>>>
>



From mike.duigou at oracle.com  Thu Apr 18 01:53:03 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 17 Apr 2013 18:53:03 -0700
Subject: RFR: JDK8011946 - java.util.Currency javadoc has broken link to
	iso.org
In-Reply-To: <516F44F4.2020300@oracle.com>
References: <516F44F4.2020300@oracle.com>
Message-ID: 

Looks good to me! The table is still accessible from that page it's just no longer part of the page. 

Mike

On Apr 17 2013, at 17:57 , Dan Xu wrote:

> Hi All,
> 
> Here is ajava doc fix. I have changed the broken link and pointed it to the page for standard ISO 4217. Thanks!
> 
> Webrev: http://cr.openjdk.java.net/~dxu/8011946/webrev/
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8011946
> 
> -Dan
> 



From david.holmes at oracle.com  Thu Apr 18 02:18:14 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 12:18:14 +1000
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F434C.4030308@oracle.com>
References: <516F347D.5030108@oracle.com> <516F356F.6010107@oracle.com>
	<516F3E95.1050308@oracle.com> <516F434C.4030308@oracle.com>
Message-ID: <516F57E6.7020808@oracle.com>

On 18/04/2013 10:50 AM, Dan Xu wrote:
> Hi David,
>
> Under src/macosx/native/jobjc folder, it contains not only native *.m
> source files, but also *.java files. If you check the build results in
> build/macosx-x86_64-normal-server-release/jdk folder, it contains some
> build results specific for jobjc, say gensrc_jobjc/,
> gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.
>
> So it must have some extra build steps to generate those jobjc results.
> And I wonder what they are and why they are special and not merged into
> the regular native compilation and java compilation processes. Thanks!

In jdk/makefiles:

- The java files are handled in CompileJavaClasses.gmk.
- There is special handling via GensrcJObjC.gmk

David

> -Dan
>
>
> On 04/17/2013 05:30 PM, David Holmes wrote:
>> Hi Dan,
>>
>> I don't quite understand the question but all native code building is
>> handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn
>> utilizes the set up from /common/makefiles/NativeCompilation.gmk
>>
>> HTH
>>
>> David
>>
>> On 18/04/2013 9:51 AM, Dan Xu wrote:
>>> Adding core-libs-dev
>>>
>>> On 04/17/2013 04:47 PM, Dan Xu wrote:
>>>> Hi,
>>>>
>>>> As for the sourcecodes for mac platform, it has a special place
>>>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>>>> wonder how those codes are builtand whether its compilation process
>>>> has any special handling. Thanks!
>>>>
>>>> -Dan
>>>
>


From martinrb at google.com  Thu Apr 18 03:29:52 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Apr 2013 20:29:52 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F47E9.7020001@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516F1EF7.8030001@oracle.com> <516F47E9.7020001@oracle.com>
Message-ID: 

To be concrete, here's a proposed toString method :
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/toString/
which is pretty good as it stands, but even better once it gets to use the
no-copy String constructor.


From mike.duigou at oracle.com  Thu Apr 18 03:43:28 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 17 Apr 2013 20:43:28 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516F1EF7.8030001@oracle.com> <516F47E9.7020001@oracle.com>
	
Message-ID: <4EF70C1C-B7E1-40F2-A79C-4BEC066D3E6F@oracle.com>

If I don't get a chance to revisit the whole UUID optimization patch soon I will see what I can do about breaking it up further and maybe just do the no-copy String constructor by itself.

Mike

On Apr 17 2013, at 20:29 , Martin Buchholz wrote:

> To be concrete, here's a proposed toString method :
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/toString/
> which is pretty good as it stands, but even better once it gets to use the
> no-copy String constructor.



From mike.duigou at oracle.com  Thu Apr 18 04:02:09 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 18 Apr 2013 04:02:09 +0000
Subject: hg: jdk8/tl/jdk: 8010096: Initial java.util.Spliterator putback
Message-ID: <20130418040222.B5890483EB@hg.openjdk.java.net>

Changeset: 674880648db4
Author:    briangoetz
Date:      2013-04-16 13:51 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/674880648db4

8010096: Initial java.util.Spliterator putback
Reviewed-by: mduigou, alanb, chegar, darcy
Contributed-by: Paul Sandoz , Brian Goetz , Doug Lea 
    

! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterator.java
+ src/share/classes/java/util/Spliterators.java
+ src/share/classes/java/util/Tripwire.java
+ test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
+ test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java



From huizhe.wang at oracle.com  Thu Apr 18 06:28:06 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 17 Apr 2013 23:28:06 -0700
Subject: system reserved property names
Message-ID: <516F9276.1010105@oracle.com>

System.getProperties [1] returns all of the "current" system properties. Is there a way to get a list of the system reserved properties such as "java.version" and etc.?  Would anyone know?


[1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29

Thanks,
Joe



From erik.joelsson at oracle.com  Thu Apr 18 08:46:17 2013
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 Apr 2013 10:46:17 +0200
Subject: What is the Build Process for Codes inside
	jdk/src/macosx/native/jobjc
In-Reply-To: <516F434C.4030308@oracle.com>
References: <516F347D.5030108@oracle.com>
	<516F356F.6010107@oracle.com>	<516F3E95.1050308@oracle.com>
	<516F434C.4030308@oracle.com>
Message-ID: <516FB2D9.2030203@oracle.com>

Hello Dan,

These sources are indeed treated separately. I don't actually know why, 
but they were in the old build. (There the native was compiled as an 
XCode project and the java code with Ant). When converting to the new 
build, we strived to keep differences in build output to a minimum. This 
means that the library libJObjC is built as both 32 and 64 bit and 
packaged as a universal binary. The java source for this is compiled 
with source/target 1.5 for the same reason. Now that equality with the 
old build is no longer a requirement, I would welcome the removal of 
this and moving the source to more standard locations.

To see how it's done, look in jdk/makefiles/CompileNativeLibraries.gmk 
and CompileJavaClasses.gmk and search for jobjc.

/Erik

On 2013-04-18 02:50, Dan Xu wrote:
> Hi David,
>
> Under src/macosx/native/jobjc folder, it contains not only native *.m 
> source files, but also *.java files. If you check the build results in 
> build/macosx-x86_64-normal-server-release/jdk folder, it contains some 
> build results specific for jobjc, say gensrc_jobjc/, 
> gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.
>
> So it must have some extra build steps to generate those jobjc 
> results. And I wonder what they are and why they are special and not 
> merged into the regular native compilation and java compilation 
> processes. Thanks!
>
> -Dan
>
>
> On 04/17/2013 05:30 PM, David Holmes wrote:
>> Hi Dan,
>>
>> I don't quite understand the question but all native code building is 
>> handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
>> utilizes the set up from /common/makefiles/NativeCompilation.gmk
>>
>> HTH
>>
>> David
>>
>> On 18/04/2013 9:51 AM, Dan Xu wrote:
>>> Adding core-libs-dev
>>>
>>> On 04/17/2013 04:47 PM, Dan Xu wrote:
>>>> Hi,
>>>>
>>>> As for the sourcecodes for mac platform, it has a special place
>>>> holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
>>>> wonder how those codes are builtand whether its compilation process
>>>> has any special handling. Thanks!
>>>>
>>>> -Dan
>>>
>


From Alan.Bateman at oracle.com  Thu Apr 18 09:13:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Apr 2013 10:13:42 +0100
Subject: system reserved property names
In-Reply-To: <516F9276.1010105@oracle.com>
References: <516F9276.1010105@oracle.com>
Message-ID: <516FB946.1040500@oracle.com>

On 18/04/2013 07:28, huizhe wang wrote:
> System.getProperties [1] returns all of the "current" system 
> properties. Is there a way to get a list of the system reserved 
> properties such as "java.version" and etc.?  Would anyone know?
>
>
> [1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29 
>
I'm not 100% sure what you mean by "reserved" but I will guess that you 
asking if there is a complete list of the system properties defined by 
the Java SE APIs and perhaps the list of JDK-specific system properties 
too. Off-hand, I'm not aware of a master list, they are instead "buried" 
in the API specs. Is the context the system properties that JAXP 1.5 is 
proposing to define?
-Alan


From huizhe.wang at oracle.com  Thu Apr 18 09:43:32 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 18 Apr 2013 02:43:32 -0700
Subject: JDK-8011653: Upgrade to JAXP 1.5
In-Reply-To: <516BC6BD.1090400@oracle.com>
References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com>
	<516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com>
Message-ID: <516FC044.4070803@oracle.com>


On 4/15/2013 2:22 AM, Alan Bateman wrote:
> On 15/04/2013 08:48, Joe Wang wrote:
>> :
>>
>>>
>>> For the new properties then it specifies that a "a runtime 
>>> exception" will be thrown. Can this be more specific?
>>
>> They can't be in XMLConstants, but they are in the specific 
>> Factories. The properties may be supported by factories that may 
>> throw different exceptions.
> I think it would be help if this were expanded to something like "a 
> runtime exception that is specific to the context is thrown" and give 
> an example so that it's clear what it saying.

Absolutely!  While doing so, I realized that I should have been even 
more specific in what throws which exception. I've added more details to 
the javadoc in Factories and SAXParser.
>
>>
>> Webrevs updated:
>> http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/
> This looks much better. For now, I've stayed focused on the 
> javadoc/spec for now as we have to get that right.
>
> The wording "\"jar\" plus the scheme portion" suggests it matches 
> "jar" exactly and maybe this could be clearer because this is also 
> case insensitive.

Added 'including the keyword "jar"' in Protocols are case-insensitive.

>
> @since on the new properties 1.7. I don't know if this should have 1.8 
> or JAXP 1.5.

I think we'll have approval to integrate JAXP 1.5 into JDK7. So it's 
1.7.  In JAXP javadocs, JDK versions have been used for @since.

>
> The intending of the 
       and 
    •  looks a bit odd when the paragraphs 
> aren't indented. This doesn't impact the generated javadoc of course, 
> just looks odd in the source code.

It was indeed intended since the section within 
         and 
      •  applies to 
the new property only. I've added tabs to make it easier to read.

>
> Otherwise I think the javadoc looks okay to me.

Thanks,
Joe

>
> -Alan



From alan.bateman at oracle.com  Thu Apr 18 10:17:57 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 18 Apr 2013 10:17:57 +0000
Subject: hg: jdk8/tl/jdk: 8011536: (fs) BasicFileAttributes.creationTime()
	should return birth time (mac)
Message-ID: <20130418101843.80C2F483FF@hg.openjdk.java.net>

Changeset: 296c9ec816c6
Author:    alanb
Date:      2013-04-18 11:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/296c9ec816c6

8011536: (fs) BasicFileAttributes.creationTime() should return birth time (mac)
Reviewed-by: chegar

! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixCopyFile.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java
+ test/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java



From sundararajan.athijegannathan at oracle.com  Thu Apr 18 10:39:54 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 18 Apr 2013 10:39:54 +0000
Subject: hg: jdk8/tl/nashorn: 5 new changesets
Message-ID: <20130418104001.5A17D48402@hg.openjdk.java.net>

Changeset: aa8170c0dec9
Author:    sundar
Date:      2013-04-15 20:12 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa8170c0dec9

8012240: Array.prototype.map.call({length: -1, get 0(){throw 0}}, function(){}).length does not throw error
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
+ test/script/basic/JDK-8012240.js

Changeset: 486d92559c37
Author:    sundar
Date:      2013-04-17 16:52 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/486d92559c37

8012457: Function.prototype.apply should accept any array-like argument for function arguments
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeFunction.java
+ test/script/basic/JDK-8012457.js

Changeset: d4468316fe73
Author:    jlaskey
Date:      2013-04-17 08:48 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d4468316fe73

Merge


Changeset: 04b36c02c0e2
Author:    jlaskey
Date:      2013-04-17 15:36 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/04b36c02c0e2

8012529: Remove -esa from testing jvmargs
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! make/project.properties

Changeset: 2bb3b22392d7
Author:    sundar
Date:      2013-04-18 15:47 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2bb3b22392d7

Merge




From Alan.Bateman at oracle.com  Thu Apr 18 11:18:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Apr 2013 12:18:42 +0100
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F18D7.4040308@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
Message-ID: <516FD692.80806@oracle.com>

On 17/04/2013 22:49, Jim Gish wrote:
> Here's an update: 
> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 
> 
>
> Jim
StringJoiner looks much better now, good to see it reduced down to 2 
simple constructors.

One thing that I didn't bring up in the previous round is that as all 
the parameters are CharSequences, then it probably should be made clear 
that the constructors and setEmptyValue method take copies. I'm not 
suggesting it would be logical to implement it otherwise but if someone 
using StringBuilder or mutable CharSequences implementation needs to be 
sure that StringJoiner will do the right thing if the char sequence is 
changed subsequently.

In the class description it reads:

   "if the {@code emptyValue} parameter is supplied via the ..."

which is a bit confusing because a StringJoiner doesn't have a 
"emptyValue parameter". It might be clearer if changed to:

   "if a default empty value is specified via the ..."

A minor comment on the wording in the constructors is that "Also" should 
probably be dropped from the second sentence.

The 3-arg constructor still specifies that it throws NPE if the 
emptyValue is null but there isn't an emptyValue parameter here.

In toString then I assume that you can avoid the +suffix when it is the 
empty string (which is going to very common).

You've addressed my previous comment on String.join not specifying how 
null behaves so this is clear now - thanks.

Also looks like you've moved the tests and extended the coverage for 
nulls - thanks.

So overall I think this is looking much better.

-Alan.


From alan.bateman at oracle.com  Thu Apr 18 11:27:29 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 18 Apr 2013 11:27:29 +0000
Subject: hg: jdk8/tl/jdk: 8009648: Tests fail in -agentvm -concurrency mode
Message-ID: <20130418112800.4B0DA48403@hg.openjdk.java.net>

Changeset: 3c8724085cf7
Author:    alanb
Date:      2013-04-18 12:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c8724085cf7

8009648: Tests fail in -agentvm -concurrency mode
Reviewed-by: alanb
Contributed-by: roger.riggs at oracle.com

! test/Makefile
! test/java/time/TEST.properties



From Ulf.Zibis at CoSoCo.de  Thu Apr 18 11:43:20 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 18 Apr 2013 13:43:20 +0200
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F4A4A.4040906@Oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com> <516F4A4A.4040906@Oracle.com>
Message-ID: <516FDC58.2090802@CoSoCo.de>

Hi,

I don't think it's worth to add the braces at lines 2359..2360.

Please swap lines 2740 <-> 2739.

-Ulf

Am 18.04.2013 03:20, schrieb Roger Riggs:
> Hi,
>
> Can I suggest that the StringJoiner.toString() method explicitly append the suffix
> to the existing StringBuilder.
>
>  152         return (value != null ? value.toString() + suffix : emptyValue);
>
> Currently it will go to the trouble of creating a String from the builder and then
> transparently create another StringBuilder to do the concatenation.
>
>  152         return (value != null ? value.append(suffix).toString() : emptyValue);
>
> or something similar.
>
> The overhead of StringJoiner supporting prefix and suffix is lower than doing it separately
> in terms of object allocations and garbage and all places that would need write their
> own code to do the concatenation.
>
> Roger
>
>
> On 4/17/13 5:49 PM, Jim Gish wrote:
>> Here's an update: http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 
>> 
>>
>> Jim



From Alan.Bateman at oracle.com  Thu Apr 18 12:07:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Apr 2013 13:07:31 +0100
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
Message-ID: <516FE203.4030405@oracle.com>

On 18/04/2013 00:51, Mike Duigou wrote:
> Hello All;
>
> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>
> @apiNote : Non-normative notes about the API. Usually used for examples.
> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>
> The tags are used primarily by default method implementations but will be used elsewhere as well.
>
> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>
> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>
> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>
@implSpec is very welcome, more reasons now with the addition of default 
methods.

Clearly distinguishing normative from non-normative text is also been a 
long standing problem so having a tag to identify the non-normative text 
is very useful. I had to look at a few examples in the lambda/jdk repo 
to convince myself that both @apiNote and @implNote are needed. One 
thing that isn't clear to me is whether the "official" Java SE 
documentation should include the text tagged @implNote or not.

Are you planning to provide a documentation page for these tags? This 
would be useful to others writing API docs in the future.

One question on the webrev. You've listed "factory" and I'm not sure 
that I recognize this. A long standing needs has been to distinguish 
static factory methods in the javadoc and perhaps this is related to 
that? I might have missed something of course.

-Alan


From Ulf.Zibis at CoSoCo.de  Thu Apr 18 12:49:32 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 18 Apr 2013 14:49:32 +0200
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
Message-ID: <516FEBDC.2030004@CoSoCo.de>

Hi,

I'm wondering, that StringJoiner has some logic for pre/suffix, but nothing to loop the elements 
themselves :-(

To me, StringJoiner is a useless complicated box around StringBuilder, and imagine, someone needs 
thread-safety.
It also slows down performance, as it needs additional instances and additional class to be loaded 
(critical at VM startup).

Instead please add to StringBuilder and StringBuffer:
      append(CharSequence... elements);
      append(char delimiter, CharSequence... elements);
append(char delimiter, Iterable elements);
cut(int len);    // removes len chars at the end of the sequence
optional:
append(CharSequence delimiter, CharSequence... elements);
append(CharSequence delimiter, Iterable elements);

For performance reasons, append should always append the trailing delimeter, which could be cut at 
the end.

It's questionable, if class string needs a static (=no relation to an existing string in contrast to 
non-static split()) join method, as it seduces to
         "[" + String.join(...) + "]"
which needs some effort from javac side to optimize to a single StringBuilder task.
IMO we better had StringBuilder.join(...), so javac could easily optimize to:
     new StringBuilder().append('[').append(',', someStrings).cut(1).append(']').toString()

-Ulf


Am 18.04.2013 00:07, schrieb Martin Buchholz:
> I'm still wondering about whether a joiner utility should support a prefix
> and suffix.  The obvious uses for this are collection class toString
> methods, but we already know that we can and should implement those with a
> single precise char[] construction, so should not use StringJoiner, or at
> least not this StringJoiner implementation.  And if we're just talking
> about pure convenience, it's hard to beat
>
> "[" + String.join(...) + "]"
>
>
> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:
>
>> Here's an update: http://cr.openjdk.java.net/~**
>> jgish/Bugs-5015163-7172553/<
>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/
>> Jim
>>
>>
>> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>>
>>> String::
>>>
>>> line 1253: This should use {@code } rather than . I think
>>> regular spaces are OK as well.   seems inappropriate.
>>>
>>> lines 2425/2467: elements may not be null either.
>>>
>>> I can tell you (or maybe it's just me) are itching to change :
>>>
>>> for (CharSequence cs: elements) {
>>> 2477             joiner.add(cs);
>>> 2478         }
>>>
>>> to:
>>>
>>> elements.forEach(joiner::add);
>>>
>>> StringJoiner::
>>>
>>> - 
         isn't needed around 
         as it's already a 
         you
>>> probably mean to do
>>>
>>> 
         {@code
>>> ...
>>> }
        
>>>
>>> for code samples.
>>>
>>> - It would be nice if the empty output generation in three arg
>>> constructor could be suppressed unless needed. Perhaps a special (not null
>>> please!) sentinel value?
>>>
>>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>>
>>>
>>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>>
>>>   Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-*
>>>> *7172553/<
>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/
>>>> These are changes that we made in lambda that we're now bringing into
>>>> JDK8.
>>>>
>>>> I've made a couple of additions - making StringJoiner final and adding a
>>>> couple of constructors to set the emptyOutput chars.
>>>>
>>>> Thanks,
>>>>     Jim
>>>>
>>>> --
>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>> Oracle Java Platform Group | Core Libraries Team
>>>> 35 Network Drive
>>>> Burlington, MA 01803
>>>> jim.gish at oracle.com
>>>>
>>>>
>> --
>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>> Oracle Java Platform Group | Core Libraries Team
>> 35 Network Drive
>> Burlington, MA 01803
>> jim.gish at oracle.com
>>
>>



From roger.riggs at oracle.com  Thu Apr 18 13:27:37 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 18 Apr 2013 09:27:37 -0400
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
Message-ID: <516FF4C9.5010900@oracle.com>

Hi Mike,

The new tags are useful.  JSR 310 has a similar need and construct as
@implSpec and will adopt the common tags.

Some more information would be useful about the changeset;
why are the pre-existing tags included in the change?

Note that Oracle accessibility guidelines for html indicate that headers
should use header tags   to be properly navigable by 
accessibility tools.

Thanks, Roger


On 4/17/2013 7:51 PM, Mike Duigou wrote:
> Hello All;
>
> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>
> @apiNote : Non-normative notes about the API. Usually used for examples.
> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>
> The tags are used primarily by default method implementations but will be used elsewhere as well.
>
> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>
> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>
> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>
>
>
>



From frederic.parain at oracle.com  Thu Apr 18 14:23:09 2013
From: frederic.parain at oracle.com (frederic parain)
Date: Thu, 18 Apr 2013 16:23:09 +0200
Subject: RFR: 7150256: 	Add back Diagnostic Command JMX API
In-Reply-To: <50D3A1DD.4040703@oracle.com>
References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com>
	<50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com>
Message-ID: <517001CD.2080109@oracle.com>

Mandy,

Thanks for the review

New webrevs are available here:

7150256:
http://cr.openjdk.java.net/~fparain/7150256/webrev.05/

8004095:
http://cr.openjdk.java.net/~fparain/8004095/webrev.05/

My answers to your questions are in-lined below.

On 21/12/2012 00:40, Mandy Chung wrote:
> Hi Frederic,
>
> It's good to see the management interface for diagnostic commands is back.
>
> On 12/17/12 6:58 AM, Frederic Parain wrote:
>>
>> http://cr.openjdk.java.net/~fparain/7150256/webrev.01/
>>
> Please send your makefiles change to build-dev and build-infra for
> review to ensure necessary change is made in the new build-infra work.

makefiles have been reviewed and approved by the build team.

> I didn't have time to a detailed review and I think it looks okay. Some
> comments:
>
> DiagnosticCommandImpl.Wrapper class
>     If there is any issue initializing the diagnostic command, it
> ignores the exception.  That makes it very hard to diagnose when things
> go wrong.  This exports diagnostic commands supported by the running JVM
> and so I would think any error would be a bug.

An exception when creating the Wrapper doesn't necessarily mean a bug.
The call to get the list of diagnostic commands and the call to get
the descriptions of these commands cannot be performed in an atomic
way. Because the diagnostic command framework allows dynamic
addition and removal of commands, a command might "disappear" between
the two calls. In this case, the creation of the wrapper for this
command will fail, but this shouldn't be considered as a bug.

> DiagnosticCommandArgumentInfo is non-public class but its constructor
> and methods are still public.

Fixed.

> The new tests hardcode the port number that is unreliable and may fail
> in nightly/jprt testing (e.g. the port is occupied by another test
> run).   Some management tests have the same reliability issue and I'm
> not sure what the state is right now.  It'd be good if the new tests can
> avoid using hardcode port number.

I don't know how to avoid the hardcoding of the port without wrapping
the test in a shell scripts. Is there a template available to do
dynamic port allocation?

Thanks,

Fred

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From pbenedict at apache.org  Thu Apr 18 14:26:58 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 18 Apr 2013 09:26:58 -0500
Subject: RFR: JDK-8011917 (java.util.stream.Collectors)
In-Reply-To: <516EF76F.4060703@oracle.com>
References: <51267293.4060203@oracle.com>
	<516EF76F.4060703@oracle.com>
Message-ID: 

Brian, this is low-hanging fruit, but all descriptions after @param and
@return should start with lowercase per published JavaDoc conventions.


On Wed, Apr 17, 2013 at 2:26 PM, Brian Goetz  wrote:

> Single new source file at:
>
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/76ac19e61df1/src/share/classes/java/util/stream/Collectors.java
>
> Doc at:
>
>
> http://cr.openjdk.java.net/~briangoetz/JDK-8008682/api/java/util/stream/Collectors.html
>
> for JDK-8011917 (Collectors class in java.util.stream).
>
> (No webrev as there's just one new file.)
>
>
>


From mike.duigou at oracle.com  Thu Apr 18 15:01:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 08:01:24 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <516FF4C9.5010900@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
Message-ID: <019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>


On Apr 18 2013, at 06:27 , roger riggs wrote:

> Hi Mike,
> 
> The new tags are useful.  JSR 310 has a similar need and construct as
> @implSpec and will adopt the common tags.
> 
> Some more information would be useful about the changeset;
> why are the pre-existing tags included in the change?

Sorry I had meant to mention this in my original note but forgot. The pre-existing tags are enumerated to provide ordering. Normally new tags added with -tag are appended into javadoc output. Since we wish to order the new tags before @param tags we have to provide the total ordering of all tags.

> 
> Note that Oracle accessibility guidelines for html indicate that headers
> should use header tags   to be properly navigable by accessibility tools.

Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.

Mike

> 
> Thanks, Roger
> 
> 
> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>> Hello All;
>> 
>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>> 
>> @apiNote : Non-normative notes about the API. Usually used for examples.
>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>> 
>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>> 
>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>> 
>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>> 
>> 
>> 
>> 
> 



From mike.duigou at oracle.com  Thu Apr 18 15:12:49 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 08:12:49 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <516FE203.4030405@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FE203.4030405@oracle.com>
Message-ID: <03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>


On Apr 18 2013, at 05:07 , Alan Bateman wrote:

> On 18/04/2013 00:51, Mike Duigou wrote:
>> Hello All;
>> 
>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>> 
>> @apiNote : Non-normative notes about the API. Usually used for examples.
>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>> 
>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>> 
>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>> 
>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>> 
> @implSpec is very welcome, more reasons now with the addition of default methods.
> 
> Clearly distinguishing normative from non-normative text is also been a long standing problem so having a tag to identify the non-normative text is very useful. I had to look at a few examples in the lambda/jdk repo to convince myself that both @apiNote and @implNote are needed. One thing that isn't clear to me is whether the "official" Java SE documentation should include the text tagged @implNote or not.

Once we got going we decided to fill out the matrix. There's no obligation to use all of the tags.


> Are you planning to provide a documentation page for these tags? This would be useful to others writing API docs in the future.

I hadn't planned to though I understand it would be useful. Perhaps something for the wiki?

> One question on the webrev. You've listed "factory" and I'm not sure that I recognize this.

The @factory tag is actually present in the current javadoc tool. I don't know it's origin or why it was never documented. Only the @apiNote, @implSpec and @implNote are new tags. The pre-existing tags are enumerated along with the new tags to provide ordering for tag output. Normally the output of new tags added with -tag is placed at the end of the javadoc output after other tags. Since we wish to order the new tags before @param tags we have to provide the total ordering of all tags. 

> A long standing needs has been to distinguish static factory methods in the javadoc and perhaps this is related to that? I might have missed something of course.

Since it's never been documented or adopted for usage the @factory tag should probably be avoided for now. In particular it's output will be incomplete (no title) and not localized. We may want to remove it before someone notices it and starts to use it! :-)

Mike




From roger.riggs at oracle.com  Thu Apr 18 15:44:19 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 18 Apr 2013 11:44:19 -0400
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
Message-ID: <517014D3.4030503@oracle.com>

Hi Mike,

On 4/18/2013 11:01 AM, Mike Duigou wrote:
>> Note that Oracle accessibility guidelines for html indicate that headers
>> should use header tags   to be properly navigable by accessibility tools.
> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.

ok, I see that javadoc defines the tag to be wrapped in  
xxx.

I don't see that the additional emphasis is needed relative to the other
style elements of the javadoc.

I would remove the  explicit markup or if possible delegate
to the stylesheet with a .

Roger

>
> Mike
>
>> Thanks, Roger
>>
>>
>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>> Hello All;
>>>
>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>
>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>
>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>
>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>
>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>
>>>
>>>
>>>



From daniel.smith at oracle.com  Thu Apr 18 16:33:08 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 18 Apr 2013 10:33:08 -0600
Subject: Use of super in type parameters
In-Reply-To: 
References: 
	
	
	
Message-ID: <0740B39E-B9A8-44C9-A6DE-1F739BCF8777@oracle.com>

On Apr 17, 2013, at 6:11 PM, Zhong Yu  wrote:

> On Wed, Apr 17, 2013 at 4:53 PM, Martin Buchholz  wrote:
>> With the coming of lambda, it is more likely that people will be creating
>> APIs with "not quite correct" generic types, as we are doing in
> 
> I believe that we can tweak generic signatures in APIs without
> breaking calling codes.

It's one thing to make a change that won't break callers.  It's another to make a change that won't break implementers.

>     foo(List, List)
> but we declare it today as, regrettably,
>    foo(List, List)

Unfortunately (without some sort of language change...), neither one of these signatures can be used to override the other.  So if somebody extends my class and overrides my signature, when I change it to the other one later, their code will break.

?Dan

From mike.duigou at oracle.com  Thu Apr 18 16:49:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 09:49:45 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <517014D3.4030503@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
	<517014D3.4030503@oracle.com>
Message-ID: <8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>


On Apr 18 2013, at 08:44 , roger riggs wrote:

> Hi Mike,
> 
> On 4/18/2013 11:01 AM, Mike Duigou wrote:
>>> Note that Oracle accessibility guidelines for html indicate that headers
>>> should use header tags   to be properly navigable by accessibility tools.
>> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.
> 
> ok, I see that javadoc defines the tag to be wrapped in  xxx.
> 
> I don't see that the additional emphasis is needed relative to the other
> style elements of the javadoc.

I *had* thought I was copying the JLS tag but see now that that's not the case. I no longer remember where the  came from.

> 
> I would remove the  explicit markup or if possible delegate
> to the stylesheet with a .

I will remove it and allow the default formatting to be used.

> 
> Roger
> 
>> 
>> Mike
>> 
>>> Thanks, Roger
>>> 
>>> 
>>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>>> Hello All;
>>>> 
>>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>> 
>>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>> 
>>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>> 
>>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>> 
>>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>> 
>>>> 
>>>> 
>>>> 
> 



From dan.xu at oracle.com  Thu Apr 18 17:23:19 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 18 Apr 2013 17:23:19 +0000
Subject: hg: jdk8/tl/jdk: 8011946: java.util.Currency javadoc has broken link
	to iso.org
Message-ID: <20130418172331.65E6248414@hg.openjdk.java.net>

Changeset: 3cc833b1fd0c
Author:    dxu
Date:      2013-04-18 10:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cc833b1fd0c

8011946: java.util.Currency javadoc has broken link to iso.org
Reviewed-by: mduigou

! src/share/classes/java/util/Currency.java



From jim.gish at oracle.com  Thu Apr 18 17:34:54 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 18 Apr 2013 13:34:54 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516F4A4A.4040906@Oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com> <516F4A4A.4040906@Oracle.com>
Message-ID: <51702EBE.3060605@oracle.com>

That was a nice idea, but you don't want to change the value when you do 
toString().  Otherwise, if you subsequently add a new element, you're 
hosed because you've already added on the suffix.

Jim

On 04/17/2013 09:20 PM, Roger Riggs wrote:
> Hi,
>
> Can I suggest that the StringJoiner.toString() method explicitly 
> append the suffix
> to the existing StringBuilder.
>
>  152         return (value != null ? value.toString() + suffix : 
> emptyValue);
>
> Currently it will go to the trouble of creating a String from the 
> builder and then
> transparently create another StringBuilder to do the concatenation.
>
>  152         return (value != null ? value.append(suffix).toString() : 
> emptyValue);
>
> or something similar.
>
> The overhead of StringJoiner supporting prefix and suffix is lower 
> than doing it separately
> in terms of object allocations and garbage and all places that would 
> need write their
> own code to do the concatenation.
>
> Roger
>
>
> On 4/17/13 5:49 PM, Jim Gish wrote:
>> Here's an update: 
>> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 
>> 
>>
>> Jim
>>
>> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>>> String::
>>>
>>> line 1253: This should use {@code } rather than . I 
>>> think regular spaces are OK as well.   seems inappropriate.
>>>
>>> lines 2425/2467: elements may not be null either.
>>>
>>> I can tell you (or maybe it's just me) are itching to change :
>>>
>>> for (CharSequence cs: elements) {
>>> 2477             joiner.add(cs);
>>> 2478         }
>>>
>>> to:
>>>
>>> elements.forEach(joiner::add);
>>>
>>> StringJoiner::
>>>
>>> - 
         isn't needed around 
         as it's already a 
         you 
>>> probably mean to do
>>>
>>> 
         {@code
>>> ...
>>> }
        
>>>
>>> for code samples.
>>>
>>> - It would be nice if the empty output generation in three arg 
>>> constructor could be suppressed unless needed. Perhaps a special 
>>> (not null please!) sentinel value?
>>>
>>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>>
>>>
>>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>>
>>>> Please review 
>>>> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 
>>>> 
>>>>
>>>> These are changes that we made in lambda that we're now bringing 
>>>> into JDK8.
>>>>
>>>> I've made a couple of additions - making StringJoiner final and 
>>>> adding a couple of constructors to set the emptyOutput chars.
>>>>
>>>> Thanks,
>>>>    Jim
>>>>
>>>> -- 
>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>> Oracle Java Platform Group | Core Libraries Team
>>>> 35 Network Drive
>>>> Burlington, MA 01803
>>>> jim.gish at oracle.com
>>>>
>>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From jim.gish at oracle.com  Thu Apr 18 17:37:25 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 18 Apr 2013 13:37:25 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <516FEBDC.2030004@CoSoCo.de>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de>
Message-ID: <51702F55.5050702@oracle.com>


On 04/18/2013 08:49 AM, Ulf Zibis wrote:
> Hi,
>
> I'm wondering, that StringJoiner has some logic for pre/suffix, but 
> nothing to loop the elements themselves :-(
>
> To me, StringJoiner is a useless complicated box around StringBuilder, 
> and imagine, someone needs thread-safety.
> It also slows down performance, as it needs additional instances and 
> additional class to be loaded (critical at VM startup).
>
> Instead please add to StringBuilder and StringBuffer:
>      append(CharSequence... elements);
>      append(char delimiter, CharSequence... elements);
> append(char delimiter, Iterable elements);
> cut(int len);    // removes len chars at the end of the sequence
> optional:
> append(CharSequence delimiter, CharSequence... elements);
> append(CharSequence delimiter, Iterable 
> elements);
I started off with something similar, but it was stripped out when Henry 
did the performance improvements.
Given that most people feel that this is going to be put to heavy-weight 
usage, it doesn't seem to merit too much emphasis on performance or 
complicating the implementation at this point.

Thanks
>
> For performance reasons, append should always append the trailing 
> delimeter, which could be cut at the end.
>
> It's questionable, if class string needs a static (=no relation to an 
> existing string in contrast to non-static split()) join method, as it 
> seduces to
>         "[" + String.join(...) + "]"
> which needs some effort from javac side to optimize to a single 
> StringBuilder task.
> IMO we better had StringBuilder.join(...), so javac could easily 
> optimize to:
>     new StringBuilder().append('[').append(',', 
> someStrings).cut(1).append(']').toString()
>
> -Ulf
>
>
> Am 18.04.2013 00:07, schrieb Martin Buchholz:
>> I'm still wondering about whether a joiner utility should support a 
>> prefix
>> and suffix.  The obvious uses for this are collection class toString
>> methods, but we already know that we can and should implement those 
>> with a
>> single precise char[] construction, so should not use StringJoiner, 
>> or at
>> least not this StringJoiner implementation.  And if we're just talking
>> about pure convenience, it's hard to beat
>>
>> "[" + String.join(...) + "]"
>>
>>
>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:
>>
>>> Here's an update: http://cr.openjdk.java.net/~**
>>> jgish/Bugs-5015163-7172553/< 
>>>
>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/ 
>>>
>>> Jim
>>>
>>>
>>> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>>>
>>>> String::
>>>>
>>>> line 1253: This should use {@code } rather than . I think
>>>> regular spaces are OK as well.   seems inappropriate.
>>>>
>>>> lines 2425/2467: elements may not be null either.
>>>>
>>>> I can tell you (or maybe it's just me) are itching to change :
>>>>
>>>> for (CharSequence cs: elements) {
>>>> 2477             joiner.add(cs);
>>>> 2478         }
>>>>
>>>> to:
>>>>
>>>> elements.forEach(joiner::add);
>>>>
>>>> StringJoiner::
>>>>
>>>> - 
         isn't needed around 
         as it's already a 
         you
>>>> probably mean to do
>>>>
>>>> 
         {@code
>>>> ...
>>>> }
        
>>>>
>>>> for code samples.
>>>>
>>>> - It would be nice if the empty output generation in three arg
>>>> constructor could be suppressed unless needed. Perhaps a special 
>>>> (not null
>>>> please!) sentinel value?
>>>>
>>>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>>>
>>>>
>>>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>>>
>>>>   Please review 
>>>> http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-*
>>>>> *7172553/< 
>>>>>
>>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/ 
>>>>>
>>>>> These are changes that we made in lambda that we're now bringing into
>>>>> JDK8.
>>>>>
>>>>> I've made a couple of additions - making StringJoiner final and 
>>>>> adding a
>>>>> couple of constructors to set the emptyOutput chars.
>>>>>
>>>>> Thanks,
>>>>>     Jim
>>>>>
>>>>> -- 
>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>>> Oracle Java Platform Group | Core Libraries Team
>>>>> 35 Network Drive
>>>>> Burlington, MA 01803
>>>>> jim.gish at oracle.com
>>>>>
>>>>>
>>> -- 
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.gish at oracle.com
>>>
>>>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From Alan.Bateman at oracle.com  Thu Apr 18 17:43:30 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Apr 2013 18:43:30 +0100
Subject: RFR: JDK-8005954: JAXP Plugability Layer should use
	java.util.ServiceLoader
In-Reply-To: <516ED29D.9060809@oracle.com>
References: <516EC2B6.2030302@oracle.com> <516ECE0D.4080406@oracle.com>
	<516ED29D.9060809@oracle.com>
Message-ID: <517030C2.9030102@oracle.com>

On 17/04/2013 17:49, Daniel Fuchs wrote:
>
> Most of the merge troubles were in the FactoryFinder.java
> and XxxxFactoryFinder.java files - the merge was a bit difficult 
> because some lines had changes in both parent and child - like
> method signature where a  had been added to the return type
> in the child and a new argument had been added in the parent.
>
> In transform/FactoryFinder I had removed a boolean from the
> newInstance(...) methods - and that caused a merge issue too
> which had to be resolved carefully.
> (originally requested by Mandy who noticed that the method
>  was always called with the same boolean value - and therefore
>  did not need that boolean has argument).
>
> Merge in the other files was otherwise trivial.
>
> -- daniel
I've looked through the FactoryFinders again and I don't see anything 
obviously wrong (meaning it looks like the changes we agreed). So I 
think this is good to go.

-Alan


From roger.riggs at oracle.com  Thu Apr 18 17:56:27 2013
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 18 Apr 2013 13:56:27 -0400
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
	<517014D3.4030503@oracle.com>
	<8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>
Message-ID: <517033CB.8070300@oracle.com>

Hi Mike,

Another wrinkle...

The "a" tag allows the tag to be used in any context package, method, 
constructor, package,
field and type and overview.  However, the predefined javadoc structure 
makes it
unsuitable for use in the package and overview.

Since javadoc groups the tags inside an indented 
        ... blocks it
looks quite odd.  For an example see,
http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/java/time/package-summary.html

Scan down to the "Implementation Requirements" header.
Since there is no 'end' to the @implSpec the rest of the input is indented.

I would not recommend use of any of these in the overview or package 
contexts.

Roger


On 4/18/2013 12:49 PM, Mike Duigou wrote:
> On Apr 18 2013, at 08:44 , roger riggs wrote:
>
>> Hi Mike,
>>
>> On 4/18/2013 11:01 AM, Mike Duigou wrote:
>>>> Note that Oracle accessibility guidelines for html indicate that headers
>>>> should use header tags   to be properly navigable by accessibility tools.
>>> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.
>> ok, I see that javadoc defines the tag to be wrapped in  xxx.
>>
>> I don't see that the additional emphasis is needed relative to the other
>> style elements of the javadoc.
> I *had* thought I was copying the JLS tag but see now that that's not the case. I no longer remember where the  came from.
>
>> I would remove the  explicit markup or if possible delegate
>> to the stylesheet with a .
> I will remove it and allow the default formatting to be used.
>
>> Roger
>>
>>> Mike
>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>>>> Hello All;
>>>>>
>>>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>>>
>>>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>>>
>>>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>>>
>>>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>>>
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>>>
>>>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>>>
>>>>>
>>>>>
>>>>>



From mandy.chung at oracle.com  Thu Apr 18 18:07:32 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Apr 2013 11:07:32 -0700
Subject: Review Request: 8012624: Add
	sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java
	in ProblemList.txt
Message-ID: <51703664.5000104@oracle.com>

This fix adds GetSafepointSyncTime.java test in the ProblemList.txt
until 8010897 is resolved. It has been failing intermittently on macosx-x64.

diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -144,6 +144,9 @@

  # jdk_management

+# 8010897
+sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java   macosx-all
+
  ############################################################################

  # jdk_jmx




From Lance.Andersen at oracle.com  Thu Apr 18 18:09:23 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 18 Apr 2013 14:09:23 -0400
Subject: Review Request: 8012624: Add
	sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java in
	ProblemList.txt
In-Reply-To: <51703664.5000104@oracle.com>
References: <51703664.5000104@oracle.com>
Message-ID: <0B48571E-3109-455B-8D70-3BAD4F8E4D98@oracle.com>

+1
On Apr 18, 2013, at 2:07 PM, Mandy Chung wrote:

> This fix adds GetSafepointSyncTime.java test in the ProblemList.txt
> until 8010897 is resolved. It has been failing intermittently on macosx-x64.
> 
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -144,6 +144,9 @@
> 
> # jdk_management
> 
> +# 8010897
> +sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java   macosx-all
> +
> ############################################################################
> 
> # jdk_jmx
> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From Alan.Bateman at oracle.com  Thu Apr 18 18:09:53 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Apr 2013 19:09:53 +0100
Subject: Review Request: 8012624: Add
	sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java
	in ProblemList.txt
In-Reply-To: <51703664.5000104@oracle.com>
References: <51703664.5000104@oracle.com>
Message-ID: <517036F1.8080803@oracle.com>

On 18/04/2013 19:07, Mandy Chung wrote:
> This fix adds GetSafepointSyncTime.java test in the ProblemList.txt
> until 8010897 is resolved. It has been failing intermittently on 
> macosx-x64.
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -144,6 +144,9 @@
>
>  # jdk_management
>
> +# 8010897
> +sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java   
> macosx-all
> +
>  ############################################################################ 
>
>
>  # jdk_jmx
>
Looks fine to me.

-Alan



From mandy.chung at oracle.com  Thu Apr 18 18:15:08 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 18 Apr 2013 18:15:08 +0000
Subject: hg: jdk8/tl/jdk: 8012624: Add
	sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java in
	ProblemList.txt
Message-ID: <20130418181520.58C1048417@hg.openjdk.java.net>

Changeset: 32c3a580812b
Author:    mchung
Date:      2013-04-18 11:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32c3a580812b

8012624: Add sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java in ProblemList.txt
Reviewed-by: lancea, alanb

! test/ProblemList.txt



From akhil.arora at oracle.com  Thu Apr 18 18:49:47 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 18 Apr 2013 11:49:47 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C6C51C.8080903@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
Message-ID: <5170404B.9000708@oracle.com>

Looks like the stars are aligning on getting on this into TL... the 
refreshed webrev is -

http://cr.openjdk.java.net/~akhil/8001647.8/webrev/

Please review

Thanks

On 12/10/2012 09:31 PM, Akhil Arora wrote:
> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
>
> - now with synchronized and unmodifiable wrappers in Collections.java
> for the default methods being added
>
> On 12/10/2012 01:48 PM, Akhil Arora wrote:
>> Updated with yours and Alan's comments -
>>
>> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>>
>> - removed null check for removeSet
>> - cache this.size in removeAll, replaceAll
>>      (for ArrayList, Vector and CopyOnWriteArrayList)
>> - calculate removeCount instead of BitCount.cardinality()
>> - removed unnecessary @library from test support classes



From mike.duigou at oracle.com  Thu Apr 18 19:36:59 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 12:36:59 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5170404B.9000708@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com>
Message-ID: <84BA98C9-0C2E-4BA4-BF6D-F4007DA8EDB7@oracle.com>

Hi Akhil;

List.sort:: 

- @since tag is in a strange location.

- The (optional) on IAE is in a strange position and not linked like the others.


AbstractList::

- Should we consider adding overrides for default methods here even if our impls wouldn't use them? We could at least add modCount checking.

Tests::

- Lots of enhancement here since my last review. Good Job!

- Wrong GPL license. Tests don't get Classpath exemption.

- In Map.Defaults (around line 539 in http://cr.openjdk.java.net/~mduigou/JDK-8010122/6/webrev/test/java/util/Map/Defaults.java.html) I found it useful to generate an implementation of the base interface to directly test the default methods implementations. You may want to add something similar to CollectionExtensionMethodsTest. 

- You may want to include a Collections.newSetFromMap in DataProvider.

- I am now preferring the Iterator return from DataProvider though I haven't made an on-demand provider yet. You could also mark your DataProvider as ", parallel = true"

On Apr 18 2013, at 11:49 , Akhil Arora wrote:

> Looks like the stars are aligning on getting on this into TL... the refreshed webrev is -
> 
> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
> 
> Please review
> 
> Thanks
> 
> On 12/10/2012 09:31 PM, Akhil Arora wrote:
>> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
>> 
>> - now with synchronized and unmodifiable wrappers in Collections.java
>> for the default methods being added
>> 
>> On 12/10/2012 01:48 PM, Akhil Arora wrote:
>>> Updated with yours and Alan's comments -
>>> 
>>> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>>> 
>>> - removed null check for removeSet
>>> - cache this.size in removeAll, replaceAll
>>>     (for ArrayList, Vector and CopyOnWriteArrayList)
>>> - calculate removeCount instead of BitCount.cardinality()
>>> - removed unnecessary @library from test support classes
> 



From mandy.chung at oracle.com  Thu Apr 18 20:03:12 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 18 Apr 2013 20:03:12 +0000
Subject: hg: jdk8/tl/jdk: 8011934: sun.misc.PerfCounter calls Perf.createLong
	with incorrect parameters
Message-ID: <20130418200325.B1F6248420@hg.openjdk.java.net>

Changeset: 3b81fac25d26
Author:    mchung
Date:      2013-04-18 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b81fac25d26

8011934: sun.misc.PerfCounter calls Perf.createLong with incorrect parameters
Reviewed-by: mchung
Contributed-by: Yasumasa Suenaga 

! src/share/classes/sun/misc/PerfCounter.java



From jim.gish at oracle.com  Thu Apr 18 20:15:12 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 18 Apr 2013 16:15:12 -0400
Subject: RFR: 8012005: LogManager needs test to ensure stack trace is not
	being done to find bundle
Message-ID: <51705450.8090606@oracle.com>

Please review 
http://cr.openjdk.java.net/~jgish/Bug8012005-BundleSearchTest/ 


This is a new test for LogManager to ensure that the changes made for 
8002070 (removing the stack search when finding a resource bundle), are 
working properly.

Thanks,
     Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Thu Apr 18 20:41:00 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Apr 2013 13:41:00 -0700
Subject: Incorrect arguments is passed to sun.misc.Perf#createLong
In-Reply-To: <516F1375.5080106@oracle.com>
References: <5164007C.5040408@ysfactory.dip.jp> <5165D537.2040403@oracle.com>
	<51661903.2060107@ysfactory.dip.jp> <516F1375.5080106@oracle.com>
Message-ID: <51705A5C.8060608@oracle.com>

I have pushed the changeset:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b81fac25d26

FYI.  While looking at the hotspot implementation, I found a bug that 
creates the long counter of incorrect type (it got V_Variable and 
V_Monotonic reverse).  I have file a hotspot bug and suggested a patch:
   8012641: Perf_CreateLong creates perf counter of incorrect type

Mandy

On 4/17/13 2:26 PM, Mandy Chung wrote:
> Hi Yasumasa,
>
> Thanks for the patch.  I'm going to sponsor your fix for 8011934 and 
> will be pushing it shortly.
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011934/webrev.00/
>
> Mandy
>
> On 4/10/2013 6:59 PM, Yasu wrote:
>> Hi Mandy,
>>
>> On 4:59, Mandy Chung wrote:
>>> Hi Yasumasa,
>>>
>>> I'm adding core-libs and bcc serviceability-dev to move this thread 
>>> to core-libs for sun.misc.PerfCounter discussion.
>>>
>>> On 4/9/2013 4:50 AM, Yasu wrote:
>>>> Hi,
>>>>
>>>> I'm trying to create entry from Java program to hsperfdata through 
>>>> sun.misc.PerfCounter .
>>>
>>> First of all, sun.misc.PerfCounter is a private API that is not 
>>> supported and may be changed and removed in any future release. I'm 
>>> curious how you create a counter in hsperfdata through 
>>> sun.misc.PerfCounter. The constructor is private.
>>
>> I've understood that sun.* packages is private API.
>> I use PerfCounter with reflection API ( setAccessible(true) )  .
>>
>>
>>>> However, I cannot watch the updated value in my entry through the 
>>>> jstat with interval option.
>>>>
>>>> I guess this cause is that wrong arguments are passed from 
>>>> PerfCounter# to Perf#createLong .
>>>>
>>>
>>> Indeed - it's a bug that calls Perf.createLong with the incorrect 
>>> parameters. I have filed a bug (8011934).
>>
>> Thanks!
>>
>>
>>> Have you signed the OCA [1]?
>>
>> Yes.
>> I already sent OCA with my signature.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>> Thanks
>>> Mandy
>>> [1] http://openjdk.java.net/contribute/
>>>
>>>> sun.misc.PerfCounter:
>>>> ---------
>>>> private PerfCounter(String name, int type) {
>>>> this.name = name;
>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L);
>>>> bb.order(ByteOrder.nativeOrder());
>>>> this.lb = bb.asLongBuffer();
>>>> }
>>>> ---------
>>>>
>>>> sun.misc.Perf:
>>>> ---------
>>>> public native ByteBuffer createLong(String name, int variability,
>>>> int units, long value);
>>>> ---------
>>>>
>>>> "type" in constructor of PerfCounter means "variability".
>>>> So "type" should be set to 2nd argument in perf.createLong()
>>>>
>>>> perf.createLong() should be called as following:
>>>> ---------
>>>> ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
>>>> ---------
>>>>
>>>>
>>>> I've applied a patch which is attached in this email, it's works fine.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>
>



From martinrb at google.com  Thu Apr 18 21:02:43 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Apr 2013 14:02:43 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <51702EBE.3060605@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com> <516F4A4A.4040906@Oracle.com>
	<51702EBE.3060605@oracle.com>
Message-ID: 

On Thu, Apr 18, 2013 at 10:34 AM, Jim Gish  wrote:

> That was a nice idea, but you don't want to change the value when you do
> toString().  Otherwise, if you subsequently add a new element, you're hosed
> because you've already added on the suffix.
>
>
You can cheaply save the current length, append the suffix, call toString,
and reset the length back to the old value to avoid the overhead of String
"+".


From martinrb at google.com  Thu Apr 18 21:03:49 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Apr 2013 14:03:49 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <51702F55.5050702@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de> <51702F55.5050702@oracle.com>
Message-ID: 

Garbled javadoc:

  41  * method will, by default, return {@code prefix+{@code suffix}}.
 However, if


From mike.duigou at oracle.com  Thu Apr 18 21:27:23 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 14:27:23 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <517033CB.8070300@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
	<517014D3.4030503@oracle.com>
	<8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>
	<517033CB.8070300@oracle.com>
Message-ID: <4CA998A4-79CA-44A1-B752-158E0AE43573@oracle.com>


On Apr 18 2013, at 10:56 , roger riggs wrote:

> Hi Mike,
> 
> Another wrinkle...
> 
> The "a" tag allows the tag to be used in any context package, method, constructor, package,
> field and type and overview.  However, the predefined javadoc structure makes it
> unsuitable for use in the package and overview.
> 
> Since javadoc groups the tags inside an indented 
        ... blocks it
> looks quite odd.  For an example see,
> http://cr.openjdk.java.net/~rriggs/javadoc-implspec-213/java/time/package-summary.html
> 
> Scan down to the "Implementation Requirements" header.
> Since there is no 'end' to the @implSpec the rest of the input is indented.
> 
> I would not recommend use of any of these in the overview or package contexts.

Alternatively we could submit an RFE to improve javadoc styling for simple tags in overview and package contexts. I know it generates different output for different contexts already.

> 
> Roger
> 
> 
> On 4/18/2013 12:49 PM, Mike Duigou wrote:
>> On Apr 18 2013, at 08:44 , roger riggs wrote:
>> 
>>> Hi Mike,
>>> 
>>> On 4/18/2013 11:01 AM, Mike Duigou wrote:
>>>>> Note that Oracle accessibility guidelines for html indicate that headers
>>>>> should use header tags   to be properly navigable by accessibility tools.
>>>> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.
>>> ok, I see that javadoc defines the tag to be wrapped in  xxx.
>>> 
>>> I don't see that the additional emphasis is needed relative to the other
>>> style elements of the javadoc.
>> I *had* thought I was copying the JLS tag but see now that that's not the case. I no longer remember where the  came from.
>> 
>>> I would remove the  explicit markup or if possible delegate
>>> to the stylesheet with a .
>> I will remove it and allow the default formatting to be used.
>> 
>>> Roger
>>> 
>>>> Mike
>>>> 
>>>>> Thanks, Roger
>>>>> 
>>>>> 
>>>>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>>>>> Hello All;
>>>>>> 
>>>>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>>>> 
>>>>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>>>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>>>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>>>> 
>>>>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>>>> 
>>>>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>>>> 
>>>>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
> 



From jim.gish at oracle.com  Thu Apr 18 22:21:14 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 18 Apr 2013 18:21:14 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de> <51702F55.5050702@oracle.com>
	
Message-ID: <517071DA.3050506@oracle.com>

Thanks for catching that.  I thought I fixed it.  (In fact, I'm sure I 
did in the latest rev).

On 04/18/2013 05:03 PM, Martin Buchholz wrote:
> Garbled javadoc:
>
>   41  * method will, by default, return {@code prefix+{@code suffix}}. 
>  However, if
>
>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Thu Apr 18 22:29:11 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Apr 2013 15:29:11 -0700
Subject: RFR: 8012005: LogManager needs test to ensure stack trace is
	not being done to find bundle
In-Reply-To: <51705450.8090606@oracle.com>
References: <51705450.8090606@oracle.com>
Message-ID: <517073B7.5000801@oracle.com>

Looks good.  I'll sponsor it.

Mandy

On 4/18/2013 1:15 PM, Jim Gish wrote:
> Please review 
> http://cr.openjdk.java.net/~jgish/Bug8012005-BundleSearchTest/
>
> This is a new test for LogManager to ensure that the changes made for 
> 8002070 (removing the stack search when finding a resource bundle), 
> are working properly.
>
> Thanks,
>     Jim
>



From huizhe.wang at oracle.com  Thu Apr 18 22:32:46 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 18 Apr 2013 15:32:46 -0700
Subject: system reserved property names
In-Reply-To: <516FB946.1040500@oracle.com>
References: <516F9276.1010105@oracle.com> <516FB946.1040500@oracle.com>
Message-ID: <5170748E.3040201@oracle.com>


On 4/18/2013 2:13 AM, Alan Bateman wrote:
> On 18/04/2013 07:28, huizhe wang wrote:
>> System.getProperties [1] returns all of the "current" system 
>> properties. Is there a way to get a list of the system reserved 
>> properties such as "java.version" and etc.? Would anyone know?
>>
>>
>> [1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29 
>>
> I'm not 100% sure what you mean by "reserved" but I will guess that 
> you asking if there is a complete list of the system properties 
> defined by the Java SE APIs and perhaps the list of JDK-specific 
> system properties too. Off-hand, I'm not aware of a master list, they 
> are instead "buried" in the API specs. Is the context the system 
> properties that JAXP 1.5 is proposing to define?

Yes, those defined by the Java SE APIs or the JDK-specific system 
properties. Not related to JAXP 1.5, I'm just asking a general question 
to find out if there's an API to get the 'master' list.

-Joe


> -Alan



From Ulf.Zibis at CoSoCo.de  Thu Apr 18 22:48:25 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Fri, 19 Apr 2013 00:48:25 +0200
Subject: RFR: 8004518 & 8010122 : Default methods on Map
In-Reply-To: <5165AE71.8040909@univ-mlv.fr>
References: <0EDBB8F6-E151-45D4-B6A0-DC94765021D8@oracle.com>
	<5165271D.6040904@CoSoCo.de> <51654DDD.5020804@oracle.com>
	<51659F2E.8060905@CoSoCo.de> <5165AE71.8040909@univ-mlv.fr>
Message-ID: <51707839.8040003@CoSoCo.de>

Am 10.04.2013 20:24, schrieb Remi Forax:
> interface + default methods are conceptually what is known as traits(*),
> you can see them as interface + method with code or as abstract class without state,
> it's the same thing.
>
> Now, if you want traits in Java, you have 3 choices: add a new kind of type, trait,
> introduce a stateless abstract class or add default methods to interface.
> All these changes require to change the VM, so all of them are *big* changes.
> The lambda expert group studies each solution and adding default methods
> to interface is the path that creates less problems, that why it was chosen.

I like to mention another thought.
When I look at the result, we now have interfaces with normal methods and default methods and to the 
unprepared reader it seems as there is no logical rationale for which method which type was chosen. 
The only justification is the history about extending legacy interfaces.

Thanks,

-Ulf



From Ulf.Zibis at CoSoCo.de  Thu Apr 18 23:38:40 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Fri, 19 Apr 2013 01:38:40 +0200
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <51702F55.5050702@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de> <51702F55.5050702@oracle.com>
Message-ID: <51708400.4040603@CoSoCo.de>

Am 18.04.2013 19:37, schrieb Jim Gish:
>
> On 04/18/2013 08:49 AM, Ulf Zibis wrote:
>> Hi,
>>
>> I'm wondering, that StringJoiner has some logic for pre/suffix, but nothing to loop the elements 
>> themselves :-(
>>
>> To me, StringJoiner is a useless complicated box around StringBuilder, and imagine, someone needs 
>> thread-safety.
>> It also slows down performance, as it needs additional instances and additional class to be 
>> loaded (critical at VM startup).
>>
>> Instead please add to StringBuilder and StringBuffer:
>>      append(CharSequence... elements);
>>      append(char delimiter, CharSequence... elements);
>> append(char delimiter, Iterable elements);
>> cut(int len);    // removes len chars at the end of the sequence
>> optional:
>> append(CharSequence delimiter, CharSequence... elements);
>> append(CharSequence delimiter, Iterable elements);
> I started off with something similar, but it was stripped out when Henry did the performance 
> improvements.

Hm, I have no idea, how above suggestions should prevent performance improvements. Can you help me?

> Given that most people feel that this is going to be put to heavy-weight usage, it doesn't seem to 
> merit too much emphasis on performance or complicating the implementation at this point.

Your implementation has
1 class with 7 methods
2 additional methods in String
To cover the same functionality, above approach basically only needs 2 additional methods in 
StringBuilder, has better performance, so what is complicated on that?

@Martin: What is your opinion?

Thanks,

-Ulf


>> For performance reasons, append should always append the trailing delimeter, which could be cut 
>> at the end.
>>
>> It's questionable, if class string needs a static (=no relation to an existing string in contrast 
>> to non-static split()) join method, as it seduces to
>>         "[" + String.join(...) + "]"
>> which needs some effort from javac side to optimize to a single StringBuilder task.
>> IMO we better had StringBuilder.join(...), so javac could easily optimize to:
>>     new StringBuilder().append('[').append(',', someStrings).cut(1).append(']').toString()
>>
>> -Ulf
>>
>>
>> Am 18.04.2013 00:07, schrieb Martin Buchholz:
>>> I'm still wondering about whether a joiner utility should support a prefix
>>> and suffix.  The obvious uses for this are collection class toString
>>> methods, but we already know that we can and should implement those with a
>>> single precise char[] construction, so should not use StringJoiner, or at
>>> least not this StringJoiner implementation.  And if we're just talking
>>> about pure convenience, it's hard to beat
>>>
>>> "[" + String.join(...) + "]"
>>>
>>>
>>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:
>>>
>>>> Here's an update: http://cr.openjdk.java.net/~**
>>>> jgish/Bugs-5015163-7172553/<
>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/ 
>>>>
>>>> Jim



From jonathan.gibbons at oracle.com  Fri Apr 19 00:17:37 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 19 Apr 2013 00:17:37 +0000
Subject: hg: jdk8/tl/langtools: 8008174: DocTree API should provide start and
	end positions for tree nodes
Message-ID: <20130419001740.C518248437@hg.openjdk.java.net>

Changeset: ed918a442b83
Author:    jlahoda
Date:      2013-04-17 15:54 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ed918a442b83

8008174: DocTree API should provide start and end positions for tree nodes
Summary: Adding DocSourcePositions to allow access to DocTree starting/ending position
Reviewed-by: jjg, darcy
Contributed-by: Ralph Benjamin Ruijs , Jan Lahoda 

+ src/share/classes/com/sun/source/util/DocSourcePositions.java
! src/share/classes/com/sun/source/util/DocTrees.java
! src/share/classes/com/sun/source/util/SourcePositions.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/share/classes/com/sun/tools/javac/tree/DCTree.java
+ test/tools/javac/doctree/positions/TestPosition.java
+ test/tools/javac/doctree/positions/TestPosition.out
+ test/tools/javac/doctree/positions/TestPositionSource.java



From mandy.chung at oracle.com  Fri Apr 19 00:23:21 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 19 Apr 2013 00:23:21 +0000
Subject: hg: jdk8/tl/jdk: 8012005: LogManager needs test to ensure stack trace
	is not being done to find bundle
Message-ID: <20130419002337.EDDDF48439@hg.openjdk.java.net>

Changeset: 3e4a0fddeb00
Author:    jgish
Date:      2013-04-18 16:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e4a0fddeb00

8012005: LogManager needs test to ensure stack trace is not being done to find bundle
Reviewed-by: mchung

+ test/java/util/logging/bundlesearch/ClassPathTestBundle_en.properties
+ test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java
+ test/java/util/logging/bundlesearch/LoadItUp.java
+ test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java
+ test/java/util/logging/bundlesearch/resources/ContextClassLoaderTestBundle_en.properties
+ test/java/util/logging/bundlesearch/resources/StackSearchableResource_en.properties



From brian.goetz at oracle.com  Fri Apr 19 00:40:05 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 18 Apr 2013 20:40:05 -0400
Subject: RFR: JDK-8011920 (Main implementation classes for java.util.stream)
Message-ID: <51709265.5090806@oracle.com>

This is a review request for the bulk of the java.util.stream 
implementation; webrev at:

   http://cr.openjdk.java.net/~briangoetz/JDK-8011920/webrev/

You might ask: with 15,000 lines of new code, why are there no tests?

The simple answer is: we've got plenty of 'em, but they can't be put 
back until all the source goes back.  So until then, I'll just show you 
the coverage report for java.util.stream:

   http://cr.openjdk.java.net/~briangoetz/JDK-8011920/Coverage.pdf

So...we have tests.  We'll put them back soon.



From mike.duigou at oracle.com  Fri Apr 19 01:22:04 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 18:22:04 -0700
Subject: RFR : 8008670 : Initial java.util.stream putback -- internal API
	classes
Message-ID: <34725FFA-BB1B-4FAE-B9D6-BB242FD3FB1C@oracle.com>

Hello all;

This is a final review for a set of internal implementation classes in the lambda streams libraries. They have no public API. Brian originally put these out for review about a month ago and nobody immediately stepped up to look at them. Since that time David Holmes and myself as well as Paul Sandoz have taken a good look at them and Brian has done a lot of work improving the documentation.

http://cr.openjdk.java.net/~mduigou/JDK-8008670/0/webrev/

This will be the next chunk of lambda streams to be pushed to TL. Speak now...

Thanks

Mike

From jonathan.gibbons at oracle.com  Fri Apr 19 01:23:07 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 18 Apr 2013 18:23:07 -0700
Subject: RFR: JDK-8011920 (Main implementation classes for
	java.util.stream)
In-Reply-To: <51709265.5090806@oracle.com>
References: <51709265.5090806@oracle.com>
Message-ID: <51709C7B.8040108@oracle.com>

Brian,

Are you asking for people to review the code, just to get some warm 
fuzzy feedback,
or are you asking for a formal review of the code with the direct goal 
of pushing 15K
LOC into jdk8/tl with no corresponding tests.

If you are looking to push bits soon, why can't you wait until you have 
everything ready?

-- Jon



On 04/18/2013 05:40 PM, Brian Goetz wrote:
> This is a review request for the bulk of the java.util.stream
> implementation; webrev at:
>
>     http://cr.openjdk.java.net/~briangoetz/JDK-8011920/webrev/
>
> You might ask: with 15,000 lines of new code, why are there no tests?
>
> The simple answer is: we've got plenty of 'em, but they can't be put
> back until all the source goes back.  So until then, I'll just show you
> the coverage report for java.util.stream:
>
>     http://cr.openjdk.java.net/~briangoetz/JDK-8011920/Coverage.pdf
>
> So...we have tests.  We'll put them back soon.
>
>



From david.holmes at oracle.com  Fri Apr 19 02:44:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 12:44:30 +1000
Subject: system reserved property names
In-Reply-To: <5170748E.3040201@oracle.com>
References: <516F9276.1010105@oracle.com> <516FB946.1040500@oracle.com>
	<5170748E.3040201@oracle.com>
Message-ID: <5170AF8E.6020501@oracle.com>

On 19/04/2013 8:32 AM, huizhe wang wrote:
>
> On 4/18/2013 2:13 AM, Alan Bateman wrote:
>> On 18/04/2013 07:28, huizhe wang wrote:
>>> System.getProperties [1] returns all of the "current" system
>>> properties. Is there a way to get a list of the system reserved
>>> properties such as "java.version" and etc.? Would anyone know?
>>>
>>>
>>> [1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29
>>>
>> I'm not 100% sure what you mean by "reserved" but I will guess that
>> you asking if there is a complete list of the system properties
>> defined by the Java SE APIs and perhaps the list of JDK-specific
>> system properties too. Off-hand, I'm not aware of a master list, they
>> are instead "buried" in the API specs. Is the context the system
>> properties that JAXP 1.5 is proposing to define?
>
> Yes, those defined by the Java SE APIs or the JDK-specific system
> properties. Not related to JAXP 1.5, I'm just asking a general question
> to find out if there's an API to get the 'master' list.

As with Alan I don't know what you mean by "reserved". The documentation 
you link to above tells you what properties must exist. But an 
implementation can add other properties. I don't know if there is any 
rule that says they can't add properties in the java.* namespace.

David

> -Joe
>
>
>> -Alan
>


From jonathan.gibbons at oracle.com  Fri Apr 19 02:59:51 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 19 Apr 2013 02:59:51 +0000
Subject: hg: jdk8/tl/langtools: 8012658: Change default langtools source level
	to 7
Message-ID: <20130419025954.1366C4843F@hg.openjdk.java.net>

Changeset: 891b88acf47a
Author:    jjg
Date:      2013-04-18 19:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/891b88acf47a

8012658: Change default langtools source level to 7
Reviewed-by: darcy

! make/netbeans/langtools/nbproject/project.xml



From jonathan.gibbons at oracle.com  Fri Apr 19 03:01:06 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 19 Apr 2013 03:01:06 +0000
Subject: hg: jdk8/tl/langtools: 8012656: cache frequently used name strings
	for DocImpl classes
Message-ID: <20130419030109.2330C48440@hg.openjdk.java.net>

Changeset: 95d29b99e5b3
Author:    jjg
Date:      2013-04-18 20:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/95d29b99e5b3

8012656: cache frequently used name strings for DocImpl classes
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java



From david.holmes at oracle.com  Fri Apr 19 04:06:39 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 14:06:39 +1000
Subject: How to deal with a missing VM? (was Re: RFR 8010280: jvm.cfg
	needs updating for non-server builds)
In-Reply-To: <516E08A4.6090000@oracle.com>
References: <516B474B.8090404@oracle.com>
	
	<516C826C.4020709@oracle.com> <516E08A4.6090000@oracle.com>
Message-ID: <5170C2CF.6070602@oracle.com>

Okay no opinions. CCC request will go with aliasing for historical 
compatibility.

David

On 17/04/2013 12:27 PM, David Holmes wrote:
> This change to the jvm.cfg file needs to be put through our internal CCC
> process for approval. Given that, and that this is mostly about policy
> (not mechanism) and there is no absolute right answer just a
> not-unreasonable default, I thought I would solicit opinions on this.
>
> what should be the behaviour if you ask for a VM that could be, but
> isn't present? Options:
>
> a) Missing from jvm.cfg so VM error:
>
> Unrecognized option: -client
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
>
> b) ERROR in jvm.cfg
>
> Error: client VM not supported
>
> c) WARN in jvm.cfg
>
> Warning: client VM not supported;  VM will be used
>
> d) ALIAS to default (which is in effect a silent warning but with
> control over which VM to use)
>
> e) IGNORE (which seems to be a degenerate case of ALIAS as it just uses
> the default)
>
> Note that this has no affect on the Oracle JDK (SE or Embedded) as the
> committed jvm.cfg (possibly with '-minimal KNOWN' added) will be used.
> This is primarily about developer builds.
>
> Thanks,
> David
>
>
> On 16/04/2013 8:42 AM, David Holmes wrote:
>> FYI updated webrev at same location, removing the dead code Erik spotted.
>>
>> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>>
>> On 16/04/2013 2:25 AM, Mike Duigou wrote:
>>> Hi David;
>>>
>>> I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped
>>> to see the "classic" and "green" flags go away and some of the other
>>> legacy flags like "-hotspot" reduced to WARN. What's the difference
>>> between removing an entry completely and retaining it with "ERROR"?
>>
>> Just the nature of the error message:
>>
>>  > java -green
>> Error: green VM not supported
>>  > java -blue
>> Unrecognized option: -blue
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>>
>> I wasn't touching any of the legacy stuff - though if this needs to go
>> to CCC I would suggest removing all the legacy entries.
>>
>>> Additionally I don't like that aliases have differing definitions and
>>> some confusing ones like "-server ALIASED_TO -client". Is this
>>> necessary or just historically convenient?
>>
>> I don't like aliases period! Historically (and this is very recent
>> history) it was necessary to deal with the test suites being applied to
>> a JDK with, eg, only client VM. Every test that specified -server would
>> fail if the alias didn't exist (and as I stated we're moving away from
>> that ie the tests don't set -client or -server but the complete test
>> suite run does, and it knows what VM is under test.
>>
>> Personally I'd probably choose WARN for any VM not present.
>>
>> The problem is that the "right" thing depends on who is building what,
>> and how they plan to use it. All I can do is define a not-unreasonable
>> default policy. I also have a time constraint as I need to get this in
>> before the 23rd to meet an internal deadline.
>>
>> I've attached all the generated versions below.
>>
>> Thanks,
>> David
>>
>> ::::::::::::::
>> linux-i586-client/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -client KNOWN
>> -server ALIASED_TO -client
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-client-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but
>> WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License
>> version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-client-server-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but
>> WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License
>> version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> -minimal KNOWN
>> ::::::::::::::
>> linux-i586-minimal1-client/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -client KNOWN
>> -server ALIASED_TO -client
>> -hotspot ALIASED_TO -client
>> -minimal KNOWN
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -minimal KNOWN
>> -server ALIASED_TO -minimal
>> -client ALIASED_TO -minimal
>> -hotspot ALIASED_TO -minimal
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-minimal1-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -server KNOWN
>> -client ALIASED_TO -server
>> -hotspot ALIASED_TO -server
>> -minimal KNOWN
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-server-client-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but
>> WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License
>> version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> -minimal KNOWN
>> ::::::::::::::
>> linux-i586-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -server KNOWN
>> -client ALIASED_TO -server
>> -hotspot ALIASED_TO -server
>> -classic WARN
>> -native ERROR
>> -green ERROR
>>


From mike.duigou at oracle.com  Fri Apr 19 04:26:08 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 21:26:08 -0700
Subject: How to deal with a missing VM? (was Re: RFR 8010280: jvm.cfg
	needs updating for non-server builds)
In-Reply-To: <516E08A4.6090000@oracle.com>
References: <516B474B.8090404@oracle.com>
	
	<516C826C.4020709@oracle.com> <516E08A4.6090000@oracle.com>
Message-ID: <1E7CD685-DFBB-40A2-9CE5-71AE604102E7@oracle.com>

Oops, "B" for anything commonly valid and "a" for everything long obsolete.

Mike

On Apr 16 2013, at 19:27 , David Holmes wrote:

> This change to the jvm.cfg file needs to be put through our internal CCC process for approval. Given that, and that this is mostly about policy (not mechanism) and there is no absolute right answer just a not-unreasonable default, I thought I would solicit opinions on this.
> 
> what should be the behaviour if you ask for a VM that could be, but isn't present? Options:
> 
> a) Missing from jvm.cfg so VM error:
> 
> Unrecognized option: -client
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> b) ERROR in jvm.cfg
> 
> Error: client VM not supported
> 
> c) WARN in jvm.cfg
> 
> Warning: client VM not supported;  VM will be used
> 
> d) ALIAS to default (which is in effect a silent warning but with control over which VM to use)
> 
> e) IGNORE (which seems to be a degenerate case of ALIAS as it just uses the default)
> 
> Note that this has no affect on the Oracle JDK (SE or Embedded) as the committed jvm.cfg (possibly with '-minimal KNOWN' added) will be used. This is primarily about developer builds.
> 
> Thanks,
> David
> 
> 
> On 16/04/2013 8:42 AM, David Holmes wrote:
>> FYI updated webrev at same location, removing the dead code Erik spotted.
>> 
>> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>> 
>> On 16/04/2013 2:25 AM, Mike Duigou wrote:
>>> Hi David;
>>> 
>>> I remember reviewing the jvm.cfg config patch for JDK 7. I had hoped
>>> to see the "classic" and "green" flags go away and some of the other
>>> legacy flags like "-hotspot" reduced to WARN. What's the difference
>>> between removing an entry completely and retaining it with "ERROR"?
>> 
>> Just the nature of the error message:
>> 
>> > java -green
>> Error: green VM not supported
>> > java -blue
>> Unrecognized option: -blue
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> I wasn't touching any of the legacy stuff - though if this needs to go
>> to CCC I would suggest removing all the legacy entries.
>> 
>>> Additionally I don't like that aliases have differing definitions and
>>> some confusing ones like "-server ALIASED_TO -client". Is this
>>> necessary or just historically convenient?
>> 
>> I don't like aliases period! Historically (and this is very recent
>> history) it was necessary to deal with the test suites being applied to
>> a JDK with, eg, only client VM. Every test that specified -server would
>> fail if the alias didn't exist (and as I stated we're moving away from
>> that ie the tests don't set -client or -server but the complete test
>> suite run does, and it knows what VM is under test.
>> 
>> Personally I'd probably choose WARN for any VM not present.
>> 
>> The problem is that the "right" thing depends on who is building what,
>> and how they plan to use it. All I can do is define a not-unreasonable
>> default policy. I also have a time constraint as I need to get this in
>> before the 23rd to meet an internal deadline.
>> 
>> I've attached all the generated versions below.
>> 
>> Thanks,
>> David
>> 
>> ::::::::::::::
>> linux-i586-client/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -client KNOWN
>> -server ALIASED_TO -client
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-client-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-client-server-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> -minimal KNOWN
>> ::::::::::::::
>> linux-i586-minimal1-client/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -client KNOWN
>> -server ALIASED_TO -client
>> -hotspot ALIASED_TO -client
>> -minimal KNOWN
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -minimal KNOWN
>> -server ALIASED_TO -minimal
>> -client ALIASED_TO -minimal
>> -hotspot ALIASED_TO -minimal
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-minimal1-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -server KNOWN
>> -client ALIASED_TO -server
>> -hotspot ALIASED_TO -server
>> -minimal KNOWN
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> ::::::::::::::
>> linux-i586-server-client-minimal1/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> # Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights
>> reserved.
>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> #
>> # This code is free software; you can redistribute it and/or modify it
>> # under the terms of the GNU General Public License version 2 only, as
>> # published by the Free Software Foundation.  Oracle designates this
>> # particular file as subject to the "Classpath" exception as provided
>> # by Oracle in the LICENSE file that accompanied this code.
>> #
>> # This code is distributed in the hope that it will be useful, but WITHOUT
>> # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> # version 2 for more details (a copy is included in the LICENSE file that
>> # accompanied this code).
>> #
>> # You should have received a copy of the GNU General Public License version
>> # 2 along with this work; if not, write to the Free Software Foundation,
>> # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> #
>> # Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> # or visit www.oracle.com if you need additional information or have any
>> # questions.
>> #
>> # List of JVMs that can be used as an option to java, javac, etc.
>> # Order is important -- first in this list is the default JVM.
>> # NOTE that this both this file and its format are UNSUPPORTED and
>> # WILL GO AWAY in a future release.
>> #
>> # You may also select a JVM in an arbitrary location with the
>> # "-XXaltjvm=" option, but that too is unsupported
>> # and may not be available in a future release.
>> #
>> -client IF_SERVER_CLASS -server
>> -server KNOWN
>> -hotspot ALIASED_TO -client
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> -minimal KNOWN
>> ::::::::::::::
>> linux-i586-server/jdk/lib/i386/jvm.cfg
>> ::::::::::::::
>> -server KNOWN
>> -client ALIASED_TO -server
>> -hotspot ALIASED_TO -server
>> -classic WARN
>> -native ERROR
>> -green ERROR
>> 



From mike.duigou at oracle.com  Fri Apr 19 04:52:10 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Apr 2013 21:52:10 -0700
Subject: RFR JDK-8011426: java.util collection Spliterator implementations
In-Reply-To: 
References: 
Message-ID: <441BED95-6164-400F-A6BC-70228F352142@oracle.com>

I reversed this change :

-final Collection c;
-
+        final Collection c;


in Collections.UnmodifiableCollection instead opting or casts in the forEach and spliterator Methods.


- I wonder if it's worth it to have the NONNULL characteristic change in Collections::singletonSpliterator depending on element. 

LinkedHashMap::

- needs an overridden spliterator providing ORDERED for it's entry set. (I can do this tomorrow if needed).

PriorityQueue::

- I am surprised the spliterator is not ORDERED.

Mike

On Apr 10 2013, at 06:50 , Paul Sandoz wrote:

> Hi,
> 
> Following up from JDK-8010096 [1] here is a webrev for spliterator implementations of collection classes in java.util:
> 
>  http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8011426/webrev/
> 
> This is dependent on [1].
> 
> --
> 
> Note that for some reason the webrev script creates the jdk changeset file for my complete hg patch queue and not from the revision i specify. Anyone know how to change that?
> 
> Paul.
> 
> 
> [1] http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8010096/webrev/



From suenaga.yasumasa at lab.ntt.co.jp  Fri Apr 19 05:07:55 2013
From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga)
Date: Fri, 19 Apr 2013 14:07:55 +0900
Subject: Incorrect arguments is passed to sun.misc.Perf#createLong
In-Reply-To: <51705A5C.8060608@oracle.com>
References: <5164007C.5040408@ysfactory.dip.jp> <5165D537.2040403@oracle.com>
	<51661903.2060107@ysfactory.dip.jp>
	<516F1375.5080106@oracle.com> <51705A5C.8060608@oracle.com>
Message-ID: <5170D12B.1060006@lab.ntt.co.jp>

Hi Mandy,

Thank you so much for your cooperation.

> FYI. While looking at the hotspot implementation, I found a bug that creates the long counter of incorrect type (it got V_Variable and V_Monotonic reverse). I have file a hotspot bug and suggested a patch:

I didn't realize it :-)
Please fix it too!


Thanks,

Yasumasa


On 2013/04/19 5:41, Mandy Chung wrote:
> I have pushed the changeset:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b81fac25d26
>
> FYI. While looking at the hotspot implementation, I found a bug that creates the long counter of incorrect type (it got V_Variable and V_Monotonic reverse). I have file a hotspot bug and suggested a patch:
> 8012641: Perf_CreateLong creates perf counter of incorrect type
>
> Mandy
>
> On 4/17/13 2:26 PM, Mandy Chung wrote:
>> Hi Yasumasa,
>>
>> Thanks for the patch. I'm going to sponsor your fix for 8011934 and will be pushing it shortly.
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011934/webrev.00/
>>
>> Mandy
>>
>> On 4/10/2013 6:59 PM, Yasu wrote:
>>> Hi Mandy,
>>>
>>> On 4:59, Mandy Chung wrote:
>>>> Hi Yasumasa,
>>>>
>>>> I'm adding core-libs and bcc serviceability-dev to move this thread to core-libs for sun.misc.PerfCounter discussion.
>>>>
>>>> On 4/9/2013 4:50 AM, Yasu wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to create entry from Java program to hsperfdata through sun.misc.PerfCounter .
>>>>
>>>> First of all, sun.misc.PerfCounter is a private API that is not supported and may be changed and removed in any future release. I'm curious how you create a counter in hsperfdata through sun.misc.PerfCounter. The constructor is private.
>>>
>>> I've understood that sun.* packages is private API.
>>> I use PerfCounter with reflection API ( setAccessible(true) ) .
>>>
>>>
>>>>> However, I cannot watch the updated value in my entry through the jstat with interval option.
>>>>>
>>>>> I guess this cause is that wrong arguments are passed from PerfCounter# to Perf#createLong .
>>>>>
>>>>
>>>> Indeed - it's a bug that calls Perf.createLong with the incorrect parameters. I have filed a bug (8011934).
>>>
>>> Thanks!
>>>
>>>
>>>> Have you signed the OCA [1]?
>>>
>>> Yes.
>>> I already sent OCA with my signature.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>> Thanks
>>>> Mandy
>>>> [1] http://openjdk.java.net/contribute/
>>>>
>>>>> sun.misc.PerfCounter:
>>>>> ---------
>>>>> private PerfCounter(String name, int type) {
>>>>> this.name = name;
>>>>> ByteBuffer bb = perf.createLong(name, U_None, type, 0L);
>>>>> bb.order(ByteOrder.nativeOrder());
>>>>> this.lb = bb.asLongBuffer();
>>>>> }
>>>>> ---------
>>>>>
>>>>> sun.misc.Perf:
>>>>> ---------
>>>>> public native ByteBuffer createLong(String name, int variability,
>>>>> int units, long value);
>>>>> ---------
>>>>>
>>>>> "type" in constructor of PerfCounter means "variability".
>>>>> So "type" should be set to 2nd argument in perf.createLong()
>>>>>
>>>>> perf.createLong() should be called as following:
>>>>> ---------
>>>>> ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
>>>>> ---------
>>>>>
>>>>>
>>>>> I've applied a patch which is attached in this email, it's works fine.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>
>>



From xuelei.fan at oracle.com  Fri Apr 19 05:25:29 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Fri, 19 Apr 2013 05:25:29 +0000
Subject: hg: jdk8/tl/jdk: 8006935: Need to take care of long secret keys in
	HMAC/PRF compuation
Message-ID: <20130419052551.2E60248469@hg.openjdk.java.net>

Changeset: 7bdb3e186497
Author:    xuelei
Date:      2013-04-18 22:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bdb3e186497

8006935: Need to take care of long secret keys in HMAC/PRF compuation
Reviewed-by: valeriep

! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java



From mandy.chung at oracle.com  Fri Apr 19 05:33:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Apr 2013 22:33:28 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <516EAF4A.6040605@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
Message-ID: <5170D728.3060103@oracle.com>

Hi Peter,

On 4/17/13 7:18 AM, Peter Levart wrote:
> As expected, the Proxy.getProxyClass() is yet a little slower than 
> with FlattenedWeakCache, but still much faster than original Proxy 
> implementation. Another lookup in the ConcurrentHashMap and another 
> indirection have a price, but we also get something in return - space.
>
[...]
> So we loose approx. 32 bytes (32bit addresses) or 48 bytes (64 bit 
> addresses) for each proxy class compared to original code when using 
> FlattenedWeakCache, but we gain 8 bytes (32 bit or 64 bit addresses) 
> for each proxy class cached compared to original code when using 
> TwoLevelWeakCache. So which to favour, space or time?
>
> With TwoLevelWeakCache, there is a "step" of 108 bytes (32bit 
> addresses) when new ClassLoader is encoutered (new 2nd level 
> ConcurrentHashMap is allocated and new entry added to 1st level CHM. 
> There's no such "step" in FlattenedWeakCache (modulo the steps when 
> the CHMs are itself resized). So we roughly have 108 bytes wasted for 
> each new ClassLoader encountered with TwoLevelWeakCache vs. 
> FlattenedWeakCache, but we also have 40 bytes spared for each proxy 
> class cached. TwoLevelWeakCache starts to pay off if there are at 
> least 3 proxy classes defined per ClassLoader in average.
>
>

Thanks for the detailed measurement and analysis.  Although the extra 
lookup on the per-loader cache incurs additional overhead on 
Proxy.getProxyClass, it still shows 10x speed on your performance 
measurement result which is very good.

Since the performance improvement is significant on both approaches, the 
memory saving would be the desirable choice.Especially Java SE 8 
profiles [1] can run on small devices and we should be cautious about 
the space and speed tradeoff.I'll support going for per-loader cache 
(i.e. two-level weak cache).

Another point - Proxies are used in the JDK to implement annotations, 
java.beans.EventHandler, JMX MXBeans mapping, JMX MBean proxies, 
Invocable interface by script engines, and RMI/serialization.   JAXWS 
also uses proxies to support @javax.xml.bind.annotation.XmlElement. For 
the case of annotations and JMX, the number of generated proxy classes 
would typically not be a couple that depends on what interfaces 
application define. In EE environment, there will be many class loaders 
running. It'd be better to prepare to work the moderate number, if not 
high, of proxy classes and multiple loaders case.

>
> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html
> What about package-private in java.lang.reflect? It makes Proxy itself 
> much easier to read. When we decide which way to go, I can remove the 
> interface and only leave a single package-private class...
>

thanks.  Moving it to a single package-private classin 
java.lang.reflectand remove the interface sounds good.

I have merged your patch with the recent TL repo and did some clean up 
while reviewing it.  Some comments:
1. getProxyClass0 should validate the input interfaces and throw IAE if 
any illegal argument (e.g. interfaces are not visible to the given 
loader) before calling proxyClassCache.get(loader, interfaces). I moved 
back the validation code from ProxyClassFactory.apply to getProxyClass0.
2. I did some cleanup to restore some original comments to make the 
diffs clearer where the change is.
3. I removed the newInstance method which is dead code after my previous 
code.  Since we are in this code, I took the chance to clean that up and 
also change a couple for-loop to use for-each.

I have put the merged and slightly modified Proxy.java and webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/

We will use this bug for your contribution:
    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load

For the weak cache class, since it's for proxy implementation use, I 
suggest to take out the supportContainsValueOperation flagas it always 
keeps the reverse map for isProxyClass lookup.

You can simply call Objects.requireNonNull(param) instead of 
requireNonNull(param, "param-name") since the proxy implementation 
should have made sure the argument is non-null.

Formatting nits:

   68         Object cacheKey = CacheKey.valueOf(
   69             key,
   70             refQueue
   71         );

should be: all in one line or line break on a long-line.  Same for
method signature.

  237         void expungeFrom(
  238             ConcurrentMap> map,
  239             ConcurrentMap reverseMap
  240         );

should be:

void expungeFrom(ConcurrentMap> map,
                  ConcurrentMap reverseMap);

so that it'll be more consistent with the existing code.  I'll do a
detailed review on the weak cache class as you will finalize the code
per the decision to go with the two-level weak cache.

Thanks again for the good work.

Mandy
[1] http://openjdk.java.net/jeps/161


From peter.levart at gmail.com  Fri Apr 19 07:08:11 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Apr 2013 09:08:11 +0200
Subject: can't build current jdk8/tl tip
Message-ID: <5170ED5B.4000305@gmail.com>

Hi,

I get the following compile-time error:

/home/peter/work/hg/jdk8-tl/langtools/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java:264: 
error: illegal start of expression
         if (qualifiedName == null) }
                                    ^


...isn't this '}' supposed to be '{' ?

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/tools-FileDocImpl/webrev/index.html


Regards, Peter



From Alan.Bateman at oracle.com  Fri Apr 19 07:30:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 08:30:40 +0100
Subject: can't build current jdk8/tl tip
In-Reply-To: <5170ED5B.4000305@gmail.com>
References: <5170ED5B.4000305@gmail.com>
Message-ID: <5170F2A0.9010406@oracle.com>

On 19/04/2013 08:08, Peter Levart wrote:
> Hi,
>
> I get the following compile-time error:
>
> /home/peter/work/hg/jdk8-tl/langtools/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java:264: 
> error: illegal start of expression
>         if (qualifiedName == null) }
I'm seeing the same thing, looks like the typo crept in with this change 
last night:

http://hg.openjdk.java.net/jdk8/tl/langtools/rev/95d29b99e5b3

-Alan


From weijun.wang at oracle.com  Fri Apr 19 07:43:01 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 19 Apr 2013 07:43:01 +0000
Subject: hg: jdk8/tl/jdk: 8009636: JARSigner including TimeStamp PolicyID
	(TSAPolicyID) as defined in RFC3161
Message-ID: <20130419074314.4D2234846F@hg.openjdk.java.net>

Changeset: 778b16225d85
Author:    weijun
Date:      2013-04-19 15:41 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/778b16225d85

8009636: JARSigner including TimeStamp PolicyID (TSAPolicyID) as defined in RFC3161
Reviewed-by: mullan

! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/timestamp/TSRequest.java
! src/share/classes/sun/security/timestamp/TimestampToken.java
! src/share/classes/sun/security/tools/jarsigner/Main.java
! src/share/classes/sun/security/tools/jarsigner/Resources.java
! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/tools/jarsigner/ts.sh



From joel.franck at oracle.com  Fri Apr 19 08:49:16 2013
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 19 Apr 2013 10:49:16 +0200
Subject: RFR 8012681: Commit for JDK-8012656 breaks tl build Was: can't build
	current jdk8/tl tip
In-Reply-To: <5170F2A0.9010406@oracle.com>
References: <5170ED5B.4000305@gmail.com> <5170F2A0.9010406@oracle.com>
Message-ID: <5171050C.2090908@oracle.com>

Hi

On 04/19/2013 09:30 AM, Alan Bateman wrote:> On 19/04/2013 08:08, Peter 
Levart wrote:
 >> Hi,
 >>
 >> I get the following compile-time error:
 >>
 >> 
/home/peter/work/hg/jdk8-tl/langtools/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java:264: 

 >> error: illegal start of expression
 >>         if (qualifiedName == null) }
 > I'm seeing the same thing, looks like the typo crept in with this change
 > last night:
 >
 > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/95d29b99e5b3
 >

See inline patch to fix this. Since TL isn't building I think we can review 
this on core-libs-dev although technically a compiler issue.

With this fix langtools builds and all langtools tests passes.

cheers
/Joel

diff --git a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java 
b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
--- a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
+++ b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
@@ -261,7 +261,7 @@
      private String name;

      public String qualifiedName() {
-        if (qualifiedName == null) }
+        if (qualifiedName == null) {
              qualifiedName = sym.enclClass().getQualifiedName() + "." + name();
          }
          return qualifiedName;


From chris.hegarty at oracle.com  Fri Apr 19 09:01:07 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 19 Apr 2013 10:01:07 +0100
Subject: RFR 8012681: Commit for JDK-8012656 breaks tl build Was: can't
	build current jdk8/tl tip
In-Reply-To: <5171050C.2090908@oracle.com>
References: <5170ED5B.4000305@gmail.com> <5170F2A0.9010406@oracle.com>
	<5171050C.2090908@oracle.com>
Message-ID: <517107D3.4030205@oracle.com>

Looks good to me Joel,

-Chris.

On 19/04/2013 09:49, Joel Borggr?n-Franck wrote:
> Hi
>
> On 04/19/2013 09:30 AM, Alan Bateman wrote:> On 19/04/2013 08:08, Peter
> Levart wrote:
>  >> Hi,
>  >>
>  >> I get the following compile-time error:
>  >>
>  >>
> /home/peter/work/hg/jdk8-tl/langtools/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java:264:
>
>  >> error: illegal start of expression
>  >> if (qualifiedName == null) }
>  > I'm seeing the same thing, looks like the typo crept in with this change
>  > last night:
>  >
>  > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/95d29b99e5b3
>  >
>
> See inline patch to fix this. Since TL isn't building I think we can
> review this on core-libs-dev although technically a compiler issue.
>
> With this fix langtools builds and all langtools tests passes.
>
> cheers
> /Joel
>
> diff --git a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> --- a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> +++ b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> @@ -261,7 +261,7 @@
> private String name;
>
> public String qualifiedName() {
> - if (qualifiedName == null) }
> + if (qualifiedName == null) {
> qualifiedName = sym.enclClass().getQualifiedName() + "." + name();
> }
> return qualifiedName;


From paul.sandoz at oracle.com  Fri Apr 19 09:36:32 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Apr 2013 11:36:32 +0200
Subject: RFR JDK-8011426: java.util collection Spliterator implementations
In-Reply-To: <441BED95-6164-400F-A6BC-70228F352142@oracle.com>
References: 
	<441BED95-6164-400F-A6BC-70228F352142@oracle.com>
Message-ID: <5D4793E7-FADB-4F98-8495-015FC5E409B8@oracle.com>


On Apr 19, 2013, at 6:52 AM, Mike Duigou  wrote:

> I reversed this change :
> 
> -final Collection c;
> -
> +        final Collection c;
> 
> 
> in Collections.UnmodifiableCollection instead opting or casts in the forEach and spliterator Methods.
> 

OK, i prefer the former but i ain't gonna argue this one :-)


> 
> - I wonder if it's worth it to have the NONNULL characteristic change in Collections::singletonSpliterator depending on element. 
> 

My preference is to be accurate if it is cheap to do.


> LinkedHashMap::
> 
> - needs an overridden spliterator providing ORDERED for it's entry set. (I can do this tomorrow if needed).
> 

Right, the key/value/entry collections all have an encounter order. 

Note that one cannot leverage the HashMap spliterator implementations, we need to create a spliterator from the collection (basically delayed use of the collection's iterator), hence the following check in HashMap:

            if (HashMap.this.getClass() == HashMap.class)

Doing something more optimal for LinkedHashMap would require a lot more work.


> PriorityQueue::
> 
> - I am surprised the spliterator is not ORDERED.
> 

Yes, that surprised me at first.  Guarantees on order are only made for the head, plus the order is not stable for two values that tie for the least value.

Paul.

From Alan.Bateman at oracle.com  Fri Apr 19 09:38:48 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 10:38:48 +0100
Subject: RFR 8012681: Commit for JDK-8012656 breaks tl build Was: can't
	build current jdk8/tl tip
In-Reply-To: <5171050C.2090908@oracle.com>
References: <5170ED5B.4000305@gmail.com> <5170F2A0.9010406@oracle.com>
	<5171050C.2090908@oracle.com>
Message-ID: <517110A8.8010102@oracle.com>

On 19/04/2013 09:49, Joel Borggr?n-Franck wrote:
>
> See inline patch to fix this. Since TL isn't building I think we can 
> review this on core-libs-dev although technically a compiler issue.
>
> With this fix langtools builds and all langtools tests passes.
Looks fine, this is what Peter Levart suggested too.

-Alan


From chris.hegarty at oracle.com  Fri Apr 19 09:45:15 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 19 Apr 2013 09:45:15 +0000
Subject: hg: jdk8/tl/jdk: 8010505: HTTP DIGEST implementation incorrectly
	quotes header values, fails auth
Message-ID: <20130419094604.23C3648472@hg.openjdk.java.net>

Changeset: 90b03f9a2e77
Author:    jzavgren
Date:      2013-04-17 11:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90b03f9a2e77

8010505: HTTP DIGEST implementation incorrectly quotes header values, fails auth
Summary: The extraneous quotes were removed.
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java



From joel.franck at oracle.com  Fri Apr 19 09:59:12 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Fri, 19 Apr 2013 09:59:12 +0000
Subject: hg: jdk8/tl/langtools: 8012681: Commit for JDK-8012656 breaks tl build
Message-ID: <20130419095920.7D0CC48473@hg.openjdk.java.net>

Changeset: a3655c24e232
Author:    jfranck
Date:      2013-04-19 11:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3655c24e232

8012681: Commit for JDK-8012656 breaks tl build
Reviewed-by: vromero, chegar, alanb

! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java



From joel.franck at oracle.com  Fri Apr 19 10:08:03 2013
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 19 Apr 2013 12:08:03 +0200
Subject: RFR 8012681: Commit for JDK-8012656 breaks tl build Was: can't
	build current jdk8/tl tip
In-Reply-To: <5171050C.2090908@oracle.com>
References: <5170ED5B.4000305@gmail.com> <5170F2A0.9010406@oracle.com>
	<5171050C.2090908@oracle.com>
Message-ID: <51711783.6020009@oracle.com>

Fix pushed, thanks for the reviews.

Peter, I missed your patch. My fix should probably have been attributed to 
you, sorry!

cheers
/Joel

On 04/19/2013 10:49 AM, Joel Borggr?n-Franck wrote:
> Hi
>
> On 04/19/2013 09:30 AM, Alan Bateman wrote:> On 19/04/2013 08:08, Peter
> Levart wrote:
>  >> Hi,
>  >>
>  >> I get the following compile-time error:
>  >>
>  >>
> /home/peter/work/hg/jdk8-tl/langtools/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java:264:
>
>  >> error: illegal start of expression
>  >>         if (qualifiedName == null) }
>  > I'm seeing the same thing, looks like the typo crept in with this change
>  > last night:
>  >
>  > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/95d29b99e5b3
>  >
>
> See inline patch to fix this. Since TL isn't building I think we can review
> this on core-libs-dev although technically a compiler issue.
>
> With this fix langtools builds and all langtools tests passes.
>
> cheers
> /Joel
>
> diff --git a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> --- a/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> +++ b/src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
> @@ -261,7 +261,7 @@
>       private String name;
>
>       public String qualifiedName() {
> -        if (qualifiedName == null) }
> +        if (qualifiedName == null) {
>               qualifiedName = sym.enclClass().getQualifiedName() + "." +
> name();
>           }
>           return qualifiedName;


From Alan.Bateman at oracle.com  Fri Apr 19 10:40:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 11:40:17 +0100
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FE203.4030405@oracle.com>
	<03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>
Message-ID: <51711F11.1040700@oracle.com>

On 18/04/2013 16:12, Mike Duigou wrote:
> :
>
>> @implSpec is very welcome, more reasons now with the addition of default methods.
>>
>> Clearly distinguishing normative from non-normative text is also been a long standing problem so having a tag to identify the non-normative text is very useful. I had to look at a few examples in the lambda/jdk repo to convince myself that both @apiNote and @implNote are needed. One thing that isn't clear to me is whether the "official" Java SE documentation should include the text tagged @implNote or not.
> Once we got going we decided to fill out the matrix. There's no obligation to use all of the tags.
>
Where @implSpec is used, then do you have a view on whether this should 
be filtered out of the Java SE specs?

-Alan


From Alan.Bateman at oracle.com  Fri Apr 19 11:15:24 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 12:15:24 +0100
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5170404B.9000708@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com>
Message-ID: <5171274C.1080606@oracle.com>

On 18/04/2013 19:49, Akhil Arora wrote:
> Looks like the stars are aligning on getting on this into TL... the
> refreshed webrev is -
>
> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>
A minor comment on Collection.removeIf is "that satisifies the given 
predicate" might be better than "which matches the provided predicate". 
Also for completeness, you could say "RuntimeExceptions and Errors 
thrown by the predicate are propagated ...".

In List.replaceAll then @throws NullPointerException is listed twice, 
which is okay, but might be better to combine them. A typo in the second 
NPE description "if the an element".

In the implementation then the only thing that puzzled me is checking 
the modification count in legacy Vector, that seems unnecessary.

I see Mike has looked through the tests in detail. One additional 
comment is just location and trying to keep it consistent with the 
current organization if possible.

-Alan.


From paul.sandoz at oracle.com  Fri Apr 19 12:14:04 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Apr 2013 14:14:04 +0200
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5171274C.1080606@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
Message-ID: <35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>


On Apr 19, 2013, at 1:15 PM, Alan Bateman  wrote:

> On 18/04/2013 19:49, Akhil Arora wrote:
>> Looks like the stars are aligning on getting on this into TL... the
>> refreshed webrev is -
>> 
>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>> 
> A minor comment on Collection.removeIf is "that satisifies the given predicate" might be better than "which matches the provided predicate". Also for completeness, you could say "RuntimeExceptions and Errors thrown by the predicate are propagated ...".
> 
> In List.replaceAll then @throws NullPointerException is listed twice, which is okay, but might be better to combine them. A typo in the second NPE description "if the an element".
> 
> In the implementation then the only thing that puzzled me is checking the modification count in legacy Vector, that seems unnecessary.
> 

The function value could structurally modify the Vector instance.

Paul.

From david.holmes at oracle.com  Fri Apr 19 12:29:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 22:29:01 +1000
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5170404B.9000708@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com>
Message-ID: <5171388D.40007@oracle.com>

Hi Akhil,

This is only a partial review so far.

I have some issues with the ConcurrentModificationException strategy.

Taking ArrayList, the basic idea is that you want to detect 
modifications that are concurrent with iteration - so the mutators up 
the modCount and the iterator functions check to see if the modCount has 
changed since the iterator was constructed. So you've then treated the 
bulk operations as "iterations" and you check the modCount each time 
through the loop. Problem is the modCount is not volatile so in all 
likelihood the JIT is going to hoist the check of modCount out of the 
loop and it will only be checked once. That's not incorrect as it is 
"best effort" detection, but it might be surprising. (Note if existing 
iterator methods get inlined the same problem can exist today.) Maybe it 
is not worth trying to check this? The reality is that if the ArrayList 
is really being modified concurrently - particularly if the size changes 
- then you will just get exceptions (NPE, AIOOBE etc) not a nice neat CME.

It's late and I may have overlooked ssomething but in Vector all the 
methods are synchronized yet you still check the modCount for changes ?? 
But it is impossible for anyone to change modCount during a bullk 
operation. It is only possible with iteration because a mutating method 
in one thread can execute between the separate iterator hasNext()/next() 
calls in another thread. So all the CME code can be dropped from the new 
bulk methods.

Cheers,
David

On 19/04/2013 4:49 AM, Akhil Arora wrote:
> Looks like the stars are aligning on getting on this into TL... the
> refreshed webrev is -
>
> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>
> Please review
>
> Thanks
>
> On 12/10/2012 09:31 PM, Akhil Arora wrote:
>> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
>>
>> - now with synchronized and unmodifiable wrappers in Collections.java
>> for the default methods being added
>>
>> On 12/10/2012 01:48 PM, Akhil Arora wrote:
>>> Updated with yours and Alan's comments -
>>>
>>> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>>>
>>> - removed null check for removeSet
>>> - cache this.size in removeAll, replaceAll
>>>      (for ArrayList, Vector and CopyOnWriteArrayList)
>>> - calculate removeCount instead of BitCount.cardinality()
>>> - removed unnecessary @library from test support classes
>


From Alan.Bateman at oracle.com  Fri Apr 19 12:29:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 13:29:07 +0100
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
Message-ID: <51713893.9010001@oracle.com>

On 19/04/2013 13:14, Paul Sandoz wrote:
> :
> The function value could structurally modify the Vector instance.
>
Ah yes, got it - thanks.

For removeIf then I assume it isn't required in the pass over the removeSet.

-Alan.


From david.holmes at oracle.com  Fri Apr 19 12:42:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 22:42:15 +1000
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
Message-ID: <51713BA7.2040002@oracle.com>

On 19/04/2013 10:14 PM, Paul Sandoz wrote:
>
> On Apr 19, 2013, at 1:15 PM, Alan Bateman  wrote:
>
>> On 18/04/2013 19:49, Akhil Arora wrote:
>>> Looks like the stars are aligning on getting on this into TL... the
>>> refreshed webrev is -
>>>
>>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>>
>> A minor comment on Collection.removeIf is "that satisifies the given predicate" might be better than "which matches the provided predicate". Also for completeness, you could say "RuntimeExceptions and Errors thrown by the predicate are propagated ...".
>>
>> In List.replaceAll then @throws NullPointerException is listed twice, which is okay, but might be better to combine them. A typo in the second NPE description "if the an element".
>>
>> In the implementation then the only thing that puzzled me is checking the modification count in legacy Vector, that seems unnecessary.
>>
>
> The function value could structurally modify the Vector instance.

So this came through while I was writing my similar comments ...

My reaction to this is simply "well don't do that". If the 
function/predicate/comparator is mutating the Vector then the user gets 
what they deserve in my opinion. Trying to account for that is somewhat 
futile. As per my other email the loop check for 
modCount==expectedModCount will get hoisted from the loop. Further in 
removeIf you need to be a lot more defensive during the first iteration 
as you haven't kept a reference to the original size and array. That 
aside the second part of removeIf (the actual removal) doesn't invoke 
any external code so no concurrent modification is possible then.

This seems like overkill to me.

Cheers,
David

> Paul.
>


From paul.sandoz at oracle.com  Fri Apr 19 12:54:46 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Apr 2013 14:54:46 +0200
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5171388D.40007@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171388D.40007@oracle.com>
Message-ID: <650EBF12-83B6-49DE-AFEC-DE8F3BCD0A6B@oracle.com>


On Apr 19, 2013, at 2:29 PM, David Holmes  wrote:

> Hi Akhil,
> 
> This is only a partial review so far.
> 
> I have some issues with the ConcurrentModificationException strategy.
> 
> Taking ArrayList, the basic idea is that you want to detect 
> modifications that are concurrent with iteration - so the mutators up 
> the modCount and the iterator functions check to see if the modCount has 
> changed since the iterator was constructed. So you've then treated the 
> bulk operations as "iterations" and you check the modCount each time 
> through the loop. Problem is the modCount is not volatile so in all 
> likelihood the JIT is going to hoist the check of modCount out of the 
> loop and it will only be checked once. That's not incorrect as it is 
> "best effort" detection, but it might be surprising. (Note if existing 
> iterator methods get inlined the same problem can exist today.) Maybe it 
> is not worth trying to check this? The reality is that if the ArrayList 
> is really being modified concurrently - particularly if the size changes 
> - then you will just get exceptions (NPE, AIOOBE etc) not a nice neat CME.
> 
> It's late and I may have overlooked ssomething but in Vector all the 
> methods are synchronized yet you still check the modCount for changes ?? 
> But it is impossible for anyone to change modCount during a bullk 
> operation. It is only possible with iteration because a mutating method 
> in one thread can execute between the separate iterator hasNext()/next() 
> calls in another thread. So all the CME code can be dropped from the new 
> bulk methods.
> 

  Vector v = new Vector<>(Arrays.asList(1, 2, 3));

  // Any of the following will throw a CME
  v.forEach(e -> v.add(e));
  v.iterator().forEachRemaining(e -> v.add(e));
  v.spliterator().forEachRemaining(e -> v.add(e));

Paul.


From peter.levart at gmail.com  Fri Apr 19 14:36:23 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Apr 2013 16:36:23 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5170D728.3060103@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com>
Message-ID: <51715667.3010103@gmail.com>

Hi Mandy,

On 04/19/2013 07:33 AM, Mandy Chung wrote:
>>
>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html 
>>
>> What about package-private in java.lang.reflect? It makes Proxy 
>> itself much easier to read. When we decide which way to go, I can 
>> remove the interface and only leave a single package-private class...
>>
>
> thanks.  Moving it to a single package-private classin 
> java.lang.reflectand remove the interface sounds good.

Right.

>
> I have merged your patch with the recent TL repo and did some clean up 
> while reviewing it.  Some comments:
> 1. getProxyClass0 should validate the input interfaces and throw IAE 
> if any illegal argument (e.g. interfaces are not visible to the given 
> loader) before calling proxyClassCache.get(loader, interfaces). I 
> moved back the validation code from ProxyClassFactory.apply to 
> getProxyClass0.

Ops, you're right. There could be a request with interface(s) with same 
name(s) but loaded by different loader(s) and such code could return 
wrong pre-cached proxy class instead of throwing exception. 
Unfortunately, moving validation to slow-path was the cause of major 
performance and scalability improvement observed. With validation moved 
back to getProxyClass0 (in spite of using two-level WeakCache), we have 
the following performance (WeakCache#1):


Summary (4 Cores x 2 Threads i7 CPU):

Test                     Threads  ns/op Original WeakCache#1
=======================  =======  ============== ===========
Proxy_getProxyClass            1        2,403.27 2,174.51
                                4        3,039.01 2,555.00
                                8        5,193.58 4,273.42

Proxy_isProxyClassTrue         1           95.02 43.14
                                4        2,266.29 43.23
                                8        4,782.29 72.06

Proxy_isProxyClassFalse        1           95.02 1.36
                                4        2,186.59 1.36
                                8        4,891.15 2.72

Annotation_equals              1          240.10 195.68
                                4        1,864.06 201.41
                                8        8,639.20 337.46

It's a little better than original getProxyClass(), but not much. The 
isProxyClass() and consequently Annotation.equals() are far better 
though. But as you might have guessed, I kind of solved that too...

My first attempt was to optimize the interface validation. Only the 
"visibility" part is necessary to be performed on fast-path. Uniqueness 
and other things can be performed on slow-path. With split-validation 
and hacks like:

     private static final MethodHandle findLoadedClass0MH, 
findBootstrapClassMH;
     private static final ClassLoader dummyCL = new ClassLoader() {};

     static {
         try {
             Method method = 
ClassLoader.class.getDeclaredMethod("findLoadedClass0", String.class);
             method.setAccessible(true);
             findLoadedClass0MH = MethodHandles.lookup().unreflect(method);

             method = 
ClassLoader.class.getDeclaredMethod("findBootstrapClass", String.class);
             method.setAccessible(true);
             findBootstrapClassMH = 
MethodHandles.lookup().unreflect(method);
         } catch (NoSuchMethodException e) {
             throw (Error) new 
NoSuchMethodError(e.getMessage()).initCause(e);
         } catch (IllegalAccessException e) {
             throw (Error) new 
IllegalAccessError(e.getMessage()).initCause(e);
         }
     }

     static Class findLoadedClass(ClassLoader loader, String name) {
         try {
             if (VM.isSystemDomainLoader(loader)) {
                 return (Class) 
findBootstrapClassMH.invokeExact(dummyCL, name);
             } else {
                 return (Class) 
findLoadedClass0MH.invokeExact(loader, name);
             }
         } catch (RuntimeException | Error e) {
             throw e;
         } catch (Throwable t) {
             throw new UndeclaredThrowableException(t);
         }
     }


... using findLoadedClass(loader, intf.getName()) and only doing 
Class.forName(intf.getName(), false, loader) if the former returned null 
... I managed to reclaim some performance (WeakCache#1+):


Test                     Threads  ns/op Original  WeakCache#1 WeakCache#1+
=======================  =======  ============== ===========  ============
Proxy_getProxyClass            1        2,403.27 2,174.51      1,589.36
                                4        3,039.01 2,555.00      1,929.11
                                8        5,193.58 4,273.42      3,409.77


...but that was still not very satisfactory.

I modified the KeyFactory to create keys that weakly-reference interface 
Class objects and implement hashCode/equals in terms of comparing those 
Class objects. With such keys, no false aliasing can occur and the whole 
validation can be pushed back to slow-path. I tried hard to create keys 
with as little space overhead as possible:

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html

...but there can be no miracles. The good news is that the performance 
is back (WeakCache#2):


Summary (4 Cores x 2 Threads i7 CPU):

Test                     Threads  ns/op Original WeakCache#1  WeakCache#2
=======================  =======  ============== ===========  ===========
Proxy_getProxyClass            1        2,403.27 2,174.51       163.57
                                4        3,039.01 2,555.00       211.70
                                8        5,193.58 4,273.42       322.14

Proxy_isProxyClassTrue         1           95.02 43.14        41.23
                                4        2,266.29 43.23        42.20
                                8        4,782.29 72.06        72.21

Proxy_isProxyClassFalse        1           95.02 1.36         1.36
                                4        2,186.59 1.36         1.36
                                8        4,891.15 2.72         2.72

Annotation_equals              1          240.10 195.68       194.61
                                4        1,864.06 201.41       198.81
                                8        8,639.20 337.46       342.90


... and the most common usage (proxy class implementing exactly one 
interface) uses even less space than with interface-names-key - 16 bytes 
saved per proxy class vs. 8 bytes saved (32 bit addressing mode):

--------------------------------------
       Original j.l.r.Proxy
       1 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       768       368
        1         2       920       152
        1         3      1072       152
        1         4      1224       152
        1         5      1376       152
        1         6      1528       152
        1         7      1680       152
        1         8      1832       152
        2         9      2152       320
        2        10      2304       152
        2        11      2456       152
        2        12      2672       216
        2        13      2824       152
        2        14      2976       152
        2        15      3128       152
        2        16      3280       152

--------------------------------------
       Patched j.l.r.Proxy
       1 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       792       552
        1         2       928       136
        1         3      1064       136
        1         4      1200       136
        1         5      1336       136
        1         6      1472       136
        1         7      1608       136
        1         8      1744       136
        2         9      2088       344
        2        10      2224       136
        2        11      2360       136
        2        12      2560       200
        2        13      2696       136
        2        14      2832       136
        2        15      2968       136
        2        16      3104       136


Did you know, that Proxy.getProxyClass() can generate proxy classes 
implementing 0 interfaces? It can. There's exactly one such class 
generated per class loader:


--------------------------------------
       Original j.l.r.Proxy
       0 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       760       360
        2         2      1072       312

--------------------------------------
       Patched j.l.r.Proxy
       0 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       728       488
        2         2      1040       312


With 2 or more interfaces implemented by proxy class the space overhead 
increases faster than with original Proxy:


--------------------------------------
       Original j.l.r.Proxy
       2 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       768       368
        1         2       920       152
        1         3      1072       152
        1         4      1224       152
        1         5      1376       152
        1         6      1528       152
        1         7      1680       152
        1         8      1832       152
        2         9      2152       320
        2        10      2304       152
        2        11      2456       152
        2        12      2672       216
        2        13      2824       152
        2        14      2976       152
        2        15      3128       152
        2        16      3280       152

--------------------------------------
       Patched j.l.r.Proxy
       2 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       832       592
        1         2      1008       176
        1         3      1184       176
        1         4      1360       176
        1         5      1536       176
        1         6      1712       176
        1         7      1888       176
        1         8      2064       176
        2         9      2448       384
        2        10      2624       176
        2        11      2800       176
        2        12      3040       240
        2        13      3216       176
        2        14      3392       176
        2        15      3568       176
        2        16      3744       176

--------------------------------------
       Original j.l.r.Proxy
       3 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       776       376
        1         2       936       160
        1         3      1096       160
        1         4      1256       160
        1         5      1416       160
        1         6      1576       160
        1         7      1736       160
        1         8      1896       160
        2         9      2224       328
        2        10      2384       160
        2        11      2544       160
        2        12      2768       224
        2        13      2928       160
        2        14      3088       160
        2        15      3248       160
        2        16      3408       160

--------------------------------------
       Patched j.l.r.Proxy
       3 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       864       624
        1         2      1072       208
        1         3      1280       208
        1         4      1488       208
        1         5      1696       208
        1         6      1904       208
        1         7      2112       208
        1         8      2320       208
        2         9      2736       416
        2        10      2944       208
        2        11      3152       208
        2        12      3424       272
        2        13      3632       208
        2        14      3840       208
        2        15      4048       208
        2        16      4256       208

--------------------------------------
       Original j.l.r.Proxy
       4 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       776       376
        1         2       936       160
        1         3      1096       160
        1         4      1256       160
        1         5      1416       160
        1         6      1576       160
        1         7      1736       160
        1         8      1896       160
        2         9      2224       328
        2        10      2384       160
        2        11      2544       160
        2        12      2768       224
        2        13      2928       160
        2        14      3088       160
        2        15      3248       160
        2        16      3408       160

--------------------------------------
       Patched j.l.r.Proxy
       4 interfaces / proxy class

class     proxy     size of   delta to
loaders   classes   caches    prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       896       656
        1         2      1136       240
        1         3      1376       240
        1         4      1616       240
        1         5      1856       240
        1         6      2096       240
        1         7      2336       240
        1         8      2576       240
        2         9      3024       448
        2        10      3264       240
        2        11      3504       240
        2        12      3808       304
        2        13      4048       240
        2        14      4288       240
        2        15      4528       240
        2        16      4768       240


There's an increase of 8 bytes per proxy class key for each 2 interfaces 
added to proxy class in original Proxy code, but there's an increase of 
32 bytes per proxy class key for each single interface added in patched 
Proxy code.

I think the most common usage is to implement a single interface and 
there is 16 bytes gained for each such usage compared to original Proxy 
code.

> 2. I did some cleanup to restore some original comments to make the 
> diffs clearer where the change is.
> 3. I removed the newInstance method which is dead code after my 
> previous code.  Since we are in this code, I took the chance to clean 
> that up and also change a couple for-loop to use for-each.
>
> I have put the merged and slightly modified Proxy.java and webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/
>
> We will use this bug for your contribution:
>    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load

I took j.l.r.Proxy file from your webrev and just changed the KeyFactory 
implementation. WeakCache is generic and can be used unchanged with 
either implementation of KeyFactory.

>
> For the weak cache class, since it's for proxy implementation use, I 
> suggest to take out the supportContainsValueOperation flagas it always 
> keeps the reverse map for isProxyClass lookup.
>
> You can simply call Objects.requireNonNull(param) instead of 
> requireNonNull(param, "param-name") since the proxy implementation 
> should have made sure the argument is non-null.
>
> Formatting nits:
>
>   68         Object cacheKey = CacheKey.valueOf(
>   69             key,
>   70             refQueue
>   71         );
>
> should be: all in one line or line break on a long-line.  Same for
> method signature.
>
>  237         void expungeFrom(
>  238             ConcurrentMap> map,
>  239             ConcurrentMap reverseMap
>  240         );
>
> should be:
>
> void expungeFrom(ConcurrentMap> map,
>                  ConcurrentMap reverseMap);
>
> so that it'll be more consistent with the existing code.  I'll do a
> detailed review on the weak cache class as you will finalize the code
> per the decision to go with the two-level weak cache.

I hope I have addressed all that in above webrev.

Regards, Peter

>
> Thanks again for the good work.
>
> Mandy
> [1] http://openjdk.java.net/jeps/161 



From daniel.fuchs at oracle.com  Fri Apr 19 14:57:19 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Fri, 19 Apr 2013 14:57:19 +0000
Subject: hg: jdk8/tl/jaxp: 8005954: JAXP Plugability Layer should use
	java.util.ServiceLoader
Message-ID: <20130419145721.80F514847A@hg.openjdk.java.net>

Changeset: fad6560cb32a
Author:    dfuchs
Date:      2013-04-17 15:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fad6560cb32a

8005954: JAXP Plugability Layer should use java.util.ServiceLoader
Summary: This fix replaces manual processing of files under META-INF/services in JAXP factories by calls to java.util.ServiceLoader.
Reviewed-by: alanb, joehw, mchung

! src/javax/xml/datatype/DatatypeFactory.java
! src/javax/xml/datatype/FactoryFinder.java
! src/javax/xml/parsers/DocumentBuilderFactory.java
! src/javax/xml/parsers/FactoryFinder.java
! src/javax/xml/parsers/SAXParserFactory.java
! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/stream/XMLEventFactory.java
! src/javax/xml/stream/XMLInputFactory.java
! src/javax/xml/stream/XMLOutputFactory.java
! src/javax/xml/transform/FactoryFinder.java
! src/javax/xml/transform/TransformerFactory.java
! src/javax/xml/validation/SchemaFactory.java
+ src/javax/xml/validation/SchemaFactoryConfigurationError.java
! src/javax/xml/validation/SchemaFactoryFinder.java
! src/javax/xml/xpath/XPathFactory.java
! src/javax/xml/xpath/XPathFactoryFinder.java



From paul.sandoz at oracle.com  Fri Apr 19 14:59:24 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Apr 2013 16:59:24 +0200
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <51713BA7.2040002@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
	<51713BA7.2040002@oracle.com>
Message-ID: <0F0E4FD1-4F4E-4116-A663-F509FBC1612F@oracle.com>


On Apr 19, 2013, at 2:42 PM, David Holmes  wrote:

> On 19/04/2013 10:14 PM, Paul Sandoz wrote:
>> 
>> On Apr 19, 2013, at 1:15 PM, Alan Bateman  wrote:
>> 
>>> On 18/04/2013 19:49, Akhil Arora wrote:
>>>> Looks like the stars are aligning on getting on this into TL... the
>>>> refreshed webrev is -
>>>> 
>>>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>>> 
>>> A minor comment on Collection.removeIf is "that satisifies the given predicate" might be better than "which matches the provided predicate". Also for completeness, you could say "RuntimeExceptions and Errors thrown by the predicate are propagated ...".
>>> 
>>> In List.replaceAll then @throws NullPointerException is listed twice, which is okay, but might be better to combine them. A typo in the second NPE description "if the an element".
>>> 
>>> In the implementation then the only thing that puzzled me is checking the modification count in legacy Vector, that seems unnecessary.
>>> 
>> 
>> The function value could structurally modify the Vector instance.
> 
> So this came through while I was writing my similar comments ...
> 
> My reaction to this is simply "well don't do that".

FWIW in the past this functionality has helped me detect bugs, so yes i agree "don't do it" but sometimes it unintentionally happens and it can be harder to track down the source of the problem without a CME.


> If the function/predicate/comparator is mutating the Vector then the user gets what they deserve in my opinion. Trying to account for that is somewhat futile. As per my other email the loop check for modCount==expectedModCount will get hoisted from the loop. Further in removeIf you need to be a lot more defensive during the first iteration as you haven't kept a reference to the original size and array. That aside the second part of removeIf (the actual removal) doesn't invoke any external code so no concurrent modification is possible then.
> 
> This seems like overkill to me.
> 

I think the mod count checking should be explicitly hoisted outside the loops and performed at the end of the loop/method (see the spliterator.forEachReamining implementations) since a CME should only be used to detect bugs. Doug's comments on ArrayList's spliterator [*] are relevant.

Probably the most important methods for such checking are forEach, to be consistent with the default method implementation, Iterator/Spliterator.forEachRemaining, and Stream.forEach. 

If we can do such checking easily and efficiently for the other methods, which seems possible, then i think it worth doing and is consistent with the default methods, since they use iterator (List.sort defers to Collections.sort uses the iterator to update the list).

Paul.

[*]
        /*
         * If ArrayLists were immutable, or structurally immutable (no
         * adds, removes, etc), we could implement their spliterators
         * with Arrays.spliterator. Instead we detect as much
         * interference during traversal as practical without
         * sacrificing much performance. We rely primarily on
         * modCounts. These are not guaranteed to detect concurrency
         * violations, and are sometimes overly conservative about
         * within-thread interference, but detect enough problems to
         * be worthwhile in practice. To carry this out, we (1) lazily
         * initialize fence and expectedModCount until the latest
         * point that we need to commit to the state we are checking
         * against; thus improving precision.  (This doesn't apply to
         * SubLists, that create spliterators with current non-lazy
         * values).  (2) We perform only a single
         * ConcurrentModificationException check at the end of forEach
         * (the most performance-sensitive method). When using forEach
         * (as opposed to iterators), we can normally only detect
         * interference after actions, not before. Further
         * CME-triggering checks apply to all other possible
         * violations of assumptions for example null or too-small
         * elementData array given its size(), that could only have
         * occurred due to interference.  This allows the inner loop
         * of forEach to run without any further checks, and
         * simplifies lambda-resolution. While this does entail a
         * number of checks, note that in the common case of
         * list.stream().forEach(a), no checks or other computation
         * occur anywhere other than inside forEach itself.  The other
         * less-often-used methods cannot take advantage of most of
         * these streamlinings.
         */




From mike.duigou at oracle.com  Fri Apr 19 15:13:59 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 19 Apr 2013 08:13:59 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <51711F11.1040700@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FE203.4030405@oracle.com>
	<03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>
	<51711F11.1040700@oracle.com>
Message-ID: <7CEE4715-0FFC-4E28-9078-8D86352B1C0C@oracle.com>


On Apr 19 2013, at 03:40 , Alan Bateman wrote:

> On 18/04/2013 16:12, Mike Duigou wrote:
>> :
>> 
>>> @implSpec is very welcome, more reasons now with the addition of default methods.
>>> 
>>> Clearly distinguishing normative from non-normative text is also been a long standing problem so having a tag to identify the non-normative text is very useful. I had to look at a few examples in the lambda/jdk repo to convince myself that both @apiNote and @implNote are needed. One thing that isn't clear to me is whether the "official" Java SE documentation should include the text tagged @implNote or not.
>> Once we got going we decided to fill out the matrix. There's no obligation to use all of the tags.
>> 
> Where @implSpec is used, then do you have a view on whether this should be filtered out of the Java SE specs?

Not as currently used, no. The @implSpec is being used to describe required behaviour of the implementation, usually defaults. ie. Conforming defaults implementations must throw ISE (or UOE, etc.).  

Mike



From Alan.Bateman at oracle.com  Fri Apr 19 15:15:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Apr 2013 16:15:50 +0100
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and
	@implNote for JDK API Docs
In-Reply-To: <7CEE4715-0FFC-4E28-9078-8D86352B1C0C@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FE203.4030405@oracle.com>
	<03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>
	<51711F11.1040700@oracle.com>
	<7CEE4715-0FFC-4E28-9078-8D86352B1C0C@oracle.com>
Message-ID: <51715FA6.3020806@oracle.com>

On 19/04/2013 16:13, Mike Duigou wrote:
> :
> Not as currently used, no. The @implSpec is being used to describe required behaviour of the implementation, usually defaults. ie. Conforming defaults implementations must throw ISE (or UOE, etc.).
>
Sorry, I meant @implNote where it may not always be desirable to have 
that show up in the generated javadoc.

-Alan.


From mike.duigou at oracle.com  Fri Apr 19 15:18:50 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 19 Apr 2013 08:18:50 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <51715FA6.3020806@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FE203.4030405@oracle.com>
	<03E4E031-5876-4986-A5F3-932AE4854E1B@oracle.com>
	<51711F11.1040700@oracle.com>
	<7CEE4715-0FFC-4E28-9078-8D86352B1C0C@oracle.com>
	<51715FA6.3020806@oracle.com>
Message-ID: <649FC988-E76B-47F9-8A76-C3A48124D49F@oracle.com>


On Apr 19 2013, at 08:15 , Alan Bateman wrote:

> On 19/04/2013 16:13, Mike Duigou wrote:
>> :
>> Not as currently used, no. The @implSpec is being used to describe required behaviour of the implementation, usually defaults. ie. Conforming defaults implementations must throw ISE (or UOE, etc.).
>> 
> Sorry, I meant @implNote where it may not always be desirable to have that show up in the generated javadoc.

Unsure. I haven't looked at how the @implNote tag has been used. According to the definition it certainly could be. Both the @apiNote and @implNote are non-normative and could technically be removed from the spec.

I have a task today of generate samples with the @implSpec and @implNote tags moved to the end of the docs rather than before @param. That thread would be a good place to have the discussion about inclusion (along with placement).

Mike

> 
> -Alan.



From peter.levart at gmail.com  Fri Apr 19 15:43:11 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Apr 2013 17:43:11 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51715667.3010103@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
Message-ID: <5171660F.9000005@gmail.com>

On 04/19/2013 04:36 PM, Peter Levart wrote:
>
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>
>

Hi Mandy,

I changed the copyright header of WeakCache to GPLv2 with ClassPath 
exception and corrected a minor formatting inconsistency:

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html

Regards, Peter



From peter.levart at gmail.com  Fri Apr 19 16:29:00 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Apr 2013 18:29:00 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5171660F.9000005@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<5171660F.9000005@gmail.com>
Message-ID: <517170CC.6020801@gmail.com>

Hi Mandy,

I just noticed the following (have been thinking of it already, but then 
forgot) in original code:

/*
  512              * Note that we need not worry about reaping the cache for
  513              * entries with cleared weak references because if a proxy class
  514              * has been garbage collected, its class loader will have been
  515              * garbage collected as well, so the entire cache will be reaped
  516              * from the loaderToCache map.
  517              */


Each ClassLoader maintains explicit hard-references to all Class objects 
for classes defined by the loader. So proxy Class object can not be 
GC-ed until the ClassLoader is GC-ed. So we need not register the 
CacheValue objects in WeakCache with a refQueue. The expunging of 
reverseMap entries is already performed with CacheKey when it is cleared 
and equeued. There's no harm as it is, since the clean-up is performed 
with all the checks and is idempotent, but it need not be done for 
ClassValue objects holding weak references to proxy Class objects.

I'll do that change to WeakCache in next webrev together with any other 
possible changes that might be needed.

Regards, Peter


On 04/19/2013 05:43 PM, Peter Levart wrote:
> On 04/19/2013 04:36 PM, Peter Levart wrote:
>>
>> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>>
>>
>
> Hi Mandy,
>
> I changed the copyright header of WeakCache to GPLv2 with ClassPath 
> exception and corrected a minor formatting inconsistency:
>
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html 
>
>
> Regards, Peter
>



From bharadwaj.yadavalli at oracle.com  Fri Apr 19 16:41:56 2013
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Fri, 19 Apr 2013 12:41:56 -0400
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
Message-ID: <517173D4.1040207@oracle.com>

I would like to request for a review of code changes made to support 
lambda related modifications to allow static and invokespecial calls to 
interface methods per spec version 0.6.2 
(http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.html). These changes 
support an upcoming change that compiles lambdas as private static 
methods in conjunction with hotspot changes pushed to address JDK-8006267.

JBS        : https://jbs.oracle.com/bugs/browse/JDK-8008687
Webrev : http://cr.openjdk.java.net/~bharadwaj/8008687/webrev/

Thanks,

Bharadwaj



From jim.gish at oracle.com  Fri Apr 19 16:54:06 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 19 Apr 2013 12:54:06 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <51708400.4040603@CoSoCo.de>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de> <51702F55.5050702@oracle.com>
	<51708400.4040603@CoSoCo.de>
Message-ID: <517176AE.80807@oracle.com>

Hi Henry,  Can you please comment on the simplifications you did ?

Thanks,
     Jim

On 04/18/2013 07:38 PM, Ulf Zibis wrote:
> Am 18.04.2013 19:37, schrieb Jim Gish:
>>
>> On 04/18/2013 08:49 AM, Ulf Zibis wrote:
>>> Hi,
>>>
>>> I'm wondering, that StringJoiner has some logic for pre/suffix, but 
>>> nothing to loop the elements themselves :-(
>>>
>>> To me, StringJoiner is a useless complicated box around 
>>> StringBuilder, and imagine, someone needs thread-safety.
>>> It also slows down performance, as it needs additional instances and 
>>> additional class to be loaded (critical at VM startup).
>>>
>>> Instead please add to StringBuilder and StringBuffer:
>>>      append(CharSequence... elements);
>>>      append(char delimiter, CharSequence... elements);
>>> append(char delimiter, Iterable elements);
>>> cut(int len);    // removes len chars at the end of the sequence
>>> optional:
>>> append(CharSequence delimiter, CharSequence... elements);
>>> append(CharSequence delimiter, Iterable 
>>> elements);
>> I started off with something similar, but it was stripped out when 
>> Henry did the performance improvements.
>
> Hm, I have no idea, how above suggestions should prevent performance 
> improvements. Can you help me?
>
>> Given that most people feel that this is going to be put to 
>> heavy-weight usage, it doesn't seem to merit too much emphasis on 
>> performance or complicating the implementation at this point.
>
> Your implementation has
> 1 class with 7 methods
> 2 additional methods in String
> To cover the same functionality, above approach basically only needs 2 
> additional methods in StringBuilder, has better performance, so what 
> is complicated on that?
>
> @Martin: What is your opinion?
>
> Thanks,
>
> -Ulf
>
>
>>> For performance reasons, append should always append the trailing 
>>> delimeter, which could be cut at the end.
>>>
>>> It's questionable, if class string needs a static (=no relation to 
>>> an existing string in contrast to non-static split()) join method, 
>>> as it seduces to
>>>         "[" + String.join(...) + "]"
>>> which needs some effort from javac side to optimize to a single 
>>> StringBuilder task.
>>> IMO we better had StringBuilder.join(...), so javac could easily 
>>> optimize to:
>>>     new StringBuilder().append('[').append(',', 
>>> someStrings).cut(1).append(']').toString()
>>>
>>> -Ulf
>>>
>>>
>>> Am 18.04.2013 00:07, schrieb Martin Buchholz:
>>>> I'm still wondering about whether a joiner utility should support a 
>>>> prefix
>>>> and suffix.  The obvious uses for this are collection class toString
>>>> methods, but we already know that we can and should implement those 
>>>> with a
>>>> single precise char[] construction, so should not use StringJoiner, 
>>>> or at
>>>> least not this StringJoiner implementation.  And if we're just talking
>>>> about pure convenience, it's hard to beat
>>>>
>>>> "[" + String.join(...) + "]"
>>>>
>>>>
>>>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:
>>>>
>>>>> Here's an update: http://cr.openjdk.java.net/~**
>>>>> jgish/Bugs-5015163-7172553/< 
>>>>>
>>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/ 
>>>>>
>>>>> Jim
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From henry.jen at oracle.com  Fri Apr 19 17:06:25 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 19 Apr 2013 10:06:25 -0700
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: <517176AE.80807@oracle.com>
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com>
	
	<516FEBDC.2030004@CoSoCo.de> <51702F55.5050702@oracle.com>
	<51708400.4040603@CoSoCo.de> <517176AE.80807@oracle.com>
Message-ID: 

Sorry I am not receiving emails from core-lib-dev earlier.

What I did was to remove things we considered not absolutely required, which left us only a StringJoiner class and two String.join methods.

StringJoiner was intended to be used with Stream as a collector, thus prefix, and suffix is desired like Collection.toString().

Cheers,
Henry


On Apr 19, 2013, at 9:54 AM, Jim Gish  wrote:

> Hi Henry,  Can you please comment on the simplifications you did ?
> 
> Thanks,
>    Jim
> 
> On 04/18/2013 07:38 PM, Ulf Zibis wrote:
>> Am 18.04.2013 19:37, schrieb Jim Gish:
>>> 
>>> On 04/18/2013 08:49 AM, Ulf Zibis wrote:
>>>> Hi,
>>>> 
>>>> I'm wondering, that StringJoiner has some logic for pre/suffix, but nothing to loop the elements themselves :-(
>>>> 
>>>> To me, StringJoiner is a useless complicated box around StringBuilder, and imagine, someone needs thread-safety.
>>>> It also slows down performance, as it needs additional instances and additional class to be loaded (critical at VM startup).
>>>> 
>>>> Instead please add to StringBuilder and StringBuffer:
>>>>     append(CharSequence... elements);
>>>>     append(char delimiter, CharSequence... elements);
>>>> append(char delimiter, Iterable elements);
>>>> cut(int len);    // removes len chars at the end of the sequence
>>>> optional:
>>>> append(CharSequence delimiter, CharSequence... elements);
>>>> append(CharSequence delimiter, Iterable elements);
>>> I started off with something similar, but it was stripped out when Henry did the performance improvements.
>> 
>> Hm, I have no idea, how above suggestions should prevent performance improvements. Can you help me?
>> 
>>> Given that most people feel that this is going to be put to heavy-weight usage, it doesn't seem to merit too much emphasis on performance or complicating the implementation at this point.
>> 
>> Your implementation has
>> 1 class with 7 methods
>> 2 additional methods in String
>> To cover the same functionality, above approach basically only needs 2 additional methods in StringBuilder, has better performance, so what is complicated on that?
>> 
>> @Martin: What is your opinion?
>> 
>> Thanks,
>> 
>> -Ulf
>> 
>> 
>>>> For performance reasons, append should always append the trailing delimeter, which could be cut at the end.
>>>> 
>>>> It's questionable, if class string needs a static (=no relation to an existing string in contrast to non-static split()) join method, as it seduces to
>>>>        "[" + String.join(...) + "]"
>>>> which needs some effort from javac side to optimize to a single StringBuilder task.
>>>> IMO we better had StringBuilder.join(...), so javac could easily optimize to:
>>>>    new StringBuilder().append('[').append(',', someStrings).cut(1).append(']').toString()
>>>> 
>>>> -Ulf
>>>> 
>>>> 
>>>> Am 18.04.2013 00:07, schrieb Martin Buchholz:
>>>>> I'm still wondering about whether a joiner utility should support a prefix
>>>>> and suffix.  The obvious uses for this are collection class toString
>>>>> methods, but we already know that we can and should implement those with a
>>>>> single precise char[] construction, so should not use StringJoiner, or at
>>>>> least not this StringJoiner implementation.  And if we're just talking
>>>>> about pure convenience, it's hard to beat
>>>>> 
>>>>> "[" + String.join(...) + "]"
>>>>> 
>>>>> 
>>>>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:
>>>>> 
>>>>>> Here's an update: http://cr.openjdk.java.net/~**
>>>>>> jgish/Bugs-5015163-7172553/< 
>>>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/ 
>>>>>> Jim
>> 
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
> 



From Lance.Andersen at oracle.com  Fri Apr 19 17:34:46 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 19 Apr 2013 13:34:46 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
Message-ID: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>

Hi,

We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be notified when/if it was deregistered via DriverManager.deregisterDriver if desired.


The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01



Best
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From andrea.aime at geo-solutions.it  Sun Apr 14 15:37:07 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sun, 14 Apr 2013 17:37:07 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
	Memory enhancements
In-Reply-To: 
References: 
Message-ID: 

On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s
wrote:

> Dear Java2D members,
>
> Could someone review the following webrev concerning Java2D Pisces to
> enhance its performance and reduce its memory footprint (RendererContext
> stored in thread local or concurrent queue):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>
> FYI I fixed file headers in this patch and signed my OCA 3 weeks ago.
>
> Remaining work:
> - cleanup (comments ...)
> - statistics to perform auto-tuning
> - cache / memory cleanup (SoftReference ?): use hints or System properties
> to adapt it to use cases
> - another problem: fix clipping performance in Dasher / Stroker for
> segments out of bounds
>
> Could somebody support me ? ie help me working on these tasks or just to
> discuss on Pisces algorithm / implementation ?
>

Hi,
I would like to express my support for this patch.
Given that micro-benchmarks have already been run, I took the patch for a
spin in a large, real world benchmark instead,
the OSGeo WMS Shootout 2010 benchmark, for which you can see the results
here:
http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010

The presentation is long, but suffice it to say all Java based
implementations took quite the beating due to the
poor scalability of Ductus with antialiased rendering of vector data (for
an executive summary just look
at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
Constellation SDI were the
Java based ones)

I took the same tests and run them again on my machine (different hardware
than the tests, don't try to compare
the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a
couple of weeks old) and the
same, but with Laurent's patches applied.
Here are the results, throughput (in maps generated per second) with the
load generator (JMeter) going
up from one client to 64 concurrent clients:

   *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces
renderer improvements* *Pisces renderer performance gain, %*  1 13,97 12,43
13,03 4,75%  2 22,08 20,60 20,77 0,81%  4 34,36 33,15 33,36 0,62%  8 39,39
40,51 41,71 2,96%  16 40,61 44,57 46,98 5,39%  32 41,41 44,73 48,16 7,66%
64 37,09 42,19 45,28 7,32%

Well, first of all, congratulations to the JDK developers, don't know what
changed in JDK 8, but
GeoServer seems to like it quite a bit :-).
That said, Laurent's patch also gives a visible boost, especially when
several concurrent clients are
asking for the maps.

Mind, as I said, this is no micro-benchmark, it is a real application
loading doing a lot of I/O
(from the operating system file cache), other processing before the data
reaches the rendering
pipeline, and then has to PNG encode the output BufferedImage (PNG encoding
being rather
expensive), so getting this speedup from just a change in the rendering
pipeline is significant.

Long story short... personally I'd be very happy if this patch was going to
be integrated in Java 8 :-)

Cheers
Andrea

-- 
==
GeoServer training in Milan, 6th & 7th June 2013!  Visit
http://geoserver.geo-solutions.it for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------


From tim at peierls.net  Tue Apr 16 12:05:57 2013
From: tim at peierls.net (Tim Peierls)
Date: Tue, 16 Apr 2013 08:05:57 -0400
Subject: RFR : 8010953: Add primitive summary statistics utils
In-Reply-To: 
References: 
Message-ID: 

On Mon, Apr 15, 2013 at 7:30 PM, Mike Duigou  wrote:

> Another integration review in the JSR-335 libraries series. These three
> classes provide a utility for conveniently finding count, sum, min,  max
> and average of ints, longs or doubles. They can be used with existing code
> but will most likely be used with the Collectors utilities or directly with
> primitive or boxed streams.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8010953/1/webrev/


Why the extra toString() calls on the result of String.format(...)?

--tim


From yong.huang at oracle.com  Wed Apr 17 08:06:43 2013
From: yong.huang at oracle.com (yong.huang at oracle.com)
Date: Wed, 17 Apr 2013 08:06:43 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130417080719.7090948381@hg.openjdk.java.net>

Changeset: 414384c3b3eb
Author:    yhuang
Date:      2013-04-16 22:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/414384c3b3eb

8011977: ISO 4217 Amendment Number 155
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! test/java/util/Currency/tablea1.txt

Changeset: 779ba708fee3
Author:    yhuang
Date:      2013-04-17 01:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/779ba708fee3

Merge

- src/share/native/java/lang/ResourceBundle.c



From richard.bair at oracle.com  Wed Apr 17 20:26:11 2013
From: richard.bair at oracle.com (Richard Bair)
Date: Wed, 17 Apr 2013 13:26:11 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
	Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
Message-ID: 

> 
> Also, this is with the Java version, right?  
> 
> Yes, my patch is pure java given as webrev:
>         http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>  
> We got a decent 2x speedup in FX by porting the version of Open Pisces that you started with to C code (all except on Linux where we couldn't find the right gcc options to make it faster than Hotspot).  So, we have yet to investigate a native version in the JDK which might provide even more gains?

Oleg did more analysis on this and it appears the reason hotspot on Linux was faster than the C version was because on Linux it is -server compiler (c2) whereas on Windows / Mac it is client compiler (c1). Possibly using -server on windows / mac would also have hotspot beating the C version, although that hasn't been tested.

Richard



From jim.gish at oracle.com  Fri Apr 19 17:40:00 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 19 Apr 2013 13:40:00 -0400
Subject: RFR: String.join(), StringJoiner additions
In-Reply-To: 
References: <51673A45.8060908@oracle.com>
	
	<516F18D7.4040308@oracle.com> <516F4A4A.4040906@Oracle.com>
	<51702EBE.3060605@oracle.com>
	
Message-ID: <51718170.7040803@oracle.com>

Martin,

I've updated the toString() method as you suggested. 
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 


Thanks,
    Jim
On 04/18/2013 05:02 PM, Martin Buchholz wrote:
>
>
>
> On Thu, Apr 18, 2013 at 10:34 AM, Jim Gish  > wrote:
>
>     That was a nice idea, but you don't want to change the value when
>     you do toString().  Otherwise, if you subsequently add a new
>     element, you're hosed because you've already added on the suffix.
>
>
> You can cheaply save the current length, append the suffix, call 
> toString, and reset the length back to the old value to avoid the 
> overhead of String "+".

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From daniel.fuchs at oracle.com  Fri Apr 19 18:08:42 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Fri, 19 Apr 2013 18:08:42 +0000
Subject: hg: jdk8/tl/jaxp: 8010495: Update JAXP NetBeans project - add support
	for generating javadoc
Message-ID: <20130419180845.D591D48484@hg.openjdk.java.net>

Changeset: 1c2079d11a79
Author:    dfuchs
Date:      2013-04-19 17:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c2079d11a79

8010495: Update JAXP NetBeans project - add support for generating javadoc
Summary: Make it possible to use NetBeans to edit the jaxp sources and to generate a preview of the associated javadoc.
Reviewed-by: joehw, alanb

! build.xml
! nbproject/project.xml



From Lance.Andersen at oracle.com  Fri Apr 19 18:11:22 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 19 Apr 2013 14:11:22 -0400
Subject: review request: 8011620 adding free form netbeans project for
	jdbc to jdk/make/netbeans
In-Reply-To: 
References: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com>
	<5164330F.3010604@CoSoCo.de>
	
Message-ID: 

still looking for a committer to bless this webrev so I can put it back 

thank you in advance

best
Lance
On Apr 9, 2013, at 11:58 AM, Lance Andersen - Oracle wrote:

> Thank you ulf,  I made the change in my workspace so that it will be accommodated as part of the putback
> 
> Best
> Lance
> On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote:
> 
>> Hi,
>> 
>> there is a little indentation error in build.xml in line 42.
>> 
>> -Ulf
>> 
>> Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle:
>>> Hi,
>>> 
>>> This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc
>>> 
>>> As part of this change,  I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8
>>> 
>>> The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/
>>> 
>>> Best
>>> lance
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>> 
>>> 
>> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From jonathan.gibbons at oracle.com  Fri Apr 19 18:12:02 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 19 Apr 2013 18:12:02 +0000
Subject: hg: jdk8/tl/langtools: 8012661: remove langtools Makefile-classic
Message-ID: <20130419181205.9C80448485@hg.openjdk.java.net>

Changeset: d59730bd3162
Author:    jjg
Date:      2013-04-19 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d59730bd3162

8012661: remove langtools Makefile-classic
Reviewed-by: erikj, tbell

- make/Makefile-classic



From mike.duigou at oracle.com  Fri Apr 19 18:16:41 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 19 Apr 2013 18:16:41 +0000
Subject: hg: jdk8/tl/jdk: 8008670: Initial java.util.stream putback --
	internal API classes
Message-ID: <20130419181702.A824A48486@hg.openjdk.java.net>

Changeset: 6139f8fb0137
Author:    mduigou
Date:      2013-04-16 22:50 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6139f8fb0137

8008670: Initial java.util.stream putback -- internal API classes
Reviewed-by: mduigou, dholmes
Contributed-by: Brian Goetz , Doug Lea 
        , Paul Sandoz 

+ src/share/classes/java/util/stream/AbstractShortCircuitTask.java
+ src/share/classes/java/util/stream/AbstractTask.java
+ src/share/classes/java/util/stream/FindOps.java
+ src/share/classes/java/util/stream/ForEachOps.java
+ src/share/classes/java/util/stream/MatchOps.java
+ src/share/classes/java/util/stream/Node.java
+ src/share/classes/java/util/stream/PipelineHelper.java
+ src/share/classes/java/util/stream/Sink.java
+ src/share/classes/java/util/stream/StreamOpFlag.java
+ src/share/classes/java/util/stream/StreamShape.java
+ src/share/classes/java/util/stream/TerminalOp.java
+ src/share/classes/java/util/stream/TerminalSink.java
+ src/share/classes/java/util/stream/Tripwire.java



From jim.gish at oracle.com  Fri Apr 19 19:44:43 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 19 Apr 2013 15:44:43 -0400
Subject: RFR: 8010939 Deadlock in LogManager
In-Reply-To: <51688FEE.3070208@oracle.com>
References: <51686A66.70107@oracle.com> <51688FEE.3070208@oracle.com>
Message-ID: <51719EAB.10207@oracle.com>

Hi Mandy,

I've incorporated your changes, run JPRT, and posted an updated webrev: 
http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock.1/ 


Thanks,
     Jim

On 04/12/2013 06:51 PM, Mandy Chung wrote:
> Hi Jim,
>
> Thanks for fixing this.
>
> On 4/12/2013 1:11 PM, Jim Gish wrote:
>> Please review: 
>> http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock/
>>
>
> The fix looks okay.  I would recommend to move the call to 
> manager.drainLoggerRefQueueBounded() back to LogManager.addLogger 
> which was originally intended and make the two separate synchronized 
> methods called at the entry point as it's described in the comments of 
> the drainLoggerRefQueueBounded.
>
> You added a comment listing the bug ID.   Our convention does not 
> reference the bug numbers in the source unless it's absolute critical 
> information to capture to help cross-referencing.  I wouldn't want to 
> see the bug numbers in the source that are fixed in the past 18 years :)
>
> Good that you have a test to reproduce the deadlock.   A few comments:
> The thread should be daemon threads so that the test will terminate 
> right away if there is a deadlock.
> L99: is this needed to reproduce the deadlock?  Logger.getLogger has 
> already called LogManager.addLogger to register the logger.
> L111: what exception is expected to be thrown and ignored by the test?
> L137,144 you can call ThreadMXBean.isSynchronizerUsageSupported() to 
> test if monitoring of ownable synchronizer is supported instead of 
> catch UOE.
> L154: you may just throw an exception and terminate the test.
>
> Better to rename your test to some informative name that will give 
> some idea what it does.  It should have @summary to give a summary of 
> what it tests.  There are several deadlock tests in 
> test/java/util/logging.  I like your framework and probably good to 
> consolidate these deadlock tests but this is something for the future 
> clean up - just to mention it.  The LoggingDeadlocks*.java tests have 
> the comments how the deadlock occurs that I find useful. It'll be good 
> to add similar information in your new test.  Some formatting nit: L97 
> a space after "i=0;" and an extra space is many places (e.g. L69-71, 
> L128, 141, 156, etc: a space not needed in front of the first 
> parameter after "(",   a space of the last parameter before ")" not 
> needed - L127, 134, 152, etc.
>
> thanks
> Mandy

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From akhil.arora at oracle.com  Fri Apr 19 23:59:59 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 19 Apr 2013 16:59:59 -0700
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
Message-ID: <5171DA7F.1070105@oracle.com>

Please review the addition of optimized defaults for Iterator's 
forEachRemaining to ArrayList, LinkedList, Vector and 
CopyOnWriteArrayList. The unit test has a performance comparison test 
(disabled by default) that measures the difference between this method 
and hasNext()/next(). Significant improvements were measured by 
overriding the default forEachRemaining by these classes (others, not so 
much).

http://cr.openjdk.java.net/~akhil/8005051.1/webrev/

Thanks


From akhil.arora at oracle.com  Sat Apr 20 01:36:49 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 19 Apr 2013 18:36:49 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5170404B.9000708@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com>
Message-ID: <5171F131.2050209@oracle.com>

Updated with feedback so far -

http://cr.openjdk.java.net/~akhil/8001647.9/webrev/

On 04/18/2013 11:49 AM, Akhil Arora wrote:
> Looks like the stars are aligning on getting on this into TL... the
> refreshed webrev is -
>
> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>
> Please review
>
> Thanks
>
> On 12/10/2012 09:31 PM, Akhil Arora wrote:
>> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
>>
>> - now with synchronized and unmodifiable wrappers in Collections.java
>> for the default methods being added
>>
>> On 12/10/2012 01:48 PM, Akhil Arora wrote:
>>> Updated with yours and Alan's comments -
>>>
>>> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>>>
>>> - removed null check for removeSet
>>> - cache this.size in removeAll, replaceAll
>>>       (for ArrayList, Vector and CopyOnWriteArrayList)
>>> - calculate removeCount instead of BitCount.cardinality()
>>> - removed unnecessary @library from test support classes
>
>



From akhil.arora at oracle.com  Sat Apr 20 01:37:04 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 19 Apr 2013 18:37:04 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <84BA98C9-0C2E-4BA4-BF6D-F4007DA8EDB7@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com>
	<84BA98C9-0C2E-4BA4-BF6D-F4007DA8EDB7@oracle.com>
Message-ID: <5171F140.9070400@oracle.com>

On 04/18/2013 12:36 PM, Mike Duigou wrote:
> Hi Akhil;
>
> List.sort::
>
> - @since tag is in a strange location.
>
> - The (optional) on IAE is in a strange position and not linked like the others.

fixed both

> AbstractList::
>
> - Should we consider adding overrides for default methods here even if our impls wouldn't use them? We could at least add modCount checking.

I tried, but could not do anything here more than what the default is 
doing, so left it alone

> Tests::
>
> - Lots of enhancement here since my last review. Good Job!
>
> - Wrong GPL license. Tests don't get Classpath exemption.

fixed

> - In Map.Defaults (around line 539 in http://cr.openjdk.java.net/~mduigou/JDK-8010122/6/webrev/test/java/util/Map/Defaults.java.html) I found it useful to generate an implementation of the base interface to directly test the default methods implementations. You may want to add something similar to CollectionExtensionMethodsTest.

the default methods are exercised (and tested) by the classes that do 
not provide optimized defaults, so i think we do have coverage for the 
pure default methods

> - You may want to include a Collections.newSetFromMap in DataProvider.

done

> - I am now preferring the Iterator return from DataProvider though I haven't made an on-demand provider yet. You could also mark your DataProvider as ", parallel = true"

added parallel

> On Apr 18 2013, at 11:49 , Akhil Arora wrote:
>
>> Looks like the stars are aligning on getting on this into TL... the refreshed webrev is -
>>
>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>
>> Please review
>>
>> Thanks
>>
>> On 12/10/2012 09:31 PM, Akhil Arora wrote:
>>> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
>>>
>>> - now with synchronized and unmodifiable wrappers in Collections.java
>>> for the default methods being added
>>>
>>> On 12/10/2012 01:48 PM, Akhil Arora wrote:
>>>> Updated with yours and Alan's comments -
>>>>
>>>> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>>>>
>>>> - removed null check for removeSet
>>>> - cache this.size in removeAll, replaceAll
>>>>      (for ArrayList, Vector and CopyOnWriteArrayList)
>>>> - calculate removeCount instead of BitCount.cardinality()
>>>> - removed unnecessary @library from test support classes
>>
>



From akhil.arora at oracle.com  Sat Apr 20 01:39:19 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 19 Apr 2013 18:39:19 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5171274C.1080606@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
Message-ID: <5171F1C7.80504@oracle.com>

On 04/19/2013 04:15 AM, Alan Bateman wrote:
> On 18/04/2013 19:49, Akhil Arora wrote:
>> Looks like the stars are aligning on getting on this into TL... the
>> refreshed webrev is -
>>
>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>
> A minor comment on Collection.removeIf is "that satisifies the given
> predicate" might be better than "which matches the provided predicate".
> Also for completeness, you could say "RuntimeExceptions and Errors
> thrown by the predicate are propagated ...".

fixed both

> In List.replaceAll then @throws NullPointerException is listed twice,
> which is okay, but might be better to combine them. A typo in the second
> NPE description "if the an element".

combined and fixed NPE

> In the implementation then the only thing that puzzled me is checking
> the modification count in legacy Vector, that seems unnecessary.
>
> I see Mike has looked through the tests in detail. One additional
> comment is just location and trying to keep it consistent with the
> current organization if possible.

moved the tests to java/util/Collection

> -Alan.



From akhil.arora at oracle.com  Sat Apr 20 02:17:37 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 19 Apr 2013 19:17:37 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <51713BA7.2040002@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<35AB9770-D45C-404B-9AA3-03162E7F8B17@oracle.com>
	<51713BA7.2040002@oracle.com>
Message-ID: <5171FAC1.7030802@oracle.com>

On 04/19/2013 05:42 AM, David Holmes wrote:
> On 19/04/2013 10:14 PM, Paul Sandoz wrote:
>>
>> On Apr 19, 2013, at 1:15 PM, Alan Bateman 
>> wrote:
>>
>>> On 18/04/2013 19:49, Akhil Arora wrote:
>>>> Looks like the stars are aligning on getting on this into TL... the
>>>> refreshed webrev is -
>>>>
>>>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>>>
>>> A minor comment on Collection.removeIf is "that satisifies the given
>>> predicate" might be better than "which matches the provided
>>> predicate". Also for completeness, you could say "RuntimeExceptions
>>> and Errors thrown by the predicate are propagated ...".
>>>
>>> In List.replaceAll then @throws NullPointerException is listed twice,
>>> which is okay, but might be better to combine them. A typo in the
>>> second NPE description "if the an element".
>>>
>>> In the implementation then the only thing that puzzled me is checking
>>> the modification count in legacy Vector, that seems unnecessary.
>>>
>>
>> The function value could structurally modify the Vector instance.
>
> So this came through while I was writing my similar comments ...
>
> My reaction to this is simply "well don't do that". If the
> function/predicate/comparator is mutating the Vector then the user gets
> what they deserve in my opinion. Trying to account for that is somewhat
> futile. As per my other email the loop check for
> modCount==expectedModCount will get hoisted from the loop. Further in
> removeIf you need to be a lot more defensive during the first iteration
> as you haven't kept a reference to the original size and array. That
> aside the second part of removeIf (the actual removal) doesn't invoke
> any external code so no concurrent modification is possible then.
>
> This seems like overkill to me.

removed the in-loop modCount checks in the second part of removeIf for 
ArrayList and Vector

There are some tests that verify that a CME is thrown when a lambda 
modifies the collection it is operating upon. I added a count of how 
many times a lambda is called, and except for sort (which calls through 
to Arrays.sort), all such attempts are detected at the very first 
attempt (at index 0) so the checks seem to be working (and are not 
getting hoisted).



From mandy.chung at oracle.com  Sat Apr 20 06:24:16 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Sat, 20 Apr 2013 06:24:16 +0000
Subject: hg: jdk8/tl/jdk: 8010939: Deadlock in LogManager
Message-ID: <20130420062429.63531484A1@hg.openjdk.java.net>

Changeset: e8f1dc6d0c0c
Author:    jgish
Date:      2013-04-19 16:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8f1dc6d0c0c

8010939: Deadlock in LogManager
Summary: re-order locks to avoid deadlock
Reviewed-by: mchung

! src/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/DrainFindDeadlockTest.java



From chris.hegarty at oracle.com  Sat Apr 20 06:46:41 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 20 Apr 2013 07:46:41 +0100
Subject: review request: 8011620 adding free form netbeans project for
	jdbc to jdk/make/netbeans
In-Reply-To: 
References: <28656B01-FE05-48D1-B544-03E08B362651@oracle.com>
	<5164330F.3010604@CoSoCo.de>
	
	
Message-ID: <517239D1.8070300@oracle.com>

FWIW, looks ok to me.

-Chris.

On 04/19/2013 07:11 PM, Lance Andersen - Oracle wrote:
> still looking for a committer to bless this webrev so I can put it back
>
> thank you in advance
>
> best
> Lance
> On Apr 9, 2013, at 11:58 AM, Lance Andersen - Oracle wrote:
>
>> Thank you ulf,  I made the change in my workspace so that it will be accommodated as part of the putback
>>
>> Best
>> Lance
>> On Apr 9, 2013, at 11:26 AM, Ulf Zibis wrote:
>>
>>> Hi,
>>>
>>> there is a little indentation error in build.xml in line 42.
>>>
>>> -Ulf
>>>
>>> Am 09.04.2013 16:55, schrieb Lance Andersen - Oracle:
>>>> Hi,
>>>>
>>>> This is a request to review adding a netbeans freeform project to jdk/make/netbeans for jdbc
>>>>
>>>> As part of this change,  I also modified common/shared.xml to properly look for the jtreg report.html in the html directory and so the javadoc was using version 1.8
>>>>
>>>> The web rev is here http://cr.openjdk.java.net/~lancea/8011620/webrev.00/
>>>>
>>>> Best
>>>> lance
>>>>
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>>
>>>>
>>>
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>


From peter.levart at gmail.com  Sat Apr 20 07:31:00 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 Apr 2013 09:31:00 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51715667.3010103@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
Message-ID: <51724434.10107@gmail.com>

Hi Mandy,

I have another idea. Before jumping to implement it, I will first ask 
what do you think of it. For example:

- have an optimal interface names key calculated from interfaces.
- visibility of interfaces and other validations are pushed to slow-path 
(inside ProxyClassFactory.apply)
- the proxy Class object returned from WeakCache.get() is post-validated 
with a check like:

for (Class intf : interfaces) {
     if (!intf.isAssignableFrom(proxyClass)) {
         throw new IllegalArgumentException();
     }
}
// return post-validated proxyClass from getProxyClass0()...

I feel that Class.isAssignableFrom(Class) check could be much faster and 
that the only reason the check can fail is if some interface is not 
visible from the class loader.

Am I correct?

Regards, Peter



On 04/19/2013 04:36 PM, Peter Levart wrote:
> Hi Mandy,
>
> On 04/19/2013 07:33 AM, Mandy Chung wrote:
>>>
>>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html 
>>>
>>> What about package-private in java.lang.reflect? It makes Proxy 
>>> itself much easier to read. When we decide which way to go, I can 
>>> remove the interface and only leave a single package-private class...
>>>
>>
>> thanks.  Moving it to a single package-private classin 
>> java.lang.reflectand remove the interface sounds good.
>
> Right.
>
>>
>> I have merged your patch with the recent TL repo and did some clean 
>> up while reviewing it.  Some comments:
>> 1. getProxyClass0 should validate the input interfaces and throw IAE 
>> if any illegal argument (e.g. interfaces are not visible to the given 
>> loader) before calling proxyClassCache.get(loader, interfaces). I 
>> moved back the validation code from ProxyClassFactory.apply to 
>> getProxyClass0.
>
> Ops, you're right. There could be a request with interface(s) with 
> same name(s) but loaded by different loader(s) and such code could 
> return wrong pre-cached proxy class instead of throwing exception. 
> Unfortunately, moving validation to slow-path was the cause of major 
> performance and scalability improvement observed. With validation 
> moved back to getProxyClass0 (in spite of using two-level WeakCache), 
> we have the following performance (WeakCache#1):
>
>
> Summary (4 Cores x 2 Threads i7 CPU):
>
> Test                     Threads  ns/op Original WeakCache#1
> =======================  =======  ============== ===========
> Proxy_getProxyClass            1        2,403.27 2,174.51
>                                4        3,039.01 2,555.00
>                                8        5,193.58 4,273.42
>
> Proxy_isProxyClassTrue         1           95.02 43.14
>                                4        2,266.29 43.23
>                                8        4,782.29 72.06
>
> Proxy_isProxyClassFalse        1           95.02 1.36
>                                4        2,186.59 1.36
>                                8        4,891.15 2.72
>
> Annotation_equals              1          240.10 195.68
>                                4        1,864.06 201.41
>                                8        8,639.20 337.46
>
> It's a little better than original getProxyClass(), but not much. The 
> isProxyClass() and consequently Annotation.equals() are far better 
> though. But as you might have guessed, I kind of solved that too...
>
> My first attempt was to optimize the interface validation. Only the 
> "visibility" part is necessary to be performed on fast-path. 
> Uniqueness and other things can be performed on slow-path. With 
> split-validation and hacks like:
>
>     private static final MethodHandle findLoadedClass0MH, 
> findBootstrapClassMH;
>     private static final ClassLoader dummyCL = new ClassLoader() {};
>
>     static {
>         try {
>             Method method = 
> ClassLoader.class.getDeclaredMethod("findLoadedClass0", String.class);
>             method.setAccessible(true);
>             findLoadedClass0MH = 
> MethodHandles.lookup().unreflect(method);
>
>             method = 
> ClassLoader.class.getDeclaredMethod("findBootstrapClass", String.class);
>             method.setAccessible(true);
>             findBootstrapClassMH = 
> MethodHandles.lookup().unreflect(method);
>         } catch (NoSuchMethodException e) {
>             throw (Error) new 
> NoSuchMethodError(e.getMessage()).initCause(e);
>         } catch (IllegalAccessException e) {
>             throw (Error) new 
> IllegalAccessError(e.getMessage()).initCause(e);
>         }
>     }
>
>     static Class findLoadedClass(ClassLoader loader, String name) {
>         try {
>             if (VM.isSystemDomainLoader(loader)) {
>                 return (Class) 
> findBootstrapClassMH.invokeExact(dummyCL, name);
>             } else {
>                 return (Class) 
> findLoadedClass0MH.invokeExact(loader, name);
>             }
>         } catch (RuntimeException | Error e) {
>             throw e;
>         } catch (Throwable t) {
>             throw new UndeclaredThrowableException(t);
>         }
>     }
>
>
> ... using findLoadedClass(loader, intf.getName()) and only doing 
> Class.forName(intf.getName(), false, loader) if the former returned 
> null ... I managed to reclaim some performance (WeakCache#1+):
>
>
> Test                     Threads  ns/op Original  WeakCache#1 
> WeakCache#1+
> =======================  =======  ============== =========== ============
> Proxy_getProxyClass            1        2,403.27 2,174.51 1,589.36
>                                4        3,039.01 2,555.00 1,929.11
>                                8        5,193.58 4,273.42 3,409.77
>
>
> ...but that was still not very satisfactory.
>
> I modified the KeyFactory to create keys that weakly-reference 
> interface Class objects and implement hashCode/equals in terms of 
> comparing those Class objects. With such keys, no false aliasing can 
> occur and the whole validation can be pushed back to slow-path. I 
> tried hard to create keys with as little space overhead as possible:
>
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>
>
> ...but there can be no miracles. The good news is that the performance 
> is back (WeakCache#2):
>
>
> Summary (4 Cores x 2 Threads i7 CPU):
>
> Test                     Threads  ns/op Original WeakCache#1 WeakCache#2
> =======================  =======  ============== =========== ===========
> Proxy_getProxyClass            1        2,403.27 2,174.51 163.57
>                                4        3,039.01 2,555.00 211.70
>                                8        5,193.58 4,273.42 322.14
>
> Proxy_isProxyClassTrue         1           95.02 43.14 41.23
>                                4        2,266.29 43.23 42.20
>                                8        4,782.29 72.06 72.21
>
> Proxy_isProxyClassFalse        1           95.02 1.36         1.36
>                                4        2,186.59 1.36         1.36
>                                8        4,891.15 2.72         2.72
>
> Annotation_equals              1          240.10 195.68 194.61
>                                4        1,864.06 201.41 198.81
>                                8        8,639.20 337.46 342.90
>
>
> ... and the most common usage (proxy class implementing exactly one 
> interface) uses even less space than with interface-names-key - 16 
> bytes saved per proxy class vs. 8 bytes saved (32 bit addressing mode):
>
> --------------------------------------
>       Original j.l.r.Proxy
>       1 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       400       400
>        1         1       768       368
>        1         2       920       152
>        1         3      1072       152
>        1         4      1224       152
>        1         5      1376       152
>        1         6      1528       152
>        1         7      1680       152
>        1         8      1832       152
>        2         9      2152       320
>        2        10      2304       152
>        2        11      2456       152
>        2        12      2672       216
>        2        13      2824       152
>        2        14      2976       152
>        2        15      3128       152
>        2        16      3280       152
>
> --------------------------------------
>       Patched j.l.r.Proxy
>       1 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       240       240
>        1         1       792       552
>        1         2       928       136
>        1         3      1064       136
>        1         4      1200       136
>        1         5      1336       136
>        1         6      1472       136
>        1         7      1608       136
>        1         8      1744       136
>        2         9      2088       344
>        2        10      2224       136
>        2        11      2360       136
>        2        12      2560       200
>        2        13      2696       136
>        2        14      2832       136
>        2        15      2968       136
>        2        16      3104       136
>
>
> Did you know, that Proxy.getProxyClass() can generate proxy classes 
> implementing 0 interfaces? It can. There's exactly one such class 
> generated per class loader:
>
>
> --------------------------------------
>       Original j.l.r.Proxy
>       0 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       400       400
>        1         1       760       360
>        2         2      1072       312
>
> --------------------------------------
>       Patched j.l.r.Proxy
>       0 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       240       240
>        1         1       728       488
>        2         2      1040       312
>
>
> With 2 or more interfaces implemented by proxy class the space 
> overhead increases faster than with original Proxy:
>
>
> --------------------------------------
>       Original j.l.r.Proxy
>       2 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       400       400
>        1         1       768       368
>        1         2       920       152
>        1         3      1072       152
>        1         4      1224       152
>        1         5      1376       152
>        1         6      1528       152
>        1         7      1680       152
>        1         8      1832       152
>        2         9      2152       320
>        2        10      2304       152
>        2        11      2456       152
>        2        12      2672       216
>        2        13      2824       152
>        2        14      2976       152
>        2        15      3128       152
>        2        16      3280       152
>
> --------------------------------------
>       Patched j.l.r.Proxy
>       2 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       240       240
>        1         1       832       592
>        1         2      1008       176
>        1         3      1184       176
>        1         4      1360       176
>        1         5      1536       176
>        1         6      1712       176
>        1         7      1888       176
>        1         8      2064       176
>        2         9      2448       384
>        2        10      2624       176
>        2        11      2800       176
>        2        12      3040       240
>        2        13      3216       176
>        2        14      3392       176
>        2        15      3568       176
>        2        16      3744       176
>
> --------------------------------------
>       Original j.l.r.Proxy
>       3 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       400       400
>        1         1       776       376
>        1         2       936       160
>        1         3      1096       160
>        1         4      1256       160
>        1         5      1416       160
>        1         6      1576       160
>        1         7      1736       160
>        1         8      1896       160
>        2         9      2224       328
>        2        10      2384       160
>        2        11      2544       160
>        2        12      2768       224
>        2        13      2928       160
>        2        14      3088       160
>        2        15      3248       160
>        2        16      3408       160
>
> --------------------------------------
>       Patched j.l.r.Proxy
>       3 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       240       240
>        1         1       864       624
>        1         2      1072       208
>        1         3      1280       208
>        1         4      1488       208
>        1         5      1696       208
>        1         6      1904       208
>        1         7      2112       208
>        1         8      2320       208
>        2         9      2736       416
>        2        10      2944       208
>        2        11      3152       208
>        2        12      3424       272
>        2        13      3632       208
>        2        14      3840       208
>        2        15      4048       208
>        2        16      4256       208
>
> --------------------------------------
>       Original j.l.r.Proxy
>       4 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       400       400
>        1         1       776       376
>        1         2       936       160
>        1         3      1096       160
>        1         4      1256       160
>        1         5      1416       160
>        1         6      1576       160
>        1         7      1736       160
>        1         8      1896       160
>        2         9      2224       328
>        2        10      2384       160
>        2        11      2544       160
>        2        12      2768       224
>        2        13      2928       160
>        2        14      3088       160
>        2        15      3248       160
>        2        16      3408       160
>
> --------------------------------------
>       Patched j.l.r.Proxy
>       4 interfaces / proxy class
>
> class     proxy     size of   delta to
> loaders   classes   caches    prev.ln.
> --------  --------  --------  --------
>        0         0       240       240
>        1         1       896       656
>        1         2      1136       240
>        1         3      1376       240
>        1         4      1616       240
>        1         5      1856       240
>        1         6      2096       240
>        1         7      2336       240
>        1         8      2576       240
>        2         9      3024       448
>        2        10      3264       240
>        2        11      3504       240
>        2        12      3808       304
>        2        13      4048       240
>        2        14      4288       240
>        2        15      4528       240
>        2        16      4768       240
>
>
> There's an increase of 8 bytes per proxy class key for each 2 
> interfaces added to proxy class in original Proxy code, but there's an 
> increase of 32 bytes per proxy class key for each single interface 
> added in patched Proxy code.
>
> I think the most common usage is to implement a single interface and 
> there is 16 bytes gained for each such usage compared to original 
> Proxy code.
>
>> 2. I did some cleanup to restore some original comments to make the 
>> diffs clearer where the change is.
>> 3. I removed the newInstance method which is dead code after my 
>> previous code.  Since we are in this code, I took the chance to clean 
>> that up and also change a couple for-loop to use for-each.
>>
>> I have put the merged and slightly modified Proxy.java and webrev at:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/
>>
>> We will use this bug for your contribution:
>>    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
>
> I took j.l.r.Proxy file from your webrev and just changed the 
> KeyFactory implementation. WeakCache is generic and can be used 
> unchanged with either implementation of KeyFactory.
>
>>
>> For the weak cache class, since it's for proxy implementation use, I 
>> suggest to take out the supportContainsValueOperation flagas it 
>> always keeps the reverse map for isProxyClass lookup.
>>
>> You can simply call Objects.requireNonNull(param) instead of 
>> requireNonNull(param, "param-name") since the proxy implementation 
>> should have made sure the argument is non-null.
>>
>> Formatting nits:
>>
>>   68         Object cacheKey = CacheKey.valueOf(
>>   69             key,
>>   70             refQueue
>>   71         );
>>
>> should be: all in one line or line break on a long-line.  Same for
>> method signature.
>>
>>  237         void expungeFrom(
>>  238             ConcurrentMap> map,
>>  239             ConcurrentMap reverseMap
>>  240         );
>>
>> should be:
>>
>> void expungeFrom(ConcurrentMap> map,
>>                  ConcurrentMap reverseMap);
>>
>> so that it'll be more consistent with the existing code.  I'll do a
>> detailed review on the weak cache class as you will finalize the code
>> per the decision to go with the two-level weak cache.
>
> I hope I have addressed all that in above webrev.
>
> Regards, Peter
>
>>
>> Thanks again for the good work.
>>
>> Mandy
>> [1] http://openjdk.java.net/jeps/161 
>



From peter.levart at gmail.com  Sat Apr 20 16:37:18 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 Apr 2013 18:37:18 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51724434.10107@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com>
Message-ID: <5172C43E.8070907@gmail.com>

On 04/20/2013 09:31 AM, Peter Levart wrote:
> Hi Mandy,
>
> I have another idea. Before jumping to implement it, I will first ask 
> what do you think of it. For example:
>
> - have an optimal interface names key calculated from interfaces.
> - visibility of interfaces and other validations are pushed to 
> slow-path (inside ProxyClassFactory.apply)
> - the proxy Class object returned from WeakCache.get() is 
> post-validated with a check like:
>
> for (Class intf : interfaces) {
>     if (!intf.isAssignableFrom(proxyClass)) {
>         throw new IllegalArgumentException();
>     }
> }
> // return post-validated proxyClass from getProxyClass0()...

I just did it:

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.03/index.html

I also incorporated the expunging optimization that I talked about in 
one of previous mails.

And the keys, composed of interface names, are now more space-friendly too:
- a key for 0 interface proxy is a singleton Object
- a key for 1 interface proxy is the name of the interface itself (an 
already interned String)
- a key for 2 interface proxy is a special class with 2 references to 
interned Strings
- a key for 3+ interface proxy is a special class wrapping an array of 
interned Strings

The performance is screaming again (WeakCache+post-validation):


                                         ns/op   WeakCache+ WeakCache+
Test                     Threads     Original   pre-valid. post-valid.
=======================  =======  ===========  =========== ===========
Proxy_getProxyClass            1     2,420.99 2,258.00       211.04
                                4     3,075.39 2,644.26       282.93
                                8     5,374.45 5,159.71       432.14

Proxy_isProxyClassTrue         1        97.75 45.37        42.67
                                4     2,505.92 42.59        42.77
                                8     5,042.61 75.44        73.20

Proxy_isProxyClassFalse        1        89.20 1.40         1.40
                                4     2,548.61 1.40         1.40
                                8     4,901.56 2.82         2.80

Annotation_equals              1       224.39 201.82       202.97
                                4     2,046.21 200.61       204.89
                                8     3,564.78 347.27       344.57


And the space savings are now even greater. Patched code is always 
better space-wise. The savings are:

32 bit addressing:

- 56 bytes per proxy class implementing 1 interface
- 32 bytes per proxy class implementing 2 interfaces
- 16 bytes per proxy class implementing 3 or more interfaces

64 bit addressing:

- 80 bytes per proxy class implementing 1 interface
- 56 bytes per proxy class implementing 2 interfaces
- 24 bytes per proxy class implementing 3 or more interfaces


Regards, Peter


P.S. Details:

32 bit addressing:


    ** Original j.l.r.Proxy
    ** 0 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       760       360
        2         9      1072       312
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 1 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       768       368
        1         2       920       152
        1         3      1072       152
        1         4      1224       152
        1         5      1376       152
        1         6      1528       152
        1         7      1680       152
        1         8      1832       152
        2         9      2152       320
        2        10      2304       152
        2        11      2456       152
        2        12      2672       216
        2        13      2824       152
        2        14      2976       152
        2        15      3128       152
        2        16      3280       152
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 2 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       768       368
        1         2       920       152
        1         3      1072       152
        1         4      1224       152
        1         5      1376       152
        1         6      1528       152
        1         7      1680       152
        1         8      1832       152
        2         9      2152       320
        2        10      2304       152
        2        11      2456       152
        2        12      2672       216
        2        13      2824       152
        2        14      2976       152
        2        15      3128       152
        2        16      3280       152
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 3 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       776       376
        1         2       936       160
        1         3      1096       160
        1         4      1256       160
        1         5      1416       160
        1         6      1576       160
        1         7      1736       160
        1         8      1896       160
        2         9      2224       328
        2        10      2384       160
        2        11      2544       160
        2        12      2768       224
        2        13      2928       160
        2        14      3088       160
        2        15      3248       160
        2        16      3408       160
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 4 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       400       400
        1         1       776       376
        1         2       936       160
        1         3      1096       160
        1         4      1256       160
        1         5      1416       160
        1         6      1576       160
        1         7      1736       160
        1         8      1896       160
        2         9      2224       328
        2        10      2384       160
        2        11      2544       160
        2        12      2768       224
        2        13      2928       160
        2        14      3088       160
        2        15      3248       160
        2        16      3408       160
--------  --------  --------  --------


    ** Patched j.l.r.Proxy
    ** 0 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       768       528
        2         9      1072       304
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 1 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       752       512
        1         2       848        96
        1         3       944        96
        1         4      1040        96
        1         5      1136        96
        1         6      1232        96
        1         7      1328        96
        1         8      1424        96
        2         9      1728       304
        2        10      1824        96
        2        11      1920        96
        2        12      2080       160
        2        13      2176        96
        2        14      2272        96
        2        15      2368        96
        2        16      2464        96
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 2 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       776       536
        1         2       896       120
        1         3      1016       120
        1         4      1136       120
        1         5      1256       120
        1         6      1376       120
        1         7      1496       120
        1         8      1616       120
        2         9      1944       328
        2        10      2064       120
        2        11      2184       120
        2        12      2368       184
        2        13      2488       120
        2        14      2608       120
        2        15      2728       120
        2        16      2848       120
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 3 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       800       560
        1         2       944       144
        1         3      1088       144
        1         4      1232       144
        1         5      1376       144
        1         6      1520       144
        1         7      1664       144
        1         8      1808       144
        2         9      2160       352
        2        10      2304       144
        2        11      2448       144
        2        12      2656       208
        2        13      2800       144
        2        14      2944       144
        2        15      3088       144
        2        16      3232       144
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 4 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       240       240
        1         1       800       560
        1         2       944       144
        1         3      1088       144
        1         4      1232       144
        1         5      1376       144
        1         6      1520       144
        1         7      1664       144
        1         8      1808       144
        2         9      2160       352
        2        10      2304       144
        2        11      2448       144
        2        12      2656       208
        2        13      2800       144
        2        14      2944       144
        2        15      3088       144
        2        16      3232       144
--------  --------  --------  --------


64 bit addressing:


    ** Original j.l.r.Proxy
    ** 0 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       632       632
        1         1      1208       576
        2         9      1728       520
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 1 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       632       632
        1         1      1216       584
        1         2      1448       232
        1         3      1680       232
        1         4      1912       232
        1         5      2144       232
        1         6      2376       232
        1         7      2608       232
        1         8      2840       232
        2         9      3368       528
        2        10      3600       232
        2        11      3832       232
        2        12      4192       360
        2        13      4424       232
        2        14      4656       232
        2        15      4888       232
        2        16      5120       232
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 2 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       632       632
        1         1      1224       592
        1         2      1464       240
        1         3      1704       240
        1         4      1944       240
        1         5      2184       240
        1         6      2424       240
        1         7      2664       240
        1         8      2904       240
        2         9      3440       536
        2        10      3680       240
        2        11      3920       240
        2        12      4288       368
        2        13      4528       240
        2        14      4768       240
        2        15      5008       240
        2        16      5248       240
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 3 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       632       632
        1         1      1232       600
        1         2      1480       248
        1         3      1728       248
        1         4      1976       248
        1         5      2224       248
        1         6      2472       248
        1         7      2720       248
        1         8      2968       248
        2         9      3512       544
        2        10      3760       248
        2        11      4008       248
        2        12      4384       376
        2        13      4632       248
        2        14      4880       248
        2        15      5128       248
        2        16      5376       248
--------  --------  --------  --------

    ** Original j.l.r.Proxy
    ** 4 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       632       632
        1         1      1240       608
        1         2      1496       256
        1         3      1752       256
        1         4      2008       256
        1         5      2264       256
        1         6      2520       256
        1         7      2776       256
        1         8      3032       256
        2         9      3584       552
        2        10      3840       256
        2        11      4096       256
        2        12      4480       384
        2        13      4736       256
        2        14      4992       256
        2        15      5248       256
        2        16      5504       256
--------  --------  --------  --------


    ** Patched j.l.r.Proxy
    ** 0 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       336       336
        1         1      1216       880
        2         9      1720       504
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 1 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       336       336
        1         1      1200       864
        1         2      1352       152
        1         3      1504       152
        1         4      1656       152
        1         5      1808       152
        1         6      1960       152
        1         7      2112       152
        1         8      2264       152
        2         9      2768       504
        2        10      2920       152
        2        11      3072       152
        2        12      3352       280
        2        13      3504       152
        2        14      3656       152
        2        15      3808       152
        2        16      3960       152
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 2 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       336       336
        1         1      1232       896
        1         2      1416       184
        1         3      1600       184
        1         4      1784       184
        1         5      1968       184
        1         6      2152       184
        1         7      2336       184
        1         8      2520       184
        2         9      3056       536
        2        10      3240       184
        2        11      3424       184
        2        12      3736       312
        2        13      3920       184
        2        14      4104       184
        2        15      4288       184
        2        16      4472       184
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 3 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       336       336
        1         1      1272       936
        1         2      1496       224
        1         3      1720       224
        1         4      1944       224
        1         5      2168       224
        1         6      2392       224
        1         7      2616       224
        1         8      2840       224
        2         9      3416       576
        2        10      3640       224
        2        11      3864       224
        2        12      4216       352
        2        13      4440       224
        2        14      4664       224
        2        15      4888       224
        2        16      5112       224
--------  --------  --------  --------

    ** Patched j.l.r.Proxy
    ** 4 interfaces / proxy class

    class     proxy   size of  delta to
  loaders   classes    caches  prev.ln.
--------  --------  --------  --------
        0         0       336       336
        1         1      1280       944
        1         2      1512       232
        1         3      1744       232
        1         4      1976       232
        1         5      2208       232
        1         6      2440       232
        1         7      2672       232
        1         8      2904       232
        2         9      3488       584
        2        10      3720       232
        2        11      3952       232
        2        12      4312       360
        2        13      4544       232
        2        14      4776       232
        2        15      5008       232
        2        16      5240       232
--------  --------  --------  --------


On 04/20/2013 09:31 AM, Peter Levart wrote:
> Hi Mandy,
>
> I have another idea. Before jumping to implement it, I will first ask 
> what do you think of it. For example:
>
> - have an optimal interface names key calculated from interfaces.
> - visibility of interfaces and other validations are pushed to 
> slow-path (inside ProxyClassFactory.apply)
> - the proxy Class object returned from WeakCache.get() is 
> post-validated with a check like:
>
> for (Class intf : interfaces) {
>     if (!intf.isAssignableFrom(proxyClass)) {
>         throw new IllegalArgumentException();
>     }
> }
> // return post-validated proxyClass from getProxyClass0()...
>
> I feel that Class.isAssignableFrom(Class) check could be much faster 
> and that the only reason the check can fail is if some interface is 
> not visible from the class loader.
>
> Am I correct?
>
> Regards, Peter
>
>
>
> On 04/19/2013 04:36 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> On 04/19/2013 07:33 AM, Mandy Chung wrote:
>>>>
>>>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html 
>>>>
>>>> What about package-private in java.lang.reflect? It makes Proxy 
>>>> itself much easier to read. When we decide which way to go, I can 
>>>> remove the interface and only leave a single package-private class...
>>>>
>>>
>>> thanks.  Moving it to a single package-private classin 
>>> java.lang.reflectand remove the interface sounds good.
>>
>> Right.
>>
>>>
>>> I have merged your patch with the recent TL repo and did some clean 
>>> up while reviewing it.  Some comments:
>>> 1. getProxyClass0 should validate the input interfaces and throw IAE 
>>> if any illegal argument (e.g. interfaces are not visible to the 
>>> given loader) before calling proxyClassCache.get(loader, 
>>> interfaces). I moved back the validation code from 
>>> ProxyClassFactory.apply to getProxyClass0.
>>
>> Ops, you're right. There could be a request with interface(s) with 
>> same name(s) but loaded by different loader(s) and such code could 
>> return wrong pre-cached proxy class instead of throwing exception. 
>> Unfortunately, moving validation to slow-path was the cause of major 
>> performance and scalability improvement observed. With validation 
>> moved back to getProxyClass0 (in spite of using two-level WeakCache), 
>> we have the following performance (WeakCache#1):
>>
>>
>> Summary (4 Cores x 2 Threads i7 CPU):
>>
>> Test                     Threads  ns/op Original WeakCache#1
>> =======================  =======  ============== ===========
>> Proxy_getProxyClass            1        2,403.27 2,174.51
>>                                4        3,039.01 2,555.00
>>                                8        5,193.58 4,273.42
>>
>> Proxy_isProxyClassTrue         1           95.02 43.14
>>                                4        2,266.29 43.23
>>                                8        4,782.29 72.06
>>
>> Proxy_isProxyClassFalse        1           95.02 1.36
>>                                4        2,186.59 1.36
>>                                8        4,891.15 2.72
>>
>> Annotation_equals              1          240.10 195.68
>>                                4        1,864.06 201.41
>>                                8        8,639.20 337.46
>>
>> It's a little better than original getProxyClass(), but not much. The 
>> isProxyClass() and consequently Annotation.equals() are far better 
>> though. But as you might have guessed, I kind of solved that too...
>>
>> My first attempt was to optimize the interface validation. Only the 
>> "visibility" part is necessary to be performed on fast-path. 
>> Uniqueness and other things can be performed on slow-path. With 
>> split-validation and hacks like:
>>
>>     private static final MethodHandle findLoadedClass0MH, 
>> findBootstrapClassMH;
>>     private static final ClassLoader dummyCL = new ClassLoader() {};
>>
>>     static {
>>         try {
>>             Method method = 
>> ClassLoader.class.getDeclaredMethod("findLoadedClass0", String.class);
>>             method.setAccessible(true);
>>             findLoadedClass0MH = 
>> MethodHandles.lookup().unreflect(method);
>>
>>             method = 
>> ClassLoader.class.getDeclaredMethod("findBootstrapClass", String.class);
>>             method.setAccessible(true);
>>             findBootstrapClassMH = 
>> MethodHandles.lookup().unreflect(method);
>>         } catch (NoSuchMethodException e) {
>>             throw (Error) new 
>> NoSuchMethodError(e.getMessage()).initCause(e);
>>         } catch (IllegalAccessException e) {
>>             throw (Error) new 
>> IllegalAccessError(e.getMessage()).initCause(e);
>>         }
>>     }
>>
>>     static Class findLoadedClass(ClassLoader loader, String name) {
>>         try {
>>             if (VM.isSystemDomainLoader(loader)) {
>>                 return (Class) 
>> findBootstrapClassMH.invokeExact(dummyCL, name);
>>             } else {
>>                 return (Class) 
>> findLoadedClass0MH.invokeExact(loader, name);
>>             }
>>         } catch (RuntimeException | Error e) {
>>             throw e;
>>         } catch (Throwable t) {
>>             throw new UndeclaredThrowableException(t);
>>         }
>>     }
>>
>>
>> ... using findLoadedClass(loader, intf.getName()) and only doing 
>> Class.forName(intf.getName(), false, loader) if the former returned 
>> null ... I managed to reclaim some performance (WeakCache#1+):
>>
>>
>> Test                     Threads  ns/op Original  WeakCache#1 
>> WeakCache#1+
>> =======================  =======  ============== =========== 
>> ============
>> Proxy_getProxyClass            1        2,403.27 2,174.51 1,589.36
>>                                4        3,039.01 2,555.00 1,929.11
>>                                8        5,193.58 4,273.42 3,409.77
>>
>>
>> ...but that was still not very satisfactory.
>>
>> I modified the KeyFactory to create keys that weakly-reference 
>> interface Class objects and implement hashCode/equals in terms of 
>> comparing those Class objects. With such keys, no false aliasing can 
>> occur and the whole validation can be pushed back to slow-path. I 
>> tried hard to create keys with as little space overhead as possible:
>>
>> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>>
>>
>> ...but there can be no miracles. The good news is that the 
>> performance is back (WeakCache#2):
>>
>>
>> Summary (4 Cores x 2 Threads i7 CPU):
>>
>> Test                     Threads  ns/op Original WeakCache#1 WeakCache#2
>> =======================  =======  ============== =========== ===========
>> Proxy_getProxyClass            1        2,403.27 2,174.51 163.57
>>                                4        3,039.01 2,555.00 211.70
>>                                8        5,193.58 4,273.42 322.14
>>
>> Proxy_isProxyClassTrue         1           95.02 43.14 41.23
>>                                4        2,266.29 43.23 42.20
>>                                8        4,782.29 72.06 72.21
>>
>> Proxy_isProxyClassFalse        1           95.02 1.36 1.36
>>                                4        2,186.59 1.36 1.36
>>                                8        4,891.15 2.72 2.72
>>
>> Annotation_equals              1          240.10 195.68 194.61
>>                                4        1,864.06 201.41 198.81
>>                                8        8,639.20 337.46 342.90
>>
>>
>> ... and the most common usage (proxy class implementing exactly one 
>> interface) uses even less space than with interface-names-key - 16 
>> bytes saved per proxy class vs. 8 bytes saved (32 bit addressing mode):
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       1 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       768       368
>>        1         2       920       152
>>        1         3      1072       152
>>        1         4      1224       152
>>        1         5      1376       152
>>        1         6      1528       152
>>        1         7      1680       152
>>        1         8      1832       152
>>        2         9      2152       320
>>        2        10      2304       152
>>        2        11      2456       152
>>        2        12      2672       216
>>        2        13      2824       152
>>        2        14      2976       152
>>        2        15      3128       152
>>        2        16      3280       152
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       1 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       792       552
>>        1         2       928       136
>>        1         3      1064       136
>>        1         4      1200       136
>>        1         5      1336       136
>>        1         6      1472       136
>>        1         7      1608       136
>>        1         8      1744       136
>>        2         9      2088       344
>>        2        10      2224       136
>>        2        11      2360       136
>>        2        12      2560       200
>>        2        13      2696       136
>>        2        14      2832       136
>>        2        15      2968       136
>>        2        16      3104       136
>>
>>
>> Did you know, that Proxy.getProxyClass() can generate proxy classes 
>> implementing 0 interfaces? It can. There's exactly one such class 
>> generated per class loader:
>>
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       0 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       760       360
>>        2         2      1072       312
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       0 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       728       488
>>        2         2      1040       312
>>
>>
>> With 2 or more interfaces implemented by proxy class the space 
>> overhead increases faster than with original Proxy:
>>
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       2 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       768       368
>>        1         2       920       152
>>        1         3      1072       152
>>        1         4      1224       152
>>        1         5      1376       152
>>        1         6      1528       152
>>        1         7      1680       152
>>        1         8      1832       152
>>        2         9      2152       320
>>        2        10      2304       152
>>        2        11      2456       152
>>        2        12      2672       216
>>        2        13      2824       152
>>        2        14      2976       152
>>        2        15      3128       152
>>        2        16      3280       152
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       2 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       832       592
>>        1         2      1008       176
>>        1         3      1184       176
>>        1         4      1360       176
>>        1         5      1536       176
>>        1         6      1712       176
>>        1         7      1888       176
>>        1         8      2064       176
>>        2         9      2448       384
>>        2        10      2624       176
>>        2        11      2800       176
>>        2        12      3040       240
>>        2        13      3216       176
>>        2        14      3392       176
>>        2        15      3568       176
>>        2        16      3744       176
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       3 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       776       376
>>        1         2       936       160
>>        1         3      1096       160
>>        1         4      1256       160
>>        1         5      1416       160
>>        1         6      1576       160
>>        1         7      1736       160
>>        1         8      1896       160
>>        2         9      2224       328
>>        2        10      2384       160
>>        2        11      2544       160
>>        2        12      2768       224
>>        2        13      2928       160
>>        2        14      3088       160
>>        2        15      3248       160
>>        2        16      3408       160
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       3 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       864       624
>>        1         2      1072       208
>>        1         3      1280       208
>>        1         4      1488       208
>>        1         5      1696       208
>>        1         6      1904       208
>>        1         7      2112       208
>>        1         8      2320       208
>>        2         9      2736       416
>>        2        10      2944       208
>>        2        11      3152       208
>>        2        12      3424       272
>>        2        13      3632       208
>>        2        14      3840       208
>>        2        15      4048       208
>>        2        16      4256       208
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       4 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       776       376
>>        1         2       936       160
>>        1         3      1096       160
>>        1         4      1256       160
>>        1         5      1416       160
>>        1         6      1576       160
>>        1         7      1736       160
>>        1         8      1896       160
>>        2         9      2224       328
>>        2        10      2384       160
>>        2        11      2544       160
>>        2        12      2768       224
>>        2        13      2928       160
>>        2        14      3088       160
>>        2        15      3248       160
>>        2        16      3408       160
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       4 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       896       656
>>        1         2      1136       240
>>        1         3      1376       240
>>        1         4      1616       240
>>        1         5      1856       240
>>        1         6      2096       240
>>        1         7      2336       240
>>        1         8      2576       240
>>        2         9      3024       448
>>        2        10      3264       240
>>        2        11      3504       240
>>        2        12      3808       304
>>        2        13      4048       240
>>        2        14      4288       240
>>        2        15      4528       240
>>        2        16      4768       240
>>
>>
>> There's an increase of 8 bytes per proxy class key for each 2 
>> interfaces added to proxy class in original Proxy code, but there's 
>> an increase of 32 bytes per proxy class key for each single interface 
>> added in patched Proxy code.
>>
>> I think the most common usage is to implement a single interface and 
>> there is 16 bytes gained for each such usage compared to original 
>> Proxy code.
>>
>>> 2. I did some cleanup to restore some original comments to make the 
>>> diffs clearer where the change is.
>>> 3. I removed the newInstance method which is dead code after my 
>>> previous code.  Since we are in this code, I took the chance to 
>>> clean that up and also change a couple for-loop to use for-each.
>>>
>>> I have put the merged and slightly modified Proxy.java and webrev at:
>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/
>>>
>>> We will use this bug for your contribution:
>>>    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
>>
>> I took j.l.r.Proxy file from your webrev and just changed the 
>> KeyFactory implementation. WeakCache is generic and can be used 
>> unchanged with either implementation of KeyFactory.
>>
>>>
>>> For the weak cache class, since it's for proxy implementation use, I 
>>> suggest to take out the supportContainsValueOperation flagas it 
>>> always keeps the reverse map for isProxyClass lookup.
>>>
>>> You can simply call Objects.requireNonNull(param) instead of 
>>> requireNonNull(param, "param-name") since the proxy implementation 
>>> should have made sure the argument is non-null.
>>>
>>> Formatting nits:
>>>
>>>   68         Object cacheKey = CacheKey.valueOf(
>>>   69             key,
>>>   70             refQueue
>>>   71         );
>>>
>>> should be: all in one line or line break on a long-line.  Same for
>>> method signature.
>>>
>>>  237         void expungeFrom(
>>>  238             ConcurrentMap> map,
>>>  239             ConcurrentMap reverseMap
>>>  240         );
>>>
>>> should be:
>>>
>>> void expungeFrom(ConcurrentMap> map,
>>>                  ConcurrentMap reverseMap);
>>>
>>> so that it'll be more consistent with the existing code.  I'll do a
>>> detailed review on the weak cache class as you will finalize the code
>>> per the decision to go with the two-level weak cache.
>>
>> I hope I have addressed all that in above webrev.
>>
>> Regards, Peter
>>
>>>
>>> Thanks again for the good work.
>>>
>>> Mandy
>>> [1] http://openjdk.java.net/jeps/161 
>>
>



From Ulf.Zibis at CoSoCo.de  Sat Apr 20 20:42:24 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sat, 20 Apr 2013 22:42:24 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5171DA7F.1070105@oracle.com>
References: <5171DA7F.1070105@oracle.com>
Message-ID: <5172FDB0.2050707@CoSoCo.de>

Am 20.04.2013 01:59, schrieb Akhil Arora:
> Please review the addition of optimized defaults for Iterator's forEachRemaining to ArrayList, 
> LinkedList, Vector and CopyOnWriteArrayList. The unit test has a performance comparison test 
> (disabled by default) that measures the difference between this method and hasNext()/next(). 
> Significant improvements were measured by overriding the default forEachRemaining by these classes 
> (others, not so much).
>
> http://cr.openjdk.java.net/~akhil/8005051.1/webrev/

You mostly do not need ".this.", e.g. in Vector:
Compare lines 1160 <-> 1137
Line 1165 could be:
     final Object[] elementData = this.elementData;
or simply
     final Object[] elements = elementData;

To be in line with old habits, please remove space after casts. See also: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278

For performance reasons it could be considered to make Itr final and copy its methods to ListItr.

Interesting: I ever thought, private members are always final, but here a private method becomes 
extended.

-Ulf



From mike.duigou at oracle.com  Sun Apr 21 00:05:42 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 20 Apr 2013 17:05:42 -0700
Subject: RFR : 8008682 : Core lambda Streams API
Message-ID: <73F3A6AC-1920-45ED-AC7C-64FA8AD8B7AA@oracle.com>

Hello all;

This the is big one! This changeset is the core API of the parallel bulk-data streams feature.

http://cr.openjdk.java.net/~mduigou/JDK-8008682/0/webrev/

While the APIs and method documentation are complete you will likely notice TODO, FIXME and other notes in the package documentation, and to a lesser extent the class documentation. These will be corrected in future updates and aren't expected to change any normative aspects of the API. (No doubt there will also be doc and code bugs to fix as well).

Mike

From mandy.chung at oracle.com  Sun Apr 21 02:52:58 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 20 Apr 2013 19:52:58 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51724434.10107@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com>
Message-ID: <5173548A.5010107@oracle.com>

Hi Peter,

I want to give it some more thought and discuss with you next week. As 
for the zero number of interface, I think it's a bug and it should throw 
IAE if the given interfaces array is empty.   Thanks for finding it and 
I'll file a separate bug for that since it requires spec 
update/clarification.

Mandy

On 4/20/2013 12:31 AM, Peter Levart wrote:
> Hi Mandy,
>
> I have another idea. Before jumping to implement it, I will first ask 
> what do you think of it. For example:
>
> - have an optimal interface names key calculated from interfaces.
> - visibility of interfaces and other validations are pushed to 
> slow-path (inside ProxyClassFactory.apply)
> - the proxy Class object returned from WeakCache.get() is 
> post-validated with a check like:
>
> for (Class intf : interfaces) {
>     if (!intf.isAssignableFrom(proxyClass)) {
>         throw new IllegalArgumentException();
>     }
> }
> // return post-validated proxyClass from getProxyClass0()...
>
> I feel that Class.isAssignableFrom(Class) check could be much faster 
> and that the only reason the check can fail is if some interface is 
> not visible from the class loader.
>
> Am I correct?
>
> Regards, Peter
>
>
>
> On 04/19/2013 04:36 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> On 04/19/2013 07:33 AM, Mandy Chung wrote:
>>>>
>>>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html 
>>>>
>>>> What about package-private in java.lang.reflect? It makes Proxy 
>>>> itself much easier to read. When we decide which way to go, I can 
>>>> remove the interface and only leave a single package-private class...
>>>>
>>>
>>> thanks.  Moving it to a single package-private classin 
>>> java.lang.reflectand remove the interface sounds good.
>>
>> Right.
>>
>>>
>>> I have merged your patch with the recent TL repo and did some clean 
>>> up while reviewing it.  Some comments:
>>> 1. getProxyClass0 should validate the input interfaces and throw IAE 
>>> if any illegal argument (e.g. interfaces are not visible to the 
>>> given loader) before calling proxyClassCache.get(loader, 
>>> interfaces). I moved back the validation code from 
>>> ProxyClassFactory.apply to getProxyClass0.
>>
>> Ops, you're right. There could be a request with interface(s) with 
>> same name(s) but loaded by different loader(s) and such code could 
>> return wrong pre-cached proxy class instead of throwing exception. 
>> Unfortunately, moving validation to slow-path was the cause of major 
>> performance and scalability improvement observed. With validation 
>> moved back to getProxyClass0 (in spite of using two-level WeakCache), 
>> we have the following performance (WeakCache#1):
>>
>>
>> Summary (4 Cores x 2 Threads i7 CPU):
>>
>> Test                     Threads  ns/op Original WeakCache#1
>> =======================  =======  ============== ===========
>> Proxy_getProxyClass            1        2,403.27 2,174.51
>>                                4        3,039.01 2,555.00
>>                                8        5,193.58 4,273.42
>>
>> Proxy_isProxyClassTrue         1           95.02 43.14
>>                                4        2,266.29 43.23
>>                                8        4,782.29 72.06
>>
>> Proxy_isProxyClassFalse        1           95.02 1.36
>>                                4        2,186.59 1.36
>>                                8        4,891.15 2.72
>>
>> Annotation_equals              1          240.10 195.68
>>                                4        1,864.06 201.41
>>                                8        8,639.20 337.46
>>
>> It's a little better than original getProxyClass(), but not much. The 
>> isProxyClass() and consequently Annotation.equals() are far better 
>> though. But as you might have guessed, I kind of solved that too...
>>
>> My first attempt was to optimize the interface validation. Only the 
>> "visibility" part is necessary to be performed on fast-path. 
>> Uniqueness and other things can be performed on slow-path. With 
>> split-validation and hacks like:
>>
>>     private static final MethodHandle findLoadedClass0MH, 
>> findBootstrapClassMH;
>>     private static final ClassLoader dummyCL = new ClassLoader() {};
>>
>>     static {
>>         try {
>>             Method method = 
>> ClassLoader.class.getDeclaredMethod("findLoadedClass0", String.class);
>>             method.setAccessible(true);
>>             findLoadedClass0MH = 
>> MethodHandles.lookup().unreflect(method);
>>
>>             method = 
>> ClassLoader.class.getDeclaredMethod("findBootstrapClass", String.class);
>>             method.setAccessible(true);
>>             findBootstrapClassMH = 
>> MethodHandles.lookup().unreflect(method);
>>         } catch (NoSuchMethodException e) {
>>             throw (Error) new 
>> NoSuchMethodError(e.getMessage()).initCause(e);
>>         } catch (IllegalAccessException e) {
>>             throw (Error) new 
>> IllegalAccessError(e.getMessage()).initCause(e);
>>         }
>>     }
>>
>>     static Class findLoadedClass(ClassLoader loader, String name) {
>>         try {
>>             if (VM.isSystemDomainLoader(loader)) {
>>                 return (Class) 
>> findBootstrapClassMH.invokeExact(dummyCL, name);
>>             } else {
>>                 return (Class) 
>> findLoadedClass0MH.invokeExact(loader, name);
>>             }
>>         } catch (RuntimeException | Error e) {
>>             throw e;
>>         } catch (Throwable t) {
>>             throw new UndeclaredThrowableException(t);
>>         }
>>     }
>>
>>
>> ... using findLoadedClass(loader, intf.getName()) and only doing 
>> Class.forName(intf.getName(), false, loader) if the former returned 
>> null ... I managed to reclaim some performance (WeakCache#1+):
>>
>>
>> Test                     Threads  ns/op Original  WeakCache#1 
>> WeakCache#1+
>> =======================  =======  ============== =========== 
>> ============
>> Proxy_getProxyClass            1        2,403.27 2,174.51 1,589.36
>>                                4        3,039.01 2,555.00 1,929.11
>>                                8        5,193.58 4,273.42 3,409.77
>>
>>
>> ...but that was still not very satisfactory.
>>
>> I modified the KeyFactory to create keys that weakly-reference 
>> interface Class objects and implement hashCode/equals in terms of 
>> comparing those Class objects. With such keys, no false aliasing can 
>> occur and the whole validation can be pushed back to slow-path. I 
>> tried hard to create keys with as little space overhead as possible:
>>
>> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>>
>>
>> ...but there can be no miracles. The good news is that the 
>> performance is back (WeakCache#2):
>>
>>
>> Summary (4 Cores x 2 Threads i7 CPU):
>>
>> Test                     Threads  ns/op Original WeakCache#1 WeakCache#2
>> =======================  =======  ============== =========== ===========
>> Proxy_getProxyClass            1        2,403.27 2,174.51 163.57
>>                                4        3,039.01 2,555.00 211.70
>>                                8        5,193.58 4,273.42 322.14
>>
>> Proxy_isProxyClassTrue         1           95.02 43.14 41.23
>>                                4        2,266.29 43.23 42.20
>>                                8        4,782.29 72.06 72.21
>>
>> Proxy_isProxyClassFalse        1           95.02 1.36 1.36
>>                                4        2,186.59 1.36 1.36
>>                                8        4,891.15 2.72 2.72
>>
>> Annotation_equals              1          240.10 195.68 194.61
>>                                4        1,864.06 201.41 198.81
>>                                8        8,639.20 337.46 342.90
>>
>>
>> ... and the most common usage (proxy class implementing exactly one 
>> interface) uses even less space than with interface-names-key - 16 
>> bytes saved per proxy class vs. 8 bytes saved (32 bit addressing mode):
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       1 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       768       368
>>        1         2       920       152
>>        1         3      1072       152
>>        1         4      1224       152
>>        1         5      1376       152
>>        1         6      1528       152
>>        1         7      1680       152
>>        1         8      1832       152
>>        2         9      2152       320
>>        2        10      2304       152
>>        2        11      2456       152
>>        2        12      2672       216
>>        2        13      2824       152
>>        2        14      2976       152
>>        2        15      3128       152
>>        2        16      3280       152
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       1 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       792       552
>>        1         2       928       136
>>        1         3      1064       136
>>        1         4      1200       136
>>        1         5      1336       136
>>        1         6      1472       136
>>        1         7      1608       136
>>        1         8      1744       136
>>        2         9      2088       344
>>        2        10      2224       136
>>        2        11      2360       136
>>        2        12      2560       200
>>        2        13      2696       136
>>        2        14      2832       136
>>        2        15      2968       136
>>        2        16      3104       136
>>
>>
>> Did you know, that Proxy.getProxyClass() can generate proxy classes 
>> implementing 0 interfaces? It can. There's exactly one such class 
>> generated per class loader:
>>
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       0 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       760       360
>>        2         2      1072       312
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       0 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       728       488
>>        2         2      1040       312
>>
>>
>> With 2 or more interfaces implemented by proxy class the space 
>> overhead increases faster than with original Proxy:
>>
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       2 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       768       368
>>        1         2       920       152
>>        1         3      1072       152
>>        1         4      1224       152
>>        1         5      1376       152
>>        1         6      1528       152
>>        1         7      1680       152
>>        1         8      1832       152
>>        2         9      2152       320
>>        2        10      2304       152
>>        2        11      2456       152
>>        2        12      2672       216
>>        2        13      2824       152
>>        2        14      2976       152
>>        2        15      3128       152
>>        2        16      3280       152
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       2 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       832       592
>>        1         2      1008       176
>>        1         3      1184       176
>>        1         4      1360       176
>>        1         5      1536       176
>>        1         6      1712       176
>>        1         7      1888       176
>>        1         8      2064       176
>>        2         9      2448       384
>>        2        10      2624       176
>>        2        11      2800       176
>>        2        12      3040       240
>>        2        13      3216       176
>>        2        14      3392       176
>>        2        15      3568       176
>>        2        16      3744       176
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       3 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       776       376
>>        1         2       936       160
>>        1         3      1096       160
>>        1         4      1256       160
>>        1         5      1416       160
>>        1         6      1576       160
>>        1         7      1736       160
>>        1         8      1896       160
>>        2         9      2224       328
>>        2        10      2384       160
>>        2        11      2544       160
>>        2        12      2768       224
>>        2        13      2928       160
>>        2        14      3088       160
>>        2        15      3248       160
>>        2        16      3408       160
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       3 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       864       624
>>        1         2      1072       208
>>        1         3      1280       208
>>        1         4      1488       208
>>        1         5      1696       208
>>        1         6      1904       208
>>        1         7      2112       208
>>        1         8      2320       208
>>        2         9      2736       416
>>        2        10      2944       208
>>        2        11      3152       208
>>        2        12      3424       272
>>        2        13      3632       208
>>        2        14      3840       208
>>        2        15      4048       208
>>        2        16      4256       208
>>
>> --------------------------------------
>>       Original j.l.r.Proxy
>>       4 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       400       400
>>        1         1       776       376
>>        1         2       936       160
>>        1         3      1096       160
>>        1         4      1256       160
>>        1         5      1416       160
>>        1         6      1576       160
>>        1         7      1736       160
>>        1         8      1896       160
>>        2         9      2224       328
>>        2        10      2384       160
>>        2        11      2544       160
>>        2        12      2768       224
>>        2        13      2928       160
>>        2        14      3088       160
>>        2        15      3248       160
>>        2        16      3408       160
>>
>> --------------------------------------
>>       Patched j.l.r.Proxy
>>       4 interfaces / proxy class
>>
>> class     proxy     size of   delta to
>> loaders   classes   caches    prev.ln.
>> --------  --------  --------  --------
>>        0         0       240       240
>>        1         1       896       656
>>        1         2      1136       240
>>        1         3      1376       240
>>        1         4      1616       240
>>        1         5      1856       240
>>        1         6      2096       240
>>        1         7      2336       240
>>        1         8      2576       240
>>        2         9      3024       448
>>        2        10      3264       240
>>        2        11      3504       240
>>        2        12      3808       304
>>        2        13      4048       240
>>        2        14      4288       240
>>        2        15      4528       240
>>        2        16      4768       240
>>
>>
>> There's an increase of 8 bytes per proxy class key for each 2 
>> interfaces added to proxy class in original Proxy code, but there's 
>> an increase of 32 bytes per proxy class key for each single interface 
>> added in patched Proxy code.
>>
>> I think the most common usage is to implement a single interface and 
>> there is 16 bytes gained for each such usage compared to original 
>> Proxy code.
>>
>>> 2. I did some cleanup to restore some original comments to make the 
>>> diffs clearer where the change is.
>>> 3. I removed the newInstance method which is dead code after my 
>>> previous code.  Since we are in this code, I took the chance to 
>>> clean that up and also change a couple for-loop to use for-each.
>>>
>>> I have put the merged and slightly modified Proxy.java and webrev at:
>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/
>>>
>>> We will use this bug for your contribution:
>>>    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
>>
>> I took j.l.r.Proxy file from your webrev and just changed the 
>> KeyFactory implementation. WeakCache is generic and can be used 
>> unchanged with either implementation of KeyFactory.
>>
>>>
>>> For the weak cache class, since it's for proxy implementation use, I 
>>> suggest to take out the supportContainsValueOperation flagas it 
>>> always keeps the reverse map for isProxyClass lookup.
>>>
>>> You can simply call Objects.requireNonNull(param) instead of 
>>> requireNonNull(param, "param-name") since the proxy implementation 
>>> should have made sure the argument is non-null.
>>>
>>> Formatting nits:
>>>
>>>   68         Object cacheKey = CacheKey.valueOf(
>>>   69             key,
>>>   70             refQueue
>>>   71         );
>>>
>>> should be: all in one line or line break on a long-line.  Same for
>>> method signature.
>>>
>>>  237         void expungeFrom(
>>>  238             ConcurrentMap> map,
>>>  239             ConcurrentMap reverseMap
>>>  240         );
>>>
>>> should be:
>>>
>>> void expungeFrom(ConcurrentMap> map,
>>>                  ConcurrentMap reverseMap);
>>>
>>> so that it'll be more consistent with the existing code.  I'll do a
>>> detailed review on the weak cache class as you will finalize the code
>>> per the decision to go with the two-level weak cache.
>>
>> I hope I have addressed all that in above webrev.
>>
>> Regards, Peter
>>
>>>
>>> Thanks again for the good work.
>>>
>>> Mandy
>>> [1] http://openjdk.java.net/jeps/161 
>>
>



From Alan.Bateman at oracle.com  Sun Apr 21 08:34:58 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 21 Apr 2013 09:34:58 +0100
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver
	to notify the JDBC driver that it has been deregistered.
In-Reply-To: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
Message-ID: <5173A4B2.6010802@oracle.com>

On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
> Hi,
>
> We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be notified when/if it was deregistered via DriverManager.deregisterDriver if desired.
>
>
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01
>
This looks much better than the original proposal, it would have been 
just too problematic to have Driver define a deregister method. Also the 
proposed wording to specify Driver-implementation specific behavior when 
the Driver or Connections is in use, or subsequent use, addresses the 
points that I brought up in the original thread here (thanks!).

Driver

- {@linkplain DriverManager.deregister} -> I assume this should 
DriverManagert#deregisterDriver

- minor alignment issue with the 
         tag.


DriverManager

- one point that isn't covered in the spec is whether the DriverAction's 
deregister is invoked before or after it is deregistered. This 
distinction is probably only interesting for the case that the 
deregister method fails with an error/exception but it's not clear if 
the driver is still registered in that case. For completeness then the 
spec should probably say that any error/runtime exception is propagated 
to the caller of deregisterDriver.

- could the new (and the original) registerDriver methods specify the 
behavior for the case that the Driver is already registered? This brings 
up the question as to whether the DriverAction is overridden if already 
registered.

- the @param alignment is inconsistent in the new deregisterDriver.

- the re-wording of the original deregisterDriver looks much better. 
Minor nit: "was null" -> "is null".

- DriverInfo - would be cleaner to extend the constructor to take the 
DriverAction. Also an action() accessor would make the usage a bit 
cleaner too.


That's all I have for now.

-Alan






From Alan.Bateman at oracle.com  Sun Apr 21 11:33:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 21 Apr 2013 12:33:02 +0100
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5171F1C7.80504@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<5171F1C7.80504@oracle.com>
Message-ID: <5173CE6E.7050008@oracle.com>

On 20/04/2013 02:39, Akhil Arora wrote:
> On 04/19/2013 04:15 AM, Alan Bateman wrote:
>> On 18/04/2013 19:49, Akhil Arora wrote:
>>> Looks like the stars are aligning on getting on this into TL... the
>>> refreshed webrev is -
>>>
>>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>>
>> A minor comment on Collection.removeIf is "that satisifies the given
>> predicate" might be better than "which matches the provided predicate".
>> Also for completeness, you could say "RuntimeExceptions and Errors
>> thrown by the predicate are propagated ...".
>
> fixed both
Thanks, I see the update to Collection.removeIf. I don't see the update 
to List.replaceAll so that could be changed to be consistent before you 
push this.

I looked through the latest webrev (8001647.9) and don't see any other 
issues.

-Alan.


From Lance.Andersen at oracle.com  Sun Apr 21 11:45:27 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Sun, 21 Apr 2013 07:45:27 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
In-Reply-To: <5173A4B2.6010802@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
Message-ID: <20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>

Thank you for the feedback Alan,

Please see below and the webrev http://cr.openjdk.java.net/~lancea/8010416/webrev.02/
On Apr 21, 2013, at 4:34 AM, Alan Bateman wrote:

> On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
>> Hi,
>> 
>> We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be notified when/if it was deregistered via DriverManager.deregisterDriver if desired.
>> 
>> 
>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01
>> 
> This looks much better than the original proposal, it would have been just too problematic to have Driver define a deregister method. Also the proposed wording to specify Driver-implementation specific behavior when the Driver or Connections is in use, or subsequent use, addresses the points that I brought up in the original thread here (thanks!).
> 
> Driver
> 
> - {@linkplain DriverManager.deregister} -> I assume this should DriverManagert#deregisterDriver
> 
> - minor alignment issue with the 
         tag.

Fixed
> 
> 
> DriverManager
> 
> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
> 
> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
clarified
> 
> - the @param alignment is inconsistent in the new deregisterDriver.
done
> 
> - the re-wording of the original deregisterDriver looks much better. Minor nit: "was null" -> "is null".
done
> 
> - DriverInfo - would be cleaner to extend the constructor to take the DriverAction. Also an action() accessor would make the usage a bit cleaner too.

done

Best
Lance
> 
> 
> That's all I have for now.
> 
> -Alan
> 
> 
> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From peter.levart at gmail.com  Sun Apr 21 13:39:21 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 21 Apr 2013 15:39:21 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5173548A.5010107@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <5173548A.5010107@oracle.com>
Message-ID: <5173EC09.1030007@gmail.com>


On 04/21/2013 04:52 AM, Mandy Chung wrote:
> Hi Peter,
>
> I want to give it some more thought and discuss with you next week.  
> As for the zero number of interface, I think it's a bug and it should 
> throw IAE if the given interfaces array is empty. Thanks for finding 
> it and I'll file a separate bug for that since it requires spec 
> update/clarification.

I think it's a feature. It's useful, since it forwards Object methods to 
InvocationHandler (equals, hashCode, ...). Sometimes that's all you need.

Regards, Peter

>
> Mandy
>
> On 4/20/2013 12:31 AM, Peter Levart wrote:
>> Hi Mandy,
>>
>> I have another idea. Before jumping to implement it, I will first ask 
>> what do you think of it. For example:
>>
>> - have an optimal interface names key calculated from interfaces.
>> - visibility of interfaces and other validations are pushed to 
>> slow-path (inside ProxyClassFactory.apply)
>> - the proxy Class object returned from WeakCache.get() is 
>> post-validated with a check like:
>>
>> for (Class intf : interfaces) {
>>     if (!intf.isAssignableFrom(proxyClass)) {
>>         throw new IllegalArgumentException();
>>     }
>> }
>> // return post-validated proxyClass from getProxyClass0()...
>>
>> I feel that Class.isAssignableFrom(Class) check could be much faster 
>> and that the only reason the check can fail is if some interface is 
>> not visible from the class loader.
>>
>> Am I correct?
>>
>> Regards, Peter
>>
>>
>>
>> On 04/19/2013 04:36 PM, Peter Levart wrote:
>>> Hi Mandy,
>>>
>>> On 04/19/2013 07:33 AM, Mandy Chung wrote:
>>>>>
>>>>> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html 
>>>>>
>>>>> What about package-private in java.lang.reflect? It makes Proxy 
>>>>> itself much easier to read. When we decide which way to go, I can 
>>>>> remove the interface and only leave a single package-private class...
>>>>>
>>>>
>>>> thanks.  Moving it to a single package-private classin 
>>>> java.lang.reflectand remove the interface sounds good.
>>>
>>> Right.
>>>
>>>>
>>>> I have merged your patch with the recent TL repo and did some clean 
>>>> up while reviewing it.  Some comments:
>>>> 1. getProxyClass0 should validate the input interfaces and throw 
>>>> IAE if any illegal argument (e.g. interfaces are not visible to the 
>>>> given loader) before calling proxyClassCache.get(loader, 
>>>> interfaces). I moved back the validation code from 
>>>> ProxyClassFactory.apply to getProxyClass0.
>>>
>>> Ops, you're right. There could be a request with interface(s) with 
>>> same name(s) but loaded by different loader(s) and such code could 
>>> return wrong pre-cached proxy class instead of throwing exception. 
>>> Unfortunately, moving validation to slow-path was the cause of major 
>>> performance and scalability improvement observed. With validation 
>>> moved back to getProxyClass0 (in spite of using two-level 
>>> WeakCache), we have the following performance (WeakCache#1):
>>>
>>>
>>> Summary (4 Cores x 2 Threads i7 CPU):
>>>
>>> Test                     Threads  ns/op Original WeakCache#1
>>> =======================  =======  ============== ===========
>>> Proxy_getProxyClass            1        2,403.27 2,174.51
>>>                                4        3,039.01 2,555.00
>>>                                8        5,193.58 4,273.42
>>>
>>> Proxy_isProxyClassTrue         1           95.02 43.14
>>>                                4        2,266.29 43.23
>>>                                8        4,782.29 72.06
>>>
>>> Proxy_isProxyClassFalse        1           95.02 1.36
>>>                                4        2,186.59 1.36
>>>                                8        4,891.15 2.72
>>>
>>> Annotation_equals              1          240.10 195.68
>>>                                4        1,864.06 201.41
>>>                                8        8,639.20 337.46
>>>
>>> It's a little better than original getProxyClass(), but not much. 
>>> The isProxyClass() and consequently Annotation.equals() are far 
>>> better though. But as you might have guessed, I kind of solved that 
>>> too...
>>>
>>> My first attempt was to optimize the interface validation. Only the 
>>> "visibility" part is necessary to be performed on fast-path. 
>>> Uniqueness and other things can be performed on slow-path. With 
>>> split-validation and hacks like:
>>>
>>>     private static final MethodHandle findLoadedClass0MH, 
>>> findBootstrapClassMH;
>>>     private static final ClassLoader dummyCL = new ClassLoader() {};
>>>
>>>     static {
>>>         try {
>>>             Method method = 
>>> ClassLoader.class.getDeclaredMethod("findLoadedClass0", String.class);
>>>             method.setAccessible(true);
>>>             findLoadedClass0MH = 
>>> MethodHandles.lookup().unreflect(method);
>>>
>>>             method = 
>>> ClassLoader.class.getDeclaredMethod("findBootstrapClass", 
>>> String.class);
>>>             method.setAccessible(true);
>>>             findBootstrapClassMH = 
>>> MethodHandles.lookup().unreflect(method);
>>>         } catch (NoSuchMethodException e) {
>>>             throw (Error) new 
>>> NoSuchMethodError(e.getMessage()).initCause(e);
>>>         } catch (IllegalAccessException e) {
>>>             throw (Error) new 
>>> IllegalAccessError(e.getMessage()).initCause(e);
>>>         }
>>>     }
>>>
>>>     static Class findLoadedClass(ClassLoader loader, String name) {
>>>         try {
>>>             if (VM.isSystemDomainLoader(loader)) {
>>>                 return (Class) 
>>> findBootstrapClassMH.invokeExact(dummyCL, name);
>>>             } else {
>>>                 return (Class) 
>>> findLoadedClass0MH.invokeExact(loader, name);
>>>             }
>>>         } catch (RuntimeException | Error e) {
>>>             throw e;
>>>         } catch (Throwable t) {
>>>             throw new UndeclaredThrowableException(t);
>>>         }
>>>     }
>>>
>>>
>>> ... using findLoadedClass(loader, intf.getName()) and only doing 
>>> Class.forName(intf.getName(), false, loader) if the former returned 
>>> null ... I managed to reclaim some performance (WeakCache#1+):
>>>
>>>
>>> Test                     Threads  ns/op Original  WeakCache#1 
>>> WeakCache#1+
>>> =======================  =======  ============== =========== 
>>> ============
>>> Proxy_getProxyClass            1        2,403.27 2,174.51 1,589.36
>>>                                4        3,039.01 2,555.00 1,929.11
>>>                                8        5,193.58 4,273.42 3,409.77
>>>
>>>
>>> ...but that was still not very satisfactory.
>>>
>>> I modified the KeyFactory to create keys that weakly-reference 
>>> interface Class objects and implement hashCode/equals in terms of 
>>> comparing those Class objects. With such keys, no false aliasing can 
>>> occur and the whole validation can be pushed back to slow-path. I 
>>> tried hard to create keys with as little space overhead as possible:
>>>
>>> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html 
>>>
>>>
>>> ...but there can be no miracles. The good news is that the 
>>> performance is back (WeakCache#2):
>>>
>>>
>>> Summary (4 Cores x 2 Threads i7 CPU):
>>>
>>> Test                     Threads  ns/op Original WeakCache#1 
>>> WeakCache#2
>>> =======================  =======  ============== =========== 
>>> ===========
>>> Proxy_getProxyClass            1        2,403.27 2,174.51       163.57
>>>                                4        3,039.01 2,555.00       211.70
>>>                                8        5,193.58 4,273.42       322.14
>>>
>>> Proxy_isProxyClassTrue         1           95.02 43.14 41.23
>>>                                4        2,266.29 43.23 42.20
>>>                                8        4,782.29 72.06 72.21
>>>
>>> Proxy_isProxyClassFalse        1           95.02 1.36 1.36
>>>                                4        2,186.59 1.36 1.36
>>>                                8        4,891.15 2.72 2.72
>>>
>>> Annotation_equals              1          240.10 195.68 194.61
>>>                                4        1,864.06 201.41 198.81
>>>                                8        8,639.20 337.46 342.90
>>>
>>>
>>> ... and the most common usage (proxy class implementing exactly one 
>>> interface) uses even less space than with interface-names-key - 16 
>>> bytes saved per proxy class vs. 8 bytes saved (32 bit addressing mode):
>>>
>>> --------------------------------------
>>>       Original j.l.r.Proxy
>>>       1 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       400       400
>>>        1         1       768       368
>>>        1         2       920       152
>>>        1         3      1072       152
>>>        1         4      1224       152
>>>        1         5      1376       152
>>>        1         6      1528       152
>>>        1         7      1680       152
>>>        1         8      1832       152
>>>        2         9      2152       320
>>>        2        10      2304       152
>>>        2        11      2456       152
>>>        2        12      2672       216
>>>        2        13      2824       152
>>>        2        14      2976       152
>>>        2        15      3128       152
>>>        2        16      3280       152
>>>
>>> --------------------------------------
>>>       Patched j.l.r.Proxy
>>>       1 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       240       240
>>>        1         1       792       552
>>>        1         2       928       136
>>>        1         3      1064       136
>>>        1         4      1200       136
>>>        1         5      1336       136
>>>        1         6      1472       136
>>>        1         7      1608       136
>>>        1         8      1744       136
>>>        2         9      2088       344
>>>        2        10      2224       136
>>>        2        11      2360       136
>>>        2        12      2560       200
>>>        2        13      2696       136
>>>        2        14      2832       136
>>>        2        15      2968       136
>>>        2        16      3104       136
>>>
>>>
>>> Did you know, that Proxy.getProxyClass() can generate proxy classes 
>>> implementing 0 interfaces? It can. There's exactly one such class 
>>> generated per class loader:
>>>
>>>
>>> --------------------------------------
>>>       Original j.l.r.Proxy
>>>       0 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       400       400
>>>        1         1       760       360
>>>        2         2      1072       312
>>>
>>> --------------------------------------
>>>       Patched j.l.r.Proxy
>>>       0 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       240       240
>>>        1         1       728       488
>>>        2         2      1040       312
>>>
>>>
>>> With 2 or more interfaces implemented by proxy class the space 
>>> overhead increases faster than with original Proxy:
>>>
>>>
>>> --------------------------------------
>>>       Original j.l.r.Proxy
>>>       2 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       400       400
>>>        1         1       768       368
>>>        1         2       920       152
>>>        1         3      1072       152
>>>        1         4      1224       152
>>>        1         5      1376       152
>>>        1         6      1528       152
>>>        1         7      1680       152
>>>        1         8      1832       152
>>>        2         9      2152       320
>>>        2        10      2304       152
>>>        2        11      2456       152
>>>        2        12      2672       216
>>>        2        13      2824       152
>>>        2        14      2976       152
>>>        2        15      3128       152
>>>        2        16      3280       152
>>>
>>> --------------------------------------
>>>       Patched j.l.r.Proxy
>>>       2 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       240       240
>>>        1         1       832       592
>>>        1         2      1008       176
>>>        1         3      1184       176
>>>        1         4      1360       176
>>>        1         5      1536       176
>>>        1         6      1712       176
>>>        1         7      1888       176
>>>        1         8      2064       176
>>>        2         9      2448       384
>>>        2        10      2624       176
>>>        2        11      2800       176
>>>        2        12      3040       240
>>>        2        13      3216       176
>>>        2        14      3392       176
>>>        2        15      3568       176
>>>        2        16      3744       176
>>>
>>> --------------------------------------
>>>       Original j.l.r.Proxy
>>>       3 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       400       400
>>>        1         1       776       376
>>>        1         2       936       160
>>>        1         3      1096       160
>>>        1         4      1256       160
>>>        1         5      1416       160
>>>        1         6      1576       160
>>>        1         7      1736       160
>>>        1         8      1896       160
>>>        2         9      2224       328
>>>        2        10      2384       160
>>>        2        11      2544       160
>>>        2        12      2768       224
>>>        2        13      2928       160
>>>        2        14      3088       160
>>>        2        15      3248       160
>>>        2        16      3408       160
>>>
>>> --------------------------------------
>>>       Patched j.l.r.Proxy
>>>       3 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       240       240
>>>        1         1       864       624
>>>        1         2      1072       208
>>>        1         3      1280       208
>>>        1         4      1488       208
>>>        1         5      1696       208
>>>        1         6      1904       208
>>>        1         7      2112       208
>>>        1         8      2320       208
>>>        2         9      2736       416
>>>        2        10      2944       208
>>>        2        11      3152       208
>>>        2        12      3424       272
>>>        2        13      3632       208
>>>        2        14      3840       208
>>>        2        15      4048       208
>>>        2        16      4256       208
>>>
>>> --------------------------------------
>>>       Original j.l.r.Proxy
>>>       4 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       400       400
>>>        1         1       776       376
>>>        1         2       936       160
>>>        1         3      1096       160
>>>        1         4      1256       160
>>>        1         5      1416       160
>>>        1         6      1576       160
>>>        1         7      1736       160
>>>        1         8      1896       160
>>>        2         9      2224       328
>>>        2        10      2384       160
>>>        2        11      2544       160
>>>        2        12      2768       224
>>>        2        13      2928       160
>>>        2        14      3088       160
>>>        2        15      3248       160
>>>        2        16      3408       160
>>>
>>> --------------------------------------
>>>       Patched j.l.r.Proxy
>>>       4 interfaces / proxy class
>>>
>>> class     proxy     size of   delta to
>>> loaders   classes   caches    prev.ln.
>>> --------  --------  --------  --------
>>>        0         0       240       240
>>>        1         1       896       656
>>>        1         2      1136       240
>>>        1         3      1376       240
>>>        1         4      1616       240
>>>        1         5      1856       240
>>>        1         6      2096       240
>>>        1         7      2336       240
>>>        1         8      2576       240
>>>        2         9      3024       448
>>>        2        10      3264       240
>>>        2        11      3504       240
>>>        2        12      3808       304
>>>        2        13      4048       240
>>>        2        14      4288       240
>>>        2        15      4528       240
>>>        2        16      4768       240
>>>
>>>
>>> There's an increase of 8 bytes per proxy class key for each 2 
>>> interfaces added to proxy class in original Proxy code, but there's 
>>> an increase of 32 bytes per proxy class key for each single 
>>> interface added in patched Proxy code.
>>>
>>> I think the most common usage is to implement a single interface and 
>>> there is 16 bytes gained for each such usage compared to original 
>>> Proxy code.
>>>
>>>> 2. I did some cleanup to restore some original comments to make the 
>>>> diffs clearer where the change is.
>>>> 3. I removed the newInstance method which is dead code after my 
>>>> previous code.  Since we are in this code, I took the chance to 
>>>> clean that up and also change a couple for-loop to use for-each.
>>>>
>>>> I have put the merged and slightly modified Proxy.java and webrev at:
>>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.00/
>>>>
>>>> We will use this bug for your contribution:
>>>>    7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
>>>
>>> I took j.l.r.Proxy file from your webrev and just changed the 
>>> KeyFactory implementation. WeakCache is generic and can be used 
>>> unchanged with either implementation of KeyFactory.
>>>
>>>>
>>>> For the weak cache class, since it's for proxy implementation use, 
>>>> I suggest to take out the supportContainsValueOperation flagas it 
>>>> always keeps the reverse map for isProxyClass lookup.
>>>>
>>>> You can simply call Objects.requireNonNull(param) instead of 
>>>> requireNonNull(param, "param-name") since the proxy implementation 
>>>> should have made sure the argument is non-null.
>>>>
>>>> Formatting nits:
>>>>
>>>>   68         Object cacheKey = CacheKey.valueOf(
>>>>   69             key,
>>>>   70             refQueue
>>>>   71         );
>>>>
>>>> should be: all in one line or line break on a long-line. Same for
>>>> method signature.
>>>>
>>>>  237         void expungeFrom(
>>>>  238             ConcurrentMap> map,
>>>>  239             ConcurrentMap reverseMap
>>>>  240         );
>>>>
>>>> should be:
>>>>
>>>> void expungeFrom(ConcurrentMap> map,
>>>>                  ConcurrentMap reverseMap);
>>>>
>>>> so that it'll be more consistent with the existing code. I'll do a
>>>> detailed review on the weak cache class as you will finalize the code
>>>> per the decision to go with the two-level weak cache.
>>>
>>> I hope I have addressed all that in above webrev.
>>>
>>> Regards, Peter
>>>
>>>>
>>>> Thanks again for the good work.
>>>>
>>>> Mandy
>>>> [1] http://openjdk.java.net/jeps/161 
>>>
>>
>



From Ulf.Zibis at CoSoCo.de  Sun Apr 21 15:09:37 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sun, 21 Apr 2013 17:09:37 +0200
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver
	to notify the JDBC driver that it has been deregistered.
In-Reply-To: <20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
Message-ID: <51740131.9000000@CoSoCo.de>

Minor nits:
DriverManager line 349: I would break the line right after the opening parenthesis.
DriverManager line 355: missing space after comma.

-Ulf

Am 21.04.2013 13:45, schrieb Lance Andersen - Oracle:
> Thank you for the feedback Alan,
>
> Please see below and the webrev http://cr.openjdk.java.net/~lancea/8010416/webrev.02/
> On Apr 21, 2013, at 4:34 AM, Alan Bateman wrote:
>
>> On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
>>> Hi,
>>>
>>> We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be notified when/if it was deregistered via DriverManager.deregisterDriver if desired.
>>>
>>>
>>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01
>>>
>> This looks much better than the original proposal, it would have been just too problematic to have Driver define a deregister method. Also the proposed wording to specify Driver-implementation specific behavior when the Driver or Connections is in use, or subsequent use, addresses the points that I brought up in the original thread here (thanks!).
>>
>> Driver
>>
>> - {@linkplain DriverManager.deregister} -> I assume this should DriverManagert#deregisterDriver
>>
>> - minor alignment issue with the 
         tag.
> Fixed
>>
>> DriverManager
>>
>> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
>>
>> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
> clarified
>> - the @param alignment is inconsistent in the new deregisterDriver.
> done
>> - the re-wording of the original deregisterDriver looks much better. Minor nit: "was null" -> "is null".
> done
>> - DriverInfo - would be cleaner to extend the constructor to take the DriverAction. Also an action() accessor would make the usage a bit cleaner too.
> done
>
> Best
> Lance
>>
>> That's all I have for now.
>>
>> -Alan
>>
>>
>>
>>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From akhil.arora at oracle.com  Sun Apr 21 17:46:40 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Sun, 21 Apr 2013 10:46:40 -0700
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <5173CE6E.7050008@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
	<50C658A9.30607@oracle.com> <50C6C51C.8080903@oracle.com>
	<5170404B.9000708@oracle.com> <5171274C.1080606@oracle.com>
	<5171F1C7.80504@oracle.com> <5173CE6E.7050008@oracle.com>
Message-ID: <51742600.7080906@oracle.com>

On 04/21/2013 04:33 AM, Alan Bateman wrote:
> On 20/04/2013 02:39, Akhil Arora wrote:
>> On 04/19/2013 04:15 AM, Alan Bateman wrote:
>>> On 18/04/2013 19:49, Akhil Arora wrote:
>>>> Looks like the stars are aligning on getting on this into TL... the
>>>> refreshed webrev is -
>>>>
>>>> http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
>>>>
>>> A minor comment on Collection.removeIf is "that satisifies the given
>>> predicate" might be better than "which matches the provided predicate".
>>> Also for completeness, you could say "RuntimeExceptions and Errors
>>> thrown by the predicate are propagated ...".
>>
>> fixed both
> Thanks, I see the update to Collection.removeIf. I don't see the update
> to List.replaceAll so that could be changed to be consistent before you
> push this.

Updated List.replaceAll. I noticed a few other inconsistencies, 
corrected them in 8001647.9 -

http://cr.openjdk.java.net/~akhil/8001647.9/webrev/

the two changes are -

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f51da04f3899

and

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d907dff00ace

Thanks


From weijun.wang at oracle.com  Mon Apr 22 03:40:42 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 22 Apr 2013 03:40:42 +0000
Subject: hg: jdk8/tl/jdk: 8005527: [TEST_BUG] console.sh failed Automatically
	with exit code 1.
Message-ID: <20130422034055.05086484CC@hg.openjdk.java.net>

Changeset: 22a27dfd0510
Author:    weijun
Date:      2013-04-22 11:39 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22a27dfd0510

8005527: [TEST_BUG] console.sh failed Automatically with exit code 1.
Reviewed-by: xuelei

! test/sun/security/tools/keytool/console.sh



From joel.franck at oracle.com  Mon Apr 22 08:44:15 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 22 Apr 2013 08:44:15 +0000
Subject: hg: jdk8/tl/langtools: 8011027: Type parameter annotations not passed
	through to javax.lang.model
Message-ID: <20130422084422.7F679484D2@hg.openjdk.java.net>

Changeset: bae8387d16aa
Author:    jfranck
Date:      2013-04-22 10:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bae8387d16aa

8011027: Type parameter annotations not passed through to javax.lang.model
Reviewed-by: jjg, darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
+ test/tools/javac/processing/model/element/TestTypeParameterAnnotations.java



From Alan.Bateman at oracle.com  Mon Apr 22 13:13:49 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Apr 2013 14:13:49 +0100
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver
	to notify the JDBC driver that it has been deregistered.
In-Reply-To: <20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
Message-ID: <5175378D.4010800@oracle.com>

On 21/04/2013 12:45, Lance Andersen - Oracle wrote:
> :
>>
>> DriverManager
>>
>> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
>>
>> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
> clarified
Thanks, I think that covers all the corner cases.

One typo, line 376, should be "If the specified ...".

-Alan.



From Lance.Andersen at oracle.com  Mon Apr 22 15:17:35 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 22 Apr 2013 11:17:35 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
In-Reply-To: <5175378D.4010800@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
	<5175378D.4010800@oracle.com>
Message-ID: <8AFCEB1B-E102-4469-9F0E-FF895955C007@oracle.com>


On Apr 22, 2013, at 9:13 AM, Alan Bateman wrote:

> On 21/04/2013 12:45, Lance Andersen - Oracle wrote:
>> :
>>> 
>>> DriverManager
>>> 
>>> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
>>> 
>>> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
>> clarified
> Thanks, I think that covers all the corner cases.
> 
> One typo, line 376, should be "If the specified ...".

Fixed that thank you.
> 
> -Alan.
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From Lance.Andersen at oracle.com  Mon Apr 22 15:19:17 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 22 Apr 2013 11:19:17 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
In-Reply-To: <51740131.9000000@CoSoCo.de>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
	<51740131.9000000@CoSoCo.de>
Message-ID: <7EDAB6DA-EE34-473E-9526-A89B3E776F18@oracle.com>


On Apr 21, 2013, at 11:09 AM, Ulf Zibis wrote:

> Minor nits:
> DriverManager line 349: I would break the line right after the opening parenthesis.

I did not change this as other methods break after the 1st parameter (getConnection is one example) so I would prefer to keep it consistent (or as much as it can be)
> DriverManager line 355: missing space after comma.

fixed this.  thank for this

Best
Lance
> 
> -Ulf
> 
> Am 21.04.2013 13:45, schrieb Lance Andersen - Oracle:
>> Thank you for the feedback Alan,
>> 
>> Please see below and the webrev http://cr.openjdk.java.net/~lancea/8010416/webrev.02/
>> On Apr 21, 2013, at 4:34 AM, Alan Bateman wrote:
>> 
>>> On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
>>>> Hi,
>>>> 
>>>> We have been asked  by a few JDBC driver vendors  to allow a JDBC driver to be notified when/if it was deregistered via DriverManager.deregisterDriver if desired.
>>>> 
>>>> 
>>>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01
>>>> 
>>> This looks much better than the original proposal, it would have been just too problematic to have Driver define a deregister method. Also the proposed wording to specify Driver-implementation specific behavior when the Driver or Connections is in use, or subsequent use, addresses the points that I brought up in the original thread here (thanks!).
>>> 
>>> Driver
>>> 
>>> - {@linkplain DriverManager.deregister} -> I assume this should DriverManagert#deregisterDriver
>>> 
>>> - minor alignment issue with the 
         tag.
>> Fixed
>>> 
>>> DriverManager
>>> 
>>> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
>>> 
>>> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
>> clarified
>>> - the @param alignment is inconsistent in the new deregisterDriver.
>> done
>>> - the re-wording of the original deregisterDriver looks much better. Minor nit: "was null" -> "is null".
>> done
>>> - DriverInfo - would be cleaner to extend the constructor to take the DriverAction. Also an action() accessor would make the usage a bit cleaner too.
>> done
>> 
>> Best
>> Lance
>>> 
>>> That's all I have for now.
>>> 
>>> -Alan
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From eric.mccorkle at oracle.com  Mon Apr 22 16:10:43 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 22 Apr 2013 12:10:43 -0400
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
Message-ID: <51756103.6020409@oracle.com>

Hello,

Please review this simple change, which corrects some errors in the
javadoc comments for method parameter reflection.

Note that this changeset does not include any code changes.

The webrev is here:
http://cr.openjdk.java.net/~emc/8012937/webrev.00/


Also, if you have any additional issues with the javadoc comments,
please reply to this request with a description of the problem.

Thanks,
Eric

From sundararajan.athijegannathan at oracle.com  Mon Apr 22 16:15:10 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 22 Apr 2013 16:15:10 +0000
Subject: hg: jdk8/tl/nashorn: 9 new changesets
Message-ID: <20130422161516.ECB0F484DF@hg.openjdk.java.net>

Changeset: ac309d492b8d
Author:    sundar
Date:      2013-04-18 15:50 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ac309d492b8d

8012462: Date.prototype.toJSON does not handle non-Date 'this' as per the spec.
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8012462.js

Changeset: d1d564f5cf82
Author:    hannesw
Date:      2013-04-18 14:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d1d564f5cf82

8012460: RegExp regression
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java
+ test/script/basic/JDK-8012460.js
+ test/script/basic/JDK-8012460.js.EXPECTED

Changeset: bc251a7b5103
Author:    sundar
Date:      2013-04-19 17:46 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bc251a7b5103

8012612: Compile failed
Reviewed-by: hannesw, jlaskey, attila

! src/jdk/nashorn/internal/runtime/Context.java

Changeset: c8460f668d0c
Author:    sundar
Date:      2013-04-19 18:23 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c8460f668d0c

8012593: JSAdapter overrides impacts strongly construction time
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/objects/NativeJSAdapter.java

Changeset: 3a209cbd1d8f
Author:    lagergren
Date:      2013-04-19 16:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3a209cbd1d8f

8010701: Immutable nodes - final iteration
Reviewed-by: sundar, hannesw, jlaskey

! bin/verbose_octane.sh
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/ClassEmitter.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
- src/jdk/nashorn/internal/codegen/Frame.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/Namespace.java
! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/codegen/ObjectCreator.java
+ src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/AccessNode.java
! src/jdk/nashorn/internal/ir/BaseNode.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Block.java
+ src/jdk/nashorn/internal/ir/BlockLexicalContext.java
! src/jdk/nashorn/internal/ir/BreakNode.java
! src/jdk/nashorn/internal/ir/BreakableNode.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/CaseNode.java
! src/jdk/nashorn/internal/ir/CatchNode.java
! src/jdk/nashorn/internal/ir/ContinueNode.java
- src/jdk/nashorn/internal/ir/DoWhileNode.java
! src/jdk/nashorn/internal/ir/EmptyNode.java
! src/jdk/nashorn/internal/ir/ExecuteNode.java
+ src/jdk/nashorn/internal/ir/Flags.java
! src/jdk/nashorn/internal/ir/ForNode.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/IfNode.java
! src/jdk/nashorn/internal/ir/IndexNode.java
! src/jdk/nashorn/internal/ir/LabelNode.java
- src/jdk/nashorn/internal/ir/LabeledNode.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
+ src/jdk/nashorn/internal/ir/LexicalContextNode.java
! src/jdk/nashorn/internal/ir/LineNumberNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/Location.java
+ src/jdk/nashorn/internal/ir/LoopNode.java
! src/jdk/nashorn/internal/ir/Node.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/PropertyNode.java
! src/jdk/nashorn/internal/ir/ReturnNode.java
! src/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk/nashorn/internal/ir/SplitNode.java
! src/jdk/nashorn/internal/ir/SwitchNode.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/ThrowNode.java
! src/jdk/nashorn/internal/ir/TryNode.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
! src/jdk/nashorn/internal/ir/VarNode.java
! src/jdk/nashorn/internal/ir/WhileNode.java
! src/jdk/nashorn/internal/ir/WithNode.java
+ src/jdk/nashorn/internal/ir/annotations/Immutable.java
! src/jdk/nashorn/internal/ir/debug/ASTWriter.java
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java
! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java
! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/parser/TokenType.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/DebugLogger.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/StructureLoader.java
! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
! src/jdk/nashorn/tools/Shell.java
+ test/script/basic/try2.js
+ test/script/basic/try2.js.EXPECTED

Changeset: e599a1cad89a
Author:    jlaskey
Date:      2013-04-20 08:54 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e599a1cad89a

8011578: -Dnashorn.unstable.relink.threshold=1 causes tests to fail.
Reviewed-by: sundar, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/FindProperty.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/WithObject.java
+ test/script/basic/JDK-8011578.js
+ test/script/basic/JDK-8011578.js.EXPECTED

Changeset: ead94bc57939
Author:    sundar
Date:      2013-04-22 18:09 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ead94bc57939

8012673: Nashorn's package name vs class name inferring logic is wrong
Reviewed-by: hannesw, jlaskey, attila

! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java

Changeset: 812e9cc70320
Author:    jlaskey
Date:      2013-04-22 10:37 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/812e9cc70320

8012919: findMegaMorphicSetMethod should not cast result type
Reviewed-by: attila, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/WithObject.java

Changeset: cfda59f3d827
Author:    sundar
Date:      2013-04-22 19:57 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cfda59f3d827

Merge

- src/jdk/nashorn/internal/codegen/Frame.java
- src/jdk/nashorn/internal/ir/DoWhileNode.java
- src/jdk/nashorn/internal/ir/LabeledNode.java



From joe.darcy at oracle.com  Mon Apr 22 16:49:34 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Apr 2013 09:49:34 -0700
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <51756103.6020409@oracle.com>
References: <51756103.6020409@oracle.com>
Message-ID: <51756A1E.30306@oracle.com>

On 04/22/2013 09:10 AM, Eric McCorkle wrote:
> Hello,
>
> Please review this simple change, which corrects some errors in the
> javadoc comments for method parameter reflection.
>
> Note that this changeset does not include any code changes.
>
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>
>
> Also, if you have any additional issues with the javadoc comments,
> please reply to this request with a description of the problem.
>
> Thanks,
> Eric

Looks fine, but I'd also delete

  157         // As per the spec, if a parameter has no name, return argX,
  158         // where x is the index.
  159         //


when you're making this change.

-Joe


From john.r.rose at oracle.com  Mon Apr 22 18:06:26 2013
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 22 Apr 2013 11:06:26 -0700
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
In-Reply-To: <517173D4.1040207@oracle.com>
References: <517173D4.1040207@oracle.com>
Message-ID: <2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>

On Apr 19, 2013, at 9:41 AM, Bharadwaj Yadavalli  wrote:

> I would like to request for a review of code changes made to support lambda related modifications to allow static and invokespecial calls to interface methods per spec version 0.6.2 (http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.html). These changes support an upcoming change that compiles lambdas as private static methods in conjunction with hotspot changes pushed to address JDK-8006267.
> 
> JBS        : https://jbs.oracle.com/bugs/browse/JDK-8008687
> Webrev : http://cr.openjdk.java.net/~bharadwaj/8008687/webrev/

Looks good as far as it goes (to allow private lambda bodies to be accessed from interfaces).  But more work is needed to align the java.lang.invoke APIs with the new class file rules.

In your code, I think the case 'refKind == REF_invokeSpecial' is missing.  The draft JVMS implies REF_invokeSpecial is also allowed, since an interface method can be any of {public,private}+{static,non-static}.  We should have unit tests for findStatic and findSpecial of interface methods.  (Also unreflect and unreflectSpecial.)

But it is a step forward.  You can count me as a reviewer.  Please consider filing a followup bug to support the other new interface method kinds.

? John

From mike.duigou at oracle.com  Mon Apr 22 18:18:11 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 22 Apr 2013 18:18:11 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130422181846.C7437484EB@hg.openjdk.java.net>

Changeset: 3ca33647db95
Author:    akhil
Date:      2013-04-22 09:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ca33647db95

8001647: default methods for Collections - forEach, removeIf, replaceAll, sort
Reviewed-by: alanb, dholmes, mduigou, psandoz, smarks
Contributed-by: Akhil Arora , Arne Siegel , Brian Goetz 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
+ test/java/util/Collection/CollectionDefaults.java
+ test/java/util/Collection/ListDefaults.java
+ test/java/util/Collection/testlibrary/CollectionAsserts.java
+ test/java/util/Collection/testlibrary/CollectionSupplier.java

Changeset: 2a78d8f1fec1
Author:    briangoetz
Date:      2013-04-17 14:39 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a78d8f1fec1

8008682: Inital Streams public API
Reviewed-by: mduigou, dholmes, darcy
Contributed-by: Brian Goetz , Mike Duigou , Paul Sandoz , JSR-335 EG 

+ src/share/classes/java/util/stream/BaseStream.java
+ src/share/classes/java/util/stream/CloseableStream.java
+ src/share/classes/java/util/stream/Collector.java
+ src/share/classes/java/util/stream/DelegatingStream.java
+ src/share/classes/java/util/stream/DoubleStream.java
+ src/share/classes/java/util/stream/IntStream.java
+ src/share/classes/java/util/stream/LongStream.java
+ src/share/classes/java/util/stream/Stream.java
+ src/share/classes/java/util/stream/package-info.java

Changeset: 98a7bb7baa76
Author:    psandoz
Date:      2013-04-17 11:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76

8011426: java.util collection Spliterator implementations
Summary: Spliterator implementations for collection classes in java.util.
Reviewed-by: mduigou, briangoetz
Contributed-by: Doug Lea 
        , Paul Sandoz 

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/WeakHashMap.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java



From xueming.shen at oracle.com  Mon Apr 22 18:32:52 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 22 Apr 2013 11:32:52 -0700
Subject: Codereview request: 8012638:
	test/java/time/test/java/util/TestFormatter fails in UTC TZ
Message-ID: <51758254.5070000@oracle.com>

Hi,

This is a "test regression" caused by the JSR310 latest push into TL repository, in which
the timezone name handling is slightly different for those "special" timezone name such
as UTC, GMT and UT. The offending test case has not been updated accordingly (the test
case had the old workaround to map the UTC/GMT/UT back to JSR310 specific "Z" for the
golden data, which is no longer needed in the latest JSR310 spec/implementation), so
it fails on env/conf that has the TZ configured to UTC/GMT/UT, which is likely on some
server machines, like our JPRT solaris machines. The proposed change has been reviewed
and pushed into JSR310 repo already, guess it might be preferred to push this test case
only/simple fix into the TL to remove the test/nightly test failure.

http://cr.openjdk.java.net/~sherman/8012638/webrev

thanks,
-Sherman


From Alan.Bateman at oracle.com  Mon Apr 22 18:42:12 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Apr 2013 19:42:12 +0100
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5171DA7F.1070105@oracle.com>
References: <5171DA7F.1070105@oracle.com>
Message-ID: <51758484.7030600@oracle.com>

On 20/04/2013 00:59, Akhil Arora wrote:
> Please review the addition of optimized defaults for Iterator's 
> forEachRemaining to ArrayList, LinkedList, Vector and 
> CopyOnWriteArrayList. The unit test has a performance comparison test 
> (disabled by default) that measures the difference between this method 
> and hasNext()/next(). Significant improvements were measured by 
> overriding the default forEachRemaining by these classes (others, not 
> so much).
>
> http://cr.openjdk.java.net/~akhil/8005051.1/webrev/
>
> Thanks
One thing I meant to ask when forEachRemaining was added was whether it 
should say anything about the "last element"? I see in the webrev that 
you've set it for the ArrayList iterators but not the LinkedList 
iterator - should it?

-Alan.


From eric.mccorkle at oracle.com  Mon Apr 22 18:46:39 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 22 Apr 2013 14:46:39 -0400
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <51756103.6020409@oracle.com>
References: <51756103.6020409@oracle.com>
Message-ID: <5175858F.5040003@oracle.com>

I have posted a newer version with some more edits.  Please review and
suggest any further changes.

http://cr.openjdk.java.net/~emc/8012937/webrev.01/

On 04/22/13 12:10, Eric McCorkle wrote:
> Hello,
> 
> Please review this simple change, which corrects some errors in the
> javadoc comments for method parameter reflection.
> 
> Note that this changeset does not include any code changes.
> 
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
> 
> 
> Also, if you have any additional issues with the javadoc comments,
> please reply to this request with a description of the problem.
> 
> Thanks,
> Eric
> 

From martinrb at google.com  Mon Apr 22 19:45:40 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 Apr 2013 12:45:40 -0700
Subject: Add getChars to CharSequence
In-Reply-To: 
References: 
	<5167151C.6090601@CoSoCo.de>
	
Message-ID: 

Another preliminary webrev is out at
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/

Alan et al: Before continuing, can we:

Have thumbs up on the changes to out of bounds exceptions?

The handling of the rw conditional in the preprocessed sources is very
confusing and error-prone.  I cleaned up some of that code and added tests
to catch the most obvious mistakes.  We can do this all in a single
changeset, but if you like, we can separate the general nio buffer
improvements into a separate changeset; if so, file a bug.

Direct-X-Buffer.java.template
There's a minor comedy of errors here:

     public $Type$Buffer get($type$[] dst, int offset, int length) {-#if[rw]

...

-#else[rw]-        throw new ReadOnlyBufferException();-#end[rw]

get should never throw ReadOnlyBufferException, but in fact it never does,
since the entire method is within a #if[rw] block, causing the throw to be
dead code.




On Thu, Apr 11, 2013 at 2:12 PM, Martin Buchholz wrote:

>
>
>
> On Thu, Apr 11, 2013 at 12:55 PM, Ulf Zibis  wrote:
>
>>
>> Anyway as those methods all need some CPU time to execute normally, I'm
>> not sure if it's worth to save 1 comparison by outsourcing.
>>
>
> Saving one comparison is worth doing in any case in these
> performance-critical methods.
> "Out-lining" the creation of the detail message is a standard refactoring
> that is known to make hotspot happy.
>
>
>> Additionally having getCharsOutOfBounds as source for the exceptions
>> cause/stacktrace could lead to some confusion.
>>
>
> Let's use this sane exception detail:
>
>     private String outOfBoundsMsg(int srcBegin, int srcEnd) {
>         return "srcBegin = " + srcBegin
>             + ", srcEnd = " + srcEnd
>             + ", length() = " + count;
>     }
>
>


From naoto.sato at oracle.com  Mon Apr 22 20:37:38 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 22 Apr 2013 20:37:38 +0000
Subject: hg: jdk8/tl/jdk: 8010666: Implement Currency/LocaleNameProvider in
	Windows Host LocaleProviderAdapter
Message-ID: <20130422203753.76C31484FC@hg.openjdk.java.net>

Changeset: 62fb9e2b5da1
Author:    naoto
Date:      2013-04-22 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62fb9e2b5da1

8010666: Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter
Reviewed-by: okutsu

! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh



From joe.darcy at oracle.com  Mon Apr 22 23:05:02 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 22 Apr 2013 16:05:02 -0700
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <516EDC9A.4070207@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
Message-ID: <5175C21E.2040502@oracle.com>

Hello,

Just reasserting the request for a review of the latest version of this 
patch:

     http://cr.openjdk.java.net/~darcy/8012044.2

I believe this version does an appropriate job of propagating exception 
information when there is misuse of the methods on Throwable.

Thanks,

-Joe

On 4/17/2013 10:32 AM, Joe Darcy wrote:
> On 04/14/2013 07:36 PM, Joe Darcy wrote:
>> On 04/12/2013 07:29 PM, Jason Mehrens wrote:
>>> Joe,
>>> You'll have guard ise.addSuppressed against null.  Looks good 
>>> otherwise.
>>>
>>> private static void initCauseNull() {
>>>       Throwable t1 = new Throwable();
>>>       t1.initCause(null);
>>>       try {
>>>         t1.initCause(null);
>>>       } catch(IllegalStateException expect) {
>>>       }
>>> }
>>
>> Right you are; check added and test updated in:
>>
>>     http://cr.openjdk.java.net/~darcy/8012044.2/
>>
>> Full patch to Throwable:
>
> [snip]
>
> One more iteration; I've changed the initCause logic to suppress both 
> exceptions rather than using one as the cause:
>
>      http://cr.openjdk.java.net/~darcy/8012044.2
>
> Patch to throwable:
>
> --- old/src/share/classes/java/lang/Throwable.java    2013-04-14 
> 19:33:23.000000000 -0700
> +++ new/src/share/classes/java/lang/Throwable.java    2013-04-14 
> 19:33:23.000000000 -0700
> @@ -452,10 +452,15 @@
>       * @since  1.4
>       */
>      public synchronized Throwable initCause(Throwable cause) {
> -        if (this.cause != this)
> -            throw new IllegalStateException("Can't overwrite cause");
> +        if (this.cause != this) {
> +            IllegalStateException ise =
> +                new IllegalStateException("Can't overwrite cause", 
> this);
> +            if (cause != null)
> +                ise.addSuppressed(cause);
> +            throw ise;
> +        }
>          if (cause == this)
> -            throw new IllegalArgumentException("Self-causation not 
> permitted");
> +            throw new IllegalArgumentException("Self-causation not 
> permitted", this);
>          this.cause = cause;
>          return this;
>      }
> @@ -1039,7 +1044,7 @@
>       */
>      public final synchronized void addSuppressed(Throwable exception) {
>          if (exception == this)
> -            throw new 
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
> +            throw new 
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>
>          if (exception == null)
>              throw new NullPointerException(NULL_CAUSE_MESSAGE);
>
> The suppression mechanism is typically, but not exclusively, used by 
> the try-with-resources statement.
>
> Thanks,
>
> -Joe



From mike.duigou at oracle.com  Tue Apr 23 01:15:12 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 22 Apr 2013 18:15:12 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: <5170426D.3000500@oracle.com>
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
	<517014D3.4030503@oracle.com>
	<8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>
	<5170426D.3000500@oracle.com>
Message-ID: 

Hi All;

I've produced a sample of Javadoc with the @implSpec/@implNote tag output before and after the @param section.

http://cr.openjdk.java.net/~mduigou/JDK-8008632/implBefore/

http://cr.openjdk.java.net/~mduigou/JDK-8008632/implAfter/

Take a look at these samples and see if you feel strongly about one or the other. Then visit:

https://www.surveymonkey.com/s/CQ8S7R8

I will run the survey for a couple of days and report the results here.

Thanks

Mike


On Apr 18 2013, at 11:58 , roger riggs wrote:

> Hi Mike,
> 
> Sorry for so many comments on this but I have one more.
> 
> I don't think the order of @implSpec, @implNote is optimal.  As a developer I want to read
> the javadoc and see the description, parameters, returns, etc.
> 
> I don't want to see the implementation spec or notes.  Maybe they are more
> important in default methods but in ordinary methods, they are important
> only when the details matter.
> 
> I would push @implSpec and @implNote down after @throws.
> 
> Roger
> 
> On 4/18/2013 12:49 PM, Mike Duigou wrote:
>> On Apr 18 2013, at 08:44 , roger riggs wrote:
>> 
>>> Hi Mike,
>>> 
>>> On 4/18/2013 11:01 AM, Mike Duigou wrote:
>>>>> Note that Oracle accessibility guidelines for html indicate that headers
>>>>> should use header tags   to be properly navigable by accessibility tools.
>>>> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.
>>> ok, I see that javadoc defines the tag to be wrapped in  xxx.
>>> 
>>> I don't see that the additional emphasis is needed relative to the other
>>> style elements of the javadoc.
>> I *had* thought I was copying the JLS tag but see now that that's not the case. I no longer remember where the  came from.
>> 
>>> I would remove the  explicit markup or if possible delegate
>>> to the stylesheet with a .
>> I will remove it and allow the default formatting to be used.
>> 
>>> Roger
>>> 
>>>> Mike
>>>> 
>>>>> Thanks, Roger
>>>>> 
>>>>> 
>>>>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>>>>> Hello All;
>>>>>> 
>>>>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>>>> 
>>>>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>>>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>>>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>>>> 
>>>>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>>>> 
>>>>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>>>> 
>>>>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
> 



From joe.darcy at oracle.com  Tue Apr 23 02:09:44 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 22 Apr 2013 19:09:44 -0700
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <5175858F.5040003@oracle.com>
References: <51756103.6020409@oracle.com> <5175858F.5040003@oracle.com>
Message-ID: <5175ED68.7010201@oracle.com>

Hello,

  240      * Returns the number of formal parameters (whether explicitly
  241      * declared or implicitly declared or neither) for the executable

Are there parameters that are neither explicitly nor implicitly declared?

I still think the follow comment is better deleted given the source that 
follows it:

  157         // If a parameter has no name, return argX, where x is the
  158         // index.
  159         //

-Joe

On 4/22/2013 11:46 AM, Eric McCorkle wrote:
> I have posted a newer version with some more edits.  Please review and
> suggest any further changes.
>
> http://cr.openjdk.java.net/~emc/8012937/webrev.01/
>
> On 04/22/13 12:10, Eric McCorkle wrote:
>> Hello,
>>
>> Please review this simple change, which corrects some errors in the
>> javadoc comments for method parameter reflection.
>>
>> Note that this changeset does not include any code changes.
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>>
>>
>> Also, if you have any additional issues with the javadoc comments,
>> please reply to this request with a description of the problem.
>>
>> Thanks,
>> Eric
>>



From bharadwaj.yadavalli at oracle.com  Tue Apr 23 02:48:08 2013
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Mon, 22 Apr 2013 22:48:08 -0400
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
In-Reply-To: <2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
References: <517173D4.1040207@oracle.com>
	<2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
Message-ID: <5175F668.1060202@oracle.com>

Thanks for your quick review, John.

On 4/22/2013 2:06 PM, John Rose wrote:
> On Apr 19, 2013, at 9:41 AM, Bharadwaj Yadavalli  wrote:
>
>> I would like to request for a review of code changes made to support lambda related modifications to allow static and invokespecial calls to interface methods per spec version 0.6.2 (http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.html). These changes support an upcoming change that compiles lambdas as private static methods in conjunction with hotspot changes pushed to address JDK-8006267.
>>
>> JBS        : https://jbs.oracle.com/bugs/browse/JDK-8008687
>> Webrev : http://cr.openjdk.java.net/~bharadwaj/8008687/webrev/
> Looks good as far as it goes (to allow private lambda bodies to be accessed from interfaces).  But more work is needed to align the java.lang.invoke APIs with the new class file rules.
>
> In your code, I think the case 'refKind == REF_invokeSpecial' is missing.

I see lambda test failures when I add add that check. I am not yet sure 
what is causing these failure. I will look into them.

>   The draft JVMS implies REF_invokeSpecial is also allowed, since an interface method can be any of {public,private}+{static,non-static}.  We should have unit tests for findStatic and findSpecial of interface methods.  (Also unreflect and unreflectSpecial.)
>
> But it is a step forward.  You can count me as a reviewer.  Please consider filing a followup bug to support the other new interface method kinds.

OK. I'll file the bug to track the necessary support.

Thanks,

Bharadwaj



From mandy.chung at oracle.com  Tue Apr 23 03:27:43 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 Apr 2013 20:27:43 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5173EC09.1030007@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <5173548A.5010107@oracle.com>
	<5173EC09.1030007@gmail.com>
Message-ID: <5175FFAF.3020109@oracle.com>


On 4/21/2013 6:39 AM, Peter Levart wrote:
> On 04/21/2013 04:52 AM, Mandy Chung wrote:
>> Hi Peter,
>>
>> I want to give it some more thought and discuss with you next week.  
>> As for the zero number of interface, I think it's a bug and it should 
>> throw IAE if the given interfaces array is empty.   Thanks for 
>> finding it and I'll file a separate bug for that since it requires 
>> spec update/clarification.
>
> I think it's a feature. It's useful, since it forwards Object methods 
> to InvocationHandler (equals, hashCode, ...). Sometimes that's all you 
> need.
>

Do you have specific use case or know any existing applications doing 
that?  What's the reason one would  prefer to create a proxy class with 
InvocationHandler rather than defining its own class that implements 
equals, hashCode, or toString() method?

Mandy


From Ulf.Zibis at CoSoCo.de  Tue Apr 23 04:11:32 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 23 Apr 2013 06:11:32 +0200
Subject: Add getChars to CharSequence
In-Reply-To: 
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
Message-ID: <517609F4.20308@CoSoCo.de>

Am 22.04.2013 21:45, schrieb Martin Buchholz:
> Another preliminary webrev is out at
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ 
> 
>
> Alan et al: Before continuing, can we:
>
> Have thumbs up on the changes to out of bounds exceptions?

This looks great, but AbstractStringBuilder could be again simplified ...

1. What is the difference between replaceOutOfBounds() and substringOutOfBounds() ? ;-)

2. naming suggestion:
     outOfBoundsMsg() --> outOfSrcBoundsMsg()
     replaceOutOfBounds(), substringOutOfBounds() --> outOfDstBoundsMsg()

3. You could rename the parameters of getChars to:
     getChars(int start, int end, char[] dst, int dstStart)
     Then you only need one method: outOfBoundsMsg() !!
     Note that append(CharSequence s, int start, int end), calling getChars(), also uses start, end.

4. Instead:
         if (start < 0 || start > end || end > count)
     you could write:
         if (start < 0 || end - start < 0 || end > count)
     because result of end - start could be reused later.

5. One more abstraction:
     int checkBounds(int start, int end, int count) {
         int len = end - start;
         if (start < 0 || len < 0 || end > count)
             throw new StringIndexOutOfBoundsException
                 (outOfBoundsMsg(start, end, count));
         return len;
     }

6. insert() methods should likewise throw SIOOBE instead IOOBE.
     Then likewise outOfBoundsMsg() could be used.

7.:
  504         int newCount = count + end - start; // remember in local variable
  505         ensureCapacityInternal(newCount);
  506         s.getChars(start, end, value, count); // can reuse result of end - start if GIT-inlined
  507         count = newCount ;


8.:
  819         int remainingStart = start + str.length();
  820         int remaining = count - regionEnd;
  821         int newCount = remainingStart + remaining;
  822         ensureCapacityInternal(newCount);
  823         System.arraycopy(value, regionEnd,
  824                          value, remainingStart, remaining);

9.:
1128         tail = count - dstOffset;
1129         if ((dstOffset < 0) || (tail < 0))
1130             throw new IndexOutOfBoundsException("dstOffset "+dstOffset);
1131         int len = checkBounds(start, end, s.length());
1132         int newCount = count + len;
1133         ensureCapacityInternal(newCount);
1134         System.arraycopy(value, dstOffset, value, newCount - tail, tail);
1137         s.getChars(start, end, value, dstOffset);
1138         count = newCount;


-Ulf



From david.holmes at oracle.com  Tue Apr 23 05:25:34 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 Apr 2013 15:25:34 +1000
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <5175C21E.2040502@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com>
Message-ID: <51761B4E.8020205@oracle.com>

Hi Joe,

On 23/04/2013 9:05 AM, Joseph Darcy wrote:
> Hello,
>
> Just reasserting the request for a review of the latest version of this
> patch:
>
>      http://cr.openjdk.java.net/~darcy/8012044.2
>
> I believe this version does an appropriate job of propagating exception
> information when there is misuse of the methods on Throwable.

I still find the use of addSuppressed in initCause to be questionable. 
Given:

    catch(SomeException s) {
       sharedException.initCause(s); // oops already has a cause
       throw sharedException;
    }

then the ISE isn't suppressing 's', but replacing/suppressing 
sharedException in my view, as it is what would have been thrown had the 
ISE not occurred.

I understand the desire to not lose sight of the fact that 's' was 
thrown, but this is really no different to a finally block losing the 
original exception info. (And fixing that was rejected when the 
suppression mechanism was added.)

Anyway this isn't a "block" (not that such a thing exists), just a 
comment. The change isn't harmful and may be useful.

Cheers,
David

> Thanks,
>
> -Joe
>
> On 4/17/2013 10:32 AM, Joe Darcy wrote:
>> On 04/14/2013 07:36 PM, Joe Darcy wrote:
>>> On 04/12/2013 07:29 PM, Jason Mehrens wrote:
>>>> Joe,
>>>> You'll have guard ise.addSuppressed against null.  Looks good
>>>> otherwise.
>>>>
>>>> private static void initCauseNull() {
>>>>       Throwable t1 = new Throwable();
>>>>       t1.initCause(null);
>>>>       try {
>>>>         t1.initCause(null);
>>>>       } catch(IllegalStateException expect) {
>>>>       }
>>>> }
>>>
>>> Right you are; check added and test updated in:
>>>
>>>     http://cr.openjdk.java.net/~darcy/8012044.2/
>>>
>>> Full patch to Throwable:
>>
>> [snip]
>>
>> One more iteration; I've changed the initCause logic to suppress both
>> exceptions rather than using one as the cause:
>>
>>      http://cr.openjdk.java.net/~darcy/8012044.2
>>
>> Patch to throwable:
>>
>> --- old/src/share/classes/java/lang/Throwable.java    2013-04-14
>> 19:33:23.000000000 -0700
>> +++ new/src/share/classes/java/lang/Throwable.java    2013-04-14
>> 19:33:23.000000000 -0700
>> @@ -452,10 +452,15 @@
>>       * @since  1.4
>>       */
>>      public synchronized Throwable initCause(Throwable cause) {
>> -        if (this.cause != this)
>> -            throw new IllegalStateException("Can't overwrite cause");
>> +        if (this.cause != this) {
>> +            IllegalStateException ise =
>> +                new IllegalStateException("Can't overwrite cause",
>> this);
>> +            if (cause != null)
>> +                ise.addSuppressed(cause);
>> +            throw ise;
>> +        }
>>          if (cause == this)
>> -            throw new IllegalArgumentException("Self-causation not
>> permitted");
>> +            throw new IllegalArgumentException("Self-causation not
>> permitted", this);
>>          this.cause = cause;
>>          return this;
>>      }
>> @@ -1039,7 +1044,7 @@
>>       */
>>      public final synchronized void addSuppressed(Throwable exception) {
>>          if (exception == this)
>> -            throw new
>> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
>> +            throw new
>> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>>
>>          if (exception == null)
>>              throw new NullPointerException(NULL_CAUSE_MESSAGE);
>>
>> The suppression mechanism is typically, but not exclusively, used by
>> the try-with-resources statement.
>>
>> Thanks,
>>
>> -Joe
>


From joe.darcy at oracle.com  Tue Apr 23 05:51:04 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Apr 2013 22:51:04 -0700
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <51761B4E.8020205@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com> <51761B4E.8020205@oracle.com>
Message-ID: <51762148.9080407@oracle.com>

Hi David,

On 04/22/2013 10:25 PM, David Holmes wrote:
> Hi Joe,
>
> On 23/04/2013 9:05 AM, Joseph Darcy wrote:
>> Hello,
>>
>> Just reasserting the request for a review of the latest version of this
>> patch:
>>
>>      http://cr.openjdk.java.net/~darcy/8012044.2
>>
>> I believe this version does an appropriate job of propagating exception
>> information when there is misuse of the methods on Throwable.
>
> I still find the use of addSuppressed in initCause to be questionable. 
> Given:
>
>    catch(SomeException s) {
>       sharedException.initCause(s); // oops already has a cause
>       throw sharedException;
>    }
>
> then the ISE isn't suppressing 's', but replacing/suppressing 
> sharedException in my view, as it is what would have been thrown had 
> the ISE not occurred.
>
> I understand the desire to not lose sight of the fact that 's' was 
> thrown, but this is really no different to a finally block losing the 
> original exception info. (And fixing that was rejected when the 
> suppression mechanism was added.)

Project Coin discussions did note try-catch-finally and 
try-with-resources were inconsistent on this point. While the 
try-with-resources behavior is regarded as preferable, we thought it 
would be too large a change to redefine the long-standing semantics of 
try-catch-finally.

>
> Anyway this isn't a "block" (not that such a thing exists), just a 
> comment. The change isn't harmful and may be useful.
>
> Cheers,
> David
>

Yes, I would describe the intention of this change as provding 
programmers more information to debug when the methods are Throwable and 
used improperly.

Thanks,

-Joe


From peter.levart at gmail.com  Tue Apr 23 06:24:51 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 23 Apr 2013 08:24:51 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5175FFAF.3020109@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <5173548A.5010107@oracle.com>
	<5173EC09.1030007@gmail.com> <5175FFAF.3020109@oracle.com>
Message-ID: <51762933.5040206@gmail.com>

On 04/23/2013 05:27 AM, Mandy Chung wrote:
>
> On 4/21/2013 6:39 AM, Peter Levart wrote:
>> On 04/21/2013 04:52 AM, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>> I want to give it some more thought and discuss with you next week.  
>>> As for the zero number of interface, I think it's a bug and it 
>>> should throw IAE if the given interfaces array is empty.   Thanks 
>>> for finding it and I'll file a separate bug for that since it 
>>> requires spec update/clarification.
>>
>> I think it's a feature. It's useful, since it forwards Object methods 
>> to InvocationHandler (equals, hashCode, ...). Sometimes that's all 
>> you need.
>>
>
> Do you have specific use case or know any existing applications doing 
> that?  What's the reason one would  prefer to create a proxy class 
> with InvocationHandler rather than defining its own class that 
> implements equals, hashCode, or toString() method?

I really don't have a use-case here. I can only think of a hypothetical 
case where one would already have an InvocationHandler capable of 
serving proxies for various interfaces, including equals/hashCode 
methods. Now to be able to re-use that logic for constructing keys for 
Maps, one could simply request a proxy with no interfaces. The fact is 
that currently this is allowed and although there might not be any 
usages, it doesn't hurt to allow it in the future and there's no 
performance cost supporting it. I think that not putting artificial 
constraints on API usage without a reason is a good design. It's similar 
in a way to some things in language, like for example the support for 
empty arrays. Why would anyone want to have an empty array?

Regards, Peter

P.S. What do you think of the latest webrev? I did some further 
simplifications to code (removed checks for reverseMap != null) and 
re-worded some javadocs. I can publish another webrev together with 
possible further changes when you review it.

>
> Mandy



From mandy.chung at oracle.com  Tue Apr 23 06:43:31 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 Apr 2013 23:43:31 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51762933.5040206@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <5173548A.5010107@oracle.com>
	<5173EC09.1030007@gmail.com> <5175FFAF.3020109@oracle.com>
	<51762933.5040206@gmail.com>
Message-ID: <51762D93.4050300@oracle.com>


On 4/22/2013 11:24 PM, Peter Levart wrote:
> On 04/23/2013 05:27 AM, Mandy Chung wrote:
>>
>> On 4/21/2013 6:39 AM, Peter Levart wrote:
>>> On 04/21/2013 04:52 AM, Mandy Chung wrote:
>>>> Hi Peter,
>>>>
>>>> I want to give it some more thought and discuss with you next 
>>>> week.  As for the zero number of interface, I think it's a bug and 
>>>> it should throw IAE if the given interfaces array is empty.   
>>>> Thanks for finding it and I'll file a separate bug for that since 
>>>> it requires spec update/clarification.
>>>
>>> I think it's a feature. It's useful, since it forwards Object 
>>> methods to InvocationHandler (equals, hashCode, ...). Sometimes 
>>> that's all you need.
>>>
>>
>> Do you have specific use case or know any existing applications doing 
>> that?  What's the reason one would  prefer to create a proxy class 
>> with InvocationHandler rather than defining its own class that 
>> implements equals, hashCode, or toString() method?
>
> I really don't have a use-case here. I can only think of a 
> hypothetical case where one would already have an InvocationHandler 
> capable of serving proxies for various interfaces, including 
> equals/hashCode methods. Now to be able to re-use that logic for 
> constructing keys for Maps, one could simply request a proxy with no 
> interfaces. The fact is that currently this is allowed and although 
> there might not be any usages, it doesn't hurt to allow it in the 
> future and there's no performance cost supporting it. I think that not 
> putting artificial constraints on API usage without a reason is a good 
> design. 

I can't say for sure allowing to define a proxy class with no interface 
is a good design and thus I propose to file a separate issue to follow 
up and determine if there is any issue with and without such constraint 
(interfaces.length() > 0 or not).  Yes - I am in a position not to allow 
creating a proxy class with no interface since that was not the original 
use case (for RMI).  But I see your point and we need to investigate 
before we decide one way or the other.  If we determine no need to 
constraint that, we can close that bug as will not fix.

> It's similar in a way to some things in language, like for example the 
> support for empty arrays. Why would anyone want to have an empty array?
>

I don't think the Proxy API can be compared with empty array language 
support :)

> Regards, Peter
>
> P.S. What do you think of the latest webrev? I did some further 
> simplifications to code (removed checks for reverseMap != null) and 
> re-worded some javadocs. I can publish another webrev together with 
> possible further changes when you review it.
>

Sorry I didn't get the chance to look at your past 2 webrevs (I was 
distracted with higher priority tasks).

Mandy

>>
>> Mandy
>



From forax at univ-mlv.fr  Tue Apr 23 10:23:35 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 23 Apr 2013 12:23:35 +0200
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <51762148.9080407@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com> <51761B4E.8020205@oracle.com>
	<51762148.9080407@oracle.com>
Message-ID: <51766127.8020403@univ-mlv.fr>

On 04/23/2013 07:51 AM, Joe Darcy wrote:
> Hi David,
>
> On 04/22/2013 10:25 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 23/04/2013 9:05 AM, Joseph Darcy wrote:
>>> Hello,
>>>
>>> Just reasserting the request for a review of the latest version of this
>>> patch:
>>>
>>>      http://cr.openjdk.java.net/~darcy/8012044.2
>>>
>>> I believe this version does an appropriate job of propagating exception
>>> information when there is misuse of the methods on Throwable.
>>
>> I still find the use of addSuppressed in initCause to be 
>> questionable. Given:
>>
>>    catch(SomeException s) {
>>       sharedException.initCause(s); // oops already has a cause
>>       throw sharedException;
>>    }
>>
>> then the ISE isn't suppressing 's', but replacing/suppressing 
>> sharedException in my view, as it is what would have been thrown had 
>> the ISE not occurred.
>>
>> I understand the desire to not lose sight of the fact that 's' was 
>> thrown, but this is really no different to a finally block losing the 
>> original exception info. (And fixing that was rejected when the 
>> suppression mechanism was added.)
>
> Project Coin discussions did note try-catch-finally and 
> try-with-resources were inconsistent on this point. While the 
> try-with-resources behavior is regarded as preferable, we thought it 
> would be too large a change to redefine the long-standing semantics of 
> try-catch-finally.
>
>>
>> Anyway this isn't a "block" (not that such a thing exists), just a 
>> comment. The change isn't harmful and may be useful.
>>
>> Cheers,
>> David
>>
>
> Yes, I would describe the intention of this change as provding 
> programmers more information to debug when the methods are Throwable 
> and used improperly.
>
> Thanks,
>
> -Joe

Like David,
I think that the use of addSuppressed is a bit too much,
suppressed exception are exceptions that were thrown and there is no 
guarantee that a cause was thrown before
(it's sometime the case, but sometimes the cause is used as a 
'tunelling' mechanism,
If I want to throw ThatException but the method only throw ThisException 
so I will create a ThisException
that used a newly created ThatException as cause. In that case, the 
cause was never thrown
and register it has a suppressed exception is weird IMO.

cheers,
R?mi





From Alan.Bateman at oracle.com  Tue Apr 23 11:17:46 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Apr 2013 12:17:46 +0100
Subject: Add getChars to CharSequence
In-Reply-To: 
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
Message-ID: <51766DDA.1010807@oracle.com>

On 22/04/2013 20:45, Martin Buchholz wrote:
> Another preliminary webrev is out at
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ 
> 
>
> Alan et al: Before continuing, can we:
>
> Have thumbs up on the changes to out of bounds exceptions?
I looked over the bound checking. The only one that isn't clear is 
AbstractStringBuilder.insert where dstOffset is specified to be greater 
than this.length rather than count.


>
> The handling of the rw conditional in the preprocessed sources is very 
> confusing and error-prone.  I cleaned up some of that code and added 
> tests to catch the most obvious mistakes.  We can do this all in a 
> single changeset, but if you like, we can separate the general nio 
> buffer improvements into a separate changeset; if so, file a bug.
>
The templates are complicated to work with. Can you provide more details 
on the issues that you found? I grabbed the changes to the buffer tests 
in your patch and ran them with a build on jdk8/tl and the new tests you 
added pass there. Maybe it is the comedy of errors that some of these 
cases actually work but it would be good to get a summary.

-Alan.


From Alan.Bateman at oracle.com  Tue Apr 23 11:52:56 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Apr 2013 12:52:56 +0100
Subject: Add getChars to CharSequence
In-Reply-To: <51766DDA.1010807@oracle.com>
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
	<51766DDA.1010807@oracle.com>
Message-ID: <51767618.5030702@oracle.com>

On 23/04/2013 12:17, Alan Bateman wrote:
> On 22/04/2013 20:45, Martin Buchholz wrote:
>> Another preliminary webrev is out at
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ 
>> 
>>
>> Alan et al: Before continuing, can we:
>>
>> Have thumbs up on the changes to out of bounds exceptions?
> I looked over the bound checking. The only one that isn't clear is 
> AbstractStringBuilder.insert where dstOffset is specified to be 
> greater than this.length rather than count.
One other observation, but as the 2-arg getChars doesn't have explicit 
bounds checking then it may have have copied some chars into the 
destination array before it throws the AIOOBE. Not too interesting of 
course but it may be worth considering a check before copying.

-Alan.


From alexey.utkin at oracle.com  Tue Apr 23 13:22:43 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Tue, 23 Apr 2013 17:22:43 +0400
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
Message-ID: <51768B23.6060506@oracle.com>

Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8012453
http://bugs.sun.com/view_bug.do?bug_id=8012453

Here is the suggested trivial fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.00/

Summary:
----------------------------------
Summary:
        Since the changes for JDK-8005942/JDK-8009463 that commands 
containing spaces cannot be used with Runtime.exec(String). Applications 
should really specify the command and its arguments using the 
Runtime.exec methods that take an array, or alternatively use 
ProcessBuilder as recommended since jdk1.5.

Nevertheless we would like to minimize the impact for legacy Windows OS 
Java application. For application that works without the Security 
Manager, the "jdk.lang.Process.allowAmbigousCommands" Java property 
could be defined programmatically or by program switch 
[-Djdk.lang.Process.allowAmbigousCommands]. Definition of the property 
returns old verification procedure for program name and program 
arguments with full risk of security vulnerabilities.

For compatibility reason the case of quoted executable name in the 
Runtime.exec(String ) was supported. 
If the Security Manager is installed, it is called twice for this case: 
for space-based paring result and result of extended parsing procedure 
that takes quotation into account. We do not guaranty the backward 
compatibility for any call with quoted executable name, but in general 
it works.

Regards,
-uta


From alan.bateman at oracle.com  Tue Apr 23 14:09:32 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 23 Apr 2013 14:09:32 +0000
Subject: hg: jdk8/tl/jdk: 8012930: (fs) Eliminate recursion from FileTreeWalker
Message-ID: <20130423140944.2C95248515@hg.openjdk.java.net>

Changeset: 8b07b318f713
Author:    alanb
Date:      2013-04-23 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b07b318f713

8012930: (fs) Eliminate recursion from FileTreeWalker
Reviewed-by: chegar

! src/share/classes/java/nio/file/FileTreeWalker.java
! src/share/classes/java/nio/file/Files.java
! test/java/nio/file/Files/walkFileTree/CreateFileTree.java
! test/java/nio/file/Files/walkFileTree/MaxDepth.java
! test/java/nio/file/Files/walkFileTree/SkipSiblings.java
+ test/java/nio/file/Files/walkFileTree/SkipSubtree.java
! test/java/nio/file/Files/walkFileTree/TerminateWalk.java
+ test/java/nio/file/Files/walkFileTree/find.sh
- test/java/nio/file/Files/walkFileTree/walk_file_tree.sh



From eric.mccorkle at oracle.com  Tue Apr 23 14:46:15 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 23 Apr 2013 10:46:15 -0400
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <5175ED68.7010201@oracle.com>
References: <51756103.6020409@oracle.com> <5175858F.5040003@oracle.com>
	<5175ED68.7010201@oracle.com>
Message-ID: <51769EB7.40204@oracle.com>

I believe so.  Alex Buckley recommended the exact wording.

On 04/22/13 22:09, Joseph Darcy wrote:
> Hello,
> 
>  240      * Returns the number of formal parameters (whether explicitly
>  241      * declared or implicitly declared or neither) for the executable
> 
> Are there parameters that are neither explicitly nor implicitly declared?
> 
> I still think the follow comment is better deleted given the source that
> follows it:
> 
>  157         // If a parameter has no name, return argX, where x is the
>  158         // index.
>  159         //
> 
> -Joe
> 
> On 4/22/2013 11:46 AM, Eric McCorkle wrote:
>> I have posted a newer version with some more edits.  Please review and
>> suggest any further changes.
>>
>> http://cr.openjdk.java.net/~emc/8012937/webrev.01/
>>
>> On 04/22/13 12:10, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this simple change, which corrects some errors in the
>>> javadoc comments for method parameter reflection.
>>>
>>> Note that this changeset does not include any code changes.
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>>>
>>>
>>> Also, if you have any additional issues with the javadoc comments,
>>> please reply to this request with a description of the problem.
>>>
>>> Thanks,
>>> Eric
>>>
> 

From lance.andersen at oracle.com  Tue Apr 23 15:18:21 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 23 Apr 2013 15:18:21 +0000
Subject: hg: jdk8/tl/jdk: 8011620: adding free form netbeans project for jdbc
	to jdk/make/netbeans
Message-ID: <20130423151834.DD1C948519@hg.openjdk.java.net>

Changeset: b456f25c2075
Author:    lancea
Date:      2013-04-23 11:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b456f25c2075

8011620: adding free form netbeans project for jdbc to jdk/make/netbeans
Reviewed-by: chegar

! make/netbeans/common/shared.xml
+ make/netbeans/jdbc/README
+ make/netbeans/jdbc/build.properties
+ make/netbeans/jdbc/build.xml
+ make/netbeans/jdbc/nbproject/project.xml



From martinrb at google.com  Tue Apr 23 16:45:23 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 23 Apr 2013 09:45:23 -0700
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <51768B23.6060506@oracle.com>
References: <51768B23.6060506@oracle.com>
Message-ID: 

Random comments from a former maintainer:

I was never brave enough to tackle windows argument parsing or trying to
change legacy behavior.

I'm surprised you used LinkedList, which is almost never useful.  Why not
ArrayList?

Windows has arcane command line parsing rules, which are rather difficult
to get right, and I'm suspicious that you are not testing for all of them
(e.g. odd vs. even numbers of backslashes)

Martin


On Tue, Apr 23, 2013 at 6:22 AM, Alexey Utkin wrote:

> Bug description:
> https://jbs.oracle.com/bugs/**browse/JDK-8012453
> http://bugs.sun.com/view_bug.**do?bug_id=8012453
>
> Here is the suggested trivial fix:
> http://cr.openjdk.java.net/~**uta/openjdk-webrevs/JDK-**8012453/webrev.00/
>
> Summary:
> ------------------------------**----
> Summary:
>        Since the changes for JDK-8005942/JDK-8009463 that commands
> containing spaces cannot be used with Runtime.exec(String). Applications
> should really specify the command and its arguments using the Runtime.exec
> methods that take an array, or alternatively use ProcessBuilder as
> recommended since jdk1.5.
>
> Nevertheless we would like to minimize the impact for legacy Windows OS
> Java application. For application that works without the Security Manager,
> the "jdk.lang.Process.**allowAmbigousCommands" Java property could be
> defined programmatically or by program switch [-Djdk.lang.Process.**allowAmbigousCommands].
> Definition of the property returns old verification procedure for program
> name and program arguments with full risk of security vulnerabilities.
>
> For compatibility reason the case of quoted executable name in the
> Runtime.exec(String ) was supported.
> If the Security Manager is installed, it is called twice for this case: for
> space-based paring result and result of extended parsing procedure that
> takes quotation into account. We do not guaranty the backward compatibility
> for any call with quoted executable name, but in general it works.
>
> Regards,
> -uta
>


From jason_mehrens at hotmail.com  Tue Apr 23 17:26:04 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 23 Apr 2013 12:26:04 -0500
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <51761B4E.8020205@oracle.com>
References: <51676122.4020802@oracle.com>,
	, ,
	<516845EC.8090105@oracle.com>,
	, ,
	<51685B97.5010507@oracle.com>,
	,
	<516B6799.1010206@oracle.com>
	<516EDC9A.4070207@oracle.com>, <5175C21E.2040502@oracle.com>,
	<51761B4E.8020205@oracle.com>
Message-ID: 

> I still find the use of addSuppressed in initCause to be questionable. 
> Given:
> 
> catch(SomeException s) {
>        sharedException.initCause(s); // oops already has a cause
> throw sharedException;
> }
> 
> then the ISE isn't suppressing 's', but replacing/suppressing 
> sharedException in my view, as it is what would have been thrown had the 
> ISE not occurred.
I agree. I think makes sense to swap the ISE cause and suppressed arguments because the root cause should be the most important throwable to see in a log file.
In David's example, that would be 's' or the root cause of 's'. Also when the two arguments are swapped the line numbers are in descending order.
 
===========JDK 7 testcase===========================
public static void main(String[] args) throws Exception {
 final Throwable cause = new NoClassDefFoundError();
 final Throwable THIS = new ClassNotFoundException();
 try {
            THIS.initCause(cause); //It's a trap!!
 } catch (IllegalStateException ISE) {
            ISE.initCause(cause); //swapped
            ISE.addSuppressed(THIS); //swapped
            ISE.printStackTrace();
 }
 }
 
java.lang.IllegalStateException: Can't overwrite cause
 at java.lang.Throwable.initCause(Throwable.java:456)
 at Main.main(Main.java:33)
 Suppressed: java.lang.ClassNotFoundException
  at Main.main(Main.java:31)
Caused by: java.lang.NoClassDefFoundError
 at Main.main(Main.java:30)
===============================================
 
Jason 		 	   		  

From brian.burkhalter at oracle.com  Tue Apr 23 18:37:45 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Apr 2013 11:37:45 -0700
Subject: Math.round(...) and bug 6430675
In-Reply-To: <1359798058.38334.YahooMailNeo@web132106.mail.ird.yahoo.com>
References: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com>
	<97FBDF44-F141-4158-B16F-0C4BFA9330EF@oracle.com>
	<1359798058.38334.YahooMailNeo@web132106.mail.ird.yahoo.com>
Message-ID: <8B12F263-71B7-4478-BBDD-FDDB44A188D0@oracle.com>

FYI this came through as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.

Brian

On Feb 2, 2013, at 1:40 AM, Jeff Hain wrote:

> 
> >Would you mind filing an issue so that this may be tracked?
> 
> Done: "Math.round has surprising behavior for odd values of ulp 1"
> 
> -Jeff
> 



From akhil.arora at oracle.com  Tue Apr 23 19:14:05 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Tue, 23 Apr 2013 12:14:05 -0700
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5172FDB0.2050707@CoSoCo.de>
References: <5171DA7F.1070105@oracle.com> <5172FDB0.2050707@CoSoCo.de>
Message-ID: <5176DD7D.1040902@oracle.com>

On 04/20/2013 01:42 PM, Ulf Zibis wrote:
> Am 20.04.2013 01:59, schrieb Akhil Arora:
>> Please review the addition of optimized defaults for Iterator's
>> forEachRemaining to ArrayList, LinkedList, Vector and
>> CopyOnWriteArrayList. The unit test has a performance comparison test
>> (disabled by default) that measures the difference between this method
>> and hasNext()/next(). Significant improvements were measured by
>> overriding the default forEachRemaining by these classes (others, not
>> so much).
>>
>> http://cr.openjdk.java.net/~akhil/8005051.1/webrev/
>
> You mostly do not need ".this.", e.g. in Vector:
> Compare lines 1160 <-> 1137
> Line 1165 could be:
>      final Object[] elementData = this.elementData;
> or simply
>      final Object[] elements = elementData;

done

> To be in line with old habits, please remove space after casts. See
> also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278

I see that new code by others is using spaces after casts, so I would 
like to stick with that convention.

> For performance reasons it could be considered to make Itr final and
> copy its methods to ListItr.

That is beyond the scope of this issue, needs a new issue.

> Interesting: I ever thought, private members are always final, but here
> a private method becomes extended.
>
> -Ulf
>



From akhil.arora at oracle.com  Tue Apr 23 19:18:20 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Tue, 23 Apr 2013 12:18:20 -0700
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <51758484.7030600@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
Message-ID: <5176DE7C.8060404@oracle.com>

On 04/22/2013 11:42 AM, Alan Bateman wrote:
> On 20/04/2013 00:59, Akhil Arora wrote:
>> Please review the addition of optimized defaults for Iterator's
>> forEachRemaining to ArrayList, LinkedList, Vector and
>> CopyOnWriteArrayList. The unit test has a performance comparison test
>> (disabled by default) that measures the difference between this method
>> and hasNext()/next(). Significant improvements were measured by
>> overriding the default forEachRemaining by these classes (others, not
>> so much).
>>
>> http://cr.openjdk.java.net/~akhil/8005051.1/webrev/
>>
>> Thanks
> One thing I meant to ask when forEachRemaining was added was whether it
> should say anything about the "last element"? I see in the webrev that
> you've set it for the ArrayList iterators but not the LinkedList
> iterator - should it?

done, and added more tests for the state of the iterator after 
forEachRemaining returns

http://cr.openjdk.java.net/~akhil/8005051.2/webrev/

(a portion of version 1 of the webrev has already been pushed to TL as 
part of rev 6973 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)


From martinrb at google.com  Tue Apr 23 19:36:17 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 23 Apr 2013 12:36:17 -0700
Subject: Add getChars to CharSequence
In-Reply-To: <517609F4.20308@CoSoCo.de>
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
	<517609F4.20308@CoSoCo.de>
Message-ID: 

Hi Ulf!


On Mon, Apr 22, 2013 at 9:11 PM, Ulf Zibis  wrote:

> Am 22.04.2013 21:45, schrieb Martin Buchholz:
>
>> Another preliminary webrev is out at
>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**getChars/<
>> http://cr.openjdk.java.net/%**7Emartin/webrevs/openjdk8/**getChars/
>> >
>>
>> This looks great, but AbstractStringBuilder could be again simplified ...
>
> 1. What is the difference between replaceOutOfBounds() and
> substringOutOfBounds() ? ;-)
>
>
detail message is different to try to match the parameter names (most of
the time...)


> 2. naming suggestion:
>     outOfBoundsMsg() --> outOfSrcBoundsMsg()
>     replaceOutOfBounds(), substringOutOfBounds() --> outOfDstBoundsMsg()
>
> 3. You could rename the parameters of getChars to:
>     getChars(int start, int end, char[] dst, int dstStart)
>     Then you only need one method: outOfBoundsMsg() !!
>     Note that append(CharSequence s, int start, int end), calling
> getChars(), also uses start, end.
>
>
If a method has a "src" and "dst", then it makes sense to make that clear
in the parameter names, but if it only has a "src", then it makes sense to
leave out the prefix "src" in the parameter names.  It's annoying to use
the words "begin" and "start" interchangeably.  I prefer "start", but it's
probably not possible to fix this now.


> 4. Instead:
>         if (start < 0 || start > end || end > count)
>     you could write:
>         if (start < 0 || end - start < 0 || end > count)
>     because result of end - start could be reused later.
>
>
Yeah, and we can do even better:

    public void getChars(int srcBegin, int srcEnd, char[] dst, int
dstBegin) {
        int length = srcEnd - srcBegin;
        if ((srcBegin | length | (count - srcEnd)) < 0)
            throw new StringIndexOutOfBoundsException
                (outOfBoundsMsg(srcBegin, srcEnd));
        System.arraycopy(value, srcBegin, dst, dstBegin, length);
    }



> 6. insert() methods should likewise throw SIOOBE instead IOOBE.
>     Then likewise outOfBoundsMsg() could be used.
>
>
I'm willing to change exception detail, but not the actual class of the
exception thrown.


From Alan.Bateman at oracle.com  Tue Apr 23 19:39:19 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Apr 2013 20:39:19 +0100
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <51768B23.6060506@oracle.com>
References: <51768B23.6060506@oracle.com>
Message-ID: <5176E367.9090601@oracle.com>

Alexey,

I plan to review this, just don't have time to do a detailed review 
today. At a high-level then I think the approach looks reasonable. If 
someone has gone to the trouble of quoting a program path with spaces in 
it, then the fallback should handle it. It's important that the security 
manager's checkExec is called with the new path to the program and I 
didn't see that when I skimmed over the changes.

The truly ambiguous and legacy cases is difficult but we know that there 
are still applications using these JDK1.0 area APIs. The 
allowAmbigousCommands property is probably okay as a last resort.

-Alan


On 23/04/2013 14:22, Alexey Utkin wrote:
> Bug description:
> https://jbs.oracle.com/bugs/browse/JDK-8012453
> http://bugs.sun.com/view_bug.do?bug_id=8012453
>
> Here is the suggested trivial fix:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.00/
>
> Summary:
> ----------------------------------
> Summary:
>        Since the changes for JDK-8005942/JDK-8009463 that commands 
> containing spaces cannot be used with Runtime.exec(String). 
> Applications should really specify the command and its arguments using 
> the Runtime.exec methods that take an array, or alternatively use 
> ProcessBuilder as recommended since jdk1.5.
>
> Nevertheless we would like to minimize the impact for legacy Windows 
> OS Java application. For application that works without the Security 
> Manager, the "jdk.lang.Process.allowAmbigousCommands" Java property 
> could be defined programmatically or by program switch 
> [-Djdk.lang.Process.allowAmbigousCommands]. Definition of the property 
> returns old verification procedure for program name and program 
> arguments with full risk of security vulnerabilities.
>
> For compatibility reason the case of quoted executable name in the 
> Runtime.exec(String ) was supported. 
> If the Security Manager is installed, it is called twice for this 
> case: for space-based paring result and result of extended parsing 
> procedure that takes quotation into account. We do not guaranty the 
> backward compatibility for any call with quoted executable name, but 
> in general it works.
>
> Regards,
> -uta 



From martinrb at google.com  Tue Apr 23 19:55:49 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 23 Apr 2013 12:55:49 -0700
Subject: Add getChars to CharSequence
In-Reply-To: <51767618.5030702@oracle.com>
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
	<51766DDA.1010807@oracle.com> <51767618.5030702@oracle.com>
Message-ID: 

Yes, all-or-nothing behavior on errors is worth something, and we should
get it right, especially when it's cheap.


On Tue, Apr 23, 2013 at 4:52 AM, Alan Bateman wrote:

> One other observation, but as the 2-arg getChars doesn't have explicit
> bounds checking then it may have have copied some chars into the
> destination array before it throws the AIOOBE. Not too interesting of
> course but it may be worth considering a check before copying.
>
> -Alan.
>


From Ulf.Zibis at CoSoCo.de  Tue Apr 23 23:03:25 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 24 Apr 2013 01:03:25 +0200
Subject: Add getChars to CharSequence
In-Reply-To: 
References: 
	<5167151C.6090601@CoSoCo.de>
	
	
	<517609F4.20308@CoSoCo.de>
	
Message-ID: <5177133D.60309@CoSoCo.de>

Hi Martin,  (cc'd core-libs-dev)

Am 23.04.2013 21:36, schrieb Martin Buchholz:
> Hi Ulf!
>
>
> On Mon, Apr 22, 2013 at 9:11 PM, Ulf Zibis > wrote:
>
>     Am 22.04.2013 21:45, schrieb Martin Buchholz:
>
>         Another preliminary webrev is out at
>         http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/
>         
>         
>
>     This looks great, but AbstractStringBuilder could be again simplified ...
>
>     1. What is the difference between replaceOutOfBounds() and substringOutOfBounds() ? ;-)
>
>
> detail message is different to try to match the parameter names (most of the time...)

Hm, maybe I'm blind, I can't see any difference, even in the parameter names.

>     2. naming suggestion:
>         outOfBoundsMsg() --> outOfSrcBoundsMsg()
>         replaceOutOfBounds(), substringOutOfBounds() --> outOfDstBoundsMsg()
>

Hm, I'm additionally "concerned" about that in one case you add the suffix "Msg", but not in the others.

>
>     3. You could rename the parameters of getChars to:
>         getChars(int start, int end, char[] dst, int dstStart)
>         Then you only need one method: outOfBoundsMsg() !!
>         Note that append(CharSequence s, int start, int end), calling getChars(), also uses start,
>     end.
>
>
> If a method has a "src" and "dst", then it makes sense to make that clear in the parameter names, 
> but if it only has a "src", then it makes sense to leave out the prefix "src" in the parameter names.

Well, if one invokes append(CharSequence s, int start, int end), then IMO it's confusing to see 
"srcBegin" + "srcEnd" in the exception message. Why isn't this possible to change as you stated below?
Instead "dst" you could also use "result" or "drain", and instead "dstStart", "dstOffset" or just 
"offset". The parameters order would make it clear enough that "offset" is meant for "dst".

>  It's annoying to use the words "begin" and "start" interchangeably.  I prefer "start", but it's 
> probably not possible to fix this now.

That's exactly, what I wanted to say. I think it's up to you, because it's a new introduced method, 
to use "start" rather than "begin", as I too would prefer it.

>     4. Instead:
>             if (start < 0 || start > end || end > count)
>         you could write:
>             if (start < 0 || end - start < 0 || end > count)
>         because result of end - start could be reused later.
>
>
> Yeah, and we can do even better:
>
>     public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
>         int length = srcEnd - srcBegin;
>         if ((srcBegin | length | (count - srcEnd)) < 0)
>             throw new StringIndexOutOfBoundsException
>                 (outOfBoundsMsg(srcBegin, srcEnd));
>         System.arraycopy(value, srcBegin, dst, dstBegin, length);
>     }

Yep, great discovery ! I guess, there are many places in the JDK, where this would apply.

>     6. insert() methods should likewise throw SIOOBE instead IOOBE.
>         Then likewise outOfBoundsMsg() could be used.
>
>
> I'm willing to change exception detail, but not the actual class of the exception thrown.

Hm, in my feeling it was by mistake, to inconsistently throw IOOBE instead SIOOBE. IMO it wouldn't 
hurt to throw an SIOOBE, as it's derived from IOOBE, so catching for IOOBE would still work.

-Ulf



From henry.jen at oracle.com  Tue Apr 23 23:09:15 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 23 Apr 2013 16:09:15 -0700
Subject: RFR: JDK-8012650 and JDK-8011918
Message-ID: <5177149B.1080407@oracle.com>

Hi,

Please review static Stream factory methods and methods for Arrays.
Webrev is at

http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.0

Stream methods are covered in a test suite which will be put back soon
once all depends part is in place.

Arrays setAll and parallelSetAll methods has test included.

Cheers,
Henry


From lana.steuck at oracle.com  Tue Apr 23 23:33:23 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:23 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20130423233332.67B8F48542@hg.openjdk.java.net>

Changeset: 8abe95530f58
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8abe95530f58

Added tag jdk8-b86 for changeset a5e7c2f093c9

! .hgtags

Changeset: 9d251e1ec1eb
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9d251e1ec1eb

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:33:18 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:18 +0000
Subject: hg: jdk8/tl: 6 new changesets
Message-ID: <20130423233319.35C7C48540@hg.openjdk.java.net>

Changeset: bee6ff988f9c
Author:    katleman
Date:      2013-04-12 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/bee6ff988f9c

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: 8c5b18d6f4fb
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8c5b18d6f4fb

Merge


Changeset: df9b5240f0a7
Author:    katleman
Date:      2013-04-16 14:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/df9b5240f0a7

Merge


Changeset: 6981694f7674
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/6981694f7674

Added tag jdk8-b86 for changeset df9b5240f0a7

! .hgtags

Changeset: 238b28991d66
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/238b28991d66

Merge


Changeset: b9415faa7066
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/b9415faa7066

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:33:15 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:15 +0000
Subject: hg: jdk8/tl/corba: Added tag jdk8-b86 for changeset 44a8ce4a759f
Message-ID: <20130423233317.D9C3A4853F@hg.openjdk.java.net>

Changeset: f1709874d55a
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/f1709874d55a

Added tag jdk8-b86 for changeset 44a8ce4a759f

! .hgtags



From lana.steuck at oracle.com  Tue Apr 23 23:33:18 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:18 +0000
Subject: hg: jdk8/tl/hotspot: 6 new changesets
Message-ID: <20130423233335.AEE4048544@hg.openjdk.java.net>

Changeset: b0301c02f38e
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0301c02f38e

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! make/bsd/makefiles/fastdebug.make
! src/share/vm/services/diagnosticArgument.cpp
! test/sanity/WBApi.java
! test/serviceability/ParserTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
! test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: c9eb0ec1c792
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9eb0ec1c792

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 86db4847f195
Author:    katleman
Date:      2013-04-17 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86db4847f195

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 2e657354f6bc
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e657354f6bc

Added tag jdk8-b86 for changeset 86db4847f195

! .hgtags

Changeset: db9c527a1fd8
Author:    lana
Date:      2013-04-17 21:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db9c527a1fd8

Merge


Changeset: d4c266784660
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d4c266784660

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:33:22 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:22 +0000
Subject: hg: jdk8/tl/jaxp: 3 new changesets
Message-ID: <20130423233333.3577D48543@hg.openjdk.java.net>

Changeset: 9550aab82b5d
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9550aab82b5d

Added tag jdk8-b86 for changeset ca71ec37b2ef

! .hgtags

Changeset: eddbc8ad2435
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eddbc8ad2435

Merge


Changeset: 6c6411a7070f
Author:    lana
Date:      2013-04-23 15:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6c6411a7070f

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:33:34 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:34 +0000
Subject: hg: jdk8/tl/langtools: 7 new changesets
Message-ID: <20130423233355.D474B48545@hg.openjdk.java.net>

Changeset: 2b585be0da7a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2b585be0da7a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java

Changeset: 717bcda533f2
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/717bcda533f2

Merge


Changeset: 6ab578e141df
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6ab578e141df

Merge


Changeset: 4f4509c2fe35
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4f4509c2fe35

Added tag jdk8-b86 for changeset 6ab578e141df

! .hgtags

Changeset: cad4fc23f691
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cad4fc23f691

Merge


Changeset: 1329f9c38d93
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1329f9c38d93

Merge


Changeset: da0bd69335d4
Author:    lana
Date:      2013-04-23 15:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/da0bd69335d4

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:33:22 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:33:22 +0000
Subject: hg: jdk8/tl/nashorn: 7 new changesets
Message-ID: <20130423233331.13E0948541@hg.openjdk.java.net>

Changeset: e7e82c1e9aed
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e7e82c1e9aed

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! docs/JavaScriptingProgrammersGuide.html
! src/jdk/nashorn/api/scripting/Formatter.java

Changeset: 399a4b8e4607
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/399a4b8e4607

Merge


Changeset: 002ad9d6735f
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/002ad9d6735f

Merge


Changeset: 899cbeee7253
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/899cbeee7253

Added tag jdk8-b86 for changeset 002ad9d6735f

! .hgtags

Changeset: cba329ce5efe
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cba329ce5efe

Merge


Changeset: 774aeaa89bc1
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/774aeaa89bc1

Merge


Changeset: 08143fa6b3da
Author:    lana
Date:      2013-04-23 15:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/08143fa6b3da

Merge




From lana.steuck at oracle.com  Tue Apr 23 23:34:37 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 23 Apr 2013 23:34:37 +0000
Subject: hg: jdk8/tl/jdk: 19 new changesets
Message-ID: <20130423233818.25E0148546@hg.openjdk.java.net>

Changeset: e5c5e369af6a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5c5e369af6a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/net/URLConnection/RequestProperties.java
! test/java/util/Optional/BasicDouble.java
! test/javax/swing/text/html/7189299/bug7189299.java
! test/sun/management/jdp/JdpTest.sh
! test/sun/misc/URLClassPath/JarLoaderTest.java
! test/sun/util/calendar/zi/ZoneInfoFile.java

Changeset: b45456703c65
Author:    katleman
Date:      2013-04-15 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b45456703c65

Merge


Changeset: 7989cd0cc3a9
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7989cd0cc3a9

Merge


Changeset: f4c62eecf7fa
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4c62eecf7fa

Added tag jdk8-b86 for changeset 7989cd0cc3a9

! .hgtags

Changeset: b59b1f5a98dd
Author:    bae
Date:      2013-04-15 16:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b59b1f5a98dd

8005930: [lcms] ColorConvertOp: Alpha channel is not transferred from source to destination.
Reviewed-by: prr

! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
+ test/sun/java2d/cmm/ColorConvertOp/AlphaTest.java

Changeset: 03ee8c648624
Author:    bae
Date:      2013-04-15 18:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03ee8c648624

8011622: Use lcms as the default color management module in jdk8
Reviewed-by: prr, vadim

! make/sun/cmm/Makefile
! make/sun/cmm/kcms/Makefile
! make/sun/cmm/lcms/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
+ src/share/classes/sun/java2d/cmm/CMMServiceProvider.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
+ src/share/classes/sun/java2d/cmm/lcms/LcmsServiceProvider.java
+ src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.CMMServiceProvider
- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: 271d5bf7d61f
Author:    lana
Date:      2013-04-17 12:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/271d5bf7d61f

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk

Changeset: 0799af4553b5
Author:    lana
Date:      2013-04-17 21:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0799af4553b5

Merge

- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: d241f117ff46
Author:    malenkov
Date:      2013-04-11 19:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d241f117ff46

4683761: Incomplete Introspection on nonpublic classes lead to IllegalAccessExceptions
Reviewed-by: alexsch

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test4683761.java

Changeset: be89273ceb9c
Author:    pchelko
Date:      2013-04-12 14:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be89273ceb9c

8010009: [macosx] Unable type into online word games on MacOSX
Reviewed-by: anthony, dcherepanov

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/TestApplet.java

Changeset: 4490ef60ecd3
Author:    anthony
Date:      2013-04-12 14:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4490ef60ecd3

8010297: Missing isLoggable() checks in logging code
Summary: Add isLoggable() checks
Reviewed-by: anthony, mchung, serb
Contributed-by: Laurent Bourges 

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java

Changeset: 39ce1056694d
Author:    serb
Date:      2013-04-12 15:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39ce1056694d

8000629: [macosx] Blurry rendering with Java 7 on Retina display
Reviewed-by: anthony, prr, flar

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CGraphicsDevice.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/Region.java
+ test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java
+ test/java/awt/Graphics2D/FlipDrawImage/FlipDrawImage.java
+ test/java/awt/Graphics2D/TransformSetGet/TransformSetGet.java
+ test/java/awt/image/DrawImage/IncorrectBounds.java
+ test/java/awt/image/DrawImage/IncorrectOffset.java

Changeset: ffd45b1a9c11
Author:    serb
Date:      2013-04-12 20:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffd45b1a9c11

8004866: [macosx] HiDPI support in Aqua L&F
Reviewed-by: swingler, alexsch

! src/macosx/classes/com/apple/laf/AquaPainter.java
! src/macosx/classes/com/apple/laf/ImageCache.java
! src/macosx/native/com/apple/laf/JRSUIController.m

Changeset: dcdf8cd4b09e
Author:    ant
Date:      2013-04-15 13:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcdf8cd4b09e

7147075: JTextField doesn't get focus or loses focus forever
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: 8fbe247ad2d8
Author:    lana
Date:      2013-04-17 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fbe247ad2d8

Merge

! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java

Changeset: bb098a221d85
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb098a221d85

Merge


Changeset: 4b8e606f8afb
Author:    lana
Date:      2013-04-17 21:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8e606f8afb

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
- src/share/native/java/lang/ResourceBundle.c
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 10ad4a4330bc
Author:    lana
Date:      2013-04-23 09:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10ad4a4330bc

Merge


Changeset: 57b02a7558f3
Author:    lana
Date:      2013-04-23 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57b02a7558f3

Merge

- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM



From mandy.chung at oracle.com  Tue Apr 23 23:43:04 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 23 Apr 2013 16:43:04 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51724434.10107@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com>
Message-ID: <51771C88.6060902@oracle.com>

Hi Peter,

Sorry for the delay.

On 4/20/2013 12:31 AM, Peter Levart wrote:
> Hi Mandy,
>
> I have another idea. Before jumping to implement it, I will first ask 
> what do you think of it. For example:
>
> - have an optimal interface names key calculated from interfaces.
> - visibility of interfaces and other validations are pushed to 
> slow-path (inside ProxyClassFactory.apply)
> - the proxy Class object returned from WeakCache.get() is 
> post-validated with a check like:
>
> for (Class intf : interfaces) {
>     if (!intf.isAssignableFrom(proxyClass)) {
>         throw new IllegalArgumentException();
>     }
> }
> // return post-validated proxyClass from getProxyClass0()...
>
> I feel that Class.isAssignableFrom(Class) check could be much faster 
> and that the only reason the check can fail is if some interface is 
> not visible from the class loader.
>
> Am I correct?

The isAssignableFrom check should be correct for well-behaved class 
loaders [1].  However, for non well-behaved class loaders, I'm not 
absolutely confident that this is right.  The case that I was concerned 
is when intf.isAssignableFrom(proxyClass) returns true but the proxy 
class doesn't implement the runtime types (i.e. given interfaces).   
Precise check should be to validate if the given interfaces == the proxy 
interfaces implemented by the cached proxy class (i.e. 
proxyClass.getInterfaces()).

Class.isAssignableFrom method checks if the proxy class is a subtype of 
the interface and no class loading/resolution involved.  It's definitely 
much cheaper than Class.forName which involves checking if a class is 
loaded (class loader delegation and class file search if not loaded - 
which is not the case you measure).

The existing implementation uses the interface names as the key to the 
per-loader proxy class cache.   I think we should use the Class[] as 
the key (your webrev.02).   I have quickly modified the version I sent 
you (simply change the Key class to use Class[] rather than String[] 
but didn't change the concurrent map cache to keep weak references) and 
the benchmark shows comparable speedup.

> I just noticed the following (have been thinking of it already, but 
> then forgot) in original code:
>
> /*
>  512              * Note that we need not worry about reaping the 
> cache for
>  513              * entries with cleared weak references because if a 
> proxy class
>  514              * has been garbage collected, its class loader will 
> have been
>  515              * garbage collected as well, so the entire cache 
> will be reaped
>  516              * from the loaderToCache map.
>  517              */
>
>

Hmm... I think the original code has the class loader leak.  The 
WeakHashMap, Class>> keeps a weak 
reference to the ClassLoader but a strong reference to the cache of the 
proxy classes that are defined by that class loader.  The proxy classes 
are not GC'ed and thus the class loader is still kept alive.


> Each ClassLoader maintains explicit hard-references to all Class 
> objects for classes defined by the loader. So proxy Class object can 
> not be GC-ed until the ClassLoader is GC-ed. So we need not register 
> the CacheValue objects in WeakCache with a refQueue. The expunging of 
> reverseMap entries is already performed with CacheKey when it is 
> cleared and equeued. There's no harm as it is, since the clean-up is 
> performed with all the checks and is idempotent, but it need not be 
> done for ClassValue objects holding weak references to proxy Class 
> objects.
>

As explained above, for the per-loader proxy class cache, both the key 
(interfaces) and the proxy class should be wrapped with weak reference.

In your revisions, you optimize for 0-interface and 1-interface proxy 
class.  What I hacked up earlier was just to use Class[] as the key 
(need to make a copy of the array to prevent that being mutated during 
runtime) that is a simpler and straightforward implementation.  I didn't 
measure the footprint and compare the performance of your versions.  
Have you seen any performance difference which led you to make the 
recent changes?

Mandy
[1] http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3


From joe.darcy at oracle.com  Tue Apr 23 23:54:11 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 23 Apr 2013 16:54:11 -0700
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <51769EB7.40204@oracle.com>
References: <51756103.6020409@oracle.com> <5175858F.5040003@oracle.com>
	<5175ED68.7010201@oracle.com> <51769EB7.40204@oracle.com>
Message-ID: <51771F23.50103@oracle.com>

Acknowledged; thanks for checking,

-Joe

On 4/23/2013 7:46 AM, Eric McCorkle wrote:
> I believe so.  Alex Buckley recommended the exact wording.
>
> On 04/22/13 22:09, Joseph Darcy wrote:
>> Hello,
>>
>>   240      * Returns the number of formal parameters (whether explicitly
>>   241      * declared or implicitly declared or neither) for the executable
>>
>> Are there parameters that are neither explicitly nor implicitly declared?
>>
>> I still think the follow comment is better deleted given the source that
>> follows it:
>>
>>   157         // If a parameter has no name, return argX, where x is the
>>   158         // index.
>>   159         //
>>
>> -Joe
>>
>> On 4/22/2013 11:46 AM, Eric McCorkle wrote:
>>> I have posted a newer version with some more edits.  Please review and
>>> suggest any further changes.
>>>
>>> http://cr.openjdk.java.net/~emc/8012937/webrev.01/
>>>
>>> On 04/22/13 12:10, Eric McCorkle wrote:
>>>> Hello,
>>>>
>>>> Please review this simple change, which corrects some errors in the
>>>> javadoc comments for method parameter reflection.
>>>>
>>>> Note that this changeset does not include any code changes.
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>>>>
>>>>
>>>> Also, if you have any additional issues with the javadoc comments,
>>>> please reply to this request with a description of the problem.
>>>>
>>>> Thanks,
>>>> Eric
>>>>



From bharadwaj.yadavalli at oracle.com  Wed Apr 24 01:26:05 2013
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Tue, 23 Apr 2013 21:26:05 -0400
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
In-Reply-To: <2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
References: <517173D4.1040207@oracle.com>
	<2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
Message-ID: <517734AD.8040302@oracle.com>

On 4/22/2013 2:06 PM, John Rose wrote:
> On Apr 19, 2013, at 9:41 AM, Bharadwaj Yadavalli  wrote:
>> I would like to request for a review of code changes made to support lambda related modifications to allow static and invokespecial calls to interface methods per spec version 0.6.2 (http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2.html). These changes support an upcoming change that compiles lambdas as private static methods in conjunction with hotspot changes pushed to address JDK-8006267.
> Looks good as far as it goes (to allow private lambda bodies to be accessed from interfaces).  But more work is needed to align the java.lang.invoke APIs with the new class file rules.
>
> In your code, I think the case 'refKind == REF_invokeSpecial' is missing. The draft JVMS implies REF_invokeSpecial is also allowed, since an interface method can be any of {public,private}+{static,non-static}.

Thanks for pointing it out. I modified the assertion in 
referenceKindIsConsistent() to allow REF_invokeSpecial to reference 
interface method. I have uploaded the modified webrev. Please review.

JBS : https://jbs.oracle.com/bugs/browse/JDK-8008687
Original Webrev : http://cr.openjdk.java.net/~bharadwaj/8008687/webrev_0/
Modified Webrev : http://cr.openjdk.java.net/~bharadwaj/8008687/webrev_1/

Reran lambda tests successfully.

> We should have unit tests for findStatic and findSpecial of interface methods.  (Also unreflect and unreflectSpecial.)
>
> But it is a step forward.  You can count me as a reviewer.  Please consider filing a followup bug to support the other new interface method kinds.

I have filed a new JBS issue.

Thanks again.

Bharadwaj



From john.r.rose at oracle.com  Wed Apr 24 01:53:07 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 23 Apr 2013 18:53:07 -0700
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
In-Reply-To: <517734AD.8040302@oracle.com>
References: <517173D4.1040207@oracle.com>
	<2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
	<517734AD.8040302@oracle.com>
Message-ID: <27D03E9B-E1DE-400F-827D-BEF5CD978604@oracle.com>

On Apr 23, 2013, at 6:26 PM, Bharadwaj Yadavalli  wrote:

> I modified the assertion in referenceKindIsConsistent() to allow REF_invokeSpecial to reference interface method. I have uploaded the modified webrev.

Good, thanks.  ? John

From john.r.rose at oracle.com  Wed Apr 24 01:57:52 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 23 Apr 2013 18:57:52 -0700
Subject: RFR(XS) : JDK-8008687 - MethodHandle code: allow static and
	invokespecial calls to interface methods
In-Reply-To: <517734AD.8040302@oracle.com>
References: <517173D4.1040207@oracle.com>
	<2FE50E73-5B31-4437-B078-EBC038138E5B@oracle.com>
	<517734AD.8040302@oracle.com>
Message-ID: <9767D03C-DA62-4CAA-80BC-4E4DA33303EB@oracle.com>

On Apr 23, 2013, at 6:26 PM, Bharadwaj Yadavalli  wrote:

> Reran lambda tests successfully.

Just in case, be sure the jtreg tests in test/java/lang/invoke/ also pass, with -ea -esa turned on.  That's probably already true, but if there is a false fire in the assertions, you'll want to catch it now.

? John

From mandy.chung at oracle.com  Wed Apr 24 05:33:38 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 23 Apr 2013 22:33:38 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51771C88.6060902@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
Message-ID: <51776EB2.80709@oracle.com>

More comments in addition to what I replied earlier....

On 4/23/2013 4:43 PM, Mandy Chung wrote:
>
>> Each ClassLoader maintains explicit hard-references to all Class 
>> objects for classes defined by the loader. So proxy Class object can 
>> not be GC-ed until the ClassLoader is GC-ed. 

AFAIU, a class loader will be GC'ed as long as there is no reference to 
any of its loaded classes.  The ClassLoader's internal vector of keeping 
the loaded classes is to prevent the classes from being GC'ed until the 
class loader is being GC'ed which will unload the classes.

So we should make the class loader and the proxy classes weak referenced 
so that they will be GC'ed properly.

>> So we need not register the CacheValue objects in WeakCache with a 
>> refQueue. The expunging of reverseMap entries is already performed 
>> with CacheKey when it is cleared and equeued. There's no harm as it 
>> is, since the clean-up is performed with all the checks and is 
>> idempotent, but it need not be done for ClassValue objects holding 
>> weak references to proxy Class objects.


I actually think we don't need to make CacheKey as a weak reference but 
the CacheValue object should still be registered in the refQueue.  The 
proxy class in the CacheValue implementing the given interfaces always 
reference the interfaces in the CacheKey and it means that the classes 
in the CacheKey will never be GC'ed before the proxy class.   When there 
is no reference to the proxy class, it will be added to the reference 
queue.  Once the entry with the CacheValue holding the proxy class is 
expunged,  the interfaces will not be referenced in the cache.

Does this make sense to you?
Mandy

>
> As explained above, for the per-loader proxy class cache, both the key 
> (interfaces) and the proxy class should be wrapped with weak reference.
>
> In your revisions, you optimize for 0-interface and 1-interface proxy 
> class.  What I hacked up earlier was just to use Class[] as the key 
> (need to make a copy of the array to prevent that being mutated during 
> runtime) that is a simpler and straightforward implementation.  I 
> didn't measure the footprint and compare the performance of your 
> versions.  Have you seen any performance difference which led you to 
> make the recent changes?
>
> Mandy
> [1] 
> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3



From peter.levart at gmail.com  Wed Apr 24 06:58:48 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 08:58:48 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51771C88.6060902@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
Message-ID: <517782A8.1010602@gmail.com>

Hi Mandy,

On 04/24/2013 01:43 AM, Mandy Chung wrote:
> Hi Peter,
>
> Sorry for the delay.
>
> On 4/20/2013 12:31 AM, Peter Levart wrote:
>> Hi Mandy,
>>
>> I have another idea. Before jumping to implement it, I will first ask 
>> what do you think of it. For example:
>>
>> - have an optimal interface names key calculated from interfaces.
>> - visibility of interfaces and other validations are pushed to 
>> slow-path (inside ProxyClassFactory.apply)
>> - the proxy Class object returned from WeakCache.get() is 
>> post-validated with a check like:
>>
>> for (Class intf : interfaces) {
>>     if (!intf.isAssignableFrom(proxyClass)) {
>>         throw new IllegalArgumentException();
>>     }
>> }
>> // return post-validated proxyClass from getProxyClass0()...
>>
>> I feel that Class.isAssignableFrom(Class) check could be much faster 
>> and that the only reason the check can fail is if some interface is 
>> not visible from the class loader.
>>
>> Am I correct?
>
> The isAssignableFrom check should be correct for well-behaved class 
> loaders [1].  However, for non well-behaved class loaders, I'm not 
> absolutely confident that this is right.  The case that I was 
> concerned is when intf.isAssignableFrom(proxyClass) returns true but 
> the proxy class doesn't implement the runtime types (i.e. given 
> interfaces).   Precise check should be to validate if the given 
> interfaces == the proxy interfaces implemented by the cached proxy 
> class (i.e. proxyClass.getInterfaces()).

Really? This can happen? Could you describe a situation when?

>
> Class.isAssignableFrom method checks if the proxy class is a subtype 
> of the interface and no class loading/resolution involved.  It's 
> definitely much cheaper than Class.forName which involves checking if 
> a class is loaded (class loader delegation and class file search if 
> not loaded - which is not the case you measure).
>
> The existing implementation uses the interface names as the key to the 
> per-loader proxy class cache.   I think we should use the Class[] 
> as the key (your webrev.02).   I have quickly modified the version I 
> sent you (simply change the Key class to use Class[] rather than 
> String[] but didn't change the concurrent map cache to keep weak 
> references) and the benchmark shows comparable speedup.
>
>> I just noticed the following (have been thinking of it already, but 
>> then forgot) in original code:
>>
>> /*
>>  512              * Note that we need not worry about reaping the 
>> cache for
>>  513              * entries with cleared weak references because if a 
>> proxy class
>>  514              * has been garbage collected, its class loader will 
>> have been
>>  515              * garbage collected as well, so the entire cache 
>> will be reaped
>>  516              * from the loaderToCache map.
>>  517              */
>>
>>
>
> Hmm... I think the original code has the class loader leak.  The 
> WeakHashMap, Class>> keeps a weak 
> reference to the ClassLoader but a strong reference to the cache of 
> the proxy classes that are defined by that class loader.  The proxy 
> classes are not GC'ed and thus the class loader is still kept alive.

Original code is actualy using the following structure: 
WeakHashMap, WeakReference>>
... so no ClassLoader leak here...

The TwoLevelWeakCache is an analogous structure: 
ConcurrentHashMap, ConcurrentHashMap>>

The point I was trying to make is that it is not needed to register a 
ReferenceQueue with WeakReference values and remove entries as 
they are cleared and enqueued, because they will not be cleared until 
the ClassLoader that defines the Class-es is GC-ed and the expunging 
logic can work solely on the grounds of cleared and enqueued 
WeakReference keys, which is what my latest webrev using 
String-based sub-keys does (I have to update the other too).

>
>
>> Each ClassLoader maintains explicit hard-references to all Class 
>> objects for classes defined by the loader. So proxy Class object can 
>> not be GC-ed until the ClassLoader is GC-ed. So we need not register 
>> the CacheValue objects in WeakCache with a refQueue. The expunging of 
>> reverseMap entries is already performed with CacheKey when it is 
>> cleared and equeued. There's no harm as it is, since the clean-up is 
>> performed with all the checks and is idempotent, but it need not be 
>> done for ClassValue objects holding weak references to proxy Class 
>> objects.
>>
>
> As explained above, for the per-loader proxy class cache, both the key 
> (interfaces) and the proxy class should be wrapped with weak reference.

Not the key (interfaces array) but the individual interface Class object 
- each has to be separately wrapped with a WeakReference. If you just do 
the WeakReference it will quickly be cleared since no-one is 
holding a strong reference to the array object.

The following webrev was an attempt in that direction (notice different 
name in URL: proxy-wc-wi - WeakCache-WeakInterfaces - I maintain 
separate numbering for webrevs in this branch):

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html


>
> In your revisions, you optimize for 0-interface and 1-interface proxy 
> class.  What I hacked up earlier was just to use Class[] as the key 
> (need to make a copy of the array to prevent that being mutated during 
> runtime) that is a simpler and straightforward implementation.  I 
> didn't measure the footprint and compare the performance of your 
> versions.  Have you seen any performance difference which led you to 
> make the recent changes?

I developed two different approaches:

1. Key made of WeakReference-s to interface Class objects.
Strong points:
- no key aliasing, validation can be pushed entirely to slow-path
- quick and scalable
- less memory usage than original code for 0 and 1-interface proxies
Weak points:
- more memory usage for 2+ -interface proxies
Latest webrev:
http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html
Comments:
   I like this one. If 2+ -interface proxies are relatively rare and you 
don't mind extra space consumption for them,  I would go with this approach.

2. Key made of interned Strings (names of interfaces)
Strong points:
- quick and scalable
- much less memory usage than original code for all variations of 
interface counts and in particular for 0, 1 and 2-interface proxies
Weak points:
- key is aliased, so the validation of interfaces has to be done - I 
tried to do it post-festum with intf.isAssignableFrom(proxyClass) but 
you say that is not reliable. If the validation is performed on 
fast-path before proxy class is obtained, using Class.forName, the 
slow-down is huge.
Latest webrev:
http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.03/index.html
Comments:
   This is the best space-saving approach. With tricks for single and 
two-interface keys, the savings are noticable.

So, I would really like to understand the situation where 
intf.isAssignableFrom(proxyClass) returns true, but proxyClass does not 
implement the interface. Maybe we could work-it out somehow.

Are you thinking of a situation like:

- intf1: pkg.Interface, loaded by classloader1
- intf2: pkg.SubInterface extends pkg.Interface, loaded by classloader1
- intf3: pkg.Interface extends pkg.SubInterface, loaded by classloader2 
which is child of classloader1

Now you call:

proxy3 = Proxy.getProxyClass(classloader2, intf3);

followed by:

proxy1 = Proxy.getProxyClass(classloader2, intf1);

Is it possible that the second call succeeds and returns proxy1 == proxy3 ?



Regards, Peter

>
> Mandy
> [1] http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3



From peter.levart at gmail.com  Wed Apr 24 07:13:31 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 09:13:31 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51776EB2.80709@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<51776EB2.80709@oracle.com>
Message-ID: <5177861B.4090307@gmail.com>


On 04/24/2013 07:33 AM, Mandy Chung wrote:
> More comments in addition to what I replied earlier....
>
> On 4/23/2013 4:43 PM, Mandy Chung wrote:
>>
>>> Each ClassLoader maintains explicit hard-references to all Class 
>>> objects for classes defined by the loader. So proxy Class object can 
>>> not be GC-ed until the ClassLoader is GC-ed. 
>
> AFAIU, a class loader will be GC'ed as long as there is no reference 
> to any of its loaded classes.  The ClassLoader's internal vector of 
> keeping the loaded classes is to prevent the classes from being GC'ed 
> until the class loader is being GC'ed which will unload the classes.
>
> So we should make the class loader and the proxy classes weak 
> referenced so that they will be GC'ed properly.

That's right.

>
>>> So we need not register the CacheValue objects in WeakCache with a 
>>> refQueue. The expunging of reverseMap entries is already performed 
>>> with CacheKey when it is cleared and equeued. There's no harm as it 
>>> is, since the clean-up is performed with all the checks and is 
>>> idempotent, but it need not be done for ClassValue objects holding 
>>> weak references to proxy Class objects.
>
>
> I actually think we don't need to make CacheKey as a weak reference 
> but the CacheValue object should still be registered in the refQueue.  
> The proxy class in the CacheValue implementing the given interfaces 
> always reference the interfaces in the CacheKey and it means that the 
> classes in the CacheKey will never be GC'ed before the proxy class.   
> When there is no reference to the proxy class, it will be added to the 
> reference queue.  Once the entry with the CacheValue holding the proxy 
> class is expunged,  the interfaces will not be referenced in the cache.

But! If the interface in the sub-key (the CacheKey in WeakCache is the 
1st-level key and is a WeakReference, the sub-key holds 
interfaces or interface names) happens to be loaded by the same 
ClassLoader as the proxy class, the ClassLoader will never be GC-ed and 
consequently the ClassValue will never be cleared and the entry will 
never be expunged... We have to wrap with a WeakReference:
- the ClassLoader
- each individual interface Class object
- proxy Class object

All 3 types of objects can have implicit or explicit strong references 
among them.

Regards, Peter

>
> Does this make sense to you?
> Mandy
>
>>
>> As explained above, for the per-loader proxy class cache, both the 
>> key (interfaces) and the proxy class should be wrapped with weak 
>> reference.
>>
>> In your revisions, you optimize for 0-interface and 1-interface proxy 
>> class.  What I hacked up earlier was just to use Class[] as the 
>> key (need to make a copy of the array to prevent that being mutated 
>> during runtime) that is a simpler and straightforward 
>> implementation.  I didn't measure the footprint and compare the 
>> performance of your versions.  Have you seen any performance 
>> difference which led you to make the recent changes?
>>
>> Mandy
>> [1] 
>> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3
>



From peter.levart at gmail.com  Wed Apr 24 07:16:43 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 09:16:43 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51771C88.6060902@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
Message-ID: <517786DB.8040900@gmail.com>


On 04/24/2013 01:43 AM, Mandy Chung wrote:
> Precise check should be to validate if the given interfaces == the 
> proxy interfaces implemented by the cached proxy class (i.e. 
> proxyClass.getInterfaces()).

Hi Mandy,

I will try to profile this approach as a post-validation and let you 
know the results.


Regards, Peter



From peter.levart at gmail.com  Wed Apr 24 08:11:26 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 10:11:26 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517782A8.1010602@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com>
Message-ID: <517793AE.2000405@gmail.com>


On 04/24/2013 08:58 AM, Peter Levart wrote:
>>
>> In your revisions, you optimize for 0-interface and 1-interface proxy 
>> class.  What I hacked up earlier was just to use Class[] as the 
>> key (need to make a copy of the array to prevent that being mutated 
>> during runtime) that is a simpler and straightforward 
>> implementation.  I didn't measure the footprint and compare the 
>> performance of your versions. *Have you seen any performance 
>> difference which led you to make the recent changes?*
>
> I developed two different approaches:
>
> 1. Key made of WeakReference-s to interface Class objects.
> Strong points:
> - no key aliasing, validation can be pushed entirely to slow-path
> - quick and scalable
> - less memory usage than original code for 0 and 1-interface proxies

That's the sole reason for optimized: WekaReferece -> 
WeakReference -> ... -> WeakReference linked list instead 
of the WeakReference[] array approach. And it's not using any 
recursion for equals/hashCode, so the peformance is comparable to array 
approach and it doesn't suffer from StackOverflowExceptions for lots of 
interfaces.

> Weak points:
> - more memory usage for 2+ -interface proxies
> Latest webrev:
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html
> Comments:
>   I like this one. If 2+ -interface proxies are relatively rare and 
> you don't mind extra space consumption for them,  I would go with this 
> approach.
>
> 2. Key made of interned Strings (names of interfaces)
> Strong points:
> - quick and scalable
> - much less memory usage than original code for all variations of 
> interface counts and in particular for 0, 1 and 2-interface proxies

The special-cased keys for 1 and 2-interface proxies (the most frequent) 
make for additional space savings.

> Weak points:
> - key is aliased, so the validation of interfaces has to be done - I 
> tried to do it post-festum with intf.isAssignableFrom(proxyClass) but 
> you say that is not reliable. If the validation is performed on 
> fast-path before proxy class is obtained, using Class.forName, the 
> slow-down is huge.
> Latest webrev:
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.03/index.html
> Comments:
>   This is the best space-saving approach. With tricks for single and 
> two-interface keys, the savings are noticable.


Regards, Peter



From alexey.utkin at oracle.com  Wed Apr 24 10:11:42 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Wed, 24 Apr 2013 14:11:42 +0400
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: 
References: <51768B23.6060506@oracle.com>
	
Message-ID: <5177AFDE.1030500@oracle.com>

Hi Martin,

On 23.04.2013 20:45, Martin Buchholz wrote:
> Random comments from a former maintainer:
>
> I was never brave enough to tackle windows argument parsing or trying 
> to change legacy behavior.
>
> I'm surprised you used LinkedList, which is almost never useful.  Why 
> not ArrayList?
Here is the parsing procedure with unpredictable number of tokens. "Add" 
operation is cheapest in the LinkedList container.

> Windows has arcane command line parsing rules, which are rather 
> difficult to get right, and I'm suspicious that you are not testing 
> for all of them (e.g. odd vs. even numbers of backslashes)
Yes, we cannot predict the Windows parsing result for arbitrary command 
line, because the Windows parsing process can involve procedure of  file 
existence checking that hard to repeat. But we cannot pass the command 
line to OS without modification due to security reasons.
As Alan wrote, we need to conserve backward compatibility for case of 
the quoted executable name (that is the only secure way to run that you 
like in legacy JDK) and  provide the allowAmbigousCommands property as a 
last resort.

Regards,
-uta

>
> Martin
>
>
> On Tue, Apr 23, 2013 at 6:22 AM, Alexey Utkin  > wrote:
>
>     Bug description:
>     https://jbs.oracle.com/bugs/browse/JDK-8012453
>     http://bugs.sun.com/view_bug.do?bug_id=8012453
>
>     Here is the suggested trivial fix:
>     http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.00/
>     
>
>     Summary:
>     ----------------------------------
>     Summary:
>            Since the changes for JDK-8005942/JDK-8009463 that commands
>     containing spaces cannot be used with Runtime.exec(String).
>     Applications should really specify the command and its arguments
>     using the Runtime.exec methods that take an array, or
>     alternatively use ProcessBuilder as recommended since jdk1.5.
>
>     Nevertheless we would like to minimize the impact for legacy
>     Windows OS Java application. For application that works without
>     the Security Manager, the "jdk.lang.Process.allowAmbigousCommands"
>     Java property could be defined programmatically or by program
>     switch [-Djdk.lang.Process.allowAmbigousCommands]. Definition of
>     the property returns old verification procedure for program name
>     and program arguments with full risk of security vulnerabilities.
>
>     For compatibility reason the case of quoted executable name in the
>     Runtime.exec(String ) was
>     supported. If the Security Manager is installed, it is called
>     twice for this case: for space-based paring result and result of
>     extended parsing procedure that takes quotation into account. We
>     do not guaranty the backward compatibility for any call with
>     quoted executable name, but in general it works.
>
>     Regards,
>     -uta
>
>



From peter.levart at gmail.com  Wed Apr 24 12:21:42 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 14:21:42 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517786DB.8040900@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517786DB.8040900@gmail.com>
Message-ID: <5177CE56.8070408@gmail.com>

On 04/24/2013 09:16 AM, Peter Levart wrote:
>
> On 04/24/2013 01:43 AM, Mandy Chung wrote:
>> Precise check should be to validate if the given interfaces == the 
>> proxy interfaces implemented by the cached proxy class (i.e. 
>> proxyClass.getInterfaces()).
>
> Hi Mandy,
>
> I will try to profile this approach as a post-validation and let you 
> know the results.
>

Hi Mandy,

Here's the modified webrev using optimized String-based sub-keys and 
pos-validation of proxyClass using proxyClass.getInterfaces():

https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.04/index.html

The benchmark results are the following:


Summary (4 Cores x 2 Threads i7 CPU):
                                                WeakCache+
                                         ns/op  Strings key+
Test                     Threads     Original  getIntfcs() post-valid.
=======================  =======  ===========  ===========
Proxy_getProxyClass            1     2,453.77       565.96
                                4     3,051.12       653.81
                                8     5,113.27     1,174.33

Proxy_isProxyClassTrue         1        94.96        41.47
                                4     2,102.29        41.57
                                8     4,823.50        71.80

Proxy_isProxyClassFalse        1        86.59         1.36
                                4     2,139.05         1.36
                                8     4,639.17         2.72

Annotation_equals              1       222.86       195.39
                                4     2,972.93       197.66
                                8     9,658.96       338.62


...  not that bad, but not so great either, compared to Weakly 
referenced interfaces-based sub-key and no post-validation:

WeakCache+
Test                     Threads  ns/op Original  intfcs key
=======================  =======  ============== ===========
Proxy_getProxyClass            1        2,403.27 163.57
                                4        3,039.01 211.70
                                8        5,193.58 322.14

Proxy_isProxyClassTrue         1           95.02 41.23
                                4        2,266.29 42.20
                                8        4,782.29 72.21

Proxy_isProxyClassFalse        1           95.02 1.36
                                4        2,186.59 1.36
                                8        4,891.15 2.72

Annotation_equals              1          240.10 194.61
                                4        1,864.06 198.81
                                8        8,639.20 342.90


Regards, Peter



From peter.levart at gmail.com  Wed Apr 24 12:44:44 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Apr 2013 14:44:44 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5177CE56.8070408@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517786DB.8040900@gmail.com> <5177CE56.8070408@gmail.com>
Message-ID: <5177D3BC.1020501@gmail.com>

Hi Mandy,

I have noticed recently on the hotspot-runime-dev mailing list: 
"RFR(XXS): 8012714: Assign the unique traceid directly to the Klass upon 
creation"...

Could this be accessed from Java? It looks like a perfect key to 
identify a class within a JVM. Can it be represented as int or long? 
That would map to int[] or long[] as a sub-key in the WeakCache?...

Regards, Peter



From staffan.larsen at oracle.com  Wed Apr 24 12:50:09 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 24 Apr 2013 12:50:09 +0000
Subject: hg: jdk8/tl/jdk: 8009985: [parfait] Uninitialised variable at
	jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
Message-ID: <20130424125031.3004648573@hg.openjdk.java.net>

Changeset: 754c9bb4f085
Author:    sla
Date:      2013-04-24 14:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/754c9bb4f085

8009985: [parfait] Uninitialised variable at jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
Reviewed-by: sla, rbackman, alanb, dholmes, rdurbin
Contributed-by: peter.allwin at oracle.com

! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c



From alexey.utkin at oracle.com  Wed Apr 24 12:58:20 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Wed, 24 Apr 2013 16:58:20 +0400
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <5176E367.9090601@oracle.com>
References: <51768B23.6060506@oracle.com> <5176E367.9090601@oracle.com>
Message-ID: <5177D6EC.8020304@oracle.com>

Thanks for clarification, Alan!

A part of the fix was not covered by summary, but need to be mentioned.
I changed in the ProcessBuilder class to restore the compatibility with 
Java documentation. In accordance with spec, the 
IllegalArgumentException exception could not be thrown from the start 
method. I made it a cause for declared IOException.

On 23.04.2013 23:39, Alan Bateman wrote:
> Alexey,
>
> I plan to review this, just don't have time to do a detailed review 
> today. At a high-level then I think the approach looks reasonable. If 
> someone has gone to the trouble of quoting a program path with spaces 
> in it, then the fallback should handle it. It's important that the 
> security manager's checkExec is called with the new path to the 
> program and I didn't see that when I skimmed over the changes.
You are right. The call was lost in the latest refactoring process for 
Java property.
Thanks for your attention. The test was extended to cover the case.

New version:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.01/

Lines 381-382 in ProcessImpl.java file are responsible for the second 
call to Security Manager.
The call with [".\Program Files\doNot.cmd" arg] param does not pass the 
second Security Manager verification in the ExecCommand.java test.

-uta

>
> The truly ambiguous and legacy cases is difficult but we know that 
> there are still applications using these JDK1.0 area APIs. The 
> allowAmbigousCommands property is probably okay as a last resort.
>
> -Alan
>
>
> On 23/04/2013 14:22, Alexey Utkin wrote:
>> Bug description:
>> https://jbs.oracle.com/bugs/browse/JDK-8012453
>> http://bugs.sun.com/view_bug.do?bug_id=8012453
>>
>> Here is the suggested trivial fix:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.00/
>>
>> Summary:
>> ----------------------------------
>> Summary:
>>        Since the changes for JDK-8005942/JDK-8009463 that commands 
>> containing spaces cannot be used with Runtime.exec(String). 
>> Applications should really specify the command and its arguments 
>> using the Runtime.exec methods that take an array, or alternatively 
>> use ProcessBuilder as recommended since jdk1.5.
>>
>> Nevertheless we would like to minimize the impact for legacy Windows 
>> OS Java application. For application that works without the Security 
>> Manager, the "jdk.lang.Process.allowAmbigousCommands" Java property 
>> could be defined programmatically or by program switch 
>> [-Djdk.lang.Process.allowAmbigousCommands]. Definition of the 
>> property returns old verification procedure for program name and 
>> program arguments with full risk of security vulnerabilities.
>>
>> For compatibility reason the case of quoted executable name in the 
>> Runtime.exec(String ) was 
>> supported. If the Security Manager is installed, it is called twice 
>> for this case: for space-based paring result and result of extended 
>> parsing procedure that takes quotation into account. We do not 
>> guaranty the backward compatibility for any call with quoted 
>> executable name, but in general it works.
>>
>> Regards,
>> -uta 
>



From Alan.Bateman at oracle.com  Wed Apr 24 13:19:03 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 14:19:03 +0100
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5176DE7C.8060404@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com>
Message-ID: <5177DBC7.8000605@oracle.com>

On 23/04/2013 20:18, Akhil Arora wrote:
> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>> One thing I meant to ask when forEachRemaining was added was whether it
>> should say anything about the "last element"? I see in the webrev that
>> you've set it for the ArrayList iterators but not the LinkedList
>> iterator - should it?
>
> done, and added more tests for the state of the iterator after 
> forEachRemaining returns
>
> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>
> (a portion of version 1 of the webrev has already been pushed to TL as 
> part of rev 6973 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
The remaining changes in the webrev looks okay to me. Also good to have 
the test expanded.

So do you think that the javadoc should say anything about the 
relationship between forEachRemaining and remove?

-Alan.



From aleksej.efimov at oracle.com  Wed Apr 24 13:53:08 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 24 Apr 2013 17:53:08 +0400
Subject: RFR 8009581: Xpathexception does not honor initcause()
Message-ID: <5177E3C4.3090703@oracle.com>

Hi all,

Can I have a reviews for the following change:
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ 


Summary:
There is an erroneous behavior in 'initCause' method of 
javax.xml.xpath.XPathException class.
Lets look at the following situation:
XPathException is created with 'XPathException(String )' constructor and 
then the cause is initialized with 'initCause' method. Such 
initialization sequence of actions isn't restricted by XPathException 
[1] and Throwable [2] docs.
After that a cause is retrieved by 'getCause()' method: this call 
returns incorrect cause = 'null'. It should return the same cause as was 
used in 'initCause'.  And this is the erroneous behavior.

Suggested fix (with regression test) is applicable both for JDK 8 and 7.

Regards,
-Aleksej


[1] 
http://download.java.net/jdk8/docs/api/javax/xml/xpath/XPathException.html
[2] 
http://download.java.net/jdk8/docs/api/java/lang/Throwable.html#initCause(java.lang.Throwable) 

[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009581


From Alan.Bateman at oracle.com  Wed Apr 24 13:54:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 14:54:22 +0100
Subject: RFR: JDK-8012650 and JDK-8011918
In-Reply-To: <5177149B.1080407@oracle.com>
References: <5177149B.1080407@oracle.com>
Message-ID: <5177E40E.7020405@oracle.com>

On 24/04/2013 00:09, Henry Jen wrote:
> Hi,
>
> Please review static Stream factory methods and methods for Arrays.
> Webrev is at
>
> http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.0
>
> Stream methods are covered in a test suite which will be put back soon
> once all depends part is in place.
>
> Arrays setAll and parallelSetAll methods has test included.
>
> Cheers,
> Henry
I went over the webrev and don't see anything obviously wrong.

Will you add the @since 1.8 to the Arrays methods before pushing this? 
The stream methods have it, just not the setAll/parallelSetAll.

Another minor comment is that the stream methods specify NPE but that 
isn't strictly requires as the Arrays class has a statement in the class 
description to say that all methods throw NPE if the array reference is 
null.

-Alan.




From Alan.Bateman at oracle.com  Wed Apr 24 14:23:55 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 15:23:55 +0100
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <5177D6EC.8020304@oracle.com>
References: <51768B23.6060506@oracle.com> <5176E367.9090601@oracle.com>
	<5177D6EC.8020304@oracle.com>
Message-ID: <5177EAFB.7000803@oracle.com>

On 24/04/2013 13:58, Alexey Utkin wrote:
>
> I changed in the ProcessBuilder class to restore the compatibility 
> with Java documentation. In accordance with spec, the 
> IllegalArgumentException exception could not be thrown from the start 
> method. I made it a cause for declared IOException.
This part looks good to me.


>
> Thanks for your attention. The test was extended to cover the case.
>
> New version:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.01/
>
> Lines 381-382 in ProcessImpl.java file are responsible for the second 
> call to Security Manager.
> The call with [".\Program Files\doNot.cmd" arg] param does not pass 
> the second Security Manager verification in the ExecCommand.java test.
Overall I think this looks okay.

In getTokensFromCommand then I guess I would have used a regex rather 
than legacy StringTokenizer (I realize Runtime is specified to use 
StringTokenizer for the initial split). I think I agree with Martin on 
wondering why LinkedList is used but it's not an issue as this is the 
fallback. Minor nit is that the brace on L161 can be moved to the end of 
the previous line.

A minor comment is that -Djdk.lang.Process.allowAmbigousCommands=false 
will not do what is intended (the value of the property is not examined).

The test needs a copyright header but otherwise looks comprehensive. One 
thing I see is that it doesn't read from the child's output/error 
streams so if there is a problem then it will be hard to diagnose from 
the logs.

Minor comments on the test is that the creation of the commands could 
use try-with-resources.

-Alan.





From Alan.Bateman at oracle.com  Wed Apr 24 15:08:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 16:08:26 +0100
Subject: Codereview request: 8012638:
	test/java/time/test/java/util/TestFormatter fails in UTC TZ
In-Reply-To: <51758254.5070000@oracle.com>
References: <51758254.5070000@oracle.com>
Message-ID: <5177F56A.5050701@oracle.com>

On 22/04/2013 19:32, Xueming Shen wrote:
> Hi,
>
> This is a "test regression" caused by the JSR310 latest push into TL 
> repository, in which
> the timezone name handling is slightly different for those "special" 
> timezone name such
> as UTC, GMT and UT. The offending test case has not been updated 
> accordingly (the test
> case had the old workaround to map the UTC/GMT/UT back to JSR310 
> specific "Z" for the
> golden data, which is no longer needed in the latest JSR310 
> spec/implementation), so
> it fails on env/conf that has the TZ configured to UTC/GMT/UT, which 
> is likely on some
> server machines, like our JPRT solaris machines. The proposed change 
> has been reviewed
> and pushed into JSR310 repo already, guess it might be preferred to 
> push this test case
> only/simple fix into the TL to remove the test/nightly test failure.
>
> http://cr.openjdk.java.net/~sherman/8012638/webrev
This looks okay to me. The test should probably list 8003680 before bugs 
for subsequent changes.

-Alan.


From Alan.Bateman at oracle.com  Wed Apr 24 16:15:13 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 17:15:13 +0100
Subject: 8005555: TEST_BUG:
	java/io/Serializable/accessConstants/AccessConstants.java
	can probably be removed
Message-ID: <51780511.1090300@oracle.com>


This test has been failing recently for me with the error "No action 
after @build", I think possibly related to an update in jtreg (I built 
jtreg from code-tools-jtreg).

The test is a compile-only test, it doesn't actually run or do anything. 
It basically just tests that ObjectStreamConstants constants are public 
and so would fail to compile if something removed these constants from 
the API.

We can trivially replace the @build with a @compile tag but I'm not sure 
that the test has any value. Instead I suggest we just remove it, as in:

hg rm test/java/io/Serializable/accessConstants/AccessConstants.java

Any objections?

-Alan.


From chris.hegarty at oracle.com  Wed Apr 24 16:34:45 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 24 Apr 2013 17:34:45 +0100
Subject: 8005555: TEST_BUG:
	java/io/Serializable/accessConstants/AccessConstants.java
	can probably be removed
In-Reply-To: <51780511.1090300@oracle.com>
References: <51780511.1090300@oracle.com>
Message-ID: <517809A5.4080107@oracle.com>

On 04/24/2013 05:15 PM, Alan Bateman wrote:
>
> This test has been failing recently for me with the error "No action
> after @build", I think possibly related to an update in jtreg (I built
> jtreg from code-tools-jtreg).
>
> The test is a compile-only test, it doesn't actually run or do anything.
> It basically just tests that ObjectStreamConstants constants are public
> and so would fail to compile if something removed these constants from
> the API.
>
> We can trivially replace the @build with a @compile tag but I'm not sure
> that the test has any value. Instead I suggest we just remove it, as in:
>
> hg rm test/java/io/Serializable/accessConstants/AccessConstants.java
>
> Any objections?

Not from me. In fact, I'd be happy for it to be removed.

-Chris.

>
> -Alan.


From eric.mccorkle at oracle.com  Wed Apr 24 16:35:15 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 24 Apr 2013 12:35:15 -0400
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <51771F23.50103@oracle.com>
References: <51756103.6020409@oracle.com> <5175858F.5040003@oracle.com>
	<5175ED68.7010201@oracle.com> <51769EB7.40204@oracle.com>
	<51771F23.50103@oracle.com>
Message-ID: <517809C3.2060703@oracle.com>

Any further comments, or is this one good to go?

On 04/23/13 19:54, Joseph Darcy wrote:
> Acknowledged; thanks for checking,
> 
> -Joe
> 
> On 4/23/2013 7:46 AM, Eric McCorkle wrote:
>> I believe so.  Alex Buckley recommended the exact wording.
>>
>> On 04/22/13 22:09, Joseph Darcy wrote:
>>> Hello,
>>>
>>>   240      * Returns the number of formal parameters (whether explicitly
>>>   241      * declared or implicitly declared or neither) for the
>>> executable
>>>
>>> Are there parameters that are neither explicitly nor implicitly
>>> declared?
>>>
>>> I still think the follow comment is better deleted given the source that
>>> follows it:
>>>
>>>   157         // If a parameter has no name, return argX, where x is the
>>>   158         // index.
>>>   159         //
>>>
>>> -Joe
>>>
>>> On 4/22/2013 11:46 AM, Eric McCorkle wrote:
>>>> I have posted a newer version with some more edits.  Please review and
>>>> suggest any further changes.
>>>>
>>>> http://cr.openjdk.java.net/~emc/8012937/webrev.01/
>>>>
>>>> On 04/22/13 12:10, Eric McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this simple change, which corrects some errors in the
>>>>> javadoc comments for method parameter reflection.
>>>>>
>>>>> Note that this changeset does not include any code changes.
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>>>>>
>>>>>
>>>>> Also, if you have any additional issues with the javadoc comments,
>>>>> please reply to this request with a description of the problem.
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
> 

From akhil.arora at oracle.com  Wed Apr 24 17:24:44 2013
From: akhil.arora at oracle.com (Akhil Arora)
Date: Wed, 24 Apr 2013 10:24:44 -0700
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5177DBC7.8000605@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
Message-ID: <5178155C.6050600@oracle.com>

On 04/24/2013 06:19 AM, Alan Bateman wrote:
> On 23/04/2013 20:18, Akhil Arora wrote:
>> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>>> One thing I meant to ask when forEachRemaining was added was whether it
>>> should say anything about the "last element"? I see in the webrev that
>>> you've set it for the ArrayList iterators but not the LinkedList
>>> iterator - should it?
>>
>> done, and added more tests for the state of the iterator after
>> forEachRemaining returns
>>
>> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>>
>> (a portion of version 1 of the webrev has already been pushed to TL as
>> part of rev 6973 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
> The remaining changes in the webrev looks okay to me. Also good to have
> the test expanded.
>
> So do you think that the javadoc should say anything about the
> relationship between forEachRemaining and remove?

Good question. forEachRemaining docs state -

Implementation Requirements:

     The default implementation behaves as if:

     while (hasNext())
              action.accept(next());

so a subsequent remove() should remove the last element.

To avoid blocking the feature, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of 
remove and other ListIterator methods after forEachRemaining returns.


From forax at univ-mlv.fr  Wed Apr 24 17:57:24 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 Apr 2013 19:57:24 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5178155C.6050600@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com>
Message-ID: <51781D04.7000907@univ-mlv.fr>

On 04/24/2013 07:24 PM, Akhil Arora wrote:
> On 04/24/2013 06:19 AM, Alan Bateman wrote:
>> On 23/04/2013 20:18, Akhil Arora wrote:
>>> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>>>> One thing I meant to ask when forEachRemaining was added was 
>>>> whether it
>>>> should say anything about the "last element"? I see in the webrev that
>>>> you've set it for the ArrayList iterators but not the LinkedList
>>>> iterator - should it?
>>>
>>> done, and added more tests for the state of the iterator after
>>> forEachRemaining returns
>>>
>>> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>>>
>>> (a portion of version 1 of the webrev has already been pushed to TL as
>>> part of rev 6973 
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
>> The remaining changes in the webrev looks okay to me. Also good to have
>> the test expanded.
>>
>> So do you think that the javadoc should say anything about the
>> relationship between forEachRemaining and remove?
>
> Good question. forEachRemaining docs state -
>
> Implementation Requirements:
>
>     The default implementation behaves as if:
>
>     while (hasNext())
>              action.accept(next());
>
> so a subsequent remove() should remove the last element.
>
> To avoid blocking the feature, I have filed
> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior 
> of remove and other ListIterator methods after forEachRemaining returns.

I think the fact that the last element can be removed should be 
specified as unspecified,
because it's more an artefact of the default implementation than 
something which part
of the semantics.

R?mi






From Alan.Bateman at oracle.com  Wed Apr 24 17:58:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 18:58:07 +0100
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <5178155C.6050600@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com>
Message-ID: <51781D2F.4090002@oracle.com>

On 24/04/2013 18:24, Akhil Arora wrote:
>
> Good question. forEachRemaining docs state -
>
> Implementation Requirements:
>
>     The default implementation behaves as if:
>
>     while (hasNext())
>              action.accept(next());
>
> so a subsequent remove() should remove the last element.
That specifies how the default implementation behaves rather than the 
general contract so I think it would be good to re-look at when there is 
time.

-Alan


From Alan.Bateman at oracle.com  Wed Apr 24 18:17:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Apr 2013 19:17:47 +0100
Subject: RFR 8009581: Xpathexception does not honor initcause()
In-Reply-To: <5177E3C4.3090703@oracle.com>
References: <5177E3C4.3090703@oracle.com>
Message-ID: <517821CB.70608@oracle.com>

On 24/04/2013 14:53, Aleksej Efimov wrote:
> Hi all,
>
> Can I have a reviews for the following change:
> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ 
> 
>
> Summary:
> There is an erroneous behavior in 'initCause' method of 
> javax.xml.xpath.XPathException class.
> Lets look at the following situation:
> XPathException is created with 'XPathException(String )' constructor 
> and then the cause is initialized with 'initCause' method. Such 
> initialization sequence of actions isn't restricted by XPathException 
> [1] and Throwable [2] docs.
> After that a cause is retrieved by 'getCause()' method: this call 
> returns incorrect cause = 'null'. It should return the same cause as 
> was used in 'initCause'.  And this is the erroneous behavior.
>
> Suggested fix (with regression test) is applicable both for JDK 8 and 7.
Exceptions are serializable so I think this may require further 
investigation to see if a readObject/writeObject is required.

-Alan.


From alan.bateman at oracle.com  Wed Apr 24 18:43:38 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 24 Apr 2013 18:43:38 +0000
Subject: hg: jdk8/tl/jdk: 8005555: TEST_BUG:
	java/io/Serializable/accessConstants/AccessConstants.java
	should be removed
Message-ID: <20130424184350.EB00E48588@hg.openjdk.java.net>

Changeset: bbcebf893b83
Author:    alanb
Date:      2013-04-24 19:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbcebf893b83

8005555: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java should be removed
Reviewed-by: chegar

- test/java/io/Serializable/accessConstants/AccessConstants.java



From mandy.chung at oracle.com  Wed Apr 24 20:07:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 Apr 2013 13:07:28 -0700
Subject: RFR: 7150256: 	Add back Diagnostic Command JMX API
In-Reply-To: <517001CD.2080109@oracle.com>
References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com>
	<50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com>
	<517001CD.2080109@oracle.com>
Message-ID: <51783B80.5010807@oracle.com>

Hi Frederic,

I reviewed the jdk webrev that is looking good.  I reviewed 
com.sun.management.DiagnosticCommandMBean spec almost half a year ago.  
Reviewing it now with a fresh memory has some benefit that I have a few 
comments on the spec.

java.lang.management.PlatformManagedObject is specified as JMX MXBean 
while dynamic mbean is not a MXBean.  You have modified 
ManagementFactory.getPlatformManagementInterfaces() to return the 
DiagnosticCommandMBean which I agree it is the right thing to do.

The PlatformManagedObject spec should be revised to cover dynamic mbeans 
for this extension.  The primary requirement for the platform mbeans is 
to be interoperable so that a JMX client can access the platform mbeans 
in a JVM running with a different JRE version (old or new) in which the 
types are not required to be present in the JMX client.

ManagementFactory.getPlatformMXBean(DiagnosticCommandMBean.class) and 
the getPlatformMXBeans method should throw IAE.  I think the existing 
implementation already does that correctly but better to have a test to 
catch that.  The spec says @throws IAE if the mxbeaninterface is not a 
platform management interface.  The method name is very explict about 
MXBean and so the @throws javadoc should be clarified it's not a 
platform MXBean.

What will be the way to obtain DiagnosticCommandMBean?

Your DiagnosticCommandAsPlatformMBeanTest calls 
ManagementFactory.getPlatformMXBean(DiagnosticCommandMBean.class) and 
expect it to work. I think it should throw IAE instead. Nit: the 
HOTSPOT_DIAGNOSTIC_MXBEAN_NAME field was leftover from your previous 
version and should be removed.

DiagnosticCommandMBean specifies the meta-data of the diagnostic command 
and the option/argument the command takes.  Have you considering 
defining interfaces/abstract class for DiagnosticCommandInfo and 
DiagnosticCommandArgumentInfo for a client to implement for parsing the 
meta-data and maybeproviding factory methods? It's very easy to make 
mistake without any API support.  The spec is definitely not easy to 
read :)

dcmd.arg.type may be non-Java type.  What are the examples?  For Java 
types, I suggest to use the type signatures as defined in JNI and 
consistent with the standard representation:
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html#wp276

dcmdArgInfo.position - would it be better to define a value (e.g. -1) if 
dcmdArgInfo.option is set to true so that assertion can be added if desired.

dcmd.permissionClass - s/class name/fully-qualified class name

The comment on java.lang.management spec needs to be addressed for this 
change.  As for the comments on DiagnosticCommandMBean, it's fine with 
me to integrate your current DiagnosticCommandMBean and follow up to 
make the spec enhancement, if appropriate, as a separate changeset.

Is DiagnosticCommandMBean target for 7u?  It has @since 8.

The javadoc for DiagnosticCommandMBean should include more links such as
    platform mbeanserver 
(java.lang.management.ManagementFactory.getPlatformMBeanServer)
    descriptor, parameter, etc, and the methods such as getName, 
getDescription, etc
    "jmx.mbean.info.changed" (MBeanInfo)

    replace .. with {@code ..}
line 32: It is a management interface.  Perhaps the first sentence 
should be:
     Management interface for the diagnostic commands for the HotSpot 
Virtual Machine.

Here are my comments on the implementation:
sun/management/ManagementFactoryHelper.java
    line 380: missing space between 'if' and '('

sun/management/DiagnosticCommandImpl.java
    set/getAttribute(s) methods should throw AttributeNotFoundException 
instead of UOE?

line 164-181: can replace the if-statement by using ?: shorthand

line 445-447: space around the binary operators '==', '?', '"' in the 
4th argument of the MBeanOperationInfo constructor.

sun/management/VMManagement.java, VMManagementImpl.java and 
VMManagementImpl.c
  108     // Diagnostic Commands support
  109     public String[]                getDiagnosticCommands();
  110     public DiagnosticCommandInfo[] 
getDiagnosticCommandInfo(String[] commands);
  111     public String executeDiagnosticCommand(String command);

These native methods are more appropriate to belong in 
DiagnosticCommandImpl which already has one native method.

In the native methods getDiagnosticCommandInfo, executeDiagnosticCommand,
getDiagnosticCommandArgumentInfoArray, you check if rdcmd_support is 
supported and throws UOE if not. A running VM supporting the remote 
diagnostic command will not change during its lifetime, right?  Then I 
suggest to check it in the Java level first calls 
VMManagement.isRemoteDiagnosticCommandsSupported before calling the 
native method. GetOptionalSupport is called during class initialization 
to cache the values in Java to avoid fetching the value multiple time.

test/java/lang/management/MXBean/MXBeanBehavior.java
   line 39: diamond operator
   Since the test is for MXBeans, it's more appropriate to exclude 
non-MXBean from this test or rename the test to cover the new platform 
mbeans.


On 4/18/2013 7:23 AM, frederic parain wrote:
>>
>> DiagnosticCommandImpl.Wrapper class
>>     If there is any issue initializing the diagnostic command, it
>> ignores the exception.  That makes it very hard to diagnose when things
>> go wrong.  This exports diagnostic commands supported by the running JVM
>> and so I would think any error would be a bug.
>
> An exception when creating the Wrapper doesn't necessarily mean a bug.
> The call to get the list of diagnostic commands and the call to get
> the descriptions of these commands cannot be performed in an atomic
> way. Because the diagnostic command framework allows dynamic
> addition and removal of commands, a command might "disappear" between
> the two calls. In this case, the creation of the wrapper for this
> command will fail, but this shouldn't be considered as a bug.
>

Can you add the comment there describing why the exception is ignored.  
I'm not sure under what circumstances the exception is expected or not.

The Wrapper constructor throws InstantiationException when it fails to 
initialize the permission class but  getMBeanInfo() ignores 
InstantiationException.  It seems a bug in the implementation to me?  If 
IAE and UOE during initiatizing the diagnostic commands, it returns an 
empty one that seems okay.    Comments to explain that would help.

>
>> The new tests hardcode the port number that is unreliable and may fail
>> in nightly/jprt testing (e.g. the port is occupied by another test
>> run).   Some management tests have the same reliability issue and I'm
>> not sure what the state is right now.  It'd be good if the new tests can
>> avoid using hardcode port number.
>
> I don't know how to avoid the hardcoding of the port without wrapping
> the test in a shell scripts. Is there a template available to do
> dynamic port allocation?

I skimmed on some existing tests but not able to find the example. I 
think it's still a clean up task to be done.  It's fine with me if you 
do this test cleanup later and we probably need to write a test library 
to help this.

Mandy


From jim.gish at oracle.com  Wed Apr 24 21:23:00 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 24 Apr 2013 17:23:00 -0400
Subject: RFR:7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
Message-ID: <51784D34.60806@oracle.com>

Please review 
http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-failure.1/ 


This is a simple fix that removes a long-standing bug in acquiring a 
using the global Logger in which Logger.getGlobal().info() (for 
example), would not log without additional configuration that would 
trigger LogManager initialization.  I have also added a test to reassure 
us that I have not introduced a deadlock between LogManager 
initialization and getting the global logger.

In addition, I've introduced a utility class I developed during a recent 
fix to a logging deadlock, which helps us detect and report on the 
details of a deadlock.

Thanks,
    Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From xueming.shen at oracle.com  Wed Apr 24 21:28:42 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 24 Apr 2013 21:28:42 +0000
Subject: hg: jdk8/tl/jdk: 8012638: test/java/time/test/java/util/TestFormatter
	fails in UTC TZ
Message-ID: <20130424212905.4C5E148596@hg.openjdk.java.net>

Changeset: 8c06a38aa2c5
Author:    sherman
Date:      2013-04-24 21:27 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c06a38aa2c5

8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ
Summary: updated the offending test case
Reviewed-by: alanb

! test/java/time/test/java/util/TestFormatter.java



From brian.burkhalter at oracle.com  Wed Apr 24 21:57:43 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 24 Apr 2013 14:57:43 -0700
Subject: Re-Review: 7032154 - Performance tuning of
	sun.misc.FloatingDecimal/FormattedFloatingDecimal
Message-ID: <14C2EBA8-C864-4274-8432-34EC43A6762E@oracle.com>

Hello,

Re-post of the proposed fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032154.

The updated webrev is at http://cr.openjdk.java.net/~bpb/7032154/.

Since this change proposal was originally posted, more extensive review and testing has been performed, a couple of bugs found and fixed, and the code cleaned up substantially, primarily in terms of style and documentation.

Please review at your convenience. Hopefully this time the change will be deemed acceptable and we can move on.

Some statistics about the changes are included below. I hope that the formatting survives auto-forwarding ...

Thanks,

Brian

~~~~~

--- Lines of code ---

Net code reduction of 448 lines based on cloc (http://cloc.sourceforge.net) v 1.56:

File														Before		After
src/share/classes/java/util/Formatter.java					1974		1944
src/share/classes/sun/misc/FloatingDecimal.java				1369		1329
src/share/classes/sun/misc/FormattedFloatingDecimal.java	1104		269
src/share/classes/sun/misc/FDBigInt.java					330			0
src/share/classes/sun/misc/FDBigInteger.java				0			787
										Total (-448)		4777		4329

--- Microbenchmarking Results (operations / millisecond) ---

Dual Core MacBookPro5,3
JDK 8 64-bit fastdebug server
Server VM (-server)

-- Single Threaded

Test											Before		After		Change (%)
decimalFormatFormatDouble					37.138		54.551		+47
decimalFormatFormatObjectDouble			37.604		54.988		+46
decimalFormatFormatObjectFloat				77.850		106.716		+37
decimalFormatFormatToCharIteratorDouble		1.359		1.352		-0.5
decimalFormatFormatToCharIteratorFloat		8.293		8.421		+1.5
doubleToStringFast							2553.488	4006.301	+57
doubleToStringFastIterative					1776.017	2304.943	+30
doubleToStringSlowIterative					91.069		314.900		+46
floatToStringFast								3320.959	5398.451	+63
floatToStringFastIterative						2898.135	4498.891	+55
floatToStringSlowIterative						351.807		841.788		+39
formatterFormatDouble						34.628		53.091		+53
formatterFormatFloat							77.532		115.328		+49
parseDoubleFast								6600.946	8163.202	+24
parseDoubleFastIterative						3037.867	4397.148	+47
parseDoubleHex								152.875		565.412		+270
parseDoubleSlowIterative						357.848		760.584		+113
parseFloatFast								6679.775	8342.373	+25
parseFloatFastIterative						3627.009	4672.158	+29
parseFloatHex								151.791		567.527		+274
parseFloatSlowIterative						960.797		1497.473	+56
stringBufferAppendDouble					82.135		244.290		+197
stringBufferAppendFloat						280.669		599.049		+113
stringBuilderAppendDouble					82.102		246.431		+200
stringBuilderAppendFloat						284.135		613.715		+116

-- Two Threads on Dual Core MacBookPro5,3

Parenthetical values indicate change versus the same test on a single thread.

Test											Before			After
decimalFormatFormatDouble					57.038 (1.54)	89.872 (1.65)
decimalFormatFormatObjectDouble			58.337 (1.55)	90.631 (1.65)
decimalFormatFormatObjectFloat				121.016 (1.55)	179.136 (1.68)
decimalFormatFormatToCharIteratorDouble		1.826 (1.34)		1.885 (1.39)
decimalFormatFormatToCharIteratorFloat		11.717 (1.41)	12.316 (1.46)
doubleToStringFast							3645.053 (1.43)	6275.872 (1.57)
doubleToStringFastIterative					2874.118 (1.62)	4013.234 (1.74)
doubleToStringSlowIterative					130.749 (1.44)	548.555 (1.74)
floatToStringFast								4759.219 (1.43)	8427.571 (1.56)
floatToStringFastIterative						4148.118 (1.43)	7042.274 (1.56)
floatToStringSlowIterative						509.901 (1.45)	1399.959 (1.663)
formatterFormatDouble						50.776 (1.47)	79.339 (1.49)
formatterFormatFloat							113.682 (1.47)	173.964 (1.51)
parseDoubleFast								9726.542 (1.47)	12194.055 (1.49)
parseDoubleFastIterative						4950.301 (1.63)	6812.298 (1.55)
parseDoubleHex								243.253 (1.59)	903.218 (1.60)
parseDoubleSlowIterative						500.704 (1.40)	1101.429 (1.45)
parseFloatFast								9759.319 (1.46)	12398.548 (1.49)
parseFloatFastIterative						5903.467 (1.63)	7489.077 (1.61)
parseFloatHex								239.219 (1.58)	914.947 (1.61)
parseFloatSlowIterative						1434.349 (1.49)	2236.705 (1.49)
stringBufferAppendDouble					118.747 (1.45)	424.010 (1.74)
stringBufferAppendFloat						407.550 (1.45)	1020.185 (1.70)
stringBuilderAppendDouble					118.506 (1.44)	427.533 (1.73)
stringBuilderAppendFloat						409.844 (1.44)	1034.202 (1.69)



From mandy.chung at oracle.com  Wed Apr 24 22:01:16 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 Apr 2013 15:01:16 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517782A8.1010602@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com>
Message-ID: <5178562C.2030007@oracle.com>


On 4/23/2013 11:58 PM, Peter Levart wrote:
>> The isAssignableFrom check should be correct for well-behaved class 
>> loaders [1].  However, for non well-behaved class loaders, I'm not 
>> absolutely confident that this is right.  The case that I was 
>> concerned is when intf.isAssignableFrom(proxyClass) returns true but 
>> the proxy class doesn't implement the runtime types (i.e. given 
>> interfaces).   Precise check should be to validate if the given 
>> interfaces == the proxy interfaces implemented by the cached proxy 
>> class (i.e. proxyClass.getInterfaces()).
>
> Really? This can happen? Could you describe a situation when?
> Are you thinking of a situation like:
>
> - intf1: pkg.Interface, loaded by classloader1
> - intf2: pkg.SubInterface extends pkg.Interface, loaded by classloader1
> - intf3: pkg.Interface extends pkg.SubInterface, loaded by 
> classloader2 which is child of classloader1
>

Similar but classloader2 is non well-behaved classloader e.g. doesn't 
have relationship with classloader1; otherwise I don't think it's 
possible to define intf3 (classloader1.loadClass("pkg.Interface") should 
be resolved with intf1 instead (not its own defined pkg.Interface).

I haven't been able to identify such a case but I wasn't able to prove 
it not possible either as it is subject to non well-behaved class loader 
behavior :)

The isAssignableFrom method returns true not only if it's identical but 
also if it's a superinterface that a class implements.
> Now you call:
>
> proxy3 = Proxy.getProxyClass(classloader2, intf3);
>
> followed by:
>
> proxy1 = Proxy.getProxyClass(classloader2, intf1);
>
> Is it possible that the second call succeeds and returns proxy1 == 
> proxy3 ?

If it's possible to have intf1 and intf3 different runtime type of the 
same name, the second getProxyclass call would return proxy3 since 
intf1.isAssignableFrom(proxy3).What I'm not certain is - how would 
classloader2 be able to define intf3 with classloader1 defining intf1?  
We can't really predict how a non well-behaved class loader and thus I 
wouldn't exclude the possibility.

It seems that the key matching the list of interface names should 
already be a safe guard but we would need a proof for a name + 
isAssignableFrom is equivalent to that runtime type to determine its 
correctness with the consideration of all possible class loader 
behaviors that I don't have.  That's what my feedback was about.

Mandy


From joe.darcy at oracle.com  Thu Apr 25 00:24:39 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 24 Apr 2013 17:24:39 -0700
Subject: Review Request for JDK-8012937: Correct errors in javadoc comments
In-Reply-To: <517809C3.2060703@oracle.com>
References: <51756103.6020409@oracle.com> <5175858F.5040003@oracle.com>
	<5175ED68.7010201@oracle.com> <51769EB7.40204@oracle.com>
	<51771F23.50103@oracle.com> <517809C3.2060703@oracle.com>
Message-ID: <517877C7.4020503@oracle.com>

Please remove lines 157-159; otherwise, looks fine.

Thanks,

-Joe

On 04/24/2013 09:35 AM, Eric McCorkle wrote:
> Any further comments, or is this one good to go?
>
> On 04/23/13 19:54, Joseph Darcy wrote:
>> Acknowledged; thanks for checking,
>>
>> -Joe
>>
>> On 4/23/2013 7:46 AM, Eric McCorkle wrote:
>>> I believe so.  Alex Buckley recommended the exact wording.
>>>
>>> On 04/22/13 22:09, Joseph Darcy wrote:
>>>> Hello,
>>>>
>>>>    240      * Returns the number of formal parameters (whether explicitly
>>>>    241      * declared or implicitly declared or neither) for the
>>>> executable
>>>>
>>>> Are there parameters that are neither explicitly nor implicitly
>>>> declared?
>>>>
>>>> I still think the follow comment is better deleted given the source that
>>>> follows it:
>>>>
>>>>    157         // If a parameter has no name, return argX, where x is the
>>>>    158         // index.
>>>>    159         //
>>>>
>>>> -Joe
>>>>
>>>> On 4/22/2013 11:46 AM, Eric McCorkle wrote:
>>>>> I have posted a newer version with some more edits.  Please review and
>>>>> suggest any further changes.
>>>>>
>>>>> http://cr.openjdk.java.net/~emc/8012937/webrev.01/
>>>>>
>>>>> On 04/22/13 12:10, Eric McCorkle wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this simple change, which corrects some errors in the
>>>>>> javadoc comments for method parameter reflection.
>>>>>>
>>>>>> Note that this changeset does not include any code changes.
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~emc/8012937/webrev.00/
>>>>>>
>>>>>>
>>>>>> Also, if you have any additional issues with the javadoc comments,
>>>>>> please reply to this request with a description of the problem.
>>>>>>
>>>>>> Thanks,
>>>>>> Eric
>>>>>>



From mandy.chung at oracle.com  Thu Apr 25 01:38:26 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 Apr 2013 18:38:26 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517782A8.1010602@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com>
Message-ID: <51788912.5070106@oracle.com>

Hi Peter,

We both prefer the interface types as the subKey.    See my comment 
inlined below.

On 4/23/2013 11:58 PM, Peter Levart wrote:
> I developed two different approaches:
>
> 1. Key made of WeakReference-s to interface Class objects.
> Strong points:
> - no key aliasing, validation can be pushed entirely to slow-path
> - quick and scalable
> - less memory usage than original code for 0 and 1-interface proxies
> Weak points:
> - more memory usage for 2+ -interface proxies
> Latest webrev:
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.02/index.html
> Comments:
>   I like this one. If 2+ -interface proxies are relatively rare and 
> you don't mind extra space consumption for them,  I would go with this 
> approach.

I like this one too.  The mapping is straight forward and clean that 
avoids the fallback and post validation path. Let's proceed with this 
one.  It's good to optimize for the common case (1-interface). For 2 or 
more interfaces, we can improve the memory usage in the future when it 
turns out to be an issue.  I'm fine with the zero-interface proxy which 
is the current implementation too.

>
> That's the sole reason for optimized: WekaReferece -> 
> WeakReference -> ... -> WeakReference linked list 
> instead of the WeakReference[] array approach. And it's not 
> using any recursion for equals/hashCode, so the peformance is 
> comparable to array approach and it doesn't suffer from 
> StackOverflowExceptions for lots of interfaces.

I'm not objecting to build its own linked list but I'm not convinced if 
it's worth the extra complexity (although it's simple, this adds 
KeyNode, MidKeyNode, Key1, KeyX classes).  For 1-interface proxy, you 
can make it one single weak reference as you have right now.  I would 
simply think the array approach for 2+ interface proxy is preferable and 
the performance is comparable as you noted.  Did I miss any important 
reason you chose the linked list approach?  If not, let's do the simple 
approach that will help the future maintainers of this code.

The change in Proxy.java looks good to me with the comment about the 
array vs custom linked list.

WeakCache.java
    The javadoc for the get(K,P) method - @throws RuntimeException and 
@throws Error are not needed here since any method being called in the 
implementation may throw unchecked exceptions.  There are a couple 
places that checks if (reverseMap != null) .... that check is not needed 
since it's always non-null.  But I'm fine if you keep it as it is - just 
wanted to mention it in case it was just leftover from the previous version.

I think we're very close of getting this pushed.

Below are my comments to follow up the discussion we had last night and 
this morning just for clarification.  We should be now on the same page.

> Original code is actualy using the following structure: 
> WeakHashMap, WeakReference>>
> ... so no ClassLoader leak here...
>

Oops... somehow I thought the original code didn't make a weak reference 
of the proxy class. I should have looked at the original code before I 
replied :(

> The TwoLevelWeakCache is an analogous structure: 
> ConcurrentHashMap, 
> ConcurrentHashMap>>
>
> The point I was trying to make is that it is not needed to register a 
> ReferenceQueue with WeakReference values and remove entries as 
> they are cleared and enqueued, because they will not be cleared until 
> the ClassLoader that defines the Class-es is GC-ed and the expunging 
> logic can work solely on the grounds of cleared and enqueued 
> WeakReference keys, which is what my latest webrev using 
> String-based sub-keys does (I have to update the other too).

Agree.   That makes sense.   I got confused with CacheKey and the 
subkey.  I am now reading the WeakCache code closely.  You got it right 
that the key (defining ClassLoader), subkey (individual interfaces), and 
value (proxy class) have to be weakly referenced to ensure that classes 
loaded by any classloader cached as a key are not strongly reachable not 
causing the class loader leak.

> Not the key (interfaces array) but the individual interface Class 
> object - each has to be separately wrapped with a WeakReference. 

Sorry I should have been more precise - that's indeed what I meant.

thanks
Mandy


From mike.duigou at oracle.com  Thu Apr 25 04:47:40 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 25 Apr 2013 04:47:40 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20130425044740.896EF485B1@hg.openjdk.java.net>

Changeset: e34781a0566b
Author:    mduigou
Date:      2013-04-24 21:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/e34781a0566b

8013185: Add java.util.stream to CORE_PKGS.gmk in root repo
Reviewed-by: mduigou
Contributed-by: Henry Jen 

! common/makefiles/javadoc/CORE_PKGS.gmk

Changeset: e4794ae1016e
Author:    mduigou
Date:      2013-04-24 21:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/e4794ae1016e

Merge




From joe.darcy at oracle.com  Thu Apr 25 07:16:05 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Apr 2013 00:16:05 -0700
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <51762148.9080407@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com> <51761B4E.8020205@oracle.com>
	<51762148.9080407@oracle.com>
Message-ID: <5178D835.4080302@oracle.com>

Hello,

Responding to David's comment and some comments from Alan off-list, here 
is a variant which doesn't use suppressed exceptions in initCause, but 
still passes along some information:

     http://cr.openjdk.java.net/~darcy/8012044.4

Patch to Throwable:

--- a/src/share/classes/java/lang/Throwable.java    Wed Apr 24 21:27:52 
2013 +0000
+++ b/src/share/classes/java/lang/Throwable.java    Thu Apr 25 00:15:32 
2013 -0700
@@ -453,9 +453,10 @@
       */
      public synchronized Throwable initCause(Throwable cause) {
          if (this.cause != this)
-            throw new IllegalStateException("Can't overwrite cause");
+            throw new IllegalStateException("Can't overwrite cause with " +
+ Objects.toString(cause, "a null"), this);
          if (cause == this)
-            throw new IllegalArgumentException("Self-causation not 
permitted");
+            throw new IllegalArgumentException("Self-causation not 
permitted", this);
          this.cause = cause;
          return this;
      }
@@ -1039,7 +1040,7 @@
       */
      public final synchronized void addSuppressed(Throwable exception) {
          if (exception == this)
-            throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
+            throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);

          if (exception == null)
              throw new NullPointerException(NULL_CAUSE_MESSAGE);

Thanks,

-Joe

On 04/22/2013 10:51 PM, Joe Darcy wrote:
> Hi David,
>
> On 04/22/2013 10:25 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 23/04/2013 9:05 AM, Joseph Darcy wrote:
>>> Hello,
>>>
>>> Just reasserting the request for a review of the latest version of this
>>> patch:
>>>
>>>      http://cr.openjdk.java.net/~darcy/8012044.2
>>>
>>> I believe this version does an appropriate job of propagating exception
>>> information when there is misuse of the methods on Throwable.
>>
>> I still find the use of addSuppressed in initCause to be 
>> questionable. Given:
>>
>>    catch(SomeException s) {
>>       sharedException.initCause(s); // oops already has a cause
>>       throw sharedException;
>>    }
>>
>> then the ISE isn't suppressing 's', but replacing/suppressing 
>> sharedException in my view, as it is what would have been thrown had 
>> the ISE not occurred.
>>
>> I understand the desire to not lose sight of the fact that 's' was 
>> thrown, but this is really no different to a finally block losing the 
>> original exception info. (And fixing that was rejected when the 
>> suppression mechanism was added.)
>
> Project Coin discussions did note try-catch-finally and 
> try-with-resources were inconsistent on this point. While the 
> try-with-resources behavior is regarded as preferable, we thought it 
> would be too large a change to redefine the long-standing semantics of 
> try-catch-finally.
>
>>
>> Anyway this isn't a "block" (not that such a thing exists), just a 
>> comment. The change isn't harmful and may be useful.
>>
>> Cheers,
>> David
>>
>
> Yes, I would describe the intention of this change as provding 
> programmers more information to debug when the methods are Throwable 
> and used improperly.
>
> Thanks,
>
> -Joe



From alexey.utkin at oracle.com  Thu Apr 25 14:41:55 2013
From: alexey.utkin at oracle.com (Alexey Utkin)
Date: Thu, 25 Apr 2013 18:41:55 +0400
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <5177EAFB.7000803@oracle.com>
References: <51768B23.6060506@oracle.com> <5176E367.9090601@oracle.com>
	<5177D6EC.8020304@oracle.com> <5177EAFB.7000803@oracle.com>
Message-ID: <517940B3.2050609@oracle.com>

Alan,

Thanks for your comments.
I did the changes in code.
Please, read my answers below.

Here is fixed version:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.02/

Regards,
-uta


On 24.04.2013 18:23, Alan Bateman wrote:
> On 24/04/2013 13:58, Alexey Utkin wrote:
>>
>> I changed in the ProcessBuilder class to restore the compatibility 
>> with Java documentation. In accordance with spec, the 
>> IllegalArgumentException exception could not be thrown from the start 
>> method. I made it a cause for declared IOException.
> This part looks good to me.
>
>
>>
>> Thanks for your attention. The test was extended to cover the case.
>>
>> New version:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.01/
>>
>> Lines 381-382 in ProcessImpl.java file are responsible for the second 
>> call to Security Manager.
>> The call with [".\Program Files\doNot.cmd" arg] param does not pass 
>> the second Security Manager verification in the ExecCommand.java test.
> Overall I think this looks okay.
>
> In getTokensFromCommand then I guess I would have used a regex rather 
> than legacy StringTokenizer (I realize Runtime is specified to use 
> StringTokenizer for the initial split). I think I agree with Martin on 
> wondering why LinkedList is used but it's not an issue as this is the 
> fallback. Minor nit is that the brace on L161 can be moved to the end 
> of the previous line.
Done.

> A minor comment is that -Djdk.lang.Process.allowAmbigousCommands=false 
> will not do what is intended (the value of the property is not examined).
Done.

>
> The test needs a copyright header but otherwise looks comprehensive. 
Done.

> One thing I see is that it doesn't read from the child's output/error 
> streams so if there is a problem then it will be hard to diagnose from 
> the logs.
The diagnostic includes logging of the command line  in problem. It 
should not be a problem to localize issue.

> Minor comments on the test is that the creation of the commands could 
> use try-with-resources.
Done




From Alan.Bateman at oracle.com  Thu Apr 25 14:53:52 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Apr 2013 15:53:52 +0100
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <5178D835.4080302@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com> <51761B4E.8020205@oracle.com>
	<51762148.9080407@oracle.com> <5178D835.4080302@oracle.com>
Message-ID: <51794380.7090206@oracle.com>

On 25/04/2013 08:16, Joe Darcy wrote:
> Hello,
>
> Responding to David's comment and some comments from Alan off-list, 
> here is a variant which doesn't use suppressed exceptions in 
> initCause, but still passes along some information:
>
>     http://cr.openjdk.java.net/~darcy/8012044.4
>
This looks reasonable to me in that it provides useful information in 
the ISA. Like David, I would have found it confusing to have the cause 
show up as a suppressed exception in output.

-Alan.


From peter.levart at gmail.com  Thu Apr 25 15:40:26 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 25 Apr 2013 17:40:26 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51788912.5070106@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
Message-ID: <51794E6A.3000100@gmail.com>

Hi Mandy,

Here's another update that changes the sub-key back to 
WeakReference based:

http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.05/index.html


On 04/25/2013 03:38 AM, Mandy Chung wrote:
> I like this one too.  The mapping is straight forward and clean that 
> avoids the fallback and post validation path. Let's proceed with this 
> one.  It's good to optimize for the common case (1-interface). For 2 
> or more interfaces, we can improve the memory usage in the future when 
> it turns out to be an issue.  I'm fine with the zero-interface proxy 
> which is the current implementation too.

I made 3 straight-forward implementations of sub-keys:
- Key1 - single interface
- Key2 - two interfaces
- KeyX - any number of interfaces

The cache-structure size increment for each new cached proxy-class is 
(32 bit OOPS):

#of intfcs  original  patched
----------  --------  ------------
          1       152  128(Key1)
          2       152  168(Key2), 208(KeyX)
          3       160  248(KeyX)
          4       160  280(KeyX)

...so you can decide if Key2 is worth having or not.

>
> WeakCache.java
>    The javadoc for the get(K,P) method - @throws RuntimeException and 
> @throws Error are not needed here since any method being called in the 
> implementation may throw unchecked exceptions. There are a couple 
> places that checks if (reverseMap != null) .... that check is not 
> needed since it's always non-null.  But I'm fine if you keep it as it 
> is - just wanted to mention it in case it was just leftover from the 
> previous version.

Removed the unneeded @throws and reverseMap != null checks (the later 
was already removed in latest string-based webrev and I used that 
version here).

>
> I think we're very close of getting this pushed.
>

Do you think this could also get backported to JDK7? The WeakCache uses 
two interfaces from java.util.function. Should we make private 
equivalents in this patch or do we leave that for the possible 
back-porting effort. I should note that JDK7's ConcurrentHashMap is not 
that space-efficient as proposed JDK8's, so space-usage would be 
different on JDK7...

Regards, Peter

>
>
> thanks
> Mandy



From jason_mehrens at hotmail.com  Thu Apr 25 15:50:18 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 25 Apr 2013 10:50:18 -0500
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <5178D835.4080302@oracle.com>
References: <51676122.4020802@oracle.com>,
	, ,
	<516845EC.8090105@oracle.com>,
	, ,
	<51685B97.5010507@oracle.com>,
	,
	<516B6799.1010206@oracle.com>
	<516EDC9A.4070207@oracle.com>,<5175C21E.2040502@oracle.com>
	<51761B4E.8020205@oracle.com>, <51762148.9080407@oracle.com>,
	<5178D835.4080302@oracle.com>
Message-ID: 

Looks good.  I still think last sentence of the Throwable.addSuppressed javadocs side steps the counter arguments.

Thanks for working on this,

Jason

----------------------------------------
> Date: Thu, 25 Apr 2013 00:16:05 -0700
> From: joe.darcy at oracle.com
> To: david.holmes at oracle.com; Alan.Bateman at oracle.com
> Subject: Re: REASSERT Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed
> CC: core-libs-dev at openjdk.java.net
>
> Hello,
>
> Responding to David's comment and some comments from Alan off-list, here
> is a variant which doesn't use suppressed exceptions in initCause, but
> still passes along some information:
>
> http://cr.openjdk.java.net/~darcy/8012044.4
>
> Patch to Throwable:
>
> --- a/src/share/classes/java/lang/Throwable.java Wed Apr 24 21:27:52
> 2013 +0000
> +++ b/src/share/classes/java/lang/Throwable.java Thu Apr 25 00:15:32
> 2013 -0700
> @@ -453,9 +453,10 @@
> */
> public synchronized Throwable initCause(Throwable cause) {
> if (this.cause != this)
> - throw new IllegalStateException("Can't overwrite cause");
> + throw new IllegalStateException("Can't overwrite cause with " +
> + Objects.toString(cause, "a null"), this);
> if (cause == this)
> - throw new IllegalArgumentException("Self-causation not
> permitted");
> + throw new IllegalArgumentException("Self-causation not
> permitted", this);
> this.cause = cause;
> return this;
> }
> @@ -1039,7 +1040,7 @@
> */
> public final synchronized void addSuppressed(Throwable exception) {
> if (exception == this)
> - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
> + throw new
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>
> if (exception == null)
> throw new NullPointerException(NULL_CAUSE_MESSAGE);
>
> Thanks,
>
> -Joe 		 	   		  

From joe.darcy at oracle.com  Thu Apr 25 16:37:33 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 25 Apr 2013 16:37:33 +0000
Subject: hg: jdk8/tl/jdk: 8012044: Give more information about
	self-suppression from Throwable.addSuppressed
Message-ID: <20130425163757.A4E8B485D2@hg.openjdk.java.net>

Changeset: 4da1d43f5843
Author:    darcy
Date:      2013-04-25 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4da1d43f5843

8012044: Give more information about self-suppression from Throwable.addSuppressed
Reviewed-by: alanb, dholmes

! src/share/classes/java/lang/Throwable.java
! test/java/lang/Throwable/SuppressedExceptions.java



From kumar.x.srinivasan at oracle.com  Thu Apr 25 17:53:21 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 25 Apr 2013 10:53:21 -0700
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
Message-ID: <51796D91.6070304@oracle.com>

Hello,

Please review changes which essentially contains asm5_future in asm's 
mainline
repository, I have tested this patch with Nashorn (so has Sundar), as 
well as Lambda's
usage.

Fixes that I know of:
1. supports v52.0 class files and JSR 308/Type Annotations changes

Thanks to Remi
2. elimination of "_" usages in variable names
3. several javadoc changes and one reported by Sundar
http://jbs.oracle.com/bugs/browse/JDK-8010083


Thanks
Kumar



From henry.jen at oracle.com  Thu Apr 25 18:14:38 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 25 Apr 2013 11:14:38 -0700
Subject: RFR: JDK-8012650 and JDK-8011918
In-Reply-To: <5177E40E.7020405@oracle.com>
References: <5177149B.1080407@oracle.com> <5177E40E.7020405@oracle.com>
Message-ID: <5179728E.60708@oracle.com>

On 04/24/2013 06:54 AM, Alan Bateman wrote:
> On 24/04/2013 00:09, Henry Jen wrote:
>> Hi,
>>
>> Please review static Stream factory methods and methods for Arrays.
>> Webrev is at
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.0
>>
>> Stream methods are covered in a test suite which will be put back soon
>> once all depends part is in place.
>>
>> Arrays setAll and parallelSetAll methods has test included.
>>
>> Cheers,
>> Henry
> I went over the webrev and don't see anything obviously wrong.
> 
> Will you add the @since 1.8 to the Arrays methods before pushing this?
> The stream methods have it, just not the setAll/parallelSetAll.
> 
> Another minor comment is that the stream methods specify NPE but that
> isn't strictly requires as the Arrays class has a statement in the class
> description to say that all methods throw NPE if the array reference is
> null.
> 
> 

Both fixed, new webrev is at

http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.1

Cheers,
Henry



From Alan.Bateman at oracle.com  Thu Apr 25 18:43:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Apr 2013 19:43:07 +0100
Subject: RFR: JDK-8012650 and JDK-8011918
In-Reply-To: <5179728E.60708@oracle.com>
References: <5177149B.1080407@oracle.com> <5177E40E.7020405@oracle.com>
	<5179728E.60708@oracle.com>
Message-ID: <5179793B.6070100@oracle.com>

On 25/04/2013 19:14, Henry Jen wrote:
> :
> Both fixed, new webrev is at
>
> http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.1
>
> Cheers,
> Henry
>
Thanks, I didn't mean you have to have to generate a new webrev for such 
minor matters. Anyway, I don't see any other issues and looks fine to me.

-Alan



From eric.mccorkle at oracle.com  Thu Apr 25 18:32:55 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 25 Apr 2013 18:32:55 +0000
Subject: hg: jdk8/tl/jdk: 8012937: Correct errors in javadoc comments.
Message-ID: <20130425183322.657BA485D4@hg.openjdk.java.net>

Changeset: ca0957f0d408
Author:    emc
Date:      2013-04-25 14:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca0957f0d408

8012937: Correct errors in javadoc comments.
Summary: Correct some errors in the javadoc comments for parameter reflection.
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Parameter.java



From mike.duigou at oracle.com  Thu Apr 25 19:19:47 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 25 Apr 2013 12:19:47 -0700
Subject: RFR : 8008632 : Additional JavaDoc tags @apiNote,
	@implSpec and @implNote for JDK API Docs
In-Reply-To: 
References: <2601AA97-DECB-4C91-BF3A-3FC026D3340A@oracle.com>
	<516FF4C9.5010900@oracle.com>
	<019751E7-4FDB-42C0-ABED-2590A39A2401@oracle.com>
	<517014D3.4030503@oracle.com>
	<8091A52E-86D0-43A8-A018-AB8AD0633E7F@oracle.com>
	<5170426D.3000500@oracle.com>
	
Message-ID: <06A4BFD6-CB7C-4543-A174-6878952DE661@oracle.com>

Hello all;

Here's the promised results of the survey. With 10 responses 7 favoured the "before @param" option and 3 favoured the "@after throws" option. Here are the survey text comments, "-", with my notes, "--", following each.

- "@apiNote should be removed, anything it has to say should be included in the normal text of the constructor or method. @implNote should be used sparingly it adds little value. In any case it should be formatted to be part of the method description not an indented block following the normal javadoc text"

-- @apiNote is intended for informational API text. This will probably be mostly examples. Existing examples could be converted to "API Notes"

-- @implNote is expected to be the least used of the tags. It's include to square out the matrix of api/impl spec/note.

- "API Notes is not shown after the @throws tag in sample #2. It should be."

-- The positioning before @param was intentional. API notes will mostly be reclassifications of existing examples which are currently before @param.

- "@implSpec has to be shown. Its normative!"

-- Agreed, the question at hand is its position.

- "@implSpec and @implNote should be rendered in a smaller font, and collapsed by default"

-- Outside the scope of this request. The javadoc html doclet defines the presentation of elements.

- "I want to know. Don't hide it."

-- Agreed, the question at hand is its position.

- "Historically, implementation notes have been in the "main section". These tags just formalize this. Also, the sections labeled by them are likely to be long; historically, the "little" ones (@param, @return, @throws, @since) are at the end. So I think these pretty clearly go after the main spec and before the @param."

-- (no response)


Thank you all for your responses and feedback on this issue. I believe this leaves us with the @implSpec/@implNote being presented before the @param tag and this is the direction I will proceed for now. There's still time in the Java 8 schedule to refine the placement and presentation should further hands-on experience lead us to other conclusions. One outstanding issue is poor html presentation of the @apiNote/@implSpec/@implNote in class and package docs--this is still to be followed up on in a separate issue.

I will wait 24 hours for any vetos to pushing this change.

Mike


On Apr 22 2013, at 18:15 , Mike Duigou wrote:

> Hi All;
> 
> I've produced a sample of Javadoc with the @implSpec/@implNote tag output before and after the @param section.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8008632/implBefore/
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8008632/implAfter/
> 
> Take a look at these samples and see if you feel strongly about one or the other. Then visit:
> 
> https://www.surveymonkey.com/s/CQ8S7R8
> 
> I will run the survey for a couple of days and report the results here.
> 
> Thanks
> 
> Mike
> 
> 
> On Apr 18 2013, at 11:58 , roger riggs wrote:
> 
>> Hi Mike,
>> 
>> Sorry for so many comments on this but I have one more.
>> 
>> I don't think the order of @implSpec, @implNote is optimal.  As a developer I want to read
>> the javadoc and see the description, parameters, returns, etc.
>> 
>> I don't want to see the implementation spec or notes.  Maybe they are more
>> important in default methods but in ordinary methods, they are important
>> only when the details matter.
>> 
>> I would push @implSpec and @implNote down after @throws.
>> 
>> Roger
>> 
>> On 4/18/2013 12:49 PM, Mike Duigou wrote:
>>> On Apr 18 2013, at 08:44 , roger riggs wrote:
>>> 
>>>> Hi Mike,
>>>> 
>>>> On 4/18/2013 11:01 AM, Mike Duigou wrote:
>>>>>> Note that Oracle accessibility guidelines for html indicate that headers
>>>>>> should use header tags   to be properly navigable by accessibility tools.
>>>>> Understood. That would be a separate issue though as we have no control over the html generated by the javadoc html doclet.
>>>> ok, I see that javadoc defines the tag to be wrapped in  xxx.
>>>> 
>>>> I don't see that the additional emphasis is needed relative to the other
>>>> style elements of the javadoc.
>>> I *had* thought I was copying the JLS tag but see now that that's not the case. I no longer remember where the  came from.
>>> 
>>>> I would remove the  explicit markup or if possible delegate
>>>> to the stylesheet with a .
>>> I will remove it and allow the default formatting to be used.
>>> 
>>>> Roger
>>>> 
>>>>> Mike
>>>>> 
>>>>>> Thanks, Roger
>>>>>> 
>>>>>> 
>>>>>> On 4/17/2013 7:51 PM, Mike Duigou wrote:
>>>>>>> Hello All;
>>>>>>> 
>>>>>>> Some of you have noticed that the lambda streams libraries patches currently going in to the TL repo make use of special javadoc tags. There are three tags being used:
>>>>>>> 
>>>>>>> @apiNote : Non-normative notes about the API. Usually used for examples.
>>>>>>> @implSpec : Describes required behaviour of conforming implementations. Key is that the description is not inherited.
>>>>>>> @implNote : Non-normative notes about the implementation. Typically used for descriptions of the behaviour. Also not inherited.
>>>>>>> 
>>>>>>> The tags are used primarily by default method implementations but will be used elsewhere as well.
>>>>>>> 
>>>>>>> These tags are enabled by use of the -tag feature on the javadoc tool command line. They are not proposed as standard javadoc tags and may be implemented differently in future Java releases. Since they are implemented as custom tags just for the JDK API documentation you can't automatically use them in your own code. (You can, of course, add the same command line options to your javadoc invocations if you like these tags).
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/
>>>>>>> 
>>>>>>> The patch enumerates the new custom tags in addition to the standard tags to ensure correct output order.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>> 
> 



From sean.coffey at oracle.com  Thu Apr 25 20:11:43 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Thu, 25 Apr 2013 20:11:43 +0000
Subject: hg: jdk8/tl/jdk: 8000529: Regression: SimpleDateFormat incorrectly
	parses dates formatted with Z and z pattern letters
Message-ID: <20130425201205.51F3D485DB@hg.openjdk.java.net>

Changeset: 5871d7b1673c
Author:    coffeys
Date:      2013-04-25 21:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5871d7b1673c

8000529: Regression: SimpleDateFormat incorrectly parses dates formatted with Z and z pattern letters
Reviewed-by: okutsu

! src/share/classes/java/text/CalendarBuilder.java
! src/share/classes/java/text/SimpleDateFormat.java
! test/java/text/Format/DateFormat/Bug7130335.java



From kumar.x.srinivasan at oracle.com  Thu Apr 25 20:24:40 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 25 Apr 2013 13:24:40 -0700
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <51796D91.6070304@oracle.com>
References: <51796D91.6070304@oracle.com>
Message-ID: <51799108.6040801@oracle.com>

Here is the webrev:
http://cr.openjdk.java.net/~ksrini/8013225/webrev.0/

Thanks
Kumar

> Hello,
>
> Please review changes which essentially contains asm5_future in asm's 
> mainline
> repository, I have tested this patch with Nashorn (so has Sundar), as 
> well as Lambda's
> usage.
>
> Fixes that I know of:
> 1. supports v52.0 class files and JSR 308/Type Annotations changes
>
> Thanks to Remi
> 2. elimination of "_" usages in variable names
> 3. several javadoc changes and one reported by Sundar
> http://jbs.oracle.com/bugs/browse/JDK-8010083
>
>
> Thanks
> Kumar
>



From henry.jen at oracle.com  Thu Apr 25 20:25:25 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 25 Apr 2013 13:25:25 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
Message-ID: <51799135.5020801@oracle.com>

Hi,

Please review two default methods add to CharSequence returns IntStream
of char value or code point value.

http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/

The synchronization test is relieved so lambda and other synthetic
method is not tested. If synchronization is needed for those two default
methods, subclass should override the methods.

With charAt and codePointAt properly synchronized, the default
implementation is sufficient. However as noted, if the sequence is
mutated while the stream is being read, the result is undefined.

Cheers,
Henry



From Lance.Andersen at oracle.com  Thu Apr 25 20:53:58 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 25 Apr 2013 16:53:58 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
In-Reply-To: <8AFCEB1B-E102-4469-9F0E-FF895955C007@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
	<5175378D.4010800@oracle.com>
	<8AFCEB1B-E102-4469-9F0E-FF895955C007@oracle.com>
Message-ID: <5A44649D-1662-422D-948E-FDA5380FC9BC@oracle.com>

http://cr.openjdk.java.net/~lancea/8010416/webrev.03/  addresses the typos that were pointed out and also fixes a couple javadoc warnings

Best,
Lance
On Apr 22, 2013, at 11:17 AM, Lance Andersen - Oracle wrote:

> 
> On Apr 22, 2013, at 9:13 AM, Alan Bateman wrote:
> 
>> On 21/04/2013 12:45, Lance Andersen - Oracle wrote:
>>> :
>>>> 
>>>> DriverManager
>>>> 
>>>> - one point that isn't covered in the spec is whether the DriverAction's deregister is invoked before or after it is deregistered. This distinction is probably only interesting for the case that the deregister method fails with an error/exception but it's not clear if the driver is still registered in that case. For completeness then the spec should probably say that any error/runtime exception is propagated to the caller of deregisterDriver.
>>>> 
>>>> - could the new (and the original) registerDriver methods specify the behavior for the case that the Driver is already registered? This brings up the question as to whether the DriverAction is overridden if already registered.
>>> clarified
>> Thanks, I think that covers all the corner cases.
>> 
>> One typo, line 376, should be "If the specified ...".
> 
> Fixed that thank you.
>> 
>> -Alan.
>> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From pbenedict at apache.org  Thu Apr 25 20:57:41 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Thu, 25 Apr 2013 15:57:41 -0500
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
Message-ID: 

Henry,

I believe the coding standards require curly braces for any if-statement
and for-loop.

Also the return statements exceed the 80 character limit. It would be nice
to have them formatted across several lines like the following because it's
difficult to read going straight across:

return StreamSupport.intStream(() ->
        Spliterators.spliterator(
            new CharIterator(),
            length(),
            Spliterator.ORDERED),
        Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED);

Paul


From henry.jen at oracle.com  Thu Apr 25 21:45:50 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 25 Apr 2013 14:45:50 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: 
References: 
Message-ID: <5179A40E.9090104@oracle.com>

On 04/25/2013 01:57 PM, Paul Benedict wrote:
> Henry,
> 
> I believe the coding standards require curly braces for any if-statement
> and for-loop.
> 
> Also the return statements exceed the 80 character limit. It would be nice
> to have them formatted across several lines like the following because it's
> difficult to read going straight across:
> 
> return StreamSupport.intStream(() ->
>         Spliterators.spliterator(
>             new CharIterator(),
>             length(),
>             Spliterator.ORDERED),
>         Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED);
> 
> Paul
> 


Thanks, updated.

Cheers,
Henry


From mandy.chung at oracle.com  Thu Apr 25 21:53:57 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Apr 2013 14:53:57 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <51794E6A.3000100@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com>
Message-ID: <5179A5F5.4070503@oracle.com>

Hi Peter,

This looks great.  I have imported your patch with slight modification 
in WeakCache:
   http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.01/

I believe WeakCache.get(K, P) should throw NPE if key is null and I 
fixed that.  I changed refQueue to be of type ReferenceQueue rather 
than ReferenceQueue since CacheValue no longer added to the ref 
queue.  In the expungeStaleEntries method, change CacheKey to 
CacheKey.  WeakCache.get(K, P) takes instance of K and P but 
subKeyFactory and valueFactory take superclasses of K and P - is that 
what you really want?  I have changed them to BiFunction. I 
also fixed a few typos and that's all.

The performance improvement is significant and I want to push this 
version to jdk8/tl.  We can tune the memory usage in the future if that 
turns out to be an issue.  I don't have plan to backport to jdk7u-dev 
unless there are customers escalating this :)  This should be easy to 
convert without using BiFunction and Supplier and I will leave it as it 
is until there is a request to backport.

I keep Key2 class since jdk also creates a proxy of 2 interfaces and you 
have already implemented it.  If we think of a better way to replace the 
generation of the subkey in an optimized way, we could improve that in 
the future.  The first and second level maps maintained in the WeakCache 
have Object as the type for the key which I think we should look for a 
specific type (CacheKey and SubKey type).  To make the key of the 
first-level map to CacheKey would need to keep a separate cache for null 
key.  For the second-level map, the subkey type would need to be 
declared as a parameter type to WeakCache.  They are something that we 
should look at and clean up in the future if appropriate.  I think what 
you have is good work that shouldn't be delayed any further.

I'm running more tests.  If the above webrev looks fine with you, I'll 
push the changeset tomorrow.

thanks
Mandy

On 4/25/13 8:40 AM, Peter Levart wrote:
> Hi Mandy,
>
> Here's another update that changes the sub-key back to 
> WeakReference based:
>
> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.05/index.html
>
> On 04/25/2013 03:38 AM, Mandy Chung wrote:
>> I like this one too.  The mapping is straight forward and clean that 
>> avoids the fallback and post validation path. Let's proceed with this 
>> one.  It's good to optimize for the common case (1-interface). For 2 
>> or more interfaces, we can improve the memory usage in the future 
>> when it turns out to be an issue.  I'm fine with the zero-interface 
>> proxy which is the current implementation too.
>
> I made 3 straight-forward implementations of sub-keys:
> - Key1 - single interface
> - Key2 - two interfaces
> - KeyX - any number of interfaces
>
> The cache-structure size increment for each new cached proxy-class is 
> (32 bit OOPS):
>
> #of intfcs  original  patched
> ----------  --------  ------------
>          1       152  128(Key1)
>          2       152  168(Key2), 208(KeyX)
>          3       160  248(KeyX)
>          4       160  280(KeyX)
>
> ...so you can decide if Key2 is worth having or not.
>
>>
>> WeakCache.java
>>    The javadoc for the get(K,P) method - @throws RuntimeException and 
>> @throws Error are not needed here since any method being called in 
>> the implementation may throw unchecked exceptions.  There are a 
>> couple places that checks if (reverseMap != null) .... that check is 
>> not needed since it's always non-null.  But I'm fine if you keep it 
>> as it is - just wanted to mention it in case it was just leftover 
>> from the previous version.
>
> Removed the unneeded @throws and reverseMap != null checks (the later 
> was already removed in latest string-based webrev and I used that 
> version here).
>
>>
>> I think we're very close of getting this pushed.
>>
>
> Do you think this could also get backported to JDK7? The WeakCache 
> uses two interfaces from java.util.function. Should we make private 
> equivalents in this patch or do we leave that for the possible 
> back-porting effort. I should note that JDK7's ConcurrentHashMap is 
> not that space-efficient as proposed JDK8's, so space-usage would be 
> different on JDK7...
>
> Regards, Peter
>
>>
>>
>> thanks
>> Mandy
>



From mike.duigou at oracle.com  Thu Apr 25 22:53:48 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 25 Apr 2013 15:53:48 -0700
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <51799108.6040801@oracle.com>
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
Message-ID: <750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>

The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.

I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.

Looks OK. The testing, which you have done, is the important qualifier for this change.

Mike

On Apr 25 2013, at 13:24 , Kumar Srinivasan wrote:

> Here is the webrev:
> http://cr.openjdk.java.net/~ksrini/8013225/webrev.0/
> 
> Thanks
> Kumar
> 
>> Hello,
>> 
>> Please review changes which essentially contains asm5_future in asm's mainline
>> repository, I have tested this patch with Nashorn (so has Sundar), as well as Lambda's
>> usage.
>> 
>> Fixes that I know of:
>> 1. supports v52.0 class files and JSR 308/Type Annotations changes
>> 
>> Thanks to Remi
>> 2. elimination of "_" usages in variable names
>> 3. several javadoc changes and one reported by Sundar
>> http://jbs.oracle.com/bugs/browse/JDK-8010083
>> 
>> 
>> Thanks
>> Kumar
>> 
> 



From martinrb at google.com  Thu Apr 25 23:14:03 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 25 Apr 2013 16:14:03 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: <51799135.5020801@oracle.com>
References: <51799135.5020801@oracle.com>
Message-ID: 

I think core library code should write the slightly lower-level code for
performance

+                int cp = Character.codePointAt(CharSequence.this, cur);
+                cur += Character.charCount(cp);

int length = length();
if (cur == length) throw NSEE;
char c1 = charAt(cur++), c2;
if (!isHighSurrogate(c1) || cur == length || !isLowSurrogate(c2 =
charAt(cur))
  return c1;
cur++;
return toCodePoint(c1, c2);




On Thu, Apr 25, 2013 at 1:25 PM, Henry Jen  wrote:

> Hi,
>
> Please review two default methods add to CharSequence returns IntStream
> of char value or code point value.
>
> http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
>
> The synchronization test is relieved so lambda and other synthetic
> method is not tested. If synchronization is needed for those two default
> methods, subclass should override the methods.
>
> With charAt and codePointAt properly synchronized, the default
> implementation is sufficient. However as noted, if the sequence is
> mutated while the stream is being read, the result is undefined.
>
> Cheers,
> Henry
>
>


From brian.burkhalter at oracle.com  Thu Apr 25 23:21:08 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 25 Apr 2013 16:21:08 -0700
Subject: Review Request: BigInteger patch for efficient multiplication and
	division (#4837946)
In-Reply-To: 
References: 
Message-ID: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com>

Hello,

We are at long last soon to commence our long overdue effort to integrate this important submission.

To this end I have a couple of questions and a comment below.

Thanks,

Brian

On Mar 10, 2013, at 1:39 PM, Tim Buktu wrote:

> I have updated the patch. It now contains Alan Eliasen's fast square() and pow() implementations.
> Special characters have been replaced with ASCII ones.
> 
> Also included is a patched MutableBigInteger which uses the fast division algorithm in BigInteger, and a patched BigDecimal which uses the fast BigInteger.pow() method. Both changes speed up BigDecimal division.
> BigDecimal division is still much slower than BigInteger division (except BigDecimal.divideAndRound) because it calls doRound(), setScale(), and bigMultiplyPowerTen() which are pretty slow. Maybe these
> methods can be made more efficient.
> 
> To view the four patched files (#4 is BigIntegerTest.java) on one page, go to
> 
> https://gist.github.com/tbuktu/1576025 ,
> 
> or get them individually at
> 
> https://gist.github.com/tbuktu/1576025/raw/96e9dfd9261862223aa9ff81618f1d85045e85a5/BigInteger.java
> https://gist.github.com/tbuktu/1576025/raw/447db955ef74b065b03b0b45abd443cea5d7b2c6/MutableBigInteger.java
> https://gist.github.com/tbuktu/1576025/raw/6863a38032835b48b73cbce5aa833680c881557f/BigDecimal.java
> https://gist.github.com/tbuktu/1576025/raw/11977be7d001e093baa915b4370f326e30218eec/BigIntegerTest.java

This patch differs from the code in https://github.com/tbuktu/bigint.git. Notably I observed that Schonhage-Strassen multiplication and Barrett division are not present. Is this intentional and if so why would that be? Are the implementations of these additional algorithms not quite ready for contribution or is there a licensing issue perhaps?

> Semi-related: I think there is a bug in
> jdk/test/java/math/BigInteger/CompareToTests.java and
> jdk/test/java/math/BigDecimal/CompareToTests.java. It prints failures
> (with or without my patches) but the overall test doesn't fail.

I have taken note of this with the intent of investigating it in the course of evaluating this submission.

From kumar.x.srinivasan at oracle.com  Thu Apr 25 23:26:34 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 25 Apr 2013 16:26:34 -0700
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
Message-ID: <5179BBAA.2010506@oracle.com>

On 4/25/2013 3:53 PM, Mike Duigou wrote:
> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>
> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.

Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
can shed some light on that.

Kumar

>
> Looks OK. The testing, which you have done, is the important qualifier for this change.
>
> Mike
>
> On Apr 25 2013, at 13:24 , Kumar Srinivasan wrote:
>
>> Here is the webrev:
>> http://cr.openjdk.java.net/~ksrini/8013225/webrev.0/
>>
>> Thanks
>> Kumar
>>
>>> Hello,
>>>
>>> Please review changes which essentially contains asm5_future in asm's mainline
>>> repository, I have tested this patch with Nashorn (so has Sundar), as well as Lambda's
>>> usage.
>>>
>>> Fixes that I know of:
>>> 1. supports v52.0 class files and JSR 308/Type Annotations changes
>>>
>>> Thanks to Remi
>>> 2. elimination of "_" usages in variable names
>>> 3. several javadoc changes and one reported by Sundar
>>> http://jbs.oracle.com/bugs/browse/JDK-8010083
>>>
>>>
>>> Thanks
>>> Kumar
>>>



From bradford.wetmore at oracle.com  Fri Apr 26 00:13:23 2013
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Fri, 26 Apr 2013 00:13:23 +0000
Subject: hg: jdk8/tl/jdk: 8012530:
	test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
Message-ID: <20130426001335.EA4CC485E3@hg.openjdk.java.net>

Changeset: b600d637ef77
Author:    wetmore
Date:      2013-04-25 17:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d637ef77

8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
Reviewed-by: wetmore
Contributed-by: alan.bateman at oracle.com

! test/sun/security/provider/SecureRandom/StrongSeedReader.java



From jonathan.gibbons at oracle.com  Fri Apr 26 00:47:20 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 26 Apr 2013 00:47:20 +0000
Subject: hg: jdk8/tl/langtools: 8013256: javac test failing after Lambda
	changes to java.util.List
Message-ID: <20130426004726.EBB85485E4@hg.openjdk.java.net>

Changeset: 4b0038f66d66
Author:    jjg
Date:      2013-04-25 17:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4b0038f66d66

8013256: javac test failing after Lambda changes to java.util.List
Reviewed-by: mduigou

! test/tools/javac/api/TestJavacTaskScanner.java



From mike.duigou at oracle.com  Fri Apr 26 01:37:46 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 26 Apr 2013 01:37:46 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130426013833.440C0485E8@hg.openjdk.java.net>

Changeset: a8da4e516bc3
Author:    akhil
Date:      2013-04-23 11:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8da4e516bc3

8005051: optimized defaults for Iterator.forEachRemaining
Reviewed-by: alanb, mduigou, psandoz, ulfzibis
Contributed-by: Akhil Arora 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/Vector.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java

Changeset: ceeed0fcb371
Author:    jgish
Date:      2013-04-02 18:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceeed0fcb371

5015163: (str) String merge/join that is the inverse of String.split()
7172553: A utility class that forms the basis of a String.join() operation
Summary: Integrate StringJoiner changes from lambda
Reviewed-by: alanb, mduigou

! make/java/java/FILES_java.gmk
! src/share/classes/java/lang/String.java
+ src/share/classes/java/util/StringJoiner.java
+ test/java/lang/String/StringJoinTest.java
+ test/java/util/StringJoiner/StringJoinerTest.java

Changeset: 2cb55846c9bb
Author:    mduigou
Date:      2013-04-24 16:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cb55846c9bb

8011920: Main streams implementation
8012542: Stream methods on Collection
Reviewed-by: dholmes, mduigou
Contributed-by: Brian Goetz , Mike Duigou , Paul Sandoz 

! make/docs/CORE_PKGS.gmk
! src/share/classes/java/util/Collection.java
+ src/share/classes/java/util/stream/AbstractPipeline.java
+ src/share/classes/java/util/stream/AbstractSpinedBuffer.java
+ src/share/classes/java/util/stream/DistinctOps.java
+ src/share/classes/java/util/stream/DoublePipeline.java
+ src/share/classes/java/util/stream/IntPipeline.java
+ src/share/classes/java/util/stream/LongPipeline.java
+ src/share/classes/java/util/stream/Nodes.java
+ src/share/classes/java/util/stream/ReduceOps.java
+ src/share/classes/java/util/stream/ReferencePipeline.java
+ src/share/classes/java/util/stream/SliceOps.java
+ src/share/classes/java/util/stream/SortedOps.java
+ src/share/classes/java/util/stream/SpinedBuffer.java
+ src/share/classes/java/util/stream/StreamSpliterators.java
+ src/share/classes/java/util/stream/StreamSupport.java



From huizhe.wang at oracle.com  Fri Apr 26 03:29:42 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 25 Apr 2013 20:29:42 -0700
Subject: system reserved property names
In-Reply-To: <5170AF8E.6020501@oracle.com>
References: <516F9276.1010105@oracle.com> <516FB946.1040500@oracle.com>
	<5170748E.3040201@oracle.com> <5170AF8E.6020501@oracle.com>
Message-ID: <5179F4A6.2000806@oracle.com>


On 4/18/2013 7:44 PM, David Holmes wrote:
> On 19/04/2013 8:32 AM, huizhe wang wrote:
>>
>> On 4/18/2013 2:13 AM, Alan Bateman wrote:
>>> On 18/04/2013 07:28, huizhe wang wrote:
>>>> System.getProperties [1] returns all of the "current" system
>>>> properties. Is there a way to get a list of the system reserved
>>>> properties such as "java.version" and etc.? Would anyone know?
>>>>
>>>>
>>>> [1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29 
>>>>
>>>>
>>> I'm not 100% sure what you mean by "reserved" but I will guess that
>>> you asking if there is a complete list of the system properties
>>> defined by the Java SE APIs and perhaps the list of JDK-specific
>>> system properties too. Off-hand, I'm not aware of a master list, they
>>> are instead "buried" in the API specs. Is the context the system
>>> properties that JAXP 1.5 is proposing to define?
>>
>> Yes, those defined by the Java SE APIs or the JDK-specific system
>> properties. Not related to JAXP 1.5, I'm just asking a general question
>> to find out if there's an API to get the 'master' list.
>
> As with Alan I don't know what you mean by "reserved". The 
> documentation you link to above tells you what properties must exist. 
> But an implementation can add other properties. I don't know if there 
> is any rule that says they can't add properties in the java.* namespace.

I meant to ask if there's an API to get the list of JDK-specific system 
properties, and it seems there's none.

Thanks,
Joe

>
> David
>
>> -Joe
>>
>>
>>> -Alan
>>



From peter.levart at gmail.com  Fri Apr 26 06:53:27 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 26 Apr 2013 08:53:27 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <5179A5F5.4070503@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
Message-ID: <517A2467.4070300@gmail.com>

Hi Mandy,

Just a note on null keys (1st level)...

On 04/25/2013 11:53 PM, Mandy Chung wrote:
> Hi Peter,
>
> This looks great.  I have imported your patch with slight modification 
> in WeakCache:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.01/
>
> I believe WeakCache.get(K, P) should throw NPE if key is null and I 
> fixed that. 

The null key support is necessary to support bootstrap classloader as a 
key. It could be supported by a separate 2nd-level map internally 
(instead of using singleton NULL_KEY substitute Object), but the 
external API must support null. And as I can see the webrev at above URL 
still supports it.

> I changed refQueue to be of type ReferenceQueue rather than 
> ReferenceQueue since CacheValue no longer added to the ref 
> queue.  In the expungeStaleEntries method, change CacheKey to 
> CacheKey.  WeakCache.get(K, P) takes instance of K and P but 
> subKeyFactory and valueFactory take superclasses of K and P - is that 
> what you really want?  I have changed them to BiFunction. I 
> also fixed a few typos and that's all.

It's just standard wildcards to allow functions with contra-varint 
parameters and co-variant returns. It's useful as a generic API but in 
our concrete usage doesn't have a value.

> The performance improvement is significant and I want to push this 
> version to jdk8/tl.  We can tune the memory usage in the future if 
> that turns out to be an issue.  I don't have plan to backport to 
> jdk7u-dev unless there are customers escalating this :)  This should 
> be easy to convert without using BiFunction and Supplier and I will 
> leave it as it is until there is a request to backport.
>
> I keep Key2 class since jdk also creates a proxy of 2 interfaces and 
> you have already implemented it.  If we think of a better way to 
> replace the generation of the subkey in an optimized way, we could 
> improve that in the future.  The first and second level maps 
> maintained in the WeakCache have Object as the type for the key which 
> I think we should look for a specific type (CacheKey and SubKey 
> type).  To make the key of the first-level map to CacheKey would need 
> to keep a separate cache for null key.  For the second-level map, the 
> subkey type would need to be declared as a parameter type to 
> WeakCache.  They are something that we should look at and clean up in 
> the future if appropriate.  I think what you have is good work that 
> shouldn't be delayed any further.

The CacheKey is only private and internal to WeekCache, so making the 
1st-level map's key as Object allows for NULL_KEY trick and makes logic 
more uniform. If bootstrap classloader is used a lot to define proxy 
classes, then a separate map can be viewed as a little speed-up for a 
special case though (saves one Map.get, but introduces complications 
with lazy instantiation - with AtomicReference perhaps). The sub-key as 
a type parameter would only have some value if we would want the user of 
WeakCache to constrain himself on the type of sub-keys returned by the 
supplied subKeyFunction - so the constraint (the type of sub-keys) would 
be specified together with the constrained function - at the WeakCache 
constructor call site. In our case we would have to instantiate it as 
Object (the common supertype of key0, Key1, Key2 and KeyX). The type 
parameter for sub-key has little value in general, since WeakCache only 
needs them to be Objects and sub-keys are never "returned" from the 
methods of the public API...

>
> I'm running more tests.  If the above webrev looks fine with you, I'll 
> push the changeset tomorrow.
>
> thanks
> Mandy

Fingers crossed.

Regards, Peter

>
> On 4/25/13 8:40 AM, Peter Levart wrote:
>> Hi Mandy,
>>
>> Here's another update that changes the sub-key back to 
>> WeakReference based:
>>
>> http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.05/index.html
>>
>> On 04/25/2013 03:38 AM, Mandy Chung wrote:
>>> I like this one too.  The mapping is straight forward and clean that 
>>> avoids the fallback and post validation path. Let's proceed with 
>>> this one.  It's good to optimize for the common case (1-interface). 
>>> For 2 or more interfaces, we can improve the memory usage in the 
>>> future when it turns out to be an issue.  I'm fine with the 
>>> zero-interface proxy which is the current implementation too.
>>
>> I made 3 straight-forward implementations of sub-keys:
>> - Key1 - single interface
>> - Key2 - two interfaces
>> - KeyX - any number of interfaces
>>
>> The cache-structure size increment for each new cached proxy-class is 
>> (32 bit OOPS):
>>
>> #of intfcs  original  patched
>> ----------  --------  ------------
>>          1       152  128(Key1)
>>          2       152  168(Key2), 208(KeyX)
>>          3       160  248(KeyX)
>>          4       160  280(KeyX)
>>
>> ...so you can decide if Key2 is worth having or not.
>>
>>>
>>> WeakCache.java
>>>    The javadoc for the get(K,P) method - @throws RuntimeException 
>>> and @throws Error are not needed here since any method being called 
>>> in the implementation may throw unchecked exceptions.  There are a 
>>> couple places that checks if (reverseMap != null) .... that check is 
>>> not needed since it's always non-null.  But I'm fine if you keep it 
>>> as it is - just wanted to mention it in case it was just leftover 
>>> from the previous version.
>>
>> Removed the unneeded @throws and reverseMap != null checks (the later 
>> was already removed in latest string-based webrev and I used that 
>> version here).
>>
>>>
>>> I think we're very close of getting this pushed.
>>>
>>
>> Do you think this could also get backported to JDK7? The WeakCache 
>> uses two interfaces from java.util.function. Should we make private 
>> equivalents in this patch or do we leave that for the possible 
>> back-porting effort. I should note that JDK7's ConcurrentHashMap is 
>> not that space-efficient as proposed JDK8's, so space-usage would be 
>> different on JDK7...
>>
>> Regards, Peter
>>
>>>
>>>
>>> thanks
>>> Mandy
>>
>



From mandy.chung at oracle.com  Fri Apr 26 06:57:43 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Apr 2013 23:57:43 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517A2467.4070300@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
	<517A2467.4070300@gmail.com>
Message-ID: <517A2567.9040808@oracle.com>


On 4/25/2013 11:53 PM, Peter Levart wrote:
>> I believe WeakCache.get(K, P) should throw NPE if key is null and I 
>> fixed that. 
>

Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V 
value) should throw NPE if value is null.

Mandy


From david.holmes at oracle.com  Fri Apr 26 07:27:47 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Apr 2013 17:27:47 +1000
Subject: RFR 8010280: jvm.cfg needs updating for non-server builds
In-Reply-To: <516B474B.8090404@oracle.com>
References: <516B474B.8090404@oracle.com>
Message-ID: <517A2C73.306@oracle.com>

Here is the final form of this after CCC approval.

http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/

For the "traditional" build of client+server we continue to use the 
platform specific jvm.cfg files committed into the source repository. 
Consequently no product builds (SE or Embedded) are altered by this 
proposal. (Those files already contain "-minimal KNOWN" if applicable to 
that platform.)

Otherwise we define a jvm.cfg file where:
- the default VM is the "dominant" VM (server > client > minimal)
- a missing client/server is aliased to the default VM
- the minimal VM is only present in the jvm.cfg file if it is built

Further, as a target of opportunity we stop generating, and delete from 
the existing jvm.cfg files the legacy entries for "hotspot", "classic", 
"native" and "green"

Thanks,
David

Generated jvm.cfg contents based on selected JVM variants:

::::::::::::::
client
::::::::::::::
-client KNOWN
-server ALIASED_TO -client

::::::::::::::
minimal+client
::::::::::::::
-client KNOWN
-server ALIASED_TO -client
-minimal KNOWN

::::::::::::::
minimal
::::::::::::::
-minimal KNOWN
-server ALIASED_TO -minimal
-client ALIASED_TO -minimal

::::::::::::::
minimal+server
::::::::::::::
-server KNOWN
-client ALIASED_TO -server
-minimal KNOWN

::::::::::::::
server
::::::::::::::
-server KNOWN
-client ALIASED_TO -server


On 15/04/2013 10:18 AM, David Holmes wrote:
> Some background.
>
> The jvm.cfg file, for which there is a per-architecture committed file
> in the repository, controls which VM's (client, server, minimal) are
> known, which is the default, whether there are other aliases and whether
> ergonomic selection is used.
>
> Historically things were simple:
> - 64-bit platforms had server only
> - 32-bit platforms had client and server
>
> then we acknowledged that some platforms may be client only and we added
> some support (originally in the old build then converted to the new
> build) for dynamically creating a jvm.cfg for the case of building
> client only.
>
> Then the minimal VM was introduced and we potentially have three VMs to
> handle. To address this we initially added "-minimal KNOWN" to all the
> jvm.cfg files for platforms known to support the minimal VM - this was
> done under JDK-7198815 (and those changes are now reversed by this
> changeset.)
>
> The problem after minimal was introduced was that the logic for
> "building client only" didn't account for building minimal (only or
> combined with client) and we need support for not-building-server. And
> that is what this changeset does.
>
> This only affects 32-bit builds as there is no client nor minimal VM on
> 64-bit. The basic operation is as follows:
>
> - If building client+server then we use the committed jvm.cfg (which
> handles ergonomics if applicable), adding a "-minimal KNOWN" line if
> minimal is also selected;
> - Otherwise we dynamically generate a jvm.cfg for the set of VMs being
> built, using these simple rules:
>    - if client or server are present they are default
>    - if client and/or server is absent then the absent VM is aliased to
> the default VM in that config
>    - if minimal is not selected then it is absent from the jvm.cfg (we
> do not add any aliases for minimal**).
>
> ** The alias mechanism is useful for deprecating legacy VM names, and
> has also made testing more convenient. However I think it is a flawed
> mechanism for testing and our internal test infrastructure is moving
> away from arbitrarily using -client/-server when actually running
> server/client. If you ask for the minimal VM and it is not available I
> think you should get an error not silent use of a different VM. (Note:
> this selection doesn't affect SE Embedded as it defines jvm.cfg files
> using it's own rules/preferences.)
>
> webrev:
>
> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>
> Thanks,
> David


From vicente.romero at oracle.com  Fri Apr 26 09:05:19 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 26 Apr 2013 09:05:19 +0000
Subject: hg: jdk8/tl/langtools: 8012723: strictfp interface misses strictfp
	modifer on default method
Message-ID: <20130426090529.6A5D448609@hg.openjdk.java.net>

Changeset: 3c02d2f1a421
Author:    vromero
Date:      2013-04-26 10:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3c02d2f1a421

8012723: strictfp interface misses strictfp modifer on default method
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/defaultMethods/CheckACC_STRICTFlagOnDefaultMethodTest.java



From peter.levart at gmail.com  Fri Apr 26 09:13:15 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 26 Apr 2013 11:13:15 +0200
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517A2567.9040808@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
	<517A2467.4070300@gmail.com> <517A2567.9040808@oracle.com>
Message-ID: <517A452B.2060403@gmail.com>

On 04/26/2013 08:57 AM, Mandy Chung wrote:
>
> On 4/25/2013 11:53 PM, Peter Levart wrote:
>>> I believe WeakCache.get(K, P) should throw NPE if key is null and I 
>>> fixed that. 
>>
>
> Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V 
> value) should throw NPE if value is null.

I agree. Analogous to ConcurrentHashMap, for example.

>
> Mandy



From david.holmes at oracle.com  Fri Apr 26 09:17:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Apr 2013 19:17:59 +1000
Subject: system reserved property names
In-Reply-To: <5179F4A6.2000806@oracle.com>
References: <516F9276.1010105@oracle.com> <516FB946.1040500@oracle.com>
	<5170748E.3040201@oracle.com> <5170AF8E.6020501@oracle.com>
	<5179F4A6.2000806@oracle.com>
Message-ID: <517A4647.1060909@oracle.com>

On 26/04/2013 1:29 PM, huizhe wang wrote:
>
> On 4/18/2013 7:44 PM, David Holmes wrote:
>> On 19/04/2013 8:32 AM, huizhe wang wrote:
>>>
>>> On 4/18/2013 2:13 AM, Alan Bateman wrote:
>>>> On 18/04/2013 07:28, huizhe wang wrote:
>>>>> System.getProperties [1] returns all of the "current" system
>>>>> properties. Is there a way to get a list of the system reserved
>>>>> properties such as "java.version" and etc.? Would anyone know?
>>>>>
>>>>>
>>>>> [1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29
>>>>>
>>>>>
>>>> I'm not 100% sure what you mean by "reserved" but I will guess that
>>>> you asking if there is a complete list of the system properties
>>>> defined by the Java SE APIs and perhaps the list of JDK-specific
>>>> system properties too. Off-hand, I'm not aware of a master list, they
>>>> are instead "buried" in the API specs. Is the context the system
>>>> properties that JAXP 1.5 is proposing to define?
>>>
>>> Yes, those defined by the Java SE APIs or the JDK-specific system
>>> properties. Not related to JAXP 1.5, I'm just asking a general question
>>> to find out if there's an API to get the 'master' list.
>>
>> As with Alan I don't know what you mean by "reserved". The
>> documentation you link to above tells you what properties must exist.
>> But an implementation can add other properties. I don't know if there
>> is any rule that says they can't add properties in the java.* namespace.
>
> I meant to ask if there's an API to get the list of JDK-specific system
> properties, and it seems there's none.

Do you want to be able to determine which properties in 
System.getProperties() are mandated by the platform specification versus 
being properties the current implementation happens to provide? If so, 
no there is no API to do that.

David

> Thanks,
> Joe
>
>>
>> David
>>
>>> -Joe
>>>
>>>
>>>> -Alan
>>>
>


From vicente.romero at oracle.com  Fri Apr 26 09:18:23 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 26 Apr 2013 09:18:23 +0000
Subject: hg: jdk8/tl/langtools: 8008562: javac,
	a refactoring to Bits is necessary in order to provide a change
	history
Message-ID: <20130426091831.8A8B24860A@hg.openjdk.java.net>

Changeset: 2ca9e7d50136
Author:    vromero
Date:      2013-04-26 10:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2ca9e7d50136

8008562: javac, a refactoring to Bits is necessary in order to provide a change history
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/util/Bits.java



From paul.sandoz at oracle.com  Fri Apr 26 11:43:07 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Apr 2013 13:43:07 +0200
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <5179BBAA.2010506@oracle.com>
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
	<5179BBAA.2010506@oracle.com>
Message-ID: 

On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan  wrote:
> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>> 
>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
> 
> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
> can shed some light on that.
> 

If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.

Paul.

From paul.sandoz at oracle.com  Fri Apr 26 11:52:19 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Apr 2013 13:52:19 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <51781D04.7000907@univ-mlv.fr>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
Message-ID: 


On Apr 24, 2013, at 7:57 PM, Remi Forax  wrote:

> On 04/24/2013 07:24 PM, Akhil Arora wrote:
>> On 04/24/2013 06:19 AM, Alan Bateman wrote:
>>> On 23/04/2013 20:18, Akhil Arora wrote:
>>>> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>>>>> One thing I meant to ask when forEachRemaining was added was whether it
>>>>> should say anything about the "last element"? I see in the webrev that
>>>>> you've set it for the ArrayList iterators but not the LinkedList
>>>>> iterator - should it?
>>>> 
>>>> done, and added more tests for the state of the iterator after
>>>> forEachRemaining returns
>>>> 
>>>> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>>>> 
>>>> (a portion of version 1 of the webrev has already been pushed to TL as
>>>> part of rev 6973 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
>>> The remaining changes in the webrev looks okay to me. Also good to have
>>> the test expanded.
>>> 
>>> So do you think that the javadoc should say anything about the
>>> relationship between forEachRemaining and remove?
>> 
>> Good question. forEachRemaining docs state -
>> 
>> Implementation Requirements:
>> 
>>    The default implementation behaves as if:
>> 
>>    while (hasNext())
>>             action.accept(next());
>> 
>> so a subsequent remove() should remove the last element.
>> 
>> To avoid blocking the feature, I have filed
>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove and other ListIterator methods after forEachRemaining returns.
> 
> I think the fact that the last element can be removed should be specified as unspecified,
> because it's more an artefact of the default implementation than something which part
> of the semantics.
> 

I was wondering about that too. What happens if an implementing class decides later on to override the default implementation? If the overriding implementation does not conform to the same behaviour as the default it could break compatibility. 

Plus one could change code from:

  while(it.hasNext() { doSomething(it.next()); }
  doSomethingAtEnd(it);

to

  it.forEachRemaining(this::doSomething}
  doSomethingAtEnd(it);

Paul.

From david.holmes at oracle.com  Fri Apr 26 12:06:56 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Apr 2013 22:06:56 +1000
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: 
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
Message-ID: <517A6DE0.4080602@oracle.com>

On 26/04/2013 9:52 PM, Paul Sandoz wrote:
>
> On Apr 24, 2013, at 7:57 PM, Remi Forax  wrote:
>
>> On 04/24/2013 07:24 PM, Akhil Arora wrote:
>>> On 04/24/2013 06:19 AM, Alan Bateman wrote:
>>>> On 23/04/2013 20:18, Akhil Arora wrote:
>>>>> On 04/22/2013 11:42 AM, Alan Bateman wrote:
>>>>>> One thing I meant to ask when forEachRemaining was added was whether it
>>>>>> should say anything about the "last element"? I see in the webrev that
>>>>>> you've set it for the ArrayList iterators but not the LinkedList
>>>>>> iterator - should it?
>>>>>
>>>>> done, and added more tests for the state of the iterator after
>>>>> forEachRemaining returns
>>>>>
>>>>> http://cr.openjdk.java.net/~akhil/8005051.2/webrev/
>>>>>
>>>>> (a portion of version 1 of the webrev has already been pushed to TL as
>>>>> part of rev 6973 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a7bb7baa76)
>>>> The remaining changes in the webrev looks okay to me. Also good to have
>>>> the test expanded.
>>>>
>>>> So do you think that the javadoc should say anything about the
>>>> relationship between forEachRemaining and remove?
>>>
>>> Good question. forEachRemaining docs state -
>>>
>>> Implementation Requirements:
>>>
>>>     The default implementation behaves as if:
>>>
>>>     while (hasNext())
>>>              action.accept(next());
>>>
>>> so a subsequent remove() should remove the last element.
>>>
>>> To avoid blocking the feature, I have filed
>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove and other ListIterator methods after forEachRemaining returns.
>>
>> I think the fact that the last element can be removed should be specified as unspecified,
>> because it's more an artefact of the default implementation than something which part
>> of the semantics.
>>
>
> I was wondering about that too. What happens if an implementing class decides later on to override the default implementation? If the overriding implementation does not conform to the same behaviour as the default it could break compatibility.
>
> Plus one could change code from:
>
>    while(it.hasNext() { doSomething(it.next()); }
>    doSomethingAtEnd(it);
>
> to
>
>    it.forEachRemaining(this::doSomething}
>    doSomethingAtEnd(it);

All implementations must obey the contract of the specification, and no 
clients should assume any kind of behaviour beyond what that contract says.

That said I've lost the context of this particular issue - what is the 
problem here?

David

> Paul.
>


From Alan.Bateman at oracle.com  Fri Apr 26 12:24:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Apr 2013 13:24:26 +0100
Subject: Review request: JDK-8012453 (process) Runtime.exec(String) fails
	if command contains spaces [win]
In-Reply-To: <517940B3.2050609@oracle.com>
References: <51768B23.6060506@oracle.com> <5176E367.9090601@oracle.com>
	<5177D6EC.8020304@oracle.com> <5177EAFB.7000803@oracle.com>
	<517940B3.2050609@oracle.com>
Message-ID: <517A71FA.9040608@oracle.com>

On 25/04/2013 15:41, Alexey Utkin wrote:
> Alan,
>
> Thanks for your comments.
> I did the changes in code.
> Please, read my answers below.
>
> Here is fixed version:
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.02/
The implementation changes look good now.


> :
>
>> One thing I see is that it doesn't read from the child's output/error 
>> streams so if there is a problem then it will be hard to diagnose 
>> from the logs.
> The diagnostic includes logging of the command line  in problem. It 
> should not be a problem to localize issue.
We'll see, sometimes it is hard to diagnose issues when you can see the 
output from the child. What you have is fine and we can easily change 
the test if we run into issues.

-Alan


From Ulf.Zibis at CoSoCo.de  Fri Apr 26 12:29:06 2013
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Fri, 26 Apr 2013 14:29:06 +0200
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: 
References: 
Message-ID: <517A7312.30709@CoSoCo.de>

I think, sometimes it is better to violate those 2 rules because:
- modern wide-screens have much horizontal, but less vertical space, especially on labtops
- line break for only one/few word(s) looks ugly, disturbs read-flow
- it's no problem, if e.g. 1 of 50 lines must be scrolled a little horizontally, but it's a big 
problem if I have to vertically scroll twice often, when too much lines are "wasted". Comparing and 
understanding code then becomes a nightmare.

Referring to your example, on the other hand, continuation lines should be indented 8 rather than 4 
spaces to separate them from logical nesting. Especially your last line looks like less nested than 
the three before, which IMHO is a clear mistake.

-Ulf


Am 25.04.2013 22:57, schrieb Paul Benedict:
> Henry,
>
> I believe the coding standards require curly braces for any if-statement
> and for-loop.
>
> Also the return statements exceed the 80 character limit. It would be nice
> to have them formatted across several lines like the following because it's
> difficult to read going straight across:
>
> return StreamSupport.intStream(() ->
>          Spliterators.spliterator(
>              new CharIterator(),
>              length(),
>              Spliterator.ORDERED),
>          Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED);
>
> Paul
>



From Alan.Bateman at oracle.com  Fri Apr 26 12:35:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Apr 2013 13:35:40 +0100
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver
	to notify the JDBC driver that it has been deregistered.
In-Reply-To: <5A44649D-1662-422D-948E-FDA5380FC9BC@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
	<5175378D.4010800@oracle.com>
	<8AFCEB1B-E102-4469-9F0E-FF895955C007@oracle.com>
	<5A44649D-1662-422D-948E-FDA5380FC9BC@oracle.com>
Message-ID: <517A749C.9050605@oracle.com>

On 25/04/2013 21:53, Lance Andersen - Oracle wrote:
> http://cr.openjdk.java.net/~lancea/8010416/webrev.03/  addresses the typos that were pointed out and also fixes a couple javadoc warnings
>
This looks okay to me.

One small suggestion for DriverAction and the first statement where it 
reads " ... when a Driver wants to be notified by DriverManager". It 
might be better as "... to receive notifications from the 
DriverManager". I suggest this because it's not specifically the Driver 
that is notified.

-Alan.




From paul.sandoz at oracle.com  Fri Apr 26 12:50:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Apr 2013 14:50:05 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <517A6DE0.4080602@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
Message-ID: 

On Apr 26, 2013, at 2:06 PM, David Holmes  wrote:
>>>> 
>>>> To avoid blocking the feature, I have filed
>>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove and other ListIterator methods after forEachRemaining returns.
>>> 
>>> I think the fact that the last element can be removed should be specified as unspecified,
>>> because it's more an artefact of the default implementation than something which part
>>> of the semantics.
>>> 
>> 
>> I was wondering about that too. What happens if an implementing class decides later on to override the default implementation? If the overriding implementation does not conform to the same behaviour as the default it could break compatibility.
>> 
>> Plus one could change code from:
>> 
>>   while(it.hasNext() { doSomething(it.next()); }
>>   doSomethingAtEnd(it);
>> 
>> to
>> 
>>   it.forEachRemaining(this::doSomething}
>>   doSomethingAtEnd(it);
> 
> All implementations must obey the contract of the specification, and no clients should assume any kind of behaviour beyond what that contract says.
> 
> That said I've lost the context of this particular issue - what is the problem here?
> 

What is the state of the Iterator after a call to Iterator.forEachRemaining e.g.:

  void doSometingAtEnd(Iterator it) {
    it.remove(); 
  }

IMO overriding forEachRemaining implementations should place the iterator in the same state as the default method implementation. We just need to call this out more clearly in the docs.

Paul.

From forax at univ-mlv.fr  Fri Apr 26 13:06:20 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 26 Apr 2013 15:06:20 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: 
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
	
Message-ID: <517A7BCC.9030209@univ-mlv.fr>

On 04/26/2013 02:50 PM, Paul Sandoz wrote:
> On Apr 26, 2013, at 2:06 PM, David Holmes  wrote:
>>>>> To avoid blocking the feature, I have filed
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove and other ListIterator methods after forEachRemaining returns.
>>>> I think the fact that the last element can be removed should be specified as unspecified,
>>>> because it's more an artefact of the default implementation than something which part
>>>> of the semantics.
>>>>
>>> I was wondering about that too. What happens if an implementing class decides later on to override the default implementation? If the overriding implementation does not conform to the same behaviour as the default it could break compatibility.
>>>
>>> Plus one could change code from:
>>>
>>>    while(it.hasNext() { doSomething(it.next()); }
>>>    doSomethingAtEnd(it);
>>>
>>> to
>>>
>>>    it.forEachRemaining(this::doSomething}
>>>    doSomethingAtEnd(it);
>> All implementations must obey the contract of the specification, and no clients should assume any kind of behaviour beyond what that contract says.
>>
>> That said I've lost the context of this particular issue - what is the problem here?
>>
> What is the state of the Iterator after a call to Iterator.forEachRemaining e.g.:
>
>    void doSometingAtEnd(Iterator it) {
>      it.remove();
>    }
>
> IMO overriding forEachRemaining implementations should place the iterator in the same state as the default method implementation. We just need to call this out more clearly in the docs.

I don't like the fact that the default implementation dictates the 
semantics of forEachRemaining.
It's cleaner to separate the two and says that you can replace the while 
loop by forEachRemaining
only if the iterator is not used after the while loop.

Basically, it means that the semantics of forEachRemaining is more like 
the semantics of the enhanced for loop.

>
> Paul.

R?mi



From Alan.Bateman at oracle.com  Fri Apr 26 13:21:33 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Apr 2013 14:21:33 +0100
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: <51799135.5020801@oracle.com>
References: <51799135.5020801@oracle.com>
Message-ID: <517A7F5D.8050206@oracle.com>

On 25/04/2013 21:25, Henry Jen wrote:
> Hi,
>
> Please review two default methods add to CharSequence returns IntStream
> of char value or code point value.
>
> http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
>
> The synchronization test is relieved so lambda and other synthetic
> method is not tested. If synchronization is needed for those two default
> methods, subclass should override the methods.
>
> With charAt and codePointAt properly synchronized, the default
> implementation is sufficient. However as noted, if the sequence is
> mutated while the stream is being read, the result is undefined.
>
> Cheers,
> Henry
I looked through the webrev and it looks okay as a first version. I 
agree with Martin's suggestion on the performance. I also wonder if 
CharBuffer will need to override at least chars(). This could of course 
be done as a follow-on piece of work.

In TestSynchronization then I assume the commented System.out should be 
removed.

-Alan.



From forax at univ-mlv.fr  Fri Apr 26 13:25:46 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 26 Apr 2013 15:25:46 +0200
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: 
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
	<5179BBAA.2010506@oracle.com>
	
Message-ID: <517A805A.3030808@univ-mlv.fr>

On 04/26/2013 01:43 PM, Paul Sandoz wrote:
> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan  wrote:
>> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>>>
>>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
>> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
>> can shed some light on that.
>>
> If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.

The"rampant layering violation" was introduced consciously.
ASM is still used on small devices to re-transform bytecodes at runtime 
(ASM was originally created for that)
so the core of ASM tries to minimize its memory impact, hence use tricks 
to avoid to create more classes than it should.

>
> Paul.

R?mi



From mark.sheppard at oracle.com  Fri Apr 26 13:55:45 2013
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 26 Apr 2013 14:55:45 +0100
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that
	unexpectedly inserts line separator when using some of the encoding
	methods
Message-ID: <517A8761.2090908@oracle.com>

Hi,
    please oblige with a review of the fix for the issue JDK-8007799 as 
shown in the webrev
below:

http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/

This fix takes into account the feedback from the initial review and
condenses the solution to a check on the line length in the getEncoder() 
method,
which will return an RFC4648 base64 encoder when the line length <=0.
The RFC4648 base64 encoder provides the required semantics specified
in the API.

regards
Mark


From paul.sandoz at oracle.com  Fri Apr 26 14:12:43 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Apr 2013 16:12:43 +0200
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <517A805A.3030808@univ-mlv.fr>
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
	<5179BBAA.2010506@oracle.com>
	
	<517A805A.3030808@univ-mlv.fr>
Message-ID: 


On Apr 26, 2013, at 3:25 PM, Remi Forax  wrote:

> On 04/26/2013 01:43 PM, Paul Sandoz wrote:
>> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan  wrote:
>>> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>>>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>>>> 
>>>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
>>> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
>>> can shed some light on that.
>>> 
>> If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.
> 
> The"rampant layering violation" was introduced consciously.
> ASM is still used on small devices to re-transform bytecodes at runtime (ASM was originally created for that)
> so the core of ASM tries to minimize its memory impact, hence use tricks to avoid to create more classes than it should.
> 

Is it really so terribly constrained that there is no room for another class?

Out of curiosity how much does the static memory footprint increase by if you add an additional class implementing an Iterator over 0, 1, or 2 elements?

Paul.

From peter.levart at gmail.com  Fri Apr 26 14:22:54 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 26 Apr 2013 16:22:54 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <517A7BCC.9030209@univ-mlv.fr>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
	
	<517A7BCC.9030209@univ-mlv.fr>
Message-ID: <517A8DBE.6080807@gmail.com>

On 04/26/2013 03:06 PM, Remi Forax wrote:
> On 04/26/2013 02:50 PM, Paul Sandoz wrote:
>> On Apr 26, 2013, at 2:06 PM, David Holmes  
>> wrote:
>>>>>> To avoid blocking the feature, I have filed
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the 
>>>>>> behavior of remove and other ListIterator methods after 
>>>>>> forEachRemaining returns.
>>>>> I think the fact that the last element can be removed should be 
>>>>> specified as unspecified,
>>>>> because it's more an artefact of the default implementation than 
>>>>> something which part
>>>>> of the semantics.
>>>>>
>>>> I was wondering about that too. What happens if an implementing 
>>>> class decides later on to override the default implementation? If 
>>>> the overriding implementation does not conform to the same 
>>>> behaviour as the default it could break compatibility.
>>>>
>>>> Plus one could change code from:
>>>>
>>>>    while(it.hasNext() { doSomething(it.next()); }
>>>>    doSomethingAtEnd(it);
>>>>
>>>> to
>>>>
>>>>    it.forEachRemaining(this::doSomething}
>>>>    doSomethingAtEnd(it);
>>> All implementations must obey the contract of the specification, and 
>>> no clients should assume any kind of behaviour beyond what that 
>>> contract says.
>>>
>>> That said I've lost the context of this particular issue - what is 
>>> the problem here?
>>>
>> What is the state of the Iterator after a call to 
>> Iterator.forEachRemaining e.g.:
>>
>>    void doSometingAtEnd(Iterator it) {
>>      it.remove();
>>    }
>>
>> IMO overriding forEachRemaining implementations should place the 
>> iterator in the same state as the default method implementation. We 
>> just need to call this out more clearly in the docs.
>
> I don't like the fact that the default implementation dictates the 
> semantics of forEachRemaining.
> It's cleaner to separate the two and says that you can replace the 
> while loop by forEachRemaining
> only if the iterator is not used after the while loop.
>
> Basically, it means that the semantics of forEachRemaining is more 
> like the semantics of the enhanced for loop.

... which is based on Iterable, not Iterator (the Iterator is not 
accessible in the foreach).

Do you think there could be implementations that are more optimal if 
this is not dictated? If the same object provides an API for both 
internal and external iteration and the internal iteration can continue 
where the external left-off, then it must always be prepared to maintain 
the state for external iteration, so it's not a big deal to update this 
state once at the end of internal iteration. Do you imagine a situation 
where this would actually provide to be difficult or less performant?

What about the following:

Iterator i = ...;

i.forEachRemaining(e -> {...});

i.forEachRemaining(e -> {...});

would the second call to forEachRemaining be specified to not be defined 
too?

Another interesting question. What about the following usage:

Iterator i = ...;

i.forEachRemaining(e -> {
    ...
    if (.. && i.hasNext()) i.next(); // skip one element
    ...
});

Should this be allowed and work as "expected", disallowed and attempted 
to be prevented, or not defined ?

Regards, Peter

>
>>
>> Paul.
>
> R?mi
>



From peter.levart at gmail.com  Fri Apr 26 14:37:17 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 26 Apr 2013 16:37:17 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <517A7BCC.9030209@univ-mlv.fr>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
	
	<517A7BCC.9030209@univ-mlv.fr>
Message-ID: <517A911D.8040800@gmail.com>

On 04/26/2013 03:06 PM, Remi Forax wrote:
> On 04/26/2013 02:50 PM, Paul Sandoz wrote:
>> On Apr 26, 2013, at 2:06 PM, David Holmes  
>> wrote:
>>>>>> To avoid blocking the feature, I have filed
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the 
>>>>>> behavior of remove and other ListIterator methods after 
>>>>>> forEachRemaining returns.
>>>>> I think the fact that the last element can be removed should be 
>>>>> specified as unspecified,
>>>>> because it's more an artefact of the default implementation than 
>>>>> something which part
>>>>> of the semantics.
>>>>>
>>>> I was wondering about that too. What happens if an implementing 
>>>> class decides later on to override the default implementation? If 
>>>> the overriding implementation does not conform to the same 
>>>> behaviour as the default it could break compatibility.
>>>>
>>>> Plus one could change code from:
>>>>
>>>>    while(it.hasNext() { doSomething(it.next()); }
>>>>    doSomethingAtEnd(it);
>>>>
>>>> to
>>>>
>>>>    it.forEachRemaining(this::doSomething}
>>>>    doSomethingAtEnd(it);
>>> All implementations must obey the contract of the specification, and 
>>> no clients should assume any kind of behaviour beyond what that 
>>> contract says.
>>>
>>> That said I've lost the context of this particular issue - what is 
>>> the problem here?
>>>
>> What is the state of the Iterator after a call to 
>> Iterator.forEachRemaining e.g.:
>>
>>    void doSometingAtEnd(Iterator it) {
>>      it.remove();
>>    }
>>
>> IMO overriding forEachRemaining implementations should place the 
>> iterator in the same state as the default method implementation. We 
>> just need to call this out more clearly in the docs.
>
> I don't like the fact that the default implementation dictates the 
> semantics of forEachRemaining.
> It's cleaner to separate the two and says that you can replace the 
> while loop by forEachRemaining
> only if the iterator is not used after the while loop.
>
> Basically, it means that the semantics of forEachRemaining is more 
> like the semantics of the enhanced for loop.

Another "interesting" usage:

Iterator i = ...;

i.forEachRemaining(e -> {
    ...
    if (...) {
       i.forEachRemaining(dummy -> {}); // drain it
    }
    ...
});

It seems that mixing external and internal iteration in the same object 
is like a box of chocolates. For internal iteration, Iterable.forEach is 
more suitable than Iterator.forEachRemaining unless the later is 
specified to have the common state for both external and internal 
iteration, which means that internal can not be more effective than 
external.

Regards, Peter

>
>>
>> Paul.
>
> R?mi
>



From pbenedict at apache.org  Fri Apr 26 14:48:38 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 26 Apr 2013 09:48:38 -0500
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: <517A7312.30709@CoSoCo.de>
References: 
	<517A7312.30709@CoSoCo.de>
Message-ID: 

Ulf, I have my opinions too on code style. However, the published
guidelines for Java code is what Oracle/Sun set out for themselves. AFAIK,
it is what's expected for JDK source.


On Fri, Apr 26, 2013 at 7:29 AM, Ulf Zibis  wrote:

> I think, sometimes it is better to violate those 2 rules because:
> - modern wide-screens have much horizontal, but less vertical space,
> especially on labtops
> - line break for only one/few word(s) looks ugly, disturbs read-flow
> - it's no problem, if e.g. 1 of 50 lines must be scrolled a little
> horizontally, but it's a big problem if I have to vertically scroll twice
> often, when too much lines are "wasted". Comparing and understanding code
> then becomes a nightmare.
>
> Referring to your example, on the other hand, continuation lines should be
> indented 8 rather than 4 spaces to separate them from logical nesting.
> Especially your last line looks like less nested than the three before,
> which IMHO is a clear mistake.
>
> -Ulf
>
>
> Am 25.04.2013 22:57, schrieb Paul Benedict:
>
>  Henry,
>>
>> I believe the coding standards require curly braces for any if-statement
>> and for-loop.
>>
>> Also the return statements exceed the 80 character limit. It would be nice
>> to have them formatted across several lines like the following because
>> it's
>> difficult to read going straight across:
>>
>> return StreamSupport.intStream(() ->
>>          Spliterators.spliterator(
>>              new CharIterator(),
>>              length(),
>>              Spliterator.ORDERED),
>>          Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED);
>>
>> Paul
>>
>>
>


From vicente.romero at oracle.com  Fri Apr 26 15:00:19 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 26 Apr 2013 15:00:19 +0000
Subject: hg: jdk8/tl/langtools: 8010304: javac should detect all mutable
	implicit static fields in langtools using a plugin
Message-ID: <20130426150026.4A90948635@hg.openjdk.java.net>

Changeset: f3f3ac1273e8
Author:    vromero
Date:      2013-04-26 15:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3f3ac1273e8

8010304: javac should detect all mutable implicit static fields in langtools using a plugin
Reviewed-by: jjg

! make/build.xml
+ make/tools/crules/AbstractCodingRulesAnalyzer.java
+ make/tools/crules/MutableFieldsAnalyzer.java
+ make/tools/crules/resources/crules.properties



From xueming.shen at oracle.com  Fri Apr 26 15:04:39 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Apr 2013 08:04:39 -0700
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder
	that unexpectedly inserts line separator when using some of the
	encoding methods
In-Reply-To: <517A8761.2090908@oracle.com>
References: <517A8761.2090908@oracle.com>
Message-ID: <517A9787.4090802@oracle.com>

On 4/26/13 6:55 AM, Mark Sheppard wrote:
> Hi,
>    please oblige with a review of the fix for the issue JDK-8007799 as 
> shown in the webrev
> below:
>
> http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/
>
> This fix takes into account the feedback from the initial review and
> condenses the solution to a check on the line length in the 
> getEncoder() method,
> which will return an RFC4648 base64 encoder when the line length <=0.
> The RFC4648 base64 encoder provides the required semantics specified
> in the API.
>
> regards
> Mark

Hi Mark,

I think we may still want to non-null-check lineSeparator and its content
first and then the lineLength <=0 (move ln#135-137 down just before ln#145),
otherwise it may fail some tck tests. I understand the line?eparator 
will not
be used in this scenario so the check may look like wasting of time, but I
guess it would be better to still throw the NPE or IAE if they are null 
or having
illegal bytes in it.

The copyright should be "2012, 2013,"?

-Sherman




From brian.goetz at oracle.com  Fri Apr 26 15:16:07 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 26 Apr 2013 11:16:07 -0400
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: 
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
	<5179BBAA.2010506@oracle.com>
	
	<517A805A.3030808@univ-mlv.fr>
	
Message-ID: 

How many years ago was this done?  Hasn't the hardware reality changed since then?  What might have been a justifiable crime then may just be a crime now.  

On Apr 26, 2013, at 10:12 AM, Paul Sandoz wrote:

> 
> On Apr 26, 2013, at 3:25 PM, Remi Forax  wrote:
> 
>> On 04/26/2013 01:43 PM, Paul Sandoz wrote:
>>> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan  wrote:
>>>> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>>>>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>>>>> 
>>>>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
>>>> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
>>>> can shed some light on that.
>>>> 
>>> If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.
>> 
>> The"rampant layering violation" was introduced consciously.
>> ASM is still used on small devices to re-transform bytecodes at runtime (ASM was originally created for that)
>> so the core of ASM tries to minimize its memory impact, hence use tricks to avoid to create more classes than it should.
>> 
> 
> Is it really so terribly constrained that there is no room for another class?
> 
> Out of curiosity how much does the static memory footprint increase by if you add an additional class implementing an Iterator over 0, 1, or 2 elements?
> 
> Paul.



From iris.clark at oracle.com  Fri Apr 26 15:24:26 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 26 Apr 2013 08:24:26 -0700 (PDT)
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder
	that unexpectedly inserts line separator when using some of the
	encoding methods
In-Reply-To: <517A9787.4090802@oracle.com>
References: <517A8761.2090908@oracle.com> <517A9787.4090802@oracle.com>
Message-ID: <869cc0f8-1c5b-430c-89b1-4cc4a6d66ad3@default>

> The copyright should be "2012, 2013,"?

I agree.  The copyright year should be updated as Sherman indicated.

iris

-----Original Message-----
From: Xueming Shen 
Sent: Friday, April 26, 2013 8:05 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that unexpectedly inserts line separator when using some of the encoding methods

On 4/26/13 6:55 AM, Mark Sheppard wrote:
> Hi,
>    please oblige with a review of the fix for the issue JDK-8007799 as 
> shown in the webrev
> below:
>
> http://cr.openjdk.java.net/~msheppar/8007799/webrev.01/
>
> This fix takes into account the feedback from the initial review and 
> condenses the solution to a check on the line length in the
> getEncoder() method,
> which will return an RFC4648 base64 encoder when the line length <=0.
> The RFC4648 base64 encoder provides the required semantics specified 
> in the API.
>
> regards
> Mark

Hi Mark,

I think we may still want to non-null-check lineSeparator and its content first and then the lineLength <=0 (move ln#135-137 down just before ln#145), otherwise it may fail some tck tests. I understand the line?eparator will not be used in this scenario so the check may look like wasting of time, but I guess it would be better to still throw the NPE or IAE if they are null or having illegal bytes in it.

The copyright should be "2012, 2013,"?

-Sherman




From noel.poore at oracle.com  Fri Apr 26 15:30:52 2013
From: noel.poore at oracle.com (Noel Poore)
Date: Fri, 26 Apr 2013 11:30:52 -0400
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: 
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
	<5179BBAA.2010506@oracle.com>
	
	<517A805A.3030808@univ-mlv.fr>
	
	
Message-ID: 

Brian

For any individual case, there is always an argument that "adding a couple of extra classes won't matter", but if that is the answer to every question, the result is something slow and bloated. Also, what frequently happens is that hardware advances are used to deliver lower cost rather than better performance. I don't know enough to comment on this specific issue, but IMO we should be careful not to just say that "hardware has changed, so these things no longer matter." I could go on at some length about this subject, but don't have time to write a long email right now, so I'll stop here.

Noel

On Apr 26, 2013, at 11:16 AM, Brian Goetz wrote:

> How many years ago was this done?  Hasn't the hardware reality changed since then?  What might have been a justifiable crime then may just be a crime now.  
> 
> On Apr 26, 2013, at 10:12 AM, Paul Sandoz wrote:
> 
>> 
>> On Apr 26, 2013, at 3:25 PM, Remi Forax  wrote:
>> 
>>> On 04/26/2013 01:43 PM, Paul Sandoz wrote:
>>>> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan  wrote:
>>>>> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>>>>>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>>>>>> 
>>>>>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
>>>>> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
>>>>> can shed some light on that.
>>>>> 
>>>> If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.
>>> 
>>> The"rampant layering violation" was introduced consciously.
>>> ASM is still used on small devices to re-transform bytecodes at runtime (ASM was originally created for that)
>>> so the core of ASM tries to minimize its memory impact, hence use tricks to avoid to create more classes than it should.
>>> 
>> 
>> Is it really so terribly constrained that there is no room for another class?
>> 
>> Out of curiosity how much does the static memory footprint increase by if you add an additional class implementing an Iterator over 0, 1, or 2 elements?
>> 
>> Paul.
> 



From paul.sandoz at oracle.com  Fri Apr 26 15:46:35 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 26 Apr 2013 17:46:35 +0200
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <517A911D.8040800@gmail.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
	
	<517A7BCC.9030209@univ-mlv.fr> <517A911D.8040800@gmail.com>
Message-ID: <1E5A39D8-BA73-4ADC-AAB1-0DBD02AD5AB9@oracle.com>


On Apr 26, 2013, at 4:37 PM, Peter Levart  wrote:
> 
> Another "interesting" usage:
> 
> Iterator i = ...;
> 
> i.forEachRemaining(e -> {
>   ...
>   if (...) {
>      i.forEachRemaining(dummy -> {}); // drain it
>   }
>   ...
> });
> 
> It seems that mixing external and internal iteration in the same object is like a box of chocolates. For internal iteration, Iterable.forEach is more suitable than Iterator.forEachRemaining unless the later is specified to have the common state for both external and internal iteration, which means that internal can not be more effective than external.
> 

Similar observations can apply to Spliterator as well. IIRC many spliterator.forEachRemaining implementations set up state to be fully traversed before looping. However, it is not possible in all cases.

I think we may have to document that a consumer must not interfere with the current traversal otherwise behaviour is undefined.

Paul.



From mike.duigou at oracle.com  Fri Apr 26 16:10:46 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 26 Apr 2013 09:10:46 -0700
Subject: RFR 8010280: jvm.cfg needs updating for non-server builds
In-Reply-To: <517A2C73.306@oracle.com>
References: <516B474B.8090404@oracle.com> <517A2C73.306@oracle.com>
Message-ID: <14023B19-5E2B-43ED-9859-F8295CE0083B@oracle.com>

Looks good. It's nice to see the legacy entries finally get removed.

Mike

On Apr 26 2013, at 00:27 , David Holmes wrote:

> Here is the final form of this after CCC approval.
> 
> http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
> 
> For the "traditional" build of client+server we continue to use the platform specific jvm.cfg files committed into the source repository. Consequently no product builds (SE or Embedded) are altered by this proposal. (Those files already contain "-minimal KNOWN" if applicable to that platform.)
> 
> Otherwise we define a jvm.cfg file where:
> - the default VM is the "dominant" VM (server > client > minimal)
> - a missing client/server is aliased to the default VM
> - the minimal VM is only present in the jvm.cfg file if it is built
> 
> Further, as a target of opportunity we stop generating, and delete from the existing jvm.cfg files the legacy entries for "hotspot", "classic", "native" and "green"
> 
> Thanks,
> David
> 
> Generated jvm.cfg contents based on selected JVM variants:
> 
> ::::::::::::::
> client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
> 
> ::::::::::::::
> minimal+client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
> -minimal KNOWN
> 
> ::::::::::::::
> minimal
> ::::::::::::::
> -minimal KNOWN
> -server ALIASED_TO -minimal
> -client ALIASED_TO -minimal
> 
> ::::::::::::::
> minimal+server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
> -minimal KNOWN
> 
> ::::::::::::::
> server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
> 
> 
> On 15/04/2013 10:18 AM, David Holmes wrote:
>> Some background.
>> 
>> The jvm.cfg file, for which there is a per-architecture committed file
>> in the repository, controls which VM's (client, server, minimal) are
>> known, which is the default, whether there are other aliases and whether
>> ergonomic selection is used.
>> 
>> Historically things were simple:
>> - 64-bit platforms had server only
>> - 32-bit platforms had client and server
>> 
>> then we acknowledged that some platforms may be client only and we added
>> some support (originally in the old build then converted to the new
>> build) for dynamically creating a jvm.cfg for the case of building
>> client only.
>> 
>> Then the minimal VM was introduced and we potentially have three VMs to
>> handle. To address this we initially added "-minimal KNOWN" to all the
>> jvm.cfg files for platforms known to support the minimal VM - this was
>> done under JDK-7198815 (and those changes are now reversed by this
>> changeset.)
>> 
>> The problem after minimal was introduced was that the logic for
>> "building client only" didn't account for building minimal (only or
>> combined with client) and we need support for not-building-server. And
>> that is what this changeset does.
>> 
>> This only affects 32-bit builds as there is no client nor minimal VM on
>> 64-bit. The basic operation is as follows:
>> 
>> - If building client+server then we use the committed jvm.cfg (which
>> handles ergonomics if applicable), adding a "-minimal KNOWN" line if
>> minimal is also selected;
>> - Otherwise we dynamically generate a jvm.cfg for the set of VMs being
>> built, using these simple rules:
>>   - if client or server are present they are default
>>   - if client and/or server is absent then the absent VM is aliased to
>> the default VM in that config
>>   - if minimal is not selected then it is absent from the jvm.cfg (we
>> do not add any aliases for minimal**).
>> 
>> ** The alias mechanism is useful for deprecating legacy VM names, and
>> has also made testing more convenient. However I think it is a flawed
>> mechanism for testing and our internal test infrastructure is moving
>> away from arbitrarily using -client/-server when actually running
>> server/client. If you ask for the minimal VM and it is not available I
>> think you should get an error not silent use of a different VM. (Note:
>> this selection doesn't affect SE Embedded as it defines jvm.cfg files
>> using it's own rules/preferences.)
>> 
>> webrev:
>> 
>> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>> 
>> Thanks,
>> David



From tim.bell at oracle.com  Fri Apr 26 16:21:05 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 26 Apr 2013 09:21:05 -0700
Subject: RFR 8010280: jvm.cfg needs updating for non-server builds
In-Reply-To: <517A2C73.306@oracle.com>
References: <516B474B.8090404@oracle.com> <517A2C73.306@oracle.com>
Message-ID: <517AA971.1070600@oracle.com>

Hi David

Looks good to me.

Tim

On 04/26/13 12:27 AM, David Holmes wrote:
> Here is the final form of this after CCC approval.
>
> http://cr.openjdk.java.net/~dholmes/8010280/webrev.v3/
>
> For the "traditional" build of client+server we continue to use the 
> platform specific jvm.cfg files committed into the source repository. 
> Consequently no product builds (SE or Embedded) are altered by this 
> proposal. (Those files already contain "-minimal KNOWN" if applicable 
> to that platform.)
>
> Otherwise we define a jvm.cfg file where:
> - the default VM is the "dominant" VM (server > client > minimal)
> - a missing client/server is aliased to the default VM
> - the minimal VM is only present in the jvm.cfg file if it is built
>
> Further, as a target of opportunity we stop generating, and delete 
> from the existing jvm.cfg files the legacy entries for "hotspot", 
> "classic", "native" and "green"
>
> Thanks,
> David
>
> Generated jvm.cfg contents based on selected JVM variants:
>
> ::::::::::::::
> client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
>
> ::::::::::::::
> minimal+client
> ::::::::::::::
> -client KNOWN
> -server ALIASED_TO -client
> -minimal KNOWN
>
> ::::::::::::::
> minimal
> ::::::::::::::
> -minimal KNOWN
> -server ALIASED_TO -minimal
> -client ALIASED_TO -minimal
>
> ::::::::::::::
> minimal+server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
> -minimal KNOWN
>
> ::::::::::::::
> server
> ::::::::::::::
> -server KNOWN
> -client ALIASED_TO -server
>
>
> On 15/04/2013 10:18 AM, David Holmes wrote:
>> Some background.
>>
>> The jvm.cfg file, for which there is a per-architecture committed file
>> in the repository, controls which VM's (client, server, minimal) are
>> known, which is the default, whether there are other aliases and whether
>> ergonomic selection is used.
>>
>> Historically things were simple:
>> - 64-bit platforms had server only
>> - 32-bit platforms had client and server
>>
>> then we acknowledged that some platforms may be client only and we added
>> some support (originally in the old build then converted to the new
>> build) for dynamically creating a jvm.cfg for the case of building
>> client only.
>>
>> Then the minimal VM was introduced and we potentially have three VMs to
>> handle. To address this we initially added "-minimal KNOWN" to all the
>> jvm.cfg files for platforms known to support the minimal VM - this was
>> done under JDK-7198815 (and those changes are now reversed by this
>> changeset.)
>>
>> The problem after minimal was introduced was that the logic for
>> "building client only" didn't account for building minimal (only or
>> combined with client) and we need support for not-building-server. And
>> that is what this changeset does.
>>
>> This only affects 32-bit builds as there is no client nor minimal VM on
>> 64-bit. The basic operation is as follows:
>>
>> - If building client+server then we use the committed jvm.cfg (which
>> handles ergonomics if applicable), adding a "-minimal KNOWN" line if
>> minimal is also selected;
>> - Otherwise we dynamically generate a jvm.cfg for the set of VMs being
>> built, using these simple rules:
>>    - if client or server are present they are default
>>    - if client and/or server is absent then the absent VM is aliased to
>> the default VM in that config
>>    - if minimal is not selected then it is absent from the jvm.cfg (we
>> do not add any aliases for minimal**).
>>
>> ** The alias mechanism is useful for deprecating legacy VM names, and
>> has also made testing more convenient. However I think it is a flawed
>> mechanism for testing and our internal test infrastructure is moving
>> away from arbitrarily using -client/-server when actually running
>> server/client. If you ask for the minimal VM and it is not available I
>> think you should get an error not silent use of a different VM. (Note:
>> this selection doesn't affect SE Embedded as it defines jvm.cfg files
>> using it's own rules/preferences.)
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8010280/webrev/
>>
>> Thanks,
>> David



From xueming.shen at oracle.com  Fri Apr 26 17:25:13 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Apr 2013 10:25:13 -0700
Subject: RFR: 8007395 StringIndexOutofBoundsException in Match.find() when
	input String contains surrogate UTF-16 characters
Message-ID: <517AB879.2060703@oracle.com>

Hi

Please help review the proposed fix for

8007395: StringIndexOutofBoundsException in Match.find() when input String contains surrogate UTF-16 characters

http://cr.openjdk.java.net/~sherman/8007395/webrev

The root cause is the "iterative optimization" class GroupCurly fails to backtrack
correctly when matching/finding fails, if the previously matched (for each iteration)
have different size (for example a CharProperty regex constructor that can match
both bmp and non-bmp in this case). The existing implementation does have the
mechanism to deal with the "different sized" matching result for each iteration, see
ln#4451, by "recursively" entering into a new layer of match0, but it incorrectly
uses the latest matched size to backtrack all the way back to the "cmin" when
the "next" matching fails (so in this case, it backtrack by two char all the way back
to "cmin", when in fact it should back off by 2 only for the last surrogate pair, then
using 1 for the rest). Each match0() really should only backtrack to its starting iteration
count, and leave the rest to its "invoker". The fix is an easy two-line fix, to make
sure backtrack backs off correctly with the appropriate matching size.

Thanks,
-Sherman


From mandy.chung at oracle.com  Fri Apr 26 20:09:22 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 Apr 2013 13:09:22 -0700
Subject: RFR: 8007395 StringIndexOutofBoundsException in Match.find()
	when input String contains surrogate UTF-16 characters
In-Reply-To: <517AB879.2060703@oracle.com>
References: <517AB879.2060703@oracle.com>
Message-ID: <517ADEF2.60208@oracle.com>


On 4/26/2013 10:25 AM, Xueming Shen wrote:
> Hi
>
> Please help review the proposed fix for
>
> 8007395: StringIndexOutofBoundsException in Match.find() when input 
> String contains surrogate UTF-16 characters
>
> http://cr.openjdk.java.net/~sherman/8007395/webrev
>

This looks fine with me.

The new test case you add in RegExTest.java catches the exception. It 
might be better to let the exception thrown as in the existing test 
cases that will make it easier to diagnose in such error case.

Mandy


From xueming.shen at oracle.com  Fri Apr 26 20:17:15 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Apr 2013 13:17:15 -0700
Subject: RFR: 8007395 StringIndexOutofBoundsException in Match.find()
	when input String contains surrogate UTF-16 characters
In-Reply-To: <517ADEF2.60208@oracle.com>
References: <517AB879.2060703@oracle.com> <517ADEF2.60208@oracle.com>
Message-ID: <517AE0CB.20605@oracle.com>

On 04/26/2013 01:09 PM, Mandy Chung wrote:
>
> On 4/26/2013 10:25 AM, Xueming Shen wrote:
>> Hi
>>
>> Please help review the proposed fix for
>>
>> 8007395: StringIndexOutofBoundsException in Match.find() when input String contains surrogate UTF-16 characters
>>
>> http://cr.openjdk.java.net/~sherman/8007395/webrev
>>
>
> This looks fine with me.
>
> The new test case you add in RegExTest.java catches the exception. It might be better to let the exception thrown as in the existing test cases that will make it easier to diagnose in such error case.

Hi Mandy,

Thanks for the review.

The "usual convention" in RegTest is to catch the exception and increase the failureCount
so the test can keep going even some tests "unexpected" throw exception. The test will
fail with RuntimeException at the end if the failureCount>0.

-Sherman


>
> Mandy



From xueming.shen at oracle.com  Fri Apr 26 21:00:13 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Fri, 26 Apr 2013 21:00:13 +0000
Subject: hg: jdk8/tl/jdk: 8007395: StringIndexOutofBoundsException in
	Match.find() when input String contains surrogate UTF-16 characters
Message-ID: <20130426210027.5E51E4864C@hg.openjdk.java.net>

Changeset: 5144db7f0f88
Author:    sherman
Date:      2013-04-26 13:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5144db7f0f88

8007395: StringIndexOutofBoundsException in Match.find() when input String contains surrogate UTF-16 characters
Summary: updated GroupCurly.match0() to backtrack correctly
Reviewed-by: mchung

! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java



From michael.fang at oracle.com  Fri Apr 26 21:27:06 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Fri, 26 Apr 2013 21:27:06 +0000
Subject: hg: jdk8/tl/jdk: 4 new changesets
Message-ID: <20130426212816.4F2334864F@hg.openjdk.java.net>

Changeset: f5fbd8065920
Author:    mfang
Date:      2013-03-25 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5fbd8065920

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

+ src/macosx/classes/com/apple/laf/resources/aqua_de.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_es.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_fr.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_it.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_ja.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_ko.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_sv.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
+ src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties
! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties
! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java
! src/share/classes/sun/awt/resources/awt_de.properties
! src/share/classes/sun/awt/resources/awt_es.properties
! src/share/classes/sun/awt/resources/awt_pt_BR.properties
! src/share/classes/sun/awt/resources/awt_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/management/resources/agent_de.properties
! src/share/classes/sun/management/resources/agent_es.properties
! src/share/classes/sun/management/resources/agent_fr.properties
! src/share/classes/sun/management/resources/agent_it.properties
! src/share/classes/sun/management/resources/agent_ja.properties
! src/share/classes/sun/management/resources/agent_ko.properties
! src/share/classes/sun/management/resources/agent_pt_BR.properties
! src/share/classes/sun/management/resources/agent_sv.properties
! src/share/classes/sun/management/resources/agent_zh_CN.properties
! src/share/classes/sun/management/resources/agent_zh_TW.properties
! src/share/classes/sun/misc/resources/Messages_de.java
! src/share/classes/sun/misc/resources/Messages_es.java
! src/share/classes/sun/misc/resources/Messages_fr.java
! src/share/classes/sun/misc/resources/Messages_it.java
! src/share/classes/sun/misc/resources/Messages_ja.java
! src/share/classes/sun/misc/resources/Messages_ko.java
! src/share/classes/sun/misc/resources/Messages_pt_BR.java
! src/share/classes/sun/misc/resources/Messages_sv.java
! src/share/classes/sun/misc/resources/Messages_zh_CN.java
! src/share/classes/sun/misc/resources/Messages_zh_TW.java
! src/share/classes/sun/print/resources/serviceui_de.properties
! src/share/classes/sun/print/resources/serviceui_es.properties
! src/share/classes/sun/print/resources/serviceui_fr.properties
! src/share/classes/sun/print/resources/serviceui_it.properties
! src/share/classes/sun/print/resources/serviceui_ja.properties
! src/share/classes/sun/print/resources/serviceui_ko.properties
! src/share/classes/sun/print/resources/serviceui_pt_BR.properties
! src/share/classes/sun/print/resources/serviceui_sv.properties
! src/share/classes/sun/print/resources/serviceui_zh_CN.properties
! src/share/classes/sun/print/resources/serviceui_zh_TW.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties
! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties
! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties
! src/share/classes/sun/rmi/server/resources/rmid_de.properties
! src/share/classes/sun/rmi/server/resources/rmid_es.properties
! src/share/classes/sun/rmi/server/resources/rmid_fr.properties
! src/share/classes/sun/rmi/server/resources/rmid_it.properties
! src/share/classes/sun/rmi/server/resources/rmid_ja.properties
! src/share/classes/sun/rmi/server/resources/rmid_ko.properties
! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties
! src/share/classes/sun/rmi/server/resources/rmid_sv.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties
! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties
! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/share/classes/sun/security/util/AuthResources_pt_BR.java
! src/share/classes/sun/security/util/AuthResources_zh_TW.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java
! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java
! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties
! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties

Changeset: 6d8cd4f28a2f
Author:    mfang
Date:      2013-04-22 23:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d8cd4f28a2f

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/sun/security/ssl/Authenticator.java
- src/share/classes/sun/security/util/KeyLength.java
- src/share/native/java/lang/ResourceBundle.c
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java
! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: a6781797ae53
Author:    mfang
Date:      2013-04-26 09:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6781797ae53

Merge


Changeset: 890485cafb8b
Author:    mfang
Date:      2013-04-26 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/890485cafb8b

Merge




From henry.jen at oracle.com  Fri Apr 26 21:59:44 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 26 Apr 2013 14:59:44 -0700
Subject: RFR JDK-8003258: BufferedReader.lines()
Message-ID: <517AF8D0.2020902@oracle.com>

Hi,

Please review webrev at

http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/

It adds a method to BufferedReader.

public Stream lines() {}

A class java.io.UncheckedIOException is also added as a general approach
for wrapping up an IOException to be unchecked.

Cheers,
Henry


From Lance.Andersen at oracle.com  Fri Apr 26 22:13:30 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 26 Apr 2013 18:13:30 -0400
Subject: review request for 8010416: Provide a way for
	DriverManager.deregisterDriver to notify the JDBC driver that
	it has been deregistered.
In-Reply-To: <517A749C.9050605@oracle.com>
References: <3B8F7818-FD9C-4C6D-A99C-640584CE4460@oracle.com>
	<5173A4B2.6010802@oracle.com>
	<20FDEDC7-DF23-4061-BD25-467D0DACFD78@oracle.com>
	<5175378D.4010800@oracle.com>
	<8AFCEB1B-E102-4469-9F0E-FF895955C007@oracle.com>
	<5A44649D-1662-422D-948E-FDA5380FC9BC@oracle.com>
	<517A749C.9050605@oracle.com>
Message-ID: 


On Apr 26, 2013, at 8:35 AM, Alan Bateman wrote:

> On 25/04/2013 21:53, Lance Andersen - Oracle wrote:
>> http://cr.openjdk.java.net/~lancea/8010416/webrev.03/  addresses the typos that were pointed out and also fixes a couple javadoc warnings
>> 
> This looks okay to me.
> 
> One small suggestion for DriverAction and the first statement where it reads " ... when a Driver wants to be notified by DriverManager". It might be better as "... to receive notifications from the DriverManager". I suggest this because it's not specifically the Driver that is notified.

I changed it to

A JDBC driver may create a DriverAction implementation in order to receive notifications when DriverManager.deregisterDriver has been called.


I won't issue another webrev but once the ccc is final I will push the changes


thank you for the input

best
Lance
> 
> -Alan.
> 
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From henry.jen at oracle.com  Fri Apr 26 23:08:19 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 26 Apr 2013 16:08:19 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random, ThreadLocalRandom, 
	ZipFile
Message-ID: <517B08E3.6060406@oracle.com>

Hi,

Please review webrev at

http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev

The API doc in specdiff format is at

http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff

Cheers,
Henry


From mandy.chung at oracle.com  Fri Apr 26 23:09:39 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 26 Apr 2013 23:09:39 +0000
Subject: hg: jdk8/tl/jdk: 7123493: (proxy) Proxy.getProxyClass doesn't scale
	under high load
Message-ID: <20130426230952.773D448652@hg.openjdk.java.net>

Changeset: 5e7ae178b24d
Author:    plevart
Date:      2013-04-26 16:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d

7123493: (proxy) Proxy.getProxyClass doesn't scale under high load
Reviewed-by: mchung

! src/share/classes/java/lang/reflect/Proxy.java
+ src/share/classes/java/lang/reflect/WeakCache.java



From mandy.chung at oracle.com  Fri Apr 26 23:13:24 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 Apr 2013 16:13:24 -0700
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517A2467.4070300@gmail.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
	<517A2467.4070300@gmail.com>
Message-ID: <517B0A14.8040704@oracle.com>

Peter,

I have pushed the changeset:

Changeset: 5e7ae178b24d
Author:    plevart
Date:      2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d

Mandy




From mike.duigou at oracle.com  Fri Apr 26 23:24:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 26 Apr 2013 16:24:24 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517B08E3.6060406@oracle.com>
References: <517B08E3.6060406@oracle.com>
Message-ID: <025A8D28-E057-4E3A-BCF2-0A1FE6AEDF52@oracle.com>

Looks good. Two minor non-blocking nits:

ZipFile.java::

- "Create an ordered" -> "Return an ordered"

- could mention ordered in @return as well.

Mike

On Apr 26 2013, at 16:08 , Henry Jen wrote:

> Hi,
> 
> Please review webrev at
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
> 
> The API doc in specdiff format is at
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
> 
> Cheers,
> Henry
> 



From scolebourne at joda.org  Fri Apr 26 23:46:49 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 27 Apr 2013 00:46:49 +0100
Subject: RFR JDK-8003258: BufferedReader.lines()
In-Reply-To: <517AF8D0.2020902@oracle.com>
References: <517AF8D0.2020902@oracle.com>
Message-ID: 

I would suggest a new line at the end of each file.

Plus there is some very stylised formatting in terms of making things
align vertically that I wouldn't do personally, and seem to waste a
lot of screen space. Plus a single line which should be three lines.
public void close() { closed = true; }

"Since the {@code Stream} does not necessary consume all lines"
should be
"Since the {@code Stream} does not necessarily consume all lines"

I did a double take when I saw:
 try {
  return nextLine;
 } finally {
  nextLine = null;
 }
Certainly an "interesting" approach to returning and clearing.

Stephen


On 26 April 2013 22:59, Henry Jen  wrote:
> Hi,
>
> Please review webrev at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
>
> It adds a method to BufferedReader.
>
> public Stream lines() {}
>
> A class java.io.UncheckedIOException is also added as a general approach
> for wrapping up an IOException to be unchecked.
>
> Cheers,
> Henry


From mike.duigou at oracle.com  Sat Apr 27 00:12:02 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 26 Apr 2013 17:12:02 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
Message-ID: 

Hello all;

A very small change to review. 

http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/

The change removes some erroneous documentation from the Deque push() method.

Mike


From mandy.chung at oracle.com  Sat Apr 27 01:05:34 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 Apr 2013 18:05:34 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
Message-ID: 

Looks good to me.

Mandy

On Apr 26, 2013, at 5:12 PM, Mike Duigou  wrote:

> Hello all;
> 
> A very small change to review. 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
> 
> The change removes some erroneous documentation from the Deque push() method.
> 
> Mike


From david.holmes at oracle.com  Sat Apr 27 01:50:07 2013
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 27 Apr 2013 11:50:07 +1000
Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining
In-Reply-To: <1E5A39D8-BA73-4ADC-AAB1-0DBD02AD5AB9@oracle.com>
References: <5171DA7F.1070105@oracle.com> <51758484.7030600@oracle.com>
	<5176DE7C.8060404@oracle.com> <5177DBC7.8000605@oracle.com>
	<5178155C.6050600@oracle.com> <51781D04.7000907@univ-mlv.fr>
	
	<517A6DE0.4080602@oracle.com>
	
	<517A7BCC.9030209@univ-mlv.fr> <517A911D.8040800@gmail.com>
	<1E5A39D8-BA73-4ADC-AAB1-0DBD02AD5AB9@oracle.com>
Message-ID: <517B2ECF.7020404@oracle.com>

On 27/04/2013 1:46 AM, Paul Sandoz wrote:
>
> On Apr 26, 2013, at 4:37 PM, Peter Levart  wrote:
>>
>> Another "interesting" usage:
>>
>> Iterator i = ...;
>>
>> i.forEachRemaining(e -> {
>>    ...
>>    if (...) {
>>       i.forEachRemaining(dummy -> {}); // drain it
>>    }
>>    ...
>> });
>>
>> It seems that mixing external and internal iteration in the same object is like a box of chocolates. For internal iteration, Iterable.forEach is more suitable than Iterator.forEachRemaining unless the later is specified to have the common state for both external and internal iteration, which means that internal can not be more effective than external.
>>
>
> Similar observations can apply to Spliterator as well. IIRC many spliterator.forEachRemaining implementations set up state to be fully traversed before looping. However, it is not possible in all cases.
>
> I think we may have to document that a consumer must not interfere with the current traversal otherwise behaviour is undefined.

Maybe my thinking is not creative enough but to me a method on Iterator 
called forEachRemaining(f) has very clear semantics:

while (it.hasNext()) {
   f.accept(next());
}

at completion the Iterator is "consumed" there are no elements left.

If f.accept messes with the iterator then it is probably best left 
unspecified as to what might, or might not happen. Then again perhaps 
the interaction of all Iterator methods should be fully spelt out - and 
if we think that is a problem maybe adding methods to Iterator is not 
such a great idea.

But I think this needs to go back to the expert list, if not already there.

David

> Paul.
>


From weijun.wang at oracle.com  Sat Apr 27 03:14:58 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 27 Apr 2013 11:14:58 +0800
Subject: new File(parent, child) when child is absolute
Message-ID: <517B42B2.8070607@oracle.com>

I thought that in this case parent is just ignored and it's still the 
child itself. Turns out this is not true, and

    new File("/tmp", "/etc/passwd") is /tmp/etc/passwd

Is this really useful in any way?

Thanks
Max


From Alan.Bateman at oracle.com  Sat Apr 27 07:34:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Apr 2013 08:34:17 +0100
Subject: new File(parent, child) when child is absolute
In-Reply-To: <517B42B2.8070607@oracle.com>
References: <517B42B2.8070607@oracle.com>
Message-ID: <517B7F79.6060104@oracle.com>

On 27/04/2013 04:14, Weijun Wang wrote:
> I thought that in this case parent is just ignored and it's still the 
> child itself. Turns out this is not true, and
>
>    new File("/tmp", "/etc/passwd") is /tmp/etc/passwd
>
> Is this really useful in any way?
I agree this isn't always obvious but this is how this method was 
originally specified (JDK1.1, maybe JDK1.0). I've no doubt that 
attempting to change it now would cause breakage, particularly Windows 
where a file path such as "/etc/passwd" is a relative path. Can you use 
java.nio.file.Path for what you are doing? It has resolve methods that 
do the right thing.

-Alan.


From Alan.Bateman at oracle.com  Sat Apr 27 07:36:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Apr 2013 08:36:01 +0100
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
Message-ID: <517B7FE1.3060401@oracle.com>

On 27/04/2013 01:12, Mike Duigou wrote:
> Hello all;
>
> A very small change to review.
>
> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
>
> The change removes some erroneous documentation from the Deque push() method.
>
> Mike
Looks fine to me too.

-Alan


From Alan.Bateman at oracle.com  Sat Apr 27 07:37:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Apr 2013 08:37:34 +0100
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517B0A14.8040704@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
	<517A2467.4070300@gmail.com> <517B0A14.8040704@oracle.com>
Message-ID: <517B803E.5050100@oracle.com>

On 27/04/2013 00:13, Mandy Chung wrote:
> Peter,
>
> I have pushed the changeset:
>
> Changeset: 5e7ae178b24d
> Author:    plevart
> Date:      2013-04-26 16:09 -0700
> URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
>
> Mandy
This is great work, thank you!

-Alan.



From weijun.wang at oracle.com  Sat Apr 27 07:56:44 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 27 Apr 2013 15:56:44 +0800
Subject: new File(parent, child) when child is absolute
In-Reply-To: <517B7F79.6060104@oracle.com>
References: <517B42B2.8070607@oracle.com> <517B7F79.6060104@oracle.com>
Message-ID: <517B84BC.5040800@oracle.com>



On 4/27/13 3:34 PM, Alan Bateman wrote:
> On 27/04/2013 04:14, Weijun Wang wrote:
>> I thought that in this case parent is just ignored and it's still the
>> child itself. Turns out this is not true, and
>>
>>    new File("/tmp", "/etc/passwd") is /tmp/etc/passwd
>>
>> Is this really useful in any way?
> I agree this isn't always obvious but this is how this method was
> originally specified (JDK1.1, maybe JDK1.0). I've no doubt that
> attempting to change it now would cause breakage, particularly Windows
> where a file path such as "/etc/passwd" is a relative path. Can you use
> java.nio.file.Path for what you are doing? It has resolve methods that
> do the right thing.

Great. I should have thought of it. Path/Files/Paths are precious.

Thanks
Max

>
> -Alan.


From Alan.Bateman at oracle.com  Sat Apr 27 08:15:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Apr 2013 09:15:59 +0100
Subject: RFR JDK-8003258: BufferedReader.lines()
In-Reply-To: <517AF8D0.2020902@oracle.com>
References: <517AF8D0.2020902@oracle.com>
Message-ID: <517B893F.8030401@oracle.com>

On 26/04/2013 22:59, Henry Jen wrote:
> Hi,
>
> Please review webrev at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
>
> It adds a method to BufferedReader.
>
> public Stream  lines() {}
>
> A class java.io.UncheckedIOException is also added as a general approach
> for wrapping up an IOException to be unchecked.
>
> Cheers,
> Henry
>
I'm not so sure about setting expectations that you can readily mix 
stream usage with the other methods that BufferedReader defines. This 
puts a strict requirement on the implementation that it must be based on 
readLines and that it can never do any read ahead.

The javadoc should probably specify that lines() returns a Stream even 
if the reader is closed.

Otherwise just minor comments:

In UncheckedIOException then the @since should be 1.8. The @see probably 
isn't needed here because there is already a link to IOException in the 
description (but it doesn't matter).

I agree with Stephen's comment on finally { nextLine = null; }. It might 
be more obvious with a simple:

   String result = nextLine;
   nextLine = null;
   return result;

The test has the Classpath exception, I assume you'll put the pure GPL 
header on this before you push.

-Alan.





From forax at univ-mlv.fr  Sat Apr 27 08:35:16 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 27 Apr 2013 10:35:16 +0200
Subject: RFR JDK-8003258: BufferedReader.lines()
In-Reply-To: 
References: <517AF8D0.2020902@oracle.com>
	
Message-ID: <517B8DC4.5040103@univ-mlv.fr>

On 04/27/2013 01:46 AM, Stephen Colebourne wrote:
> I would suggest a new line at the end of each file.
>
> Plus there is some very stylised formatting in terms of making things
> align vertically that I wouldn't do personally, and seem to waste a
> lot of screen space. Plus a single line which should be three lines.
> public void close() { closed = true; }
>
> "Since the {@code Stream} does not necessary consume all lines"
> should be
> "Since the {@code Stream} does not necessarily consume all lines"
>
> I did a double take when I saw:
>   try {
>    return nextLine;
>   } finally {
>    nextLine = null;
>   }
> Certainly an "interesting" approach to returning and clearing.
>
> Stephen

It's a known trick,
but javac is not smart enough to *not* generate an exception table,
so the resulting bytecode is equivalent to:

   String tmp;
   try {
     tmp = nextLine;
   } catch(Throwable t) {
     nextLine = null;
     throw t;
   }
   nextLine = null;
   return tmp;

not something beautiful.

R?mi


>
>
> On 26 April 2013 22:59, Henry Jen  wrote:
>> Hi,
>>
>> Please review webrev at
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
>>
>> It adds a method to BufferedReader.
>>
>> public Stream lines() {}
>>
>> A class java.io.UncheckedIOException is also added as a general approach
>> for wrapping up an IOException to be unchecked.
>>
>> Cheers,
>> Henry



From weijun.wang at oracle.com  Sat Apr 27 10:26:04 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Sat, 27 Apr 2013 10:26:04 +0000
Subject: hg: jdk8/tl/jdk: 8005523: Unbound krb5 for TLS
Message-ID: <20130427102639.072794865D@hg.openjdk.java.net>

Changeset: 964b95a59656
Author:    weijun
Date:      2013-04-27 18:25 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/964b95a59656

8005523: Unbound krb5 for TLS
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/Krb5Proxy.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
! test/sun/security/krb5/auto/SSL.java



From Alan.Bateman at oracle.com  Sat Apr 27 15:01:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Apr 2013 16:01:34 +0100
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517B08E3.6060406@oracle.com>
References: <517B08E3.6060406@oracle.com>
Message-ID: <517BE84E.3040600@oracle.com>

On 27/04/2013 00:08, Henry Jen wrote:
> Hi,
>
> Please review webrev at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>
> The API doc in specdiff format is at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>
> Cheers,
> Henry
In the ZipFile spec it reads "Entries appear in the {@code Stream} in 
the order they appear in the ZIP file" but I think the order of the 
entries in the central directory and this may not be the same as the 
order of the entries in the archive.

I'm still a newbie on the Spliterator characteristics so bear with me. 
In BitSet.stream then the spliterator is created as SORTED, is that 
right? I'm also wondering about the characteristics when creating the 
ZipFile and JarFile streams, should it include DISTINCT?

The tests looks good. One suggestion for StreamZipEntriesTest is to 
include a test to check that ISE is thrown when stream is invoked on a 
closed ZipFile.

-Alan.




From Alan.Bateman at oracle.com  Sun Apr 28 11:09:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Apr 2013 12:09:36 +0100
Subject: 8013413: javadoc warnings
Message-ID: <517D0370.2000903@oracle.com>


I need a reviewer to fix two trivial javadoc warnings that sneaked in 
recently.

-Alan.

diff --git a/src/share/classes/java/nio/file/attribute/FileTime.java 
b/src/share/classes/java/nio/file/attribute/FileTime.java
--- a/src/share/classes/java/nio/file/attribute/FileTime.java
+++ b/src/share/classes/java/nio/file/attribute/FileTime.java
@@ -219,8 +219,8 @@
       *
       * 
         {@code FileTime} can store points on the time-line further 
in the
       * future and further in the past than {@code Instant}. Conversion
-     * from such further time points saturates to {@link Instant.MIN} if
-     * earlier than {@code Instant.MIN} or {@link Instant.MAX} if later
+     * from such further time points saturates to {@link Instant#MIN} if
+     * earlier than {@code Instant.MIN} or {@link Instant#MAX} if later
       * than {@code Instant.MAX}.
       *
       * @return  an instant representing the same point on the time-line as
diff --git a/src/share/classes/java/util/Spliterator.java 
b/src/share/classes/java/util/Spliterator.java
--- a/src/share/classes/java/util/Spliterator.java
+++ b/src/share/classes/java/util/Spliterator.java
@@ -438,7 +438,7 @@
      /**
       * If this Spliterator's source is {@link #SORTED} by a {@link 
Comparator},
       * returns that {@code Comparator}. If the source is {@code SORTED} in
-     * {@linkplain Comparable natural order, returns {@code null}.  
Otherwise,
+     * {@linkplain Comparable natural order}, returns {@code null}.  
Otherwise,
       * if the source is not {@code SORTED}, throws {@link 
IllegalStateException}.
       *
       * @implSpec


From Lance.Andersen at oracle.com  Sun Apr 28 11:20:39 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Sun, 28 Apr 2013 07:20:39 -0400
Subject: 8013413: javadoc warnings
In-Reply-To: <517D0370.2000903@oracle.com>
References: <517D0370.2000903@oracle.com>
Message-ID: <92A893CF-B586-438B-93D7-7FDEA0C263D4@oracle.com>

Looks fine

--

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com

Sent from my iPhone

On Apr 28, 2013, at 7:09 AM, Alan Bateman  wrote:

> 
> I need a reviewer to fix two trivial javadoc warnings that sneaked in recently.
> 
> -Alan.
> 
> diff --git a/src/share/classes/java/nio/file/attribute/FileTime.java b/src/share/classes/java/nio/file/attribute/FileTime.java
> --- a/src/share/classes/java/nio/file/attribute/FileTime.java
> +++ b/src/share/classes/java/nio/file/attribute/FileTime.java
> @@ -219,8 +219,8 @@
>      *
>      * 
         {@code FileTime} can store points on the time-line further in the
>      * future and further in the past than {@code Instant}. Conversion
> -     * from such further time points saturates to {@link Instant.MIN} if
> -     * earlier than {@code Instant.MIN} or {@link Instant.MAX} if later
> +     * from such further time points saturates to {@link Instant#MIN} if
> +     * earlier than {@code Instant.MIN} or {@link Instant#MAX} if later
>      * than {@code Instant.MAX}.
>      *
>      * @return  an instant representing the same point on the time-line as
> diff --git a/src/share/classes/java/util/Spliterator.java b/src/share/classes/java/util/Spliterator.java
> --- a/src/share/classes/java/util/Spliterator.java
> +++ b/src/share/classes/java/util/Spliterator.java
> @@ -438,7 +438,7 @@
>     /**
>      * If this Spliterator's source is {@link #SORTED} by a {@link Comparator},
>      * returns that {@code Comparator}. If the source is {@code SORTED} in
> -     * {@linkplain Comparable natural order, returns {@code null}.  Otherwise,
> +     * {@linkplain Comparable natural order}, returns {@code null}.  Otherwise,
>      * if the source is not {@code SORTED}, throws {@link IllegalStateException}.
>      *
>      * @implSpec


From chris.hegarty at oracle.com  Sun Apr 28 12:33:21 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 28 Apr 2013 13:33:21 +0100
Subject: 8013413: javadoc warnings
In-Reply-To: <92A893CF-B586-438B-93D7-7FDEA0C263D4@oracle.com>
References: <517D0370.2000903@oracle.com>
	<92A893CF-B586-438B-93D7-7FDEA0C263D4@oracle.com>
Message-ID: 


On 28 Apr 2013, at 12:20, Lance Andersen  wrote:

> Looks fine

+1 best to quash these whenever they're noticed.

-Chris.

> 
> --
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> Sent from my iPhone
> 
> On Apr 28, 2013, at 7:09 AM, Alan Bateman  wrote:
> 
>> 
>> I need a reviewer to fix two trivial javadoc warnings that sneaked in recently.
>> 
>> -Alan.
>> 
>> diff --git a/src/share/classes/java/nio/file/attribute/FileTime.java b/src/share/classes/java/nio/file/attribute/FileTime.java
>> --- a/src/share/classes/java/nio/file/attribute/FileTime.java
>> +++ b/src/share/classes/java/nio/file/attribute/FileTime.java
>> @@ -219,8 +219,8 @@
>>     *
>>     * 
         {@code FileTime} can store points on the time-line further in the
>>     * future and further in the past than {@code Instant}. Conversion
>> -     * from such further time points saturates to {@link Instant.MIN} if
>> -     * earlier than {@code Instant.MIN} or {@link Instant.MAX} if later
>> +     * from such further time points saturates to {@link Instant#MIN} if
>> +     * earlier than {@code Instant.MIN} or {@link Instant#MAX} if later
>>     * than {@code Instant.MAX}.
>>     *
>>     * @return  an instant representing the same point on the time-line as
>> diff --git a/src/share/classes/java/util/Spliterator.java b/src/share/classes/java/util/Spliterator.java
>> --- a/src/share/classes/java/util/Spliterator.java
>> +++ b/src/share/classes/java/util/Spliterator.java
>> @@ -438,7 +438,7 @@
>>    /**
>>     * If this Spliterator's source is {@link #SORTED} by a {@link Comparator},
>>     * returns that {@code Comparator}. If the source is {@code SORTED} in
>> -     * {@linkplain Comparable natural order, returns {@code null}.  Otherwise,
>> +     * {@linkplain Comparable natural order}, returns {@code null}.  Otherwise,
>>     * if the source is not {@code SORTED}, throws {@link IllegalStateException}.
>>     *
>>     * @implSpec


From alan.bateman at oracle.com  Sun Apr 28 20:09:39 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 28 Apr 2013 20:09:39 +0000
Subject: hg: jdk8/tl/jdk: 8013413: javadoc warnings
Message-ID: <20130428200952.6598948672@hg.openjdk.java.net>

Changeset: c5d7bdee8c64
Author:    alanb
Date:      2013-04-28 21:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5d7bdee8c64

8013413: javadoc warnings
Reviewed-by: lancea, chegar

! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/util/Spliterator.java



From david.holmes at oracle.com  Sun Apr 28 23:29:14 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Sun, 28 Apr 2013 23:29:14 +0000
Subject: hg: jdk8/tl: 8011152: Precision problems on sflt builds
Message-ID: <20130428232914.E00C348673@hg.openjdk.java.net>

Changeset: 10775618db00
Author:    aharlap
Date:      2013-04-26 15:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/10775618db00

8011152: Precision problems on sflt builds
Summary: Need to add global flag to the linker
Reviewed-by: tbell, dholmes

! common/makefiles/NativeCompilation.gmk



From tbuktu at hotmail.com  Sun Apr 28 23:31:39 2013
From: tbuktu at hotmail.com (Tim Buktu)
Date: Mon, 29 Apr 2013 01:31:39 +0200
Subject: Review Request: BigInteger patch for efficient multiplication
	and division (#4837946)
In-Reply-To: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com>
References: 
	<1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com>
Message-ID: 

Hi Brian,

thanks for the update.
> This patch differs from the code in https://github.com/tbuktu/bigint.git. Notably I observed that Schonhage-Strassen multiplication and Barrett division are not present. Is this intentional and if so why would that be? Are the implementations of these additional algorithms not quite ready for contribution or is there a licensing issue perhaps?
Sch?nhage-Strassen and Barrett have been tested by me. I believe Alan
Eliasen also ran tests. There are no known bugs and there shouldn't be
any licensing issues because I wrote the code myself.

The reason why I didn't include these two algorithms in the patch I
posted here is because I wasn't sure if it was too much code to review.
If that is not a problem and you'd rather use the full implementation,
the four patched files are at

https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/BigInteger.java
https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/MutableBigInteger.java
https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/BigDecimal.java
https://raw.github.com/tbuktu/bigint/master/src/test/java/BigIntegerTest.java

Let me know if there are any more questions.
Thanks,

Tim


From Lance.Andersen at oracle.com  Sun Apr 28 23:36:08 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Sun, 28 Apr 2013 19:36:08 -0400
Subject: RFR: [corba] 4504275, 8011986 - two issues with generated code
In-Reply-To: <5167E669.2090505@oracle.com>
References: <5167E669.2090505@oracle.com>
Message-ID: <816C0697-B13A-4D84-B6D2-4DB376C8F422@oracle.com>

This is good to go.  Also reviewed by Russ Gold from the Corba team

Best
Lance
On Apr 12, 2013, at 6:48 AM, Dmeetry Degrave wrote:

> 
> Hi all,
> 
> I'm looking for a review for two ancient issues in idlj.
> 
> First is an issue with uncompilable java code generated for unions with boolean discriminator.
> 
> 4504275: CORBA boolean type unions do not generate compilable code from idlj
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504275
> fix: http://cr.openjdk.java.net/~dmeetry/4504275/webrev.0/
> 
> Second (is not available on bugs.sun.com atm) is an issue with generated read/write union helper methods that throw org.omg.CORBA.BAD_OPERATION in cases when boolean discriminator's value isn't matched, which is wrong.
> 
> 8011986: [corba] idlj generates read/write union helper methods that throw wrong exception in some cases
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011986
> fix: http://cr.openjdk.java.net/~dmeetry/8011986/webrev.0/
> 
> Both fixes are intended for jdk7 and 8.
> 
> thanks,
> dmeetry

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From paul.sandoz at oracle.com  Mon Apr 29 08:53:45 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Apr 2013 10:53:45 +0200
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517BE84E.3040600@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
Message-ID: 


On Apr 27, 2013, at 5:01 PM, Alan Bateman  wrote:

> On 27/04/2013 00:08, Henry Jen wrote:
>> Hi,
>> 
>> Please review webrev at
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>> 
>> The API doc in specdiff format is at
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>> 
>> Cheers,
>> Henry
> In the ZipFile spec it reads "Entries appear in the {@code Stream} in the order they appear in the ZIP file" but I think the order of the entries in the central directory and this may not be the same as the order of the entries in the archive.
> 
> I'm still a newbie on the Spliterator characteristics so bear with me. In BitSet.stream then the spliterator is created as SORTED, is that right?

Yes, since a stream of increasing int values, corresponding to indexes of set bits, is created (the current index of a set bit is used to obtain the index of the next set bit) i.e. it is doing:

  for (int i = bs.nextSetBit(0); i >= 0; i = bs.nextSetBit(i+1)) { }

(Note that primitive streams created from ranges are also sorted/distinct, although we are still working out the edge cases for doubles).

The stream is not bound to the bit set until the terminal operation commences. If the bit set is interfered with during executing of the terminal operation (e.g. function values could update it) then results are undefined. I think we should say:

     * 
        The bit set must remain constant during the execution of the terminal
     * stream operation.  Otherwise, the result of the terminal stream operation is 
     * undefined

(This implementation does not fail-fast with a CME.)


> I'm also wondering about the characteristics when creating the ZipFile and JarFile streams, should it include DISTINCT?
> 

Yes, i think so (like with the file-based streams IIRC), plus it should be IMMUTABLE and NONNULL.

It is also very tempting to write an inner class that implements Iterator and Enumeration over zip entries, so the same class can be used by entries() and streams().

Paul.

> The tests looks good. One suggestion for StreamZipEntriesTest is to include a test to check that ISE is thrown when stream is invoked on a closed ZipFile.
> 
> -Alan.
> 
> 



From chris.hegarty at oracle.com  Mon Apr 29 09:23:14 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Apr 2013 10:23:14 +0100
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
	
Message-ID: <517E3C02.6010409@oracle.com>

Looks fine to me too.

-Chris.

On 27/04/2013 02:05, Mandy Chung wrote:
> Looks good to me.
>
> Mandy
>
> On Apr 26, 2013, at 5:12 PM, Mike Duigou  wrote:
>
>> Hello all;
>>
>> A very small change to review.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
>>
>> The change removes some erroneous documentation from the Deque push() method.
>>
>> Mike


From paul.sandoz at oracle.com  Mon Apr 29 09:29:16 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Apr 2013 11:29:16 +0200
Subject: RFR JDK-8003258: BufferedReader.lines()
In-Reply-To: <517B893F.8030401@oracle.com>
References: <517AF8D0.2020902@oracle.com> <517B893F.8030401@oracle.com>
Message-ID: 


On Apr 27, 2013, at 10:15 AM, Alan Bateman  wrote:

> On 26/04/2013 22:59, Henry Jen wrote:
>> Hi,
>> 
>> Please review webrev at
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8003258.1/webrev/
>> 
>> It adds a method to BufferedReader.
>> 
>> public Stream  lines() {}
>> 
>> A class java.io.UncheckedIOException is also added as a general approach
>> for wrapping up an IOException to be unchecked.
>> 
>> Cheers,
>> Henry
>> 
> I'm not so sure about setting expectations that you can readily mix stream usage with the other methods that BufferedReader defines. This puts a strict requirement on the implementation that it must be based on readLines and that it can never do any read ahead.
> 

Even if the implementation uses readLines, if the stream is evaluated in parallel more lines may be read than absolutely necessary so we cannot guarantee that the following will consume at most one element:

  br.lines().parallel().findAny();
  br.lines().parallel().findFirst();
  br.lines().parallel().limit(1).collect(toList());

So we have to say something like:

    * 
        The reader must not be operated on during the execution of the terminal
    * stream operation.  Otherwise, the result of the terminal stream operation is 
    * undefined
    *
    * 
        After execution of the terminal stream operation there are no guarantees that
    * the reader will be at a specific position from which to read the next character or line.

Paul.



> The javadoc should probably specify that lines() returns a Stream even if the reader is closed.
> 
> Otherwise just minor comments:
> 
> In UncheckedIOException then the @since should be 1.8. The @see probably isn't needed here because there is already a link to IOException in the description (but it doesn't matter).
> 
> I agree with Stephen's comment on finally { nextLine = null; }. It might be more obvious with a simple:
> 
>  String result = nextLine;
>  nextLine = null;
>  return result;
> 
> The test has the Classpath exception, I assume you'll put the pure GPL header on this before you push.
> 
> -Alan.
> 
> 
> 



From alan.bateman at oracle.com  Mon Apr 29 09:30:22 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 29 Apr 2013 09:30:22 +0000
Subject: hg: jdk8/tl/jdk: 8013415: Changes for JDK-8005523 requires updates to
	refs.allowed
Message-ID: <20130429093047.51F9648680@hg.openjdk.java.net>

Changeset: 94b05be10eec
Author:    alanb
Date:      2013-04-29 10:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94b05be10eec

8013415: Changes for JDK-8005523 requires updates to refs.allowed
Reviewed-by: chegar

! make/tools/src/build/tools/deps/refs.allowed



From Alan.Bateman at oracle.com  Mon Apr 29 10:56:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Apr 2013 11:56:31 +0100
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: 
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	
Message-ID: <517E51DF.408@oracle.com>

On 29/04/2013 09:53, Paul Sandoz wrote:
>
> Yes, since a stream of increasing int values, corresponding to indexes of set bits, is created (the current index of a set bit is used to obtain the index of the next set bit) i.e. it is doing:
>
>    for (int i = bs.nextSetBit(0); i>= 0; i = bs.nextSetBit(i+1)) { }
>
> (Note that primitive streams created from ranges are also sorted/distinct, although we are still working out the edge cases for doubles).
Got it, I mis-read it and now see that the indexes are returned in order.

-Alan.


From aleksey.shipilev at oracle.com  Mon Apr 29 11:26:15 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 29 Apr 2013 15:26:15 +0400
Subject: Proxy.isProxyClass scalability
In-Reply-To: <517B803E.5050100@oracle.com>
References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com>
	<5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com>
	<510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com>
	<5106A397.1060203@gmail.com> <51655C8C.8050809@gmail.com>
	<51687D24.9070802@oracle.com> <5169D55B.8040709@gmail.com>
	<516C860E.2050205@oracle.com> <516D5DB3.3020102@gmail.com>
	<516E33B9.50007@oracle.com> <516EAF4A.6040605@gmail.com>
	<5170D728.3060103@oracle.com> <51715667.3010103@gmail.com>
	<51724434.10107@gmail.com> <51771C88.6060902@oracle.com>
	<517782A8.1010602@gmail.com> <51788912.5070106@oracle.com>
	<51794E6A.3000100@gmail.com> <5179A5F5.4070503@oracle.com>
	<517A2467.4070300@gmail.com> <517B0A14.8040704@oracle.com>
	<517B803E.5050100@oracle.com>
Message-ID: <517E58D7.5030705@oracle.com>

On 04/27/2013 11:37 AM, Alan Bateman wrote:
> On 27/04/2013 00:13, Mandy Chung wrote:
>> Peter,
>>
>> I have pushed the changeset:
>>
>> Changeset: 5e7ae178b24d
>> Author:    plevart
>> Date:      2013-04-26 16:09 -0700
>> URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
>>
>> Mandy
> This is great work, thank you!

+1.

-Aleksey.

P.S. Dear Santa, please get more people like Peter in this project, please?


From david.holmes at oracle.com  Mon Apr 29 11:43:45 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Mon, 29 Apr 2013 11:43:45 +0000
Subject: hg: jdk8/tl/jdk: 8010280: jvm.cfg needs updating for non-server builds
Message-ID: <20130429114409.9E31248685@hg.openjdk.java.net>

Changeset: 138f767b8eff
Author:    dholmes
Date:      2013-04-29 07:40 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/138f767b8eff

8010280: jvm.cfg needs updating for non-server builds
Summary: Generate jvm.cfg based on chosen VMs for non-"standard" builds and remove legacy entries from committed jvm.cfg files
Reviewed-by: mduigou, tbell

! makefiles/CopyFiles.gmk
! src/macosx/bin/x86_64/jvm.cfg
! src/solaris/bin/amd64/jvm.cfg
! src/solaris/bin/arm/jvm.cfg
! src/solaris/bin/i586/jvm.cfg
! src/solaris/bin/ia64/jvm.cfg
! src/solaris/bin/ppc/jvm.cfg
! src/solaris/bin/sparc/jvm.cfg
! src/solaris/bin/sparcv9/jvm.cfg
! src/solaris/bin/zero/jvm.cfg
! src/windows/bin/amd64/jvm.cfg
! src/windows/bin/i586/jvm.cfg
! src/windows/bin/ia64/jvm.cfg



From paul.sandoz at oracle.com  Mon Apr 29 12:25:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 29 Apr 2013 14:25:05 +0200
Subject: RFR: 8012646: Pattern.splitAsStream
Message-ID: <523D87F8-BE7E-43A9-806E-CF1798A7A0C1@oracle.com>

Hi,

Please review:

  http://cr.openjdk.java.net/~psandoz/lambda/jdk-8012646/webrev/

The stream-based test currently resides in the lambda repo and will flow into tl with other stream-based tests:

  http://hg.openjdk.java.net/lambda/lambda/jdk/file/d5456784b348/test-ng/tests/org/openjdk/tests/java/util/regex/PatternTest.java

Paul.

From dmitry.degrave at oracle.com  Mon Apr 29 12:45:47 2013
From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com)
Date: Mon, 29 Apr 2013 12:45:47 +0000
Subject: hg: jdk8/tl/corba: 4504275: CORBA boolean type unions do not generate
	compilable code from idlj
Message-ID: <20130429124549.321BF48689@hg.openjdk.java.net>

Changeset: 8f0a461776a9
Author:    dmeetry
Date:      2013-04-29 16:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/8f0a461776a9

4504275: CORBA boolean type unions do not generate compilable code from idlj
Summary: JLS doesn't allow boolean type in switch statement, hence substituted by if statement.
Reviewed-by: lancea

! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/UnionGen.java



From dmitry.degrave at oracle.com  Mon Apr 29 12:52:13 2013
From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com)
Date: Mon, 29 Apr 2013 12:52:13 +0000
Subject: hg: jdk8/tl/corba: 8011986: [corba] idlj generates read/write union
	helper methods that throw wrong exception in some cases
Message-ID: <20130429125214.46BCE4868A@hg.openjdk.java.net>

Changeset: 846aaf02e516
Author:    dmeetry
Date:      2013-04-29 16:51 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/846aaf02e516

8011986: [corba] idlj generates read/write union helper methods that throw wrong exception in some cases
Reviewed-by: lancea

! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/UnionGen.java



From aleksej.efimov at oracle.com  Mon Apr 29 13:45:38 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 29 Apr 2013 17:45:38 +0400
Subject: RFR 8009581: Xpathexception does not honor initcause()
In-Reply-To: <517821CB.70608@oracle.com>
References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com>
Message-ID: <517E7982.8060803@oracle.com>

Alan,
The XPathException class doesn't have any fields only methods (it had a 
'cause' method, but it was deleted in suggested fix). And, as I can see, 
there is no need to control what information is saved or to append 
additional information to the serialization stream.
So, I think the readObject/writeObject is not required here.

-Aleksej

On 04/24/2013 10:17 PM, Alan Bateman wrote:
> On 24/04/2013 14:53, Aleksej Efimov wrote:
>> Hi all,
>>
>> Can I have a reviews for the following change:
>> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ 
>> 
>>
>> Summary:
>> There is an erroneous behavior in 'initCause' method of 
>> javax.xml.xpath.XPathException class.
>> Lets look at the following situation:
>> XPathException is created with 'XPathException(String )' constructor 
>> and then the cause is initialized with 'initCause' method. Such 
>> initialization sequence of actions isn't restricted by XPathException 
>> [1] and Throwable [2] docs.
>> After that a cause is retrieved by 'getCause()' method: this call 
>> returns incorrect cause = 'null'. It should return the same cause as 
>> was used in 'initCause'.  And this is the erroneous behavior.
>>
>> Suggested fix (with regression test) is applicable both for JDK 8 and 7.
> Exceptions are serializable so I think this may require further 
> investigation to see if a readObject/writeObject is required.
>
> -Alan.



From Alan.Bateman at oracle.com  Mon Apr 29 13:56:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Apr 2013 14:56:42 +0100
Subject: RFR 8009581: Xpathexception does not honor initcause()
In-Reply-To: <517E7982.8060803@oracle.com>
References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com>
	<517E7982.8060803@oracle.com>
Message-ID: <517E7C1A.6090303@oracle.com>

On 29/04/2013 14:45, Aleksej Efimov wrote:
> Alan,
> The XPathException class doesn't have any fields only methods (it had 
> a 'cause' method, but it was deleted in suggested fix). And, as I can 
> see, there is no need to control what information is saved or to 
> append additional information to the serialization stream.
> So, I think the readObject/writeObject is not required here.
>
> -Aleksej
The serialized form then it includes XPathException's "cause" field. So 
if you remove it then I think it is technically an API change.

-Alan.


From henry.jen at oracle.com  Mon Apr 29 16:47:57 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Apr 2013 09:47:57 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: 
References: <51799135.5020801@oracle.com>
	
Message-ID: <517EA43D.3000504@oracle.com>

Hi Martin,

Thanks for the comment, I looked at this when I first saw a similar
comment in the code, and didn't change it because the charCount() is a
small operation. The code is just,

> codePoint >= MIN_SUPPLEMENTARY_CODE_POINT ? 2 : 1;

Another reason I didn't change it is to avoid repeated code.

I suspect there is much to gain. We can follow up this in a separate
issue and get this version in first before feature freeze?

Cheers,
Henry

On 04/25/2013 04:14 PM, Martin Buchholz wrote:
> I think core library code should write the slightly lower-level code for
> performance
> 
> +                int cp = Character.codePointAt(CharSequence.this, cur);
> +                cur += Character.charCount(cp);
> 
> int length = length();
> if (cur == length) throw NSEE;
> char c1 = charAt(cur++), c2;
> if (!isHighSurrogate(c1) || cur == length || !isLowSurrogate(c2 =
> charAt(cur))
>   return c1;
> cur++;
> return toCodePoint(c1, c2);
>   
> 
> 
> 
> On Thu, Apr 25, 2013 at 1:25 PM, Henry Jen  > wrote:
> 
>     Hi,
> 
>     Please review two default methods add to CharSequence returns IntStream
>     of char value or code point value.
> 
>     http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
> 
>     The synchronization test is relieved so lambda and other synthetic
>     method is not tested. If synchronization is needed for those two default
>     methods, subclass should override the methods.
> 
>     With charAt and codePointAt properly synchronized, the default
>     implementation is sufficient. However as noted, if the sequence is
>     mutated while the stream is being read, the result is undefined.
> 
>     Cheers,
>     Henry
> 
> 



From henry.jen at oracle.com  Mon Apr 29 16:51:47 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Apr 2013 09:51:47 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: <517A7F5D.8050206@oracle.com>
References: <51799135.5020801@oracle.com> <517A7F5D.8050206@oracle.com>
Message-ID: <517EA523.1020509@oracle.com>

On 04/26/2013 06:21 AM, Alan Bateman wrote:
> On 25/04/2013 21:25, Henry Jen wrote:
>> Hi,
>>
>> Please review two default methods add to CharSequence returns IntStream
>> of char value or code point value.
>>
>> http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
>>
>> The synchronization test is relieved so lambda and other synthetic
>> method is not tested. If synchronization is needed for those two default
>> methods, subclass should override the methods.
>>
>> With charAt and codePointAt properly synchronized, the default
>> implementation is sufficient. However as noted, if the sequence is
>> mutated while the stream is being read, the result is undefined.
>>
>> Cheers,
>> Henry
> I looked through the webrev and it looks okay as a first version. I
> agree with Martin's suggestion on the performance. I also wonder if
> CharBuffer will need to override at least chars(). This could of course
> be done as a follow-on piece of work.
> 

I agree, let's follow up on this after first version.

> In TestSynchronization then I assume the commented System.out should be
> removed.
> 

I will remove it.



From huizhe.wang at oracle.com  Mon Apr 29 17:00:24 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 29 Apr 2013 10:00:24 -0700
Subject: RFR: JDK-8008738 - Issue in
	com.sun.org.apache.xml.internal.serializer.Encodings
	causes some JCK tests to fail intermittently
In-Reply-To: <516C0A14.1080408@oracle.com>
References: <516C0A14.1080408@oracle.com>
Message-ID: <517EA728.4070304@oracle.com>

Hi Daniel,

Thanks for the detailed explanation!  The fix looks good.

Sorry for the delay.

Regards,
Joe

On 4/15/2013 7:09 AM, Daniel Fuchs wrote:
> Hi,
>
> This a fix for:
>
> JDK-8008738 - Issue in 
> com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK 
> tests to fail intermittently.
>
> 
>
> The issue here is that 
> com.sun.org.apache.xml.internal.serializer.Encodings
> tries to implement a double mapping:
>
>    Java Charset Name => Preferred XML Mime Name
>
> and
>
>    XML Mime Name => Java Charset Name
>
> from a specification that it reads from an Encoding.properties file.
>
> However, there can be several 'Java' names (aliases) corresponding to
> a given Charset, and there could also be several XML Mime Names,
> corresponding to that same charset.
>
> The Encodings.properties files uses 'Java Names' as keys, which it
> can map to one - or more - XML mime names, where the first XML name
> in the list stands for the 'preferred' mime name.
>
> The trouble is that some of the Java names present in the
> Encodings.properties files are not recognized by the Charset API,
> although some of the corresponding XML mime names, can be.
>
> This resulted in the creation of EncodingInfo objects whose charset
> name was not recognized by the Charset API. However, since there can
> be several Java Names specified with the same XML name, this did
> not always lead to errors:
> when 'converting' an XML name to a Java Name, if the first
> mapping picked up had a recognized Java Name - everything went well.
> If however - the first mapping picked up had an unrecognized Java Name,
> then this lead to failure to encode characters properly.
> Since the order in which the EncodingInfo where registered depended on
> the order of keys/values returned by HashMap/Properties - it could
> work in one run and fail in another.
>
> The proposed changeset is reworking the algorithm that
> creates EncodingInfo objects and perform the mapping
> Java Name <-> Mime Name:
>
> * Parse the whole line and consider both Java Names & Mime Names when
>   trying to instantiate EncodingInfo objects for a Java Name,
> * Make sure the javaName recorded in EncodingInfo is one that is
>   recognized by Charset.forName().
>
> The changeset has a unit test (under jdk/test/javax/xml/jaxp) which
>
> 1. verifies that the Encodings.properties file has no inconsistencies
>
> 2. verifies the mapping implemented by Encodings.java - by calling
>    Encodings.convertMime2JavaEncoding() and
>    Encodings.getMimeEncoding()
>    (skipping those names for which no charset could be loaded, as
>    not all charset are necessarily available on all machines).
>
> -- daniel
>
>
>



From chris.hegarty at oracle.com  Mon Apr 29 17:14:13 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 29 Apr 2013 17:14:13 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130429171452.186EA4869F@hg.openjdk.java.net>

Changeset: 9d324d667bb3
Author:    jzavgren
Date:      2013-04-29 08:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d324d667bb3

8012108: Memory leak in jdk/src/windows/native/java/net/NetworkInterface_winXP.c
Summary: Modified code to fix this leak and then proactively fixed improper calls to realloc() in the windows native code that can also cause leaks.
Reviewed-by: chegar, khazra, dsamersoff

! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

Changeset: b013d7433184
Author:    chegar
Date:      2013-04-29 18:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b013d7433184

Merge




From brian.burkhalter at oracle.com  Mon Apr 29 18:00:38 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 29 Apr 2013 11:00:38 -0700
Subject: Review Request: BigInteger patch for efficient multiplication and
	division (#4837946)
In-Reply-To: 
References: 
	<1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com>
	
Message-ID: 

Hi Tim,

On Apr 28, 2013, at 4:31 PM, Tim Buktu wrote:

> thanks for the update.

You're welcome.

>> This patch differs from the code inhttps://github.com/tbuktu/bigint.git. Notably I observed that Schonhage-Strassen multiplication and Barrett division are not present. Is this intentional and if so why would that be? Are the implementations of these additional algorithms not quite ready for contribution or is there a licensing issue perhaps?
> Sch?nhage-Strassen and Barrett have been tested by me. I believe Alan
> Eliasen also ran tests. There are no known bugs and there shouldn't be
> any licensing issues because I wrote the code myself.
> 
> The reason why I didn't include these two algorithms in the patch I
> posted here is because I wasn't sure if it was too much code to review.
> If that is not a problem and you'd rather use the full implementation,
> the four patched files are at
> 
> https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/BigInteger.java
> https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/MutableBigInteger.java
> https://raw.github.com/tbuktu/bigint/master/src/main/java/java/math/BigDecimal.java
> https://raw.github.com/tbuktu/bigint/master/src/test/java/BigIntegerTest.java

How much additional code is there for these two algorithms? Unless it is some daunting amount, then if you think that the code is of sufficient quality, my opinion would be that we might as well go ahead and review the most recent version. This would take longer of course, but I think less total time than doing it in two separate passes. Also, if these are not addressed now, it could be some time before separately reviewing the other two algorithms percolated to the top of the list.

> Let me know if there are any more questions.

Are the patched files listed above with respect to the current tip of the JDK8 repository?

Thanks,

Brian

From henry.jen at oracle.com  Mon Apr 29 19:41:35 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Apr 2013 12:41:35 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517BE84E.3040600@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
Message-ID: <517ECCEF.2020200@oracle.com>

On 04/27/2013 08:01 AM, Alan Bateman wrote:
> On 27/04/2013 00:08, Henry Jen wrote:
>> Hi,
>>
>> Please review webrev at
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>>
>> The API doc in specdiff format is at
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>>
>> Cheers,
>> Henry
> In the ZipFile spec it reads "Entries appear in the {@code Stream} in
> the order they appear in the ZIP file" but I think the order of the
> entries in the central directory and this may not be the same as the
> order of the entries in the archive.
> 

It is the order of enumeration of entries(), which I believe is the
order of the entries in the central directory of a zip file.

After another thought, is the ordering actually meaningful or has any
sort of benefit/guaranteed characteristics we should preserve?
Otherwise, it is probably better to left out the ORDERED.

Cheers,
Henry


From martinrb at google.com  Mon Apr 29 20:00:16 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 13:00:16 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: <517EA43D.3000504@oracle.com>
References: <51799135.5020801@oracle.com>
	
	<517EA43D.3000504@oracle.com>
Message-ID: 

Sure, micro-optimization doesn't necessarily buy much, and might be useless
with a sufficiently smart JIT and micro-benchmarking is known to be
difficult and surprising.  Nevertheless, we who have been writing
performance-critical code in core libraries have developed a style that
hotspot is known to love.

The biggest question for me is why length() is being called repeatedly.
 Can't you just copy the length once?  Since it's an interface call, it
might not always be easy for the JIT to inline.

Untested, but I would write this in bonkers-for-performance style like this:


    public default IntStream codePoints3() {
        class CodePointIterator implements PrimitiveIterator.OfInt {
            int cur = 0;
            final int length = length();

            @Override
            public void forEachRemaining(IntConsumer block) {
                final int length = this.length;
                for (int i = cur; i < length;) {
                    char c = charAt(i++);
                    if (!isHighSurrogate(c))
                        block.accept(c);
                    else {
                        forEachRemainingSupplementary(block, i);
                        break;
                    }
                }
                cur = length;
            }

            private void forEachRemainingSupplementary(IntConsumer block,
                                                       int i) {
                int cp;
                for (i--; i < length; i += charCount(cp)) {
                    cp = codePointAt(CharSequence.this, cur);
                    block.accept(cp);
                }
            }

            public boolean hasNext() {
                return cur < length;
            }

            public int nextInt() {
                if (cur >= length) {
                    throw new NoSuchElementException();
                }
                char c = charAt(cur++);
                return isHighSurrogate(c) ? nextIntSupplementary(c) : c;
            }

            private int nextIntSupplementary(char highSurrogate) {
                if (cur < length) {
                    char c = charAt(cur);
                    if (isLowSurrogate(c)) {
                        cur++;
                        return toCodePoint(highSurrogate, c);
                    }
                }
                return highSurrogate;
            }
        }

        return StreamSupport.intStream(() ->
                Spliterators.spliteratorUnknownSize(
                        new CodePointIterator(),
                        Spliterator.ORDERED),
                Spliterator.SUBSIZED | Spliterator.SIZED |
Spliterator.ORDERED);
    }


On Mon, Apr 29, 2013 at 9:47 AM, Henry Jen  wrote:

> Hi Martin,
>
> Thanks for the comment, I looked at this when I first saw a similar
> comment in the code, and didn't change it because the charCount() is a
> small operation. The code is just,
>
> > codePoint >= MIN_SUPPLEMENTARY_CODE_POINT ? 2 : 1;
>
> Another reason I didn't change it is to avoid repeated code.
>
> I suspect there is much to gain. We can follow up this in a separate
> issue and get this version in first before feature freeze?
>
> Cheers,
> Henry
>
> On 04/25/2013 04:14 PM, Martin Buchholz wrote:
> > I think core library code should write the slightly lower-level code for
> > performance
> >
> > +                int cp = Character.codePointAt(CharSequence.this, cur);
> > +                cur += Character.charCount(cp);
> >
> > int length = length();
> > if (cur == length) throw NSEE;
> > char c1 = charAt(cur++), c2;
> > if (!isHighSurrogate(c1) || cur == length || !isLowSurrogate(c2 =
> > charAt(cur))
> >   return c1;
> > cur++;
> > return toCodePoint(c1, c2);
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 1:25 PM, Henry Jen  > > wrote:
> >
> >     Hi,
> >
> >     Please review two default methods add to CharSequence returns
> IntStream
> >     of char value or code point value.
> >
> >     http://cr.openjdk.java.net/~henryjen/tl/8012665.0/webrev/
> >
> >     The synchronization test is relieved so lambda and other synthetic
> >     method is not tested. If synchronization is needed for those two
> default
> >     methods, subclass should override the methods.
> >
> >     With charAt and codePointAt properly synchronized, the default
> >     implementation is sufficient. However as noted, if the sequence is
> >     mutated while the stream is being read, the result is undefined.
> >
> >     Cheers,
> >     Henry
> >
> >
>
>


From martinrb at google.com  Mon Apr 29 20:02:06 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 13:02:06 -0700
Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints
In-Reply-To: 
References: <51799135.5020801@oracle.com>
	
	<517EA43D.3000504@oracle.com>
	
Message-ID: 

Note also that I'm making vaguely related changes to CharSequence and
Buffer implementations.
No reason not to at least get this code feature-complete now and optimize
later.


From xueming.shen at oracle.com  Mon Apr 29 20:56:23 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 29 Apr 2013 13:56:23 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible by
	group name
Message-ID: <517EDE77.2050305@oracle.com>

Hi,

The regex named capturing group support was added into jdk7 [1].
Matcher.group(gname) is the only direct access method we added back then
to access the matched result. The proposed change here is to add a pair of
accessing/convenient method Matcher.start/end(gname) to access the start/end
offset info of the matched result, to match the corresponding start/end/group
(int index) access methods.

http://cr.openjdk.java.net/~sherman/8013252/webrev

Thanks!
-Sherman

[1] http://cr.openjdk.java.net/~sherman/6350801/webrev.02/


From mike.duigou at oracle.com  Mon Apr 29 21:21:56 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 29 Apr 2013 21:21:56 +0000
Subject: hg: jdk8/tl: 2 new changesets
Message-ID: <20130429212156.2EF63486AC@hg.openjdk.java.net>

Changeset: a7a8302473d3
Author:    mduigou
Date:      2013-04-29 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/a7a8302473d3

8008632: Additional JavaDoc tags @apiNote, @implSpec and @implNote
Reviewed-by: briangoetz, alanb, rriggs

! common/makefiles/javadoc/Javadoc.gmk

Changeset: f171aa801ea5
Author:    mduigou
Date:      2013-04-29 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f171aa801ea5

Merge




From kumar.x.srinivasan at oracle.com  Mon Apr 29 22:05:34 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 29 Apr 2013 15:05:34 -0700
Subject: RFR: 8009389: Unpack200 native library should be removed from profiles
Message-ID: <517EEEAE.1020502@oracle.com>

Hi,

Please review this fix which will enable profiles and embedded distros to
eliminate the unpack200 binaries saving space, all this does is switch
to the java implementation if the native one cannot be found.

http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/

Thanks
Kumar



From kumar.x.srinivasan at oracle.com  Mon Apr 29 22:25:31 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 29 Apr 2013 15:25:31 -0700
Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest.
In-Reply-To: <750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com>
	<750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com>
Message-ID: <517EF35B.1000104@oracle.com>


> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>
> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.

It looks the SmallSet needs more discussion.. barring that anyone else 
have any other
concerns with this change ? If I don't hear any objections I will push 
this on 05/01.

Thanks
Kumar

>
> Looks OK. The testing, which you have done, is the important qualifier for this change.
>
> Mike
>
> On Apr 25 2013, at 13:24 , Kumar Srinivasan wrote:
>
>> Here is the webrev:
>> http://cr.openjdk.java.net/~ksrini/8013225/webrev.0/
>>
>> Thanks
>> Kumar
>>
>>> Hello,
>>>
>>> Please review changes which essentially contains asm5_future in asm's mainline
>>> repository, I have tested this patch with Nashorn (so has Sundar), as well as Lambda's
>>> usage.
>>>
>>> Fixes that I know of:
>>> 1. supports v52.0 class files and JSR 308/Type Annotations changes
>>>
>>> Thanks to Remi
>>> 2. elimination of "_" usages in variable names
>>> 3. several javadoc changes and one reported by Sundar
>>> http://jbs.oracle.com/bugs/browse/JDK-8010083
>>>
>>>
>>> Thanks
>>> Kumar
>>>



From mark.sheppard at oracle.com  Mon Apr 29 23:04:51 2013
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 30 Apr 2013 00:04:51 +0100
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder that
	unexpectedly inserts line separator when using some of the encoding
	methods
Message-ID: <517EFC93.6050603@oracle.com>

Hi,
    please find below an updated webrev incorporating the feedback from 
webrev.01 (thanks for the replies)

http://cr.openjdk.java.net/~msheppar/8007799/webrev.02/

regards
Mark


From john.r.rose at oracle.com  Mon Apr 29 23:11:06 2013
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 29 Apr 2013 16:11:06 -0700
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517EEEAE.1020502@oracle.com>
References: <517EEEAE.1020502@oracle.com>
Message-ID: 

On Apr 29, 2013, at 3:05 PM, Kumar Srinivasan  wrote:

> Please review this fix which will enable profiles and embedded distros to
> eliminate the unpack200 binaries saving space, all this does is switch
> to the java implementation if the native one cannot be found.
> 
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/

Yes, that looks good.  ? John

From xueming.shen at oracle.com  Mon Apr 29 23:27:56 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 29 Apr 2013 16:27:56 -0700
Subject: RFR: JDK-8007799 Base64.getEncoder(0, byte[]) returns encoder
	that unexpectedly inserts line separator when using some of the
	encoding methods
In-Reply-To: <517EFC93.6050603@oracle.com>
References: <517EFC93.6050603@oracle.com>
Message-ID: <517F01FC.6010506@oracle.com>

Looks fine.

-Sherman

On 04/29/2013 04:04 PM, Mark Sheppard wrote:
> Hi,
>    please find below an updated webrev incorporating the feedback from webrev.01 (thanks for the replies)
>
> http://cr.openjdk.java.net/~msheppar/8007799/webrev.02/
>
> regards
> Mark



From brian.burkhalter at oracle.com  Mon Apr 29 23:40:59 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 29 Apr 2013 16:40:59 -0700
Subject: Review Request: BigInteger patch for efficient multiplication and
	division (#4837946)
In-Reply-To: 
References: 
	<1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com>
	
	
Message-ID: 

On Apr 29, 2013, at 11:00 AM, Brian Burkhalter wrote:

> How much additional code is there for these two algorithms?

To answer my own question, there are apparently about 1,000 more lines.

> Unless it is some daunting amount, then if you think that the code is of sufficient quality, my opinion would be that we might as well go ahead and review the most recent version. This would take longer of course, but I think less total time than doing it in two separate passes. Also, if these are not addressed now, it could be some time before separately reviewing the other two algorithms percolated to the top of the list.
> 
>> Let me know if there are any more questions.
> 
> Are the patched files listed above with respect to the current tip of the JDK8 repository?

It looks to me as if they are, i.e., the only changes versus the JDK8 repo are those intended for this patch.

Thanks,

Brian

From martinrb at google.com  Mon Apr 29 23:43:26 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 16:43:26 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
Message-ID: 

As always for changes to files maintained in jsr166 CVS, we'd like changes
to flow through jsr166 CVS into openjdk proper.

In this case, there are some issues with missing exception specs in
implementing classes.  I'll come up with a diff.

Martin


On Fri, Apr 26, 2013 at 5:12 PM, Mike Duigou  wrote:

> Hello all;
>
> A very small change to review.
>
> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
>
> The change removes some erroneous documentation from the Deque push()
> method.
>
> Mike
>


From mike.duigou at oracle.com  Mon Apr 29 23:56:54 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 29 Apr 2013 16:56:54 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
	
Message-ID: 

OK, I will wait on that and hopefully Chris can pick it up on the next jsr166 sync.

Mike

On Apr 29 2013, at 16:43 , Martin Buchholz wrote:

> As always for changes to files maintained in jsr166 CVS, we'd like changes to flow through jsr166 CVS into openjdk proper.
> 
> In this case, there are some issues with missing exception specs in implementing classes.  I'll come up with a diff.
> 
> Martin
> 
> 
> On Fri, Apr 26, 2013 at 5:12 PM, Mike Duigou  wrote:
> Hello all;
> 
> A very small change to review.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
> 
> The change removes some erroneous documentation from the Deque push() method.
> 
> Mike
> 



From martinrb at google.com  Tue Apr 30 01:05:03 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 18:05:03 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
	
	
Message-ID: 

Below is my proposed alternative fix, that also  adds some missing @throws,
reuses some existing wording, and makes small improvements to existing
@throws specs (maintaining these specs is very tedious...)

Index: src/main/java/util/Deque.java
===================================================================
RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/Deque.java,v
retrieving revision 1.24
diff -u -U 15 -r1.24 Deque.java
--- src/main/java/util/Deque.java 11 Feb 2013 17:27:45 -0000 1.24
+++ src/main/java/util/Deque.java 30 Apr 2013 01:01:56 -0000
@@ -155,51 +155,53 @@
  * methods, but instead inherit the identity-based versions from class
  * {@code Object}.
  *
  * 
        This interface is a member of the  Java
Collections
  * Framework.
  *
  * @author Doug Lea
  * @author Josh Bloch
  * @since  1.6
  * @param  the type of elements held in this collection
  */
 public interface Deque extends Queue {
     /**
      * Inserts the specified element at the front of this deque if it is
-     * possible to do so immediately without violating capacity
restrictions.
-     * When using a capacity-restricted deque, it is generally preferable
to
-     * use method {@link #offerFirst}.
+     * possible to do so immediately without violating capacity
restrictions,
+     * throwing an {@code IllegalStateException} if no space is currently
+     * available.  When using a capacity-restricted deque, it is generally
+     * preferable to use method {@link #offerFirst}.
      *
      * @param e the element to add
      * @throws IllegalStateException if the element cannot be added at this
      *         time due to capacity restrictions
      * @throws ClassCastException if the class of the specified element
      *         prevents it from being added to this deque
      * @throws NullPointerException if the specified element is null and
this
      *         deque does not permit null elements
      * @throws IllegalArgumentException if some property of the specified
      *         element prevents it from being added to this deque
      */
     void addFirst(E e);

     /**
      * Inserts the specified element at the end of this deque if it is
-     * possible to do so immediately without violating capacity
restrictions.
-     * When using a capacity-restricted deque, it is generally preferable
to
-     * use method {@link #offerLast}.
+     * possible to do so immediately without violating capacity
restrictions,
+     * throwing an {@code IllegalStateException} if no space is currently
+     * available.  When using a capacity-restricted deque, it is generally
+     * preferable to use method {@link #offerLast}.
      *
      * 
        This method is equivalent to {@link #add}.
      *
      * @param e the element to add
      * @throws IllegalStateException if the element cannot be added at this
      *         time due to capacity restrictions
      * @throws ClassCastException if the class of the specified element
      *         prevents it from being added to this deque
      * @throws NullPointerException if the specified element is null and
this
      *         deque does not permit null elements
      * @throws IllegalArgumentException if some property of the specified
      *         element prevents it from being added to this deque
      */
     void addLast(E e);

@@ -441,32 +443,31 @@
      * returns {@code null} if this deque is empty.
      *
      * 
        This method is equivalent to {@link #peekFirst()}.
      *
      * @return the head of the queue represented by this deque, or
      *         {@code null} if this deque is empty
      */
     E peek();


     // *** Stack methods ***

     /**
      * Pushes an element onto the stack represented by this deque (in other
      * words, at the head of this deque) if it is possible to do so
-     * immediately without violating capacity restrictions, returning
-     * {@code true} upon success and throwing an
+     * immediately without violating capacity restrictions, throwing an
      * {@code IllegalStateException} if no space is currently available.
      *
      * 
        This method is equivalent to {@link #addFirst}.
      *
      * @param e the element to push
      * @throws IllegalStateException if the element cannot be added at this
      *         time due to capacity restrictions
      * @throws ClassCastException if the class of the specified element
      *         prevents it from being added to this deque
      * @throws NullPointerException if the specified element is null and
this
      *         deque does not permit null elements
      * @throws IllegalArgumentException if some property of the specified
      *         element prevents it from being added to this deque
      */
     void push(E e);
Index: src/main/java/util/concurrent/BlockingDeque.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/BlockingDeque.java,v
retrieving revision 1.25
diff -u -U 15 -r1.25 BlockingDeque.java
--- src/main/java/util/concurrent/BlockingDeque.java 11 Feb 2013 17:27:45
-0000 1.25
+++ src/main/java/util/concurrent/BlockingDeque.java 30 Apr 2013 01:01:57
-0000
@@ -596,28 +596,29 @@
      * @return the number of elements in this deque
      */
     public int size();

     /**
      * Returns an iterator over the elements in this deque in proper
sequence.
      * The elements will be returned in order from first (head) to last
(tail).
      *
      * @return an iterator over the elements in this deque in proper
sequence
      */
     Iterator iterator();

     // *** Stack methods ***

     /**
-     * Pushes an element onto the stack represented by this deque.  In
other
-     * words, inserts the element at the front of this deque unless it
would
-     * violate capacity restrictions.
+     * Pushes an element onto the stack represented by this deque (in other
+     * words, at the head of this deque) if it is possible to do so
+     * immediately without violating capacity restrictions, throwing an
+     * {@code IllegalStateException} if no space is currently available.
      *
      * 
        This method is equivalent to {@link #addFirst(Object) addFirst}.
      *
      * @throws IllegalStateException {@inheritDoc}
      * @throws ClassCastException {@inheritDoc}
      * @throws NullPointerException if the specified element is null
      * @throws IllegalArgumentException {@inheritDoc}
      */
     void push(E e);
 }
Index: src/main/java/util/concurrent/ConcurrentLinkedDeque.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v
retrieving revision 1.43
diff -u -U 15 -r1.43 ConcurrentLinkedDeque.java
--- src/main/java/util/concurrent/ConcurrentLinkedDeque.java 27 Mar 2013
19:46:34 -0000 1.43
+++ src/main/java/util/concurrent/ConcurrentLinkedDeque.java 30 Apr 2013
01:01:57 -0000
@@ -989,35 +989,51 @@
     }

     /**
      * Inserts the specified element at the tail of this deque.
      * As the deque is unbounded, this method will never throw
      * {@link IllegalStateException} or return {@code false}.
      *
      * @return {@code true} (as specified by {@link Collection#add})
      * @throws NullPointerException if the specified element is null
      */
     public boolean add(E e) {
         return offerLast(e);
     }

     public E poll()           { return pollFirst(); }
-    public E remove()         { return removeFirst(); }
     public E peek()           { return peekFirst(); }
+
+    /**
+     * @throws NoSuchElementException {@inheritDoc}
+     */
+    public E remove()         { return removeFirst(); }
+
+    /**
+     * @throws NoSuchElementException {@inheritDoc}
+     */
+    public E pop()            { return removeFirst(); }
+
+    /**
+     * @throws NoSuchElementException {@inheritDoc}
+     */
     public E element()        { return getFirst(); }
+
+    /**
+     * @throws NullPointerException {@inheritDoc}
+     */
     public void push(E e)     { addFirst(e); }
-    public E pop()            { return removeFirst(); }

     /**
      * Removes the first element {@code e} such that
      * {@code o.equals(e)}, if such an element exists in this deque.
      * If the deque does not contain the element, it is unchanged.
      *
      * @param o element to be removed from this deque, if present
      * @return {@code true} if the deque contained the specified element
      * @throws NullPointerException if the specified element is null
      */
     public boolean removeFirstOccurrence(Object o) {
         checkNotNull(o);
         for (Node p = first(); p != null; p = succ(p)) {
             E item = p.item;
             if (item != null && o.equals(item) && p.casItem(item, null)) {
Index: src/main/java/util/concurrent/LinkedBlockingDeque.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v
retrieving revision 1.44
diff -u -U 15 -r1.44 LinkedBlockingDeque.java
--- src/main/java/util/concurrent/LinkedBlockingDeque.java 27 Mar 2013
19:46:34 -0000 1.44
+++ src/main/java/util/concurrent/LinkedBlockingDeque.java 30 Apr 2013
01:01:57 -0000
@@ -280,40 +280,40 @@
             unlinkLast();
         } else {
             p.next = n;
             n.prev = p;
             x.item = null;
             // Don't mess with x's links.  They may still be in use by
             // an iterator.
             --count;
             notFull.signal();
         }
     }

     // BlockingDeque methods

     /**
-     * @throws IllegalStateException {@inheritDoc}
-     * @throws NullPointerException  {@inheritDoc}
+     * @throws IllegalStateException if this deque is full
+     * @throws NullPointerException {@inheritDoc}
      */
     public void addFirst(E e) {
         if (!offerFirst(e))
             throw new IllegalStateException("Deque full");
     }

     /**
-     * @throws IllegalStateException {@inheritDoc}
+     * @throws IllegalStateException if this deque is full
      * @throws NullPointerException  {@inheritDoc}
      */
     public void addLast(E e) {
         if (!offerLast(e))
             throw new IllegalStateException("Deque full");
     }

     /**
      * @throws NullPointerException {@inheritDoc}
      */
     public boolean offerFirst(E e) {
         if (e == null) throw new NullPointerException();
         Node node = new Node(e);
         final ReentrantLock lock = this.lock;
         lock.lock();
@@ -588,32 +588,31 @@
             return false;
         } finally {
             lock.unlock();
         }
     }

     // BlockingQueue methods

     /**
      * Inserts the specified element at the end of this deque unless it
would
      * violate capacity restrictions.  When using a capacity-restricted
deque,
      * it is generally preferable to use method {@link #offer(Object)
offer}.
      *
      * 
        This method is equivalent to {@link #addLast}.
      *
-     * @throws IllegalStateException if the element cannot be added at this
-     *         time due to capacity restrictions
+     * @throws IllegalStateException if this deque is full
      * @throws NullPointerException if the specified element is null
      */
     public boolean add(E e) {
         addLast(e);
         return true;
     }

     /**
      * @throws NullPointerException if the specified element is null
      */
     public boolean offer(E e) {
         return offerLast(e);
     }

     /**
@@ -726,32 +725,32 @@
         try {
             int n = Math.min(maxElements, count);
             for (int i = 0; i < n; i++) {
                 c.add(first.item);   // In this order, in case add()
throws.
                 unlinkFirst();
             }
             return n;
         } finally {
             lock.unlock();
         }
     }

     // Stack methods

     /**
-     * @throws IllegalStateException {@inheritDoc}
-     * @throws NullPointerException  {@inheritDoc}
+     * @throws IllegalStateException if this deque is full
+     * @throws NullPointerException {@inheritDoc}
      */
     public void push(E e) {
         addFirst(e);
     }

     /**
      * @throws NoSuchElementException {@inheritDoc}
      */
     public E pop() {
         return removeFirst();
     }

     // Collection methods

     /**
@@ -817,31 +816,31 @@
      * collection, especially when count is close to capacity.
      */

 //     /**
 //      * Adds all of the elements in the specified collection to this
 //      * queue.  Attempts to addAll of a queue to itself result in
 //      * {@code IllegalArgumentException}. Further, the behavior of
 //      * this operation is undefined if the specified collection is
 //      * modified while the operation is in progress.
 //      *
 //      * @param c collection containing elements to be added to this queue
 //      * @return {@code true} if this queue changed as a result of the
call
 //      * @throws ClassCastException            {@inheritDoc}
 //      * @throws NullPointerException          {@inheritDoc}
 //      * @throws IllegalArgumentException      {@inheritDoc}
-//      * @throws IllegalStateException         {@inheritDoc}
+//      * @throws IllegalStateException if this deque is full
 //      * @see #add(Object)
 //      */
 //     public boolean addAll(Collection c) {
 //         if (c == null)
 //             throw new NullPointerException();
 //         if (c == this)
 //             throw new IllegalArgumentException();
 //         final ReentrantLock lock = this.lock;
 //         lock.lock();
 //         try {
 //             boolean modified = false;
 //             for (E e : c)
 //                 if (linkLast(e))
 //                     modified = true;
 //             return modified;



On Mon, Apr 29, 2013 at 4:56 PM, Mike Duigou  wrote:

> OK, I will wait on that and hopefully Chris can pick it up on the next
> jsr166 sync.
>
> Mike
>
> On Apr 29 2013, at 16:43 , Martin Buchholz wrote:
>
> As always for changes to files maintained in jsr166 CVS, we'd like changes
> to flow through jsr166 CVS into openjdk proper.
>
> In this case, there are some issues with missing exception specs in
> implementing classes.  I'll come up with a diff.
>
> Martin
>
>
> On Fri, Apr 26, 2013 at 5:12 PM, Mike Duigou wrote:
>
>> Hello all;
>>
>> A very small change to review.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
>>
>> The change removes some erroneous documentation from the Deque push()
>> method.
>>
>> Mike
>>
>
>
>


From mike.duigou at oracle.com  Tue Apr 30 01:14:39 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 29 Apr 2013 18:14:39 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: 
References: 
	
	
	
Message-ID: <785068FE-A26A-4C67-9B17-32D54C8B104C@oracle.com>

Looks reasonable to me. Could BlockingDeque::push() just use {@inheritDoc} for main body doc?

Mike

On Apr 29 2013, at 18:05 , Martin Buchholz wrote:

> Below is my proposed alternative fix, that also  adds some missing @throws, reuses some existing wording, and makes small improvements to existing @throws specs (maintaining these specs is very tedious...)
> 
> Index: src/main/java/util/Deque.java
> ===================================================================
> RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/Deque.java,v
> retrieving revision 1.24
> diff -u -U 15 -r1.24 Deque.java
> --- src/main/java/util/Deque.java	11 Feb 2013 17:27:45 -0000	1.24
> +++ src/main/java/util/Deque.java	30 Apr 2013 01:01:56 -0000
> @@ -155,51 +155,53 @@
>   * methods, but instead inherit the identity-based versions from class
>   * {@code Object}.
>   *
>   * 
        This interface is a member of the    * href="{@docRoot}/../technotes/guides/collections/index.html"> Java Collections
>   * Framework.
>   *
>   * @author Doug Lea
>   * @author Josh Bloch
>   * @since  1.6
>   * @param  the type of elements held in this collection
>   */
>  public interface Deque extends Queue {
>      /**
>       * Inserts the specified element at the front of this deque if it is
> -     * possible to do so immediately without violating capacity restrictions.
> -     * When using a capacity-restricted deque, it is generally preferable to
> -     * use method {@link #offerFirst}.
> +     * possible to do so immediately without violating capacity restrictions,
> +     * throwing an {@code IllegalStateException} if no space is currently
> +     * available.  When using a capacity-restricted deque, it is generally
> +     * preferable to use method {@link #offerFirst}.
>       *
>       * @param e the element to add
>       * @throws IllegalStateException if the element cannot be added at this
>       *         time due to capacity restrictions
>       * @throws ClassCastException if the class of the specified element
>       *         prevents it from being added to this deque
>       * @throws NullPointerException if the specified element is null and this
>       *         deque does not permit null elements
>       * @throws IllegalArgumentException if some property of the specified
>       *         element prevents it from being added to this deque
>       */
>      void addFirst(E e);
>  
>      /**
>       * Inserts the specified element at the end of this deque if it is
> -     * possible to do so immediately without violating capacity restrictions.
> -     * When using a capacity-restricted deque, it is generally preferable to
> -     * use method {@link #offerLast}.
> +     * possible to do so immediately without violating capacity restrictions,
> +     * throwing an {@code IllegalStateException} if no space is currently
> +     * available.  When using a capacity-restricted deque, it is generally
> +     * preferable to use method {@link #offerLast}.
>       *
>       * 
        This method is equivalent to {@link #add}.
>       *
>       * @param e the element to add
>       * @throws IllegalStateException if the element cannot be added at this
>       *         time due to capacity restrictions
>       * @throws ClassCastException if the class of the specified element
>       *         prevents it from being added to this deque
>       * @throws NullPointerException if the specified element is null and this
>       *         deque does not permit null elements
>       * @throws IllegalArgumentException if some property of the specified
>       *         element prevents it from being added to this deque
>       */
>      void addLast(E e);
>  
> @@ -441,32 +443,31 @@
>       * returns {@code null} if this deque is empty.
>       *
>       * 
        This method is equivalent to {@link #peekFirst()}.
>       *
>       * @return the head of the queue represented by this deque, or
>       *         {@code null} if this deque is empty
>       */
>      E peek();
>  
>  
>      // *** Stack methods ***
>  
>      /**
>       * Pushes an element onto the stack represented by this deque (in other
>       * words, at the head of this deque) if it is possible to do so
> -     * immediately without violating capacity restrictions, returning
> -     * {@code true} upon success and throwing an
> +     * immediately without violating capacity restrictions, throwing an
>       * {@code IllegalStateException} if no space is currently available.
>       *
>       * 
        This method is equivalent to {@link #addFirst}.
>       *
>       * @param e the element to push
>       * @throws IllegalStateException if the element cannot be added at this
>       *         time due to capacity restrictions
>       * @throws ClassCastException if the class of the specified element
>       *         prevents it from being added to this deque
>       * @throws NullPointerException if the specified element is null and this
>       *         deque does not permit null elements
>       * @throws IllegalArgumentException if some property of the specified
>       *         element prevents it from being added to this deque
>       */
>      void push(E e);
> Index: src/main/java/util/concurrent/BlockingDeque.java
> ===================================================================
> RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/BlockingDeque.java,v
> retrieving revision 1.25
> diff -u -U 15 -r1.25 BlockingDeque.java
> --- src/main/java/util/concurrent/BlockingDeque.java	11 Feb 2013 17:27:45 -0000	1.25
> +++ src/main/java/util/concurrent/BlockingDeque.java	30 Apr 2013 01:01:57 -0000
> @@ -596,28 +596,29 @@
>       * @return the number of elements in this deque
>       */
>      public int size();
>  
>      /**
>       * Returns an iterator over the elements in this deque in proper sequence.
>       * The elements will be returned in order from first (head) to last (tail).
>       *
>       * @return an iterator over the elements in this deque in proper sequence
>       */
>      Iterator iterator();
>  
>      // *** Stack methods ***
>  
>      /**
> -     * Pushes an element onto the stack represented by this deque.  In other
> -     * words, inserts the element at the front of this deque unless it would
> -     * violate capacity restrictions.
> +     * Pushes an element onto the stack represented by this deque (in other
> +     * words, at the head of this deque) if it is possible to do so
> +     * immediately without violating capacity restrictions, throwing an
> +     * {@code IllegalStateException} if no space is currently available.
>       *
>       * 
        This method is equivalent to {@link #addFirst(Object) addFirst}.
>       *
>       * @throws IllegalStateException {@inheritDoc}
>       * @throws ClassCastException {@inheritDoc}
>       * @throws NullPointerException if the specified element is null
>       * @throws IllegalArgumentException {@inheritDoc}
>       */
>      void push(E e);
>  }
> Index: src/main/java/util/concurrent/ConcurrentLinkedDeque.java
> ===================================================================
> RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v
> retrieving revision 1.43
> diff -u -U 15 -r1.43 ConcurrentLinkedDeque.java
> --- src/main/java/util/concurrent/ConcurrentLinkedDeque.java	27 Mar 2013 19:46:34 -0000	1.43
> +++ src/main/java/util/concurrent/ConcurrentLinkedDeque.java	30 Apr 2013 01:01:57 -0000
> @@ -989,35 +989,51 @@
>      }
>  
>      /**
>       * Inserts the specified element at the tail of this deque.
>       * As the deque is unbounded, this method will never throw
>       * {@link IllegalStateException} or return {@code false}.
>       *
>       * @return {@code true} (as specified by {@link Collection#add})
>       * @throws NullPointerException if the specified element is null
>       */
>      public boolean add(E e) {
>          return offerLast(e);
>      }
>  
>      public E poll()           { return pollFirst(); }
> -    public E remove()         { return removeFirst(); }
>      public E peek()           { return peekFirst(); }
> +
> +    /**
> +     * @throws NoSuchElementException {@inheritDoc}
> +     */
> +    public E remove()         { return removeFirst(); }
> +
> +    /**
> +     * @throws NoSuchElementException {@inheritDoc}
> +     */
> +    public E pop()            { return removeFirst(); }
> +
> +    /**
> +     * @throws NoSuchElementException {@inheritDoc}
> +     */
>      public E element()        { return getFirst(); }
> +
> +    /**
> +     * @throws NullPointerException {@inheritDoc}
> +     */
>      public void push(E e)     { addFirst(e); }
> -    public E pop()            { return removeFirst(); }
>  
>      /**
>       * Removes the first element {@code e} such that
>       * {@code o.equals(e)}, if such an element exists in this deque.
>       * If the deque does not contain the element, it is unchanged.
>       *
>       * @param o element to be removed from this deque, if present
>       * @return {@code true} if the deque contained the specified element
>       * @throws NullPointerException if the specified element is null
>       */
>      public boolean removeFirstOccurrence(Object o) {
>          checkNotNull(o);
>          for (Node p = first(); p != null; p = succ(p)) {
>              E item = p.item;
>              if (item != null && o.equals(item) && p.casItem(item, null)) {
> Index: src/main/java/util/concurrent/LinkedBlockingDeque.java
> ===================================================================
> RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v
> retrieving revision 1.44
> diff -u -U 15 -r1.44 LinkedBlockingDeque.java
> --- src/main/java/util/concurrent/LinkedBlockingDeque.java	27 Mar 2013 19:46:34 -0000	1.44
> +++ src/main/java/util/concurrent/LinkedBlockingDeque.java	30 Apr 2013 01:01:57 -0000
> @@ -280,40 +280,40 @@
>              unlinkLast();
>          } else {
>              p.next = n;
>              n.prev = p;
>              x.item = null;
>              // Don't mess with x's links.  They may still be in use by
>              // an iterator.
>              --count;
>              notFull.signal();
>          }
>      }
>  
>      // BlockingDeque methods
>  
>      /**
> -     * @throws IllegalStateException {@inheritDoc}
> -     * @throws NullPointerException  {@inheritDoc}
> +     * @throws IllegalStateException if this deque is full
> +     * @throws NullPointerException {@inheritDoc}
>       */
>      public void addFirst(E e) {
>          if (!offerFirst(e))
>              throw new IllegalStateException("Deque full");
>      }
>  
>      /**
> -     * @throws IllegalStateException {@inheritDoc}
> +     * @throws IllegalStateException if this deque is full
>       * @throws NullPointerException  {@inheritDoc}
>       */
>      public void addLast(E e) {
>          if (!offerLast(e))
>              throw new IllegalStateException("Deque full");
>      }
>  
>      /**
>       * @throws NullPointerException {@inheritDoc}
>       */
>      public boolean offerFirst(E e) {
>          if (e == null) throw new NullPointerException();
>          Node node = new Node(e);
>          final ReentrantLock lock = this.lock;
>          lock.lock();
> @@ -588,32 +588,31 @@
>              return false;
>          } finally {
>              lock.unlock();
>          }
>      }
>  
>      // BlockingQueue methods
>  
>      /**
>       * Inserts the specified element at the end of this deque unless it would
>       * violate capacity restrictions.  When using a capacity-restricted deque,
>       * it is generally preferable to use method {@link #offer(Object) offer}.
>       *
>       * 
        This method is equivalent to {@link #addLast}.
>       *
> -     * @throws IllegalStateException if the element cannot be added at this
> -     *         time due to capacity restrictions
> +     * @throws IllegalStateException if this deque is full
>       * @throws NullPointerException if the specified element is null
>       */
>      public boolean add(E e) {
>          addLast(e);
>          return true;
>      }
>  
>      /**
>       * @throws NullPointerException if the specified element is null
>       */
>      public boolean offer(E e) {
>          return offerLast(e);
>      }
>  
>      /**
> @@ -726,32 +725,32 @@
>          try {
>              int n = Math.min(maxElements, count);
>              for (int i = 0; i < n; i++) {
>                  c.add(first.item);   // In this order, in case add() throws.
>                  unlinkFirst();
>              }
>              return n;
>          } finally {
>              lock.unlock();
>          }
>      }
>  
>      // Stack methods
>  
>      /**
> -     * @throws IllegalStateException {@inheritDoc}
> -     * @throws NullPointerException  {@inheritDoc}
> +     * @throws IllegalStateException if this deque is full
> +     * @throws NullPointerException {@inheritDoc}
>       */
>      public void push(E e) {
>          addFirst(e);
>      }
>  
>      /**
>       * @throws NoSuchElementException {@inheritDoc}
>       */
>      public E pop() {
>          return removeFirst();
>      }
>  
>      // Collection methods
>  
>      /**
> @@ -817,31 +816,31 @@
>       * collection, especially when count is close to capacity.
>       */
>  
>  //     /**
>  //      * Adds all of the elements in the specified collection to this
>  //      * queue.  Attempts to addAll of a queue to itself result in
>  //      * {@code IllegalArgumentException}. Further, the behavior of
>  //      * this operation is undefined if the specified collection is
>  //      * modified while the operation is in progress.
>  //      *
>  //      * @param c collection containing elements to be added to this queue
>  //      * @return {@code true} if this queue changed as a result of the call
>  //      * @throws ClassCastException            {@inheritDoc}
>  //      * @throws NullPointerException          {@inheritDoc}
>  //      * @throws IllegalArgumentException      {@inheritDoc}
> -//      * @throws IllegalStateException         {@inheritDoc}
> +//      * @throws IllegalStateException if this deque is full
>  //      * @see #add(Object)
>  //      */
>  //     public boolean addAll(Collection c) {
>  //         if (c == null)
>  //             throw new NullPointerException();
>  //         if (c == this)
>  //             throw new IllegalArgumentException();
>  //         final ReentrantLock lock = this.lock;
>  //         lock.lock();
>  //         try {
>  //             boolean modified = false;
>  //             for (E e : c)
>  //                 if (linkLast(e))
>  //                     modified = true;
>  //             return modified;
> 
> 
> 
> On Mon, Apr 29, 2013 at 4:56 PM, Mike Duigou  wrote:
> OK, I will wait on that and hopefully Chris can pick it up on the next jsr166 sync.
> 
> Mike
> 
> On Apr 29 2013, at 16:43 , Martin Buchholz wrote:
> 
>> As always for changes to files maintained in jsr166 CVS, we'd like changes to flow through jsr166 CVS into openjdk proper.
>> 
>> In this case, there are some issues with missing exception specs in implementing classes.  I'll come up with a diff.
>> 
>> Martin
>> 
>> 
>> On Fri, Apr 26, 2013 at 5:12 PM, Mike Duigou  wrote:
>> Hello all;
>> 
>> A very small change to review.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
>> 
>> The change removes some erroneous documentation from the Deque push() method.
>> 
>> Mike
>> 
> 
> 



From martinrb at google.com  Tue Apr 30 01:21:21 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 18:21:21 -0700
Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from
	Deque.push(E e)
In-Reply-To: <785068FE-A26A-4C67-9B17-32D54C8B104C@oracle.com>
References: 
	
	
	
	<785068FE-A26A-4C67-9B17-32D54C8B104C@oracle.com>
Message-ID: 

On Mon, Apr 29, 2013 at 6:14 PM, Mike Duigou  wrote:

> Looks reasonable to me. Could BlockingDeque::push() just use {@inheritDoc}
> for main body doc?
>
>
Perhaps.  But as I wrote many years ago in the same source file,

    /*
     * We have "diamond" multiple interface inheritance here, and that
     * introduces ambiguities.  Methods might end up with different
     * specs depending on the branch chosen by javadoc.  Thus a lot of
     * methods specs here are copied from superinterfaces.
     */

We found that @inheritDoc is far too often not *exactly* what we wanted.


From mike.duigou at oracle.com  Tue Apr 30 01:54:19 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 29 Apr 2013 18:54:19 -0700
Subject: RFR : 7129185 : Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
Message-ID: 

Hello all;

This is a non-integration code review. I am picking this patch up after ignoring it for most of the last year. I've recently expanded the regression tests to, I believe, handle almost all of the new code paths added by this patch.

http://cr.openjdk.java.net/~mduigou/JDK-7129185/0/webrev/

This issue is a follow-on to JDK-4533691 which added emptySortedSet(). In addition to adding support for NavigableSet/Map this patch also corrects differences between the behaviour of:

Set uts = Collections.unmodifiableNavigableSet(new TreeSet())

and 

Set es = Collections.emptyNavigableSet()

involving bounded sub-ranges. At this point I believe that "uts" and "es" will be operationally indistinguishable. emptyNavigableSet() will still be more efficient though as it is a singleton and doesn't generally(*) consume additional resources for each instance. The asterisk next to generally comes from the bounded sub-ranges functionality. Sub ranges of empty SortedSet and NavigableSet will no longer be the singleton. They are instead instances which capture the range.

Because so much time has passed since this issue originally surfaced I'm concerned that I might be forgetting something. I do know that I still need to create an EmptyNavigableMap unit test and add serialversionid to all the new classes but does anything else seem to be missing either in terms of the implementation or the tests?

Mike

From mike.duigou at oracle.com  Tue Apr 30 02:11:56 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 29 Apr 2013 19:11:56 -0700
Subject: RFR: 8011814/8013271/8013272: Three improvements to J2SE Netbeans
	project
Message-ID: <5867A704-95D9-4D38-AA10-78CE8CD7C1FE@oracle.com>

Hello All;

This is a review for three changes to the J2SE Netbeans project. If necessary I can break this up into three separate patches but I would rather not if possible.


http://cr.openjdk.java.net/~mduigou/JDK-8011814/0/webrev/


8011814: Add testng.jar to Netbeans projects test compile classpath

An increasing number of jtreg tests now use TestNG. This change adds the TestNG jar from you JTReg installation to the tests classpath. The location of JTReg is specified in build.properties using jtreg.home or from the environment via JT_HOME.


8013271: Add OS X sources to J2SE Netbeans project

Adds as source entry for Apple OS X sources to match the Unix and Windows entries. I checked the trademark with the Apple Trademarks page to make sure I got it correct.


8013272: JDK Netbeans projects should use ASCII encoding for sources

The build scripts compile all OpenJDK java sources using the US-ASCII encoding. This change causes Netbeans to respect this encoding. Whether US-ASCII is the awesomest encoding is certainly debatable, but all editors and IDEs should use what the compiler uses.


Thanks for reviewing,

Mike

From mike.duigou at oracle.com  Tue Apr 30 04:30:00 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 29 Apr 2013 21:30:00 -0700
Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to String(char[],
	boolean) constructor
Message-ID: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>

Hello all;

This change originated as part of JDK-8006627 (which was also previously split into JDK-8007398 as well). It adds an internal mechanism for performance sensitive usages to create a string from a provided character array without copying that array. This saves both in the allocation (and subsequent GC) as well as the copying of the characters. There are a few places in the JDK that return Strings which can benefit from this change.

http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/

Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it would be to get this change in to allow other potential users to move forward with their changes.

Mike

From mandy.chung at oracle.com  Tue Apr 30 05:05:30 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 29 Apr 2013 22:05:30 -0700
Subject: 8013531: Provide a utility class in com.sun.tools.classfile to find
	field/method references
Message-ID: <517F511A.9040808@oracle.com>

test/sun/reflect/CallerSensitive/MethodFinder.java is a useful utility 
class that jdeps or other tool can take advantage of. This fix moves 
MethodFinder.java to com.sun.tools.classfile and generalize it to find 
field, method, and interface method references.

Webrev at:
    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8013531/

thanks
Mandy


From mike.duigou at oracle.com  Tue Apr 30 05:11:29 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 30 Apr 2013 05:11:29 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130430051152.A55A2486CD@hg.openjdk.java.net>

Changeset: 7857129859bd
Author:    briangoetz
Date:      2013-04-20 18:53 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7857129859bd

8012650: Arrays streams methods
8011918: java.util.stream.Streams
Reviewed-by: alanb, mduigou, darcy, henryjen
Contributed-by: brian.goetz at oracle.com, paul.sandoz at oracle.com

! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java
+ src/share/classes/java/util/stream/StreamBuilder.java
+ src/share/classes/java/util/stream/Streams.java
+ test/java/util/Arrays/SetAllTest.java

Changeset: 46ddd9d272b5
Author:    mduigou
Date:      2013-04-29 22:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46ddd9d272b5

8011917: Add java.util.stream.Collectors utilities
Reviewed-by: darcy, mduigou
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/stream/Collectors.java



From henry.jen at oracle.com  Tue Apr 30 05:17:54 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 29 Apr 2013 22:17:54 -0700
Subject: RFR JDK-8012645(2nd round): Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
Message-ID: <517F5402.2010205@oracle.com>

Hi,

Adapt feedback from the first round, updated webrev and specdiff can be
found at:

http://cr.openjdk.java.net/~henryjen/ccc/8012645.1/webrev
http://cr.openjdk.java.net/~henryjen/ccc/8012645.1/specdiff

Summary of change,
1. Javadoc change for ZipFile::stream
2. A inner class implements Enumeration and Iterator for
ZipEntry/JarEntry, and the stream is now not order-significant.
3. Added test case for close ZipFile and JarFile to throw
IllegalStateException.

Cheers,
Henry



From david.holmes at oracle.com  Tue Apr 30 06:38:33 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Apr 2013 16:38:33 +1000
Subject: REASSERT Code review request for 8012044: Give more information
	about self-suppression from Throwable.addSuppressed
In-Reply-To: <5178D835.4080302@oracle.com>
References: <51676122.4020802@oracle.com>
	,
	<516845EC.8090105@oracle.com>
	,
	<51685B97.5010507@oracle.com>
	
	<516B6799.1010206@oracle.com> <516EDC9A.4070207@oracle.com>
	<5175C21E.2040502@oracle.com> <51761B4E.8020205@oracle.com>
	<51762148.9080407@oracle.com> <5178D835.4080302@oracle.com>
Message-ID: <517F66E9.1090108@oracle.com>

Sorry this slipped through the cracks.

Looks good to me. (Don't know if you already pushed it :) )

David

On 25/04/2013 5:16 PM, Joe Darcy wrote:
> Hello,
>
> Responding to David's comment and some comments from Alan off-list, here
> is a variant which doesn't use suppressed exceptions in initCause, but
> still passes along some information:
>
>      http://cr.openjdk.java.net/~darcy/8012044.4
>
> Patch to Throwable:
>
> --- a/src/share/classes/java/lang/Throwable.java    Wed Apr 24 21:27:52
> 2013 +0000
> +++ b/src/share/classes/java/lang/Throwable.java    Thu Apr 25 00:15:32
> 2013 -0700
> @@ -453,9 +453,10 @@
>        */
>       public synchronized Throwable initCause(Throwable cause) {
>           if (this.cause != this)
> -            throw new IllegalStateException("Can't overwrite cause");
> +            throw new IllegalStateException("Can't overwrite cause with
> " +
> + Objects.toString(cause, "a null"), this);
>           if (cause == this)
> -            throw new IllegalArgumentException("Self-causation not
> permitted");
> +            throw new IllegalArgumentException("Self-causation not
> permitted", this);
>           this.cause = cause;
>           return this;
>       }
> @@ -1039,7 +1040,7 @@
>        */
>       public final synchronized void addSuppressed(Throwable exception) {
>           if (exception == this)
> -            throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
> +            throw new
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>
>           if (exception == null)
>               throw new NullPointerException(NULL_CAUSE_MESSAGE);
>
> Thanks,
>
> -Joe
>
> On 04/22/2013 10:51 PM, Joe Darcy wrote:
>> Hi David,
>>
>> On 04/22/2013 10:25 PM, David Holmes wrote:
>>> Hi Joe,
>>>
>>> On 23/04/2013 9:05 AM, Joseph Darcy wrote:
>>>> Hello,
>>>>
>>>> Just reasserting the request for a review of the latest version of this
>>>> patch:
>>>>
>>>>      http://cr.openjdk.java.net/~darcy/8012044.2
>>>>
>>>> I believe this version does an appropriate job of propagating exception
>>>> information when there is misuse of the methods on Throwable.
>>>
>>> I still find the use of addSuppressed in initCause to be
>>> questionable. Given:
>>>
>>>    catch(SomeException s) {
>>>       sharedException.initCause(s); // oops already has a cause
>>>       throw sharedException;
>>>    }
>>>
>>> then the ISE isn't suppressing 's', but replacing/suppressing
>>> sharedException in my view, as it is what would have been thrown had
>>> the ISE not occurred.
>>>
>>> I understand the desire to not lose sight of the fact that 's' was
>>> thrown, but this is really no different to a finally block losing the
>>> original exception info. (And fixing that was rejected when the
>>> suppression mechanism was added.)
>>
>> Project Coin discussions did note try-catch-finally and
>> try-with-resources were inconsistent on this point. While the
>> try-with-resources behavior is regarded as preferable, we thought it
>> would be too large a change to redefine the long-standing semantics of
>> try-catch-finally.
>>
>>>
>>> Anyway this isn't a "block" (not that such a thing exists), just a
>>> comment. The change isn't harmful and may be useful.
>>>
>>> Cheers,
>>> David
>>>
>>
>> Yes, I would describe the intention of this change as provding
>> programmers more information to debug when the methods are Throwable
>> and used improperly.
>>
>> Thanks,
>>
>> -Joe
>


From martinrb at google.com  Tue Apr 30 06:51:28 2013
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 29 Apr 2013 23:51:28 -0700
Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to
	String(char[], boolean) constructor
In-Reply-To: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
Message-ID: 

Looks good.  As a very small clarification, I might throw in a comma after
"created".


On Mon, Apr 29, 2013 at 9:30 PM, Mike Duigou  wrote:

> Hello all;
>
> This change originated as part of JDK-8006627 (which was also previously
> split into JDK-8007398 as well). It adds an internal mechanism for
> performance sensitive usages to create a string from a provided character
> array without copying that array. This saves both in the allocation (and
> subsequent GC) as well as the copying of the characters. There are a few
> places in the JDK that return Strings which can benefit from this change.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/
>
> Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it
> would be to get this change in to allow other potential users to move
> forward with their changes.
>
> Mike


From david.holmes at oracle.com  Tue Apr 30 07:08:11 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Apr 2013 17:08:11 +1000
Subject: RFR 8009581: Xpathexception does not honor initcause()
In-Reply-To: <517E7982.8060803@oracle.com>
References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com>
	<517E7982.8060803@oracle.com>
Message-ID: <517F6DDB.4020809@oracle.com>

On 29/04/2013 11:45 PM, Aleksej Efimov wrote:
> Alan,
> The XPathException class doesn't have any fields only methods (it had a
> 'cause' method, but it was deleted in suggested fix).

It had a cause field that was deleted not a method, hence the change to 
the serialized form that Alan is highlighting.

David
-----

And, as I can see,
> there is no need to control what information is saved or to append
> additional information to the serialization stream.
> So, I think the readObject/writeObject is not required here.
>
> -Aleksej
>
> On 04/24/2013 10:17 PM, Alan Bateman wrote:
>> On 24/04/2013 14:53, Aleksej Efimov wrote:
>>> Hi all,
>>>
>>> Can I have a reviews for the following change:
>>> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/
>>> 
>>>
>>> Summary:
>>> There is an erroneous behavior in 'initCause' method of
>>> javax.xml.xpath.XPathException class.
>>> Lets look at the following situation:
>>> XPathException is created with 'XPathException(String )' constructor
>>> and then the cause is initialized with 'initCause' method. Such
>>> initialization sequence of actions isn't restricted by XPathException
>>> [1] and Throwable [2] docs.
>>> After that a cause is retrieved by 'getCause()' method: this call
>>> returns incorrect cause = 'null'. It should return the same cause as
>>> was used in 'initCause'.  And this is the erroneous behavior.
>>>
>>> Suggested fix (with regression test) is applicable both for JDK 8 and 7.
>> Exceptions are serializable so I think this may require further
>> investigation to see if a readObject/writeObject is required.
>>
>> -Alan.
>


From Alan.Bateman at oracle.com  Tue Apr 30 07:32:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 08:32:50 +0100
Subject: RFR JDK-8012645(2nd round): Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517F5402.2010205@oracle.com>
References: <517F5402.2010205@oracle.com>
Message-ID: <517F73A2.5030301@oracle.com>

On 30/04/2013 06:17, Henry Jen wrote:
> Hi,
>
> Adapt feedback from the first round, updated webrev and specdiff can be
> found at:
>
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.1/webrev
> http://cr.openjdk.java.net/~henryjen/ccc/8012645.1/specdiff
>
> Summary of change,
> 1. Javadoc change for ZipFile::stream
> 2. A inner class implements Enumeration and Iterator for
> ZipEntry/JarEntry, and the stream is now not order-significant.
> 3. Added test case for close ZipFile and JarFile to throw
> IllegalStateException.
>
> Cheers,
> Henry
>
I see the inner classes are protected so they will leak into the API. 
The inner class is fine for ZipFile (assuming you change it to private 
or package-private). For JarFile then it might be simplest to just go 
back to what you had originally.

Otherwise looks okay to me.

-Alan


From Alan.Bateman at oracle.com  Tue Apr 30 07:33:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 08:33:50 +0100
Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to
	String(char[], boolean) constructor
In-Reply-To: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
Message-ID: <517F73DE.1020809@oracle.com>

On 30/04/2013 05:30, Mike Duigou wrote:
> Hello all;
>
> This change originated as part of JDK-8006627 (which was also previously split into JDK-8007398 as well). It adds an internal mechanism for performance sensitive usages to create a string from a provided character array without copying that array. This saves both in the allocation (and subsequent GC) as well as the copying of the characters. There are a few places in the JDK that return Strings which can benefit from this change.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/
>
> Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it would be to get this change in to allow other potential users to move forward with their changes.
>
> Mike
Looks good to me.

-Alan.


From Alan.Bateman at oracle.com  Tue Apr 30 07:48:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 08:48:45 +0100
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517EEEAE.1020502@oracle.com>
References: <517EEEAE.1020502@oracle.com>
Message-ID: <517F775D.3040203@oracle.com>

On 29/04/2013 23:05, Kumar Srinivasan wrote:
> Hi,
>
> Please review this fix which will enable profiles and embedded distros to
> eliminate the unpack200 binaries saving space, all this does is switch
> to the java implementation if the native one cannot be found.
>
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/
>
> Thanks
> Kumar
>
Looks okay to me too. So is David or Bob going to update 
profile-includes.txt to move libunpack from PROFILE_1_JRE_LIB_FILES to 
FULL_JRE_LIB_FILES in a follow up change?

-Alan.



From david.holmes at oracle.com  Tue Apr 30 07:55:49 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Apr 2013 17:55:49 +1000
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517EEEAE.1020502@oracle.com>
References: <517EEEAE.1020502@oracle.com>
Message-ID: <517F7905.8090503@oracle.com>

Hi Kumar,

On 30/04/2013 8:05 AM, Kumar Srinivasan wrote:
> Hi,
>
> Please review this fix which will enable profiles and embedded distros to
> eliminate the unpack200 binaries saving space, all this does is switch
> to the java implementation if the native one cannot be found.
>
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/

Minor nit: why the duplicate code instead of having only the unpack in 
the try-catch:

               } else {
+                 try {
                       (new NativeUnpack(this)).run(in0, out);
+                 } catch (UnsatisfiedLinkError ule) {
+                     // failover to java implementation
+                     (new DoUnpack()).run(in0, out);
                   }
                   in0.close();
                   Utils.markJarFile(out);
+             }

Thanks,
david

> Thanks
> Kumar
>


From david.holmes at oracle.com  Tue Apr 30 07:57:54 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Apr 2013 17:57:54 +1000
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517F775D.3040203@oracle.com>
References: <517EEEAE.1020502@oracle.com> <517F775D.3040203@oracle.com>
Message-ID: <517F7982.2020706@oracle.com>

On 30/04/2013 5:48 PM, Alan Bateman wrote:
> On 29/04/2013 23:05, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review this fix which will enable profiles and embedded distros to
>> eliminate the unpack200 binaries saving space, all this does is switch
>> to the java implementation if the native one cannot be found.
>>
>> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/
>>
>> Thanks
>> Kumar
>>
> Looks okay to me too. So is David or Bob going to update
> profile-includes.txt to move libunpack from PROFILE_1_JRE_LIB_FILES to
> FULL_JRE_LIB_FILES in a follow up change?

Carlos will be handling that - though he will need a sponsor for the 
push and I will be away this week.

It would have been preferable to me to not have split this into two but 
Kumar is obviously more comfortable dealing with this part and needs to 
get on with other things.

David

> -Alan.
>


From chris.hegarty at oracle.com  Tue Apr 30 08:15:46 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Apr 2013 09:15:46 +0100
Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to
	String(char[], boolean) constructor
In-Reply-To: <517F73DE.1020809@oracle.com>
References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
	<517F73DE.1020809@oracle.com>
Message-ID: <517F7DB2.2060501@oracle.com>

On 04/30/2013 08:33 AM, Alan Bateman wrote:
> On 30/04/2013 05:30, Mike Duigou wrote:
>> Hello all;
>>
>> This change originated as part of JDK-8006627 (which was also
>> previously split into JDK-8007398 as well). It adds an internal
>> mechanism for performance sensitive usages to create a string from a
>> provided character array without copying that array. This saves both
>> in the allocation (and subsequent GC) as well as the copying of the
>> characters. There are a few places in the JDK that return Strings
>> which can benefit from this change.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/
>>
>> Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it
>> would be to get this change in to allow other potential users to move
>> forward with their changes.
>>
>> Mike
> Looks good to me.

Yeap, look fine to me too.

-Chris.

>
> -Alan.


From paul.sandoz at oracle.com  Tue Apr 30 08:33:31 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Apr 2013 10:33:31 +0200
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <517ECCEF.2020200@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
Message-ID: 


On Apr 29, 2013, at 9:41 PM, Henry Jen  wrote:

> On 04/27/2013 08:01 AM, Alan Bateman wrote:
>> On 27/04/2013 00:08, Henry Jen wrote:
>>> Hi,
>>> 
>>> Please review webrev at
>>> 
>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>>> 
>>> The API doc in specdiff format is at
>>> 
>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>>> 
>>> Cheers,
>>> Henry
>> In the ZipFile spec it reads "Entries appear in the {@code Stream} in
>> the order they appear in the ZIP file" but I think the order of the
>> entries in the central directory and this may not be the same as the
>> order of the entries in the archive.
>> 
> 
> It is the order of enumeration of entries(), which I believe is the
> order of the entries in the central directory of a zip file.
> 
> After another thought, is the ordering actually meaningful or has any
> sort of benefit/guaranteed characteristics we should preserve?
> Otherwise, it is probably better to left out the ORDERED.
> 

ZipFile/JarFile entry enumeration/stream can have an encounter order if repeated traversal of the same zip file entries (for multiple program executions) will always encounter those entries in the same order.

Having an encounter order will ensure deterministic results when evaluating sequentially and in parallel. My expectation would be that entries of a zip file would have an encounter order.

So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)

Paul.

From staffan.larsen at oracle.com  Tue Apr 30 08:48:38 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 30 Apr 2013 08:48:38 +0000
Subject: hg: jdk8/tl/jdk: 8003671: [findbugs]
	sun.management.AgentConfigurationError.getParams() may expose
	internal representation by returning AgentConfigurationError.params
Message-ID: <20130430084913.1372B486D4@hg.openjdk.java.net>

Changeset: fff665e54df0
Author:    sla
Date:      2013-04-30 10:48 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fff665e54df0

8003671: [findbugs] sun.management.AgentConfigurationError.getParams() may expose internal representation by returning AgentConfigurationError.params
Reviewed-by: mchung, rbackman, jbachorik

! src/share/classes/sun/management/AgentConfigurationError.java



From sundararajan.athijegannathan at oracle.com  Tue Apr 30 08:52:18 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 30 Apr 2013 08:52:18 +0000
Subject: hg: jdk8/tl/nashorn: 21 new changesets
Message-ID: <20130430085234.07755486D5@hg.openjdk.java.net>

Changeset: 0547a1c76259
Author:    attila
Date:      2013-04-23 12:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0547a1c76259

8011065: Problems when script implements an interface with variadic methods
Reviewed-by: jlaskey, hannesw, sundar

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
+ test/src/jdk/nashorn/api/scripting/VariableArityTestInterface.java

Changeset: 32036918585d
Author:    attila
Date:      2013-04-23 16:48 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/32036918585d

8010731: Don't expose internal symbols to scripts
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java

Changeset: a6c53280343d
Author:    hannesw
Date:      2013-04-24 13:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a6c53280343d

8012334: ToUint32, ToInt32, and ToUint16 don't conform to spec
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeUint32Array.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
+ test/examples/int-micro.js
+ test/script/basic/JDK-8012334.js
+ test/script/basic/JDK-8012334.js.EXPECTED
! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java

Changeset: 3974ce844f17
Author:    hannesw
Date:      2013-04-24 13:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3974ce844f17

8012931: NativeDate.safeToString() throws RangeError for invalid date
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8012931.js
+ test/script/basic/JDK-8012931.js.EXPECTED

Changeset: e959c7969f3b
Author:    hannesw
Date:      2013-04-24 13:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e959c7969f3b

8008238: Labeled break in finally causes stack overflow in Node copy
Reviewed-by: lagergren, attila

+ test/script/basic/JDK-8008238.js

Changeset: c0a10bbf6752
Author:    jlaskey
Date:      2013-04-24 14:25 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c0a10bbf6752

8012251: jjs should support -fx option
Reviewed-by: sundar, attila, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
+ src/jdk/nashorn/internal/runtime/resources/fx/base.js
+ src/jdk/nashorn/internal/runtime/resources/fx/bootstrap.js
+ src/jdk/nashorn/internal/runtime/resources/fx/controls.js
+ src/jdk/nashorn/internal/runtime/resources/fx/fxml.js
+ src/jdk/nashorn/internal/runtime/resources/fx/graphics.js
+ src/jdk/nashorn/internal/runtime/resources/fx/media.js
+ src/jdk/nashorn/internal/runtime/resources/fx/swing.js
+ src/jdk/nashorn/internal/runtime/resources/fx/swt.js
+ src/jdk/nashorn/internal/runtime/resources/fx/web.js
! src/jdk/nashorn/tools/Shell.java
! tools/fxshell/jdk/nashorn/tools/FXShell.java

Changeset: 9ad1ebb44c86
Author:    hannesw
Date:      2013-04-25 14:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9ad1ebb44c86

8013131: Various compatibility issues in String.prototype.split()
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java
! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8013131.js
+ test/script/basic/JDK-8013131.js.EXPECTED

Changeset: ff1e4655a57f
Author:    attila
Date:      2013-04-25 14:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ff1e4655a57f

8013203: A collection of smaller speedups to compilation pipeline
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java

Changeset: fd0b969a6d07
Author:    attila
Date:      2013-04-25 15:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fd0b969a6d07

8013167: Vararg constructor not found
Reviewed-by: jlaskey, lagergren, sundar

! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java
! src/jdk/internal/dynalink/beans/StaticClassLinker.java
+ test/script/basic/JDK-8013167.js
+ test/script/basic/JDK-8013167.js.EXPECTED
+ test/src/jdk/nashorn/test/models/VarArgConstructor.java

Changeset: 215d9b042cb6
Author:    sundar
Date:      2013-04-26 12:17 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/215d9b042cb6

8013295: ScriptEngineTest.java fails with compilation error when running under jtreg
Reviewed-by: attila, hannesw

! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 7917ef020898
Author:    attila
Date:      2013-04-26 09:20 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7917ef020898

8013325: function named 'arguments' should set DEFINES_ARGUMENTS flag in its parent, not itself
Reviewed-by: hannesw, sundar

! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8013325.js
+ test/script/basic/JDK-8013325.js.EXPECTED

Changeset: 5c98cc846f92
Author:    jlaskey
Date:      2013-04-26 09:48 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5c98cc846f92

8013208: Octane performance regression
Reviewed-by: hannesw, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java

Changeset: b532eeab085f
Author:    sundar
Date:      2013-04-26 18:31 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b532eeab085f

8013337: Issues with Date.prototype's get, set functions
Reviewed-by: jlaskey, hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8013337.js
+ test/script/basic/JDK-8013337.js.EXPECTED

Changeset: c62144b08c65
Author:    hannesw
Date:      2013-04-26 17:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c62144b08c65

8006559: Octane:pdfjs leaks memory, runs slower iteration to iteration
Reviewed-by: attila, sundar, jlaskey

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java
! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java

Changeset: 241904013024
Author:    sundar
Date:      2013-04-26 22:29 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/241904013024

8013369: nashorn build failure with jdk8 b84
Reviewed-by: hannesw

! make/build-nasgen.xml

Changeset: ef4c1f3aa9ed
Author:    jlaskey
Date:      2013-04-26 15:13 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ef4c1f3aa9ed

8013360: Should be using JavaFX 8 classes for -fx support
Reviewed-by: hannesw, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/resources/fx/base.js
! src/jdk/nashorn/internal/runtime/resources/fx/controls.js
! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js
! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js
! src/jdk/nashorn/internal/runtime/resources/fx/media.js
! src/jdk/nashorn/internal/runtime/resources/fx/swing.js
! src/jdk/nashorn/internal/runtime/resources/fx/swt.js
! src/jdk/nashorn/internal/runtime/resources/fx/web.js

Changeset: e8d7298f29a1
Author:    attila
Date:      2013-04-29 13:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e8d7298f29a1

8013419: Streamline handling of with and eval
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java

Changeset: ada2ca9aeac5
Author:    sundar
Date:      2013-04-29 18:40 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ada2ca9aeac5

8013444: JSON.parse does not invoke "reviver" callback as per spec.
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/JSONFunctions.java
+ test/script/basic/JDK-8013444.js
+ test/script/basic/JDK-8013444.js.EXPECTED

Changeset: 630372cb8f2a
Author:    attila
Date:      2013-04-29 23:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/630372cb8f2a

8008814: Configurable ignore/warning/error behavior for function declaration as statement
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/parser/AbstractParser.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
+ test/script/basic/JDK-8008814-3.js
+ test/script/basic/JDK-8008814-3.js.EXPECTED
+ test/script/basic/JDK-8008814-4.js
+ test/script/basic/JDK-8008814-4.js.EXPECTED
+ test/script/error/JDK-8008814-1.js
+ test/script/error/JDK-8008814-1.js.EXPECTED
+ test/script/error/JDK-8008814-2.js
+ test/script/error/JDK-8008814-2.js.EXPECTED

Changeset: 3f339ab2d050
Author:    jlaskey
Date:      2013-04-29 21:38 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3f339ab2d050

Merge


Changeset: ad28f2b52b12
Author:    lagergren
Date:      2013-04-30 09:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ad28f2b52b12

8013533: Increase code coverage report for types and logging
Reviewed-by: hannesw, sundar

! src/jdk/nashorn/internal/codegen/types/BooleanType.java
! src/jdk/nashorn/internal/codegen/types/IntType.java
! src/jdk/nashorn/internal/codegen/types/LongType.java
! src/jdk/nashorn/internal/codegen/types/NumberType.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! test/script/error/JDK-8008814-1.js.EXPECTED
! test/script/error/JDK-8008814-2.js.EXPECTED
+ test/script/trusted/logcoverage.js
+ test/script/trusted/logcoverage.js.EXPECTED



From Alan.Bateman at oracle.com  Tue Apr 30 09:18:57 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 10:18:57 +0100
Subject: RFR: JDK-8008738 - Issue in
	com.sun.org.apache.xml.internal.serializer.Encodings
	causes some JCK tests to fail intermittently
In-Reply-To: <516C0A14.1080408@oracle.com>
References: <516C0A14.1080408@oracle.com>
Message-ID: <517F8C81.7030602@oracle.com>

On 15/04/2013 15:09, Daniel Fuchs wrote:
> Hi,
>
> This a fix for:
>
> JDK-8008738 - Issue in 
> com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK 
> tests to fail intermittently.
>
> 
>
I skimmed over the webrev and it looks reasonable to me.

In getWriter then I don't understand the "java 1.1.8" comment, I wonder 
if the catching of IAE should just be removed.

For jdk_other in the test Makefile then it might be simpler to just add 
javax/xml and drop the existing soap and ws directories. I suggest this 
because there are only a tiny number of JAXP and JAX-WS tests in the jdk 
repo and they are all run via the jdk_other target.

-Alan


From ivan.gerasimov at oracle.com  Tue Apr 30 11:41:13 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Apr 2013 15:41:13 +0400
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in special
	cases
Message-ID: <517FADD9.7030903@oracle.com>

Hello everybody!

Would you please review my proposal to change constructor of 
CopyOnWriteArraySet?
http://cr.openjdk.java.net/~dmeetry/8005953/webrev.0/ 


Currently, the body of the constructor is like this:
al = new CopyOnWriteArrayList();
al.addAllAbsent(c);

The addAllAbsent() function has O(c.length^2) complexity, so 
construction time quickly grows with the input size.
However, if we knew that c is a Set, we could construct the COWAS in 
linear time.
And if the c was known to be another COWAS, we could simply clone the 
underlying CopyOnWriteArrayList.

The webrew also includes a test I used to make sure nothing is broken.

Sincerely yours,
Ivan


From david.holmes at oracle.com  Tue Apr 30 11:45:37 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 30 Apr 2013 21:45:37 +1000
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in
	special cases
In-Reply-To: <517FADD9.7030903@oracle.com>
References: <517FADD9.7030903@oracle.com>
Message-ID: <517FAEE1.5020401@oracle.com>

Hi Ivan,

On 30/04/2013 9:41 PM, Ivan Gerasimov wrote:
> Hello everybody!
>
> Would you please review my proposal to change constructor of
> CopyOnWriteArraySet?

Has this been run past Doug Lea and JSR-166 (ex)EG yet? All 
java.util.concurrent updates have to be coordinated through Doug.

David
-----

> http://cr.openjdk.java.net/~dmeetry/8005953/webrev.0/
> 
>
> Currently, the body of the constructor is like this:
> al = new CopyOnWriteArrayList();
> al.addAllAbsent(c);
>
> The addAllAbsent() function has O(c.length^2) complexity, so
> construction time quickly grows with the input size.
> However, if we knew that c is a Set, we could construct the COWAS in
> linear time.
> And if the c was known to be another COWAS, we could simply clone the
> underlying CopyOnWriteArrayList.
>
> The webrew also includes a test I used to make sure nothing is broken.
>
> Sincerely yours,
> Ivan


From ivan.gerasimov at oracle.com  Tue Apr 30 11:49:48 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Apr 2013 15:49:48 +0400
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in
	special cases
In-Reply-To: <517FAEE1.5020401@oracle.com>
References: <517FADD9.7030903@oracle.com> <517FAEE1.5020401@oracle.com>
Message-ID: <517FAFDC.3090707@oracle.com>


On 30.04.2013 15:45, David Holmes wrote:
> Hi Ivan,
>
> On 30/04/2013 9:41 PM, Ivan Gerasimov wrote:
>> Hello everybody!
>>
>> Would you please review my proposal to change constructor of
>> CopyOnWriteArraySet?
>
> Has this been run past Doug Lea and JSR-166 (ex)EG yet? All 
> java.util.concurrent updates have to be coordinated through Doug.
>
I cc'ed the message to Doug Lea (just checked the sent box to make sure 
I did).
For some reasons I do not see his address in the message received 
through the list.

> David
> -----
>
>> http://cr.openjdk.java.net/~dmeetry/8005953/webrev.0/
>> 
>>
>> Currently, the body of the constructor is like this:
>> al = new CopyOnWriteArrayList();
>> al.addAllAbsent(c);
>>
>> The addAllAbsent() function has O(c.length^2) complexity, so
>> construction time quickly grows with the input size.
>> However, if we knew that c is a Set, we could construct the COWAS in
>> linear time.
>> And if the c was known to be another COWAS, we could simply clone the
>> underlying CopyOnWriteArrayList.
>>
>> The webrew also includes a test I used to make sure nothing is broken.
>>
>> Sincerely yours,
>> Ivan
>
>



From jason_mehrens at hotmail.com  Tue Apr 30 12:55:22 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 30 Apr 2013 07:55:22 -0500
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in
	special cases
In-Reply-To: <517FADD9.7030903@oracle.com>
References: <517FADD9.7030903@oracle.com>
Message-ID: 

Ivan,

> The addAllAbsent() function has O(c.length^2) complexity, so
> construction time quickly grows with the input size.
> However, if we knew that c is a Set, we could construct the COWAS in
> linear time.

You have to be able to prove that the given Set uses the same equivalence relation as the COWAS.  Otherwise, it will fall apart you pass a SortedSet with a Comparator or an identity set.

> And if the c was known to be another COWAS, we could simply clone the
> underlying CopyOnWriteArrayList.

That would be safe.

Jason 		 	   		  

From dl at cs.oswego.edu  Tue Apr 30 13:24:22 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 30 Apr 2013 09:24:22 -0400
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in
	special cases
In-Reply-To: <517FAFDC.3090707@oracle.com>
References: <517FADD9.7030903@oracle.com> <517FAEE1.5020401@oracle.com>
	<517FAFDC.3090707@oracle.com>
Message-ID: <517FC606.1060308@cs.oswego.edu>

On 04/30/13 07:49, Ivan Gerasimov wrote:
>
> On 30.04.2013 15:45, David Holmes wrote:
>> Hi Ivan,
>>
>> On 30/04/2013 9:41 PM, Ivan Gerasimov wrote:
>>>
>>> Would you please review my proposal to change constructor of
>>> CopyOnWriteArraySet?
>>
>> Has this been run past Doug Lea and JSR-166 (ex)EG yet? All
>> java.util.concurrent updates have to be coordinated through Doug.

CopyOnWriteArrayList is in need of a bunch of resyncs across
jsr166, lambda, and tl/openjdk versions. I plan to integrate
these (including the Set constructor) sometime within the next
week.

-Doug


>>> http://cr.openjdk.java.net/~dmeetry/8005953/webrev.0/
>>> 
>>>



From ivan.gerasimov at oracle.com  Tue Apr 30 13:29:48 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Apr 2013 17:29:48 +0400
Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in
	special cases
In-Reply-To: 
References: <517FADD9.7030903@oracle.com>
	
Message-ID: <517FC74C.4000709@oracle.com>

Thanks, Jason!

>> The addAllAbsent() function has O(c.length^2) complexity, so
>> construction time quickly grows with the input size.
>> However, if we knew that c is a Set, we could construct the COWAS in
>> linear time.
> You have to be able to prove that the given Set uses the same equivalence relation as the COWAS.  Otherwise, it will fall apart you pass a SortedSet with a Comparator or an identity set.

I relied on what the documentation [1] says: "sets contain no pair of 
elements e1 and e2 such that e1.equals(e2)".
Further, [2] states: "the ordering maintained by a sorted set (whether 
or not an explicit comparator is provided) must be consistent with 
equals if the sorted set is to correctly implement the Set interface"

However you're right that if a class derived from Set is implemented 
inconsistently with equals (even though the documentation says it should 
not), the behavior of the constructor will change.

[1] http://docs.oracle.com/javase/7/docs/api/java/util/Set.html
[2] http://docs.oracle.com/javase/7/docs/api/java/util/SortedSet.html

Sincerely,
Ivan
>> And if the c was known to be another COWAS, we could simply clone the
>> underlying CopyOnWriteArrayList.
> That would be safe.
>
> Jason 		 	   		
>



From Alan.Bateman at oracle.com  Tue Apr 30 13:43:32 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 14:43:32 +0100
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517FC79D.7070704@Oracle.com>
References: <517F7982.2020706@oracle.com> <517FC79D.7070704@Oracle.com>
Message-ID: <517FCA84.6010200@oracle.com>

On 30/04/2013 14:31, Carlos Lucasius wrote:
> Webrev for my part of the fix to the code:
>
> http://cr.openjdk.java.net/~clucasius/8009389/webrev00/
>
> Thanks,
>
> -Carlos
Looks okay except that it would be good to maintain the ordering, ie: 
after t2k.

-Alan


From Lance.Andersen at oracle.com  Tue Apr 30 13:46:15 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 30 Apr 2013 09:46:15 -0400
Subject: RFR: 8011814/8013271/8013272: Three improvements to J2SE Netbeans
	project
In-Reply-To: <5867A704-95D9-4D38-AA10-78CE8CD7C1FE@oracle.com>
References: <5867A704-95D9-4D38-AA10-78CE8CD7C1FE@oracle.com>
Message-ID: <385FDE8A-5D15-45B2-9E34-C4AAC14494FE@oracle.com>

Hi Mike,

The changes look good to me.  

Best
Lance
On Apr 29, 2013, at 10:11 PM, Mike Duigou wrote:

> Hello All;
> 
> This is a review for three changes to the J2SE Netbeans project. If necessary I can break this up into three separate patches but I would rather not if possible.
> 
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8011814/0/webrev/
> 
> 
> 8011814: Add testng.jar to Netbeans projects test compile classpath
> 
> An increasing number of jtreg tests now use TestNG. This change adds the TestNG jar from you JTReg installation to the tests classpath. The location of JTReg is specified in build.properties using jtreg.home or from the environment via JT_HOME.
> 
> 
> 8013271: Add OS X sources to J2SE Netbeans project
> 
> Adds as source entry for Apple OS X sources to match the Unix and Windows entries. I checked the trademark with the Apple Trademarks page to make sure I got it correct.
> 
> 
> 8013272: JDK Netbeans projects should use ASCII encoding for sources
> 
> The build scripts compile all OpenJDK java sources using the US-ASCII encoding. This change causes Netbeans to respect this encoding. Whether US-ASCII is the awesomest encoding is certainly debatable, but all editors and IDEs should use what the compiler uses.
> 
> 
> Thanks for reviewing,
> 
> Mike

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From kumar.x.srinivasan at oracle.com  Tue Apr 30 14:04:28 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 30 Apr 2013 07:04:28 -0700
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517F7905.8090503@oracle.com>
References: <517EEEAE.1020502@oracle.com> <517F7905.8090503@oracle.com>
Message-ID: <517FCF6C.2070909@oracle.com>

Hi David,
Good point, I have made the changes, here is the updated webrev:

http://cr.openjdk.java.net/~ksrini/8009389/webrev.1/

delta webrev to last change:
http://cr.openjdk.java.net/~ksrini/8009389/webrev.1/webrev.delta/index.html

Thanks
Kumar

> Hi Kumar,
>
> On 30/04/2013 8:05 AM, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review this fix which will enable profiles and embedded 
>> distros to
>> eliminate the unpack200 binaries saving space, all this does is switch
>> to the java implementation if the native one cannot be found.
>>
>> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/
>
> Minor nit: why the duplicate code instead of having only the unpack in 
> the try-catch:
>
>               } else {
> +                 try {
>                       (new NativeUnpack(this)).run(in0, out);
> +                 } catch (UnsatisfiedLinkError ule) {
> +                     // failover to java implementation
> +                     (new DoUnpack()).run(in0, out);
>                   }
>                   in0.close();
>                   Utils.markJarFile(out);
> +             }
>
> Thanks,
> david
>
>> Thanks
>> Kumar
>>



From chris.hegarty at oracle.com  Tue Apr 30 14:23:48 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 30 Apr 2013 14:23:48 +0000
Subject: hg: jdk8/tl/jdk: 8007373: Inet6Address serialization incompatibility
Message-ID: <20130430142428.C726C486DD@hg.openjdk.java.net>

Changeset: 49d6596100db
Author:    msheppar
Date:      2013-04-29 23:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49d6596100db

8007373: Inet6Address serialization incompatibility
Reviewed-by: alanb, chegar

! src/share/classes/java/net/Inet6Address.java
+ test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java



From Alan.Bateman at oracle.com  Tue Apr 30 14:50:20 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 15:50:20 +0100
Subject: 8013531: Provide a utility class in com.sun.tools.classfile to
	find field/method references
In-Reply-To: <517F511A.9040808@oracle.com>
References: <517F511A.9040808@oracle.com>
Message-ID: <517FDA2C.3080003@oracle.com>

On 30/04/2013 06:05, Mandy Chung wrote:
> test/sun/reflect/CallerSensitive/MethodFinder.java is a useful utility 
> class that jdeps or other tool can take advantage of. This fix moves 
> MethodFinder.java to com.sun.tools.classfile and generalize it to find 
> field, method, and interface method references.
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8013531/
>
> thanks
> Mandy
This looks good to me.

A minor comment is that ReferenceFinder's ctor could uses 
Objects.requiresNonNull.

-Alan.


From thomas.schatzl at oracle.com  Tue Apr 30 14:57:20 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 16:57:20 +0200
Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in
	ReferenceHandler thread
Message-ID: <1367333840.2722.118.camel@cirrus>

Hi all,

  the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
presents a first stab at the CR "7038914: VM could throw uncaught OOME
in ReferenceHandler thread".

The problem is that under very heavy memory pressure, there is the
reference handler throws an exception with the message "Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
thread "Reference Handler".

The change improves handling of out-of-memory conditions in the
ReferenceHandler thread. Instead of crashing the thread, and then
disabling reference processing, it catches this exception and continues.

I'd like to discuss the change as I'm not really familiar with JDK
coding style, handling of such situations and have some questions about
it.

Bugs.sun
http://bugs.sun.com/view_bug.do?bug_id=7038914

JBS:
https://jbs.oracle.com/bugs/browse/JDK-7038914

Proposed webrev:
http://cr.openjdk.java.net/~tschatzl/7038914/webrev/

- first, I could not reliably reproduce the issue using the information
in the CR. Only via code review (and an idea from Bengt Rutisson -
thanks!) I implemented a nice way to reproduce an OOME in the reference
handler. This involves implementing a custom
java.lang.ref.ReferenceQueue and overriding the enqueue() method, and
doing some allocation that causes an OOME within that method.
My current theory is that synchronization/locking allocates some objects
on the java heap, which are very small, so an OOME in that thread can be
caused. I walked the locking code, but could not find a java heap
allocation there (ObjectMonitor seems to be a C heap object) - maybe I
overlooked it. Probably somebody else knows?
It cannot be the invocation of the Cleaner.clean() methods above the
enqueuing since it has it's own try-catch block already.
Anyway, since the reproducer I wrote shows the same symptoms as reported
in the CR, I hope that this test case is sufficient to be regarded as a
reproducer and the change as a fix.

- the actual change in java/lang/ref/Reference as mentioned involves
putting the entire main enqueuing procedure within a try-catch block.
It only catches OOME to decrease the possibility to catch anything that
should not be caught.
The problem is that this fix does not (and cannot) really fix bad
programming in anyone overriding java.lang.ref.ReferenceQueue.enqueue(),
i.e. if the OOME condition is before the actual execution of the
original enqueue() method, i.e. corruption of the queue may be still
possible.
On the other hand, since overriding ReferenceQueue.enqueue() requires
putting the custom ReferenceQueue into the boot class path, I assume
that people doing that are aware of possible issues.

- handling the OOME: in the catch block of the I put a block

                    // avoid crashing the reference handler thread,
                    // but provide for some diagnosability
                    assert false : e.toString();

to provide some diagnosability in the case of an exception (when
running with assertions). I copied that from other code that tries to
catch similar problems in the clean() method of the Cleaners. There are
other variants of managing this in the jdk, some involving calling
system.exit(). I thought that was too drastic, so I didn't do that, but
what is the appropriate way to handle this situation?

- if the use of locks or the synchronization keyword is indeed the
problem, I think it is possible to use nonblocking synchronization that
is known to not allocate any memory for managing the reference queues
instead. However I think to guard against misbehaving ReferenceQueue
implementations you'd still want to have a try-catch block here.

- is the location of the test correct? I.e. in the jdk
test/java/lang/ref directory? Or is the correct place for that the
hotspot test directories?

Since this is (seems to be) a JDK only change, and this is my first time
changing the JDK, I hope core-libs-dev is the right mailing list.
Otherwise please direct me to the the appropriate one.

Thanks,
Thomas



From mandy.chung at oracle.com  Tue Apr 30 15:04:48 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Apr 2013 08:04:48 -0700
Subject: 8013531: Provide a utility class in com.sun.tools.classfile to
	find field/method references
In-Reply-To: <517FDA2C.3080003@oracle.com>
References: <517F511A.9040808@oracle.com> <517FDA2C.3080003@oracle.com>
Message-ID: <517FDD90.5040909@oracle.com>


On 4/30/2013 7:50 AM, Alan Bateman wrote:
> On 30/04/2013 06:05, Mandy Chung wrote:
>> test/sun/reflect/CallerSensitive/MethodFinder.java is a useful 
>> utility class that jdeps or other tool can take advantage of. This 
>> fix moves MethodFinder.java to com.sun.tools.classfile and generalize 
>> it to find field, method, and interface method references.
>>
>> Webrev at:
>>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8013531/
>>
>> thanks
>> Mandy
> This looks good to me.
>
thanks.

> A minor comment is that ReferenceFinder's ctor could uses 
> Objects.requiresNonNull.
>

Will make the change before I push.  I was thinking to update that too :)

Mandy


From kumar.x.srinivasan at oracle.com  Tue Apr 30 15:17:53 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 30 Apr 2013 08:17:53 -0700
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517FCF6C.2070909@oracle.com>
References: <517EEEAE.1020502@oracle.com> <517F7905.8090503@oracle.com>
	<517FCF6C.2070909@oracle.com>
Message-ID: <517FE0A1.4090705@oracle.com>

Ok this also combines the build file changes.

http://cr.openjdk.java.net/~ksrini/8009389/webrev.2/

Thanks

Kumar

> Hi David,
> Good point, I have made the changes, here is the updated webrev:
>
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.1/
>
> delta webrev to last change:
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.1/webrev.delta/index.html 
>
>
> Thanks
> Kumar
>
>> Hi Kumar,
>>
>> On 30/04/2013 8:05 AM, Kumar Srinivasan wrote:
>>> Hi,
>>>
>>> Please review this fix which will enable profiles and embedded 
>>> distros to
>>> eliminate the unpack200 binaries saving space, all this does is switch
>>> to the java implementation if the native one cannot be found.
>>>
>>> http://cr.openjdk.java.net/~ksrini/8009389/webrev.0/
>>
>> Minor nit: why the duplicate code instead of having only the unpack 
>> in the try-catch:
>>
>>               } else {
>> +                 try {
>>                       (new NativeUnpack(this)).run(in0, out);
>> +                 } catch (UnsatisfiedLinkError ule) {
>> +                     // failover to java implementation
>> +                     (new DoUnpack()).run(in0, out);
>>                   }
>>                   in0.close();
>>                   Utils.markJarFile(out);
>> +             }
>>
>> Thanks,
>> david
>>
>>> Thanks
>>> Kumar
>>>
>



From Alan.Bateman at oracle.com  Tue Apr 30 15:27:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 16:27:37 +0100
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517FE0A1.4090705@oracle.com>
References: <517EEEAE.1020502@oracle.com> <517F7905.8090503@oracle.com>
	<517FCF6C.2070909@oracle.com> <517FE0A1.4090705@oracle.com>
Message-ID: <517FE2E9.7020603@oracle.com>

On 30/04/2013 16:17, Kumar Srinivasan wrote:
> Ok this also combines the build file changes.
>
> http://cr.openjdk.java.net/~ksrini/8009389/webrev.2/
>
> Thanks
>
> Kumar
Looks good to me.

-Alan.


From henry.jen at oracle.com  Tue Apr 30 15:43:42 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Apr 2013 08:43:42 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: 
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
Message-ID: <960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>


On Apr 30, 2013, at 1:33 AM, Paul Sandoz  wrote:

> 
> On Apr 29, 2013, at 9:41 PM, Henry Jen  wrote:
> 
>> On 04/27/2013 08:01 AM, Alan Bateman wrote:
>>> On 27/04/2013 00:08, Henry Jen wrote:
>>>> Hi,
>>>> 
>>>> Please review webrev at
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>>>> 
>>>> The API doc in specdiff format is at
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>>>> 
>>>> Cheers,
>>>> Henry
>>> In the ZipFile spec it reads "Entries appear in the {@code Stream} in
>>> the order they appear in the ZIP file" but I think the order of the
>>> entries in the central directory and this may not be the same as the
>>> order of the entries in the archive.
>>> 
>> 
>> It is the order of enumeration of entries(), which I believe is the
>> order of the entries in the central directory of a zip file.
>> 
>> After another thought, is the ordering actually meaningful or has any
>> sort of benefit/guaranteed characteristics we should preserve?
>> Otherwise, it is probably better to left out the ORDERED.
>> 
> 
> ZipFile/JarFile entry enumeration/stream can have an encounter order if repeated traversal of the same zip file entries (for multiple program executions) will always encounter those entries in the same order.
> 
> Having an encounter order will ensure deterministic results when evaluating sequentially and in parallel. My expectation would be that entries of a zip file would have an encounter order.
> 

Yes, any sequence has an encounter order, but is it significant and should be preserved is the question.

The repeatability of order is from the container,  if we have an implicit policy that such repeatability implies order, then we can add the ORDERED characteristic back.

In latest version, I removed the ORDERED because the order in the central directory is tool-dependent AFAIK, which I don't think worth preserving.

> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
> 

I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.
But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.

Cheers,
Henry



From Alan.Bateman at oracle.com  Tue Apr 30 15:44:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 16:44:42 +0100
Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in
	ReferenceHandler thread
In-Reply-To: <1367333840.2722.118.camel@cirrus>
References: <1367333840.2722.118.camel@cirrus>
Message-ID: <517FE6EA.6070907@oracle.com>

On 30/04/2013 15:57, Thomas Schatzl wrote:
> Hi all,
>
>    the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
> presents a first stab at the CR "7038914: VM could throw uncaught OOME
> in ReferenceHandler thread".
>
> The problem is that under very heavy memory pressure, there is the
> reference handler throws an exception with the message "Exception:
> java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
> thread "Reference Handler".
>
> The change improves handling of out-of-memory conditions in the
> ReferenceHandler thread. Instead of crashing the thread, and then
> disabling reference processing, it catches this exception and continues.
It's surprising to heard that the Reference Handler thread failed with 
OOME. I wouldn't expect anything in this code path to throw OOME, except 
maybe in fast-path for sun.misc.Cleaner but that will abort the VM be it 
fails. The enqueue method that you override in the test to provoke this 
is package-private so it's unlikely that the test or whatever that 
resulted in this bug report is doing that.

So I'm again this proposed change, rather I'm just trying to understand 
how it happened. Is there instrumentation involved by any chance? It the 
OOME something other than "java heap" or do we know?

-Alan.


From bob.vandette at oracle.com  Tue Apr 30 15:48:01 2013
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 30 Apr 2013 11:48:01 -0400
Subject: RFR: 8009389: Unpack200 native library should be removed from
	profiles
In-Reply-To: <517FE2E9.7020603@oracle.com>
References: <517EEEAE.1020502@oracle.com> <517F7905.8090503@oracle.com>
	<517FCF6C.2070909@oracle.com> <517FE0A1.4090705@oracle.com>
	<517FE2E9.7020603@oracle.com>
Message-ID: <58BECD8C-73BE-469E-A9E5-D964C42182ED@oracle.com>

Me too.

Bob.

On Apr 30, 2013, at 11:27 AM, Alan Bateman wrote:

> On 30/04/2013 16:17, Kumar Srinivasan wrote:
>> Ok this also combines the build file changes.
>> 
>> http://cr.openjdk.java.net/~ksrini/8009389/webrev.2/
>> 
>> Thanks
>> 
>> Kumar
> Looks good to me.
> 
> -Alan.



From frederic.parain at oracle.com  Tue Apr 30 16:26:42 2013
From: frederic.parain at oracle.com (frederic parain)
Date: Tue, 30 Apr 2013 18:26:42 +0200
Subject: RFR: 7150256/8004095: Add back Remote Diagnostic Commands
Message-ID: <517FF0C2.4040208@oracle.com>

Hi all,

This is a second request for review to add back
Remote Diagnostic Commands.

This work adds a new platform MBean providing
remote access to the diagnostic command framework
via JMX (already accessible locally with the jcmd
tool).

There's two CR number because this work is made of two
parts pushed to two different repositories.

JDK changeset CR 7150256
http://cr.openjdk.java.net/~fparain/7150256/webrev.06/

HotSpot changeset: CR 8004095
http://cr.openjdk.java.net/~fparain/8004095/webrev.06/

Questions from previous review have been answered
in initial review threads. Changesets also include
some minor changes coming from internal audit and
feedback sent in private e-mails.

However, one issue is still pending: some unit tests
use a hard coded port number, which could cause test
failures if several instances of the same test are
run on the same machine. I propose to postpone the
fix of this issue after the JDK8 feature freeze
(leaving for vacations soon, I won't have time to
fix tests before the feature freeze).

Thanks,

Fred

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From paul.sandoz at oracle.com  Tue Apr 30 16:35:13 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Apr 2013 18:35:13 +0200
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
Message-ID: <58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>

On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
> 
>> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
>> 
> 
> I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.

> But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.
> 

When you do the following what entry do you think should be returned?

  zipfile.entries().nextElement();

  zipfile.stream().findFirst();

  zipfile.stream().parallel().findFirst();

I would expect all entries to be equal and to be the first entry in the central directory. I would not expect the latter to be non-deterministic [*].

Or what about the following:

  List l = new ArrayList(); Enumeration e = zip file.entries(); 
  for(int i = 0; i < 10 & e.hasMoreElements(); i++) l.add(e.nextElement()); 
  List ss = zipfile.entries().limit(10).collect(toList());
  List sp = zipfile.entries().parallel().limit(10).collect(toList());

Should those lists be equal? Again i would expect so.

There does appear to be a well-defined encounter order. I don't think most developers will consider the collection of zip entries to behave like a Set. It is more list-like.

Paul.

[*] Note that our current implementation is deterministic, but that is because we don't currently check when doing a find first if the stream has no order and then defer to find any, which is a minor optimization we can enable.

From alexander.zuev at oracle.com  Tue Apr 30 16:38:05 2013
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Tue, 30 Apr 2013 20:38:05 +0400
Subject: RFR: 8013155: [pack200] improve performance of pack200
Message-ID: <517FF36D.7070102@oracle.com>

Please review this fix which by fine-tuning of just one method gives up 
to 40% performance
improvement on packing and repacking of jar files.
Also removed unneeded local variable initialization from Code class - 
not for performance gain,
just to make world a better place.

http://cr.openjdk.java.net/~kizune/8013155/webrev.00


From jim.gish at oracle.com  Tue Apr 30 16:48:36 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Tue, 30 Apr 2013 12:48:36 -0400
Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks
	Glassfish startup
Message-ID: <517FF5E4.6000105@oracle.com>

Please review http://cr.openjdk.java.net/~jgish/TestRB.2/ 


This fixes a regression caused by the removal of the search of the call 
stack for resource bundles by java.util.logging.  We have added a 
single-level search up the stack, i.e. just the immediate caller's 
ClassLoader, as an additional alternative to the specified method of 
using the thread context classloader if set and the system classloader 
if the TCCL is not set.  This is intended to handle cases such as 
Glassfish or other OSGi-based apps/3rd-party libs for which setting the 
TCCL is not feasible.

Thanks,
     Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From stevenschlansker at gmail.com  Tue Apr 30 17:01:11 2013
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 30 Apr 2013 10:01:11 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
Message-ID: <3E1D3509-023B-4B08-944C-F0356A619C18@gmail.com>


On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:

> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
>> 
>>> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
>>> 
>> 
>> I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.
> 
>> But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.
>> 
> 
> There does appear to be a well-defined encounter order. I don't think most developers will consider the collection of zip entries to behave like a Set. It is more list-like.

For what it's worth, as a random developer that has used Zip[Input,Output]Stream on occasion, I sometimes depend on the ordering property for application specific uses.  The most common is if you are taking a "hot backup" or "hot restore" of some sort of data structure, you would wish to ensure that data is written in / out in "data dependency order" so that you don't write references to data that has not been restored yet.

I am not sure that this is a good justification for keeping the stream ORDERED, but maybe it is.

Best,
Steven



From xueming.shen at oracle.com  Tue Apr 30 17:01:44 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Apr 2013 10:01:44 -0700
Subject: RFR JDK-8013254: Constructor \w need update to add the support of
	\p{Join_Control}
Message-ID: <517FF8F8.3080208@oracle.com>

Hi,

It appears we dropped the ball on u+200c and u+200d when we updated
the "simple word boundaries" back to jdk7 [1]. You can find most of the
related discussion here [2]. These 2 code points are listed as one of the
issues we were trying to fix but obviously the final doc and implementation
don't address them. Mainly because the \p{Join_Control} was not explicitly
listed in TR#18 "compatibility" section back then (the earlier version) [3],
though these 2 code points are explicitly mentioned at section RL1.4 Simple
Word Boundaries [4]. The \p{Join_Control} (u+200c and u+200d) has been
added/listed in the "compatibility" section in the latest version of TR#18 [5].

The proposed change here is to
(1) add these two code points back to the collection of \w
(2) list them explicitly into the \w definition as \p{Join_Control}
(3) list Join_Control as one of the supported binary properties.

http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html

The webrev for RegExTest.java above includes the change for 8013252
which is being reviewed as well, I'm not separating them out just for
convenience. The regression/unit tests may not that "direct", here is
a direct version to verify the fix.

         Matcher wordU = Pattern.compile("\\w", Pattern.UNICODE_CHARACTER_CLASS).matcher("");
         System.out.println(wordU.reset("\u200c").find());
         System.out.println(wordU.reset("\u200d").find());

thanks
-Sherman

[1] http://ccc.us.oracle.com/7039066
[2] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html
[3] http://www.unicode.org/reports/tr18/tr18-13.html#Compatibility_Properties
[4] http://www.unicode.org/reports/tr18/tr18-13.html#Simple_Word_Boundaries
[5] http://www.unicode.org/reports/tr18/#Compatibility_Properties


From martinrb at google.com  Tue Apr 30 18:11:50 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 30 Apr 2013 11:11:50 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
Message-ID: 

The order of entries in a zip file can be and is used by applications.
Notably, many people spend a lot of time optimizing the order of entries in
a zip file for performance reasons.  But it's also likely some people
depend on the order for correctness.  Whether or not your streams are
ORDERED, many people will need the ability to access the entries in a
sequential fashion.  Both ordered and non-ordered access may be useful.


On Tue, Apr 30, 2013 at 8:43 AM, Henry Jen  wrote:

>
> On Apr 30, 2013, at 1:33 AM, Paul Sandoz  wrote:
>
> >
> > On Apr 29, 2013, at 9:41 PM, Henry Jen  wrote:
> >
> >> On 04/27/2013 08:01 AM, Alan Bateman wrote:
> >>> On 27/04/2013 00:08, Henry Jen wrote:
> >>>> Hi,
> >>>>
> >>>> Please review webrev at
> >>>>
> >>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
> >>>>
> >>>> The API doc in specdiff format is at
> >>>>
> >>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
> >>>>
> >>>> Cheers,
> >>>> Henry
> >>> In the ZipFile spec it reads "Entries appear in the {@code Stream} in
> >>> the order they appear in the ZIP file" but I think the order of the
> >>> entries in the central directory and this may not be the same as the
> >>> order of the entries in the archive.
> >>>
> >>
> >> It is the order of enumeration of entries(), which I believe is the
> >> order of the entries in the central directory of a zip file.
> >>
> >> After another thought, is the ordering actually meaningful or has any
> >> sort of benefit/guaranteed characteristics we should preserve?
> >> Otherwise, it is probably better to left out the ORDERED.
> >>
> >
> > ZipFile/JarFile entry enumeration/stream can have an encounter order if
> repeated traversal of the same zip file entries (for multiple program
> executions) will always encounter those entries in the same order.
> >
> > Having an encounter order will ensure deterministic results when
> evaluating sequentially and in parallel. My expectation would be that
> entries of a zip file would have an encounter order.
> >
>
> Yes, any sequence has an encounter order, but is it significant and should
> be preserved is the question.
>
> The repeatability of order is from the container,  if we have an implicit
> policy that such repeatability implies order, then we can add the ORDERED
> characteristic back.
>
> In latest version, I removed the ORDERED because the order in the central
> directory is tool-dependent AFAIK, which I don't think worth preserving.
>
> > So if possible we should report ORDERED and state the association, if
> any, of encounter order with the order declared in the central directory,
> which i hope is, and seems to be, the same. (Plus update the docs of
> entries() too.)
> >
>
> I agree with you entries() and streams() should be in sync on ordering.
> Spec-wise, I have no clear preference.
> But when I looked into a zip file archive, I always would like to see
> entries in alphabetic order so I can find the files I really care, which
> will also have directory structure nicely. Order in central directory not
> necessary helping me.
>
> Cheers,
> Henry
>
>


From kumar.x.srinivasan at oracle.com  Tue Apr 30 18:32:38 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 30 Apr 2013 11:32:38 -0700
Subject: RFR: 8013155: [pack200] improve performance of pack200
In-Reply-To: <517FF36D.7070102@oracle.com>
References: <517FF36D.7070102@oracle.com>
Message-ID: <51800E46.6000301@oracle.com>

Hi Alex,

Great job identifying this hot method.  I realize the code is 
complicated but optimized
for speed.

Couple of nits:
I don't think you need the parens

j = (nextsemi < nextangl ? nextsemi : nextangl);

Coding conventions nits:
missing spaces for operators.

for (int i = firstl+1, j; i > 0; i = sig.indexOf('L', j)+1) {

I take it all the regression tests have been run ? in 
jdk/test/tools/pack200.

Thanks
Kumar


> Please review this fix which by fine-tuning of just one method gives 
> up to 40% performance
> improvement on packing and repacking of jar files.
> Also removed unneeded local variable initialization from Code class - 
> not for performance gain,
> just to make world a better place.
>
> http://cr.openjdk.java.net/~kizune/8013155/webrev.00



From lance.andersen at oracle.com  Tue Apr 30 18:45:43 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 30 Apr 2013 18:45:43 +0000
Subject: hg: jdk8/tl/jdk: 8010416: Add a way for java.sql.Driver to be
	notified when it is deregistered
Message-ID: <20130430184555.645AB486E4@hg.openjdk.java.net>

Changeset: ac3e189c9099
Author:    lancea
Date:      2013-04-30 14:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e189c9099

8010416: Add a way for java.sql.Driver to be notified when it is deregistered
Reviewed-by: alanb, ulfzibis

! src/share/classes/java/sql/Driver.java
+ src/share/classes/java/sql/DriverAction.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/SQLPermission.java



From mike.duigou at oracle.com  Tue Apr 30 18:57:36 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Apr 2013 11:57:36 -0700
Subject: RFR (S) CR 8006627/8007398: Improve performance of
	Long.toUnsignedString0, Integer.toUnsignedString0,
	UUID(String) and UUID.toString
In-Reply-To: 
References: 
	<84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com>
	<0EC036A3-3D11-4F56-B3FD-403CCC610347@gmail.com>
	
	
	<9251F945-7B88-484A-B38F-487A29D66F4D@oracle.com>
	<7DDE01A1-0845-4FE7-9454-958CC5F585FF@gmail.com>
	<9E63A0FB-47D8-4993-94DD-258ED9A4EDDA@oracle.com>
	<511AEB3C.6050309@CoSoCo.de>
	<0AA1CB21-D478-4FF5-A880-9B01E5052268@oracle.com>
	<511AF9B2.6060601@CoSoCo.de>
	<0D2150A5-DF5A-41CF-8405-C7D19959F3EC@oracle.com>
	
Message-ID: 

Finally some follow up on this!

On Feb 13 2013, at 23:43 , Martin Buchholz wrote:

> I like the optimizations in this change, especially the avoidance of copies. Was there some good reason the jdk never before used JavaLangAccess to avoid String creation copies?

Not that I am aware of. I did work on String and thereafter the idea occurred to me. Copying...we hates it.

>  I am tempted to micro-optimize this some more, e.g. specialize the hex printing code.  I might get rid of the digits table and compute ASCII characters simply:
> 
> ((i < 10) ? '0' : ('a' - 10)) + i

I wanted to play with JMH so used this as an excuse.

It turns out that using a calculation is a performance loser:

Benchmark                                   Thr    Cnt  Sec         Mean   Mean error          Var    Units
o.o.j.s.g.t.DigitsTableVsCalc.digitsCalc      1      8    1  8463376.310     2516.169  4136965.190  ops/sec
o.o.j.s.g.t.DigitsTableVsCalc.digitsTable     1      8    1 11838194.938     4936.538 15923812.479  ops/sec

The source of the benchmarks:

    @OutputTimeUnit(TimeUnit.SECONDS)
    @GenerateMicroBenchmark(BenchmarkType.OpsPerTimeUnit)
    public void digitsTable() throws InterruptedException {
        int end = testData.length;
        for (int each = 0; each < end; each++) {
            int i = testData[each];
            output[each] = digits[i];
        }
    }

    @OutputTimeUnit(TimeUnit.SECONDS)
    @GenerateMicroBenchmark(BenchmarkType.OpsPerTimeUnit)
    public void digitsCalc() throws InterruptedException {
        int end = testData.length;
        for (int each = 0; each < end; each++) {
            int i = testData[each];
            int base = i < 10 ? 48 : 87;
            output[each] = (char) (base + i);
        }
    }

Where testData is a 100 element static int array of random digit values (0-35).

> Why not formatUnsignedInt?

Now added and it seems to help.

> Why not make the new format methods public?

They seemed too specialized to me, particularly with the constraints on radix.

> 
> Is there a better name than createStringSharedChars?  We hope those chars will *not* be shared!  How about newStringUnsafe(char[] chars)
> 
> The spec for
> +    int formatUnsignedLong(long val, int shift, char[] buf, int offset, int len);
> should make it clearer whose responsibility getting the size right is.  It looks like the caller has to ensure there will be enough space, so perhaps the caller should just pass one offset instead of offset plus len.

Seems reasonable.

> +     * @return the lowest character  location used
> stray space

Corrected.

> 
> 
> On Wed, Feb 13, 2013 at 2:45 PM, Mike Duigou  wrote:
> I have updated the patch with some of Ulf's feedback and corrected one cut-and-paste error that I made.
> 
> The updated webrev is at:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8006627/2/webrev/
> 
> Mike
> 
> On Feb 12 2013, at 18:25 , Ulf Zibis wrote:
> 
> > Am 13.02.2013 02:34, schrieb Mike Duigou:
> >> Thank you for the comments Ulf.
> >>
> >> On Feb 12 2013, at 17:24 , Ulf Zibis wrote:
> >>
> >>> Am 13.02.2013 00:30, schrieb Mike Duigou:
> >>>> Hi Steven;
> >>>>
> >>>> I have updated the patch for Java 8. There's somewhat less code sharing and a bit of refactoring than your last version but the performance should be about the same or a little better.
> >>>>
> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/0/webrev/
> >>> Couldn't you use String(buf, true) for all to(Unsigned)String(...) methods ?
> >> Possibly. I didn't go looking too far with looking for additional improvements.
> >>
> >>> Instead of calculating the mask each time, you could use:
> >>> 309     private static String toUnsignedString(int i, int shift, int mask) {
> >> I think that would actually be inefficient. I haven't looked at the JITed code but the mask calculation is pretty cheap relative to parameter passing.
> >
> > I believe, JIT will inline the code, so there would be no parameter passing.
> >
> > Additionally the calculation of char count could be faster, if you would have short cuts like:
> > numberOfLeading2Zeros(i)
> > numberOfLeading4Zeros(i)
> > numberOfLeading8Zeros(i)
> > ...
> > So the optimum would be with separate toString methods:
> > String toBase2String(int i);
> > String toBase4String(int i);
> > String toBase8String(int i);
> > ...
> >
> > In any case I would save 2 lines:
> >
> > 311         int mag = Integer.SIZE - Long.numberOfLeadingZeros(i);
> > 312         int charCount = Math.max(((mag + (shift - 1)) / shift), 1);
> > 313         char[] buf = new char[charCount];
> > 316         int mask = (1 << shift) - 1;
> >
> > -Ulf
> >
> 
> 



From henry.jen at oracle.com  Tue Apr 30 19:02:11 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Apr 2013 12:02:11 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
Message-ID: <6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>

Point taken.

It seems to me we should at least keep the ORDERED characterristic for the returned stream, but not necessarily need to specify what order it is, which would be inline with entries().

Does that make sense?

I'll add back the ORDERED flag but keep the javadoc not mention ordering.

Cheers,
Henry

On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:

> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
>> 
>>> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
>>> 
>> 
>> I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.
> 
>> But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.
>> 
> 
> When you do the following what entry do you think should be returned?
> 
>  zipfile.entries().nextElement();
> 
>  zipfile.stream().findFirst();
> 
>  zipfile.stream().parallel().findFirst();
> 
> I would expect all entries to be equal and to be the first entry in the central directory. I would not expect the latter to be non-deterministic [*].
> 
> Or what about the following:
> 
>  List l = new ArrayList(); Enumeration e = zip file.entries(); 
>  for(int i = 0; i < 10 & e.hasMoreElements(); i++) l.add(e.nextElement()); 
>  List ss = zipfile.entries().limit(10).collect(toList());
>  List sp = zipfile.entries().parallel().limit(10).collect(toList());
> 
> Should those lists be equal? Again i would expect so.
> 
> There does appear to be a well-defined encounter order. I don't think most developers will consider the collection of zip entries to behave like a Set. It is more list-like.
> 
> Paul.
> 
> [*] Note that our current implementation is deterministic, but that is because we don't currently check when doing a find first if the stream has no order and then defer to find any, which is a minor optimization we can enable.



From mike.duigou at oracle.com  Tue Apr 30 19:33:36 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 30 Apr 2013 19:33:36 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130430193400.17ABB486E7@hg.openjdk.java.net>

Changeset: 0e6f412f5536
Author:    mduigou
Date:      2013-04-30 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e6f412f5536

8011814: Add testng.jar to Netbeans projects test compile classpath
8013271: Add MacOS sources to J2SE Netbeans project
8013272: JDK Netbeans projects should use ASCII encoding for sources
Reviewed-by: lancea

! make/netbeans/common/closed-share-sources.ent
! make/netbeans/common/demo-view.ent
! make/netbeans/common/java-data-native.ent
! make/netbeans/common/java-data-no-native.ent
! make/netbeans/common/jtreg-view.ent
+ make/netbeans/common/macosx-sources.ent
+ make/netbeans/common/macosx-view.ent
! make/netbeans/common/properties.ent
! make/netbeans/common/sample-view.ent
! make/netbeans/common/share-sources.ent
! make/netbeans/common/unix-sources.ent
! make/netbeans/common/windows-sources.ent
! make/netbeans/j2se/nbproject/project.xml
! make/netbeans/world/nbproject/project.xml

Changeset: 2fba6ae13ed8
Author:    mduigou
Date:      2013-04-30 12:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fba6ae13ed8

Merge




From paul.sandoz at oracle.com  Tue Apr 30 19:40:04 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Apr 2013 21:40:04 +0200
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: <6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
	<6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>
Message-ID: 

On Apr 30, 2013, at 9:02 PM, Henry Jen  wrote:

> Point taken.
> 
> It seems to me we should at least keep the ORDERED characterristic for the returned stream, but not necessarily need to specify what order it is, which would be inline with entries().
> 
> Does that make sense?
> 
> I'll add back the ORDERED flag but keep the javadoc not mention ordering.
> 

Is there any reason why we cannot mention the order is the same as the order declared in the central directory? 

Or is that considered an implementation detail? If so it seems like a feature to me we should call out. However, I don't really know much about the zip implementation to say much with confidence on this matter.

Paul.

> Cheers,
> Henry
> 
> On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:
> 
>> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
>>> 
>>>> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
>>>> 
>>> 
>>> I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.
>> 
>>> But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.
>>> 
>> 
>> When you do the following what entry do you think should be returned?
>> 
>> zipfile.entries().nextElement();
>> 
>> zipfile.stream().findFirst();
>> 
>> zipfile.stream().parallel().findFirst();
>> 
>> I would expect all entries to be equal and to be the first entry in the central directory. I would not expect the latter to be non-deterministic [*].
>> 
>> Or what about the following:
>> 
>> List l = new ArrayList(); Enumeration e = zip file.entries(); 
>> for(int i = 0; i < 10 & e.hasMoreElements(); i++) l.add(e.nextElement()); 
>> List ss = zipfile.entries().limit(10).collect(toList());
>> List sp = zipfile.entries().parallel().limit(10).collect(toList());
>> 
>> Should those lists be equal? Again i would expect so.
>> 
>> There does appear to be a well-defined encounter order. I don't think most developers will consider the collection of zip entries to behave like a Set. It is more list-like.
>> 
>> Paul.
>> 
>> [*] Note that our current implementation is deterministic, but that is because we don't currently check when doing a find first if the stream has no order and then defer to find any, which is a minor optimization we can enable.
> 



From mandy.chung at oracle.com  Tue Apr 30 19:43:14 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Apr 2013 12:43:14 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible
	by group name
In-Reply-To: <517EDE77.2050305@oracle.com>
References: <517EDE77.2050305@oracle.com>
Message-ID: <51801ED2.6060506@oracle.com>

Hi Sherman,

Looks okay in general.  A couple of comments:

Have you considered providing a method to map from group name to its 
group index?  Would that be useful?

group(String) can simply return group(getMatchedGroupIndex(name)) rather 
than duplicating the implementation.  Similarly for start(String) and 
end(String).  Is the performance overhead due to the extra check for 
(first < 0) and (group < 0 || group > groupCount()) the concern?  I

btw, start(int) and end(int) are missing the check if (group < 0).

Nit: -1 can be replaced with {@code -1}.

Mandy

On 4/29/13 1:56 PM, Xueming Shen wrote:
> Hi,
>
> The regex named capturing group support was added into jdk7 [1].
> Matcher.group(gname) is the only direct access method we added back then
> to access the matched result. The proposed change here is to add a 
> pair of
> accessing/convenient method Matcher.start/end(gname) to access the 
> start/end
> offset info of the matched result, to match the corresponding 
> start/end/group
> (int index) access methods.
>
> http://cr.openjdk.java.net/~sherman/8013252/webrev
>
> Thanks!
> -Sherman
>
> [1] http://cr.openjdk.java.net/~sherman/6350801/webrev.02/



From martinrb at google.com  Tue Apr 30 19:56:01 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 30 Apr 2013 12:56:01 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: 
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
	<6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>
	
Message-ID: 

In practice, the order of entries in the central directory is always the
same as the order of actual entries, although in theory they might be
different.  I think it would be useful to say that the entries are returned
in the order that they are stored in the zip file, and leave the central
directory order subtlety out of it.


On Tue, Apr 30, 2013 at 12:40 PM, Paul Sandoz wrote:

> On Apr 30, 2013, at 9:02 PM, Henry Jen  wrote:
>
> > Point taken.
> >
> > It seems to me we should at least keep the ORDERED characterristic for
> the returned stream, but not necessarily need to specify what order it is,
> which would be inline with entries().
> >
> > Does that make sense?
> >
> > I'll add back the ORDERED flag but keep the javadoc not mention ordering.
> >
>
> Is there any reason why we cannot mention the order is the same as the
> order declared in the central directory?
>
> Or is that considered an implementation detail? If so it seems like a
> feature to me we should call out. However, I don't really know much about
> the zip implementation to say much with confidence on this matter.
>
> Paul.
>
> > Cheers,
> > Henry
> >
> > On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:
> >
> >> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
> >>>
> >>>> So if possible we should report ORDERED and state the association, if
> any, of encounter order with the order declared in the central directory,
> which i hope is, and seems to be, the same. (Plus update the docs of
> entries() too.)
> >>>>
> >>>
> >>> I agree with you entries() and streams() should be in sync on
> ordering. Spec-wise, I have no clear preference.
> >>
> >>> But when I looked into a zip file archive, I always would like to see
> entries in alphabetic order so I can find the files I really care, which
> will also have directory structure nicely. Order in central directory not
> necessary helping me.
> >>>
> >>
> >> When you do the following what entry do you think should be returned?
> >>
> >> zipfile.entries().nextElement();
> >>
> >> zipfile.stream().findFirst();
> >>
> >> zipfile.stream().parallel().findFirst();
> >>
> >> I would expect all entries to be equal and to be the first entry in the
> central directory. I would not expect the latter to be non-deterministic
> [*].
> >>
> >> Or what about the following:
> >>
> >> List l = new ArrayList(); Enumeration e = zip file.entries();
> >> for(int i = 0; i < 10 & e.hasMoreElements(); i++)
> l.add(e.nextElement());
> >> List ss = zipfile.entries().limit(10).collect(toList());
> >> List sp = zipfile.entries().parallel().limit(10).collect(toList());
> >>
> >> Should those lists be equal? Again i would expect so.
> >>
> >> There does appear to be a well-defined encounter order. I don't think
> most developers will consider the collection of zip entries to behave like
> a Set. It is more list-like.
> >>
> >> Paul.
> >>
> >> [*] Note that our current implementation is deterministic, but that is
> because we don't currently check when doing a find first if the stream has
> no order and then defer to find any, which is a minor optimization we can
> enable.
> >
>
>


From alan.bateman at oracle.com  Tue Apr 30 20:21:17 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 30 Apr 2013 20:21:17 +0000
Subject: hg: jdk8/tl/jdk: 8013647: JPRT unable to clean-up after tests that
	leave file trees with loops
Message-ID: <20130430202128.E9D9F486EB@hg.openjdk.java.net>

Changeset: eda99449ab26
Author:    alanb
Date:      2013-04-30 21:19 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eda99449ab26

8013647: JPRT unable to clean-up after tests that leave file trees with loops
Reviewed-by: chegar, tbell

! test/java/nio/file/Files/walkFileTree/MaxDepth.java
! test/java/nio/file/Files/walkFileTree/SkipSiblings.java
! test/java/nio/file/Files/walkFileTree/SkipSubtree.java
! test/java/nio/file/Files/walkFileTree/TerminateWalk.java



From xueming.shen at oracle.com  Tue Apr 30 20:22:54 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Apr 2013 13:22:54 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible
	by group name
In-Reply-To: <51801ED2.6060506@oracle.com>
References: <517EDE77.2050305@oracle.com> <51801ED2.6060506@oracle.com>
Message-ID: <5180281E.70703@oracle.com>

On 04/30/2013 12:43 PM, Mandy Chung wrote:
> Hi Sherman,
>
> Looks okay in general.  A couple of comments:
>
> Have you considered providing a method to map from group name to its group index?  Would that be useful?
>

No plan for now. It appears a bit of redundant after we have the
start/end/group(name) in place, and you can use the "name" for
the replacement already, so there is pretty much no need to get
the "index" from the name after this change.

> group(String) can simply return group(getMatchedGroupIndex(name)) rather than duplicating the implementation.  Similarly for start(String) and end(String).  Is the performance overhead due to the extra check for (first < 0) and (group < 0 || group > groupCount()) the concern?

Yes, the "consolidation" will trigger two redundant/unnecessary (first <0) and
(group> groupCount()) checks and one layer more of method invocation. It
probably doesn't really matter though. But given it's a one-line code, I prefer
to keep it asis.

>
> btw, start(int) and end(int) are missing the check if (group < 0).
>

Guess the reason why the check was missing from the original
code is that the implementation will throw the specified anyway
when access the group array next line. Though group(int) does
check the boundary and throws with a "better" error message.
Updated with the <0 check.


> Nit: -1 can be replaced with {@code -1}.
>

The reason I did not do it is that the regex uses ...
and ... everywhere, it might be better to keep
the consistency here and wait for a complete replacement
someday. But since you pointed it out, updated to use the
new style.

updated webrev:
http://cr.openjdk.java.net/~sherman/8013252/webrev/

(again, the RegExTest.java is mixed with the change for
#8013254)

Thanks!
-Sherman


> Mandy
>
> On 4/29/13 1:56 PM, Xueming Shen wrote:
>> Hi,
>>
>> The regex named capturing group support was added into jdk7 [1].
>> Matcher.group(gname) is the only direct access method we added back then
>> to access the matched result. The proposed change here is to add a pair of
>> accessing/convenient method Matcher.start/end(gname) to access the start/end
>> offset info of the matched result, to match the corresponding start/end/group
>> (int index) access methods.
>>
>> http://cr.openjdk.java.net/~sherman/8013252/webrev
>>
>> Thanks!
>> -Sherman
>>
>> [1] http://cr.openjdk.java.net/~sherman/6350801/webrev.02/
>



From Alan.Bateman at oracle.com  Tue Apr 30 20:29:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 21:29:34 +0100
Subject: RFR: 8013380 - Removal of stack walk to find resource bundle
	breaks Glassfish startup
In-Reply-To: <517FF5E4.6000105@oracle.com>
References: <517FF5E4.6000105@oracle.com>
Message-ID: <518029AE.7080203@oracle.com>

On 30/04/2013 17:48, Jim Gish wrote:
> Please review http://cr.openjdk.java.net/~jgish/TestRB.2/ 
> 
>
> This fixes a regression caused by the removal of the search of the 
> call stack for resource bundles by java.util.logging.  We have added a 
> single-level search up the stack, i.e. just the immediate caller's 
> ClassLoader, as an additional alternative to the specified method of 
> using the thread context classloader if set and the system classloader 
> if the TCCL is not set.  This is intended to handle cases such as 
> Glassfish or other OSGi-based apps/3rd-party libs for which setting 
> the TCCL is not feasible.
It's unfortunate that the stack walk was masking this issue. Are you 
planning an update to the javadoc to reconcile the spec vs. impl difference?

-Alan.


From kumar.x.srinivasan at oracle.com  Tue Apr 30 20:14:00 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 30 Apr 2013 20:14:00 +0000
Subject: hg: jdk8/tl/jdk: 8009389: Unpack200 native library should be removed
	from profiles
Message-ID: <20130430201414.37845486EA@hg.openjdk.java.net>

Changeset: 1432a6247ac9
Author:    ksrini
Date:      2013-04-30 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1432a6247ac9

8009389: Unpack200 native library should be removed from profiles
Reviewed-by: alanb, bobv, jrose

! makefiles/profile-includes.txt
! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java



From henry.jen at oracle.com  Tue Apr 30 20:32:16 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 30 Apr 2013 13:32:16 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: 
References: <517B08E3.6060406@oracle.com> <517BE84E.3040600@oracle.com>
	<517ECCEF.2020200@oracle.com>
	
	<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>
	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>
	<6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>
	
	
Message-ID: 

That's what it was, but as Alan pointed out, it is potential misleading to people who knows detail about zip file.

I think the ordering is an implementation detail, and based on zip file spec, I would assume it's the order as in central directory.

I didn't dig down to the native code to confirm what ordering have been implemented, so my confidence level is at most be par with Paul. :)

Cheers,
Henry


On Apr 30, 2013, at 12:56 PM, Martin Buchholz  wrote:

> In practice, the order of entries in the central directory is always the
> same as the order of actual entries, although in theory they might be
> different.  I think it would be useful to say that the entries are returned
> in the order that they are stored in the zip file, and leave the central
> directory order subtlety out of it.
> 
> 
> On Tue, Apr 30, 2013 at 12:40 PM, Paul Sandoz wrote:
> 
>> On Apr 30, 2013, at 9:02 PM, Henry Jen  wrote:
>> 
>>> Point taken.
>>> 
>>> It seems to me we should at least keep the ORDERED characterristic for
>> the returned stream, but not necessarily need to specify what order it is,
>> which would be inline with entries().
>>> 
>>> Does that make sense?
>>> 
>>> I'll add back the ORDERED flag but keep the javadoc not mention ordering.
>>> 
>> 
>> Is there any reason why we cannot mention the order is the same as the
>> order declared in the central directory?
>> 
>> Or is that considered an implementation detail? If so it seems like a
>> feature to me we should call out. However, I don't really know much about
>> the zip implementation to say much with confidence on this matter.
>> 
>> Paul.
>> 
>>> Cheers,
>>> Henry
>>> 
>>> On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:
>>> 
>>>> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
>>>>> 
>>>>>> So if possible we should report ORDERED and state the association, if
>> any, of encounter order with the order declared in the central directory,
>> which i hope is, and seems to be, the same. (Plus update the docs of
>> entries() too.)
>>>>>> 
>>>>> 
>>>>> I agree with you entries() and streams() should be in sync on
>> ordering. Spec-wise, I have no clear preference.
>>>> 
>>>>> But when I looked into a zip file archive, I always would like to see
>> entries in alphabetic order so I can find the files I really care, which
>> will also have directory structure nicely. Order in central directory not
>> necessary helping me.
>>>>> 
>>>> 
>>>> When you do the following what entry do you think should be returned?
>>>> 
>>>> zipfile.entries().nextElement();
>>>> 
>>>> zipfile.stream().findFirst();
>>>> 
>>>> zipfile.stream().parallel().findFirst();
>>>> 
>>>> I would expect all entries to be equal and to be the first entry in the
>> central directory. I would not expect the latter to be non-deterministic
>> [*].
>>>> 
>>>> Or what about the following:
>>>> 
>>>> List l = new ArrayList(); Enumeration e = zip file.entries();
>>>> for(int i = 0; i < 10 & e.hasMoreElements(); i++)
>> l.add(e.nextElement());
>>>> List ss = zipfile.entries().limit(10).collect(toList());
>>>> List sp = zipfile.entries().parallel().limit(10).collect(toList());
>>>> 
>>>> Should those lists be equal? Again i would expect so.
>>>> 
>>>> There does appear to be a well-defined encounter order. I don't think
>> most developers will consider the collection of zip entries to behave like
>> a Set. It is more list-like.
>>>> 
>>>> Paul.
>>>> 
>>>> [*] Note that our current implementation is deterministic, but that is
>> because we don't currently check when doing a find first if the stream has
>> no order and then defer to find any, which is a minor optimization we can
>> enable.
>>> 
>> 
>> 



From mandy.chung at oracle.com  Tue Apr 30 20:58:05 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Apr 2013 13:58:05 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible
	by group name
In-Reply-To: <5180281E.70703@oracle.com>
References: <517EDE77.2050305@oracle.com> <51801ED2.6060506@oracle.com>
	<5180281E.70703@oracle.com>
Message-ID: <5180305D.3000503@oracle.com>

On 4/30/13 1:22 PM, Xueming Shen wrote:
> updated webrev:
> http://cr.openjdk.java.net/~sherman/8013252/webrev/
>
Looks good.
> (again, the RegExTest.java is mixed with the change for
> #8013254)
>

Are you going to separate the change in the right changeset?  I can't 
find the webrev for 8013254 from your mail [1].

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016522.html


From xueming.shen at oracle.com  Tue Apr 30 20:58:14 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Apr 2013 13:58:14 -0700
Subject: RFR JDK-8012645: Stream methods on BitSet, Random,
	ThreadLocalRandom, ZipFile
In-Reply-To: 
References: <517B08E3.6060406@oracle.com>
	<517BE84E.3040600@oracle.com>	<517ECCEF.2020200@oracle.com>		<960B41E9-7AA6-44FA-B798-073FED5508BD@oracle.com>	<58C4AF5D-A982-4EB4-B93F-5DE69C859601@oracle.com>	<6D4EA546-0B01-4B7E-B89B-DA00C1CF51CB@oracle.com>		
	
Message-ID: <51803066.4060202@oracle.com>

On 04/30/2013 01:32 PM, Henry Jen wrote:
> That's what it was, but as Alan pointed out, it is potential misleading to people who knows detail about zip file.
>
> I think the ordering is an implementation detail, and based on zip file spec, I would assume it's the order as in central directory.
>
> I didn't dig down to the native code to confirm what ordering have been implemented, so my confidence level is at most be par with Paul. :)
>

The order from the implementation is the entry's order in cen, the central directory.

-Sherman


> Cheers,
> Henry
>
>
> On Apr 30, 2013, at 12:56 PM, Martin Buchholz  wrote:
>
>> In practice, the order of entries in the central directory is always the
>> same as the order of actual entries, although in theory they might be
>> different.  I think it would be useful to say that the entries are returned
>> in the order that they are stored in the zip file, and leave the central
>> directory order subtlety out of it.
>>
>>
>> On Tue, Apr 30, 2013 at 12:40 PM, Paul Sandozwrote:
>>
>>> On Apr 30, 2013, at 9:02 PM, Henry Jen  wrote:
>>>
>>>> Point taken.
>>>>
>>>> It seems to me we should at least keep the ORDERED characterristic for
>>> the returned stream, but not necessarily need to specify what order it is,
>>> which would be inline with entries().
>>>> Does that make sense?
>>>>
>>>> I'll add back the ORDERED flag but keep the javadoc not mention ordering.
>>>>
>>> Is there any reason why we cannot mention the order is the same as the
>>> order declared in the central directory?
>>>
>>> Or is that considered an implementation detail? If so it seems like a
>>> feature to me we should call out. However, I don't really know much about
>>> the zip implementation to say much with confidence on this matter.
>>>
>>> Paul.
>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>> On Apr 30, 2013, at 9:35 AM, Paul Sandoz  wrote:
>>>>
>>>>> On Apr 30, 2013, at 5:43 PM, Henry Jen  wrote:
>>>>>>> So if possible we should report ORDERED and state the association, if
>>> any, of encounter order with the order declared in the central directory,
>>> which i hope is, and seems to be, the same. (Plus update the docs of
>>> entries() too.)
>>>>>> I agree with you entries() and streams() should be in sync on
>>> ordering. Spec-wise, I have no clear preference.
>>>>>> But when I looked into a zip file archive, I always would like to see
>>> entries in alphabetic order so I can find the files I really care, which
>>> will also have directory structure nicely. Order in central directory not
>>> necessary helping me.
>>>>> When you do the following what entry do you think should be returned?
>>>>>
>>>>> zipfile.entries().nextElement();
>>>>>
>>>>> zipfile.stream().findFirst();
>>>>>
>>>>> zipfile.stream().parallel().findFirst();
>>>>>
>>>>> I would expect all entries to be equal and to be the first entry in the
>>> central directory. I would not expect the latter to be non-deterministic
>>> [*].
>>>>> Or what about the following:
>>>>>
>>>>> List l = new ArrayList(); Enumeration e = zip file.entries();
>>>>> for(int i = 0; i<  10&  e.hasMoreElements(); i++)
>>> l.add(e.nextElement());
>>>>> List ss = zipfile.entries().limit(10).collect(toList());
>>>>> List sp = zipfile.entries().parallel().limit(10).collect(toList());
>>>>>
>>>>> Should those lists be equal? Again i would expect so.
>>>>>
>>>>> There does appear to be a well-defined encounter order. I don't think
>>> most developers will consider the collection of zip entries to behave like
>>> a Set. It is more list-like.
>>>>> Paul.
>>>>>
>>>>> [*] Note that our current implementation is deterministic, but that is
>>> because we don't currently check when doing a find first if the stream has
>>> no order and then defer to find any, which is a minor optimization we can
>>> enable.
>>>



From xueming.shen at oracle.com  Tue Apr 30 21:01:12 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Apr 2013 14:01:12 -0700
Subject: RFR JDK-8013254: Constructor \w need update to add the support
	of \p{Join_Control}
In-Reply-To: <517FF8F8.3080208@oracle.com>
References: <517FF8F8.3080208@oracle.com>
Message-ID: <51803118.1020407@oracle.com>

My apology, the webrev is at

http://cr.openjdk.java.net/~sherman/8013254/webrev/

-Sherman

On 04/30/2013 10:01 AM, Xueming Shen wrote:
> Hi,
>
> It appears we dropped the ball on u+200c and u+200d when we updated
> the "simple word boundaries" back to jdk7 [1]. You can find most of the
> related discussion here [2]. These 2 code points are listed as one of the
> issues we were trying to fix but obviously the final doc and implementation
> don't address them. Mainly because the \p{Join_Control} was not explicitly
> listed in TR#18 "compatibility" section back then (the earlier version) [3],
> though these 2 code points are explicitly mentioned at section RL1.4 Simple
> Word Boundaries [4]. The \p{Join_Control} (u+200c and u+200d) has been
> added/listed in the "compatibility" section in the latest version of TR#18 [5].
>
> The proposed change here is to
> (1) add these two code points back to the collection of \w
> (2) list them explicitly into the \w definition as \p{Join_Control}
> (3) list Join_Control as one of the supported binary properties.
>
> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html
>
> The webrev for RegExTest.java above includes the change for 8013252
> which is being reviewed as well, I'm not separating them out just for
> convenience. The regression/unit tests may not that "direct", here is
> a direct version to verify the fix.
>
>         Matcher wordU = Pattern.compile("\\w", Pattern.UNICODE_CHARACTER_CLASS).matcher("");
>         System.out.println(wordU.reset("\u200c").find());
>         System.out.println(wordU.reset("\u200d").find());
>
> thanks
> -Sherman
>
> [1] http://ccc.us.oracle.com/7039066
> [2] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000381.html
> [3] http://www.unicode.org/reports/tr18/tr18-13.html#Compatibility_Properties
> [4] http://www.unicode.org/reports/tr18/tr18-13.html#Simple_Word_Boundaries
> [5] http://www.unicode.org/reports/tr18/#Compatibility_Properties



From xueming.shen at oracle.com  Tue Apr 30 21:02:33 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Apr 2013 14:02:33 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible
	by group name
In-Reply-To: <5180305D.3000503@oracle.com>
References: <517EDE77.2050305@oracle.com> <51801ED2.6060506@oracle.com>
	<5180281E.70703@oracle.com> <5180305D.3000503@oracle.com>
Message-ID: <51803169.3070807@oracle.com>

On 04/30/2013 01:58 PM, Mandy Chung wrote:
> On 4/30/13 1:22 PM, Xueming Shen wrote:
>> updated webrev:
>> http://cr.openjdk.java.net/~sherman/8013252/webrev/
>>
> Looks good.
>> (again, the RegExTest.java is mixed with the change for
>> #8013254)
>>
>
> Are you going to separate the change in the right changeset?  I can't find the webrev for 8013254 from your mail [1].

My apology, a wrong copy/paste...here is the webrev, please help review
as well:-)

I'm planning to push them in one changeset, if both get approved.

http://cr.openjdk.java.net/~sherman/8013254/webrev/

-Sherman

>
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016522.html



From jim.gish at oracle.com  Tue Apr 30 21:10:51 2013
From: jim.gish at oracle.com (Jim Gish)
Date: Tue, 30 Apr 2013 17:10:51 -0400
Subject: RFR: 8013380 - Removal of stack walk to find resource bundle
	breaks Glassfish startup
In-Reply-To: <518029AE.7080203@oracle.com>
References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com>
Message-ID: <5180335B.4050302@oracle.com>


On 04/30/2013 04:29 PM, Alan Bateman wrote:
> On 30/04/2013 17:48, Jim Gish wrote:
>> Please review http://cr.openjdk.java.net/~jgish/TestRB.2/ 
>> 
>>
>> This fixes a regression caused by the removal of the search of the 
>> call stack for resource bundles by java.util.logging.  We have added 
>> a single-level search up the stack, i.e. just the immediate caller's 
>> ClassLoader, as an additional alternative to the specified method of 
>> using the thread context classloader if set and the system 
>> classloader if the TCCL is not set.  This is intended to handle cases 
>> such as Glassfish or other OSGi-based apps/3rd-party libs for which 
>> setting the TCCL is not feasible.
> It's unfortunate that the stack walk was masking this issue. Are you 
> planning an update to the javadoc to reconcile the spec vs. impl 
> difference?
>
Yes
> -Alan.

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From john.r.rose at oracle.com  Tue Apr 30 21:23:42 2013
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 30 Apr 2013 14:23:42 -0700
Subject: RFR: 8013155: [pack200] improve performance of pack200
In-Reply-To: <51800E46.6000301@oracle.com>
References: <517FF36D.7070102@oracle.com> <51800E46.6000301@oracle.com>
Message-ID: <96279A20-C059-485B-8409-EF0D1B07BCB1@oracle.com>

On Apr 30, 2013, at 11:32 AM, Kumar Srinivasan  wrote:

> Couple of nits:
> I don't think you need the parens
> 
> j = (nextsemi < nextangl ? nextsemi : nextangl);

I recommend (and many style guides recommend) adding extra parens in when the operator precedence is obscure.  In this case, assignment and ?: are competing for precedence, so the parens serve a purpose.  (At least they do for this reader of code.)

> Coding conventions nits:
> missing spaces for operators.
> 
> for (int i = firstl+1, j; i > 0; i = sig.indexOf('L', j)+1) {

I agree.

The old code was bad for two reasons:

1. It had a String.intern in it; those are usually a bottleneck
2. It looped over strings using String.charAt.

I'm kind of sad (as a JIT guy) that the optimizer didn't unwind all the charAt overhead.  The JIT works hard on array range checks but apparently it is not as effective on the explicitly coded range checks inside String.  We should watch that.  I filed a tracking bug:

  8013655: external loop over String characters has extra overhead

The new code avoids that overhead by using the canned loops in String.indexOf, which work on the naked array.

Thanks for tracking this down.

? John

From mandy.chung at oracle.com  Tue Apr 30 22:43:20 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 30 Apr 2013 22:43:20 +0000
Subject: hg: jdk8/tl/jdk: 8013531: Provide a utility class in
	com.sun.tools.classfile to find field/method references
Message-ID: <20130430224333.5E20648703@hg.openjdk.java.net>

Changeset: 4a82d2b86c75
Author:    mchung
Date:      2013-04-30 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a82d2b86c75

8013531: Provide a utility class in com.sun.tools.classfile to find field/method references
Reviewed-by: alanb

! test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java
- test/sun/reflect/CallerSensitive/MethodFinder.java
! test/sun/reflect/CallerSensitive/MissingCallerSensitive.java



From mandy.chung at oracle.com  Tue Apr 30 22:42:57 2013
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 30 Apr 2013 22:42:57 +0000
Subject: hg: jdk8/tl/langtools: 8013531: Provide a utility class in
	com.sun.tools.classfile to find field/method references
Message-ID: <20130430224300.5556248702@hg.openjdk.java.net>

Changeset: 57648bad3287
Author:    mchung
Date:      2013-04-30 15:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/57648bad3287

8013531: Provide a utility class in com.sun.tools.classfile to find field/method references
Reviewed-by: alanb

! src/share/classes/com/sun/tools/classfile/Dependencies.java
+ src/share/classes/com/sun/tools/classfile/ReferenceFinder.java



From mike.duigou at oracle.com  Tue Apr 30 22:45:11 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Apr 2013 15:45:11 -0700
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
Message-ID: 

Hello all;

Another changeset coming from the lambda libraries effort. This one is two small additions to the Objects class. The introduced methods are not really intended to be used directly, comparison operators work better in imperative logic, but the methods will be very useful as Predicates.

http://cr.openjdk.java.net/~mduigou/JDK-8013712/0/webrev/

Thanks,

Mike

From mark.reinhold at oracle.com  Tue Apr 30 23:00:31 2013
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 30 Apr 2013 16:00:31 -0700 (PDT)
Subject: JEP 185: JAXP 1.5: Restrict Fetching of External Resources
Message-ID: <20130430230031.1B3759E7@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/185

- Mark


From mandy.chung at oracle.com  Tue Apr 30 23:06:48 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 Apr 2013 16:06:48 -0700
Subject: RFR 8013252: Regex Matcher .start and .end should be accessible
	by group name
In-Reply-To: <51803169.3070807@oracle.com>
References: <517EDE77.2050305@oracle.com> <51801ED2.6060506@oracle.com>
	<5180281E.70703@oracle.com> <5180305D.3000503@oracle.com>
	<51803169.3070807@oracle.com>
Message-ID: <51804E88.40905@oracle.com>

On 4/30/13 2:02 PM, Xueming Shen wrote:
> I'm planning to push them in one changeset, if both get approved.
>
> http://cr.openjdk.java.net/~sherman/8013254/webrev/
>

These 2 bugs are not dependent on each other as I understand.  Is there 
a reason why you want to push them in one single changeset besides they 
both modify the RegExTest.java test?

I suggest you to push 8013252 as one changeset while I will review 
8013254 next.

Mandy




From mike.duigou at oracle.com  Tue Apr 30 23:31:29 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 30 Apr 2013 16:31:29 -0700
Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to
	String(char[], boolean) constructor
In-Reply-To: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com>
Message-ID: <2F3D8AF2-0C1C-4493-8F26-C347B321BA67@oracle.com>

Hello all;

Since this code will be introduced without any usages I decided it was critical to make a stand alone unit test. I've updated the webrev:

http://cr.openjdk.java.net/~mduigou/JDK-8013528/1/webrev/

The webrev mistakes my hg copy for a rename... Ignore that. Capturing the provenance of the test file probably isn't critical since the file is repurposed for a different test, but I prefer to have the origin tracked rather than use a non-vcs copy.

I also made the other changes suggested by reviewers.

Thanks

Mike

On Apr 29 2013, at 21:30 , Mike Duigou wrote:

> Hello all;
> 
> This change originated as part of JDK-8006627 (which was also previously split into JDK-8007398 as well). It adds an internal mechanism for performance sensitive usages to create a string from a provided character array without copying that array. This saves both in the allocation (and subsequent GC) as well as the copying of the characters. There are a few places in the JDK that return Strings which can benefit from this change.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/
> 
> Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it would be to get this change in to allow other potential users to move forward with their changes.
> 
> Mike