From jim.gish at oracle.com Wed May 1 00:13:17 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 30 Apr 2013 20:13:17 -0400 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <5180335B.4050302@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> Message-ID: <51805E1D.9060504@oracle.com> Here's an update: http://cr.openjdk.java.net/~jgish/TestRB.3/ Thanks, Jim On 04/30/2013 05:10 PM, Jim Gish wrote: > > 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 mandy.chung at oracle.com Wed May 1 03:34:14 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 30 Apr 2013 20:34:14 -0700 Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: References: Message-ID: <51808D36.9080101@oracle.com> On 4/30/2013 3:45 PM, Mike Duigou wrote: > 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/ This looks fine. Minor nit: s/null/{@code null} in the javadoc. It'd be good to add simple test cases to the existing test test/java/util/Objects/BasicObjectsTest.java for these 2 methods. Mandy From mike.duigou at oracle.com Wed May 1 03:37:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 30 Apr 2013 20:37:44 -0700 Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: <51808D36.9080101@oracle.com> References: <51808D36.9080101@oracle.com> Message-ID: I will make both suggested changes. Thank you. Mike On Apr 30 2013, at 20:34 , Mandy Chung wrote: > > On 4/30/2013 3:45 PM, Mike Duigou wrote: >> 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/ > > This looks fine. Minor nit: s/null/{@code null} in the javadoc. > > It'd be good to add simple test cases to the existing test test/java/util/Objects/BasicObjectsTest.java for these 2 methods. > > Mandy > From henry.jen at oracle.com Wed May 1 04:36:27 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 30 Apr 2013 21:36:27 -0700 Subject: RFR JDK-8003258: BufferedReader.lines() In-Reply-To: References: <517AF8D0.2020902@oracle.com> <517B893F.8030401@oracle.com> Message-ID: <51809BCB.4060609@oracle.com> On 04/29/2013 02:29 AM, Paul Sandoz wrote: > > 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() {} >>> >> 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. >> I hear you, I think this is a feature. As a BufferedReader, it is "Buffered", thus any read-ahead should probably happening with the buffer? It is probably desired to have optimized lines() method elsewhere, for example, one of such candidate would be Files::lines() although the initial implementation is based on BufferedReader::lines(). > > 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. > Right, this is a general characteristic of stream operation, there is no guarantee on how many element to be consumed. We do say when mixed API, it pick up from where it was left though. What do people think about following spec? Maybe we can remove the "Since..." for the mix API usage so we don't "set expectation" by calling it out. Or do you think we should actually remove most of the text base on the "readLine" implementation? > > /** > * Returns a {@code Stream}, the elements of which are lines read from this > * {@code BufferedReader}. The {@link Stream} is lazily populated via > * calls to {@link #readLine()}. > * > *

Each element consumed by the {@code Stream} caused a line to be > * read from this {@code BufferedReader}. Since the {@code Stream} does > * not necessarily consume all lines, it is possible to mix and use > * different read methods on a {@code BufferedReader}. Each method will > * simply pick up from where it was left on last read. > * > *

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 > * > *

Noted that some terminal stream operations make no guarantee how many > * element to be consumed. Therefore 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. > * > *

If an {@link IOException} is thrown when accessing the underlying > * {@code BufferedReader}, it is wrapped in an {@link > * UncheckedIOException} which will be thrown from the {@code Stream} > * method that caused the read to take place. For example, when trying to > * read from the {@code Stream} after the {@code BufferedReader} is > * closed, will throw an {@code UncheckedIOException}. Note that This > * method will return the {@code Stream} even if this {@code > * BufferedReader} is closed, but the operation cause reading will throw > * {@code UncheckedIOException}. > * > * @return a {@code Stream} providing the lines of text > * described by this {@code BufferedReader} > * > * @since 1.8 > */ > public Stream lines() {} Cheers, Henry From lana.steuck at oracle.com Wed May 1 04:45:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:09 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130501044512.1D61F4870F@hg.openjdk.java.net> Changeset: 4e3a881ebb1e Author: katleman Date: 2013-04-25 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e3a881ebb1e Added tag jdk8-b87 for changeset f1709874d55a ! .hgtags Changeset: ed59110eecdb Author: lana Date: 2013-04-30 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ed59110eecdb Merge From lana.steuck at oracle.com Wed May 1 04:45:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:09 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130501044513.8722C48710@hg.openjdk.java.net> Changeset: 40c107d1ae6f Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/40c107d1ae6f Added tag jdk8-b87 for changeset 774aeaa89bc1 ! .hgtags Changeset: 9fee4992f796 Author: lana Date: 2013-04-30 17:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9fee4992f796 Merge From lana.steuck at oracle.com Wed May 1 04:45:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:15 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130501044525.8E68248713@hg.openjdk.java.net> Changeset: a1e10f3adc47 Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a1e10f3adc47 Added tag jdk8-b87 for changeset 1329f9c38d93 ! .hgtags Changeset: 260013a710ef Author: lana Date: 2013-04-30 17:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/260013a710ef Merge From lana.steuck at oracle.com Wed May 1 04:45:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:11 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130501044521.730F748712@hg.openjdk.java.net> Changeset: 7122f7bb0fcc Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7122f7bb0fcc Added tag jdk8-b87 for changeset eddbc8ad2435 ! .hgtags Changeset: be5d6853d821 Author: lana Date: 2013-04-30 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/be5d6853d821 Merge From lana.steuck at oracle.com Wed May 1 04:45:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:09 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20130501044510.3ADDB4870E@hg.openjdk.java.net> Changeset: c29b583938b1 Author: katleman Date: 2013-04-25 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c29b583938b1 Added tag jdk8-b87 for changeset b9415faa7066 ! .hgtags Changeset: 1603c9216e83 Author: lana Date: 2013-04-30 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1603c9216e83 Merge From lana.steuck at oracle.com Wed May 1 04:45:10 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:10 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130501044520.3E54548711@hg.openjdk.java.net> Changeset: 72e03566f0a6 Author: katleman Date: 2013-04-23 18:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/72e03566f0a6 8012643: JDK8 b86 source with GPL header errors Reviewed-by: dholmes, alanb ! 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 Changeset: 24fa5452e5d4 Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/24fa5452e5d4 Added tag jdk8-b87 for changeset 72e03566f0a6 ! .hgtags From lana.steuck at oracle.com Wed May 1 04:45:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:20 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130501044600.6EA9A48714@hg.openjdk.java.net> Changeset: d5228e624826 Author: katleman Date: 2013-04-23 18:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5228e624826 8012643: JDK8 b86 source with GPL header errors Reviewed-by: dholmes, alanb ! test/java/lang/Runtime/exec/WinCommand.java ! test/java/lang/reflect/Method/DefaultMethodModeling.java Changeset: 53be90fb39d6 Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53be90fb39d6 Added tag jdk8-b87 for changeset d5228e624826 ! .hgtags Changeset: 4550ba263cbf Author: lana Date: 2013-04-30 17:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4550ba263cbf Merge From lana.steuck at oracle.com Wed May 1 04:45:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 01 May 2013 04:45:46 +0000 Subject: hg: jdk8/tl/hotspot: 52 new changesets Message-ID: <20130501044726.246F948715@hg.openjdk.java.net> Changeset: d080f5168deb Author: katleman Date: 2013-04-25 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d080f5168deb Added tag jdk8-b87 for changeset d4c266784660 ! .hgtags Changeset: c60f69931e1a Author: amurillo Date: 2013-04-11 21:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c60f69931e1a 8011949: new hotspot build - hs25-b29 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 35f8765422b9 Author: zgu Date: 2013-04-10 08:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35f8765422b9 8010151: nsk/regression/b6653214 fails "assert(snapshot != NULL) failed: Worker should not be started" Summary: Fixed a racing condition when shutting down NMT while worker thread is being started, also fixed a few mis-declared volatile pointers. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f2c0ccccc6b6 Author: rdurbin Date: 2013-04-16 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2c0ccccc6b6 Merge Changeset: 71013d764f6e Author: johnc Date: 2013-04-10 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71013d764f6e 8010780: G1: Eden occupancy/capacity output wrong after a full GC Summary: Move the calculation and recording of eden capacity to the start of a GC and print a detailed heap transition for full GCs. Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: c0000f77bc6d Author: johnc Date: 2013-04-11 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0000f77bc6d Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9aa8d8037ee3 Author: mgerdin Date: 2013-04-16 12:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9aa8d8037ee3 Merge ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: df254344edf1 Author: jmasa Date: 2013-04-01 10:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df254344edf1 8011173: NPG: Replace the ChunkList implementation with class FreeList Reviewed-by: mgerdin, tschatzl, johnc, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: f2e682ef3156 Author: johnc Date: 2013-04-17 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2e682ef3156 8012335: G1: Fix bug with compressed oops in template interpreter on x86 and sparc. Summary: In do_oop_store the uncompressed value of the oop being stored needs to be preserved and passed to g1_write_barrier_post. This is necessary for the heap region cross check to work correctly. Reviewed-by: coleenp, johnc Contributed-by: Martin Doerr ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 07a4efc5ed14 Author: brutisso Date: 2013-04-18 06:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/07a4efc5ed14 8012455: Missing time and date stamps for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime Summary: also reviewed by: kirk at kodewerk.com, brandon at twitter.com Reviewed-by: tschatzl, stefank, johnc ! src/share/vm/services/runtimeService.cpp Changeset: cbf8c8c25bbe Author: mgerdin Date: 2013-04-18 14:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbf8c8c25bbe Merge Changeset: aeaca88565e6 Author: jiangli Date: 2013-04-09 17:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aeaca88565e6 8010862: The Method counter fields used for profiling can be allocated lazily. Summary: Allocate the method's profiling related metadata until they are needed. Reviewed-by: coleenp, roland ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java + agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp + src/share/vm/oops/methodCounters.cpp + src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 42a42da29fd7 Author: jiangli Date: 2013-04-11 23:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42a42da29fd7 8012052: java/lang/invoke/6987555/Test6987555.java crashes with assert(mcs != NULL) failed: MethodCounters cannot be NULL. Summary: Skip counter decay if the MethodCounters is NULL in NonTieredCompPolicy::delay_compilation(). Reviewed-by: kvn, dholmes ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 8df6ddda8090 Author: jiangli Date: 2013-04-15 21:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8df6ddda8090 Merge ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 9500809ceead Author: jiangli Date: 2013-04-18 17:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9500809ceead Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: b8b081e53312 Author: twisti Date: 2013-04-12 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8b081e53312 8011933: add number of classes, methods and time spent to CompileTheWorld Reviewed-by: jrose, kvn ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 393fd4ef89c4 Author: twisti Date: 2013-04-12 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/393fd4ef89c4 8011678: test/Makefile should pick up JT_HOME environment variable Reviewed-by: kvn ! test/Makefile Changeset: f36e073d56a4 Author: drchase Date: 2013-04-12 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f36e073d56a4 7104565: trim jprt build targets Summary: remove JPRT debug builds, remove -DDEBUG -DFASTDEBUG and use ASSERT instead in sources Reviewed-by: dholmes, kvn, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/fastdebug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/fastdebug.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/fastdebug.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! make/windows/build.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/hsdis/Makefile ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: bc63dd2539a4 Author: kvn Date: 2013-04-12 20:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc63dd2539a4 Merge ! make/bsd/makefiles/debug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make ! make/linux/makefiles/debug.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make ! make/solaris/makefiles/debug.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make Changeset: 886d1fd67dc3 Author: drchase Date: 2013-04-12 19:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/886d1fd67dc3 6443505: Ideal() function for CmpLTMask Summary: Repair wrong code generation, added new matching rule Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/cfgnode.cpp + test/compiler/6443505/Test6443505.java Changeset: bb4a966cc68f Author: roland Date: 2013-04-15 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb4a966cc68f 8011582: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range Summary: c1 runtime's predicate_failed_trap should use jump_to on sparc Reviewed-by: kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 1c6887c9afaa Author: twisti Date: 2013-04-15 16:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c6887c9afaa 7172922: export_ makefile targets do not work unless all supported variants are built Reviewed-by: dholmes, kvn ! make/Makefile Changeset: acadb114c818 Author: roland Date: 2013-04-15 17:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acadb114c818 8011648: C1: optimized build is broken after 7153771 Summary: missing #ifdef ASSERT Reviewed-by: kvn ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! 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_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: b105029fdbfd Author: roland Date: 2013-04-15 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b105029fdbfd Merge Changeset: 8373c19be854 Author: neliasso Date: 2013-04-16 10:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8373c19be854 8011621: live_ranges_in_separate_class.patch Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c89eab0b6b30 Author: neliasso Date: 2013-04-16 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c89eab0b6b30 Merge - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 4b2eebe03f93 Author: iignatyev Date: 2013-04-16 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b2eebe03f93 8011971: WB API doesn't accept j.l.reflect.Constructor Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp ! 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: a7fb14888912 Author: neliasso Date: 2013-04-11 13:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7fb14888912 8006952: Slow VM due to excessive code cache freelist iteration Summary: Remove continous free block requirement Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/opto/output.cpp Changeset: dedc8563e33d Author: bharadwaj Date: 2013-04-18 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dedc8563e33d Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 2a9d97b57920 Author: bharadwaj Date: 2013-04-19 03:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a9d97b57920 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 01d5f04e64dc Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01d5f04e64dc Merge ! make/bsd/makefiles/fastdebug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 0491c26b1f1d Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0491c26b1f1d Added tag hs25-b29 for changeset 01d5f04e64dc ! .hgtags Changeset: f78763f49817 Author: amurillo Date: 2013-04-19 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f78763f49817 8012559: new hotspot build - hs25-b30 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63e31ce40bdb Author: hseigel Date: 2013-04-17 08:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63e31ce40bdb 8009928: PSR:PERF Increase default string table size Summary: Increase default string table size to 60013 for 64-bit platforms. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b80cc96882f7 Author: zgu Date: 2013-04-18 10:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b80cc96882f7 8012464: NMT: classes should not derive from _ValueObj, use VALUE_OBJ_CLASS_SPEC instead Summary: NMT value objects should use VALUE_OBJ_CLASS_SPEC instead of deriving from _ValueObj Reviewed-by: coleenp, hseigel, dholmes ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.hpp Changeset: 41ed397cc0cd Author: bharadwaj Date: 2013-04-18 08:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41ed397cc0cd 8006267: InterfaceMethod_ref should allow invokestatic and invokespecial Summary: Lambda changes; spec 0.6.2 - Allow static invokestatic and invokespecial calls to InterfaceMethod_ref Reviewed-by: dholmes, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp Changeset: 7815eaceaa8c Author: bharadwaj Date: 2013-04-18 14:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7815eaceaa8c Merge Changeset: 6f817ce50129 Author: minqi Date: 2013-04-19 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f817ce50129 8010992: Remove calls to global ::operator new[] and new Summary: disable use of global operator new and new[] which could cause unexpected exception and escape from NMT tracking. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 17c51f84773a Author: dcubed Date: 2013-04-19 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17c51f84773a Merge Changeset: 5b6512efcdc4 Author: dcubed Date: 2013-04-19 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b6512efcdc4 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6337ca4dcad8 Author: sspitsyn Date: 2013-04-20 04:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6337ca4dcad8 8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's Reviewed-by: coleenp, jrose, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a527ddd44e07 Author: mgronlun Date: 2013-04-20 19:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a527ddd44e07 6729929: I18N - Taking Heap Dump failed if project path contains multibyte characters Reviewed-by: dholmes, rbackman Contributed-by: peter.allwin at oracle.com ! src/share/vm/services/management.cpp Changeset: 5a9fa2ba85f0 Author: dcubed Date: 2013-04-21 20:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a9fa2ba85f0 8012907: anti-delta fix for 8010992 Summary: anti-delta fix for 8010992 until 8012902 can be fixed Reviewed-by: acorn, minqi, rdurbin ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: cc12becb22e7 Author: dcubed Date: 2013-04-21 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc12becb22e7 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce6d7e43501c Author: bharadwaj Date: 2013-04-23 08:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce6d7e43501c 8012961: Do not restrict static interface methods to be private Summary: Lambda changes; spec 0.6.2 - remove the restriction that was added as part of recent changes made to support upcoming changes to compilation of lambda methods. Reviewed-by: dholmes, acorn ! src/share/vm/prims/methodHandles.cpp Changeset: 1ea6a35dcbe5 Author: jiangli Date: 2013-04-23 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ea6a35dcbe5 8012927: 'assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range' in interpreter initialization. Summary: Change br_null_short() to br_null(). Reviewed-by: coleenp, hseigel ! src/cpu/sparc/vm/interp_masm_sparc.cpp Changeset: 35c15dad89ea Author: roland Date: 2013-04-16 17:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35c15dad89ea 8011901: Unsafe.getAndAddLong(obj, off, delta) does not work properly with long deltas Summary: instruct xaddL_no_res shouldn't allow 64 bit constants. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad + test/compiler/8011901/Test8011901.java Changeset: 6a3629cf7075 Author: roland Date: 2013-04-24 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a3629cf7075 8011771: runThese crashed with EAV Summary: Array bound check elimination's in block motion doesn't always reset its data structures from one step to the other. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_RangeCheckElimination.cpp Changeset: 47766e2d2527 Author: jiangli Date: 2013-04-24 18:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/47766e2d2527 8013041: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset. Summary: Change jmpb() to jmp(). Reviewed-by: coleenp, rdurbin, dcubed ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: e8a7a5995e65 Author: bharadwaj Date: 2013-04-25 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8a7a5995e65 Merge Changeset: c4af77d20454 Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4af77d20454 Merge ! .hgtags - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 8482058e74bc Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8482058e74bc Added tag hs25-b30 for changeset c4af77d20454 ! .hgtags From peter.levart at gmail.com Wed May 1 06:41:18 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 1 May 2013 08:41:18 +0200 Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to String(char[], boolean) constructor In-Reply-To: <2F3D8AF2-0C1C-4493-8F26-C347B321BA67@oracle.com> References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com> <2F3D8AF2-0C1C-4493-8F26-C347B321BA67@oracle.com> Message-ID: Hi Mike, Some comments about the test... 40 String benchmark = "exemplar"; 41 String constructorCopy = new String(benchmark); 42 String jlaCopy = jla.newStringUnsafe(benchmark.toCharArray()); 43 44 if (constructorCopy == constructorCopy) { 45 throw new Error("should be different instances"); 46 } Wouldn't this always throw error? You really wanted to test benchmark == constructorCopy, right? 47 if (!benchmark.equals(constructorCopy)) { 48 throw new Error("Copy not equal"); 49 } 50 if (0 != Objects.compare(benchmark, constructorCopy, Comparators.naturalOrder())) { 51 throw new Error("Copy not equal"); 52 } 53 54 if (benchmark == jlaCopy) { 55 throw new Error("should be different instances"); 56 } 57 if (!benchmark.equals(jlaCopy)) { 58 throw new Error("Copy not equal"); 59 } 60 if (0 != Objects.compare(benchmark, jlaCopy, Comparators.naturalOrder())) { 61 throw new Error("Copy not equal"); 62 } 63 64 if (constructorCopy == jlaCopy) { 65 throw new Error("should be different instances"); 66 } 67 if (!constructorCopy.equals(jlaCopy)) { 68 throw new Error("Copy not equal"); 69 } 70 if (0 != Objects.compare(constructorCopy, jlaCopy, Comparators.naturalOrder())) { 71 throw new Error("Copy not equal"); To check whether the jlaCopy is really taking the given char array by reference, a test could also do something "illegal" like: char[] array = benchmark.toCharArray(); String jlaCopy = jla.newStringUnsafe(array); array[0] = "X"; // ouch! String constructorCopy = new String(array); if (!constructorCopy.equals(jlaCopy)) { ... } Regards, Peter 2013/5/1 Mike Duigou > 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 > > From henry.jen at oracle.com Wed May 1 07:21:31 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 01 May 2013 00:21:31 -0700 Subject: RFR JDK-8012645(3rd round): Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile In-Reply-To: <517F73A2.5030301@oracle.com> References: <517F5402.2010205@oracle.com> <517F73A2.5030301@oracle.com> Message-ID: <5180C27B.1060900@oracle.com> On 04/30/2013 12:32 AM, Alan Bateman wrote: > On 30/04/2013 06:17, Henry Jen wrote: >> Hi, >> >> Adapt feedback from the first round, updated webrev and specdiff can be >> found at: >> >> >> 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. Please review http://cr.openjdk.java.net/~henryjen/ccc/8012645.2/webrev http://cr.openjdk.java.net/~henryjen/ccc/8012645.2/specdiff - Fix the inner class. - Add back the order for ZipFile.stream() and spec the order to be as appears in the central directory of the zip file. Cheers, Henry From chris.hegarty at oracle.com Wed May 1 09:05:22 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 01 May 2013 09:05:22 +0000 Subject: hg: jdk8/tl/jdk: 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Message-ID: <20130501090606.88DF148727@hg.openjdk.java.net> Changeset: dddd17cf61ff Author: chegar Date: 2013-05-01 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dddd17cf61ff 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Reviewed-by: alanb ! src/windows/native/java/net/NetworkInterface_winXP.c ! test/java/net/NetworkInterface/Test.java From chris.hegarty at oracle.com Wed May 1 09:11:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 01 May 2013 10:11:05 +0100 Subject: RFR 8013723: ProblemList.txt updates (5/2013) Message-ID: <5180DC29.4000606@oracle.com> Just a minor addition to the ProblemList.txt, until 8009615 can be resolved. diff -r dddd17cf61ff test/ProblemList.txt --- a/test/ProblemList.txt Wed May 01 10:03:39 2013 +0100 +++ b/test/ProblemList.txt Wed May 01 10:06:43 2013 +0100 @@ -121,6 +121,9 @@ ############################################################################ # jdk_lang + +# 8009615 +java/lang/instrument/IsModifiableClassAgent.java generic-all # 6944188 java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all -Chris. From Alan.Bateman at oracle.com Wed May 1 09:52:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 May 2013 10:52:52 +0100 Subject: RFR JDK-8012645(3rd round): Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile In-Reply-To: <5180C27B.1060900@oracle.com> References: <517F5402.2010205@oracle.com> <517F73A2.5030301@oracle.com> <5180C27B.1060900@oracle.com> Message-ID: <5180E5F4.7060407@oracle.com> On 01/05/2013 08:21, Henry Jen wrote: > : > Please review > > http://cr.openjdk.java.net/~henryjen/ccc/8012645.2/webrev > http://cr.openjdk.java.net/~henryjen/ccc/8012645.2/specdiff > > - Fix the inner class. > - Add back the order for ZipFile.stream() and spec the order to be as > appears in the central directory of the zip file. > > Cheers, > Henry I think looks good. -Alan From Alan.Bateman at oracle.com Wed May 1 09:55:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 May 2013 10:55:23 +0100 Subject: RFR 8013723: ProblemList.txt updates (5/2013) In-Reply-To: <5180DC29.4000606@oracle.com> References: <5180DC29.4000606@oracle.com> Message-ID: <5180E68B.8020306@oracle.com> This looks fine, hopefully the JVMTI support for BootstrapMethod attributes will be added soon so that this test can be liberated again. -Alan On 01/05/2013 10:11, Chris Hegarty wrote: > Just a minor addition to the ProblemList.txt, until 8009615 can be > resolved. > > > diff -r dddd17cf61ff test/ProblemList.txt > --- a/test/ProblemList.txt Wed May 01 10:03:39 2013 +0100 > +++ b/test/ProblemList.txt Wed May 01 10:06:43 2013 +0100 > @@ -121,6 +121,9 @@ > > ############################################################################ > > > # jdk_lang > + > +# 8009615 > +java/lang/instrument/IsModifiableClassAgent.java > generic-all > > # 6944188 > java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all > > -Chris. > > From Alan.Bateman at oracle.com Wed May 1 10:05:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 May 2013 11:05:46 +0100 Subject: RFR: 8012646: Pattern.splitAsStream In-Reply-To: <523D87F8-BE7E-43A9-806E-CF1798A7A0C1@oracle.com> References: <523D87F8-BE7E-43A9-806E-CF1798A7A0C1@oracle.com> Message-ID: <5180E8FA.90607@oracle.com> On 29/04/2013 13:25, Paul Sandoz wrote: > 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. > I looked through the webrev and it looks good to me. The subtly to get the remaining segment looks right. The javadoc seems consistent with the existing split methods too. A minor nit is that this class normally a space for

tags. -Alan. From chris.hegarty at oracle.com Wed May 1 10:16:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 01 May 2013 10:16:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130501101742.C20AA4872A@hg.openjdk.java.net> Changeset: 73793f2af80a Author: msheppar Date: 2013-04-30 16:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73793f2af80a 8007799: Base64.getEncoder(0, byte[]) returns an encoder that unexpectedly inserts line separators Reviewed-by: sherman, iris ! src/share/classes/java/util/Base64.java + test/java/util/Base64/Base64GetEncoderTest.java Changeset: 5941f7c9c76a Author: chegar Date: 2013-05-01 11:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5941f7c9c76a 8013723: ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt From Alan.Bateman at oracle.com Wed May 1 11:05:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 May 2013 12:05:35 +0100 Subject: RFR JDK-8013254: Constructor \w need update to add the support of \p{Join_Control} In-Reply-To: <51803118.1020407@oracle.com> References: <517FF8F8.3080208@oracle.com> <51803118.1020407@oracle.com> Message-ID: <5180F6FF.6080500@oracle.com> On 30/04/2013 22:01, Xueming Shen wrote: > 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 I went through the webrev and it looks good to me. I assume you have checked to make sure that we didn't miss anything else. -Alan From weijun.wang at oracle.com Wed May 1 13:11:40 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 01 May 2013 13:11:40 +0000 Subject: hg: jdk8/tl/jdk: 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Message-ID: <20130501131206.472EC4872D@hg.openjdk.java.net> Changeset: ae4a82e69da2 Author: weijun Date: 2013-05-01 21:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae4a82e69da2 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Reviewed-by: vinnie ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java + test/sun/security/krb5/auto/SaslGSS.java From brian.goetz at oracle.com Wed May 1 15:22:44 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 01 May 2013 11:22:44 -0400 Subject: RFR 8012664 -- Tests for java.util.stream and lambda translation Message-ID: <51813344.1030207@oracle.com> Webrev at: http://cr.openjdk.java.net/~briangoetz/JDK-8012664/webrev/ These tests give ~92% line coverage on java.util.stream (they are being reviewed separately to minimize putback dependencies.) From mike.duigou at oracle.com Wed May 1 15:37:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 01 May 2013 15:37:19 +0000 Subject: hg: jdk8/tl/jdk: 8012665: add CharSequence.chars, CharSequence.codePoints Message-ID: <20130501153732.3B74448732@hg.openjdk.java.net> Changeset: c6aef650e615 Author: mduigou Date: 2013-05-01 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6aef650e615 8012665: add CharSequence.chars, CharSequence.codePoints Reviewed-by: martin, alanb, ulfzibis, mduigou Contributed-by: Stuart Marks , Henry Jen ! src/share/classes/java/lang/CharSequence.java + test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/StringBuffer/TestSynchronization.java From paul.sandoz at oracle.com Wed May 1 15:42:27 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 May 2013 17:42:27 +0200 Subject: RFR JDK-8003258: BufferedReader.lines() In-Reply-To: <51809BCB.4060609@oracle.com> References: <517AF8D0.2020902@oracle.com> <517B893F.8030401@oracle.com> <51809BCB.4060609@oracle.com> Message-ID: <860817F2-1FBF-4CCA-9013-099C52428569@oracle.com> On May 1, 2013, at 6:36 AM, Henry Jen wrote: > >> >> /** >> * Returns a {@code Stream}, the elements of which are lines read from this >> * {@code BufferedReader}. The {@link Stream} is lazily populated via >> * calls to {@link #readLine()}. >> * >> *

Each element consumed by the {@code Stream} caused a line to be >> * read from this {@code BufferedReader}. Since the {@code Stream} does >> * not necessarily consume all lines, it is possible to mix and use >> * different read methods on a {@code BufferedReader}. Each method will >> * simply pick up from where it was left on last read. >> * >> *

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 >> * >> *

Noted that some terminal stream operations make no guarantee how many >> * element to be consumed. Therefore 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. >> * I don't think the first sentence of the above paragraph is necessary for normative stuff. I think it sufficient to state "After execution of the terminal operation there are... " You could, if you wish, add an @apiNote providing further details as to why there are no such guarantees. Paul. From mandy.chung at oracle.com Wed May 1 15:44:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 May 2013 08:44:45 -0700 Subject: RFR JDK-8013254: Constructor \w need update to add the support of \p{Join_Control} In-Reply-To: <51803118.1020407@oracle.com> References: <517FF8F8.3080208@oracle.com> <51803118.1020407@oracle.com> Message-ID: <5181386D.8050804@oracle.com> On 4/30/2013 2:01 PM, Xueming Shen wrote: > > http://cr.openjdk.java.net/~sherman/8013254/webrev/ > Looks good. Mandy > -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 robert.field at oracle.com Wed May 1 15:46:50 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 01 May 2013 15:46:50 +0000 Subject: hg: jdk8/tl/langtools: 8011591: BootstrapMethodError when capturing constructor ref to local classes Message-ID: <20130501154653.7F0E64873C@hg.openjdk.java.net> Changeset: 8e27e84de2e9 Author: rfield Date: 2013-05-01 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e27e84de2e9 8011591: BootstrapMethodError when capturing constructor ref to local classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInnerImplicitArgs.java From Alan.Bateman at oracle.com Wed May 1 16:06:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 May 2013 17:06:40 +0100 Subject: RFR JDK-8003258: BufferedReader.lines() In-Reply-To: <51809BCB.4060609@oracle.com> References: <517AF8D0.2020902@oracle.com> <517B893F.8030401@oracle.com> <51809BCB.4060609@oracle.com> Message-ID: <51813D90.4080407@oracle.com> On 01/05/2013 05:36, Henry Jen wrote: > : > > What do people think about following spec? Maybe we can remove the > "Since..." for the mix API usage so we don't "set expectation" by > calling it out. Or do you think we should actually remove most of the > text base on the "readLine" implementation? I think it should be removed. Also it appears to conflict with the later wording that the position is not guaranteed after the terminal operation. -Alan. From paul.sandoz at oracle.com Wed May 1 16:27:24 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 May 2013 18:27:24 +0200 Subject: RFR JDK-8003258: BufferedReader.lines() In-Reply-To: <860817F2-1FBF-4CCA-9013-099C52428569@oracle.com> References: <517AF8D0.2020902@oracle.com> <517B893F.8030401@oracle.com> <51809BCB.4060609@oracle.com> <860817F2-1FBF-4CCA-9013-099C52428569@oracle.com> Message-ID: <46E3C3B8-5BD8-4A40-97CA-CDA080DD5F74@oracle.com> Also... On May 1, 2013, at 5:42 PM, Paul Sandoz wrote: > On May 1, 2013, at 6:36 AM, Henry Jen wrote: >> >>> >>> /** >>> * Returns a {@code Stream}, the elements of which are lines read from this >>> * {@code BufferedReader}. The {@link Stream} is lazily populated via >>> * calls to {@link #readLine()}. >>> * Also ... the last sentence is too specific. I think it can be removed or made an @implNote. We could state. Lines are read from the reader during execution of the terminal stream operation. Suitable massaging with other sentences that mention " terminal stream operation" to perhaps avoid undue repetition. Paul. From kumar.x.srinivasan at oracle.com Wed May 1 19:33:48 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 01 May 2013 12:33:48 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness Message-ID: <51816E1C.6020902@oracle.com> Hi, Please review simple fixes for code correctness in the launcher. http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ Thanks Kumar From kumar.x.srinivasan at oracle.com Wed May 1 21:03:26 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 01 May 2013 14:03:26 -0700 Subject: RFR: JDK-8001163: [pack200] should support attributes introduced by JSR-308 Message-ID: <5181831E.1080109@oracle.com> Hi, This is the implementation for JSR-308 support in pack200. http://cr.openjdk.java.net/~ksrini/8001163/webrev.jdk.4/ The JSR-308 specification is at: http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html Please let me know if you have any comments or suggestions. Thanks Kumar From martinrb at google.com Wed May 1 22:19:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 1 May 2013 15:19:23 -0700 Subject: Add getChars to CharSequence In-Reply-To: <5177133D.60309@CoSoCo.de> References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: Another version of this change is ready. No longer preliminary. Tests have been written. http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ This kind of change is particularly subject to feature creep, and I am trying to restrain myself. I even addressed some of Ulf's suggestions. The "Msg" suffix is gone. I reverted changes to AbstractStringBuilder.replace. I kept the naming convention for getChars parameter names. Parameter names and exception details continue to be maddeningly unsystematic, but they should be a little better than before. From akhil.arora at oracle.com Wed May 1 22:55:28 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Wed, 01 May 2013 15:55:28 -0700 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: <51819D60.9090008@oracle.com> On 04/26/2013 04:52 AM, 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); > > Paul. The testOptimizedForEach test verifies that remove() and previous() work as expected after forEachRemaining returns (lines 238-251). Please review - http://cr.openjdk.java.net/~akhil/8013150/webrev/ Somehow tests got left behind in the previous commit, adding them back. Thanks From tbuktu at hotmail.com Thu May 2 01:34:48 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Thu, 2 May 2013 03:34:48 +0200 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 Brian, On 04/30/2013 01:40 AM, Brian Burkhalter wrote: > To answer my own question, there are apparently about 1,000 more lines. > It looks to me as if they are, i.e., the only changes versus the JDK8 repo are those intended for this patch. Yes and yes :) I just checked in a bug fix to BigInteger and a couple of improvements to BigIntegerTest. I'm assuming you're going to go with the code at https://github.com/tbuktu/bigint (i.e. the version that contains all algorithms), so I didn't update the "lite version" at https://gist.github.com/tbuktu/1576025. Alan is working on an improved BigInteger.toString() that should be dramatically faster for large numbers. What's the deadline for getting this in? Thanks, Tim From sundararajan.athijegannathan at oracle.com Thu May 2 04:02:25 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 02 May 2013 09:32:25 +0530 Subject: RFR: JDK-8013225: Refresh jdk's private ASM to the latest. In-Reply-To: <517EF35B.1000104@oracle.com> References: <51796D91.6070304@oracle.com> <51799108.6040801@oracle.com> <750365AA-1F45-4C0E-AA59-6D7733835468@oracle.com> <517EF35B.1000104@oracle.com> Message-ID: <5181E551.5090200@oracle.com> Hi Kumar, So long as those nashorn tests (jtreg tests under $jdk/test/javax/script, $jdk/sun/tools/jrunscript, $nashorn/test and nashorn ant tests - $nashorn/make - ant test) run fine, we've no objections from nashorn team. Thanks -Sundar On Tuesday 30 April 2013 03:55 AM, Kumar Srinivasan 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. > > 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 henry.jen at oracle.com Thu May 2 06:49:58 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 01 May 2013 23:49:58 -0700 Subject: RFR JDK-8003258(2nd round): BufferedReader.lines() Message-ID: <51820C96.4030006@oracle.com> Hi, Take feedbacks from previous round, the javadoc is updated http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/specdiff/ > /** > * Returns a {@code Stream}, the elements of which are lines read from > * this {@code BufferedReader}. The {@link Stream} is lazily populated, > * i.e, read only occurs during the > * terminal > * stream operation. > * > *

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. > * > *

If an {@link IOException} is thrown when accessing the underlying > * {@code BufferedReader}, it is wrapped in an {@link > * UncheckedIOException} which will be thrown from the {@code Stream} > * method that caused the read to take place. For example, when trying to > * read from the {@code Stream} after the {@code BufferedReader} is > * closed, will throw an {@code UncheckedIOException}. Note that This > * method will return the {@code Stream} even if this {@code > * BufferedReader} is closed, but the operation cause reading will throw > * {@code UncheckedIOException}. > * > * @return a {@code Stream} providing the lines of text > * described by this {@code BufferedReader} > * > * @since 1.8 > */ > public Stream lines() {} Cheers, Henry From henry.jen at oracle.com Thu May 2 06:52:46 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 01 May 2013 23:52:46 -0700 Subject: RFR: JDK-8006884: (fs) Add Files.list, lines and find Message-ID: <51820D3E.70103@oracle.com> Hi, Please review a couple stream access API proposed for java.nio.file.Files and java.nio.file.DirectoryStream, http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/ Cheers, Henry From Ulf.Zibis at CoSoCo.de Thu May 2 09:55:27 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 02 May 2013 11:55:27 +0200 Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints In-Reply-To: References: <517A7312.30709@CoSoCo.de> Message-ID: <5182380F.1060701@CoSoCo.de> Thanks for your opinion, Paul. Looking into the existing sources, violation of the 80 character limit seems widely accepted, so to me it seems reasonable to continue this style in appropriate cases. But I rarely see good reasons to violate the 8-spaces indentation rule for continuation lines. -Ulf Am 26.04.2013 16:48, schrieb Paul Benedict: > 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 neil.richards at ngmr.net Thu May 2 11:08:33 2013 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 02 May 2013 12:08:33 +0100 Subject: RFEs implementing JEP 170 In-Reply-To: <1367492526.19948.14.camel@localhost> References: <1367492526.19948.14.camel@localhost> Message-ID: <1367492913.19948.16.camel@localhost> Oops, messed up my reply-to address. (I blame my newly upgraded system). Hopefully this should be better. Regards, Neil On Thu, 2013-05-02 at 12:02 +0100, Neil Richards wrote: > Hi Lance, > I've been trying to identify the Java bug ids for the RFEs which > implement JEP 170 (which, from what I can tell, should be in OpenJDK 8 > since milestone 6 [1]). > > Unlike most JEPs, the entry for 170 does not seem to hold references to > these ids (only to the affected JSRs). > > Searching the mailing archives for "jep 170", "jsr 114" & "jsr 221" also > didn't offer any greater insight, though by searching for "jdbc 4.2", I > did manage to find reference to 8005080 [2] [3]. > > That conversation suggests there should be other RFEs concerned with > the remaining implementation of JEP 170, but I haven't been able to > determine which those are. > > Could you please tell me which RFEs implements this JEP? > It also would be good to update the document for JEP 170 [4] with there > references, and perhaps update its status to "Completed" if it has, > indeed, been completely delivered into openjdk 8? > > Thanks, > Neil > > [1] http://openjdk.java.net/projects/jdk8/milestones > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013569.html > [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d3da0d29d7cd > [4] http://openjdk.java.net/jeps/170 > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Thu May 2 11:13:55 2013 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 02 May 2013 12:13:55 +0100 Subject: RFEs implementing JEP 170 Message-ID: <1367493235.19948.17.camel@localhost> Hi Lance, I've been trying to identify the Java bug ids for the RFEs which implement JEP 170 (which, from what I can tell, should be in OpenJDK 8 since milestone 6 [1]). Unlike most JEPs, the entry for 170 does not seem to hold references to these ids (only to the affected JSRs). Searching the mailing archives for "jep 170", "jsr 114" & "jsr 221" also didn't offer any greater insight, though by searching for "jdbc 4.2", I did manage to find reference to 8005080 [2] [3]. That conversation suggests there should be other RFEs concerned with the remaining implementation of JEP 170, but I haven't been able to determine which those are. Could you please tell me which RFEs implements this JEP? It also would be good to update the document for JEP 170 [4] with there references, and perhaps update its status to "Completed" if it has, indeed, been completely delivered into openjdk 8? Thanks, Neil [1] http://openjdk.java.net/projects/jdk8/milestones [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013569.html [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d3da0d29d7cd [4] http://openjdk.java.net/jeps/170 -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jeffhain at rocketmail.com Thu May 2 11:14:06 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 2 May 2013 12:14:06 +0100 (BST) Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: References: <51808D36.9080101@oracle.com> Message-ID: <1367493246.59689.YahooMailNeo@web171706.mail.ir2.yahoo.com> Hello. nonNull could be renamed into isNonNull, else people might use it instead of requireNonNull, especially if they are already used to a pre-Java 7 requireNonNull that would be called nonNull. (example: http://grokbase.com/p/openjdk/core-libs-dev/111tbha823/code-review-7012540-java-util-objects-nonnull-incorrectly-named ) It would also be more consistent with isNull. -Jeff From thomas.schatzl at oracle.com Thu May 2 11:30:26 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 May 2013 13:30:26 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <517FE6EA.6070907@oracle.com> References: <1367333840.2722.118.camel@cirrus> <517FE6EA.6070907@oracle.com> Message-ID: <1367494226.2941.136.camel@cirrus> Hi, On Tue, 2013-04-30 at 16:44 +0100, Alan Bateman wrote: > 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. The test is just that: a somewhat artificial way to reproduce the problem always. I tried some of the example programs listed below thousands of times, sometimes without any issue. The developer previously working on that also had severe problems reproducing it. > 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? No instrumentation I can see of, but a whole set of weak reference related nightly UTE tests fail at different times (I would suspect nightly testing does not do any instrumentation). Here is a list with exactly these errors: gc/gctests/ReferencesGC gc/gctests/WeakReference/weak003 gc/gctests/SoftReference/soft005 gc/gctests/LargeObjects/large002 nsk/jdi/ObjectReference/referringObjects/referringObjects002 gc/gctests/PhantomReference/PhantomReferenceTest gc/gctests/OneeFinalizerTest heapdump/JMapHeap gc/gctests/FinalizeTest01 nsk/sysdict/vm/stress/btree/btree007 Apart from these failures, the more serious problem seems to be that the reference handler thread silently dies. Which means that weak reference processing is effectively disabled after such an error. A VM abort like for the Cleaner processing would be lot preferable than the current situation too. Thanks, Thomas From Alan.Bateman at oracle.com Thu May 2 12:02:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 13:02:37 +0100 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> Message-ID: <518255DD.8000008@oracle.com> On 02/05/2013 02:34, Tim Buktu wrote: > : > > Alan is working on an improved BigInteger.toString() that should be > dramatically faster for large numbers. What's the deadline for getting > this in? > Thanks, > > Tim Here's the latest milestone dates: http://openjdk.java.net/projects/jdk8/milestones Given the size of the patch then it would be great to get it in as early as possible. With the review effort then I assume Feature Complete is too tight although I know Brian Burkhalter is anxious to get it in as soon as possible. I can't comment on the BigInteger.toString work to know how big this is. -Alan. From Alan.Bateman at oracle.com Thu May 2 12:08:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 13:08:22 +0100 Subject: RFR JDK-8003258(2nd round): BufferedReader.lines() In-Reply-To: <51820C96.4030006@oracle.com> References: <51820C96.4030006@oracle.com> Message-ID: <51825736.1080007@oracle.com> On 02/05/2013 07:49, Henry Jen wrote: > Hi, > > Take feedbacks from previous round, the javadoc is updated > > http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/webrev/ > http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/specdiff/ > This looks good to me except for the last two sentences of the final paragraph: "For example, when trying toread from the Stream after the BufferedReaderis closed, will throw an UncheckedIOException. Note thatmethod will return the Stream Stream even if this BufferedReader is closed, but the operation cause reading will throwUncheckedIOException." How about: "This method will return a Stream if invoked on a BufferedReader that is closed. Any operation on that stream requires reading from the BufferedReader after is it closed will cause an UncheckedIOException to be thrown". Otherwise I think we are at the finish line. -Alan From Alan.Bateman at oracle.com Thu May 2 12:11:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 13:11:17 +0100 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <51816E1C.6020902@oracle.com> References: <51816E1C.6020902@oracle.com> Message-ID: <518257E5.2040802@oracle.com> On 01/05/2013 20:33, Kumar Srinivasan wrote: > Hi, > > Please review simple fixes for code correctness in the launcher. > > http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ > > Thanks > Kumar > This looks okay to me although I wonder why the NULL_CHECK macros check for 0 rather than NULL. I don't know if jexec is still used but does the malloc return need to be checked? -Alan From kumar.x.srinivasan at oracle.com Thu May 2 12:49:58 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 02 May 2013 12:49:58 +0000 Subject: hg: jdk8/tl/jdk: 8013225: Refresh jdk's private ASM to the latest. Message-ID: <20130502125032.62CF048777@hg.openjdk.java.net> Changeset: 167d2dcaeeee Author: ksrini Date: 2013-05-01 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/167d2dcaeeee 8013225: Refresh jdk's private ASM to the latest. Reviewed-by: mduigou, sundar ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java ! src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Context.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handler.java ! src/share/classes/jdk/internal/org/objectweb/asm/Item.java ! src/share/classes/jdk/internal/org/objectweb/asm/Label.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/TypePath.java + src/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/version.txt From alexander.zuev at oracle.com Thu May 2 13:30:54 2013 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 02 May 2013 17:30:54 +0400 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: <51826A8E.6010806@oracle.com> Kumar, On 4/30/13 22:32, Kumar Srinivasan wrote: > Couple of nits: > I don't think you need the parens > > j = (nextsemi < nextangl ? nextsemi : nextangl); Here i tend to agree with John - the condition being a superposition of two really closely named variables might look confusing and since the world supply of parentheses is not limited i will humbly ask for permission to leave one extra pair of them there. > > Coding conventions nits: > missing spaces for operators. > > for (int i = firstl+1, j; i > 0; i = sig.indexOf('L', j)+1) { Fixed. > I take it all the regression tests have been run ? in > jdk/test/tools/pack200. Sure - since it is not platform-specific code i took liberty to perform testing on Mac OS and Linux only - all the pack200 regression tests are passed. The updated webrev can be seen here: http://cr.openjdk.java.net/~kizune/8013155/webrev.01 With best regards, Alex From kumar.x.srinivasan at oracle.com Thu May 2 15:14:31 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 02 May 2013 08:14:31 -0700 Subject: RFR: 8013155: [pack200] improve performance of pack200 In-Reply-To: <51826A8E.6010806@oracle.com> References: <517FF36D.7070102@oracle.com> <51800E46.6000301@oracle.com> <51826A8E.6010806@oracle.com> Message-ID: <518282D7.70708@oracle.com> Looks good. Kumar > Kumar, > > On 4/30/13 22:32, Kumar Srinivasan wrote: >> Couple of nits: >> I don't think you need the parens >> >> j = (nextsemi < nextangl ? nextsemi : nextangl); > Here i tend to agree with John - the condition being a superposition > of two really closely named > variables might look confusing and since the world supply of > parentheses is not limited i will humbly > ask for permission to leave one extra pair of them there. >> >> Coding conventions nits: >> missing spaces for operators. >> >> for (int i = firstl+1, j; i > 0; i = sig.indexOf('L', j)+1) { > Fixed. >> I take it all the regression tests have been run ? in >> jdk/test/tools/pack200. > Sure - since it is not platform-specific code i took liberty to > perform testing on Mac OS and Linux only - all the pack200 > regression tests are passed. > > The updated webrev can be seen here: > http://cr.openjdk.java.net/~kizune/8013155/webrev.01 > > With best regards, > Alex From Alan.Bateman at oracle.com Thu May 2 15:22:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 16:22:56 +0100 Subject: RFR: JDK-8006884: (fs) Add Files.list, lines and find In-Reply-To: <51820D3E.70103@oracle.com> References: <51820D3E.70103@oracle.com> Message-ID: <518284D0.4090008@oracle.com> On 02/05/2013 07:52, Henry Jen wrote: > Hi, > > Please review a couple stream access API proposed for > java.nio.file.Files and java.nio.file.DirectoryStream, > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ > http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/ > > Cheers, > Henry One corner case that I meant to ask about is the expected behavior when someone attempts to do something on a CloseableStream after it is closed? It's not specified so it's not testable but I'm just wondering if the Iterator throwing ISE is right or whether this should be an UncheckedIOException. As I understand it, an ISE will be thrown if someone attempts to use a stream that already been operated on, so this really just leaves the uninteresting case where the stream is closed before using it. -Alan. From Alan.Bateman at oracle.com Thu May 2 15:45:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 16:45:11 +0100 Subject: RFEs implementing JEP 170 In-Reply-To: <1367493235.19948.17.camel@localhost> References: <1367493235.19948.17.camel@localhost> Message-ID: <51828A07.1020402@oracle.com> On 02/05/2013 12:13, Neil Richards wrote: > : > > That conversation suggests there should be other RFEs concerned with > the remaining implementation of JEP 170, but I haven't been able to > determine which those are. > I'm sure Lance will add the links but in the mean-time then "hg log src/share/classes/java/sql" and "hg log src/share/classes/javax/sql" should help you find the recent changes. -Alan. From henry.jen at oracle.com Thu May 2 15:52:54 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 2 May 2013 08:52:54 -0700 Subject: RFR: JDK-8006884: (fs) Add Files.list, lines and find In-Reply-To: <518284D0.4090008@oracle.com> References: <51820D3E.70103@oracle.com> <518284D0.4090008@oracle.com> Message-ID: <1DCCDD90-5C40-4148-9A82-E130FCA7A4C0@oracle.com> On May 2, 2013, at 8:22 AM, Alan Bateman wrote: > On 02/05/2013 07:52, Henry Jen wrote: >> Hi, >> >> Please review a couple stream access API proposed for >> java.nio.file.Files and java.nio.file.DirectoryStream, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/ >> >> Cheers, >> Henry > One corner case that I meant to ask about is the expected behavior when someone attempts to do something on a CloseableStream after it is closed? It's not specified so it's not testable but I'm just wondering if the Iterator throwing ISE is right or whether this should be an UncheckedIOException. As I understand it, an ISE will be thrown if someone attempts to use a stream that already been operated on, so this really just leaves the uninteresting case where the stream is closed before using it. I think UncheckedIOException is expected as read on a closed InputStream should throw IOException. A related question, what do we expect when iterate a DirectoryStream which is closed after we obtain the iterator? Cheers, Henry From henry.jen at oracle.com Thu May 2 15:58:14 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 2 May 2013 08:58:14 -0700 Subject: RFR: JDK-8006884: (fs) Add Files.list, lines and find In-Reply-To: <1DCCDD90-5C40-4148-9A82-E130FCA7A4C0@oracle.com> References: <51820D3E.70103@oracle.com> <518284D0.4090008@oracle.com> <1DCCDD90-5C40-4148-9A82-E130FCA7A4C0@oracle.com> Message-ID: <2AFA1449-1B6F-45EA-9072-43604FA72019@oracle.com> On May 2, 2013, at 8:52 AM, Henry Jen wrote: > > On May 2, 2013, at 8:22 AM, Alan Bateman wrote: > >> On 02/05/2013 07:52, Henry Jen wrote: >>> Hi, >>> >>> Please review a couple stream access API proposed for >>> java.nio.file.Files and java.nio.file.DirectoryStream, >>> >>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/ >>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/ >>> >>> Cheers, >>> Henry >> One corner case that I meant to ask about is the expected behavior when someone attempts to do something on a CloseableStream after it is closed? It's not specified so it's not testable but I'm just wondering if the Iterator throwing ISE is right or whether this should be an UncheckedIOException. As I understand it, an ISE will be thrown if someone attempts to use a stream that already been operated on, so this really just leaves the uninteresting case where the stream is closed before using it. > > I think UncheckedIOException is expected as read on a closed InputStream should throw IOException. > > A related question, what do we expect when iterate a DirectoryStream which is closed after we obtain the iterator? Answer myself, as end of stream expected. Cheers, Henry From henry.jen at oracle.com Thu May 2 16:00:55 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 02 May 2013 09:00:55 -0700 Subject: RFR JDK-8003258(2nd round): BufferedReader.lines() In-Reply-To: <51825736.1080007@oracle.com> References: <51820C96.4030006@oracle.com> <51825736.1080007@oracle.com> Message-ID: <51828DB7.4030500@oracle.com> On 05/02/2013 05:08 AM, Alan Bateman wrote: > On 02/05/2013 07:49, Henry Jen wrote: >> Hi, >> >> Take feedbacks from previous round, the javadoc is updated >> >> http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/webrev/ >> http://cr.openjdk.java.net/~henryjen/ccc/8003258.2/specdiff/ >> > This looks good to me except for the last two sentences of the final > paragraph: > > "For example, when trying toread from the Stream after the > BufferedReaderis closed, will throw an UncheckedIOException. Note > thatmethod will return the Stream Stream even if this BufferedReader is > closed, but the operation cause reading will throwUncheckedIOException." > > How about: > > "This method will return a Stream if invoked on a BufferedReader that is > closed. Any operation on that stream requires reading from the > BufferedReader after is it closed will cause an UncheckedIOException to > be thrown". > Updated as suggested. > Otherwise I think we are at the finish line. > Cheers, Henry From daniel.fuchs at oracle.com Thu May 2 16:24:37 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 02 May 2013 18:24:37 +0200 Subject: RFR: JDK-8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently In-Reply-To: <517F8C81.7030602@oracle.com> References: <516C0A14.1080408@oracle.com> <517F8C81.7030602@oracle.com> Message-ID: <51829345.9070700@oracle.com> Hi, Please find an updated webrev below: Changes are: catch IAE are removed - as suggested by Alan. I didn't find traces of IAE being thrown by OutputStreamWriter constructor in recent JDK - so I think it's safe to remove those catch clauses. changes in test Makefile have been removed: I rebased my patch on jdk8 tip, which already has these test Makefile changes. best regards, -- daniel On 4/30/13 11:18 AM, Alan Bateman wrote: > 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 mike.duigou at oracle.com Thu May 2 16:25:01 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 02 May 2013 16:25:01 +0000 Subject: hg: jdk8/tl/jdk: 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Message-ID: <20130502162514.B703948781@hg.openjdk.java.net> Changeset: 5045eb04a579 Author: mduigou Date: 2013-05-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5045eb04a579 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Reviewed-by: mduigou, henryjen, alanb, martin, psandoz Contributed-by: akhil.arora at oracle.com, brian.goetz at oracle.com ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/BitSet/BitSetStreamTest.java + test/java/util/Random/RandomStreamTest.java + test/java/util/zip/ZipFile/StreamZipEntriesTest.java From lance.andersen at oracle.com Thu May 2 16:31:28 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Thu, 2 May 2013 12:31:28 -0400 Subject: RFEs implementing JEP 170 In-Reply-To: <51828A07.1020402@oracle.com> References: <1367493235.19948.17.camel@localhost> <51828A07.1020402@oracle.com> Message-ID: <2CFDEF04-775F-4AD2-8DB1-51EB0E2E0DAE@oracle.com> Yes I am away right now but will follow up when I am back mid next week 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 Sent from my iPad On May 2, 2013, at 11:45 AM, Alan Bateman wrote: > On 02/05/2013 12:13, Neil Richards wrote: >> : >> >> That conversation suggests there should be other RFEs concerned with >> the remaining implementation of JEP 170, but I haven't been able to >> determine which those are. > I'm sure Lance will add the links but in the mean-time then "hg log src/share/classes/java/sql" and "hg log src/share/classes/javax/sql" should help you find the recent changes. > > -Alan. From Karen.Kinnear at oracle.com Thu May 2 16:37:35 2013 From: Karen.Kinnear at oracle.com (Karen Kinnear) Date: Thu, 2 May 2013 12:37:35 -0400 Subject: RFR: 7150256/8004095: Add back Remote Diagnostic Commands In-Reply-To: <517FF0C2.4040208@oracle.com> References: <517FF0C2.4040208@oracle.com> Message-ID: Frederic, Code looks good - actually it looks very clean. Ship it. Couple of minor comments that don't require re-review: 1. nmtDCmd.hpp/cpp - copyrights 2012 -> 2012, 2013 2. jmm.h line 213: "True is" -> "True if" 3. diagnosticFramework.hpp Thank you for the comments! line 298 "rational" -> "rationale" 4. diagnosticCommand.cpp lines 105/109 - what prints if p._name is null? thanks, Karen On Apr 30, 2013, at 12:26 PM, frederic parain wrote: > 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 sundararajan.athijegannathan at oracle.com Thu May 2 16:41:09 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 02 May 2013 22:11:09 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 Message-ID: <51829725.9090406@oracle.com> Hi, Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package, makefiles etc. Please review the open jdk changes here: http://cr.openjdk.java.net/~sundar/8012975/ Thanks, -Sundar From Alan.Bateman at oracle.com Thu May 2 16:45:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 17:45:43 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51829725.9090406@oracle.com> References: <51829725.9090406@oracle.com> Message-ID: <51829837.9090406@oracle.com> On 02/05/2013 17:41, A. Sundararajan wrote: > Hi, > > Oracle JDK includes Rhino based javax.script implementation (which > lives mostly in "closed" code). Rhino is being removed from Oracle JDK > builds and there are the changes to the jdk open repository as well > like com.sun.script.javascript package, makefiles etc. Please review > the open jdk changes here: > > http://cr.openjdk.java.net/~sundar/8012975/ In profiles-rtjar-includes.txt then you also need to remove META-INF/services/javax.script.ScriptEngineFactory from PROFILE_3_INCLUDE_METAINF_SERVICES. Otherwise good fine. -Alan. From martinrb at google.com Thu May 2 16:51:07 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 May 2013 09:51:07 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <51816E1C.6020902@oracle.com> References: <51816E1C.6020902@oracle.com> Message-ID: I would also be inclined to change == 0 to == NULL This seems like another occasion to use the weird do { ... } while(0) trick to make the macro behave more like a statement. I might obfuscate the macro parameters to make collisions less likely, e.g. e => N_C_RV_e On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > Hi, > > Please review simple fixes for code correctness in the launcher. > > http://cr.openjdk.java.net/~**ksrini/8013736/webrev.0/ > > Thanks > Kumar > > From martinrb at google.com Thu May 2 17:17:11 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 May 2013 10:17:11 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: References: <51816E1C.6020902@oracle.com> Message-ID: This is global fix creep, but ... these macros are also found in the hotspot sources. I would rewrite all the macros in the jdk to adopt the blessed style do { ... } while(0) and remove all comments in the jdk of the form /* next token must be ; */ If you want a macro that does nothing at all, you should define it do {} while (0) instead of defining it to the empty string. On Thu, May 2, 2013 at 9:51 AM, Martin Buchholz wrote: > I would also be inclined to change > == 0 > to > == NULL > > This seems like another occasion to use the weird > > do { ... } while(0) > > trick to make the macro behave more like a statement. > > I might obfuscate the macro parameters to make collisions less likely, > e.g. e => N_C_RV_e > > > > > On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan < > kumar.x.srinivasan at oracle.com> wrote: > >> Hi, >> >> Please review simple fixes for code correctness in the launcher. >> >> http://cr.openjdk.java.net/~**ksrini/8013736/webrev.0/ >> >> Thanks >> Kumar >> >> > From alexander.zuev at oracle.com Thu May 2 17:24:16 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Thu, 02 May 2013 17:24:16 +0000 Subject: hg: jdk8/tl/jdk: 8013155: [pack200] improve performance of pack200 Message-ID: <20130502172428.6F15048787@hg.openjdk.java.net> Changeset: a6ff4a823164 Author: kizune Date: 2013-05-02 21:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ff4a823164 8013155: [pack200] improve performance of pack200 Reviewed-by: ksrini, jrose ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java From kumar.x.srinivasan at oracle.com Thu May 2 17:45:25 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 02 May 2013 10:45:25 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: References: <51816E1C.6020902@oracle.com> Message-ID: <5182A635.7070106@oracle.com> On 5/2/2013 10:17 AM, Martin Buchholz wrote: > This is global fix creep, but ... :( > > these macros are also found in the hotspot sources. > I would rewrite all the macros in the jdk to adopt the blessed style > do { ... } while(0) > and remove all comments in the jdk of the form > /* next token must be ; */ > If you want a macro that does nothing at all, you should define it > do {} while (0) > instead of defining it to the empty string. I am not following, could you be more explicit on how this applies to -#define NULL_CHECK0(e) if ((e) == 0) { \ +#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ JLI_ReportErrorMessage(JNI_ERROR); \ - return 0; \ + return rv; \ } -#define NULL_CHECK(e) if ((e) == 0) { \ - JLI_ReportErrorMessage(JNI_ERROR); \ - return; \ - } +#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) +#define NULL_CHECK(e) NULL_CHECK_RV(e, ) + > > > I would also be inclined to change > == 0 > to > == NULL > Yes will take care of this, as well as Alan suggestion added a check for malloc return. > This seems like another occasion to use the weird > > do { ... } while(0) > > trick to make the macro behave more like a statement. > > I might obfuscate the macro parameters to make collisions less > likely, e.g. e => N_C_RV_e > You want me to rename the macro parameter e to N_C_RV_e ? or something else say ncrve to avoid collision ? Kumar > > > > > On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan > > wrote: > > Hi, > > Please review simple fixes for code correctness in the launcher. > > http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ > > > Thanks > Kumar > > > From martinrb at google.com Thu May 2 18:16:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 May 2013 11:16:23 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <5182A635.7070106@oracle.com> References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> Message-ID: What would Martin actually do? #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ ncor_failure_return_value) \ do { \ if ((ncor_pointer_to_check) == NULL) { \ JLI_ReportErrorMessage(JNI_ERROR); \ return ncor_failure_return_value; \ } \ } while(0); On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > On 5/2/2013 10:17 AM, Martin Buchholz wrote: > > This is global fix creep, but ... > > > :( > > > > these macros are also found in the hotspot sources. > I would rewrite all the macros in the jdk to adopt the blessed style > do { ... } while(0) > and remove all comments in the jdk of the form > /* next token must be ; */ > If you want a macro that does nothing at all, you should define it > do {} while (0) > instead of defining it to the empty string. > > I am not following, could you be more explicit on how this applies to > > -#define NULL_CHECK0(e) if ((e) == 0) { \+#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ > JLI_ReportErrorMessage(JNI_ERROR); \- return 0; \+ return rv; \ > } > -#define NULL_CHECK(e) if ((e) == 0) { \- JLI_ReportErrorMessage(JNI_ERROR); \- return; \- }+#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) > +#define NULL_CHECK(e) NULL_CHECK_RV(e, )+ > > > > > I would also be inclined to change >> == 0 >> to >> == NULL >> >> > Yes will take care of this, as well as Alan suggestion added a check for > malloc return. > > > This seems like another occasion to use the weird >> >> do { ... } while(0) >> >> trick to make the macro behave more like a statement. >> >> I might obfuscate the macro parameters to make collisions less likely, >> e.g. e => N_C_RV_e >> > > You want me to rename the macro parameter e to N_C_RV_e ? or something else > say ncrve to avoid collision ? > > Kumar > > > >> >> >> >> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan < >> kumar.x.srinivasan at oracle.com> wrote: >> >>> Hi, >>> >>> Please review simple fixes for code correctness in the launcher. >>> >>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >>> >>> Thanks >>> Kumar >>> >>> >> > > From martinrb at google.com Thu May 2 18:17:59 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 May 2013 11:17:59 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> Message-ID: Oops. Of course, that shouldn't have the trailing semicolon #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ ncor_failure_return_value) \ do { \ if ((ncor_pointer_to_check) == NULL) { \ JLI_ReportErrorMessage(JNI_ERROR); \ return ncor_failure_return_value; \ } \ } while(0) On Thu, May 2, 2013 at 11:16 AM, Martin Buchholz wrote: > What would Martin actually do? > > #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ > ncor_failure_return_value) \ > do { \ > if ((ncor_pointer_to_check) == NULL) { \ > JLI_ReportErrorMessage(JNI_ERROR); \ > return ncor_failure_return_value; \ > } \ > } while(0); > > > > > On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan < > kumar.x.srinivasan at oracle.com> wrote: > >> On 5/2/2013 10:17 AM, Martin Buchholz wrote: >> >> This is global fix creep, but ... >> >> >> :( >> >> >> >> these macros are also found in the hotspot sources. >> I would rewrite all the macros in the jdk to adopt the blessed style >> do { ... } while(0) >> and remove all comments in the jdk of the form >> /* next token must be ; */ >> If you want a macro that does nothing at all, you should define it >> do {} while (0) >> instead of defining it to the empty string. >> >> I am not following, could you be more explicit on how this applies to >> >> -#define NULL_CHECK0(e) if ((e) == 0) { \+#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ >> JLI_ReportErrorMessage(JNI_ERROR); \- return 0; \+ return rv; \ >> } >> -#define NULL_CHECK(e) if ((e) == 0) { \- JLI_ReportErrorMessage(JNI_ERROR); \- return; \- }+#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) >> +#define NULL_CHECK(e) NULL_CHECK_RV(e, )+ >> >> >> >> >> I would also be inclined to change >>> == 0 >>> to >>> == NULL >>> >>> >> Yes will take care of this, as well as Alan suggestion added a check for >> malloc return. >> >> >> This seems like another occasion to use the weird >>> >>> do { ... } while(0) >>> >>> trick to make the macro behave more like a statement. >>> >>> I might obfuscate the macro parameters to make collisions less likely, >>> e.g. e => N_C_RV_e >>> >> >> You want me to rename the macro parameter e to N_C_RV_e ? or something >> else >> say ncrve to avoid collision ? >> >> Kumar >> >> >> >>> >>> >>> >>> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan < >>> kumar.x.srinivasan at oracle.com> wrote: >>> >>>> Hi, >>>> >>>> Please review simple fixes for code correctness in the launcher. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>> >> >> > From peter.levart at gmail.com Thu May 2 18:27:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 02 May 2013 20:27:15 +0200 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: <5182B003.7030305@gmail.com> On 04/30/2013 04:57 PM, 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. > > 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? Hi Tomas, I don't know if this is the case here, but what if the ReferenceHandler thread is interrupted while wait()-ing and the construction of InterruptedException triggers OOME? Regards, Peter > 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 frederic.parain at oracle.com Thu May 2 18:27:23 2013 From: frederic.parain at oracle.com (frederic parain) Date: Thu, 02 May 2013 20:27:23 +0200 Subject: RFR: 7150256/8004095: Add back Remote Diagnostic Commands In-Reply-To: References: <517FF0C2.4040208@oracle.com> Message-ID: <5182B00B.9030007@oracle.com> Karen, Thank you for the review. 1. 2. and 3. have been fixed. Regarding 4. Most (all?) permissions have a name argument. However, if p._name is null, the string "(null)" is printed. This is not wrong, but not very pretty: Permission: MyPermission((null)). I've changed the code (both 105 and 109) with a short conditional: ... p._name == NULL ? "null" : p._name ... which gives a better output: Permission: MyPermission(null) Fred On 02/05/2013 18:37, Karen Kinnear wrote: > Frederic, > > Code looks good - actually it looks very clean. Ship it. > > Couple of minor comments that don't require re-review: > > 1. nmtDCmd.hpp/cpp - copyrights 2012 -> 2012, 2013 > > 2. jmm.h > line 213: "True is" -> "True if" > > 3. diagnosticFramework.hpp > Thank you for the comments! > line 298 "rational" -> "rationale" > > 4. diagnosticCommand.cpp > lines 105/109 - what prints if p._name is null? > > thanks, > Karen > > On Apr 30, 2013, at 12:26 PM, frederic parain wrote: > >> 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 > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From mike.duigou at oracle.com Thu May 2 18:29:22 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 2 May 2013 11:29:22 -0700 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: <3506B092-C05B-44D8-A67E-9ADCA52FFBD8@oracle.com> As a followup to this issue it's been pointed out that I pushed this patch with source-level set to "1.8" which is not supported by Netbeans 7.2 or 7.3. Source 1.8 is supported by the development version of Netbeans which is what I use primarily. There's a problem here: - The JDK repo now contains Java 8 source and over time will include much more Java 8 source (lambdas, default methods, static methods on interfaces, etc.). - The release versions of Netbeans don't understand Java 8 source. So we have to choose between using release versions of Netbeans and accept broken source parsing and using dev versions of Netbeans and the likely bugs (and missing extensions) that will be encountered. Should we change the source level back to 1.7 for now? My vote is "No", but I'm not the decider. Mike On Apr 29 2013, at 19:11 , 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 From martinrb at google.com Thu May 2 19:55:12 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 May 2013 12:55:12 -0700 Subject: RFR : 7178639 : (XXS) Remove incorrect documentation from Deque.push(E e) In-Reply-To: References: <785068FE-A26A-4C67-9B17-32D54C8B104C@oracle.com> Message-ID: My proposed changes are now in JSR166 CVS. Syncing work is needed before jdk8 ships! From tim.bell at oracle.com Thu May 2 20:24:02 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 May 2013 13:24:02 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51829725.9090406@oracle.com> References: <51829725.9090406@oracle.com> Message-ID: <5182CB62.30307@oracle.com> Hi Sundar: > Oracle JDK includes Rhino based javax.script implementation (which > lives mostly in "closed" code). Rhino is being removed from Oracle JDK > builds and there are the changes to the jdk open repository as well > like com.sun.script.javascript package, makefiles etc. Please review > the open jdk changes here: > > http://cr.openjdk.java.net/~sundar/8012975/ This looks good. Approved. Tim From kurchi.subhra.hazra at oracle.com Thu May 2 21:17:51 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 02 May 2013 21:17:51 +0000 Subject: hg: jdk8/tl/jdk: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Message-ID: <20130502211812.21CA248793@hg.openjdk.java.net> Changeset: 3062bf908281 Author: khazra Date: 2013-05-02 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062bf908281 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Summary: Remove buffer overruns in native code Reviewed-by: alanb, chegar ! src/solaris/native/java/net/NetworkInterface.c From dan.xu at oracle.com Thu May 2 23:08:37 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 02 May 2013 16:08:37 -0700 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5133BCD9.6060400@redhat.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> <5133BCD9.6060400@redhat.com> Message-ID: <5182F1F5.2030406@oracle.com> Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the compatibility issue, we cannot throw an exception immediately in the File constructors. So the failure is delayed and only shown up when any file operation is triggered. As for FileInputStream, FileOutputStream, and RandomAccessFile classes, the FileNotFoundException will be thrown right away since their spec allow this exception happen in the constructors. Thanks for your review! webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/ -Dan From brian.burkhalter at oracle.com Fri May 3 00:37:53 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 2 May 2013 17:37:53 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <518255DD.8000008@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> Message-ID: <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> On May 2, 2013, at 5:02 AM, Alan Bateman wrote: > On 02/05/2013 02:34, Tim Buktu wrote: >> : >> >> Alan is working on an improved BigInteger.toString() that should be >> dramatically faster for large numbers. What's the deadline for getting >> this in? >> Thanks, >> >> Tim > Here's the latest milestone dates: > > http://openjdk.java.net/projects/jdk8/milestones > > Given the size of the patch then it would be great to get it in as early as possible. With the review effort then I assume Feature Complete is too tight although I know Brian Burkhalter is anxious to get it in as soon as possible. I can't comment on the BigInteger.toString work to know how big this is. I think that's the best answer that can be given: as soon as possible. The 4837946 patch is far from simple to comprehend to say the least and then there is the testing so it's not going to be fast. If the toString() work is ready early enough to review then perhaps we can handle it, but I don't want to make anyone hurry to complete something and then say we cannot do it. Thanks, Brian From weijun.wang at oracle.com Fri May 3 02:44:40 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 03 May 2013 02:44:40 +0000 Subject: hg: jdk8/tl/jdk: 8013855: DigestMD5Client has not checked RealmChoiceCallback value Message-ID: <20130503024453.7B540487AC@hg.openjdk.java.net> Changeset: 81be41c7323f Author: weijun Date: 2013-05-03 10:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81be41c7323f 8013855: DigestMD5Client has not checked RealmChoiceCallback value Reviewed-by: xuelei, mullan ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java + test/com/sun/security/sasl/digest/AuthRealmChoices.java From xueming.shen at oracle.com Fri May 3 04:29:03 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 May 2013 21:29:03 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Message-ID: <51833D0F.1070003@oracle.com> Hi, Please help review the proposed fix for 8012326. The direct trigger is the fix we put in #6898310 [1], in which we added the synchronization to prevent a possible race condition as described in $4685305. However it appears the added synchronization triggers another race condition as showed in this stack trace [4] when run the test case [2][3]. The root cause here is (1) The ExtendedCharsetProvider is intended to be used as a singleton (as the probeExtendedProvider + lookupExtendedCharset mechanism in Charset.java), however this is only true for the Charset.forName()->lookup()...scenario. Multiple instances of ExtendedCharsetProvider is being created in Charset.availableCharset() every time it is invoked, via providers()/ServiceLoader.load(). (2) ISO2022_JP_2 and MSISO2022JP are provided via ExtendedCharsetProvider, however both of them have two static variable DEC02{12|08}/ENC02{12|08} that need to be initialized during the "class initialization", which will indirectly trigger the invocation of ExtendedCharsetProvider.alisesFor(...) (3) static method ExtendedCharsets.aliaseFor() has a hacky implementation that goes to AbstractCharsetProvider.alise() for lookup, which needs to obtain a lock on its ExtendedCharesetProvider.instance. This will potential cause race condition if the "instance" it tries to synchronize on is not its "own" instance. This is possible because the constructor of ExtendedCharsetProvider overwrites static "instance" variable with "this". Unfortunately as demonstrated in [4], this appears to be what is happening. The Thread-1/#9 is trying to synchronize on someone else's ExtendedCharsetProvider instance <0xa4824730> (its own instance should be <0xa4835328>, which it holds the monitor in the iterator.next()), it is blocked because Thread-0 already holds the monitor of <0xa4824730> (in its iteratior.next()), but Thread-0 is blocked at Class.forName0(), which I think is because Thread-1 is inside it already...two theads are deadlocked. A "quick fix/solution" is to remove the direct trigger in ISO2022_JP_2 and MSISO2022JP to lazily-initialize those static variables as showed in the webrev. However while this probably will solve the race condition, the multiple instances of ExtendedCharsetProvider is really not desired. And given the fact we have already hardwired ExtendedCharsetProvider (as well as the StandardCharset, for performance reason) for charset lookup/forName(), the availableCharsets() should also utilize the "singleton" ExtendedCharsetProvider instanc (extendedCharsetProvider) as well, instead of going to the ServiceLoader every time for a new instance. The suggested change is to use Charset. extendedCharsetProvide via probeExtendedProvider() for extended charset iteration (availableCharset()). Meanwhile, since the ExtendedCharsetProvider/ charsets.jar should always be in the boot classpath (if installed, and we are looking up via Class.forName("sun.nio.cs.ext.ExtededCharsetProvider")), there is really no need for it to be looked up/loaded via the spi mechanism (in fact it's redundant to load it again after we have lookup/iterate the hardwired "extendedCharsetProvider". So I removed the spi description from the charsts.jar as well. An alternative is to really implement the singleton pattern in ECP, however given the existing mechanism we have in Charset.java and the "hacky" init() implementation we need in ECP, I go with the current approach. http://cr.openjdk.java.net/~sherman/8012326/webrev Thanks, Sherman [1] http://cr.openjdk.java.net/~sherman/6898310/webrev/ [2] http://cr.openjdk.java.net/~sherman/8012326/runtest.bat [3] http://cr.openjdk.java.net/~sherman/8012326/Test.java [4] http://cr.openjdk.java.net/~sherman/8012326/stacktrace From tim.bell at oracle.com Fri May 3 06:23:51 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 May 2013 23:23:51 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5182CB62.30307@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> Message-ID: <518357F7.80203@oracle.com> On 05/ 2/13 01:24 PM, I wrote: > Hi Sundar: > >> Oracle JDK includes Rhino based javax.script implementation (which >> lives mostly in "closed" code). Rhino is being removed from Oracle >> JDK builds and there are the changes to the jdk open repository as >> well like com.sun.script.javascript package, makefiles etc. Please >> review the open jdk changes here: >> >> http://cr.openjdk.java.net/~sundar/8012975/ > > This looks good. Approved. > > Tim Sundar - we have had some breakage in the build forest recently, so to be extra careful I created a forest and then added your changes. I also did some blasting away with 'find ... -print | xargs egrep ...' commands to look for traces of rhino or javascript. I think you need to look at removing these files as well: jdk/make/com/sun/script/Makefile jdk/make/sun/org/mozilla/javascript/Makefile Tim From jaroslav.bachorik at oracle.com Fri May 3 06:24:33 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Fri, 03 May 2013 06:24:33 +0000 Subject: hg: jdk8/tl/jdk: 7199324: Connection ID for IPv6 addresses is not generated accordingly to the specification Message-ID: <20130503062446.788CD487BA@hg.openjdk.java.net> Changeset: 470f19b6bfdd Author: jbachorik Date: 2013-05-02 13:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/470f19b6bfdd 7199324: Connection ID for IPv6 addresses is not generated accordingly to the specification Summary: RemoteServer.getClientHost is returning a String with an IPv6 literal address and we need to enclose it in [] when building the connection id Reviewed-by: alanb, sjiang ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java From sundararajan.athijegannathan at oracle.com Fri May 3 06:47:50 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 03 May 2013 12:17:50 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518357F7.80203@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> Message-ID: <51835D96.3060209@oracle.com> On Friday 03 May 2013 11:53 AM, Tim Bell wrote: > On 05/ 2/13 01:24 PM, I wrote: >> Hi Sundar: >> >>> Oracle JDK includes Rhino based javax.script implementation (which >>> lives mostly in "closed" code). Rhino is being removed from Oracle >>> JDK builds and there are the changes to the jdk open repository as >>> well like com.sun.script.javascript package, makefiles etc. Please >>> review the open jdk changes here: >>> >>> http://cr.openjdk.java.net/~sundar/8012975/ >> >> This looks good. Approved. >> >> Tim > > Sundar - we have had some breakage in the build forest recently, so to > be extra careful I created a forest and then added your changes. I > also did some blasting away with 'find ... -print | xargs egrep ...' > commands to look for traces of rhino or javascript. > > I think you need to look at removing these files as well: > > jdk/make/com/sun/script/Makefile > jdk/make/sun/org/mozilla/javascript/Makefile > > Tim > Thanks. Looks like the first one has not been removed. But second one was removed: hg stat shows R make/sun/org/mozilla/javascript/Makefile (also the webrev shows it as removed). Perhaps patch does not take care of deleted files?? I am not sure. Also, build seems to go through without removing first one!! I'll remove that, build/test again and send another webrev. Thanks -Sundar From huizhe.wang at oracle.com Fri May 3 08:01:23 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 03 May 2013 01:01:23 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <516FC044.4070803@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> Message-ID: <51836ED3.3050600@oracle.com> Hi Alan, Lance, This is an update that reflects the spec change, and also fixes for JDK-8013232 and JDK-8013484. Please review: http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ Thanks, Joe On 4/18/2013 2:43 AM, huizhe wang wrote: > > 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 paul.sandoz at oracle.com Fri May 3 09:10:12 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 May 2013 11:10:12 +0200 Subject: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit Message-ID: Hi, Please review the patch below for some minor fixes to the Spltierator JavaDoc and a tweak to the spec of Spliterator.trySplit. http://bugs.sun.com/view_bug.do?bug_id=8013334 Paul. # HG changeset patch # User psandoz # Date 1367571917 -7200 # Node ID fda6ca78a7c299349f201c310ec480351a855ed1 # Parent 470f19b6bfdd07aed3ca6e0debdabcd8cd7f8083 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit Summary: In addition to fixing 8013334 this changeset containts some minor, non spec, related fixes to tidy up other areas of the JavaDoc. Reviewed-by: Contributed-by: John Rose , Mike Duigou , Paul Sandoz diff -r 470f19b6bfdd -r fda6ca78a7c2 src/share/classes/java/util/Spliterator.java --- a/src/share/classes/java/util/Spliterator.java Thu May 02 13:21:09 2013 +0200 +++ b/src/share/classes/java/util/Spliterator.java Fri May 03 11:05:17 2013 +0200 @@ -140,32 +140,32 @@ * (in approximate order of decreasing desirability): *
        *
      • The source cannot be structurally interfered with. - *
        For example, an instance of + *
        For example, an instance of * {@link java.util.concurrent.CopyOnWriteArrayList} is an immutable source. * A Spliterator created from the source reports a characteristic of * {@code IMMUTABLE}.
      • *
      • The source manages concurrent modifications. - *
        For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} + *
        For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} * is a concurrent source. A Spliterator created from the source reports a * characteristic of {@code CONCURRENT}.
      • *
      • The mutable source provides a late-binding and fail-fast Spliterator. - *
        Late binding narrows the window during which interference can affect + *
        Late binding narrows the window during which interference can affect * the calculation; fail-fast detects, on a best-effort basis, that structural * interference has occurred after traversal has commenced and throws * {@link ConcurrentModificationException}. For example, {@link ArrayList}, * and many other non-concurrent {@code Collection} classes in the JDK, provide * a late-binding, fail-fast spliterator.
      • *
      • The mutable source provides a non-late-binding but fail-fast Spliterator. - *
        The source increases the likelihood of throwing + *
        The source increases the likelihood of throwing * {@code ConcurrentModificationException} since the window of potential * interference is larger.
      • *
      • The mutable source provides a late-binding and non-fail-fast Spliterator. - *
        The source risks arbitrary, non-deterministic behavior after traversal + *
        The source risks arbitrary, non-deterministic behavior after traversal * has commenced since interference is not detected. *
      • *
      • The mutable source provides a non-late-binding and non-fail-fast * Spliterator. - *
        The source increases the risk of arbitrary, non-deterministic behavior + *
        The source increases the risk of arbitrary, non-deterministic behavior * since non-detected interference may occur after construction. *
      • *
      @@ -284,6 +284,8 @@ * is set to {@code true} then diagnostic warnings are reported if boxing of * primitive values occur when operating on primitive subtype specializations. * + * @param the type of elements returned by this Spliterator + * * @see Collection * @since 1.8 */ @@ -333,9 +335,8 @@ * Upon non-null return: *
        *
      • the value reported for {@code estimateSize()} before splitting, - * if not already zero or {@code Long.MAX_VALUE}, must, after splitting, be - * greater than {@code estimateSize()} for this and the returned - * Spliterator; and
      • + * must, after splitting, be greater than or equal to {@code estimateSize()} + * for this and the returned Spliterator; and *
      • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} * for this spliterator before splitting must be equal to the sum of * {@code estimateSize()} for this and the returned Spliterator after From Alan.Bateman at oracle.com Fri May 3 09:26:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 May 2013 10:26:09 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51835D96.3060209@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> Message-ID: <518382B1.6040501@oracle.com> On 03/05/2013 07:47, A. Sundararajan wrote: > > Thanks. Looks like the first one has not been removed. But second one > was removed: hg stat shows > > R make/sun/org/mozilla/javascript/Makefile > > (also the webrev shows it as removed). Perhaps patch does not take > care of deleted files?? I am not sure. Also, build seems to go through > without removing first one!! > > I'll remove that, build/test again and send another webrev. One other one is make/tools/src/build/tools/deps/refs.allowed. The last two lines can be replaced with: java.beans.PropertyChangeListener=java.util.logging.LogManager,compact1,compact2,compact3 and the comment line about Rhino can be removed. -Alan. From peter.levart at gmail.com Fri May 3 10:07:52 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 May 2013 12:07:52 +0200 Subject: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit In-Reply-To: References: Message-ID: <51838C78.3020505@gmail.com> Hi Paul, Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces either null+N or n+m (n *
      • the value reported for {@code estimateSize()} before splitting, * must, after splitting, be greater than {@code estimateSize()} * for this and greater than or equal than {@code estimateSize()} * for the returned Spliterator; and
      • *
      • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} * for this spliterator before splitting must be equal to the sum of * {@code estimateSize()} for this and the returned Spliterator after Regards, Peter On 05/03/2013 11:10 AM, Paul Sandoz wrote: > Hi, > > Please review the patch below for some minor fixes to the Spltierator JavaDoc and a tweak to the spec of Spliterator.trySplit. > > http://bugs.sun.com/view_bug.do?bug_id=8013334 > > Paul. > > # HG changeset patch > # User psandoz > # Date 1367571917 -7200 > # Node ID fda6ca78a7c299349f201c310ec480351a855ed1 > # Parent 470f19b6bfdd07aed3ca6e0debdabcd8cd7f8083 > 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit > Summary: In addition to fixing 8013334 this changeset containts some minor, > non spec, related fixes to tidy up other areas of the JavaDoc. > Reviewed-by: > Contributed-by: John Rose , Mike Duigou , > Paul Sandoz > > diff -r 470f19b6bfdd -r fda6ca78a7c2 src/share/classes/java/util/Spliterator.java > --- a/src/share/classes/java/util/Spliterator.java Thu May 02 13:21:09 2013 +0200 > +++ b/src/share/classes/java/util/Spliterator.java Fri May 03 11:05:17 2013 +0200 > @@ -140,32 +140,32 @@ > * (in approximate order of decreasing desirability): > *
          > *
        • The source cannot be structurally interfered with. > - *
          For example, an instance of > + *
          For example, an instance of > * {@link java.util.concurrent.CopyOnWriteArrayList} is an immutable source. > * A Spliterator created from the source reports a characteristic of > * {@code IMMUTABLE}.
        • > *
        • The source manages concurrent modifications. > - *
          For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} > + *
          For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} > * is a concurrent source. A Spliterator created from the source reports a > * characteristic of {@code CONCURRENT}.
        • > *
        • The mutable source provides a late-binding and fail-fast Spliterator. > - *
          Late binding narrows the window during which interference can affect > + *
          Late binding narrows the window during which interference can affect > * the calculation; fail-fast detects, on a best-effort basis, that structural > * interference has occurred after traversal has commenced and throws > * {@link ConcurrentModificationException}. For example, {@link ArrayList}, > * and many other non-concurrent {@code Collection} classes in the JDK, provide > * a late-binding, fail-fast spliterator.
        • > *
        • The mutable source provides a non-late-binding but fail-fast Spliterator. > - *
          The source increases the likelihood of throwing > + *
          The source increases the likelihood of throwing > * {@code ConcurrentModificationException} since the window of potential > * interference is larger.
        • > *
        • The mutable source provides a late-binding and non-fail-fast Spliterator. > - *
          The source risks arbitrary, non-deterministic behavior after traversal > + *
          The source risks arbitrary, non-deterministic behavior after traversal > * has commenced since interference is not detected. > *
        • > *
        • The mutable source provides a non-late-binding and non-fail-fast > * Spliterator. > - *
          The source increases the risk of arbitrary, non-deterministic behavior > + *
          The source increases the risk of arbitrary, non-deterministic behavior > * since non-detected interference may occur after construction. > *
        • > *
        > @@ -284,6 +284,8 @@ > * is set to {@code true} then diagnostic warnings are reported if boxing of > * primitive values occur when operating on primitive subtype specializations. > * > + * @param the type of elements returned by this Spliterator > + * > * @see Collection > * @since 1.8 > */ > @@ -333,9 +335,8 @@ > * Upon non-null return: > *
          > *
        • the value reported for {@code estimateSize()} before splitting, > - * if not already zero or {@code Long.MAX_VALUE}, must, after splitting, be > - * greater than {@code estimateSize()} for this and the returned > - * Spliterator; and
        • > + * must, after splitting, be greater than or equal to {@code estimateSize()} > + * for this and the returned Spliterator; and > *
        • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} > * for this spliterator before splitting must be equal to the sum of > * {@code estimateSize()} for this and the returned Spliterator after From joel.franck at oracle.com Fri May 3 12:17:29 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 03 May 2013 14:17:29 +0200 Subject: RFR 8007073: Implement Core Reflection for Type Annotations on parameters Message-ID: <5183AAD9.2060805@oracle.com> Hello all, Here is an update to core reflection for type annotations adding support for reflecting over annotated type use on parameters. http://cr.openjdk.java.net/~jfranck/8007073/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007073 cheers /Joel From joel.franck at oracle.com Fri May 3 12:35:22 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 03 May 2013 14:35:22 +0200 Subject: RFR 8013541: Revise javadoc for Executable.getAnnotatedReturnType() Message-ID: <5183AF0A.7050802@oracle.com> Hello all, Also a small update to the javadoc of Executable to make it more consistent for type annotations. http://cr.openjdk.java.net/~jfranck/8013541/webrev.00/ For oracle reviewers, CCC is filed. cheers /Joel From Alan.Bateman at oracle.com Fri May 3 13:48:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 May 2013 14:48:11 +0100 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5182F1F5.2030406@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> <5133BCD9.6060400@redhat.com> <5182F1F5.2030406@oracle.com> Message-ID: <5183C01B.6080105@oracle.com> On 03/05/2013 00:08, Dan Xu wrote: > Hi All, > > Thanks for all your comments. Based on the previous feedback, I have > moved to the other approach, i.e., to fail file operations if the > invalid NUL characher is found in a file path. As you know, due to the > compatibility issue, we cannot throw an exception immediately in the > File constructors. So the failure is delayed and only shown up when > any file operation is triggered. > > As for FileInputStream, FileOutputStream, and RandomAccessFile > classes, the FileNotFoundException will be thrown right away since > their spec allow this exception happen in the constructors. Thanks for > your review! > > webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/ > > -Dan > This looks much better. I guess a Boolean would have worked as well as adding the PathStatus enum but what you have seems okay. It would be good to get Sherman's confirmation that we don't need to be concerned about anything else encoding to include NUL. -Alan. From Alan.Bateman at oracle.com Fri May 3 14:18:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 May 2013 15:18:53 +0100 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <51833D0F.1070003@oracle.com> References: <51833D0F.1070003@oracle.com> Message-ID: <5183C74D.4040207@oracle.com> On 03/05/2013 05:29, Xueming Shen wrote: > : > > An alternative is to really implement the singleton pattern in ECP, > however > given the existing mechanism we have in Charset.java and the "hacky" > init() > implementation we need in ECP, I go with the current approach. > > http://cr.openjdk.java.net/~sherman/8012326/webrev I'm not sure that I understand your comment, are you saying that the initialize-on-demand holder idiom wouldn't work here? I would think it should make it simpler and easier to understand. For the ISO2022_JP_2 and MSISO2022JP then they probably don't need to be volatile. As it stands then the fields may get written more than once (which is harmless). -Alan. From Alan.Bateman at oracle.com Fri May 3 14:49:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 May 2013 15:49:21 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <51836ED3.3050600@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> Message-ID: <5183CE71.6070003@oracle.com> On 03/05/2013 09:01, huizhe wang wrote: > Hi Alan, Lance, > > This is an update that reflects the spec change, and also fixes for > JDK-8013232 and JDK-8013484. > > Please review: > http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ > I've read through the javadoc/spec changes. One comment is that there is a lot of repetition. The syntax of the property value is defined in no less than 9 places. At least for the setAttribute methods, then couldn't these just reference the properties in XMLConstants? One suggestion for "Default value: implementations shall decide whether to restrict connection by default ...." and the options list. is to replace it with: "The default value is implementation specific and therefore not specified. Implementations are highly recommend to restrict external connections by default when FEATURE_SECURE_PROCESSING is set to true." For ACCESS_EXTERNAL_DTD then this statement isn't clear: "Restrict access to external DTDs, external Entity References to the protocols specified." Should "external Entity References" be dropped here, or "," replaced with "and"? -Alan. From xueming.shen at oracle.com Fri May 3 15:12:50 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 May 2013 08:12:50 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <5183C74D.4040207@oracle.com> References: <51833D0F.1070003@oracle.com> <5183C74D.4040207@oracle.com> Message-ID: <5183D3F2.5030209@oracle.com> On 5/3/13 7:18 AM, Alan Bateman wrote: > On 03/05/2013 05:29, Xueming Shen wrote: >> : >> >> An alternative is to really implement the singleton pattern in ECP, >> however >> given the existing mechanism we have in Charset.java and the "hacky" >> init() >> implementation we need in ECP, I go with the current approach. >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev > I'm not sure that I understand your comment, are you saying that the > initialize-on-demand holder idiom wouldn't work here? I would think it > should make it simpler and easier to understand. I meant the proposed the change does not change how the Charset.forName() works, which we also had race condition problem in the past. I can go with a complete re-work if you prefer to. I was thinking of re-workng the ECP during the investigation, I got couple other issues with it as well. But decided to go the easy way given I still have bunch other bugs to go after for jdk8. -Sherman > > For the ISO2022_JP_2 and MSISO2022JP then they probably don't need to > be volatile. As it stands then the fields may get written more than > once (which is harmless). > > -Alan. From xueming.shen at oracle.com Fri May 3 15:43:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 May 2013 08:43:36 -0700 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5183C01B.6080105@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> <5133BCD9.6060400@redhat.com> <5182F1F5.2030406@oracle.com> <5183C01B.6080105@oracle.com> Message-ID: <5183DB28.8010309@oracle.com> On 5/3/13 6:48 AM, Alan Bateman wrote: > On 03/05/2013 00:08, Dan Xu wrote: >> Hi All, >> >> Thanks for all your comments. Based on the previous feedback, I have >> moved to the other approach, i.e., to fail file operations if the >> invalid NUL characher is found in a file path. As you know, due to >> the compatibility issue, we cannot throw an exception immediately in >> the File constructors. So the failure is delayed and only shown up >> when any file operation is triggered. >> >> As for FileInputStream, FileOutputStream, and RandomAccessFile >> classes, the FileNotFoundException will be thrown right away since >> their spec allow this exception happen in the constructors. Thanks >> for your review! >> >> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/ >> >> -Dan >> > This looks much better. I guess a Boolean would have worked as well as > adding the PathStatus enum but what you have seems okay. > > It would be good to get Sherman's confirmation that we don't need to > be concerned about anything else encoding to include NUL. > > -Alan. > > The change looks fine. I don't see any encoding issue, though this reminds me one possible use scenario. Do we want to make it path "valid", if the NUL is at the end of the path? This should not been an issue normally though, everything from the native does not have it. Just wonder if this scenario might work before (?), with no potential vuln risk (?), we may want to keep it? No, I don't know any real code has the NUL attached to the end, just a wild guess. It's definitely fine to wait for any complain, if there will be, and then react. -Sherman From frederic.parain at oracle.com Fri May 3 16:43:13 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 03 May 2013 18:43:13 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <51783B80.5010807@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> Message-ID: <5183E921.7020209@oracle.com> Hi all, After an intense work with Mandy, here's a new webrev which fix the issue with the PlatformManagedObject specification. The DiagnosticCommandMBean is not a PlatformManagedObject anymore, it's just a DynamicMBean registered to the platform MBean server. Many smaller fixes have also been done based on provided feedback. http://cr.openjdk.java.net/~fparain/7150256/webrev.07/ Thanks, Fred On 24/04/2013 22:07, Mandy Chung wrote: > 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 -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From jonathan.gibbons at oracle.com Fri May 3 16:57:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 16:57:40 +0000 Subject: hg: jdk8/tl/langtools: 8012728: Normalize @ignore comments on langtools tests Message-ID: <20130503165746.D12F5487F0@hg.openjdk.java.net> Changeset: abd153854f16 Author: jjg Date: 2013-05-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abd153854f16 8012728: Normalize @ignore comments on langtools tests Reviewed-by: vromero, mcimadamore ! test/com/sun/javadoc/_template/Template.java ! test/com/sun/javadoc/_template/TemplateComplete.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/OverrideBridge.java ! test/tools/javac/lambda/TargetType36.java ! test/tools/javac/lambda/TargetType53.java ! test/tools/javac/lambda/TargetType54.java ! test/tools/javac/lambda/TargetType58.java ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/output/Tester.java From daniel.fuchs at oracle.com Fri May 3 17:13:29 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 03 May 2013 19:13:29 +0200 Subject: JDK-8011653: Upgrade to JAXP 1.5 Message-ID: <5183F039.3010805@oracle.com> Hi Joe, I am not a JAXP expert - so I've been discovering most of this code as I read it. It would be impossible for me to assess whether there's some setFeature or setProperty missing somewhere for instance. So with my limited knowledge I have only these few remarks: ========== 1. XalanConstants.java: javadoc ORACLE_FEATURE_SERVICE_MECHANISM: "instructs the implementation to use service mechanism to find implementation" That sounds a bit cryptic to my ears. Would something like: "true: instruct an object to use service mechanism to find a service implementation" "false: instruct an object to skip service mechanism and use the default implementation for that service" work better? (disclaimer: I am not a native English speaker.) ========== 2. 773 //JAXP 1.5 properties 774 if (propertyId.startsWith(Constants.JAXPAPI_PROPERTY_PREFIX)) { 775 if (propertyId.equals(ACCESS_EXTERNAL_DTD)) 776 { 777 fAccessExternalDTD = (String)value; 778 } 779 } The first line (startsWith(...) seems useless. When I saw this lines of code - I first thought there was a bug - expecting ACCESS_EXTERNAL_DTD to be a suffix like in the lines just before. =========== 3. Same remark than 2. with: (lines 1643-1650) =========== 4. same class as above: what is the story with this "Zephyr feature ignore-external-dtd" ? Namely I'm puzzled as to why in one case we check only the Zephyr feature, and in another case we check only the Xerces feature. Shouldn't both be checked? I mean - are we sure that nobody can call something like: PropertyManager propertyManager = ...; propertyManager.setFeature(LOAD_EXTERNAL_DTD, false); ========== -- daniel From jonathan.gibbons at oracle.com Fri May 3 17:17:25 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 17:17:25 +0000 Subject: hg: jdk8/tl/langtools: 8002387: Improve rendered HTML formatting for {@code} Message-ID: <20130503171727.C503F487F1@hg.openjdk.java.net> Changeset: 38c4bade0ec1 Author: jjg Date: 2013-05-03 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38c4bade0ec1 8002387: Improve rendered HTML formatting for {@code} Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javadoc/Comment.java + test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java + test/com/sun/javadoc/testLiteralCodeInPre/pkg/Test.java From thomas.schatzl at oracle.com Fri May 3 17:47:56 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 May 2013 19:47:56 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <5182B003.7030305@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> Message-ID: <1367603276.4723.7.camel@cirrus> Hi, > > Hi Tomas, > > I don't know if this is the case here, but what if the > ReferenceHandler thread is interrupted while wait()-ing and the > construction of InterruptedException triggers OOME? I am sure this is the case - previously I thought InterruptedException is a preallocated exception like others. ObjectMonitor::wait() may throw it, by creating new InterruptedException instances. Thanks! Now that we've found the very likely cause, what to do about it? The current state of silently crashing the reference handler thread is unsatisfying imo as it leads to very hard to find problems. The options I see all involve catching this (or any other OOME caused by other means like the test program) and either recovering as much as possible or exiting the VM (like in the sun.misc.Cleaner handling). Any other suggestions? Thanks, Thomas From mike.duigou at oracle.com Fri May 3 18:00:50 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 3 May 2013 11:00:50 -0700 Subject: RFR : 8013528 : (XS) Provide SharedSecrets access to String(char[], boolean) constructor In-Reply-To: References: <72DBF93B-D857-4880-B95C-FCAA2EA43A20@oracle.com> <2F3D8AF2-0C1C-4493-8F26-C347B321BA67@oracle.com> Message-ID: On Apr 30 2013, at 23:41 , Peter Levart wrote: > Hi Mike, > > Some comments about the test... > > 40 String benchmark = "exemplar"; > 41 String constructorCopy = new String(benchmark); > 42 String jlaCopy = jla.newStringUnsafe(benchmark.toCharArray()); > 43 > 44 if (constructorCopy == constructorCopy) { > 45 throw new Error("should be different instances"); > 46 } > Wouldn't this always throw error? You really wanted to test benchmark == constructorCopy, right? Argh, yes. I forgot a hg qrefresh before generating the webrev. This was corrected in my local copy. > To check whether the jlaCopy is really taking the given char array by reference, a test could also do something "illegal" like: > > > char[] array = benchmark.toCharArray(); > String jlaCopy = jla.newStringUnsafe(array); > array[0] = "X"; // ouch! > String constructorCopy = new String(array); > > if (!constructorCopy.equals(jlaCopy)) { ... } > > Regards, Peter > I have added an "evil" test to check exactly that. I'm pleased to be able to include you an official reviewer. :-) Thanks, Mike > > > > 2013/5/1 Mike Duigou > 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 > > From huizhe.wang at oracle.com Fri May 3 18:02:53 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 03 May 2013 11:02:53 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5183CE71.6070003@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> Message-ID: <5183FBCD.5060908@oracle.com> On 5/3/2013 7:49 AM, Alan Bateman wrote: > On 03/05/2013 09:01, huizhe wang wrote: >> Hi Alan, Lance, >> >> This is an update that reflects the spec change, and also fixes for >> JDK-8013232 and JDK-8013484. >> >> Please review: >> http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ >> > I've read through the javadoc/spec changes. > > One comment is that there is a lot of repetition. The syntax of the > property value is defined in no less than 9 places. At least for the > setAttribute methods, then couldn't these just reference the > properties in XMLConstants? Removed the repetitive "value" definition from the setAttribute/setProperty methods. The open statements already have references to the properties in XMLConstants. > > One suggestion for > > "Default value: implementations shall decide whether to restrict > connection by default ...." and the options list. > > is to replace it with: > > "The default value is implementation specific and therefore not > specified. Implementations are highly recommend to restrict external > connections by default when FEATURE_SECURE_PROCESSING is set to true." Updated to: "The default value is implementation specific and therefore not specified. The following options are provided for consideration:" The 2nd paragraph already had the "recommendation" when FSP is set to true (same as in the JEP). > > > For ACCESS_EXTERNAL_DTD then this statement isn't clear: > > "Restrict access to external DTDs, external Entity References to the > protocols specified." > > Should "external Entity References" be dropped here, or "," replaced > with "and"? Yes, both. Replaced "," with "and". Thanks, Joe > > -Alan. > > > > > From mandy.chung at oracle.com Fri May 3 18:02:51 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 May 2013 11:02:51 -0700 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <5183E921.7020209@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> Message-ID: <5183FBCB.2030902@oracle.com> Frederic, This looks good. Thanks for the update and also move the native method and implementations to DiagnosticCommandImpl.c and removing the check for rdcmd_support which is much cleaner. Minor comment: DiagnosticCommandImpl.Wrapper constructor - it'd be good to catch the exception causing the instantiation of permission instance to fail and set it to the cause of InstantiationException. Looks like InstantiationException doesn't take cause in the constructor and you would have to call initCause() before throwing it. No need to generate the new webrev for this minor fix. Ship it when you're ready. As we discussed offline, you will file bugs to follow up the following issues: 1. PlatformManagedObject should be updated to include DynamicMBean as a platform mbean and DiagnosticCommandMBean will implement PlatformManagedObject. ManagementFactory may provide new method to obtain platform dynamic mbean. 2. Investigate what DiagnosticCommandImpl.getAttributes and setAttributes should do per DynamicMBean spec. The current implementation throws UOE which seem to be okay. It's good to confirm what is specified or not specified per DynamicMBean spec Thanks Mandy On 5/3/2013 9:43 AM, frederic parain wrote: > Hi all, > > After an intense work with Mandy, here's a new webrev which > fix the issue with the PlatformManagedObject specification. > The DiagnosticCommandMBean is not a PlatformManagedObject > anymore, it's just a DynamicMBean registered to the platform > MBean server. Many smaller fixes have also been done based > on provided feedback. > > http://cr.openjdk.java.net/~fparain/7150256/webrev.07/ > > Thanks, > > Fred > > On 24/04/2013 22:07, Mandy Chung wrote: >> 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 huizhe.wang at oracle.com Fri May 3 18:04:17 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 03 May 2013 11:04:17 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5183F039.3010805@oracle.com> References: <5183F039.3010805@oracle.com> Message-ID: <5183FC21.5030104@oracle.com> On 5/3/2013 10:13 AM, Daniel Fuchs wrote: > Hi Joe, > > I am not a JAXP expert - so I've been discovering most > of this code as I read it. It would be impossible for me > to assess whether there's some setFeature or setProperty > missing somewhere for instance. So with my limited > knowledge I have only these few remarks: > > > ========== > > 1. XalanConstants.java: javadoc ORACLE_FEATURE_SERVICE_MECHANISM: > > "instructs the implementation to use service mechanism to find > implementation" > > That sounds a bit cryptic to my ears. Would something like: > > "true: instruct an object to use service mechanism to > find a service implementation" > > "false: instruct an object to skip service mechanism and > use the default implementation for that service" > > work better? (disclaimer: I am not a native English speaker.) Yes. Updated using the above. > > ========== > > 2. > > > 773 //JAXP 1.5 properties > 774 if > (propertyId.startsWith(Constants.JAXPAPI_PROPERTY_PREFIX)) { > 775 if (propertyId.equals(ACCESS_EXTERNAL_DTD)) > 776 { > 777 fAccessExternalDTD = (String)value; > 778 } > 779 } > > > The first line (startsWith(...) seems useless. > When I saw this lines of code - I first thought there was a > bug - expecting ACCESS_EXTERNAL_DTD to be a suffix like > in the lines just before. I was following the tradition of the original impl where properties such as those from Xerces were grouped together. I was thinking there would be other JAXP API properties in the future. > > =========== > > 3. Same remark than 2. with: > > > > (lines 1643-1650) > > > =========== > > 4. same class as above: what is the story with this > "Zephyr feature ignore-external-dtd" ? > > Namely I'm puzzled as to why in one case we check only > the Zephyr feature, and in another case we check only the > Xerces feature. > > Shouldn't both be checked? > > I mean - are we sure that nobody can call something like: > > PropertyManager propertyManager = ...; > propertyManager.setFeature(LOAD_EXTERNAL_DTD, false); This is the result of integrating Zephyr (Sun's StAX impl) into the JDK (since 1.6). Zephyr uses a PropertyManager rather than Xerces' XMLComponentManager. No, PropertyManager is internal to the implementation. Thanks! Joe > > > ========== > > -- daniel From daniel.fuchs at oracle.com Fri May 3 18:19:54 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 03 May 2013 20:19:54 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <5183FBCB.2030902@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> Message-ID: <5183FFCA.1090108@oracle.com> Hi, On 5/3/13 8:02 PM, Mandy Chung wrote: > 2. Investigate what DiagnosticCommandImpl.getAttributes and > setAttributes should do per DynamicMBean spec. The current > implementation throws UOE which seem to be okay. It's good to confirm > what is specified or not specified per DynamicMBean spec By analogy with what the MBeanServerConnection says and what the StandardMBean class does, I'd say that the expected behavior would be to return an empty AttributeList for both methods. See: and -- daniel > > Thanks > Mandy From mandy.chung at oracle.com Fri May 3 18:30:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 May 2013 11:30:24 -0700 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <5183FFCA.1090108@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> <5183FFCA.1090108@oracle.com> Message-ID: <51840240.4060705@oracle.com> On 5/3/2013 11:19 AM, Daniel Fuchs wrote: > Hi, > > On 5/3/13 8:02 PM, Mandy Chung wrote: >> 2. Investigate what DiagnosticCommandImpl.getAttributes and >> setAttributes should do per DynamicMBean spec. The current >> implementation throws UOE which seem to be okay. It's good to confirm >> what is specified or not specified per DynamicMBean spec > > By analogy with what the MBeanServerConnection says and what > the StandardMBean class does, I'd say that the expected behavior > would be to return an empty AttributeList for both methods. Thanks Daniel. I initially thought that these 2 methods should return an empty AttributeList. MBeanServerConnection specifies clearly that missing attribute will be omitted and the caller will use the returned value to determine any missing attribute. It makes sense to expect DynamicMBean.get/setAttributes the same behavior as MBS forwards the call to the mbeans. Frederic - you can simply fix this to return an empty AttributeList. Can you also file a bug for DynamicMBean to clarify the expected behavior in the specification? Thanks Mandy > > See: > > > > and > > > > -- daniel > >> >> Thanks >> Mandy > From frederic.parain at oracle.com Fri May 3 18:31:45 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 03 May 2013 20:31:45 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <5183FBCB.2030902@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> Message-ID: <51840291.8020506@oracle.com> Thank you Mandy, I'll file the bugs and fix the exception cause. Fred On 03/05/2013 20:02, Mandy Chung wrote: > Frederic, > > This looks good. Thanks for the update and also move the native method > and implementations to DiagnosticCommandImpl.c and removing the check > for rdcmd_support which is much cleaner. > > Minor comment: > DiagnosticCommandImpl.Wrapper constructor - it'd be good to catch the > exception causing the instantiation of permission instance to fail and > set it to the cause of InstantiationException. Looks like > InstantiationException doesn't take cause in the constructor and you > would have to call initCause() before throwing it. > > No need to generate the new webrev for this minor fix. Ship it when > you're ready. > > As we discussed offline, you will file bugs to follow up the following > issues: > 1. PlatformManagedObject should be updated to include DynamicMBean as a > platform mbean and DiagnosticCommandMBean will implement > PlatformManagedObject. ManagementFactory may provide new method to > obtain platform dynamic mbean. > > 2. Investigate what DiagnosticCommandImpl.getAttributes and > setAttributes should do per DynamicMBean spec. The current > implementation throws UOE which seem to be okay. It's good to confirm > what is specified or not specified per DynamicMBean spec > > Thanks > Mandy > > On 5/3/2013 9:43 AM, frederic parain wrote: >> Hi all, >> >> After an intense work with Mandy, here's a new webrev which >> fix the issue with the PlatformManagedObject specification. >> The DiagnosticCommandMBean is not a PlatformManagedObject >> anymore, it's just a DynamicMBean registered to the platform >> MBean server. Many smaller fixes have also been done based >> on provided feedback. >> >> http://cr.openjdk.java.net/~fparain/7150256/webrev.07/ >> >> Thanks, >> >> Fred >> >> On 24/04/2013 22:07, Mandy Chung wrote: >>> 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 >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri May 3 18:32:59 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 03 May 2013 20:32:59 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <51840240.4060705@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> <5183FFCA.1090108@oracle.com> <51840240.4060705@oracle.com> Message-ID: <518402DB.8040407@oracle.com> I'll fix it and file a new bug. Fred On 03/05/2013 20:30, Mandy Chung wrote: > On 5/3/2013 11:19 AM, Daniel Fuchs wrote: >> Hi, >> >> On 5/3/13 8:02 PM, Mandy Chung wrote: >>> 2. Investigate what DiagnosticCommandImpl.getAttributes and >>> setAttributes should do per DynamicMBean spec. The current >>> implementation throws UOE which seem to be okay. It's good to confirm >>> what is specified or not specified per DynamicMBean spec >> >> By analogy with what the MBeanServerConnection says and what >> the StandardMBean class does, I'd say that the expected behavior >> would be to return an empty AttributeList for both methods. > > Thanks Daniel. I initially thought that these 2 methods should return > an empty AttributeList. MBeanServerConnection specifies clearly that > missing attribute will be omitted and the caller will use the returned > value to determine any missing attribute. It makes sense to expect > DynamicMBean.get/setAttributes the same behavior as MBS forwards the > call to the mbeans. > > Frederic - you can simply fix this to return an empty AttributeList. Can > you also file a bug for DynamicMBean to clarify the expected behavior in > the specification? > > Thanks > Mandy > >> >> See: >> >> >> >> and >> >> >> > >> -- daniel >> >>> >>> Thanks >>> Mandy >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri May 3 18:40:08 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 03 May 2013 20:40:08 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <5183FFCA.1090108@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> <5183FFCA.1090108@oracle.com> Message-ID: <51840488.3060604@oracle.com> MBeanServer.setAttributes() returns an AttributeList but the return type of DynamicMBean.setAttributes() is void. Does it mean that in our case, setAttributes() should simply be a no-op method? Fred On 03/05/2013 20:19, Daniel Fuchs wrote: > Hi, > > On 5/3/13 8:02 PM, Mandy Chung wrote: >> 2. Investigate what DiagnosticCommandImpl.getAttributes and >> setAttributes should do per DynamicMBean spec. The current >> implementation throws UOE which seem to be okay. It's good to confirm >> what is specified or not specified per DynamicMBean spec > > By analogy with what the MBeanServerConnection says and what > the StandardMBean class does, I'd say that the expected behavior > would be to return an empty AttributeList for both methods. > > See: > > > > and > > > > -- daniel > >> >> Thanks >> Mandy > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From mandy.chung at oracle.com Fri May 3 18:53:59 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 May 2013 11:53:59 -0700 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <51840488.3060604@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> <5183FFCA.1090108@oracle.com> <51840488.3060604@oracle.com> Message-ID: <518407C7.8050204@oracle.com> DynamicMBean: public AttributeList setAttributes(AttributeList attributes); Maybe you looked at setAttribute method. It's easily misread with and without 's'. On 5/3/2013 11:40 AM, frederic parain wrote: > MBeanServer.setAttributes() returns an AttributeList > but the return type of DynamicMBean.setAttributes() is > void. Does it mean that in our case, setAttributes() > should simply be a no-op method? > > Fred > > On 03/05/2013 20:19, Daniel Fuchs wrote: >> Hi, >> >> On 5/3/13 8:02 PM, Mandy Chung wrote: >>> 2. Investigate what DiagnosticCommandImpl.getAttributes and >>> setAttributes should do per DynamicMBean spec. The current >>> implementation throws UOE which seem to be okay. It's good to confirm >>> what is specified or not specified per DynamicMBean spec >> >> By analogy with what the MBeanServerConnection says and what >> the StandardMBean class does, I'd say that the expected behavior >> would be to return an empty AttributeList for both methods. >> >> See: >> >> >> >> >> and >> >> >> >> >> -- daniel >> >>> >>> Thanks >>> Mandy >> > From frederic.parain at oracle.com Fri May 3 19:07:28 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 03 May 2013 21:07:28 +0200 Subject: RFR: 7150256: Add back Diagnostic Command JMX API In-Reply-To: <518407C7.8050204@oracle.com> References: <50CF0187.6080001@oracle.com> <50CF1A31.7020106@oracle.com> <50CF3311.7020606@oracle.com> <50D3A1DD.4040703@oracle.com> <517001CD.2080109@oracle.com> <51783B80.5010807@oracle.com> <5183E921.7020209@oracle.com> <5183FBCB.2030902@oracle.com> <5183FFCA.1090108@oracle.com> <51840488.3060604@oracle.com> <518407C7.8050204@oracle.com> Message-ID: <51840AF0.5020707@oracle.com> You're right. I'll update setAttributes() to return an empty AttributeList. Fred On 03/05/2013 20:53, Mandy Chung wrote: > DynamicMBean: > public AttributeList setAttributes(AttributeList attributes); > > Maybe you looked at setAttribute method. It's easily misread with and > without 's'. > > On 5/3/2013 11:40 AM, frederic parain wrote: >> MBeanServer.setAttributes() returns an AttributeList >> but the return type of DynamicMBean.setAttributes() is >> void. Does it mean that in our case, setAttributes() >> should simply be a no-op method? >> >> Fred >> >> On 03/05/2013 20:19, Daniel Fuchs wrote: >>> Hi, >>> >>> On 5/3/13 8:02 PM, Mandy Chung wrote: >>>> 2. Investigate what DiagnosticCommandImpl.getAttributes and >>>> setAttributes should do per DynamicMBean spec. The current >>>> implementation throws UOE which seem to be okay. It's good to confirm >>>> what is specified or not specified per DynamicMBean spec >>> >>> By analogy with what the MBeanServerConnection says and what >>> the StandardMBean class does, I'd say that the expected behavior >>> would be to return an empty AttributeList for both methods. >>> >>> See: >>> >>> >>> >>> >>> and >>> >>> >>> >>> >>> -- daniel >>> >>>> >>>> Thanks >>>> Mandy >>> >> > -- 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 Fri May 3 19:10:21 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 May 2013 21:10:21 +0200 Subject: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit In-Reply-To: <51838C78.3020505@gmail.com> References: <51838C78.3020505@gmail.com> Message-ID: Hi Peter, On May 3, 2013, at 12:07 PM, Peter Levart wrote: > Hi Paul, > > Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces either null+N or n+m (n N could be 0, which can occur for spliterators of maps, but for N > 0 i think it unlikely. However, i am not sure we should explicitly rule it out given sizes may be estimates. I think it may be prudent to give spliterators the wiggle room, as some wiggle in unexpected ways, and document what the best way to wiggle is. How about we add some non-normative text to the api note of trySplit? i can log another issue for that. Paul. > * Upon non-null return: > *
            > *
          • the value reported for {@code estimateSize()} before splitting, > * must, after splitting, be greater than {@code estimateSize()} > * for this and greater than or equal than {@code estimateSize()} > * for the returned Spliterator; and
          • > *
          • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} > * for this spliterator before splitting must be equal to the sum of > * {@code estimateSize()} for this and the returned Spliterator after > > > Regards, Peter > > > On 05/03/2013 11:10 AM, Paul Sandoz wrote: >> Hi, >> >> Please review the patch below for some minor fixes to the Spltierator JavaDoc and a tweak to the spec of Spliterator.trySplit. >> >> http://bugs.sun.com/view_bug.do?bug_id=8013334 >> >> Paul. >> >> # HG changeset patch >> # User psandoz >> # Date 1367571917 -7200 >> # Node ID fda6ca78a7c299349f201c310ec480351a855ed1 >> # Parent 470f19b6bfdd07aed3ca6e0debdabcd8cd7f8083 >> 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit >> Summary: In addition to fixing 8013334 this changeset containts some minor, >> non spec, related fixes to tidy up other areas of the JavaDoc. >> Reviewed-by: >> Contributed-by: John Rose , Mike Duigou , >> Paul Sandoz >> >> diff -r 470f19b6bfdd -r fda6ca78a7c2 src/share/classes/java/util/Spliterator.java >> --- a/src/share/classes/java/util/Spliterator.java Thu May 02 13:21:09 2013 +0200 >> +++ b/src/share/classes/java/util/Spliterator.java Fri May 03 11:05:17 2013 +0200 >> @@ -140,32 +140,32 @@ >> * (in approximate order of decreasing desirability): >> *
              >> *
            • The source cannot be structurally interfered with. >> - *
              For example, an instance of >> + *
              For example, an instance of >> * {@link java.util.concurrent.CopyOnWriteArrayList} is an immutable source. >> * A Spliterator created from the source reports a characteristic of >> * {@code IMMUTABLE}.
            • >> *
            • The source manages concurrent modifications. >> - *
              For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} >> + *
              For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} >> * is a concurrent source. A Spliterator created from the source reports a >> * characteristic of {@code CONCURRENT}.
            • >> *
            • The mutable source provides a late-binding and fail-fast Spliterator. >> - *
              Late binding narrows the window during which interference can affect >> + *
              Late binding narrows the window during which interference can affect >> * the calculation; fail-fast detects, on a best-effort basis, that structural >> * interference has occurred after traversal has commenced and throws >> * {@link ConcurrentModificationException}. For example, {@link ArrayList}, >> * and many other non-concurrent {@code Collection} classes in the JDK, provide >> * a late-binding, fail-fast spliterator.
            • >> *
            • The mutable source provides a non-late-binding but fail-fast Spliterator. >> - *
              The source increases the likelihood of throwing >> + *
              The source increases the likelihood of throwing >> * {@code ConcurrentModificationException} since the window of potential >> * interference is larger.
            • >> *
            • The mutable source provides a late-binding and non-fail-fast Spliterator. >> - *
              The source risks arbitrary, non-deterministic behavior after traversal >> + *
              The source risks arbitrary, non-deterministic behavior after traversal >> * has commenced since interference is not detected. >> *
            • >> *
            • The mutable source provides a non-late-binding and non-fail-fast >> * Spliterator. >> - *
              The source increases the risk of arbitrary, non-deterministic behavior >> + *
              The source increases the risk of arbitrary, non-deterministic behavior >> * since non-detected interference may occur after construction. >> *
            • >> *
            >> @@ -284,6 +284,8 @@ >> * is set to {@code true} then diagnostic warnings are reported if boxing of >> * primitive values occur when operating on primitive subtype specializations. >> * >> + * @param the type of elements returned by this Spliterator >> + * >> * @see Collection >> * @since 1.8 >> */ >> @@ -333,9 +335,8 @@ >> * Upon non-null return: >> *
              >> *
            • the value reported for {@code estimateSize()} before splitting, >> - * if not already zero or {@code Long.MAX_VALUE}, must, after splitting, be >> - * greater than {@code estimateSize()} for this and the returned >> - * Spliterator; and
            • >> + * must, after splitting, be greater than or equal to {@code estimateSize()} >> + * for this and the returned Spliterator; and >> *
            • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} >> * for this spliterator before splitting must be equal to the sum of >> * {@code estimateSize()} for this and the returned Spliterator after > From peter.levart at gmail.com Fri May 3 19:25:21 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 May 2013 21:25:21 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367603276.4723.7.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> Message-ID: <51840F21.9010802@gmail.com> On 05/03/2013 07:47 PM, Thomas Schatzl wrote: > Hi, >> Hi Tomas, >> >> I don't know if this is the case here, but what if the >> ReferenceHandler thread is interrupted while wait()-ing and the >> construction of InterruptedException triggers OOME? > I am sure this is the case - previously I thought InterruptedException > is a preallocated exception like others. > ObjectMonitor::wait() may throw it, by creating new InterruptedException > instances. > > Thanks! > > Now that we've found the very likely cause, what to do about it? Maybe just ignore it since if it happens during wait(), the cause is supposed to be interrupted thread and the InterruptedException that was to be thrown would be ignored too: try { lock.wait(); } catch (InterruptedException | OutOfMemoryError x) { } Regards, Peter > The current state of silently crashing the reference handler thread is > unsatisfying imo as it leads to very hard to find problems. > > The options I see all involve catching this (or any other OOME caused by > other means like the test program) and either recovering as much as > possible or exiting the VM (like in the sun.misc.Cleaner handling). > > Any other suggestions? > > Thanks, > Thomas > From peter.levart at gmail.com Fri May 3 19:42:29 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 May 2013 21:42:29 +0200 Subject: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit In-Reply-To: References: <51838C78.3020505@gmail.com> Message-ID: <51841325.201@gmail.com> On 05/03/2013 09:10 PM, Paul Sandoz wrote: > Hi Peter, > > On May 3, 2013, at 12:07 PM, Peter Levart > wrote: > >> Hi Paul, >> >> Maybe the JavaDoc could also suggest that the trySplit producing N+0 >> result should converge so that returned Spliterator eventualy >> produces either null+N or n+m (n> finite number of steps. Also I don't know why would any Spliterator >> implementation want to return 0+N from trySplit (the N+0 return can >> be useful because the returned instance can be of different >> class/implementation, but the 0+N has no utility), so the javaDoc >> could be more strict: >> > > N could be 0, which can occur for spliterators of maps, but for N > 0 > i think it unlikely. > > However, i am not sure we should explicitly rule it out given sizes > may be estimates. I think it may be prudent to give spliterators the > wiggle room, as some wiggle in unexpected ways, and document what the > best way to wiggle is. > > How about we add some non-normative text to the api note of trySplit? > i can log another issue for that. Now looking at the whole JavaDoc, I see there is already the following at the top of trySplit: *

              Unless this Spliterator covers an infinite number of elements, * repeated calls to {@code trySplit()} must eventually return {@code null}. Which I think is enough of a hint for the eventual implementor of the interface to conclude that this (and not N+0 or 0+N) is the sole terminating condition for the process of splitting. Regards, Peter > > Paul. > >> * Upon non-null return: >> *

                >> *
              • the value reported for {@code estimateSize()} before splitting, >> * must, after splitting, be greater than {@code estimateSize()} >> * for this and greater than or equal than {@code estimateSize()} >> * for the returned Spliterator; and
              • >> *
              • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} >> * for this spliterator before splitting must be equal to the sum of >> * {@code estimateSize()} for this and the returned Spliterator after >> >> >> Regards, Peter >> >> >> On 05/03/2013 11:10 AM, Paul Sandoz wrote: >>> Hi, >>> >>> Please review the patch below for some minor fixes to the Spltierator JavaDoc and a tweak to the spec of Spliterator.trySplit. >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8013334 >>> >>> Paul. >>> >>> # HG changeset patch >>> # User psandoz >>> # Date 1367571917 -7200 >>> # Node ID fda6ca78a7c299349f201c310ec480351a855ed1 >>> # Parent 470f19b6bfdd07aed3ca6e0debdabcd8cd7f8083 >>> 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit >>> Summary: In addition to fixing 8013334 this changeset containts some minor, >>> non spec, related fixes to tidy up other areas of the JavaDoc. >>> Reviewed-by: >>> Contributed-by: John Rose, Mike Duigou, >>> Paul Sandoz >>> >>> diff -r 470f19b6bfdd -r fda6ca78a7c2 src/share/classes/java/util/Spliterator.java >>> --- a/src/share/classes/java/util/Spliterator.java Thu May 02 13:21:09 2013 +0200 >>> +++ b/src/share/classes/java/util/Spliterator.java Fri May 03 11:05:17 2013 +0200 >>> @@ -140,32 +140,32 @@ >>> * (in approximate order of decreasing desirability): >>> *
                  >>> *
                • The source cannot be structurally interfered with. >>> - *
                  For example, an instance of >>> + *
                  For example, an instance of >>> * {@link java.util.concurrent.CopyOnWriteArrayList} is an immutable source. >>> * A Spliterator created from the source reports a characteristic of >>> * {@code IMMUTABLE}.
                • >>> *
                • The source manages concurrent modifications. >>> - *
                  For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} >>> + *
                  For example, a key set of a {@link java.util.concurrent.ConcurrentHashMap} >>> * is a concurrent source. A Spliterator created from the source reports a >>> * characteristic of {@code CONCURRENT}.
                • >>> *
                • The mutable source provides a late-binding and fail-fast Spliterator. >>> - *
                  Late binding narrows the window during which interference can affect >>> + *
                  Late binding narrows the window during which interference can affect >>> * the calculation; fail-fast detects, on a best-effort basis, that structural >>> * interference has occurred after traversal has commenced and throws >>> * {@link ConcurrentModificationException}. For example, {@link ArrayList}, >>> * and many other non-concurrent {@code Collection} classes in the JDK, provide >>> * a late-binding, fail-fast spliterator.
                • >>> *
                • The mutable source provides a non-late-binding but fail-fast Spliterator. >>> - *
                  The source increases the likelihood of throwing >>> + *
                  The source increases the likelihood of throwing >>> * {@code ConcurrentModificationException} since the window of potential >>> * interference is larger.
                • >>> *
                • The mutable source provides a late-binding and non-fail-fast Spliterator. >>> - *
                  The source risks arbitrary, non-deterministic behavior after traversal >>> + *
                  The source risks arbitrary, non-deterministic behavior after traversal >>> * has commenced since interference is not detected. >>> *
                • >>> *
                • The mutable source provides a non-late-binding and non-fail-fast >>> * Spliterator. >>> - *
                  The source increases the risk of arbitrary, non-deterministic behavior >>> + *
                  The source increases the risk of arbitrary, non-deterministic behavior >>> * since non-detected interference may occur after construction. >>> *
                • >>> *
                >>> @@ -284,6 +284,8 @@ >>> * is set to {@code true} then diagnostic warnings are reported if boxing of >>> * primitive values occur when operating on primitive subtype specializations. >>> * >>> + * @param the type of elements returned by this Spliterator >>> + * >>> * @see Collection >>> * @since 1.8 >>> */ >>> @@ -333,9 +335,8 @@ >>> * Upon non-null return: >>> *
                  >>> *
                • the value reported for {@code estimateSize()} before splitting, >>> - * if not already zero or {@code Long.MAX_VALUE}, must, after splitting, be >>> - * greater than {@code estimateSize()} for this and the returned >>> - * Spliterator; and
                • >>> + * must, after splitting, be greater than or equal to {@code estimateSize()} >>> + * for this and the returned Spliterator; and >>> *
                • if this Spliterator is {@code SUBSIZED}, then {@code estimateSize()} >>> * for this spliterator before splitting must be equal to the sum of >>> * {@code estimateSize()} for this and the returned Spliterator after >> > From mike.duigou at oracle.com Fri May 3 21:33:27 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 03 May 2013 21:33:27 +0000 Subject: hg: jdk8/tl/jdk: 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Message-ID: <20130503213340.41D60487FF@hg.openjdk.java.net> Changeset: fc156b925259 Author: mduigou Date: 2013-05-03 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc156b925259 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Reviewed-by: martin, alanb, chegar, plevart ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/sun/misc/JavaLangAccess/NewUnsafeString.java From jason.uh at oracle.com Fri May 3 22:05:11 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Fri, 03 May 2013 22:05:11 +0000 Subject: hg: jdk8/tl/jdk: 8005922: TEST_BUG: There is no /tmp directory for windows system. Message-ID: <20130503220525.0E4E348800@hg.openjdk.java.net> Changeset: d7f3d5659c46 Author: juh Date: 2013-05-03 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7f3d5659c46 8005922: TEST_BUG: There is no /tmp directory for windows system. Reviewed-by: weijun ! test/sun/security/tools/policytool/ChangeUI.html ! test/sun/security/tools/policytool/UpdatePermissions.html ! test/sun/security/tools/policytool/i18n.html From jonathan.gibbons at oracle.com Fri May 3 22:11:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 May 2013 22:11:26 +0000 Subject: hg: jdk8/tl/langtools: 8000407: remove @GenerateNativeHeader Message-ID: <20130503221128.F392D48801@hg.openjdk.java.net> Changeset: a2889739cf21 Author: jjg Date: 2013-05-03 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a2889739cf21 8000407: remove @GenerateNativeHeader Reviewed-by: vromero, darcy ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java From vitalyd at gmail.com Fri May 3 23:42:40 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 May 2013 19:42:40 -0400 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51840F21.9010802@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> Message-ID: Personally, I think I'd exit the VM in this case. The odds of hitting OOM while allocating TIE and having it be just a very unfortunate transient condition are quite low; most likely, the VM is going to have lots of trouble elsewhere anyway. Also, by swallowing the OOM there and continuing makes an assumption that the lock is still in valid/working state; that may be the case today, but I don't know if that's a safe assumption generally. Sent from my phone On May 3, 2013 3:26 PM, "Peter Levart" wrote: > > On 05/03/2013 07:47 PM, Thomas Schatzl wrote: > >> Hi, >> >>> Hi Tomas, >>> >>> I don't know if this is the case here, but what if the >>> ReferenceHandler thread is interrupted while wait()-ing and the >>> construction of InterruptedException triggers OOME? >>> >> I am sure this is the case - previously I thought InterruptedException >> is a preallocated exception like others. >> ObjectMonitor::wait() may throw it, by creating new InterruptedException >> instances. >> >> Thanks! >> >> Now that we've found the very likely cause, what to do about it? >> > > Maybe just ignore it since if it happens during wait(), the cause is > supposed to be interrupted thread and the InterruptedException that was to > be thrown would be ignored too: > > try { > lock.wait(); > } catch (InterruptedException | OutOfMemoryError > x) { } > > Regards, Peter > > The current state of silently crashing the reference handler thread is >> unsatisfying imo as it leads to very hard to find problems. >> >> The options I see all involve catching this (or any other OOME caused by >> other means like the test program) and either recovering as much as >> possible or exiting the VM (like in the sun.misc.Cleaner handling). >> >> Any other suggestions? >> >> Thanks, >> Thomas >> >> > From jonathan.gibbons at oracle.com Sat May 4 00:46:41 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 04 May 2013 00:46:41 +0000 Subject: hg: jdk8/tl/langtools: 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Message-ID: <20130504004644.180ED48807@hg.openjdk.java.net> Changeset: d918b63a5509 Author: jjg Date: 2013-05-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d918b63a5509 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Reviewed-by: jjg, mduigou Contributed-by: jonathan.gibbons at oracle.com, mike.duigou at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java + test/com/sun/javadoc/InheritDocForUserTags/DocTest.java + test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java + test/com/sun/javadoc/testSimpleTagInherit/p/BaseClass.java + test/com/sun/javadoc/testSimpleTagInherit/p/TestClass.java From mike.duigou at oracle.com Sat May 4 02:28:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 3 May 2013 19:28:20 -0700 Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: References: Message-ID: <5E833D21-CF16-4468-809E-5569964C85B8@oracle.com> I have updated the webrev to include incorporate the feedback I have received. http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/ Regarding the naming of the "nonNull" method. I originally added this method in 2011 but I've forgotten since then why it has the name it does. As best as I can determine the name is either derived from the the name used by Guava for the same predicate, "notNull", or the names derives from the name "requireNonNull" in that this method doesn't require that the reference be non-null. The EG hasn't been concerned that this method doesn't use the "is" prefix. Mike On Apr 30 2013, at 15:45 , Mike Duigou wrote: > 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 Alan.Bateman at oracle.com Sat May 4 07:12:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 04 May 2013 08:12:14 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5183FBCD.5060908@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> Message-ID: <5184B4CE.3080403@oracle.com> On 03/05/2013 19:02, huizhe wang wrote: > : > > Removed the repetitive "value" definition from the > setAttribute/setProperty methods. The open statements already have > references to the properties in XMLConstants. > > Updated to: > "The default value is implementation specific and therefore not > specified. The following options are provided for consideration:" > > The 2nd paragraph already had the "recommendation" when FSP is set to > true (same as in the JEP). I looked at the updated webrev, again mostly focusing on the javadoc/spec changes, and this looks much better. One comment on the "options for consideration" is that it reads "an empty string to allow no access permission". This might be better as "an empty string to deny all access to external references". In each of the setProperty methods it specifies the exception that are thrown when a connection is denied. For example in TransformerFactory it reads "If access is denied during processing due to the restriction of this property,TransformerConfigurationExceptionwill be thrown by TransformerFactory". In this case I thought it was Transformer but more generally the wording doesn't make it clear that it's the parse or transform or whatever methods that throw the exceptions. I agree with Daniel's comment that it is hard to completely assess whether all code paths have been identified. It's a reminder that this one needs extensive testing. -Alan From peter.levart at gmail.com Sat May 4 08:06:09 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 04 May 2013 10:06:09 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> Message-ID: <5184C171.8040702@gmail.com> On 05/04/2013 01:42 AM, Vitaly Davidovich wrote: > > Personally, I think I'd exit the VM in this case. The odds of hitting > OOM while allocating TIE and having it be just a very unfortunate > transient condition are quite low; most likely, the VM is going to > have lots of trouble elsewhere anyway. > I thought the purpose of fixing this bug was exactly to support un-terminated reference processing in situations where OOME *is* a transient condition, and not to take every opportunity to exit the VM when OOME is encountered. > Also, by swallowing the OOM there and continuing makes an assumption > that the lock is still in valid/working state; that may be the case > today, but I don't know if that's a safe assumption generally. > I think It would be a JVM bug if it wasn't so. The construction and propagation of InterruptedException should be and is attempted after the ownership of the object monitor is re-obtained. Besides, no OOME will be thrown if the ReferenceHandler thread isn't interrupted while there is heap memory shortage, but VM is equally "in trouble elsewhere" nevertheless. So I don't think it's ReferenceHandler's call to decide when to terminate the VM. It can continue with it's purpose unaffected... Another thing to be considered is what happens when the ReferenceHandler thread is stop()-ed while it is executing code inside wait(). In this case a ThreadDeath is thrown which should not be caught and ignored. But as it appears, the ThreadDeath error object is constructed by the thread executing the Thread.stop() method so the OOME can only be thrown in that thread and not in the thread being stopped... To back this claims, I have written the following test: public class Test extends Thread { final Object lock = new Object(); public Test() { super("test"); } static void log(String msg) { System.err.println( Thread.currentThread().getName() + " @ " + new SimpleDateFormat("hh:mm:ss.SSS").format(new Date()) + ": " + msg ); } @Override public void run() { while (true) { synchronized (lock) { try { log("waiting"); lock.wait(); } catch (InterruptedException ie) { log("interrupted"); ie.printStackTrace(); } catch (ThreadDeath td) { log("stopped"); td.printStackTrace(); throw td; } } } } public static void main(String[] args) throws Exception { Test test = new Test(); test.start(); Thread.sleep(1000L); synchronized (test.lock) { log("interrupting"); test.interrupt(); Thread.sleep(1000L); } log("exited synchronized block 1"); Thread.sleep(1000L); synchronized (test.lock) { log("stopping"); test.stop(); Thread.sleep(1000L); } log("exited synchronized block 2"); test.join(); } } Which produces the following output: test @ 09:57:53.998: waiting main @ 09:57:54.974: interrupting main @ 09:57:55.975: exited synchronized block 1 test @ 09:57:55.975: interrupted java.lang.InterruptedException: Constructed by test @ 09:57:55.975 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at test.Test.run(Test.java:36) test @ 09:57:55.977: waiting main @ 09:57:56.975: stopping main @ 09:57:57.976: exited synchronized block 2 test @ 09:57:57.976: stopped java.lang.ThreadDeath: Constructed by main @ 09:57:56.976 at java.lang.Thread.stop(Thread.java:815) at test.Test.main(Test.java:66) I also modified the InterruptedException and ThreadDeath no-arg constructors to record the thread name and time of construction to get this output: public InterruptedException() { super("Constructed by " + Thread.currentThread().getName() + " @ " + new SimpleDateFormat("hh:mm:ss.SSS").format(new Date())); } Regards, Peter > Sent from my phone > > On May 3, 2013 3:26 PM, "Peter Levart" > wrote: > > > On 05/03/2013 07:47 PM, Thomas Schatzl wrote: > > Hi, > > Hi Tomas, > > I don't know if this is the case here, but what if the > ReferenceHandler thread is interrupted while wait()-ing > and the > construction of InterruptedException triggers OOME? > > I am sure this is the case - previously I thought > InterruptedException > is a preallocated exception like others. > ObjectMonitor::wait() may throw it, by creating new > InterruptedException > instances. > > Thanks! > > Now that we've found the very likely cause, what to do about it? > > > Maybe just ignore it since if it happens during wait(), the cause > is supposed to be interrupted thread and the InterruptedException > that was to be thrown would be ignored too: > > try { > lock.wait(); > } catch (InterruptedException | > OutOfMemoryError x) { } > > Regards, Peter > > The current state of silently crashing the reference handler > thread is > unsatisfying imo as it leads to very hard to find problems. > > The options I see all involve catching this (or any other OOME > caused by > other means like the test program) and either recovering as > much as > possible or exiting the VM (like in the sun.misc.Cleaner > handling). > > Any other suggestions? > > Thanks, > Thomas > > From eliasen at mindspring.com Sat May 4 12:13:52 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Sat, 04 May 2013 06:13:52 -0600 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> Message-ID: <5184FB80.7030203@mindspring.com> On 05/02/2013 06:37 PM, Brian Burkhalter wrote: > On May 2, 2013, at 5:02 AM, Alan Bateman wrote: > >> On 02/05/2013 02:34, Tim Buktu wrote: >>> : >>> >>> Alan is working on an improved BigInteger.toString() that should >>> be dramatically faster for large numbers. What's the deadline for >>> getting this in? Thanks, >>> >>> Tim >> Here's the latest milestone dates: >> >> http://openjdk.java.net/projects/jdk8/milestones >> >> Given the size of the patch then it would be great to get it in as >> early as possible. With the review effort then I assume Feature >> Complete is too tight although I know Brian Burkhalter is anxious >> to get it in as soon as possible. I can't comment on the >> BigInteger.toString work to know how big this is. > > I think that's the best answer that can be given: as soon as > possible. The 4837946 patch is far from simple to comprehend to say > the least and then there is the testing so it's not going to be fast. > If the toString() work is ready early enough to review then perhaps > we can handle it, but I don't want to make anyone hurry to complete > something and then say we cannot do it. Brian: If you're feeling overwhelmed by the magnitude of the changes to BigInteger, I would very strongly suggest that you review it in stages. This e-mail proposes stages for the review of this patch. Since I first posted these patches over 5 years ago, we were asked to make patches as small as possible so they would get reviewed more quickly. That's why my patches focused on what was a minimal but necessary subset: making multiply and pow work *much* faster with very simple, understandable, well-known, hard-to-get-wrong routines and simple optimizations that built on existing routines but gave very significant performance increases. (Implementing Karatsuba and Toom-Cook multiplication routines in Java is often given as a homework problem in undergrad Algorithms courses. Understanding their correctness requires nothing more than first-year Algebra.) Today, I finished porting my recursive Schoenhage toString routines that I've been using for years in my programming language "Frink" ( http://futureboy.us/frinkdocs/ ). They are drastically, stunningly faster than the existing BigInteger.toString algorithms. I have run these through my enormous regression tests which produce over 232 GB of output with no differences. I ram these (very large) regression tests which test multiplication and pow and toString functions in BigInteger. (They produce about 232 gigabytes of output, which I compare against known good output that was produced by previous versions of Java and by the Kaffe VM which used the GMP library. This tells you how long I've been working on this; Kaffe removed support for GMP over 4 years ago.) It should be known that I would need to further increase the size of these tests to make a significant test of the very large numbers that trigger Sch?nhage-Strassen (SS) multiplication. Currently, the smallest numbers that will trigger SS multiplication are both operands >247,000 bits, or about 7718 ints. SS multiplication is used at all times when both operands are 1,249,000 bits or more. These are biggish numbers, and my tests currently don't go out that far. I can vouch strongly for the correctness of Karatsuba and Toom-Cook multiplication, though. Keep in mind that torture-testing Sch?nhage-Strassen multiplication and comparing against the runs of Java 1.7 or earlier might take a *very* long time because the earlier versions of BigInteger.multiply(BigInteger) are so slow in multiplications of the size where SS multiplication is used. I can personally vouch for having very strongly tested the parts of multiplication and pow that I wrote, which include: * Karatsuba multiplication * 3-way Toom-Cook multiplication * Karatsuba squaring * Toom-Cook squaring * Revised pow() function While I have been using Tim's Sch?nhage-Strassen multiplication and Burnickel-Ziegler division routines in my daily work, and have not detected failures, I have not written explicit tests for division at all, and my number of very large integer divisions has been small. I have implicitly used his division routines in my base conversion routines for large numbers, and have found no errors. My multiplication tests were written to test general multiplication, but also to very strongly test around the regions at which Karatsuba and Toom-Cook have edge cases. Since I don't know the Sch?nhage-Strassen algorithms, I don't know where they might have particular edge cases, so I haven't written any specific tests for them. Brian, would it be possible to make BigInteger.square() public? It would make it possible for end-users to write algorithms that performed notably faster. If not, a possible (much less optimal) optimization would be for multiply to detect that its arguments are equal (either using == which would be fast or .equals or .compareTo which may be much slower if the numbers are large) and call squaring routines instead of doing the naive multiply. If reviewing time is limited, I might suggest performing the reviews and integration in a few steps: Step 1) would be integrating the simple, high-benefit, low-risk changes that I made: * Karatsuba multiplication * 3-way Toom-Cook multiplication * Karatsuba squaring * Toom-Cook squaring * Revised pow() function these require the helper functions: * getLower(int) and * getUpper(int) for Karatsuba which do efficient slices of numbers * getToomSlice() for Toom-Cook slicing to do efficient slicing of numbers. * exactDivideBy3: A function to do divisions by modular multiplication, which is at least 17 times faster on most architectures. Used in Toom-Cook3 multiplication. It should be noted that the pow() function performs some arguments (e.g. when the base is a power of 2) millions or billions of times faster than current Java and would alone drastically improve the performance of many programs. Step 2) incorporating my toString changes. It's useless to work with these very big numbers if you can't output them in reasonable time. And right now toString() will be the bottleneck for most programs as it's approximately O(n^2.0634) in my tests. With the improved division routines that Tim Buktu wrote, and my recursive base conversion algorithms, I can make these perform in O(n^1.3596) or better. This means, as a practical matter, that printing the largest known Mersenne number in base 10 is reduced from 18 hours to 150 seconds. (I can provide constants to the asymptotes if desired.) The bug for improving toString is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 I considered toString() slightly more controversial because to perform repeated conversions efficiently it is very useful to allocate a cache of "helper" values of 10^2^n to speed up calculations. This had memory usage implications, synchronization implications, and questions about conversions to different bases (say, to convert to base 5, you also need a cache of 5^2^n, etc.) I didn't want this to delay the acceptance of the simple and noncontroversial multiplication and pow routines which had no external impact and didn't touch other files like MutableBigInteger, SignedMutableBigInteger, etc. My complete patch contains very much faster, simple Schoenhage recursive base conversion routines for toString. By the way, the synchronization for the new toString() routines could be rewritten to use Future and other synchronization mechanisms. In any case. the current mechanism will almost always be faster. While I have been using Tim's Sch?nhage-Strassen multiplication and Burnickel-Ziegler division routines in my daily work, and have not detected failures, I have not written explicit tests for division at all, and my number of very large integer divisions has been small. My multiplication tests were written to test general multiplication, but also to very strongly test around the regions at which Karatsuba and Toom-Cook have edge cases. Since I don't know the Sch?nhage-Strassen algorithms, I don't know where they might have particular edge cases, so I haven't written any specific tests for them. Brian, would it be possible to make BigInteger.square() public? It would make it possible for end-users to write algorithms that performed notably faster. If not, a possible (much less optimal) optimization would be for multiply() to detect that its arguments are equal (either using == which would be fast or .equals or .compareTo which may be much slower if the numbers are large) and call squaring routines instead of doing the naive multiply. Step 3) would involve faster division: The Burnickel-Ziegler and Barrett division routines that Tim wrote. These are important for making base conversion faster, and making division reasonably fast. (For many programs, division speed is the limiting factor. This limits the performance of BigDecimal too.) They are complicated. Step 4) integrating what I believe are the most tricky routines: Schoenhage-Strassen (SS) multiplication. I respect Tim Buktu's programming skills, but I also know that SS multiplication is hard to get right, even for super-geniuses. The GMP team historically released versions of SS multiplication that were wrong for a small subset of arguments. This stuff is hard. My latest best version of all of these routines is located at: http://futureboy.us/temp/BigInteger.java This passes all of my regression tests for multiply in the Karatsuba and Toom-Cook regions, and all base conversion test. It does not test multiplication in the Schoenhage-Strassen regions, nor does it test large division. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From Ulf.Zibis at CoSoCo.de Sat May 4 15:09:53 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 04 May 2013 17:09:53 +0200 Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: <5E833D21-CF16-4468-809E-5569964C85B8@oracle.com> References: <5E833D21-CF16-4468-809E-5569964C85B8@oracle.com> Message-ID: <518524C1.5010203@CoSoCo.de> Am 04.05.2013 04:28, schrieb Mike Duigou: > I have updated the webrev to include incorporate the feedback I have received. > > http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/ > > Regarding the naming of the "nonNull" method. I originally added this method in 2011 but I've forgotten since then why it has the name it does. As best as I can determine the name is either derived from the the name used by Guava for the same predicate, "notNull", or the names derives from the name "requireNonNull" in that this method doesn't require that the reference be non-null. The EG hasn't been concerned that this method doesn't use the "is" prefix. Do we need nonNull/isNotNull() at all, as it's always !isNull()? Anyway I would prefer isNotNull(). -Ulf From Ulf.Zibis at CoSoCo.de Sat May 4 17:09:31 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 04 May 2013 19:09:31 +0200 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <51833D0F.1070003@oracle.com> References: <51833D0F.1070003@oracle.com> Message-ID: <518540CB.1060004@CoSoCo.de> Hi Sherman, looks good to me. Maybe you like to compare with webrevs from: https://bugs.openjdk.java.net/show_bug.cgi?id=100092 https://bugs.openjdk.java.net/show_bug.cgi?id=100095 -Ulf Am 03.05.2013 06:29, schrieb Xueming Shen: > Hi, > > Please help review the proposed fix for 8012326. > > The direct trigger is the fix we put in #6898310 [1], in which we added the > synchronization to prevent a possible race condition as described in $4685305. > > However it appears the added synchronization triggers another race condition as > showed in this stack trace [4] when run the test case [2][3]. > > The root cause here is > > (1) The ExtendedCharsetProvider is intended to be used as a singleton (as the > probeExtendedProvider + lookupExtendedCharset mechanism in Charset.java), > however this is only true for the Charset.forName()->lookup()...scenario. Multiple > instances of ExtendedCharsetProvider is being created in Charset.availableCharset() > every time it is invoked, via providers()/ServiceLoader.load(). > > (2) ISO2022_JP_2 and MSISO2022JP are provided via ExtendedCharsetProvider, > however both of them have two static variable DEC02{12|08}/ENC02{12|08} that > need to be initialized during the "class initialization", which will indirectly trigger > the invocation of ExtendedCharsetProvider.alisesFor(...) > > (3) static method ExtendedCharsets.aliaseFor() has a hacky implementation that > goes to AbstractCharsetProvider.alise() for lookup, which needs to obtain a lock > on its ExtendedCharesetProvider.instance. This will potential cause race condition > if the "instance" it tries to synchronize on is not its "own" instance. This is possible > because the constructor of ExtendedCharsetProvider overwrites static "instance" > variable with "this". > > Unfortunately as demonstrated in [4], this appears to be what is happening. > The Thread-1/#9 is trying to synchronize on someone else's ExtendedCharsetProvider > instance <0xa4824730> (its own instance should be <0xa4835328>, which it > holds the monitor in the iterator.next()), it is blocked because Thread-0 already holds > the monitor of <0xa4824730> (in its iteratior.next()), but Thread-0 is blocked at > Class.forName0(), which I think is because Thread-1 is inside it already...two theads > are deadlocked. > > A "quick fix/solution" is to remove the direct trigger in ISO2022_JP_2 and > MSISO2022JP to lazily-initialize those static variables as showed in the > webrev. However while this probably will solve the race condition, the multiple > instances of ExtendedCharsetProvider is really not desired. And given the > fact we have already hardwired ExtendedCharsetProvider (as well as the > StandardCharset, for performance reason) for charset lookup/forName(), the > availableCharsets() should also utilize the "singleton" ExtendedCharsetProvider > instanc (extendedCharsetProvider) as well, instead of going to the ServiceLoader > every time for a new instance. The suggested change is to use Charset. > extendedCharsetProvide via probeExtendedProvider() for extended charset > iteration (availableCharset()). Meanwhile, since the ExtendedCharsetProvider/ > charsets.jar should always be in the boot classpath (if installed, and we are > looking up via Class.forName("sun.nio.cs.ext.ExtededCharsetProvider")), there > is really no need for it to be looked up/loaded via the spi mechanism (in > fact it's redundant to load it again after we have lookup/iterate the > hardwired "extendedCharsetProvider". So I removed the spi description from > the charsts.jar as well. > > An alternative is to really implement the singleton pattern in ECP, however > given the existing mechanism we have in Charset.java and the "hacky" init() > implementation we need in ECP, I go with the current approach. > > http://cr.openjdk.java.net/~sherman/8012326/webrev > > Thanks, > Sherman > > [1] http://cr.openjdk.java.net/~sherman/6898310/webrev/ > [2] http://cr.openjdk.java.net/~sherman/8012326/runtest.bat > [3] http://cr.openjdk.java.net/~sherman/8012326/Test.java > [4] http://cr.openjdk.java.net/~sherman/8012326/stacktrace > From vitalyd at gmail.com Sat May 4 17:38:21 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 4 May 2013 13:38:21 -0400 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <5184C171.8040702@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> Message-ID: Oops, that was my mistake - I thought the lock here was a j.u.c.Lock which of course doesn't even make sense given we're talking about ObjectMonitor. So disregard that bit. Ignoring OOM and continuing just seems very fragile as it means you somehow know that all state is still consistent. Most java code isn't async exception safe, so it's hard to reason about state after OOM. Maybe Reference Handler is OK in that regard though. Cheers Thanks Sent from my phone From mike.duigou at oracle.com Sat May 4 18:50:18 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 4 May 2013 11:50:18 -0700 Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull In-Reply-To: <518524C1.5010203@CoSoCo.de> References: <5E833D21-CF16-4468-809E-5569964C85B8@oracle.com> <518524C1.5010203@CoSoCo.de> Message-ID: On May 4 2013, at 08:09 , Ulf Zibis wrote: > > Am 04.05.2013 04:28, schrieb Mike Duigou: >> I have updated the webrev to include incorporate the feedback I have received. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/ >> >> Regarding the naming of the "nonNull" method. I originally added this method in 2011 but I've forgotten since then why it has the name it does. As best as I can determine the name is either derived from the the name used by Guava for the same predicate, "notNull", or the names derives from the name "requireNonNull" in that this method doesn't require that the reference be non-null. The EG hasn't been concerned that this method doesn't use the "is" prefix. > > Do we need nonNull/isNotNull() at all, as it's always !isNull()? It's more convenient to refer to the method Objects::nonNull than it is to have to use ((Predicate)Objects::isNull).negate() Remember, we don't expect to see direct invocation of these methods, instead they will more commonly be used as predicates via method references. Mike From xueming.shen at oracle.com Sat May 4 19:05:52 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 04 May 2013 12:05:52 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <518540CB.1060004@CoSoCo.de> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> Message-ID: <51855C10.3050203@oracle.com> Thanks Ulf! There is another version with a new ExtendedCharsets.java at http://cr.openjdk.java.net/~sherman/8012326/webrev.newECP/ I merged the stuff in AbstractCharsetProvider into ExtendedCharsets.java. The standardcharset provider now uses the FastCharsetProvider, so there is no need to have an abstract class anymore, as long as we are not going to add a new or separate the charsets.jar. I kinda remember there was a plan to further divide the charsets.jar in the past though... I took the chance to "clean up" the synchronization mechanism in ExtendedCharsets. It appears there are two sync needs here. One is to protect the "cache" inside lookup(), which triggers the race condition if the lookup() gets invoked by multiple threads and the "cahce" map gets accessed/updated at the same time, this is reported and fixed by 4685305 [1], the original fix is to put the sync block in AbstractCharsetProvider.charsetForName(). We put in another sync block in iterator.next() for 6898310 [2], which is the trigger of this bug. In the new version, I "consolidated" them together into lookup() Another sync need is for the "init()", in which it may update the aliasMap, classMap and aliasNameMap via charset() and deleteCharset() if those special properties are defined. There are two sources for the charset()/ deleteCharset(), one is from the constructor, one is from the init(), given ExtendedCharsets is now singleton and get initialized at class init, these should be no race concern between these two sources, so no need to have any sync block inside charset() and deleteCharset(), the only thing need to defend is inside init(), and all three public methods invoke the init() at the beginning of the method body. It appears I will still have to keep the same logic in Charset to access the ExtendedCharset, as it is need to be "probed", just in case it is not "installed"... Yes, there is also room to improve in FastCharsetProvider...I know I need pick some time on it. -Sherman On 5/4/13 10:09 AM, Ulf Zibis wrote: > Hi Sherman, > > looks good to me. > > Maybe you like to compare with webrevs from: > https://bugs.openjdk.java.net/show_bug.cgi?id=100092 > https://bugs.openjdk.java.net/show_bug.cgi?id=100095 > > -Ulf > > Am 03.05.2013 06:29, schrieb Xueming Shen: >> Hi, >> >> Please help review the proposed fix for 8012326. >> >> The direct trigger is the fix we put in #6898310 [1], in which we >> added the >> synchronization to prevent a possible race condition as described in >> $4685305. >> >> However it appears the added synchronization triggers another race >> condition as >> showed in this stack trace [4] when run the test case [2][3]. >> >> The root cause here is >> >> (1) The ExtendedCharsetProvider is intended to be used as a singleton >> (as the >> probeExtendedProvider + lookupExtendedCharset mechanism in >> Charset.java), >> however this is only true for the >> Charset.forName()->lookup()...scenario. Multiple >> instances of ExtendedCharsetProvider is being created in >> Charset.availableCharset() >> every time it is invoked, via providers()/ServiceLoader.load(). >> >> (2) ISO2022_JP_2 and MSISO2022JP are provided via >> ExtendedCharsetProvider, >> however both of them have two static variable >> DEC02{12|08}/ENC02{12|08} that >> need to be initialized during the "class initialization", which will >> indirectly trigger >> the invocation of ExtendedCharsetProvider.alisesFor(...) >> >> (3) static method ExtendedCharsets.aliaseFor() has a hacky >> implementation that >> goes to AbstractCharsetProvider.alise() for lookup, which needs to >> obtain a lock >> on its ExtendedCharesetProvider.instance. This will potential cause >> race condition >> if the "instance" it tries to synchronize on is not its "own" >> instance. This is possible >> because the constructor of ExtendedCharsetProvider overwrites static >> "instance" >> variable with "this". >> >> Unfortunately as demonstrated in [4], this appears to be what is >> happening. >> The Thread-1/#9 is trying to synchronize on someone else's >> ExtendedCharsetProvider >> instance <0xa4824730> (its own instance should be <0xa4835328>, which it >> holds the monitor in the iterator.next()), it is blocked because >> Thread-0 already holds >> the monitor of <0xa4824730> (in its iteratior.next()), but Thread-0 >> is blocked at >> Class.forName0(), which I think is because Thread-1 is inside it >> already...two theads >> are deadlocked. >> >> A "quick fix/solution" is to remove the direct trigger in >> ISO2022_JP_2 and >> MSISO2022JP to lazily-initialize those static variables as showed in the >> webrev. However while this probably will solve the race condition, >> the multiple >> instances of ExtendedCharsetProvider is really not desired. And given >> the >> fact we have already hardwired ExtendedCharsetProvider (as well as the >> StandardCharset, for performance reason) for charset >> lookup/forName(), the >> availableCharsets() should also utilize the "singleton" >> ExtendedCharsetProvider >> instanc (extendedCharsetProvider) as well, instead of going to the >> ServiceLoader >> every time for a new instance. The suggested change is to use Charset. >> extendedCharsetProvide via probeExtendedProvider() for extended charset >> iteration (availableCharset()). Meanwhile, since the >> ExtendedCharsetProvider/ >> charsets.jar should always be in the boot classpath (if installed, >> and we are >> looking up via >> Class.forName("sun.nio.cs.ext.ExtededCharsetProvider")), there >> is really no need for it to be looked up/loaded via the spi mechanism >> (in >> fact it's redundant to load it again after we have lookup/iterate the >> hardwired "extendedCharsetProvider". So I removed the spi description >> from >> the charsts.jar as well. >> >> An alternative is to really implement the singleton pattern in ECP, >> however >> given the existing mechanism we have in Charset.java and the "hacky" >> init() >> implementation we need in ECP, I go with the current approach. >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev >> >> Thanks, >> Sherman >> >> [1] http://cr.openjdk.java.net/~sherman/6898310/webrev/ >> [2] http://cr.openjdk.java.net/~sherman/8012326/runtest.bat >> [3] http://cr.openjdk.java.net/~sherman/8012326/Test.java >> [4] http://cr.openjdk.java.net/~sherman/8012326/stacktrace >> > From peter.levart at gmail.com Sat May 4 19:23:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 04 May 2013 21:23:41 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> Message-ID: <5185603D.9080904@gmail.com> On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: > > Oops, that was my mistake - I thought the lock here was a j.u.c.Lock > which of course doesn't even make sense given we're talking about > ObjectMonitor. So disregard that bit. > > Ignoring OOM and continuing just seems very fragile as it means you > somehow know that all state is still consistent. Most java code isn't > async exception safe, so it's hard to reason about state after OOM. > Maybe Reference Handler is OK in that regard though. > I think it is safe to ignore OOME here, since this is the only place where heap allocation happens and it is known what provokes it. Otherwise ReferenceHandler just shuffles existing pointers in existing objects... Regards, Peter > Cheers > > Thanks > > Sent from my phone > From tbuktu at hotmail.com Sun May 5 02:48:39 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Sun, 5 May 2013 04:48:39 +0200 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <5184FB80.7030203@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> Message-ID: On 05/04/2013 2:13 PM, Alan Eliasen wrote: > My multiplication tests were written to test general multiplication, > but also to very strongly test around the regions at which Karatsuba and > Toom-Cook have edge cases. Since I don't know the Sch?nhage-Strassen > algorithms, I don't know where they might have particular edge cases, so > I haven't written any specific tests for them. Edge cases in SS are powers of two and powers of two plus one. I added code to (the patched) BigIntegerTest.java earlier that tests those numbers. According to the author of the SS implementation in GMP, numbers with long sequences of zeros or ones are good test cases as well. Those have been in my patched BigIntegerTest.java for a while. BigIntegerTest only does so many iterations of course. I increased that number so it would run for about a day, and the tests all passed. I did some optimizations after that which caused a couple of bugs, but they have been fixed and BigIntegerTest hasn't failed since (including another 24h run). I will run the latest version of BigIntegerTest (which tests the above mentioned numbers around powers of two) for a day or so and report back. > Step 3) would involve faster division: The Burnickel-Ziegler and > Barrett division routines that Tim wrote. These are important for > making base conversion faster, and making division reasonably fast. > (For many programs, division speed is the limiting factor. This limits > the performance of BigDecimal too.) They are complicated. I agree on Barrett, especially because it is only useful in combination with Schoenhage-Strassen. Burnikel-Ziegler on the other hand, covers a wide range (750 - 750,000 digits, comparable to Toom-Cook) and it's not nearly as complex as SS. Tim From tbuktu at hotmail.com Mon May 6 00:18:20 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Mon, 6 May 2013 02:18:20 +0200 Subject: Relicensing of the BigInteger patch Message-ID: Hi, I was contacted by the maintainer of the Spire project (https://github.com/non/spire). They would like to port the fast BigInteger algorithms to Scala and they're asking whether the patch (i.e. just the code I and Alan Eliasen wrote) could be made available under a MIT or BSD license. I don't have a problem with it, and neither does Alan, but I was wondering if there were any legal concerns from the JDK team. Thanks, Tim From dag.wanvik at oracle.com Mon May 6 04:06:13 2013 From: dag.wanvik at oracle.com (dag.wanvik at oracle.com) Date: Mon, 06 May 2013 04:06:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130506040646.ADA004882A@hg.openjdk.java.net> Changeset: d8f01bfb1da4 Author: dwanvik Date: 2013-05-06 05:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8f01bfb1da4 8013403: Update JDK8 with Java DB 10.10.1.1. Summary: Drop Java DB 10.10.1.1 bits into JDK 8 and update image builds Reviewed-by: tbell ! make/common/Release.gmk ! makefiles/CompileDemos.gmk ! makefiles/Images.gmk Changeset: 398fe07f530f Author: dwanvik Date: 2013-05-06 06:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/398fe07f530f Merge - test/sun/reflect/CallerSensitive/MethodFinder.java From joe.darcy at oracle.com Mon May 6 04:08:50 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 05 May 2013 21:08:50 -0700 Subject: Relicensing of the BigInteger patch In-Reply-To: References: Message-ID: <51872CD2.8080702@oracle.com> Hello, With the standard disclaimers that IANAL and "this is not legal advice," I suggest you review the "Do I lose any rights to my contribution under the OCA?" question in the Oracle Contributor Agreement FAQ: http://www.oracle.com/technetwork/oca-faq-405384.pdf HTH, -Joe On 05/05/2013 05:18 PM, Tim Buktu wrote: > Hi, > > I was contacted by the maintainer of the Spire project > (https://github.com/non/spire). They would like to port the fast > BigInteger algorithms to Scala and they're asking whether the patch > (i.e. just the code I and Alan Eliasen wrote) could be made available > under a MIT or BSD license. > > I don't have a problem with it, and neither does Alan, but I was > wondering if there were any legal concerns from the JDK team. > Thanks, > > Tim From joe.darcy at oracle.com Mon May 6 04:05:14 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 May 2013 04:05:14 +0000 Subject: hg: jdk8/tl/langtools: 8013909: Fix doclint issues in javax.lang.model Message-ID: <20130506040520.B9DF648829@hg.openjdk.java.net> Changeset: e8987ce7fb4b Author: darcy Date: 2013-05-05 21:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e8987ce7fb4b 8013909: Fix doclint issues in javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/SupportedAnnotationTypes.java ! src/share/classes/javax/annotation/processing/SupportedOptions.java ! src/share/classes/javax/annotation/processing/SupportedSourceVersion.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/NestingKind.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/lang/model/util/Types.java From thomas.schatzl at oracle.com Mon May 6 08:02:27 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 May 2013 10:02:27 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <5185603D.9080904@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> Message-ID: <1367827347.2653.24.camel@cirrus> Hi, On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote: > > On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: > > > Oops, that was my mistake - I thought the lock here was a j.u.c.Lock > > which of course doesn't even make sense given we're talking about > > ObjectMonitor. So disregard that bit. > > > > Ignoring OOM and continuing just seems very fragile as it means you > > somehow know that all state is still consistent. Most java code > > isn't async exception safe, so it's hard to reason about state after > > OOM. Maybe Reference Handler is OK in that regard though. > > > > I think it is safe to ignore OOME here, since this is the only place As my test program shows, this may not be the only place where heap allocation can happen within that code. Alan also mentioned something about instrumentation that can add memory allocations basically anywhere. As the reference handler code is plain java code, it will be affected as other java code. > where heap allocation happens and it is known what provokes it. > Otherwise ReferenceHandler just shuffles existing pointers in existing > objects... In the current compilers, yes. But what about other compilers/VMs that may add more elaborate profiling information here and there? E.g. the graal compiler? Not sure if it does, probably it does not, but it seems shaky to rely on compiler code generation here. So is it possible to handle all known issues (especially if the fix is similar/known/understandable), not just the original one, here? I mean, if we fix this issue as you suggested (I am not against that, it looks reasonable), I would not know what to do with the test program except file another bug against the very same component with the same problem, with the same fix suggestion. I.e. the code still seems to buggy even after applying that fix, and with instrumentation I think I could create another reproducer. As reference processing is something critical to the VM, I think it is prudent to fix all known problems here and now if possible. Maybe there is some argument against simply wrapping the entire loop with a try-catch? Please elaborate if so (maybe I overlooked that?), or maybe you could suggest another solution? Additionally, just fixing only the exact issue here seems somewhat wasteful in terms of time (imho) - because next time another developer will likely spend lots of time trying to reproduce this again. (As mentioned, the former assignee also seemed to be unable to reproduce this for a long time). Thanks, Thomas From paul.sandoz at oracle.com Mon May 6 08:35:22 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 6 May 2013 10:35:22 +0200 Subject: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit In-Reply-To: <51841325.201@gmail.com> References: <51838C78.3020505@gmail.com> <51841325.201@gmail.com> Message-ID: <12B9A240-AE03-4A35-BEE5-0957CBB77E9E@oracle.com> On May 3, 2013, at 9:42 PM, Peter Levart wrote: > > On 05/03/2013 09:10 PM, Paul Sandoz wrote: >> Hi Peter, >> >> On May 3, 2013, at 12:07 PM, Peter Levart wrote: >> >>> Hi Paul, >>> >>> Maybe the JavaDoc could also suggest that the trySplit producing N+0 result should converge so that returned Spliterator eventualy produces either null+N or n+m (n>> >> >> N could be 0, which can occur for spliterators of maps, but for N > 0 i think it unlikely. >> >> However, i am not sure we should explicitly rule it out given sizes may be estimates. I think it may be prudent to give spliterators the wiggle room, as some wiggle in unexpected ways, and document what the best way to wiggle is. >> >> How about we add some non-normative text to the api note of trySplit? i can log another issue for that. > > Now looking at the whole JavaDoc, I see there is already the following at the top of trySplit: > > *

                  Unless this Spliterator covers an infinite number of elements, > * repeated calls to {@code trySplit()} must eventually return {@code null}. > > Which I think is enough of a hint for the eventual implementor of the interface to conclude that this (and not N+0 or 0+N) is the sole terminating condition for the process of splitting. Right, that is the key piece of information for termination. Practically speaking such termination is unlikely to be encountered by the stream implementation since splitting is controlled by a size threshold. However, we do test that null is eventually returned, within the bounds of a certain depth (2^18, which is more than enough to detect a bad spliterator given the size of the input data). Paul. From peter.levart at gmail.com Mon May 6 11:52:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 06 May 2013 13:52:23 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367827347.2653.24.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> Message-ID: <51879977.8030307@gmail.com> On 05/06/2013 10:02 AM, Thomas Schatzl wrote: > Hi, > > On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote: >> On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: >> >>> Oops, that was my mistake - I thought the lock here was a j.u.c.Lock >>> which of course doesn't even make sense given we're talking about >>> ObjectMonitor. So disregard that bit. >>> >>> Ignoring OOM and continuing just seems very fragile as it means you >>> somehow know that all state is still consistent. Most java code >>> isn't async exception safe, so it's hard to reason about state after >>> OOM. Maybe Reference Handler is OK in that regard though. >>> >> I think it is safe to ignore OOME here, since this is the only place > As my test program shows, this may not be the only place where heap > allocation can happen within that code. > > Alan also mentioned something about instrumentation that can add memory > allocations basically anywhere. > As the reference handler code is plain java code, it will be affected as > other java code. > >> where heap allocation happens and it is known what provokes it. >> Otherwise ReferenceHandler just shuffles existing pointers in existing >> objects... > In the current compilers, yes. But what about other compilers/VMs that > may add more elaborate profiling information here and there? E.g. the > graal compiler? Not sure if it does, probably it does not, but it seems > shaky to rely on compiler code generation here. > > So is it possible to handle all known issues (especially if the fix is > similar/known/understandable), not just the original one, here? > > I mean, if we fix this issue as you suggested (I am not against that, it > looks reasonable), I would not know what to do with the test program > except file another bug against the very same component with the same > problem, with the same fix suggestion. > > I.e. the code still seems to buggy even after applying that fix, and > with instrumentation I think I could create another reproducer. As > reference processing is something critical to the VM, I think it is > prudent to fix all known problems here and now if possible. > > Maybe there is some argument against simply wrapping the entire loop > with a try-catch? Please elaborate if so (maybe I overlooked that?), or > maybe you could suggest another solution? > > Additionally, just fixing only the exact issue here seems somewhat > wasteful in terms of time (imho) - because next time another developer > will likely spend lots of time trying to reproduce this again. (As > mentioned, the former assignee also seemed to be unable to reproduce > this for a long time). > > Thanks, > Thomas Hi Thomas, I agree with you. If instrumentation/different JVM can throw OOME practicaly anywhere, then we have a problem with every such "critical" piece of code that is written in Java. What if instrumentation inserts allocation at the start of each loop? You might think this could be fixed by: for (;;) { // instrumentation added allocation #1 here try { for (;;) { // instrumentation added allocation #2 here ... } } catch (OutOfMemoryError ignore) {} } Say you successfully enter inner-loop and run it for a while. Then a heap shortage situation happens and "allocation #2" throws OOME, which is caught and ignored. In next iteration of outer-loop "allocation #1" will probably throw OOME too, since heap is probably still full... To be 100% sure such "critical" loop never ends, I only see two options: 1. move such loop to different environment (native code?) where allocations are more predictable or 2. add facility to Java/JVM that can mark portions of Java code where allocation happens more predictably The 2nd option could be specified as a kind of annotation on a method, for example: private static class ReferenceHandler extends Thread { @DontInstrument public void run() { ... } For the 1st option, we could create a native counterpart of the following static method: public class CriticalLoop { public static void doForever(Runnable runnable) { for (;;) { try { runnable.run(); } catch (OutOfMemoryError) { // wait a little uninterruptibly } } } } ...and use it in ReferenceHandler to run the critical loop. Regards, Peter From Alan.Bateman at oracle.com Mon May 6 12:52:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 May 2013 13:52:36 +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: <51829345.9070700@oracle.com> References: <516C0A14.1080408@oracle.com> <517F8C81.7030602@oracle.com> <51829345.9070700@oracle.com> Message-ID: <5187A794.1030502@oracle.com> On 02/05/2013 17:24, Daniel Fuchs wrote: > Hi, > > Please find an updated webrev below: > > > Changes are: > > catch IAE are removed - as suggested by Alan. > I didn't find traces of IAE being thrown by OutputStreamWriter > constructor in recent JDK - so I think it's safe to remove > those catch clauses. > > changes in test Makefile have been removed: I rebased my patch on > jdk8 tip, which already has these test Makefile changes. > > best regards, > > -- daniel Thanks, this looks good to me. -Alan From fweimer at redhat.com Mon May 6 13:59:49 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 06 May 2013 15:59:49 +0200 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5182F1F5.2030406@oracle.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> <5133BCD9.6060400@redhat.com> <5182F1F5.2030406@oracle.com> Message-ID: <5187B755.30504@redhat.com> On 05/03/2013 01:08 AM, Dan Xu wrote: > Hi All, > > Thanks for all your comments. Based on the previous feedback, I have > moved to the other approach, i.e., to fail file operations if the > invalid NUL characher is found in a file path. As you know, due to the > compatibility issue, we cannot throw an exception immediately in the > File constructors. So the failure is delayed and only shown up when any > file operation is triggered. > > As for FileInputStream, FileOutputStream, and RandomAccessFile classes, > the FileNotFoundException will be thrown right away since their spec > allow this exception happen in the constructors. Thanks for your review! > > webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/ I like this approach, thanks. I think the additional parenthesis around the return expression and the ternary operator are not part of the usual coding standard. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Mon May 6 15:03:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 May 2013 16:03:37 +0100 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367827347.2653.24.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> Message-ID: <5187C649.60903@oracle.com> On 06/05/2013 09:02, Thomas Schatzl wrote: > : > > Alan also mentioned something about instrumentation that can add memory > allocations basically anywhere. > As the reference handler code is plain java code, it will be affected as > other java code. I mentioned instrumentation on the off-chance that there was more to this puzzle. I think Peter is right and the allocation of the InterruptedException seems to be the only place where OOME is possible in this code. Do you know if these tests call Thread.interrupt on random threads (maybe as a stress test)? It is possible to get a reference to the Reference Handler thread via Thread.getAllStackTraces and a few other APIs so maybe this what is going on. If the tests aren't calling interrupt on random threads then it suggests to me that there is something else going on, maybe there is a lurking VM bug. In any case, it seems safe to catch/ignore OOME here. One of the mails mentioned ThreadDeath and I don't know if want to expand the scope of the patch. That seems a case where it should be like the Cleaner and terminate the VM. -Alan. From dl at cs.oswego.edu Mon May 6 16:16:05 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 06 May 2013 12:16:05 -0400 Subject: RFR [8005953] Speedup construction of CopyOnWriteArraySet in special cases In-Reply-To: <517FADD9.7030903@oracle.com> References: <517FADD9.7030903@oracle.com> Message-ID: <5187D745.8070702@cs.oswego.edu> On 04/30/13 07:41, Ivan Gerasimov wrote: > Hello everybody! > > Would you please review my proposal to change constructor of CopyOnWriteArraySet? I included something with similar effect in CopyOnWriteArray{List,Set} update in jsr166 repo: It bypasses copy in CopyOnWriteArrayList constructor (and, when empty, addAll) when argument is another CopyOnWriteArrayList. The CopyOnWriteArraySet constructor relays to it when possible. As Jason noted, this is a conservatively compatible change. It doesn't apply to non-CopyOnWriteArray{List,Set} arguments. We can integrate this into openjdk at next sync-up. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java?view=log http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArraySet.java?view=log -Doug From henry.jen at oracle.com Mon May 6 16:56:10 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 06 May 2013 09:56:10 -0700 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find Message-ID: <5187E0AA.405@oracle.com> Hi, Updated based on feedback, http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/specdiff/ Changed from previous request, 1. DirectoryStream.entries() is renamed to DirectoryStream.stream(). 2. Clarify operating closed stream returned from Files.list as end-of-stream, from Files.walk will throw IllegalStateException, and added test case. Cheers, Henry From huizhe.wang at oracle.com Mon May 6 17:49:19 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 06 May 2013 10:49:19 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5184B4CE.3080403@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> <5184B4CE.3080403@oracle.com> Message-ID: <5187ED1F.9030705@oracle.com> On 5/4/2013 12:12 AM, Alan Bateman wrote: > On 03/05/2013 19:02, huizhe wang wrote: >> : >> >> Removed the repetitive "value" definition from the >> setAttribute/setProperty methods. The open statements already have >> references to the properties in XMLConstants. >> >> Updated to: >> "The default value is implementation specific and therefore not >> specified. The following options are provided for consideration:" >> >> The 2nd paragraph already had the "recommendation" when FSP is set to >> true (same as in the JEP). > I looked at the updated webrev, again mostly focusing on the > javadoc/spec changes, and this looks much better. > > One comment on the "options for consideration" is that it reads "an > empty string to allow no access permission". This might be better as > "an empty string to deny all access to external references". Done. > > In each of the setProperty methods it specifies the exception that are > thrown when a connection is denied. For example in TransformerFactory > it reads "If access is denied during processing due to the restriction > of this property,TransformerConfigurationExceptionwill be thrown by > TransformerFactory". In this case I thought it was Transformer but > more generally the wording doesn't make it clear that it's the parse > or transform or whatever methods that throw the exceptions. I added more details to TransformerFactory, SchemaFactory and Validator on what exception is thrown by which method(s), e.g. * Access to external DTDs in the source file is restricted to the protocols specified by the |XMLConstants.ACCESS_EXTERNAL_DTD| property. If access is denied during transformation due to the restriction of this property, |TransformerException| will be thrown by |Transformer.transform(Source, Result)| . Access to external DTDs in the stylesheet is restricted to the protocols specified by the |XMLConstants.ACCESS_EXTERNAL_DTD| property. If access is denied during the creation of a new transformer due to the restriction of this property, |TransformerConfigurationException| will be thrown by the |newTransformer(Source)| method. Access to external reference set by the stylesheet processing instruction, Import and Include element is restricted to the protocols specified by the |XMLConstants.ACCESS_EXTERNAL_STYLESHEET| property. If access is denied during the creation of a new transformer due to the restriction of this property, |TransformerConfigurationException| will be thrown by the |newTransformer(Source)| method. Access to external document through XSLT document function is restricted to the protocols specified by the property. If access is denied during the transformation due to the restriction of this property, |TransformerException| will be thrown by the |Transformer.transform(Source, Result)| method. > > I agree with Daniel's comment that it is hard to completely assess > whether all code paths have been identified. It's a reminder that this > one needs extensive testing. True. I've added 176 new tests. JCK team is also testing using the current build of JAXP RI. I will also run regression tests. The new webrev included fixes to a couple of test failures in the last JPRT build. http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ Thanks, Joe > > -Alan From mike.duigou at oracle.com Mon May 6 17:49:24 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 May 2013 10:49:24 -0700 Subject: RFR: 8005051: optimized defaults for Iterator.forEachRemaining In-Reply-To: <51819D60.9090008@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> <51819D60.9090008@oracle.com> Message-ID: Looks good to me. I will run it through final integration tests and push to TL. Mike On May 1 2013, at 15:55 , Akhil Arora wrote: > On 04/26/2013 04:52 AM, 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); >> >> Paul. > > The testOptimizedForEach test verifies that remove() and previous() work as expected after forEachRemaining returns (lines 238-251). Please review - > > http://cr.openjdk.java.net/~akhil/8013150/webrev/ > > Somehow tests got left behind in the previous commit, adding them back. > > Thanks From joe.darcy at oracle.com Mon May 6 18:37:04 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 6 May 2013 11:37:04 -0700 (PDT) Subject: RFR 8013541: Revise javadoc for Executable.getAnnotatedReturnType() In-Reply-To: <5183AF0A.7050802@oracle.com> References: <5183AF0A.7050802@oracle.com> Message-ID: <5187F850.6080203@oracle.com> Hi Joel, Looks fine; cheers, -Joe On 05/03/2013 05:35 AM, Joel Borggr?n-Franck wrote: > Hello all, > > Also a small update to the javadoc of Executable to make it more > consistent for type annotations. > > http://cr.openjdk.java.net/~jfranck/8013541/webrev.00/ > > For oracle reviewers, CCC is filed. > > cheers > /Joel From peter.levart at gmail.com Mon May 6 19:42:38 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 06 May 2013 21:42:38 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <5187C649.60903@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> Message-ID: <518807AE.7040708@gmail.com> On 05/06/2013 05:03 PM, Alan Bateman wrote: > On 06/05/2013 09:02, Thomas Schatzl wrote: >> : >> >> Alan also mentioned something about instrumentation that can add memory >> allocations basically anywhere. >> As the reference handler code is plain java code, it will be affected as >> other java code. > I mentioned instrumentation on the off-chance that there was more to > this puzzle. > > I think Peter is right and the allocation of the InterruptedException > seems to be the only place where OOME is possible in this code. Do you > know if these tests call Thread.interrupt on random threads (maybe as > a stress test)? It is possible to get a reference to the Reference > Handler thread via Thread.getAllStackTraces and a few other APIs so > maybe this what is going on. If the tests aren't calling interrupt on > random threads then it suggests to me that there is something else > going on, maybe there is a lurking VM bug. > > In any case, it seems safe to catch/ignore OOME here. One of the mails > mentioned ThreadDeath and I don't know if want to expand the scope of > the patch. That seems a case where it should be like the Cleaner and > terminate the VM. I mentioned ThreadDeath as another possibility, similar to InterruptedException, that could cause OOME. OOME that would result from unsuccessful allocation of ThreadDeath error object in victim thread should not be ignored though. But it seems that JVM designers have already taken care of that, because contrary to InterruptedException the ThreadDeath error object is allocated in thread executing Thread.stop() method and this instance is later raised as exception in victim thread. So OOME in Object.wait() can only be caused by unsuccessful allocation of InterruptedException and nothing else. That was my final conclusion. ThreadDeath thrown in ReferenceHandler thread should not be caught and ignored. Regards, Peter > > -Alan. > > From peter.levart at gmail.com Mon May 6 20:34:26 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 06 May 2013 22:34:26 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367827347.2653.24.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> Message-ID: <518813D2.2060704@gmail.com> On 05/06/2013 10:02 AM, Thomas Schatzl wrote: > I mean, if we fix this issue as you suggested (I am not against that, it > looks reasonable), I would not know what to do with the test program > except file another bug against the very same component with the same > problem, with the same fix suggestion. Hi Thomas, If you want a simple reproducer for OOME in ReferenceHandler's Object.wait(), here is one: public class OOMEInReferenceHandler { static Object[] fillHeap() { Object[] first = null, last = null; int size = 1 << 20; while (size > 0) { try { Object[] array = new Object[size]; if (first == null) { first = array; } else { last[0] = array; } last = array; } catch (OutOfMemoryError oome) { size = size >>> 1; } } return first; } public static void main(String[] args) throws Exception { ReferenceQueue refQueue = new ReferenceQueue(); Object referent = new Object(); WeakReference weakRef = new WeakReference(referent, refQueue); ThreadGroup tg = Thread.currentThread().getThreadGroup(); for (ThreadGroup tgn = tg; tgn != null; tg = tgn, tgn = tg.getParent()); Thread[] threads = new Thread[tg.activeCount()]; Thread referenceHandlerThread = null; int n = tg.enumerate(threads); for (int i = 0; i < n; i++) { if("Reference Handler".equals(threads[i].getName())) { referenceHandlerThread = threads[i]; } } if (referenceHandlerThread == null) { throw new IllegalStateException("Couldn't find Reference Handler thread."); } Object waste = fillHeap(); referenceHandlerThread.interrupt(); Thread.sleep(1000L); waste = null; referent = null; System.gc(); Thread.sleep(1000L); System.out.println("weakRef.get() = " + weakRef.get()); System.out.println("refQueue.poll() = " + refQueue.poll()); } } ... just run it with some low heap setting like -Xmx128m or so. It doesn't need to be G1 garbage collector. Default will do. This prints on my computer: Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Reference Handler" weakRef.get() = null refQueue.poll() = null Regards, Peter Regards, Peter From dan.xu at oracle.com Mon May 6 20:44:45 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 06 May 2013 13:44:45 -0700 Subject: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly In-Reply-To: <5187B755.30504@redhat.com> References: <512D4F0B.8020903@oracle.com> <512D7009.70506@oracle.com> <512D74D7.2010902@oracle.com> <512DF6E9.4050100@gmail.com> <512DF8CA.20109@oracle.com> <5133ABE2.7080205@redhat.com> <5133BA10.8000103@oracle.com> <5133BCD9.6060400@redhat.com> <5182F1F5.2030406@oracle.com> <5187B755.30504@redhat.com> Message-ID: <5188163D.10908@oracle.com> On 05/06/2013 06:59 AM, Florian Weimer wrote: > On 05/03/2013 01:08 AM, Dan Xu wrote: >> Hi All, >> >> Thanks for all your comments. Based on the previous feedback, I have >> moved to the other approach, i.e., to fail file operations if the >> invalid NUL characher is found in a file path. As you know, due to the >> compatibility issue, we cannot throw an exception immediately in the >> File constructors. So the failure is delayed and only shown up when any >> file operation is triggered. >> >> As for FileInputStream, FileOutputStream, and RandomAccessFile classes, >> the FileNotFoundException will be thrown right away since their spec >> allow this exception happen in the constructors. Thanks for your review! >> >> webrev: http://cr.openjdk.java.net/~dxu/8003992/webrev.01/ > > I like this approach, thanks. > > I think the additional parenthesis around the return expression and > the ternary operator are not part of the usual coding standard. > Thank you for your good review. I will fix the format. As for the possible scenario, NUL appearing at the end of a path, I will regard it as the same kind of invalidity as other embedded NUL cases since there are no obvious use cases for that. I will push the fix today. Thanks! -Dan From brian.burkhalter at oracle.com Mon May 6 20:47:42 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 May 2013 13:47:42 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <5184FB80.7030203@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> Message-ID: <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> Hi Alan, Thank you for the detailed, thoughtful message. On May 4, 2013, at 5:13 AM, Alan Eliasen wrote: > If you're feeling overwhelmed by the magnitude of the changes to > BigInteger, I would very strongly suggest that you review it in stages. > This e-mail proposes stages for the review of this patch. It is indeed rather a lot, especially given that the Barrett plus SS code alone accounts for more lines of changes than do all the previously proposed changes combined. > Since I first posted these patches over 5 years ago, we were asked to > make patches as small as possible so they would get reviewed more > quickly. My rationale for attempting a larger review was that if these new changes were not examined now, then they will likely miss the JDK 8 train altogether. On the other hand if time were to run out on a large review then there would be a risk of nothing getting in. > That's why my patches focused on what was a minimal but > necessary subset: making multiply and pow work *much* faster with very > simple, understandable, well-known, hard-to-get-wrong routines and > simple optimizations that built on existing routines but gave very > significant performance increases. (Implementing Karatsuba and > Toom-Cook multiplication routines in Java is often given as a homework > problem in undergrad Algorithms courses. Understanding their > correctness requires nothing more than first-year Algebra.) Apparently - and fortunately - algebra as in pre-calculus not as in abstract (groups / rings / fields): something which I studied as an undergraduate but which has long since succumbed to brain rot. > Today, I finished porting my recursive Schoenhage toString routines > that I've been using for years in my programming language "Frink" ( > http://futureboy.us/frinkdocs/ ). They are drastically, stunningly > faster than the existing BigInteger.toString algorithms. The Schoenhage here is unrelated to SS multiplication? > I can personally vouch for having very strongly tested the parts of > multiplication and pow that I wrote, which include: > > * Karatsuba multiplication > * 3-way Toom-Cook multiplication > * Karatsuba squaring > * Toom-Cook squaring > * Revised pow() function That is good to know. > While I have been using Tim's Sch?nhage-Strassen multiplication and > Burnickel-Ziegler division routines in my daily work, and have not > detected failures, I have not written explicit tests for division at > all, and my number of very large integer divisions has been small. I > have implicitly used his division routines in my base conversion > routines for large numbers, and have found no errors. It looks like Tim has made some changes to BigIntegerTest which exercise the Burnickel-Ziegler code. > Brian, would it be possible to make BigInteger.square() public? I am looking into it. > If reviewing time is limited, I might suggest performing the reviews > and integration in a few steps: > > Step 1) would be integrating the simple, high-benefit, low-risk > changes that I made: > > * Karatsuba multiplication > * 3-way Toom-Cook multiplication > * Karatsuba squaring > * Toom-Cook squaring > * Revised pow() function This is equivalent to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 plus http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474. > Step 2) incorporating my toString changes. It's useless to work with > these very big numbers if you can't output them in reasonable time. The bug for improving toString is: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 > > My complete patch contains very much faster, simple Schoenhage > recursive base conversion routines for toString. This and quick look at your code answers my question, i.e., it is unrelated to SS multiplication. > Step 3) would involve faster division: The Burnickel-Ziegler and > Barrett division routines that Tim wrote. They are complicated. Based on Tim's subsequent comment ("[?] Barrett, especially because it is only useful in combination with Schoenhage-Strassen"), it seems that Barrett division should be moved to Step 4. > Step 4) integrating what I believe are the most tricky > routines: Schoenhage-Strassen (SS) multiplication. This stuff is hard. I think that your proposal for a staged review is a good plan including in terms of the order in which the algorithms would be addressed. I would like to know what others think about it. If this approach were taken, probably we should file three new issues for Burnickel-Ziegler division, Schoenhage-Strassen multiplication, and Barrett division, respectively. I can take care of this if it sounds reasonable. Also helpful to the process would be to have (four) staged patches available. I could take on this task as well, i.e., derive patches from the code provided thus far, but it might be safer if those more intimately familiar with the code helped out, especially as said patches might already exist somewhere. If I am not mistaken, the patch for Step 1 less the pow() improvements is this one: https://gist.github.com/tbuktu/1576025. For the time being I will start to look at this patch. > My latest best version of all of these routines is located at: > > http://futureboy.us/temp/BigInteger.java This is equivalent to the most recent version of TIm's repository https://github.com/tbuktu/bigint plus your changes for pow() and toString()? Thanks, Brian From peter.levart at gmail.com Mon May 6 21:04:25 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 06 May 2013 23:04:25 +0200 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: <51881AD9.208@gmail.com> On 04/30/2013 04:57 PM, Thomas Schatzl wrote: > 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. Hi Thomas, I don't think many people are doing that. Overriding package-private system classes/methods and putting custom code in boot classloader can break anything. I think that anyone messing with system code should catch his own OOMEs. Regards, Peter From dan.xu at oracle.com Mon May 6 21:18:54 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Mon, 06 May 2013 21:18:54 +0000 Subject: hg: jdk8/tl/jdk: 8003992: File and other classes in java.io do not handle embedded nulls properly Message-ID: <20130506211907.94A234884E@hg.openjdk.java.net> Changeset: bd118033e44c Author: dxu Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd118033e44c 8003992: File and other classes in java.io do not handle embedded nulls properly Summary: Have every file operation done with File, FileInputStream, FileOutputStream, or RandomAccessFile that involves a file path containing NUL fail. Also reviewed by fweimer at redhat.com Reviewed-by: alanb, sherman, ahgross, mduigou, dholmes, aph, plevart, martin ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/File/NulFile.java From peter.levart at gmail.com Mon May 6 21:44:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 06 May 2013 23:44:06 +0200 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518807AE.7040708@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> Message-ID: <51882426.2060801@gmail.com> On 05/06/2013 09:42 PM, Peter Levart wrote: > > On 05/06/2013 05:03 PM, Alan Bateman wrote: >> On 06/05/2013 09:02, Thomas Schatzl wrote: >>> : >>> >>> Alan also mentioned something about instrumentation that can add memory >>> allocations basically anywhere. >>> As the reference handler code is plain java code, it will be >>> affected as >>> other java code. >> I mentioned instrumentation on the off-chance that there was more to >> this puzzle. >> >> I think Peter is right and the allocation of the InterruptedException >> seems to be the only place where OOME is possible in this code. Do >> you know if these tests call Thread.interrupt on random threads >> (maybe as a stress test)? It is possible to get a reference to the >> Reference Handler thread via Thread.getAllStackTraces and a few other >> APIs so maybe this what is going on. If the tests aren't calling >> interrupt on random threads then it suggests to me that there is >> something else going on, maybe there is a lurking VM bug. >> >> In any case, it seems safe to catch/ignore OOME here. One of the >> mails mentioned ThreadDeath and I don't know if want to expand the >> scope of the patch. That seems a case where it should be like the >> Cleaner and terminate the VM. > > I mentioned ThreadDeath as another possibility, similar to > InterruptedException, that could cause OOME. OOME that would result > from unsuccessful allocation of ThreadDeath error object in victim > thread should not be ignored though. But it seems that JVM designers > have already taken care of that, because contrary to > InterruptedException the ThreadDeath error object is allocated in > thread executing Thread.stop() method and this instance is later > raised as exception in victim thread. So OOME in Object.wait() can > only be caused by unsuccessful allocation of InterruptedException and > nothing else. That was my final conclusion. ThreadDeath thrown in > ReferenceHandler thread should not be caught and ignored. If anyone is stop()-ing ReferenceHandler thread then it should be stopped. Speaking of that, if ThreadDeath is thrown in the middle of Cleaner's thunk.run() processing, then the Cleaner will exit JVM. I think ThreadDeath should be separately caught and re-thrown instead. Regards, Peter > > Regards, Peter > >> >> -Alan. >> >> > From mike.duigou at oracle.com Mon May 6 22:03:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 May 2013 15:03:39 -0700 Subject: reRFR: 4802647 : NullPointerException not thrown by AbstractCollection.retainAll/removeAll Message-ID: <6AC6B450-2826-45E1-A957-1FAD5AAA4656@oracle.com> Hello all; Long, long ago, Brandon Passanisi proposed a fix to correct non-conformant implementation of retainAll/removeAll(). It was reviewed but was never committed to TL repo (it got lost amidst Christmas vacation and other matters). Rather than surprise everyone with a rogue changeset they may have forgotten I'm reposting the review webrev and giving everyone a chance to change their mind. http://cr.openjdk.java.net/~mduigou/JDK-4802647/0/webrev/ Hearing no objections I will push this in about 24 hours. Mike From kumar.x.srinivasan at oracle.com Mon May 6 23:29:59 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 06 May 2013 16:29:59 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> Message-ID: <51883CF7.8030501@oracle.com> Here is the modified webrev: http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/ delta webrev to the last webrev: http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/webrev.delta/index.html I added the do { ..... } while (0) pattern to all the launcher's macro defs, I also addressed Alan's comments. I know that the native unpacker uses macros which will need this pattern I will fix that separately. Alan, do you want me to search and file bugs on other jdk components ? Thanks Kumar > Oops. Of course, that shouldn't have the trailing semicolon > > #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ > ncor_failure_return_value) \ > do { \ > if ((ncor_pointer_to_check) == NULL) { \ > JLI_ReportErrorMessage(JNI_ERROR); \ > return ncor_failure_return_value; \ > } \ > } while(0) > > > > On Thu, May 2, 2013 at 11:16 AM, Martin Buchholz > wrote: > > What would Martin actually do? > > #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ > ncor_failure_return_value) \ > do { \ > if ((ncor_pointer_to_check) == NULL) { \ > JLI_ReportErrorMessage(JNI_ERROR); \ > return ncor_failure_return_value; \ > } \ > } while(0); > > > > > On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan > > wrote: > > On 5/2/2013 10:17 AM, Martin Buchholz wrote: >> This is global fix creep, but ... > > :( > > >> >> these macros are also found in the hotspot sources. >> I would rewrite all the macros in the jdk to adopt the >> blessed style >> do { ... } while(0) >> and remove all comments in the jdk of the form >> /* next token must be ; */ >> If you want a macro that does nothing at all, you should >> define it >> do {} while (0) >> instead of defining it to the empty string. > I am not following, could you be more explicit on how this > applies to > > -#define NULL_CHECK0(e) if ((e) == 0) { \ > +#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ > JLI_ReportErrorMessage(JNI_ERROR); \ > - return 0; \ > + return rv; \ > } > > -#define NULL_CHECK(e) if ((e) == 0) { \ > - JLI_ReportErrorMessage(JNI_ERROR); \ > - return; \ > - } > +#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) > > +#define NULL_CHECK(e) NULL_CHECK_RV(e, ) > + > > >> >> >> I would also be inclined to change >> == 0 >> to >> == NULL >> > > Yes will take care of this, as well as Alan suggestion added a > check for malloc return. > > >> This seems like another occasion to use the weird >> >> do { ... } while(0) >> >> trick to make the macro behave more like a statement. >> >> I might obfuscate the macro parameters to make collisions >> less likely, e.g. e => N_C_RV_e >> > > You want me to rename the macro parameter e to N_C_RV_e ? or > something else > say ncrve to avoid collision ? > > Kumar > > >> >> >> >> >> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan >> > > wrote: >> >> Hi, >> >> Please review simple fixes for code correctness in >> the launcher. >> >> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >> >> >> Thanks >> Kumar >> >> >> > > > From martinrb at google.com Mon May 6 23:34:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 May 2013 16:34:03 -0700 Subject: reRFR: 4802647 : NullPointerException not thrown by AbstractCollection.retainAll/removeAll In-Reply-To: <6AC6B450-2826-45E1-A957-1FAD5AAA4656@oracle.com> References: <6AC6B450-2826-45E1-A957-1FAD5AAA4656@oracle.com> Message-ID: I recall considering whether to fix this "bug" myself many years ago. I decided that the value was so low (throw the "required" NPE when this collection is empty and the argument collection is null) that users who where not ultra-pedantic (or tck testers) would prefer the legacy behavior. And I would make the same decision today. But it's hard to really object to something that appears to make the implementation a bit more compliant with the spec. On Mon, May 6, 2013 at 3:03 PM, Mike Duigou wrote: > Hello all; > > Long, long ago, Brandon Passanisi proposed a fix to correct non-conformant > implementation of retainAll/removeAll(). It was reviewed but was never > committed to TL repo (it got lost amidst Christmas vacation and other > matters). Rather than surprise everyone with a rogue changeset they may > have forgotten I'm reposting the review webrev and giving everyone a chance > to change their mind. > > http://cr.openjdk.java.net/~mduigou/JDK-4802647/0/webrev/ > > Hearing no objections I will push this in about 24 hours. > > Mike From tbuktu at hotmail.com Mon May 6 23:35:01 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Tue, 7 May 2013 01:35:01 +0200 Subject: Relicensing of the BigInteger patch In-Reply-To: <51872CD2.8080702@oracle.com> References: <51872CD2.8080702@oracle.com> Message-ID: Hi, On 06.05.2013 06:08, Joe Darcy wrote: > Hello, > > With the standard disclaimers that IANAL and "this is not legal > advice," I suggest you review the "Do I lose any rights to my > contribution under the OCA?" question in the Oracle Contributor > Agreement FAQ: > > http://www.oracle.com/technetwork/oca-faq-405384.pdf > > HTH, > > -Joe That's pretty unambiguous. Thanks! Tim From tbuktu at hotmail.com Tue May 7 00:16:04 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Tue, 7 May 2013 02:16:04 +0200 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> Message-ID: Hi Brian, On 06.05.2013 22:47, Brian Burkhalter wrote: > > Also helpful to the process would be to have (four) staged patches > available. I could take on this task as well, i.e., derive patches > from the code provided thus far, but it might be safer if those more > intimately familiar with the code helped out, especially as said > patches might already exist somewhere. If I am not mistaken, the patch > for Step 1 less the pow() improvements is this > one: https://gist.github.com/tbuktu/1576025. For the time being I will > start to look at this patch. Note that it also includes Burnikel-Ziegler. I put it in there because BZ is kind of the division counterpart of Karatsuba/Toom-Cook, so I thought they should go together. If you go with Alan's proposal, we'd need to make a new patch with just Karatsuba, Toom-Cook, and pow(). Maybe Alan has that patch already. >> My latest best version of all of these routines is located at: >> >> http://futureboy.us/temp/BigInteger.java > > This is equivalent to the most recent version of TIm's repository > > https://github.com/tbuktu/bigint > > plus your changes for pow() and toString()? > They're the same except for some formatting changes I did so the old and new code would match. Tim From tbuktu at hotmail.com Tue May 7 00:19:19 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Tue, 7 May 2013 02:19:19 +0200 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> Message-ID: Replying to myself: > I will run the latest version of BigIntegerTest (which tests the above > mentioned numbers around powers of two) for a day or so and report back. The test ran successfully. Tim From brian.burkhalter at oracle.com Tue May 7 00:28:15 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 May 2013 17:28:15 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> Message-ID: On May 6, 2013, at 5:19 PM, Tim Buktu wrote: > Replying to myself: > >> I will run the latest version of BigIntegerTest (which tests the above >> mentioned numbers around powers of two) for a day or so and report back. > > The test ran successfully. Thanks for the update! Brian From brian.burkhalter at oracle.com Tue May 7 02:25:04 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 6 May 2013 19:25:04 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> Message-ID: <35EB4E5D-E72E-474C-AE28-1909EE65118B@oracle.com> Hi Tim, On May 6, 2013, at 5:16 PM, Tim Buktu wrote: >> If I am not mistaken, the patch >> for Step 1 less the pow() improvements is this >> one: https://gist.github.com/tbuktu/1576025. For the time being I will >> start to look at this patch. > > Note that it also includes Burnikel-Ziegler. I put it in there because > BZ is kind of the division counterpart of Karatsuba/Toom-Cook, so I > thought they should go together. If you go with Alan's proposal, we'd > need to make a new patch with just Karatsuba, Toom-Cook, and pow(). > Maybe Alan has that patch already. You are correct: I realized that I was mistaken after leaving work. >>> My latest best version of all of these routines is located at: >>> >>> http://futureboy.us/temp/BigInteger.java >> >> This is equivalent to the most recent version of TIm's repository >> >> https://github.com/tbuktu/bigint >> >> plus your changes for pow() and toString()? >> > They're the same except for some formatting changes I did so the old and > new code would match. OK - thanks. Brian From david.holmes at oracle.com Tue May 7 02:31:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 May 2013 12:31:30 +1000 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51882426.2060801@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> Message-ID: <51886782.60908@oracle.com> Catching ThreadDeath is futile. If someone is invoking stop() then you can encounter the ThreadDeath anywhere and it is impossible to write completely robust code in the face of such an async exception. So please let's not even go there. stop() is long deprecated and should never be used. Backing up I think the try/catch(IE|OOME) around wait() is the most reasonable solution here. Anyone messing with instrumentation or overriding etc can break things - so be it - don't do that. StackOverflowError can also completely break many things - again it is effectively an async exception and writing async-exception-safe Java code is impractical if not impossible. Cheers, David On 7/05/2013 7:44 AM, Peter Levart wrote: > > On 05/06/2013 09:42 PM, Peter Levart wrote: >> >> On 05/06/2013 05:03 PM, Alan Bateman wrote: >>> On 06/05/2013 09:02, Thomas Schatzl wrote: >>>> : >>>> >>>> Alan also mentioned something about instrumentation that can add memory >>>> allocations basically anywhere. >>>> As the reference handler code is plain java code, it will be >>>> affected as >>>> other java code. >>> I mentioned instrumentation on the off-chance that there was more to >>> this puzzle. >>> >>> I think Peter is right and the allocation of the InterruptedException >>> seems to be the only place where OOME is possible in this code. Do >>> you know if these tests call Thread.interrupt on random threads >>> (maybe as a stress test)? It is possible to get a reference to the >>> Reference Handler thread via Thread.getAllStackTraces and a few other >>> APIs so maybe this what is going on. If the tests aren't calling >>> interrupt on random threads then it suggests to me that there is >>> something else going on, maybe there is a lurking VM bug. >>> >>> In any case, it seems safe to catch/ignore OOME here. One of the >>> mails mentioned ThreadDeath and I don't know if want to expand the >>> scope of the patch. That seems a case where it should be like the >>> Cleaner and terminate the VM. >> >> I mentioned ThreadDeath as another possibility, similar to >> InterruptedException, that could cause OOME. OOME that would result >> from unsuccessful allocation of ThreadDeath error object in victim >> thread should not be ignored though. But it seems that JVM designers >> have already taken care of that, because contrary to >> InterruptedException the ThreadDeath error object is allocated in >> thread executing Thread.stop() method and this instance is later >> raised as exception in victim thread. So OOME in Object.wait() can >> only be caused by unsuccessful allocation of InterruptedException and >> nothing else. That was my final conclusion. ThreadDeath thrown in >> ReferenceHandler thread should not be caught and ignored. > > If anyone is stop()-ing ReferenceHandler thread then it should be > stopped. Speaking of that, if ThreadDeath is thrown in the middle of > Cleaner's thunk.run() processing, then the Cleaner will exit JVM. I > think ThreadDeath should be separately caught and re-thrown instead. > > Regards, Peter > >> >> Regards, Peter >> >>> >>> -Alan. >>> >>> >> > From martinrb at google.com Tue May 7 02:38:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 May 2013 19:38:33 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <51883CF7.8030501@oracle.com> References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> <51883CF7.8030501@oracle.com> Message-ID: This looks good. There's one check I found confusing. 175 if (alen <= 0 || alen > INT_MAX / sizeof(char *)) { Not that it matters much, but I'm not sure exactly what you're trying to check here. If you're trying to check that argc+2 doesn't overflow INT_MAX, I would do that directly in the original argc check. If you're trying to check that alen won't overflow, I would check something like (argc+2) < SIZE_MAX/sizeof(const char *) On 5/6/13, Kumar Srinivasan wrote: > Here is the modified webrev: > http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/ > > delta webrev to the last webrev: > http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/webrev.delta/index.html > > I added the do { ..... } while (0) pattern to all the launcher's macro > defs, > I also addressed Alan's comments. > > I know that the native unpacker uses macros which will need this pattern > I will fix that separately. > > Alan, do you want me to search and file bugs on other jdk components ? > > Thanks > Kumar > > > >> Oops. Of course, that shouldn't have the trailing semicolon >> >> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >> ncor_failure_return_value) \ >> do { \ >> if ((ncor_pointer_to_check) == NULL) { \ >> JLI_ReportErrorMessage(JNI_ERROR); \ >> return ncor_failure_return_value; \ >> } \ >> } while(0) >> >> >> >> On Thu, May 2, 2013 at 11:16 AM, Martin Buchholz > > wrote: >> >> What would Martin actually do? >> >> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >> ncor_failure_return_value) \ >> do { \ >> if ((ncor_pointer_to_check) == NULL) { \ >> JLI_ReportErrorMessage(JNI_ERROR); \ >> return ncor_failure_return_value; \ >> } \ >> } while(0); >> >> >> >> >> On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan >> > > wrote: >> >> On 5/2/2013 10:17 AM, Martin Buchholz wrote: >>> This is global fix creep, but ... >> >> :( >> >> >>> >>> these macros are also found in the hotspot sources. >>> I would rewrite all the macros in the jdk to adopt the >>> blessed style >>> do { ... } while(0) >>> and remove all comments in the jdk of the form >>> /* next token must be ; */ >>> If you want a macro that does nothing at all, you should >>> define it >>> do {} while (0) >>> instead of defining it to the empty string. >> I am not following, could you be more explicit on how this >> applies to >> >> -#define NULL_CHECK0(e) if ((e) == 0) { \ >> +#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ >> JLI_ReportErrorMessage(JNI_ERROR); \ >> - return 0; \ >> + return rv; \ >> } >> >> -#define NULL_CHECK(e) if ((e) == 0) { \ >> - JLI_ReportErrorMessage(JNI_ERROR); \ >> - return; \ >> - } >> +#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) >> >> +#define NULL_CHECK(e) NULL_CHECK_RV(e, ) >> + >> >> >>> >>> >>> I would also be inclined to change >>> == 0 >>> to >>> == NULL >>> >> >> Yes will take care of this, as well as Alan suggestion added a >> check for malloc return. >> >> >>> This seems like another occasion to use the weird >>> >>> do { ... } while(0) >>> >>> trick to make the macro behave more like a statement. >>> >>> I might obfuscate the macro parameters to make collisions >>> less likely, e.g. e => N_C_RV_e >>> >> >> You want me to rename the macro parameter e to N_C_RV_e ? or >> something else >> say ncrve to avoid collision ? >> >> Kumar >> >> >>> >>> >>> >>> >>> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan >>> >> > wrote: >>> >>> Hi, >>> >>> Please review simple fixes for code correctness in >>> the launcher. >>> >>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >>> >>> >>> Thanks >>> Kumar >>> >>> >>> >> >> >> > > From mike.duigou at oracle.com Tue May 7 03:56:18 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 03:56:18 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130507035652.E8C7F4885D@hg.openjdk.java.net> Changeset: e13cf31e5a96 Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e13cf31e5a96 8013712: Add Objects.nonNull and Objects.isNull Reviewed-by: mchung, darcy ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3cbb65d9af9e Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cbb65d9af9e 8013150: Iterator.remove and forEachRemaining relationship not specified Reviewed-by: mduigou 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 + test/java/util/Iterator/IteratorDefaults.java Changeset: 8221c421490f Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8221c421490f 8003258: BufferedReader.lines() Reviewed-by: alanb, mduigou, psandoz Contributed-by: Brian Goetz , Henry Jen ! src/share/classes/java/io/BufferedReader.java + src/share/classes/java/io/UncheckedIOException.java + test/java/io/BufferedReader/Lines.java From xueming.shen at oracle.com Tue May 7 04:25:15 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 07 May 2013 04:25:15 +0000 Subject: hg: jdk8/tl/jdk: 8013252: Regex Matcher .start and .end should be accessible by group name; ... Message-ID: <20130507042526.D8ED64885E@hg.openjdk.java.net> Changeset: b4a013f4eff4 Author: sherman Date: 2013-05-06 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4a013f4eff4 8013252: Regex Matcher .start and .end should be accessible by group name 8013254: Constructor \w need update to add the support of \p{Join_Control} Summary: added the requested methods and updated the \w constructor Reviewed-by: mchung, alanb ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/regex/UnicodeProp.java ! test/java/util/regex/POSIX_Unicode.java ! test/java/util/regex/RegExTest.java From weijun.wang at oracle.com Tue May 7 04:32:02 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 07 May 2013 04:32:02 +0000 Subject: hg: jdk8/tl/jdk: 8010192: Enable native JGSS provider on Mac Message-ID: <20130507043213.AB25048861@hg.openjdk.java.net> Changeset: 814dcc08df52 Author: weijun Date: 2013-05-07 12:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/814dcc08df52 8010192: Enable native JGSS provider on Mac Reviewed-by: valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/native/sun/security/jgss/wrapper/gssapi.h ! test/sun/security/krb5/runNameEquals.sh From jonathan.gibbons at oracle.com Tue May 7 05:52:07 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 May 2013 05:52:07 +0000 Subject: hg: jdk8/tl/langtools: 8009724: Enhance the DocTree API with DocTreePath Message-ID: <20130507055210.2F0D948865@hg.openjdk.java.net> Changeset: a7ff36d06fa2 Author: jlahoda Date: 2013-05-06 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a7ff36d06fa2 8009724: Enhance the DocTree API with DocTreePath Summary: Adding DocTreePath and DocTreePathScanner similar to TreePath and TreePathScanner, respectively Reviewed-by: jjg Contributed-by: Ralph Benjamin Ruijs , Jan Lahoda + src/share/classes/com/sun/source/util/DocTreePath.java + src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/doctree/DocTreePathScannerTest.java ! test/tools/javac/doctree/ReferenceTest.java From Alan.Bateman at oracle.com Tue May 7 06:46:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 May 2013 07:46:44 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5187ED1F.9030705@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> <5184B4CE.3080403@oracle.com> <5187ED1F.9030705@oracle.com> Message-ID: <5188A354.5070103@oracle.com> On 06/05/2013 18:49, huizhe wang wrote: > : > > True. I've added 176 new tests. JCK team is also testing using the > current build of JAXP RI. I will also run regression tests. > > The new webrev included fixes to a couple of test failures in the last > JPRT build. > > http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ At some point we need to figure out how to get the JAXP tests into the jaxp repository. I've looked at the updated javadoc and it looks good. A couple of nits: - DocumentBuilderFactory still says that SAXException is throw by DocumentBuilderFactory. - "or or" in SchemaFactory L428. -Alan From Alan.Bateman at oracle.com Tue May 7 06:56:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 May 2013 07:56:38 +0100 Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51882426.2060801@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> Message-ID: <5188A5A6.5000303@oracle.com> On 06/05/2013 22:44, Peter Levart wrote: > : > > If anyone is stop()-ing ReferenceHandler thread then it should be > stopped. Speaking of that, if ThreadDeath is thrown in the middle of > Cleaner's thunk.run() processing, then the Cleaner will exit JVM. I > think ThreadDeath should be separately caught and re-thrown instead. Yes, it should although I can't imagine anything other than tests wanting to do that. -Alan From huizhe.wang at oracle.com Tue May 7 07:39:18 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 07 May 2013 00:39:18 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5188A354.5070103@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> <5184B4CE.3080403@oracle.com> <5187ED1F.9030705@oracle.com> <5188A354.5070103@oracle.com> Message-ID: <5188AFA6.9070907@oracle.com> On 5/6/2013 11:46 PM, Alan Bateman wrote: > On 06/05/2013 18:49, huizhe wang wrote: >> : >> >> True. I've added 176 new tests. JCK team is also testing using the >> current build of JAXP RI. I will also run regression tests. >> >> The new webrev included fixes to a couple of test failures in the >> last JPRT build. >> >> http://cr.openjdk.java.net/~joehw/jdk8/8011653/webrev/ > At some point we need to figure out how to get the JAXP tests into the > jaxp repository. That would be nice. I'll ask again SQE's plan to start this. > > I've looked at the updated javadoc and it looks good. Great! thanks. > A couple of nits: > > - DocumentBuilderFactory still says that SAXException is throw by > DocumentBuilderFactory. Yes, that's what's in the jaxp1.3/1.4 spec unfortunately. Both DOM and SAX throws SAXException. It should have defined a DOMException for DOM operations. > > - "or or" in SchemaFactory L428. Fixed. Thanks, Joe > > > -Alan From Alan.Bateman at oracle.com Tue May 7 07:49:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 May 2013 08:49:38 +0100 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5188AFA6.9070907@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> <5184B4CE.3080403@oracle.com> <5187ED1F.9030705@oracle.com> <5188A354.5070103@oracle.com> <5188AFA6.9070907@oracle.com> Message-ID: <5188B212.8060402@oracle.com> On 07/05/2013 08:39, huizhe wang wrote: > > : > >> : >> >> - DocumentBuilderFactory still says that SAXException is throw by >> DocumentBuilderFactory. > > Yes, that's what's in the jaxp1.3/1.4 spec unfortunately. Both DOM and > SAX throws SAXException. It should have defined a DOMException for DOM > operations. I understand that. I was trying to point out the words "thrown by DocumentBuilder" should really be "thrown the parse methods defined by DocumentBuilder". Otherwise I think this is good to go. -Alan. From thomas.schatzl at oracle.com Tue May 7 07:51:21 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 May 2013 09:51:21 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51886782.60908@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> Message-ID: <1367913081.2658.7.camel@cirrus> Hi all, On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: > Catching ThreadDeath is futile. If someone is invoking stop() then you > can encounter the ThreadDeath anywhere and it is impossible to write > completely robust code in the face of such an async exception. So please > let's not even go there. stop() is long deprecated and should never be used. > > Backing up I think the try/catch(IE|OOME) around wait() is the most > reasonable solution here. Anyone messing with instrumentation or > overriding etc can break things - so be it - don't do that. > StackOverflowError can also completely break many things - again it is > effectively an async exception and writing async-exception-safe Java > code is impractical if not impossible. I can understand this reasoning. I provided a new patch (this time for review) http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements this change as suggested. Regarding regression testing, I marked this bug as "noreg-other" with the explanation that it is too hard to write a proper regression test, and the note that any test would involve using methods that we don't give any guarantees for (overriding package private jdk methods, instrumentation). I need reviewers and a sponsor pushing this as I don't have any role in the jdk project, and this is a jdk only patch. Thanks, Thomas From joel.franck at oracle.com Tue May 7 08:00:33 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 07 May 2013 08:00:33 +0000 Subject: hg: jdk8/tl/jdk: 8013541: Revise javadoc for Executable.getAnnotatedReturnType() Message-ID: <20130507080055.CBAA04886A@hg.openjdk.java.net> Changeset: 9c9b2385c1b0 Author: jfranck Date: 2013-05-07 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c9b2385c1b0 8013541: Revise javadoc for Executable.getAnnotatedReturnType() Reviewed-by: abuckley, darcy ! src/share/classes/java/lang/reflect/Executable.java From huizhe.wang at oracle.com Tue May 7 08:17:12 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 07 May 2013 01:17:12 -0700 Subject: JDK-8011653: Upgrade to JAXP 1.5 In-Reply-To: <5188B212.8060402@oracle.com> References: <5162743C.9030606@oracle.com> <5162B6E3.3090508@oracle.com> <516BB0C7.9090107@oracle.com> <516BC6BD.1090400@oracle.com> <516FC044.4070803@oracle.com> <51836ED3.3050600@oracle.com> <5183CE71.6070003@oracle.com> <5183FBCD.5060908@oracle.com> <5184B4CE.3080403@oracle.com> <5187ED1F.9030705@oracle.com> <5188A354.5070103@oracle.com> <5188AFA6.9070907@oracle.com> <5188B212.8060402@oracle.com> Message-ID: <5188B888.5040704@oracle.com> On 5/7/2013 12:49 AM, Alan Bateman wrote: > On 07/05/2013 08:39, huizhe wang wrote: >> >> : >> >>> : >>> >>> - DocumentBuilderFactory still says that SAXException is throw by >>> DocumentBuilderFactory. >> >> Yes, that's what's in the jaxp1.3/1.4 spec unfortunately. Both DOM >> and SAX throws SAXException. It should have defined a DOMException >> for DOM operations. > I understand that. I was trying to point out the words "thrown by > DocumentBuilder" should really be "thrown the parse methods defined by > DocumentBuilder". Ah, I see! It now reads: * {@link org.xml.sax.SAXException} will be thrown by the parse methods defined by * {@link javax.xml.parsers.DocumentBuilder}. and for SAXParser: {@link org.xml.sax.SAXException} will be thrown by the parse methods defined by {@link javax.xml.parsers.SAXParser}. and for XMLInputFactory {@link javax.xml.stream.XMLStreamException} * will be thrown by {@link javax.xml.stream.XMLStreamReader#next()} or * {@link javax.xml.stream.XMLEventReader#nextEvent()}. > > Otherwise I think this is good to go. Thanks! Joe > > -Alan. From eliasen at mindspring.com Tue May 7 09:33:13 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Tue, 07 May 2013 03:33:13 -0600 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> Message-ID: <5188CA59.9040100@mindspring.com> > On May 4, 2013, at 5:13 AM, Alan Eliasen wrote: >> If you're feeling overwhelmed by the magnitude of the changes to >> BigInteger, I would very strongly suggest that you review it in >> stages. This e-mail proposes stages for the review of this patch. On 05/06/2013 02:47 PM, Brian Burkhalter wrote: > It is indeed rather a lot, especially given that the Barrett plus SS > code alone accounts for more lines of changes than do all the > previously proposed changes combined. I agree that the complexity and volume of code needed to implement Barrett division and SS multiplication are significantly larger than Karatsuba and Toom-Cook. > My rationale for attempting a larger review was that if these new > changes were not examined now, then they will likely miss the JDK 8 > train altogether. On the other hand if time were to run out on a > large review then there would be a risk of nothing getting in. Yes, I understand that concern, which is why I think a staged review makes sense. I've noted before that the leading researcher in Toom-Cook multiplication, Marco Bodrato, and his colleagues reviewed my Karatsuba and Toom-Cook patches, and called them "very clean." This review was performed to a level of subtlety that they suggested a slighty different proven-optimal Toom-Cook formulation that came from their research. This allowed me to remove one shiftLeft from the routine. This should give some confidence and reduce review concerns for Karatsuba and Toom-Cook multiplication. (Believe me, I've tried to do everything I can to simplify the review effort!) Since first posting these patches, I have had a large number of Java users contact *me* and use these routines in their JDK. I know that these improvements are in good demand and have been widely tested. I have used these in very large computational efforts for years, and tested them against >> Today, I finished porting my recursive Schoenhage toString >> routines that I've been using for years in my programming language >> "Frink" ( http://futureboy.us/frinkdocs/ ). They are drastically, >> stunningly faster than the existing BigInteger.toString >> algorithms. > > The Schoenhage here is unrelated to SS multiplication? As you noted later, yes, the routines were both described by (I believe) the same Schoenhage, but the algorithm has nothing to do with the Fourier transforms that make up SS multiplication. The Schoenhage base conversion is quite simple; it's a recursive divide-and-conquer that breaks each number approximately in half and then formats each half separately, which can be done faster. >> Step 3) would involve faster division: The Burnickel-Ziegler and >> Barrett division routines that Tim wrote. They are complicated. > > Based on Tim's subsequent comment ("[?] Barrett, especially because > it is only useful in combination with Schoenhage-Strassen"), it seems > that Barrett division should be moved to Step 4. Yes, that's a good point. I agree that Barrett division should be moved to the same timeframe as SS multiplication. If it makes it more likely that we get an improved division routine (in Burnickel-Ziegler) then it's more likely to give a useful combination of features in Java 1.8. > If this approach were taken, probably we should file three new issues > for Burnickel-Ziegler division, Schoenhage-Strassen multiplication, > and Barrett division, respectively. I can take care of this if it > sounds reasonable. That's fine with me. There are several bugs involved that you can close after this: 4228681: Some BigInteger operations are slow with very large numbers http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228681 (this was closed but never fixed.) 4837946: Implement Karatsuba multiplication algorithm in BigInteger http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 4646474: BigInteger.pow() algorithm slow in 1.4.0 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 This is improved in many ways: * Rewrote pow() to use Karatsuba and Toom-Cook multiplication * Implemented Karatsuba squaring * Immplemented 3-way Toom-Cook squaring * Found good threshholds for Karatsuba and Toom-Cook squaring * Added an optimization to use left-shifting for multiples of 2 in the base. This improved speed by thousands of times for things like Mersenne numbers, and may be one of the most significant improvements for practical programs. 4641897: BigInteger.toString() algorithm slow for large numbers http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 > Also helpful to the process would be to have (four) staged patches > available. I could take on this task as well, i.e., derive patches > from the code provided thus far, but it might be safer if those more > intimately familiar with the code helped out, especially as said > patches might already exist somewhere. Okay, I can provide patches for each of these phases if you'd like. The patch for the first phase you're looking at (below) would be a good place to start. Do you want these as actual patches? Or just the whole file that you can drop into place? If you prefer patches, what format would you like them in? > If I am not mistaken, the > patch for Step 1 less the pow() improvements is this one: > https://gist.github.com/tbuktu/1576025. For the time being I will > start to look at this patch. That seems like a good place to start. It doesn't include the pow() fixes, though. >> My latest best version of all of these routines is located at: >> >> http://futureboy.us/temp/BigInteger.java > > This is equivalent to the most recent version of TIm's repository > > https://github.com/tbuktu/bigint > > plus your changes for pow() and toString()? Yes, Tim merged my toString changes into his github repository. The files there contain all of our known changes. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From daniel.fuchs at oracle.com Tue May 7 09:58:24 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 07 May 2013 09:58:24 +0000 Subject: hg: jdk8/tl/jaxp: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <20130507095833.BA0374886F@hg.openjdk.java.net> Changeset: 452e1a182907 Author: dfuchs Date: 2013-05-06 18:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/452e1a182907 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb ! src/com/sun/org/apache/xml/internal/serializer/Encodings.java From daniel.fuchs at oracle.com Tue May 7 09:59:09 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 07 May 2013 09:59:09 +0000 Subject: hg: jdk8/tl/jdk: 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <20130507100036.C35C948870@hg.openjdk.java.net> Changeset: 2602eab5f086 Author: dfuchs Date: 2013-05-07 11:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2602eab5f086 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb + test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java From peter.levart at gmail.com Tue May 7 13:12:08 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 07 May 2013 15:12:08 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367913081.2658.7.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> Message-ID: <5188FDA8.3080303@gmail.com> On 05/07/2013 09:51 AM, Thomas Schatzl wrote: > Hi all, > > On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: >> Catching ThreadDeath is futile. If someone is invoking stop() then you >> can encounter the ThreadDeath anywhere and it is impossible to write >> completely robust code in the face of such an async exception. So please >> let's not even go there. stop() is long deprecated and should never be used. >> >> Backing up I think the try/catch(IE|OOME) around wait() is the most >> reasonable solution here. Anyone messing with instrumentation or >> overriding etc can break things - so be it - don't do that. >> StackOverflowError can also completely break many things - again it is >> effectively an async exception and writing async-exception-safe Java >> code is impractical if not impossible. > I can understand this reasoning. > > I provided a new patch (this time for review) > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements > this change as suggested. > > Regarding regression testing, I marked this bug as "noreg-other" with > the explanation that it is too hard to write a proper regression test, > and the note that any test would involve using methods that we don't > give any guarantees for (overriding package private jdk methods, > instrumentation). Hi Thomas, Does the bug reproducer I sent to the list not work for you? The test can check the return value of refQueue.poll() and decide if it passes or not (null return means the ReferenceHandler thread has died and the bug is here, non-null return means thread still works and there is no bug). Regards, Peter > > I need reviewers and a sponsor pushing this as I don't have any role in > the jdk project, and this is a jdk only patch. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue May 7 13:26:36 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 May 2013 15:26:36 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <5188FDA8.3080303@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> Message-ID: <1367933196.2658.87.camel@cirrus> Hi, On Tue, 2013-05-07 at 15:12 +0200, Peter Levart wrote: > On 05/07/2013 09:51 AM, Thomas Schatzl wrote: > > Hi all, > > > > On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: > >> Catching ThreadDeath is futile. If someone is invoking stop() then you > >> can encounter the ThreadDeath anywhere and it is impossible to write > >> completely robust code in the face of such an async exception. So please > >> let's not even go there. stop() is long deprecated and should never be used. > >> > >> Backing up I think the try/catch(IE|OOME) around wait() is the most > >> reasonable solution here. Anyone messing with instrumentation or > >> overriding etc can break things - so be it - don't do that. > >> StackOverflowError can also completely break many things - again it is > >> effectively an async exception and writing async-exception-safe Java > >> code is impractical if not impossible. > > I can understand this reasoning. > > > > I provided a new patch (this time for review) > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements > > this change as suggested. > > > > Regarding regression testing, I marked this bug as "noreg-other" with > > the explanation that it is too hard to write a proper regression test, > > and the note that any test would involve using methods that we don't > > give any guarantees for (overriding package private jdk methods, > > instrumentation). > > Hi Thomas, > > Does the bug reproducer I sent to the list not work for you? The test > can check the return value of refQueue.poll() and decide if it passes or > not (null return means the ReferenceHandler thread has died and the bug > is here, non-null return means thread still works and there is no bug). I will check the code again, but unfortunately I think it does not help a lot. The problem of reproducing this issue is trying to get the ReferenceHandler to die, i.e. have the OOME occur in the reference handler thread. The allocation of the InterruptedException is such a small allocation so that in almost all of the cases of OOME, its allocation still succeeds or is not the actual cause for the OOME. So the probability that the java application threads get the OOME to handle is much higher, especially in the stress tests. There is a message emitted by the VM reading "java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Reference Handler"" that is sufficient to detect the problem itself (at least if you enable some flags). I will look at it again and report back if it can be used in some way. Thanks, Thomas From jason_mehrens at hotmail.com Tue May 7 13:36:36 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 7 May 2013 08:36:36 -0500 Subject: RFR : 7129185 : Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: Mike, EmptyNavigableMap and EmptyNavigableSet should contain the static final references themselves and not the Collections class. That way they load on demand and not with the Collections class. Use default visibility inside the inner class so the compiler doesn't generate method to promote access. See the EmptyIterator class. Jason ---------------------------------------- > From: mike.duigou at oracle.com > Subject: RFR : 7129185 : Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} > Date: Mon, 29 Apr 2013 18:54:19 -0700 > To: core-libs-dev at openjdk.java.net > > 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 robert.field at oracle.com Tue May 7 13:40:47 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 07 May 2013 13:40:47 +0000 Subject: hg: jdk8/tl/langtools: 8014023: When a method reference to a local class constructor is contained in a method whose number of parameters matches the number of constructor parameters compilation fails Message-ID: <20130507134050.5103F48876@hg.openjdk.java.net> Changeset: 68142e69cafb Author: rfield Date: 2013-05-07 06:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/68142e69cafb 8014023: When a method reference to a local class constructor is contained in a method whose number of parameters matches the number of constructor parameters compilation fails Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReference/TreeMakerParamsIsGoofy.java From peter.levart at gmail.com Tue May 7 14:10:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 07 May 2013 16:10:15 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367933196.2658.87.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> Message-ID: <51890B47.2010002@gmail.com> On 05/07/2013 03:26 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2013-05-07 at 15:12 +0200, Peter Levart wrote: >> On 05/07/2013 09:51 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: >>>> Catching ThreadDeath is futile. If someone is invoking stop() then you >>>> can encounter the ThreadDeath anywhere and it is impossible to write >>>> completely robust code in the face of such an async exception. So please >>>> let's not even go there. stop() is long deprecated and should never be used. >>>> >>>> Backing up I think the try/catch(IE|OOME) around wait() is the most >>>> reasonable solution here. Anyone messing with instrumentation or >>>> overriding etc can break things - so be it - don't do that. >>>> StackOverflowError can also completely break many things - again it is >>>> effectively an async exception and writing async-exception-safe Java >>>> code is impractical if not impossible. >>> I can understand this reasoning. >>> >>> I provided a new patch (this time for review) >>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements >>> this change as suggested. >>> >>> Regarding regression testing, I marked this bug as "noreg-other" with >>> the explanation that it is too hard to write a proper regression test, >>> and the note that any test would involve using methods that we don't >>> give any guarantees for (overriding package private jdk methods, >>> instrumentation). >> Hi Thomas, >> >> Does the bug reproducer I sent to the list not work for you? The test >> can check the return value of refQueue.poll() and decide if it passes or >> not (null return means the ReferenceHandler thread has died and the bug >> is here, non-null return means thread still works and there is no bug). > I will check the code again, but unfortunately I think it does not help > a lot. > > The problem of reproducing this issue is trying to get the > ReferenceHandler to die, i.e. have the OOME occur in the reference > handler thread. > > The allocation of the InterruptedException is such a small allocation so > that in almost all of the cases of OOME, its allocation still succeeds > or is not the actual cause for the OOME. So the probability that the > java application threads get the OOME to handle is much higher, > especially in the stress tests. > > There is a message emitted by the VM reading "java.lang.OutOfMemoryError > thrown from the UncaughtExceptionHandler in thread "Reference Handler"" > that is sufficient to detect the problem itself (at least if you enable > some flags). > > I will look at it again and report back if it can be used in some way. On my computer the test always produced the same result. So it's pretty reliable. The trick is in fillHeap() method that fills the heap so that even "new Object[1]" throws OOME. Throwable object takes at least the same space as Object[1]; Regards, Peter > > Thanks, > Thomas > > From kumar.x.srinivasan at oracle.com Tue May 7 14:15:10 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 07 May 2013 07:15:10 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> <51883CF7.8030501@oracle.com> Message-ID: <51890C6E.5010801@oracle.com> On 5/6/2013 7:38 PM, Martin Buchholz wrote: > This looks good. > > There's one check I found confusing. > > 175 if (alen <= 0 || alen > INT_MAX / sizeof(char *)) { > > Not that it matters much, but I'm not sure exactly what you're trying > to check here. > If you're trying to check that argc+2 doesn't overflow INT_MAX, I > would do that directly in the original argc check. Making sure alen won't overflow, I will look into your suggestion. Kumar > If you're trying to check that alen won't overflow, I would check something like > (argc+2) < SIZE_MAX/sizeof(const char *) > > On 5/6/13, Kumar Srinivasan wrote: >> Here is the modified webrev: >> http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/ >> >> delta webrev to the last webrev: >> http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/webrev.delta/index.html >> >> I added the do { ..... } while (0) pattern to all the launcher's macro >> defs, >> I also addressed Alan's comments. >> >> I know that the native unpacker uses macros which will need this pattern >> I will fix that separately. >> >> Alan, do you want me to search and file bugs on other jdk components ? >> >> Thanks >> Kumar >> >> >> >>> Oops. Of course, that shouldn't have the trailing semicolon >>> >>> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >>> ncor_failure_return_value) \ >>> do { \ >>> if ((ncor_pointer_to_check) == NULL) { \ >>> JLI_ReportErrorMessage(JNI_ERROR); \ >>> return ncor_failure_return_value; \ >>> } \ >>> } while(0) >>> >>> >>> >>> On Thu, May 2, 2013 at 11:16 AM, Martin Buchholz >> > wrote: >>> >>> What would Martin actually do? >>> >>> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >>> ncor_failure_return_value) \ >>> do { \ >>> if ((ncor_pointer_to_check) == NULL) { \ >>> JLI_ReportErrorMessage(JNI_ERROR); \ >>> return ncor_failure_return_value; \ >>> } \ >>> } while(0); >>> >>> >>> >>> >>> On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan >>> >> > wrote: >>> >>> On 5/2/2013 10:17 AM, Martin Buchholz wrote: >>>> This is global fix creep, but ... >>> :( >>> >>> >>>> these macros are also found in the hotspot sources. >>>> I would rewrite all the macros in the jdk to adopt the >>>> blessed style >>>> do { ... } while(0) >>>> and remove all comments in the jdk of the form >>>> /* next token must be ; */ >>>> If you want a macro that does nothing at all, you should >>>> define it >>>> do {} while (0) >>>> instead of defining it to the empty string. >>> I am not following, could you be more explicit on how this >>> applies to >>> >>> -#define NULL_CHECK0(e) if ((e) == 0) { \ >>> +#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ >>> JLI_ReportErrorMessage(JNI_ERROR); \ >>> - return 0; \ >>> + return rv; \ >>> } >>> >>> -#define NULL_CHECK(e) if ((e) == 0) { \ >>> - JLI_ReportErrorMessage(JNI_ERROR); \ >>> - return; \ >>> - } >>> +#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) >>> >>> +#define NULL_CHECK(e) NULL_CHECK_RV(e, ) >>> + >>> >>> >>>> >>>> I would also be inclined to change >>>> == 0 >>>> to >>>> == NULL >>>> >>> Yes will take care of this, as well as Alan suggestion added a >>> check for malloc return. >>> >>> >>>> This seems like another occasion to use the weird >>>> >>>> do { ... } while(0) >>>> >>>> trick to make the macro behave more like a statement. >>>> >>>> I might obfuscate the macro parameters to make collisions >>>> less likely, e.g. e => N_C_RV_e >>>> >>> You want me to rename the macro parameter e to N_C_RV_e ? or >>> something else >>> say ncrve to avoid collision ? >>> >>> Kumar >>> >>> >>>> >>>> >>>> >>>> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Please review simple fixes for code correctness in >>>> the launcher. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >>>> >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >>> >>> >> From fweimer at redhat.com Tue May 7 14:42:33 2013 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 07 May 2013 16:42:33 +0200 Subject: JEP 185: JAXP 1.5: Restrict Fetching of External Resources In-Reply-To: <20130430230031.1B3759E7@eggemoggin.niobe.net> References: <20130430230031.1B3759E7@eggemoggin.niobe.net> Message-ID: <518912D9.3070804@redhat.com> On 05/01/2013 01:00 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/185 Are other robustness improvements out of scope? The "Schema Component Constraint: Unique Particle Attribution" comes to my mind, which is currently not enforced by OpenJDK. -- Florian Weimer / Red Hat Product Security Team From chris.hegarty at oracle.com Tue May 7 14:51:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 15:51:19 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements Message-ID: <518914E7.80109@oracle.com> Doug has made some updates to the java.util.Arrays sorting code to provide stable sorting. There have also been some changes to the original Parallel Array Sorting ( MIN_ARRAY_SORT_GRAN is public again ). Right now a copy of this work is sitting in the lambda repo. This issue proposed to integrate this work into jdk8. http://cr.openjdk.java.net/~chegar/8014076/ver.00/specdiff/java/util/Arrays.html http://cr.openjdk.java.net/~chegar/8014076/ver.00/webrev/ Thanks, -Chris. From jesper.wilhelmsson at oracle.com Tue May 7 15:07:59 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 07 May 2013 17:07:59 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367933196.2658.87.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> Message-ID: <518918CF.2020703@oracle.com> Thomas Schatzl skrev 7/5/13 3:26 PM: > Hi, > > On Tue, 2013-05-07 at 15:12 +0200, Peter Levart wrote: >> On 05/07/2013 09:51 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote: >>>> Catching ThreadDeath is futile. If someone is invoking stop() then you >>>> can encounter the ThreadDeath anywhere and it is impossible to write >>>> completely robust code in the face of such an async exception. So please >>>> let's not even go there. stop() is long deprecated and should never be used. >>>> >>>> Backing up I think the try/catch(IE|OOME) around wait() is the most >>>> reasonable solution here. Anyone messing with instrumentation or >>>> overriding etc can break things - so be it - don't do that. >>>> StackOverflowError can also completely break many things - again it is >>>> effectively an async exception and writing async-exception-safe Java >>>> code is impractical if not impossible. >>> I can understand this reasoning. >>> >>> I provided a new patch (this time for review) >>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements >>> this change as suggested. >>> >>> Regarding regression testing, I marked this bug as "noreg-other" with >>> the explanation that it is too hard to write a proper regression test, >>> and the note that any test would involve using methods that we don't >>> give any guarantees for (overriding package private jdk methods, >>> instrumentation). >> >> Hi Thomas, >> >> Does the bug reproducer I sent to the list not work for you? The test >> can check the return value of refQueue.poll() and decide if it passes or >> not (null return means the ReferenceHandler thread has died and the bug >> is here, non-null return means thread still works and there is no bug). > > I will check the code again, but unfortunately I think it does not help > a lot. > > The problem of reproducing this issue is trying to get the > ReferenceHandler to die, i.e. have the OOME occur in the reference > handler thread. > > The allocation of the InterruptedException is such a small allocation so > that in almost all of the cases of OOME, its allocation still succeeds > or is not the actual cause for the OOME. So the probability that the > java application threads get the OOME to handle is much higher, > especially in the stress tests. Would it be possible to pad the InterruptedException object by adding some huge instance variable to make it bigger and thus increase the probability for OOME? /Jesper > > There is a message emitted by the VM reading "java.lang.OutOfMemoryError > thrown from the UncaughtExceptionHandler in thread "Reference Handler"" > that is sufficient to detect the problem itself (at least if you enable > some flags). > > I will look at it again and report back if it can be used in some way. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Tue May 7 15:09:05 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 May 2013 17:09:05 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51890B47.2010002@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> Message-ID: <1367939345.2658.102.camel@cirrus> Hi, On Tue, 2013-05-07 at 16:10 +0200, Peter Levart wrote: > On 05/07/2013 03:26 PM, Thomas Schatzl wrote: > > Hi, > > > There is a message emitted by the VM reading "java.lang.OutOfMemoryError > > thrown from the UncaughtExceptionHandler in thread "Reference Handler"" > > that is sufficient to detect the problem itself (at least if you enable > > some flags). > > > > I will look at it again and report back if it can be used in some way. > > On my computer the test always produced the same result. So it's pretty > reliable. The trick is in fillHeap() method that fills the heap so that > even "new Object[1]" throws OOME. Throwable object takes at least the > same space as Object[1]; > It is fine, thanks. Since you're openjdk author already (plevart?), I will set you as author for the change - as you both provided the fix as well as the reproducer. I merely added boilerplate code. I will provide a webrev as soon as a jprt run goes through. Thanks everyone, Thomas From mike.duigou at oracle.com Tue May 7 15:46:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 7 May 2013 08:46:14 -0700 Subject: RFR : 7129185 : Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: <3348495C-BDCA-4989-A682-B5769E5289E7@oracle.com> Good suggestion, thank you. Mike On May 7 2013, at 06:36 , Jason Mehrens wrote: > Mike, > > EmptyNavigableMap and EmptyNavigableSet should contain the static final references themselves and not the Collections class. That way they load on demand and not with the Collections class. Use default visibility inside the inner class so the compiler doesn't generate method to promote access. See the EmptyIterator class. > > Jason > > > ---------------------------------------- >> From: mike.duigou at oracle.com >> Subject: RFR : 7129185 : Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} >> Date: Mon, 29 Apr 2013 18:54:19 -0700 >> To: core-libs-dev at openjdk.java.net >> >> 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 May 7 16:04:01 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 7 May 2013 09:04:01 -0700 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518914E7.80109@oracle.com> References: <518914E7.80109@oracle.com> Message-ID: <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. Mike On May 7 2013, at 07:51 , Chris Hegarty wrote: > Doug has made some updates to the java.util.Arrays sorting code to provide stable sorting. There have also been some changes to the original Parallel Array Sorting ( MIN_ARRAY_SORT_GRAN is public again ). > > Right now a copy of this work is sitting in the lambda repo. This issue proposed to integrate this work into jdk8. > > http://cr.openjdk.java.net/~chegar/8014076/ver.00/specdiff/java/util/Arrays.html > http://cr.openjdk.java.net/~chegar/8014076/ver.00/webrev/ > > Thanks, > -Chris. From chris.hegarty at oracle.com Tue May 7 17:13:25 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 May 2013 18:13:25 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> Message-ID: <51893635.4070300@oracle.com> On 05/07/2013 05:04 PM, Mike Duigou wrote: > The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? No problem. That would read... "When the sub-array length reaches a {@linlplain #MIN_ARRAY_SORT_GRAN minimum granularity}, the sub-array is sorted using the appropriate Arrays.sort method." > I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. I really don't care much for MIN_ARRAY_SORT_GRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. -Chris. > > Mike > > On May 7 2013, at 07:51 , Chris Hegarty wrote: > >> Doug has made some updates to the java.util.Arrays sorting code to provide stable sorting. There have also been some changes to the original Parallel Array Sorting ( MIN_ARRAY_SORT_GRAN is public again ). >> >> Right now a copy of this work is sitting in the lambda repo. This issue proposed to integrate this work into jdk8. >> >> http://cr.openjdk.java.net/~chegar/8014076/ver.00/specdiff/java/util/Arrays.html >> http://cr.openjdk.java.net/~chegar/8014076/ver.00/webrev/ >> >> Thanks, >> -Chris. > From staffan.larsen at oracle.com Tue May 7 17:58:16 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 07 May 2013 17:58:16 +0000 Subject: hg: jdk8/tl/jdk: 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1; ... Message-ID: <20130507175848.2F40E48885@hg.openjdk.java.net> Changeset: 7b40394ad944 Author: sla Date: 2013-05-07 19:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b40394ad944 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1 7181907: TEST_BUG: j/l/management/MemoryMXBean/ResetPeakMemoryUsage fails with NegativeArraySizeException 7148492: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java failing since update to hs23-b15 or b16 Reviewed-by: mchung, brutisso ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java From staffan.larsen at oracle.com Tue May 7 18:02:05 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 07 May 2013 18:02:05 +0000 Subject: hg: jdk8/tl/jdk: 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true Message-ID: <20130507180217.528FF48886@hg.openjdk.java.net> Changeset: 100027950b05 Author: sla Date: 2013-05-07 20:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/100027950b05 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true Reviewed-by: alanb, dsamersoff ! test/sun/tools/jinfo/Basic.sh From kumar.x.srinivasan at oracle.com Tue May 7 18:23:16 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 07 May 2013 11:23:16 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <51890C6E.5010801@oracle.com> References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> <51883CF7.8030501@oracle.com> <51890C6E.5010801@oracle.com> Message-ID: <51894694.4040800@oracle.com> On 5/7/2013 7:15 AM, Kumar Srinivasan wrote: > On 5/6/2013 7:38 PM, Martin Buchholz wrote: >> This looks good. >> >> There's one check I found confusing. >> >> 175 if (alen <= 0 || alen > INT_MAX / sizeof(char *)) { >> >> Not that it matters much, but I'm not sure exactly what you're trying >> to check here. >> If you're trying to check that argc+2 doesn't overflow INT_MAX, I >> would do that directly in the original argc check. > > Making sure alen won't overflow, I will look into your suggestion. I think I will leave it as-is, jexec, it appears may not be needed, this was added for Solaris primarily, and I am not sure if this is required anymore (as Alan pointed out earlier), I need to research this, and likely yank out jexec.c completely. Kumar > > Kumar > >> If you're trying to check that alen won't overflow, I would check >> something like >> (argc+2) < SIZE_MAX/sizeof(const char *) >> >> On 5/6/13, Kumar Srinivasan wrote: >>> Here is the modified webrev: >>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/ >>> >>> delta webrev to the last webrev: >>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/webrev.delta/index.html >>> >>> >>> I added the do { ..... } while (0) pattern to all the launcher's macro >>> defs, >>> I also addressed Alan's comments. >>> >>> I know that the native unpacker uses macros which will need this >>> pattern >>> I will fix that separately. >>> >>> Alan, do you want me to search and file bugs on other jdk components ? >>> >>> Thanks >>> Kumar >>> >>> >>> >>>> Oops. Of course, that shouldn't have the trailing semicolon >>>> >>>> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >>>> ncor_failure_return_value) \ >>>> do { \ >>>> if ((ncor_pointer_to_check) == NULL) { \ >>>> JLI_ReportErrorMessage(JNI_ERROR); \ >>>> return ncor_failure_return_value; \ >>>> } \ >>>> } while(0) >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 11:16 AM, Martin Buchholz >>> > wrote: >>>> >>>> What would Martin actually do? >>>> >>>> #define NULL_CHECK_OR_RETURN(ncor_pointer_to_check, \ >>>> ncor_failure_return_value) \ >>>> do { \ >>>> if ((ncor_pointer_to_check) == NULL) { \ >>>> JLI_ReportErrorMessage(JNI_ERROR); \ >>>> return ncor_failure_return_value; \ >>>> } \ >>>> } while(0); >>>> >>>> >>>> >>>> >>>> On Thu, May 2, 2013 at 10:45 AM, Kumar Srinivasan >>>> >>> > wrote: >>>> >>>> On 5/2/2013 10:17 AM, Martin Buchholz wrote: >>>>> This is global fix creep, but ... >>>> :( >>>> >>>> >>>>> these macros are also found in the hotspot sources. >>>>> I would rewrite all the macros in the jdk to adopt the >>>>> blessed style >>>>> do { ... } while(0) >>>>> and remove all comments in the jdk of the form >>>>> /* next token must be ; */ >>>>> If you want a macro that does nothing at all, you should >>>>> define it >>>>> do {} while (0) >>>>> instead of defining it to the empty string. >>>> I am not following, could you be more explicit on how this >>>> applies to >>>> >>>> -#define NULL_CHECK0(e) if ((e) == 0) { \ >>>> +#define NULL_CHECK_RV(e, rv) if ((e) == 0) { \ >>>> JLI_ReportErrorMessage(JNI_ERROR); \ >>>> - return 0; \ >>>> + return rv; \ >>>> } >>>> >>>> -#define NULL_CHECK(e) if ((e) == 0) { \ >>>> - JLI_ReportErrorMessage(JNI_ERROR); \ >>>> - return; \ >>>> - } >>>> +#define NULL_CHECK0(e) NULL_CHECK_RV(e, 0) >>>> >>>> +#define NULL_CHECK(e) NULL_CHECK_RV(e, ) >>>> + >>>> >>>> >>>>> >>>>> I would also be inclined to change >>>>> == 0 >>>>> to >>>>> == NULL >>>>> >>>> Yes will take care of this, as well as Alan suggestion >>>> added a >>>> check for malloc return. >>>> >>>> >>>>> This seems like another occasion to use the weird >>>>> >>>>> do { ... } while(0) >>>>> >>>>> trick to make the macro behave more like a statement. >>>>> >>>>> I might obfuscate the macro parameters to make >>>>> collisions >>>>> less likely, e.g. e => N_C_RV_e >>>>> >>>> You want me to rename the macro parameter e to N_C_RV_e ? or >>>> something else >>>> say ncrve to avoid collision ? >>>> >>>> Kumar >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Wed, May 1, 2013 at 12:33 PM, Kumar Srinivasan >>>>> >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review simple fixes for code correctness in >>>>> the launcher. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8013736/webrev.0/ >>>>> >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>> >>>> >>>> >>> > From naoto.sato at oracle.com Tue May 7 18:31:45 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 07 May 2013 18:31:45 +0000 Subject: hg: jdk8/tl/jdk: 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Message-ID: <20130507183159.253EB48896@hg.openjdk.java.net> Changeset: e30396e22c6f Author: naoto Date: 2013-05-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e30396e22c6f 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From huizhe.wang at oracle.com Tue May 7 18:41:11 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 07 May 2013 11:41:11 -0700 Subject: JEP 185: JAXP 1.5: Restrict Fetching of External Resources In-Reply-To: <518912D9.3070804@redhat.com> References: <20130430230031.1B3759E7@eggemoggin.niobe.net> <518912D9.3070804@redhat.com> Message-ID: <51894AC7.6040404@oracle.com> On 5/7/2013 7:42 AM, Florian Weimer wrote: > On 05/01/2013 01:00 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/185 > > Are other robustness improvements out of scope? Yes, JAXP MR 1.5 is focused on external references. > > The "Schema Component Constraint: Unique Particle Attribution" comes > to my mind, which is currently not enforced by OpenJDK. We currently don't have a plan to upgrade to fully support Schema 1.1. We can consider updating to the current version of Xerces which has partial support. But it will not be in MR 1.5. -Joe From brian.burkhalter at oracle.com Tue May 7 18:53:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 May 2013 11:53:39 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <5188CA59.9040100@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> Message-ID: <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> Alan, On May 7, 2013, at 2:33 AM, Alan Eliasen wrote: >> My rationale for attempting a larger review was that if these new >> changes were not examined now, then they will likely miss the JDK 8 >> train altogether. On the other hand if time were to run out on a >> large review then there would be a risk of nothing getting in. > > Yes, I understand that concern, which is why I think a staged review > makes sense. Agreed. > I've noted before that the leading researcher in Toom-Cook > multiplication, Marco Bodrato, and his colleagues reviewed my Karatsuba > and Toom-Cook patches, and called them "very clean." This review was > performed to a level of subtlety that they suggested a slighty different > proven-optimal Toom-Cook formulation that came from their research. > This allowed me to remove one shiftLeft from the routine. This should > give some confidence and reduce review concerns for Karatsuba and > Toom-Cook multiplication. Definitely. I cannot by any stretch purport to being a domain expert at that level. My role is simply to apply due diligence in shepherding these improvements through final review, testing, and integration insofar as possible. > (Believe me, I've tried to do everything I > can to simplify the review effort!) I can see that. > Since first posting these patches, I have had a large number of Java > users contact *me* and use these routines in their JDK. I know that > these improvements are in good demand and have been widely tested. I > have used these in very large computational efforts for years, and > tested them against [sic] The demand and utility are clear which is why this is at the top of the list now. >>> Step 3) would involve faster division: The Burnickel-Ziegler and >>> Barrett division routines that Tim wrote. They are complicated. >> >> Based on Tim's subsequent comment ("[?] Barrett, especially because >> it is only useful in combination with Schoenhage-Strassen"), it seems >> that Barrett division should be moved to Step 4. > > Yes, that's a good point. I agree that Barrett division should be > moved to the same timeframe as SS multiplication. If it makes it more > likely that we get an improved division routine (in Burnickel-Ziegler) > then it's more likely to give a useful combination of features in Java 1.8. That was the idea. >> If this approach were taken, probably we should file three new issues >> for Burnickel-Ziegler division, Schoenhage-Strassen multiplication, >> and Barrett division, respectively. I can take care of this if it >> sounds reasonable. > > That's fine with me. There are several bugs involved that you can > close after this: > > 4228681: Some BigInteger operations are slow with very large numbers > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228681 > > (this was closed but never fixed.) It is marked "Resolved-Fixed" even though it is not but I am not sure it is worth re-opening it and re-marking it as resolved. I think it can be linked however to the following issue with an accompanying comment. > 4837946: Implement Karatsuba multiplication algorithm in BigInteger > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 Assuming that such modification of an existing issue is acceptable, this one ought to be renamed to something like "Implement Karatsuba and Toom-Cook multiplication and squaring" with an appropriate update to the description. >> Also helpful to the process would be to have (four) staged patches >> available. I could take on this task as well, i.e., derive patches >> from the code provided thus far, but it might be safer if those more >> intimately familiar with the code helped out, especially as said >> patches might already exist somewhere. > > Okay, I can provide patches for each of these phases if you'd like. That would be very helpful and appreciated. Please see the summary at the end. > The patch for the first phase you're looking at (below) would be a good > place to start. As caught by Tim and myself, that patch is not really equivalent to the Phase 1 patch. > Do you want these as actual patches? Or just the whole file that you > can drop into place? If you prefer patches, what format would you like > them in? Whole files are preferable; I can generate the diffs myself. >> If I am not mistaken, the >> patch for Step 1 less the pow() improvements is this one: >> https://gist.github.com/tbuktu/1576025. For the time being I will >> start to look at this patch. > > That seems like a good place to start. It doesn't include the pow() > fixes, though. And as noted elsewhere does include Burnickel-Ziegler so it is not apropos for Phase 1. >>> My latest best version of all of these routines is located at: >>> >>> http://futureboy.us/temp/BigInteger.java >> >> This is equivalent to the most recent version of TIm's repository >> >> https://github.com/tbuktu/bigint >> >> plus your changes for pow() and toString()? > > Yes, Tim merged my toString changes into his github repository. The > files there contain all of our known changes. Good to know. To recapitulate in one place, I think we agree on the following sequence: Phase 1: Faster multiplication and exponentiation of large integers * Karatsuba and Toom-Cook multiplication and squaring; revised pow() function. * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 (update synopsis/description) * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 Phase 2: Faster string conversion of large integers * Recursive Schoenhage toString() routines. * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 Phase 3: Faster division of large integers * Burnickel-Ziegler division routines. * Issue to be filed. Phase 4: Faster multiplication and division of very large integers * Barrett division and Schoenhage-Strassen multiplication. * Issue to be filed. Thanks again for your comments and assistance. Brian From mike.duigou at oracle.com Tue May 7 19:06:45 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 19:06:45 +0000 Subject: hg: jdk8/tl/jdk: 4802647: Throw required NPEs from removeAll()/retainAll() Message-ID: <20130507190659.5BB8D4889A@hg.openjdk.java.net> Changeset: fe4e9bc2186f Author: mduigou Date: 2013-05-07 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe4e9bc2186f 4802647: Throw required NPEs from removeAll()/retainAll() Reviewed-by: mduigou, chegar, dholmes Contributed-by: Brandon Passanisi ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! test/java/util/Collection/MOAT.java From martinrb at google.com Tue May 7 19:44:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 7 May 2013 12:44:23 -0700 Subject: RFR: JDK-8013736: [launcher] cleanup code for correctness In-Reply-To: <51894694.4040800@oracle.com> References: <51816E1C.6020902@oracle.com> <5182A635.7070106@oracle.com> <51883CF7.8030501@oracle.com> <51890C6E.5010801@oracle.com> <51894694.4040800@oracle.com> Message-ID: On 5/7/13, Kumar Srinivasan wrote: > On 5/7/2013 7:15 AM, Kumar Srinivasan wrote: > I think I will leave it as-is, jexec, it appears may not be needed, this > was added for > Solaris primarily, and I am not sure if this is required anymore (as > Alan pointed out earlier), > I need to research this, and likely yank out jexec.c completely. OK. Folks think they want jexec, but in practice it doesn't work as well as they would like, and people instead have more success with the prepend-executable-to-jar-file trick. argv-size checks here don't matter in practice. The dreaded system-limit-of-doom, namely the argument-list-too-big limit, will get them first. From jonathan.gibbons at oracle.com Tue May 7 21:28:36 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 May 2013 21:28:36 +0000 Subject: hg: jdk8/tl/langtools: 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar Message-ID: <20130507212839.A34B0488A1@hg.openjdk.java.net> Changeset: 43c2f7cb9c76 Author: jjg Date: 2013-05-07 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/43c2f7cb9c76 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + src/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! test/tools/javac/plugin/showtype/Test.java From mike.duigou at oracle.com Tue May 7 23:19:54 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 May 2013 23:19:54 +0000 Subject: hg: jdk8/tl/jdk: 8012664: Add tests for java.util.stream and lambda translation Message-ID: <20130507232015.C328D488B7@hg.openjdk.java.net> Changeset: 6feee75b0a8b Author: briangoetz Date: 2013-05-06 11:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6feee75b0a8b 8012664: Add tests for java.util.stream and lambda translation Reviewed-by: mduigou, briangoetz Contributed-by: Brian Goetz , Paul Sandoz , Mike Duigou , Robert Field , Jim Gish ! test/Makefile + test/java/util/concurrent/atomic/AtomicReferenceTest.java + test/java/util/stream/bootlib/TEST.properties + test/java/util/stream/bootlib/java/util/stream/CollectorOps.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java + test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/OpTestCase.java + test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java + test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java + test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/TestData.java + test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java + test/java/util/stream/boottest/TEST.properties + test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java + test/java/util/stream/boottest/java/util/stream/FlagOpTest.java + test/java/util/stream/boottest/java/util/stream/IntNodeTest.java + test/java/util/stream/boottest/java/util/stream/LongNodeTest.java + test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java + test/java/util/stream/boottest/java/util/stream/NodeTest.java + test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java + test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java + test/java/util/stream/boottest/java/util/stream/UnorderedTest.java + test/java/util/stream/test/TEST.properties + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FilterOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindAnyOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveAverageOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamParSeqTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TeeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java + test/jdk/lambda/ArrayCtorRefTest.java + test/jdk/lambda/FDTest.java + test/jdk/lambda/LambdaTranslationCompoundSamTest.java + test/jdk/lambda/LambdaTranslationInInterface.java + test/jdk/lambda/LambdaTranslationInnerConstructor.java + test/jdk/lambda/LambdaTranslationTest1.java + test/jdk/lambda/LambdaTranslationTest2.java + test/jdk/lambda/MethodReferenceTestFDCCE.java + test/jdk/lambda/MethodReferenceTestInnerDefault.java + test/jdk/lambda/MethodReferenceTestInnerInstance.java + test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java + test/jdk/lambda/MethodReferenceTestInstance.java + test/jdk/lambda/MethodReferenceTestInstanceMethod.java + test/jdk/lambda/MethodReferenceTestKinds.java + test/jdk/lambda/MethodReferenceTestNew.java + test/jdk/lambda/MethodReferenceTestNewInner.java + test/jdk/lambda/MethodReferenceTestSueCase1.java + test/jdk/lambda/MethodReferenceTestSueCase2.java + test/jdk/lambda/MethodReferenceTestSueCase4.java + test/jdk/lambda/MethodReferenceTestSuper.java + test/jdk/lambda/MethodReferenceTestSuperDefault.java + test/jdk/lambda/MethodReferenceTestTypeConversion.java + test/jdk/lambda/MethodReferenceTestVarArgs.java + test/jdk/lambda/MethodReferenceTestVarArgsExt.java + test/jdk/lambda/MethodReferenceTestVarArgsSuper.java + test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java + test/jdk/lambda/MethodReferenceTestVarArgsThis.java + test/jdk/lambda/TEST.properties + test/jdk/lambda/TestInnerCtorRef.java + test/jdk/lambda/TestPrivateCtorRef.java + test/jdk/lambda/separate/AttributeInjector.java + test/jdk/lambda/separate/ClassFile.java + test/jdk/lambda/separate/ClassFilePreprocessor.java + test/jdk/lambda/separate/ClassToInterfaceConverter.java + test/jdk/lambda/separate/Compiler.java + test/jdk/lambda/separate/DirectedClassLoader.java + test/jdk/lambda/separate/SourceModel.java + test/jdk/lambda/separate/TestHarness.java + test/jdk/lambda/shapegen/ClassCase.java + test/jdk/lambda/shapegen/Hierarchy.java + test/jdk/lambda/shapegen/HierarchyGenerator.java + test/jdk/lambda/shapegen/Rule.java + test/jdk/lambda/shapegen/RuleGroup.java + test/jdk/lambda/shapegen/TTNode.java + test/jdk/lambda/shapegen/TTParser.java + test/jdk/lambda/shapegen/TTShape.java + test/jdk/lambda/vm/DefaultMethodRegressionTests.java + test/jdk/lambda/vm/DefaultMethodsTest.java + test/jdk/lambda/vm/InterfaceAccessFlagsTest.java + test/jdk/lambda/vm/StrictfpDefault.java From brian.goetz at oracle.com Tue May 7 23:46:38 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 07 May 2013 19:46:38 -0400 Subject: Streams milestone Message-ID: <5189925E.2040401@oracle.com> With changeset: 7058:6feee75b0a8b summary: 8012664: Add tests for java.util.stream and lambda translation we now have the lion's share of the java.util.stream code and tests put back into the JDK8 repositories (16+ KLoC of new code and 15+ KLoC of new tests, with nearly 100% coverage)*. Various loose ends remain, but we're over the hump of getting the streams libraries into the JDK! Thanks to all who have put in a huge effort over these last weeks to get all these changesets prepared, staged, reviewed, and pushed. * Some may find this ratio of code to tests surprisingly lean; usually I would generally expect to see closer to 2:1 or 3:1 of test code to tested code. A few factors are in play here. A significant fraction of the new code is comment and specification. Also lambda was part of the testing success story; we used lambdas extensively in the test framework, which had the effect of giving us a lot of coverage for less code. From mark.reinhold at oracle.com Wed May 8 00:06:55 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 07 May 2013 17:06:55 -0700 Subject: Streams milestone In-Reply-To: <5189925E.2040401@oracle.com> References: <5189925E.2040401@oracle.com> Message-ID: <20130507170655.376130@eggemoggin.niobe.net> 2013/5/7 9:46 -0700, brian.goetz at oracle.com: > With > > changeset: 7058:6feee75b0a8b > summary: 8012664: Add tests for java.util.stream and lambda translation > > we now have the lion's share of the java.util.stream code and tests put > back into the JDK8 repositories (16+ KLoC of new code and 15+ KLoC of > new tests, with nearly 100% coverage)*. Various loose ends remain, but > we're over the hump of getting the streams libraries into the JDK! Excellent! Very glad to see this work getting finished up. - Mark From weijun.wang at oracle.com Wed May 8 00:26:14 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 08 May 2013 00:26:14 +0000 Subject: hg: jdk8/tl/jdk: 8012679: Let allow_weak_crypto default to false Message-ID: <20130508002627.168F2488BB@hg.openjdk.java.net> Changeset: 7d89b0dd973c Author: weijun Date: 2013-05-08 08:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d89b0dd973c 8012679: Let allow_weak_crypto default to false Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/etype/WeakCrypto.java From david.holmes at oracle.com Wed May 8 00:36:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 May 2013 10:36:09 +1000 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518914E7.80109@oracle.com> References: <518914E7.80109@oracle.com> Message-ID: <51899DF9.8060601@oracle.com> Hi Chris, Didn't Doug's changes also remove the constraint: "The algorithm requires a working space equal to the size of the original array." ? David On 8/05/2013 12:51 AM, Chris Hegarty wrote: > Doug has made some updates to the java.util.Arrays sorting code to > provide stable sorting. There have also been some changes to the > original Parallel Array Sorting ( MIN_ARRAY_SORT_GRAN is public again ). > > Right now a copy of this work is sitting in the lambda repo. This issue > proposed to integrate this work into jdk8. > > http://cr.openjdk.java.net/~chegar/8014076/ver.00/specdiff/java/util/Arrays.html > > http://cr.openjdk.java.net/~chegar/8014076/ver.00/webrev/ > > Thanks, > -Chris. From chris.hegarty at oracle.com Wed May 8 08:57:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 08 May 2013 09:57:44 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <51899DF9.8060601@oracle.com> References: <518914E7.80109@oracle.com> <51899DF9.8060601@oracle.com> Message-ID: <518A1388.9000604@oracle.com> Doug, David raises a good question here. Is this implementation detail still correct: "The algorithm requires a working space equal to the size of the original array." I did get clarifications on a number of the minor spec/implementation details, but I don't think we discuss this one. (I believe lambda's version of Arrays was not sync'ed with TL after integration of parallelSort, and before Doug did his work. Or at least there was some confusion about the latest version of this file). -Chris. On 08/05/2013 01:36, David Holmes wrote: > Hi Chris, > > Didn't Doug's changes also remove the constraint: > > "The algorithm requires a working space equal to the size of the > original array." > > ? > > David > > On 8/05/2013 12:51 AM, Chris Hegarty wrote: >> Doug has made some updates to the java.util.Arrays sorting code to >> provide stable sorting. There have also been some changes to the >> original Parallel Array Sorting ( MIN_ARRAY_SORT_GRAN is public again ). >> >> Right now a copy of this work is sitting in the lambda repo. This issue >> proposed to integrate this work into jdk8. >> >> http://cr.openjdk.java.net/~chegar/8014076/ver.00/specdiff/java/util/Arrays.html >> >> >> http://cr.openjdk.java.net/~chegar/8014076/ver.00/webrev/ >> >> Thanks, >> -Chris. From dl at cs.oswego.edu Wed May 8 10:23:17 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 08 May 2013 06:23:17 -0400 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518A1388.9000604@oracle.com> References: <518914E7.80109@oracle.com> <51899DF9.8060601@oracle.com> <518A1388.9000604@oracle.com> Message-ID: <518A2795.9000302@cs.oswego.edu> On 05/08/13 04:57, Chris Hegarty wrote: > Doug, > > David raises a good question here. Is this implementation detail still correct: > "The algorithm requires a working space equal to the size of the > original array." All sort methods require working space of at most the size of the array segment (which is the size of the array in the methods without subrange bounds). This is also true for the non-parallel sorts. (One of the changes is to DualPivotQuickSort, to use size of segment, not size of array when it allocates). The only difference is that the parallel sorts ALWAYS allocate working array space, but the non-parallel ones sometimes don't. (DualPivotQuickSort usually does not; TimSort usually allocates less than segment size.) I'm not sure of the best way to convey this across all of the sort methods, especially since the "parallel" sorts use sequential sorts when arrays sizes are smaller that the threshold. (Aside: Sorting is unlike java.util.streams about this. For sorting, we can make a decision about when inter-thread memory contention and parallelization overhead outweigh benefits. For streams, if a users says "parallel()" we must parallelize even if it causes worse throughput.) > (I believe lambda's version of Arrays was not sync'ed with TL after > integration of parallelSort, and before Doug did his work. Or at least there was > some confusion about the latest version of this file). Yes, sorry not to have realized that these were different when I put in the algorithms to support stable parallel sorts. -Doug From joel.franck at oracle.com Wed May 8 12:12:25 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 08 May 2013 12:12:25 +0000 Subject: hg: jdk8/tl/langtools: 8013485: javac can't handle annotations with a from a previous compilation unit Message-ID: <20130508121228.4FF20488D6@hg.openjdk.java.net> Changeset: 780014a234fa Author: jfranck Date: 2013-05-08 14:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/780014a234fa 8013485: javac can't handle annotations with a from a previous compilation unit Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/clinit/AnnoWithClinit1.java + test/tools/javac/annotations/clinit/AnnoWithClinitFail.java + test/tools/javac/annotations/clinit/AnnoWithClinitFail.out From thomas.schatzl at oracle.com Wed May 8 15:28:08 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 08 May 2013 17:28:08 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1367939345.2658.102.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> Message-ID: <1368026888.2658.31.camel@cirrus> Hi, please review the latest webrev for this patch that is available at http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ As mentioned, it incorporates the fix and reproducer from Peter Levart. Bugs.sun.com: http://bugs.sun.com/view_bug.do?bug_id=7038914 JIRA: https://jbs.oracle.com/bugs/browse/JDK-7038914 Testing: JPRT, with the new reproducer passing In need of reviewers and a sponsor for this patch; as mentioned earlier I will set Peter (plevart) as author for this patch, i.e. send a patchset to the sponsor for this change with that author set. Thanks, Thomas From lance.andersen at oracle.com Wed May 8 16:33:40 2013 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 8 May 2013 12:33:40 -0400 Subject: RFEs implementing JEP 170 In-Reply-To: <1367493235.19948.17.camel@localhost> References: <1367493235.19948.17.camel@localhost> Message-ID: Hi Neil, Just back from holiday and catching up (or trying to) On May 2, 2013, at 7:13 AM, Neil Richards wrote: > > Hi Lance, > I've been trying to identify the Java bug ids for the RFEs which > implement JEP 170 (which, from what I can tell, should be in OpenJDK 8 > since milestone 6 [1]). The following changesets are for JDBC 4.2 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd (8005080) http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb74c3ffba (8007520) http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e189c9099 (8010416) The last change was pushed last week before I left so at this point JDBC 4.2/ JEP 170 is complete. I will look to update the JEP now that I am back once I catch up on my backlog :-) Best Lance > > Unlike most JEPs, the entry for 170 does not seem to hold references to > these ids (only to the affected JSRs). > > Searching the mailing archives for "jep 170", "jsr 114" & "jsr 221" also > didn't offer any greater insight, though by searching for "jdbc 4.2", I > did manage to find reference to 8005080 [2] [3]. > > That conversation suggests there should be other RFEs concerned with > the remaining implementation of JEP 170, but I haven't been able to > determine which those are. > > Could you please tell me which RFEs implements this JEP? > It also would be good to update the document for JEP 170 [4] with there > references, and perhaps update its status to "Completed" if it has, > indeed, been completely delivered into openjdk 8? > > Thanks, > Neil > > [1] http://openjdk.java.net/projects/jdk8/milestones > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013569.html > [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d3da0d29d7cd > [4] http://openjdk.java.net/jeps/170 > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- 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 Wed May 8 17:03:43 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 May 2013 17:03:43 +0000 Subject: hg: jdk8/tl/jdk: 8013652: (profiles) Add javax.script to compact1 Message-ID: <20130508170355.73850488E2@hg.openjdk.java.net> Changeset: c8f47674d105 Author: alanb Date: 2013-05-08 18:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8f47674d105 8013652: (profiles) Add javax.script to compact1 Reviewed-by: mchung, dholmes ! makefiles/profile-rtjar-includes.txt From neil.richards at ngmr.net Wed May 8 17:06:36 2013 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 08 May 2013 18:06:36 +0100 Subject: RFEs implementing JEP 170 In-Reply-To: References: <1367493235.19948.17.camel@localhost> Message-ID: <1368032796.15085.3.camel@localhost> Hi Lance, Thanks for the info. Hope you had a good break, and the transition back hasn't been too extreme :) Regards, Neil On Wed, 2013-05-08 at 12:33 -0400, Lance Andersen - Oracle wrote: > Hi Neil, > > Just back from holiday and catching up (or trying to) > > > On May 2, 2013, at 7:13 AM, Neil Richards wrote: > > > > > Hi Lance, > > I've been trying to identify the Java bug ids for the RFEs which > > implement JEP 170 (which, from what I can tell, should be in OpenJDK 8 > > since milestone 6 [1]). > > The following changesets are for JDBC 4.2 > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd (8005080) > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb74c3ffba (8007520) > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e189c9099 (8010416) > > The last change was pushed last week before I left so at this point JDBC 4.2/ JEP 170 is complete. I will look to update the JEP now that I am back once I catch up on my backlog :-) > > Best > Lance > > > > Unlike most JEPs, the entry for 170 does not seem to hold references to > > these ids (only to the affected JSRs). > > > > Searching the mailing archives for "jep 170", "jsr 114" & "jsr 221" also > > didn't offer any greater insight, though by searching for "jdbc 4.2", I > > did manage to find reference to 8005080 [2] [3]. > > > > That conversation suggests there should be other RFEs concerned with > > the remaining implementation of JEP 170, but I haven't been able to > > determine which those are. > > > > Could you please tell me which RFEs implements this JEP? > > It also would be good to update the document for JEP 170 [4] with there > > references, and perhaps update its status to "Completed" if it has, > > indeed, been completely delivered into openjdk 8? > > > > Thanks, > > Neil > > > > [1] http://openjdk.java.net/projects/jdk8/milestones > > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013569.html > > [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d3da0d29d7cd > > [4] http://openjdk.java.net/jeps/170 > > > > -- > > Unless stated above: > > IBM email: neil_richards at uk.ibm.com > > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > 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 > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alexey.utkin at oracle.com Wed May 8 17:17:37 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Wed, 08 May 2013 21:17:37 +0400 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever Message-ID: <518A88B1.3060105@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-7147084 http://bugs.sun.com/view_bug.do?bug_id=7147084 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.00/ Summary: I would like to describe the bug synopsis, common Java approach to Windows handle inheritance and introduce the solution. The description covers the bugs JDK-7147084 , JDK-6921885 , JDK-6428742 . All of them have the same source. Inherited Windows handles are limited by IO and synchronization objects (read more at [1]). The handle itself is an integer key in a system hash map. The system hash map is unique for a process. The parent process could share the handles with installed [HANDLE_FLAG_INHERIT] bit (the inherit-bit for short) with child process by setting the parameter [bInheritHandles] to [TRUE] in the Win32 API [CreateProcess] call [2]. Only the [CreateProcess] call is used by Java for new process creation. The term "share the handle" means that the same integer key (handle) is valid in both system hash maps: in parent and child processes. Java does not provide the API to change the inherit-bit for any handle. More other, since at least the JDK 6, all Java-created handles have no installed inherit-bit . Handles that change the inherit-bit to 1 in the Java call are the handles of redirected Input, Output, and Error streams (IOE streams for short) for child process. That is the only way to redirect the streams. That's why we can not give up the nomination in [TRUE] the parameter [bInheritHandles] in the [CreateProcess] call. And I want to mention again that this is the only place in JDK where Java installs the inherit-bit. Java itself does not use handle inheritance. Below are the facts that are essential for further discussion, but not mentioned explicitly in the MS documentation: - the only way to redirect the IOE streams of child process is to make they inherited in parent process and nominate in [TRUE] the parameter [bInheritHandles] in the [CreateProcess] call; - handles of IOE streams in the child process have the same value and conserve the inherit-bit in 1; - nomination of the inherit-bit bit to 0 in parent process does not drop the the inherit-bit in child process. As a result the grandchild process inherits the child process IOE handles; - Java does not provide the API to change the inherit-bit, Java child process cannot drop the inherit-bit; child process can not suggest, should it drop the inherit-bit for IOE handles or not; - each inheritance increase the handle reference counter; - synchronous read/write operations for pipes cannot finish until another-end handle will not finally closed in all processes. As a result of facts below we got two problems: - if IOE handles made "inherit" in parent process, they conserve the inherit-bit in 1 at least in time of the [CreateProcess] call (in case we like to return the bit in previous value, that is not true for current implementation). That is rather long time. If the parallel thread will be fast enough, it will have time to make a competitive challenge to the [ProcessImpl.create] function and the competitive child process will inherit not belong to him handles. That is the subject of JDK-6921885 bug. - the fact that in the child process handles of IOE streams have the same value and conserve the inherit-bit in 1 leads to "greeady grandchild" problem. That is a subject of JDK-7147084 . The common root of problems described in MS knowlage DB [3]. Suggested fix based on following facts: - Java does not need the installed inherit-bit, except when starting a child process and only for the IOE handles - (consequence of the first) In the child process IOE handles are the only that could get installed inherit-bit due to Java activity. Java is not interested in inheritance of IOE handle to grandchild process by default, but only as explicit IOE handle for grandchild. - in accordance with MS kb315939 the synchronized [ProcessImpl.create] call is mandatory for JDK-6921885 fix. - any IOE standard handle should have the same value of inherit-bit before and after the [ProcessImpl.create] call to minimize the fix impact handle propagation in child processes. References: 1. Handle Inheritance: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724466%28v=vs.85%29.aspx 2. CreateProcess function: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx 3. kb315939: http://support.microsoft.com/kb/315939 Regards, -uta From aleksey.shipilev at oracle.com Wed May 8 17:29:54 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 08 May 2013 21:29:54 +0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended Message-ID: <518A8B92.8010509@oracle.com> Hi, This is from our backlog after JDK-8005926. After ThreadLocalRandom state was merged into Thread, we now have to deal with the false sharing induced by heavily-updated fields in Thread. TLR was padded before, and it should make sense to make Thread bear @Contended annotation to isolate its fields in the same manner. The webrev is here: http://cr.openjdk.java.net/~shade/8014233/webrev.00/ Testing: - microbenchmarks (see below) - JPRT cycle against jdk8-tl The extended rationale for the change follows. If we look at the current Thread layout, we can see the TLR state is buried within the Thread instance. TLR state are by far the mostly updated fields in Thread now: > Running 64-bit HotSpot VM. > Using compressed references with 3-bit shift. > Objects are 8 bytes aligned. > > java.lang.Thread > offset size type description > 0 12 (assumed to be the object header + first field alignment) > 12 4 int Thread.priority > 16 8 long Thread.eetop > 24 8 long Thread.stackSize > 32 8 long Thread.nativeParkEventPointer > 40 8 long Thread.tid > 48 8 long Thread.threadLocalRandomSeed > 56 4 int Thread.threadStatus > 60 4 int Thread.threadLocalRandomProbe > 64 4 int Thread.threadLocalRandomSecondarySeed > 68 1 boolean Thread.single_step > 69 1 boolean Thread.daemon > 70 1 boolean Thread.stillborn > 71 1 (alignment/padding gap) > 72 4 char[] Thread.name > 76 4 Thread Thread.threadQ > 80 4 Runnable Thread.target > 84 4 ThreadGroup Thread.group > 88 4 ClassLoader Thread.contextClassLoader > 92 4 AccessControlContext Thread.inheritedAccessControlContext > 96 4 ThreadLocalMap Thread.threadLocals > 100 4 ThreadLocalMap Thread.inheritableThreadLocals > 104 4 Object Thread.parkBlocker > 108 4 Interruptible Thread.blocker > 112 4 Object Thread.blockerLock > 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler > 120 (object boundary, size estimate) > VM reports 120 bytes per instance Assuming current x86 hardware with 64-byte cache line sizes and current class layout, we can see the trailing fields in Thread are providing enough insulation from the false sharing with an adjacent object. Also, the Thread itself is large enough so that two TLRs belonging to different threads will not collide. However the leading fields are not enough: we have a few words which can occupy the same cache line, but belong to another object. This is where things can get worse in two ways: a) the TLR update can make the field access in adjacent object considerably slower; and much worse b) the update in the adjacent field can disturb the TLR state, which is critical for j.u.concurrent performance relying heavily on fast TLR. To illustrate both points, there is a simple benchmark driven by JMH (http://openjdk.java.net/projects/code-tools/jmh/): http://cr.openjdk.java.net/~shade/8014233/threadbench.zip On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and Thread with/without @Contended that microbenchmark yields the following results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: Accessing ThreadLocalRandom.current().nextInt(): baseline: 932 +- 4 ops/usec @Contended: 927 +- 10 ops/usec Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): baseline: 454 +- 2 ops/usec @Contended: 490 +- 3 ops/usec One might note the $uncaughtExceptionHandler is the trailing field in the Thread, so it can naturally be false-shared with the adjacent thread's TLR. We had chosen this as the illustration, in real examples with multitude objects on the heap, we can get another contender. So that is ~10% performance hit on false sharing even on very small machine. Translating it back: having heavily-updated field in the object adjacent to Thread can bring these overheads to TLR, and then jeopardize j.u.c performance. Of course, as soon as status quo about field layout is changed, we might start to lose spectacularly. I would recommend we deal with this now, so less surprises come in the future. The caveat is that we are wasting some of the space per Thread instance. After the patch, we layout is: > java.lang.Thread > offset size type description > 0 12 (assumed to be the object header + first field alignment) > 12 128 (alignment/padding gap) > 140 4 int Thread.priority > 144 8 long Thread.eetop > 152 8 long Thread.stackSize > 160 8 long Thread.nativeParkEventPointer > 168 8 long Thread.tid > 176 8 long Thread.threadLocalRandomSeed > 184 4 int Thread.threadStatus > 188 4 int Thread.threadLocalRandomProbe > 192 4 int Thread.threadLocalRandomSecondarySeed > 196 1 boolean Thread.single_step > 197 1 boolean Thread.daemon > 198 1 boolean Thread.stillborn > 199 1 (alignment/padding gap) > 200 4 char[] Thread.name > 204 4 Thread Thread.threadQ > 208 4 Runnable Thread.target > 212 4 ThreadGroup Thread.group > 216 4 ClassLoader Thread.contextClassLoader > 220 4 AccessControlContext Thread.inheritedAccessControlContext > 224 4 ThreadLocalMap Thread.threadLocals > 228 4 ThreadLocalMap Thread.inheritableThreadLocals > 232 4 Object Thread.parkBlocker > 236 4 Interruptible Thread.blocker > 240 4 Object Thread.blockerLock > 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler > 248 (object boundary, size estimate) > VM reports 376 bytes per instance ...and we have additional 256 bytes per Thread (twice the -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the space wasted in native memory for each thread, especially stack areas. Thanks, Aleksey. From martinrb at google.com Wed May 8 18:20:48 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 May 2013 11:20:48 -0700 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever In-Reply-To: <518A88B1.3060105@oracle.com> References: <518A88B1.3060105@oracle.com> Message-ID: Alexey, Thanks for working on the scary windows process stuff. I only have time for superficial review. It looks like you know what you're doing. + String[] cmdArray = { + "java", + "-cp", This looks like it's invoking whatever "java" is on the path. But there's no guarantee there is such a java, or that it's the right one. Consider invoking the java we're in, as in other jtreg tests like IIRC ProcessBuilder/Basic.java From Alan.Bateman at oracle.com Wed May 8 18:58:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 May 2013 19:58:50 +0100 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <51855C10.3050203@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> Message-ID: <518AA06A.3080605@oracle.com> On 04/05/2013 20:05, Xueming Shen wrote: > : > > Another sync need is for the "init()", in which it may update the > aliasMap, > classMap and aliasNameMap via charset() and deleteCharset() if those > special properties are defined. There are two sources for the charset()/ > deleteCharset(), one is from the constructor, one is from the init(), > given > ExtendedCharsets is now singleton and get initialized at class init, > these > should be no race concern between these two sources, so no need to > have any sync block inside charset() and deleteCharset(), the only thing > need to defend is inside init(), and all three public methods invoke the > init() at the beginning of the method body. > One question on this. What would be the downside be doing all the initialization in ExtendedCharsets's constructor instead of two phases? Aside from availableCharsets then I would expect that all other usages would require the mappings to be setup. -Alan. From xueming.shen at oracle.com Wed May 8 19:15:14 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 08 May 2013 12:15:14 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <518AA06A.3080605@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AA06A.3080605@oracle.com> Message-ID: <518AA442.5040603@oracle.com> On 05/08/2013 11:58 AM, Alan Bateman wrote: > On 04/05/2013 20:05, Xueming Shen wrote: >> : >> >> Another sync need is for the "init()", in which it may update the aliasMap, >> classMap and aliasNameMap via charset() and deleteCharset() if those >> special properties are defined. There are two sources for the charset()/ >> deleteCharset(), one is from the constructor, one is from the init(), given >> ExtendedCharsets is now singleton and get initialized at class init, these >> should be no race concern between these two sources, so no need to >> have any sync block inside charset() and deleteCharset(), the only thing >> need to defend is inside init(), and all three public methods invoke the >> init() at the beginning of the method body. >> > One question on this. What would be the downside be doing all the initialization in ExtendedCharsets's constructor instead of two phases? Aside from availableCharsets then I would expect that all other usages would require the mappings to be setup. > > -Alan. > ExtendedCharsets might be loaded/looked up for the default charset during vm-boot, in which the system properties might not have been initialized yet. So the "init()" need to be invoked again later, after boot, after we have those system properties initialized (if specified). -Sherman From mandy.chung at oracle.com Wed May 8 19:49:59 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 May 2013 12:49:59 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <51855C10.3050203@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> Message-ID: <518AAC67.9080503@oracle.com> Hi Sherman, I reviewed webrev and also checked out webrev.newECP. While it's good to simplify the synchronization needed in ExtendedCharsets, maybe better to separpate the ExtendedCharsets change from the fix for 8012326 that would require a more detailed review (I can do that next). Charset.java ExtendedCharsets provider only needs to be instantiated once. The ECP initialization can be simplified by using the initialization-on-demand holder idiom to replace the existing initialization logic using the extendedProviderLock and extendedProviderProbed. You could also simply have a holder class to define the lookupExtendedCharset (probably better to rename it to "charsetForName") and charsets() methods to return one or all available charsets from the extended provider respectively. I think that would be cleaner and easy to read. MSISO2022JP.java and ISO2022_JP_2.java Similiarly, it'd be cleaner to use a holder class to initialize the DEC02XX and ENC02XX variable. Mandy On 5/4/2013 12:05 PM, Xueming Shen wrote: > Thanks Ulf! > > There is another version with a new ExtendedCharsets.java at > > http://cr.openjdk.java.net/~sherman/8012326/webrev.newECP/ > > I merged the stuff in AbstractCharsetProvider into ExtendedCharsets.java. > The standardcharset provider now uses the FastCharsetProvider, so there > is no need to have an abstract class anymore, as long as we are not going > to add a new or separate the charsets.jar. I kinda remember there was > a plan to further divide the charsets.jar in the past though... > > I took the chance to "clean up" the synchronization mechanism in > ExtendedCharsets. It appears there are two sync needs here. > > One is to protect the "cache" inside lookup(), which triggers the race > condition if the lookup() gets invoked by multiple threads and the > "cahce" map gets accessed/updated at the same time, this is reported > and fixed by 4685305 [1], the original fix is to put the sync block in > AbstractCharsetProvider.charsetForName(). We put in another sync > block in iterator.next() for 6898310 [2], which is the trigger of this > bug. > In the new version, I "consolidated" them together into lookup() > > Another sync need is for the "init()", in which it may update the > aliasMap, > classMap and aliasNameMap via charset() and deleteCharset() if those > special properties are defined. There are two sources for the charset()/ > deleteCharset(), one is from the constructor, one is from the init(), > given > ExtendedCharsets is now singleton and get initialized at class init, > these > should be no race concern between these two sources, so no need to > have any sync block inside charset() and deleteCharset(), the only thing > need to defend is inside init(), and all three public methods invoke the > init() at the beginning of the method body. > > It appears I will still have to keep the same logic in Charset to access > the ExtendedCharset, as it is need to be "probed", just in case it is not > "installed"... > > Yes, there is also room to improve in FastCharsetProvider...I know I > need pick some time on it. > > -Sherman > > On 5/4/13 10:09 AM, Ulf Zibis wrote: >> Hi Sherman, >> >> looks good to me. >> >> Maybe you like to compare with webrevs from: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100092 >> https://bugs.openjdk.java.net/show_bug.cgi?id=100095 >> >> -Ulf >> >> Am 03.05.2013 06:29, schrieb Xueming Shen: >>> Hi, >>> >>> Please help review the proposed fix for 8012326. >>> >>> The direct trigger is the fix we put in #6898310 [1], in which we >>> added the >>> synchronization to prevent a possible race condition as described in >>> $4685305. >>> >>> However it appears the added synchronization triggers another race >>> condition as >>> showed in this stack trace [4] when run the test case [2][3]. >>> >>> The root cause here is >>> >>> (1) The ExtendedCharsetProvider is intended to be used as a >>> singleton (as the >>> probeExtendedProvider + lookupExtendedCharset mechanism in >>> Charset.java), >>> however this is only true for the >>> Charset.forName()->lookup()...scenario. Multiple >>> instances of ExtendedCharsetProvider is being created in >>> Charset.availableCharset() >>> every time it is invoked, via providers()/ServiceLoader.load(). >>> >>> (2) ISO2022_JP_2 and MSISO2022JP are provided via >>> ExtendedCharsetProvider, >>> however both of them have two static variable >>> DEC02{12|08}/ENC02{12|08} that >>> need to be initialized during the "class initialization", which will >>> indirectly trigger >>> the invocation of ExtendedCharsetProvider.alisesFor(...) >>> >>> (3) static method ExtendedCharsets.aliaseFor() has a hacky >>> implementation that >>> goes to AbstractCharsetProvider.alise() for lookup, which needs to >>> obtain a lock >>> on its ExtendedCharesetProvider.instance. This will potential cause >>> race condition >>> if the "instance" it tries to synchronize on is not its "own" >>> instance. This is possible >>> because the constructor of ExtendedCharsetProvider overwrites static >>> "instance" >>> variable with "this". >>> >>> Unfortunately as demonstrated in [4], this appears to be what is >>> happening. >>> The Thread-1/#9 is trying to synchronize on someone else's >>> ExtendedCharsetProvider >>> instance <0xa4824730> (its own instance should be <0xa4835328>, >>> which it >>> holds the monitor in the iterator.next()), it is blocked because >>> Thread-0 already holds >>> the monitor of <0xa4824730> (in its iteratior.next()), but Thread-0 >>> is blocked at >>> Class.forName0(), which I think is because Thread-1 is inside it >>> already...two theads >>> are deadlocked. >>> >>> A "quick fix/solution" is to remove the direct trigger in >>> ISO2022_JP_2 and >>> MSISO2022JP to lazily-initialize those static variables as showed in >>> the >>> webrev. However while this probably will solve the race condition, >>> the multiple >>> instances of ExtendedCharsetProvider is really not desired. And >>> given the >>> fact we have already hardwired ExtendedCharsetProvider (as well as the >>> StandardCharset, for performance reason) for charset >>> lookup/forName(), the >>> availableCharsets() should also utilize the "singleton" >>> ExtendedCharsetProvider >>> instanc (extendedCharsetProvider) as well, instead of going to the >>> ServiceLoader >>> every time for a new instance. The suggested change is to use Charset. >>> extendedCharsetProvide via probeExtendedProvider() for extended charset >>> iteration (availableCharset()). Meanwhile, since the >>> ExtendedCharsetProvider/ >>> charsets.jar should always be in the boot classpath (if installed, >>> and we are >>> looking up via >>> Class.forName("sun.nio.cs.ext.ExtededCharsetProvider")), there >>> is really no need for it to be looked up/loaded via the spi >>> mechanism (in >>> fact it's redundant to load it again after we have lookup/iterate the >>> hardwired "extendedCharsetProvider". So I removed the spi >>> description from >>> the charsts.jar as well. >>> >>> An alternative is to really implement the singleton pattern in ECP, >>> however >>> given the existing mechanism we have in Charset.java and the "hacky" >>> init() >>> implementation we need in ECP, I go with the current approach. >>> >>> http://cr.openjdk.java.net/~sherman/8012326/webrev >>> >>> Thanks, >>> Sherman >>> >>> [1] http://cr.openjdk.java.net/~sherman/6898310/webrev/ >>> [2] http://cr.openjdk.java.net/~sherman/8012326/runtest.bat >>> [3] http://cr.openjdk.java.net/~sherman/8012326/Test.java >>> [4] http://cr.openjdk.java.net/~sherman/8012326/stacktrace >>> >> > From joe.darcy at oracle.com Wed May 8 20:20:49 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 May 2013 13:20:49 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() Message-ID: <518AB3A1.7010301@oracle.com> Hello, Please review my changes to address JDK-8014249 Add Modifer.parameterModifiers() Diff below. The motivation is that since we now have a reflective model of parameters (JDK-8004729), the java.lang.reflect.Modifier class should provide a parameterModifiers method similar to other "fooModifers" methods already in the class (JDK-6261502). Thanks, -Joe diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 12:32:49 2013 -0700 +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 13:16:22 2013 -0700 @@ -351,7 +351,7 @@ } /** - * See JLSv3 section 8.1.1. + * See JLS section 8.1.1. */ private static final int CLASS_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -359,7 +359,7 @@ Modifier.STRICT; /** - * See JLSv3 section 9.1.1. + * See JLS section 9.1.1. */ private static final int INTERFACE_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -367,13 +367,13 @@ /** - * See JLSv3 section 8.8.3. + * See JLS section 8.8.3. */ private static final int CONSTRUCTOR_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE; /** - * See JLSv3 section 8.4.3. + * See JLS section 8.4.3. */ private static final int METHOD_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -381,7 +381,7 @@ Modifier.SYNCHRONIZED | Modifier.NATIVE | Modifier.STRICT; /** - * See JLSv3 section 8.3.1. + * See JLS section 8.3.1. */ private static final int FIELD_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -389,6 +389,12 @@ Modifier.VOLATILE; /** + * See JLS section 8.4.1. + */ + private static final int PARAMETER_MODIFIERS = + Modifier.FINAL; + + /** * */ static final int ACCESS_MODIFIERS = @@ -446,6 +452,18 @@ return METHOD_MODIFIERS; } + /** + * Return an {@code int} value OR-ing together the source language + * modifiers that can be applied to a parameter. + * @return an {@code int} value OR-ing together the source language + * modifiers that can be applied to a parameter. + * + * @jls 8.4.1 Formal Parameters + * @since 1.8 + */ + public static int parameterModifiers() { + return PARAMETER_MODIFIERS; + } /** * Return an {@code int} value OR-ing together the source language From mike.duigou at oracle.com Wed May 8 20:46:09 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 13:46:09 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: <518AB3A1.7010301@oracle.com> References: <518AB3A1.7010301@oracle.com> Message-ID: The substance of the change looks good to me. Why are "JLS section 8.1.1" comments used in some places and @jls tags (which I prefer since they are links) in other places? Mike On May 8 2013, at 13:20 , Joe Darcy wrote: > Hello, > > Please review my changes to address > > JDK-8014249 Add Modifer.parameterModifiers() > > Diff below. > > The motivation is that since we now have a reflective model of parameters (JDK-8004729), the java.lang.reflect.Modifier class should provide a parameterModifiers method similar to other "fooModifers" methods already in the class (JDK-6261502). > > Thanks, > > -Joe > > diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java > --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 12:32:49 2013 -0700 > +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 13:16:22 2013 -0700 > @@ -351,7 +351,7 @@ > } > > /** > - * See JLSv3 section 8.1.1. > + * See JLS section 8.1.1. > */ > private static final int CLASS_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | > @@ -359,7 +359,7 @@ > Modifier.STRICT; > > /** > - * See JLSv3 section 9.1.1. > + * See JLS section 9.1.1. > */ > private static final int INTERFACE_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | > @@ -367,13 +367,13 @@ > > > /** > - * See JLSv3 section 8.8.3. > + * See JLS section 8.8.3. > */ > private static final int CONSTRUCTOR_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE; > > /** > - * See JLSv3 section 8.4.3. > + * See JLS section 8.4.3. > */ > private static final int METHOD_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | > @@ -381,7 +381,7 @@ > Modifier.SYNCHRONIZED | Modifier.NATIVE | Modifier.STRICT; > > /** > - * See JLSv3 section 8.3.1. > + * See JLS section 8.3.1. > */ > private static final int FIELD_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | > @@ -389,6 +389,12 @@ > Modifier.VOLATILE; > > /** > + * See JLS section 8.4.1. > + */ > + private static final int PARAMETER_MODIFIERS = > + Modifier.FINAL; > + > + /** > * > */ > static final int ACCESS_MODIFIERS = > @@ -446,6 +452,18 @@ > return METHOD_MODIFIERS; > } > > + /** > + * Return an {@code int} value OR-ing together the source language > + * modifiers that can be applied to a parameter. > + * @return an {@code int} value OR-ing together the source language > + * modifiers that can be applied to a parameter. > + * > + * @jls 8.4.1 Formal Parameters > + * @since 1.8 > + */ > + public static int parameterModifiers() { > + return PARAMETER_MODIFIERS; > + } > > /** > * Return an {@code int} value OR-ing together the source language > From mike.duigou at oracle.com Wed May 8 20:56:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 13:56:23 -0700 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <51893635.4070300@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> Message-ID: On May 7 2013, at 10:13 , Chris Hegarty wrote: > On 05/07/2013 05:04 PM, Mike Duigou wrote: >> The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? > > No problem. That would read... > > "When the sub-array length reaches a {@linlplain #MIN_ARRAY_SORT_GRAN > minimum granularity}, the sub-array is sorted using the appropriate > Arrays.sort method." linlplain -> linkplain > > I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. > > I really don't care much for MIN_ARRAY_SORT_GRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. One other issue with MIN_ARRAY_SORT_GRAN is that, according to separate compilation rules, as a static final int the value of MIN_ARRAY_SORT_GRAN can/will be compiled into code. The value isn't thereafter changeable except by recompiling everything which references it. In particular, injecting a different value into Arrays.MIN_ARRAY_SORT_GRAN would likely have no effect at runtime. This situation seems a little strange/unhelpful to me. It wouldn't even be practically changeable between releases since code compiled with Java 8 would keep using that value even when running on future versions with a different value for MIN_ARRAY_SORT_GRAN. Mike From joe.darcy at oracle.com Wed May 8 21:13:52 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 May 2013 14:13:52 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: References: <518AB3A1.7010301@oracle.com> Message-ID: <518AC010.90300@oracle.com> Hi Mike, The public methods use the @jls tags while the private fields use the comments. (What probably happened was that the old "JLSv3" comments were missed in the comments -> tags pass.) I could swap out the comments for tags if you think that would be useful. Thanks, -Joe On 05/08/2013 01:46 PM, Mike Duigou wrote: > The substance of the change looks good to me. > > Why are "JLS section 8.1.1" comments used in some places and @jls tags (which I prefer since they are links) in other places? > > Mike > > On May 8 2013, at 13:20 , Joe Darcy wrote: > >> Hello, >> >> Please review my changes to address >> >> JDK-8014249 Add Modifer.parameterModifiers() >> >> Diff below. >> >> The motivation is that since we now have a reflective model of parameters (JDK-8004729), the java.lang.reflect.Modifier class should provide a parameterModifiers method similar to other "fooModifers" methods already in the class (JDK-6261502). >> >> Thanks, >> >> -Joe >> >> diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java >> --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 12:32:49 2013 -0700 >> +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 13:16:22 2013 -0700 >> @@ -351,7 +351,7 @@ >> } >> >> /** >> - * See JLSv3 section 8.1.1. >> + * See JLS section 8.1.1. >> */ >> private static final int CLASS_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | >> @@ -359,7 +359,7 @@ >> Modifier.STRICT; >> >> /** >> - * See JLSv3 section 9.1.1. >> + * See JLS section 9.1.1. >> */ >> private static final int INTERFACE_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | >> @@ -367,13 +367,13 @@ >> >> >> /** >> - * See JLSv3 section 8.8.3. >> + * See JLS section 8.8.3. >> */ >> private static final int CONSTRUCTOR_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE; >> >> /** >> - * See JLSv3 section 8.4.3. >> + * See JLS section 8.4.3. >> */ >> private static final int METHOD_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | >> @@ -381,7 +381,7 @@ >> Modifier.SYNCHRONIZED | Modifier.NATIVE | Modifier.STRICT; >> >> /** >> - * See JLSv3 section 8.3.1. >> + * See JLS section 8.3.1. >> */ >> private static final int FIELD_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | >> @@ -389,6 +389,12 @@ >> Modifier.VOLATILE; >> >> /** >> + * See JLS section 8.4.1. >> + */ >> + private static final int PARAMETER_MODIFIERS = >> + Modifier.FINAL; >> + >> + /** >> * >> */ >> static final int ACCESS_MODIFIERS = >> @@ -446,6 +452,18 @@ >> return METHOD_MODIFIERS; >> } >> >> + /** >> + * Return an {@code int} value OR-ing together the source language >> + * modifiers that can be applied to a parameter. >> + * @return an {@code int} value OR-ing together the source language >> + * modifiers that can be applied to a parameter. >> + * >> + * @jls 8.4.1 Formal Parameters >> + * @since 1.8 >> + */ >> + public static int parameterModifiers() { >> + return PARAMETER_MODIFIERS; >> + } >> >> /** >> * Return an {@code int} value OR-ing together the source language >> From chris.hegarty at oracle.com Wed May 8 21:26:53 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 May 2013 22:26:53 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> Message-ID: <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> On 8 May 2013, at 21:56, Mike Duigou wrote: > > On May 7 2013, at 10:13 , Chris Hegarty wrote: > >> On 05/07/2013 05:04 PM, Mike Duigou wrote: >>> The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? >> >> No problem. That would read... >> >> "When the sub-array length reaches a {@linlplain #MIN_ARRAY_SORT_GRAN >> minimum granularity}, the sub-array is sorted using the appropriate >> Arrays.sort method." > > > linlplain -> linkplain > >>> I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. >> >> I really don't care much for MIN_ARRAY_SORT_GRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. > > One other issue with MIN_ARRAY_SORT_GRAN is that, according to separate compilation rules, as a static final int the value of MIN_ARRAY_SORT_GRAN can/will be compiled into code. The value isn't thereafter changeable except by recompiling everything which references it. In particular, injecting a different value into Arrays.MIN_ARRAY_SORT_GRAN would likely have no effect at runtime. This situation seems a little strange/unhelpful to me. It wouldn't even be practically changeable between releases since code compiled with Java 8 would keep using that value even when running on future versions with a different value for MIN_ARRAY_SORT_GRAN. Good point Mike. I guess the same argument could be made for putting any value in the implementation detail. Any objection to completely removing any reference to this? -Chris > > Mike > From martinrb at google.com Wed May 8 22:05:22 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 May 2013 15:05:22 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: Alan (et al): Ping. On Wed, May 1, 2013 at 3:19 PM, Martin Buchholz wrote: > Another version of this change is ready. No longer preliminary. Tests > have been written. > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ > > This kind of change is particularly subject to feature creep, and I am > trying to restrain myself. > > I even addressed some of Ulf's suggestions. > The "Msg" suffix is gone. > I reverted changes to AbstractStringBuilder.replace. > I kept the naming convention for getChars parameter names. > Parameter names and exception details continue to be maddeningly > unsystematic, but they should be a little better than before. > From xueming.shen at oracle.com Wed May 8 22:20:35 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 08 May 2013 15:20:35 -0700 Subject: RFR JDK-8013386: (tz) Support tzdata2013c Message-ID: <518ACFB3.5030000@oracle.com> Hi, Please help review the proposed change to update the tz data in JDK8 from 2012i to 2013c. Other than the tzdb data file update under make/sun/javazic/tzdata, corresponding updates have also been made in TimeZoneNames***.java for the newly added zones, Asia/Khandyga and Ust-Nera, and updated zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya) test/java/util/TimeZone/tools/share/Make has been run to generate the new test data at TimeZoneData. # I have to update the displaynames.txt "manually" to undo the change for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c) back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the definition in TimeZoneNames.java (which has FKT as the standard name and FKST as the summer name) does not match the tz data file (which suggests that Stanley has moved to use only summer zone), but since this appears to be an existing issue that not related to this update, I keep the test data for Stanley untouched. Tests list below have been run and passed. java/util/TimeZone java/util/Calendar java/util/Formatter java/time closed/java/util/TimeZone closed/java/util/Calendar webrev: http://cr.openjdk.java.net/~sherman/8013386/webrev/ http://cr.openjdk.java.net/~sherman/8013386/test.closed/ Thanks! Sherman From mandy.chung at oracle.com Wed May 8 22:26:17 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 May 2013 15:26:17 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: <518AC010.90300@oracle.com> References: <518AB3A1.7010301@oracle.com> <518AC010.90300@oracle.com> Message-ID: <518AD109.8060803@oracle.com> The change looks good to me. I also think it's a good idea to swap out the comment for @jls tag for consistency. Mandy On 5/8/2013 2:13 PM, Joe Darcy wrote: > Hi Mike, > > The public methods use the @jls tags while the private fields use the > comments. (What probably happened was that the old "JLSv3" comments > were missed in the comments -> tags pass.) > > I could swap out the comments for tags if you think that would be useful. > > Thanks, > > -Joe > > On 05/08/2013 01:46 PM, Mike Duigou wrote: >> The substance of the change looks good to me. >> >> Why are "JLS section 8.1.1" comments used in some places and @jls >> tags (which I prefer since they are links) in other places? >> >> Mike >> >> On May 8 2013, at 13:20 , Joe Darcy wrote: >> >>> Hello, >>> >>> Please review my changes to address >>> >>> JDK-8014249 Add Modifer.parameterModifiers() >>> >>> Diff below. >>> >>> The motivation is that since we now have a reflective model of >>> parameters (JDK-8004729), the java.lang.reflect.Modifier class >>> should provide a parameterModifiers method similar to other >>> "fooModifers" methods already in the class (JDK-6261502). >>> >>> Thanks, >>> >>> -Joe >>> >>> diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java >>> --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr >>> 30 12:32:49 2013 -0700 >>> +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May >>> 08 13:16:22 2013 -0700 >>> @@ -351,7 +351,7 @@ >>> } >>> >>> /** >>> - * See JLSv3 section 8.1.1. >>> + * See JLS section 8.1.1. >>> */ >>> private static final int CLASS_MODIFIERS = >>> Modifier.PUBLIC | Modifier.PROTECTED | >>> Modifier.PRIVATE | >>> @@ -359,7 +359,7 @@ >>> Modifier.STRICT; >>> >>> /** >>> - * See JLSv3 section 9.1.1. >>> + * See JLS section 9.1.1. >>> */ >>> private static final int INTERFACE_MODIFIERS = >>> Modifier.PUBLIC | Modifier.PROTECTED | >>> Modifier.PRIVATE | >>> @@ -367,13 +367,13 @@ >>> >>> >>> /** >>> - * See JLSv3 section 8.8.3. >>> + * See JLS section 8.8.3. >>> */ >>> private static final int CONSTRUCTOR_MODIFIERS = >>> Modifier.PUBLIC | Modifier.PROTECTED | >>> Modifier.PRIVATE; >>> >>> /** >>> - * See JLSv3 section 8.4.3. >>> + * See JLS section 8.4.3. >>> */ >>> private static final int METHOD_MODIFIERS = >>> Modifier.PUBLIC | Modifier.PROTECTED | >>> Modifier.PRIVATE | >>> @@ -381,7 +381,7 @@ >>> Modifier.SYNCHRONIZED | Modifier.NATIVE | >>> Modifier.STRICT; >>> >>> /** >>> - * See JLSv3 section 8.3.1. >>> + * See JLS section 8.3.1. >>> */ >>> private static final int FIELD_MODIFIERS = >>> Modifier.PUBLIC | Modifier.PROTECTED | >>> Modifier.PRIVATE | >>> @@ -389,6 +389,12 @@ >>> Modifier.VOLATILE; >>> >>> /** >>> + * See JLS section 8.4.1. >>> + */ >>> + private static final int PARAMETER_MODIFIERS = >>> + Modifier.FINAL; >>> + >>> + /** >>> * >>> */ >>> static final int ACCESS_MODIFIERS = >>> @@ -446,6 +452,18 @@ >>> return METHOD_MODIFIERS; >>> } >>> >>> + /** >>> + * Return an {@code int} value OR-ing together the source language >>> + * modifiers that can be applied to a parameter. >>> + * @return an {@code int} value OR-ing together the source >>> language >>> + * modifiers that can be applied to a parameter. >>> + * >>> + * @jls 8.4.1 Formal Parameters >>> + * @since 1.8 >>> + */ >>> + public static int parameterModifiers() { >>> + return PARAMETER_MODIFIERS; >>> + } >>> >>> /** >>> * Return an {@code int} value OR-ing together the source language >>> > From forax at univ-mlv.fr Wed May 8 22:52:11 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 09 May 2013 00:52:11 +0200 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: <518AB3A1.7010301@oracle.com> References: <518AB3A1.7010301@oracle.com> Message-ID: <518AD71B.8030908@univ-mlv.fr> Hi Joe, does the spec has changed recently, or you should also add SYNTHETIZED to parameter modifiers ? R?mi On 05/08/2013 10:20 PM, Joe Darcy wrote: > Hello, > > Please review my changes to address > > JDK-8014249 Add Modifer.parameterModifiers() > > Diff below. > > The motivation is that since we now have a reflective model of > parameters (JDK-8004729), the java.lang.reflect.Modifier class should > provide a parameterModifiers method similar to other "fooModifers" > methods already in the class (JDK-6261502). > > Thanks, > > -Joe > > diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java > --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 > 12:32:49 2013 -0700 > +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 > 13:16:22 2013 -0700 > @@ -351,7 +351,7 @@ > } > > /** > - * See JLSv3 section 8.1.1. > + * See JLS section 8.1.1. > */ > private static final int CLASS_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | > Modifier.PRIVATE | > @@ -359,7 +359,7 @@ > Modifier.STRICT; > > /** > - * See JLSv3 section 9.1.1. > + * See JLS section 9.1.1. > */ > private static final int INTERFACE_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | > Modifier.PRIVATE | > @@ -367,13 +367,13 @@ > > > /** > - * See JLSv3 section 8.8.3. > + * See JLS section 8.8.3. > */ > private static final int CONSTRUCTOR_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | > Modifier.PRIVATE; > > /** > - * See JLSv3 section 8.4.3. > + * See JLS section 8.4.3. > */ > private static final int METHOD_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | > Modifier.PRIVATE | > @@ -381,7 +381,7 @@ > Modifier.SYNCHRONIZED | Modifier.NATIVE | > Modifier.STRICT; > > /** > - * See JLSv3 section 8.3.1. > + * See JLS section 8.3.1. > */ > private static final int FIELD_MODIFIERS = > Modifier.PUBLIC | Modifier.PROTECTED | > Modifier.PRIVATE | > @@ -389,6 +389,12 @@ > Modifier.VOLATILE; > > /** > + * See JLS section 8.4.1. > + */ > + private static final int PARAMETER_MODIFIERS = > + Modifier.FINAL; > + > + /** > * > */ > static final int ACCESS_MODIFIERS = > @@ -446,6 +452,18 @@ > return METHOD_MODIFIERS; > } > > + /** > + * Return an {@code int} value OR-ing together the source language > + * modifiers that can be applied to a parameter. > + * @return an {@code int} value OR-ing together the source language > + * modifiers that can be applied to a parameter. > + * > + * @jls 8.4.1 Formal Parameters > + * @since 1.8 > + */ > + public static int parameterModifiers() { > + return PARAMETER_MODIFIERS; > + } > > /** > * Return an {@code int} value OR-ing together the source language > From mandy.chung at oracle.com Thu May 9 00:13:17 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 May 2013 17:13:17 -0700 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument Message-ID: <518AEA1D.5030402@oracle.com> Please review the simple change for: JDK-4487672 (proxy) Proxy constructor should check for null argument Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/ Thanks Mandy From mike.duigou at oracle.com Thu May 9 00:30:56 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 17:30:56 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: Hi Martin; Some notes from a non-exhaustive (ran out of time before dinner) review. Mike AbstractStringBuilder:: - The impls like insert(int dstOffset, CharSequence s) makes me slightly uneasy because the private value field escapes to an unknown class. Who knows what evil (or foolishness) could result? Direct-X-Buffer.java:: - +#if[rw] public boolean isDirect() : Why would this be conditionalized with rw? Heap-X-Buffer.java:: - protected -> private int ix(int i) : Is Alan OK with this change. I've mostly avoided these templates. :-) X-Buffer.java.template:: - toString() could use the JavaLangAccess.newUnsafeString() constructor! - I prefer your formatting of "return bigEndian ?". test/.../GetChars:: - Great to see you've already adopted using TestNG for JTReg tests! - ArraysCharSequence.hashCode() could have been Arrays.hashcode(chars) or not implemented at all. - Could use a @DataProivder for "CharSequence[] seqs = {" style tests. - There's been some informal discussion of packaging commonly used test utils as jtreg @library. This could be a good candidate. ArraysCharSequence is a candidate for testing utils lib. Basic impls that override no defaults are going to be increasingly important for testing. - I like your varargs assertsThrows. I have written a non-varargs one in test/.../Map/Defaults.java. Your varargs one of necessity violates the actual, expected, [message] pattern used by other TestNG assertions but I prefer it. This is also a candidate for utils lib. On May 1 2013, at 15:19 , Martin Buchholz wrote: > Another version of this change is ready. No longer preliminary. Tests > have been written. > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ > > This kind of change is particularly subject to feature creep, and I am > trying to restrain myself. > > I even addressed some of Ulf's suggestions. > The "Msg" suffix is gone. > I reverted changes to AbstractStringBuilder.replace. > I kept the naming convention for getChars parameter names. > Parameter names and exception details continue to be maddeningly > unsystematic, but they should be a little better than before. From Lance.Andersen at oracle.com Thu May 9 00:42:47 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Wed, 8 May 2013 20:42:47 -0400 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument In-Reply-To: <518AEA1D.5030402@oracle.com> References: <518AEA1D.5030402@oracle.com> Message-ID: Looks fine Mandy 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 Sent from my iPhone On May 8, 2013, at 8:13 PM, Mandy Chung wrote: > Please review the simple change for: > JDK-4487672 (proxy) Proxy constructor should check for null argument > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/ > > Thanks > Mandy From martinrb at google.com Thu May 9 01:31:11 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 May 2013 18:31:11 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > > Direct-X-Buffer.java:: > > - +#if[rw] public boolean isDirect() : Why would this be conditionalized > with rw? > > Welcome to the -X- files. Since you have conditional preprocessing and inheritance happening at the same time, all readonly methods should be within #if[rw] > > Heap-X-Buffer.java:: > > - protected -> private int ix(int i) : Is Alan OK with this change. I've > mostly avoided these templates. :-) > > Make things as private as you can. Possible now that subclass no longer needs to access these fields. > > X-Buffer.java.template:: > > - toString() could use the JavaLangAccess.newUnsafeString() constructor! > > Right! I've been semi-waiting for that! > - I prefer your formatting of "return bigEndian ?". > > > test/.../GetChars:: > > - Great to see you've already adopted using TestNG for JTReg tests! > > It's my first TestNG test! > - ArraysCharSequence.hashCode() could have been Arrays.hashcode(chars) or > not implemented at all. > > I removed it. More later. From xuelei.fan at oracle.com Thu May 9 02:30:31 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 May 2013 10:30:31 +0800 Subject: Code review request: 8005598 (reopened) Need to clone array of input/output parameters Message-ID: <518B0A47.2090809@oracle.com> Hi, It's a correction of previous fix of JDK-8003265: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4472a641b4dc Which introduced compiler warning and error, and backouted later. Thanks, Xuelei From xuelei.fan at oracle.com Thu May 9 02:31:32 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 May 2013 10:31:32 +0800 Subject: Code review request: 8005598 (reopened) Need to clone array of input/output parameters In-Reply-To: <518B0A47.2090809@oracle.com> References: <518B0A47.2090809@oracle.com> Message-ID: <518B0A84.2060301@oracle.com> Oops, here is the webrev: http://cr.openjdk.java.net/~xuelei/8005598/webrev.00/ Xuelei On 5/9/2013 10:30 AM, Xuelei Fan wrote: > Hi, > > It's a correction of previous fix of JDK-8003265: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4472a641b4dc > > Which introduced compiler warning and error, and backouted later. > > Thanks, > Xuelei > From weijun.wang at oracle.com Thu May 9 03:03:55 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 09 May 2013 11:03:55 +0800 Subject: Code review request: 8005598 (reopened) Need to clone array of input/output parameters In-Reply-To: <518B0A84.2060301@oracle.com> References: <518B0A47.2090809@oracle.com> <518B0A84.2060301@oracle.com> Message-ID: <518B121B.8050508@oracle.com> Good. They look fine. -Max On 5/9/13 10:31 AM, Xuelei Fan wrote: > Oops, here is the webrev: > > http://cr.openjdk.java.net/~xuelei/8005598/webrev.00/ > > Xuelei > > On 5/9/2013 10:30 AM, Xuelei Fan wrote: >> Hi, >> >> It's a correction of previous fix of JDK-8003265: >> >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4472a641b4dc >> >> Which introduced compiler warning and error, and backouted later. >> >> Thanks, >> Xuelei >> > From joe.darcy at oracle.com Thu May 9 03:18:08 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 May 2013 20:18:08 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: <518AD109.8060803@oracle.com> References: <518AB3A1.7010301@oracle.com> <518AC010.90300@oracle.com> <518AD109.8060803@oracle.com> Message-ID: <518B1570.1050606@oracle.com> On 05/08/2013 03:26 PM, Mandy Chung wrote: > The change looks good to me. I also think it's a good idea to swap > out the comment for @jls tag for consistency. Okay; you both convinced me :-) Revised patch below, including a new comment explaining the FOO_MODIFIERS fields and fooModifiers() method pattern. Thanks, -Joe diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 12:32:49 2013 -0700 +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 20:16:21 2013 -0700 @@ -350,8 +350,19 @@ return (mod & MANDATED) != 0; } + // Note on the FOO_MODIFIERS fields and fooModifiers() methods: + // the sets of modifiers are not guaranteed to be constants + // across time and Java SE releases. Therefore, it would not be + // appropriate to expose an external interface to this information + // that would allow the values to be treated as Java-level + // constants since the values could be constant folded and updates + // to the sets of modifiers missed. Thus, the fooModifiers() + // methods return an unchanging values for a given release, but a + // value that can change over time. + /** - * See JLSv3 section 8.1.1. + * The Java source modifiers that can be applied to a class. + * @jls 8.1.1 Class Modifiers */ private static final int CLASS_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -359,7 +370,8 @@ Modifier.STRICT; /** - * See JLSv3 section 9.1.1. + * The Java source modifiers that can be applied to an interface. + * @jls 9.1.1 Interface Modifiers */ private static final int INTERFACE_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -367,13 +379,15 @@ /** - * See JLSv3 section 8.8.3. + * The Java source modifiers that can be applied to a constructor. + * @jls 8.8.3 Constructor Modifiers */ private static final int CONSTRUCTOR_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE; /** - * See JLSv3 section 8.4.3. + * The Java source modifiers that can be applied to a method. + * @jls8.4.3 Method Modifiers */ private static final int METHOD_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -381,7 +395,8 @@ Modifier.SYNCHRONIZED | Modifier.NATIVE | Modifier.STRICT; /** - * See JLSv3 section 8.3.1. + * The Java source modifiers that can be applied to a field. + * @jls 8.3.1 Field Modifiers */ private static final int FIELD_MODIFIERS = Modifier.PUBLIC | Modifier.PROTECTED | Modifier.PRIVATE | @@ -389,6 +404,13 @@ Modifier.VOLATILE; /** + * The Java source modifiers that can be applied to a method or constructor parameter. + * @jls 8.4.1 Formal Parameters + */ + private static final int PARAMETER_MODIFIERS = + Modifier.FINAL; + + /** * */ static final int ACCESS_MODIFIERS = @@ -446,7 +468,6 @@ return METHOD_MODIFIERS; } - /** * Return an {@code int} value OR-ing together the source language * modifiers that can be applied to a field. @@ -459,4 +480,17 @@ public static int fieldModifiers() { return FIELD_MODIFIERS; } + + /** + * Return an {@code int} value OR-ing together the source language + * modifiers that can be applied to a parameter. + * @return an {@code int} value OR-ing together the source language + * modifiers that can be applied to a parameter. + * + * @jls 8.4.1 Formal Parameters + * @since 1.8 + */ + public static int parameterModifiers() { + return PARAMETER_MODIFIERS; + } } From joe.darcy at oracle.com Thu May 9 03:18:47 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 May 2013 20:18:47 -0700 Subject: JDK 8 code review request for JDK-8014249 Add Modifer.parameterModifiers() In-Reply-To: <518AD71B.8030908@univ-mlv.fr> References: <518AB3A1.7010301@oracle.com> <518AD71B.8030908@univ-mlv.fr> Message-ID: <518B1597.7070400@oracle.com> Hi Remi, In this context, the modifiers in question are only source-level modifiers. Thanks, -Joe On 05/08/2013 03:52 PM, Remi Forax wrote: > Hi Joe, > does the spec has changed recently, or you should also add SYNTHETIZED > to parameter modifiers ? > > R?mi > > On 05/08/2013 10:20 PM, Joe Darcy wrote: >> Hello, >> >> Please review my changes to address >> >> JDK-8014249 Add Modifer.parameterModifiers() >> >> Diff below. >> >> The motivation is that since we now have a reflective model of >> parameters (JDK-8004729), the java.lang.reflect.Modifier class should >> provide a parameterModifiers method similar to other "fooModifers" >> methods already in the class (JDK-6261502). >> >> Thanks, >> >> -Joe >> >> diff -r 2fba6ae13ed8 src/share/classes/java/lang/reflect/Modifier.java >> --- a/src/share/classes/java/lang/reflect/Modifier.java Tue Apr 30 >> 12:32:49 2013 -0700 >> +++ b/src/share/classes/java/lang/reflect/Modifier.java Wed May 08 >> 13:16:22 2013 -0700 >> @@ -351,7 +351,7 @@ >> } >> >> /** >> - * See JLSv3 section 8.1.1. >> + * See JLS section 8.1.1. >> */ >> private static final int CLASS_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | >> Modifier.PRIVATE | >> @@ -359,7 +359,7 @@ >> Modifier.STRICT; >> >> /** >> - * See JLSv3 section 9.1.1. >> + * See JLS section 9.1.1. >> */ >> private static final int INTERFACE_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | >> Modifier.PRIVATE | >> @@ -367,13 +367,13 @@ >> >> >> /** >> - * See JLSv3 section 8.8.3. >> + * See JLS section 8.8.3. >> */ >> private static final int CONSTRUCTOR_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | >> Modifier.PRIVATE; >> >> /** >> - * See JLSv3 section 8.4.3. >> + * See JLS section 8.4.3. >> */ >> private static final int METHOD_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | >> Modifier.PRIVATE | >> @@ -381,7 +381,7 @@ >> Modifier.SYNCHRONIZED | Modifier.NATIVE | >> Modifier.STRICT; >> >> /** >> - * See JLSv3 section 8.3.1. >> + * See JLS section 8.3.1. >> */ >> private static final int FIELD_MODIFIERS = >> Modifier.PUBLIC | Modifier.PROTECTED | >> Modifier.PRIVATE | >> @@ -389,6 +389,12 @@ >> Modifier.VOLATILE; >> >> /** >> + * See JLS section 8.4.1. >> + */ >> + private static final int PARAMETER_MODIFIERS = >> + Modifier.FINAL; >> + >> + /** >> * >> */ >> static final int ACCESS_MODIFIERS = >> @@ -446,6 +452,18 @@ >> return METHOD_MODIFIERS; >> } >> >> + /** >> + * Return an {@code int} value OR-ing together the source language >> + * modifiers that can be applied to a parameter. >> + * @return an {@code int} value OR-ing together the source language >> + * modifiers that can be applied to a parameter. >> + * >> + * @jls 8.4.1 Formal Parameters >> + * @since 1.8 >> + */ >> + public static int parameterModifiers() { >> + return PARAMETER_MODIFIERS; >> + } >> >> /** >> * Return an {@code int} value OR-ing together the source language >> > From mike.duigou at oracle.com Thu May 9 04:17:54 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 21:17:54 -0700 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find In-Reply-To: <5187E0AA.405@oracle.com> References: <5187E0AA.405@oracle.com> Message-ID: Looks good to me. FaultyFileSystem is I hope something we can reuse in other tests. Mike On May 6 2013, at 09:56 , Henry Jen wrote: > Hi, > > Updated based on feedback, > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/webrev/ > http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/specdiff/ > > Changed from previous request, > > 1. DirectoryStream.entries() is renamed to DirectoryStream.stream(). > 2. Clarify operating closed stream returned from Files.list as > end-of-stream, from Files.walk will throw IllegalStateException, and > added test case. > > Cheers, > Henry From mike.duigou at oracle.com Thu May 9 04:43:23 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 09 May 2013 04:43:23 +0000 Subject: hg: jdk8/tl: 8014269: Add missing .PHONY targets to Main.gmk Message-ID: <20130509044323.7ECAC4891F@hg.openjdk.java.net> Changeset: e2eb6bc06621 Author: mduigou Date: 2013-05-08 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e2eb6bc06621 8014269: Add missing .PHONY targets to Main.gmk Reviewed-by: mchung, tbell ! common/makefiles/Main.gmk From henry.jen at oracle.com Thu May 9 05:27:54 2013 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 08 May 2013 22:27:54 -0700 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find In-Reply-To: References: <5187E0AA.405@oracle.com> Message-ID: <518B33DA.4060206@oracle.com> On 05/08/2013 09:17 PM, Mike Duigou wrote: > Looks good to me. > Thanks, we have a minor update to exclude changes for DirectoryStream. http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/ A quick review on the update is really appreciated. Cheers, Henry > FaultyFileSystem is I hope something we can reuse in other tests. > > Mike > > On May 6 2013, at 09:56 , Henry Jen wrote: > >> Hi, >> >> Updated based on feedback, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/webrev/ >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/specdiff/ >> >> Changed from previous request, >> >> 1. DirectoryStream.entries() is renamed to DirectoryStream.stream(). >> 2. Clarify operating closed stream returned from Files.list as >> end-of-stream, from Files.walk will throw IllegalStateException, and >> added test case. >> >> Cheers, >> Henry > From mike.duigou at oracle.com Thu May 9 05:49:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 22:49:31 -0700 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find In-Reply-To: <518B33DA.4060206@oracle.com> References: <5187E0AA.405@oracle.com> <518B33DA.4060206@oracle.com> Message-ID: <8E8F619A-9BE8-4049-9B13-6498EFFFF7FA@oracle.com> Still looks good. :-) On May 8 2013, at 22:27 , Henry Jen wrote: > On 05/08/2013 09:17 PM, Mike Duigou wrote: >> Looks good to me. >> > > Thanks, we have a minor update to exclude changes for DirectoryStream. > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/ > > A quick review on the update is really appreciated. > > Cheers, > Henry > > >> FaultyFileSystem is I hope something we can reuse in other tests. >> >> Mike >> >> On May 6 2013, at 09:56 , Henry Jen wrote: >> >>> Hi, >>> >>> Updated based on feedback, >>> >>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/webrev/ >>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/specdiff/ >>> >>> Changed from previous request, >>> >>> 1. DirectoryStream.entries() is renamed to DirectoryStream.stream(). >>> 2. Clarify operating closed stream returned from Files.list as >>> end-of-stream, from Files.walk will throw IllegalStateException, and >>> added test case. >>> >>> Cheers, >>> Henry >> > From david.holmes at oracle.com Thu May 9 05:53:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 15:53:34 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1368026888.2658.31.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> Message-ID: <518B39DE.9020802@oracle.com> Hi Thomas, On 9/05/2013 1:28 AM, Thomas Schatzl wrote: > Hi, > > please review the latest webrev for this patch that is available at > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ > > As mentioned, it incorporates the fix and reproducer from Peter Levart. Fix is fine. I'm not sure about the test (sorry I didn't pay it attention earlier). Have you instrumented the code to verify that the test actually triggers an OOME? It may be possible that if the OOME did kill the reference thread that we wouldn't necessarily detect it using the sleeps etc. Also I don't understand the need for the actual weakRef usage and System.gc() etc. If the heap is full then the interrupt will wake the reference handler thread and the allocation will trigger the OOME. It doesn't matter if there are any references to process. The main logic might then reduce to: referenceHandlerThread.interrupt(); for (int i = 0; i < 10; i++) { if (!referenceHandlerThread.isAlive()) throw new Exception("Reference-handler thread died"); Thread.sleep(1000); } which just gives it 10s to die else assumes all ok. ? But I can live with existing test (it just might vacuously pass) Cheers, David > Bugs.sun.com: > http://bugs.sun.com/view_bug.do?bug_id=7038914 > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-7038914 > > Testing: > JPRT, with the new reproducer passing > > In need of reviewers and a sponsor for this patch; as mentioned earlier > I will set Peter (plevart) as author for this patch, i.e. send a > patchset to the sponsor for this change with that author set. > > Thanks, > Thomas > From huizhe.wang at oracle.com Thu May 9 06:38:54 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 09 May 2013 06:38:54 +0000 Subject: hg: jdk8/tl/jaxp: 8011653: Upgrade JDK8 to JAXP 1.5 Message-ID: <20130509063858.C4C2148920@hg.openjdk.java.net> Changeset: 1e8d98012ab8 Author: joehw Date: 2013-05-08 23:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1e8d98012ab8 8011653: Upgrade JDK8 to JAXP 1.5 Reviewed-by: alanb, dfuchs ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.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/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.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/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java ! src/javax/xml/validation/Validator.java From eliasen at mindspring.com Thu May 9 07:11:46 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Thu, 09 May 2013 01:11:46 -0600 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> Message-ID: <518B4C32.7010106@mindspring.com> On 05/07/2013 12:53 PM, Brian Burkhalter wrote: > To recapitulate in one place, I think we agree on the following sequence: > > Phase 1: Faster multiplication and exponentiation of large integers > * Karatsuba and Toom-Cook multiplication and squaring; revised pow() function. > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 (update synopsis/description) > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 > > Phase 2: Faster string conversion of large integers > * Recursive Schoenhage toString() routines. > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 > > Phase 3: Faster division of large integers > * Burnickel-Ziegler division routines. > * Issue to be filed. > > Phase 4: Faster multiplication and division of very large integers > * Barrett division and Schoenhage-Strassen multiplication. > * Issue to be filed. Okay, I've created a set of patches that implement these 4 phases. (They're not actually patches, but the entire source file for each phase, as Brian requested.) These are available at: http://futureboy.us/temp/BigIntegerPatch.zip In this zipfile, the file(s) to use for each phase are marked with the ".phaseX" suffix. If there is no change in a file for a given phase, there is no file included for that phase, but you should make sure that you are still using the BigDecimal and MutableBigInteger file(s) applied in the previous phases. So, to be very clear, the files that make up each phase are: Phase 1: BigInteger.java.phase1 BigDecimal.java.phase1 (since BigInteger.pow is accelerated, the workaround in BigDecimal is removed.) Phase 2: BigInteger.java.phase2 Phase 3: BigInteger.java.phase3 MutableBigInteger.java.phase3 (to use Burnikel-Ziegler divide) Phase 4: BigInteger.java.phase4 For your reference, the final versions of each file are contained with the ".final" suffix. These will be identical to previous phases applied, and you don't have to apply them, but if someone wants to quickly drop in the best improvements to their own JDK, just use the 3 files with the ".final" suffix. Let me know if you have any issues with these. Tim and Brian, you might decide amongst yourselves who wants to file the issues for phases 3 and 4. I don't know if Brian has any magical powers to make the issues skip the QA process. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From peter.levart at gmail.com Thu May 9 08:35:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 10:35:57 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B39DE.9020802@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> Message-ID: <518B5FED.1050505@gmail.com> On 05/09/2013 07:53 AM, David Holmes wrote: > Hi Thomas, > > On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >> Hi, >> >> please review the latest webrev for this patch that is available at >> >> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >> >> As mentioned, it incorporates the fix and reproducer from Peter Levart. > > Fix is fine. > > I'm not sure about the test (sorry I didn't pay it attention earlier). > Have you instrumented the code to verify that the test actually > triggers an OOME? It may be possible that if the OOME did kill the > reference thread that we wouldn't necessarily detect it using the > sleeps etc. Also I don't understand the need for the actual weakRef > usage and System.gc() etc. If the heap is full then the interrupt will > wake the reference handler thread and the allocation will trigger the > OOME. It doesn't matter if there are any references to process. The > main logic might then reduce to: > > referenceHandlerThread.interrupt(); > for (int i = 0; i < 10; i++) { > if (!referenceHandlerThread.isAlive()) > throw new Exception("Reference-handler thread died"); > Thread.sleep(1000); > } > > which just gives it 10s to die else assumes all ok. ? > > But I can live with existing test (it just might vacuously pass) > > Cheers, > David Hi David, Thomas, Yes, this was just a left-over from my bug reproducer that demonstrated the situation where WeakReference was cleared, but nothing was enqueue-d into the ReferenceQueue. Reference Handler thread otherwise just sleeps in lock.wait() most of the time if there's nothing to do and interrupting it's thread will trigger allocation of InterruptedException and consequently OOME nevertheless. One think to watch: Reference Handler thread is started in the j.l.r.Reference static initializer, so the Reference class must be initialized. I don't know if there is any guarantee that this is done before entering main(). So there should be something explicit in main() method that ensures it. Also, throwing test-fail exception should be done after releasing the heap or we'll just trigger another OOME without any message to describe the situation. Waiting in a loop for ReferenceHandler thread is not needed since the test will normally succeed and so the whole loop will execute to the end. Only when the test fails the loop will exit faster. In my experience, the thread dies between 10-20ms after interrupting, so waiting for about 500ms is enough I think. Also no System.gc() and additional waiting is needed to report the outcome - just releasing the reference to 'waste' variable is enuugh in my experience to restore the heap into working condition. Here's the updated test that does all that: public class OOMEInReferenceHandler { static Object[] fillHeap() { Object[] first = null, last = null; int size = 1 << 20; while (size > 0) { try { Object[] array = new Object[size]; if (first == null) { first = array; } else { last[0] = array; } last = array; } catch (OutOfMemoryError oome) { size = size >>> 1; } } return first; } public static void main(String[] args) throws Exception { // ensure ReferenceHandler thread is started new WeakReference(new Object()); ThreadGroup tg = Thread.currentThread().getThreadGroup(); for (ThreadGroup tgn = tg; tgn != null; tg = tgn, tgn = tg.getParent()); Thread[] threads = new Thread[tg.activeCount()]; Thread referenceHandlerThread = null; int n = tg.enumerate(threads); for (int i = 0; i < n; i++) { if("Reference Handler".equals(threads[i].getName())) { referenceHandlerThread = threads[i]; } } if (referenceHandlerThread == null) { throw new IllegalStateException("Couldn't find Reference Handler thread."); } Object waste = fillHeap(); referenceHandlerThread.interrupt(); Thread.sleep(500L); // release waste so we can allocate and throw normal exceptions waste = null; // check that the handler is still alive if (!referenceHandlerThread.isAlive()) { throw new Exception("Reference Handler thread died."); } } } Regards, Peter > >> Bugs.sun.com: >> http://bugs.sun.com/view_bug.do?bug_id=7038914 >> >> JIRA: >> https://jbs.oracle.com/bugs/browse/JDK-7038914 >> >> Testing: >> JPRT, with the new reproducer passing >> >> In need of reviewers and a sponsor for this patch; as mentioned earlier >> I will set Peter (plevart) as author for this patch, i.e. send a >> patchset to the sponsor for this change with that author set. >> >> Thanks, >> Thomas >> From peter.levart at gmail.com Thu May 9 08:56:08 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 10:56:08 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B5FED.1050505@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> Message-ID: <518B64A8.50706@gmail.com> On 05/09/2013 10:35 AM, Peter Levart wrote: > In my experience, the thread dies between 10-20ms after interrupting, > so waiting for about 500ms is enough I think. But only if the test is started with low max. heap setting. When trying with large heaps (2G+), a long GC pause can ruin Thread.sleep() enforced ordering. The test also works with heaps as low as 16m, so perhaps it should be started with -Xmx64m or even -Xmx32m... Regards, Peter From sean.coffey at oracle.com Thu May 9 09:06:13 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 09 May 2013 10:06:13 +0100 Subject: RFR JDK-8013386: (tz) Support tzdata2013c In-Reply-To: <518ACFB3.5030000@oracle.com> References: <518ACFB3.5030000@oracle.com> Message-ID: <518B6705.3050203@oracle.com> Thanks for taking care of this Sherman. I was wondering what sort of impact JSR 310 would make on tzdata updates. The Atlantic/Stanley display name issue mentioned is a regular one, we should log a bug against the test file generation scripts. I just had a quick grok of the jdk8 repo. The following files need updating also : jdk/test/sun/util/calendar/zi/tzdata/* jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 85) jdk/makefiles/GendataTimeZone.gmk (line 29) It looks like jdk/makefiles/GendataTimeZone.gmk still has a dependency on reading files from jdk/make. That'll all have to change too once the old build system is removed from jdk8. I think the new tzdata sources should be moved into a directory under makefiles rather than keeping them in make. The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in jdk/makefiles/GendataTimeZone.gmk should be removed if we know that the version string can be read from the VERSION file stored with tzdata. Above points are not necessarily related to 2013c update and should be cleaned up separately perhaps. regards, Sean. On 08/05/2013 23:20, Xueming Shen wrote: > Hi, > > Please help review the proposed change to update the tz data > in JDK8 from 2012i to 2013c. > > Other than the tzdb data file update under make/sun/javazic/tzdata, > corresponding updates have also been made in TimeZoneNames***.java > for the newly added zones, Asia/Khandyga and Ust-Nera, and updated > zone display names (from EET to CET) for Africa/Tripoli (and its alias > Libya) > > test/java/util/TimeZone/tools/share/Make has been run to generate the > new test data at TimeZoneData. > > # I have to update the displaynames.txt "manually" to undo the change > for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt > both > in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c) > back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the > definition in TimeZoneNames.java (which has FKT as the standard name and > FKST as the summer name) does not match the tz data file (which suggests > that Stanley has moved to use only summer zone), but since this appears > to be an existing issue that not related to this update, I keep the > test data for > Stanley untouched. > > Tests list below have been run and passed. > > java/util/TimeZone > java/util/Calendar > java/util/Formatter > java/time > closed/java/util/TimeZone > closed/java/util/Calendar > > webrev: > > http://cr.openjdk.java.net/~sherman/8013386/webrev/ > http://cr.openjdk.java.net/~sherman/8013386/test.closed/ > > Thanks! > Sherman From peter.levart at gmail.com Thu May 9 09:18:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 11:18:35 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B39DE.9020802@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> Message-ID: <518B69EB.8010104@gmail.com> On 05/09/2013 07:53 AM, David Holmes wrote: > Have you instrumented the code to verify that the test actually > triggers an OOME? Without the patch, the test always throws OOME in lock.wait() and kills the thread. At least in all executions I tried (100s) it did the same. The test might pass without a patch only perhaps when TLABs are used. The default is: -XX:-UseTLAB right? Perhaps it should be specified explicitly... Regards, Peter From dl at cs.oswego.edu Thu May 9 09:32:14 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 09 May 2013 05:32:14 -0400 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> Message-ID: <518B6D1E.3050804@cs.oswego.edu> On 05/08/13 17:26, Chris Hegarty wrote: > > On 8 May 2013, at 21:56, Mike Duigou wrote: > >> >> On May 7 2013, at 10:13 , Chris Hegarty wrote: >> >>> On 05/07/2013 05:04 PM, Mike Duigou wrote: >>>> The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? >>> >>> No problem. That would read... >>> >>> "When the sub-array length reaches a {@linlplain #MIN_ARRAY_SORT_GRAN >>> minimum granularity}, the sub-array is sorted using the appropriate >>> Arrays.sort method." >> >> >> linlplain -> linkplain >> >>>> I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. >>> >>> I really don't care much for MIN_ARRAY_SORT_GRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. >> >> One other issue with MIN_ARRAY_SORT_GRAN is that, according to separate compilation rules, as a static final int the value of MIN_ARRAY_SORT_GRAN can/will be compiled into code. The value isn't thereafter changeable except by recompiling everything which references it. In particular, injecting a different value into Arrays.MIN_ARRAY_SORT_GRAN would likely have no effect at runtime. This situation seems a little strange/unhelpful to me. It wouldn't even be practically changeable between releases since code compiled with Java 8 would keep using that value even when running on future versions with a different value for MIN_ARRAY_SORT_GRAN. > > Good point Mike. I guess the same argument could be made for putting any value in the implementation detail. Any objection to completely removing any reference to this? > I agree that making it non-public is fine. Somewhere though there should be a note saying that a "parallel" sort might not actually use multiple threads because there are too few elements. -Doug From david.holmes at oracle.com Thu May 9 09:39:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 19:39:40 +1000 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518A8B92.8010509@oracle.com> References: <518A8B92.8010509@oracle.com> Message-ID: <518B6EDC.6030503@oracle.com> Hi Aleksey Well the code change is easy enough to review :) As to the effects ... no way to judge that: time and testing will tell. David On 9/05/2013 3:29 AM, Aleksey Shipilev wrote: > Hi, > > This is from our backlog after JDK-8005926. After ThreadLocalRandom > state was merged into Thread, we now have to deal with the false sharing > induced by heavily-updated fields in Thread. TLR was padded before, and > it should make sense to make Thread bear @Contended annotation to > isolate its fields in the same manner. > > The webrev is here: > http://cr.openjdk.java.net/~shade/8014233/webrev.00/ > > Testing: > - microbenchmarks (see below) > - JPRT cycle against jdk8-tl > > The extended rationale for the change follows. > > If we look at the current Thread layout, we can see the TLR state is > buried within the Thread instance. TLR state are by far the mostly > updated fields in Thread now: > >> Running 64-bit HotSpot VM. >> Using compressed references with 3-bit shift. >> Objects are 8 bytes aligned. >> >> java.lang.Thread >> offset size type description >> 0 12 (assumed to be the object header + first field alignment) >> 12 4 int Thread.priority >> 16 8 long Thread.eetop >> 24 8 long Thread.stackSize >> 32 8 long Thread.nativeParkEventPointer >> 40 8 long Thread.tid >> 48 8 long Thread.threadLocalRandomSeed >> 56 4 int Thread.threadStatus >> 60 4 int Thread.threadLocalRandomProbe >> 64 4 int Thread.threadLocalRandomSecondarySeed >> 68 1 boolean Thread.single_step >> 69 1 boolean Thread.daemon >> 70 1 boolean Thread.stillborn >> 71 1 (alignment/padding gap) >> 72 4 char[] Thread.name >> 76 4 Thread Thread.threadQ >> 80 4 Runnable Thread.target >> 84 4 ThreadGroup Thread.group >> 88 4 ClassLoader Thread.contextClassLoader >> 92 4 AccessControlContext Thread.inheritedAccessControlContext >> 96 4 ThreadLocalMap Thread.threadLocals >> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >> 104 4 Object Thread.parkBlocker >> 108 4 Interruptible Thread.blocker >> 112 4 Object Thread.blockerLock >> 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >> 120 (object boundary, size estimate) >> VM reports 120 bytes per instance > > > Assuming current x86 hardware with 64-byte cache line sizes and current > class layout, we can see the trailing fields in Thread are providing > enough insulation from the false sharing with an adjacent object. Also, > the Thread itself is large enough so that two TLRs belonging to > different threads will not collide. > > However the leading fields are not enough: we have a few words which can > occupy the same cache line, but belong to another object. This is where > things can get worse in two ways: a) the TLR update can make the field > access in adjacent object considerably slower; and much worse b) the > update in the adjacent field can disturb the TLR state, which is > critical for j.u.concurrent performance relying heavily on fast TLR. > > To illustrate both points, there is a simple benchmark driven by JMH > (http://openjdk.java.net/projects/code-tools/jmh/): > http://cr.openjdk.java.net/~shade/8014233/threadbench.zip > > On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and > Thread with/without @Contended that microbenchmark yields the following > results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: > > Accessing ThreadLocalRandom.current().nextInt(): > baseline: 932 +- 4 ops/usec > @Contended: 927 +- 10 ops/usec > > Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): > baseline: 454 +- 2 ops/usec > @Contended: 490 +- 3 ops/usec > > One might note the $uncaughtExceptionHandler is the trailing field in > the Thread, so it can naturally be false-shared with the adjacent > thread's TLR. We had chosen this as the illustration, in real examples > with multitude objects on the heap, we can get another contender. > > So that is ~10% performance hit on false sharing even on very small > machine. Translating it back: having heavily-updated field in the object > adjacent to Thread can bring these overheads to TLR, and then jeopardize > j.u.c performance. > > Of course, as soon as status quo about field layout is changed, we might > start to lose spectacularly. I would recommend we deal with this now, so > less surprises come in the future. > > The caveat is that we are wasting some of the space per Thread instance. > After the patch, we layout is: > >> java.lang.Thread >> offset size type description >> 0 12 (assumed to be the object header + first field alignment) >> 12 128 (alignment/padding gap) >> 140 4 int Thread.priority >> 144 8 long Thread.eetop >> 152 8 long Thread.stackSize >> 160 8 long Thread.nativeParkEventPointer >> 168 8 long Thread.tid >> 176 8 long Thread.threadLocalRandomSeed >> 184 4 int Thread.threadStatus >> 188 4 int Thread.threadLocalRandomProbe >> 192 4 int Thread.threadLocalRandomSecondarySeed >> 196 1 boolean Thread.single_step >> 197 1 boolean Thread.daemon >> 198 1 boolean Thread.stillborn >> 199 1 (alignment/padding gap) >> 200 4 char[] Thread.name >> 204 4 Thread Thread.threadQ >> 208 4 Runnable Thread.target >> 212 4 ThreadGroup Thread.group >> 216 4 ClassLoader Thread.contextClassLoader >> 220 4 AccessControlContext Thread.inheritedAccessControlContext >> 224 4 ThreadLocalMap Thread.threadLocals >> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >> 232 4 Object Thread.parkBlocker >> 236 4 Interruptible Thread.blocker >> 240 4 Object Thread.blockerLock >> 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >> 248 (object boundary, size estimate) >> VM reports 376 bytes per instance > > ...and we have additional 256 bytes per Thread (twice the > -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the > space wasted in native memory for each thread, especially stack areas. > > Thanks, > Aleksey. > From weijun.wang at oracle.com Thu May 9 09:45:03 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 09 May 2013 17:45:03 +0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <518B4C32.7010106@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> Message-ID: <518B701F.6070906@oracle.com> Out of curiosity (my major was math back in university), I take a look at BigInteger.java.phase1: First you have: /** * The threshold value for using 3-way Toom-Cook multiplication. * If the number of ints in both mag arrays are greater than this number, * then Toom-Cook multiplication will be used. This value is found * experimentally to work well. */ private static final int TOOM_COOK_THRESHOLD = 75; but then: public BigInteger multiply(BigInteger val) { if (val.signum == 0 || signum == 0) return ZERO; int xlen = mag.length; int ylen = val.mag.length; if ((xlen < KARATSUBA_THRESHOLD) || (ylen < KARATSUBA_THRESHOLD)) { .... } else if ((xlen < TOOM_COOK_THRESHOLD) && (ylen < TOOM_COOK_THRESHOLD)) return multiplyKaratsuba(this, val); else return multiplyToomCook3(this, val); } So, is it *both* numbers or *any* of them great than the constant that the Toom-Cook algotithm will be used? Thanks Max On 5/9/13 3:11 PM, Alan Eliasen wrote: > On 05/07/2013 12:53 PM, Brian Burkhalter wrote: >> To recapitulate in one place, I think we agree on the following sequence: >> >> Phase 1: Faster multiplication and exponentiation of large integers >> * Karatsuba and Toom-Cook multiplication and squaring; revised pow() function. >> * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 (update synopsis/description) >> * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 >> >> Phase 2: Faster string conversion of large integers >> * Recursive Schoenhage toString() routines. >> * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 >> >> Phase 3: Faster division of large integers >> * Burnickel-Ziegler division routines. >> * Issue to be filed. >> >> Phase 4: Faster multiplication and division of very large integers >> * Barrett division and Schoenhage-Strassen multiplication. >> * Issue to be filed. > > Okay, I've created a set of patches that implement these 4 phases. > (They're not actually patches, but the entire source file for each > phase, as Brian requested.) > > These are available at: > http://futureboy.us/temp/BigIntegerPatch.zip > > In this zipfile, the file(s) to use for each phase are marked with > the ".phaseX" suffix. If there is no change in a file for a given > phase, there is no file included for that phase, but you should make > sure that you are still using the BigDecimal and MutableBigInteger > file(s) applied in the previous phases. > > So, to be very clear, the files that make up each phase are: > > Phase 1: > BigInteger.java.phase1 > BigDecimal.java.phase1 (since BigInteger.pow is accelerated, the > workaround in BigDecimal is removed.) > > Phase 2: > BigInteger.java.phase2 > > Phase 3: > BigInteger.java.phase3 > MutableBigInteger.java.phase3 (to use Burnikel-Ziegler divide) > > Phase 4: > BigInteger.java.phase4 > > For your reference, the final versions of each file are contained > with the ".final" suffix. These will be identical to previous phases > applied, and you don't have to apply them, but if someone wants to > quickly drop in the best improvements to their own JDK, just use the 3 > files with the ".final" suffix. > > Let me know if you have any issues with these. > > Tim and Brian, you might decide amongst yourselves who wants to file > the issues for phases 3 and 4. I don't know if Brian has any magical > powers to make the issues skip the QA process. > From david.holmes at oracle.com Thu May 9 09:45:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 19:45:18 +1000 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> Message-ID: <518B702E.3060405@oracle.com> On 9/05/2013 7:26 AM, Chris Hegarty wrote: > On 8 May 2013, at 21:56, Mike Duigou wrote: >> On May 7 2013, at 10:13 , Chris Hegarty wrote: >> >>> On 05/07/2013 05:04 PM, Mike Duigou wrote: >>>> The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove currently? >>> >>> No problem. That would read... >>> >>> "When the sub-array length reaches a {@linlplain #MIN_ARRAY_SORT_GRAN >>> minimum granularity}, the sub-array is sorted using the appropriate >>> Arrays.sort method." >> >> >> linlplain -> linkplain >> >>>> I would expect to see currently if the numerical value of MIN_ARRAY_SORT_GRAN was presented. We may change the threshold but we're otherwise committed to the constant name for the threshold. >>> >>> I really don't care much for MIN_ARRAY_SORT_GRAN. I left it out from the original push, then flip flopped a few times on it. I don't like {@value}, as the field would still need to be public, but not referenced in the docs. I could be persuaded to go either way on it, but it is not worth spending time on. >> >> One other issue with MIN_ARRAY_SORT_GRAN is that, according to separate compilation rules, as a static final int the value of MIN_ARRAY_SORT_GRAN can/will be compiled into code. The value isn't thereafter changeable except by recompiling everything which references it. In particular, injecting a different value into Arrays.MIN_ARRAY_SORT_GRAN would likely have no effect at runtime. This situation seems a little strange/unhelpful to me. It wouldn't even be practically changeable between releases since code compiled with Java 8 would keep using that value even when running on future versions with a different value for MIN_ARRAY_SORT_GRAN. > > Good point Mike. I guess the same argument could be made for putting any value in the implementation detail. Any objection to completely removing any reference to this? The compile-time constant issue is easily fixed by using an initialization function. I think it is important for users to know what the sequential sorting threshold is. David ----- > -Chris > >> >> Mike >> From chris.hegarty at oracle.com Thu May 9 09:47:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 09 May 2013 10:47:28 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518B702E.3060405@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> Message-ID: <518B70B0.30703@oracle.com> On 05/09/2013 10:45 AM, David Holmes wrote: > .... >> Good point Mike. I guess the same argument could be made for putting >> any value in the implementation detail. Any objection to completely >> removing any reference to this? > > The compile-time constant issue is easily fixed by using an > initialization function. > > I think it is important for users to know what the sequential sorting > threshold is. I don't understand why this is important. Is the general advise not, always use parallelSort unless there is a good reason not to? -Chris > > David > ----- > >> -Chris >> >>> >>> Mike >>> From aleksey.shipilev at oracle.com Thu May 9 09:53:26 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 09 May 2013 13:53:26 +0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518B6EDC.6030503@oracle.com> References: <518A8B92.8010509@oracle.com> <518B6EDC.6030503@oracle.com> Message-ID: <518B7216.9030207@oracle.com> On 05/09/2013 01:39 PM, David Holmes wrote: > Well the code change is easy enough to review :) Ha! Bike-shed opportunity: to use fully quailified class name in the annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and friends). > As to the effects ... no way to judge that: time and testing will tell. What exactly do you mean by this? Testing tells securing against the false sharing is fruitful. And letting it drag means it will fire back at us sooner or later, and we will waste orders of magnitude more work tracing the particular concurrency issue back to Thread. -Aleksey. From Alan.Bateman at oracle.com Thu May 9 10:00:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 May 2013 11:00:27 +0100 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument In-Reply-To: <518AEA1D.5030402@oracle.com> References: <518AEA1D.5030402@oracle.com> Message-ID: <518B73BB.2050606@oracle.com> On 09/05/2013 01:13, Mandy Chung wrote: > Please review the simple change for: > JDK-4487672 (proxy) Proxy constructor should check for null argument > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/ It looks okay to me although technically an incompatible change. I guess it will at least have the NPE caught earlier that it would if the handler were actually used. -Alan From david.holmes at oracle.com Thu May 9 10:02:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 20:02:46 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B5FED.1050505@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> Message-ID: <518B7446.6060108@oracle.com> Hi Peter, Thanks for clarifying the test details. A few follow ups: - The reference class does get initialized early in the VM startup well before Main will be loaded. But the use of the weakref doesn't hurt. - 500ms may not be enough on some platforms, particularly some embedded systems. Ideally we could code up a handshake using another weakref that would guarantee that the handler thread really survived past the OOM. But at some point this just becomes a no-reg-hard situation :) - I'm not certain that setting waste=null is sufficient to guarantee the next allocation will succeed under all GC's. GC folk can confim/deny that. Thanks, David On 9/05/2013 6:35 PM, Peter Levart wrote: > On 05/09/2013 07:53 AM, David Holmes wrote: >> Hi Thomas, >> >> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> please review the latest webrev for this patch that is available at >>> >>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>> >>> As mentioned, it incorporates the fix and reproducer from Peter Levart. >> >> Fix is fine. >> >> I'm not sure about the test (sorry I didn't pay it attention earlier). >> Have you instrumented the code to verify that the test actually >> triggers an OOME? It may be possible that if the OOME did kill the >> reference thread that we wouldn't necessarily detect it using the >> sleeps etc. Also I don't understand the need for the actual weakRef >> usage and System.gc() etc. If the heap is full then the interrupt will >> wake the reference handler thread and the allocation will trigger the >> OOME. It doesn't matter if there are any references to process. The >> main logic might then reduce to: >> >> referenceHandlerThread.interrupt(); >> for (int i = 0; i < 10; i++) { >> if (!referenceHandlerThread.isAlive()) >> throw new Exception("Reference-handler thread died"); >> Thread.sleep(1000); >> } >> >> which just gives it 10s to die else assumes all ok. ? >> >> But I can live with existing test (it just might vacuously pass) >> >> Cheers, >> David > > Hi David, Thomas, > > Yes, this was just a left-over from my bug reproducer that demonstrated > the situation where WeakReference was cleared, but nothing was enqueue-d > into the ReferenceQueue. Reference Handler thread otherwise just sleeps > in lock.wait() most of the time if there's nothing to do and > interrupting it's thread will trigger allocation of InterruptedException > and consequently OOME nevertheless. > > One think to watch: Reference Handler thread is started in the > j.l.r.Reference static initializer, so the Reference class must be > initialized. I don't know if there is any guarantee that this is done > before entering main(). So there should be something explicit in main() > method that ensures it. > > Also, throwing test-fail exception should be done after releasing the > heap or we'll just trigger another OOME without any message to describe > the situation. > > Waiting in a loop for ReferenceHandler thread is not needed since the > test will normally succeed and so the whole loop will execute to the > end. Only when the test fails the loop will exit faster. In my > experience, the thread dies between 10-20ms after interrupting, so > waiting for about 500ms is enough I think. Also no System.gc() and > additional waiting is needed to report the outcome - just releasing the > reference to 'waste' variable is enuugh in my experience to restore the > heap into working condition. > > Here's the updated test that does all that: > > > public class OOMEInReferenceHandler { > static Object[] fillHeap() { > Object[] first = null, last = null; > int size = 1 << 20; > while (size > 0) { > try { > Object[] array = new Object[size]; > if (first == null) { > first = array; > } > else { > last[0] = array; > } > last = array; > } > catch (OutOfMemoryError oome) { > size = size >>> 1; > } > } > return first; > } > > public static void main(String[] args) throws Exception { > // ensure ReferenceHandler thread is started > new WeakReference(new Object()); > > ThreadGroup tg = Thread.currentThread().getThreadGroup(); > for (ThreadGroup tgn = tg; > tgn != null; > tg = tgn, tgn = tg.getParent()); > > Thread[] threads = new Thread[tg.activeCount()]; > Thread referenceHandlerThread = null; > int n = tg.enumerate(threads); > for (int i = 0; i < n; i++) { > if("Reference Handler".equals(threads[i].getName())) { > referenceHandlerThread = threads[i]; > } > } > > if (referenceHandlerThread == null) { > throw new IllegalStateException("Couldn't find Reference > Handler thread."); > } > > Object waste = fillHeap(); > > referenceHandlerThread.interrupt(); > > Thread.sleep(500L); > > // release waste so we can allocate and throw normal exceptions > waste = null; > > // check that the handler is still alive > if (!referenceHandlerThread.isAlive()) { > throw new Exception("Reference Handler thread died."); > } > } > } > > > > Regards, Peter > >> >>> Bugs.sun.com: >>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>> >>> JIRA: >>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>> >>> Testing: >>> JPRT, with the new reproducer passing >>> >>> In need of reviewers and a sponsor for this patch; as mentioned earlier >>> I will set Peter (plevart) as author for this patch, i.e. send a >>> patchset to the sponsor for this change with that author set. >>> >>> Thanks, >>> Thomas >>> > From david.holmes at oracle.com Thu May 9 10:08:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 20:08:21 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B69EB.8010104@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B69EB.8010104@gmail.com> Message-ID: <518B7595.6050901@oracle.com> On 9/05/2013 7:18 PM, Peter Levart wrote: > On 05/09/2013 07:53 AM, David Holmes wrote: >> Have you instrumented the code to verify that the test actually >> triggers an OOME? > > Without the patch, the test always throws OOME in lock.wait() and kills > the thread. At least in all executions I tried (100s) it did the same. How many different platforms could you try? > The test might pass without a patch only perhaps when TLABs are used. > The default is: -XX:-UseTLAB right? Perhaps it should be specified > explicitly... UseTLAB is true by default on most platforms: ./cpu/x86/vm/c1_globals_x86.hpp:define_pd_global(bool, UseTLAB, true ); ./cpu/x86/vm/c2_globals_x86.hpp:define_pd_global(bool, UseTLAB, true); ./cpu/zero/vm/shark_globals_zero.hpp:define_pd_global(bool, UseTLAB, true ); ./cpu/sparc/vm/c2_globals_sparc.hpp:define_pd_global(bool, UseTLAB, true); ./cpu/sparc/vm/c1_globals_sparc.hpp:define_pd_global(bool, UseTLAB, true ); I don't expect the test to be absolutely foolproof on every platform but it would be good to know it actually catches the bug on our test systems :) Something Thomas should be able to test I hope. Thanks, David > Regards, Peter > From Alan.Bateman at oracle.com Thu May 9 10:11:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 May 2013 11:11:04 +0100 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find In-Reply-To: <518B33DA.4060206@oracle.com> References: <5187E0AA.405@oracle.com> <518B33DA.4060206@oracle.com> Message-ID: <518B7638.2030902@oracle.com> On 09/05/2013 06:27, Henry Jen wrote: > On 05/08/2013 09:17 PM, Mike Duigou wrote: >> Looks good to me. >> > Thanks, we have a minor update to exclude changes for DirectoryStream. > > http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/ > > A quick review on the update is really appreciated. > Looks good to me. Just on the FaultFileSystem used by the tests. A typo in the class description " A FileSystem help testing". For completeness then .close should be idempotent. Minor alignment problem in getFileStore. Thanks for fixing the bug in the PassThroughFileSystem, that method must not be used by the other tests that uses this test file system. -Alan From david.holmes at oracle.com Thu May 9 10:12:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 20:12:00 +1000 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518B70B0.30703@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> <518B70B0.30703@oracle.com> Message-ID: <518B7670.4080405@oracle.com> On 9/05/2013 7:47 PM, Chris Hegarty wrote: > On 05/09/2013 10:45 AM, David Holmes wrote: >> .... >>> Good point Mike. I guess the same argument could be made for putting >>> any value in the implementation detail. Any objection to completely >>> removing any reference to this? >> >> The compile-time constant issue is easily fixed by using an >> initialization function. >> >> I think it is important for users to know what the sequential sorting >> threshold is. > > I don't understand why this is important. Is the general advise not, > always use parallelSort unless there is a good reason not to? That certainly would NOT be my general advise. My general advise is only use parallelism to solve a performance problem. Overuse of FJ for non critical tasks will just cause contention and an overall loss of performance at the system level. David ----- > -Chris > >> >> David >> ----- >> >>> -Chris >>> >>>> >>>> Mike >>>> From david.holmes at oracle.com Thu May 9 10:15:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 20:15:18 +1000 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518B7216.9030207@oracle.com> References: <518A8B92.8010509@oracle.com> <518B6EDC.6030503@oracle.com> <518B7216.9030207@oracle.com> Message-ID: <518B7736.80705@oracle.com> On 9/05/2013 7:53 PM, Aleksey Shipilev wrote: > On 05/09/2013 01:39 PM, David Holmes wrote: >> Well the code change is easy enough to review :) > > Ha! Bike-shed opportunity: to use fully quailified class name in the > annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and > friends). > >> As to the effects ... no way to judge that: time and testing will tell. ^for me > What exactly do you mean by this? Only that I can't validate the utility of this from simple code inspection. As time goes by and the code is put to the test we will find out if there are any performance issues/surprises and if there still lurk any hidden bugs in the @Contended implementation. Cheers, David > Testing tells securing against the > false sharing is fruitful. And letting it drag means it will fire back > at us sooner or later, and we will waste orders of magnitude more work > tracing the particular concurrency issue back to Thread. > > -Aleksey. > > From aleksey.shipilev at oracle.com Thu May 9 10:20:46 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 09 May 2013 14:20:46 +0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518B7736.80705@oracle.com> References: <518A8B92.8010509@oracle.com> <518B6EDC.6030503@oracle.com> <518B7216.9030207@oracle.com> <518B7736.80705@oracle.com> Message-ID: <518B787E.5070701@oracle.com> On 05/09/2013 02:15 PM, David Holmes wrote: > On 9/05/2013 7:53 PM, Aleksey Shipilev wrote: >> On 05/09/2013 01:39 PM, David Holmes wrote: >>> Well the code change is easy enough to review :) >> >> Ha! Bike-shed opportunity: to use fully quailified class name in the >> annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and >> friends). >> >>> As to the effects ... no way to judge that: time and testing will tell. > ^for me >> What exactly do you mean by this? > > Only that I can't validate the utility of this from simple code > inspection. As time goes by and the code is put to the test we will find > out if there are any performance issues/surprises and if there still > lurk any hidden bugs in the @Contended implementation. Ah, sure, that's why we have benchmarks :) There is a hidden step in this logic: we've seen how troubling false sharing can be, and so even if the microbenchmark raises the red flag, it's time to act. Also, I was watching carefully with this experiment if @Contended breaks my intuition about things. So far it is does not raise the red flags on its own. -Aleksey. From dl at cs.oswego.edu Thu May 9 10:38:30 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 09 May 2013 06:38:30 -0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518B6EDC.6030503@oracle.com> References: <518A8B92.8010509@oracle.com> <518B6EDC.6030503@oracle.com> Message-ID: <518B7CA6.5010806@cs.oswego.edu> On 05/09/13 05:39, David Holmes wrote: > Hi Aleksey > > Well the code change is easy enough to review :) > > As to the effects ... no way to judge that: time and testing will tell. > For some initial sanity-check testing, I just built lambda with the added @Contended annotation on Thread and ran a few of our jsr166 performance tests involving classes that somehow frequently touch Thread fields. It seems to be a strictly positive change. Not a dramatic one on average, but the main benefit is avoiding occasional really terrible performance due to the GC colocating all Thread objects, or locating them near busy ThreadLocals etc. -Doug From peter.levart at gmail.com Thu May 9 10:40:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 12:40:50 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B7595.6050901@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B69EB.8010104@gmail.com> <518B7595.6050901@oracle.com> Message-ID: <518B7D32.3000801@gmail.com> On 05/09/2013 12:08 PM, David Holmes wrote: > On 9/05/2013 7:18 PM, Peter Levart wrote: >> On 05/09/2013 07:53 AM, David Holmes wrote: >>> Have you instrumented the code to verify that the test actually >>> triggers an OOME? >> >> Without the patch, the test always throws OOME in lock.wait() and kills >> the thread. At least in all executions I tried (100s) it did the same. > > How many different platforms could you try? > >> The test might pass without a patch only perhaps when TLABs are used. >> The default is: -XX:-UseTLAB right? Perhaps it should be specified >> explicitly... > > UseTLAB is true by default on most platforms: > > ./cpu/x86/vm/c1_globals_x86.hpp:define_pd_global(bool, UseTLAB, > true ); > ./cpu/x86/vm/c2_globals_x86.hpp:define_pd_global(bool, UseTLAB, > true); > ./cpu/zero/vm/shark_globals_zero.hpp:define_pd_global(bool, UseTLAB, > true ); > ./cpu/sparc/vm/c2_globals_sparc.hpp:define_pd_global(bool, UseTLAB, > true); > ./cpu/sparc/vm/c1_globals_sparc.hpp:define_pd_global(bool, UseTLAB, > true ); Hm, interesting. How do you explain that the allocation of a simple InterruptedException fails in Reference Handler thread after the 'main' thread has burnt all the heap including it's own TLAB? Is it just by chance that there was not enough space in Reference Handler's TLAB to allocate the exception? Is TLAB allocated lazily when the thread does it's 1st allocation? There're no allocations in the ReferenceHandler's run() method (excluding Cleaners), so the InterruptedException might be it's 1st allocation. To be more robust, we should specify -XX:-UseTLAB to run the test. Regards, Peter > > I don't expect the test to be absolutely foolproof on every platform > but it would be good to know it actually catches the bug on our test > systems :) Something Thomas should be able to test I hope. > > Thanks, > David > >> Regards, Peter >> From peter.levart at gmail.com Thu May 9 11:16:39 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 13:16:39 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B7446.6060108@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> Message-ID: <518B8597.50209@gmail.com> Hi David, On 05/09/2013 12:02 PM, David Holmes wrote: > Hi Peter, > > Thanks for clarifying the test details. A few follow ups: > > - The reference class does get initialized early in the VM startup > well before Main will be loaded. But the use of the weakref doesn't hurt. Ok, so if this is guaranteed, we can remove the weakref construction. > > - 500ms may not be enough on some platforms, particularly some > embedded systems. Ideally we could code up a handshake using another > weakref that would guarantee that the handler thread really survived > past the OOM. But at some point this just becomes a no-reg-hard > situation :) If we used a weakref then there should be a delay between the referenceHandlerThread.interrupt() and the release of the WeakReference's referent, otherwise the WeakReference could be cleared and enqueued before Reference Handler attempts to throw InterruptedException (this really happens - I tried without delay and the clearing/enqueueing was quicker than interrupt). After this initial delay (currently set to 500ms) releasing the referent and waiting for WeakReference to be enqueued (while executing System.gc()) is analogous to testing for referenceHandlerThread.isAlive() - the only difference being the code that has to be executed in Reference Handler while unwinding the stack until the state of thread changes to TERMINATED. Can this be delayed for a long time? > > - I'm not certain that setting waste=null is sufficient to guarantee > the next allocation will succeed under all GC's. GC folk can > confim/deny that. We can pre-allocate the test-fail exception before doing fillHeap() so that we can conditionally throw it later, like this: public class Test { static Object[] fillHeap() { Object[] first = null, last = null; int size = 1 << 20; while (size > 0) { try { Object[] array = new Object[size]; if (first == null) { first = array; } else { last[0] = array; } last = array; } catch (OutOfMemoryError oome) { size = size >>> 1; } } return first; } public static void main(String[] args) throws Exception { ThreadGroup tg = Thread.currentThread().getThreadGroup(); for ( ThreadGroup tgn = tg; tgn != null; tg = tgn, tgn = tg.getParent() ) ; Thread[] threads = new Thread[tg.activeCount()]; Thread referenceHandlerThread = null; int n = tg.enumerate(threads); for (int i = 0; i < n; i++) { if ("Reference Handler".equals(threads[i].getName())) { referenceHandlerThread = threads[i]; } } if (referenceHandlerThread == null) { throw new IllegalStateException("Couldn't find Reference Handler thread."); } // pre-allocate failure so that we don't cause OOME later Exception failure = new Exception("Reference Handler thread died."); Object waste = fillHeap(); referenceHandlerThread.interrupt(); // allow referenceHandlerThread some time to throw OOME Thread.sleep(500L); if (waste != null && // keep 'waste' reference alive until this point !referenceHandlerThread.isAlive()// check that the handler is still alive ) { throw failure; } } } Regards, Peter > > Thanks, > David > > On 9/05/2013 6:35 PM, Peter Levart wrote: >> On 05/09/2013 07:53 AM, David Holmes wrote: >>> Hi Thomas, >>> >>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> please review the latest webrev for this patch that is available at >>>> >>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>> >>>> As mentioned, it incorporates the fix and reproducer from Peter >>>> Levart. >>> >>> Fix is fine. >>> >>> I'm not sure about the test (sorry I didn't pay it attention earlier). >>> Have you instrumented the code to verify that the test actually >>> triggers an OOME? It may be possible that if the OOME did kill the >>> reference thread that we wouldn't necessarily detect it using the >>> sleeps etc. Also I don't understand the need for the actual weakRef >>> usage and System.gc() etc. If the heap is full then the interrupt will >>> wake the reference handler thread and the allocation will trigger the >>> OOME. It doesn't matter if there are any references to process. The >>> main logic might then reduce to: >>> >>> referenceHandlerThread.interrupt(); >>> for (int i = 0; i < 10; i++) { >>> if (!referenceHandlerThread.isAlive()) >>> throw new Exception("Reference-handler thread died"); >>> Thread.sleep(1000); >>> } >>> >>> which just gives it 10s to die else assumes all ok. ? >>> >>> But I can live with existing test (it just might vacuously pass) >>> >>> Cheers, >>> David >> >> Hi David, Thomas, >> >> Yes, this was just a left-over from my bug reproducer that demonstrated >> the situation where WeakReference was cleared, but nothing was enqueue-d >> into the ReferenceQueue. Reference Handler thread otherwise just sleeps >> in lock.wait() most of the time if there's nothing to do and >> interrupting it's thread will trigger allocation of InterruptedException >> and consequently OOME nevertheless. >> >> One think to watch: Reference Handler thread is started in the >> j.l.r.Reference static initializer, so the Reference class must be >> initialized. I don't know if there is any guarantee that this is done >> before entering main(). So there should be something explicit in main() >> method that ensures it. >> >> Also, throwing test-fail exception should be done after releasing the >> heap or we'll just trigger another OOME without any message to describe >> the situation. >> >> Waiting in a loop for ReferenceHandler thread is not needed since the >> test will normally succeed and so the whole loop will execute to the >> end. Only when the test fails the loop will exit faster. In my >> experience, the thread dies between 10-20ms after interrupting, so >> waiting for about 500ms is enough I think. Also no System.gc() and >> additional waiting is needed to report the outcome - just releasing the >> reference to 'waste' variable is enuugh in my experience to restore the >> heap into working condition. >> >> Here's the updated test that does all that: >> >> >> public class OOMEInReferenceHandler { >> static Object[] fillHeap() { >> Object[] first = null, last = null; >> int size = 1 << 20; >> while (size > 0) { >> try { >> Object[] array = new Object[size]; >> if (first == null) { >> first = array; >> } >> else { >> last[0] = array; >> } >> last = array; >> } >> catch (OutOfMemoryError oome) { >> size = size >>> 1; >> } >> } >> return first; >> } >> >> public static void main(String[] args) throws Exception { >> // ensure ReferenceHandler thread is started >> new WeakReference(new Object()); >> >> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >> for (ThreadGroup tgn = tg; >> tgn != null; >> tg = tgn, tgn = tg.getParent()); >> >> Thread[] threads = new Thread[tg.activeCount()]; >> Thread referenceHandlerThread = null; >> int n = tg.enumerate(threads); >> for (int i = 0; i < n; i++) { >> if("Reference Handler".equals(threads[i].getName())) { >> referenceHandlerThread = threads[i]; >> } >> } >> >> if (referenceHandlerThread == null) { >> throw new IllegalStateException("Couldn't find Reference >> Handler thread."); >> } >> >> Object waste = fillHeap(); >> >> referenceHandlerThread.interrupt(); >> >> Thread.sleep(500L); >> >> // release waste so we can allocate and throw normal exceptions >> waste = null; >> >> // check that the handler is still alive >> if (!referenceHandlerThread.isAlive()) { >> throw new Exception("Reference Handler thread died."); >> } >> } >> } >> >> >> >> Regards, Peter >> >>> >>>> Bugs.sun.com: >>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>> >>>> JIRA: >>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>> >>>> Testing: >>>> JPRT, with the new reproducer passing >>>> >>>> In need of reviewers and a sponsor for this patch; as mentioned >>>> earlier >>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>> patchset to the sponsor for this change with that author set. >>>> >>>> Thanks, >>>> Thomas >>>> >> From david.holmes at oracle.com Thu May 9 11:28:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 21:28:07 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B7D32.3000801@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B69EB.8010104@gmail.com> <518B7595.6050901@oracle.com> <518B7D32.3000801@gmail.com> Message-ID: <518B8847.2070806@oracle.com> On 9/05/2013 8:40 PM, Peter Levart wrote: > On 05/09/2013 12:08 PM, David Holmes wrote: >> On 9/05/2013 7:18 PM, Peter Levart wrote: >>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>> Have you instrumented the code to verify that the test actually >>>> triggers an OOME? >>> >>> Without the patch, the test always throws OOME in lock.wait() and kills >>> the thread. At least in all executions I tried (100s) it did the same. >> >> How many different platforms could you try? >> >>> The test might pass without a patch only perhaps when TLABs are used. >>> The default is: -XX:-UseTLAB right? Perhaps it should be specified >>> explicitly... >> >> UseTLAB is true by default on most platforms: >> >> ./cpu/x86/vm/c1_globals_x86.hpp:define_pd_global(bool, UseTLAB, >> true ); >> ./cpu/x86/vm/c2_globals_x86.hpp:define_pd_global(bool, UseTLAB, >> true); >> ./cpu/zero/vm/shark_globals_zero.hpp:define_pd_global(bool, UseTLAB, >> true ); >> ./cpu/sparc/vm/c2_globals_sparc.hpp:define_pd_global(bool, UseTLAB, >> true); >> ./cpu/sparc/vm/c1_globals_sparc.hpp:define_pd_global(bool, UseTLAB, >> true ); > > Hm, interesting. How do you explain that the allocation of a simple > InterruptedException fails in Reference Handler thread after the 'main' > thread has burnt all the heap including it's own TLAB? Is it just by > chance that there was not enough space in Reference Handler's TLAB to > allocate the exception? Is TLAB allocated lazily when the thread does > it's 1st allocation? There're no allocations in the ReferenceHandler's > run() method (excluding Cleaners), so the InterruptedException might be > it's 1st allocation. To be more robust, we should specify -XX:-UseTLAB > to run the test. I can't answer that - GC folk? David ----- > Regards, Peter > >> >> I don't expect the test to be absolutely foolproof on every platform >> but it would be good to know it actually catches the bug on our test >> systems :) Something Thomas should be able to test I hope. >> >> Thanks, >> David >> >>> Regards, Peter >>> > From david.holmes at oracle.com Thu May 9 11:33:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 May 2013 21:33:22 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B8597.50209@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> Message-ID: <518B8982.20305@oracle.com> On 9/05/2013 9:16 PM, Peter Levart wrote: > Hi David, > > On 05/09/2013 12:02 PM, David Holmes wrote: >> Hi Peter, >> >> Thanks for clarifying the test details. A few follow ups: >> >> - The reference class does get initialized early in the VM startup >> well before Main will be loaded. But the use of the weakref doesn't hurt. > > Ok, so if this is guaranteed, we can remove the weakref construction. > >> >> - 500ms may not be enough on some platforms, particularly some >> embedded systems. Ideally we could code up a handshake using another >> weakref that would guarantee that the handler thread really survived >> past the OOM. But at some point this just becomes a no-reg-hard >> situation :) > > If we used a weakref then there should be a delay between the > referenceHandlerThread.interrupt() and the release of the > WeakReference's referent, otherwise the WeakReference could be cleared > and enqueued before Reference Handler attempts to throw > InterruptedException (this really happens - I tried without delay and > the clearing/enqueueing was quicker than interrupt). After this initial > delay (currently set to 500ms) releasing the referent and waiting for > WeakReference to be enqueued (while executing System.gc()) is analogous > to testing for referenceHandlerThread.isAlive() - the only difference > being the code that has to be executed in Reference Handler while > unwinding the stack until the state of thread changes to TERMINATED. Can > this be delayed for a long time? What I was thinking was that after we interrupt we then create a new weakref and we loop until the ref gets cleared, or we detect the reference thread is not alive (with a sleep in between). One of those two conditions must become true. >> >> - I'm not certain that setting waste=null is sufficient to guarantee >> the next allocation will succeed under all GC's. GC folk can >> confim/deny that. > > We can pre-allocate the test-fail exception before doing fillHeap() so > that we can conditionally throw it later, like this: So when we do the throw there is logic in the launcher that will try to print the stacktrace, which may also encounter OOME unless we have freed the heap. So I think we want to release memory, I just wasn't certain that simply setting waste=null would guarantee it. David ------ > public class Test { > static Object[] fillHeap() { > Object[] first = null, last = null; > int size = 1 << 20; > while (size > 0) { > try { > Object[] array = new Object[size]; > if (first == null) { > first = array; > } else { > last[0] = array; > } > last = array; > } catch (OutOfMemoryError oome) { > size = size >>> 1; > } > } > return first; > } > > public static void main(String[] args) throws Exception { > ThreadGroup tg = Thread.currentThread().getThreadGroup(); > for ( > ThreadGroup tgn = tg; > tgn != null; > tg = tgn, tgn = tg.getParent() > ) > ; > > Thread[] threads = new Thread[tg.activeCount()]; > Thread referenceHandlerThread = null; > int n = tg.enumerate(threads); > for (int i = 0; i < n; i++) { > if ("Reference Handler".equals(threads[i].getName())) { > referenceHandlerThread = threads[i]; > } > } > > if (referenceHandlerThread == null) { > throw new IllegalStateException("Couldn't find Reference > Handler thread."); > } > > // pre-allocate failure so that we don't cause OOME later > Exception failure = new Exception("Reference Handler thread > died."); > > Object waste = fillHeap(); > > referenceHandlerThread.interrupt(); > > // allow referenceHandlerThread some time to throw OOME > Thread.sleep(500L); > > if (waste != null && // keep 'waste' reference alive until this > point > !referenceHandlerThread.isAlive()// check that the handler > is still alive > ) { > throw failure; > } > } > } > > > > Regards, Peter > >> >> Thanks, >> David >> >> On 9/05/2013 6:35 PM, Peter Levart wrote: >>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>> Hi Thomas, >>>> >>>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>>> Hi, >>>>> >>>>> please review the latest webrev for this patch that is available at >>>>> >>>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>>> >>>>> As mentioned, it incorporates the fix and reproducer from Peter >>>>> Levart. >>>> >>>> Fix is fine. >>>> >>>> I'm not sure about the test (sorry I didn't pay it attention earlier). >>>> Have you instrumented the code to verify that the test actually >>>> triggers an OOME? It may be possible that if the OOME did kill the >>>> reference thread that we wouldn't necessarily detect it using the >>>> sleeps etc. Also I don't understand the need for the actual weakRef >>>> usage and System.gc() etc. If the heap is full then the interrupt will >>>> wake the reference handler thread and the allocation will trigger the >>>> OOME. It doesn't matter if there are any references to process. The >>>> main logic might then reduce to: >>>> >>>> referenceHandlerThread.interrupt(); >>>> for (int i = 0; i < 10; i++) { >>>> if (!referenceHandlerThread.isAlive()) >>>> throw new Exception("Reference-handler thread died"); >>>> Thread.sleep(1000); >>>> } >>>> >>>> which just gives it 10s to die else assumes all ok. ? >>>> >>>> But I can live with existing test (it just might vacuously pass) >>>> >>>> Cheers, >>>> David >>> >>> Hi David, Thomas, >>> >>> Yes, this was just a left-over from my bug reproducer that demonstrated >>> the situation where WeakReference was cleared, but nothing was enqueue-d >>> into the ReferenceQueue. Reference Handler thread otherwise just sleeps >>> in lock.wait() most of the time if there's nothing to do and >>> interrupting it's thread will trigger allocation of InterruptedException >>> and consequently OOME nevertheless. >>> >>> One think to watch: Reference Handler thread is started in the >>> j.l.r.Reference static initializer, so the Reference class must be >>> initialized. I don't know if there is any guarantee that this is done >>> before entering main(). So there should be something explicit in main() >>> method that ensures it. >>> >>> Also, throwing test-fail exception should be done after releasing the >>> heap or we'll just trigger another OOME without any message to describe >>> the situation. >>> >>> Waiting in a loop for ReferenceHandler thread is not needed since the >>> test will normally succeed and so the whole loop will execute to the >>> end. Only when the test fails the loop will exit faster. In my >>> experience, the thread dies between 10-20ms after interrupting, so >>> waiting for about 500ms is enough I think. Also no System.gc() and >>> additional waiting is needed to report the outcome - just releasing the >>> reference to 'waste' variable is enuugh in my experience to restore the >>> heap into working condition. >>> >>> Here's the updated test that does all that: >>> >>> >>> public class OOMEInReferenceHandler { >>> static Object[] fillHeap() { >>> Object[] first = null, last = null; >>> int size = 1 << 20; >>> while (size > 0) { >>> try { >>> Object[] array = new Object[size]; >>> if (first == null) { >>> first = array; >>> } >>> else { >>> last[0] = array; >>> } >>> last = array; >>> } >>> catch (OutOfMemoryError oome) { >>> size = size >>> 1; >>> } >>> } >>> return first; >>> } >>> >>> public static void main(String[] args) throws Exception { >>> // ensure ReferenceHandler thread is started >>> new WeakReference(new Object()); >>> >>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>> for (ThreadGroup tgn = tg; >>> tgn != null; >>> tg = tgn, tgn = tg.getParent()); >>> >>> Thread[] threads = new Thread[tg.activeCount()]; >>> Thread referenceHandlerThread = null; >>> int n = tg.enumerate(threads); >>> for (int i = 0; i < n; i++) { >>> if("Reference Handler".equals(threads[i].getName())) { >>> referenceHandlerThread = threads[i]; >>> } >>> } >>> >>> if (referenceHandlerThread == null) { >>> throw new IllegalStateException("Couldn't find Reference >>> Handler thread."); >>> } >>> >>> Object waste = fillHeap(); >>> >>> referenceHandlerThread.interrupt(); >>> >>> Thread.sleep(500L); >>> >>> // release waste so we can allocate and throw normal exceptions >>> waste = null; >>> >>> // check that the handler is still alive >>> if (!referenceHandlerThread.isAlive()) { >>> throw new Exception("Reference Handler thread died."); >>> } >>> } >>> } >>> >>> >>> >>> Regards, Peter >>> >>>> >>>>> Bugs.sun.com: >>>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>>> >>>>> JIRA: >>>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>>> >>>>> Testing: >>>>> JPRT, with the new reproducer passing >>>>> >>>>> In need of reviewers and a sponsor for this patch; as mentioned >>>>> earlier >>>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>>> patchset to the sponsor for this change with that author set. >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>> > From dl at cs.oswego.edu Thu May 9 11:41:27 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 09 May 2013 07:41:27 -0400 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518B7670.4080405@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> <518B70B0.30703@oracle.com> <518B7670.4080405@oracle.com> Message-ID: <518B8B67.2060502@cs.oswego.edu> >> I don't understand why this is important. Is the general advise not, >> always use parallelSort unless there is a good reason not to? > > That certainly would NOT be my general advise. My general advise is only use > parallelism to solve a performance problem. Overuse of FJ for non critical tasks > will just cause contention and an overall loss of performance at the system level. > Hoping not to veer too far off track on this.... But the goal is of course for "parallel" versions of sorting, stream operations, etc to always have better performance. Many of the associated changes (like @Contended and smarter thresholding for parallel sort) represent attempts to get closer to this goal. There will be cases where it doesn't hold. In particular, Collection.parallelStream() operations for very lightweight operations (lambdas) on very few elements have crummy performance, so rely on Users to not do that. But the driving sentiment is that in general, users should get overall throughput improvements for any parallel* method for which they might reasonably expect it. Tests of this parallelSort code show that it is almost always faster than plain sort() unless the array is already nearly sorted. -Doug From peter.levart at gmail.com Thu May 9 12:13:42 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 14:13:42 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B8982.20305@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> Message-ID: <518B92F6.6030105@gmail.com> On 05/09/2013 01:33 PM, David Holmes wrote: > On 9/05/2013 9:16 PM, Peter Levart wrote: >> Hi David, >> >> On 05/09/2013 12:02 PM, David Holmes wrote: >>> Hi Peter, >>> >>> Thanks for clarifying the test details. A few follow ups: >>> >>> - The reference class does get initialized early in the VM startup >>> well before Main will be loaded. But the use of the weakref doesn't >>> hurt. >> >> Ok, so if this is guaranteed, we can remove the weakref construction. >> >>> >>> - 500ms may not be enough on some platforms, particularly some >>> embedded systems. Ideally we could code up a handshake using another >>> weakref that would guarantee that the handler thread really survived >>> past the OOM. But at some point this just becomes a no-reg-hard >>> situation :) >> >> If we used a weakref then there should be a delay between the >> referenceHandlerThread.interrupt() and the release of the >> WeakReference's referent, otherwise the WeakReference could be cleared >> and enqueued before Reference Handler attempts to throw >> InterruptedException (this really happens - I tried without delay and >> the clearing/enqueueing was quicker than interrupt). After this initial >> delay (currently set to 500ms) releasing the referent and waiting for >> WeakReference to be enqueued (while executing System.gc()) is analogous >> to testing for referenceHandlerThread.isAlive() - the only difference >> being the code that has to be executed in Reference Handler while >> unwinding the stack until the state of thread changes to TERMINATED. Can >> this be delayed for a long time? > > What I was thinking was that after we interrupt we then create a new > weakref Can't do that immediately (no space)! > and we loop until the ref gets cleared, or we detect the reference > thread is not alive (with a sleep in between). One of those two > conditions must become true. To create a weakref after interrupt, we have to 1st wait some time (to give Reference Handler thread a chance to throw OOME), then free the heap (release 'waste' and possibly do some System.gc()) to get some space for weakref creation. After we do that, a chance that Reference Handler thread is just in the process of unwinding the stack after uncaught OOME and referenceHandlerThread.isAlive() still returns true is minimal. Do you think we should wait some more to be sure thread is still alive? > >>> >>> - I'm not certain that setting waste=null is sufficient to guarantee >>> the next allocation will succeed under all GC's. GC folk can >>> confim/deny that. >> >> We can pre-allocate the test-fail exception before doing fillHeap() so >> that we can conditionally throw it later, like this: > > So when we do the throw there is logic in the launcher that will try > to print the stacktrace, which may also encounter OOME unless we have > freed the heap. So I think we want to release memory, I just wasn't > certain that simply setting waste=null would guarantee it. 'waste' is local variable and goes out of scope when main() is finished. So in final variation I haven't even bothered to set it to null at the end. What do you suggest for successful test failure? Setting 'waste' to null, followed by a System.gc() and Thread.sleep()? Can we signal test failure in another way? System.exit(1)? Regards, Peter > > David > ------ > >> public class Test { >> static Object[] fillHeap() { >> Object[] first = null, last = null; >> int size = 1 << 20; >> while (size > 0) { >> try { >> Object[] array = new Object[size]; >> if (first == null) { >> first = array; >> } else { >> last[0] = array; >> } >> last = array; >> } catch (OutOfMemoryError oome) { >> size = size >>> 1; >> } >> } >> return first; >> } >> >> public static void main(String[] args) throws Exception { >> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >> for ( >> ThreadGroup tgn = tg; >> tgn != null; >> tg = tgn, tgn = tg.getParent() >> ) >> ; >> >> Thread[] threads = new Thread[tg.activeCount()]; >> Thread referenceHandlerThread = null; >> int n = tg.enumerate(threads); >> for (int i = 0; i < n; i++) { >> if ("Reference Handler".equals(threads[i].getName())) { >> referenceHandlerThread = threads[i]; >> } >> } >> >> if (referenceHandlerThread == null) { >> throw new IllegalStateException("Couldn't find Reference >> Handler thread."); >> } >> >> // pre-allocate failure so that we don't cause OOME later >> Exception failure = new Exception("Reference Handler thread >> died."); >> >> Object waste = fillHeap(); >> >> referenceHandlerThread.interrupt(); >> >> // allow referenceHandlerThread some time to throw OOME >> Thread.sleep(500L); >> >> if (waste != null && // keep 'waste' reference alive until this >> point >> !referenceHandlerThread.isAlive()// check that the handler >> is still alive >> ) { >> throw failure; >> } >> } >> } >> >> >> >> Regards, Peter >> >>> >>> Thanks, >>> David >>> >>> On 9/05/2013 6:35 PM, Peter Levart wrote: >>>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>>> Hi Thomas, >>>>> >>>>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>>>> Hi, >>>>>> >>>>>> please review the latest webrev for this patch that is >>>>>> available at >>>>>> >>>>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>>>> >>>>>> As mentioned, it incorporates the fix and reproducer from Peter >>>>>> Levart. >>>>> >>>>> Fix is fine. >>>>> >>>>> I'm not sure about the test (sorry I didn't pay it attention >>>>> earlier). >>>>> Have you instrumented the code to verify that the test actually >>>>> triggers an OOME? It may be possible that if the OOME did kill the >>>>> reference thread that we wouldn't necessarily detect it using the >>>>> sleeps etc. Also I don't understand the need for the actual weakRef >>>>> usage and System.gc() etc. If the heap is full then the interrupt >>>>> will >>>>> wake the reference handler thread and the allocation will trigger the >>>>> OOME. It doesn't matter if there are any references to process. The >>>>> main logic might then reduce to: >>>>> >>>>> referenceHandlerThread.interrupt(); >>>>> for (int i = 0; i < 10; i++) { >>>>> if (!referenceHandlerThread.isAlive()) >>>>> throw new Exception("Reference-handler thread died"); >>>>> Thread.sleep(1000); >>>>> } >>>>> >>>>> which just gives it 10s to die else assumes all ok. ? >>>>> >>>>> But I can live with existing test (it just might vacuously pass) >>>>> >>>>> Cheers, >>>>> David >>>> >>>> Hi David, Thomas, >>>> >>>> Yes, this was just a left-over from my bug reproducer that >>>> demonstrated >>>> the situation where WeakReference was cleared, but nothing was >>>> enqueue-d >>>> into the ReferenceQueue. Reference Handler thread otherwise just >>>> sleeps >>>> in lock.wait() most of the time if there's nothing to do and >>>> interrupting it's thread will trigger allocation of >>>> InterruptedException >>>> and consequently OOME nevertheless. >>>> >>>> One think to watch: Reference Handler thread is started in the >>>> j.l.r.Reference static initializer, so the Reference class must be >>>> initialized. I don't know if there is any guarantee that this is done >>>> before entering main(). So there should be something explicit in >>>> main() >>>> method that ensures it. >>>> >>>> Also, throwing test-fail exception should be done after releasing the >>>> heap or we'll just trigger another OOME without any message to >>>> describe >>>> the situation. >>>> >>>> Waiting in a loop for ReferenceHandler thread is not needed since the >>>> test will normally succeed and so the whole loop will execute to the >>>> end. Only when the test fails the loop will exit faster. In my >>>> experience, the thread dies between 10-20ms after interrupting, so >>>> waiting for about 500ms is enough I think. Also no System.gc() and >>>> additional waiting is needed to report the outcome - just releasing >>>> the >>>> reference to 'waste' variable is enuugh in my experience to restore >>>> the >>>> heap into working condition. >>>> >>>> Here's the updated test that does all that: >>>> >>>> >>>> public class OOMEInReferenceHandler { >>>> static Object[] fillHeap() { >>>> Object[] first = null, last = null; >>>> int size = 1 << 20; >>>> while (size > 0) { >>>> try { >>>> Object[] array = new Object[size]; >>>> if (first == null) { >>>> first = array; >>>> } >>>> else { >>>> last[0] = array; >>>> } >>>> last = array; >>>> } >>>> catch (OutOfMemoryError oome) { >>>> size = size >>> 1; >>>> } >>>> } >>>> return first; >>>> } >>>> >>>> public static void main(String[] args) throws Exception { >>>> // ensure ReferenceHandler thread is started >>>> new WeakReference(new Object()); >>>> >>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>> for (ThreadGroup tgn = tg; >>>> tgn != null; >>>> tg = tgn, tgn = tg.getParent()); >>>> >>>> Thread[] threads = new Thread[tg.activeCount()]; >>>> Thread referenceHandlerThread = null; >>>> int n = tg.enumerate(threads); >>>> for (int i = 0; i < n; i++) { >>>> if("Reference Handler".equals(threads[i].getName())) { >>>> referenceHandlerThread = threads[i]; >>>> } >>>> } >>>> >>>> if (referenceHandlerThread == null) { >>>> throw new IllegalStateException("Couldn't find Reference >>>> Handler thread."); >>>> } >>>> >>>> Object waste = fillHeap(); >>>> >>>> referenceHandlerThread.interrupt(); >>>> >>>> Thread.sleep(500L); >>>> >>>> // release waste so we can allocate and throw normal >>>> exceptions >>>> waste = null; >>>> >>>> // check that the handler is still alive >>>> if (!referenceHandlerThread.isAlive()) { >>>> throw new Exception("Reference Handler thread died."); >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>>> Bugs.sun.com: >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>>>> >>>>>> JIRA: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>>>> >>>>>> Testing: >>>>>> JPRT, with the new reproducer passing >>>>>> >>>>>> In need of reviewers and a sponsor for this patch; as mentioned >>>>>> earlier >>>>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>>>> patchset to the sponsor for this change with that author set. >>>>>> >>>>>> Thanks, >>>>>> Thomas >>>>>> >>>> >> From Alan.Bateman at oracle.com Thu May 9 12:38:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 May 2013 13:38:46 +0100 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: <518B98D6.40303@oracle.com> On 08/05/2013 23:05, Martin Buchholz wrote: > Alan (et al): Ping. > I've looked through the webrev. The scary part is subsequenceRaw where the offsets including the position. I don't see anything obviously wrong and the tests should catch any issues. I don't see any issue conditionally generating the isDirect/order methods although it should been harmless. Mike - as this is an API change, are you going to looking after the paperwork? -Alan. From peter.levart at gmail.com Thu May 9 14:19:55 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 16:19:55 +0200 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518A8B92.8010509@oracle.com> References: <518A8B92.8010509@oracle.com> Message-ID: <518BB08B.8050909@gmail.com> Hi Aleksey, Wouldn't it be even better if just threadLocalRandom* fields were annotated with @Contended("ThreadLocal") ? Some fields within the Thread object are accessed from non-local threads. I don't know how frequently, but isolating just threadLocalRandom* fields from all possible false-sharing scenarios would seem even better, no? Regards, Peter On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: > Hi, > > This is from our backlog after JDK-8005926. After ThreadLocalRandom > state was merged into Thread, we now have to deal with the false sharing > induced by heavily-updated fields in Thread. TLR was padded before, and > it should make sense to make Thread bear @Contended annotation to > isolate its fields in the same manner. > > The webrev is here: > http://cr.openjdk.java.net/~shade/8014233/webrev.00/ > > Testing: > - microbenchmarks (see below) > - JPRT cycle against jdk8-tl > > The extended rationale for the change follows. > > If we look at the current Thread layout, we can see the TLR state is > buried within the Thread instance. TLR state are by far the mostly > updated fields in Thread now: > >> Running 64-bit HotSpot VM. >> Using compressed references with 3-bit shift. >> Objects are 8 bytes aligned. >> >> java.lang.Thread >> offset size type description >> 0 12 (assumed to be the object header + first field alignment) >> 12 4 int Thread.priority >> 16 8 long Thread.eetop >> 24 8 long Thread.stackSize >> 32 8 long Thread.nativeParkEventPointer >> 40 8 long Thread.tid >> 48 8 long Thread.threadLocalRandomSeed >> 56 4 int Thread.threadStatus >> 60 4 int Thread.threadLocalRandomProbe >> 64 4 int Thread.threadLocalRandomSecondarySeed >> 68 1 boolean Thread.single_step >> 69 1 boolean Thread.daemon >> 70 1 boolean Thread.stillborn >> 71 1 (alignment/padding gap) >> 72 4 char[] Thread.name >> 76 4 Thread Thread.threadQ >> 80 4 Runnable Thread.target >> 84 4 ThreadGroup Thread.group >> 88 4 ClassLoader Thread.contextClassLoader >> 92 4 AccessControlContext Thread.inheritedAccessControlContext >> 96 4 ThreadLocalMap Thread.threadLocals >> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >> 104 4 Object Thread.parkBlocker >> 108 4 Interruptible Thread.blocker >> 112 4 Object Thread.blockerLock >> 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >> 120 (object boundary, size estimate) >> VM reports 120 bytes per instance > > Assuming current x86 hardware with 64-byte cache line sizes and current > class layout, we can see the trailing fields in Thread are providing > enough insulation from the false sharing with an adjacent object. Also, > the Thread itself is large enough so that two TLRs belonging to > different threads will not collide. > > However the leading fields are not enough: we have a few words which can > occupy the same cache line, but belong to another object. This is where > things can get worse in two ways: a) the TLR update can make the field > access in adjacent object considerably slower; and much worse b) the > update in the adjacent field can disturb the TLR state, which is > critical for j.u.concurrent performance relying heavily on fast TLR. > > To illustrate both points, there is a simple benchmark driven by JMH > (http://openjdk.java.net/projects/code-tools/jmh/): > http://cr.openjdk.java.net/~shade/8014233/threadbench.zip > > On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and > Thread with/without @Contended that microbenchmark yields the following > results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: > > Accessing ThreadLocalRandom.current().nextInt(): > baseline: 932 +- 4 ops/usec > @Contended: 927 +- 10 ops/usec > > Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): > baseline: 454 +- 2 ops/usec > @Contended: 490 +- 3 ops/usec > > One might note the $uncaughtExceptionHandler is the trailing field in > the Thread, so it can naturally be false-shared with the adjacent > thread's TLR. We had chosen this as the illustration, in real examples > with multitude objects on the heap, we can get another contender. > > So that is ~10% performance hit on false sharing even on very small > machine. Translating it back: having heavily-updated field in the object > adjacent to Thread can bring these overheads to TLR, and then jeopardize > j.u.c performance. > > Of course, as soon as status quo about field layout is changed, we might > start to lose spectacularly. I would recommend we deal with this now, so > less surprises come in the future. > > The caveat is that we are wasting some of the space per Thread instance. > After the patch, we layout is: > >> java.lang.Thread >> offset size type description >> 0 12 (assumed to be the object header + first field alignment) >> 12 128 (alignment/padding gap) >> 140 4 int Thread.priority >> 144 8 long Thread.eetop >> 152 8 long Thread.stackSize >> 160 8 long Thread.nativeParkEventPointer >> 168 8 long Thread.tid >> 176 8 long Thread.threadLocalRandomSeed >> 184 4 int Thread.threadStatus >> 188 4 int Thread.threadLocalRandomProbe >> 192 4 int Thread.threadLocalRandomSecondarySeed >> 196 1 boolean Thread.single_step >> 197 1 boolean Thread.daemon >> 198 1 boolean Thread.stillborn >> 199 1 (alignment/padding gap) >> 200 4 char[] Thread.name >> 204 4 Thread Thread.threadQ >> 208 4 Runnable Thread.target >> 212 4 ThreadGroup Thread.group >> 216 4 ClassLoader Thread.contextClassLoader >> 220 4 AccessControlContext Thread.inheritedAccessControlContext >> 224 4 ThreadLocalMap Thread.threadLocals >> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >> 232 4 Object Thread.parkBlocker >> 236 4 Interruptible Thread.blocker >> 240 4 Object Thread.blockerLock >> 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >> 248 (object boundary, size estimate) >> VM reports 376 bytes per instance > ...and we have additional 256 bytes per Thread (twice the > -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the > space wasted in native memory for each thread, especially stack areas. > > Thanks, > Aleksey. From bourges.laurent at gmail.com Thu May 9 14:59:43 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 9 May 2013 16:59:43 +0200 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518BB08B.8050909@gmail.com> References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> Message-ID: Hi all, A stupid question: any ThreadLocal subclass should be marked @Contended to be sure that false sharing never happens between ThreadLocal instance and any other object on the heap ? Laurent 2013/5/9 Peter Levart > Hi Aleksey, > > Wouldn't it be even better if just threadLocalRandom* fields were > annotated with @Contended("ThreadLocal") ? > Some fields within the Thread object are accessed from non-local threads. > I don't know how frequently, but isolating just threadLocalRandom* fields > from all possible false-sharing scenarios would seem even better, no? > > Regards, Peter > > > On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: > >> Hi, >> >> This is from our backlog after JDK-8005926. After ThreadLocalRandom >> state was merged into Thread, we now have to deal with the false sharing >> induced by heavily-updated fields in Thread. TLR was padded before, and >> it should make sense to make Thread bear @Contended annotation to >> isolate its fields in the same manner. >> >> The webrev is here: >> http://cr.openjdk.java.net/~**shade/8014233/webrev.00/ >> >> Testing: >> - microbenchmarks (see below) >> - JPRT cycle against jdk8-tl >> >> The extended rationale for the change follows. >> >> If we look at the current Thread layout, we can see the TLR state is >> buried within the Thread instance. TLR state are by far the mostly >> updated fields in Thread now: >> >> Running 64-bit HotSpot VM. >>> Using compressed references with 3-bit shift. >>> Objects are 8 bytes aligned. >>> >>> java.lang.Thread >>> offset size type description >>> 0 12 (assumed to be the object >>> header + first field alignment) >>> 12 4 int Thread.priority >>> 16 8 long Thread.eetop >>> 24 8 long Thread.stackSize >>> 32 8 long Thread.nativeParkEventPointer >>> 40 8 long Thread.tid >>> 48 8 long Thread.threadLocalRandomSeed >>> 56 4 int Thread.threadStatus >>> 60 4 int Thread.threadLocalRandomProbe >>> 64 4 int Thread.** >>> threadLocalRandomSecondarySeed >>> 68 1 boolean Thread.single_step >>> 69 1 boolean Thread.daemon >>> 70 1 boolean Thread.stillborn >>> 71 1 (alignment/padding gap) >>> 72 4 char[] Thread.name >>> 76 4 Thread Thread.threadQ >>> 80 4 Runnable Thread.target >>> 84 4 ThreadGroup Thread.group >>> 88 4 ClassLoader Thread.contextClassLoader >>> 92 4 AccessControlContext Thread.** >>> inheritedAccessControlContext >>> 96 4 ThreadLocalMap Thread.threadLocals >>> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >>> 104 4 Object Thread.parkBlocker >>> 108 4 Interruptible Thread.blocker >>> 112 4 Object Thread.blockerLock >>> 116 4 UncaughtExceptionHandler Thread.** >>> uncaughtExceptionHandler >>> 120 (object boundary, size estimate) >>> VM reports 120 bytes per instance >>> >> >> Assuming current x86 hardware with 64-byte cache line sizes and current >> class layout, we can see the trailing fields in Thread are providing >> enough insulation from the false sharing with an adjacent object. Also, >> the Thread itself is large enough so that two TLRs belonging to >> different threads will not collide. >> >> However the leading fields are not enough: we have a few words which can >> occupy the same cache line, but belong to another object. This is where >> things can get worse in two ways: a) the TLR update can make the field >> access in adjacent object considerably slower; and much worse b) the >> update in the adjacent field can disturb the TLR state, which is >> critical for j.u.concurrent performance relying heavily on fast TLR. >> >> To illustrate both points, there is a simple benchmark driven by JMH >> (http://openjdk.java.net/**projects/code-tools/jmh/ >> ): >> http://cr.openjdk.java.net/~**shade/8014233/threadbench.zip >> >> On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and >> Thread with/without @Contended that microbenchmark yields the following >> results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: >> >> Accessing ThreadLocalRandom.current().**nextInt(): >> baseline: 932 +- 4 ops/usec >> @Contended: 927 +- 10 ops/usec >> >> Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): >> baseline: 454 +- 2 ops/usec >> @Contended: 490 +- 3 ops/usec >> >> One might note the $uncaughtExceptionHandler is the trailing field in >> the Thread, so it can naturally be false-shared with the adjacent >> thread's TLR. We had chosen this as the illustration, in real examples >> with multitude objects on the heap, we can get another contender. >> >> So that is ~10% performance hit on false sharing even on very small >> machine. Translating it back: having heavily-updated field in the object >> adjacent to Thread can bring these overheads to TLR, and then jeopardize >> j.u.c performance. >> >> Of course, as soon as status quo about field layout is changed, we might >> start to lose spectacularly. I would recommend we deal with this now, so >> less surprises come in the future. >> >> The caveat is that we are wasting some of the space per Thread instance. >> After the patch, we layout is: >> >> java.lang.Thread >>> offset size type description >>> 0 12 (assumed to be the object header >>> + first field alignment) >>> 12 128 (alignment/padding gap) >>> 140 4 int Thread.priority >>> 144 8 long Thread.eetop >>> 152 8 long Thread.stackSize >>> 160 8 long Thread.nativeParkEventPointer >>> 168 8 long Thread.tid >>> 176 8 long Thread.threadLocalRandomSeed >>> 184 4 int Thread.threadStatus >>> 188 4 int Thread.threadLocalRandomProbe >>> 192 4 int Thread.** >>> threadLocalRandomSecondarySeed >>> 196 1 boolean Thread.single_step >>> 197 1 boolean Thread.daemon >>> 198 1 boolean Thread.stillborn >>> 199 1 (alignment/padding gap) >>> 200 4 char[] Thread.name >>> 204 4 Thread Thread.threadQ >>> 208 4 Runnable Thread.target >>> 212 4 ThreadGroup Thread.group >>> 216 4 ClassLoader Thread.contextClassLoader >>> 220 4 AccessControlContext Thread.** >>> inheritedAccessControlContext >>> 224 4 ThreadLocalMap Thread.threadLocals >>> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >>> 232 4 Object Thread.parkBlocker >>> 236 4 Interruptible Thread.blocker >>> 240 4 Object Thread.blockerLock >>> 244 4 UncaughtExceptionHandler Thread.** >>> uncaughtExceptionHandler >>> 248 (object boundary, size estimate) >>> VM reports 376 bytes per instance >>> >> ...and we have additional 256 bytes per Thread (twice the >> -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the >> space wasted in native memory for each thread, especially stack areas. >> >> Thanks, >> Aleksey. >> > > From Mike.Duigou at oracle.com Thu May 9 15:01:39 2013 From: Mike.Duigou at oracle.com (Mike Duigou) Date: Thu, 9 May 2013 08:01:39 -0700 Subject: Add getChars to CharSequence In-Reply-To: <518B98D6.40303@oracle.com> References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> <518B98D6.40303@oracle.com> Message-ID: <4FA54F59-A258-49D9-9BCD-57F0A1426948@oracle.com> On May 9 2013, at 05:38 , Alan Bateman wrote: > On 08/05/2013 23:05, Martin Buchholz wrote: >> Alan (et al): Ping. >> > I've looked through the webrev. > > The scary part is subsequenceRaw where the offsets including the position. I don't see anything obviously wrong and the tests should catch any issues. I don't see any issue conditionally generating the isDirect/order methods although it should been harmless. > > Mike - as this is an API change, are you going to looking after the paperwork? Yes, I can do that. Since the proposed API is the part that's most complete I think we can proceed with that. Mike From kumar.x.srinivasan at oracle.com Thu May 9 15:10:16 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 09 May 2013 15:10:16 +0000 Subject: hg: jdk8/tl/jdk: 8013736: [launcher] cleanup code for correctness; ... Message-ID: <20130509151028.762904892B@hg.openjdk.java.net> Changeset: 3fd83f282c61 Author: ksrini Date: 2013-05-07 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fd83f282c61 8013736: [launcher] cleanup code for correctness 8005735: [parfait] False positive integer overflow in jdk/src/solaris/bin/jexec.c 8009873: [parfait] Memory leak at jdk/src/share/bin/wildcard.c 8005807: [parfait] Undefined return value at jdk/src/share/bin/java.c Reviewed-by: alanb, martin ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/wildcard.c ! src/solaris/bin/jexec.c From mandy.chung at oracle.com Thu May 9 17:38:25 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 09 May 2013 10:38:25 -0700 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument In-Reply-To: <518B73BB.2050606@oracle.com> References: <518AEA1D.5030402@oracle.com> <518B73BB.2050606@oracle.com> Message-ID: <518BDF11.5000404@oracle.com> On 5/9/13 3:00 AM, Alan Bateman wrote: > On 09/05/2013 01:13, Mandy Chung wrote: >> Please review the simple change for: >> JDK-4487672 (proxy) Proxy constructor should check for null argument >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/ > It looks okay to me although technically an incompatible change. I > guess it will at least have the NPE caught earlier that it would if > the handler were actually used. > Yes it is technically an incompatible change. Existing code that constructs a dynamic proxy instance with null argument doesn't get NPE but instead NPE will bethrown at a later time when a method of the proxy instance is invoked. It's expected that such usage should be very rare as such proxy instance has no use at all. thanks Mandy From brian.burkhalter at oracle.com Thu May 9 17:44:59 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 May 2013 10:44:59 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <518B4C32.7010106@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> Message-ID: On May 9, 2013, at 12:11 AM, Alan Eliasen wrote: >> Phase 1: Faster multiplication and exponentiation of large integers >> Phase 2: Faster string conversion of large integers >> Phase 3: Faster division of large integers >> Phase 4: Faster multiplication and division of very large integers > > Okay, I've created a set of patches that implement these 4 phases. > (They're not actually patches, but the entire source file for each > phase, as Brian requested.) > > These are available at: > http://futureboy.us/temp/BigIntegerPatch.zip Excellent! Thank you very much for this assistance. > In this zipfile, the file(s) to use for each phase are marked with > the ".phaseX" suffix. [?] For your reference, the final versions of each file are contained > with the ".final" suffix. > > Let me know if you have any issues with these. Certainly. > Tim and Brian, you might decide amongst yourselves who wants to file > the issues for phases 3 and 4. I don't know if Brian has any magical > powers to make the issues skip the QA process. Indeed if I file them it will streamline things. I will compose a draft summary and description for each of these issues and post it before filing so that if anyone has anything to add it may be done in one step for each. Thanks, Brian From peter.levart at gmail.com Thu May 9 17:56:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 09 May 2013 19:56:24 +0200 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> Message-ID: <518BE348.4000107@gmail.com> On 05/09/2013 04:59 PM, Laurent Bourg?s wrote: > Hi all, > > A stupid question: > any ThreadLocal subclass should be marked @Contended to be sure that > false sharing never happens between ThreadLocal instance and any other > object on the heap ? > Hi Laurent, ThreadLocal object is just a key (into a ThreadLocalMap). It's usually not subclassed to add any state but to override initialValue method. ThreadLocal contains a single final field 'threadLocalHashCode', which is read at every call to ThreadLocal.get() (usually by multiple threads). This can contend with a frequent write of a field in some other object, placed into it's proximity, yes, but I don't think we should put @Contended on every class that has frequently read fields. @Contended should be reserved for classes with fields that are frequently written, if I understand the concept correctly. Regards, Peter > Laurent > > 2013/5/9 Peter Levart > > > Hi Aleksey, > > Wouldn't it be even better if just threadLocalRandom* fields were > annotated with @Contended("ThreadLocal") ? > Some fields within the Thread object are accessed from non-local > threads. I don't know how frequently, but isolating just > threadLocalRandom* fields from all possible false-sharing > scenarios would seem even better, no? > > Regards, Peter > > > On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: > > Hi, > > This is from our backlog after JDK-8005926. After > ThreadLocalRandom > state was merged into Thread, we now have to deal with the > false sharing > induced by heavily-updated fields in Thread. TLR was padded > before, and > it should make sense to make Thread bear @Contended annotation to > isolate its fields in the same manner. > > The webrev is here: > http://cr.openjdk.java.net/~shade/8014233/webrev.00/ > > > Testing: > - microbenchmarks (see below) > - JPRT cycle against jdk8-tl > > The extended rationale for the change follows. > > If we look at the current Thread layout, we can see the TLR > state is > buried within the Thread instance. TLR state are by far the mostly > updated fields in Thread now: > > Running 64-bit HotSpot VM. > Using compressed references with 3-bit shift. > Objects are 8 bytes aligned. > > java.lang.Thread > offset size type description > 0 12 (assumed to be > the object header + first field alignment) > 12 4 int Thread.priority > 16 8 long Thread.eetop > 24 8 long Thread.stackSize > 32 8 long > Thread.nativeParkEventPointer > 40 8 long Thread.tid > 48 8 long > Thread.threadLocalRandomSeed > 56 4 int Thread.threadStatus > 60 4 int > Thread.threadLocalRandomProbe > 64 4 int > Thread.threadLocalRandomSecondarySeed > 68 1 boolean Thread.single_step > 69 1 boolean Thread.daemon > 70 1 boolean Thread.stillborn > 71 1 (alignment/padding gap) > 72 4 char[] Thread.name > 76 4 Thread Thread.threadQ > 80 4 Runnable Thread.target > 84 4 ThreadGroup Thread.group > 88 4 ClassLoader > Thread.contextClassLoader > 92 4 AccessControlContext > Thread.inheritedAccessControlContext > 96 4 ThreadLocalMap Thread.threadLocals > 100 4 ThreadLocalMap > Thread.inheritableThreadLocals > 104 4 Object Thread.parkBlocker > 108 4 Interruptible Thread.blocker > 112 4 Object Thread.blockerLock > 116 4 UncaughtExceptionHandler > Thread.uncaughtExceptionHandler > 120 (object boundary, > size estimate) > VM reports 120 bytes per instance > > > Assuming current x86 hardware with 64-byte cache line sizes > and current > class layout, we can see the trailing fields in Thread are > providing > enough insulation from the false sharing with an adjacent > object. Also, > the Thread itself is large enough so that two TLRs belonging to > different threads will not collide. > > However the leading fields are not enough: we have a few words > which can > occupy the same cache line, but belong to another object. This > is where > things can get worse in two ways: a) the TLR update can make > the field > access in adjacent object considerably slower; and much worse > b) the > update in the adjacent field can disturb the TLR state, which is > critical for j.u.concurrent performance relying heavily on > fast TLR. > > To illustrate both points, there is a simple benchmark driven > by JMH > (http://openjdk.java.net/projects/code-tools/jmh/): > http://cr.openjdk.java.net/~shade/8014233/threadbench.zip > > > On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and > Thread with/without @Contended that microbenchmark yields the > following > results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: > > Accessing ThreadLocalRandom.current().nextInt(): > baseline: 932 +- 4 ops/usec > @Contended: 927 +- 10 ops/usec > > Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): > baseline: 454 +- 2 ops/usec > @Contended: 490 +- 3 ops/usec > > One might note the $uncaughtExceptionHandler is the trailing > field in > the Thread, so it can naturally be false-shared with the adjacent > thread's TLR. We had chosen this as the illustration, in real > examples > with multitude objects on the heap, we can get another contender. > > So that is ~10% performance hit on false sharing even on very > small > machine. Translating it back: having heavily-updated field in > the object > adjacent to Thread can bring these overheads to TLR, and then > jeopardize > j.u.c performance. > > Of course, as soon as status quo about field layout is > changed, we might > start to lose spectacularly. I would recommend we deal with > this now, so > less surprises come in the future. > > The caveat is that we are wasting some of the space per Thread > instance. > After the patch, we layout is: > > java.lang.Thread > offset size type description > 0 12 (assumed to be the > object header + first field alignment) > 12 128 (alignment/padding gap) > 140 4 int Thread.priority > 144 8 long Thread.eetop > 152 8 long Thread.stackSize > 160 8 long > Thread.nativeParkEventPointer > 168 8 long Thread.tid > 176 8 long > Thread.threadLocalRandomSeed > 184 4 int Thread.threadStatus > 188 4 int > Thread.threadLocalRandomProbe > 192 4 int > Thread.threadLocalRandomSecondarySeed > 196 1 boolean Thread.single_step > 197 1 boolean Thread.daemon > 198 1 boolean Thread.stillborn > 199 1 (alignment/padding gap) > 200 4 char[] Thread.name > 204 4 Thread Thread.threadQ > 208 4 Runnable Thread.target > 212 4 ThreadGroup Thread.group > 216 4 ClassLoader > Thread.contextClassLoader > 220 4 AccessControlContext > Thread.inheritedAccessControlContext > 224 4 ThreadLocalMap Thread.threadLocals > 228 4 ThreadLocalMap > Thread.inheritableThreadLocals > 232 4 Object Thread.parkBlocker > 236 4 Interruptible Thread.blocker > 240 4 Object Thread.blockerLock > 244 4 UncaughtExceptionHandler > Thread.uncaughtExceptionHandler > 248 (object boundary, > size estimate) > VM reports 376 bytes per instance > > ...and we have additional 256 bytes per Thread (twice the > -XX:ContendedPaddingWidth, actually). Seems irrelevant > comparing to the > space wasted in native memory for each thread, especially > stack areas. > > Thanks, > Aleksey. > > > From mike.duigou at oracle.com Thu May 9 18:16:11 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 9 May 2013 11:16:11 -0700 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument In-Reply-To: <518BDF11.5000404@oracle.com> References: <518AEA1D.5030402@oracle.com> <518B73BB.2050606@oracle.com> <518BDF11.5000404@oracle.com> Message-ID: <27C77837-6370-459D-8F83-684E654CFD15@oracle.com> On May 9 2013, at 10:38 , Mandy Chung wrote: > On 5/9/13 3:00 AM, Alan Bateman wrote: >> On 09/05/2013 01:13, Mandy Chung wrote: >>> Please review the simple change for: >>> JDK-4487672 (proxy) Proxy constructor should check for null argument >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/ >> It looks okay to me although technically an incompatible change. I guess it will at least have the NPE caught earlier that it would if the handler were actually used. >> > > Yes it is technically an incompatible change. > > Existing code that constructs a dynamic proxy instance with null argument doesn't get NPE but instead NPE will bethrown at a later time when a method of the proxy instance is invoked. It's expected that such usage should be very rare as such proxy instance has no use at all. As we found with 5045147 (TreeMap with null first entry), which is similar in terms of how the null treatment changed, there almost certainly will be people's code who barfs when generating the proxy now throws the NPE. I'm not saying don't make the change, but there will probably some repercussions. Mike > thanks > Mandy From mandy.chung at oracle.com Thu May 9 18:50:46 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 09 May 2013 11:50:46 -0700 Subject: Review request for JDK-4487672 (proxy) Proxy constructor should check for null argument In-Reply-To: <27C77837-6370-459D-8F83-684E654CFD15@oracle.com> References: <518AEA1D.5030402@oracle.com> <518B73BB.2050606@oracle.com> <518BDF11.5000404@oracle.com> <27C77837-6370-459D-8F83-684E654CFD15@oracle.com> Message-ID: <518BF006.9020306@oracle.com> On 5/9/13 11:16 AM, Mike Duigou wrote: > As we found with 5045147 (TreeMap with null first entry), which is similar in terms of how the null treatment changed, there almost certainly will be people's code who barfs when generating the proxy now throws the NPE. Thanks for the reference. The proxy case is somewhat different than the TreeMap case. In order to make a proxy usable, it must provide an InvocationHandler as in Proxy.newProxyInstance method. > I'm not saying don't make the change, but there will probably some repercussions. Yes and that'd be the case when one creates a proxy with null InvocationHandler and not use it after all. I expect this is really rare and customer testings on jdk8 EA bits will confirm this. Mandy From jason.uh at oracle.com Thu May 9 19:02:00 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Thu, 09 May 2013 19:02:00 +0000 Subject: hg: jdk8/tl/jdk: 8007699: Move some tests from test/sun/security/provider/certpath/X509CertPath to closed repo Message-ID: <20130509190224.0881348939@hg.openjdk.java.net> Changeset: bb9cdfac1a7d Author: juh Date: 2013-05-09 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb9cdfac1a7d 8007699: Move some tests from test/sun/security/provider/certpath/X509CertPath to closed repo Reviewed-by: mullan - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java From brian.burkhalter at oracle.com Thu May 9 21:02:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 May 2013 14:02:31 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <518B701F.6070906@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <518B701F.6070906@oracle.com> Message-ID: <7C57030C-9D7D-4C83-8B93-73CB2B949231@oracle.com> Hi Max, On May 9, 2013, at 2:45 AM, Weijun Wang wrote: > Out of curiosity (my major was math back in university), I take a look at BigInteger.java.phase1: All useful comments are welcome, for whatever reason! > First you have: > > /** > * The threshold value for using 3-way Toom-Cook multiplication. > * If the number of ints in both mag arrays are greater than this number, > * then Toom-Cook multiplication will be used. This value is found > * experimentally to work well. > */ > private static final int TOOM_COOK_THRESHOLD = 75; > > but then: > > public BigInteger multiply(BigInteger val) { > if (val.signum == 0 || signum == 0) > return ZERO; > > int xlen = mag.length; > int ylen = val.mag.length; > > if ((xlen < KARATSUBA_THRESHOLD) || (ylen < KARATSUBA_THRESHOLD)) > { > .... > } > else > if ((xlen < TOOM_COOK_THRESHOLD) && (ylen < TOOM_COOK_THRESHOLD)) > return multiplyKaratsuba(this, val); > else > return multiplyToomCook3(this, val); > } > > So, is it *both* numbers or *any* of them great than the constant that the Toom-Cook algotithm will be used? Indeed the javadoc and the code appear to be contradictory. If the comments are accurate then one would expect the logic to be if ((xlen < TOOM_COOK_THRESHOLD) || (ylen < TOOM_COOK_THRESHOLD)) return multiplyKaratsuba(this, val); I can understand in the case of Karatsuba versus the base algorithm why one would require both numbers to be below the threshold, but I don't know enough about the Toom-3 algorithm yet to comment on your question. I imagine Alan or Tim might have something more useful to say on this point. Thanks, Brian From mike.duigou at oracle.com Thu May 9 21:18:50 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 09 May 2013 21:18:50 +0000 Subject: hg: jdk8/tl/jdk: 8012646: Pattern.splitAsStream Message-ID: <20130509211915.77F494894C@hg.openjdk.java.net> Changeset: 498ea4c3a4c6 Author: psandoz Date: 2013-05-01 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/498ea4c3a4c6 8012646: Pattern.splitAsStream Reviewed-by: forax, plevart, alanb Contributed-by: Ben Evans , Paul Sandoz ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From henry.jen at oracle.com Thu May 9 21:46:39 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 09 May 2013 14:46:39 -0700 Subject: RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find In-Reply-To: <518B7638.2030902@oracle.com> References: <5187E0AA.405@oracle.com> <518B33DA.4060206@oracle.com> <518B7638.2030902@oracle.com> Message-ID: <518C193F.3060209@oracle.com> On 05/09/2013 03:11 AM, Alan Bateman wrote: > On 09/05/2013 06:27, Henry Jen wrote: >> On 05/08/2013 09:17 PM, Mike Duigou wrote: >>> Looks good to me. >>> >> Thanks, we have a minor update to exclude changes for DirectoryStream. >> >> http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/ >> >> A quick review on the update is really appreciated. >> > Looks good to me. > > Just on the FaultFileSystem used by the tests. A typo in the class > description " A FileSystem help testing". For completeness then .close > should be idempotent. Minor alignment problem in getFileStore. > All updated, thanks. Cheers, Henry > Thanks for fixing the bug in the PassThroughFileSystem, that method must > not be used by the other tests that uses this test file system. > > -Alan > From lana.steuck at oracle.com Thu May 9 23:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:19 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130509232223.5EDBE48971@hg.openjdk.java.net> Changeset: 1f13a798d1b8 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1f13a798d1b8 Added tag jdk8-b88 for changeset 4e3a881ebb1e ! .hgtags Changeset: fe4150590ee5 Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe4150590ee5 Merge From lana.steuck at oracle.com Thu May 9 23:22:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:21 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20130509232222.9079848970@hg.openjdk.java.net> Changeset: 1dfcc874461e Author: omajid Date: 2013-04-29 12:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1dfcc874461e 8013480: fix zero build on arm Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: 7e7582e961ba Author: jwilhelm Date: 2013-04-25 16:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7e7582e961ba 7074926: create Solaris Studio IDE (Netbeans) project for hotspot sources Summary: Project files for hotspot delevopment in Solaris Studio and NetBeans. Also reviewed by vladimir.voskresensky at oracle.com Reviewed-by: erikj, dsamersoff + common/nb_native/nbproject/configurations.xml + common/nb_native/nbproject/project.xml Changeset: b9bf111a9547 Author: katleman Date: 2013-04-30 14:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b9bf111a9547 Merge Changeset: e404d321abc6 Author: erikj Date: 2013-05-02 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e404d321abc6 8013786: JDK-8013480 broke configure on solaris Reviewed-by: tbell ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/toolchain.m4 Changeset: e1a929afcfc4 Author: erikj Date: 2013-05-02 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e1a929afcfc4 8011687: Support correct dependencies from header files on windows and solaris Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/makefiles/NativeCompilation.gmk Changeset: 8fb91165e596 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8fb91165e596 Added tag jdk8-b88 for changeset e1a929afcfc4 ! .hgtags Changeset: 892a0196d10c Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/892a0196d10c Merge ! common/makefiles/NativeCompilation.gmk Changeset: 49ea9293fa49 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/49ea9293fa49 Merge From lana.steuck at oracle.com Thu May 9 23:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:19 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b88 for changeset 24fa5452e5d4 Message-ID: <20130509232229.8D32B48972@hg.openjdk.java.net> Changeset: 88838e08e4ef Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88838e08e4ef Added tag jdk8-b88 for changeset 24fa5452e5d4 ! .hgtags From lana.steuck at oracle.com Thu May 9 23:22:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:23 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130509232240.7620248974@hg.openjdk.java.net> Changeset: 21f75e572cb3 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/21f75e572cb3 Added tag jdk8-b88 for changeset 7122f7bb0fcc ! .hgtags Changeset: 893d2ba8bbea Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/893d2ba8bbea Merge Changeset: 6976616f5753 Author: lana Date: 2013-05-08 22:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6976616f5753 Merge Changeset: 9e4dfe933ba9 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9e4dfe933ba9 Merge From lana.steuck at oracle.com Thu May 9 23:22:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:27 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130509232230.915E148973@hg.openjdk.java.net> Changeset: 501bc4aeb1b1 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/501bc4aeb1b1 Added tag jdk8-b88 for changeset 40c107d1ae6f ! .hgtags Changeset: 45ce27fbe272 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/45ce27fbe272 Merge - src/jdk/nashorn/internal/codegen/Frame.java - src/jdk/nashorn/internal/ir/DoWhileNode.java - src/jdk/nashorn/internal/ir/LabeledNode.java From lana.steuck at oracle.com Thu May 9 23:22:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:22:27 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130509232242.33B1148975@hg.openjdk.java.net> Changeset: adec2a5d510a Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/adec2a5d510a Added tag jdk8-b88 for changeset a1e10f3adc47 ! .hgtags Changeset: ec434cfd2752 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec434cfd2752 Merge - make/Makefile-classic Changeset: c68834236058 Author: lana Date: 2013-05-08 23:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c68834236058 Merge From xueming.shen at oracle.com Thu May 9 23:24:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 09 May 2013 16:24:57 -0700 Subject: RFR JDK-8013386: (tz) Support tzdata2013c In-Reply-To: <518B6705.3050203@oracle.com> References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com> Message-ID: <518C3049.5050801@oracle.com> Hi Sean, Thanks for the review. It appears I missed jdk/test/sun/util/calendar/zi/tzdata, webrev has been updated to include the test data update. http://cr.openjdk.java.net/~sherman/8013386/webrev I will update TCKZoneRulesProvider.java separately in JSR310 repo, this def is actually is not being used by anyone anymore, just need to be removed. jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be removed, I will remove it separately later. Masayoshi, The update also included the two changes needed to fix/workaround the following 2 issues found during running the regression test jdk/test/sun/util/calendar/zi/TestZoneInfo310.java, due to the changes for Rule Palestine and the corresponding Zone Asia/Gaza and Asia/Hebron [1]. (1) Now the Rule Palestine has the def of "lastThu 24:00", similar to Asia/Amman, so these two zones need to be handled specially in ZoneInfoFile as well [2] (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 transitions for 2011 when returned from Rule.getRules(int year). Unfortunately it appears the Comparator for Arrays.sorting is incorrectly implemented when comparing two longs [3]. The directly consequence of this decade-old bug is that the returned list has the wrong order for 2011/08/01/xxx and 2011/08/30/xxx Please help review. Thanks! -Sherman [1] http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html [2] http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html [3] http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html On 05/09/2013 02:06 AM, Se?n Coffey wrote: > Thanks for taking care of this Sherman. I was wondering what sort of impact JSR 310 would make on tzdata updates. The Atlantic/Stanley display name issue mentioned is a regular one, we should log a bug against the test file generation scripts. > > I just had a quick grok of the jdk8 repo. The following files need updating also : > > jdk/test/sun/util/calendar/zi/tzdata/* > jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line 85) > jdk/makefiles/GendataTimeZone.gmk (line 29) > > It looks like jdk/makefiles/GendataTimeZone.gmk still has a dependency on reading files from jdk/make. That'll all have to change too once the old build system is removed from jdk8. I think the new tzdata sources should be moved into a directory under makefiles rather than keeping them in make. > > The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in jdk/makefiles/GendataTimeZone.gmk should be removed if we know that the version string can be read from the VERSION file stored with tzdata. > > Above points are not necessarily related to 2013c update and should be cleaned up separately perhaps. > > regards, > Sean. > > On 08/05/2013 23:20, Xueming Shen wrote: >> Hi, >> >> Please help review the proposed change to update the tz data >> in JDK8 from 2012i to 2013c. >> >> Other than the tzdb data file update under make/sun/javazic/tzdata, >> corresponding updates have also been made in TimeZoneNames***.java >> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated >> zone display names (from EET to CET) for Africa/Tripoli (and its alias Libya) >> >> test/java/util/TimeZone/tools/share/Make has been run to generate the >> new test data at TimeZoneData. >> >> # I have to update the displaynames.txt "manually" to undo the change >> for Atlantic/Stanley from "FKST" (which is defined in southamerica.txt both >> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c) >> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the >> definition in TimeZoneNames.java (which has FKT as the standard name and >> FKST as the summer name) does not match the tz data file (which suggests >> that Stanley has moved to use only summer zone), but since this appears >> to be an existing issue that not related to this update, I keep the test data for >> Stanley untouched. >> >> Tests list below have been run and passed. >> >> java/util/TimeZone >> java/util/Calendar >> java/util/Formatter >> java/time >> closed/java/util/TimeZone >> closed/java/util/Calendar >> >> webrev: >> >> http://cr.openjdk.java.net/~sherman/8013386/webrev/ >> http://cr.openjdk.java.net/~sherman/8013386/test.closed/ >> >> Thanks! >> Sherman > From lana.steuck at oracle.com Thu May 9 23:23:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:23:06 +0000 Subject: hg: jdk8/tl/hotspot: 66 new changesets Message-ID: <20130509232912.050B148978@hg.openjdk.java.net> Changeset: d0081bfc425c Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0081bfc425c Added tag jdk8-b88 for changeset 8482058e74bc ! .hgtags Changeset: 57ac6a688ae6 Author: amurillo Date: 2013-04-26 00:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac6a688ae6 8013227: new hotspot build - hs25-b31 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cc70cbbd422e Author: hseigel Date: 2013-04-24 09:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc70cbbd422e 8012695: Assertion message displays %u and %s text instead of actual values Summary: USe err_msg() to create a proper assertion message. Reviewed-by: twisti, coleenp, iklam ! src/share/vm/classfile/classFileParser.hpp Changeset: fbca7eaeac2e Author: zgu Date: 2013-04-24 14:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fbca7eaeac2e 8011218: Kitchensink hanged, likely NMT is to blame Summary: Made NMT query safepoint aware. Reviewed-by: dholmes, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memTracker.cpp Changeset: d587a5c30bd8 Author: coleenp Date: 2013-04-24 16:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d587a5c30bd8 8011803: release_C_heap_structures is never called for anonymous classes. Summary: Call this function from the ClassLoaderData destructor instead of the system dictionary walk. Reviewed-by: stefank, mgerdin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: d66a24adbe3f Author: coleenp Date: 2013-04-24 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d66a24adbe3f Merge Changeset: 15a99ca4ee34 Author: sspitsyn Date: 2013-04-25 03:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15a99ca4ee34 8007037: JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Summary: References from operands to CP entries and back must be correct after CP merge Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: c115fac239eb Author: iklam Date: 2013-04-25 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c115fac239eb 8008962: NPG: Memory regression: One extra Monitor per ConstantPool Summary: Re-use InstanceKlass::_init_lock locking ConstantPool as well. Reviewed-by: dholmes, coleenp, acorn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 3c9b7ef92c61 Author: dcubed Date: 2013-04-26 08:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c9b7ef92c61 Merge Changeset: d1644a010f52 Author: emc Date: 2013-04-26 07:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1644a010f52 8007154: Remove support for u4 MethodParameter flags fields Summary: Remove support for parsing class files with four-byte flags fields in MethodParameters attributes Reviewed-by: jrose, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: f258c5828eb8 Author: hseigel Date: 2013-04-29 16:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f258c5828eb8 8011773: Some tests on Interned String crashed JVM with OOM Summary: Instead of terminating the VM, throw OutOfMemoryError exceptions. Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/whitebox.cpp Changeset: c53e49efe6a8 Author: hseigel Date: 2013-04-29 16:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c53e49efe6a8 Merge Changeset: f32b6c267d2e Author: mikael Date: 2013-04-29 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f32b6c267d2e 8012015: Use PROT_NONE when reserving memory Summary: Reserved memory had PROT_READ+PROT_WRITE access on Linux/bsd, now changed to PROT_NONE. Reviewed-by: dholmes, ctornqvi ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReserveMemory.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 9f96b7a853bc Author: sla Date: 2013-04-30 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f96b7a853bc 8013466: SA crashes when attaching to a process on OS X Reviewed-by: coleenp, rbackman, minqi ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 409d4b59e095 Author: sla Date: 2013-04-30 02:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/409d4b59e095 Merge Changeset: ed5a590835a4 Author: zgu Date: 2013-04-30 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed5a590835a4 8013214: BigApps fails due to 'fatal error: Illegal threadstate encountered: 6' Summary: Grab and drop SR_lock to get the thread to honor the safepoint protocol Reviewed-by: dcubed, coleenp ! src/share/vm/services/memBaseline.cpp Changeset: 746b070f5022 Author: ccheung Date: 2013-04-30 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/746b070f5022 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" Reviewed-by: coleenp, zgu, hseigel ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp Changeset: e4614b063fe1 Author: sla Date: 2013-04-30 21:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4614b063fe1 8013364: SA-JDI exceptions caused by lack of permissions on OSX should be more verbose about issue cause Reviewed-by: coleenp, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 376ff861f611 Author: sla Date: 2013-05-01 01:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/376ff861f611 Merge Changeset: b4081e9714ec Author: vladidan Date: 2013-04-30 17:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4081e9714ec 8013398: Adjust number of stack guard pages on systems with large memory page size Summary: Auto adjust number of stack guard pages on systems with large memory page size Reviewed-by: bobv, coleenp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 1847df492437 Author: vladidan Date: 2013-05-01 10:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1847df492437 Merge Changeset: 08236d966eea Author: bharadwaj Date: 2013-05-01 08:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/08236d966eea 8013418: assert(i == total_args_passed) in AdapterHandlerLibrary::get_adapter since 8-b87 Summary: Do not treat static methods as miranda methods. Reviewed-by: dholmes, acorn ! src/share/vm/oops/klassVtable.cpp + test/runtime/lambda-features/PublicStaticInterfaceMethodHandling.java Changeset: 8fe2542bdc8d Author: bharadwaj Date: 2013-05-01 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8fe2542bdc8d Merge Changeset: a6e09d6dd8e5 Author: dlong Date: 2013-04-24 20:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6e09d6dd8e5 8003853: specify offset of IC load in java_to_interp stub Summary: refactored code to allow platform-specific differences Reviewed-by: dlong, twisti Contributed-by: Goetz Lindenmaier + src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/cpu/zero/vm/compiledIC_zero.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/opto/output.cpp Changeset: e10e43e58e92 Author: dlong Date: 2013-04-24 21:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e10e43e58e92 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/output.cpp - test/gc/6941923/test6941923.sh - test/gc/TestVerifyBeforeGCDuringStartup.java - test/runtime/NMT/AllocTestType.java Changeset: 3c0584fec1e6 Author: dholmes Date: 2013-04-28 18:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c0584fec1e6 8010428: Special -agentpath checks needed with minimal VM to produce proper error message Reviewed-by: dholmes, alanb, cjplummer, olagneau Contributed-by: Carlos Lucasius ! src/share/vm/runtime/arguments.cpp Changeset: 78603aa58b1e Author: jiangli Date: 2013-04-26 16:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78603aa58b1e Merge ! src/cpu/x86/vm/x86_64.ad Changeset: e01e02a9fcb6 Author: jiangli Date: 2013-04-29 01:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e01e02a9fcb6 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 052caeaeb771 Author: jiangli Date: 2013-05-02 12:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/052caeaeb771 Merge Changeset: 8f9fae155577 Author: jiangli Date: 2013-05-02 13:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f9fae155577 Merge Changeset: c23dbf0e8ab7 Author: jmasa Date: 2013-03-01 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c23dbf0e8ab7 8011268: NPG: Free unused VirtualSpaceNodes Reviewed-by: mgerdin, coleenp, johnc ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: bfe3be9ebd6c Author: kevinw Date: 2013-04-18 17:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfe3be9ebd6c 7109087: gc/7072527/TestFullGCCount.java fails when GC is set in command-line Reviewed-by: mgerdin ! test/gc/7072527/TestFullGCCount.java Changeset: 12927badda81 Author: kevinw Date: 2013-04-19 05:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12927badda81 Merge Changeset: d391427ddc29 Author: mgerdin Date: 2013-04-22 10:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d391427ddc29 Merge Changeset: a08c80e9e1e5 Author: stefank Date: 2013-04-22 20:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a08c80e9e1e5 8012687: Remove unused is_root checks and closures Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: ebded0261dfc Author: jmasa Date: 2013-04-22 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ebded0261dfc 8012111: Remove warning about CMS generation shrinking. Reviewed-by: johnc, brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/GuardShrinkWarning.java Changeset: 1cb4795305b9 Author: mgerdin Date: 2013-04-23 08:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb4795305b9 8011802: NPG: init_dependencies in class loader data graph can cause invalid CLD Summary: Restructure initialization of ClassLoaderData to not add a new instance if init_dependencies fail Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp Changeset: 5c93c1f61226 Author: johnc Date: 2013-04-18 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c93c1f61226 8011724: G1: Stack allocate instances of HeapRegionRemSetIterator Summary: Stack allocate instances of HeapRegionRemSetIterator during RSet scanning. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 868d87ed63c8 Author: jmasa Date: 2013-02-12 14:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/868d87ed63c8 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions Reviewed-by: mgerdin, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 9d75bcd7c890 Author: mgerdin Date: 2013-04-24 19:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d75bcd7c890 8013136: NPG: Parallel class loading tests fail after fix for JDK-8011802 Summary: Move initialization of dependencies to before allocation of CLD Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp Changeset: d50cc62e94ff Author: johnc Date: 2013-04-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d50cc62e94ff 8012715: G1: GraphKit accesses PtrQueue::_index as int but is size_t Summary: In graphKit INT operations were generated to access PtrQueue::_index which has type size_t. This is 64 bit on 64-bit machines. No problems occur on little endian machines as long as the index fits into 32 bit, but on big endian machines the upper part is read, which is zero. This leads to unnecessary branches to the slow path in the runtime. Reviewed-by: twisti, johnc Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp Changeset: b06ac540229e Author: stefank Date: 2013-04-24 20:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b06ac540229e 8013132: Add a flag to turn off the output of the verbose verification code Reviewed-by: johnc, brutisso ! 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/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: b294421fa3c5 Author: brutisso Date: 2013-04-26 09:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b294421fa3c5 8012915: ReservedSpace::align_reserved_region() broken on Windows Summary: remove unused constructors and helper methods for ReservedHeapSpace and ReservedSpace Reviewed-by: mgerdin, jmasa, johnc, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 2f50bc369470 Author: stefank Date: 2013-04-26 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f50bc369470 8013160: NPG: Remove unnecessary mark stack draining after CodeCache::do_unloading Reviewed-by: coleenp, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 3edf23423bb2 Author: johnc Date: 2013-04-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3edf23423bb2 8011898: gc/TestVerifyBeforeGCDuringStartup.java: java.lang.RuntimeException: '[Verifying' missing from stdout/stderr: [Error: Could not find or load main class] Summary: System.getProperty("test.java.opts") can return NULL, which gets converted to to the empty string, and the child java command then interprets that as the name of the main class. Reviewed-by: jmasa, brutisso ! test/gc/TestVerifyDuringStartup.java Changeset: caac22686b17 Author: mgerdin Date: 2013-04-29 09:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/caac22686b17 Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/runtime/thread.cpp Changeset: 601183f604b2 Author: mgerdin Date: 2013-04-29 13:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/601183f604b2 8013129: Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking Summary: Change Metaspace::deallocate to take lock with _no_safepoint_check_flag Reviewed-by: coleenp, jmasa, dholmes ! src/share/vm/memory/metaspace.cpp Changeset: 9075044ed66b Author: ehelin Date: 2013-04-30 16:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9075044ed66b 8008541: Remove old code in HotSpot that supported the jmap -permstat functionality Reviewed-by: sla, brutisso ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java Changeset: d58c62b7447d Author: mgerdin Date: 2013-05-02 19:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d58c62b7447d Merge ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: cbd4ce58f1f3 Author: mgerdin Date: 2013-05-02 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbd4ce58f1f3 Merge Changeset: e12c9b3740db Author: vlivanov Date: 2013-04-25 11:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e12c9b3740db 8012260: ciReplay: Include PID into the name of replay data file Reviewed-by: kvn, twisti ! 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/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: dc7db03f5aa2 Author: iignatyev Date: 2013-04-25 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc7db03f5aa2 8012337: Change Whitebox implementation to make absence of method in Whitebox.class not fatal Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp + test/sanity/WhiteBox.java Changeset: 7b23cb975cf2 Author: iignatyev Date: 2013-04-25 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b23cb975cf2 8011675: adding compilation level to replay data Reviewed-by: kvn, vlivanov - agent/doc/c2replay.html + agent/doc/cireplay.html ! agent/doc/clhsdb.html ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/ciReplay/TestSA.sh + test/compiler/ciReplay/TestVM.sh + test/compiler/ciReplay/TestVM_no_comp_level.sh + test/compiler/ciReplay/common.sh Changeset: 247342108a11 Author: neliasso Date: 2013-04-23 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/247342108a11 8010332: removed unused method: ciMethod::uses_monitors Reviewed-by: twisti, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/ci/ciMethod.hpp Changeset: a5c95fcf7cb7 Author: neliasso Date: 2013-04-23 18:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5c95fcf7cb7 8012157: removed unused code in SharedRuntime::handle_wrong_method Reviewed-by: kvn, roland, rbackman Contributed-by: albert.noll at oracle.com ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d1c9384eecb4 Author: iignatyev Date: 2013-04-26 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1c9384eecb4 8012322: Tiered: CompilationPolicy::can_be_compiled(CompLevel_all) mistakenly return false Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: 93b8272814cf Author: vlivanov Date: 2013-04-26 08:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93b8272814cf Merge Changeset: 0b55a78c6be5 Author: bharadwaj Date: 2013-04-26 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b55a78c6be5 Merge - agent/doc/c2replay.html ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fd49109d0d88 Author: bharadwaj Date: 2013-04-26 14:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd49109d0d88 Merge Changeset: 487d442ef257 Author: jiangli Date: 2013-04-26 16:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/487d442ef257 8013036: vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL). Summary: Change the assert to if check as MethodCounters could be NULL under TieredCompilation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 62b683108582 Author: jiangli Date: 2013-04-26 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62b683108582 Merge Changeset: 0cfa93c2fcc4 Author: neliasso Date: 2013-04-29 13:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cfa93c2fcc4 8012547: Code cache flushing can get stuck reclaming of memory Summary: Keep sweeping regardless of if we are flushing Reviewed-by: kvn, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: e4e131b15d5c Author: roland Date: 2013-05-02 10:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4e131b15d5c 8013532: Remove unused parameter "compiler" from DTRACE_METHOD_COMPILE* macros Summary: remove unused parameter in dtrace macros Reviewed-by: kvn, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/compiler/compileBroker.cpp Changeset: 9ce110b1d14a Author: kvn Date: 2013-05-02 18:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ce110b1d14a Merge - agent/doc/c2replay.html ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 4ec913499722 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ec913499722 Merge - agent/doc/c2replay.html Changeset: 9c1fe0b419b4 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c1fe0b419b4 Added tag hs25-b31 for changeset 4ec913499722 ! .hgtags From lana.steuck at oracle.com Thu May 9 23:26:02 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 09 May 2013 23:26:02 +0000 Subject: hg: jdk8/tl/jdk: 30 new changesets Message-ID: <20130509233415.263C54897B@hg.openjdk.java.net> Changeset: 78d08fc2dd12 Author: mullan Date: 2013-04-25 11:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78d08fc2dd12 8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not defined Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 3e282678a885 Author: mullan Date: 2013-04-25 15:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e282678a885 8013228: Create new system properties to control allowable OCSP clock skew and CRL connection timeout Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java Changeset: 7c4eb715c5e8 Author: ngthomas Date: 2013-04-30 21:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c4eb715c5e8 Merge Changeset: 12af7c32c648 Author: omajid Date: 2013-04-29 12:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12af7c32c648 8013480: fix zero build on arm Reviewed-by: erikj ! makefiles/GensrcX11Wrappers.gmk Changeset: 7a96ead5ea89 Author: katleman Date: 2013-04-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a96ead5ea89 Merge Changeset: 55c7b90fe57e Author: katleman Date: 2013-05-01 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55c7b90fe57e Merge Changeset: 8dbb4b159e04 Author: erikj Date: 2013-05-02 15:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8dbb4b159e04 8013552: Add build support for different man pages for OpenJDK and OracleJDK Reviewed-by: tbell, omajid ! makefiles/Images.gmk Changeset: 1daef88acff2 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1daef88acff2 Added tag jdk8-b88 for changeset 8dbb4b159e04 ! .hgtags Changeset: b0c41789f500 Author: jgodinez Date: 2013-04-25 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0c41789f500 8009199: Printed text become garbage on Mac OSX Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: f4aa34a7a44d Author: jchen Date: 2013-04-29 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4aa34a7a44d 8005302: [findbugs] public methods return internal arrays; may be private Reviewed-by: bae, prr ! src/share/classes/sun/java2d/pipe/AAShapePipe.java Changeset: 46686202aa23 Author: lana Date: 2013-04-30 22:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46686202aa23 Merge Changeset: c70346f4c0a9 Author: pchelko Date: 2013-04-18 15:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c70346f4c0a9 8011686: AWT accidentally disables the NSApplicationDelegate of SWT, causing loss of OS X integration functionality Reviewed-by: anthony, serb Contributed-by: Markus Persson ! src/macosx/native/sun/awt/awt.m Changeset: ac92ac05dde4 Author: kshefov Date: 2013-04-22 18:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac92ac05dde4 8011230: [TEST_BUG] java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java failed on solaris Reviewed-by: serb, anthony ! test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 578fb8766200 Author: leonidr Date: 2013-04-22 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/578fb8766200 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 0894b8476a49 Author: lana Date: 2013-04-23 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0894b8476a49 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 - src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM - src/share/native/java/lang/ResourceBundle.c - 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: 7103434eefe2 Author: kshefov Date: 2013-04-24 11:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7103434eefe2 8011186: [TEST_BUG] java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java failed on windows 8 Reviewed-by: anthony, serb, ant - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java + test/java/awt/Focus/SimpleWindowActivationTest/SimpleWindowActivationTest.java Changeset: 854f60ec4bfb Author: anthony Date: 2013-04-26 18:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/854f60ec4bfb 8012586: [x11] Modal dialogs for fullscreen window may show behind its owner Summary: Use the _NET_WM_WINDOW_TYPE_DIALOG type for owned windows Reviewed-by: anthony, art, serb Contributed-by: Vladimir Kravets ! src/solaris/classes/sun/awt/X11/XWindowPeer.java + test/java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java Changeset: e76f3e8e653f Author: malenkov Date: 2013-04-29 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76f3e8e653f 8007458: [findbugs] One more beans issue, with ReflectionUtils Reviewed-by: art, alexsch ! src/share/classes/java/beans/MetaData.java - src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLEncoder.java ! test/java/beans/XMLEncoder/AbstractTest.java ! test/java/beans/XMLEncoder/BeanValidator.java ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4679556.java ! test/java/beans/XMLEncoder/java_awt_BorderLayout.java + test/java/beans/XMLEncoder/java_awt_CardLayout.java + test/java/beans/XMLEncoder/java_awt_GridBagLayout.java ! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java Changeset: 358acb00cb2d Author: mcherkas Date: 2013-04-30 13:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/358acb00cb2d 8012004: JInternalFrame not being finalized after closing Reviewed-by: alexsch, alexp ! src/share/classes/javax/swing/JDesktopPane.java + test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: 31e111f82993 Author: serb Date: 2013-04-30 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31e111f82993 7166296: closed/java/awt/Frame/DisabledParentOfToplevel/DisabledParentOfToplevel.html failed since 1.8.0b36 Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: caeedce39396 Author: serb Date: 2013-05-01 12:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/caeedce39396 8009012: [macosx] DisplayChangedListener is not implemented in LWWindowPeer/CGraphicsEnvironment Reviewed-by: anthony, bae ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/CGraphicsEnv.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: c357c11f076f Author: lana Date: 2013-05-01 09:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c357c11f076f Merge Changeset: 920ad6c95d93 Author: lana Date: 2013-05-01 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/920ad6c95d93 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: f6f2802f980c Author: lana Date: 2013-05-01 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6f2802f980c Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 336a110f1196 Author: lana Date: 2013-05-06 11:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336a110f1196 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 88125d32eb06 Author: andrew Date: 2013-05-04 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88125d32eb06 8011366: Enable debug info on all libraries for OpenJDK builds Summary: The build should not be turning off debugging if it has been requested. Reviewed-by: erikj, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: 7ba77fff0ef6 Author: katleman Date: 2013-05-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ba77fff0ef6 Merge Changeset: 845025546e35 Author: katleman Date: 2013-05-07 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/845025546e35 Merge Changeset: 573a593379cb Author: lana Date: 2013-05-08 23:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/573a593379cb Merge ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 2023e3d573eb Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2023e3d573eb Merge - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java From mike.duigou at oracle.com Thu May 9 23:50:54 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 9 May 2013 16:50:54 -0700 Subject: RFR: 8014316 : (XXS) Use Method Refs in j.u.stream.MatchOps Message-ID: <43666510-18BF-47BB-8002-AD0E99B9A22C@oracle.com> Hello all; This is a small review to clean up a non-longer-need workaround. http://cr.openjdk.java.net/~mduigou/JDK-8014316/0/webrev/ Thanks From brian.burkhalter at oracle.com Fri May 10 00:28:41 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 May 2013 17:28:41 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> Message-ID: <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> On May 9, 2013, at 10:44 AM, Brian Burkhalter wrote: >> Tim and Brian, you might decide amongst yourselves who wants to file >> the issues for phases 3 and 4. I don't know if Brian has any magical >> powers to make the issues skip the QA process. > > Indeed if I file them it will streamline things. I will compose a draft summary and description for each of these issues and post it before filing so that if anyone has anything to add it may be done in one step for each. I just went ahead and filed 8014319 and 8014320 for phases 3 and 4, respectively. They will show up on http://bugs.sun.com/bugdatabase after some unspecified delay, probably about a day. Verbiage may be updated as needed. Brian From david.holmes at oracle.com Fri May 10 03:20:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 13:20:25 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518B92F6.6030105@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> Message-ID: <518C6779.5060802@oracle.com> On 9/05/2013 10:13 PM, Peter Levart wrote: > On 05/09/2013 01:33 PM, David Holmes wrote: >> On 9/05/2013 9:16 PM, Peter Levart wrote: >>> Hi David, >>> >>> On 05/09/2013 12:02 PM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> Thanks for clarifying the test details. A few follow ups: >>>> >>>> - The reference class does get initialized early in the VM startup >>>> well before Main will be loaded. But the use of the weakref doesn't >>>> hurt. >>> >>> Ok, so if this is guaranteed, we can remove the weakref construction. >>> >>>> >>>> - 500ms may not be enough on some platforms, particularly some >>>> embedded systems. Ideally we could code up a handshake using another >>>> weakref that would guarantee that the handler thread really survived >>>> past the OOM. But at some point this just becomes a no-reg-hard >>>> situation :) >>> >>> If we used a weakref then there should be a delay between the >>> referenceHandlerThread.interrupt() and the release of the >>> WeakReference's referent, otherwise the WeakReference could be cleared >>> and enqueued before Reference Handler attempts to throw >>> InterruptedException (this really happens - I tried without delay and >>> the clearing/enqueueing was quicker than interrupt). After this initial >>> delay (currently set to 500ms) releasing the referent and waiting for >>> WeakReference to be enqueued (while executing System.gc()) is analogous >>> to testing for referenceHandlerThread.isAlive() - the only difference >>> being the code that has to be executed in Reference Handler while >>> unwinding the stack until the state of thread changes to TERMINATED. Can >>> this be delayed for a long time? >> >> What I was thinking was that after we interrupt we then create a new >> weakref > > Can't do that immediately (no space)! > >> and we loop until the ref gets cleared, or we detect the reference >> thread is not alive (with a sleep in between). One of those two >> conditions must become true. > > To create a weakref after interrupt, we have to 1st wait some time (to > give Reference Handler thread a chance to throw OOME), then free the > heap (release 'waste' and possibly do some System.gc()) to get some > space for weakref creation. After we do that, a chance that Reference > Handler thread is just in the process of unwinding the stack after > uncaught OOME and referenceHandlerThread.isAlive() still returns true is > minimal. Do you think we should wait some more to be sure thread is > still alive? "create a new weakref" was the wrong thing to say. We should already have the weakref and then clear the string ref (wrapped by the weakref) and wait for the weakref to be cleared (or not) - which would require looping with system.gc() call. >> >>>> >>>> - I'm not certain that setting waste=null is sufficient to guarantee >>>> the next allocation will succeed under all GC's. GC folk can >>>> confim/deny that. >>> >>> We can pre-allocate the test-fail exception before doing fillHeap() so >>> that we can conditionally throw it later, like this: >> >> So when we do the throw there is logic in the launcher that will try >> to print the stacktrace, which may also encounter OOME unless we have >> freed the heap. So I think we want to release memory, I just wasn't >> certain that simply setting waste=null would guarantee it. > > 'waste' is local variable and goes out of scope when main() is finished. Good point. But again I'm not certain that once waste is null, or out of scope, that an attempted allocation (eg for stacktrace) will force GC to run, release everything, and have the allocation succeed. This is what I'd like GC folk to confirm/refute. > So in final variation I haven't even bothered to set it to null at the > end. What do you suggest for successful test failure? Setting 'waste' to > null, followed by a System.gc() and Thread.sleep()? Can we signal test > failure in another way? System.exit(1)? The test harness expects exceptions for failures. System.exit is not allowed in general. David ----- > Regards, Peter > >> >> David >> ------ >> >>> public class Test { >>> static Object[] fillHeap() { >>> Object[] first = null, last = null; >>> int size = 1 << 20; >>> while (size > 0) { >>> try { >>> Object[] array = new Object[size]; >>> if (first == null) { >>> first = array; >>> } else { >>> last[0] = array; >>> } >>> last = array; >>> } catch (OutOfMemoryError oome) { >>> size = size >>> 1; >>> } >>> } >>> return first; >>> } >>> >>> public static void main(String[] args) throws Exception { >>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>> for ( >>> ThreadGroup tgn = tg; >>> tgn != null; >>> tg = tgn, tgn = tg.getParent() >>> ) >>> ; >>> >>> Thread[] threads = new Thread[tg.activeCount()]; >>> Thread referenceHandlerThread = null; >>> int n = tg.enumerate(threads); >>> for (int i = 0; i < n; i++) { >>> if ("Reference Handler".equals(threads[i].getName())) { >>> referenceHandlerThread = threads[i]; >>> } >>> } >>> >>> if (referenceHandlerThread == null) { >>> throw new IllegalStateException("Couldn't find Reference >>> Handler thread."); >>> } >>> >>> // pre-allocate failure so that we don't cause OOME later >>> Exception failure = new Exception("Reference Handler thread >>> died."); >>> >>> Object waste = fillHeap(); >>> >>> referenceHandlerThread.interrupt(); >>> >>> // allow referenceHandlerThread some time to throw OOME >>> Thread.sleep(500L); >>> >>> if (waste != null && // keep 'waste' reference alive until this >>> point >>> !referenceHandlerThread.isAlive()// check that the handler >>> is still alive >>> ) { >>> throw failure; >>> } >>> } >>> } >>> >>> >>> >>> Regards, Peter >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/05/2013 6:35 PM, Peter Levart wrote: >>>>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>>>> Hi Thomas, >>>>>> >>>>>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the latest webrev for this patch that is >>>>>>> available at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>>>>> >>>>>>> As mentioned, it incorporates the fix and reproducer from Peter >>>>>>> Levart. >>>>>> >>>>>> Fix is fine. >>>>>> >>>>>> I'm not sure about the test (sorry I didn't pay it attention >>>>>> earlier). >>>>>> Have you instrumented the code to verify that the test actually >>>>>> triggers an OOME? It may be possible that if the OOME did kill the >>>>>> reference thread that we wouldn't necessarily detect it using the >>>>>> sleeps etc. Also I don't understand the need for the actual weakRef >>>>>> usage and System.gc() etc. If the heap is full then the interrupt >>>>>> will >>>>>> wake the reference handler thread and the allocation will trigger the >>>>>> OOME. It doesn't matter if there are any references to process. The >>>>>> main logic might then reduce to: >>>>>> >>>>>> referenceHandlerThread.interrupt(); >>>>>> for (int i = 0; i < 10; i++) { >>>>>> if (!referenceHandlerThread.isAlive()) >>>>>> throw new Exception("Reference-handler thread died"); >>>>>> Thread.sleep(1000); >>>>>> } >>>>>> >>>>>> which just gives it 10s to die else assumes all ok. ? >>>>>> >>>>>> But I can live with existing test (it just might vacuously pass) >>>>>> >>>>>> Cheers, >>>>>> David >>>>> >>>>> Hi David, Thomas, >>>>> >>>>> Yes, this was just a left-over from my bug reproducer that >>>>> demonstrated >>>>> the situation where WeakReference was cleared, but nothing was >>>>> enqueue-d >>>>> into the ReferenceQueue. Reference Handler thread otherwise just >>>>> sleeps >>>>> in lock.wait() most of the time if there's nothing to do and >>>>> interrupting it's thread will trigger allocation of >>>>> InterruptedException >>>>> and consequently OOME nevertheless. >>>>> >>>>> One think to watch: Reference Handler thread is started in the >>>>> j.l.r.Reference static initializer, so the Reference class must be >>>>> initialized. I don't know if there is any guarantee that this is done >>>>> before entering main(). So there should be something explicit in >>>>> main() >>>>> method that ensures it. >>>>> >>>>> Also, throwing test-fail exception should be done after releasing the >>>>> heap or we'll just trigger another OOME without any message to >>>>> describe >>>>> the situation. >>>>> >>>>> Waiting in a loop for ReferenceHandler thread is not needed since the >>>>> test will normally succeed and so the whole loop will execute to the >>>>> end. Only when the test fails the loop will exit faster. In my >>>>> experience, the thread dies between 10-20ms after interrupting, so >>>>> waiting for about 500ms is enough I think. Also no System.gc() and >>>>> additional waiting is needed to report the outcome - just releasing >>>>> the >>>>> reference to 'waste' variable is enuugh in my experience to restore >>>>> the >>>>> heap into working condition. >>>>> >>>>> Here's the updated test that does all that: >>>>> >>>>> >>>>> public class OOMEInReferenceHandler { >>>>> static Object[] fillHeap() { >>>>> Object[] first = null, last = null; >>>>> int size = 1 << 20; >>>>> while (size > 0) { >>>>> try { >>>>> Object[] array = new Object[size]; >>>>> if (first == null) { >>>>> first = array; >>>>> } >>>>> else { >>>>> last[0] = array; >>>>> } >>>>> last = array; >>>>> } >>>>> catch (OutOfMemoryError oome) { >>>>> size = size >>> 1; >>>>> } >>>>> } >>>>> return first; >>>>> } >>>>> >>>>> public static void main(String[] args) throws Exception { >>>>> // ensure ReferenceHandler thread is started >>>>> new WeakReference(new Object()); >>>>> >>>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>>> for (ThreadGroup tgn = tg; >>>>> tgn != null; >>>>> tg = tgn, tgn = tg.getParent()); >>>>> >>>>> Thread[] threads = new Thread[tg.activeCount()]; >>>>> Thread referenceHandlerThread = null; >>>>> int n = tg.enumerate(threads); >>>>> for (int i = 0; i < n; i++) { >>>>> if("Reference Handler".equals(threads[i].getName())) { >>>>> referenceHandlerThread = threads[i]; >>>>> } >>>>> } >>>>> >>>>> if (referenceHandlerThread == null) { >>>>> throw new IllegalStateException("Couldn't find Reference >>>>> Handler thread."); >>>>> } >>>>> >>>>> Object waste = fillHeap(); >>>>> >>>>> referenceHandlerThread.interrupt(); >>>>> >>>>> Thread.sleep(500L); >>>>> >>>>> // release waste so we can allocate and throw normal >>>>> exceptions >>>>> waste = null; >>>>> >>>>> // check that the handler is still alive >>>>> if (!referenceHandlerThread.isAlive()) { >>>>> throw new Exception("Reference Handler thread died."); >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>>> Bugs.sun.com: >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>>>>> >>>>>>> JIRA: >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>>>>> >>>>>>> Testing: >>>>>>> JPRT, with the new reproducer passing >>>>>>> >>>>>>> In need of reviewers and a sponsor for this patch; as mentioned >>>>>>> earlier >>>>>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>>>>> patchset to the sponsor for this change with that author set. >>>>>>> >>>>>>> Thanks, >>>>>>> Thomas >>>>>>> >>>>> >>> > From david.holmes at oracle.com Fri May 10 03:33:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 13:33:35 +1000 Subject: RFR: 8014316 : (XXS) Use Method Refs in j.u.stream.MatchOps In-Reply-To: <43666510-18BF-47BB-8002-AD0E99B9A22C@oracle.com> References: <43666510-18BF-47BB-8002-AD0E99B9A22C@oracle.com> Message-ID: <518C6A8F.5070802@oracle.com> Looks good to me Mike! David On 10/05/2013 9:50 AM, Mike Duigou wrote: > Hello all; > > This is a small review to clean up a non-longer-need workaround. > > http://cr.openjdk.java.net/~mduigou/JDK-8014316/0/webrev/ > > Thanks > From david.holmes at oracle.com Fri May 10 03:34:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 13:34:43 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518C6779.5060802@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> Message-ID: <518C6AD3.2000102@oracle.com> string ref -> strong ref David On 10/05/2013 1:20 PM, David Holmes wrote: > On 9/05/2013 10:13 PM, Peter Levart wrote: >> On 05/09/2013 01:33 PM, David Holmes wrote: >>> On 9/05/2013 9:16 PM, Peter Levart wrote: >>>> Hi David, >>>> >>>> On 05/09/2013 12:02 PM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> Thanks for clarifying the test details. A few follow ups: >>>>> >>>>> - The reference class does get initialized early in the VM startup >>>>> well before Main will be loaded. But the use of the weakref doesn't >>>>> hurt. >>>> >>>> Ok, so if this is guaranteed, we can remove the weakref construction. >>>> >>>>> >>>>> - 500ms may not be enough on some platforms, particularly some >>>>> embedded systems. Ideally we could code up a handshake using another >>>>> weakref that would guarantee that the handler thread really survived >>>>> past the OOM. But at some point this just becomes a no-reg-hard >>>>> situation :) >>>> >>>> If we used a weakref then there should be a delay between the >>>> referenceHandlerThread.interrupt() and the release of the >>>> WeakReference's referent, otherwise the WeakReference could be cleared >>>> and enqueued before Reference Handler attempts to throw >>>> InterruptedException (this really happens - I tried without delay and >>>> the clearing/enqueueing was quicker than interrupt). After this initial >>>> delay (currently set to 500ms) releasing the referent and waiting for >>>> WeakReference to be enqueued (while executing System.gc()) is analogous >>>> to testing for referenceHandlerThread.isAlive() - the only difference >>>> being the code that has to be executed in Reference Handler while >>>> unwinding the stack until the state of thread changes to TERMINATED. >>>> Can >>>> this be delayed for a long time? >>> >>> What I was thinking was that after we interrupt we then create a new >>> weakref >> >> Can't do that immediately (no space)! >> >>> and we loop until the ref gets cleared, or we detect the reference >>> thread is not alive (with a sleep in between). One of those two >>> conditions must become true. >> >> To create a weakref after interrupt, we have to 1st wait some time (to >> give Reference Handler thread a chance to throw OOME), then free the >> heap (release 'waste' and possibly do some System.gc()) to get some >> space for weakref creation. After we do that, a chance that Reference >> Handler thread is just in the process of unwinding the stack after >> uncaught OOME and referenceHandlerThread.isAlive() still returns true is >> minimal. Do you think we should wait some more to be sure thread is >> still alive? > > "create a new weakref" was the wrong thing to say. We should already > have the weakref and then clear the string ref (wrapped by the weakref) > and wait for the weakref to be cleared (or not) - which would require > looping with system.gc() call. > >>> >>>>> >>>>> - I'm not certain that setting waste=null is sufficient to guarantee >>>>> the next allocation will succeed under all GC's. GC folk can >>>>> confim/deny that. >>>> >>>> We can pre-allocate the test-fail exception before doing fillHeap() so >>>> that we can conditionally throw it later, like this: >>> >>> So when we do the throw there is logic in the launcher that will try >>> to print the stacktrace, which may also encounter OOME unless we have >>> freed the heap. So I think we want to release memory, I just wasn't >>> certain that simply setting waste=null would guarantee it. >> >> 'waste' is local variable and goes out of scope when main() is finished. > > Good point. But again I'm not certain that once waste is null, or out of > scope, that an attempted allocation (eg for stacktrace) will force GC to > run, release everything, and have the allocation succeed. This is what > I'd like GC folk to confirm/refute. > >> So in final variation I haven't even bothered to set it to null at the >> end. What do you suggest for successful test failure? Setting 'waste' to >> null, followed by a System.gc() and Thread.sleep()? Can we signal test >> failure in another way? System.exit(1)? > > The test harness expects exceptions for failures. System.exit is not > allowed in general. > > David > ----- > >> Regards, Peter >> >>> >>> David >>> ------ >>> >>>> public class Test { >>>> static Object[] fillHeap() { >>>> Object[] first = null, last = null; >>>> int size = 1 << 20; >>>> while (size > 0) { >>>> try { >>>> Object[] array = new Object[size]; >>>> if (first == null) { >>>> first = array; >>>> } else { >>>> last[0] = array; >>>> } >>>> last = array; >>>> } catch (OutOfMemoryError oome) { >>>> size = size >>> 1; >>>> } >>>> } >>>> return first; >>>> } >>>> >>>> public static void main(String[] args) throws Exception { >>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>> for ( >>>> ThreadGroup tgn = tg; >>>> tgn != null; >>>> tg = tgn, tgn = tg.getParent() >>>> ) >>>> ; >>>> >>>> Thread[] threads = new Thread[tg.activeCount()]; >>>> Thread referenceHandlerThread = null; >>>> int n = tg.enumerate(threads); >>>> for (int i = 0; i < n; i++) { >>>> if ("Reference Handler".equals(threads[i].getName())) { >>>> referenceHandlerThread = threads[i]; >>>> } >>>> } >>>> >>>> if (referenceHandlerThread == null) { >>>> throw new IllegalStateException("Couldn't find Reference >>>> Handler thread."); >>>> } >>>> >>>> // pre-allocate failure so that we don't cause OOME later >>>> Exception failure = new Exception("Reference Handler thread >>>> died."); >>>> >>>> Object waste = fillHeap(); >>>> >>>> referenceHandlerThread.interrupt(); >>>> >>>> // allow referenceHandlerThread some time to throw OOME >>>> Thread.sleep(500L); >>>> >>>> if (waste != null && // keep 'waste' reference alive until >>>> this >>>> point >>>> !referenceHandlerThread.isAlive()// check that the handler >>>> is still alive >>>> ) { >>>> throw failure; >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/05/2013 6:35 PM, Peter Levart wrote: >>>>>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>>>>> Hi Thomas, >>>>>>> >>>>>>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the latest webrev for this patch that is >>>>>>>> available at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>>>>>> >>>>>>>> As mentioned, it incorporates the fix and reproducer from Peter >>>>>>>> Levart. >>>>>>> >>>>>>> Fix is fine. >>>>>>> >>>>>>> I'm not sure about the test (sorry I didn't pay it attention >>>>>>> earlier). >>>>>>> Have you instrumented the code to verify that the test actually >>>>>>> triggers an OOME? It may be possible that if the OOME did kill the >>>>>>> reference thread that we wouldn't necessarily detect it using the >>>>>>> sleeps etc. Also I don't understand the need for the actual weakRef >>>>>>> usage and System.gc() etc. If the heap is full then the interrupt >>>>>>> will >>>>>>> wake the reference handler thread and the allocation will trigger >>>>>>> the >>>>>>> OOME. It doesn't matter if there are any references to process. The >>>>>>> main logic might then reduce to: >>>>>>> >>>>>>> referenceHandlerThread.interrupt(); >>>>>>> for (int i = 0; i < 10; i++) { >>>>>>> if (!referenceHandlerThread.isAlive()) >>>>>>> throw new Exception("Reference-handler thread died"); >>>>>>> Thread.sleep(1000); >>>>>>> } >>>>>>> >>>>>>> which just gives it 10s to die else assumes all ok. ? >>>>>>> >>>>>>> But I can live with existing test (it just might vacuously pass) >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>> >>>>>> Hi David, Thomas, >>>>>> >>>>>> Yes, this was just a left-over from my bug reproducer that >>>>>> demonstrated >>>>>> the situation where WeakReference was cleared, but nothing was >>>>>> enqueue-d >>>>>> into the ReferenceQueue. Reference Handler thread otherwise just >>>>>> sleeps >>>>>> in lock.wait() most of the time if there's nothing to do and >>>>>> interrupting it's thread will trigger allocation of >>>>>> InterruptedException >>>>>> and consequently OOME nevertheless. >>>>>> >>>>>> One think to watch: Reference Handler thread is started in the >>>>>> j.l.r.Reference static initializer, so the Reference class must be >>>>>> initialized. I don't know if there is any guarantee that this is done >>>>>> before entering main(). So there should be something explicit in >>>>>> main() >>>>>> method that ensures it. >>>>>> >>>>>> Also, throwing test-fail exception should be done after releasing the >>>>>> heap or we'll just trigger another OOME without any message to >>>>>> describe >>>>>> the situation. >>>>>> >>>>>> Waiting in a loop for ReferenceHandler thread is not needed since the >>>>>> test will normally succeed and so the whole loop will execute to the >>>>>> end. Only when the test fails the loop will exit faster. In my >>>>>> experience, the thread dies between 10-20ms after interrupting, so >>>>>> waiting for about 500ms is enough I think. Also no System.gc() and >>>>>> additional waiting is needed to report the outcome - just releasing >>>>>> the >>>>>> reference to 'waste' variable is enuugh in my experience to restore >>>>>> the >>>>>> heap into working condition. >>>>>> >>>>>> Here's the updated test that does all that: >>>>>> >>>>>> >>>>>> public class OOMEInReferenceHandler { >>>>>> static Object[] fillHeap() { >>>>>> Object[] first = null, last = null; >>>>>> int size = 1 << 20; >>>>>> while (size > 0) { >>>>>> try { >>>>>> Object[] array = new Object[size]; >>>>>> if (first == null) { >>>>>> first = array; >>>>>> } >>>>>> else { >>>>>> last[0] = array; >>>>>> } >>>>>> last = array; >>>>>> } >>>>>> catch (OutOfMemoryError oome) { >>>>>> size = size >>> 1; >>>>>> } >>>>>> } >>>>>> return first; >>>>>> } >>>>>> >>>>>> public static void main(String[] args) throws Exception { >>>>>> // ensure ReferenceHandler thread is started >>>>>> new WeakReference(new Object()); >>>>>> >>>>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>>>> for (ThreadGroup tgn = tg; >>>>>> tgn != null; >>>>>> tg = tgn, tgn = tg.getParent()); >>>>>> >>>>>> Thread[] threads = new Thread[tg.activeCount()]; >>>>>> Thread referenceHandlerThread = null; >>>>>> int n = tg.enumerate(threads); >>>>>> for (int i = 0; i < n; i++) { >>>>>> if("Reference Handler".equals(threads[i].getName())) { >>>>>> referenceHandlerThread = threads[i]; >>>>>> } >>>>>> } >>>>>> >>>>>> if (referenceHandlerThread == null) { >>>>>> throw new IllegalStateException("Couldn't find Reference >>>>>> Handler thread."); >>>>>> } >>>>>> >>>>>> Object waste = fillHeap(); >>>>>> >>>>>> referenceHandlerThread.interrupt(); >>>>>> >>>>>> Thread.sleep(500L); >>>>>> >>>>>> // release waste so we can allocate and throw normal >>>>>> exceptions >>>>>> waste = null; >>>>>> >>>>>> // check that the handler is still alive >>>>>> if (!referenceHandlerThread.isAlive()) { >>>>>> throw new Exception("Reference Handler thread died."); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> >>>>>>>> Bugs.sun.com: >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>>>>>> >>>>>>>> JIRA: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT, with the new reproducer passing >>>>>>>> >>>>>>>> In need of reviewers and a sponsor for this patch; as mentioned >>>>>>>> earlier >>>>>>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>>>>>> patchset to the sponsor for this change with that author set. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Thomas >>>>>>>> >>>>>> >>>> >> From masayoshi.okutsu at oracle.com Fri May 10 04:57:20 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 10 May 2013 13:57:20 +0900 Subject: RFR JDK-8013386: (tz) Support tzdata2013c In-Reply-To: <518C3049.5050801@oracle.com> References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com> <518C3049.5050801@oracle.com> Message-ID: <518C7E30.8030302@oracle.com> Do we still need to keep the old javazic code in JDK8? It's a maintenance burden to maintain both, isn't it? I'm concerned about the 24:00 fix. Is there any way to produce the correct rules without hard coding time zone IDs? Masayoshi On 5/10/2013 8:24 AM, Xueming Shen wrote: > Hi Sean, > > Thanks for the review. It appears I missed > jdk/test/sun/util/calendar/zi/tzdata, > webrev has been updated to include the test data update. > > http://cr.openjdk.java.net/~sherman/8013386/webrev > > I will update TCKZoneRulesProvider.java separately in JSR310 repo, > this def is > actually is not being used by anyone anymore, just need to be removed. > > jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be > removed, I > will remove it separately later. > > > Masayoshi, > > The update also included the two changes needed to fix/workaround the > following 2 > issues found during running the regression test > > jdk/test/sun/util/calendar/zi/TestZoneInfo310.java, > > due to the changes for Rule Palestine and the corresponding Zone > Asia/Gaza and > Asia/Hebron [1]. > > (1) Now the Rule Palestine has the def of "lastThu 24:00", similar to > Asia/Amman, so > these two zones need to be handled specially in ZoneInfoFile as well [2] > > (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 > transitions for 2011 > when returned from Rule.getRules(int year). Unfortunately it appears > the Comparator > for Arrays.sorting is incorrectly implemented when comparing two longs > [3]. The directly > consequence of this decade-old bug is that the returned list has the > wrong order for > 2011/08/01/xxx and 2011/08/30/xxx > > Please help review. > > Thanks! > -Sherman > > [1] > http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html > [2] > http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html > [3] > http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html > > On 05/09/2013 02:06 AM, Se?n Coffey wrote: >> Thanks for taking care of this Sherman. I was wondering what sort of >> impact JSR 310 would make on tzdata updates. The Atlantic/Stanley >> display name issue mentioned is a regular one, we should log a bug >> against the test file generation scripts. >> >> I just had a quick grok of the jdk8 repo. The following files need >> updating also : >> >> jdk/test/sun/util/calendar/zi/tzdata/* >> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java (line >> 85) >> jdk/makefiles/GendataTimeZone.gmk (line 29) >> >> It looks like jdk/makefiles/GendataTimeZone.gmk still has a >> dependency on reading files from jdk/make. That'll all have to change >> too once the old build system is removed from jdk8. I think the new >> tzdata sources should be moved into a directory under makefiles >> rather than keeping them in make. >> >> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in >> jdk/makefiles/GendataTimeZone.gmk should be removed if we know that >> the version string can be read from the VERSION file stored with tzdata. >> >> Above points are not necessarily related to 2013c update and should >> be cleaned up separately perhaps. >> >> regards, >> Sean. >> >> On 08/05/2013 23:20, Xueming Shen wrote: >>> Hi, >>> >>> Please help review the proposed change to update the tz data >>> in JDK8 from 2012i to 2013c. >>> >>> Other than the tzdb data file update under make/sun/javazic/tzdata, >>> corresponding updates have also been made in TimeZoneNames***.java >>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated >>> zone display names (from EET to CET) for Africa/Tripoli (and its >>> alias Libya) >>> >>> test/java/util/TimeZone/tools/share/Make has been run to generate the >>> new test data at TimeZoneData. >>> >>> # I have to update the displaynames.txt "manually" to undo the change >>> for Atlantic/Stanley from "FKST" (which is defined in >>> southamerica.txt both >>> in 2012i and 2013c, there is no change for Stanley from 2012i to 2013c) >>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why the >>> definition in TimeZoneNames.java (which has FKT as the standard name >>> and >>> FKST as the summer name) does not match the tz data file (which >>> suggests >>> that Stanley has moved to use only summer zone), but since this appears >>> to be an existing issue that not related to this update, I keep the >>> test data for >>> Stanley untouched. >>> >>> Tests list below have been run and passed. >>> >>> java/util/TimeZone >>> java/util/Calendar >>> java/util/Formatter >>> java/time >>> closed/java/util/TimeZone >>> closed/java/util/Calendar >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~sherman/8013386/webrev/ >>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/ >>> >>> Thanks! >>> Sherman >> > From david.holmes at oracle.com Fri May 10 06:03:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 16:03:59 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks Message-ID: <518C8DCF.4010909@oracle.com> Short version: Cache the value returned by toString and use it to copy-construct a new String on subsequent calls to toString(). Clear the cache on any mutating operation. webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ Testing: microbenchmark for toString performance; new regression test for correctness; JPRT testset core as a sanity check Still TBD - full SE benchmark (?) Thanks, David --------- Long version: One of the goals for JDK8 is to provide a path from Java ME CDC to Java SE (or SE Embedded). In the embedded space some pretty old benchmarks still get used for doing comparisons between JRE's. One of which makes heavy use of StringBuffer.toString, without modifying the StringBuffer in between. Up to Java 1.4.2 a StringBuffer and a String could share the underlying char[]. This meant that toString simply needed to create a new String that referenced the StringBuffer's char[] with no copying of the array needed. In Java 5 the String/StringBuffer implementations were completely revised: StringBuilder was introduced for non-synchronized use, and a new AbstractStringBuilder base class added for it and StringBuffer. In that implementation toString now has to copy the StringBuffer's char[]. This resulted in a significant performance regression for toString() and a bug - 6219959 - was opened. There is quite an elaborate evaluation in that bug report but bottom line was that "real code doesn't depend on this - won't fix". At some stage ME also updated to the new Java 5 code and they also noticed the problem. As a result CDC6 included a variation of the caching strategy that is proposed here. Going forward because we want people to be able to compare ME and SE with their familiar benchmarks, we would like to address this corner case and fix it using the caching strategy outlined. As a data point an 8K StringBuffer that takes ~1ms to be converted to a String initially, can process subsequent toString() calls in a few microseconds. So that performance issue is addressed. However we've added a write to a field in all the mutating methods which obviously adds some additional computational effort - though I have no doubt it is lost in the noise for all but the smallest of mutating methods. Even so this should be run against regular SE benchmarks to ensure there are no performance regressions there - so if anyone has a suggestion as to the best benchmark to run to exercise StringBuffer (if it exists), please let me know. Thanks for reading this far :) From schlosna at gmail.com Fri May 10 06:25:00 2013 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 10 May 2013 02:25:00 -0400 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C8DCF.4010909@oracle.com> References: <518C8DCF.4010909@oracle.com> Message-ID: Hi David, Would it be beneficial to push the toStringCache up to AbstractStringBuilder so that StringBuilder.toString() benefits from this cache as well? It seems like this would affect both StringBuilder and StringBuffer for repeated calls to toString(), although StringBuffer would obviously have the synchronization overhead as well (assuming the locking is not elided away by HotSpot). Thanks, Dave On Fri, May 10, 2013 at 2:03 AM, David Holmes wrote: > Short version: > > Cache the value returned by toString and use it to copy-construct a new > String on subsequent calls to toString(). Clear the cache on any mutating > operation. > > webrev: http://cr.openjdk.java.net/~**dholmes/8013395/webrev.v2/ > > Testing: microbenchmark for toString performance; new regression test for > correctness; JPRT testset core as a sanity check > > Still TBD - full SE benchmark (?) > > Thanks, > David > --------- > > Long version: > > One of the goals for JDK8 is to provide a path from Java ME CDC to Java SE > (or SE Embedded). In the embedded space some pretty old benchmarks still > get used for doing comparisons between JRE's. One of which makes heavy use > of StringBuffer.toString, without modifying the StringBuffer in between. > > Up to Java 1.4.2 a StringBuffer and a String could share the underlying > char[]. This meant that toString simply needed to create a new String that > referenced the StringBuffer's char[] with no copying of the array needed. > In Java 5 the String/StringBuffer implementations were completely revised: > StringBuilder was introduced for non-synchronized use, and a new > AbstractStringBuilder base class added for it and StringBuffer. In that > implementation toString now has to copy the StringBuffer's char[]. This > resulted in a significant performance regression for toString() and a bug - > 6219959 - was opened. There is quite an elaborate evaluation in that bug > report but bottom line was that "real code doesn't depend on this - won't > fix". > > At some stage ME also updated to the new Java 5 code and they also noticed > the problem. As a result CDC6 included a variation of the caching strategy > that is proposed here. > > Going forward because we want people to be able to compare ME and SE with > their familiar benchmarks, we would like to address this corner case and > fix it using the caching strategy outlined. As a data point an 8K > StringBuffer that takes ~1ms to be converted to a String initially, can > process subsequent toString() calls in a few microseconds. So that > performance issue is addressed. > > However we've added a write to a field in all the mutating methods which > obviously adds some additional computational effort - though I have no > doubt it is lost in the noise for all but the smallest of mutating methods. > Even so this should be run against regular SE benchmarks to ensure there > are no performance regressions there - so if anyone has a suggestion as to > the best benchmark to run to exercise StringBuffer (if it exists), please > let me know. > > Thanks for reading this far :) > From xueming.shen at oracle.com Fri May 10 06:30:04 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 09 May 2013 23:30:04 -0700 Subject: RFR JDK-8013386: (tz) Support tzdata2013c In-Reply-To: <518C7E30.8030302@oracle.com> References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com> <518C3049.5050801@oracle.com> <518C7E30.8030302@oracle.com> Message-ID: <518C93EC.9080209@oracle.com> On 5/9/13 9:57 PM, Masayoshi Okutsu wrote: > Do we still need to keep the old javazic code in JDK8? It's a > maintenance burden to maintain both, isn't it? > While it's a burden, but somehow it serves as a test case pretty well. The transitions are being built the "old" jdk way and threeten way, if the transition does not match, something might be wrong. This time, it's in the "old" code, maybe next time it's in the threeten. So it might be still worth keeping a while, to remove in jdk9? Btw, the Rule.java fix might need go into the tzdb update tool as well, I believe the transitions for 2011 Palestine are wrong in the updated tzdb updator. > I'm concerned about the 24:00 fix. Is there any way to produce the > correct rules without hard coding time zone IDs? I don't know how to do it, yet. I definitely can have a RFE for it and spend some time on it later. -Sherman > > Masayoshi > > On 5/10/2013 8:24 AM, Xueming Shen wrote: >> Hi Sean, >> >> Thanks for the review. It appears I missed >> jdk/test/sun/util/calendar/zi/tzdata, >> webrev has been updated to include the test data update. >> >> http://cr.openjdk.java.net/~sherman/8013386/webrev >> >> I will update TCKZoneRulesProvider.java separately in JSR310 repo, >> this def is >> actually is not being used by anyone anymore, just need to be removed. >> >> jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be >> removed, I >> will remove it separately later. >> >> >> Masayoshi, >> >> The update also included the two changes needed to fix/workaround the >> following 2 >> issues found during running the regression test >> >> jdk/test/sun/util/calendar/zi/TestZoneInfo310.java, >> >> due to the changes for Rule Palestine and the corresponding Zone >> Asia/Gaza and >> Asia/Hebron [1]. >> >> (1) Now the Rule Palestine has the def of "lastThu 24:00", similar to >> Asia/Amman, so >> these two zones need to be handled specially in ZoneInfoFile as well [2] >> >> (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 >> transitions for 2011 >> when returned from Rule.getRules(int year). Unfortunately it appears >> the Comparator >> for Arrays.sorting is incorrectly implemented when comparing two >> longs [3]. The directly >> consequence of this decade-old bug is that the returned list has the >> wrong order for >> 2011/08/01/xxx and 2011/08/30/xxx >> >> Please help review. >> >> Thanks! >> -Sherman >> >> [1] >> http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html >> [2] >> http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html >> [3] >> http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html >> >> On 05/09/2013 02:06 AM, Se?n Coffey wrote: >>> Thanks for taking care of this Sherman. I was wondering what sort of >>> impact JSR 310 would make on tzdata updates. The Atlantic/Stanley >>> display name issue mentioned is a regular one, we should log a bug >>> against the test file generation scripts. >>> >>> I just had a quick grok of the jdk8 repo. The following files need >>> updating also : >>> >>> jdk/test/sun/util/calendar/zi/tzdata/* >>> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java >>> (line 85) >>> jdk/makefiles/GendataTimeZone.gmk (line 29) >>> >>> It looks like jdk/makefiles/GendataTimeZone.gmk still has a >>> dependency on reading files from jdk/make. That'll all have to >>> change too once the old build system is removed from jdk8. I think >>> the new tzdata sources should be moved into a directory under >>> makefiles rather than keeping them in make. >>> >>> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in >>> jdk/makefiles/GendataTimeZone.gmk should be removed if we know that >>> the version string can be read from the VERSION file stored with >>> tzdata. >>> >>> Above points are not necessarily related to 2013c update and should >>> be cleaned up separately perhaps. >>> >>> regards, >>> Sean. >>> >>> On 08/05/2013 23:20, Xueming Shen wrote: >>>> Hi, >>>> >>>> Please help review the proposed change to update the tz data >>>> in JDK8 from 2012i to 2013c. >>>> >>>> Other than the tzdb data file update under make/sun/javazic/tzdata, >>>> corresponding updates have also been made in TimeZoneNames***.java >>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated >>>> zone display names (from EET to CET) for Africa/Tripoli (and its >>>> alias Libya) >>>> >>>> test/java/util/TimeZone/tools/share/Make has been run to generate the >>>> new test data at TimeZoneData. >>>> >>>> # I have to update the displaynames.txt "manually" to undo the change >>>> for Atlantic/Stanley from "FKST" (which is defined in >>>> southamerica.txt both >>>> in 2012i and 2013c, there is no change for Stanley from 2012i to >>>> 2013c) >>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure why >>>> the >>>> definition in TimeZoneNames.java (which has FKT as the standard >>>> name and >>>> FKST as the summer name) does not match the tz data file (which >>>> suggests >>>> that Stanley has moved to use only summer zone), but since this >>>> appears >>>> to be an existing issue that not related to this update, I keep the >>>> test data for >>>> Stanley untouched. >>>> >>>> Tests list below have been run and passed. >>>> >>>> java/util/TimeZone >>>> java/util/Calendar >>>> java/util/Formatter >>>> java/time >>>> closed/java/util/TimeZone >>>> closed/java/util/Calendar >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/ >>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/ >>>> >>>> Thanks! >>>> Sherman >>> >> > From bourges.laurent at gmail.com Fri May 10 06:31:25 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 10 May 2013 08:31:25 +0200 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518BE348.4000107@gmail.com> References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> <518BE348.4000107@gmail.com> Message-ID: Peter, you're absolutely right: I was thinking about thread local values (object instances) and not ThreadLocal keys ! I think ThreadLocal name is confusing as it does not correspond to values ! Several times I wonder if false sharing can happen between my thread local values (i.e. different Thread context classes) and any other object including other Thread contexts). Is the GC (old gen) able to place objects in thread dedicated area: it would so avoid any false sharing between object graphs dedicated to each thread = thread isolation. I think that TLAB does so for allocation / short lived objects but for the old generation (long lived objects) it is not the case: maybe G1 can provide different partitioning and maybe take into acccount the thread affinity ? Laurent 2013/5/9 Peter Levart > > On 05/09/2013 04:59 PM, Laurent Bourg?s wrote: > > Hi all, > > A stupid question: > any ThreadLocal subclass should be marked @Contended to be sure that false > sharing never happens between ThreadLocal instance and any other object on > the heap ? > > > Hi Laurent, > > ThreadLocal object is just a key (into a ThreadLocalMap). It's usually not > subclassed to add any state but to override initialValue method. > ThreadLocal contains a single final field 'threadLocalHashCode', which is > read at every call to ThreadLocal.get() (usually by multiple threads). This > can contend with a frequent write of a field in some other object, placed > into it's proximity, yes, but I don't think we should put @Contended on > every class that has frequently read fields. @Contended should be reserved > for classes with fields that are frequently written, if I understand the > concept correctly. > > Regards, Peter > > > Laurent > > 2013/5/9 Peter Levart > >> Hi Aleksey, >> >> Wouldn't it be even better if just threadLocalRandom* fields were >> annotated with @Contended("ThreadLocal") ? >> Some fields within the Thread object are accessed from non-local threads. >> I don't know how frequently, but isolating just threadLocalRandom* fields >> from all possible false-sharing scenarios would seem even better, no? >> >> Regards, Peter >> >> >> On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: >> >>> Hi, >>> >>> This is from our backlog after JDK-8005926. After ThreadLocalRandom >>> state was merged into Thread, we now have to deal with the false sharing >>> induced by heavily-updated fields in Thread. TLR was padded before, and >>> it should make sense to make Thread bear @Contended annotation to >>> isolate its fields in the same manner. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~shade/8014233/webrev.00/ >>> >>> Testing: >>> - microbenchmarks (see below) >>> - JPRT cycle against jdk8-tl >>> >>> The extended rationale for the change follows. >>> >>> If we look at the current Thread layout, we can see the TLR state is >>> buried within the Thread instance. TLR state are by far the mostly >>> updated fields in Thread now: >>> >>> Running 64-bit HotSpot VM. >>>> Using compressed references with 3-bit shift. >>>> Objects are 8 bytes aligned. >>>> >>>> java.lang.Thread >>>> offset size type description >>>> 0 12 (assumed to be the object >>>> header + first field alignment) >>>> 12 4 int Thread.priority >>>> 16 8 long Thread.eetop >>>> 24 8 long Thread.stackSize >>>> 32 8 long Thread.nativeParkEventPointer >>>> 40 8 long Thread.tid >>>> 48 8 long Thread.threadLocalRandomSeed >>>> 56 4 int Thread.threadStatus >>>> 60 4 int Thread.threadLocalRandomProbe >>>> 64 4 int >>>> Thread.threadLocalRandomSecondarySeed >>>> 68 1 boolean Thread.single_step >>>> 69 1 boolean Thread.daemon >>>> 70 1 boolean Thread.stillborn >>>> 71 1 (alignment/padding gap) >>>> 72 4 char[] Thread.name >>>> 76 4 Thread Thread.threadQ >>>> 80 4 Runnable Thread.target >>>> 84 4 ThreadGroup Thread.group >>>> 88 4 ClassLoader Thread.contextClassLoader >>>> 92 4 AccessControlContext >>>> Thread.inheritedAccessControlContext >>>> 96 4 ThreadLocalMap Thread.threadLocals >>>> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >>>> 104 4 Object Thread.parkBlocker >>>> 108 4 Interruptible Thread.blocker >>>> 112 4 Object Thread.blockerLock >>>> 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>>> 120 (object boundary, size >>>> estimate) >>>> VM reports 120 bytes per instance >>>> >>> >>> Assuming current x86 hardware with 64-byte cache line sizes and current >>> class layout, we can see the trailing fields in Thread are providing >>> enough insulation from the false sharing with an adjacent object. Also, >>> the Thread itself is large enough so that two TLRs belonging to >>> different threads will not collide. >>> >>> However the leading fields are not enough: we have a few words which can >>> occupy the same cache line, but belong to another object. This is where >>> things can get worse in two ways: a) the TLR update can make the field >>> access in adjacent object considerably slower; and much worse b) the >>> update in the adjacent field can disturb the TLR state, which is >>> critical for j.u.concurrent performance relying heavily on fast TLR. >>> >>> To illustrate both points, there is a simple benchmark driven by JMH >>> (http://openjdk.java.net/projects/code-tools/jmh/): >>> http://cr.openjdk.java.net/~shade/8014233/threadbench.zip >>> >>> On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and >>> Thread with/without @Contended that microbenchmark yields the following >>> results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: >>> >>> Accessing ThreadLocalRandom.current().nextInt(): >>> baseline: 932 +- 4 ops/usec >>> @Contended: 927 +- 10 ops/usec >>> >>> Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): >>> baseline: 454 +- 2 ops/usec >>> @Contended: 490 +- 3 ops/usec >>> >>> One might note the $uncaughtExceptionHandler is the trailing field in >>> the Thread, so it can naturally be false-shared with the adjacent >>> thread's TLR. We had chosen this as the illustration, in real examples >>> with multitude objects on the heap, we can get another contender. >>> >>> So that is ~10% performance hit on false sharing even on very small >>> machine. Translating it back: having heavily-updated field in the object >>> adjacent to Thread can bring these overheads to TLR, and then jeopardize >>> j.u.c performance. >>> >>> Of course, as soon as status quo about field layout is changed, we might >>> start to lose spectacularly. I would recommend we deal with this now, so >>> less surprises come in the future. >>> >>> The caveat is that we are wasting some of the space per Thread instance. >>> After the patch, we layout is: >>> >>> java.lang.Thread >>>> offset size type description >>>> 0 12 (assumed to be the object >>>> header + first field alignment) >>>> 12 128 (alignment/padding gap) >>>> 140 4 int Thread.priority >>>> 144 8 long Thread.eetop >>>> 152 8 long Thread.stackSize >>>> 160 8 long Thread.nativeParkEventPointer >>>> 168 8 long Thread.tid >>>> 176 8 long Thread.threadLocalRandomSeed >>>> 184 4 int Thread.threadStatus >>>> 188 4 int Thread.threadLocalRandomProbe >>>> 192 4 int >>>> Thread.threadLocalRandomSecondarySeed >>>> 196 1 boolean Thread.single_step >>>> 197 1 boolean Thread.daemon >>>> 198 1 boolean Thread.stillborn >>>> 199 1 (alignment/padding gap) >>>> 200 4 char[] Thread.name >>>> 204 4 Thread Thread.threadQ >>>> 208 4 Runnable Thread.target >>>> 212 4 ThreadGroup Thread.group >>>> 216 4 ClassLoader Thread.contextClassLoader >>>> 220 4 AccessControlContext >>>> Thread.inheritedAccessControlContext >>>> 224 4 ThreadLocalMap Thread.threadLocals >>>> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >>>> 232 4 Object Thread.parkBlocker >>>> 236 4 Interruptible Thread.blocker >>>> 240 4 Object Thread.blockerLock >>>> 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>>> 248 (object boundary, size estimate) >>>> VM reports 376 bytes per instance >>>> >>> ...and we have additional 256 bytes per Thread (twice the >>> -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the >>> space wasted in native memory for each thread, especially stack areas. >>> >>> Thanks, >>> Aleksey. >>> >> >> > > From schlosna at gmail.com Fri May 10 06:39:35 2013 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 10 May 2013 02:39:35 -0400 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: References: <518C8DCF.4010909@oracle.com> Message-ID: One other quick comment, if the toStringCache is non-null during invocation of toString(), that seems to imply that the StringBuffer/StringBuilder has not been mutated since the last invocation of toString(), is there any reason to still use the String copy constructor? This would address the http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6239985 portion of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959. For example, I'd envisage in AbstractStringBuilder (assuming previous comments of pushing toStringCache from StringBuffer to AbstractStringBuilder): @Override public String toString() { if (toStringCache == null) { toStringCache = new String(value, 0, count); } return toStringCache; } - Dave On Fri, May 10, 2013 at 2:25 AM, David Schlosnagle wrote: > Hi David, > > Would it be beneficial to push the toStringCache up to > AbstractStringBuilder so that StringBuilder.toString() benefits from this > cache as well? It seems like this would affect both StringBuilder and > StringBuffer for repeated calls to toString(), although StringBuffer would > obviously have the synchronization overhead as well (assuming the locking > is not elided away by HotSpot). > > Thanks, > Dave > > > On Fri, May 10, 2013 at 2:03 AM, David Holmes wrote: > >> Short version: >> >> Cache the value returned by toString and use it to copy-construct a new >> String on subsequent calls to toString(). Clear the cache on any mutating >> operation. >> >> webrev: http://cr.openjdk.java.net/~**dholmes/8013395/webrev.v2/ >> >> Testing: microbenchmark for toString performance; new regression test for >> correctness; JPRT testset core as a sanity check >> >> Still TBD - full SE benchmark (?) >> >> Thanks, >> David >> --------- >> >> Long version: >> >> One of the goals for JDK8 is to provide a path from Java ME CDC to Java >> SE (or SE Embedded). In the embedded space some pretty old benchmarks still >> get used for doing comparisons between JRE's. One of which makes heavy use >> of StringBuffer.toString, without modifying the StringBuffer in between. >> >> Up to Java 1.4.2 a StringBuffer and a String could share the underlying >> char[]. This meant that toString simply needed to create a new String that >> referenced the StringBuffer's char[] with no copying of the array needed. >> In Java 5 the String/StringBuffer implementations were completely revised: >> StringBuilder was introduced for non-synchronized use, and a new >> AbstractStringBuilder base class added for it and StringBuffer. In that >> implementation toString now has to copy the StringBuffer's char[]. This >> resulted in a significant performance regression for toString() and a bug - >> 6219959 - was opened. There is quite an elaborate evaluation in that bug >> report but bottom line was that "real code doesn't depend on this - won't >> fix". >> >> At some stage ME also updated to the new Java 5 code and they also >> noticed the problem. As a result CDC6 included a variation of the caching >> strategy that is proposed here. >> >> Going forward because we want people to be able to compare ME and SE with >> their familiar benchmarks, we would like to address this corner case and >> fix it using the caching strategy outlined. As a data point an 8K >> StringBuffer that takes ~1ms to be converted to a String initially, can >> process subsequent toString() calls in a few microseconds. So that >> performance issue is addressed. >> >> However we've added a write to a field in all the mutating methods which >> obviously adds some additional computational effort - though I have no >> doubt it is lost in the noise for all but the smallest of mutating methods. >> Even so this should be run against regular SE benchmarks to ensure there >> are no performance regressions there - so if anyone has a suggestion as to >> the best benchmark to run to exercise StringBuffer (if it exists), please >> let me know. >> >> Thanks for reading this far :) >> > > From david.holmes at oracle.com Fri May 10 06:47:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 16:47:42 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: References: <518C8DCF.4010909@oracle.com> Message-ID: <518C980E.4070809@oracle.com> Hi David, On 10/05/2013 4:39 PM, David Schlosnagle wrote: > One other quick comment, if the toStringCache is non-null during > invocation of toString(), that seems to imply that the > StringBuffer/StringBuilder has not been mutated since the last > invocation of toString(), is there any reason to still use the String > copy constructor? This would address the > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6239985 portion of > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959. > > For example, I'd envisage in AbstractStringBuilder (assuming previous > comments of pushing toStringCache from StringBuffer to > AbstractStringBuilder): > > @Override > public String toString() { > if (toStringCache == null) { > toStringCache = new String(value, 0, count); > } > return toStringCache; > } Right this was our first thought too, but the specification for toString states that a new String is created. So to go this path we'd also have to push through a spec change for StringBuilder/StringBuffer. Given this is an obscure corner case I wanted to go the most minimal route possible. The copy-constructor doesn't copy the array which is what 6239985 was complaining about. Thanks, David > - Dave > > > On Fri, May 10, 2013 at 2:25 AM, David Schlosnagle > wrote: > > Hi David, > > Would it be beneficial to push the toStringCache up to > AbstractStringBuilder so that StringBuilder.toString() benefits from > this cache as well? It seems like this would affect both > StringBuilder and StringBuffer for repeated calls to toString(), > although StringBuffer would obviously have the synchronization > overhead as well (assuming the locking is not elided away by HotSpot). > > Thanks, > Dave > > > On Fri, May 10, 2013 at 2:03 AM, David Holmes > > wrote: > > Short version: > > Cache the value returned by toString and use it to > copy-construct a new String on subsequent calls to toString(). > Clear the cache on any mutating operation. > > webrev: http://cr.openjdk.java.net/~__dholmes/8013395/webrev.v2/ > > > Testing: microbenchmark for toString performance; new regression > test for correctness; JPRT testset core as a sanity check > > Still TBD - full SE benchmark (?) > > Thanks, > David > --------- > > Long version: > > One of the goals for JDK8 is to provide a path from Java ME CDC > to Java SE (or SE Embedded). In the embedded space some pretty > old benchmarks still get used for doing comparisons between > JRE's. One of which makes heavy use of StringBuffer.toString, > without modifying the StringBuffer in between. > > Up to Java 1.4.2 a StringBuffer and a String could share the > underlying char[]. This meant that toString simply needed to > create a new String that referenced the StringBuffer's char[] > with no copying of the array needed. In Java 5 the > String/StringBuffer implementations were completely revised: > StringBuilder was introduced for non-synchronized use, and a new > AbstractStringBuilder base class added for it and StringBuffer. > In that implementation toString now has to copy the > StringBuffer's char[]. This resulted in a significant > performance regression for toString() and a bug - 6219959 - was > opened. There is quite an elaborate evaluation in that bug > report but bottom line was that "real code doesn't depend on > this - won't fix". > > At some stage ME also updated to the new Java 5 code and they > also noticed the problem. As a result CDC6 included a variation > of the caching strategy that is proposed here. > > Going forward because we want people to be able to compare ME > and SE with their familiar benchmarks, we would like to address > this corner case and fix it using the caching strategy outlined. > As a data point an 8K StringBuffer that takes ~1ms to be > converted to a String initially, can process subsequent > toString() calls in a few microseconds. So that performance > issue is addressed. > > However we've added a write to a field in all the mutating > methods which obviously adds some additional computational > effort - though I have no doubt it is lost in the noise for all > but the smallest of mutating methods. Even so this should be run > against regular SE benchmarks to ensure there are no performance > regressions there - so if anyone has a suggestion as to the best > benchmark to run to exercise StringBuffer (if it exists), please > let me know. > > Thanks for reading this far :) > > > From david.holmes at oracle.com Fri May 10 06:52:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 16:52:30 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: References: <518C8DCF.4010909@oracle.com> Message-ID: <518C992E.7060202@oracle.com> Hi Dave, On 10/05/2013 4:25 PM, David Schlosnagle wrote: > Hi David, > > Would it be beneficial to push the toStringCache up to > AbstractStringBuilder so that StringBuilder.toString() benefits from > this cache as well? It seems like this would affect both StringBuilder > and StringBuffer for repeated calls to toString(), although StringBuffer > would obviously have the synchronization overhead as well (assuming the > locking is not elided away by HotSpot). In some absolute sense yes it might be beneficial if someone is also mis-using StringBuilder.toString; but really the best fix is to change the bad code to not repeat the toString calls (which was what the reporter of 6219959 did!). The intent here to was to provide the minimal set of changes to address this specific problem, with minimal risk of inadvertently impacting other uses. Thanks, David ----- > Thanks, > Dave > > > On Fri, May 10, 2013 at 2:03 AM, David Holmes > wrote: > > Short version: > > Cache the value returned by toString and use it to copy-construct a > new String on subsequent calls to toString(). Clear the cache on any > mutating operation. > > webrev: http://cr.openjdk.java.net/~__dholmes/8013395/webrev.v2/ > > > Testing: microbenchmark for toString performance; new regression > test for correctness; JPRT testset core as a sanity check > > Still TBD - full SE benchmark (?) > > Thanks, > David > --------- > > Long version: > > One of the goals for JDK8 is to provide a path from Java ME CDC to > Java SE (or SE Embedded). In the embedded space some pretty old > benchmarks still get used for doing comparisons between JRE's. One > of which makes heavy use of StringBuffer.toString, without modifying > the StringBuffer in between. > > Up to Java 1.4.2 a StringBuffer and a String could share the > underlying char[]. This meant that toString simply needed to create > a new String that referenced the StringBuffer's char[] with no > copying of the array needed. In Java 5 the String/StringBuffer > implementations were completely revised: StringBuilder was > introduced for non-synchronized use, and a new AbstractStringBuilder > base class added for it and StringBuffer. In that implementation > toString now has to copy the StringBuffer's char[]. This resulted in > a significant performance regression for toString() and a bug - > 6219959 - was opened. There is quite an elaborate evaluation in that > bug report but bottom line was that "real code doesn't depend on > this - won't fix". > > At some stage ME also updated to the new Java 5 code and they also > noticed the problem. As a result CDC6 included a variation of the > caching strategy that is proposed here. > > Going forward because we want people to be able to compare ME and SE > with their familiar benchmarks, we would like to address this corner > case and fix it using the caching strategy outlined. As a data point > an 8K StringBuffer that takes ~1ms to be converted to a String > initially, can process subsequent toString() calls in a few > microseconds. So that performance issue is addressed. > > However we've added a write to a field in all the mutating methods > which obviously adds some additional computational effort - though I > have no doubt it is lost in the noise for all but the smallest of > mutating methods. Even so this should be run against regular SE > benchmarks to ensure there are no performance regressions there - so > if anyone has a suggestion as to the best benchmark to run to > exercise StringBuffer (if it exists), please let me know. > > Thanks for reading this far :) > > From peter.levart at gmail.com Fri May 10 07:17:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 09:17:16 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C8DCF.4010909@oracle.com> References: <518C8DCF.4010909@oracle.com> Message-ID: <518C9EFC.1080304@gmail.com> Hi David, One remote incompatibility note: the String returned from StringBuffer.toString() is retained by StringBuffer until the next call to StringBuffer mutating method. This can be observed for example if the returned String object is wrapped by a WeakReference. This is really a remotely incompatible difference in external behaviour, but it could be fixed by the following variation of toString(): private transient char[] toStringCache; @Override public synchronized String toString() { if (toStringCache == null) { toStringCache = Arrays.copyOfRange(value, 0, count); } return new String(toStringCache, true); } Regards, Peter On 05/10/2013 08:03 AM, David Holmes wrote: > Short version: > > Cache the value returned by toString and use it to copy-construct a > new String on subsequent calls to toString(). Clear the cache on any > mutating operation. > > webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ > > Testing: microbenchmark for toString performance; new regression test > for correctness; JPRT testset core as a sanity check > > Still TBD - full SE benchmark (?) > > Thanks, > David > --------- > > Long version: > > One of the goals for JDK8 is to provide a path from Java ME CDC to > Java SE (or SE Embedded). In the embedded space some pretty old > benchmarks still get used for doing comparisons between JRE's. One of > which makes heavy use of StringBuffer.toString, without modifying the > StringBuffer in between. > > Up to Java 1.4.2 a StringBuffer and a String could share the > underlying char[]. This meant that toString simply needed to create a > new String that referenced the StringBuffer's char[] with no copying > of the array needed. In Java 5 the String/StringBuffer implementations > were completely revised: StringBuilder was introduced for > non-synchronized use, and a new AbstractStringBuilder base class added > for it and StringBuffer. In that implementation toString now has to > copy the StringBuffer's char[]. This resulted in a significant > performance regression for toString() and a bug - 6219959 - was > opened. There is quite an elaborate evaluation in that bug report but > bottom line was that "real code doesn't depend on this - won't fix". > > At some stage ME also updated to the new Java 5 code and they also > noticed the problem. As a result CDC6 included a variation of the > caching strategy that is proposed here. > > Going forward because we want people to be able to compare ME and SE > with their familiar benchmarks, we would like to address this corner > case and fix it using the caching strategy outlined. As a data point > an 8K StringBuffer that takes ~1ms to be converted to a String > initially, can process subsequent toString() calls in a few > microseconds. So that performance issue is addressed. > > However we've added a write to a field in all the mutating methods > which obviously adds some additional computational effort - though I > have no doubt it is lost in the noise for all but the smallest of > mutating methods. Even so this should be run against regular SE > benchmarks to ensure there are no performance regressions there - so > if anyone has a suggestion as to the best benchmark to run to exercise > StringBuffer (if it exists), please let me know. > > Thanks for reading this far :) From ivan.gerasimov at oracle.com Fri May 10 08:03:41 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 10 May 2013 12:03:41 +0400 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading Message-ID: <518CA9DD.9060609@oracle.com> Hello everybody! GzipInputStream uses SequenceInputStream to concatenate the underlying stream with some data that reside in memory. SequenceInputStream is implementing in such a way that it closes the stream when it reaches EOS. The solution is to wrap the underlying stream with extended FilterInputStream that overrides the close() method. BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ Sincerely your, Ivan From Alan.Bateman at oracle.com Fri May 10 08:31:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 09:31:58 +0100 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C8DCF.4010909@oracle.com> References: <518C8DCF.4010909@oracle.com> Message-ID: <518CB07E.8000100@oracle.com> On 10/05/2013 07:03, David Holmes wrote: > Short version: > > Cache the value returned by toString and use it to copy-construct a > new String on subsequent calls to toString(). Clear the cache on any > mutating operation. > > webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ > > Testing: microbenchmark for toString performance; new regression test > for correctness; JPRT testset core as a sanity check > There is a bit of cringe factor to this one but you've clearly explained the rational. I think it has to limited to StringBuffer for correctness reasons. Overall I think it is harmless and is okay. I see Peter's suggestion about caching the char[] rather than String, seems a good idea but probably remote issue (not to mention that developers have been encouraged to move to StringBuilder for many years). One comment on the test is that at L205 then it could also test a != b. -Alan. From joel.franck at oracle.com Fri May 10 09:06:56 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Fri, 10 May 2013 09:06:56 +0000 Subject: hg: jdk8/tl/jdk: 8007073: Implement Core Reflection for Type Annotations on parameters Message-ID: <20130510090725.83EF1489A7@hg.openjdk.java.net> Changeset: ba74cd79e4f6 Author: jfranck Date: 2013-05-10 10:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba74cd79e4f6 8007073: Implement Core Reflection for Type Annotations on parameters Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! test/java/lang/annotation/TypeAnnotationReflection.java From huizhe.wang at oracle.com Fri May 10 09:11:09 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 10 May 2013 02:11:09 -0700 Subject: RFR: 8014333 : javadoc error in JAXP 1.5 patch Message-ID: <518CB9AD.2060904@oracle.com> Hi, This is a quick fix for a javadoc error in the JAXP 1.5 patch. http://cr.openjdk.java.net/~joehw/jdk8/8014333/webrev/ Thanks, Joe From Lance.Andersen at oracle.com Fri May 10 09:18:43 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 10 May 2013 05:18:43 -0400 Subject: RFR: 8014333 : javadoc error in JAXP 1.5 patch In-Reply-To: <518CB9AD.2060904@oracle.com> References: <518CB9AD.2060904@oracle.com> Message-ID: <7F2B5435-0C6A-4ADF-8678-2C4A10C47E06@oracle.com> Looks ok 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 Sent from my iPhone On May 10, 2013, at 5:11 AM, huizhe wang wrote: > Hi, > > This is a quick fix for a javadoc error in the JAXP 1.5 patch. > > http://cr.openjdk.java.net/~joehw/jdk8/8014333/webrev/ > > Thanks, > Joe From sundararajan.athijegannathan at oracle.com Fri May 10 09:26:05 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 14:56:05 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518382B1.6040501@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> Message-ID: <518CBD2D.4000301@oracle.com> Please review the updated webrev @ http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ Thanks -Sundar On Friday 03 May 2013 02:56 PM, Alan Bateman wrote: > On 03/05/2013 07:47, A. Sundararajan wrote: >> >> Thanks. Looks like the first one has not been removed. But second one >> was removed: hg stat shows >> >> R make/sun/org/mozilla/javascript/Makefile >> >> (also the webrev shows it as removed). Perhaps patch does not take >> care of deleted files?? I am not sure. Also, build seems to go >> through without removing first one!! >> >> I'll remove that, build/test again and send another webrev. > One other one is make/tools/src/build/tools/deps/refs.allowed. The > last two lines can be replaced with: > > java.beans.PropertyChangeListener=java.util.logging.LogManager,compact1,compact2,compact3 > > > and the comment line about Rhino can be removed. > > -Alan. From Alan.Bateman at oracle.com Fri May 10 09:33:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 10:33:05 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CBD2D.4000301@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> Message-ID: <518CBED1.8010609@oracle.com> On 10/05/2013 10:26, A. Sundararajan wrote: > Please review the updated webrev @ > http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ > > Thanks > -Sundar > PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed. refs.allowed isn't quite right, the last line needs to be removed completely. Otherwise looks okay to me. -Alan. From paul.sandoz at oracle.com Fri May 10 09:37:04 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 May 2013 11:37:04 +0200 Subject: RFR: 8014316 : (XXS) Use Method Refs in j.u.stream.MatchOps In-Reply-To: <518C6A8F.5070802@oracle.com> References: <43666510-18BF-47BB-8002-AD0E99B9A22C@oracle.com> <518C6A8F.5070802@oracle.com> Message-ID: <93A20B57-90F1-45EA-9039-44F651055019@oracle.com> On May 10, 2013, at 5:33 AM, David Holmes wrote: > Looks good to me Mike! > +1 Paul. From masayoshi.okutsu at oracle.com Fri May 10 09:57:44 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 10 May 2013 18:57:44 +0900 Subject: RFR JDK-8013386: (tz) Support tzdata2013c In-Reply-To: <518C93EC.9080209@oracle.com> References: <518ACFB3.5030000@oracle.com> <518B6705.3050203@oracle.com> <518C3049.5050801@oracle.com> <518C7E30.8030302@oracle.com> <518C93EC.9080209@oracle.com> Message-ID: <518CC498.2020000@oracle.com> On 5/10/2013 3:30 PM, Xueming Shen wrote: > On 5/9/13 9:57 PM, Masayoshi Okutsu wrote: >> Do we still need to keep the old javazic code in JDK8? It's a >> maintenance burden to maintain both, isn't it? >> > > While it's a burden, but somehow it serves as a test case pretty well. > The transitions are > being built the "old" jdk way and threeten way, if the transition does > not match, something > might be wrong. This time, it's in the "old" code, maybe next time > it's in the threeten. So > it might be still worth keeping a while, to remove in jdk9? Btw, the > Rule.java fix might need > go into the tzdb update tool as well, I believe the transitions for > 2011 Palestine are wrong in > the updated tzdb updator. Yes, the Rule.java fix needs to go to older JDKs and TZ updater (build system). Masayoshi > >> I'm concerned about the 24:00 fix. Is there any way to produce the >> correct rules without hard coding time zone IDs? > > I don't know how to do it, yet. I definitely can have a RFE for it and > spend some time on > it later. > > -Sherman > >> >> Masayoshi >> >> On 5/10/2013 8:24 AM, Xueming Shen wrote: >>> Hi Sean, >>> >>> Thanks for the review. It appears I missed >>> jdk/test/sun/util/calendar/zi/tzdata, >>> webrev has been updated to include the test data update. >>> >>> http://cr.openjdk.java.net/~sherman/8013386/webrev >>> >>> I will update TCKZoneRulesProvider.java separately in JSR310 repo, >>> this def is >>> actually is not being used by anyone anymore, just need to be removed. >>> >>> jdk/makefiles/GendataTimeZone.gmk is no longer used, need to be >>> removed, I >>> will remove it separately later. >>> >>> >>> Masayoshi, >>> >>> The update also included the two changes needed to fix/workaround >>> the following 2 >>> issues found during running the regression test >>> >>> jdk/test/sun/util/calendar/zi/TestZoneInfo310.java, >>> >>> due to the changes for Rule Palestine and the corresponding Zone >>> Asia/Gaza and >>> Asia/Hebron [1]. >>> >>> (1) Now the Rule Palestine has the def of "lastThu 24:00", similar >>> to Asia/Amman, so >>> these two zones need to be handled specially in ZoneInfoFile as well >>> [2] >>> >>> (2) Rule Palestine has 2 day-saving changes in 2011, so it has 4 >>> transitions for 2011 >>> when returned from Rule.getRules(int year). Unfortunately it appears >>> the Comparator >>> for Arrays.sorting is incorrectly implemented when comparing two >>> longs [3]. The directly >>> consequence of this decade-old bug is that the returned list has the >>> wrong order for >>> 2011/08/01/xxx and 2011/08/30/xxx >>> >>> Please help review. >>> >>> Thanks! >>> -Sherman >>> >>> [1] >>> http://cr.openjdk.java.net/~sherman/8013386/webrev/make/sun/javazic/tzdata/asia.sdiff.html >>> [2] >>> http://cr.openjdk.java.net/~sherman/8013386/webrev/src/share/classes/sun/util/calendar/ZoneInfoFile.java.sdiff.html >>> [3] >>> http://cr.openjdk.java.net/~sherman/8013386/webrev/test/sun/util/calendar/zi/Rule.java.sdiff.html >>> >>> On 05/09/2013 02:06 AM, Se?n Coffey wrote: >>>> Thanks for taking care of this Sherman. I was wondering what sort >>>> of impact JSR 310 would make on tzdata updates. The >>>> Atlantic/Stanley display name issue mentioned is a regular one, we >>>> should log a bug against the test file generation scripts. >>>> >>>> I just had a quick grok of the jdk8 repo. The following files need >>>> updating also : >>>> >>>> jdk/test/sun/util/calendar/zi/tzdata/* >>>> jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java >>>> (line 85) >>>> jdk/makefiles/GendataTimeZone.gmk (line 29) >>>> >>>> It looks like jdk/makefiles/GendataTimeZone.gmk still has a >>>> dependency on reading files from jdk/make. That'll all have to >>>> change too once the old build system is removed from jdk8. I think >>>> the new tzdata sources should be moved into a directory under >>>> makefiles rather than keeping them in make. >>>> >>>> The "GENDATA_TIMEZONE_VERSION := tzdata2012i" line in >>>> jdk/makefiles/GendataTimeZone.gmk should be removed if we know >>>> that the version string can be read from the VERSION file stored >>>> with tzdata. >>>> >>>> Above points are not necessarily related to 2013c update and should >>>> be cleaned up separately perhaps. >>>> >>>> regards, >>>> Sean. >>>> >>>> On 08/05/2013 23:20, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> Please help review the proposed change to update the tz data >>>>> in JDK8 from 2012i to 2013c. >>>>> >>>>> Other than the tzdb data file update under make/sun/javazic/tzdata, >>>>> corresponding updates have also been made in TimeZoneNames***.java >>>>> for the newly added zones, Asia/Khandyga and Ust-Nera, and updated >>>>> zone display names (from EET to CET) for Africa/Tripoli (and its >>>>> alias Libya) >>>>> >>>>> test/java/util/TimeZone/tools/share/Make has been run to generate the >>>>> new test data at TimeZoneData. >>>>> >>>>> # I have to update the displaynames.txt "manually" to undo the change >>>>> for Atlantic/Stanley from "FKST" (which is defined in >>>>> southamerica.txt both >>>>> in 2012i and 2013c, there is no change for Stanley from 2012i to >>>>> 2013c) >>>>> back to "FKT FKST" to keep Bug6329116.java passed. I'm not sure >>>>> why the >>>>> definition in TimeZoneNames.java (which has FKT as the standard >>>>> name and >>>>> FKST as the summer name) does not match the tz data file (which >>>>> suggests >>>>> that Stanley has moved to use only summer zone), but since this >>>>> appears >>>>> to be an existing issue that not related to this update, I keep >>>>> the test data for >>>>> Stanley untouched. >>>>> >>>>> Tests list below have been run and passed. >>>>> >>>>> java/util/TimeZone >>>>> java/util/Calendar >>>>> java/util/Formatter >>>>> java/time >>>>> closed/java/util/TimeZone >>>>> closed/java/util/Calendar >>>>> >>>>> webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8013386/webrev/ >>>>> http://cr.openjdk.java.net/~sherman/8013386/test.closed/ >>>>> >>>>> Thanks! >>>>> Sherman >>>> >>> >> > From sundararajan.athijegannathan at oracle.com Fri May 10 10:23:33 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 15:53:33 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CBED1.8010609@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> Message-ID: <518CCAA5.3060205@oracle.com> com/sun/script/util is generic utility package for script engine implementations. Only com/sun/script/javascript package is being removed. Since we include javax/script for profile 3, should we also include com/sun/script/util ? On refs.allowed, I'll remove it. How should I check this? Thanks -Sundar On Friday 10 May 2013 03:03 PM, Alan Bateman wrote: > On 10/05/2013 10:26, A. Sundararajan wrote: >> Please review the updated webrev @ >> http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ >> >> Thanks >> -Sundar >> > PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed. > > refs.allowed isn't quite right, the last line needs to be removed > completely. > > Otherwise looks okay to me. > > -Alan. > From Alan.Bateman at oracle.com Fri May 10 10:39:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 11:39:04 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CCAA5.3060205@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> Message-ID: <518CCE48.3090309@oracle.com> On 10/05/2013 11:23, A. Sundararajan wrote: > com/sun/script/util is generic utility package for script engine > implementations. Only com/sun/script/javascript package is being > removed. Since we include javax/script for profile 3, should we also > include com/sun/script/util ? Is com.sun.script.util meant to be a supported/documented API? Do you know if anything outside of the JDK is using it? Is Nashorn using it? The only usage I see is in com.sun.script.javascript so this is why I assumed that com.sun.script.** would go away. As you know, we moved javax.script to compact1. It doesn't require com.sun.script.util of course but if this is used by 3rd party scripting engines then it may have to be added to compact1 builds to get them working. > > On refs.allowed, I'll remove it. How should I check this? "make profiles" on Linux should be fine. As part of the profiles build it will run a dependency analyzer that checks for references to types that do not exist (this is catch configuration issues). -Alan From peter.levart at gmail.com Fri May 10 10:52:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 12:52:15 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518C6779.5060802@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> Message-ID: <518CD15F.70503@gmail.com> Hi David, Thomas, I think I understand you now, David. You want to minimize the possibility of vacuously passing the test. So here's my attempt at that: public class OOMEInReferenceHandler { static Object[] fillHeap() { Object[] first = null, last = null; int size = 1 << 20; while (size > 0) { try { Object[] array = new Object[size]; if (first == null) { first = array; } else { last[0] = array; } last = array; } catch (OutOfMemoryError oome) { size = size >>> 1; } } return first; } public static void main(String[] args) throws Exception { ThreadGroup tg = Thread.currentThread().getThreadGroup(); for ( ThreadGroup tgn = tg; tgn != null; tg = tgn, tgn = tg.getParent() ) ; Thread[] threads = new Thread[tg.activeCount()]; Thread referenceHandlerThread = null; int n = tg.enumerate(threads); for (int i = 0; i < n; i++) { if ("Reference Handler".equals(threads[i].getName())) { referenceHandlerThread = threads[i]; } } if (referenceHandlerThread == null) { throw new IllegalStateException("Couldn't find Reference Handler thread."); } ReferenceQueue refQueue = new ReferenceQueue<>(); Object referent = new Object(); WeakReference weakRef = new WeakReference<>(referent, refQueue); Object waste = fillHeap(); referenceHandlerThread.interrupt(); // allow referenceHandlerThread some time to throw OOME Thread.sleep(500L); // release waste & referent waste = null; referent = null; // wait at most 10 seconds for success or failure for (int i = 0; i < 20; i++) { if (refQueue.poll() != null) { // Reference Handler thread still working -> success return; } System.gc(); Thread.sleep(500L); // wait a little to allow GC to do it's work before allocating objects if (!referenceHandlerThread.isAlive()) { // Reference Handler thread died -> failure throw new Exception("Reference Handler thread died."); } } // no sure answer after 10 seconds throw new IllegalStateException("Reference Handler thread stuck."); } } While executing the above test with the patch to ReferenceHandler applied, I noticed a strange behaviour. I can reproduce this behaviour reliably on both JDK7 and JDK8. When the patch is applied as proposed: try { lock.wait(); } catch (InterruptedException | OutOfMemoryError x) { } ... I still get the following output from the test (reliably, always): Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Reference Handler" Exception in thread "main" java.lang.Exception: Reference Handler thread died. at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) But when i change the patch to the following: try { lock.wait(); } catch (OutOfMemoryError | InterruptedException x) { } ...the test reliably and always passes. My explanation to his behaviour is that the order of exception handlers changes the order of class referencing. In the former variation (that still throws OOME) the following seems to be happening: wait() is interrupted and InterruptedException instance creation is attempted. Because this is the 1st reference to InterruptedException class in the lifetime of the JVM, loading of InterruptedException class is attempted which fails because of OOME. This OOME is caught by handler and ignored. But after handling of this OOME, another reference to InterruptedException class is attempted by exception handlers themselves (I don't know how exception handlers work exactly, but I have a feeling this is happening). Because InterruptedException class was not successfully loaded the 1st time tried, every reference to this class must throw NoClassDefFoundError, so this is attempted, but creation of NoClassDefFoundError fails because there's no heap space and another OOME is thrown - this time out of exception handling block, which is propagated and kills the thread. If the order of exception handlers is reversed, this second OOME is caught and ignored. To be sure the order of class referencing in handlers is not disturbed by changes in compilers, I suggest the patch to be modified to this more explicit variant: try { try { lock.wait(); } catch (InterruptedException x) { } } catch (OutOfMemoryError x) {} ..which also passes the test. Regards, Peter On 05/10/2013 05:20 AM, David Holmes wrote: > On 9/05/2013 10:13 PM, Peter Levart wrote: >> On 05/09/2013 01:33 PM, David Holmes wrote: >>> On 9/05/2013 9:16 PM, Peter Levart wrote: >>>> Hi David, >>>> >>>> On 05/09/2013 12:02 PM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> Thanks for clarifying the test details. A few follow ups: >>>>> >>>>> - The reference class does get initialized early in the VM startup >>>>> well before Main will be loaded. But the use of the weakref doesn't >>>>> hurt. >>>> >>>> Ok, so if this is guaranteed, we can remove the weakref construction. >>>> >>>>> >>>>> - 500ms may not be enough on some platforms, particularly some >>>>> embedded systems. Ideally we could code up a handshake using another >>>>> weakref that would guarantee that the handler thread really survived >>>>> past the OOM. But at some point this just becomes a no-reg-hard >>>>> situation :) >>>> >>>> If we used a weakref then there should be a delay between the >>>> referenceHandlerThread.interrupt() and the release of the >>>> WeakReference's referent, otherwise the WeakReference could be cleared >>>> and enqueued before Reference Handler attempts to throw >>>> InterruptedException (this really happens - I tried without delay and >>>> the clearing/enqueueing was quicker than interrupt). After this >>>> initial >>>> delay (currently set to 500ms) releasing the referent and waiting for >>>> WeakReference to be enqueued (while executing System.gc()) is >>>> analogous >>>> to testing for referenceHandlerThread.isAlive() - the only difference >>>> being the code that has to be executed in Reference Handler while >>>> unwinding the stack until the state of thread changes to >>>> TERMINATED. Can >>>> this be delayed for a long time? >>> >>> What I was thinking was that after we interrupt we then create a new >>> weakref >> >> Can't do that immediately (no space)! >> >>> and we loop until the ref gets cleared, or we detect the reference >>> thread is not alive (with a sleep in between). One of those two >>> conditions must become true. >> >> To create a weakref after interrupt, we have to 1st wait some time (to >> give Reference Handler thread a chance to throw OOME), then free the >> heap (release 'waste' and possibly do some System.gc()) to get some >> space for weakref creation. After we do that, a chance that Reference >> Handler thread is just in the process of unwinding the stack after >> uncaught OOME and referenceHandlerThread.isAlive() still returns true is >> minimal. Do you think we should wait some more to be sure thread is >> still alive? > > "create a new weakref" was the wrong thing to say. We should already > have the weakref and then clear the string ref (wrapped by the > weakref) and wait for the weakref to be cleared (or not) - which would > require looping with system.gc() call. > >>> >>>>> >>>>> - I'm not certain that setting waste=null is sufficient to guarantee >>>>> the next allocation will succeed under all GC's. GC folk can >>>>> confim/deny that. >>>> >>>> We can pre-allocate the test-fail exception before doing fillHeap() so >>>> that we can conditionally throw it later, like this: >>> >>> So when we do the throw there is logic in the launcher that will try >>> to print the stacktrace, which may also encounter OOME unless we have >>> freed the heap. So I think we want to release memory, I just wasn't >>> certain that simply setting waste=null would guarantee it. >> >> 'waste' is local variable and goes out of scope when main() is finished. > > Good point. But again I'm not certain that once waste is null, or out > of scope, that an attempted allocation (eg for stacktrace) will force > GC to run, release everything, and have the allocation succeed. This > is what I'd like GC folk to confirm/refute. > >> So in final variation I haven't even bothered to set it to null at the >> end. What do you suggest for successful test failure? Setting 'waste' to >> null, followed by a System.gc() and Thread.sleep()? Can we signal test >> failure in another way? System.exit(1)? > > The test harness expects exceptions for failures. System.exit is not > allowed in general. > > David > ----- > >> Regards, Peter >> >>> >>> David >>> ------ >>> >>>> public class Test { >>>> static Object[] fillHeap() { >>>> Object[] first = null, last = null; >>>> int size = 1 << 20; >>>> while (size > 0) { >>>> try { >>>> Object[] array = new Object[size]; >>>> if (first == null) { >>>> first = array; >>>> } else { >>>> last[0] = array; >>>> } >>>> last = array; >>>> } catch (OutOfMemoryError oome) { >>>> size = size >>> 1; >>>> } >>>> } >>>> return first; >>>> } >>>> >>>> public static void main(String[] args) throws Exception { >>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>> for ( >>>> ThreadGroup tgn = tg; >>>> tgn != null; >>>> tg = tgn, tgn = tg.getParent() >>>> ) >>>> ; >>>> >>>> Thread[] threads = new Thread[tg.activeCount()]; >>>> Thread referenceHandlerThread = null; >>>> int n = tg.enumerate(threads); >>>> for (int i = 0; i < n; i++) { >>>> if ("Reference Handler".equals(threads[i].getName())) { >>>> referenceHandlerThread = threads[i]; >>>> } >>>> } >>>> >>>> if (referenceHandlerThread == null) { >>>> throw new IllegalStateException("Couldn't find Reference >>>> Handler thread."); >>>> } >>>> >>>> // pre-allocate failure so that we don't cause OOME later >>>> Exception failure = new Exception("Reference Handler thread >>>> died."); >>>> >>>> Object waste = fillHeap(); >>>> >>>> referenceHandlerThread.interrupt(); >>>> >>>> // allow referenceHandlerThread some time to throw OOME >>>> Thread.sleep(500L); >>>> >>>> if (waste != null && // keep 'waste' reference alive until >>>> this >>>> point >>>> !referenceHandlerThread.isAlive()// check that the >>>> handler >>>> is still alive >>>> ) { >>>> throw failure; >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/05/2013 6:35 PM, Peter Levart wrote: >>>>>> On 05/09/2013 07:53 AM, David Holmes wrote: >>>>>>> Hi Thomas, >>>>>>> >>>>>>> On 9/05/2013 1:28 AM, Thomas Schatzl wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the latest webrev for this patch that is >>>>>>>> available at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >>>>>>>> >>>>>>>> As mentioned, it incorporates the fix and reproducer from Peter >>>>>>>> Levart. >>>>>>> >>>>>>> Fix is fine. >>>>>>> >>>>>>> I'm not sure about the test (sorry I didn't pay it attention >>>>>>> earlier). >>>>>>> Have you instrumented the code to verify that the test actually >>>>>>> triggers an OOME? It may be possible that if the OOME did kill the >>>>>>> reference thread that we wouldn't necessarily detect it using the >>>>>>> sleeps etc. Also I don't understand the need for the actual weakRef >>>>>>> usage and System.gc() etc. If the heap is full then the interrupt >>>>>>> will >>>>>>> wake the reference handler thread and the allocation will >>>>>>> trigger the >>>>>>> OOME. It doesn't matter if there are any references to process. The >>>>>>> main logic might then reduce to: >>>>>>> >>>>>>> referenceHandlerThread.interrupt(); >>>>>>> for (int i = 0; i < 10; i++) { >>>>>>> if (!referenceHandlerThread.isAlive()) >>>>>>> throw new Exception("Reference-handler thread died"); >>>>>>> Thread.sleep(1000); >>>>>>> } >>>>>>> >>>>>>> which just gives it 10s to die else assumes all ok. ? >>>>>>> >>>>>>> But I can live with existing test (it just might vacuously pass) >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>> >>>>>> Hi David, Thomas, >>>>>> >>>>>> Yes, this was just a left-over from my bug reproducer that >>>>>> demonstrated >>>>>> the situation where WeakReference was cleared, but nothing was >>>>>> enqueue-d >>>>>> into the ReferenceQueue. Reference Handler thread otherwise just >>>>>> sleeps >>>>>> in lock.wait() most of the time if there's nothing to do and >>>>>> interrupting it's thread will trigger allocation of >>>>>> InterruptedException >>>>>> and consequently OOME nevertheless. >>>>>> >>>>>> One think to watch: Reference Handler thread is started in the >>>>>> j.l.r.Reference static initializer, so the Reference class must be >>>>>> initialized. I don't know if there is any guarantee that this is >>>>>> done >>>>>> before entering main(). So there should be something explicit in >>>>>> main() >>>>>> method that ensures it. >>>>>> >>>>>> Also, throwing test-fail exception should be done after releasing >>>>>> the >>>>>> heap or we'll just trigger another OOME without any message to >>>>>> describe >>>>>> the situation. >>>>>> >>>>>> Waiting in a loop for ReferenceHandler thread is not needed since >>>>>> the >>>>>> test will normally succeed and so the whole loop will execute to the >>>>>> end. Only when the test fails the loop will exit faster. In my >>>>>> experience, the thread dies between 10-20ms after interrupting, so >>>>>> waiting for about 500ms is enough I think. Also no System.gc() and >>>>>> additional waiting is needed to report the outcome - just releasing >>>>>> the >>>>>> reference to 'waste' variable is enuugh in my experience to restore >>>>>> the >>>>>> heap into working condition. >>>>>> >>>>>> Here's the updated test that does all that: >>>>>> >>>>>> >>>>>> public class OOMEInReferenceHandler { >>>>>> static Object[] fillHeap() { >>>>>> Object[] first = null, last = null; >>>>>> int size = 1 << 20; >>>>>> while (size > 0) { >>>>>> try { >>>>>> Object[] array = new Object[size]; >>>>>> if (first == null) { >>>>>> first = array; >>>>>> } >>>>>> else { >>>>>> last[0] = array; >>>>>> } >>>>>> last = array; >>>>>> } >>>>>> catch (OutOfMemoryError oome) { >>>>>> size = size >>> 1; >>>>>> } >>>>>> } >>>>>> return first; >>>>>> } >>>>>> >>>>>> public static void main(String[] args) throws Exception { >>>>>> // ensure ReferenceHandler thread is started >>>>>> new WeakReference(new Object()); >>>>>> >>>>>> ThreadGroup tg = Thread.currentThread().getThreadGroup(); >>>>>> for (ThreadGroup tgn = tg; >>>>>> tgn != null; >>>>>> tg = tgn, tgn = tg.getParent()); >>>>>> >>>>>> Thread[] threads = new Thread[tg.activeCount()]; >>>>>> Thread referenceHandlerThread = null; >>>>>> int n = tg.enumerate(threads); >>>>>> for (int i = 0; i < n; i++) { >>>>>> if("Reference Handler".equals(threads[i].getName())) { >>>>>> referenceHandlerThread = threads[i]; >>>>>> } >>>>>> } >>>>>> >>>>>> if (referenceHandlerThread == null) { >>>>>> throw new IllegalStateException("Couldn't find >>>>>> Reference >>>>>> Handler thread."); >>>>>> } >>>>>> >>>>>> Object waste = fillHeap(); >>>>>> >>>>>> referenceHandlerThread.interrupt(); >>>>>> >>>>>> Thread.sleep(500L); >>>>>> >>>>>> // release waste so we can allocate and throw normal >>>>>> exceptions >>>>>> waste = null; >>>>>> >>>>>> // check that the handler is still alive >>>>>> if (!referenceHandlerThread.isAlive()) { >>>>>> throw new Exception("Reference Handler thread died."); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> >>>>>>>> Bugs.sun.com: >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7038914 >>>>>>>> >>>>>>>> JIRA: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7038914 >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT, with the new reproducer passing >>>>>>>> >>>>>>>> In need of reviewers and a sponsor for this patch; as mentioned >>>>>>>> earlier >>>>>>>> I will set Peter (plevart) as author for this patch, i.e. send a >>>>>>>> patchset to the sponsor for this change with that author set. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Thomas >>>>>>>> >>>>>> >>>> >> From peter.levart at gmail.com Fri May 10 11:21:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 13:21:35 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CD15F.70503@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> Message-ID: <518CD83F.30906@gmail.com> On 05/10/2013 12:52 PM, Peter Levart wrote: > While executing the above test with the patch to ReferenceHandler > applied, I noticed a strange behaviour. I can reproduce this behaviour > reliably on both JDK7 and JDK8. When the patch is applied as proposed: > > try { > lock.wait(); > } catch (InterruptedException | > OutOfMemoryError x) { } > > ... I still get the following output from the test (reliably, always): > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "Reference Handler" > Exception in thread "main" java.lang.Exception: Reference Handler > thread died. > at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) > > But when i change the patch to the following: > > try { > lock.wait(); > } catch (OutOfMemoryError | > InterruptedException x) { } > > ...the test reliably and always passes. > > My explanation to his behaviour is that the order of exception > handlers changes the order of class referencing. In the former > variation (that still throws OOME) the following seems to be happening: > > wait() is interrupted and InterruptedException instance creation is > attempted. Because this is the 1st reference to InterruptedException > class in the lifetime of the JVM, loading of InterruptedException > class is attempted which fails because of OOME. This OOME is caught by > handler and ignored. But after handling of this OOME, another > reference to InterruptedException class is attempted by exception > handlers themselves (I don't know how exception handlers work exactly, > but I have a feeling this is happening). Because InterruptedException > class was not successfully loaded the 1st time tried, every reference > to this class must throw NoClassDefFoundError, so this is attempted, > but creation of NoClassDefFoundError fails because there's no heap > space and another OOME is thrown - this time out of exception handling > block, which is propagated and kills the thread. > > If the order of exception handlers is reversed, this second OOME is > caught and ignored. Hi, This really seems to be happening (at least approximately, see below) because if InterruptedException class is preloaded at start of test, the order of exception handling does not have any impact on test. By disassembling the class-files of both variants, I found the only difference is the order of OutOfMemoryError & InterruptedException entries found in exception table: catch (InterruptedException | OutOfMemoryError x) variant has: public void run(); Code: 0: invokestatic #2 // Method java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; 3: dup 4: astore_2 5: monitorenter 6: invokestatic #3 // Method java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; 9: ifnull 33 12: invokestatic #3 // Method java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; 15: astore_1 16: aload_1 17: invokestatic #4 // Method java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 20: invokestatic #5 // Method java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 23: pop 24: aload_1 25: aconst_null 26: invokestatic #6 // Method java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 29: pop 30: goto 48 * 33: invokestatic #2 // Method java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** ** 36: invokevirtual #7 // Method java/lang/Object.wait:()V** ** 39: goto 43* 42: astore_3 43: aload_2 44: monitorexit 45: goto 0 48: aload_2 49: monitorexit 50: goto 60 53: astore 4 55: aload_2 56: monitorexit 57: aload 4 59: athrow 60: aload_1 61: instanceof #10 // class sun/misc/Cleaner 64: ifeq 77 67: aload_1 68: checkcast #10 // class sun/misc/Cleaner 71: invokevirtual #11 // Method sun/misc/Cleaner.clean:()V 74: goto 0 77: aload_1 78: getfield #12 // Field java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; 81: astore_2 82: aload_2 83: getstatic #13 // Field java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; 86: if_acmpeq 95 89: aload_2 90: aload_1 91: invokevirtual #14 // Method java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z 94: pop 95: goto 0 Exception table: from to target type * 33 39 42 Class java/lang/InterruptedException** ** 33 39 42 Class java/lang/OutOfMemoryError* 6 45 53 any 48 50 53 any 53 57 53 any catch (OutOfMemoryError | InterruptedException x) variant has the exactly same bytecodes but the following exception table: Exception table: from to target type * 33 39 42 Class java/lang/OutOfMemoryError** ** 33 39 42 Class java/lang/InterruptedException* 6 45 53 any 48 50 53 any 53 57 53 any ... so what seems to be happening is a little different but similar to what I have explained. In the former variant (that still throws OOME), the handler 1st checks for the type of thrown exception against InterruptedException class, which fails and attempts to throw NoClassDefFoundError which can't be allocated so another OOME is thrown, but in the later variant the 1st check is against OutOfMemoryError class which succeeds, so the empty handler is executed and no more checks are made (no 2nd reference to InterruptedException class). The fix I proposed in previous mail works (OOME is thrown twice and 2nd OOME is handled), but also the following would work (if the order of checks follows the source in every compiler): try { lock.wait(); } catch (OutOfMemoryError x) { } catch (InterruptedException x) { } ...the benefit of this is that OOME is never thrown two times. Regards, Peter From dl at cs.oswego.edu Fri May 10 12:17:56 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 10 May 2013 08:17:56 -0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518BB08B.8050909@gmail.com> References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> Message-ID: <518CE574.5080703@cs.oswego.edu> On 05/09/13 10:19, Peter Levart wrote: > Hi Aleksey, > > Wouldn't it be even better if just threadLocalRandom* fields were annotated with > @Contended("ThreadLocal") ? > Some fields within the Thread object are accessed from non-local threads. I > don't know how frequently, but isolating just threadLocalRandom* fields from all > possible false-sharing scenarios would seem even better, no? > As it turns out, no. Nearly all other fields of class Thread are also modified mainly by or only by the current thread (at least after initialization). So the simplest solution seems to be the best one. -Doug > Regards, Peter > > On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: >> Hi, >> >> This is from our backlog after JDK-8005926. After ThreadLocalRandom >> state was merged into Thread, we now have to deal with the false sharing >> induced by heavily-updated fields in Thread. TLR was padded before, and >> it should make sense to make Thread bear @Contended annotation to >> isolate its fields in the same manner. >> >> The webrev is here: >> http://cr.openjdk.java.net/~shade/8014233/webrev.00/ >> >> Testing: >> - microbenchmarks (see below) >> - JPRT cycle against jdk8-tl >> >> The extended rationale for the change follows. >> >> If we look at the current Thread layout, we can see the TLR state is >> buried within the Thread instance. TLR state are by far the mostly >> updated fields in Thread now: >> >>> Running 64-bit HotSpot VM. >>> Using compressed references with 3-bit shift. >>> Objects are 8 bytes aligned. >>> >>> java.lang.Thread >>> offset size type description >>> 0 12 (assumed to be the object header + >>> first field alignment) >>> 12 4 int Thread.priority >>> 16 8 long Thread.eetop >>> 24 8 long Thread.stackSize >>> 32 8 long Thread.nativeParkEventPointer >>> 40 8 long Thread.tid >>> 48 8 long Thread.threadLocalRandomSeed >>> 56 4 int Thread.threadStatus >>> 60 4 int Thread.threadLocalRandomProbe >>> 64 4 int Thread.threadLocalRandomSecondarySeed >>> 68 1 boolean Thread.single_step >>> 69 1 boolean Thread.daemon >>> 70 1 boolean Thread.stillborn >>> 71 1 (alignment/padding gap) >>> 72 4 char[] Thread.name >>> 76 4 Thread Thread.threadQ >>> 80 4 Runnable Thread.target >>> 84 4 ThreadGroup Thread.group >>> 88 4 ClassLoader Thread.contextClassLoader >>> 92 4 AccessControlContext Thread.inheritedAccessControlContext >>> 96 4 ThreadLocalMap Thread.threadLocals >>> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >>> 104 4 Object Thread.parkBlocker >>> 108 4 Interruptible Thread.blocker >>> 112 4 Object Thread.blockerLock >>> 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>> 120 (object boundary, size estimate) >>> VM reports 120 bytes per instance >> >> Assuming current x86 hardware with 64-byte cache line sizes and current >> class layout, we can see the trailing fields in Thread are providing >> enough insulation from the false sharing with an adjacent object. Also, >> the Thread itself is large enough so that two TLRs belonging to >> different threads will not collide. >> >> However the leading fields are not enough: we have a few words which can >> occupy the same cache line, but belong to another object. This is where >> things can get worse in two ways: a) the TLR update can make the field >> access in adjacent object considerably slower; and much worse b) the >> update in the adjacent field can disturb the TLR state, which is >> critical for j.u.concurrent performance relying heavily on fast TLR. >> >> To illustrate both points, there is a simple benchmark driven by JMH >> (http://openjdk.java.net/projects/code-tools/jmh/): >> http://cr.openjdk.java.net/~shade/8014233/threadbench.zip >> >> On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and >> Thread with/without @Contended that microbenchmark yields the following >> results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: >> >> Accessing ThreadLocalRandom.current().nextInt(): >> baseline: 932 +- 4 ops/usec >> @Contended: 927 +- 10 ops/usec >> >> Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): >> baseline: 454 +- 2 ops/usec >> @Contended: 490 +- 3 ops/usec >> >> One might note the $uncaughtExceptionHandler is the trailing field in >> the Thread, so it can naturally be false-shared with the adjacent >> thread's TLR. We had chosen this as the illustration, in real examples >> with multitude objects on the heap, we can get another contender. >> >> So that is ~10% performance hit on false sharing even on very small >> machine. Translating it back: having heavily-updated field in the object >> adjacent to Thread can bring these overheads to TLR, and then jeopardize >> j.u.c performance. >> >> Of course, as soon as status quo about field layout is changed, we might >> start to lose spectacularly. I would recommend we deal with this now, so >> less surprises come in the future. >> >> The caveat is that we are wasting some of the space per Thread instance. >> After the patch, we layout is: >> >>> java.lang.Thread >>> offset size type description >>> 0 12 (assumed to be the object header + >>> first field alignment) >>> 12 128 (alignment/padding gap) >>> 140 4 int Thread.priority >>> 144 8 long Thread.eetop >>> 152 8 long Thread.stackSize >>> 160 8 long Thread.nativeParkEventPointer >>> 168 8 long Thread.tid >>> 176 8 long Thread.threadLocalRandomSeed >>> 184 4 int Thread.threadStatus >>> 188 4 int Thread.threadLocalRandomProbe >>> 192 4 int Thread.threadLocalRandomSecondarySeed >>> 196 1 boolean Thread.single_step >>> 197 1 boolean Thread.daemon >>> 198 1 boolean Thread.stillborn >>> 199 1 (alignment/padding gap) >>> 200 4 char[] Thread.name >>> 204 4 Thread Thread.threadQ >>> 208 4 Runnable Thread.target >>> 212 4 ThreadGroup Thread.group >>> 216 4 ClassLoader Thread.contextClassLoader >>> 220 4 AccessControlContext Thread.inheritedAccessControlContext >>> 224 4 ThreadLocalMap Thread.threadLocals >>> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >>> 232 4 Object Thread.parkBlocker >>> 236 4 Interruptible Thread.blocker >>> 240 4 Object Thread.blockerLock >>> 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>> 248 (object boundary, size estimate) >>> VM reports 376 bytes per instance >> ...and we have additional 256 bytes per Thread (twice the >> -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the >> space wasted in native memory for each thread, especially stack areas. >> >> Thanks, >> Aleksey. > From dl at cs.oswego.edu Fri May 10 12:22:43 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 10 May 2013 08:22:43 -0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> <518BE348.4000107@gmail.com> Message-ID: <518CE693.1070708@cs.oswego.edu> On 05/10/13 02:31, Laurent Bourg?s wrote: > Peter, > > you're absolutely right: I was thinking about thread local values (object > instances) and not ThreadLocal keys ! > I think ThreadLocal name is confusing as it does not correspond to values ! > > Several times I wonder if false sharing can happen between my thread local > values (i.e. different Thread context classes) and any other object > including other Thread contexts). As Peter implied, this would in general be overkill. Every use of @Contended should be an empirically guided time/space tradeoff. There are specific classes used as ThreadLocals that may warrant this. For example, java.util.concurrent.Exchanger has one. > > Is the GC (old gen) able to place objects in thread dedicated area: it > would so avoid any false sharing between object graphs dedicated to each > thread = thread isolation. No it doesn't. Some collectors use some heuristics that tend to keep per-thread objects together, but there are no guarantees. -Doug > > I think that TLAB does so for allocation / short lived objects but for the > old generation (long lived objects) it is not the case: maybe G1 can > provide different partitioning and maybe take into acccount the thread > affinity ? > > Laurent > > 2013/5/9 Peter Levart > >> >> On 05/09/2013 04:59 PM, Laurent Bourg?s wrote: >> >> Hi all, >> >> A stupid question: >> any ThreadLocal subclass should be marked @Contended to be sure that false >> sharing never happens between ThreadLocal instance and any other object on >> the heap ? >> >> >> Hi Laurent, >> >> ThreadLocal object is just a key (into a ThreadLocalMap). It's usually not >> subclassed to add any state but to override initialValue method. >> ThreadLocal contains a single final field 'threadLocalHashCode', which is >> read at every call to ThreadLocal.get() (usually by multiple threads). This >> can contend with a frequent write of a field in some other object, placed >> into it's proximity, yes, but I don't think we should put @Contended on >> every class that has frequently read fields. @Contended should be reserved >> for classes with fields that are frequently written, if I understand the >> concept correctly. >> >> Regards, Peter >> >> >> Laurent >> >> 2013/5/9 Peter Levart >> >>> Hi Aleksey, >>> >>> Wouldn't it be even better if just threadLocalRandom* fields were >>> annotated with @Contended("ThreadLocal") ? >>> Some fields within the Thread object are accessed from non-local threads. >>> I don't know how frequently, but isolating just threadLocalRandom* fields >>> from all possible false-sharing scenarios would seem even better, no? >>> >>> Regards, Peter >>> >>> >>> On 05/08/2013 07:29 PM, Aleksey Shipilev wrote: >>> >>>> Hi, >>>> >>>> This is from our backlog after JDK-8005926. After ThreadLocalRandom >>>> state was merged into Thread, we now have to deal with the false sharing >>>> induced by heavily-updated fields in Thread. TLR was padded before, and >>>> it should make sense to make Thread bear @Contended annotation to >>>> isolate its fields in the same manner. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~shade/8014233/webrev.00/ >>>> >>>> Testing: >>>> - microbenchmarks (see below) >>>> - JPRT cycle against jdk8-tl >>>> >>>> The extended rationale for the change follows. >>>> >>>> If we look at the current Thread layout, we can see the TLR state is >>>> buried within the Thread instance. TLR state are by far the mostly >>>> updated fields in Thread now: >>>> >>>> Running 64-bit HotSpot VM. >>>>> Using compressed references with 3-bit shift. >>>>> Objects are 8 bytes aligned. >>>>> >>>>> java.lang.Thread >>>>> offset size type description >>>>> 0 12 (assumed to be the object >>>>> header + first field alignment) >>>>> 12 4 int Thread.priority >>>>> 16 8 long Thread.eetop >>>>> 24 8 long Thread.stackSize >>>>> 32 8 long Thread.nativeParkEventPointer >>>>> 40 8 long Thread.tid >>>>> 48 8 long Thread.threadLocalRandomSeed >>>>> 56 4 int Thread.threadStatus >>>>> 60 4 int Thread.threadLocalRandomProbe >>>>> 64 4 int >>>>> Thread.threadLocalRandomSecondarySeed >>>>> 68 1 boolean Thread.single_step >>>>> 69 1 boolean Thread.daemon >>>>> 70 1 boolean Thread.stillborn >>>>> 71 1 (alignment/padding gap) >>>>> 72 4 char[] Thread.name >>>>> 76 4 Thread Thread.threadQ >>>>> 80 4 Runnable Thread.target >>>>> 84 4 ThreadGroup Thread.group >>>>> 88 4 ClassLoader Thread.contextClassLoader >>>>> 92 4 AccessControlContext >>>>> Thread.inheritedAccessControlContext >>>>> 96 4 ThreadLocalMap Thread.threadLocals >>>>> 100 4 ThreadLocalMap Thread.inheritableThreadLocals >>>>> 104 4 Object Thread.parkBlocker >>>>> 108 4 Interruptible Thread.blocker >>>>> 112 4 Object Thread.blockerLock >>>>> 116 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>>>> 120 (object boundary, size >>>>> estimate) >>>>> VM reports 120 bytes per instance >>>>> >>>> >>>> Assuming current x86 hardware with 64-byte cache line sizes and current >>>> class layout, we can see the trailing fields in Thread are providing >>>> enough insulation from the false sharing with an adjacent object. Also, >>>> the Thread itself is large enough so that two TLRs belonging to >>>> different threads will not collide. >>>> >>>> However the leading fields are not enough: we have a few words which can >>>> occupy the same cache line, but belong to another object. This is where >>>> things can get worse in two ways: a) the TLR update can make the field >>>> access in adjacent object considerably slower; and much worse b) the >>>> update in the adjacent field can disturb the TLR state, which is >>>> critical for j.u.concurrent performance relying heavily on fast TLR. >>>> >>>> To illustrate both points, there is a simple benchmark driven by JMH >>>> (http://openjdk.java.net/projects/code-tools/jmh/): >>>> http://cr.openjdk.java.net/~shade/8014233/threadbench.zip >>>> >>>> On my 2x2 i5-2520M Linux x86_64 laptop, running latest jdk8-tl and >>>> Thread with/without @Contended that microbenchmark yields the following >>>> results [20x1 sec warmup, 20x1 sec measurements, 10 forks]: >>>> >>>> Accessing ThreadLocalRandom.current().nextInt(): >>>> baseline: 932 +- 4 ops/usec >>>> @Contended: 927 +- 10 ops/usec >>>> >>>> Accessing TLR.current.nextInt() *and* Thread.getUEHandler(): >>>> baseline: 454 +- 2 ops/usec >>>> @Contended: 490 +- 3 ops/usec >>>> >>>> One might note the $uncaughtExceptionHandler is the trailing field in >>>> the Thread, so it can naturally be false-shared with the adjacent >>>> thread's TLR. We had chosen this as the illustration, in real examples >>>> with multitude objects on the heap, we can get another contender. >>>> >>>> So that is ~10% performance hit on false sharing even on very small >>>> machine. Translating it back: having heavily-updated field in the object >>>> adjacent to Thread can bring these overheads to TLR, and then jeopardize >>>> j.u.c performance. >>>> >>>> Of course, as soon as status quo about field layout is changed, we might >>>> start to lose spectacularly. I would recommend we deal with this now, so >>>> less surprises come in the future. >>>> >>>> The caveat is that we are wasting some of the space per Thread instance. >>>> After the patch, we layout is: >>>> >>>> java.lang.Thread >>>>> offset size type description >>>>> 0 12 (assumed to be the object >>>>> header + first field alignment) >>>>> 12 128 (alignment/padding gap) >>>>> 140 4 int Thread.priority >>>>> 144 8 long Thread.eetop >>>>> 152 8 long Thread.stackSize >>>>> 160 8 long Thread.nativeParkEventPointer >>>>> 168 8 long Thread.tid >>>>> 176 8 long Thread.threadLocalRandomSeed >>>>> 184 4 int Thread.threadStatus >>>>> 188 4 int Thread.threadLocalRandomProbe >>>>> 192 4 int >>>>> Thread.threadLocalRandomSecondarySeed >>>>> 196 1 boolean Thread.single_step >>>>> 197 1 boolean Thread.daemon >>>>> 198 1 boolean Thread.stillborn >>>>> 199 1 (alignment/padding gap) >>>>> 200 4 char[] Thread.name >>>>> 204 4 Thread Thread.threadQ >>>>> 208 4 Runnable Thread.target >>>>> 212 4 ThreadGroup Thread.group >>>>> 216 4 ClassLoader Thread.contextClassLoader >>>>> 220 4 AccessControlContext >>>>> Thread.inheritedAccessControlContext >>>>> 224 4 ThreadLocalMap Thread.threadLocals >>>>> 228 4 ThreadLocalMap Thread.inheritableThreadLocals >>>>> 232 4 Object Thread.parkBlocker >>>>> 236 4 Interruptible Thread.blocker >>>>> 240 4 Object Thread.blockerLock >>>>> 244 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler >>>>> 248 (object boundary, size estimate) >>>>> VM reports 376 bytes per instance >>>>> >>>> ...and we have additional 256 bytes per Thread (twice the >>>> -XX:ContendedPaddingWidth, actually). Seems irrelevant comparing to the >>>> space wasted in native memory for each thread, especially stack areas. >>>> >>>> Thanks, >>>> Aleksey. >>>> >>> >>> >> >> > From sundararajan.athijegannathan at oracle.com Fri May 10 12:47:33 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 18:17:33 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CCE48.3090309@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> Message-ID: <518CEC65.7050006@oracle.com> Okay, thanks. com.sun.script.util is not supported API (no CCC done for it in the past). I'll remove it as suggested and run "make profiles" to check Thanks -Sundar On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: > On 10/05/2013 11:23, A. Sundararajan wrote: >> com/sun/script/util is generic utility package for script engine >> implementations. Only com/sun/script/javascript package is being >> removed. Since we include javax/script for profile 3, should we also >> include com/sun/script/util ? > Is com.sun.script.util meant to be a supported/documented API? Do you > know if anything outside of the JDK is using it? Is Nashorn using it? > The only usage I see is in com.sun.script.javascript so this is why I > assumed that com.sun.script.** would go away. > > As you know, we moved javax.script to compact1. It doesn't require > com.sun.script.util of course but if this is used by 3rd party > scripting engines then it may have to be added to compact1 builds to > get them working. > >> >> On refs.allowed, I'll remove it. How should I check this? > "make profiles" on Linux should be fine. As part of the profiles build > it will run a dependency analyzer that checks for references to types > that do not exist (this is catch configuration issues). > > -Alan From david.holmes at oracle.com Fri May 10 13:14:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2013 23:14:03 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CD83F.30906@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> Message-ID: <518CF29B.7090202@oracle.com> Hi Peter, So it would appear that it is not in fact the "new" that causes the OOME but the classloading of InterruptedException ? I'm not sure I can quite get my head around this late on a Friday night :) David On 10/05/2013 9:21 PM, Peter Levart wrote: > On 05/10/2013 12:52 PM, Peter Levart wrote: >> While executing the above test with the patch to ReferenceHandler >> applied, I noticed a strange behaviour. I can reproduce this behaviour >> reliably on both JDK7 and JDK8. When the patch is applied as proposed: >> >> try { >> lock.wait(); >> } catch (InterruptedException | >> OutOfMemoryError x) { } >> >> ... I still get the following output from the test (reliably, always): >> >> Exception: java.lang.OutOfMemoryError thrown from the >> UncaughtExceptionHandler in thread "Reference Handler" >> Exception in thread "main" java.lang.Exception: Reference Handler >> thread died. >> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >> >> But when i change the patch to the following: >> >> try { >> lock.wait(); >> } catch (OutOfMemoryError | >> InterruptedException x) { } >> >> ...the test reliably and always passes. >> >> My explanation to his behaviour is that the order of exception >> handlers changes the order of class referencing. In the former >> variation (that still throws OOME) the following seems to be happening: >> >> wait() is interrupted and InterruptedException instance creation is >> attempted. Because this is the 1st reference to InterruptedException >> class in the lifetime of the JVM, loading of InterruptedException >> class is attempted which fails because of OOME. This OOME is caught by >> handler and ignored. But after handling of this OOME, another >> reference to InterruptedException class is attempted by exception >> handlers themselves (I don't know how exception handlers work exactly, >> but I have a feeling this is happening). Because InterruptedException >> class was not successfully loaded the 1st time tried, every reference >> to this class must throw NoClassDefFoundError, so this is attempted, >> but creation of NoClassDefFoundError fails because there's no heap >> space and another OOME is thrown - this time out of exception handling >> block, which is propagated and kills the thread. >> >> If the order of exception handlers is reversed, this second OOME is >> caught and ignored. > > Hi, > > This really seems to be happening (at least approximately, see below) > because if InterruptedException class is preloaded at start of test, the > order of exception handling does not have any impact on test. > > By disassembling the class-files of both variants, I found the only > difference is the order of OutOfMemoryError & InterruptedException > entries found in exception table: > > catch (InterruptedException | OutOfMemoryError x) variant has: > > public void run(); > Code: > 0: invokestatic #2 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; > 3: dup > 4: astore_2 > 5: monitorenter > 6: invokestatic #3 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 9: ifnull 33 > 12: invokestatic #3 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 15: astore_1 > 16: aload_1 > 17: invokestatic #4 // Method > java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 20: invokestatic #5 // Method > java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 23: pop > 24: aload_1 > 25: aconst_null > 26: invokestatic #6 // Method > java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 29: pop > 30: goto 48 > * 33: invokestatic #2 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** > ** 36: invokevirtual #7 // Method > java/lang/Object.wait:()V** > ** 39: goto 43* > 42: astore_3 > 43: aload_2 > 44: monitorexit > 45: goto 0 > 48: aload_2 > 49: monitorexit > 50: goto 60 > 53: astore 4 > 55: aload_2 > 56: monitorexit > 57: aload 4 > 59: athrow > 60: aload_1 > 61: instanceof #10 // class sun/misc/Cleaner > 64: ifeq 77 > 67: aload_1 > 68: checkcast #10 // class sun/misc/Cleaner > 71: invokevirtual #11 // Method > sun/misc/Cleaner.clean:()V > 74: goto 0 > 77: aload_1 > 78: getfield #12 // Field > java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; > 81: astore_2 > 82: aload_2 > 83: getstatic #13 // Field > java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; > 86: if_acmpeq 95 > 89: aload_2 > 90: aload_1 > 91: invokevirtual #14 // Method > java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z > 94: pop > 95: goto 0 > Exception table: > from to target type > * 33 39 42 Class java/lang/InterruptedException** > ** 33 39 42 Class java/lang/OutOfMemoryError* > 6 45 53 any > 48 50 53 any > 53 57 53 any > > catch (OutOfMemoryError | InterruptedException x) variant has the > exactly same bytecodes but the following exception table: > > Exception table: > from to target type > * 33 39 42 Class java/lang/OutOfMemoryError** > ** 33 39 42 Class java/lang/InterruptedException* > 6 45 53 any > 48 50 53 any > 53 57 53 any > > > ... so what seems to be happening is a little different but similar to > what I have explained. In the former variant (that still throws OOME), > the handler 1st checks for the type of thrown exception against > InterruptedException class, which fails and attempts to throw > NoClassDefFoundError which can't be allocated so another OOME is thrown, > but in the later variant the 1st check is against OutOfMemoryError class > which succeeds, so the empty handler is executed and no more checks are > made (no 2nd reference to InterruptedException class). > > The fix I proposed in previous mail works (OOME is thrown twice and 2nd > OOME is handled), but also the following would work (if the order of > checks follows the source in every compiler): > > > try { > lock.wait(); > } catch (OutOfMemoryError x) { } > catch (InterruptedException x) { } > > > ...the benefit of this is that OOME is never thrown two times. > > Regards, Peter > From peter.levart at gmail.com Fri May 10 13:15:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 15:15:12 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CD83F.30906@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> Message-ID: <518CF2E0.6030204@gmail.com> Hi again, While the below patch works and keeps Reference Handler running in all scenarios, the evaluation exposed a weakness of JVM. If loading of a class fails because of OOME, this class can not be used in this incarnation of the VM even if OOME was just a transient condition. Regards, Peter On 05/10/2013 01:21 PM, Peter Levart wrote: > On 05/10/2013 12:52 PM, Peter Levart wrote: >> While executing the above test with the patch to ReferenceHandler >> applied, I noticed a strange behaviour. I can reproduce this >> behaviour reliably on both JDK7 and JDK8. When the patch is applied >> as proposed: >> >> try { >> lock.wait(); >> } catch (InterruptedException | >> OutOfMemoryError x) { } >> >> ... I still get the following output from the test (reliably, always): >> >> Exception: java.lang.OutOfMemoryError thrown from the >> UncaughtExceptionHandler in thread "Reference Handler" >> Exception in thread "main" java.lang.Exception: Reference Handler >> thread died. >> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >> >> But when i change the patch to the following: >> >> try { >> lock.wait(); >> } catch (OutOfMemoryError | >> InterruptedException x) { } >> >> ...the test reliably and always passes. >> >> My explanation to his behaviour is that the order of exception >> handlers changes the order of class referencing. In the former >> variation (that still throws OOME) the following seems to be happening: >> >> wait() is interrupted and InterruptedException instance creation is >> attempted. Because this is the 1st reference to InterruptedException >> class in the lifetime of the JVM, loading of InterruptedException >> class is attempted which fails because of OOME. This OOME is caught >> by handler and ignored. But after handling of this OOME, another >> reference to InterruptedException class is attempted by exception >> handlers themselves (I don't know how exception handlers work >> exactly, but I have a feeling this is happening). Because >> InterruptedException class was not successfully loaded the 1st time >> tried, every reference to this class must throw NoClassDefFoundError, >> so this is attempted, but creation of NoClassDefFoundError fails >> because there's no heap space and another OOME is thrown - this time >> out of exception handling block, which is propagated and kills the >> thread. >> >> If the order of exception handlers is reversed, this second OOME is >> caught and ignored. > > Hi, > > This really seems to be happening (at least approximately, see below) > because if InterruptedException class is preloaded at start of test, > the order of exception handling does not have any impact on test. > > By disassembling the class-files of both variants, I found the only > difference is the order of OutOfMemoryError & InterruptedException > entries found in exception table: > > catch (InterruptedException | OutOfMemoryError x) variant has: > > public void run(); > Code: > 0: invokestatic #2 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; > 3: dup > 4: astore_2 > 5: monitorenter > 6: invokestatic #3 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 9: ifnull 33 > 12: invokestatic #3 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 15: astore_1 > 16: aload_1 > 17: invokestatic #4 // Method > java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 20: invokestatic #5 // Method > java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 23: pop > 24: aload_1 > 25: aconst_null > 26: invokestatic #6 // Method > java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 29: pop > 30: goto 48 > * 33: invokestatic #2 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** > ** 36: invokevirtual #7 // Method > java/lang/Object.wait:()V** > ** 39: goto 43* > 42: astore_3 > 43: aload_2 > 44: monitorexit > 45: goto 0 > 48: aload_2 > 49: monitorexit > 50: goto 60 > 53: astore 4 > 55: aload_2 > 56: monitorexit > 57: aload 4 > 59: athrow > 60: aload_1 > 61: instanceof #10 // class sun/misc/Cleaner > 64: ifeq 77 > 67: aload_1 > 68: checkcast #10 // class sun/misc/Cleaner > 71: invokevirtual #11 // Method > sun/misc/Cleaner.clean:()V > 74: goto 0 > 77: aload_1 > 78: getfield #12 // Field > java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; > 81: astore_2 > 82: aload_2 > 83: getstatic #13 // Field > java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; > 86: if_acmpeq 95 > 89: aload_2 > 90: aload_1 > 91: invokevirtual #14 // Method > java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z > 94: pop > 95: goto 0 > Exception table: > from to target type > * 33 39 42 Class java/lang/InterruptedException** > ** 33 39 42 Class java/lang/OutOfMemoryError* > 6 45 53 any > 48 50 53 any > 53 57 53 any > > catch (OutOfMemoryError | InterruptedException x) variant has the > exactly same bytecodes but the following exception table: > > Exception table: > from to target type > * 33 39 42 Class java/lang/OutOfMemoryError** > ** 33 39 42 Class java/lang/InterruptedException* > 6 45 53 any > 48 50 53 any > 53 57 53 any > > > ... so what seems to be happening is a little different but similar to > what I have explained. In the former variant (that still throws OOME), > the handler 1st checks for the type of thrown exception against > InterruptedException class, which fails and attempts to throw > NoClassDefFoundError which can't be allocated so another OOME is > thrown, but in the later variant the 1st check is against > OutOfMemoryError class which succeeds, so the empty handler is > executed and no more checks are made (no 2nd reference to > InterruptedException class). > > The fix I proposed in previous mail works (OOME is thrown twice and > 2nd OOME is handled), but also the following would work (if the order > of checks follows the source in every compiler): > > > try { > lock.wait(); > } catch (OutOfMemoryError x) { } > catch (InterruptedException x) { } > > > ...the benefit of this is that OOME is never thrown two times. > > Regards, Peter > From peter.levart at gmail.com Fri May 10 13:18:55 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 15:18:55 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CF29B.7090202@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> Message-ID: <518CF3BF.1030307@gmail.com> On 05/10/2013 03:14 PM, David Holmes wrote: > Hi Peter, > > So it would appear that it is not in fact the "new" that causes the > OOME but the classloading of InterruptedException ? Depends on whether the InterruptedException class was already loaded or not when "new" is attempted. > > I'm not sure I can quite get my head around this late on a Friday > night :) It will be clear on Monday morning ;) Peter > > David > > On 10/05/2013 9:21 PM, Peter Levart wrote: >> On 05/10/2013 12:52 PM, Peter Levart wrote: >>> While executing the above test with the patch to ReferenceHandler >>> applied, I noticed a strange behaviour. I can reproduce this behaviour >>> reliably on both JDK7 and JDK8. When the patch is applied as proposed: >>> >>> try { >>> lock.wait(); >>> } catch (InterruptedException | >>> OutOfMemoryError x) { } >>> >>> ... I still get the following output from the test (reliably, always): >>> >>> Exception: java.lang.OutOfMemoryError thrown from the >>> UncaughtExceptionHandler in thread "Reference Handler" >>> Exception in thread "main" java.lang.Exception: Reference Handler >>> thread died. >>> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>> >>> But when i change the patch to the following: >>> >>> try { >>> lock.wait(); >>> } catch (OutOfMemoryError | >>> InterruptedException x) { } >>> >>> ...the test reliably and always passes. >>> >>> My explanation to his behaviour is that the order of exception >>> handlers changes the order of class referencing. In the former >>> variation (that still throws OOME) the following seems to be happening: >>> >>> wait() is interrupted and InterruptedException instance creation is >>> attempted. Because this is the 1st reference to InterruptedException >>> class in the lifetime of the JVM, loading of InterruptedException >>> class is attempted which fails because of OOME. This OOME is caught by >>> handler and ignored. But after handling of this OOME, another >>> reference to InterruptedException class is attempted by exception >>> handlers themselves (I don't know how exception handlers work exactly, >>> but I have a feeling this is happening). Because InterruptedException >>> class was not successfully loaded the 1st time tried, every reference >>> to this class must throw NoClassDefFoundError, so this is attempted, >>> but creation of NoClassDefFoundError fails because there's no heap >>> space and another OOME is thrown - this time out of exception handling >>> block, which is propagated and kills the thread. >>> >>> If the order of exception handlers is reversed, this second OOME is >>> caught and ignored. >> >> Hi, >> >> This really seems to be happening (at least approximately, see below) >> because if InterruptedException class is preloaded at start of test, the >> order of exception handling does not have any impact on test. >> >> By disassembling the class-files of both variants, I found the only >> difference is the order of OutOfMemoryError & InterruptedException >> entries found in exception table: >> >> catch (InterruptedException | OutOfMemoryError x) variant has: >> >> public void run(); >> Code: >> 0: invokestatic #2 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >> 3: dup >> 4: astore_2 >> 5: monitorenter >> 6: invokestatic #3 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 9: ifnull 33 >> 12: invokestatic #3 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 15: astore_1 >> 16: aload_1 >> 17: invokestatic #4 // Method >> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 20: invokestatic #5 // Method >> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 23: pop >> 24: aload_1 >> 25: aconst_null >> 26: invokestatic #6 // Method >> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 29: pop >> 30: goto 48 >> * 33: invokestatic #2 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >> ** 36: invokevirtual #7 // Method >> java/lang/Object.wait:()V** >> ** 39: goto 43* >> 42: astore_3 >> 43: aload_2 >> 44: monitorexit >> 45: goto 0 >> 48: aload_2 >> 49: monitorexit >> 50: goto 60 >> 53: astore 4 >> 55: aload_2 >> 56: monitorexit >> 57: aload 4 >> 59: athrow >> 60: aload_1 >> 61: instanceof #10 // class sun/misc/Cleaner >> 64: ifeq 77 >> 67: aload_1 >> 68: checkcast #10 // class sun/misc/Cleaner >> 71: invokevirtual #11 // Method >> sun/misc/Cleaner.clean:()V >> 74: goto 0 >> 77: aload_1 >> 78: getfield #12 // Field >> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >> 81: astore_2 >> 82: aload_2 >> 83: getstatic #13 // Field >> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >> 86: if_acmpeq 95 >> 89: aload_2 >> 90: aload_1 >> 91: invokevirtual #14 // Method >> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >> 94: pop >> 95: goto 0 >> Exception table: >> from to target type >> * 33 39 42 Class java/lang/InterruptedException** >> ** 33 39 42 Class java/lang/OutOfMemoryError* >> 6 45 53 any >> 48 50 53 any >> 53 57 53 any >> >> catch (OutOfMemoryError | InterruptedException x) variant has the >> exactly same bytecodes but the following exception table: >> >> Exception table: >> from to target type >> * 33 39 42 Class java/lang/OutOfMemoryError** >> ** 33 39 42 Class java/lang/InterruptedException* >> 6 45 53 any >> 48 50 53 any >> 53 57 53 any >> >> >> ... so what seems to be happening is a little different but similar to >> what I have explained. In the former variant (that still throws OOME), >> the handler 1st checks for the type of thrown exception against >> InterruptedException class, which fails and attempts to throw >> NoClassDefFoundError which can't be allocated so another OOME is thrown, >> but in the later variant the 1st check is against OutOfMemoryError class >> which succeeds, so the empty handler is executed and no more checks are >> made (no 2nd reference to InterruptedException class). >> >> The fix I proposed in previous mail works (OOME is thrown twice and 2nd >> OOME is handled), but also the following would work (if the order of >> checks follows the source in every compiler): >> >> >> try { >> lock.wait(); >> } catch (OutOfMemoryError x) { } >> catch (InterruptedException x) { } >> >> >> ...the benefit of this is that OOME is never thrown two times. >> >> Regards, Peter >> From david.r.chase at oracle.com Fri May 10 13:21:26 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 10 May 2013 09:21:26 -0400 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C980E.4070809@oracle.com> References: <518C8DCF.4010909@oracle.com> <518C980E.4070809@oracle.com> Message-ID: <8D84ED3B-518B-48C0-A23B-36E618A599D4@oracle.com> On 2013-05-10, at 2:47 AM, David Holmes wrote: > Right this was our first thought too, but the specification for toString states that a new String is created. So to go this path we'd also have to push through a spec change for StringBuilder/StringBuffer. Given this is an obscure corner case I wanted to go the most minimal route possible. The copy-constructor doesn't copy the array which is what 6239985 was complaining about. Any chance that we can concurrently start a push for a spec change? Any place in the spec where we're picky about the reference identity of immutable objects is a candidate for revision; this is an issue for value types, if/when we ever get those into the language. David From aleksey.shipilev at oracle.com Fri May 10 13:27:19 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 10 May 2013 17:27:19 +0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: <518CE574.5080703@cs.oswego.edu> References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> <518CE574.5080703@cs.oswego.edu> Message-ID: On 10.05.2013, at 16:17, Doug Lea
                  wrote: > On 05/09/13 10:19, Peter Levart wrote: >> Hi Aleksey, >> >> Wouldn't it be even better if just threadLocalRandom* fields were annotated with >> @Contended("ThreadLocal") ? >> Some fields within the Thread object are accessed from non-local threads. I >> don't know how frequently, but isolating just threadLocalRandom* fields from all >> possible false-sharing scenarios would seem even better, no? > > As it turns out, no. Nearly all other fields of class Thread > are also modified mainly by or only by the current thread > (at least after initialization). So the simplest solution > seems to be the best one. +1. Although I just tried what Peter had suggested, and got even more boost on my microbenchmark. This counter-intuitive for me, since no memory layout differences could explain this in my tests. I will have to untangle this today, hold on. -Aleksey From alan.bateman at oracle.com Fri May 10 13:56:10 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 10 May 2013 13:56:10 +0000 Subject: hg: jdk8/tl/jdk: 8011128: (fs) Files.createDirectory fails if the resolved path is exactly 248 characters long Message-ID: <20130510135635.C1221489AC@hg.openjdk.java.net> Changeset: 09a3b08c986f Author: alanb Date: 2013-05-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a3b08c986f 8011128: (fs) Files.createDirectory fails if the resolved path is exactly 248 characters long Reviewed-by: khazra, chegar ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsPath.java + test/java/nio/file/Files/NameLimits.java From chris.hegarty at oracle.com Fri May 10 14:14:27 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 May 2013 15:14:27 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518B8B67.2060502@cs.oswego.edu> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> <518B70B0.30703@oracle.com> <518B7670.4080405@oracle.com> <518B8B67.2060502@cs.oswego.edu> Message-ID: <518D00C3.5040803@oracle.com> Updated webrev and specdiff. http://cr.openjdk.java.net/~chegar/8014076/ver.01/specdiff/java/util/Arrays.html http://cr.openjdk.java.net/~chegar/8014076/ver.01/webrev/ I incorporated the feedback so far, and reverted the change to make MIN_ARRAY_SORT_GRAN public ( there doesn't appear to be enough justification for this ). -Chris. From tim.bell at oracle.com Fri May 10 14:46:51 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 May 2013 07:46:51 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CEC65.7050006@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> Message-ID: <518D085B.2090301@oracle.com> Hi Sundar Looks like you have resolved the subtleties of profiles with Alan. The rest looks good to me. Tim On 05/10/13 05:47 AM, A. Sundararajan wrote: > Okay, thanks. com.sun.script.util is not supported API (no CCC done > for it in the past). I'll remove it as suggested and run "make > profiles" to check > > Thanks > -Sundar > > On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: >> On 10/05/2013 11:23, A. Sundararajan wrote: >>> com/sun/script/util is generic utility package for script engine >>> implementations. Only com/sun/script/javascript package is being >>> removed. Since we include javax/script for profile 3, should we also >>> include com/sun/script/util ? >> Is com.sun.script.util meant to be a supported/documented API? Do you >> know if anything outside of the JDK is using it? Is Nashorn using it? >> The only usage I see is in com.sun.script.javascript so this is why I >> assumed that com.sun.script.** would go away. >> >> As you know, we moved javax.script to compact1. It doesn't require >> com.sun.script.util of course but if this is used by 3rd party >> scripting engines then it may have to be added to compact1 builds to >> get them working. >> >>> >>> On refs.allowed, I'll remove it. How should I check this? >> "make profiles" on Linux should be fine. As part of the profiles >> build it will run a dependency analyzer that checks for references to >> types that do not exist (this is catch configuration issues). >> >> -Alan > From roger.riggs at oracle.com Fri May 10 15:02:29 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 May 2013 11:02:29 -0400 Subject: Request for Review 8014296: DivModTests should not compare pointers Message-ID: <518D0C05.7080808@oracle.com> Please review this minor correction to DivModTests to address this issue: http://bugs.sun.com/view_bug.do?bug_id=8014296 With autoboxing of mixed types primitive and Object, the operators == and != are interpreted as reference compare instead of value compares. The compiler is silent about the likely unintended consequences. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ Thanks, Roger From joe.darcy at oracle.com Fri May 10 15:14:21 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 08:14:21 -0700 Subject: Request for Review 8014296: DivModTests should not compare pointers In-Reply-To: <518D0C05.7080808@oracle.com> References: <518D0C05.7080808@oracle.com> Message-ID: <518D0ECD.4040004@oracle.com> On 05/10/2013 08:02 AM, roger riggs wrote: > Please review this minor correction to DivModTests to address this issue: > http://bugs.sun.com/view_bug.do?bug_id=8014296 > > With autoboxing of mixed types primitive and Object, the operators == > and != > are interpreted as reference compare instead of value compares. > The compiler is silent about the likely unintended consequences. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ > > Thanks, Roger > Roger, The copyright range should now be "2012, 2013,". Otherwise, the change looks fine. -Joe From alan.bateman at oracle.com Fri May 10 15:15:09 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 10 May 2013 15:15:09 +0000 Subject: hg: jdk8/tl/langtools: 8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that javax.script is in compact1 Message-ID: <20130510151517.4C2C5489AD@hg.openjdk.java.net> Changeset: ce7e1674eb73 Author: alanb Date: 2013-05-10 16:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce7e1674eb73 8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that javax.script is in compact1 Reviewed-by: mchung ! test/tools/javac/profiles/ProfileOptionTest.java From roger.riggs at oracle.com Fri May 10 15:25:16 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 May 2013 11:25:16 -0400 Subject: Request for Review 8014296: DivModTests should not compare pointers In-Reply-To: <518D0ECD.4040004@oracle.com> References: <518D0C05.7080808@oracle.com> <518D0ECD.4040004@oracle.com> Message-ID: <518D115C.9070106@oracle.com> Thanks, the webrev now has the correct copyright change. On 5/10/2013 11:14 AM, Joe Darcy wrote: > On 05/10/2013 08:02 AM, roger riggs wrote: >> Please review this minor correction to DivModTests to address this >> issue: >> http://bugs.sun.com/view_bug.do?bug_id=8014296 >> >> With autoboxing of mixed types primitive and Object, the operators == >> and != >> are interpreted as reference compare instead of value compares. >> The compiler is silent about the likely unintended consequences. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ >> >> Thanks, Roger >> > > Roger, > > The copyright range should now be "2012, 2013,". > > Otherwise, the change looks fine. > > -Joe From joe.darcy at oracle.com Fri May 10 15:39:04 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 08:39:04 -0700 Subject: Request for Review 8014296: DivModTests should not compare pointers In-Reply-To: <518D115C.9070106@oracle.com> References: <518D0C05.7080808@oracle.com> <518D0ECD.4040004@oracle.com> <518D115C.9070106@oracle.com> Message-ID: <518D1498.3060109@oracle.com> Good to push. -Joe On 05/10/2013 08:25 AM, roger riggs wrote: > Thanks, the webrev now has the correct copyright change. > > > On 5/10/2013 11:14 AM, Joe Darcy wrote: >> On 05/10/2013 08:02 AM, roger riggs wrote: >>> Please review this minor correction to DivModTests to address this >>> issue: >>> http://bugs.sun.com/view_bug.do?bug_id=8014296 >>> >>> With autoboxing of mixed types primitive and Object, the operators >>> == and != >>> are interpreted as reference compare instead of value compares. >>> The compiler is silent about the likely unintended consequences. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ >>> >>> Thanks, Roger >>> >> >> Roger, >> >> The copyright range should now be "2012, 2013,". >> >> Otherwise, the change looks fine. >> >> -Joe > From roger.riggs at oracle.com Fri May 10 15:40:41 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 May 2013 11:40:41 -0400 Subject: Request for Review 8014296: DivModTests should not compare pointers In-Reply-To: <518D1498.3060109@oracle.com> References: <518D0C05.7080808@oracle.com> <518D0ECD.4040004@oracle.com> <518D115C.9070106@oracle.com> <518D1498.3060109@oracle.com> Message-ID: <518D14F9.5070305@oracle.com> Thanks, I'll need help with the push (I'm not a committer for JDK). On 5/10/2013 11:39 AM, Joe Darcy wrote: > Good to push. > > -Joe > > On 05/10/2013 08:25 AM, roger riggs wrote: >> Thanks, the webrev now has the correct copyright change. >> >> >> On 5/10/2013 11:14 AM, Joe Darcy wrote: >>> On 05/10/2013 08:02 AM, roger riggs wrote: >>>> Please review this minor correction to DivModTests to address this >>>> issue: >>>> http://bugs.sun.com/view_bug.do?bug_id=8014296 >>>> >>>> With autoboxing of mixed types primitive and Object, the operators >>>> == and != >>>> are interpreted as reference compare instead of value compares. >>>> The compiler is silent about the likely unintended consequences. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ >>>> >>>> Thanks, Roger >>>> >>> >>> Roger, >>> >>> The copyright range should now be "2012, 2013,". >>> >>> Otherwise, the change looks fine. >>> >>> -Joe >> > From joe.darcy at oracle.com Fri May 10 15:56:31 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 15:56:31 +0000 Subject: hg: jdk8/tl/jdk: 8014249: Add Modifer.parameterModifiers() Message-ID: <20130510155653.EED71489B2@hg.openjdk.java.net> Changeset: ece61e21782d Author: darcy Date: 2013-05-10 08:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ece61e21782d 8014249: Add Modifer.parameterModifiers() Reviewed-by: mduigou, mchung ! src/share/classes/java/lang/reflect/Modifier.java From huizhe.wang at oracle.com Fri May 10 16:07:24 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 10 May 2013 09:07:24 -0700 Subject: RFR: 8014333 : javadoc error in JAXP 1.5 patch In-Reply-To: <7F2B5435-0C6A-4ADF-8678-2C4A10C47E06@oracle.com> References: <518CB9AD.2060904@oracle.com> <7F2B5435-0C6A-4ADF-8678-2C4A10C47E06@oracle.com> Message-ID: <518D1B3C.7070006@oracle.com> Thanks! On 5/10/2013 2:18 AM, Lance Andersen wrote: > Looks ok > > 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 > > Sent from my iPhone > > On May 10, 2013, at 5:11 AM, huizhe wang > wrote: > >> Hi, >> >> This is a quick fix for a javadoc error in the JAXP 1.5 patch. >> >> http://cr.openjdk.java.net/~joehw/jdk8/8014333/webrev/ >> >> >> Thanks, >> Joe From joe.darcy at oracle.com Fri May 10 16:07:34 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 09:07:34 -0700 Subject: Request for Review 8014296: DivModTests should not compare pointers In-Reply-To: <518D14F9.5070305@oracle.com> References: <518D0C05.7080808@oracle.com> <518D0ECD.4040004@oracle.com> <518D115C.9070106@oracle.com> <518D1498.3060109@oracle.com> <518D14F9.5070305@oracle.com> Message-ID: <518D1B46.7050108@oracle.com> Pushed; cheers, -Joe On 05/10/2013 08:40 AM, roger riggs wrote: > Thanks, I'll need help with the push (I'm not a committer for JDK). > > > On 5/10/2013 11:39 AM, Joe Darcy wrote: >> Good to push. >> >> -Joe >> >> On 05/10/2013 08:25 AM, roger riggs wrote: >>> Thanks, the webrev now has the correct copyright change. >>> >>> >>> On 5/10/2013 11:14 AM, Joe Darcy wrote: >>>> On 05/10/2013 08:02 AM, roger riggs wrote: >>>>> Please review this minor correction to DivModTests to address this >>>>> issue: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8014296 >>>>> >>>>> With autoboxing of mixed types primitive and Object, the operators >>>>> == and != >>>>> are interpreted as reference compare instead of value compares. >>>>> The compiler is silent about the likely unintended consequences. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-8014296-DivModTests/ >>>>> >>>>> Thanks, Roger >>>>> >>>> >>>> Roger, >>>> >>>> The copyright range should now be "2012, 2013,". >>>> >>>> Otherwise, the change looks fine. >>>> >>>> -Joe >>> >> > From joe.darcy at oracle.com Fri May 10 16:07:16 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 16:07:16 +0000 Subject: hg: jdk8/tl/jdk: 8014296: DivModTests should not compare pointers Message-ID: <20130510160728.8CBAC489B3@hg.openjdk.java.net> Changeset: c26e0d29249a Author: rriggs Date: 2013-05-10 09:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c26e0d29249a 8014296: DivModTests should not compare pointers Reviewed-by: darcy ! test/java/lang/Math/DivModTests.java From huizhe.wang at oracle.com Fri May 10 16:24:11 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 10 May 2013 16:24:11 +0000 Subject: hg: jdk8/tl/jaxp: 8014333: javadoc error in JAXP 1.5 patch Message-ID: <20130510162417.DA3C9489B5@hg.openjdk.java.net> Changeset: a229726149b4 Author: joehw Date: 2013-05-10 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a229726149b4 8014333: javadoc error in JAXP 1.5 patch Reviewed-by: lancea ! src/javax/xml/stream/XMLInputFactory.java From mike.duigou at oracle.com Fri May 10 17:13:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 10 May 2013 17:13:33 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130510171357.D0F0C489D3@hg.openjdk.java.net> Changeset: 2490769abdfa Author: mduigou Date: 2013-05-10 09:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2490769abdfa 8014316: Use Method Refs in j.u.stream.MatchOps Reviewed-by: dholmes ! src/share/classes/java/util/stream/MatchOps.java Changeset: 9891e4d7d5b3 Author: mduigou Date: 2013-05-10 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9891e4d7d5b3 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java From mike.duigou at oracle.com Fri May 10 17:36:09 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 May 2013 10:36:09 -0700 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C8DCF.4010909@oracle.com> References: <518C8DCF.4010909@oracle.com> Message-ID: <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> The implementation looks OK to me. I like Peter's suggestion of caching the char[] rather than string. I do wish that the cache could be in a soft reference but understand that there are tradeoffs to doing so. I am worried about leaks with this implementation. Another possibility, to go totally nuts, is to consider implementing a form of copy-on-write-following-toString. This would be the exact opposite of "minimal set of changes to address this specific problem" and probably not wise to attempt for Java 8. Just as an FYI, this issue has in-flight conflicts with Martin's ongoing CharSequence.getChars patch. Mike On May 9 2013, at 23:03 , David Holmes wrote: > Short version: > > Cache the value returned by toString and use it to copy-construct a new String on subsequent calls to toString(). Clear the cache on any mutating operation. > > webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ > > Testing: microbenchmark for toString performance; new regression test for correctness; JPRT testset core as a sanity check > > Still TBD - full SE benchmark (?) > > Thanks, > David > --------- > > Long version: > > One of the goals for JDK8 is to provide a path from Java ME CDC to Java SE (or SE Embedded). In the embedded space some pretty old benchmarks still get used for doing comparisons between JRE's. One of which makes heavy use of StringBuffer.toString, without modifying the StringBuffer in between. > > Up to Java 1.4.2 a StringBuffer and a String could share the underlying char[]. This meant that toString simply needed to create a new String that referenced the StringBuffer's char[] with no copying of the array needed. In Java 5 the String/StringBuffer implementations were completely revised: StringBuilder was introduced for non-synchronized use, and a new AbstractStringBuilder base class added for it and StringBuffer. In that implementation toString now has to copy the StringBuffer's char[]. This resulted in a significant performance regression for toString() and a bug - 6219959 - was opened. There is quite an elaborate evaluation in that bug report but bottom line was that "real code doesn't depend on this - won't fix". > > At some stage ME also updated to the new Java 5 code and they also noticed the problem. As a result CDC6 included a variation of the caching strategy that is proposed here. > > Going forward because we want people to be able to compare ME and SE with their familiar benchmarks, we would like to address this corner case and fix it using the caching strategy outlined. As a data point an 8K StringBuffer that takes ~1ms to be converted to a String initially, can process subsequent toString() calls in a few microseconds. So that performance issue is addressed. > > However we've added a write to a field in all the mutating methods which obviously adds some additional computational effort - though I have no doubt it is lost in the noise for all but the smallest of mutating methods. Even so this should be run against regular SE benchmarks to ensure there are no performance regressions there - so if anyone has a suggestion as to the best benchmark to run to exercise StringBuffer (if it exists), please let me know. > > Thanks for reading this far :) From joe.darcy at oracle.com Fri May 10 17:40:25 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 10:40:25 -0700 Subject: JDK 8 code review request for JDK-8014357 Minor refactorings to sun.reflect.generics.reflectiveObjects.* Message-ID: <518D3109.5030202@oracle.com> Hello, Please review this small refactoring of types in sun.reflect.generics.reflectiveObjects.* to use methods in java.util.Objects and the new method in JDK 8 Types.getTypeName. Webrev at http://cr.openjdk.java.net/~darcy/8014357.0/ patch below. Thanks, -Joe diff -r c26e0d29249a src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java Fri May 10 09:06:21 2013 -0700 +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java Fri May 10 10:37:42 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 @@ -27,7 +27,7 @@ import java.lang.reflect.GenericArrayType; import java.lang.reflect.Type; - +import java.util.Objects; /** * Implementation of GenericArrayType interface for core reflection. @@ -81,18 +81,13 @@ if (o instanceof GenericArrayType) { GenericArrayType that = (GenericArrayType) o; - Type thatComponentType = that.getGenericComponentType(); - return genericComponentType == null ? - thatComponentType == null : - genericComponentType.equals(thatComponentType); + return Objects.equals(genericComponentType, that.getGenericComponentType()); } else return false; } @Override public int hashCode() { - return (genericComponentType == null) ? - 0: - genericComponentType.hashCode(); + return Objects.hashCode(genericComponentType); } } diff -r c26e0d29249a src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri May 10 09:06:21 2013 -0700 +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri May 10 10:37:42 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 @@ -33,7 +33,7 @@ import java.lang.reflect.Type; import java.lang.reflect.TypeVariable; import java.util.Arrays; - +import java.util.Objects; /** Implementing class for ParameterizedType interface. */ @@ -47,9 +47,7 @@ Type ownerType) { this.actualTypeArguments = actualTypeArguments; this.rawType = rawType; - if (ownerType != null) { - this.ownerType = ownerType; - } else { this.ownerType = rawType.getDeclaringClass();} + this.ownerType = (ownerType != null) ? ownerType : rawType.getDeclaringClass(); validateConstructorArguments(); } @@ -62,7 +60,6 @@ for (int i = 0; i < actualTypeArguments.length; i++) { // check actuals against formals' bounds } - } /** @@ -189,14 +186,9 @@ return ownerEquality && rawEquality && typeArgEquality; } - return - (ownerType == null ? - thatOwner == null : - ownerType.equals(thatOwner)) && - (rawType == null ? - thatRawType == null : - rawType.equals(thatRawType)) && + Objects.equals(ownerType, thatOwner) && + Objects.equals(rawType, thatRawType) && Arrays.equals(actualTypeArguments, // avoid clone that.getActualTypeArguments()); } else @@ -207,8 +199,8 @@ public int hashCode() { return Arrays.hashCode(actualTypeArguments) ^ - (ownerType == null ? 0 : ownerType.hashCode() ) ^ - (rawType == null ? 0 : rawType.hashCode() ); + Objects.hashCode(ownerType) ^ + Objects.hashCode(rawType); } public String toString() { @@ -239,10 +231,7 @@ for(Type t: actualTypeArguments) { if (!first) sb.append(", "); - if (t instanceof Class) - sb.append(((Class)t).getName()); - else - sb.append(t.toString()); + sb.append(t.getTypeName()); first = false; } sb.append(">"); diff -r c26e0d29249a src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java Fri May 10 09:06:21 2013 -0700 +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java Fri May 10 10:37:42 2013 -0700 @@ -170,13 +170,8 @@ GenericDeclaration thatDecl = that.getGenericDeclaration(); String thatName = that.getName(); - return - (genericDeclaration == null ? - thatDecl == null : - genericDeclaration.equals(thatDecl)) && - (name == null ? - thatName == null : - name.equals(thatName)); + return Objects.equals(genericDeclaration, thatDecl) && + Objects.equals(name, thatName); } else return false; diff -r c26e0d29249a src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java Fri May 10 09:06:21 2013 -0700 +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java Fri May 10 10:37:42 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 @@ -203,10 +203,7 @@ sb.append(" & "); first = false; - if (bound instanceof Class) - sb.append(((Class)bound).getName() ); - else - sb.append(bound.toString()); + sb.append(bound.getTypeName()); } return sb.toString(); } From xueming.shen at oracle.com Fri May 10 17:53:56 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 10 May 2013 10:53:56 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <518AAC67.9080503@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> Message-ID: <518D3434.6020000@oracle.com> Thanks for the review. I have updated the Charset.java to use the init-on-depand holder idiom. I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of adding two more classes, so I leave them asis. Agreed that the ExtendedCahrsets change can be separated, but since we're here already, It would be convenient to just do them together and the "cleaner' code then can be back-port together later when requested. http://cr.openjdk.java.net/~sherman/8012326/webrev/ -Sherman On 05/08/2013 12:49 PM, Mandy Chung wrote: > Hi Sherman, > > I reviewed webrev and also checked out webrev.newECP. While it's good to simplify the synchronization needed in ExtendedCharsets, maybe better to separpate the ExtendedCharsets change from the fix for 8012326 that would require a more detailed review (I can do that next). > > Charset.java > ExtendedCharsets provider only needs to be instantiated once. The ECP initialization can be simplified by using the initialization-on-demand holder idiom to replace the existing initialization logic using the extendedProviderLock and extendedProviderProbed. You could also simply have a holder class to define the lookupExtendedCharset (probably better to rename it to "charsetForName") and charsets() methods to return one or all available charsets from the extended provider respectively. I think that would be cleaner and easy to read. > > MSISO2022JP.java and ISO2022_JP_2.java > Similiarly, it'd be cleaner to use a holder class to initialize the DEC02XX and ENC02XX variable. > > Mandy > > On 5/4/2013 12:05 PM, Xueming Shen wrote: >> Thanks Ulf! >> >> There is another version with a new ExtendedCharsets.java at >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev.newECP/ >> >> I merged the stuff in AbstractCharsetProvider into ExtendedCharsets.java. >> The standardcharset provider now uses the FastCharsetProvider, so there >> is no need to have an abstract class anymore, as long as we are not going >> to add a new or separate the charsets.jar. I kinda remember there was >> a plan to further divide the charsets.jar in the past though... >> >> I took the chance to "clean up" the synchronization mechanism in >> ExtendedCharsets. It appears there are two sync needs here. >> >> One is to protect the "cache" inside lookup(), which triggers the race >> condition if the lookup() gets invoked by multiple threads and the >> "cahce" map gets accessed/updated at the same time, this is reported >> and fixed by 4685305 [1], the original fix is to put the sync block in >> AbstractCharsetProvider.charsetForName(). We put in another sync >> block in iterator.next() for 6898310 [2], which is the trigger of this bug. >> In the new version, I "consolidated" them together into lookup() >> >> Another sync need is for the "init()", in which it may update the aliasMap, >> classMap and aliasNameMap via charset() and deleteCharset() if those >> special properties are defined. There are two sources for the charset()/ >> deleteCharset(), one is from the constructor, one is from the init(), given >> ExtendedCharsets is now singleton and get initialized at class init, these >> should be no race concern between these two sources, so no need to >> have any sync block inside charset() and deleteCharset(), the only thing >> need to defend is inside init(), and all three public methods invoke the >> init() at the beginning of the method body. >> >> It appears I will still have to keep the same logic in Charset to access >> the ExtendedCharset, as it is need to be "probed", just in case it is not >> "installed"... >> >> Yes, there is also room to improve in FastCharsetProvider...I know I >> need pick some time on it. >> >> -Sherman >> >> On 5/4/13 10:09 AM, Ulf Zibis wrote: >>> Hi Sherman, >>> >>> looks good to me. >>> >>> Maybe you like to compare with webrevs from: >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100092 >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100095 >>> >>> -Ulf >>> >>> Am 03.05.2013 06:29, schrieb Xueming Shen: >>>> Hi, >>>> >>>> Please help review the proposed fix for 8012326. >>>> >>>> The direct trigger is the fix we put in #6898310 [1], in which we added the >>>> synchronization to prevent a possible race condition as described in $4685305. >>>> >>>> However it appears the added synchronization triggers another race condition as >>>> showed in this stack trace [4] when run the test case [2][3]. >>>> >>>> The root cause here is >>>> >>>> (1) The ExtendedCharsetProvider is intended to be used as a singleton (as the >>>> probeExtendedProvider + lookupExtendedCharset mechanism in Charset.java), >>>> however this is only true for the Charset.forName()->lookup()...scenario. Multiple >>>> instances of ExtendedCharsetProvider is being created in Charset.availableCharset() >>>> every time it is invoked, via providers()/ServiceLoader.load(). >>>> >>>> (2) ISO2022_JP_2 and MSISO2022JP are provided via ExtendedCharsetProvider, >>>> however both of them have two static variable DEC02{12|08}/ENC02{12|08} that >>>> need to be initialized during the "class initialization", which will indirectly trigger >>>> the invocation of ExtendedCharsetProvider.alisesFor(...) >>>> >>>> (3) static method ExtendedCharsets.aliaseFor() has a hacky implementation that >>>> goes to AbstractCharsetProvider.alise() for lookup, which needs to obtain a lock >>>> on its ExtendedCharesetProvider.instance. This will potential cause race condition >>>> if the "instance" it tries to synchronize on is not its "own" instance. This is possible >>>> because the constructor of ExtendedCharsetProvider overwrites static "instance" >>>> variable with "this". >>>> >>>> Unfortunately as demonstrated in [4], this appears to be what is happening. >>>> The Thread-1/#9 is trying to synchronize on someone else's ExtendedCharsetProvider >>>> instance <0xa4824730> (its own instance should be <0xa4835328>, which it >>>> holds the monitor in the iterator.next()), it is blocked because Thread-0 already holds >>>> the monitor of <0xa4824730> (in its iteratior.next()), but Thread-0 is blocked at >>>> Class.forName0(), which I think is because Thread-1 is inside it already...two theads >>>> are deadlocked. >>>> >>>> A "quick fix/solution" is to remove the direct trigger in ISO2022_JP_2 and >>>> MSISO2022JP to lazily-initialize those static variables as showed in the >>>> webrev. However while this probably will solve the race condition, the multiple >>>> instances of ExtendedCharsetProvider is really not desired. And given the >>>> fact we have already hardwired ExtendedCharsetProvider (as well as the >>>> StandardCharset, for performance reason) for charset lookup/forName(), the >>>> availableCharsets() should also utilize the "singleton" ExtendedCharsetProvider >>>> instanc (extendedCharsetProvider) as well, instead of going to the ServiceLoader >>>> every time for a new instance. The suggested change is to use Charset. >>>> extendedCharsetProvide via probeExtendedProvider() for extended charset >>>> iteration (availableCharset()). Meanwhile, since the ExtendedCharsetProvider/ >>>> charsets.jar should always be in the boot classpath (if installed, and we are >>>> looking up via Class.forName("sun.nio.cs.ext.ExtededCharsetProvider")), there >>>> is really no need for it to be looked up/loaded via the spi mechanism (in >>>> fact it's redundant to load it again after we have lookup/iterate the >>>> hardwired "extendedCharsetProvider". So I removed the spi description from >>>> the charsts.jar as well. >>>> >>>> An alternative is to really implement the singleton pattern in ECP, however >>>> given the existing mechanism we have in Charset.java and the "hacky" init() >>>> implementation we need in ECP, I go with the current approach. >>>> >>>> http://cr.openjdk.java.net/~sherman/8012326/webrev >>>> >>>> Thanks, >>>> Sherman >>>> >>>> [1] http://cr.openjdk.java.net/~sherman/6898310/webrev/ >>>> [2] http://cr.openjdk.java.net/~sherman/8012326/runtest.bat >>>> [3] http://cr.openjdk.java.net/~sherman/8012326/Test.java >>>> [4] http://cr.openjdk.java.net/~sherman/8012326/stacktrace >>>> >>> >> > From mike.duigou at oracle.com Fri May 10 18:03:38 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 May 2013 11:03:38 -0700 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <518CA9DD.9060609@oracle.com> References: <518CA9DD.9060609@oracle.com> Message-ID: <982437AD-86A3-4391-8BDE-ED4BC866E040@oracle.com> The fix looks reasonable to me. Mike On May 10 2013, at 01:03 , Ivan Gerasimov wrote: > Hello everybody! > > GzipInputStream uses SequenceInputStream to concatenate the underlying stream with some data that reside in memory. > SequenceInputStream is implementing in such a way that it closes the stream when it reaches EOS. > > The solution is to wrap the underlying stream with extended FilterInputStream that overrides the close() method. > > BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 > WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ > > Sincerely your, > Ivan > From dean.long at oracle.com Fri May 10 18:10:50 2013 From: dean.long at oracle.com (Dean Long) Date: Fri, 10 May 2013 11:10:50 -0700 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CF29B.7090202@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> Message-ID: <518D382A.9000704@oracle.com> If you really want to bullet-proof ReferenceHandler (and other system threads) against OOME caused by native allocations, then don't forget about monitor inflation if there is contention for "lock" :-) dl On 5/10/2013 6:14 AM, David Holmes wrote: > Hi Peter, > > So it would appear that it is not in fact the "new" that causes the > OOME but the classloading of InterruptedException ? > > I'm not sure I can quite get my head around this late on a Friday > night :) > > David > > On 10/05/2013 9:21 PM, Peter Levart wrote: >> On 05/10/2013 12:52 PM, Peter Levart wrote: >>> While executing the above test with the patch to ReferenceHandler >>> applied, I noticed a strange behaviour. I can reproduce this behaviour >>> reliably on both JDK7 and JDK8. When the patch is applied as proposed: >>> >>> try { >>> lock.wait(); >>> } catch (InterruptedException | >>> OutOfMemoryError x) { } >>> >>> ... I still get the following output from the test (reliably, always): >>> >>> Exception: java.lang.OutOfMemoryError thrown from the >>> UncaughtExceptionHandler in thread "Reference Handler" >>> Exception in thread "main" java.lang.Exception: Reference Handler >>> thread died. >>> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>> >>> But when i change the patch to the following: >>> >>> try { >>> lock.wait(); >>> } catch (OutOfMemoryError | >>> InterruptedException x) { } >>> >>> ...the test reliably and always passes. >>> >>> My explanation to his behaviour is that the order of exception >>> handlers changes the order of class referencing. In the former >>> variation (that still throws OOME) the following seems to be happening: >>> >>> wait() is interrupted and InterruptedException instance creation is >>> attempted. Because this is the 1st reference to InterruptedException >>> class in the lifetime of the JVM, loading of InterruptedException >>> class is attempted which fails because of OOME. This OOME is caught by >>> handler and ignored. But after handling of this OOME, another >>> reference to InterruptedException class is attempted by exception >>> handlers themselves (I don't know how exception handlers work exactly, >>> but I have a feeling this is happening). Because InterruptedException >>> class was not successfully loaded the 1st time tried, every reference >>> to this class must throw NoClassDefFoundError, so this is attempted, >>> but creation of NoClassDefFoundError fails because there's no heap >>> space and another OOME is thrown - this time out of exception handling >>> block, which is propagated and kills the thread. >>> >>> If the order of exception handlers is reversed, this second OOME is >>> caught and ignored. >> >> Hi, >> >> This really seems to be happening (at least approximately, see below) >> because if InterruptedException class is preloaded at start of test, the >> order of exception handling does not have any impact on test. >> >> By disassembling the class-files of both variants, I found the only >> difference is the order of OutOfMemoryError & InterruptedException >> entries found in exception table: >> >> catch (InterruptedException | OutOfMemoryError x) variant has: >> >> public void run(); >> Code: >> 0: invokestatic #2 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >> 3: dup >> 4: astore_2 >> 5: monitorenter >> 6: invokestatic #3 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 9: ifnull 33 >> 12: invokestatic #3 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 15: astore_1 >> 16: aload_1 >> 17: invokestatic #4 // Method >> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 20: invokestatic #5 // Method >> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 23: pop >> 24: aload_1 >> 25: aconst_null >> 26: invokestatic #6 // Method >> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 29: pop >> 30: goto 48 >> * 33: invokestatic #2 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >> ** 36: invokevirtual #7 // Method >> java/lang/Object.wait:()V** >> ** 39: goto 43* >> 42: astore_3 >> 43: aload_2 >> 44: monitorexit >> 45: goto 0 >> 48: aload_2 >> 49: monitorexit >> 50: goto 60 >> 53: astore 4 >> 55: aload_2 >> 56: monitorexit >> 57: aload 4 >> 59: athrow >> 60: aload_1 >> 61: instanceof #10 // class sun/misc/Cleaner >> 64: ifeq 77 >> 67: aload_1 >> 68: checkcast #10 // class sun/misc/Cleaner >> 71: invokevirtual #11 // Method >> sun/misc/Cleaner.clean:()V >> 74: goto 0 >> 77: aload_1 >> 78: getfield #12 // Field >> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >> 81: astore_2 >> 82: aload_2 >> 83: getstatic #13 // Field >> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >> 86: if_acmpeq 95 >> 89: aload_2 >> 90: aload_1 >> 91: invokevirtual #14 // Method >> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >> 94: pop >> 95: goto 0 >> Exception table: >> from to target type >> * 33 39 42 Class java/lang/InterruptedException** >> ** 33 39 42 Class java/lang/OutOfMemoryError* >> 6 45 53 any >> 48 50 53 any >> 53 57 53 any >> >> catch (OutOfMemoryError | InterruptedException x) variant has the >> exactly same bytecodes but the following exception table: >> >> Exception table: >> from to target type >> * 33 39 42 Class java/lang/OutOfMemoryError** >> ** 33 39 42 Class java/lang/InterruptedException* >> 6 45 53 any >> 48 50 53 any >> 53 57 53 any >> >> >> ... so what seems to be happening is a little different but similar to >> what I have explained. In the former variant (that still throws OOME), >> the handler 1st checks for the type of thrown exception against >> InterruptedException class, which fails and attempts to throw >> NoClassDefFoundError which can't be allocated so another OOME is thrown, >> but in the later variant the 1st check is against OutOfMemoryError class >> which succeeds, so the empty handler is executed and no more checks are >> made (no 2nd reference to InterruptedException class). >> >> The fix I proposed in previous mail works (OOME is thrown twice and 2nd >> OOME is handled), but also the following would work (if the order of >> checks follows the source in every compiler): >> >> >> try { >> lock.wait(); >> } catch (OutOfMemoryError x) { } >> catch (InterruptedException x) { } >> >> >> ...the benefit of this is that OOME is never thrown two times. >> >> Regards, Peter >> From aleksey.shipilev at oracle.com Fri May 10 18:10:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 10 May 2013 22:10:45 +0400 Subject: RFR (XS) CR 8014233: java.lang.Thread should be @Contended In-Reply-To: References: <518A8B92.8010509@oracle.com> <518BB08B.8050909@gmail.com> <518CE574.5080703@cs.oswego.edu> Message-ID: <518D3825.2030703@oracle.com> On 05/10/2013 05:27 PM, Aleksey Shipilev wrote: > Although I just tried what Peter had suggested, and got even more > boost on my microbenchmark. This counter-intuitive for me, since no > memory layout differences could explain this in my tests. I will have > to untangle this today, hold on. Ok, I figured this out. That was a performance bug in JMH: http://mail.openjdk.java.net/pipermail/jmh-dev/2013-May/000045.html Re-measuring my old test with that infra bug fixed yields no *consistent* improvements for either @Contended on Thread, nor the TLR state: the fields have minor chance to collide; although it happens sometimes. As Doug noted, this is the lingering problem that can wake up and kick you in the face. So, with the renewed benchmark, which disturbs the other thread: http://cr.openjdk.java.net/~shade/8014233/threadbench.zip ThreadLocalRandom.current().nextInt(): baseline: 356 +- 3 ops/usec @Contended on Thread: 356 +- 2 ops/usec @Contended on TLR: 356 +- 1 ops/usec ThreadLocalRandom.current().nextInt() *and* otherThread.getId(): baseline: 106 +- 12 ops/usec @Contended on Thread: 99 +- 9 ops/usec @Contended on TLR: 323 +- 5 ops/usec Here, the whooping 3x hit just because we accessed the ID of the other thread, and disturbed the cache line containing the TLR state. @Contended on Thread does not help much about this, because those fields are densely packed. The webrev for @Contended on TLR state is here: http://cr.openjdk.java.net/~shade/8014233/webrev.01/ I'd like to proceed with this one instead. Thanks, -Aleksey. From mandy.chung at oracle.com Fri May 10 18:18:13 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 May 2013 11:18:13 -0700 Subject: JDK 8 code review request for JDK-8014357 Minor refactorings to sun.reflect.generics.reflectiveObjects.* In-Reply-To: <518D3109.5030202@oracle.com> References: <518D3109.5030202@oracle.com> Message-ID: <518D39E5.6040404@oracle.com> On 5/10/2013 10:40 AM, Joe Darcy wrote: > Hello, > > Please review this small refactoring of types in > sun.reflect.generics.reflectiveObjects.* to use methods in > java.util.Objects and the new method in JDK 8 Types.getTypeName. > > Webrev at > > http://cr.openjdk.java.net/~darcy/8014357.0/ Looks good. I like this change that makes the code simpler. Mandy From martinrb at google.com Fri May 10 18:34:07 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 May 2013 11:34:07 -0700 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> Message-ID: On Fri, May 10, 2013 at 10:36 AM, Mike Duigou wrote: > The implementation looks OK to me. I like Peter's suggestion of caching > the char[] rather than string. > > I do wish that the cache could be in a soft reference but understand that > there are tradeoffs to doing so. I am worried about leaks with this > implementation. > > Another possibility, to go totally nuts, is to consider implementing a > form of copy-on-write-following-toString. This would be the exact opposite > of "minimal set of changes to address this specific problem" and probably > not wise to attempt for Java 8. > > Just as an FYI, this issue has in-flight conflicts with Martin's ongoing > CharSequence.getChars patch. > I agree with Alan about the cringe factor, and I prefer the old implementation. But it's understandable and not too terrible for real world users, because no one outside of unrealistic benchmarks should be making heavy use of StringBuffer. And: Yes, I will need to update my own changes to StringB*. From jim.gish at oracle.com Fri May 10 19:07:42 2013 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 10 May 2013 15:07:42 -0400 Subject: RFR:7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration In-Reply-To: <51784D34.60806@oracle.com> References: <51784D34.60806@oracle.com> Message-ID: <518D457E.30402@oracle.com> Here's an updated webrev for this fix: http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-failure.2/ The changes from the previous one are: - breaking apart the two tests so that logger initialization in the basic getGlobal()/handler test doesn't cloud the deadlock testing issue. - replacing the references in LogManager to global with getGlobal() (basically to get rid of deprecated usage). Thanks, Jim On 04/24/2013 05:23 PM, Jim Gish wrote: > 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 joe.darcy at oracle.com Fri May 10 19:26:35 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 12:26:35 -0700 Subject: JDK 8 code review request for JDK-8014357 Minor refactorings to sun.reflect.generics.reflectiveObjects.* In-Reply-To: <518D39E5.6040404@oracle.com> References: <518D3109.5030202@oracle.com> <518D39E5.6040404@oracle.com> Message-ID: <518D49EB.4030409@oracle.com> On 05/10/2013 11:18 AM, Mandy Chung wrote: > On 5/10/2013 10:40 AM, Joe Darcy wrote: >> Hello, >> >> Please review this small refactoring of types in >> sun.reflect.generics.reflectiveObjects.* to use methods in >> java.util.Objects and the new method in JDK 8 Types.getTypeName. >> >> Webrev at >> >> http://cr.openjdk.java.net/~darcy/8014357.0/ > > Looks good. I like this change that makes the code simpler. > > Thanks for the quick review Mandy. I was glad to see that code clean up too :-) -Joe From joe.darcy at oracle.com Fri May 10 19:25:50 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 19:25:50 +0000 Subject: hg: jdk8/tl/jdk: 8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.* Message-ID: <20130510192612.8D50F489E7@hg.openjdk.java.net> Changeset: f84b5498b2bb Author: darcy Date: 2013-05-10 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f84b5498b2bb 8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.* Reviewed-by: mchung ! src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java From peter.levart at gmail.com Fri May 10 20:08:28 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 22:08:28 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518D382A.9000704@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> Message-ID: <518D53BC.7050804@gmail.com> On 05/10/2013 08:10 PM, Dean Long wrote: > If you really want to bullet-proof ReferenceHandler (and other system > threads) against OOME caused by native allocations, > then don't forget about monitor inflation if there is contention for > "lock" :-) Aren't monitors C++ objects? Are they allocated from java heap? Regards, Peter > > dl > > On 5/10/2013 6:14 AM, David Holmes wrote: >> Hi Peter, >> >> So it would appear that it is not in fact the "new" that causes the >> OOME but the classloading of InterruptedException ? >> >> I'm not sure I can quite get my head around this late on a Friday >> night :) >> >> David >> >> On 10/05/2013 9:21 PM, Peter Levart wrote: >>> On 05/10/2013 12:52 PM, Peter Levart wrote: >>>> While executing the above test with the patch to ReferenceHandler >>>> applied, I noticed a strange behaviour. I can reproduce this behaviour >>>> reliably on both JDK7 and JDK8. When the patch is applied as proposed: >>>> >>>> try { >>>> lock.wait(); >>>> } catch (InterruptedException | >>>> OutOfMemoryError x) { } >>>> >>>> ... I still get the following output from the test (reliably, always): >>>> >>>> Exception: java.lang.OutOfMemoryError thrown from the >>>> UncaughtExceptionHandler in thread "Reference Handler" >>>> Exception in thread "main" java.lang.Exception: Reference Handler >>>> thread died. >>>> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>>> >>>> But when i change the patch to the following: >>>> >>>> try { >>>> lock.wait(); >>>> } catch (OutOfMemoryError | >>>> InterruptedException x) { } >>>> >>>> ...the test reliably and always passes. >>>> >>>> My explanation to his behaviour is that the order of exception >>>> handlers changes the order of class referencing. In the former >>>> variation (that still throws OOME) the following seems to be >>>> happening: >>>> >>>> wait() is interrupted and InterruptedException instance creation is >>>> attempted. Because this is the 1st reference to InterruptedException >>>> class in the lifetime of the JVM, loading of InterruptedException >>>> class is attempted which fails because of OOME. This OOME is caught by >>>> handler and ignored. But after handling of this OOME, another >>>> reference to InterruptedException class is attempted by exception >>>> handlers themselves (I don't know how exception handlers work exactly, >>>> but I have a feeling this is happening). Because InterruptedException >>>> class was not successfully loaded the 1st time tried, every reference >>>> to this class must throw NoClassDefFoundError, so this is attempted, >>>> but creation of NoClassDefFoundError fails because there's no heap >>>> space and another OOME is thrown - this time out of exception handling >>>> block, which is propagated and kills the thread. >>>> >>>> If the order of exception handlers is reversed, this second OOME is >>>> caught and ignored. >>> >>> Hi, >>> >>> This really seems to be happening (at least approximately, see below) >>> because if InterruptedException class is preloaded at start of test, >>> the >>> order of exception handling does not have any impact on test. >>> >>> By disassembling the class-files of both variants, I found the only >>> difference is the order of OutOfMemoryError & InterruptedException >>> entries found in exception table: >>> >>> catch (InterruptedException | OutOfMemoryError x) variant has: >>> >>> public void run(); >>> Code: >>> 0: invokestatic #2 // Method >>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>> 3: dup >>> 4: astore_2 >>> 5: monitorenter >>> 6: invokestatic #3 // Method >>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>> 9: ifnull 33 >>> 12: invokestatic #3 // Method >>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>> 15: astore_1 >>> 16: aload_1 >>> 17: invokestatic #4 // Method >>> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 20: invokestatic #5 // Method >>> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 23: pop >>> 24: aload_1 >>> 25: aconst_null >>> 26: invokestatic #6 // Method >>> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 29: pop >>> 30: goto 48 >>> * 33: invokestatic #2 // Method >>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >>> ** 36: invokevirtual #7 // Method >>> java/lang/Object.wait:()V** >>> ** 39: goto 43* >>> 42: astore_3 >>> 43: aload_2 >>> 44: monitorexit >>> 45: goto 0 >>> 48: aload_2 >>> 49: monitorexit >>> 50: goto 60 >>> 53: astore 4 >>> 55: aload_2 >>> 56: monitorexit >>> 57: aload 4 >>> 59: athrow >>> 60: aload_1 >>> 61: instanceof #10 // class sun/misc/Cleaner >>> 64: ifeq 77 >>> 67: aload_1 >>> 68: checkcast #10 // class sun/misc/Cleaner >>> 71: invokevirtual #11 // Method >>> sun/misc/Cleaner.clean:()V >>> 74: goto 0 >>> 77: aload_1 >>> 78: getfield #12 // Field >>> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >>> 81: astore_2 >>> 82: aload_2 >>> 83: getstatic #13 // Field >>> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >>> 86: if_acmpeq 95 >>> 89: aload_2 >>> 90: aload_1 >>> 91: invokevirtual #14 // Method >>> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >>> 94: pop >>> 95: goto 0 >>> Exception table: >>> from to target type >>> * 33 39 42 Class java/lang/InterruptedException** >>> ** 33 39 42 Class java/lang/OutOfMemoryError* >>> 6 45 53 any >>> 48 50 53 any >>> 53 57 53 any >>> >>> catch (OutOfMemoryError | InterruptedException x) variant has the >>> exactly same bytecodes but the following exception table: >>> >>> Exception table: >>> from to target type >>> * 33 39 42 Class java/lang/OutOfMemoryError** >>> ** 33 39 42 Class java/lang/InterruptedException* >>> 6 45 53 any >>> 48 50 53 any >>> 53 57 53 any >>> >>> >>> ... so what seems to be happening is a little different but similar to >>> what I have explained. In the former variant (that still throws OOME), >>> the handler 1st checks for the type of thrown exception against >>> InterruptedException class, which fails and attempts to throw >>> NoClassDefFoundError which can't be allocated so another OOME is >>> thrown, >>> but in the later variant the 1st check is against OutOfMemoryError >>> class >>> which succeeds, so the empty handler is executed and no more checks are >>> made (no 2nd reference to InterruptedException class). >>> >>> The fix I proposed in previous mail works (OOME is thrown twice and 2nd >>> OOME is handled), but also the following would work (if the order of >>> checks follows the source in every compiler): >>> >>> >>> try { >>> lock.wait(); >>> } catch (OutOfMemoryError x) { } >>> catch (InterruptedException x) { } >>> >>> >>> ...the benefit of this is that OOME is never thrown two times. >>> >>> Regards, Peter >>> > From peter.levart at gmail.com Fri May 10 20:22:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 May 2013 22:22:48 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518D53BC.7050804@gmail.com> References: <1367333840.2722.118.camel@cirrus> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> <518D53BC.7050804@gmail.com> Message-ID: <518D5718.1030903@gmail.com> On 05/10/2013 10:08 PM, Peter Levart wrote: > > On 05/10/2013 08:10 PM, Dean Long wrote: >> If you really want to bullet-proof ReferenceHandler (and other system >> threads) against OOME caused by native allocations, >> then don't forget about monitor inflation if there is contention for >> "lock" :-) > > Aren't monitors C++ objects? Are they allocated from java heap? > > Regards, Peter Hi Dean, Ah, I see you're suggesting that "native" allocations can also trigger OOME in Java program. Is this true? Regards, Peter > >> >> dl >> >> On 5/10/2013 6:14 AM, David Holmes wrote: >>> Hi Peter, >>> >>> So it would appear that it is not in fact the "new" that causes the >>> OOME but the classloading of InterruptedException ? >>> >>> I'm not sure I can quite get my head around this late on a Friday >>> night :) >>> >>> David >>> >>> On 10/05/2013 9:21 PM, Peter Levart wrote: >>>> On 05/10/2013 12:52 PM, Peter Levart wrote: >>>>> While executing the above test with the patch to ReferenceHandler >>>>> applied, I noticed a strange behaviour. I can reproduce this >>>>> behaviour >>>>> reliably on both JDK7 and JDK8. When the patch is applied as >>>>> proposed: >>>>> >>>>> try { >>>>> lock.wait(); >>>>> } catch (InterruptedException | >>>>> OutOfMemoryError x) { } >>>>> >>>>> ... I still get the following output from the test (reliably, >>>>> always): >>>>> >>>>> Exception: java.lang.OutOfMemoryError thrown from the >>>>> UncaughtExceptionHandler in thread "Reference Handler" >>>>> Exception in thread "main" java.lang.Exception: Reference Handler >>>>> thread died. >>>>> at >>>>> OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>>>> >>>>> But when i change the patch to the following: >>>>> >>>>> try { >>>>> lock.wait(); >>>>> } catch (OutOfMemoryError | >>>>> InterruptedException x) { } >>>>> >>>>> ...the test reliably and always passes. >>>>> >>>>> My explanation to his behaviour is that the order of exception >>>>> handlers changes the order of class referencing. In the former >>>>> variation (that still throws OOME) the following seems to be >>>>> happening: >>>>> >>>>> wait() is interrupted and InterruptedException instance creation is >>>>> attempted. Because this is the 1st reference to InterruptedException >>>>> class in the lifetime of the JVM, loading of InterruptedException >>>>> class is attempted which fails because of OOME. This OOME is >>>>> caught by >>>>> handler and ignored. But after handling of this OOME, another >>>>> reference to InterruptedException class is attempted by exception >>>>> handlers themselves (I don't know how exception handlers work >>>>> exactly, >>>>> but I have a feeling this is happening). Because InterruptedException >>>>> class was not successfully loaded the 1st time tried, every reference >>>>> to this class must throw NoClassDefFoundError, so this is attempted, >>>>> but creation of NoClassDefFoundError fails because there's no heap >>>>> space and another OOME is thrown - this time out of exception >>>>> handling >>>>> block, which is propagated and kills the thread. >>>>> >>>>> If the order of exception handlers is reversed, this second OOME is >>>>> caught and ignored. >>>> >>>> Hi, >>>> >>>> This really seems to be happening (at least approximately, see below) >>>> because if InterruptedException class is preloaded at start of >>>> test, the >>>> order of exception handling does not have any impact on test. >>>> >>>> By disassembling the class-files of both variants, I found the only >>>> difference is the order of OutOfMemoryError & InterruptedException >>>> entries found in exception table: >>>> >>>> catch (InterruptedException | OutOfMemoryError x) variant has: >>>> >>>> public void run(); >>>> Code: >>>> 0: invokestatic #2 // Method >>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>>> 3: dup >>>> 4: astore_2 >>>> 5: monitorenter >>>> 6: invokestatic #3 // Method >>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>> 9: ifnull 33 >>>> 12: invokestatic #3 // Method >>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>> 15: astore_1 >>>> 16: aload_1 >>>> 17: invokestatic #4 // Method >>>> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>> >>>> 20: invokestatic #5 // Method >>>> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>> >>>> 23: pop >>>> 24: aload_1 >>>> 25: aconst_null >>>> 26: invokestatic #6 // Method >>>> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>> >>>> 29: pop >>>> 30: goto 48 >>>> * 33: invokestatic #2 // Method >>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >>>> ** 36: invokevirtual #7 // Method >>>> java/lang/Object.wait:()V** >>>> ** 39: goto 43* >>>> 42: astore_3 >>>> 43: aload_2 >>>> 44: monitorexit >>>> 45: goto 0 >>>> 48: aload_2 >>>> 49: monitorexit >>>> 50: goto 60 >>>> 53: astore 4 >>>> 55: aload_2 >>>> 56: monitorexit >>>> 57: aload 4 >>>> 59: athrow >>>> 60: aload_1 >>>> 61: instanceof #10 // class sun/misc/Cleaner >>>> 64: ifeq 77 >>>> 67: aload_1 >>>> 68: checkcast #10 // class sun/misc/Cleaner >>>> 71: invokevirtual #11 // Method >>>> sun/misc/Cleaner.clean:()V >>>> 74: goto 0 >>>> 77: aload_1 >>>> 78: getfield #12 // Field >>>> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >>>> 81: astore_2 >>>> 82: aload_2 >>>> 83: getstatic #13 // Field >>>> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >>>> 86: if_acmpeq 95 >>>> 89: aload_2 >>>> 90: aload_1 >>>> 91: invokevirtual #14 // Method >>>> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >>>> 94: pop >>>> 95: goto 0 >>>> Exception table: >>>> from to target type >>>> * 33 39 42 Class java/lang/InterruptedException** >>>> ** 33 39 42 Class java/lang/OutOfMemoryError* >>>> 6 45 53 any >>>> 48 50 53 any >>>> 53 57 53 any >>>> >>>> catch (OutOfMemoryError | InterruptedException x) variant has the >>>> exactly same bytecodes but the following exception table: >>>> >>>> Exception table: >>>> from to target type >>>> * 33 39 42 Class java/lang/OutOfMemoryError** >>>> ** 33 39 42 Class java/lang/InterruptedException* >>>> 6 45 53 any >>>> 48 50 53 any >>>> 53 57 53 any >>>> >>>> >>>> ... so what seems to be happening is a little different but similar to >>>> what I have explained. In the former variant (that still throws OOME), >>>> the handler 1st checks for the type of thrown exception against >>>> InterruptedException class, which fails and attempts to throw >>>> NoClassDefFoundError which can't be allocated so another OOME is >>>> thrown, >>>> but in the later variant the 1st check is against OutOfMemoryError >>>> class >>>> which succeeds, so the empty handler is executed and no more checks >>>> are >>>> made (no 2nd reference to InterruptedException class). >>>> >>>> The fix I proposed in previous mail works (OOME is thrown twice and >>>> 2nd >>>> OOME is handled), but also the following would work (if the order of >>>> checks follows the source in every compiler): >>>> >>>> >>>> try { >>>> lock.wait(); >>>> } catch (OutOfMemoryError x) { } >>>> catch (InterruptedException x) { } >>>> >>>> >>>> ...the benefit of this is that OOME is never thrown two times. >>>> >>>> Regards, Peter >>>> >> > From dean.long at oracle.com Fri May 10 20:53:15 2013 From: dean.long at oracle.com (Dean Long) Date: Fri, 10 May 2013 13:53:15 -0700 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518D5718.1030903@gmail.com> References: <1367333840.2722.118.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> <518D53BC.7050804@gmail.c! om> <518D5718.1030903@gmail.com> Message-ID: <518D5E3B.6070706@oracle.com> On 5/10/2013 1:22 PM, Peter Levart wrote: > > On 05/10/2013 10:08 PM, Peter Levart wrote: >> >> On 05/10/2013 08:10 PM, Dean Long wrote: >>> If you really want to bullet-proof ReferenceHandler (and other >>> system threads) against OOME caused by native allocations, >>> then don't forget about monitor inflation if there is contention for >>> "lock" :-) >> >> Aren't monitors C++ objects? Are they allocated from java heap? >> >> Regards, Peter > > Hi Dean, > > Ah, I see you're suggesting that "native" allocations can also trigger > OOME in Java program. Is this true? > That's what I was suggesting, but in the case of object monitors, it looks like the VM will exit if it runs out. Other places where we could fail to allocate native memory, such as class loading or adding to the system dictionary, might not exit the VM, but instead result in some other exception such as NoSuchMethod or ClassNotFound. I haven't investigated all the possibilities, but I just wanted to bring it up as something to consider. dl > Regards, Peter > >> >>> >>> dl >>> >>> On 5/10/2013 6:14 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> So it would appear that it is not in fact the "new" that causes the >>>> OOME but the classloading of InterruptedException ? >>>> >>>> I'm not sure I can quite get my head around this late on a Friday >>>> night :) >>>> >>>> David >>>> >>>> On 10/05/2013 9:21 PM, Peter Levart wrote: >>>>> On 05/10/2013 12:52 PM, Peter Levart wrote: >>>>>> While executing the above test with the patch to ReferenceHandler >>>>>> applied, I noticed a strange behaviour. I can reproduce this >>>>>> behaviour >>>>>> reliably on both JDK7 and JDK8. When the patch is applied as >>>>>> proposed: >>>>>> >>>>>> try { >>>>>> lock.wait(); >>>>>> } catch (InterruptedException | >>>>>> OutOfMemoryError x) { } >>>>>> >>>>>> ... I still get the following output from the test (reliably, >>>>>> always): >>>>>> >>>>>> Exception: java.lang.OutOfMemoryError thrown from the >>>>>> UncaughtExceptionHandler in thread "Reference Handler" >>>>>> Exception in thread "main" java.lang.Exception: Reference Handler >>>>>> thread died. >>>>>> at >>>>>> OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>>>>> >>>>>> But when i change the patch to the following: >>>>>> >>>>>> try { >>>>>> lock.wait(); >>>>>> } catch (OutOfMemoryError | >>>>>> InterruptedException x) { } >>>>>> >>>>>> ...the test reliably and always passes. >>>>>> >>>>>> My explanation to his behaviour is that the order of exception >>>>>> handlers changes the order of class referencing. In the former >>>>>> variation (that still throws OOME) the following seems to be >>>>>> happening: >>>>>> >>>>>> wait() is interrupted and InterruptedException instance creation is >>>>>> attempted. Because this is the 1st reference to InterruptedException >>>>>> class in the lifetime of the JVM, loading of InterruptedException >>>>>> class is attempted which fails because of OOME. This OOME is >>>>>> caught by >>>>>> handler and ignored. But after handling of this OOME, another >>>>>> reference to InterruptedException class is attempted by exception >>>>>> handlers themselves (I don't know how exception handlers work >>>>>> exactly, >>>>>> but I have a feeling this is happening). Because >>>>>> InterruptedException >>>>>> class was not successfully loaded the 1st time tried, every >>>>>> reference >>>>>> to this class must throw NoClassDefFoundError, so this is attempted, >>>>>> but creation of NoClassDefFoundError fails because there's no heap >>>>>> space and another OOME is thrown - this time out of exception >>>>>> handling >>>>>> block, which is propagated and kills the thread. >>>>>> >>>>>> If the order of exception handlers is reversed, this second OOME is >>>>>> caught and ignored. >>>>> >>>>> Hi, >>>>> >>>>> This really seems to be happening (at least approximately, see below) >>>>> because if InterruptedException class is preloaded at start of >>>>> test, the >>>>> order of exception handling does not have any impact on test. >>>>> >>>>> By disassembling the class-files of both variants, I found the only >>>>> difference is the order of OutOfMemoryError & InterruptedException >>>>> entries found in exception table: >>>>> >>>>> catch (InterruptedException | OutOfMemoryError x) variant has: >>>>> >>>>> public void run(); >>>>> Code: >>>>> 0: invokestatic #2 // Method >>>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>>>> 3: dup >>>>> 4: astore_2 >>>>> 5: monitorenter >>>>> 6: invokestatic #3 // Method >>>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>>> 9: ifnull 33 >>>>> 12: invokestatic #3 // Method >>>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>>> 15: astore_1 >>>>> 16: aload_1 >>>>> 17: invokestatic #4 // Method >>>>> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>> >>>>> 20: invokestatic #5 // Method >>>>> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>> >>>>> 23: pop >>>>> 24: aload_1 >>>>> 25: aconst_null >>>>> 26: invokestatic #6 // Method >>>>> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>> >>>>> 29: pop >>>>> 30: goto 48 >>>>> * 33: invokestatic #2 // Method >>>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >>>>> ** 36: invokevirtual #7 // Method >>>>> java/lang/Object.wait:()V** >>>>> ** 39: goto 43* >>>>> 42: astore_3 >>>>> 43: aload_2 >>>>> 44: monitorexit >>>>> 45: goto 0 >>>>> 48: aload_2 >>>>> 49: monitorexit >>>>> 50: goto 60 >>>>> 53: astore 4 >>>>> 55: aload_2 >>>>> 56: monitorexit >>>>> 57: aload 4 >>>>> 59: athrow >>>>> 60: aload_1 >>>>> 61: instanceof #10 // class >>>>> sun/misc/Cleaner >>>>> 64: ifeq 77 >>>>> 67: aload_1 >>>>> 68: checkcast #10 // class >>>>> sun/misc/Cleaner >>>>> 71: invokevirtual #11 // Method >>>>> sun/misc/Cleaner.clean:()V >>>>> 74: goto 0 >>>>> 77: aload_1 >>>>> 78: getfield #12 // Field >>>>> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >>>>> 81: astore_2 >>>>> 82: aload_2 >>>>> 83: getstatic #13 // Field >>>>> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >>>>> 86: if_acmpeq 95 >>>>> 89: aload_2 >>>>> 90: aload_1 >>>>> 91: invokevirtual #14 // Method >>>>> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >>>>> 94: pop >>>>> 95: goto 0 >>>>> Exception table: >>>>> from to target type >>>>> * 33 39 42 Class java/lang/InterruptedException** >>>>> ** 33 39 42 Class java/lang/OutOfMemoryError* >>>>> 6 45 53 any >>>>> 48 50 53 any >>>>> 53 57 53 any >>>>> >>>>> catch (OutOfMemoryError | InterruptedException x) variant has the >>>>> exactly same bytecodes but the following exception table: >>>>> >>>>> Exception table: >>>>> from to target type >>>>> * 33 39 42 Class java/lang/OutOfMemoryError** >>>>> ** 33 39 42 Class java/lang/InterruptedException* >>>>> 6 45 53 any >>>>> 48 50 53 any >>>>> 53 57 53 any >>>>> >>>>> >>>>> ... so what seems to be happening is a little different but >>>>> similar to >>>>> what I have explained. In the former variant (that still throws >>>>> OOME), >>>>> the handler 1st checks for the type of thrown exception against >>>>> InterruptedException class, which fails and attempts to throw >>>>> NoClassDefFoundError which can't be allocated so another OOME is >>>>> thrown, >>>>> but in the later variant the 1st check is against OutOfMemoryError >>>>> class >>>>> which succeeds, so the empty handler is executed and no more >>>>> checks are >>>>> made (no 2nd reference to InterruptedException class). >>>>> >>>>> The fix I proposed in previous mail works (OOME is thrown twice >>>>> and 2nd >>>>> OOME is handled), but also the following would work (if the order of >>>>> checks follows the source in every compiler): >>>>> >>>>> >>>>> try { >>>>> lock.wait(); >>>>> } catch (OutOfMemoryError x) { } >>>>> catch (InterruptedException x) { } >>>>> >>>>> >>>>> ...the benefit of this is that OOME is never thrown two times. >>>>> >>>>> Regards, Peter >>>>> >>> >> > From joe.darcy at oracle.com Fri May 10 21:01:18 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 14:01:18 -0700 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) Message-ID: <518D601E.6070701@oracle.com> Hello, Please (re)review this change to introduce Objects.requireNonNull(T, Supplier): http://cr.openjdk.java.net/~darcy/8014365.0/ The original change had to be pulled out because of a build issue (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build); I'll be asking for a review on build-dev of the build-related change in langtools. The test portion of the patch is slightly different than before because of the intervening changes made for 8013712: Add Objects.nonNull and Objects.isNull Thanks, -Joe From brian.burkhalter at oracle.com Fri May 10 21:19:12 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 10 May 2013 14:19:12 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> Message-ID: On May 9, 2013, at 5:28 PM, Brian Burkhalter wrote: > I just went ahead and filed 8014319 and 8014320 for phases 3 and 4, respectively. They will show up onhttp://bugs.sun.com/bugdatabase after some unspecified delay, probably about a day. Verbiage may be updated as needed. Indeed these showed up: Phase 3: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 Phase 4: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 Brian From dan.xu at oracle.com Fri May 10 21:20:40 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 May 2013 14:20:40 -0700 Subject: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies Message-ID: <518D64A8.1090906@oracle.com> Hi, The FileInputStream.available() method can return a negative value when the file position is beyond the endof afile. This is an unspecified behaviour that has the potential to break applications that expect available to return a value of 0 or greater. The FileInputStream.skip(long) method allows a negative value as its parameter. This conflicts with the specifications of InputStream and FileInputStream classes. They are both long standing behaviours. In the fix, available() has been changed to only return 0 or positive values. And for the skip(long) method, due to the compatibility concern, its behaviour will not be changed. Instead, the related java specs are going to be changed to describe its current behaviour. bug: http://bugs.sun.com/view_bug.do?bug_id=8011136 webrev: http://cr.openjdk.java.net/~dxu/8011136/webrev.00/ Thanks for your review! -Dan From joe.darcy at oracle.com Fri May 10 21:32:00 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 10 May 2013 21:32:00 +0000 Subject: hg: jdk8/tl/langtools: 8014365: Restore Objects.requireNonNull(T, Supplier) Message-ID: <20130510213206.719BD489F4@hg.openjdk.java.net> Changeset: 1c43236f6d69 Author: darcy Date: 2013-05-10 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1c43236f6d69 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: jjg ! makefiles/BuildLangtools.gmk From martinrb at google.com Fri May 10 21:57:17 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 May 2013 14:57:17 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > AbstractStringBuilder:: > > - The impls like insert(int dstOffset, CharSequence s) makes me slightly > uneasy because the private value field escapes to an unknown class. Who > knows what evil (or foolishness) could result? > There is an eternal debate about how much trust to put into these APIs. We have the analogous issue on input where we e.g. call someCollection.toArray() and depend on the collection not to retain a pointer to the array. We do not in general try to protect all of our objects against such abuse, with the exception of String, for which guarantee iron immutability (not counting reflection or Unsafe). Otherwise, we'd have to do the usual do-we-trust-them dance with: if no security manager or caller class is trusted boot class then do the fast thing. But I'd prefer to keep the code as I have it. From martinrb at google.com Fri May 10 22:03:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 May 2013 15:03:55 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > > - There's been some informal discussion of packaging commonly used test > utils as jtreg @library. This could be a good candidate. ArraysCharSequence > is a candidate for testing utils lib. Basic impls that override no defaults > are going to be increasingly important for testing. > > - I like your varargs assertsThrows. I have written a non-varargs one in > test/.../Map/Defaults.java. Your varargs one of necessity violates the > actual, expected, [message] pattern used by other TestNG assertions but I > prefer it. This is also a candidate for utils lib. > > It's good to see internal jdk support libraries emerging. That has been an historic problem. I can relocate assertThrows and ArrayCharSequence if we can agree on a location. They both seem to belong in a jdk-wide location. assertThrows was adapted from a method of the same name in Doug's CVS, where it's still being used with junit. From xueming.shen at oracle.com Fri May 10 22:48:11 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 10 May 2013 15:48:11 -0700 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <518CA9DD.9060609@oracle.com> References: <518CA9DD.9060609@oracle.com> Message-ID: <518D792B.504@oracle.com> The proposed fix does solve the issue. However it appears it does not fix the root cause that triggers this problem. The root cause, or the direct trigger of this bug is the fact that ZipInputStream .availble() is really NOT reliable to tell us whether or not there is any byte "available" to be read from the input stream. The api doc of the ZIS.available() specifies "Returns 0 after EOF has reached for the current entry data, otherwise always return 1.". The implementation is straightforward, public int available() throws IOException { if (entryEOF) { return 0; } else { return 1; } } However, the flag "entryEOF" is only set if a read attempt has been tried and failed (see ZIS.read()), which means if a previous read of the entry succeeded and it actually read all the available bytes from the entry (with a big enough buffer), there is 0 byte available for read, the "flag" is not set, so if you invoke zis.available(), it return 1, but a read() invocation will returns -1 (yes, if you then try zis.available() again , it returns the expected 0). The test below demonstrates this issue. public static void main(String args[]) throws IOException { ZipInputStream zis = new ZipInputStream(new FileInputStream(args[0])); ZipEntry ze; while((ze = zis.getNextEntry()) !=null) { System.out.println("--------------" + ze.getName() + "--------"); byte[] buf = new byte[8102]; while (true) { System.out.println(" zis.available()=" + zis.available()); int n = zis.read(buf, 0, buf.length); System.out.println(" readN=" + n); if (n == -1) break; } } } It is arguable that the this is not an implementation bug, since it is reasonable to argue that the EOF has not been "really" reached yet after the first try, the implementation happens to return all available bytes, so the next read try finally "reached" the EOF, but this obviously is not the expectation. Unfortunately the fix we put in for #4691425 [1] logically depends on in.available() to decide whether or not we need to read a little further, which directly triggers this bug when the ZIS.available() "lies". // If there are more bytes available in "in" or // the leftover in the "inf" is > 26 bytes: // this.trailer(8) + next.header.min(10) + next.trailer(8) // try concatenated case if (this.in.available() > 0 || n > 26) { .... } Not only ZInputStream has this issue, its parent class InflaterStream (and its sibling GZIPInputStream, GZS inherits InflaterStream's available() implementation directly) has the same issue, I do have a bug#7031075 filed against GZIPInputStream. So the proposed fix is more a workaround for this available() issue. The alternative is to fix the issue directly, for example, to change the ZIS's available implementation to something like public int available() throws IOException { ensureOpen(); if (entryEOF || entry == null) return 0; switch (entry.method) { case DEFLATED: return (inf.finished() || inf.needsDictionary()) ? 0 : 1; case STORED: return remaining > 0 ? 1 : 0; default: throw new ZipException("invalid compression method"); } } we probably should go further to simply remove the flag "entryEOF" and move the "deflated" case implementation into InflaterInputStream (to fix 7031075 as well). -Sherman [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/ [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075 On 05/10/2013 01:03 AM, Ivan Gerasimov wrote: > Hello everybody! > > GzipInputStream uses SequenceInputStream to concatenate the underlying stream with some data that reside in memory. > SequenceInputStream is implementing in such a way that it closes the stream when it reaches EOS. > > The solution is to wrap the underlying stream with extended FilterInputStream that overrides the close() method. > > BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 > WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ > > Sincerely your, > Ivan > From dan.xu at oracle.com Fri May 10 22:49:44 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 May 2013 15:49:44 -0700 Subject: RFR: JDK-8014360-Optimize and Refactor the Normalize Process in java.io File Systems Message-ID: <518D7988.6090402@oracle.com> Hi, The normalize() implementations in UnixFileSystem.java and WinNTFileSystem.java can be improved to make it simpler, easier, and more efficient. I have refactoredthecode when working on JDK-8003992. And Iwould like to send it out for a review in this separate bug. Thanks! webrev: http://cr.openjdk.java.net/~dxu/8014360/webrev.00/ -Dan From joe.darcy at oracle.com Fri May 10 23:08:55 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 16:08:55 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: <518D7E07.6070308@oracle.com> On 05/10/2013 03:03 PM, Martin Buchholz wrote: > On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > >> - There's been some informal discussion of packaging commonly used test >> utils as jtreg @library. This could be a good candidate. ArraysCharSequence >> is a candidate for testing utils lib. Basic impls that override no defaults >> are going to be increasingly important for testing. >> >> - I like your varargs assertsThrows. I have written a non-varargs one in >> test/.../Map/Defaults.java. Your varargs one of necessity violates the >> actual, expected, [message] pattern used by other TestNG assertions but I >> prefer it. This is also a candidate for utils lib. >> >> > It's good to see internal jdk support libraries emerging. That has been an > historic problem. > I can relocate assertThrows and ArrayCharSequence if we can agree on a > location. > They both seem to belong in a jdk-wide location. > > assertThrows was adapted from a method of the same name in Doug's CVS, > where it's still being used with junit. I think it would be a fine idea is we started putting such utilities into a new JDK-specific package like, "jdk.testing". -Joe From david.holmes at oracle.com Fri May 10 23:45:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 May 2013 09:45:25 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518D5E3B.6070706@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> <518D53BC.7050804@gmail.c!> <518D5718.1030903@gmail.com> <518D5E3B.6070706@oracle.! com> Message-ID: <518D8695.8090204@oracle.com> On 11/05/2013 6:53 AM, Dean Long wrote: > On 5/10/2013 1:22 PM, Peter Levart wrote: >> >> On 05/10/2013 10:08 PM, Peter Levart wrote: >>> >>> On 05/10/2013 08:10 PM, Dean Long wrote: >>>> If you really want to bullet-proof ReferenceHandler (and other >>>> system threads) against OOME caused by native allocations, >>>> then don't forget about monitor inflation if there is contention for >>>> "lock" :-) Inflation has already occurred if you do an Object.wait() as in this case. >>> Aren't monitors C++ objects? Are they allocated from java heap? >> >> Ah, I see you're suggesting that "native" allocations can also trigger >> OOME in Java program. Is this true? >> > > That's what I was suggesting, but in the case of object monitors, it > looks like the VM will exit if it runs out. > Other places where we could fail to allocate native memory, such as > class loading or adding to the system dictionary, > might not exit the VM, but instead result in some other exception such > as NoSuchMethod or ClassNotFound. > I haven't investigated all the possibilities, but I just wanted to bring > it up as something to consider. Right - most C-heap allocation failures in the VM result in an abort but some will convert to OOME (such as native thread creation related failures). Any test that tries to force an OOME at a particular operation is going to be fragile because you can't know what other allocations might be needed under the covers. As Peter already discovered it might occur during the "new" of InterruptedException, or it might happen during the load/initialization of InterruptedException. So pre-initializing InterruptedException is probably a wise thing to do. Aside we should also run these kind of heap-exhaustion tests with as small a heap as possible :) David ----- > dl > >> Regards, Peter >> >>> >>>> >>>> dl >>>> >>>> On 5/10/2013 6:14 AM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> So it would appear that it is not in fact the "new" that causes the >>>>> OOME but the classloading of InterruptedException ? >>>>> >>>>> I'm not sure I can quite get my head around this late on a Friday >>>>> night :) >>>>> >>>>> David >>>>> >>>>> On 10/05/2013 9:21 PM, Peter Levart wrote: >>>>>> On 05/10/2013 12:52 PM, Peter Levart wrote: >>>>>>> While executing the above test with the patch to ReferenceHandler >>>>>>> applied, I noticed a strange behaviour. I can reproduce this >>>>>>> behaviour >>>>>>> reliably on both JDK7 and JDK8. When the patch is applied as >>>>>>> proposed: >>>>>>> >>>>>>> try { >>>>>>> lock.wait(); >>>>>>> } catch (InterruptedException | >>>>>>> OutOfMemoryError x) { } >>>>>>> >>>>>>> ... I still get the following output from the test (reliably, >>>>>>> always): >>>>>>> >>>>>>> Exception: java.lang.OutOfMemoryError thrown from the >>>>>>> UncaughtExceptionHandler in thread "Reference Handler" >>>>>>> Exception in thread "main" java.lang.Exception: Reference Handler >>>>>>> thread died. >>>>>>> at >>>>>>> OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80) >>>>>>> >>>>>>> But when i change the patch to the following: >>>>>>> >>>>>>> try { >>>>>>> lock.wait(); >>>>>>> } catch (OutOfMemoryError | >>>>>>> InterruptedException x) { } >>>>>>> >>>>>>> ...the test reliably and always passes. >>>>>>> >>>>>>> My explanation to his behaviour is that the order of exception >>>>>>> handlers changes the order of class referencing. In the former >>>>>>> variation (that still throws OOME) the following seems to be >>>>>>> happening: >>>>>>> >>>>>>> wait() is interrupted and InterruptedException instance creation is >>>>>>> attempted. Because this is the 1st reference to InterruptedException >>>>>>> class in the lifetime of the JVM, loading of InterruptedException >>>>>>> class is attempted which fails because of OOME. This OOME is >>>>>>> caught by >>>>>>> handler and ignored. But after handling of this OOME, another >>>>>>> reference to InterruptedException class is attempted by exception >>>>>>> handlers themselves (I don't know how exception handlers work >>>>>>> exactly, >>>>>>> but I have a feeling this is happening). Because >>>>>>> InterruptedException >>>>>>> class was not successfully loaded the 1st time tried, every >>>>>>> reference >>>>>>> to this class must throw NoClassDefFoundError, so this is attempted, >>>>>>> but creation of NoClassDefFoundError fails because there's no heap >>>>>>> space and another OOME is thrown - this time out of exception >>>>>>> handling >>>>>>> block, which is propagated and kills the thread. >>>>>>> >>>>>>> If the order of exception handlers is reversed, this second OOME is >>>>>>> caught and ignored. >>>>>> >>>>>> Hi, >>>>>> >>>>>> This really seems to be happening (at least approximately, see below) >>>>>> because if InterruptedException class is preloaded at start of >>>>>> test, the >>>>>> order of exception handling does not have any impact on test. >>>>>> >>>>>> By disassembling the class-files of both variants, I found the only >>>>>> difference is the order of OutOfMemoryError & InterruptedException >>>>>> entries found in exception table: >>>>>> >>>>>> catch (InterruptedException | OutOfMemoryError x) variant has: >>>>>> >>>>>> public void run(); >>>>>> Code: >>>>>> 0: invokestatic #2 // Method >>>>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>>>>> 3: dup >>>>>> 4: astore_2 >>>>>> 5: monitorenter >>>>>> 6: invokestatic #3 // Method >>>>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>>>> 9: ifnull 33 >>>>>> 12: invokestatic #3 // Method >>>>>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>>>>> 15: astore_1 >>>>>> 16: aload_1 >>>>>> 17: invokestatic #4 // Method >>>>>> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>>> >>>>>> 20: invokestatic #5 // Method >>>>>> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>>> >>>>>> 23: pop >>>>>> 24: aload_1 >>>>>> 25: aconst_null >>>>>> 26: invokestatic #6 // Method >>>>>> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>>>>> >>>>>> 29: pop >>>>>> 30: goto 48 >>>>>> * 33: invokestatic #2 // Method >>>>>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;** >>>>>> ** 36: invokevirtual #7 // Method >>>>>> java/lang/Object.wait:()V** >>>>>> ** 39: goto 43* >>>>>> 42: astore_3 >>>>>> 43: aload_2 >>>>>> 44: monitorexit >>>>>> 45: goto 0 >>>>>> 48: aload_2 >>>>>> 49: monitorexit >>>>>> 50: goto 60 >>>>>> 53: astore 4 >>>>>> 55: aload_2 >>>>>> 56: monitorexit >>>>>> 57: aload 4 >>>>>> 59: athrow >>>>>> 60: aload_1 >>>>>> 61: instanceof #10 // class >>>>>> sun/misc/Cleaner >>>>>> 64: ifeq 77 >>>>>> 67: aload_1 >>>>>> 68: checkcast #10 // class >>>>>> sun/misc/Cleaner >>>>>> 71: invokevirtual #11 // Method >>>>>> sun/misc/Cleaner.clean:()V >>>>>> 74: goto 0 >>>>>> 77: aload_1 >>>>>> 78: getfield #12 // Field >>>>>> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >>>>>> 81: astore_2 >>>>>> 82: aload_2 >>>>>> 83: getstatic #13 // Field >>>>>> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >>>>>> 86: if_acmpeq 95 >>>>>> 89: aload_2 >>>>>> 90: aload_1 >>>>>> 91: invokevirtual #14 // Method >>>>>> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >>>>>> 94: pop >>>>>> 95: goto 0 >>>>>> Exception table: >>>>>> from to target type >>>>>> * 33 39 42 Class java/lang/InterruptedException** >>>>>> ** 33 39 42 Class java/lang/OutOfMemoryError* >>>>>> 6 45 53 any >>>>>> 48 50 53 any >>>>>> 53 57 53 any >>>>>> >>>>>> catch (OutOfMemoryError | InterruptedException x) variant has the >>>>>> exactly same bytecodes but the following exception table: >>>>>> >>>>>> Exception table: >>>>>> from to target type >>>>>> * 33 39 42 Class java/lang/OutOfMemoryError** >>>>>> ** 33 39 42 Class java/lang/InterruptedException* >>>>>> 6 45 53 any >>>>>> 48 50 53 any >>>>>> 53 57 53 any >>>>>> >>>>>> >>>>>> ... so what seems to be happening is a little different but >>>>>> similar to >>>>>> what I have explained. In the former variant (that still throws >>>>>> OOME), >>>>>> the handler 1st checks for the type of thrown exception against >>>>>> InterruptedException class, which fails and attempts to throw >>>>>> NoClassDefFoundError which can't be allocated so another OOME is >>>>>> thrown, >>>>>> but in the later variant the 1st check is against OutOfMemoryError >>>>>> class >>>>>> which succeeds, so the empty handler is executed and no more >>>>>> checks are >>>>>> made (no 2nd reference to InterruptedException class). >>>>>> >>>>>> The fix I proposed in previous mail works (OOME is thrown twice >>>>>> and 2nd >>>>>> OOME is handled), but also the following would work (if the order of >>>>>> checks follows the source in every compiler): >>>>>> >>>>>> >>>>>> try { >>>>>> lock.wait(); >>>>>> } catch (OutOfMemoryError x) { } >>>>>> catch (InterruptedException x) { } >>>>>> >>>>>> >>>>>> ...the benefit of this is that OOME is never thrown two times. >>>>>> >>>>>> Regards, Peter >>>>>> >>>> >>> >> > From mike.duigou at oracle.com Fri May 10 23:46:09 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 May 2013 16:46:09 -0700 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <518D00C3.5040803@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> <518B70B0.30703@oracle.com> <518B7670.4080405@oracle.com> <518B8B67.2060502@cs.oswego.edu> <518D00C3.5040803@oracle.com> Message-ID: <14899129-669F-4151-982B-C1BA9EA25CE2@oracle.com> On May 10 2013, at 07:14 , Chris Hegarty wrote: > Updated webrev and specdiff. > > http://cr.openjdk.java.net/~chegar/8014076/ver.01/specdiff/java/util/Arrays.html Docs changes look fine to me. > http://cr.openjdk.java.net/~chegar/8014076/ver.01/webrev/ ArraysParallelSortHelpers:: - It's strange to see serialversionid defined for classes that will never be serialized. ParallelSorting:: - Arrays.MIN_ARRAY_SORT_GRAN does this reference still work? Otherwise changes look good to me. (Depending very much on regression testing to ensure correctness of the algorithm). > > I incorporated the feedback so far, and reverted the change to make MIN_ARRAY_SORT_GRAN public ( there doesn't appear to be enough justification for this ). > > -Chris. From mandy.chung at oracle.com Fri May 10 23:55:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 May 2013 16:55:24 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <518D3434.6020000@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> Message-ID: <518D88EC.6030804@oracle.com> Sherman, The charsetForName, charsets and aliasesFor methods call init() first and then access the maps with no synchronization. While the maps are being accessed by one thread and system initialization completes, another thread calls charsetForName() that calls init() which will update the maps. So the maps is being updated while being accessed by another thread. So I think the original synchronized(this) is still needed for the charsetForName, charsets and aliasesFor methods for correctness. The maps are only updated once and also only if ExtendedCharsets provider is instantiated before booted and "sun.nio.cs.map" system property is set. I think it's worth further clean up this 2-phase instance initialization since ExtendedCharsets is now a singleton. Would Charset.availableCharsets() and ExtendedCharsets.charsets() not be called during system initialization? If we can restrict that they can't be called, maybe you can move the 2nd phase initialization to ExtendedCharsetsHolder (i.e. calling init() method) and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets instance methods no longer need to call init. Just one thought. You propose to remove AbstractCharsetProvider class. I don't have the history to comment on whether you should keep/remove the AbstractCharsetProvider for other charset providers to extend. Just looking at the current implementation, it's not needed. More comments inlined below. On 5/10/2013 10:53 AM, Xueming Shen wrote: > Thanks for the review. > > I have updated the Charset.java to use the init-on-depand holder idiom. > L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); You would need to use 'epc' and invoke "getInstance" method via reflection to eliminate the static reference to s.n.c.ExtendedCharsets class as it might not be present. I suggest to add these 2 methods in the ExtendedProviderHolder class: static Charset charsetForName(String charsetName) { return (extendedProvider != null) ? extendedProvider.charsetForName(charsetName) : null; } static Iterator charsets() { return (extendedProvider != null) ? extendedProvider.charsets() : Collections.emptyIterator(); } The lookup2() and availableCharsets() methods can be simplified to something like this: if ((cs = standardProvider.charsetForName(charsetName)) != null || - (cs = lookupExtendedCharset(charsetName)) != null || + (cs = ExtendedProviderHolder.charsetForName(charsetName)) != null || (cs = lookupViaProviders(charsetName)) != null) + put(ExtendedProviderHolder.charsets(), m); for (Iterator i = providers(); i.hasNext();) { CharsetProvider cp = i.next(); put(cp.charsets(), m); > I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of > adding > two more classes, so I leave them asis. > Are you concerned of the static footprint of the new class? I think the code is much cleaner but you may think it's overkill: static class Holder { static DoubleByte.Decoder DEC0208 = .... static DoubleByte.Encoder ENC0208 = .... } Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? > Agreed that the ExtendedCahrsets change can be separated, but since > we're here > already, It would be convenient to just do them together and the > "cleaner' code > then can be back-port together later when requested. It's fine with me. I suggest to look into the possibility separating the second phase update to the extended charsets if you want to remove the synchronization on the instance methods. Mandy > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > > -Sherman > From martinrb at google.com Sat May 11 00:15:09 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 May 2013 17:15:09 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > - Could use a @DataProivder for "CharSequence[] seqs = {" style tests. > OK, so I went and learned about DataProvider. Not too painful. Added in some uses of bleeding edge lambda stuff as well to pretty up the GetChars test. Webrev refreshed. From aleksej.efimov at oracle.com Sat May 11 19:43:17 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sat, 11 May 2013 23:43:17 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <517F6DDB.4020809@oracle.com> References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com> <517E7982.8060803@oracle.com> <517F6DDB.4020809@oracle.com> Message-ID: <518E9F55.6030603@oracle.com> Hello Alan, David and other experts, I presents the second version of fix for XPathException class for your review: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.1/ The serialized form remains the same in this patch, as was suggested. I have also done some tests with serialization/deserialization of XPathException class with different JDK versions. The class serialized on JDK with patch was successfully deserialized by JDK versions (6,7,8) without fix and vice versa. -Aleksej On 04/30/2013 11:08 AM, David Holmes wrote: > 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 eliasen at mindspring.com Sun May 12 03:35:41 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Sat, 11 May 2013 21:35:41 -0600 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <7C57030C-9D7D-4C83-8B93-73CB2B949231@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <518B701F.6070906@oracle.com> <7C57030C-9D7D-4C83-8B93-73CB2B949231@oracle.com> Message-ID: <518F0E0D.1090004@mindspring.com> On 05/09/2013 03:02 PM, Brian Burkhalter wrote: >> First you have: >> >> /** >> * The threshold value for using 3-way Toom-Cook multiplication. >> * If the number of ints in both mag arrays are greater than this number, >> * then Toom-Cook multiplication will be used. This value is found >> * experimentally to work well. >> */ >> private static final int TOOM_COOK_THRESHOLD = 75; >> >> but then: >> >> public BigInteger multiply(BigInteger val) { >> if (val.signum == 0 || signum == 0) >> return ZERO; >> >> int xlen = mag.length; >> int ylen = val.mag.length; >> >> if ((xlen < KARATSUBA_THRESHOLD) || (ylen < KARATSUBA_THRESHOLD)) >> { >> .... >> } >> else >> if ((xlen < TOOM_COOK_THRESHOLD) && (ylen < TOOM_COOK_THRESHOLD)) >> return multiplyKaratsuba(this, val); >> else >> return multiplyToomCook3(this, val); >> } >> >> So, is it *both* numbers or *any* of them great than the constant >> that the Toom-Cook algotithm will be used? You're right that the actual code will use Toom-Cook if 1.) both of the numbers are greater than the Karatsuba threshold *and* 2.) at least one of the numbers is greater than the Toom-Cook threshold. That test could go either way (with "and" or "or".) When the sizes of the numbers are in between Karatsuba and Toom-Cook sizes, both algorithms perform approximately equally well. You might choose Karatsuba as it has a somewhat lower constant factor, but as the efficiency of Toom-Cook multiplication increased, (say, with my fast exactDivideBy3 routine and the choice of an optimal Toom-Cook formulation,) it became slightly advantageous to choose Toom-Cook in this vague situation. But it varies with the precise bit patterns of the arguments. The thresholds were tuned to take this into account. I'm not saying that it always makes an optimal choice, but it's hard to make an optimal choice without performing potentially expensive tests. At one point, I had fiddled with "unbalanced" Toom-Cook multiplication where the numbers are of different sizes, but the added code complexity wasn't worth the effort. Note that this logic and the description will change again when Schoenhage-Strassen (SS) multiplication is added back in. The SS multiplication routines have a rather complicated stairstep of thresholds, and describing the thresholds in comments will be difficult. If you want to change the comment to something like my first sentence in the first paragraph, that would be fine. Alternately, we could change the logic to match the comment, but that would probably mean that we should re-tune the thresholds. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From dmitry.degrave at oracle.com Sun May 12 14:54:37 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Sun, 12 May 2013 14:54:37 +0000 Subject: hg: jdk8/tl/jdk: 7021870: GzipInputStream closes underlying stream during reading Message-ID: <20130512145515.EF53A48A18@hg.openjdk.java.net> Changeset: 90f715cceaae Author: dmeetry Date: 2013-05-10 23:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90f715cceaae 7021870: GzipInputStream closes underlying stream during reading Reviewed-by: mduigou Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/java/util/zip/GZIPInputStream.java + test/java/util/zip/GZIP/GZIPInZip.java From Alan.Bateman at oracle.com Sun May 12 19:16:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 May 2013 20:16:04 +0100 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <518D792B.504@oracle.com> References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com> Message-ID: <518FEA74.2010404@oracle.com> On 10/05/2013 23:48, Xueming Shen wrote: > : > > So the proposed fix is more a workaround for this available() issue. The > alternative is to fix the issue directly, for example, to change the > ZIS's > available implementation to something like > > public int available() throws IOException { > ensureOpen(); > if (entryEOF || entry == null) > return 0; > switch (entry.method) { > case DEFLATED: > return (inf.finished() || inf.needsDictionary()) ? 0 : 1; > case STORED: > return remaining > 0 ? 1 : 0; > default: > throw new ZipException("invalid compression method"); > } > } > > we probably should go further to simply remove the flag "entryEOF" > and move the "deflated" case implementation into InflaterInputStream > (to fix 7031075 as well). > Just catching up on this thread now. I agree the proposed patch is really a workaround and we should fix the real issue. The ZIS.available method that you propose looks fine for a first fix but it would be good to sort out 7031075 while we are in the area. -Alan. From tbuktu at hotmail.com Mon May 13 01:07:51 2013 From: tbuktu at hotmail.com (Tim Buktu) Date: Mon, 13 May 2013 03:07:51 +0200 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> Message-ID: On 10.05.2013 23:19, Brian Burkhalter wrote: > Indeed these showed up: > > Phase 3: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 > Phase 4: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 > > Brian > Excellent, thanks! From jonathan.gibbons at oracle.com Mon May 13 01:19:58 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 May 2013 01:19:58 +0000 Subject: hg: jdk8/tl/langtools: 8014363: javac test class ToolTester handles classpath incorrectly Message-ID: <20130513012005.3FE4948A1E@hg.openjdk.java.net> Changeset: e39669aea0bd Author: jjg Date: 2013-05-12 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e39669aea0bd 8014363: javac test class ToolTester handles classpath incorrectly Reviewed-by: ksrini ! test/tools/javac/api/6406133/T6406133.java ! test/tools/javac/api/6410643/T6410643.java ! test/tools/javac/api/6411310/T6411310.java ! test/tools/javac/api/6411333/T6411333.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6415780/T6415780.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6421756/T6421756.java ! test/tools/javac/api/6422215/T6422215.java ! test/tools/javac/api/6422327/T6422327.java ! test/tools/javac/api/6423003/T6423003.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/6437349/T6437349.java ! test/tools/javac/api/6437999/T6437999.java ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/6733837/T6733837.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/guide/Test.java ! test/tools/javac/api/lib/ToolTester.java From david.holmes at oracle.com Mon May 13 07:12:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2013 17:12:09 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> Message-ID: <51909249.6060506@oracle.com> Thanks for all the feedback and discussion. I've rewritten the patch to use Peter's suggestion of caching the char[] instead of the actual String: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ I too am concerned that any form of caching that avoids the array-copy (which is the crux of the issue) is going to incur a 2x space penalty. I can imagine old but well-behaved code that uses StringBuffer rather than StringBuilder where very long buffers are created and toString() only called once - and they may get immediate or subsequent OOME due to the extra char[]; or excessive GC activity might be induced if a lot of StringBuffers are used. So I tried to implement a simple copy-on-write-if-shared (COWIS) scheme: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v4/ but I must have done something silly as the resulting JDK won't run - for some reason it causes classes and resources to not be found. :( David ----- On 11/05/2013 3:36 AM, Mike Duigou wrote: > The implementation looks OK to me. I like Peter's suggestion of caching the char[] rather than string. > > I do wish that the cache could be in a soft reference but understand that there are tradeoffs to doing so. I am worried about leaks with this implementation. > > Another possibility, to go totally nuts, is to consider implementing a form of copy-on-write-following-toString. This would be the exact opposite of "minimal set of changes to address this specific problem" and probably not wise to attempt for Java 8. > > Just as an FYI, this issue has in-flight conflicts with Martin's ongoing CharSequence.getChars patch. > > Mike > > On May 9 2013, at 23:03 , David Holmes wrote: > >> Short version: >> >> Cache the value returned by toString and use it to copy-construct a new String on subsequent calls to toString(). Clear the cache on any mutating operation. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ >> >> Testing: microbenchmark for toString performance; new regression test for correctness; JPRT testset core as a sanity check >> >> Still TBD - full SE benchmark (?) >> >> Thanks, >> David >> --------- >> >> Long version: >> >> One of the goals for JDK8 is to provide a path from Java ME CDC to Java SE (or SE Embedded). In the embedded space some pretty old benchmarks still get used for doing comparisons between JRE's. One of which makes heavy use of StringBuffer.toString, without modifying the StringBuffer in between. >> >> Up to Java 1.4.2 a StringBuffer and a String could share the underlying char[]. This meant that toString simply needed to create a new String that referenced the StringBuffer's char[] with no copying of the array needed. In Java 5 the String/StringBuffer implementations were completely revised: StringBuilder was introduced for non-synchronized use, and a new AbstractStringBuilder base class added for it and StringBuffer. In that implementation toString now has to copy the StringBuffer's char[]. This resulted in a significant performance regression for toString() and a bug - 6219959 - was opened. There is quite an elaborate evaluation in that bug report but bottom line was that "real code doesn't depend on this - won't fix". >> >> At some stage ME also updated to the new Java 5 code and they also noticed the problem. As a result CDC6 included a variation of the caching strategy that is proposed here. >> >> Going forward because we want people to be able to compare ME and SE with their familiar benchmarks, we would like to address this corner case and fix it using the caching strategy outlined. As a data point an 8K StringBuffer that takes ~1ms to be converted to a String initially, can process subsequent toString() calls in a few microseconds. So that performance issue is addressed. >> >> However we've added a write to a field in all the mutating methods which obviously adds some additional computational effort - though I have no doubt it is lost in the noise for all but the smallest of mutating methods. Even so this should be run against regular SE benchmarks to ensure there are no performance regressions there - so if anyone has a suggestion as to the best benchmark to run to exercise StringBuffer (if it exists), please let me know. >> >> Thanks for reading this far :) > From forax at univ-mlv.fr Mon May 13 08:07:02 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 May 2013 10:07:02 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51909249.6060506@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> Message-ID: <51909F26.8000904@univ-mlv.fr> Hi David, On 05/13/2013 09:12 AM, David Holmes wrote: > Thanks for all the feedback and discussion. I've rewritten the patch > to use Peter's suggestion of caching the char[] instead of the actual > String: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ > > I too am concerned that any form of caching that avoids the array-copy > (which is the crux of the issue) is going to incur a 2x space penalty. > I can imagine old but well-behaved code that uses StringBuffer rather > than StringBuilder where very long buffers are created and toString() > only called once - and they may get immediate or subsequent OOME due > to the extra char[]; or excessive GC activity might be induced if a > lot of StringBuffers are used. > > So I tried to implement a simple copy-on-write-if-shared (COWIS) scheme: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v4/ > > but I must have done something silly as the resulting JDK won't run - > for some reason it causes classes and resources to not be found. :( I don't know if it's the only error but take a look to the constructor String(char[], boolean), you will understand what's wrong. The other possible source of errors is that the VM has some string optimizations that recognize patterns like buffer.append(s).append(s2).toString(). > > David > ----- R?mi > > On 11/05/2013 3:36 AM, Mike Duigou wrote: >> The implementation looks OK to me. I like Peter's suggestion of >> caching the char[] rather than string. >> >> I do wish that the cache could be in a soft reference but understand >> that there are tradeoffs to doing so. I am worried about leaks with >> this implementation. >> >> Another possibility, to go totally nuts, is to consider implementing >> a form of copy-on-write-following-toString. This would be the exact >> opposite of "minimal set of changes to address this specific problem" >> and probably not wise to attempt for Java 8. >> >> Just as an FYI, this issue has in-flight conflicts with Martin's >> ongoing CharSequence.getChars patch. >> >> Mike >> >> On May 9 2013, at 23:03 , David Holmes wrote: >> >>> Short version: >>> >>> Cache the value returned by toString and use it to copy-construct a >>> new String on subsequent calls to toString(). Clear the cache on any >>> mutating operation. >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ >>> >>> Testing: microbenchmark for toString performance; new regression >>> test for correctness; JPRT testset core as a sanity check >>> >>> Still TBD - full SE benchmark (?) >>> >>> Thanks, >>> David >>> --------- >>> >>> Long version: >>> >>> One of the goals for JDK8 is to provide a path from Java ME CDC to >>> Java SE (or SE Embedded). In the embedded space some pretty old >>> benchmarks still get used for doing comparisons between JRE's. One >>> of which makes heavy use of StringBuffer.toString, without modifying >>> the StringBuffer in between. >>> >>> Up to Java 1.4.2 a StringBuffer and a String could share the >>> underlying char[]. This meant that toString simply needed to create >>> a new String that referenced the StringBuffer's char[] with no >>> copying of the array needed. In Java 5 the String/StringBuffer >>> implementations were completely revised: StringBuilder was >>> introduced for non-synchronized use, and a new AbstractStringBuilder >>> base class added for it and StringBuffer. In that implementation >>> toString now has to copy the StringBuffer's char[]. This resulted in >>> a significant performance regression for toString() and a bug - >>> 6219959 - was opened. There is quite an elaborate evaluation in that >>> bug report but bottom line was that "real code doesn't depend on >>> this - won't fix". >>> >>> At some stage ME also updated to the new Java 5 code and they also >>> noticed the problem. As a result CDC6 included a variation of the >>> caching strategy that is proposed here. >>> >>> Going forward because we want people to be able to compare ME and SE >>> with their familiar benchmarks, we would like to address this corner >>> case and fix it using the caching strategy outlined. As a data point >>> an 8K StringBuffer that takes ~1ms to be converted to a String >>> initially, can process subsequent toString() calls in a few >>> microseconds. So that performance issue is addressed. >>> >>> However we've added a write to a field in all the mutating methods >>> which obviously adds some additional computational effort - though I >>> have no doubt it is lost in the noise for all but the smallest of >>> mutating methods. Even so this should be run against regular SE >>> benchmarks to ensure there are no performance regressions there - so >>> if anyone has a suggestion as to the best benchmark to run to >>> exercise StringBuffer (if it exists), please let me know. >>> >>> Thanks for reading this far :) >> From david.holmes at oracle.com Mon May 13 08:38:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2013 18:38:57 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51909F26.8000904@univ-mlv.fr> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51909F26.8000904@univ-mlv.fr> Message-ID: <5190A6A1.4030305@oracle.com> On 13/05/2013 6:07 PM, Remi Forax wrote: > Hi David, > > On 05/13/2013 09:12 AM, David Holmes wrote: >> Thanks for all the feedback and discussion. I've rewritten the patch >> to use Peter's suggestion of caching the char[] instead of the actual >> String: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >> >> I too am concerned that any form of caching that avoids the array-copy >> (which is the crux of the issue) is going to incur a 2x space penalty. >> I can imagine old but well-behaved code that uses StringBuffer rather >> than StringBuilder where very long buffers are created and toString() >> only called once - and they may get immediate or subsequent OOME due >> to the extra char[]; or excessive GC activity might be induced if a >> lot of StringBuffers are used. >> >> So I tried to implement a simple copy-on-write-if-shared (COWIS) scheme: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v4/ >> >> but I must have done something silly as the resulting JDK won't run - >> for some reason it causes classes and resources to not be found. :( > > I don't know if it's the only error but take a look to the constructor > String(char[], boolean), you will understand what's wrong. No, that's the intended constructor - we want to share the char[] bewtween the StringBuffer and String until the StringBuffer is modified. > The other possible source of errors is that the VM has some string > optimizations that > recognize patterns like buffer.append(s).append(s2).toString(). Hmmmm, if there are intriniscs for StringBuffer then there may be a problem with getting the sharing right. But I still can't see anything to cause the bizarre behaviour I'm seeing. I do note that my implementation is a little naive/simplistic as in some cases we will potentially copy the array twice eg once for COWIS then again to expand it for an append. :( Thanks, David >> >> David >> ----- > > R?mi > >> >> On 11/05/2013 3:36 AM, Mike Duigou wrote: >>> The implementation looks OK to me. I like Peter's suggestion of >>> caching the char[] rather than string. >>> >>> I do wish that the cache could be in a soft reference but understand >>> that there are tradeoffs to doing so. I am worried about leaks with >>> this implementation. >>> >>> Another possibility, to go totally nuts, is to consider implementing >>> a form of copy-on-write-following-toString. This would be the exact >>> opposite of "minimal set of changes to address this specific problem" >>> and probably not wise to attempt for Java 8. >>> >>> Just as an FYI, this issue has in-flight conflicts with Martin's >>> ongoing CharSequence.getChars patch. >>> >>> Mike >>> >>> On May 9 2013, at 23:03 , David Holmes wrote: >>> >>>> Short version: >>>> >>>> Cache the value returned by toString and use it to copy-construct a >>>> new String on subsequent calls to toString(). Clear the cache on any >>>> mutating operation. >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ >>>> >>>> Testing: microbenchmark for toString performance; new regression >>>> test for correctness; JPRT testset core as a sanity check >>>> >>>> Still TBD - full SE benchmark (?) >>>> >>>> Thanks, >>>> David >>>> --------- >>>> >>>> Long version: >>>> >>>> One of the goals for JDK8 is to provide a path from Java ME CDC to >>>> Java SE (or SE Embedded). In the embedded space some pretty old >>>> benchmarks still get used for doing comparisons between JRE's. One >>>> of which makes heavy use of StringBuffer.toString, without modifying >>>> the StringBuffer in between. >>>> >>>> Up to Java 1.4.2 a StringBuffer and a String could share the >>>> underlying char[]. This meant that toString simply needed to create >>>> a new String that referenced the StringBuffer's char[] with no >>>> copying of the array needed. In Java 5 the String/StringBuffer >>>> implementations were completely revised: StringBuilder was >>>> introduced for non-synchronized use, and a new AbstractStringBuilder >>>> base class added for it and StringBuffer. In that implementation >>>> toString now has to copy the StringBuffer's char[]. This resulted in >>>> a significant performance regression for toString() and a bug - >>>> 6219959 - was opened. There is quite an elaborate evaluation in that >>>> bug report but bottom line was that "real code doesn't depend on >>>> this - won't fix". >>>> >>>> At some stage ME also updated to the new Java 5 code and they also >>>> noticed the problem. As a result CDC6 included a variation of the >>>> caching strategy that is proposed here. >>>> >>>> Going forward because we want people to be able to compare ME and SE >>>> with their familiar benchmarks, we would like to address this corner >>>> case and fix it using the caching strategy outlined. As a data point >>>> an 8K StringBuffer that takes ~1ms to be converted to a String >>>> initially, can process subsequent toString() calls in a few >>>> microseconds. So that performance issue is addressed. >>>> >>>> However we've added a write to a field in all the mutating methods >>>> which obviously adds some additional computational effort - though I >>>> have no doubt it is lost in the noise for all but the smallest of >>>> mutating methods. Even so this should be run against regular SE >>>> benchmarks to ensure there are no performance regressions there - so >>>> if anyone has a suggestion as to the best benchmark to run to >>>> exercise StringBuffer (if it exists), please let me know. >>>> >>>> Thanks for reading this far :) >>> > From peter.levart at gmail.com Mon May 13 08:39:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 13 May 2013 10:39:31 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51909F26.8000904@univ-mlv.fr> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51909F26.8000904@univ-mlv.fr> Message-ID: <5190A6C3.8040209@gmail.com> On 05/13/2013 10:07 AM, Remi Forax wrote: > Hi David, > > On 05/13/2013 09:12 AM, David Holmes wrote: >> Thanks for all the feedback and discussion. I've rewritten the patch >> to use Peter's suggestion of caching the char[] instead of the actual >> String: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >> >> I too am concerned that any form of caching that avoids the >> array-copy (which is the crux of the issue) is going to incur a 2x >> space penalty. I can imagine old but well-behaved code that uses >> StringBuffer rather than StringBuilder where very long buffers are >> created and toString() only called once - and they may get immediate >> or subsequent OOME due to the extra char[]; or excessive GC activity >> might be induced if a lot of StringBuffers are used. >> >> So I tried to implement a simple copy-on-write-if-shared (COWIS) scheme: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v4/ >> >> but I must have done something silly as the resulting JDK won't run - >> for some reason it causes classes and resources to not be found. :( > > I don't know if it's the only error but take a look to the constructor > String(char[], boolean), > you will understand what's wrong. Hi David, R?mi, I think the problem is the toString() method (have you had the same thing in mind, R?mi?): 686 @Override 687 public synchronized String toString() { 688 isShared = true; 689 return new String(value, true); 690 } ...the returned String is always constructed with the whole 'value' array. It should only take the 1st 'count' chars... I think that toString array caching aspect and copy-on-write aspect can only be combined in situations when 'count == value.length'. Otherwise they are different aspects and the copy-on-write aspect which can only be used when count == value.length, could be useful also in StringBuilder, so it should perhaps be built into the AbstractStringBuilder logic. Although it can only be effective when count == value.length, the performance concious code could benefit (when logic can predict the final length of resulting String, the building of it could be performed without extra array copying). For example, to concatenate 2 Strings most optimally, the following would not be doing any more copies than necessary: new StringBuilder(s1.length() + s2.length()).append(s1).append(s2).toString(); Regards, Peter > > The other possible source of errors is that the VM has some string > optimizations that > recognize patterns like buffer.append(s).append(s2).toString(). > >> >> David >> ----- > > R?mi > >> >> On 11/05/2013 3:36 AM, Mike Duigou wrote: >>> The implementation looks OK to me. I like Peter's suggestion of >>> caching the char[] rather than string. >>> >>> I do wish that the cache could be in a soft reference but understand >>> that there are tradeoffs to doing so. I am worried about leaks with >>> this implementation. >>> >>> Another possibility, to go totally nuts, is to consider implementing >>> a form of copy-on-write-following-toString. This would be the exact >>> opposite of "minimal set of changes to address this specific >>> problem" and probably not wise to attempt for Java 8. >>> >>> Just as an FYI, this issue has in-flight conflicts with Martin's >>> ongoing CharSequence.getChars patch. >>> >>> Mike >>> >>> On May 9 2013, at 23:03 , David Holmes wrote: >>> >>>> Short version: >>>> >>>> Cache the value returned by toString and use it to copy-construct a >>>> new String on subsequent calls to toString(). Clear the cache on >>>> any mutating operation. >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ >>>> >>>> Testing: microbenchmark for toString performance; new regression >>>> test for correctness; JPRT testset core as a sanity check >>>> >>>> Still TBD - full SE benchmark (?) >>>> >>>> Thanks, >>>> David >>>> --------- >>>> >>>> Long version: >>>> >>>> One of the goals for JDK8 is to provide a path from Java ME CDC to >>>> Java SE (or SE Embedded). In the embedded space some pretty old >>>> benchmarks still get used for doing comparisons between JRE's. One >>>> of which makes heavy use of StringBuffer.toString, without >>>> modifying the StringBuffer in between. >>>> >>>> Up to Java 1.4.2 a StringBuffer and a String could share the >>>> underlying char[]. This meant that toString simply needed to create >>>> a new String that referenced the StringBuffer's char[] with no >>>> copying of the array needed. In Java 5 the String/StringBuffer >>>> implementations were completely revised: StringBuilder was >>>> introduced for non-synchronized use, and a new >>>> AbstractStringBuilder base class added for it and StringBuffer. In >>>> that implementation toString now has to copy the StringBuffer's >>>> char[]. This resulted in a significant performance regression for >>>> toString() and a bug - 6219959 - was opened. There is quite an >>>> elaborate evaluation in that bug report but bottom line was that >>>> "real code doesn't depend on this - won't fix". >>>> >>>> At some stage ME also updated to the new Java 5 code and they also >>>> noticed the problem. As a result CDC6 included a variation of the >>>> caching strategy that is proposed here. >>>> >>>> Going forward because we want people to be able to compare ME and >>>> SE with their familiar benchmarks, we would like to address this >>>> corner case and fix it using the caching strategy outlined. As a >>>> data point an 8K StringBuffer that takes ~1ms to be converted to a >>>> String initially, can process subsequent toString() calls in a few >>>> microseconds. So that performance issue is addressed. >>>> >>>> However we've added a write to a field in all the mutating methods >>>> which obviously adds some additional computational effort - though >>>> I have no doubt it is lost in the noise for all but the smallest of >>>> mutating methods. Even so this should be run against regular SE >>>> benchmarks to ensure there are no performance regressions there - >>>> so if anyone has a suggestion as to the best benchmark to run to >>>> exercise StringBuffer (if it exists), please let me know. >>>> >>>> Thanks for reading this far :) >>> > From david.holmes at oracle.com Mon May 13 08:45:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2013 18:45:07 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <5190A6C3.8040209@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51909F26.8000904@univ-mlv.fr> <5190A6C3.8040209@gmail.com> Message-ID: <5190A813.7010207@oracle.com> On 13/05/2013 6:39 PM, Peter Levart wrote: > On 05/13/2013 10:07 AM, Remi Forax wrote: >> Hi David, >> >> On 05/13/2013 09:12 AM, David Holmes wrote: >>> Thanks for all the feedback and discussion. I've rewritten the patch >>> to use Peter's suggestion of caching the char[] instead of the actual >>> String: >>> >>> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >>> >>> I too am concerned that any form of caching that avoids the >>> array-copy (which is the crux of the issue) is going to incur a 2x >>> space penalty. I can imagine old but well-behaved code that uses >>> StringBuffer rather than StringBuilder where very long buffers are >>> created and toString() only called once - and they may get immediate >>> or subsequent OOME due to the extra char[]; or excessive GC activity >>> might be induced if a lot of StringBuffers are used. >>> >>> So I tried to implement a simple copy-on-write-if-shared (COWIS) scheme: >>> >>> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v4/ >>> >>> but I must have done something silly as the resulting JDK won't run - >>> for some reason it causes classes and resources to not be found. :( >> >> I don't know if it's the only error but take a look to the constructor >> String(char[], boolean), >> you will understand what's wrong. > > Hi David, R?mi, > > I think the problem is the toString() method (have you had the same > thing in mind, R?mi?): > > 686 @Override > 687 public synchronized String toString() { > 688 isShared = true; > 689 return new String(value, true); > 690 } > > ...the returned String is always constructed with the whole 'value' > array. It should only take the 1st 'count' chars... Ah! Yes now I see - I said it was a silly mistake. > I think that toString array caching aspect and copy-on-write aspect can > only be combined in situations when 'count == value.length'. Otherwise Right so for this simple StringBuffer case we are basically stuck with the memory waste. > they are different aspects and the copy-on-write aspect which can only > be used when count == value.length, could be useful also in > StringBuilder, so it should perhaps be built into the > AbstractStringBuilder logic. Although it can only be effective when > count == value.length, the performance concious code could benefit (when > logic can predict the final length of resulting String, the building of > it could be performed without extra array copying). This is going too far afield. The change becomes too significant for this stage of JDK8 release. Thanks, David > For example, to concatenate 2 Strings most optimally, the following > would not be doing any more copies than necessary: > > new StringBuilder(s1.length() + > s2.length()).append(s1).append(s2).toString(); > > Regards, Peter > >> >> The other possible source of errors is that the VM has some string >> optimizations that >> recognize patterns like buffer.append(s).append(s2).toString(). >> >>> >>> David >>> ----- >> >> R?mi >> >>> >>> On 11/05/2013 3:36 AM, Mike Duigou wrote: >>>> The implementation looks OK to me. I like Peter's suggestion of >>>> caching the char[] rather than string. >>>> >>>> I do wish that the cache could be in a soft reference but understand >>>> that there are tradeoffs to doing so. I am worried about leaks with >>>> this implementation. >>>> >>>> Another possibility, to go totally nuts, is to consider implementing >>>> a form of copy-on-write-following-toString. This would be the exact >>>> opposite of "minimal set of changes to address this specific >>>> problem" and probably not wise to attempt for Java 8. >>>> >>>> Just as an FYI, this issue has in-flight conflicts with Martin's >>>> ongoing CharSequence.getChars patch. >>>> >>>> Mike >>>> >>>> On May 9 2013, at 23:03 , David Holmes wrote: >>>> >>>>> Short version: >>>>> >>>>> Cache the value returned by toString and use it to copy-construct a >>>>> new String on subsequent calls to toString(). Clear the cache on >>>>> any mutating operation. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ >>>>> >>>>> Testing: microbenchmark for toString performance; new regression >>>>> test for correctness; JPRT testset core as a sanity check >>>>> >>>>> Still TBD - full SE benchmark (?) >>>>> >>>>> Thanks, >>>>> David >>>>> --------- >>>>> >>>>> Long version: >>>>> >>>>> One of the goals for JDK8 is to provide a path from Java ME CDC to >>>>> Java SE (or SE Embedded). In the embedded space some pretty old >>>>> benchmarks still get used for doing comparisons between JRE's. One >>>>> of which makes heavy use of StringBuffer.toString, without >>>>> modifying the StringBuffer in between. >>>>> >>>>> Up to Java 1.4.2 a StringBuffer and a String could share the >>>>> underlying char[]. This meant that toString simply needed to create >>>>> a new String that referenced the StringBuffer's char[] with no >>>>> copying of the array needed. In Java 5 the String/StringBuffer >>>>> implementations were completely revised: StringBuilder was >>>>> introduced for non-synchronized use, and a new >>>>> AbstractStringBuilder base class added for it and StringBuffer. In >>>>> that implementation toString now has to copy the StringBuffer's >>>>> char[]. This resulted in a significant performance regression for >>>>> toString() and a bug - 6219959 - was opened. There is quite an >>>>> elaborate evaluation in that bug report but bottom line was that >>>>> "real code doesn't depend on this - won't fix". >>>>> >>>>> At some stage ME also updated to the new Java 5 code and they also >>>>> noticed the problem. As a result CDC6 included a variation of the >>>>> caching strategy that is proposed here. >>>>> >>>>> Going forward because we want people to be able to compare ME and >>>>> SE with their familiar benchmarks, we would like to address this >>>>> corner case and fix it using the caching strategy outlined. As a >>>>> data point an 8K StringBuffer that takes ~1ms to be converted to a >>>>> String initially, can process subsequent toString() calls in a few >>>>> microseconds. So that performance issue is addressed. >>>>> >>>>> However we've added a write to a field in all the mutating methods >>>>> which obviously adds some additional computational effort - though >>>>> I have no doubt it is lost in the noise for all but the smallest of >>>>> mutating methods. Even so this should be run against regular SE >>>>> benchmarks to ensure there are no performance regressions there - >>>>> so if anyone has a suggestion as to the best benchmark to run to >>>>> exercise StringBuffer (if it exists), please let me know. >>>>> >>>>> Thanks for reading this far :) >>>> >> > From fweimer at redhat.com Mon May 13 10:03:12 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 13 May 2013 12:03:12 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <518C8DCF.4010909@oracle.com> References: <518C8DCF.4010909@oracle.com> Message-ID: <5190BA60.6010102@redhat.com> On 05/10/2013 08:03 AM, David Holmes wrote: > Short version: > > Cache the value returned by toString and use it to copy-construct a new > String on subsequent calls to toString(). Clear the cache on any > mutating operation. > > webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/ Shouldn't you clear the cache before the modification, in case the modification throws an exception mid-way? But you cache String (and not char[]s), so it's probably not that important. -- Florian Weimer / Red Hat Product Security Team From eliasen at mindspring.com Mon May 13 11:26:38 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Mon, 13 May 2013 05:26:38 -0600 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> Message-ID: <5190CDEE.6030902@mindspring.com> On 05/10/2013 03:19 PM, Brian Burkhalter wrote: > > On May 9, 2013, at 5:28 PM, Brian Burkhalter wrote: > >> I just went ahead and filed 8014319 and 8014320 for phases 3 and 4, respectively. They will show up onhttp://bugs.sun.com/bugdatabase after some unspecified delay, probably about a day. Verbiage may be updated as needed. > > Indeed these showed up: > > Phase 3: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 > Phase 4: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 Thanks, Brian! Another minor note is that you might want to correct "reminder" to "remainder" in MutableBigInteger.java . I can revise the patches if you want. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From thomas.schatzl at oracle.com Mon May 13 11:55:08 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 13 May 2013 13:55:08 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518CD15F.70503@gmail.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> Message-ID: <1368446108.2909.29.camel@cirrus> Hi all, On Fri, 2013-05-10 at 12:52 +0200, Peter Levart wrote: > Hi David, Thomas, > > I think I understand you now, David. You want to minimize the > possibility of vacuously passing the test. So here's my attempt at that: > > > public class OOMEInReferenceHandler { > static Object[] fillHeap() { > Object[] first = null, last = null; > int size = 1 << 20; > while (size > 0) { > try { > [... new reproducer ...] > [...] > > To be sure the order of class referencing in handlers is not disturbed > by changes in compilers, I suggest the patch to be modified to this more > explicit variant: > > try { > try { > lock.wait(); > } catch (InterruptedException x) { } > } catch (OutOfMemoryError x) {} > > > ..which also passes the test. I updated the test program and the patch in java.lang.ref.Reference accordingly. As for the problem of reproducibility, in my tests I had a 100% reproduction rate with the previous version of the test. However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as suggested in some other emails. I will report back with a new webrev after some testing on more platforms as suggested by David. Hth, Thomas From sundararajan.athijegannathan at oracle.com Mon May 13 12:14:24 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 May 2013 17:44:24 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CEC65.7050006@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> Message-ID: <5190D920.7090902@oracle.com> Incorporated changes as suggested. Uploaded webrev for historical purpose: http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ PS. I am going ahead with push.. Thanks -Sundar On Friday 10 May 2013 06:17 PM, A. Sundararajan wrote: > Okay, thanks. com.sun.script.util is not supported API (no CCC done > for it in the past). I'll remove it as suggested and run "make > profiles" to check > > Thanks > -Sundar > > On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: >> On 10/05/2013 11:23, A. Sundararajan wrote: >>> com/sun/script/util is generic utility package for script engine >>> implementations. Only com/sun/script/javascript package is being >>> removed. Since we include javax/script for profile 3, should we also >>> include com/sun/script/util ? >> Is com.sun.script.util meant to be a supported/documented API? Do you >> know if anything outside of the JDK is using it? Is Nashorn using it? >> The only usage I see is in com.sun.script.javascript so this is why I >> assumed that com.sun.script.** would go away. >> >> As you know, we moved javax.script to compact1. It doesn't require >> com.sun.script.util of course but if this is used by 3rd party >> scripting engines then it may have to be added to compact1 builds to >> get them working. >> >>> >>> On refs.allowed, I'll remove it. How should I check this? >> "make profiles" on Linux should be fine. As part of the profiles >> build it will run a dependency analyzer that checks for references to >> types that do not exist (this is catch configuration issues). >> >> -Alan > From ivan.gerasimov at oracle.com Mon May 13 12:23:50 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 13 May 2013 16:23:50 +0400 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <518D792B.504@oracle.com> References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com> Message-ID: <5190DB56.2000203@oracle.com> Hello Sherman! Thank you for the review! While I agree with you that current implementation of ZipInputStream.available() is not what it's supposed to be, I doubt it is the only cause of the issue. Please consider the following example. Zip archive (z.zip) consists of two entries: f1 and f2. f1 - gzip archive concatenated with a couple of bytes (I understand it's malformed gzip archive), f2 - let it be a single byte text file. $ echo a > f1 $ echo b > f2 $ gzip f1 $ echo a >> f1.gz $ zip z.zip f1.gz f2 public class ZipMix { private static byte[] rbuf = new byte[1]; public static void main(String[] args) throws Throwable { FileInputStream fis = new FileInputStream("z.zip"); ZipInputStream zis = new ZipInputStream(fis); System.out.print("-start-\n"); if (zis.getNextEntry() != null) { InputStream gis = new GZIPInputStream(zis, 8192); while (gis.read(rbuf) != -1) System.out.print(new String(rbuf)); } if (zis.getNextEntry() != null) { // <--- throws IOException while (zis.read(rbuf) != -1) System.out.print(new String(rbuf)); } System.out.print("\n-finish-\n"); } } This code worked well with jdk1.6.20, since GZIPInputStream hadn't tried to read beyond the trailer. This breaks with the current jdk, since GZIPInputStream tries to read yet another gzip header after the first trailer, and SequenceInputStream.read() calls the close() method for underlying stream. And this would break even with the ZipInputStream.available() fixed. It seems to me that the root cause here is using SequenceInputStream, which can close the stream during the read() call. And this is what my fix was about - to prevent closing of the underlying stream. Sincerely yours, Ivan On 11.05.2013 2:48, Xueming Shen wrote: > The proposed fix does solve the issue. > > However it appears it does not fix the root cause that triggers this > problem. > The root cause, or the direct trigger of this bug is the fact that > ZipInputStream > .availble() is really NOT reliable to tell us whether or not there is > any byte > "available" to be read from the input stream. The api doc of the > ZIS.available() > specifies "Returns 0 after EOF has reached for the current entry data, > otherwise > always return 1.". The implementation is straightforward, > > public int available() throws IOException { > if (entryEOF) { > return 0; > } else { > return 1; > } > } > > However, the flag "entryEOF" is only set if a read attempt has been tried > and failed (see ZIS.read()), which means if a previous read of the entry > succeeded and it actually read all the available bytes from the entry > (with > a big enough buffer), there is 0 byte available for read, the "flag" > is not > set, so if you invoke zis.available(), it return 1, but a read() > invocation will > returns -1 (yes, if you then try zis.available() again , it returns > the expected > 0). The test below demonstrates this issue. > > public static void main(String args[]) throws IOException { > ZipInputStream zis = new ZipInputStream(new > FileInputStream(args[0])); > ZipEntry ze; > while((ze = zis.getNextEntry()) !=null) { > System.out.println("--------------" + ze.getName() + > "--------"); > byte[] buf = new byte[8102]; > > while (true) { > System.out.println(" zis.available()=" + > zis.available()); > int n = zis.read(buf, 0, buf.length); > System.out.println(" readN=" + n); > if (n == -1) > break; > } > } > > } > > It is arguable that the this is not an implementation bug, since it is > reasonable > to argue that the EOF has not been "really" reached yet after the > first try, the > implementation happens to return all available bytes, so the next read > try finally > "reached" the EOF, but this obviously is not the expectation. > > Unfortunately the fix we put in for #4691425 [1] logically depends on > in.available() to decide whether or not we need to read a little > further, which > directly triggers this bug when the ZIS.available() "lies". > > // If there are more bytes available in "in" or > // the leftover in the "inf" is > 26 bytes: > // this.trailer(8) + next.header.min(10) + next.trailer(8) > // try concatenated case > if (this.in.available() > 0 || n > 26) { > .... > } > > Not only ZInputStream has this issue, its parent class InflaterStream > (and > its sibling GZIPInputStream, GZS inherits InflaterStream's available() > implementation directly) has the same issue, I do have a bug#7031075 > filed against GZIPInputStream. > > So the proposed fix is more a workaround for this available() issue. The > alternative is to fix the issue directly, for example, to change the > ZIS's > available implementation to something like > > public int available() throws IOException { > ensureOpen(); > if (entryEOF || entry == null) > return 0; > switch (entry.method) { > case DEFLATED: > return (inf.finished() || inf.needsDictionary()) ? 0 : 1; > case STORED: > return remaining > 0 ? 1 : 0; > default: > throw new ZipException("invalid compression method"); > } > } > > we probably should go further to simply remove the flag "entryEOF" > and move the "deflated" case implementation into InflaterInputStream > (to fix 7031075 as well). > > -Sherman > > > [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/ > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075 > > On 05/10/2013 01:03 AM, Ivan Gerasimov wrote: >> Hello everybody! >> >> GzipInputStream uses SequenceInputStream to concatenate the >> underlying stream with some data that reside in memory. >> SequenceInputStream is implementing in such a way that it closes the >> stream when it reaches EOS. >> >> The solution is to wrap the underlying stream with extended >> FilterInputStream that overrides the close() method. >> >> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 >> WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ >> >> >> Sincerely your, >> Ivan >> > > > From Alan.Bateman at oracle.com Mon May 13 12:26:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 13:26:05 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5190D920.7090902@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> Message-ID: <5190DBDD.2080602@oracle.com> On 13/05/2013 13:14, A. Sundararajan wrote: > Incorporated changes as suggested. Uploaded webrev for historical > purpose: > > http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ > > PS. I am going ahead with push.. > Thanks for fixing up refs.allowed, that one looks fine okay. Did you decide to keep com.sun.script.util? Just wondering because it appears that only com.sun.script.javascript is being removed. If the util API is going away then I assume that make/com/sun/script/Makefile should be removed (although we don't really care about the old build anymore). On the other, if the util API is staying then we need to figure out which profile is should go in. If nothing is using it then I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. -Alan From xuelei.fan at oracle.com Mon May 13 12:43:32 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 13 May 2013 12:43:32 +0000 Subject: hg: jdk8/tl/jdk: 8005535: SSLSessionImpl should have protected finalize() Message-ID: <20130513124354.6003748A28@hg.openjdk.java.net> Changeset: 76998d11a643 Author: xuelei Date: 2013-05-13 05:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76998d11a643 8005535: SSLSessionImpl should have protected finalize() Reviewed-by: weijun, wetmore ! src/share/classes/sun/security/ssl/SSLSessionImpl.java From xuelei.fan at oracle.com Mon May 13 13:07:03 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 13 May 2013 13:07:03 +0000 Subject: hg: jdk8/tl/jdk: 8005598: (reopened) Need to clone array of input/output parameters Message-ID: <20130513130715.CBCE148A2C@hg.openjdk.java.net> Changeset: 46db0e633240 Author: xuelei Date: 2013-05-13 06:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46db0e633240 8005598: (reopened) Need to clone array of input/output parameters Reviewed-by: weijun ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java From chris.hegarty at oracle.com Mon May 13 13:25:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 14:25:02 +0100 Subject: test/java/util/Collection/ListDefaults.java updates Message-ID: <5190E9AE.5080504@oracle.com> Akil, Mike, I've recently been diagnosing failures with ListDefaults.java, when working on a separate issue. I found it difficult to determine which collection type was having problems, in some failure cases. The diffs below are what I had to implement in my local repo to help identify the cause of several failures. It is probably not complete in terms of updating all the possible error conditions, but what I have sitting in my local repo, and possibly useful. If you agree with the changes, I can file a bug and push them. diff --git a/test/java/util/Collection/ListDefaults.java b/test/java/util/Collection/ListDefaults.java old mode 100644 new mode 100755 --- a/test/java/util/Collection/ListDefaults.java +++ b/test/java/util/Collection/ListDefaults.java @@ -117,17 +117,18 @@ public class ListDefaults { @Test(dataProvider = "listProvider") public void testProvidedWithNull(final List list) throws Exception { + final String cn = list.getClass().getName(); try { list.forEach(null); - fail("expected NPE not thrown"); + fail("expected NPE not thrown; " + cn + ".forEach()"); } catch (NullPointerException npe) {} try { list.replaceAll(null); - fail("expected NPE not thrown"); + fail("expected NPE not thrown; " + cn + ".replaceAll()"); } catch (NullPointerException npe) {} try { list.removeIf(null); - fail("expected NPE not thrown"); + fail("expected NPE not thrown; " + cn + ".removeIf()"); } catch (NullPointerException npe) {} } @@ -183,8 +184,9 @@ public class ListDefaults { final List list = ((List) test.collection); try { + final String cn = list.getClass().getName(); list.removeIf(null); - fail("expected NPE not thrown"); + fail("expected NPE not thrown;" + cn + ".removeIf()"); } catch (NullPointerException npe) {} CollectionAsserts.assertContents(list, original); @@ -215,10 +217,12 @@ public class ListDefaults { final List list = ((List) test.collection); final List listCopy = new ArrayList<>(list); if (original.size() > SUBLIST_SIZE) { + System.out.println("Testcase.name: " + test.name + ", classname:" + test.className); final List subList = list.subList(SUBLIST_FROM, SUBLIST_TO); final List subListCopy = new ArrayList<>(subList); listCopy.removeAll(subList); subList.removeIf(pOdd); + System.out.println("Testcase.name: " + test.name + ", classname:" + test.className + " COMPLETE"); for (int i : subList) { assertTrue((i % 2) == 0); } @@ -274,8 +278,9 @@ public class ListDefaults { final List list = ((List) test.collection); try { + final String cn = list.getClass().getName(); list.replaceAll(null); - fail("expected NPE not thrown"); + fail("expected NPE not thrown;" + cn + ".replaceAll()"); } catch (NullPointerException npe) {} CollectionAsserts.assertContents(list, original); -Chris. From Alan.Bateman at oracle.com Mon May 13 13:25:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 14:25:03 +0100 Subject: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies In-Reply-To: <518D64A8.1090906@oracle.com> References: <518D64A8.1090906@oracle.com> Message-ID: <5190E9AF.5090504@oracle.com> On 10/05/2013 22:20, Dan Xu wrote: > Hi, > > The FileInputStream.available() method can return a negative value > when the file position is beyond the endof afile. This is an > unspecified behaviour that has the potential to break applications > that expect available to return a value of 0 or greater. The > FileInputStream.skip(long) method allows a negative value as its > parameter. This conflicts with the specifications of InputStream and > FileInputStream classes. > > They are both long standing behaviours. In the fix, available() has > been changed to only return 0 or positive values. And for the > skip(long) method, due to the compatibility concern, its behaviour > will not be changed. Instead, the related java specs are going to be > changed to describe its current behaviour. > > bug: http://bugs.sun.com/view_bug.do?bug_id=8011136 > webrev: http://cr.openjdk.java.net/~dxu/8011136/webrev.00/ > > Thanks for your review! > > -Dan Thanks for following up on this one. Overall I agree with the approach, it specifies skip to match long standing behavior and fixes available to not return negative values. Just on wording, it might be better if the new statement in InputStream.skip didn't start with "But". How about "Subclasses may ..." as this would be consistent with exiting wording in this class. For FileInputStream then the statement on how "available" behaves should probably move to the available javadoc. Something like "Returns 0 when the file position is beyond EOF" should be fine. -Alan. From ivan.gerasimov at oracle.com Mon May 13 13:35:15 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 13 May 2013 17:35:15 +0400 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <5190DB56.2000203@oracle.com> References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com> <5190DB56.2000203@oracle.com> Message-ID: <5190EC13.2010000@oracle.com> A small correction to the recipe for failure. The failure is reproduced when a SINGLE byte is appended to the gzip archive. In the scenario below the echo command appends TWO bytes. These two bytes are interpreted as a wrong gzip header and get successfully ignored. On 13.05.2013 16:23, Ivan Gerasimov wrote: > Hello Sherman! > > Thank you for the review! > While I agree with you that current implementation of > ZipInputStream.available() is not what it's supposed to be, I doubt it > is the only cause of the issue. > Please consider the following example. > Zip archive (z.zip) consists of two entries: f1 and f2. > f1 - gzip archive concatenated with a couple of bytes (I understand > it's malformed gzip archive), > f2 - let it be a single byte text file. > > $ echo a > f1 > $ echo b > f2 > $ gzip f1 > $ echo a >> f1.gz > $ zip z.zip f1.gz f2 > > public class ZipMix { > private static byte[] rbuf = new byte[1]; > public static void main(String[] args) throws Throwable { > FileInputStream fis = new FileInputStream("z.zip"); > ZipInputStream zis = new ZipInputStream(fis); > System.out.print("-start-\n"); > if (zis.getNextEntry() != null) { > InputStream gis = new GZIPInputStream(zis, 8192); > while (gis.read(rbuf) != -1) > System.out.print(new String(rbuf)); > } > if (zis.getNextEntry() != null) { // <--- throws IOException > while (zis.read(rbuf) != -1) > System.out.print(new String(rbuf)); > } > System.out.print("\n-finish-\n"); > } > } > > This code worked well with jdk1.6.20, since GZIPInputStream hadn't > tried to read beyond the trailer. > This breaks with the current jdk, since GZIPInputStream tries to read > yet another gzip header after the first trailer, and > SequenceInputStream.read() calls the close() method for underlying > stream. > And this would break even with the ZipInputStream.available() fixed. > > It seems to me that the root cause here is using SequenceInputStream, > which can close the stream during the read() call. > And this is what my fix was about - to prevent closing of the > underlying stream. > > Sincerely yours, > Ivan > > > On 11.05.2013 2:48, Xueming Shen wrote: >> The proposed fix does solve the issue. >> >> However it appears it does not fix the root cause that triggers this >> problem. >> The root cause, or the direct trigger of this bug is the fact that >> ZipInputStream >> .availble() is really NOT reliable to tell us whether or not there is >> any byte >> "available" to be read from the input stream. The api doc of the >> ZIS.available() >> specifies "Returns 0 after EOF has reached for the current entry >> data, otherwise >> always return 1.". The implementation is straightforward, >> >> public int available() throws IOException { >> if (entryEOF) { >> return 0; >> } else { >> return 1; >> } >> } >> >> However, the flag "entryEOF" is only set if a read attempt has been >> tried >> and failed (see ZIS.read()), which means if a previous read of the entry >> succeeded and it actually read all the available bytes from the entry >> (with >> a big enough buffer), there is 0 byte available for read, the "flag" >> is not >> set, so if you invoke zis.available(), it return 1, but a read() >> invocation will >> returns -1 (yes, if you then try zis.available() again , it returns >> the expected >> 0). The test below demonstrates this issue. >> >> public static void main(String args[]) throws IOException { >> ZipInputStream zis = new ZipInputStream(new >> FileInputStream(args[0])); >> ZipEntry ze; >> while((ze = zis.getNextEntry()) !=null) { >> System.out.println("--------------" + ze.getName() + >> "--------"); >> byte[] buf = new byte[8102]; >> >> while (true) { >> System.out.println(" zis.available()=" + >> zis.available()); >> int n = zis.read(buf, 0, buf.length); >> System.out.println(" readN=" + n); >> if (n == -1) >> break; >> } >> } >> >> } >> >> It is arguable that the this is not an implementation bug, since it >> is reasonable >> to argue that the EOF has not been "really" reached yet after the >> first try, the >> implementation happens to return all available bytes, so the next >> read try finally >> "reached" the EOF, but this obviously is not the expectation. >> >> Unfortunately the fix we put in for #4691425 [1] logically depends on >> in.available() to decide whether or not we need to read a little >> further, which >> directly triggers this bug when the ZIS.available() "lies". >> >> // If there are more bytes available in "in" or >> // the leftover in the "inf" is > 26 bytes: >> // this.trailer(8) + next.header.min(10) + next.trailer(8) >> // try concatenated case >> if (this.in.available() > 0 || n > 26) { >> .... >> } >> >> Not only ZInputStream has this issue, its parent class InflaterStream >> (and >> its sibling GZIPInputStream, GZS inherits InflaterStream's available() >> implementation directly) has the same issue, I do have a bug#7031075 >> filed against GZIPInputStream. >> >> So the proposed fix is more a workaround for this available() issue. The >> alternative is to fix the issue directly, for example, to change the >> ZIS's >> available implementation to something like >> >> public int available() throws IOException { >> ensureOpen(); >> if (entryEOF || entry == null) >> return 0; >> switch (entry.method) { >> case DEFLATED: >> return (inf.finished() || inf.needsDictionary()) ? 0 : 1; >> case STORED: >> return remaining > 0 ? 1 : 0; >> default: >> throw new ZipException("invalid compression method"); >> } >> } >> >> we probably should go further to simply remove the flag "entryEOF" >> and move the "deflated" case implementation into InflaterInputStream >> (to fix 7031075 as well). >> >> -Sherman >> >> >> [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/ >> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075 >> >> On 05/10/2013 01:03 AM, Ivan Gerasimov wrote: >>> Hello everybody! >>> >>> GzipInputStream uses SequenceInputStream to concatenate the >>> underlying stream with some data that reside in memory. >>> SequenceInputStream is implementing in such a way that it closes the >>> stream when it reaches EOS. >>> >>> The solution is to wrap the underlying stream with extended >>> FilterInputStream that overrides the close() method. >>> >>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 >>> WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ >>> >>> >>> Sincerely your, >>> Ivan >>> >> >> >> > > > From xuelei.fan at oracle.com Mon May 13 14:05:02 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 13 May 2013 22:05:02 +0800 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit Message-ID: <5190F30E.8040805@oracle.com> Hi, There is some constructors issues about mutable objects in com.sun.jndi.toolkit. webrev: http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ Thanks, Xuelei From daniel.fuchs at oracle.com Mon May 13 14:36:40 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 May 2013 16:36:40 +0200 Subject: RFR: JDK-8013900: More warnings compiling jaxp. Message-ID: <5190FA78.2060608@oracle.com> This is a fix for JDK-8013900: More warnings compiling jaxp. Although the title might suggest a trivial fix, it goes a bit beyond a simple warning fix because the root cause of those warnings is that some classes redefine equals without redefining hashCode() - and devising a hashCode() method that respects its contract with equals() is not always trivial. The proposed fix adds hashCode() methods where necessary, ensuring that: if (o1.equals(o2) == true), then (o1.hashCode() == o2.hashCode()) The fix also contains some cosmetic/sanity changes - like: 1. adding @Override wherever NetBeans complained they were missing - and 2. replacing StringBuffer with StringBuilder when possible. 3. In one instance, AbstractDateTimeDV.java I also had to reformat the whole file (due to its weird original formatting) - apologies for the noise it causes in the webrev. 4. I also removed a couple of private isEqual(obj1, obj2) methods replacing them by calls to Objects.equals(obj1, obj2) which did the same thing. 5. finally I refactored some of the existing equals (e.g. replacing try { (Sometype) other.... } catch (ClassCastException x) { return false; } with use of 'other instanceof Sometype'...) There are however a couple of more serious changes that could deserve to be reviewed in more details: a. The new implementation of hashCode() in AbstractDateTimeDV.DateTimeData, where I had to figure out a way to convert the date to UTC so that the hashCode() would match equals: AbstractDateTimeDV.java: lines 972-992 and b. in PrecisionDecimalDV.XPrecisionDecimal - where I had to invent a canonical string representation to devise a hashCode that would match equals: PrecisionDecimalDV.java: lines 147-237 For this last one - I have added a new test in jdk/test to check the implementation of the new canonical String representation for hashCode() - since the code of that is not trivial. best regards, -- daniel From alexey.utkin at oracle.com Mon May 13 14:44:36 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 13 May 2013 18:44:36 +0400 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever In-Reply-To: References: <518A88B1.3060105@oracle.com> Message-ID: <5190FC54.8050808@oracle.com> Thanks, Martin! You are right. The approach private static String JAVA_EXE = System.getProperty("java.home") + File.separator + "bin" + File.separator + "java"; private static String[] getCommandArray(String processName) { String[] cmdArray = { JAVA_EXE, "-cp", System.getProperty("java.class.path"), InheritIOEHandle.class.getName(), processName }; return cmdArray; } is better. There is one more problem with raise-condition for the file handles. In current edition there is delta when the file handle could be inherited by the concurrent process. That is not fatal for read/write, but not good for delete. Synchronized call does not cover the file.close in finalized block. I will prepare new edition soon. Regards, -uta On 5/8/2013 10:20 PM, Martin Buchholz wrote: > Alexey, > Thanks for working on the scary windows process stuff. > I only have time for superficial review. > It looks like you know what you're doing. > > + String[] cmdArray = { > + "java", > + "-cp", > This looks like it's invoking whatever "java" is on the path. But > there's no guarantee there is such a java, or that it's the right one. > Consider invoking the java we're in, as in other jtreg tests like > IIRC ProcessBuilder/Basic.java From weijun.wang at oracle.com Mon May 13 14:52:01 2013 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 13 May 2013 22:52:01 +0800 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <5190F30E.8040805@oracle.com> References: <5190F30E.8040805@oracle.com> Message-ID: <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> I'll read them tomorrow. One question: are all of them designed to be call-by-value instead of shareable? Thanks Max On May 13, 2013, at 10:05 PM, Xuelei Fan wrote: > Hi, > > There is some constructors issues about mutable objects in > com.sun.jndi.toolkit. > > webrev: http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon May 13 15:06:34 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 13 May 2013 23:06:34 +0800 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> References: <5190F30E.8040805@oracle.com> <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> Message-ID: <5191017A.7030707@oracle.com> On 5/13/2013 10:52 PM, Wang Weijun wrote: > I'll read them tomorrow. OK. It's not a urgent fix. > One question: are all of them designed to be call-by-value instead of shareable? > I'm not sure I understand the term "call-by-value" or "shareable". From my understand, they are public classes, and copy-on-write or share-value is the not right solution. Cloning mutable objects is more robust. Otherwise, we need to check every caller to the method and the thread stacks to make sure it is not abused. It's nightmare to maintain such code. In the JNDI specification, we normally declare like "This constructor will not modify environment or save a reference to it, but may save a clone. Caller should not modify mutable keys and values in environment after it has been passed to the constructor." Thanks, Xuelei > Thanks > Max > > On May 13, 2013, at 10:05 PM, Xuelei Fan wrote: > >> Hi, >> >> There is some constructors issues about mutable objects in >> com.sun.jndi.toolkit. >> >> webrev: http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ >> >> Thanks, >> Xuelei From sundararajan.athijegannathan at oracle.com Mon May 13 15:40:24 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 May 2013 21:10:24 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5190DBDD.2080602@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> <5190DBDD.2080602@oracle.com> Message-ID: <51910968.9090706@oracle.com> I agree that it is better to remove com.sun.script.util package as well. It is not used elsewhere and was never declared as supported API. I've removed the same and re-generated webrev. http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ I ran NEWBUILD=false as well as NEWBUILD=true to make sure build finishes fine. Please review. Thanks -Sundar On Monday 13 May 2013 05:56 PM, Alan Bateman wrote: > On 13/05/2013 13:14, A. Sundararajan wrote: >> Incorporated changes as suggested. Uploaded webrev for historical >> purpose: >> >> http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ >> >> PS. I am going ahead with push.. >> > Thanks for fixing up refs.allowed, that one looks fine okay. > > Did you decide to keep com.sun.script.util? Just wondering because it > appears that only com.sun.script.javascript is being removed. If the > util API is going away then I assume that make/com/sun/script/Makefile > should be removed (although we don't really care about the old build > anymore). On the other, if the util API is staying then we need to > figure out which profile is should go in. If nothing is using it then > I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. > > -Alan From Alan.Bateman at oracle.com Mon May 13 16:44:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 17:44:17 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51910968.9090706@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> <5190DBDD.2080602@oracle.com> <51910968.9090706@oracle.com> Message-ID: <51911861.6010504@oracle.com> On 13/05/2013 16:40, A. Sundararajan wrote: > I agree that it is better to remove com.sun.script.util package as > well. It is not used elsewhere and was never declared as supported > API. I've removed the same and re-generated webrev. > > http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ > > I ran NEWBUILD=false as well as NEWBUILD=true to make sure build > finishes fine. > > Please review. Looks good to me. -Alan From brent.christian at oracle.com Mon May 13 16:48:03 2013 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 13 May 2013 09:48:03 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees Message-ID: <51911943.7000106@oracle.com> Hi, Please review my changes for 8005698 : Handle Frequent HashMap Collisions with Balanced Trees. For HashMap and LinkedHashMap, we would like to duplicate the technique (and some of the code) that the latest ConcurrentHashMap[1] uses for handling hash collisions: use of balanced trees to store map entries in hash bins containing many collisions. Webrev is here: http://cr.openjdk.java.net/~bchristi/8005698/webrev.00/ Some high-level details copied from the JEP[2]: Earlier work in this area in JDK 8, namely the alternative string-hashing implementation[3], improved collision performance for string-valued keys only, and it did so at the cost of adding a new (private) field to every String instance. The changes proposed here will improve collision performance for any key type that implements Comparable. The alternative string-hashing mechanism, including the private hash32 field added to the String class, can then be removed. The principal idea is that once the number of items in a hash bucket grows beyond a certain threshold, that bucket will switch from using a linked list of entries to a balanced tree. We will not implement this for the Hashtable class - some legacy code that uses it is known to depend upon iteration order. Instead, Hashtable will be reverted to its state prior to the introduction of the alternative string-hashing implementation, and will maintain its historical iteration order. We also will not implement this technique in WeakHashMap. An attempt was made, but the complexity of having to account for weak keys resulted in an unacceptable drop in microbenchmark performance. WeakHashMap will also be reverted to its prior state. Thanks! -Brent 1. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?view=log 2. http://openjdk.java.net/jeps/180 3. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e From akhil.arora at oracle.com Mon May 13 16:58:28 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Mon, 13 May 2013 09:58:28 -0700 Subject: test/java/util/Collection/ListDefaults.java updates In-Reply-To: <5190E9AE.5080504@oracle.com> References: <5190E9AE.5080504@oracle.com> Message-ID: <51911BB4.8050703@oracle.com> Looks good to me. I have had to add similar print statements when debugging, but I deleted them before committing, to keep the default test output clean. Minor - it would be good to have a little more consistency... some tests print the class name always, some only on failure. Also would be good to have similar changes in the CollectionDefaults and IteratorDefaults tests. On 05/13/2013 06:25 AM, Chris Hegarty wrote: > Akil, Mike, > > I've recently been diagnosing failures with ListDefaults.java, when > working on a separate issue. I found it difficult to determine which > collection type was having problems, in some failure cases. > > The diffs below are what I had to implement in my local repo to help > identify the cause of several failures. It is probably not complete in > terms of updating all the possible error conditions, but what I have > sitting in my local repo, and possibly useful. > > If you agree with the changes, I can file a bug and push them. > > diff --git a/test/java/util/Collection/ListDefaults.java > b/test/java/util/Collection/ListDefaults.java > old mode 100644 > new mode 100755 > --- a/test/java/util/Collection/ListDefaults.java > +++ b/test/java/util/Collection/ListDefaults.java > @@ -117,17 +117,18 @@ public class ListDefaults { > > @Test(dataProvider = "listProvider") > public void testProvidedWithNull(final List list) throws > Exception { > + final String cn = list.getClass().getName(); > try { > list.forEach(null); > - fail("expected NPE not thrown"); > + fail("expected NPE not thrown; " + cn + ".forEach()"); > } catch (NullPointerException npe) {} > try { > list.replaceAll(null); > - fail("expected NPE not thrown"); > + fail("expected NPE not thrown; " + cn + ".replaceAll()"); > } catch (NullPointerException npe) {} > try { > list.removeIf(null); > - fail("expected NPE not thrown"); > + fail("expected NPE not thrown; " + cn + ".removeIf()"); > } catch (NullPointerException npe) {} > } > > @@ -183,8 +184,9 @@ public class ListDefaults { > final List list = ((List) test.collection); > > try { > + final String cn = list.getClass().getName(); > list.removeIf(null); > - fail("expected NPE not thrown"); > + fail("expected NPE not thrown;" + cn + ".removeIf()"); > } catch (NullPointerException npe) {} > CollectionAsserts.assertContents(list, original); > > @@ -215,10 +217,12 @@ public class ListDefaults { > final List list = ((List) test.collection); > final List listCopy = new ArrayList<>(list); > if (original.size() > SUBLIST_SIZE) { > + System.out.println("Testcase.name: " + test.name + ", > classname:" + test.className); > final List subList = > list.subList(SUBLIST_FROM, SUBLIST_TO); > final List subListCopy = new > ArrayList<>(subList); > listCopy.removeAll(subList); > subList.removeIf(pOdd); > + System.out.println("Testcase.name: " + test.name + ", > classname:" + test.className + " COMPLETE"); > for (int i : subList) { > assertTrue((i % 2) == 0); > } > @@ -274,8 +278,9 @@ public class ListDefaults { > final List list = ((List) test.collection); > > try { > + final String cn = list.getClass().getName(); > list.replaceAll(null); > - fail("expected NPE not thrown"); > + fail("expected NPE not thrown;" + cn + ".replaceAll()"); > } catch (NullPointerException npe) {} > CollectionAsserts.assertContents(list, original); > > -Chris. From chris.hegarty at oracle.com Mon May 13 17:06:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 18:06:08 +0100 Subject: test/java/util/Collection/ListDefaults.java updates In-Reply-To: <51911BB4.8050703@oracle.com> References: <5190E9AE.5080504@oracle.com> <51911BB4.8050703@oracle.com> Message-ID: <51911D80.4070601@oracle.com> Thanks Akhil, let me flesh it out a little more and send a formal webrev. -Chris. On 05/13/2013 05:58 PM, Akhil Arora wrote: > Looks good to me. I have had to add similar print statements when > debugging, but I deleted them before committing, to keep the default > test output clean. > > Minor - it would be good to have a little more consistency... some tests > print the class name always, some only on failure. Also would be good to > have similar changes in the CollectionDefaults and IteratorDefaults tests. > > On 05/13/2013 06:25 AM, Chris Hegarty wrote: >> Akil, Mike, >> >> I've recently been diagnosing failures with ListDefaults.java, when >> working on a separate issue. I found it difficult to determine which >> collection type was having problems, in some failure cases. >> >> The diffs below are what I had to implement in my local repo to help >> identify the cause of several failures. It is probably not complete in >> terms of updating all the possible error conditions, but what I have >> sitting in my local repo, and possibly useful. >> >> If you agree with the changes, I can file a bug and push them. >> >> diff --git a/test/java/util/Collection/ListDefaults.java >> b/test/java/util/Collection/ListDefaults.java >> old mode 100644 >> new mode 100755 >> --- a/test/java/util/Collection/ListDefaults.java >> +++ b/test/java/util/Collection/ListDefaults.java >> @@ -117,17 +117,18 @@ public class ListDefaults { >> >> @Test(dataProvider = "listProvider") >> public void testProvidedWithNull(final List list) throws >> Exception { >> + final String cn = list.getClass().getName(); >> try { >> list.forEach(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".forEach()"); >> } catch (NullPointerException npe) {} >> try { >> list.replaceAll(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".replaceAll()"); >> } catch (NullPointerException npe) {} >> try { >> list.removeIf(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".removeIf()"); >> } catch (NullPointerException npe) {} >> } >> >> @@ -183,8 +184,9 @@ public class ListDefaults { >> final List list = ((List) >> test.collection); >> >> try { >> + final String cn = list.getClass().getName(); >> list.removeIf(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown;" + cn + ".removeIf()"); >> } catch (NullPointerException npe) {} >> CollectionAsserts.assertContents(list, original); >> >> @@ -215,10 +217,12 @@ public class ListDefaults { >> final List list = ((List) >> test.collection); >> final List listCopy = new ArrayList<>(list); >> if (original.size() > SUBLIST_SIZE) { >> + System.out.println("Testcase.name: " + test.name + ", >> classname:" + test.className); >> final List subList = >> list.subList(SUBLIST_FROM, SUBLIST_TO); >> final List subListCopy = new >> ArrayList<>(subList); >> listCopy.removeAll(subList); >> subList.removeIf(pOdd); >> + System.out.println("Testcase.name: " + test.name + ", >> classname:" + test.className + " COMPLETE"); >> for (int i : subList) { >> assertTrue((i % 2) == 0); >> } >> @@ -274,8 +278,9 @@ public class ListDefaults { >> final List list = ((List) >> test.collection); >> >> try { >> + final String cn = list.getClass().getName(); >> list.replaceAll(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown;" + cn + ".replaceAll()"); >> } catch (NullPointerException npe) {} >> CollectionAsserts.assertContents(list, original); >> >> -Chris. > From sundararajan.athijegannathan at oracle.com Mon May 13 17:13:06 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 13 May 2013 17:13:06 +0000 Subject: hg: jdk8/tl/jdk: 8012975: Remove rhino from jdk8 Message-ID: <20130513171327.CD6EB48A31@hg.openjdk.java.net> Changeset: 536678dffa97 Author: sundar Date: 2013-05-13 22:23 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/536678dffa97 8012975: Remove rhino from jdk8 Reviewed-by: alanb, tbell ! make/com/sun/Makefile - make/com/sun/script/Makefile ! make/sun/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile ! make/tools/src/build/tools/deps/refs.allowed ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/profile-rtjar-includes.txt - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java From mike.duigou at oracle.com Mon May 13 17:16:01 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 13 May 2013 10:16:01 -0700 Subject: test/java/util/Collection/ListDefaults.java updates In-Reply-To: <51911BB4.8050703@oracle.com> References: <5190E9AE.5080504@oracle.com> <51911BB4.8050703@oracle.com> Message-ID: <58E915F6-FAF0-4321-8FC1-17742551F5FC@oracle.com> These changes look OK. I've been adding a description in my test providers which provides the test method with two params, a printable description and the test data. This has worked reasonably well and has the advantage that it can provide more information than just the class name. Mike On May 13 2013, at 09:58 , Akhil Arora wrote: > Looks good to me. I have had to add similar print statements when debugging, but I deleted them before committing, to keep the default test output clean. > > Minor - it would be good to have a little more consistency... some tests print the class name always, some only on failure. Also would be good to have similar changes in the CollectionDefaults and IteratorDefaults tests. > > On 05/13/2013 06:25 AM, Chris Hegarty wrote: >> Akil, Mike, >> >> I've recently been diagnosing failures with ListDefaults.java, when >> working on a separate issue. I found it difficult to determine which >> collection type was having problems, in some failure cases. >> >> The diffs below are what I had to implement in my local repo to help >> identify the cause of several failures. It is probably not complete in >> terms of updating all the possible error conditions, but what I have >> sitting in my local repo, and possibly useful. >> >> If you agree with the changes, I can file a bug and push them. >> >> diff --git a/test/java/util/Collection/ListDefaults.java >> b/test/java/util/Collection/ListDefaults.java >> old mode 100644 >> new mode 100755 >> --- a/test/java/util/Collection/ListDefaults.java >> +++ b/test/java/util/Collection/ListDefaults.java >> @@ -117,17 +117,18 @@ public class ListDefaults { >> >> @Test(dataProvider = "listProvider") >> public void testProvidedWithNull(final List list) throws >> Exception { >> + final String cn = list.getClass().getName(); >> try { >> list.forEach(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".forEach()"); >> } catch (NullPointerException npe) {} >> try { >> list.replaceAll(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".replaceAll()"); >> } catch (NullPointerException npe) {} >> try { >> list.removeIf(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown; " + cn + ".removeIf()"); >> } catch (NullPointerException npe) {} >> } >> >> @@ -183,8 +184,9 @@ public class ListDefaults { >> final List list = ((List) test.collection); >> >> try { >> + final String cn = list.getClass().getName(); >> list.removeIf(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown;" + cn + ".removeIf()"); >> } catch (NullPointerException npe) {} >> CollectionAsserts.assertContents(list, original); >> >> @@ -215,10 +217,12 @@ public class ListDefaults { >> final List list = ((List) test.collection); >> final List listCopy = new ArrayList<>(list); >> if (original.size() > SUBLIST_SIZE) { >> + System.out.println("Testcase.name: " + test.name + ", >> classname:" + test.className); >> final List subList = >> list.subList(SUBLIST_FROM, SUBLIST_TO); >> final List subListCopy = new >> ArrayList<>(subList); >> listCopy.removeAll(subList); >> subList.removeIf(pOdd); >> + System.out.println("Testcase.name: " + test.name + ", >> classname:" + test.className + " COMPLETE"); >> for (int i : subList) { >> assertTrue((i % 2) == 0); >> } >> @@ -274,8 +278,9 @@ public class ListDefaults { >> final List list = ((List) test.collection); >> >> try { >> + final String cn = list.getClass().getName(); >> list.replaceAll(null); >> - fail("expected NPE not thrown"); >> + fail("expected NPE not thrown;" + cn + ".replaceAll()"); >> } catch (NullPointerException npe) {} >> CollectionAsserts.assertContents(list, original); >> >> -Chris. > From brian.burkhalter at oracle.com Mon May 13 18:45:29 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 May 2013 11:45:29 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <5190CDEE.6030902@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <52FDCE59-080B-4F1C-A56F-D677B14124D3@oracle.com> <5190CDEE.6030902@mindspring.com> Message-ID: <8DE41DD4-36C1-42B3-B906-439B66A9EF99@oracle.com> On May 13, 2013, at 4:26 AM, Alan Eliasen wrote: > Another minor note is that you might want to correct "reminder" to > "remainder" in MutableBigInteger.java . I can revise the patches if you > want. Thanks, Alan, I will take care of it. Brian From brian.burkhalter at oracle.com Mon May 13 18:57:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 May 2013 11:57:31 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <518F0E0D.1090004@mindspring.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <518B701F.6070906@oracle.com> <7C57030C-9D7D-4C83-8B93-73CB2B949231@oracle.com> <518F0E0D.1090004@mindspring.com> Message-ID: <9200CFD5-984C-4972-A280-8706828FF552@oracle.com> On May 11, 2013, at 8:35 PM, Alan Eliasen wrote: > On 05/09/2013 03:02 PM, Brian Burkhalter wrote: >>> First you have: >>> >>> /** >>> * The threshold value for using 3-way Toom-Cook multiplication. >>> * If the number of ints in both mag arrays are greater than this number, >>> * then Toom-Cook multiplication will be used. This value is found >>> * experimentally to work well. >>> */ >>> private static final int TOOM_COOK_THRESHOLD = 75; > > You're right that the actual code will use Toom-Cook if 1.) both of > the numbers are greater than the Karatsuba threshold *and* 2.) at least > one of the numbers is greater than the Toom-Cook threshold. > [?] > If you want to change the comment to something like my first sentence > in the first paragraph, that would be fine. Alternately, we could > change the logic to match the comment, but that would probably mean that > we should re-tune the thresholds. I would prefer simply to change the javadoc of the constant unless others have a strong preference otherwise. Brian From Alan.Bateman at oracle.com Mon May 13 19:05:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 20:05:54 +0100 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51909249.6060506@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> Message-ID: <51913992.9030106@oracle.com> On 13/05/2013 08:12, David Holmes wrote: > Thanks for all the feedback and discussion. I've rewritten the patch > to use Peter's suggestion of caching the char[] instead of the actual > String: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ > > I too am concerned that any form of caching that avoids the array-copy > (which is the crux of the issue) is going to incur a 2x space penalty. > I can imagine old but well-behaved code that uses StringBuffer rather > than StringBuilder where very long buffers are created and toString() > only called once - and they may get immediate or subsequent OOME due > to the extra char[]; or excessive GC activity might be induced if a > lot of StringBuffers are used. Assuming the well-behaved case is where the StringBuffer is discarded after calling toString then I wouldn't expect it to too different to today. That is, you have the 2x penalty when toString is called now. Clearly there are other usages which could be problematic. I'm not sure what to say about the copy-on-change-after-toString approach. As the offset/count fields have been removed from String then it could only be the count == value.length case. It would clearly be a win in some cases but no help in others. -Alan. From mike.duigou at oracle.com Mon May 13 20:29:10 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 13 May 2013 20:29:10 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130513202933.B2B9C48A3A@hg.openjdk.java.net> Changeset: 6175fe5b07aa Author: bharadwaj Date: 2013-05-13 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6175fe5b07aa 8008687: MethodHandle code: allow static and invokespecial calls to interface methods Summary: Changes to support invocation of lambda methods compiled either as static interface methods and or private instance methods. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: f7fcfb204a69 Author: mduigou Date: 2013-05-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fcfb204a69 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java From kurchi.subhra.hazra at oracle.com Mon May 13 20:38:48 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Mon, 13 May 2013 20:38:48 +0000 Subject: hg: jdk8/tl/jdk: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive Message-ID: <20130513203900.39ACD48A3B@hg.openjdk.java.net> Changeset: 86c1e8c799f5 Author: khazra Date: 2013-05-13 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c1e8c799f5 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive Summary: Rearrange event-handling code to remove bottle-neck. Also reviewed by mhall at mhcomputing.net. Reviewed-by: chegar, alanb ! src/share/classes/sun/net/httpserver/ServerImpl.java From xueming.shen at oracle.com Mon May 13 20:58:34 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 May 2013 13:58:34 -0700 Subject: RFR 8013730: JJSR 310: DateTime API Updates III Message-ID: <519153FA.8010302@oracle.com> Hi, JSR 310 has continued to refine and update the java.time API. Please help review the changes at http://cr.openjdk.java.net/~sherman/8013730/webrev In addition to general javadoc improvements, the changes include: - Rename class java.time.format.DateTimeFormatSymbols to DecimalStyle - Clarification definition of Clock behavior - Add DateTimeFomatterBuilder.appendInstant - Add DateTimeFomatterBuilder.getLocalizedDateTimePattern - Add DateTimeFormatter.parsedLeapSecond as a query for a parsed LeapSecond - Add DateTimeFormatter.parsedExcessDays as a query for parsed days if time > 24 hours. Thanks! -Sherman From xueming.shen at oracle.com Mon May 13 22:01:07 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 May 2013 15:01:07 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <518D88EC.6030804@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> Message-ID: <519162A3.5000601@oracle.com> Thanks Mandy for reviewing. Webrev has been updated to (1) added the sync back to charset/deleteCharset(). As you suggested, there is race condition risk that the map is being accessed while the system initialization completes. (2) added the "holder" pattern for msiso2022_jp and iso2022_jp_2, as suggested. (3) keep the AbstractCharsetProvider in repo for now. I have not eliminate the static reference to s.n.c.ExtendedCharsets class, yet, since it is only invoked/referred after we have checked Class.forName. Is it really a problem here? for example, the hotspo re-arrange the order of execution? http://cr.openjdk.java.net/~sherman/8012326/webrev/ Thanks! -Sherman http://cr.openjdk.java.net/~sherman/8012326/webrev/ On 05/10/2013 04:55 PM, Mandy Chung wrote: > Sherman, > > The charsetForName, charsets and aliasesFor methods call init() first and > then access the maps with no synchronization. While the maps are being > accessed by one thread and system initialization completes, another thread > calls charsetForName() that calls init() which will update the maps. So > the maps is being updated while being accessed by another thread. So > I think the original synchronized(this) is still needed for the > charsetForName, charsets and aliasesFor methods for correctness. > > The maps are only updated once and also only if ExtendedCharsets provider > is instantiated before booted and "sun.nio.cs.map" system property is set. > I think it's worth further clean up this 2-phase instance initialization > since ExtendedCharsets is now a singleton. Would Charset.availableCharsets() > and ExtendedCharsets.charsets() not be called during system initialization? > If we can restrict that they can't be called, maybe you can move the 2nd > phase initialization to ExtendedCharsetsHolder (i.e. calling init() method) > and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets instance > methods no longer need to call init. Just one thought. > > You propose to remove AbstractCharsetProvider class. I don't have the > history to comment on whether you should keep/remove the > AbstractCharsetProvider for other charset providers to extend. Just > looking at the current implementation, it's not needed. > > More comments inlined below. > > On 5/10/2013 10:53 AM, Xueming Shen wrote: >> Thanks for the review. >> >> I have updated the Charset.java to use the init-on-depand holder idiom. >> > > L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); > > You would need to use 'epc' and invoke "getInstance" method via reflection > to eliminate the static reference to s.n.c.ExtendedCharsets class as > it might not be present. > > I suggest to add these 2 methods in the ExtendedProviderHolder class: > static Charset charsetForName(String charsetName) { > return (extendedProvider != null) > ? extendedProvider.charsetForName(charsetName) : null; > } > > static Iterator charsets() { > return (extendedProvider != null) > ? extendedProvider.charsets() > : Collections.emptyIterator(); > } > > > The lookup2() and availableCharsets() methods can be simplified to > something like this: > > if ((cs = standardProvider.charsetForName(charsetName)) != null || > - (cs = lookupExtendedCharset(charsetName)) != null || > + (cs = ExtendedProviderHolder.charsetForName(charsetName)) != null || > (cs = lookupViaProviders(charsetName)) != null) > > > + put(ExtendedProviderHolder.charsets(), m); > for (Iterator i = providers(); i.hasNext();) { > CharsetProvider cp = i.next(); > put(cp.charsets(), m); > >> I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of adding >> two more classes, so I leave them asis. >> > > Are you concerned of the static footprint of the new class? > > I think the code is much cleaner but you may think it's overkill: > static class Holder { > static DoubleByte.Decoder DEC0208 = .... > static DoubleByte.Encoder ENC0208 = .... > } > > Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? > >> Agreed that the ExtendedCahrsets change can be separated, but since we're here >> already, It would be convenient to just do them together and the "cleaner' code >> then can be back-port together later when requested. > > It's fine with me. I suggest to look into the possibility separating the second phase update to the extended charsets if you want to remove the synchronization on the instance methods. > > Mandy > >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >> >> -Sherman >> From peter.levart at gmail.com Mon May 13 22:09:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 May 2013 00:09:15 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51913992.9030106@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> Message-ID: <5191648B.6010905@gmail.com> On 05/13/2013 09:05 PM, Alan Bateman wrote: > On 13/05/2013 08:12, David Holmes wrote: >> Thanks for all the feedback and discussion. I've rewritten the patch >> to use Peter's suggestion of caching the char[] instead of the actual >> String: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >> >> I too am concerned that any form of caching that avoids the >> array-copy (which is the crux of the issue) is going to incur a 2x >> space penalty. I can imagine old but well-behaved code that uses >> StringBuffer rather than StringBuilder where very long buffers are >> created and toString() only called once - and they may get immediate >> or subsequent OOME due to the extra char[]; or excessive GC activity >> might be induced if a lot of StringBuffers are used. > Assuming the well-behaved case is where the StringBuffer is discarded > after calling toString then I wouldn't expect it to too different to > today. That is, you have the 2x penalty when toString is called now. > Clearly there are other usages which could be problematic. > > I'm not sure what to say about the copy-on-change-after-toString > approach. As the offset/count fields have been removed from String > then it could only be the count == value.length case. It would clearly > be a win in some cases but no help in others. > > -Alan. Hi David, Alan, It would be a win in cases where the capacity of StringBuilder/Buffer could be anticipated to match the final length of string. I tried to implement it just for exercise and it turns out to be tricky. Currently I have not been able to do it correctly without introducing some sort of synchronization to StringBuilder, which would severely impact performance, since StringBuilder is designed to be used by single thread. In case of sharing char array with String, the "shared" boolean flag would have to be checked/updated atomically together with any 'value' de-referencing and array updating or there could be data races that would render String instances produced with such unsynchronized StringBuilder appear mutable. While doing that, I noticed a synchronization bug in String.contentEquals method. If called with a StringBuffer argument while concurrent thread is modifying the StringBuffer, the method can either throw ArrayIndexOutOfBoundsException or return true even though the content of the StringBuffer has never been the same as the String's. Here's a proposed patch: http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ Regards, Peter From jonathan.gibbons at oracle.com Mon May 13 22:29:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 May 2013 22:29:30 +0000 Subject: hg: jdk8/tl/langtools: 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees Message-ID: <20130513222934.CF4D748A3E@hg.openjdk.java.net> Changeset: 8dd528992c15 Author: jlahoda Date: 2013-05-10 15:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8dd528992c15 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees Reviewed-by: jjg Contributed-by: Dusan Balek , Jan Lahoda ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/api/TestGetElementReference.java + test/tools/javac/api/TestGetElementReferenceData.java From peter.levart at gmail.com Mon May 13 22:34:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 May 2013 00:34:05 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <5191648B.6010905@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> Message-ID: <51916A5D.7060203@gmail.com> On 05/14/2013 12:09 AM, Peter Levart wrote: > I noticed a synchronization bug in String.contentEquals method. If > called with a StringBuffer argument while concurrent thread is > modifying the StringBuffer, the method can either throw > ArrayIndexOutOfBoundsException or return true even though the content > of the StringBuffer has never been the same as the String's. > > Here's a proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ > > Regards, Peter Or even better (with some code clean-up): http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ Regards, Peter From brian.burkhalter at oracle.com Mon May 13 23:44:29 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 May 2013 16:44:29 -0700 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) In-Reply-To: <9200CFD5-984C-4972-A280-8706828FF552@oracle.com> References: <1BF8A23A-0829-40A6-91F6-932110AE7810@oracle.com> <518255DD.8000008@oracle.com> <91EA773D-8087-458D-A78E-DEE42383CA2F@oracle.com> <5184FB80.7030203@mindspring.com> <05443E4C-6FE7-4051-806E-971F81F6D36E@oracle.com> <5188CA59.9040100@mindspring.com> <793E37CD-0C52-4D58-B647-F12BB4A6ECDB@oracle.com> <518B4C32.7010106@mindspring.com> <518B701F.6070906@oracle.com> <7C57030C-9D7D-4C83-8B93-73CB2B949231@oracle.com> <518F0E0D.1090004@mindspring.com> <9200CFD5-984C-4972-A280-8706828FF552@oracle.com> Message-ID: On May 13, 2013, at 11:57 AM, Brian Burkhalter wrote: > On May 11, 2013, at 8:35 PM, Alan Eliasen wrote: > >> On 05/09/2013 03:02 PM, Brian Burkhalter wrote: >>>> First you have: >>>> >>>> /** >>>> * The threshold value for using 3-way Toom-Cook multiplication. >>>> * If the number of ints in both mag arrays are greater than this number, >>>> * then Toom-Cook multiplication will be used. This value is found >>>> * experimentally to work well. >>>> */ >>>> private static final int TOOM_COOK_THRESHOLD = 75; >> >> You're right that the actual code will use Toom-Cook if 1.) both of >> the numbers are greater than the Karatsuba threshold *and* 2.) at least >> one of the numbers is greater than the Toom-Cook threshold. >> [?] >> If you want to change the comment to something like my first sentence >> in the first paragraph, that would be fine. Alternately, we could >> change the logic to match the comment, but that would probably mean that >> we should re-tune the thresholds. > > I would prefer simply to change the javadoc of the constant unless others have a strong preference otherwise. For example: /** * The threshold value for using 3-way Toom-Cook multiplication. * If the number of ints in each mag array is greater than the * Karatsuba threshold, and the number of ints in at least one of * the mag arrays is greater than this threshold, then Toom-Cook * multiplication will be used. */ private static final int TOOM_COOK_THRESHOLD = 75; Brian From rob.mckenna at oracle.com Tue May 14 01:59:55 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 14 May 2013 02:59:55 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys Message-ID: <51919A9B.4030700@oracle.com> Hi folks, Looking for a review of this suggested fix from Fujitsu. GetFileAttributesExW() returns ERROR_SHARING_VIOLATION for pagefile.sys and hiberfi.sys so we're falling back to FindFirstFile instead: http://cr.openjdk.java.net/~robm/7038105/webrev.01/ -Rob From xueming.shen at oracle.com Tue May 14 02:02:09 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 May 2013 19:02:09 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <519162A3.5000601@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> <519162A3.5000601@oracle.com> Message-ID: <51919B21.7080400@oracle.com> Hi Mandy, Here is the updated simple version as we chatted. I will leave the ExtendedCharsets rewrite for next round. http://cr.openjdk.java.net/~sherman/8012326/webrev/ Thanks! -Sherman On 5/13/13 3:01 PM, Xueming Shen wrote: > Thanks Mandy for reviewing. > > Webrev has been updated to > > (1) added the sync back to charset/deleteCharset(). As you suggested, > there > is race condition risk that the map is being accessed while the system > initialization completes. > (2) added the "holder" pattern for msiso2022_jp and iso2022_jp_2, as > suggested. > (3) keep the AbstractCharsetProvider in repo for now. > > I have not eliminate the static reference to s.n.c.ExtendedCharsets > class, yet, > since it is only invoked/referred after we have checked Class.forName. > Is it > really a problem here? for example, the hotspo re-arrange the order of > execution? > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > > Thanks! > -Sherman > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > > On 05/10/2013 04:55 PM, Mandy Chung wrote: >> Sherman, >> >> The charsetForName, charsets and aliasesFor methods call init() first >> and >> then access the maps with no synchronization. While the maps are being >> accessed by one thread and system initialization completes, another >> thread >> calls charsetForName() that calls init() which will update the maps. So >> the maps is being updated while being accessed by another thread. So >> I think the original synchronized(this) is still needed for the >> charsetForName, charsets and aliasesFor methods for correctness. >> >> The maps are only updated once and also only if ExtendedCharsets >> provider >> is instantiated before booted and "sun.nio.cs.map" system property is >> set. >> I think it's worth further clean up this 2-phase instance initialization >> since ExtendedCharsets is now a singleton. Would >> Charset.availableCharsets() >> and ExtendedCharsets.charsets() not be called during system >> initialization? >> If we can restrict that they can't be called, maybe you can move the 2nd >> phase initialization to ExtendedCharsetsHolder (i.e. calling init() >> method) >> and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets instance >> methods no longer need to call init. Just one thought. >> >> You propose to remove AbstractCharsetProvider class. I don't have the >> history to comment on whether you should keep/remove the >> AbstractCharsetProvider for other charset providers to extend. Just >> looking at the current implementation, it's not needed. >> >> More comments inlined below. >> >> On 5/10/2013 10:53 AM, Xueming Shen wrote: >>> Thanks for the review. >>> >>> I have updated the Charset.java to use the init-on-depand holder idiom. >>> >> >> L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); >> >> You would need to use 'epc' and invoke "getInstance" method via >> reflection >> to eliminate the static reference to s.n.c.ExtendedCharsets class as >> it might not be present. >> >> I suggest to add these 2 methods in the ExtendedProviderHolder class: >> static Charset charsetForName(String charsetName) { >> return (extendedProvider != null) >> ? >> extendedProvider.charsetForName(charsetName) : null; >> } >> >> static Iterator charsets() { >> return (extendedProvider != null) >> ? extendedProvider.charsets() >> : Collections.emptyIterator(); >> } >> >> >> The lookup2() and availableCharsets() methods can be simplified to >> something like this: >> >> if ((cs = standardProvider.charsetForName(charsetName)) != >> null || >> - (cs = lookupExtendedCharset(charsetName)) != null || >> + (cs = >> ExtendedProviderHolder.charsetForName(charsetName)) != null || >> (cs = lookupViaProviders(charsetName)) != null) >> >> >> + put(ExtendedProviderHolder.charsets(), m); >> for (Iterator i = providers(); >> i.hasNext();) { >> CharsetProvider cp = i.next(); >> put(cp.charsets(), m); >> >>> I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of >>> adding >>> two more classes, so I leave them asis. >>> >> >> Are you concerned of the static footprint of the new class? >> >> I think the code is much cleaner but you may think it's overkill: >> static class Holder { >> static DoubleByte.Decoder DEC0208 = .... >> static DoubleByte.Encoder ENC0208 = .... >> } >> >> Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? >> >>> Agreed that the ExtendedCahrsets change can be separated, but since >>> we're here >>> already, It would be convenient to just do them together and the >>> "cleaner' code >>> then can be back-port together later when requested. >> >> It's fine with me. I suggest to look into the possibility separating >> the second phase update to the extended charsets if you want to >> remove the synchronization on the instance methods. >> >> Mandy >> >>> >>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>> >>> -Sherman >>> > From xueming.shen at oracle.com Tue May 14 03:37:16 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 03:37:16 +0000 Subject: hg: jdk8/tl/jdk: 8013386: (tz) Support tzdata2013c Message-ID: <20130514033738.288CA48A4A@hg.openjdk.java.net> Changeset: ae35fdbab949 Author: sherman Date: 2013-05-13 20:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae35fdbab949 8013386: (tz) Support tzdata2013c Summary: updated tz data to version 2013c Reviewed-by: peytoia, okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/Rule.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab From Mike.Duigou at oracle.COM Tue May 14 05:06:19 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Mon, 13 May 2013 22:06:19 -0700 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <518D601E.6070701@oracle.com> References: <518D601E.6070701@oracle.com> Message-ID: Looks fine to me. Welcome back Objects.requireNonNull(obj, Supplier)! Mike On May 10 2013, at 14:01 , Joe Darcy wrote: > Hello, > > Please (re)review this change to introduce Objects.requireNonNull(T, Supplier): > > http://cr.openjdk.java.net/~darcy/8014365.0/ > > The original change had to be pulled out because of a build issue (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build); I'll be asking for a review on build-dev of the build-related change in langtools. The test portion of the patch is slightly different than before because of the intervening changes made for > > 8013712: Add Objects.nonNull and Objects.isNull > > Thanks, > > -Joe From david.holmes at oracle.com Tue May 14 05:10:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2013 15:10:36 +1000 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <51913992.9030106@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> Message-ID: <5191C74C.7030907@oracle.com> On 14/05/2013 5:05 AM, Alan Bateman wrote: > On 13/05/2013 08:12, David Holmes wrote: >> Thanks for all the feedback and discussion. I've rewritten the patch >> to use Peter's suggestion of caching the char[] instead of the actual >> String: >> >> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >> >> I too am concerned that any form of caching that avoids the array-copy >> (which is the crux of the issue) is going to incur a 2x space penalty. >> I can imagine old but well-behaved code that uses StringBuffer rather >> than StringBuilder where very long buffers are created and toString() >> only called once - and they may get immediate or subsequent OOME due >> to the extra char[]; or excessive GC activity might be induced if a >> lot of StringBuffers are used. > Assuming the well-behaved case is where the StringBuffer is discarded > after calling toString then I wouldn't expect it to too different to > today. That is, you have the 2x penalty when toString is called now. Thank you! I had been comparing the cached case with the ancient sharing case - where there was no space penalty. As you say in the existing code we already use 2x the space at the time toString is called, so no change in that regard. Doh! > Clearly there are other usages which could be problematic. Yes but we think those rare enough to not be a concern. > I'm not sure what to say about the copy-on-change-after-toString > approach. As the offset/count fields have been removed from String then > it could only be the count == value.length case. It would clearly be a > win in some cases but no help in others. Right - I was still using a offset/count based mental model for String but that doesn't apply any more so we can't share directly except in one case. And from past experiences with StringBuffer issues it seems that accurately sizing the SB based on the expected final size is quite a rarity so the copy-on-write optimization is not worth pursuing (even if it were implementable in a reasonable way - thanks Peter for the additional investigation here!) So here is hopefully final webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/ It is the same approach as v3, but as Florian pointed out the cache should be cleared before the mutating action - just in case there is an exception. That leaves one issue that was flagged by a couple of folks: hotspot intrinsification of specific "string" usage patterns. I tracked this down in the hotspot code and I think it only applies in situations where the StringBuffer/StringBuilder could be elided completely - and so would not be an issue here. But I'm confirming this with the hotspot compiler folk (unfortunately the optimization is not clearly documented anywhere.) Thanks, David > -Alan. From joe.darcy at oracle.com Tue May 14 05:17:25 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 May 2013 22:17:25 -0700 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: References: <518D601E.6070701@oracle.com> Message-ID: <5191C8E5.2070108@oracle.com> Thanks for the review Mike, -Joe On 05/13/2013 10:06 PM, Mike Duigou wrote: > Looks fine to me. Welcome back Objects.requireNonNull(obj, Supplier)! > > Mike > > On May 10 2013, at 14:01 , Joe Darcy wrote: > >> Hello, >> >> Please (re)review this change to introduce Objects.requireNonNull(T, Supplier): >> >> http://cr.openjdk.java.net/~darcy/8014365.0/ >> >> The original change had to be pulled out because of a build issue (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build); I'll be asking for a review on build-dev of the build-related change in langtools. The test portion of the patch is slightly different than before because of the intervening changes made for >> >> 8013712: Add Objects.nonNull and Objects.isNull >> >> Thanks, >> >> -Joe From joe.darcy at oracle.com Tue May 14 05:17:06 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 14 May 2013 05:17:06 +0000 Subject: hg: jdk8/tl/jdk: 8014365: Restore Objects.requireNonNull(T, Supplier) Message-ID: <20130514051719.2348548A4D@hg.openjdk.java.net> Changeset: a50bad038f31 Author: darcy Date: 2013-05-13 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50bad038f31 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: mduigou ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java From david.holmes at oracle.com Tue May 14 05:22:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2013 15:22:31 +1000 Subject: Race in String.contentEquals ( was Re: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks) In-Reply-To: <51916A5D.7060203@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> Message-ID: <5191CA17.1080706@oracle.com> Thanks Peter! I've filed 8014477 Race condition in String.contentEquals when comparing with StringBuffer On 14/05/2013 8:34 AM, Peter Levart wrote: > On 05/14/2013 12:09 AM, Peter Levart wrote: >> I noticed a synchronization bug in String.contentEquals method. If >> called with a StringBuffer argument while concurrent thread is >> modifying the StringBuffer, the method can either throw >> ArrayIndexOutOfBoundsException or return true even though the content >> of the StringBuffer has never been the same as the String's. >> >> Here's a proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >> >> Regards, Peter > > Or even better (with some code clean-up): > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ This part is not correct I believe: 1010 private boolean nonSyncContentEquals(AbstractStringBuilder sb) { 1011 char v1[] = value; 1012 char v2[] = sb.getValue(); 1013 int n = v1.length; 1014 if (n != v2.length) { 1015 return false; 1016 } v2 can be larger than v1 if v2 is not being fully used (ie count < length). David ----- From xueming.shen at oracle.com Tue May 14 05:33:12 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 13 May 2013 22:33:12 -0700 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <5190EC13.2010000@oracle.com> References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com> <5190DB56.2000203@oracle.com> <5190EC13.2010000@oracle.com> Message-ID: <5191CC98.1020007@oracle.com> Ivan, It's a fair assessment to say "ZIS.available() is not the only cause..." though I don't think it's that easy to really "craft" a real test case to demonstrate the failure with a "malformed" gzip entry inside a zip file. At least I don't think I can create one without sitting down with some real calculation:-) Or, I'm missing something in your test case? It appears you will have to have the inflater of the GZIPInputStream to happen to have only 8 bytes left in its input buffer as the "remaining" when it is done inflating the gzip stream, otherwise the this.in.available() will never > 0 (in case of < 8 byte, the trailer reading will trigger the ZIS to "fill", in which the fixed/non-customizable 512 buffer size of ZIS will guarantee to exhaust the whole entry bytes and result in the this.is.available() to return 0; if n > 8, means all bytes, including the malformed byte(s) attached, have been in the GZIS.inf's remaining buffer, so the this.is.available() will now returns 0 as well) which also means you need the ZipInputStream "happens" to be filled and inflated all bytes of the "gzip-streamed" entry, except the last one byte (malformed), in its last filling/inflating... It's also arguable that we are now discussing a "malformed" gzip entry inside a zip stream, which is not exactly the original "regression" that we are trying to address... But, given the current GZIS implementation ignores this type of "malformed" stream (un-necessarily attached bytes at the end), it's reasonable to request that reading from such an gzip-streamed entry of a zip entry should succeed as well. And the proposed/pushed fix might be the easiest approach to solve this "malformed gzip stream inside a zip entry" corner case for now. So I would suggest to consider combining the existing fix + the available() change (I would need a deep look to see if it has any "compatibility" impact...) -Sherman On 05/13/2013 06:35 AM, Ivan Gerasimov wrote: > A small correction to the recipe for failure. > The failure is reproduced when a SINGLE byte is appended to the gzip archive. > In the scenario below the echo command appends TWO bytes. These two bytes are interpreted as a wrong gzip header and get successfully ignored. > > On 13.05.2013 16:23, Ivan Gerasimov wrote: >> Hello Sherman! >> >> Thank you for the review! >> While I agree with you that current implementation of ZipInputStream.available() is not what it's supposed to be, I doubt it is the only cause of the issue. >> Please consider the following example. >> Zip archive (z.zip) consists of two entries: f1 and f2. >> f1 - gzip archive concatenated with a couple of bytes (I understand it's malformed gzip archive), >> f2 - let it be a single byte text file. >> >> $ echo a > f1 >> $ echo b > f2 >> $ gzip f1 >> $ echo a >> f1.gz >> $ zip z.zip f1.gz f2 >> >> public class ZipMix { >> private static byte[] rbuf = new byte[1]; >> public static void main(String[] args) throws Throwable { >> FileInputStream fis = new FileInputStream("z.zip"); >> ZipInputStream zis = new ZipInputStream(fis); >> System.out.print("-start-\n"); >> if (zis.getNextEntry() != null) { >> InputStream gis = new GZIPInputStream(zis, 8192); >> while (gis.read(rbuf) != -1) >> System.out.print(new String(rbuf)); >> } >> if (zis.getNextEntry() != null) { // <--- throws IOException >> while (zis.read(rbuf) != -1) >> System.out.print(new String(rbuf)); >> } >> System.out.print("\n-finish-\n"); >> } >> } >> >> This code worked well with jdk1.6.20, since GZIPInputStream hadn't tried to read beyond the trailer. >> This breaks with the current jdk, since GZIPInputStream tries to read yet another gzip header after the first trailer, and SequenceInputStream.read() calls the close() method for underlying stream. >> And this would break even with the ZipInputStream.available() fixed. >> >> It seems to me that the root cause here is using SequenceInputStream, which can close the stream during the read() call. >> And this is what my fix was about - to prevent closing of the underlying stream. >> >> Sincerely yours, >> Ivan >> >> >> On 11.05.2013 2:48, Xueming Shen wrote: >>> The proposed fix does solve the issue. >>> >>> However it appears it does not fix the root cause that triggers this problem. >>> The root cause, or the direct trigger of this bug is the fact that ZipInputStream >>> .availble() is really NOT reliable to tell us whether or not there is any byte >>> "available" to be read from the input stream. The api doc of the ZIS.available() >>> specifies "Returns 0 after EOF has reached for the current entry data, otherwise >>> always return 1.". The implementation is straightforward, >>> >>> public int available() throws IOException { >>> if (entryEOF) { >>> return 0; >>> } else { >>> return 1; >>> } >>> } >>> >>> However, the flag "entryEOF" is only set if a read attempt has been tried >>> and failed (see ZIS.read()), which means if a previous read of the entry >>> succeeded and it actually read all the available bytes from the entry (with >>> a big enough buffer), there is 0 byte available for read, the "flag" is not >>> set, so if you invoke zis.available(), it return 1, but a read() invocation will >>> returns -1 (yes, if you then try zis.available() again , it returns the expected >>> 0). The test below demonstrates this issue. >>> >>> public static void main(String args[]) throws IOException { >>> ZipInputStream zis = new ZipInputStream(new FileInputStream(args[0])); >>> ZipEntry ze; >>> while((ze = zis.getNextEntry()) !=null) { >>> System.out.println("--------------" + ze.getName() + "--------"); >>> byte[] buf = new byte[8102]; >>> >>> while (true) { >>> System.out.println(" zis.available()=" + zis.available()); >>> int n = zis.read(buf, 0, buf.length); >>> System.out.println(" readN=" + n); >>> if (n == -1) >>> break; >>> } >>> } >>> >>> } >>> >>> It is arguable that the this is not an implementation bug, since it is reasonable >>> to argue that the EOF has not been "really" reached yet after the first try, the >>> implementation happens to return all available bytes, so the next read try finally >>> "reached" the EOF, but this obviously is not the expectation. >>> >>> Unfortunately the fix we put in for #4691425 [1] logically depends on >>> in.available() to decide whether or not we need to read a little further, which >>> directly triggers this bug when the ZIS.available() "lies". >>> >>> // If there are more bytes available in "in" or >>> // the leftover in the "inf" is > 26 bytes: >>> // this.trailer(8) + next.header.min(10) + next.trailer(8) >>> // try concatenated case >>> if (this.in.available() > 0 || n > 26) { >>> .... >>> } >>> >>> Not only ZInputStream has this issue, its parent class InflaterStream (and >>> its sibling GZIPInputStream, GZS inherits InflaterStream's available() >>> implementation directly) has the same issue, I do have a bug#7031075 >>> filed against GZIPInputStream. >>> >>> So the proposed fix is more a workaround for this available() issue. The >>> alternative is to fix the issue directly, for example, to change the ZIS's >>> available implementation to something like >>> >>> public int available() throws IOException { >>> ensureOpen(); >>> if (entryEOF || entry == null) >>> return 0; >>> switch (entry.method) { >>> case DEFLATED: >>> return (inf.finished() || inf.needsDictionary()) ? 0 : 1; >>> case STORED: >>> return remaining > 0 ? 1 : 0; >>> default: >>> throw new ZipException("invalid compression method"); >>> } >>> } >>> >>> we probably should go further to simply remove the flag "entryEOF" >>> and move the "deflated" case implementation into InflaterInputStream >>> (to fix 7031075 as well). >>> >>> -Sherman >>> >>> >>> [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/ >>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075 >>> >>> On 05/10/2013 01:03 AM, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> GzipInputStream uses SequenceInputStream to concatenate the underlying stream with some data that reside in memory. >>>> SequenceInputStream is implementing in such a way that it closes the stream when it reaches EOS. >>>> >>>> The solution is to wrap the underlying stream with extended FilterInputStream that overrides the close() method. >>>> >>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 >>>> WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ >>>> >>>> Sincerely your, >>>> Ivan >>>> >>> >>> >>> >> >> >> > From peter.levart at gmail.com Tue May 14 05:53:11 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 May 2013 07:53:11 +0200 Subject: Race in String.contentEquals ( was Re: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks) In-Reply-To: <5191CA17.1080706@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> Message-ID: Right, sb.length() should be used. I will correct that as soon as I get to the keyboard. Regards, Peter On May 14, 2013 7:22 AM, "David Holmes" wrote: > Thanks Peter! I've filed > > 8014477 > Race condition in String.contentEquals when comparing with StringBuffer > > On 14/05/2013 8:34 AM, Peter Levart wrote: > >> On 05/14/2013 12:09 AM, Peter Levart wrote: >> >>> I noticed a synchronization bug in String.contentEquals method. If >>> called with a StringBuffer argument while concurrent thread is >>> modifying the StringBuffer, the method can either throw >>> ArrayIndexOutOfBoundsException or return true even though the content >>> of the StringBuffer has never been the same as the String's. >>> >>> Here's a proposed patch: >>> >>> http://cr.openjdk.java.net/~**plevart/jdk8-tl/String.** >>> contentEquals/webrev.01/ >>> >>> Regards, Peter >>> >> >> Or even better (with some code clean-up): >> >> http://cr.openjdk.java.net/~**plevart/jdk8-tl/String.** >> contentEquals/webrev.02/ >> > > This part is not correct I believe: > > 1010 private boolean nonSyncContentEquals(**AbstractStringBuilder sb) > { > 1011 char v1[] = value; > 1012 char v2[] = sb.getValue(); > 1013 int n = v1.length; > 1014 if (n != v2.length) { > 1015 return false; > 1016 } > > v2 can be larger than v1 if v2 is not being fully used (ie count < length). > > David > ----- > From paul.sandoz at oracle.com Tue May 14 07:17:17 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 May 2013 09:17:17 +0200 Subject: RFR 8014133: Spliterator.OfPrimitive Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/webrev/ http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/specdiff/overview-summary.html This enables more sharing of primitive-based spliterator code and should also reduce the bloat of primitive-based concat spliterator implementations, if we choose to add concatenation of primitive-based streams. Paul. From forax at univ-mlv.fr Tue May 14 10:12:54 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 May 2013 12:12:54 +0200 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <5191C74C.7030907@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191C74C.7030907@oracle.com> Message-ID: <51920E26.9030702@univ-mlv.fr> On 05/14/2013 07:10 AM, David Holmes wrote: [...] > > So here is hopefully final webrev: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/ > > It is the same approach as v3, but as Florian pointed out the cache > should be cleared before the mutating action - just in case there is > an exception. > > That leaves one issue that was flagged by a couple of folks: hotspot > intrinsification of specific "string" usage patterns. I tracked this > down in the hotspot code and I think it only applies in situations > where the StringBuffer/StringBuilder could be elided completely - and > so would not be an issue here. But I'm confirming this with the > hotspot compiler folk (unfortunately the optimization is not clearly > documented anywhere.) > > Thanks, > David thumb up for me. R?mi From Alan.Bateman at oracle.com Tue May 14 11:03:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 12:03:36 +0100 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <5191C74C.7030907@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191C74C.7030907@oracle.com> Message-ID: <51921A08.3010901@oracle.com> On 14/05/2013 06:10, David Holmes wrote: > : > >> I'm not sure what to say about the copy-on-change-after-toString >> approach. As the offset/count fields have been removed from String then >> it could only be the count == value.length case. It would clearly be a >> win in some cases but no help in others. > > Right - I was still using a offset/count based mental model for String > but that doesn't apply any more so we can't share directly except in > one case. And from past experiences with StringBuffer issues it seems > that accurately sizing the SB based on the expected final size is > quite a rarity so the copy-on-write optimization is not worth pursuing > (even if it were implementable in a reasonable way - thanks Peter for > the additional investigation here!) > > So here is hopefully final webrev: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/ > > It is the same approach as v3, but as Florian pointed out the cache > should be cleared before the mutating action - just in case there is > an exception. I think we should go with this version, it looks good. -Alan From peter.levart at gmail.com Tue May 14 11:04:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 May 2013 13:04:41 +0200 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> Message-ID: <51921A49.3030900@gmail.com> Ok, here's the corrected fix: http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ I also added a reproducer for the bug. Regards, peter On 05/14/2013 07:53 AM, Peter Levart wrote: > > Right, sb.length() should be used. I will correct that as soon as I > get to the keyboard. > > Regards, Peter > > On May 14, 2013 7:22 AM, "David Holmes" > wrote: > > Thanks Peter! I've filed > > 8014477 > Race condition in String.contentEquals when comparing with > StringBuffer > > On 14/05/2013 8:34 AM, Peter Levart wrote: > > On 05/14/2013 12:09 AM, Peter Levart wrote: > > I noticed a synchronization bug in String.contentEquals > method. If > called with a StringBuffer argument while concurrent thread is > modifying the StringBuffer, the method can either throw > ArrayIndexOutOfBoundsException or return true even though > the content > of the StringBuffer has never been the same as the String's. > > Here's a proposed patch: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ > > > Regards, Peter > > > Or even better (with some code clean-up): > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ > > > > This part is not correct I believe: > > 1010 private boolean > nonSyncContentEquals(AbstractStringBuilder sb) { > 1011 char v1[] = value; > 1012 char v2[] = sb.getValue(); > 1013 int n = v1.length; > 1014 if (n != v2.length) { > 1015 return false; > 1016 } > > v2 can be larger than v1 if v2 is not being fully used (ie count < > length). > > David > ----- > From david.holmes at oracle.com Tue May 14 11:17:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2013 21:17:44 +1000 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51921A49.3030900@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> Message-ID: <51921D58.5010700@oracle.com> Thanks Peter this looks good to me. One minor thing please set the correct copyright year in the test, it should just be Copyright (c) 2013, Oracle ... I couldn't get the test to actually fail, but I can see that it could. David On 14/05/2013 9:04 PM, Peter Levart wrote: > Ok, here's the corrected fix: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ > > I also added a reproducer for the bug. > > Regards, peter > > On 05/14/2013 07:53 AM, Peter Levart wrote: >> >> Right, sb.length() should be used. I will correct that as soon as I >> get to the keyboard. >> >> Regards, Peter >> >> On May 14, 2013 7:22 AM, "David Holmes" > > wrote: >> >> Thanks Peter! I've filed >> >> 8014477 >> Race condition in String.contentEquals when comparing with >> StringBuffer >> >> On 14/05/2013 8:34 AM, Peter Levart wrote: >> >> On 05/14/2013 12:09 AM, Peter Levart wrote: >> >> I noticed a synchronization bug in String.contentEquals >> method. If >> called with a StringBuffer argument while concurrent thread is >> modifying the StringBuffer, the method can either throw >> ArrayIndexOutOfBoundsException or return true even though >> the content >> of the StringBuffer has never been the same as the String's. >> >> Here's a proposed patch: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >> >> >> Regards, Peter >> >> >> Or even better (with some code clean-up): >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >> >> >> >> This part is not correct I believe: >> >> 1010 private boolean >> nonSyncContentEquals(AbstractStringBuilder sb) { >> 1011 char v1[] = value; >> 1012 char v2[] = sb.getValue(); >> 1013 int n = v1.length; >> 1014 if (n != v2.length) { >> 1015 return false; >> 1016 } >> >> v2 can be larger than v1 if v2 is not being fully used (ie count < >> length). >> >> David >> ----- >> > From Alan.Bateman at oracle.com Tue May 14 11:21:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 12:21:48 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <51919A9B.4030700@oracle.com> References: <51919A9B.4030700@oracle.com> Message-ID: <51921E4C.506@oracle.com> On 14/05/2013 02:59, Rob McKenna wrote: > Hi folks, > > Looking for a review of this suggested fix from Fujitsu. > GetFileAttributesExW() returns ERROR_SHARING_VIOLATION for > pagefile.sys and hiberfi.sys so we're falling back to FindFirstFile > instead: > > http://cr.openjdk.java.net/~robm/7038105/webrev.01/ > > -Rob Thanks for taking this one and removed the crud that is the harding of c:\pagefile.sys. Using FindFirstFile when GetFileAttributesExW fails when ERROR_SHARING_VIOLATION is the right approach but it needs an additional check on the attributes to see if they contain a reparse point, otherwise you return the attributes of the reparse point rather than the final file (try it with a symbolic link and you'll see what I mean). When it contains a reparse point then you can use getFileInformation to attempt to open the file (with sharing) and obtain the attributes. One other idea is to rename it to getFinalAttributes and move it up to near the top so that it's with the other support functions. -Alan. From peter.levart at gmail.com Tue May 14 11:34:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 14 May 2013 13:34:16 +0200 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51921D58.5010700@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> Message-ID: <51922138.4050909@gmail.com> On 05/14/2013 01:17 PM, David Holmes wrote: > Thanks Peter this looks good to me. > > One minor thing please set the correct copyright year in the test, it > should just be > > Copyright (c) 2013, Oracle ... Ok, fixed: http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ > > I couldn't get the test to actually fail, but I can see that it could. Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails immediately and always. You could try varying the number of concurrent threads and or the time to wait for exception to be thrown... > > David > > On 14/05/2013 9:04 PM, Peter Levart wrote: >> Ok, here's the corrected fix: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >> >> >> I also added a reproducer for the bug. >> >> Regards, peter >> >> On 05/14/2013 07:53 AM, Peter Levart wrote: >>> >>> Right, sb.length() should be used. I will correct that as soon as I >>> get to the keyboard. >>> >>> Regards, Peter >>> >>> On May 14, 2013 7:22 AM, "David Holmes" >> > wrote: >>> >>> Thanks Peter! I've filed >>> >>> 8014477 >>> Race condition in String.contentEquals when comparing with >>> StringBuffer >>> >>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>> >>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>> >>> I noticed a synchronization bug in String.contentEquals >>> method. If >>> called with a StringBuffer argument while concurrent >>> thread is >>> modifying the StringBuffer, the method can either throw >>> ArrayIndexOutOfBoundsException or return true even though >>> the content >>> of the StringBuffer has never been the same as the >>> String's. >>> >>> Here's a proposed patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>> >>> >>> Regards, Peter >>> >>> >>> Or even better (with some code clean-up): >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>> >>> >>> >>> This part is not correct I believe: >>> >>> 1010 private boolean >>> nonSyncContentEquals(AbstractStringBuilder sb) { >>> 1011 char v1[] = value; >>> 1012 char v2[] = sb.getValue(); >>> 1013 int n = v1.length; >>> 1014 if (n != v2.length) { >>> 1015 return false; >>> 1016 } >>> >>> v2 can be larger than v1 if v2 is not being fully used (ie count < >>> length). >>> >>> David >>> ----- >>> >> From Alan.Bateman at oracle.com Tue May 14 12:16:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 13:16:30 +0100 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Message-ID: <51922B1E.9080906@oracle.com> The bootcycle-images target is currently broken in jdk8/tl. Jon has taken 8014461 to fix genstubs but once you get past that then the CLDRConverter fails parsing LDML due to DTD references that aren't allowed by the default policy in jdk8 (since the update to JAXP 1.5). This policy is due to be re-visited later in jdk8 and I expect it will need to allow at least access to the DTDs on the file system. For now, and to get the boot cycle builds going again, I propose to update the CLDRConverter to set the accessExternalDTD property. Attached is the proposed patch. It uses a hard-coded string rather than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an older version of JAXP where this constant isn't defined. Thanks, Alan. diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java @@ -34,6 +34,8 @@ import java.util.*; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; +import org.xml.sax.SAXNotRecognizedException; +import org.xml.sax.SAXNotSupportedException; /** @@ -234,6 +236,17 @@ } } + /** + * Configure the parser to allow access to DTDs on the file system. + */ + private static void enableFileAccess(SAXParser parser) throws SAXNotSupportedException { + try { + parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", "file"); + } catch (SAXNotRecognizedException ignore) { + // property requires >= JAXP 1.5 + } + } + private static List readBundleList() throws Exception { ResourceBundle.Control defCon = ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); List retList = new ArrayList<>(); @@ -279,6 +292,7 @@ SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setValidating(true); SAXParser parser = factory.newSAXParser(); + enableFileAccess(parser); LDMLParseHandler handler = new LDMLParseHandler(id); File file = new File(SOURCE_FILE_DIR + File.separator + id + ".xml"); if (!file.exists()) { @@ -314,6 +328,7 @@ SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); factorySuppl.setValidating(true); SAXParser parserSuppl = factorySuppl.newSAXParser(); + enableFileAccess(parserSuppl); handlerSuppl = new SupplementDataParseHandler(); File fileSupply = new File(SPPL_SOURCE_FILE); parserSuppl.parse(fileSupply, handlerSuppl); @@ -322,6 +337,7 @@ SAXParserFactory numberingParser = SAXParserFactory.newInstance(); numberingParser.setValidating(true); SAXParser parserNumbering = numberingParser.newSAXParser(); + enableFileAccess(parserNumbering); handlerNumbering = new NumberingSystemsParseHandler(); File fileNumbering = new File(NUMBERING_SOURCE_FILE); parserNumbering.parse(fileNumbering, handlerNumbering); @@ -330,6 +346,7 @@ SAXParserFactory metazonesParser = SAXParserFactory.newInstance(); metazonesParser.setValidating(true); SAXParser parserMetaZones = metazonesParser.newSAXParser(); + enableFileAccess(parserMetaZones); handlerMetaZones = new MetaZonesParseHandler(); File fileMetaZones = new File(METAZONES_SOURCE_FILE); parserNumbering.parse(fileMetaZones, handlerMetaZones); From Lance.Andersen at oracle.com Tue May 14 12:27:05 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 14 May 2013 08:27:05 -0400 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 In-Reply-To: <51922B1E.9080906@oracle.com> References: <51922B1E.9080906@oracle.com> Message-ID: <1DD757D6-CB7C-4B22-996E-B2F65FD4BAD0@oracle.com> +1 On May 14, 2013, at 8:16 AM, Alan Bateman wrote: > > The bootcycle-images target is currently broken in jdk8/tl. > > Jon has taken 8014461 to fix genstubs but once you get past that then the CLDRConverter fails parsing LDML due to DTD references that aren't allowed by the default policy in jdk8 (since the update to JAXP 1.5). This policy is due to be re-visited later in jdk8 and I expect it will need to allow at least access to the DTDs on the file system. For now, and to get the boot cycle builds going again, I propose to update the CLDRConverter to set the accessExternalDTD property. > > Attached is the proposed patch. It uses a hard-coded string rather than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an older version of JAXP where this constant isn't defined. > > Thanks, > Alan. > > > > diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > @@ -34,6 +34,8 @@ > import java.util.*; > import javax.xml.parsers.SAXParser; > import javax.xml.parsers.SAXParserFactory; > +import org.xml.sax.SAXNotRecognizedException; > +import org.xml.sax.SAXNotSupportedException; > > > /** > @@ -234,6 +236,17 @@ > } > } > > + /** > + * Configure the parser to allow access to DTDs on the file system. > + */ > + private static void enableFileAccess(SAXParser parser) throws SAXNotSupportedException { > + try { > + parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", "file"); > + } catch (SAXNotRecognizedException ignore) { > + // property requires >= JAXP 1.5 > + } > + } > + > private static List readBundleList() throws Exception { > ResourceBundle.Control defCon = ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); > List retList = new ArrayList<>(); > @@ -279,6 +292,7 @@ > SAXParserFactory factory = SAXParserFactory.newInstance(); > factory.setValidating(true); > SAXParser parser = factory.newSAXParser(); > + enableFileAccess(parser); > LDMLParseHandler handler = new LDMLParseHandler(id); > File file = new File(SOURCE_FILE_DIR + File.separator + id + ".xml"); > if (!file.exists()) { > @@ -314,6 +328,7 @@ > SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); > factorySuppl.setValidating(true); > SAXParser parserSuppl = factorySuppl.newSAXParser(); > + enableFileAccess(parserSuppl); > handlerSuppl = new SupplementDataParseHandler(); > File fileSupply = new File(SPPL_SOURCE_FILE); > parserSuppl.parse(fileSupply, handlerSuppl); > @@ -322,6 +337,7 @@ > SAXParserFactory numberingParser = SAXParserFactory.newInstance(); > numberingParser.setValidating(true); > SAXParser parserNumbering = numberingParser.newSAXParser(); > + enableFileAccess(parserNumbering); > handlerNumbering = new NumberingSystemsParseHandler(); > File fileNumbering = new File(NUMBERING_SOURCE_FILE); > parserNumbering.parse(fileNumbering, handlerNumbering); > @@ -330,6 +346,7 @@ > SAXParserFactory metazonesParser = SAXParserFactory.newInstance(); > metazonesParser.setValidating(true); > SAXParser parserMetaZones = metazonesParser.newSAXParser(); > + enableFileAccess(parserMetaZones); > handlerMetaZones = new MetaZonesParseHandler(); > File fileMetaZones = new File(METAZONES_SOURCE_FILE); > parserNumbering.parse(fileMetaZones, handlerMetaZones); -------------- 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 Tue May 14 13:32:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 14:32:52 +0100 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <518D601E.6070701@oracle.com> References: <518D601E.6070701@oracle.com> Message-ID: <51923D04.7000308@oracle.com> On 10/05/2013 22:01, Joe Darcy wrote: > Hello, > > Please (re)review this change to introduce Objects.requireNonNull(T, > Supplier): > > http://cr.openjdk.java.net/~darcy/8014365.0/ > > The original change had to be pulled out because of a build issue > (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs > build); I'll be asking for a review on build-dev of the build-related > change in langtools. The test portion of the patch is slightly > different than before because of the intervening changes made for > > 8013712: Add Objects.nonNull and Objects.isNull I realize this has already been pushed but just to point out a missing parenthesis on line 272 in the javadoc, needs to be ")}". -Alan. From alan.bateman at oracle.com Tue May 14 13:34:06 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 14 May 2013 13:34:06 +0000 Subject: hg: jdk8/tl/jdk: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Message-ID: <20130514133439.831AD48A64@hg.openjdk.java.net> Changeset: b315cb9a7544 Author: alanb Date: 2013-05-14 14:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b315cb9a7544 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Reviewed-by: lancea ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java From Alan.Bateman at oracle.com Tue May 14 14:25:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 15:25:19 +0100 Subject: Time to put a stop to Thread.stop? Message-ID: <5192494F.6040609@oracle.com> I would like to broach the subject of pulling out the implementation of Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I mean changing it to unconditionally throw UnsupportedOperationException. As we all know, these methods have been deprecated since 1998 so that's 15 years to design out any need for these methods. That said, I periodically come across code that uses no-arg Thread.stop(). David Holmes mentioned to me recently that he came across a usage in the recent past too. I don't think I've ever come across code using Thread.stop(Throwable) and this one is arguably the most dangerous of the group. So I'm curious if anyone has come across a Thread.stop(Throwable) usage in recent times. Clearly changing this would be a significant change but the real impact might be close to zero. If we decide this is the right thing to do then there is a bit of detail to work out, that's for later. -Alan. From brian.goetz at oracle.com Tue May 14 14:37:00 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 May 2013 10:37:00 -0400 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5192494F.6040609@oracle.com> References: <5192494F.6040609@oracle.com> Message-ID: <2BAC80D5-A128-4960-A685-F6BFFB33DA49@oracle.com> If we can't deprecate this, we might as well deprecate @Deprecated. On May 14, 2013, at 10:25 AM, Alan Bateman wrote: > > I would like to broach the subject of pulling out the implementation of Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I mean changing it to unconditionally throw UnsupportedOperationException. > > As we all know, these methods have been deprecated since 1998 so that's 15 years to design out any need for these methods. That said, I periodically come across code that uses no-arg Thread.stop(). David Holmes mentioned to me recently that he came across a usage in the recent past too. I don't think I've ever come across code using Thread.stop(Throwable) and this one is arguably the most dangerous of the group. > > So I'm curious if anyone has come across a Thread.stop(Throwable) usage in recent times. Clearly changing this would be a significant change but the real impact might be close to zero. If we decide this is the right thing to do then there is a bit of detail to work out, that's for later. > > -Alan. From erik.joelsson at oracle.com Tue May 14 14:36:42 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 May 2013 16:36:42 +0200 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 In-Reply-To: <51922B1E.9080906@oracle.com> References: <51922B1E.9080906@oracle.com> Message-ID: <51924BFA.3060800@oracle.com> Looks good from the build side. /Erik On 2013-05-14 14:16, Alan Bateman wrote: > > The bootcycle-images target is currently broken in jdk8/tl. > > Jon has taken 8014461 to fix genstubs but once you get past that then > the CLDRConverter fails parsing LDML due to DTD references that aren't > allowed by the default policy in jdk8 (since the update to JAXP 1.5). > This policy is due to be re-visited later in jdk8 and I expect it will > need to allow at least access to the DTDs on the file system. For now, > and to get the boot cycle builds going again, I propose to update the > CLDRConverter to set the accessExternalDTD property. > > Attached is the proposed patch. It uses a hard-coded string rather > than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely > have an older version of JAXP where this constant isn't defined. > > Thanks, > Alan. > > > > diff --git > a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > @@ -34,6 +34,8 @@ > import java.util.*; > import javax.xml.parsers.SAXParser; > import javax.xml.parsers.SAXParserFactory; > +import org.xml.sax.SAXNotRecognizedException; > +import org.xml.sax.SAXNotSupportedException; > > > /** > @@ -234,6 +236,17 @@ > } > } > > + /** > + * Configure the parser to allow access to DTDs on the file system. > + */ > + private static void enableFileAccess(SAXParser parser) throws > SAXNotSupportedException { > + try { > + > parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", > "file"); > + } catch (SAXNotRecognizedException ignore) { > + // property requires >= JAXP 1.5 > + } > + } > + > private static List readBundleList() throws Exception { > ResourceBundle.Control defCon = > ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); > List retList = new ArrayList<>(); > @@ -279,6 +292,7 @@ > SAXParserFactory factory = SAXParserFactory.newInstance(); > factory.setValidating(true); > SAXParser parser = factory.newSAXParser(); > + enableFileAccess(parser); > LDMLParseHandler handler = new LDMLParseHandler(id); > File file = new File(SOURCE_FILE_DIR + File.separator + id + > ".xml"); > if (!file.exists()) { > @@ -314,6 +328,7 @@ > SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); > factorySuppl.setValidating(true); > SAXParser parserSuppl = factorySuppl.newSAXParser(); > + enableFileAccess(parserSuppl); > handlerSuppl = new SupplementDataParseHandler(); > File fileSupply = new File(SPPL_SOURCE_FILE); > parserSuppl.parse(fileSupply, handlerSuppl); > @@ -322,6 +337,7 @@ > SAXParserFactory numberingParser = > SAXParserFactory.newInstance(); > numberingParser.setValidating(true); > SAXParser parserNumbering = numberingParser.newSAXParser(); > + enableFileAccess(parserNumbering); > handlerNumbering = new NumberingSystemsParseHandler(); > File fileNumbering = new File(NUMBERING_SOURCE_FILE); > parserNumbering.parse(fileNumbering, handlerNumbering); > @@ -330,6 +346,7 @@ > SAXParserFactory metazonesParser = > SAXParserFactory.newInstance(); > metazonesParser.setValidating(true); > SAXParser parserMetaZones = metazonesParser.newSAXParser(); > + enableFileAccess(parserMetaZones); > handlerMetaZones = new MetaZonesParseHandler(); > File fileMetaZones = new File(METAZONES_SOURCE_FILE); > parserNumbering.parse(fileMetaZones, handlerMetaZones); From jeroen at sumatra.nl Tue May 14 14:45:43 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Tue, 14 May 2013 14:45:43 +0000 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5192494F.6040609@oracle.com> References: <5192494F.6040609@oracle.com> Message-ID: <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> IMO Thread.currentThread().stop(new Throwable()) should continue to work. It is not unsafe and it is probably used in a lot of code to workaround the madness that is checked exceptions. > -----Original Message----- > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > bounces at openjdk.java.net] On Behalf Of Alan Bateman > Sent: Tuesday, May 14, 2013 16:25 > To: core-libs-dev > Subject: Time to put a stop to Thread.stop? > > > I would like to broach the subject of pulling out the implementation of > Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I > mean changing it to unconditionally throw UnsupportedOperationException. > > As we all know, these methods have been deprecated since 1998 so that's > 15 years to design out any need for these methods. That said, I > periodically come across code that uses no-arg Thread.stop(). David > Holmes mentioned to me recently that he came across a usage in the > recent past too. I don't think I've ever come across code using > Thread.stop(Throwable) and this one is arguably the most dangerous of > the group. > > So I'm curious if anyone has come across a Thread.stop(Throwable) usage > in recent times. Clearly changing this would be a significant change but > the real impact might be close to zero. If we decide this is the right > thing to do then there is a bit of detail to work out, that's for later. > > -Alan. From forax at univ-mlv.fr Tue May 14 15:29:17 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 May 2013 17:29:17 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> Message-ID: <5192584D.5070503@univ-mlv.fr> On 05/14/2013 04:45 PM, Jeroen Frijters wrote: > IMO Thread.currentThread().stop(new Throwable()) should continue to work. It is not unsafe and it is probably used in a lot of code to workaround the madness that is checked exceptions. This hack doesn't work well because Thread.stop(Throwable) can call the security manager. Using a raw type to see an Exception as a RuntimeException is a better hack, obviously tunnelling the exception in a runtimee one (as a cause) is the safe way to do that. R?mi > >> -----Original Message----- >> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- >> bounces at openjdk.java.net] On Behalf Of Alan Bateman >> Sent: Tuesday, May 14, 2013 16:25 >> To: core-libs-dev >> Subject: Time to put a stop to Thread.stop? >> >> >> I would like to broach the subject of pulling out the implementation of >> Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I >> mean changing it to unconditionally throw UnsupportedOperationException. >> >> As we all know, these methods have been deprecated since 1998 so that's >> 15 years to design out any need for these methods. That said, I >> periodically come across code that uses no-arg Thread.stop(). David >> Holmes mentioned to me recently that he came across a usage in the >> recent past too. I don't think I've ever come across code using >> Thread.stop(Throwable) and this one is arguably the most dangerous of >> the group. >> >> So I'm curious if anyone has come across a Thread.stop(Throwable) usage >> in recent times. Clearly changing this would be a significant change but >> the real impact might be close to zero. If we decide this is the right >> thing to do then there is a bit of detail to work out, that's for later. >> >> -Alan. From mike.duigou at oracle.com Tue May 14 15:29:53 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 May 2013 08:29:53 -0700 Subject: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks In-Reply-To: <5191C74C.7030907@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191C74C.7030907@oracle.com> Message-ID: Looks good David. Mike On May 13 2013, at 22:10 , David Holmes wrote: > On 14/05/2013 5:05 AM, Alan Bateman wrote: >> On 13/05/2013 08:12, David Holmes wrote: >>> Thanks for all the feedback and discussion. I've rewritten the patch >>> to use Peter's suggestion of caching the char[] instead of the actual >>> String: >>> >>> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ >>> >>> I too am concerned that any form of caching that avoids the array-copy >>> (which is the crux of the issue) is going to incur a 2x space penalty. >>> I can imagine old but well-behaved code that uses StringBuffer rather >>> than StringBuilder where very long buffers are created and toString() >>> only called once - and they may get immediate or subsequent OOME due >>> to the extra char[]; or excessive GC activity might be induced if a >>> lot of StringBuffers are used. >> Assuming the well-behaved case is where the StringBuffer is discarded >> after calling toString then I wouldn't expect it to too different to >> today. That is, you have the 2x penalty when toString is called now. > > Thank you! I had been comparing the cached case with the ancient sharing case - where there was no space penalty. As you say in the existing code we already use 2x the space at the time toString is called, so no change in that regard. Doh! > >> Clearly there are other usages which could be problematic. > > Yes but we think those rare enough to not be a concern. > >> I'm not sure what to say about the copy-on-change-after-toString >> approach. As the offset/count fields have been removed from String then >> it could only be the count == value.length case. It would clearly be a >> win in some cases but no help in others. > > Right - I was still using a offset/count based mental model for String but that doesn't apply any more so we can't share directly except in one case. And from past experiences with StringBuffer issues it seems that accurately sizing the SB based on the expected final size is quite a rarity so the copy-on-write optimization is not worth pursuing (even if it were implementable in a reasonable way - thanks Peter for the additional investigation here!) > > So here is hopefully final webrev: > > http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/ > > It is the same approach as v3, but as Florian pointed out the cache should be cleared before the mutating action - just in case there is an exception. > > That leaves one issue that was flagged by a couple of folks: hotspot intrinsification of specific "string" usage patterns. I tracked this down in the hotspot code and I think it only applies in situations where the StringBuffer/StringBuilder could be elided completely - and so would not be an issue here. But I'm confirming this with the hotspot compiler folk (unfortunately the optimization is not clearly documented anywhere.) > > Thanks, > David > >> -Alan. From mike.duigou at oracle.com Tue May 14 15:39:17 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 May 2013 08:39:17 -0700 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51922138.4050909@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> Message-ID: Good to see the test added. I was also unable to reproduce the failure on my Core 2 Duo Mac laptop but the test and fix match up. Mike On May 14 2013, at 04:34 , Peter Levart wrote: > On 05/14/2013 01:17 PM, David Holmes wrote: >> Thanks Peter this looks good to me. >> >> One minor thing please set the correct copyright year in the test, it should just be >> >> Copyright (c) 2013, Oracle ... > > Ok, fixed: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ > > >> >> I couldn't get the test to actually fail, but I can see that it could. > > Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails immediately and always. You could try varying the number of concurrent threads and or the time to wait for exception to be thrown... > >> >> David >> >> On 14/05/2013 9:04 PM, Peter Levart wrote: >>> Ok, here's the corrected fix: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>> >>> I also added a reproducer for the bug. >>> >>> Regards, peter >>> >>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>> >>>> Right, sb.length() should be used. I will correct that as soon as I >>>> get to the keyboard. >>>> >>>> Regards, Peter >>>> >>>> On May 14, 2013 7:22 AM, "David Holmes" >>> > wrote: >>>> >>>> Thanks Peter! I've filed >>>> >>>> 8014477 >>>> Race condition in String.contentEquals when comparing with >>>> StringBuffer >>>> >>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>> >>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>> >>>> I noticed a synchronization bug in String.contentEquals >>>> method. If >>>> called with a StringBuffer argument while concurrent thread is >>>> modifying the StringBuffer, the method can either throw >>>> ArrayIndexOutOfBoundsException or return true even though >>>> the content >>>> of the StringBuffer has never been the same as the String's. >>>> >>>> Here's a proposed patch: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> Or even better (with some code clean-up): >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>> >>>> >>>> >>>> This part is not correct I believe: >>>> >>>> 1010 private boolean >>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>> 1011 char v1[] = value; >>>> 1012 char v2[] = sb.getValue(); >>>> 1013 int n = v1.length; >>>> 1014 if (n != v2.length) { >>>> 1015 return false; >>>> 1016 } >>>> >>>> v2 can be larger than v1 if v2 is not being fully used (ie count < >>>> length). >>>> >>>> David >>>> ----- >>>> >>> > From mike.duigou at oracle.com Tue May 14 15:41:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 May 2013 08:41:14 -0700 Subject: RFR 8014133: Spliterator.OfPrimitive In-Reply-To: References: Message-ID: Nice cleanup. Looks good. Mike On May 14 2013, at 00:17 , Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/webrev/ > http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/specdiff/overview-summary.html > > This enables more sharing of primitive-based spliterator code and should also reduce the bloat of primitive-based concat spliterator implementations, if we choose to add concatenation of primitive-based streams. > > Paul. > > From jeroen at sumatra.nl Tue May 14 15:46:20 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Tue, 14 May 2013 15:46:20 +0000 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5192584D.5070503@univ-mlv.fr> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192584D.5070503@univ-mlv.fr> Message-ID: I agree that (ab)using generics is the better way, but that doesn't matter, this trick is much older so it is probably used somewhere and there is no good reason to break it. I'm fully in favor of removing the ability to throw arbitrary exceptions on other threads. IKVM doesn't support this and I've never seen any code break. Regards, Jeroen > -----Original Message----- > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > bounces at openjdk.java.net] On Behalf Of Remi Forax > Sent: Tuesday, May 14, 2013 17:29 > To: core-libs-dev at openjdk.java.net > Subject: Re: Time to put a stop to Thread.stop? > > On 05/14/2013 04:45 PM, Jeroen Frijters wrote: > > IMO Thread.currentThread().stop(new Throwable()) should continue to > work. It is not unsafe and it is probably used in a lot of code to > workaround the madness that is checked exceptions. > > This hack doesn't work well because Thread.stop(Throwable) can call the > security manager. > > Using a raw type to see an Exception as a RuntimeException is a better > hack, obviously tunnelling the exception in a runtimee one (as a cause) > is the safe way to do that. > > R?mi > > > > >> -----Original Message----- > >> From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > >> bounces at openjdk.java.net] On Behalf Of Alan Bateman > >> Sent: Tuesday, May 14, 2013 16:25 > >> To: core-libs-dev > >> Subject: Time to put a stop to Thread.stop? > >> > >> > >> I would like to broach the subject of pulling out the implementation > >> of Thread.stop(Throwable), maybe suspend/resume later. By "pulling > >> out" I mean changing it to unconditionally throw > UnsupportedOperationException. > >> > >> As we all know, these methods have been deprecated since 1998 so > >> that's > >> 15 years to design out any need for these methods. That said, I > >> periodically come across code that uses no-arg Thread.stop(). David > >> Holmes mentioned to me recently that he came across a usage in the > >> recent past too. I don't think I've ever come across code using > >> Thread.stop(Throwable) and this one is arguably the most dangerous of > >> the group. > >> > >> So I'm curious if anyone has come across a Thread.stop(Throwable) > >> usage in recent times. Clearly changing this would be a significant > >> change but the real impact might be close to zero. If we decide this > >> is the right thing to do then there is a bit of detail to work out, > that's for later. > >> > >> -Alan. From alexey.utkin at oracle.com Tue May 14 16:24:25 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Tue, 14 May 2013 16:24:25 +0000 Subject: hg: jdk8/tl/jdk: 8012453: (process) Runtime.exec(String) fails if command contains spaces [win] Message-ID: <20130514162448.4EEF748A74@hg.openjdk.java.net> Changeset: 5ea5f5dfb96a Author: uta Date: 2013-05-14 20:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ea5f5dfb96a 8012453: (process) Runtime.exec(String) fails if command contains spaces [win] Reviewed-by: alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/windows/classes/java/lang/ProcessImpl.java + test/java/lang/Runtime/exec/ExecCommand.java From martinrb at google.com Tue May 14 16:57:27 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 14 May 2013 09:57:27 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> Message-ID: On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters wrote: > IMO Thread.currentThread().stop(new Throwable()) should continue to work. > It is not unsafe and it is probably used in a lot of code to workaround the > madness that is checked exceptions. > > There are existing JDK tests that use currentThread().stop to implement the occasionally necessary sneakyThrow. I suspect there are important uses of unsafe otherThread.stop in the real world, where it is used as a last resort to shut down an "application" running within a java vm, and works reasonably well in practice. From sundararajan.athijegannathan at oracle.com Tue May 14 17:07:18 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 14 May 2013 17:07:18 +0000 Subject: hg: jdk8/tl/jdk: 8014519: scriptpad sample does not work with nashorn Message-ID: <20130514170742.64A4448A7A@hg.openjdk.java.net> Changeset: e0135f1a8627 Author: sundar Date: 2013-05-14 22:36 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0135f1a8627 8014519: scriptpad sample does not work with nashorn Reviewed-by: attila, jlaskey Contributed-by: rieberandreas at gmail.com ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.sh ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js From jonathan.gibbons at oracle.com Tue May 14 17:17:50 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 17:17:50 +0000 Subject: hg: jdk8/tl/langtools: 17 new changesets Message-ID: <20130514171841.689DE48A7C@hg.openjdk.java.net> Changeset: 8ea30d59ac41 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ea30d59ac41 8010440: Replace int constants in LinkInfoImpl with enum Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java Changeset: 74cd21f2c2fe Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/74cd21f2c2fe 8011642: Remove LinkOutput in favor of direct use of Content Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 7a9ef837e57f Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a9ef837e57f 8011650: reduce use of RawHtml nodes in doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.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/LinkInfo.java Changeset: 6ea964c78845 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6ea964c78845 8011651: simplify LinkInfoImpl API Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java Changeset: e6c5b5ee9fac Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6c5b5ee9fac 8011662: Remove single instance of resource with HTML from doclet resource bundle Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: ce4f0769b4b2 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce4f0769b4b2 8011668: Allow HTMLWriter.getResource to take Content args Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 4c43e51433ba Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4c43e51433ba 8011288: Erratic/inconsistent indentation of signatures Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.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/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.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/LinkInfo.java + test/com/sun/javadoc/testIndentation/TestIndentation.java + test/com/sun/javadoc/testIndentation/p/Indent.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java Changeset: 7af0fa419a2b Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7af0fa419a2b 8012174: {@literal} and {@code} should use \"new\" Taglet, not old. Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java Changeset: 6a5288a298fd Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6a5288a298fd 8012175: Convert TagletOutputImpl to use ContentBuilder instead of StringBuilder Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: 76a691e3e961 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76a691e3e961 8012176: reduce use of TagletOutputImpl.toString Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java Changeset: 937aa020c667 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/937aa020c667 8012177: HTMLDocletWriter methods should generate Content, not Strings Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java Changeset: bd51ca92c013 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bd51ca92c013 8012178: Cleanup use of Util.escapeHtmlChars Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: df4f44800923 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df4f44800923 8012183: replace some uses of Configuration.getText with Configuration.getResource Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 051b728cfe90 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/051b728cfe90 8012180: Speed up removeNonInlineHtmlTags Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 25c89a492f14 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25c89a492f14 8012295: Cleanup JavaFX features in standard doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 081d7c72ee92 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/081d7c72ee92 8012311: Cleanup names and duplicatre code in TagletManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: ca8808c88f94 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca8808c88f94 8012308: Remove TagletOutput in favor of direct use of Content Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java From david.dehaven at oracle.com Tue May 14 18:06:54 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 14 May 2013 11:06:54 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <2BAC80D5-A128-4960-A685-F6BFFB33DA49@oracle.com> References: <5192494F.6040609@oracle.com> <2BAC80D5-A128-4960-A685-F6BFFB33DA49@oracle.com> Message-ID: <99A553DF-6D99-4907-B7E8-0071DF0598C3@oracle.com> @Deprecated: never -DrD- > If we can't deprecate this, we might as well deprecate @Deprecated. > > On May 14, 2013, at 10:25 AM, Alan Bateman wrote: > >> >> I would like to broach the subject of pulling out the implementation of Thread.stop(Throwable), maybe suspend/resume later. By "pulling out" I mean changing it to unconditionally throw UnsupportedOperationException. >> >> As we all know, these methods have been deprecated since 1998 so that's 15 years to design out any need for these methods. That said, I periodically come across code that uses no-arg Thread.stop(). David Holmes mentioned to me recently that he came across a usage in the recent past too. I don't think I've ever come across code using Thread.stop(Throwable) and this one is arguably the most dangerous of the group. >> >> So I'm curious if anyone has come across a Thread.stop(Throwable) usage in recent times. Clearly changing this would be a significant change but the real impact might be close to zero. If we decide this is the right thing to do then there is a bit of detail to work out, that's for later. >> >> -Alan. > From robert.field at oracle.com Tue May 14 18:11:56 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 14 May 2013 18:11:56 +0000 Subject: hg: jdk8/tl/langtools: 8012556: Implement lambda methods on interfaces as static; ... Message-ID: <20130514181201.B1A5B48A7F@hg.openjdk.java.net> Changeset: c09b7234cded Author: rfield Date: 2013-05-14 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c09b7234cded 8012556: Implement lambda methods on interfaces as static 8006140: Javac NPE compiling Lambda expression on initialization expression of static field in interface Summary: Lambdas occurring in static contexts or those not needing instance information should be generated into static methods. This has long been the case for classes. However, as a work-around to the lack of support for statics on interfaces, interface lambda methods have been generated into default methods. For lambdas in interface static contexts (fields and static methods) this causes an NPE in javac because there is no 'this'. MethodHandles now support static methods on interfaces. This changeset allows lambda methods to be generated as static interface methods. An existing bug in Hotspot (8013875) is exposed in a test when the "-esa" flag is used. This test and another test that already exposed this bug have been marked with @ignore. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaInterfaceStaticField.java ! test/tools/javac/lambda/MethodReference66.java ! test/tools/javac/lambda/bytecode/TestLambdaBytecode.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java From Alan.Bateman at oracle.com Tue May 14 18:21:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 19:21:30 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> Message-ID: <519280AA.8070407@oracle.com> On 14/05/2013 17:57, Martin Buchholz wrote: > > : > > There are existing JDK tests that use currentThread().stop to > implement the occasionally necessary sneakyThrow. > Yes, there are 4 j.u.c. tests, I haven't come across others. -Alan From xueming.shen at oracle.com Tue May 14 18:50:17 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 May 2013 11:50:17 -0700 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Message-ID: <51928769.1070300@oracle.com> Hi, Please help review the change for handling a "malformed base64 stream" corner case. The latest spec has been updated/clarified as "If there is padding character present in the final unit, the correct number of padding character(s) must be present, otherwise IllegalArgumentException is thrown during decoding." But the stream decoding implementation has not been updated accordingly. The change is to throw the IOE if the padding character "=" is missing from the xx== pattern. http://cr.openjdk.java.net/~sherman/8014217/webrev/ Thanks! Sherman From kurchi.subhra.hazra at oracle.com Tue May 14 18:51:57 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 14 May 2013 18:51:57 +0000 Subject: hg: jdk8/tl/jdk: 6328537: Improve javadocs for Socket class by adding references to SocketOptions Message-ID: <20130514185220.F24EA48A80@hg.openjdk.java.net> Changeset: 790d292ee761 Author: khazra Date: 2013-05-14 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/790d292ee761 6328537: Improve javadocs for Socket class by adding references to SocketOptions Summary: Insert references to SocketOptions.java where applicable Reviewed-by: alanb, chegar ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java From forax at univ-mlv.fr Tue May 14 19:08:46 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 May 2013 21:08:46 +0200 Subject: RFR 8014133: Spliterator.OfPrimitive In-Reply-To: References: Message-ID: <51928BBE.80200@univ-mlv.fr> On 05/14/2013 05:41 PM, Mike Duigou wrote: > Nice cleanup. Looks good. > > Mike looks good. R?mi > > On May 14 2013, at 00:17 , Paul Sandoz wrote: > >> Hi, >> >> Please review: >> >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/webrev/ >> http://cr.openjdk.java.net/~psandoz/lambda/spliterator/jdk-8014133/specdiff/overview-summary.html >> >> This enables more sharing of primitive-based spliterator code and should also reduce the bloat of primitive-based concat spliterator implementations, if we choose to add concatenation of primitive-based streams. >> >> Paul. >> >> From chris.hegarty at oracle.com Tue May 14 19:25:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 May 2013 20:25:39 +0100 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit In-Reply-To: <51928769.1070300@oracle.com> References: <51928769.1070300@oracle.com> Message-ID: Is there a conflict between the spec and implement? IOE versus IAE? -Chris On 14 May 2013, at 19:50, Xueming Shen wrote: > Hi, > > Please help review the change for handling a "malformed base64 stream" corner case. > The latest spec has been updated/clarified as > > "If there is padding character present in the final unit, the correct number of padding > character(s) must be present, otherwise IllegalArgumentException is thrown during > decoding." > > But the stream decoding implementation has not been updated accordingly. The change > is to throw the IOE if the padding character "=" is missing from the xx== pattern. > > http://cr.openjdk.java.net/~sherman/8014217/webrev/ > > Thanks! > Sherman From mandy.chung at oracle.com Tue May 14 19:29:51 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 May 2013 12:29:51 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <51919B21.7080400@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> <519162A3.5000601@oracle.com> <51919B21.7080400@oracle.com> Message-ID: <519290AF.70900@oracle.com> On 5/13/13 7:02 PM, Xueming Shen wrote: > Hi Mandy, > > Here is the updated simple version as we chatted. I will leave the > ExtendedCharsets > rewrite for next round. > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > thanks for the update. This looks fine. Minor nits: the static fields in the new ISO2022_JP_2.CoderHolder and MSISO2022JP.CoderHolder classes can retain to be final in this version (I think it was removed for your previous version). I agree with you that we should clean up and simplify the ExtendedCharsets synchronization and what you have is a good start. Can you file a new bug for the future cleanup? Mandy > Thanks! > -Sherman > > > On 5/13/13 3:01 PM, Xueming Shen wrote: >> Thanks Mandy for reviewing. >> >> Webrev has been updated to >> >> (1) added the sync back to charset/deleteCharset(). As you suggested, >> there >> is race condition risk that the map is being accessed while the system >> initialization completes. >> (2) added the "holder" pattern for msiso2022_jp and iso2022_jp_2, as >> suggested. >> (3) keep the AbstractCharsetProvider in repo for now. >> >> I have not eliminate the static reference to s.n.c.ExtendedCharsets >> class, yet, >> since it is only invoked/referred after we have checked >> Class.forName. Is it >> really a problem here? for example, the hotspo re-arrange the order of >> execution? >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >> >> Thanks! >> -Sherman >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >> >> On 05/10/2013 04:55 PM, Mandy Chung wrote: >>> Sherman, >>> >>> The charsetForName, charsets and aliasesFor methods call init() >>> first and >>> then access the maps with no synchronization. While the maps are being >>> accessed by one thread and system initialization completes, another >>> thread >>> calls charsetForName() that calls init() which will update the >>> maps. So >>> the maps is being updated while being accessed by another thread. So >>> I think the original synchronized(this) is still needed for the >>> charsetForName, charsets and aliasesFor methods for correctness. >>> >>> The maps are only updated once and also only if ExtendedCharsets >>> provider >>> is instantiated before booted and "sun.nio.cs.map" system property >>> is set. >>> I think it's worth further clean up this 2-phase instance >>> initialization >>> since ExtendedCharsets is now a singleton. Would >>> Charset.availableCharsets() >>> and ExtendedCharsets.charsets() not be called during system >>> initialization? >>> If we can restrict that they can't be called, maybe you can move the >>> 2nd >>> phase initialization to ExtendedCharsetsHolder (i.e. calling init() >>> method) >>> and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets >>> instance >>> methods no longer need to call init. Just one thought. >>> >>> You propose to remove AbstractCharsetProvider class. I don't have the >>> history to comment on whether you should keep/remove the >>> AbstractCharsetProvider for other charset providers to extend. Just >>> looking at the current implementation, it's not needed. >>> >>> More comments inlined below. >>> >>> On 5/10/2013 10:53 AM, Xueming Shen wrote: >>>> Thanks for the review. >>>> >>>> I have updated the Charset.java to use the init-on-depand holder >>>> idiom. >>>> >>> >>> L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); >>> >>> You would need to use 'epc' and invoke "getInstance" method via >>> reflection >>> to eliminate the static reference to s.n.c.ExtendedCharsets class as >>> it might not be present. >>> >>> I suggest to add these 2 methods in the ExtendedProviderHolder class: >>> static Charset charsetForName(String charsetName) { >>> return (extendedProvider != null) >>> ? >>> extendedProvider.charsetForName(charsetName) : null; >>> } >>> >>> static Iterator charsets() { >>> return (extendedProvider != null) >>> ? extendedProvider.charsets() >>> : Collections.emptyIterator(); >>> } >>> >>> >>> The lookup2() and availableCharsets() methods can be simplified to >>> something like this: >>> >>> if ((cs = standardProvider.charsetForName(charsetName)) != >>> null || >>> - (cs = lookupExtendedCharset(charsetName)) != null || >>> + (cs = >>> ExtendedProviderHolder.charsetForName(charsetName)) != null || >>> (cs = lookupViaProviders(charsetName)) != null) >>> >>> >>> + put(ExtendedProviderHolder.charsets(), m); >>> for (Iterator i = providers(); >>> i.hasNext();) { >>> CharsetProvider cp = i.next(); >>> put(cp.charsets(), m); >>> >>>> I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of >>>> adding >>>> two more classes, so I leave them asis. >>>> >>> >>> Are you concerned of the static footprint of the new class? >>> >>> I think the code is much cleaner but you may think it's overkill: >>> static class Holder { >>> static DoubleByte.Decoder DEC0208 = .... >>> static DoubleByte.Encoder ENC0208 = .... >>> } >>> >>> Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? >>> >>>> Agreed that the ExtendedCahrsets change can be separated, but since >>>> we're here >>>> already, It would be convenient to just do them together and the >>>> "cleaner' code >>>> then can be back-port together later when requested. >>> >>> It's fine with me. I suggest to look into the possibility >>> separating the second phase update to the extended charsets if you >>> want to remove the synchronization on the instance methods. >>> >>> Mandy >>> >>>> >>>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>>> >>>> -Sherman >>>> >> > From xueming.shen at oracle.com Tue May 14 19:32:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 May 2013 12:32:45 -0700 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit In-Reply-To: References: <51928769.1070300@oracle.com> Message-ID: <5192915D.90301@oracle.com> It has been discussed before that the IOE is preferred in case of the wrapped decoding stream. The spec of wrap() does mention that "IOE when reading bytes that can not be decoded". So personally I feel it has been "covered", but if preferred, it can go further as "If there is padding character present in the final unit, the correct number of padding character(s) must be present, otherwise IllegalArgumentException (or IOException in case of decoding from the wrapped base64 stream), is thrown during decoding."? -Sherman On 05/14/2013 12:25 PM, Chris Hegarty wrote: > Is there a conflict between the spec and implement? IOE versus IAE? > > -Chris > > On 14 May 2013, at 19:50, Xueming Shen wrote: > >> Hi, >> >> Please help review the change for handling a "malformed base64 stream" corner case. >> The latest spec has been updated/clarified as >> >> "If there is padding character present in the final unit, the correct number of padding >> character(s) must be present, otherwise IllegalArgumentException is thrown during >> decoding." >> >> But the stream decoding implementation has not been updated accordingly. The change >> is to throw the IOE if the padding character "=" is missing from the xx== pattern. >> >> http://cr.openjdk.java.net/~sherman/8014217/webrev/ >> >> Thanks! >> Sherman From chris.hegarty at oracle.com Tue May 14 19:46:10 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 May 2013 20:46:10 +0100 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit In-Reply-To: <5192915D.90301@oracle.com> References: <51928769.1070300@oracle.com> <5192915D.90301@oracle.com> Message-ID: <344B0604-0A8C-4FFF-8601-3F2C1F2808D4@oracle.com> Thanks for the explanation Sherman. No further changes required. What you have is fine. My question was provoked because the details in the email seemed at odds with the changes. -Chris On 14 May 2013, at 20:32, Xueming Shen wrote: > It has been discussed before that the IOE is preferred in case of the wrapped > decoding stream. The spec of wrap() does mention that "IOE when reading > bytes that can not be decoded". > > So personally I feel it has been "covered", but if preferred, it can go further as > > "If there is padding character present in the final unit, the correct number of padding > character(s) must be present, otherwise IllegalArgumentException (or IOException in case > of decoding from the wrapped base64 stream), is thrown during decoding."? > > -Sherman > > On 05/14/2013 12:25 PM, Chris Hegarty wrote: >> Is there a conflict between the spec and implement? IOE versus IAE? >> >> -Chris >> >> On 14 May 2013, at 19:50, Xueming Shen wrote: >> >>> Hi, >>> >>> Please help review the change for handling a "malformed base64 stream" corner case. >>> The latest spec has been updated/clarified as >>> >>> "If there is padding character present in the final unit, the correct number of padding >>> character(s) must be present, otherwise IllegalArgumentException is thrown during >>> decoding." >>> >>> But the stream decoding implementation has not been updated accordingly. The change >>> is to throw the IOE if the padding character "=" is missing from the xx== pattern. >>> >>> http://cr.openjdk.java.net/~sherman/8014217/webrev/ >>> >>> Thanks! >>> Sherman > From Alan.Bateman at oracle.com Tue May 14 19:47:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 20:47:00 +0100 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit In-Reply-To: <5192915D.90301@oracle.com> References: <51928769.1070300@oracle.com> <5192915D.90301@oracle.com> Message-ID: <519294B4.60704@oracle.com> On 14/05/2013 20:32, Xueming Shen wrote: > It has been discussed before that the IOE is preferred in case of the > wrapped > decoding stream. The spec of wrap() does mention that "IOE when reading > bytes that can not be decoded". > > So personally I feel it has been "covered", but if preferred, it can > go further as > > "If there is padding character present in the final unit, the correct > number of padding > character(s) must be present, otherwise IllegalArgumentException (or > IOException in case > of decoding from the wrapped base64 stream), is thrown during decoding."? > > -Sherman Right, this has come up before. The intention is that IAE be thrown if the array/buffer provided as an argument is invalid, meaning containing bytes that cannot be decoded. For the wrap methods then there aren't any invalid arguments, instead it is bytes read from the stream that can't be decoded. I believe we agreed here to keep this consistent with other InputStream usages where malformed data or decoding causes IOException to be thrown. If there is any doubt then it would be good to clarify this, maybe "IOException when reading from a a base64 stream". -Alan. From xueming.shen at oracle.com Tue May 14 19:51:31 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 May 2013 12:51:31 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <519290AF.70900@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> <519162A3.5000601@oracle.com> <51919B21.7080400@oracle.com> <519290AF.70900@oracle.com> Message-ID: <519295C3.7090202@oracle.com> Thanks Mandy! Webrev has been updated to put the "final" back as suggested. http://cr.openjdk.java.net/~sherman/8012326/webrev/ https://jbs.oracle.com/bugs/browse/JDK-8014565 has been filed for future enhancement of ExtededCharsets class. -Sherman On 05/14/2013 12:29 PM, Mandy Chung wrote: > On 5/13/13 7:02 PM, Xueming Shen wrote: >> Hi Mandy, >> >> Here is the updated simple version as we chatted. I will leave the ExtendedCharsets >> rewrite for next round. >> >> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >> > > thanks for the update. This looks fine. > > Minor nits: the static fields in the new ISO2022_JP_2.CoderHolder and MSISO2022JP.CoderHolder classes can retain to be final in this version (I think it was removed for your previous version). > > I agree with you that we should clean up and simplify the ExtendedCharsets synchronization and what you have is a good start. Can you file a new bug for the future cleanup? > > Mandy > >> Thanks! >> -Sherman >> >> >> On 5/13/13 3:01 PM, Xueming Shen wrote: >>> Thanks Mandy for reviewing. >>> >>> Webrev has been updated to >>> >>> (1) added the sync back to charset/deleteCharset(). As you suggested, there >>> is race condition risk that the map is being accessed while the system >>> initialization completes. >>> (2) added the "holder" pattern for msiso2022_jp and iso2022_jp_2, as suggested. >>> (3) keep the AbstractCharsetProvider in repo for now. >>> >>> I have not eliminate the static reference to s.n.c.ExtendedCharsets class, yet, >>> since it is only invoked/referred after we have checked Class.forName. Is it >>> really a problem here? for example, the hotspo re-arrange the order of >>> execution? >>> >>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>> >>> Thanks! >>> -Sherman >>> >>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>> >>> On 05/10/2013 04:55 PM, Mandy Chung wrote: >>>> Sherman, >>>> >>>> The charsetForName, charsets and aliasesFor methods call init() first and >>>> then access the maps with no synchronization. While the maps are being >>>> accessed by one thread and system initialization completes, another thread >>>> calls charsetForName() that calls init() which will update the maps. So >>>> the maps is being updated while being accessed by another thread. So >>>> I think the original synchronized(this) is still needed for the >>>> charsetForName, charsets and aliasesFor methods for correctness. >>>> >>>> The maps are only updated once and also only if ExtendedCharsets provider >>>> is instantiated before booted and "sun.nio.cs.map" system property is set. >>>> I think it's worth further clean up this 2-phase instance initialization >>>> since ExtendedCharsets is now a singleton. Would Charset.availableCharsets() >>>> and ExtendedCharsets.charsets() not be called during system initialization? >>>> If we can restrict that they can't be called, maybe you can move the 2nd >>>> phase initialization to ExtendedCharsetsHolder (i.e. calling init() method) >>>> and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets instance >>>> methods no longer need to call init. Just one thought. >>>> >>>> You propose to remove AbstractCharsetProvider class. I don't have the >>>> history to comment on whether you should keep/remove the >>>> AbstractCharsetProvider for other charset providers to extend. Just >>>> looking at the current implementation, it's not needed. >>>> >>>> More comments inlined below. >>>> >>>> On 5/10/2013 10:53 AM, Xueming Shen wrote: >>>>> Thanks for the review. >>>>> >>>>> I have updated the Charset.java to use the init-on-depand holder idiom. >>>>> >>>> >>>> L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); >>>> >>>> You would need to use 'epc' and invoke "getInstance" method via reflection >>>> to eliminate the static reference to s.n.c.ExtendedCharsets class as >>>> it might not be present. >>>> >>>> I suggest to add these 2 methods in the ExtendedProviderHolder class: >>>> static Charset charsetForName(String charsetName) { >>>> return (extendedProvider != null) >>>> ? extendedProvider.charsetForName(charsetName) : null; >>>> } >>>> >>>> static Iterator charsets() { >>>> return (extendedProvider != null) >>>> ? extendedProvider.charsets() >>>> : Collections.emptyIterator(); >>>> } >>>> >>>> >>>> The lookup2() and availableCharsets() methods can be simplified to >>>> something like this: >>>> >>>> if ((cs = standardProvider.charsetForName(charsetName)) != null || >>>> - (cs = lookupExtendedCharset(charsetName)) != null || >>>> + (cs = ExtendedProviderHolder.charsetForName(charsetName)) != null || >>>> (cs = lookupViaProviders(charsetName)) != null) >>>> >>>> >>>> + put(ExtendedProviderHolder.charsets(), m); >>>> for (Iterator i = providers(); i.hasNext();) { >>>> CharsetProvider cp = i.next(); >>>> put(cp.charsets(), m); >>>> >>>>> I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of adding >>>>> two more classes, so I leave them asis. >>>>> >>>> >>>> Are you concerned of the static footprint of the new class? >>>> >>>> I think the code is much cleaner but you may think it's overkill: >>>> static class Holder { >>>> static DoubleByte.Decoder DEC0208 = .... >>>> static DoubleByte.Encoder ENC0208 = .... >>>> } >>>> >>>> Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? >>>> >>>>> Agreed that the ExtendedCahrsets change can be separated, but since we're here >>>>> already, It would be convenient to just do them together and the "cleaner' code >>>>> then can be back-port together later when requested. >>>> >>>> It's fine with me. I suggest to look into the possibility separating the second phase update to the extended charsets if you want to remove the synchronization on the instance methods. >>>> >>>> Mandy >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>>>> >>>>> -Sherman >>>>> >>> >> > From brian.burkhalter at oracle.com Tue May 14 19:54:50 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 May 2013 12:54:50 -0700 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers Message-ID: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> This is the first of an eventual four phases of performance improvement of BigInteger for large integers. Issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 Webrev: http://cr.openjdk.java.net/~bpb/4837946/ This contains Alan Eliasen's implementation of Karatsuba and 3-way Toom-Cook multiplication and squaring, and pow() accelerated by power of two shifting and accelerated exponentiation by squaring. I have reviewed this code including verifying all algorithms against the references suggested in the code as well as other sources in the literature. It all looks to be entirely correct and very clean and clear. The only changes I've made with respect to the version of the code provided by Alan were to update the latest copyright year to 2013, and to change the javadoc comments of the TOOM_COOK_THRESHOLD constant in BigInteger to the verbiage I suggested to this mailing list yesterday. I still need to exercise due diligence in terms of testing the code, but I thought it would be good to post the webrev anyway so that interested parties can double check it should they so desire. One change which I have *not* made and which seems appropriate to add to this patch is to modify multiply() to use square() if the parameter is the BigInteger instance on which the method is invoked, i.e., to change this snippet public BigInteger multiply(BigInteger val) { if (val.signum == 0 || signum == 0) return ZERO; to this public BigInteger multiply(BigInteger val) { if (val.signum == 0 || signum == 0) return ZERO; if (val == this) return square(); Of course square() could be made public, but this approach has the advantage of less process overhead. Thanks, Brian From jonathan.gibbons at oracle.com Tue May 14 19:57:22 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 19:57:22 +0000 Subject: hg: jdk8/tl/langtools: 8014461: genstubs creates default native methods Message-ID: <20130514195727.3331448A8C@hg.openjdk.java.net> Changeset: 46b9c25f7024 Author: jjg Date: 2013-05-14 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46b9c25f7024 8014461: genstubs creates default native methods Reviewed-by: alanb ! make/tools/genstubs/GenStubs.java From mandy.chung at oracle.com Tue May 14 20:00:53 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 May 2013 13:00:53 -0700 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <519295C3.7090202@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> <519162A3.5000601@oracle.com> <51919B21.7080400@oracle.com> <519290AF.70900@oracle.com> <519295C3.7090202@oracle.com> Message-ID: <519297F5.4030704@oracle.com> Thanks. Looks good. Mandy On 5/14/13 12:51 PM, Xueming Shen wrote: > Thanks Mandy! > > Webrev has been updated to put the "final" back as suggested. > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > > https://jbs.oracle.com/bugs/browse/JDK-8014565 has been filed for future > enhancement of ExtededCharsets class. > > -Sherman > > On 05/14/2013 12:29 PM, Mandy Chung wrote: >> On 5/13/13 7:02 PM, Xueming Shen wrote: >>> Hi Mandy, >>> >>> Here is the updated simple version as we chatted. I will leave the >>> ExtendedCharsets >>> rewrite for next round. >>> >>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>> >>> >> >> thanks for the update. This looks fine. >> >> Minor nits: the static fields in the new ISO2022_JP_2.CoderHolder >> and MSISO2022JP.CoderHolder classes can retain to be final in this >> version (I think it was removed for your previous version). >> >> I agree with you that we should clean up and simplify the >> ExtendedCharsets synchronization and what you have is a good start. >> Can you file a new bug for the future cleanup? >> >> Mandy >> >>> Thanks! >>> -Sherman >>> >>> >>> On 5/13/13 3:01 PM, Xueming Shen wrote: >>>> Thanks Mandy for reviewing. >>>> >>>> Webrev has been updated to >>>> >>>> (1) added the sync back to charset/deleteCharset(). As you >>>> suggested, there >>>> is race condition risk that the map is being accessed while the system >>>> initialization completes. >>>> (2) added the "holder" pattern for msiso2022_jp and iso2022_jp_2, >>>> as suggested. >>>> (3) keep the AbstractCharsetProvider in repo for now. >>>> >>>> I have not eliminate the static reference to s.n.c.ExtendedCharsets >>>> class, yet, >>>> since it is only invoked/referred after we have checked >>>> Class.forName. Is it >>>> really a problem here? for example, the hotspo re-arrange the order of >>>> execution? >>>> >>>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>>> >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>>> >>>> >>>> On 05/10/2013 04:55 PM, Mandy Chung wrote: >>>>> Sherman, >>>>> >>>>> The charsetForName, charsets and aliasesFor methods call init() >>>>> first and >>>>> then access the maps with no synchronization. While the maps are >>>>> being >>>>> accessed by one thread and system initialization completes, >>>>> another thread >>>>> calls charsetForName() that calls init() which will update the >>>>> maps. So >>>>> the maps is being updated while being accessed by another thread. So >>>>> I think the original synchronized(this) is still needed for the >>>>> charsetForName, charsets and aliasesFor methods for correctness. >>>>> >>>>> The maps are only updated once and also only if ExtendedCharsets >>>>> provider >>>>> is instantiated before booted and "sun.nio.cs.map" system property >>>>> is set. >>>>> I think it's worth further clean up this 2-phase instance >>>>> initialization >>>>> since ExtendedCharsets is now a singleton. Would >>>>> Charset.availableCharsets() >>>>> and ExtendedCharsets.charsets() not be called during system >>>>> initialization? >>>>> If we can restrict that they can't be called, maybe you can move >>>>> the 2nd >>>>> phase initialization to ExtendedCharsetsHolder (i.e. calling >>>>> init() method) >>>>> and perhapsExtendedCharsets.aliasesFor so that ExtendedCharsets >>>>> instance >>>>> methods no longer need to call init. Just one thought. >>>>> >>>>> You propose to remove AbstractCharsetProvider class. I don't have >>>>> the >>>>> history to comment on whether you should keep/remove the >>>>> AbstractCharsetProvider for other charset providers to extend. Just >>>>> looking at the current implementation, it's not needed. >>>>> >>>>> More comments inlined below. >>>>> >>>>> On 5/10/2013 10:53 AM, Xueming Shen wrote: >>>>>> Thanks for the review. >>>>>> >>>>>> I have updated the Charset.java to use the init-on-depand holder >>>>>> idiom. >>>>>> >>>>> >>>>> L440: return sun.nio.cs.ext.ExtendedCharsets.getInstance(); >>>>> >>>>> You would need to use 'epc' and invoke "getInstance" method via >>>>> reflection >>>>> to eliminate the static reference to s.n.c.ExtendedCharsets class as >>>>> it might not be present. >>>>> >>>>> I suggest to add these 2 methods in the ExtendedProviderHolder class: >>>>> static Charset charsetForName(String charsetName) { >>>>> return (extendedProvider != null) >>>>> ? >>>>> extendedProvider.charsetForName(charsetName) : null; >>>>> } >>>>> >>>>> static Iterator charsets() { >>>>> return (extendedProvider != null) >>>>> ? extendedProvider.charsets() >>>>> : Collections.emptyIterator(); >>>>> } >>>>> >>>>> >>>>> The lookup2() and availableCharsets() methods can be simplified to >>>>> something like this: >>>>> >>>>> if ((cs = standardProvider.charsetForName(charsetName)) >>>>> != null || >>>>> - (cs = lookupExtendedCharset(charsetName)) != null || >>>>> + (cs = >>>>> ExtendedProviderHolder.charsetForName(charsetName)) != null || >>>>> (cs = lookupViaProviders(charsetName)) != null) >>>>> >>>>> >>>>> + put(ExtendedProviderHolder.charsets(), m); >>>>> for (Iterator i = >>>>> providers(); i.hasNext();) { >>>>> CharsetProvider cp = i.next(); >>>>> put(cp.charsets(), m); >>>>> >>>>>> I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost >>>>>> of adding >>>>>> two more classes, so I leave them asis. >>>>>> >>>>> >>>>> Are you concerned of the static footprint of the new class? >>>>> >>>>> I think the code is much cleaner but you may think it's overkill: >>>>> static class Holder { >>>>> static DoubleByte.Decoder DEC0208 = .... >>>>> static DoubleByte.Encoder ENC0208 = .... >>>>> } >>>>> >>>>> Or can you just cache new JIS_X_0208_MS932()or new JIS_X_0212()? >>>>> >>>>>> Agreed that the ExtendedCahrsets change can be separated, but >>>>>> since we're here >>>>>> already, It would be convenient to just do them together and the >>>>>> "cleaner' code >>>>>> then can be back-port together later when requested. >>>>> >>>>> It's fine with me. I suggest to look into the possibility >>>>> separating the second phase update to the extended charsets if you >>>>> want to remove the synchronization on the instance methods. >>>>> >>>>> Mandy >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~sherman/8012326/webrev/ >>>>>> >>>>>> >>>>>> -Sherman >>>>>> >>>> >>> >> > From xueming.shen at oracle.com Tue May 14 20:00:28 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 May 2013 13:00:28 -0700 Subject: RFR 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit In-Reply-To: <344B0604-0A8C-4FFF-8601-3F2C1F2808D4@oracle.com> References: <51928769.1070300@oracle.com> <5192915D.90301@oracle.com> <344B0604-0A8C-4FFF-8601-3F2C1F2808D4@oracle.com> Message-ID: <519297DC.4070309@oracle.com> Thanks Chris, I updated the wording as Alan suggest to just make sure there is no doubt on the behavior :-) http://cr.openjdk.java.net/~sherman/8014217/webrev/ -Sherman On 05/14/2013 12:46 PM, Chris Hegarty wrote: > Thanks for the explanation Sherman. No further changes required. What you have is fine. > > My question was provoked because the details in the email seemed at odds with the changes. > > -Chris > > On 14 May 2013, at 20:32, Xueming Shen wrote: > >> It has been discussed before that the IOE is preferred in case of the wrapped >> decoding stream. The spec of wrap() does mention that "IOE when reading >> bytes that can not be decoded". >> >> So personally I feel it has been "covered", but if preferred, it can go further as >> >> "If there is padding character present in the final unit, the correct number of padding >> character(s) must be present, otherwise IllegalArgumentException (or IOException in case >> of decoding from the wrapped base64 stream), is thrown during decoding."? >> >> -Sherman >> >> On 05/14/2013 12:25 PM, Chris Hegarty wrote: >>> Is there a conflict between the spec and implement? IOE versus IAE? >>> >>> -Chris >>> >>> On 14 May 2013, at 19:50, Xueming Shen wrote: >>> >>>> Hi, >>>> >>>> Please help review the change for handling a "malformed base64 stream" corner case. >>>> The latest spec has been updated/clarified as >>>> >>>> "If there is padding character present in the final unit, the correct number of padding >>>> character(s) must be present, otherwise IllegalArgumentException is thrown during >>>> decoding." >>>> >>>> But the stream decoding implementation has not been updated accordingly. The change >>>> is to throw the IOE if the padding character "=" is missing from the xx== pattern. >>>> >>>> http://cr.openjdk.java.net/~sherman/8014217/webrev/ >>>> >>>> Thanks! >>>> Sherman From Alan.Bateman at oracle.com Tue May 14 20:07:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 21:07:02 +0100 Subject: RFR 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time In-Reply-To: <519295C3.7090202@oracle.com> References: <51833D0F.1070003@oracle.com> <518540CB.1060004@CoSoCo.de> <51855C10.3050203@oracle.com> <518AAC67.9080503@oracle.com> <518D3434.6020000@oracle.com> <518D88EC.6030804@oracle.com> <519162A3.5000601@oracle.com> <51919B21.7080400@oracle.com> <519290AF.70900@oracle.com> <519295C3.7090202@oracle.com> Message-ID: <51929966.2090209@oracle.com> On 14/05/2013 20:51, Xueming Shen wrote: > Thanks Mandy! > > Webrev has been updated to put the "final" back as suggested. > > http://cr.openjdk.java.net/~sherman/8012326/webrev/ > > https://jbs.oracle.com/bugs/browse/JDK-8014565 has been filed for future > enhancement of ExtededCharsets class. > > -Sherman > The updated webrev looks fine to me, the holder idiom in Charset makes me much better. (For ISO2022_JP_2/MSISO2022JP then I thought the previous approach was fine as I don't think the encoders/decoders needs to be singletons. What you have is okay though, just adds a bit of class footprint). -Alan. From ivan.gerasimov at oracle.com Tue May 14 20:32:28 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 15 May 2013 00:32:28 +0400 Subject: RFR [7021870] GzipInputStream closes underlying stream during reading In-Reply-To: <5191CC98.1020007@oracle.com> References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com> <5190DB56.2000203@oracle.com> <5190EC13.2010000@oracle.com> <5191CC98.1020007@oracle.com> Message-ID: <51929F5C.8080908@oracle.com> Sherman, Thank you for a detailed explanation. > It's a fair assessment to say "ZIS.available() is not the only > cause..." though > I don't think it's that easy to really "craft" a real test case to > demonstrate the > failure with a "malformed" gzip entry inside a zip file. I think I found an easy way to do that. It's sufficient to create GZIPInputStream with a small buffer of 4 bytes. I've traced the code and found that at the time available() is called there was exactly 1 byte left in the input stream. Thus it would have returned true even if it were implemented more correctly. What do you think, is it worth adding it to the existing test? > At least I don't think > I can create one without sitting down with some real calculation:-) > Or, I'm > missing something in your test case? It appears you will have to have the > inflater of the GZIPInputStream to happen to have only 8 bytes left in > its > input buffer as the "remaining" when it is done inflating the gzip > stream, > otherwise the this.in.available() will never > 0 (in case of < 8 byte, > the trailer > reading will trigger the ZIS to "fill", in which the > fixed/non-customizable 512 > buffer size of ZIS will guarantee to exhaust the whole entry bytes and > result > in the this.is.available() to return 0; if n > 8, means all bytes, > including the > malformed byte(s) attached, have been in the GZIS.inf's remaining buffer, > so the this.is.available() will now returns 0 as well) which also > means you > need the ZipInputStream "happens" to be filled and inflated all bytes > of the > "gzip-streamed" entry, except the last one byte (malformed), in its last > filling/inflating... > > It's also arguable that we are now discussing a "malformed" gzip entry > inside > a zip stream, which is not exactly the original "regression" that we > are trying > to address... Well, my point is that the reported problem was that "GzipInputStream closes underlying stream during reading". Having a malformed input with a garbage at the end of the gziped entry was just another case that can trigger this problem even with fixed ZIS.available(). Sincerely, Ivan > But, given the current GZIS implementation ignores this type of > "malformed" stream (un-necessarily attached bytes at the end), it's > reasonable > to request that reading from such an gzip-streamed entry of a zip > entry should > succeed as well. And the proposed/pushed fix might be the easiest > approach > to solve this "malformed gzip stream inside a zip entry" corner case > for now. > > So I would suggest to consider combining the existing fix + the > available() > change (I would need a deep look to see if it has any "compatibility" > impact...) > > -Sherman > > > On 05/13/2013 06:35 AM, Ivan Gerasimov wrote: >> A small correction to the recipe for failure. >> The failure is reproduced when a SINGLE byte is appended to the gzip >> archive. >> In the scenario below the echo command appends TWO bytes. These two >> bytes are interpreted as a wrong gzip header and get successfully >> ignored. >> >> On 13.05.2013 16:23, Ivan Gerasimov wrote: >>> Hello Sherman! >>> >>> Thank you for the review! >>> While I agree with you that current implementation of >>> ZipInputStream.available() is not what it's supposed to be, I doubt >>> it is the only cause of the issue. >>> Please consider the following example. >>> Zip archive (z.zip) consists of two entries: f1 and f2. >>> f1 - gzip archive concatenated with a couple of bytes (I understand >>> it's malformed gzip archive), >>> f2 - let it be a single byte text file. >>> >>> $ echo a > f1 >>> $ echo b > f2 >>> $ gzip f1 >>> $ echo a >> f1.gz >>> $ zip z.zip f1.gz f2 >>> >>> public class ZipMix { >>> private static byte[] rbuf = new byte[1]; >>> public static void main(String[] args) throws Throwable { >>> FileInputStream fis = new FileInputStream("z.zip"); >>> ZipInputStream zis = new ZipInputStream(fis); >>> System.out.print("-start-\n"); >>> if (zis.getNextEntry() != null) { >>> InputStream gis = new GZIPInputStream(zis, 8192); >>> while (gis.read(rbuf) != -1) >>> System.out.print(new String(rbuf)); >>> } >>> if (zis.getNextEntry() != null) { // <--- throws IOException >>> while (zis.read(rbuf) != -1) >>> System.out.print(new String(rbuf)); >>> } >>> System.out.print("\n-finish-\n"); >>> } >>> } >>> >>> This code worked well with jdk1.6.20, since GZIPInputStream hadn't >>> tried to read beyond the trailer. >>> This breaks with the current jdk, since GZIPInputStream tries to >>> read yet another gzip header after the first trailer, and >>> SequenceInputStream.read() calls the close() method for underlying >>> stream. >>> And this would break even with the ZipInputStream.available() fixed. >>> >>> It seems to me that the root cause here is using >>> SequenceInputStream, which can close the stream during the read() call. >>> And this is what my fix was about - to prevent closing of the >>> underlying stream. >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 11.05.2013 2:48, Xueming Shen wrote: >>>> The proposed fix does solve the issue. >>>> >>>> However it appears it does not fix the root cause that triggers >>>> this problem. >>>> The root cause, or the direct trigger of this bug is the fact that >>>> ZipInputStream >>>> .availble() is really NOT reliable to tell us whether or not there >>>> is any byte >>>> "available" to be read from the input stream. The api doc of the >>>> ZIS.available() >>>> specifies "Returns 0 after EOF has reached for the current entry >>>> data, otherwise >>>> always return 1.". The implementation is straightforward, >>>> >>>> public int available() throws IOException { >>>> if (entryEOF) { >>>> return 0; >>>> } else { >>>> return 1; >>>> } >>>> } >>>> >>>> However, the flag "entryEOF" is only set if a read attempt has been >>>> tried >>>> and failed (see ZIS.read()), which means if a previous read of the >>>> entry >>>> succeeded and it actually read all the available bytes from the >>>> entry (with >>>> a big enough buffer), there is 0 byte available for read, the >>>> "flag" is not >>>> set, so if you invoke zis.available(), it return 1, but a read() >>>> invocation will >>>> returns -1 (yes, if you then try zis.available() again , it returns >>>> the expected >>>> 0). The test below demonstrates this issue. >>>> >>>> public static void main(String args[]) throws IOException { >>>> ZipInputStream zis = new ZipInputStream(new >>>> FileInputStream(args[0])); >>>> ZipEntry ze; >>>> while((ze = zis.getNextEntry()) !=null) { >>>> System.out.println("--------------" + ze.getName() + >>>> "--------"); >>>> byte[] buf = new byte[8102]; >>>> >>>> while (true) { >>>> System.out.println(" zis.available()=" + >>>> zis.available()); >>>> int n = zis.read(buf, 0, buf.length); >>>> System.out.println(" readN=" + n); >>>> if (n == -1) >>>> break; >>>> } >>>> } >>>> >>>> } >>>> >>>> It is arguable that the this is not an implementation bug, since it >>>> is reasonable >>>> to argue that the EOF has not been "really" reached yet after the >>>> first try, the >>>> implementation happens to return all available bytes, so the next >>>> read try finally >>>> "reached" the EOF, but this obviously is not the expectation. >>>> >>>> Unfortunately the fix we put in for #4691425 [1] logically depends on >>>> in.available() to decide whether or not we need to read a little >>>> further, which >>>> directly triggers this bug when the ZIS.available() "lies". >>>> >>>> // If there are more bytes available in "in" or >>>> // the leftover in the "inf" is > 26 bytes: >>>> // this.trailer(8) + next.header.min(10) + next.trailer(8) >>>> // try concatenated case >>>> if (this.in.available() > 0 || n > 26) { >>>> .... >>>> } >>>> >>>> Not only ZInputStream has this issue, its parent class >>>> InflaterStream (and >>>> its sibling GZIPInputStream, GZS inherits InflaterStream's available() >>>> implementation directly) has the same issue, I do have a bug#7031075 >>>> filed against GZIPInputStream. >>>> >>>> So the proposed fix is more a workaround for this available() >>>> issue. The >>>> alternative is to fix the issue directly, for example, to change >>>> the ZIS's >>>> available implementation to something like >>>> >>>> public int available() throws IOException { >>>> ensureOpen(); >>>> if (entryEOF || entry == null) >>>> return 0; >>>> switch (entry.method) { >>>> case DEFLATED: >>>> return (inf.finished() || inf.needsDictionary()) ? 0 : 1; >>>> case STORED: >>>> return remaining > 0 ? 1 : 0; >>>> default: >>>> throw new ZipException("invalid compression method"); >>>> } >>>> } >>>> >>>> we probably should go further to simply remove the flag "entryEOF" >>>> and move the "deflated" case implementation into InflaterInputStream >>>> (to fix 7031075 as well). >>>> >>>> -Sherman >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/ >>>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075 >>>> >>>> On 05/10/2013 01:03 AM, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> GzipInputStream uses SequenceInputStream to concatenate the >>>>> underlying stream with some data that reside in memory. >>>>> SequenceInputStream is implementing in such a way that it closes >>>>> the stream when it reaches EOS. >>>>> >>>>> The solution is to wrap the underlying stream with extended >>>>> FilterInputStream that overrides the close() method. >>>>> >>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870 >>>>> WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ >>>>> >>>>> >>>>> Sincerely your, >>>>> Ivan >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From jonathan.gibbons at oracle.com Tue May 14 20:55:46 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 20:55:46 +0000 Subject: hg: jdk8/tl/langtools: 8014557: Mutable static field in HtmlDocletWriter Message-ID: <20130514205552.B3A5848A90@hg.openjdk.java.net> Changeset: 0384683c64be Author: jjg Date: 2013-05-14 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0384683c64be 8014557: Mutable static field in HtmlDocletWriter Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java From xueming.shen at oracle.com Tue May 14 21:11:20 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 21:11:20 +0000 Subject: hg: jdk8/tl/jdk: 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Message-ID: <20130514211142.A5B6C48A92@hg.openjdk.java.net> Changeset: 08ef70f60e0d Author: sherman Date: 2013-05-14 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08ef70f60e0d 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Summary: removed the race condition risk from ExtendedCahrset access code Reviewed-by: mchung, alanb ! make/sun/nio/cs/Makefile ! makefiles/CreateJars.gmk ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java From xueming.shen at oracle.com Tue May 14 21:21:54 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 14 May 2013 21:21:54 +0000 Subject: hg: jdk8/tl/jdk: 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Message-ID: <20130514212206.9FF1848A93@hg.openjdk.java.net> Changeset: c70fff3db913 Author: sherman Date: 2013-05-14 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c70fff3db913 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Summary: to throw IOE for malformed final unit in base64 stream Reviewed-by: chegar, alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From jonathan.gibbons at oracle.com Tue May 14 22:05:12 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 May 2013 22:05:12 +0000 Subject: hg: jdk8/tl/langtools: 8013852: update reference impl for type-annotations Message-ID: <20130514220518.77FDF48A96@hg.openjdk.java.net> Changeset: ddb4a2bfcd82 Author: jjg Date: 2013-05-14 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ddb4a2bfcd82 8013852: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com, joel.franck at oracle.com, alex.buckley at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! 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/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java ! test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008769.java + test/tools/javac/annotations/typeAnnotations/classfile/T8010015.java + test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/T8008751.java + test/tools/javac/annotations/typeAnnotations/failures/T8009360.java + test/tools/javac/annotations/typeAnnotations/failures/T8011722.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Initializers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Test.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/diags/examples/ArrayAndReceiver.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverName.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverType.java + test/tools/javac/diags/examples/IncorrectReceiverName.java + test/tools/javac/diags/examples/ReceiverParameterNotApplicableConstructor.java + test/tools/javac/diags/examples/VarargsAndReceiver.java ! test/tools/javac/lib/DPrinter.java + test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/tree/SourceTreeScannerTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/typeAnnotations/NewArray.java ! test/tools/javap/typeAnnotations/Presence.java ! test/tools/javap/typeAnnotations/TypeCasts.java From mike.duigou at oracle.com Wed May 15 00:12:28 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 May 2013 17:12:28 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: <251BD4E9-902D-47F6-8B37-4C965064E67F@oracle.com> Hello all; I've continued to refine the previously posted patch and think it's now quite close to complete. I am going to scour the tests looking for additional conditions that need to be checked but this seems to be very nearly finished. http://cr.openjdk.java.net/~mduigou/JDK-7129185/1/webrev/ Since the last review I have added a newNavigableSetFromNavigableMap() implementation which I needed temporarily as I refactored out duplication in BoundedEmptyNavigableMap. I can either include this as part of this issue (it seems related enough), make a separate issue, or remove it. Comments and feedback welcome. Thanks! Mike On Apr 29 2013, at 18:54 , Mike Duigou wrote: > 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 jonathan.gibbons at oracle.com Wed May 15 01:03:21 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 01:03:21 +0000 Subject: hg: jdk8/tl/langtools: 8013163: Convert 4 tools multicatch tests to jtreg format Message-ID: <20130515010324.C4E7048A9D@hg.openjdk.java.net> Changeset: 53b389eb39c1 Author: sogoel Date: 2013-05-14 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/53b389eb39c1 8013163: Convert 4 tools multicatch tests to jtreg format Reviewed-by: jjg + test/tools/javac/multicatch/Pos11.java + test/tools/javac/multicatch/Pos12.java From brian.burkhalter at oracle.com Wed May 15 01:11:28 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 May 2013 18:11:28 -0700 Subject: 4646474 : BigInteger.pow() algorithm slow in 1.4.0 Message-ID: <33A2BE33-8D67-4F79-BEAD-231B09C6E101@oracle.com> The test in this issue report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 is pretty much useless for comparative purposes after applying 4837946 as the computed value is just a power of two which will be handled very quickly by the new algorithm. As a single alternate data point I modified the test instead to compute 17^13466917. The execution time on my MacBookPro5,3 before applying the 4837946 patch was 2336.975514 seconds and afterwards 79.202646 seconds: an improvement of about a factor of 30. I am sure that there are much more extreme examples than this but the result is good to see. I linked this issue to 4837946 as a duplicate so it will be closed out at the same time. Brian From david.holmes at oracle.com Wed May 15 03:17:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2013 13:17:57 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> Message-ID: <5192FE65.2000304@oracle.com> On 15/05/2013 2:57 AM, Martin Buchholz wrote: > On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters wrote: > >> IMO Thread.currentThread().stop(new Throwable()) should continue to work. >> It is not unsafe and it is probably used in a lot of code to workaround the >> madness that is checked exceptions. That is truly awful! Why wouldn't people just wrap in a runtime exception ???? Truly, truly awful. :( If we had to we could special-case for currentThread. :( > There are existing JDK tests that use currentThread().stop to implement the > occasionally necessary sneakyThrow. > > I suspect there are important uses of unsafe otherThread.stop in the real > world, where it is used as a last resort to shut down an "application" > running within a java vm, and works reasonably well in practice. I would dispute that it can work "reasonably well in practice" given the near impossibility of writing async-exception-safe non-trivial Java code. That aside, the proposal is only for the stop(throwable) form which I would not expect to be used for the termination case. David From jonathan.gibbons at oracle.com Wed May 15 04:10:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 04:10:15 +0000 Subject: hg: jdk8/tl/langtools: 8014323: Add VariableTree.getNameExpression Message-ID: <20130515041020.ED5C348AA0@hg.openjdk.java.net> Changeset: 529fb3ed5d2a Author: jjg Date: 2013-05-14 21:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/529fb3ed5d2a 8014323: Add VariableTree.getNameExpression Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! test/tools/javac/tree/SourceTreeScannerTest.java From david.holmes at oracle.com Wed May 15 04:15:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2013 14:15:18 +1000 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51922138.4050909@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> Message-ID: <51930BD6.1020108@oracle.com> On 14/05/2013 9:34 PM, Peter Levart wrote: > On 05/14/2013 01:17 PM, David Holmes wrote: >> Thanks Peter this looks good to me. >> >> One minor thing please set the correct copyright year in the test, it >> should just be >> >> Copyright (c) 2013, Oracle ... > > Ok, fixed: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ Thanks. >> I couldn't get the test to actually fail, but I can see that it could. > > Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails > immediately and always. You could try varying the number of concurrent > threads and or the time to wait for exception to be thrown... 24-way x86 system. I tried changing threads and timeout but still couldn't trigger a failure. Same for my 4-way win box. David >> >> David >> >> On 14/05/2013 9:04 PM, Peter Levart wrote: >>> Ok, here's the corrected fix: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>> >>> >>> I also added a reproducer for the bug. >>> >>> Regards, peter >>> >>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>> >>>> Right, sb.length() should be used. I will correct that as soon as I >>>> get to the keyboard. >>>> >>>> Regards, Peter >>>> >>>> On May 14, 2013 7:22 AM, "David Holmes" >>> > wrote: >>>> >>>> Thanks Peter! I've filed >>>> >>>> 8014477 >>>> Race condition in String.contentEquals when comparing with >>>> StringBuffer >>>> >>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>> >>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>> >>>> I noticed a synchronization bug in String.contentEquals >>>> method. If >>>> called with a StringBuffer argument while concurrent >>>> thread is >>>> modifying the StringBuffer, the method can either throw >>>> ArrayIndexOutOfBoundsException or return true even though >>>> the content >>>> of the StringBuffer has never been the same as the >>>> String's. >>>> >>>> Here's a proposed patch: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>> >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> Or even better (with some code clean-up): >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>> >>>> >>>> >>>> >>>> >>>> This part is not correct I believe: >>>> >>>> 1010 private boolean >>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>> 1011 char v1[] = value; >>>> 1012 char v2[] = sb.getValue(); >>>> 1013 int n = v1.length; >>>> 1014 if (n != v2.length) { >>>> 1015 return false; >>>> 1016 } >>>> >>>> v2 can be larger than v1 if v2 is not being fully used (ie count < >>>> length). >>>> >>>> David >>>> ----- >>>> >>> > From mike.duigou at oracle.com Wed May 15 04:22:10 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 May 2013 21:22:10 -0700 Subject: RFR : 8004015 : (S) Additional Functional Interface instance and static methods Message-ID: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> Hello all; This a fairly small set of additional methods for the existing Java 8 functional interfaces. These methods have been held back until now awaiting support for static interface methods. http://cr.openjdk.java.net/~mduigou/JDK-8004015/0/webrev/ Mike From david.holmes at oracle.com Wed May 15 04:46:51 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 15 May 2013 04:46:51 +0000 Subject: hg: jdk8/tl/jdk: 8013395: StringBuffer.toString performance regression impacting embedded benchmarks Message-ID: <20130515044703.2C79148AA4@hg.openjdk.java.net> Changeset: a3d79a4c2a24 Author: dholmes Date: 2013-05-15 00:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3d79a4c2a24 8013395: StringBuffer.toString performance regression impacting embedded benchmarks Summary: cache a copy of the char[] to use with toString() and clear it when ever the sb content is modified Reviewed-by: alanb, plevart, mduigou, forax ! src/share/classes/java/lang/StringBuffer.java + test/java/lang/StringBuffer/ToStringCache.java From martinrb at google.com Wed May 15 05:16:06 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 14 May 2013 22:16:06 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5192FE65.2000304@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> Message-ID: On Tue, May 14, 2013 at 8:17 PM, David Holmes wrote: > On 15/05/2013 2:57 AM, Martin Buchholz wrote: > >> On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters >> wrote: >> >> IMO Thread.currentThread().stop(**new Throwable()) should continue to >>> work. >>> It is not unsafe and it is probably used in a lot of code to workaround >>> the >>> madness that is checked exceptions. >>> >> > That is truly awful! Why wouldn't people just wrap in a runtime exception > ???? Truly, truly awful. :( > > General purpose library code sometimes would like to rethrow an exception that was previously caught. How should it do that? I don't think there's a generally accepted solution, although there's more than one (sneaky) way to do it, and we could stop using Thread.stop for that purpose. > If we had to we could special-case for currentThread. :( > > > There are existing JDK tests that use currentThread().stop to implement >> the >> occasionally necessary sneakyThrow. >> >> I suspect there are important uses of unsafe otherThread.stop in the real >> world, where it is used as a last resort to shut down an "application" >> running within a java vm, and works reasonably well in practice. >> > > I would dispute that it can work "reasonably well in practice" given the > near impossibility of writing async-exception-safe non-trivial Java code. > That aside, the proposal is only for the stop(throwable) form which I would > not expect to be used for the termination case. I agree it's unsafe. But you have the same problem to a lesser extent with kill -9, which is also an indispensable part of every engineer's toolbox, and works well enough in practice. From dawid.weiss at gmail.com Wed May 15 07:00:14 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 15 May 2013 09:00:14 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> Message-ID: Hello everyone, To contribute to the discussion concerning Thread.stop(*) and its usefulness. I've implemented a JUnit test runner for Lucene/ Solr and we needed test suite isolation badly but at the same time wanted to reuse the same JVM (for performance reasons). The initial implementation worked by detecting "leaked" threads (those started within a test suite and crossing its lifecycle boundary) and then tried to gracefully interrupt them; if this didn't help, an attempt to "kill" those threads was issued with a call to Thread.stop(). This works very well on small examples only. In practice what happens is: 1) you get loops with a catch (Throwable) inside; pretty much prevents the thread from being stopped (these we called ChuckNorris-type...), 2) threads going into native sections and hung there (not necessarily via JNI, even via system IO calls), Eventually we just dropped thread.stop altogether -- if a thread cannot be interrupted, it is considered a "zombie" and the test framework either proceeds or aborts entirely (depending on the configuration). So, based on this experience my point of view on the matter is that Thread.stop() is useless. For rethrowing checked exceptions you can use the generics-based sneaky throw. If you have control over the code of the threads you want to stop then you shouldn't use Thread.stop() anyway. For any code you don't have the control over it's not 100% reliable so I doubt its use is really fully justified. A much more needed addition to the standard library in place of Thread.stop() would be methods to acquire: 1) your own PID (this one is in planning for 1.8 or even has been added already), 2) forked process PID (?), 3) a way to kill the forked process (and possibly its sub-tree). These are platform-specific operations and the "workarounds" for these missing API calls are truly horrible, even if implemented nicely (see sources of Jenkins for example [1]). Dawid [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/util/ProcessTree.java#L501 From joe.darcy at oracle.com Wed May 15 07:01:03 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 15 May 2013 07:01:03 +0000 Subject: hg: jdk8/tl/langtools: 8004133: Provide javax.lang.model.* implementation backed by core reflection Message-ID: <20130515070112.226A448AA6@hg.openjdk.java.net> Changeset: bcd927639039 Author: darcy Date: 2013-05-15 00:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcd927639039 8004133: Provide javax.lang.model.* implementation backed by core reflection Summary: Joint work by darcy and jfranck to provide sample code for JEP 119. Reviewed-by: jjg Contributed-by: joe.darcy at oracle.com, joel.franck at oracle.com + src/share/sample/language/model/CoreReflectionFactory.java From peter.levart at gmail.com Wed May 15 07:50:18 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 15 May 2013 09:50:18 +0200 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> Message-ID: <51933E3A.7060905@gmail.com> Mike, David, Could you try this variant of the test: http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.05/ I tried it on 3 different machines (4-core i7 Linux, 8-core sparc T-2 Solaris, 4-core amd64 Solaris) x 2 different JDK8 JVMs (64bit and 32bit) and it fails immediately on all 6 of them. Regards, Peter On 05/14/2013 05:39 PM, Mike Duigou wrote: > Good to see the test added. I was also unable to reproduce the failure on my Core 2 Duo Mac laptop but the test and fix match up. > > Mike > > > On May 14 2013, at 04:34 , Peter Levart wrote: > >> On 05/14/2013 01:17 PM, David Holmes wrote: >>> Thanks Peter this looks good to me. >>> >>> One minor thing please set the correct copyright year in the test, it should just be >>> >>> Copyright (c) 2013, Oracle ... >> Ok, fixed: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ >> >> >>> I couldn't get the test to actually fail, but I can see that it could. >> Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails immediately and always. You could try varying the number of concurrent threads and or the time to wait for exception to be thrown... >> >>> David >>> >>> On 14/05/2013 9:04 PM, Peter Levart wrote: >>>> Ok, here's the corrected fix: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>>> >>>> I also added a reproducer for the bug. >>>> >>>> Regards, peter >>>> >>>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>>> Right, sb.length() should be used. I will correct that as soon as I >>>>> get to the keyboard. >>>>> >>>>> Regards, Peter >>>>> >>>>> On May 14, 2013 7:22 AM, "David Holmes" >>>> > wrote: >>>>> >>>>> Thanks Peter! I've filed >>>>> >>>>> 8014477 >>>>> Race condition in String.contentEquals when comparing with >>>>> StringBuffer >>>>> >>>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>>> >>>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>>> >>>>> I noticed a synchronization bug in String.contentEquals >>>>> method. If >>>>> called with a StringBuffer argument while concurrent thread is >>>>> modifying the StringBuffer, the method can either throw >>>>> ArrayIndexOutOfBoundsException or return true even though >>>>> the content >>>>> of the StringBuffer has never been the same as the String's. >>>>> >>>>> Here's a proposed patch: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> Or even better (with some code clean-up): >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>>> >>>>> >>>>> >>>>> This part is not correct I believe: >>>>> >>>>> 1010 private boolean >>>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>>> 1011 char v1[] = value; >>>>> 1012 char v2[] = sb.getValue(); >>>>> 1013 int n = v1.length; >>>>> 1014 if (n != v2.length) { >>>>> 1015 return false; >>>>> 1016 } >>>>> >>>>> v2 can be larger than v1 if v2 is not being fully used (ie count < >>>>> length). >>>>> >>>>> David >>>>> ----- >>>>> From david.holmes at oracle.com Wed May 15 08:05:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2013 18:05:16 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> Message-ID: <519341BC.2000702@oracle.com> On 15/05/2013 3:16 PM, Martin Buchholz wrote: > On Tue, May 14, 2013 at 8:17 PM, David Holmes > wrote: > > On 15/05/2013 2:57 AM, Martin Buchholz wrote: > > On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters > > wrote: > > IMO Thread.currentThread().stop(__new Throwable()) should > continue to work. > It is not unsafe and it is probably used in a lot of code to > workaround the > madness that is checked exceptions. > > > That is truly awful! Why wouldn't people just wrap in a runtime > exception ???? Truly, truly awful. :( > > > General purpose library code sometimes would like to rethrow an > exception that was previously caught. > How should it do that? Umm catch it and throw it. If it is a checked-exception that you want to propogate then you should have declared it on your method, else you are going to wrap it in a runtime exception or error. There is no need for such sleaze. > I don't think there's a generally accepted > solution, although there's more than one (sneaky) way to do it, and we > could stop using Thread.stop for that purpose. > If we had to we could special-case for currentThread. :( > > > There are existing JDK tests that use currentThread().stop to > implement the > occasionally necessary sneakyThrow. > > I suspect there are important uses of unsafe otherThread.stop in > the real > world, where it is used as a last resort to shut down an > "application" > running within a java vm, and works reasonably well in practice. > > > I would dispute that it can work "reasonably well in practice" given > the near impossibility of writing async-exception-safe non-trivial > Java code. That aside, the proposal is only for the stop(throwable) > form which I would not expect to be used for the termination case. > > > I agree it's unsafe. But you have the same problem to a lesser extent > with kill -9, which is also an indispensable part of every engineer's > toolbox, and works well enough in practice. There is a huge difference between blowing away a complete process with kill and having a single thread starting to propagate an async exception, unwinding its stack and executing finally blocks with completely broken state invariants. David From Alan.Bateman at oracle.com Wed May 15 08:31:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 09:31:26 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> Message-ID: <519347DE.80607@oracle.com> On 15/05/2013 08:00, Dawid Weiss wrote: > : > > A much more needed addition to the standard library in place of > Thread.stop() would be methods to acquire: > > 1) your own PID (this one is in planning for 1.8 or even has been > added already), > 2) forked process PID (?), > 3) a way to kill the forked process (and possibly its sub-tree). > We have JEP 102 to update Process. Some of the low hanging fruit, like Process.destroyForcibly, went into jdk8 so they have been removed from the JEP. There has been a number of attempts at adding support for exposing the process-id. Implementation is trivial, the hard part has always been consideration for environments where they may not be a 1-1 mapping. In any case, thanks for the comments and experiences on using Thread.stop. -Alan. From martin.desruisseaux at geomatys.fr Wed May 15 08:39:22 2013 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Wed, 15 May 2013 10:39:22 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519341BC.2000702@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> Message-ID: <519349BA.1010501@geomatys.fr> Le 15/05/13 10:05, David Holmes a ?crit : > There is a huge difference between blowing away a complete process > with kill and having a single thread starting to propagate an async > exception, unwinding its stack and executing finally blocks with > completely broken state invariants. Given the risk, what about a mechanism similar to the one which currently hides the Sun internal packages from the compilation phase but not yet from the runtime phase? Would it be acceptable to have 'javac' and 'javadoc' woking as if the 'Thread.stop(Throwable)' method did not existed anymore, while having the method still working (for now) at runtime for existing libraries? Maybe with an annotation yet stronger than @Deprecated. Martin From dawid.weiss at gmail.com Wed May 15 08:48:29 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 15 May 2013 10:48:29 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519347DE.80607@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519347DE.80607@oracle.com> Message-ID: > We have JEP 102 to update Process. Some of the low hanging fruit, like > Process.destroyForcibly, went into jdk8 so they have been removed from the JEP. Thanks for the pointer, Alan. I fully agree with the rationale: "Long-standing shortcoming in the platform [...] Long requested by developers." > [...] the hard part has always been consideration for environments where they may > not be a 1-1 mapping. I think this should be handled by allowing those methods to throw UnsupportedOperationException or some other form of signalling the operation as unsupported. 99% of the operating systems in existence will have (trivial?) support for these operations -- they are the very core of what an operating system is (process management), right?. Dawid From Alan.Bateman at oracle.com Wed May 15 08:50:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 09:50:21 +0100 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51933E3A.7060905@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> Message-ID: <51934C4D.5080006@oracle.com> On 15/05/2013 08:50, Peter Levart wrote: > Mike, David, > > Could you try this variant of the test: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.05/ > > > > I tried it on 3 different machines (4-core i7 Linux, 8-core sparc T-2 > Solaris, 4-core amd64 Solaris) x 2 different JDK8 JVMs (64bit and > 32bit) and it fails immediately on all 6 of them. > > Regards, Peter > The previous and new version both duplicate almost immediately for me when I tried on a 2 x 4-core Xeon and a 64 thread T4. -Alan. From yiming.wang at oracle.com Wed May 15 09:10:39 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 15 May 2013 17:10:39 +0800 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Message-ID: <5193510F.8060809@oracle.com> Hi, Please help to review the fix for bug 8004177 and 8004178 , this fix is to make sure all child threads finished before main thread exits. http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ For 8004178, the test StackTraces.java is same as GenerifyStackTraces.java, so just remove it. Thanks, Eric From chris.hegarty at oracle.com Wed May 15 09:26:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 10:26:05 +0100 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <5193510F.8060809@oracle.com> References: <5193510F.8060809@oracle.com> Message-ID: <519354AD.5060307@oracle.com> Looks fine to me Eric. Let me know if you need someone to sponsor this change for you. -Chris. On 15/05/2013 10:10, Eric Wang wrote: > Hi, > > Please help to review the fix for bug 8004177 > and 8004178 > , this fix is to make > sure all child threads finished before main thread exits. > > http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ > > > For 8004178, the test StackTraces.java is same as > GenerifyStackTraces.java, so just remove it. > > Thanks, > Eric From yiming.wang at oracle.com Wed May 15 09:26:48 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 15 May 2013 17:26:48 +0800 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <519354AD.5060307@oracle.com> References: <5193510F.8060809@oracle.com> <519354AD.5060307@oracle.com> Message-ID: <519354D8.8080000@oracle.com> Hi Chris, Thanks you for the review and sponsor this change. Regards, Eric On 2013/5/15 17:26, Chris Hegarty wrote: > Looks fine to me Eric. Let me know if you need someone to sponsor this > change for you. > > -Chris. > > On 15/05/2013 10:10, Eric Wang wrote: >> Hi, >> >> Please help to review the fix for bug 8004177 >> and 8004178 >> , this fix is to make >> sure all child threads finished before main thread exits. >> >> http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ >> >> >> For 8004178, the test StackTraces.java is same as >> GenerifyStackTraces.java, so just remove it. >> >> Thanks, >> Eric From Alan.Bateman at oracle.com Wed May 15 09:38:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 10:38:04 +0100 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <5193510F.8060809@oracle.com> References: <5193510F.8060809@oracle.com> Message-ID: <5193577C.9030802@oracle.com> On 15/05/2013 10:10, Eric Wang wrote: > Hi, > > Please help to review the fix for bug 8004177 > and 8004178 > , this fix is to make > sure all child threads finished before main thread exits. > > http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ > > > For 8004178, the test StackTraces.java is same as > GenerifyStackTraces.java, so just remove it. > > Thanks, > Eric It's good to have fix this test so that it doesn't leave a thread behind (in this case slowing down the execution of subsequent tests by taking thread dumps every 2 seconds) The change you propose is okay but a bit odd to have ThreadOne signal DumpThread to shutdown. An alternative would be to have the main thread signal DumpThread, as in: one.join(); finished = true; dt.join(); Better still might be to move the flag into the DumpThread class and have it define a shutdown method so the main thread does: one.join(); dt.shutdown(); dt.join(); I think that would be a bit cleaner. -Alan. From chris.hegarty at oracle.com Wed May 15 09:43:31 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 10:43:31 +0100 Subject: RFR : 8004015 : (S) Additional Functional Interface instance and static methods In-Reply-To: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> References: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> Message-ID: <519358C3.3080206@oracle.com> All looks good to me, and nicely consistent. -Chris. On 15/05/2013 05:22, Mike Duigou wrote: > Hello all; > > This a fairly small set of additional methods for the existing Java 8 functional interfaces. These methods have been held back until now awaiting support for static interface methods. > > http://cr.openjdk.java.net/~mduigou/JDK-8004015/0/webrev/ > > Mike From daniel.fuchs at oracle.com Wed May 15 09:42:09 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 May 2013 11:42:09 +0200 Subject: RFR: JDK-8013900: More warnings compiling jaxp. In-Reply-To: <5190FA78.2060608@oracle.com> References: <5190FA78.2060608@oracle.com> Message-ID: <51935871.80500@oracle.com> Hi, Please find below a revised version of the fix for JDK-8013900: More warnings compiling jaxp. Difference with the previous version [1] are in LocalVariableGen.java, plus 4 additional files: BranchInstruction.java CodeExceptionGen.java LineNumberGen.java Select.java This new set of changes fixes an additional issue I discovered in LocalVariableGen.java - while running the JCK tests. LocalVariableGen had a bug that was hidden by the fact that hashCode() was not compliant with equals(). Changing hashCode() to be compliant with equals() uncovered that issue. The issue with LocalVariableGen is that the instance variables used by equals/hashCode are mutable. This is an issue because instances of LocalVariableGen are stored in an HashSet (targeters) held from instances of InstructionHandle. Whenever the instruction handles in LocalVariableGen are changed, then the instance of LocalVariableGen was removed from the 'old' instruction handle targeters HashSet, and added to the 'new' instruction handle targeters HashSet - (see LocalVariableGen updateTargets(..), LocalVariableGen.setStart(...) & LocalVariableGen.setEnd(...). The issue here was that the instance of LocalVariableGen was removed from the 'old' instruction handle targeters HashSet before being modified (which was correct) - but was also added to the 'new' instruction handle targeters HashSet before being modified - which was incorrect because at that time the hashCode() was still computed using the 'old' instruction handle, and therefore had its 'old' value. (this was done by BranchInstruction.notifyTarget(...)) The fix for this new issue is to split BranchInstruction.notifyTarget(...) in two methods: BranchInstruction.notifyTargetChanging(...) which is called before the instruction handle pointer is changed, and remove the LocalVariableGen from the old instruction handle targeters HashSet, and BranchInstruction.notifyTargetChanged(...), which is called after the instruction handle pointer is changed, and adds the LocalVariableGen to the new instruction handle targeters HashSet. In LocalVariableGen - whenever one of the instruction handles that take parts in the hashCode computation is changed, we unregister 'this' from all targeters HashSets in which it is registered, then modify the instruction handle pointer, then add back 'this' to all targeters HashSets in which it needs to be registered. The 4 additional files in the webrev were also calling BranchInstruction.notifyTarget - and I modified them to call the two new methods instead of the old one - but without going through the trouble of unregistering 'this' from any known HashSet before modifictation - and adding it after, since those other classes do not have mutable hashCode(). Note: I also took this opportunity to change the method calling BranchInstruction.notifyTargetXxxx to be final, as I think it's desirable that they not be overridden, and to make the index in LocalVariableGen final - since it was never changed after the instance construction (and takes part in the HashCode computation). best regards, -- daniel previous version: [1] On 5/13/13 4:36 PM, Daniel Fuchs wrote: > This is a fix for JDK-8013900: More warnings compiling jaxp. > > > > Although the title might suggest a trivial fix, it goes a bit > beyond a simple warning fix because the root cause of those warnings > is that some classes redefine equals without redefining > hashCode() - and devising a hashCode() method that respects > its contract with equals() is not always trivial. > > The proposed fix adds hashCode() methods where necessary, ensuring > that: > > if (o1.equals(o2) == true), then (o1.hashCode() == o2.hashCode()) > > The fix also contains some cosmetic/sanity changes - like: > > 1. adding @Override wherever NetBeans complained they were > missing - and > 2. replacing StringBuffer with StringBuilder when > possible. > 3. In one instance, AbstractDateTimeDV.java I also had > to reformat the whole file (due to its weird original formatting) > - apologies for the noise it causes in the webrev. > 4. I also removed a couple of private isEqual(obj1, obj2) methods > replacing them by calls to Objects.equals(obj1, obj2) which did > the same thing. > 5. finally I refactored some of the existing equals (e.g. replacing > try { (Sometype) other.... } catch (ClassCastException x) { > return false; } with use of 'other instanceof Sometype'...) > > There are however a couple of more serious changes that could > deserve to be reviewed in more details: > > a. The new implementation of hashCode() in > AbstractDateTimeDV.DateTimeData, where I had to figure > out a way to convert the date to UTC so that the hashCode() would > match equals: > > AbstractDateTimeDV.java: lines 972-992 > > and b. in PrecisionDecimalDV.XPrecisionDecimal - where I had to > invent a canonical string representation to devise a hashCode that > would match equals: > > PrecisionDecimalDV.java: lines 147-237 > > For this last one - I have added a new test in jdk/test to check > the implementation of the new canonical String representation > for hashCode() - since the code of that is not trivial. > > > best regards, > > -- daniel From yiming.wang at oracle.com Wed May 15 11:07:28 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 15 May 2013 19:07:28 +0800 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <5193577C.9030802@oracle.com> References: <5193510F.8060809@oracle.com> <5193577C.9030802@oracle.com> Message-ID: <51936C70.8030806@oracle.com> On 2013/5/15 17:38, Alan Bateman wrote: > On 15/05/2013 10:10, Eric Wang wrote: >> Hi, >> >> Please help to review the fix for bug 8004177 >> and 8004178 >> , this fix is to make >> sure all child threads finished before main thread exits. >> >> http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ >> >> >> For 8004178, the test StackTraces.java is same as >> GenerifyStackTraces.java, so just remove it. >> >> Thanks, >> Eric > It's good to have fix this test so that it doesn't leave a thread > behind (in this case slowing down the execution of subsequent tests by > taking thread dumps every 2 seconds) > > The change you propose is okay but a bit odd to have ThreadOne signal > DumpThread to shutdown. An alternative would be to have the main > thread signal DumpThread, as in: > > one.join(); > > finished = true; > dt.join(); > > Better still might be to move the flag into the DumpThread class and > have it define a shutdown method so the main thread does: > > one.join(); > > dt.shutdown(); > dt.join(); > > I think that would be a bit cleaner. > > -Alan. > > > Hi Alan, Thanks for the suggestion, I have updated the fix again, Can you please help to take a look? http://cr.openjdk.java.net/~ewang/8004177/webrev.01/ Regards, Eric From chris.hegarty at oracle.com Wed May 15 11:56:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2013 12:56:48 +0100 Subject: RFR: JDK-8013900: More warnings compiling jaxp. In-Reply-To: <51935871.80500@oracle.com> References: <5190FA78.2060608@oracle.com> <51935871.80500@oracle.com> Message-ID: <51937800.10902@oracle.com> I skimmed over the hashCode/equals parts of the changes, and they look fine to me. -Chris. On 15/05/2013 10:42, Daniel Fuchs wrote: > Hi, > > Please find below a revised version of the fix for > JDK-8013900: More warnings compiling jaxp. > > > Difference with the previous version [1] are in LocalVariableGen.java, > plus 4 additional files: > BranchInstruction.java > CodeExceptionGen.java > LineNumberGen.java > Select.java > > This new set of changes fixes an additional issue I discovered in > LocalVariableGen.java - while running the JCK tests. > > LocalVariableGen had a bug that was hidden by the fact > that hashCode() was not compliant with equals(). > Changing hashCode() to be compliant with equals() uncovered > that issue. > > The issue with LocalVariableGen is that the instance > variables used by equals/hashCode are mutable. > This is an issue because instances of LocalVariableGen are > stored in an HashSet (targeters) held from instances of > InstructionHandle. > > Whenever the instruction handles in LocalVariableGen are changed, > then the instance of LocalVariableGen was removed from the 'old' > instruction handle targeters HashSet, and added to the 'new' > instruction handle targeters HashSet - (see LocalVariableGen > updateTargets(..), LocalVariableGen.setStart(...) & > LocalVariableGen.setEnd(...). > > The issue here was that the instance of LocalVariableGen was > removed from the 'old' instruction handle targeters HashSet > before being modified (which was correct) - but was also > added to the 'new' instruction handle targeters HashSet > before being modified - which was incorrect because at > that time the hashCode() was still computed using the 'old' > instruction handle, and therefore had its 'old' value. > (this was done by BranchInstruction.notifyTarget(...)) > > The fix for this new issue is to split > BranchInstruction.notifyTarget(...) in two methods: > BranchInstruction.notifyTargetChanging(...) which is called > before the instruction handle pointer is changed, and remove > the LocalVariableGen from the old instruction handle targeters > HashSet, and BranchInstruction.notifyTargetChanged(...), which > is called after the instruction handle pointer is changed, > and adds the LocalVariableGen to the new instruction handle > targeters HashSet. > In LocalVariableGen - whenever one of the instruction handles > that take parts in the hashCode computation is changed, we > unregister 'this' from all targeters HashSets in which it > is registered, then modify the instruction handle pointer, > then add back 'this' to all targeters HashSets in which it > needs to be registered. > > The 4 additional files in the webrev were also calling > BranchInstruction.notifyTarget - and I modified them to > call the two new methods instead of the old one - but without > going through the trouble of unregistering 'this' from any > known HashSet before modifictation - and adding it after, > since those other classes do not have mutable hashCode(). > > Note: I also took this opportunity to change the method > calling BranchInstruction.notifyTargetXxxx to be final, as > I think it's desirable that they not be overridden, and to > make the index in LocalVariableGen final - since it was > never changed after the instance construction (and takes > part in the HashCode computation). > > best regards, > > -- daniel > > previous version: > [1] > > On 5/13/13 4:36 PM, Daniel Fuchs wrote: >> This is a fix for JDK-8013900: More warnings compiling jaxp. >> >> >> >> Although the title might suggest a trivial fix, it goes a bit >> beyond a simple warning fix because the root cause of those warnings >> is that some classes redefine equals without redefining >> hashCode() - and devising a hashCode() method that respects >> its contract with equals() is not always trivial. >> >> The proposed fix adds hashCode() methods where necessary, ensuring >> that: >> >> if (o1.equals(o2) == true), then (o1.hashCode() == o2.hashCode()) >> >> The fix also contains some cosmetic/sanity changes - like: >> >> 1. adding @Override wherever NetBeans complained they were >> missing - and >> 2. replacing StringBuffer with StringBuilder when >> possible. >> 3. In one instance, AbstractDateTimeDV.java I also had >> to reformat the whole file (due to its weird original formatting) >> - apologies for the noise it causes in the webrev. >> 4. I also removed a couple of private isEqual(obj1, obj2) methods >> replacing them by calls to Objects.equals(obj1, obj2) which did >> the same thing. >> 5. finally I refactored some of the existing equals (e.g. replacing >> try { (Sometype) other.... } catch (ClassCastException x) { >> return false; } with use of 'other instanceof Sometype'...) >> >> There are however a couple of more serious changes that could >> deserve to be reviewed in more details: >> >> a. The new implementation of hashCode() in >> AbstractDateTimeDV.DateTimeData, where I had to figure >> out a way to convert the date to UTC so that the hashCode() would >> match equals: >> >> AbstractDateTimeDV.java: lines 972-992 >> >> and b. in PrecisionDecimalDV.XPrecisionDecimal - where I had to >> invent a canonical string representation to devise a hashCode that >> would match equals: >> >> PrecisionDecimalDV.java: lines 147-237 >> >> For this last one - I have added a new test in jdk/test to check >> the implementation of the new canonical String representation >> for hashCode() - since the code of that is not trivial. >> >> >> best regards, >> >> -- daniel > From maurizio.cimadamore at oracle.com Wed May 15 13:04:19 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 15 May 2013 13:04:19 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130515130430.BE5EE48AC0@hg.openjdk.java.net> Changeset: 05ec778794d0 Author: mcimadamore Date: 2013-05-15 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05ec778794d0 8012003: Method diagnostics resolution need to be simplified in some cases Summary: Unfold method resolution diagnostics when they mention errors in poly expressions Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/Diagnostics/compressed/T8012003a.java + test/tools/javac/Diagnostics/compressed/T8012003a.out + test/tools/javac/Diagnostics/compressed/T8012003b.java + test/tools/javac/Diagnostics/compressed/T8012003b.out + test/tools/javac/Diagnostics/compressed/T8012003c.java + test/tools/javac/Diagnostics/compressed/T8012003c.out ! test/tools/javac/diags/examples/BadArgTypesInLambda.java + test/tools/javac/diags/examples/CompressedDiags.java ! test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/ProbFoundReqFragment.java ! test/tools/javac/lambda/TargetType66.out Changeset: 33d1937af1a3 Author: mcimadamore Date: 2013-05-15 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33d1937af1a3 8012685: Spurious raw types warning when using unbound method references Summary: Spurious raw type warning when unbound method reference qualifier parameter types are inferred from target Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/MethodReference67.java + test/tools/javac/lambda/MethodReference67.out Changeset: 78717f2d00e8 Author: mcimadamore Date: 2013-05-15 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/78717f2d00e8 8013222: Javac issues spurious raw type warnings when lambda has implicit parameter types Summary: Bad warnings and position for lambda inferred parameter types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/NoWarnOnImplicitParams.java + test/tools/javac/lambda/NoWarnOnImplicitParams.out From vitalyd at gmail.com Wed May 15 13:50:27 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 15 May 2013 09:50:27 -0400 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519341BC.2000702@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> Message-ID: There's also Unsafe.throwException which can be used to rethrow checked exceptions. Without getting into another debate over checked exceptions, this approach is much better than Thread.stop. Sent from my phone On May 15, 2013 4:06 AM, "David Holmes" wrote: > On 15/05/2013 3:16 PM, Martin Buchholz wrote: > >> On Tue, May 14, 2013 at 8:17 PM, David Holmes > >> wrote: >> >> On 15/05/2013 2:57 AM, Martin Buchholz wrote: >> >> On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters >> > wrote: >> >> IMO Thread.currentThread().stop(__**new Throwable()) should >> continue to work. >> It is not unsafe and it is probably used in a lot of code to >> workaround the >> madness that is checked exceptions. >> >> >> That is truly awful! Why wouldn't people just wrap in a runtime >> exception ???? Truly, truly awful. :( >> >> >> General purpose library code sometimes would like to rethrow an >> exception that was previously caught. >> How should it do that? >> > > Umm catch it and throw it. If it is a checked-exception that you want to > propogate then you should have declared it on your method, else you are > going to wrap it in a runtime exception or error. There is no need for such > sleaze. > > I don't think there's a generally accepted >> solution, although there's more than one (sneaky) way to do it, and we >> could stop using Thread.stop for that purpose. >> > > > If we had to we could special-case for currentThread. :( >> >> >> There are existing JDK tests that use currentThread().stop to >> implement the >> occasionally necessary sneakyThrow. >> >> I suspect there are important uses of unsafe otherThread.stop in >> the real >> world, where it is used as a last resort to shut down an >> "application" >> running within a java vm, and works reasonably well in practice. >> >> >> I would dispute that it can work "reasonably well in practice" given >> the near impossibility of writing async-exception-safe non-trivial >> Java code. That aside, the proposal is only for the stop(throwable) >> form which I would not expect to be used for the termination case. >> >> >> I agree it's unsafe. But you have the same problem to a lesser extent >> with kill -9, which is also an indispensable part of every engineer's >> toolbox, and works well enough in practice. >> > > There is a huge difference between blowing away a complete process with > kill and having a single thread starting to propagate an async exception, > unwinding its stack and executing finally blocks with completely broken > state invariants. > > David > From robert.field at oracle.com Wed May 15 13:53:42 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 15 May 2013 13:53:42 +0000 Subject: hg: jdk8/tl/langtools: 8010006: NPE in javac with interface super in lambda Message-ID: <20130515135345.9330248AC2@hg.openjdk.java.net> Changeset: 31ef33db5e0e Author: rfield Date: 2013-05-15 06:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31ef33db5e0e 8010006: NPE in javac with interface super in lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaWithInterfaceSuper.java From michael.x.mcmahon at oracle.com Wed May 15 14:02:29 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 15 May 2013 14:02:29 +0000 Subject: hg: jdk8/tl/jdk: 8010464: Evolve java networking same origin policy Message-ID: <20130515140249.4F36C48AC3@hg.openjdk.java.net> Changeset: 93a268759ec3 Author: michaelm Date: 2013-05-15 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93a268759ec3 8010464: Evolve java networking same origin policy Reviewed-by: alanb, chegar, dsamersoff, weijun ! src/share/classes/java/net/HttpURLConnection.java + src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLPermission/HttpURLPermissionTest.java + test/java/net/HttpURLPermission/URLTest.java + test/java/net/HttpURLPermission/policy.1 + test/java/net/HttpURLPermission/policy.2 + test/java/net/HttpURLPermission/policy.3 From forax at univ-mlv.fr Wed May 15 14:04:37 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 May 2013 16:04:37 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519349BA.1010501@geomatys.fr> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> Message-ID: <519395F5.8080502@univ-mlv.fr> On 05/15/2013 10:39 AM, Martin Desruisseaux wrote: > Le 15/05/13 10:05, David Holmes a ?crit : >> There is a huge difference between blowing away a complete process >> with kill and having a single thread starting to propagate an async >> exception, unwinding its stack and executing finally blocks with >> completely broken state invariants. > > Given the risk, what about a mechanism similar to the one which > currently hides the Sun internal packages from the compilation phase > but not yet from the runtime phase? Would it be acceptable to have > 'javac' and 'javadoc' woking as if the 'Thread.stop(Throwable)' method > did not existed anymore, while having the method still working (for > now) at runtime for existing libraries? Maybe with an annotation yet > stronger than @Deprecated. > > Martin > yes, I propose @Retired. R?mi From david.r.chase at oracle.com Wed May 15 14:30:56 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 May 2013 10:30:56 -0400 Subject: What's the correct repository on which to base changes to "jdk"? Message-ID: <38D4CAF9-3EA0-4FAC-B6AA-44510CDDDD3C@oracle.com> The changed files are these: M src/share/classes/java/util/zip/Adler32.java M src/share/classes/java/util/zip/CRC32.java M src/share/classes/sun/misc/VM.java M src/share/native/java/util/zip/CRC32.c M test/java/util/zip/TimeChecksum.java A test/java/util/zip/CRCandAdlerTest.java This is for a performance RFE filed against "compiler", JDK-7088419: "Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32" The nature of the changes is 1) adding fork-join parallelism for Adler32 and CRC32, 2) handling small cases in Java when that is cheaper than JNI overheads, 3) on suitable Intel platforms, using a fancy instruction to make CRC go faster. There's a companion patch for the hotspot side -- the two conspire to pass platform feature information through a property "sun.zip.clmulSupported". And to which list should I post the request for reviews? David From neugens.limasoftware at gmail.com Wed May 15 14:36:38 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 15 May 2013 16:36:38 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519395F5.8080502@univ-mlv.fr> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> Message-ID: 2013/5/15 Remi Forax : > On 05/15/2013 10:39 AM, Martin Desruisseaux wrote: >> >> Le 15/05/13 10:05, David Holmes a ?crit : >>> >>> There is a huge difference between blowing away a complete process with >>> kill and having a single thread starting to propagate an async exception, >>> unwinding its stack and executing finally blocks with completely broken >>> state invariants. >> >> >> Given the risk, what about a mechanism similar to the one which currently >> hides the Sun internal packages from the compilation phase but not yet from >> the runtime phase? Would it be acceptable to have 'javac' and 'javadoc' >> woking as if the 'Thread.stop(Throwable)' method did not existed anymore, >> while having the method still working (for now) at runtime for existing >> libraries? Maybe with an annotation yet stronger than @Deprecated. >> >> Martin >> > > yes, I propose @Retired. +1 I think it should also blow at runtime unless people passes some fancy argument (like -XX:recallRetired :), this way is easier for people to fix their code, or, in case they can't, do workaround it. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From Alan.Bateman at oracle.com Wed May 15 14:43:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 15:43:14 +0100 Subject: What's the correct repository on which to base changes to "jdk"? In-Reply-To: <38D4CAF9-3EA0-4FAC-B6AA-44510CDDDD3C@oracle.com> References: <38D4CAF9-3EA0-4FAC-B6AA-44510CDDDD3C@oracle.com> Message-ID: <51939F02.5040308@oracle.com> On 15/05/2013 15:30, David Chase wrote: > The changed files are these: > > M src/share/classes/java/util/zip/Adler32.java > M src/share/classes/java/util/zip/CRC32.java > M src/share/classes/sun/misc/VM.java > M src/share/native/java/util/zip/CRC32.c > M test/java/util/zip/TimeChecksum.java > A test/java/util/zip/CRCandAdlerTest.java > > This is for a performance RFE filed against "compiler", > > JDK-7088419: "Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32" > > The nature of the changes is > 1) adding fork-join parallelism for Adler32 and CRC32, > 2) handling small cases in Java when that is cheaper than JNI overheads, > 3) on suitable Intel platforms, using a fancy instruction to make CRC go faster. > > There's a companion patch for the hotspot side -- the two conspire to pass platform feature information > through a property "sun.zip.clmulSupported". > > And to which list should I post the request for reviews? > > David > The core-libs-dev is best for the java.util.zip code. You can push changes to the zip code via any of the integration forests but I think it would be best if you used jdk8/tl/jdk as that is the route for all changes to the "core" libraries. -Alan From xueming.shen at oracle.com Wed May 15 14:50:54 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 15 May 2013 14:50:54 +0000 Subject: hg: jdk8/tl/jdk: 8013730: JSR 310 DateTime API Updates III Message-ID: <20130515145126.167A448AC6@hg.openjdk.java.net> Changeset: ef04044f77d2 Author: sherman Date: 2013-05-15 07:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef04044f77d2 8013730: JSR 310 DateTime API Updates III Summary: Integration of JSR310 Date/Time API update III Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DateTimeException.java ! 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/Ser.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/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/Ser.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/DateTimeFormatSymbols.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/DateTimeParseException.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/DecimalStyle.java ! src/share/classes/java/time/format/FormatStyle.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/format/SignStyle.java ! src/share/classes/java/time/format/TextStyle.java ! src/share/classes/java/time/format/package-info.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/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.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/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesException.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneOffset.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/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.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/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java + test/java/time/tck/java/time/format/TCKDecimalStyle.java + test/java/time/tck/java/time/format/TCKInstantPrinterParser.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.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/TestJapaneseChronology.java ! test/java/time/test/java/time/format/AbstractTestPrinterParser.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/TestDecimalStyle.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/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java From david.r.chase at oracle.com Wed May 15 15:39:18 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 May 2013 11:39:18 -0400 Subject: What's the correct repository on which to base changes to "jdk"? In-Reply-To: <51939F02.5040308@oracle.com> References: <38D4CAF9-3EA0-4FAC-B6AA-44510CDDDD3C@oracle.com> <51939F02.5040308@oracle.com> Message-ID: <34A16738-0F98-4C05-99DA-E19F3530F8F1@oracle.com> Thanks, I'll bring it up to date. On 2013-05-15, at 10:43 AM, Alan Bateman wrote: > The core-libs-dev is best for the java.util.zip code. > > You can push changes to the zip code via any of the integration forests but I think it would be best if you used jdk8/tl/jdk as that is the route for all changes to the "core" libraries. > > -Alan From ivan.gerasimov at oracle.com Wed May 15 15:40:50 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 15 May 2013 19:40:50 +0400 Subject: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call Message-ID: <5193AC82.7010902@oracle.com> Hello! Please have a chance to review a simple change proposal. CheckedInputStream.skip() allocates temporary buffer on every call. It's suggested to have a temporary buffer that is initialized on the first use and can be reused during subsequent calls to the skip() function. Many other input streams already use the same approach. http://cr.openjdk.java.net/~dmeetry/8014657/webrev.0/ Sincerely, Ivan From xueming.shen at oracle.com Wed May 15 16:34:10 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 15 May 2013 09:34:10 -0700 Subject: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call In-Reply-To: <5193AC82.7010902@oracle.com> References: <5193AC82.7010902@oracle.com> Message-ID: <5193B902.20009@oracle.com> public long skip(long n) throws IOException { - byte[] buf = new byte[512]; + if (tmpbuf == null) { + tmpbuf = new byte[512]; + } long total = 0; while (total < n) { long len = n - total; - len = read(buf, 0, len < buf.length ? (int)len : buf.length); + len = read(buf, 0, len < tmpbuf.length ? (int)len : tmpbuf.length); if (len == -1) { return total; } total += len; } Shouldn't the first param "buf" to be "tmpbuf" as well at ln#104, otherwise I guess it will not pass the compiler? -Sherman On 05/15/2013 08:40 AM, Ivan Gerasimov wrote: > Hello! > > Please have a chance to review a simple change proposal. > > CheckedInputStream.skip() allocates temporary buffer on every call. > It's suggested to have a temporary buffer that is initialized on the first use and can be reused during subsequent calls to the skip() function. > Many other input streams already use the same approach. > > http://cr.openjdk.java.net/~dmeetry/8014657/webrev.0/ > > Sincerely, > Ivan From joe.darcy at oracle.com Wed May 15 16:44:27 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 15 May 2013 09:44:27 -0700 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <51923D04.7000308@oracle.com> References: <518D601E.6070701@oracle.com> <51923D04.7000308@oracle.com> Message-ID: <5193BB6B.6080807@oracle.com> On 05/14/2013 06:32 AM, Alan Bateman wrote: > On 10/05/2013 22:01, Joe Darcy wrote: >> Hello, >> >> Please (re)review this change to introduce Objects.requireNonNull(T, >> Supplier): >> >> http://cr.openjdk.java.net/~darcy/8014365.0/ >> >> The original change had to be pulled out because of a build issue >> (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs >> build); I'll be asking for a review on build-dev of the build-related >> change in langtools. The test portion of the patch is slightly >> different than before because of the intervening changes made for >> >> 8013712: Add Objects.nonNull and Objects.isNull > I realize this has already been pushed but just to point out a missing > parenthesis on line 272 in the javadoc, needs to be ")}". > Sorry for introduce the javadoc issue. Please review this patch --- a/src/share/classes/java/util/Objects.java Mon May 13 22:16:55 2013 -0700 +++ b/src/share/classes/java/util/Objects.java Wed May 15 09:43:16 2013 -0700 @@ -269,7 +269,7 @@ * 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}, + *

                  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 and I'll file a bug a push the fix. Thanks, -Joe From Alan.Bateman at oracle.com Wed May 15 16:47:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2013 17:47:18 +0100 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <5193BB6B.6080807@oracle.com> References: <518D601E.6070701@oracle.com> <51923D04.7000308@oracle.com> <5193BB6B.6080807@oracle.com> Message-ID: <5193BC16.6050009@oracle.com> On 15/05/2013 17:44, Joe Darcy wrote: > : > > Sorry for introduce the javadoc issue. > > Please review this patch > > --- a/src/share/classes/java/util/Objects.java Mon May 13 22:16:55 > 2013 -0700 > +++ b/src/share/classes/java/util/Objects.java Wed May 15 09:43:16 > 2013 -0700 > @@ -269,7 +269,7 @@ > * 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}, > + *

                  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 > > and I'll file a bug a push the fix. Looks good to me. -Alan. From joe.darcy at oracle.com Wed May 15 16:54:45 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 15 May 2013 16:54:45 +0000 Subject: hg: jdk8/tl/jdk: 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier) Message-ID: <20130515165503.95F7C48AD2@hg.openjdk.java.net> Changeset: bad8f5237f10 Author: darcy Date: 2013-05-15 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bad8f5237f10 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier) Reviewed-by: alanb ! src/share/classes/java/util/Objects.java From mike.duigou at oracle.com Wed May 15 17:02:27 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 15 May 2013 10:02:27 -0700 Subject: Code review request for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <5193BB6B.6080807@oracle.com> References: <518D601E.6070701@oracle.com> <51923D04.7000308@oracle.com> <5193BB6B.6080807@oracle.com> Message-ID: Looks fine. Mike On May 15 2013, at 09:44 , Joe Darcy wrote: > On 05/14/2013 06:32 AM, Alan Bateman wrote: >> On 10/05/2013 22:01, Joe Darcy wrote: >>> Hello, >>> >>> Please (re)review this change to introduce Objects.requireNonNull(T, Supplier): >>> >>> http://cr.openjdk.java.net/~darcy/8014365.0/ >>> >>> The original change had to be pulled out because of a build issue (8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build); I'll be asking for a review on build-dev of the build-related change in langtools. The test portion of the patch is slightly different than before because of the intervening changes made for >>> >>> 8013712: Add Objects.nonNull and Objects.isNull >> I realize this has already been pushed but just to point out a missing parenthesis on line 272 in the javadoc, needs to be ")}". >> > > Sorry for introduce the javadoc issue. > > Please review this patch > > --- a/src/share/classes/java/util/Objects.java Mon May 13 22:16:55 2013 -0700 > +++ b/src/share/classes/java/util/Objects.java Wed May 15 09:43:16 2013 -0700 > @@ -269,7 +269,7 @@ > * 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}, > + *

                  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 > > and I'll file a bug a push the fix. > > Thanks, > > -Joe From jonathan.gibbons at oracle.com Wed May 15 17:40:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 May 2013 17:40:05 +0000 Subject: hg: jdk8/tl/langtools: 8006879: Detection of windows in sjavac fails. Message-ID: <20130515174013.9F55448AD3@hg.openjdk.java.net> Changeset: 445b8b5ae9f4 Author: jjg Date: 2013-05-15 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/445b8b5ae9f4 8006879: Detection of windows in sjavac fails. Reviewed-by: jjg Contributed-by: erik.joelsson at oracle.com ! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java From dan.xu at oracle.com Wed May 15 18:04:08 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 15 May 2013 11:04:08 -0700 Subject: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies In-Reply-To: <5190E9AF.5090504@oracle.com> References: <518D64A8.1090906@oracle.com> <5190E9AF.5090504@oracle.com> Message-ID: <5193CE18.9030203@oracle.com> On 05/13/2013 06:25 AM, Alan Bateman wrote: > On 10/05/2013 22:20, Dan Xu wrote: >> Hi, >> >> The FileInputStream.available() method can return a negative value >> when the file position is beyond the endof afile. This is an >> unspecified behaviour that has the potential to break applications >> that expect available to return a value of 0 or greater. The >> FileInputStream.skip(long) method allows a negative value as its >> parameter. This conflicts with the specifications of InputStream and >> FileInputStream classes. >> >> They are both long standing behaviours. In the fix, available() has >> been changed to only return 0 or positive values. And for the >> skip(long) method, due to the compatibility concern, its behaviour >> will not be changed. Instead, the related java specs are going to be >> changed to describe its current behaviour. >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=8011136 >> webrev: http://cr.openjdk.java.net/~dxu/8011136/webrev.00/ >> >> Thanks for your review! >> >> -Dan > Thanks for following up on this one. Overall I agree with the > approach, it specifies skip to match long standing behavior and fixes > available to not return negative values. > > Just on wording, it might be better if the new statement in > InputStream.skip didn't start with "But". How about "Subclasses may > ..." as this would be consistent with exiting wording in this class. > > For FileInputStream then the statement on how "available" behaves > should probably move to the available javadoc. Something like "Returns > 0 when the file position is beyond EOF" should be fine. > > -Alan. > > > > Thanks for your review, I have updated wordings in the java doc. The new webrev can be reviewed at http://cr.openjdk.java.net/~dxu/8011136/webrev.01/ . -Dan From huizhe.wang at oracle.com Wed May 15 18:51:09 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 15 May 2013 11:51:09 -0700 Subject: RFR: JDK-8013900: More warnings compiling jaxp. In-Reply-To: <51935871.80500@oracle.com> References: <5190FA78.2060608@oracle.com> <51935871.80500@oracle.com> Message-ID: <5193D91D.6050508@oracle.com> Excellent work, Daniel! The only minor problem for me is that I can't apply the patch directly to jaxp standalone since it uses JDK7 feature. But then we probably don't need to do it after all. Thanks, Joe On 5/15/2013 2:42 AM, Daniel Fuchs wrote: > Hi, > > Please find below a revised version of the fix for > JDK-8013900: More warnings compiling jaxp. > > > Difference with the previous version [1] are in LocalVariableGen.java, > plus 4 additional files: > BranchInstruction.java > CodeExceptionGen.java > LineNumberGen.java > Select.java > > This new set of changes fixes an additional issue I discovered in > LocalVariableGen.java - while running the JCK tests. > > LocalVariableGen had a bug that was hidden by the fact > that hashCode() was not compliant with equals(). > Changing hashCode() to be compliant with equals() uncovered > that issue. > > The issue with LocalVariableGen is that the instance > variables used by equals/hashCode are mutable. > This is an issue because instances of LocalVariableGen are > stored in an HashSet (targeters) held from instances of > InstructionHandle. > > Whenever the instruction handles in LocalVariableGen are changed, > then the instance of LocalVariableGen was removed from the 'old' > instruction handle targeters HashSet, and added to the 'new' > instruction handle targeters HashSet - (see LocalVariableGen > updateTargets(..), LocalVariableGen.setStart(...) & > LocalVariableGen.setEnd(...). > > The issue here was that the instance of LocalVariableGen was > removed from the 'old' instruction handle targeters HashSet > before being modified (which was correct) - but was also > added to the 'new' instruction handle targeters HashSet > before being modified - which was incorrect because at > that time the hashCode() was still computed using the 'old' > instruction handle, and therefore had its 'old' value. > (this was done by BranchInstruction.notifyTarget(...)) > > The fix for this new issue is to split > BranchInstruction.notifyTarget(...) in two methods: > BranchInstruction.notifyTargetChanging(...) which is called > before the instruction handle pointer is changed, and remove > the LocalVariableGen from the old instruction handle targeters > HashSet, and BranchInstruction.notifyTargetChanged(...), which > is called after the instruction handle pointer is changed, > and adds the LocalVariableGen to the new instruction handle > targeters HashSet. > In LocalVariableGen - whenever one of the instruction handles > that take parts in the hashCode computation is changed, we > unregister 'this' from all targeters HashSets in which it > is registered, then modify the instruction handle pointer, > then add back 'this' to all targeters HashSets in which it > needs to be registered. > > The 4 additional files in the webrev were also calling > BranchInstruction.notifyTarget - and I modified them to > call the two new methods instead of the old one - but without > going through the trouble of unregistering 'this' from any > known HashSet before modifictation - and adding it after, > since those other classes do not have mutable hashCode(). > > Note: I also took this opportunity to change the method > calling BranchInstruction.notifyTargetXxxx to be final, as > I think it's desirable that they not be overridden, and to > make the index in LocalVariableGen final - since it was > never changed after the instance construction (and takes > part in the HashCode computation). > > best regards, > > -- daniel > > previous version: > [1] > > On 5/13/13 4:36 PM, Daniel Fuchs wrote: >> This is a fix for JDK-8013900: More warnings compiling jaxp. >> >> >> >> Although the title might suggest a trivial fix, it goes a bit >> beyond a simple warning fix because the root cause of those warnings >> is that some classes redefine equals without redefining >> hashCode() - and devising a hashCode() method that respects >> its contract with equals() is not always trivial. >> >> The proposed fix adds hashCode() methods where necessary, ensuring >> that: >> >> if (o1.equals(o2) == true), then (o1.hashCode() == o2.hashCode()) >> >> The fix also contains some cosmetic/sanity changes - like: >> >> 1. adding @Override wherever NetBeans complained they were >> missing - and >> 2. replacing StringBuffer with StringBuilder when >> possible. >> 3. In one instance, AbstractDateTimeDV.java I also had >> to reformat the whole file (due to its weird original formatting) >> - apologies for the noise it causes in the webrev. >> 4. I also removed a couple of private isEqual(obj1, obj2) methods >> replacing them by calls to Objects.equals(obj1, obj2) which did >> the same thing. >> 5. finally I refactored some of the existing equals (e.g. replacing >> try { (Sometype) other.... } catch (ClassCastException x) { >> return false; } with use of 'other instanceof Sometype'...) >> >> There are however a couple of more serious changes that could >> deserve to be reviewed in more details: >> >> a. The new implementation of hashCode() in >> AbstractDateTimeDV.DateTimeData, where I had to figure >> out a way to convert the date to UTC so that the hashCode() would >> match equals: >> >> AbstractDateTimeDV.java: lines 972-992 >> >> and b. in PrecisionDecimalDV.XPrecisionDecimal - where I had to >> invent a canonical string representation to devise a hashCode that >> would match equals: >> >> PrecisionDecimalDV.java: lines 147-237 >> >> For this last one - I have added a new test in jdk/test to check >> the implementation of the new canonical String representation >> for hashCode() - since the code of that is not trivial. >> >> >> best regards, >> >> -- daniel > From mike.duigou at oracle.com Wed May 15 20:16:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 15 May 2013 13:16:35 -0700 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51933E3A.7060905@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> Message-ID: <9ED34765-1B9A-432E-AC30-EAD1AFA07769@oracle.com> Hi Peter; I tried it on my i7 box and was able to get it to fail right away. I didn't try the previous test on this box so can't say whether it would have also failed. Applying the String changes resolved the issue. I think this one is ready! Mike On May 15 2013, at 00:50 , Peter Levart wrote: > Mike, David, > > Could you try this variant of the test: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.05/ > > > I tried it on 3 different machines (4-core i7 Linux, 8-core sparc T-2 Solaris, 4-core amd64 Solaris) x 2 different JDK8 JVMs (64bit and 32bit) and it fails immediately on all 6 of them. > > Regards, Peter > > On 05/14/2013 05:39 PM, Mike Duigou wrote: >> Good to see the test added. I was also unable to reproduce the failure on my Core 2 Duo Mac laptop but the test and fix match up. >> >> Mike >> >> >> On May 14 2013, at 04:34 , Peter Levart wrote: >> >>> On 05/14/2013 01:17 PM, David Holmes wrote: >>>> Thanks Peter this looks good to me. >>>> >>>> One minor thing please set the correct copyright year in the test, it should just be >>>> >>>> Copyright (c) 2013, Oracle ... >>> Ok, fixed: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ >>> >>> >>>> I couldn't get the test to actually fail, but I can see that it could. >>> Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails immediately and always. You could try varying the number of concurrent threads and or the time to wait for exception to be thrown... >>> >>>> David >>>> >>>> On 14/05/2013 9:04 PM, Peter Levart wrote: >>>>> Ok, here's the corrected fix: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>>>> >>>>> I also added a reproducer for the bug. >>>>> >>>>> Regards, peter >>>>> >>>>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>>>> Right, sb.length() should be used. I will correct that as soon as I >>>>>> get to the keyboard. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On May 14, 2013 7:22 AM, "David Holmes" >>>>> > wrote: >>>>>> >>>>>> Thanks Peter! I've filed >>>>>> >>>>>> 8014477 >>>>>> Race condition in String.contentEquals when comparing with >>>>>> StringBuffer >>>>>> >>>>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>>>> >>>>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>>>> >>>>>> I noticed a synchronization bug in String.contentEquals >>>>>> method. If >>>>>> called with a StringBuffer argument while concurrent thread is >>>>>> modifying the StringBuffer, the method can either throw >>>>>> ArrayIndexOutOfBoundsException or return true even though >>>>>> the content >>>>>> of the StringBuffer has never been the same as the String's. >>>>>> >>>>>> Here's a proposed patch: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> Or even better (with some code clean-up): >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>>>> >>>>>> >>>>>> >>>>>> This part is not correct I believe: >>>>>> >>>>>> 1010 private boolean >>>>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>>>> 1011 char v1[] = value; >>>>>> 1012 char v2[] = sb.getValue(); >>>>>> 1013 int n = v1.length; >>>>>> 1014 if (n != v2.length) { >>>>>> 1015 return false; >>>>>> 1016 } >>>>>> >>>>>> v2 can be larger than v1 if v2 is not being fully used (ie count < >>>>>> length). >>>>>> >>>>>> David >>>>>> ----- >>>>>> > From ivan.gerasimov at oracle.com Wed May 15 21:19:39 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 16 May 2013 01:19:39 +0400 Subject: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call In-Reply-To: <5193B902.20009@oracle.com> References: <5193AC82.7010902@oracle.com> <5193B902.20009@oracle.com> Message-ID: <5193FBEB.5090404@oracle.com> Hello Sherman! On 15.05.2013 20:34, Xueming Shen wrote: > public long skip(long n) throws IOException { > - byte[] buf = new byte[512]; > + if (tmpbuf == null) { > + tmpbuf = new byte[512]; > + } > long total = 0; > while (total < n) { > long len = n - total; > - len = read(buf, 0, len < buf.length ? (int)len : > buf.length); > + len = read(buf, 0, len < tmpbuf.length ? (int)len : > tmpbuf.length); > if (len == -1) { > return total; > } > total += len; > } > > Shouldn't the first param "buf" to be "tmpbuf" as well at ln#104, > otherwise I guess > it will not pass the compiler? > Of course you're right! I should have waited for the compilation to finish before posting the message. Here's the updated webrev: http://cr.openjdk.java.net/~dmeetry/8014657/webrev.1/ Thanks, Ivan > -Sherman > > On 05/15/2013 08:40 AM, Ivan Gerasimov wrote: >> Hello! >> >> Please have a chance to review a simple change proposal. >> >> CheckedInputStream.skip() allocates temporary buffer on every call. >> It's suggested to have a temporary buffer that is initialized on the >> first use and can be reused during subsequent calls to the skip() >> function. >> Many other input streams already use the same approach. >> >> http://cr.openjdk.java.net/~dmeetry/8014657/webrev.0/ >> >> >> Sincerely, >> Ivan > > > From jim.gish at oracle.com Wed May 15 21:19:52 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 15 May 2013 17:19:52 -0400 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <51805E1D.9060504@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> <51805E1D.9060504@oracle.com> Message-ID: <5193FBF8.6010605@oracle.com> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ This is an update to the previous webrev. This is a temporary fix to workaround a regression that causes Glassfish 4.0 to fail to startup. A proper fix will be investigated. Thanks, Jim On 04/30/2013 08:13 PM, Jim Gish wrote: > Here's an update: > http://cr.openjdk.java.net/~jgish/TestRB.3/ > > > Thanks, > Jim > > On 04/30/2013 05:10 PM, Jim Gish wrote: >> >> 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 naoto.sato at oracle.com Wed May 15 23:49:20 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 15 May 2013 23:49:20 +0000 Subject: hg: jdk8/tl/jdk: 8013233: java/util/Locale/LocaleProviders.sh fails Message-ID: <20130515234940.4A42048AE0@hg.openjdk.java.net> Changeset: 3d9f25dc630c Author: naoto Date: 2013-05-15 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d9f25dc630c 8013233: java/util/Locale/LocaleProviders.sh fails Reviewed-by: okutsu ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From mike.duigou at oracle.com Thu May 16 01:17:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 15 May 2013 18:17:20 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 Message-ID: Hello all; This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). Thanks, Mike From valerie.peng at oracle.com Thu May 16 01:43:12 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 16 May 2013 01:43:12 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130516014410.ECFD148AE4@hg.openjdk.java.net> Changeset: 2ec31660cc0e Author: valeriep Date: 2013-05-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ec31660cc0e 8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be protected Summary: Change the finalize method of PKCS11 class to be protected. Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 991420add35d Author: valeriep Date: 2013-05-07 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/991420add35d 7196009: SunPkcs11 provider fails to parse config path containing parenthesis Summary: Enhanced to allow quoted string as library path values. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspQuotedPath.cfg Changeset: 804da1e9bd04 Author: ascarpino Date: 2013-05-07 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/804da1e9bd04 8001284: Buffer problems with SunPKCS11-Solaris and CKM_AES_CTR Summary: Changed output length calculation to include incomplete blocks for CTR mode. Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: fc70416beef3 Author: valeriep Date: 2013-05-13 16:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc70416beef3 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 59357ea7f131 Author: valeriep Date: 2013-05-15 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59357ea7f131 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java From joe.darcy at oracle.com Thu May 16 02:09:34 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 15 May 2013 19:09:34 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: References: Message-ID: <51943FDE.5030009@oracle.com> Hi Mike, Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? -Joe On 5/15/2013 6:17 PM, Mike Duigou wrote: > Hello all; > > This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. > > http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ > > I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. > > I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. > > Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. > > We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). > > Thanks, > > Mike From mandy.chung at oracle.com Thu May 16 02:46:22 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 May 2013 19:46:22 -0700 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <5193FBF8.6010605@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> <51805E1D.9060504@oracle.com> <5193FBF8.6010605@oracle.com> Message-ID: <5194487E.9090008@oracle.com> On 5/15/2013 2:19 PM, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ Looks fine. This fix gets the Glassfish to run on jdk8 as an interim fix while allowing us to investigate a proper solution for jdk8. Daniel mentioned the performance overhead of Reflection.getCallerClass() offline that does incur some overhead. Applications that create logger with no resource bundle likely call Logger.getLogger(String name) instead of Logger.getLogger(String name, String rbname). In other words, when Logger.getLogger(name, rbname) is called, it's likely that rbname is non-null. It might incur some performance overhead to applications who resource bundle is visible to TCCL or system class loader as Logger.getLogger(String, String) always obtains the immediate caller but not used. In Glassfish and OSGi environment, there is no performance issue since it has been doing the stack walk in the past. I think it's fine as it is. Nits: L1639, 1712 - better to align with the line above. Thanks for extending the test to cover various cases. Thanks Mandy > This is an update to the previous webrev. This is a temporary fix to > workaround a regression that causes Glassfish 4.0 to fail to startup. > A proper fix will be investigated. > > Thanks, > Jim > > On 04/30/2013 08:13 PM, Jim Gish wrote: >> Here's an update: >> http://cr.openjdk.java.net/~jgish/TestRB.3/ >> >> >> Thanks, >> Jim >> >> On 04/30/2013 05:10 PM, Jim Gish wrote: >>> >>> 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. >>> >> > From david.holmes at oracle.com Thu May 16 04:08:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 14:08:18 +1000 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51933E3A.7060905@gmail.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> Message-ID: <51945BB2.3010600@oracle.com> Okay mea culpa - I was testing on the wrong JDK. I wrongly assumed this would impact 7 as well but it doesn't as the bug was introduced with the changes in 6914123. Sorry about that. Good to go. Has anyone offered to sponsor this yet? David ----- On 15/05/2013 5:50 PM, Peter Levart wrote: > Mike, David, > > Could you try this variant of the test: > > http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.05/ > > > I tried it on 3 different machines (4-core i7 Linux, 8-core sparc T-2 > Solaris, 4-core amd64 Solaris) x 2 different JDK8 JVMs (64bit and 32bit) > and it fails immediately on all 6 of them. > > Regards, Peter > > On 05/14/2013 05:39 PM, Mike Duigou wrote: >> Good to see the test added. I was also unable to reproduce the failure >> on my Core 2 Duo Mac laptop but the test and fix match up. >> >> Mike >> >> >> On May 14 2013, at 04:34 , Peter Levart wrote: >> >>> On 05/14/2013 01:17 PM, David Holmes wrote: >>>> Thanks Peter this looks good to me. >>>> >>>> One minor thing please set the correct copyright year in the test, >>>> it should just be >>>> >>>> Copyright (c) 2013, Oracle ... >>> Ok, fixed: >>> >>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ >>> >>> >>> >>>> I couldn't get the test to actually fail, but I can see that it could. >>> Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails >>> immediately and always. You could try varying the number of >>> concurrent threads and or the time to wait for exception to be thrown... >>> >>>> David >>>> >>>> On 14/05/2013 9:04 PM, Peter Levart wrote: >>>>> Ok, here's the corrected fix: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>>>> >>>>> >>>>> I also added a reproducer for the bug. >>>>> >>>>> Regards, peter >>>>> >>>>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>>>> Right, sb.length() should be used. I will correct that as soon as I >>>>>> get to the keyboard. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On May 14, 2013 7:22 AM, "David Holmes" >>>>> > wrote: >>>>>> >>>>>> Thanks Peter! I've filed >>>>>> >>>>>> 8014477 >>>>>> Race condition in String.contentEquals when comparing with >>>>>> StringBuffer >>>>>> >>>>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>>>> >>>>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>>>> >>>>>> I noticed a synchronization bug in String.contentEquals >>>>>> method. If >>>>>> called with a StringBuffer argument while concurrent >>>>>> thread is >>>>>> modifying the StringBuffer, the method can either throw >>>>>> ArrayIndexOutOfBoundsException or return true even though >>>>>> the content >>>>>> of the StringBuffer has never been the same as the >>>>>> String's. >>>>>> >>>>>> Here's a proposed patch: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> Or even better (with some code clean-up): >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This part is not correct I believe: >>>>>> >>>>>> 1010 private boolean >>>>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>>>> 1011 char v1[] = value; >>>>>> 1012 char v2[] = sb.getValue(); >>>>>> 1013 int n = v1.length; >>>>>> 1014 if (n != v2.length) { >>>>>> 1015 return false; >>>>>> 1016 } >>>>>> >>>>>> v2 can be larger than v1 if v2 is not being fully used (ie >>>>>> count < >>>>>> length). >>>>>> >>>>>> David >>>>>> ----- >>>>>> > From david.holmes at oracle.com Thu May 16 04:15:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 14:15:35 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> Message-ID: <51945D67.3070000@oracle.com> On 16/05/2013 12:36 AM, Mario Torre wrote: > 2013/5/15 Remi Forax : >> On 05/15/2013 10:39 AM, Martin Desruisseaux wrote: >>> >>> Le 15/05/13 10:05, David Holmes a ?crit : >>>> >>>> There is a huge difference between blowing away a complete process with >>>> kill and having a single thread starting to propagate an async exception, >>>> unwinding its stack and executing finally blocks with completely broken >>>> state invariants. >>> >>> >>> Given the risk, what about a mechanism similar to the one which currently >>> hides the Sun internal packages from the compilation phase but not yet from >>> the runtime phase? Would it be acceptable to have 'javac' and 'javadoc' >>> woking as if the 'Thread.stop(Throwable)' method did not existed anymore, >>> while having the method still working (for now) at runtime for existing >>> libraries? Maybe with an annotation yet stronger than @Deprecated. >>> >>> Martin >>> >> >> yes, I propose @Retired. > > +1 > > I think it should also blow at runtime unless people passes some fancy > argument (like -XX:recallRetired :), this way is easier for people to > fix their code, or, in case they can't, do workaround it. Interesting suggestions but I for one do not think that after 15 years of deprecation we need to go to such lengths to keep stop(Throwable) on life-support - it is @Deceased in my opinion :) Cheers, David ----- > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From david.holmes at oracle.com Thu May 16 04:30:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 14:30:57 +1000 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <51936C70.8030806@oracle.com> References: <5193510F.8060809@oracle.com> <5193577C.9030802@oracle.com> <51936C70.8030806@oracle.com> Message-ID: <51946101.7010409@oracle.com> Hi Eric, Cleanup of threads looks good. The synchronization between waitForDump and finishDump is a bit dodgy but that is a different issue. Cheers, David On 15/05/2013 9:07 PM, Eric Wang wrote: > On 2013/5/15 17:38, Alan Bateman wrote: >> On 15/05/2013 10:10, Eric Wang wrote: >>> Hi, >>> >>> Please help to review the fix for bug 8004177 >>> and 8004178 >>> , this fix is to make >>> sure all child threads finished before main thread exits. >>> >>> http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ >>> >>> >>> For 8004178, the test StackTraces.java is same as >>> GenerifyStackTraces.java, so just remove it. >>> >>> Thanks, >>> Eric >> It's good to have fix this test so that it doesn't leave a thread >> behind (in this case slowing down the execution of subsequent tests by >> taking thread dumps every 2 seconds) >> >> The change you propose is okay but a bit odd to have ThreadOne signal >> DumpThread to shutdown. An alternative would be to have the main >> thread signal DumpThread, as in: >> >> one.join(); >> >> finished = true; >> dt.join(); >> >> Better still might be to move the flag into the DumpThread class and >> have it define a shutdown method so the main thread does: >> >> one.join(); >> >> dt.shutdown(); >> dt.join(); >> >> I think that would be a bit cleaner. >> >> -Alan. >> >> >> > Hi Alan, > > Thanks for the suggestion, I have updated the fix again, Can you please > help to take a look? > http://cr.openjdk.java.net/~ewang/8004177/webrev.01/ > > > Regards, > Eric From yiming.wang at oracle.com Thu May 16 04:52:03 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 16 May 2013 12:52:03 +0800 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <51946101.7010409@oracle.com> References: <5193510F.8060809@oracle.com> <5193577C.9030802@oracle.com> <51936C70.8030806@oracle.com> <51946101.7010409@oracle.com> Message-ID: <519465F3.7090906@oracle.com> Hi David, Thanks for review this issue, i'll file another bug to track this. Regards, Eric On 2013/5/16 12:30, David Holmes wrote: > Hi Eric, > > Cleanup of threads looks good. > > The synchronization between waitForDump and finishDump is a bit dodgy > but that is a different issue. > > Cheers, > David > > On 15/05/2013 9:07 PM, Eric Wang wrote: >> On 2013/5/15 17:38, Alan Bateman wrote: >>> On 15/05/2013 10:10, Eric Wang wrote: >>>> Hi, >>>> >>>> Please help to review the fix for bug 8004177 >>>> and 8004178 >>>> , this fix is to make >>>> sure all child threads finished before main thread exits. >>>> >>>> http://cr.openjdk.java.net/~ewang/8004177/webrev.00/ >>>> >>>> >>>> For 8004178, the test StackTraces.java is same as >>>> GenerifyStackTraces.java, so just remove it. >>>> >>>> Thanks, >>>> Eric >>> It's good to have fix this test so that it doesn't leave a thread >>> behind (in this case slowing down the execution of subsequent tests by >>> taking thread dumps every 2 seconds) >>> >>> The change you propose is okay but a bit odd to have ThreadOne signal >>> DumpThread to shutdown. An alternative would be to have the main >>> thread signal DumpThread, as in: >>> >>> one.join(); >>> >>> finished = true; >>> dt.join(); >>> >>> Better still might be to move the flag into the DumpThread class and >>> have it define a shutdown method so the main thread does: >>> >>> one.join(); >>> >>> dt.shutdown(); >>> dt.join(); >>> >>> I think that would be a bit cleaner. >>> >>> -Alan. >>> >>> >>> >> Hi Alan, >> >> Thanks for the suggestion, I have updated the fix again, Can you please >> help to take a look? >> http://cr.openjdk.java.net/~ewang/8004177/webrev.01/ >> >> >> Regards, >> Eric From neugens.limasoftware at gmail.com Thu May 16 07:44:25 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 16 May 2013 09:44:25 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <51945D67.3070000@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> Message-ID: 2013/5/16 David Holmes : >> +1 >> >> I think it should also blow at runtime unless people passes some fancy >> argument (like -XX:recallRetired :), this way is easier for people to >> fix their code, or, in case they can't, do workaround it. > > > Interesting suggestions but I for one do not think that after 15 years of > deprecation we need to go to such lengths to keep stop(Throwable) on > life-support - it is @Deceased in my opinion :) > Hi David, In fact, I fully agree for Thread.stop we should probably just do as you suggest and kill it :) but my interest shifted to the @Retired annotation which could be a nice general thing to have (Thread.stop could actually be a test case for it). Ideally, by Java 9, we could go through most of the @Deprecated and convert them to @Retired and give one platform lifetime to make people adjust their code. Java 10 could be finally free of all those ancient vestiges of a glorious past :) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From peter.levart at gmail.com Thu May 16 08:02:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 16 May 2013 10:02:12 +0200 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51945BB2.3010600@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> <51945BB2.3010600@oracle.com> Message-ID: <51949284.9070608@gmail.com> Hi, Right, the test calls the correctly synchronized method in JDK7. The fix for 6914123 in JDK8 moves synchronization to the other method (the one taking CharSequence as parameter type), so in JDK8 it doesn't matter which method is called, but in JDK7 it makes a difference. The same test could be modified to call the unsynchronized method in JDK7 (by casting StringBuffer to CharSequence) in case a backport to JDK7 is attempted, but for JDK8 it is good as it is. Regards, Peter On 05/16/2013 06:08 AM, David Holmes wrote: > Okay mea culpa - I was testing on the wrong JDK. I wrongly assumed > this would impact 7 as well but it doesn't as the bug was introduced > with the changes in 6914123. > > Sorry about that. > > Good to go. Has anyone offered to sponsor this yet? > > David > ----- > > On 15/05/2013 5:50 PM, Peter Levart wrote: >> Mike, David, >> >> Could you try this variant of the test: >> >> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.05/ >> >> >> >> I tried it on 3 different machines (4-core i7 Linux, 8-core sparc T-2 >> Solaris, 4-core amd64 Solaris) x 2 different JDK8 JVMs (64bit and 32bit) >> and it fails immediately on all 6 of them. >> >> Regards, Peter >> >> On 05/14/2013 05:39 PM, Mike Duigou wrote: >>> Good to see the test added. I was also unable to reproduce the failure >>> on my Core 2 Duo Mac laptop but the test and fix match up. >>> >>> Mike >>> >>> >>> On May 14 2013, at 04:34 , Peter Levart wrote: >>> >>>> On 05/14/2013 01:17 PM, David Holmes wrote: >>>>> Thanks Peter this looks good to me. >>>>> >>>>> One minor thing please set the correct copyright year in the test, >>>>> it should just be >>>>> >>>>> Copyright (c) 2013, Oracle ... >>>> Ok, fixed: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.04/ >>>> >>>> >>>> >>>> >>>>> I couldn't get the test to actually fail, but I can see that it >>>>> could. >>>> Hm, do you have a multi-core chip? On my computer (i7 CPU) it fails >>>> immediately and always. You could try varying the number of >>>> concurrent threads and or the time to wait for exception to be >>>> thrown... >>>> >>>>> David >>>>> >>>>> On 14/05/2013 9:04 PM, Peter Levart wrote: >>>>>> Ok, here's the corrected fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.03/ >>>>>> >>>>>> >>>>>> >>>>>> I also added a reproducer for the bug. >>>>>> >>>>>> Regards, peter >>>>>> >>>>>> On 05/14/2013 07:53 AM, Peter Levart wrote: >>>>>>> Right, sb.length() should be used. I will correct that as soon as I >>>>>>> get to the keyboard. >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> On May 14, 2013 7:22 AM, "David Holmes" >>>>>> > wrote: >>>>>>> >>>>>>> Thanks Peter! I've filed >>>>>>> >>>>>>> 8014477 >>>>>>> Race condition in String.contentEquals when comparing with >>>>>>> StringBuffer >>>>>>> >>>>>>> On 14/05/2013 8:34 AM, Peter Levart wrote: >>>>>>> >>>>>>> On 05/14/2013 12:09 AM, Peter Levart wrote: >>>>>>> >>>>>>> I noticed a synchronization bug in String.contentEquals >>>>>>> method. If >>>>>>> called with a StringBuffer argument while concurrent >>>>>>> thread is >>>>>>> modifying the StringBuffer, the method can either throw >>>>>>> ArrayIndexOutOfBoundsException or return true even >>>>>>> though >>>>>>> the content >>>>>>> of the StringBuffer has never been the same as the >>>>>>> String's. >>>>>>> >>>>>>> Here's a proposed patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> Or even better (with some code clean-up): >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This part is not correct I believe: >>>>>>> >>>>>>> 1010 private boolean >>>>>>> nonSyncContentEquals(AbstractStringBuilder sb) { >>>>>>> 1011 char v1[] = value; >>>>>>> 1012 char v2[] = sb.getValue(); >>>>>>> 1013 int n = v1.length; >>>>>>> 1014 if (n != v2.length) { >>>>>>> 1015 return false; >>>>>>> 1016 } >>>>>>> >>>>>>> v2 can be larger than v1 if v2 is not being fully used (ie >>>>>>> count < >>>>>>> length). >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >> From peter.levart at gmail.com Thu May 16 08:57:53 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 16 May 2013 10:57:53 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> Message-ID: <51949F91.60005@gmail.com> On 05/16/2013 09:44 AM, Mario Torre wrote: > 2013/5/16 David Holmes : > >>> +1 >>> >>> I think it should also blow at runtime unless people passes some fancy >>> argument (like -XX:recallRetired :), this way is easier for people to >>> fix their code, or, in case they can't, do workaround it. >> >> Interesting suggestions but I for one do not think that after 15 years of >> deprecation we need to go to such lengths to keep stop(Throwable) on >> life-support - it is @Deceased in my opinion :) >> > Hi David, > > In fact, I fully agree for Thread.stop we should probably just do as > you suggest and kill it :) but my interest shifted to the @Retired > annotation which could be a nice general thing to have (Thread.stop > could actually be a test case for it). > > Ideally, by Java 9, we could go through most of the @Deprecated and > convert them to @Retired and give one platform lifetime to make people > adjust their code. Java 10 could be finally free of all those ancient > vestiges of a glorious past :) > > Cheers, > Mario Hi, Since developers are by definition lazy (at least the Perl ones ;-), aren't you afraid that in order to move from JDK N to JDK N+1, they might "quickly fix" references to @Retired methods by using reflection? Regards, Peter > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From Alan.Bateman at oracle.com Thu May 16 09:04:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 10:04:16 +0100 Subject: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call In-Reply-To: <5193FBEB.5090404@oracle.com> References: <5193AC82.7010902@oracle.com> <5193B902.20009@oracle.com> <5193FBEB.5090404@oracle.com> Message-ID: <5194A110.7000403@oracle.com> On 15/05/2013 22:19, Ivan Gerasimov wrote: > : > > Of course you're right! > I should have waited for the compilation to finish before posting the > message. > Here's the updated webrev: > http://cr.openjdk.java.net/~dmeetry/8014657/webrev.1/ > The updated webrev looks okay to me. So have you done much testing with this and do you have any performance data to share? -Alan From Alan.Bateman at oracle.com Thu May 16 09:07:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 10:07:20 +0100 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <51945BB2.3010600@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> <51945BB2.3010600@oracle.com> Message-ID: <5194A1C8.20009@oracle.com> On 16/05/2013 05:08, David Holmes wrote: > Okay mea culpa - I was testing on the wrong JDK. I wrongly assumed > this would impact 7 as well but it doesn't as the bug was introduced > with the changes in 6914123. > > Sorry about that. > > Good to go. Has anyone offered to sponsor this yet? It looks good to me too and it's great that Peter spotted this (as it could have lurked for a long time without anyone noticing it). Since you've been testing with it then it might be simplest if you sponsored it (assuming you have the time of course). -Alan From xuelei.fan at oracle.com Thu May 16 09:08:43 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 16 May 2013 17:08:43 +0800 Subject: Code review request, JDK-8010814, More buffers are stored or returned without cloning Message-ID: <5194A21B.2000906@oracle.com> Hi, There is another fix to avoid the use of mutable objects. webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ Thanks, Xuelei From Alan.Bateman at oracle.com Thu May 16 09:10:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 10:10:50 +0100 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <51936C70.8030806@oracle.com> References: <5193510F.8060809@oracle.com> <5193577C.9030802@oracle.com> <51936C70.8030806@oracle.com> Message-ID: <5194A29A.4000404@oracle.com> On 15/05/2013 12:07, Eric Wang wrote: >> > Hi Alan, > > > Thanks for the suggestion, I have updated the fix again, Can you > please help to take a look? > http://cr.openjdk.java.net/~ewang/8004177/webrev.01/ > Updated webrev looks good to me. Minor nit is that you are missing a spec in "}finally " at line 55. I think Chris offered to sponsored this one and it would be good to get it in as this thread is taking cycles from other tests that run subsequently in the same VM. -Alan. From chris.hegarty at oracle.com Thu May 16 09:16:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 May 2013 10:16:15 +0100 Subject: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up In-Reply-To: <5194A29A.4000404@oracle.com> References: <5193510F.8060809@oracle.com> <5193577C.9030802@oracle.com> <51936C70.8030806@oracle.com> <5194A29A.4000404@oracle.com> Message-ID: <5194A3DF.6090300@oracle.com> On 05/16/2013 10:10 AM, Alan Bateman wrote: > On 15/05/2013 12:07, Eric Wang wrote: >>> >> Hi Alan, >> >> >> Thanks for the suggestion, I have updated the fix again, Can you >> please help to take a look? >> http://cr.openjdk.java.net/~ewang/8004177/webrev.01/ >> > Updated webrev looks good to me. Minor nit is that you are missing a > spec in "}finally " at line 55. Yes, I noticed this too. I'll fix it before pushing. -Chris. > I think Chris offered to sponsored this one and it would be good to get > it in as this thread is taking cycles from other tests that run > subsequently in the same VM. > > -Alan. From weijun.wang at oracle.com Thu May 16 09:22:34 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 16 May 2013 17:22:34 +0800 Subject: Code review request, JDK-8010814, More buffers are stored or returned without cloning In-Reply-To: <5194A21B.2000906@oracle.com> References: <5194A21B.2000906@oracle.com> Message-ID: <5194A55A.9070204@oracle.com> Hi Xuelei I'm busy on something else, so probably have no time (or cannot concentrate) to read in details. In my opinion, there are several cases as to whether to clone or not: 1. MUST NOT clone, because the value must be shared so that change at one side appears on the other side. 2. MUST clone, public available methods that leads to security issues. 3. So so, although public methods, cannot be used to do bad things. 4. Not an issue. Internal methods. In the patch, are the first two cases #1 or #3. Sorry I also have no time to read JDK-8010814, More buffers are stored or returned without cloning http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ but I am not sure if those env cases belong to #1. Thanks Max On 5/16/13 5:08 PM, Xuelei Fan wrote: > Hi, > > There is another fix to avoid the use of mutable objects. > > webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ > > Thanks, > Xuelei > From xuelei.fan at oracle.com Thu May 16 09:52:19 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 16 May 2013 17:52:19 +0800 Subject: Code review request, JDK-8010814, More buffers are stored or returned without cloning In-Reply-To: <5194A55A.9070204@oracle.com> References: <5194A21B.2000906@oracle.com> <5194A55A.9070204@oracle.com> Message-ID: <5194AC53.2070805@oracle.com> On 5/16/2013 5:22 PM, Weijun Wang wrote: > Hi Xuelei > > I'm busy on something else, so probably have no time (or cannot > concentrate) to read in details. > Not urgent fix, so please review these request only when you available. > In my opinion, there are several cases as to whether to clone or not: > > 1. MUST NOT clone, because the value must be shared so that change at > one side appears on the other side. > > 2. MUST clone, public available methods that leads to security issues. > > 3. So so, although public methods, cannot be used to do bad things. > > 4. Not an issue. Internal methods. > > In the patch, are the first two cases #1 or #3. > It's #2. For #1 and #3, I added a few comment lines in 8010815. > Sorry I also have no time to read > > JDK-8010814, More buffers are stored or returned without cloning > http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ > > but I am not sure if those env cases belong to #1. > I think both fixes are for #2. Xuelei > Thanks > Max > > > On 5/16/13 5:08 PM, Xuelei Fan wrote: >> Hi, >> >> There is another fix to avoid the use of mutable objects. >> >> webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ >> >> Thanks, >> Xuelei >> From david.holmes at oracle.com Thu May 16 09:54:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 19:54:03 +1000 Subject: bug 8014477 Race in String.contentEquals In-Reply-To: <5194A1C8.20009@oracle.com> References: <518C8DCF.4010909@oracle.com> <517204E1-F040-42E4-AC1B-9FD0EFA8C162@oracle.com> <51909249.6060506@oracle.com> <51913992.9030106@oracle.com> <5191648B.6010905@gmail.com> <51916A5D.7060203@gmail.com> <5191CA17.1080706@oracle.com> <51921A49.3030900@gmail.com> <51921D58.5010700@oracle.com> <51922138.4050909@gmail.com> <51933E3A.7060905@gmail.com> <51945BB2.3010600@oracle.com> <5194A1C8.20009@oracle.com> Message-ID: <5194ACBB.1070601@oracle.com> On 16/05/2013 7:07 PM, Alan Bateman wrote: > On 16/05/2013 05:08, David Holmes wrote: >> Okay mea culpa - I was testing on the wrong JDK. I wrongly assumed >> this would impact 7 as well but it doesn't as the bug was introduced >> with the changes in 6914123. >> >> Sorry about that. >> >> Good to go. Has anyone offered to sponsor this yet? > It looks good to me too and it's great that Peter spotted this (as it > could have lurked for a long time without anyone noticing it). Since > you've been testing with it then it might be simplest if you sponsored > it (assuming you have the time of course). Okay I will sponsor this. I'll run it through JPRT and push. David > -Alan From david.holmes at oracle.com Thu May 16 10:03:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 20:03:00 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> Message-ID: <5194AED4.1090101@oracle.com> On 16/05/2013 6:19 PM, Chris Kirk wrote: > > Dropping some of the accrued baggage would be good. Java has gone an > incredible distance without having a clear out. I for one believe that > it deserves one. > > The way that @Retired is being proposed to being used makes me think > that I misunderstand the intent of @Deprecated. Doesn't @Deprecated > mean, move off of this class/method. It has been superseded here are > some notes on what has replaced it. We intend to remove it at some point > in the future. If you ignore this warning then you risk having your > program break in an upgrade of the library. Yes - I don't think we need @Retired as a stepping stone between @Deprecated and gone. But to date @Deprecated's notion of "some point in the future" is a future yet to materialize. :( But that more general debate deserves it's own thread. Cheers, David > > > > > > > Interesting suggestions but I for one do not think that after 15 > years of > > deprecation we need to go to such lengths to keep stop(Throwable) on > > life-support - it is @Deceased in my opinion :) > > > > Hi David, > > In fact, I fully agree for Thread.stop we should probably just do as > you suggest and kill it :) but my interest shifted to the @Retired > annotation which could be a nice general thing to have (Thread.stop > could actually be a test case for it). > > Ideally, by Java 9, we could go through most of the @Deprecated and > convert them to @Retired and give one platform lifetime to make people > adjust their code. Java 10 could be finally free of all those ancient > vestiges of a glorious past :) > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > From chris.hegarty at oracle.com Thu May 16 10:06:05 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 16 May 2013 10:06:05 +0000 Subject: hg: jdk8/tl/jdk: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Message-ID: <20130516100639.24F4548AF8@hg.openjdk.java.net> Changeset: bb01cc14223c Author: ewang Date: 2013-05-16 10:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb01cc14223c 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Reviewed-by: alanb, dholmes, chegar ! test/java/lang/Thread/GenerifyStackTraces.java - test/java/lang/Thread/StackTraces.java From david.holmes at oracle.com Thu May 16 10:10:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 20:10:09 +1000 Subject: What's the correct repository on which to base changes to "jdk"? In-Reply-To: <34A16738-0F98-4C05-99DA-E19F3530F8F1@oracle.com> References: <38D4CAF9-3EA0-4FAC-B6AA-44510CDDDD3C@oracle.com> <51939F02.5040308@oracle.com> <34A16738-0F98-4C05-99DA-E19F3530F8F1@oracle.com> Message-ID: <5194B081.1030809@oracle.com> Just to clarify - you can't actually push it as you are not a jdk8 Committer. You will need a sponsor. David On 16/05/2013 1:39 AM, David Chase wrote: > Thanks, I'll bring it up to date. > > On 2013-05-15, at 10:43 AM, Alan Bateman wrote: >> The core-libs-dev is best for the java.util.zip code. >> >> You can push changes to the zip code via any of the integration forests but I think it would be best if you used jdk8/tl/jdk as that is the route for all changes to the "core" libraries. >> >> -Alan > From alexey.utkin at oracle.com Thu May 16 10:11:36 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 16 May 2013 14:11:36 +0400 Subject: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.1) In-Reply-To: <5190FC54.8050808@oracle.com> References: <518A88B1.3060105@oracle.com> <5190FC54.8050808@oracle.com> Message-ID: <5194B0D8.2040607@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-7147084 http://bugs.sun.com/view_bug.do?bug_id=7147084 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/ Summary for v1 changes: -- The set of handles that need to restore the inherit flag was extended by child process IOE handles. That was done to avoid "greedy sibling" problem for the file handles. The file handles are closed outside the synchronized block. -- "Greedy sibling" problem is covered by the [test/java/lang/ProcessBuilder/SiblingIOEHandle.java] test. -- The fact that the set of current process standard IOE handles and the set of child process IOE handles can intersect was taken into account. -- The [test/java/lang/ProcessBuilder/InheritIOEHandle.java] was changed in accordance with Martin's concern. Warning! Bugs 7147084 and 6921885 have visible impact for IDE's functionality. If they have a "hint" for the problem, the "hint" may produce the "regression". Regards, -uta On 5/13/2013 6:44 PM, Alexey Utkin wrote: > Thanks, Martin! > > You are right. The approach > > private static String JAVA_EXE = System.getProperty("java.home") > + File.separator + "bin" > + File.separator + "java"; > > private static String[] getCommandArray(String processName) { > String[] cmdArray = { > JAVA_EXE, > "-cp", > System.getProperty("java.class.path"), > InheritIOEHandle.class.getName(), > processName > }; > return cmdArray; > } > > is better. There is one more problem with raise-condition for the file > handles. In current edition there is delta when the file handle could > be inherited by the concurrent process. That is not fatal for > read/write, but not good for delete. Synchronized call does not cover > the file.close in finalized block. > > I will prepare new edition soon. > > Regards, > -uta > > > > On 5/8/2013 10:20 PM, Martin Buchholz wrote: >> Alexey, >> Thanks for working on the scary windows process stuff. >> I only have time for superficial review. >> It looks like you know what you're doing. >> >> + String[] cmdArray = { >> + "java", >> + "-cp", >> This looks like it's invoking whatever "java" is on the path. But >> there's no guarantee there is such a java, or that it's the right >> one. Consider invoking the java we're in, as in other jtreg tests >> like IIRC ProcessBuilder/Basic.java > > From Lance.Andersen at oracle.com Thu May 16 10:37:32 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 16 May 2013 06:37:32 -0400 Subject: Code review request, JDK-8010814, More buffers are stored or returned without cloning In-Reply-To: <5194A21B.2000906@oracle.com> References: <5194A21B.2000906@oracle.com> Message-ID: <47AD8E98-7109-4883-B8D8-01D030B272ED@oracle.com> Looks fine Xuelei best Lance On May 16, 2013, at 5:08 AM, Xuelei Fan wrote: > Hi, > > There is another fix to avoid the use of mutable objects. > > webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ > > Thanks, > Xuelei -------------- 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 thomas.schatzl at oracle.com Thu May 16 10:44:46 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 May 2013 12:44:46 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1368446108.2909.29.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> Message-ID: <1368701086.2716.13.camel@cirrus> Hi all, On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: > Hi all, > > I updated the test program and the patch in java.lang.ref.Reference > accordingly. > > As for the problem of reproducibility, in my tests I had a 100% > reproduction rate with the previous version of the test. > > However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as > suggested in some other emails. > > I will report back with a new webrev after some testing on more > platforms as suggested by David. a new webrev for the patch is at http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ Testing: jprt; manual tests with the test program on a jdk with and without the patch on linux 32/64 bit, windows 32/64 bit, and sparc 32/64 bit. The test program showed 100% reproduction of the error without the patch, and 100% fix success with a jdk containing the patch (each multiple tries at that). Note that jprt seems to run all jdk unit tests always anyway. I also fixed the copyright date in java/lang/ref/Reference.java. If this patch is considered acceptable, I need two reviewers as usual (possibly from GC/hsx team and one from jdk), and one sponsor pushing the change. (I am still intent on making Peter the author of the patch as both the change and the test program came from him) I am not even author for the jdk, but can act as a non-Reviewer reviewer for the gc/hsx team. Thanks a lot, Thomas From thomas.schatzl at oracle.com Thu May 16 10:48:36 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 May 2013 12:48:36 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <518D8695.8090204@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> <518D53BC.7050804@gmail.c!> <518D5718.1030903@gmail.com> <518D5E3B.6070706@oracle.! com> <518D8695.8090204@oracle.com> Message-ID: <1368701316.2716.15.camel@cirrus> Hi, On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote: > On 11/05/2013 6:53 AM, Dean Long wrote: > > On 5/10/2013 1:22 PM, Peter Levart wrote: > >> > >> On 05/10/2013 10:08 PM, Peter Levart wrote: > >>> > >>> On 05/10/2013 08:10 PM, Dean Long wrote: > >>>> If you really want to bullet-proof ReferenceHandler (and other > >>>> system threads) against OOME caused by native allocations, > >>>> then don't forget about monitor inflation if there is contention for > >>>> "lock" :-) > > > Right - most C-heap allocation failures in the VM result in an abort but > some will convert to OOME (such as native thread creation related failures). > > Any test that tries to force an OOME at a particular operation is going > to be fragile because you can't know what other allocations might be > needed under the covers. As Peter already discovered it might occur > during the "new" of InterruptedException, or it might happen during the > load/initialization of InterruptedException. So pre-initializing > InterruptedException is probably a wise thing to do. > That means what? Should I file a new CR (against what component?) for that (making InterruptedException a pre-initialized exception)? Thanks, Thomas From ivan.gerasimov at oracle.com Thu May 16 11:18:55 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 16 May 2013 15:18:55 +0400 Subject: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call In-Reply-To: <5194A110.7000403@oracle.com> References: <5193AC82.7010902@oracle.com> <5193B902.20009@oracle.com> <5193FBEB.5090404@oracle.com> <5194A110.7000403@oracle.com> Message-ID: <5194C09F.20805@oracle.com> On 16.05.2013 13:04, Alan Bateman wrote: > On 15/05/2013 22:19, Ivan Gerasimov wrote: >> : >> >> Of course you're right! >> I should have waited for the compilation to finish before posting the >> message. >> Here's the updated webrev: >> http://cr.openjdk.java.net/~dmeetry/8014657/webrev.1/ >> > The updated webrev looks okay to me. So have you done much testing > with this and do you have any performance data to share? > Thanks for the review! No, I haven't done any testing at all (yet.) I'm not sure what can be tested here - is it performance improvement of GC in the case of lots of calls to the skip function? What kind of testing would you suggest? I relied mostly on two things - assumption that one allocation is better than several and the fact that the other input streams use the same approach with reused temporary buffer. Sincerely, Ivan > -Alan > > From xuelei.fan at oracle.com Thu May 16 11:32:05 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 16 May 2013 11:32:05 +0000 Subject: hg: jdk8/tl/jdk: 8010814: More buffers are stored or returned without cloning Message-ID: <20130516113218.341CD48AF9@hg.openjdk.java.net> Changeset: b198389f9da4 Author: xuelei Date: 2013-05-16 04:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b198389f9da4 8010814: More buffers are stored or returned without cloning Reviewed-by: lancea ! src/share/classes/com/sun/jndi/ldap/BerDecoder.java ! src/share/classes/com/sun/jndi/ldap/BerEncoder.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java From Alan.Bateman at oracle.com Thu May 16 12:00:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 13:00:57 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5194AED4.1090101@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> <5194AED4.1090101@oracle.com> Message-ID: <5194CA79.6000004@oracle.com> On 16/05/2013 11:03, David Holmes wrote: > > Yes - I don't think we need @Retired as a stepping stone between > @Deprecated and gone. But to date @Deprecated's notion of "some point > in the future" is a future yet to materialize. :( > > But that more general debate deserves it's own thread. > Yes, this proposal was always likely to start a more bigger discussion and that would be good to have. For this thread then the proposal is simply to scuttle Thread.stop(Throwable), maybe suspend/resume later. I'm not too concerned about jdk tests, we can change them. The only real concern is whether there are any real impact beyond the sleazy usages already mentioned. -Alan From Alan.Bateman at oracle.com Thu May 16 12:13:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 13:13:04 +0100 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <5194487E.9090008@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> <51805E1D.9060504@oracle.com> <5193FBF8.6010605@oracle.com> <5194487E.9090008@oracle.com> Message-ID: <5194CD50.3070707@oracle.com> On 16/05/2013 03:46, Mandy Chung wrote: > On 5/15/2013 2:19 PM, Jim Gish wrote: >> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ > > Looks fine. This fix gets the Glassfish to run on jdk8 as an interim > fix while allowing us to investigate a proper solution for jdk8. > > Daniel mentioned the performance overhead of > Reflection.getCallerClass() offline that does incur some overhead. > Applications that create logger with no resource bundle likely call > Logger.getLogger(String name) instead of Logger.getLogger(String name, > String rbname). In other words, when Logger.getLogger(name, rbname) > is called, it's likely that rbname is non-null. It might incur some > performance overhead to applications who resource bundle is visible to > TCCL or system class loader as Logger.getLogger(String, String) always > obtains the immediate caller but not used. In Glassfish and OSGi > environment, there is no performance issue since it has been doing the > stack walk in the past. I think it's fine as it is. > > Nits: L1639, 1712 - better to align with the line above. > > Thanks for extending the test to cover various cases. > This looks okay to me too and I agree with Mandy's comment about thinking of this as a fix for the short-term. More work will be required to figure out what the right thing to do is and maybe the methods that take a resource bundle name needed to be deprecated in favor of new methods. -Alan From paul.sandoz at oracle.com Thu May 16 14:38:02 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 May 2013 16:38:02 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5194CA79.6000004@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> <5194AED4.1090101@oracle.com> <5194CA79.6000004@oracle.com> Message-ID: On May 16, 2013, at 2:00 PM, Alan Bateman wrote: > On 16/05/2013 11:03, David Holmes wrote: >> >> Yes - I don't think we need @Retired as a stepping stone between @Deprecated and gone. But to date @Deprecated's notion of "some point in the future" is a future yet to materialize. :( >> >> But that more general debate deserves it's own thread. >> > Yes, this proposal was always likely to start a more bigger discussion and that would be good to have. > > For this thread then the proposal is simply to scuttle Thread.stop(Throwable), maybe suspend/resume later. I'm not too concerned about jdk tests, we can change them. The only real concern is whether there are any real impact beyond the sleazy usages already mentioned. > How about doing a search for usages in all the jars on maven central? IMHO it really helps drive the discussions deprecation if we have some empirical data. Paul. From david.r.chase at oracle.com Thu May 16 14:50:30 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 10:50:30 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 Message-ID: webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/ problem: Some applications spend a surprising amount of time computing CRC32s (Not sure I'm supposed to be precise on an open mailing list). Recent Intel architectures provide instructions that might be useful in addressing this. See https://jbs.oracle.com/bugs/browse/JDK-7088419 I turned this into a general attack on performance in Adler32 and CRC32, partly because the bug report was not clear on the size of the problematic inputs. The general approach turned out to be useful, because it's tricky to get the small-case overheads down for the accelerated-instruction version of the code. fix: 1) For CRC32 and Adler32, break out the "small" case (single bytes, and up to around 60-80 bytes) to be computed on the Java side, avoiding JNI overheads. 2) For CRC32 and Adler32, figure out the "combine" operations for the checksum of a concatenated pair of byte sequences, and add fork-join parallelism for large-enough inputs. Tuning this is hard, so large "small" buffer sizes were chosen (< 512K for unaccelerated CRC32, 1MB for Adler32 and accelerated CRC32) to make this a safe optimization. This can be disabled by setting the (not-yet-documented, perhaps wrongly named) property "sun.zip.serialOnly=true". I just now noticed that this is not the case for Adler32; assuming we agree on the existence of this flag and its name, this needs to be added there, too. 3) For Adler32, defer calculation of the actual "Adler" checksum until it is requested. This is an optimization for byte-at-a-time use. 4) For CRC32, use the new-ish PCLMULQDQ instruction (64-bit by 64-bit carryless multiply, yielding a 128-bit result) in the style described in Intel's white paper on using this instruction to compute CRCs. All the constants are different because the CRC32 is bit-reversed from the checksums computed in Intel's paper, but the unrolling is the same, and the fill and drain code is also similar. This is by default enabled whenever CLMUL and AVX features are both present, and can be disabled at the command line with -XX:-UseCLMUL (or -XX:-UseAVX). There is a companion webrev that puts information about the availability of the PCLMULQDQ in 3-operand form into a hidden property: http://cr.openjdk.java.net/~drchase/8014362/webrev.02/ testing: The CRC benchmark test was adjusted to also warm-up the small-stuff case. A new test was written that was designed to exercise all the corner cases of the new Adler32 and CRC32 implementations; byte-at-a-time is compared to byte-at-a-time-not-looking is compared to arrays of bytes is compared to DirectBuffers, at a variety of sizes and alignments designed to exercise combinations of non-empty fill and drain for the Intel-accelerated CRC32, and corner cases for the fork-join code. The new test takes just under 2 minutes on a T1; that seems like it is cutting it close, so I should either trim the test or give it a little more time. Separate C unit tests (not checked in, not sure where to put them) were written to exhaustively test the accelerated code and research its portability to various compilers. problems and justifications: Using our currently specified compilers for building the JDK, the C access to the new Intel intrinsics is not available. This is unfortunately also true of the assemblers paired with our currently specified compilers. ( What IS the specified compiler for building on Linux? Gcc 4.2 on the Mac, if asked for a 16-byte alignment, helpfully tells me that is too big, and it will use 15 instead. This might be an issue on Linux, if 4.2 is the build compiler version there. ) Therefore, the native code for crc32 includes: 1) the C code with intrinsics for the accelerated CRC32 kernel (compilable with gcc 4.6 or clang, and almost compilable with Sun Studio 12.3; it parses and optimizes, but triggers a crash in the back end, which needs to be reported). 2) the 64-bit version of the assembly language, including commented byte sequences for the instructions that the build-specified assemblers do not recognize. 3) the 32-bit version of the assembly language, including commented byte sequences for the instructions that the build-specified assemblers do not recognize. My hope is that the assembly language is temporary, though it is only a modest step higher in abstraction from the C code, which is almost entirely intrinsic calls. If we have to wait for the C compilers, perhaps the assemblers will all become modern enough to handle the instructions by their proper names. I have a small tool that I wrote to automatically generate the asm statement from the output lldb x/i. (Where does such a weird little tool belong?) I tried to use the instruction just as a stand-alone intrinsic (that might be wrapped in unsafe code and called from Java) but that did not yield a performance gain; it only seems to work well if embedded in an unrolled loop with several independent pipelines of computation running, all feeding 128-bit accumulator registers. That is to say, Intel wrote that white paper for a reason, which was to help guide people like me towards happy results. To my knowledge, we don't support compilation to 128-bit wide xmm registers in hotspot, so this approach was unlikely to work. Another possibility is to wrap the entire kernel up as a single 80-instruction intrinsic. This didn't seem like a win to me, and it would require the use of Unsafe code to interface to it. Even then it's not clear it's possible, because the kernel requires that its input be 16-byte aligned. I don't know if the alignment is guaranteed by the garbage collector, and I could not find a way in Unsafe to even get the (temporarily valid) address of a GC-allocated object. It would be helpful to know the address even if it is only probably true, because for fork-join it is helpful to arrange splits so that they land on a 16-byte boundary so that the eventual serial case will (probably) go as fast as possible with empty fill/drain steps. Yet another possibility is to move all of "fastcrc32" (the outer fill and drain code written in C) into a single intrinsic, but that's 208 instructions total (I just looked). Oh yeah, performance improvements. On an Ivy Bridge laptop (2 cores, 2 threads/core), the accelerated CRC without workstealing is 2.5x faster on large inputs, 2x faster at about 512 bytes. Modest amounts of fork-join parallelism (only fork for work 1M or larger if CLMUL present) provide about 1.5x on top of that, for a 3.75x speedup. Fork-join benchmarks pretty well on the Sun T1, T2, T4 series of processors down to somewhat smaller block sizes, but for now I am conservative an use a serial-if-smaller-than setting of 512K. I've observed speedups as high as 13x on a T1 (1(32), dr-evil), 24x on a T2+ ( 4(256), mrspock), and 8x on a T4 (8(64), sc11d1901). Parallel performance is a little harder to reason about on big x86 boxes (both Intel and AMD), so I am leaving the threshold high. Dave Dice thought this might be an artifact of cores being put into a power-saving mode and being slow to wake (the particular benchmark I wrote would have been pessimal for this, since it alternated between serial and parallel phases). The eventual speedups were often impressive (6x-12x) but it was unclear how many hardware threads (out of the 32-64 available) I was using to obtain this. Yes, I need to plug this into JMH for fine-tuning. I'm using the system fork-join pool because that initially seemed like the good-citizen thing to do (balance CRC/Adler needs against those of anyone else who might be doing work) but I am starting to wonder if it would make more sense to establish a small private pool with a bounded number of threads, so that I don't need to worry about being a good citizen so much. It occurs to me, late in the game, that using big-ish units of work is another, different way to be a bad citizen. (I would prefer to get this checked in if it represents a net improvement, and then work on the tuning afterwards.) Thanks for your consideration, I know that this is large and somewhat late. It took a while to get the "last" bug out. David From jim.gish at oracle.com Thu May 16 15:20:59 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 16 May 2013 11:20:59 -0400 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <5194CD50.3070707@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> <51805E1D.9060504@oracle.com> <5193FBF8.6010605@oracle.com> <5194487E.9090008@oracle.com> <5194CD50.3070707@oracle.com> Message-ID: <5194F95B.5050204@oracle.com> Thanks. Daniel -- could you please push http://cr.openjdk.java.net/~jgish/TestRB.7.2/ ? Jim On 05/16/2013 08:13 AM, Alan Bateman wrote: > On 16/05/2013 03:46, Mandy Chung wrote: >> On 5/15/2013 2:19 PM, Jim Gish wrote: >>> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ >> >> Looks fine. This fix gets the Glassfish to run on jdk8 as an interim >> fix while allowing us to investigate a proper solution for jdk8. >> >> Daniel mentioned the performance overhead of >> Reflection.getCallerClass() offline that does incur some overhead. >> Applications that create logger with no resource bundle likely call >> Logger.getLogger(String name) instead of Logger.getLogger(String >> name, String rbname). In other words, when Logger.getLogger(name, >> rbname) is called, it's likely that rbname is non-null. It might >> incur some performance overhead to applications who resource bundle >> is visible to TCCL or system class loader as Logger.getLogger(String, >> String) always obtains the immediate caller but not used. In >> Glassfish and OSGi environment, there is no performance issue since >> it has been doing the stack walk in the past. I think it's fine as >> it is. >> >> Nits: L1639, 1712 - better to align with the line above. >> >> Thanks for extending the test to cover various cases. >> > This looks okay to me too and I agree with Mandy's comment about > thinking of this as a fix for the short-term. More work will be > required to figure out what the right thing to do is and maybe the > methods that take a resource bundle name needed to be deprecated in > favor of new methods. > > -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 Alan.Bateman at oracle.com Thu May 16 15:50:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 16:50:17 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: Message-ID: <51950039.3010200@oracle.com> On 16/05/2013 15:50, David Chase wrote: > : > > Parallel performance is a little harder to reason about on big x86 boxes (both Intel and AMD), so I am leaving the threshold high. Dave Dice thought this might be an artifact of cores being put into a power-saving mode and being slow to wake (the particular benchmark I wrote would have been pessimal for this, since it alternated between serial and parallel phases). The eventual speedups were often impressive (6x-12x) but it was unclear how many hardware threads (out of the 32-64 available) I was using to obtain this. Yes, I need to plug this into JMH for fine-tuning. I'm using the system fork-join pool because that initially seemed like the good-citizen thing to do (balance CRC/Adler needs against those of anyone else who might be doing work) but I am starting to wonder if it would make more sense to establish a small private pool with a bounded number of threads, so that I don't need to worry about being a good citizen so much. It occurs to me, late in the game, that using big-ish units of work is another, different way to be a bad citizen. (I would prefer to get this checked in if it represents a net improvement, and then work on the tuning afterwards.) > I'm sure Doug or Brian or David Holmes will have opinions on this point but I would think using the common pool is right. If parallel sort, CRC32 and other specific usages each created their own thread pool then I could imagine a lot of thread pools hanging around and competing. Plus there are cases like EE where no-parallelism might be the right answer and one wouldn't want to have to configure each usage. In any case, this looks really good work. One thing that might be worth checking is startup/warm-up. I have a vague memory of this being a concern in the past with Adler32, Sherman might remember the details. -Alan. From mike.duigou at oracle.com Thu May 16 16:17:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 16 May 2013 09:17:29 -0700 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: Message-ID: <8F76775D-B9C6-475D-99DB-60AAD0E58593@oracle.com> On May 16 2013, at 07:50 , David Chase wrote: > 4) For CRC32, use the new-ish PCLMULQDQ instruction (64-bit by 64-bit carryless multiply, yielding a 128-bit result) in the style described in Intel's white paper on using this instruction to compute CRCs. All the constants are different because the CRC32 is bit-reversed from the checksums computed in Intel's paper, but the unrolling is the same, and the fill and drain code is also similar. This is by default enabled whenever CLMUL and AVX features are both present, and can be disabled at the command line with -XX:-UseCLMUL (or -XX:-UseAVX). > > There is a companion webrev that puts information about the availability of the PCLMULQDQ in 3-operand form into a hidden property: > > http://cr.openjdk.java.net/~drchase/8014362/webrev.02/ I haven't looked at the details for the PCLMULQDQ instruction but a caryless multiply could be of use to some of the crypto primitives as well (GHASH, GMAC and probably others). Perhaps the property could be "sun.hotspot.x64.clmulSupported" or something less specific to the usage. What's our actual experience with needing switches like -XX:-UseCLMUL or-XX:-UseAVX for other features? Faulty implementations? Feature misreporting? Performance regressions? Virtualization interactions? Mike From dmitry.degrave at oracle.com Thu May 16 16:30:48 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 16 May 2013 16:30:48 +0000 Subject: hg: jdk8/tl/jdk: 8014676: Java debugger may fail to run Message-ID: <20130516163105.B15E948B04@hg.openjdk.java.net> Changeset: 81c449fd18fe Author: dmeetry Date: 2013-05-16 19:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81c449fd18fe 8014676: Java debugger may fail to run Summary: The problem is observed when the binaries for windows are placed under a path which contains a space Reviewed-by: sla, alanb Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java From michael.x.mcmahon at oracle.com Thu May 16 16:32:08 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 16 May 2013 16:32:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130516163231.64FEE48B05@hg.openjdk.java.net> Changeset: 74f91b7f4b66 Author: michaelm Date: 2013-05-16 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74f91b7f4b66 8012625: Incorrect handling of HTTP/1.1 " Expect: 100-continue " in HttpURLConnection Reviewed-by: alanb, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/B8012625.java Changeset: d02d1b18d828 Author: michaelm Date: 2013-05-16 17:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d02d1b18d828 Merge From daniel.fuchs at oracle.com Thu May 16 16:41:20 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Thu, 16 May 2013 16:41:20 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130516164146.B2CAB48B06@hg.openjdk.java.net> Changeset: da203779cb33 Author: jgish Date: 2013-05-16 11:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da203779cb33 8013380: Removal of stack walk to find resource bundle breaks Glassfish startup Summary: Use caller's classloader to load resource as an alternative to thread context classloader and system classloader Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java - test/java/util/logging/bundlesearch/LoadItUp.java + test/java/util/logging/bundlesearch/LoadItUp1.java + test/java/util/logging/bundlesearch/LoadItUp2.java + test/java/util/logging/bundlesearch/LoadItUp2Invoker.java ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java + test/java/util/logging/bundlesearch/TwiceIndirectlyLoadABundle.java + test/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties Changeset: df133f9cc4c9 Author: dfuchs Date: 2013-05-16 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df133f9cc4c9 Merge From daniel.fuchs at oracle.com Thu May 16 16:50:27 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 May 2013 18:50:27 +0200 Subject: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup In-Reply-To: <5194F95B.5050204@oracle.com> References: <517FF5E4.6000105@oracle.com> <518029AE.7080203@oracle.com> <5180335B.4050302@oracle.com> <51805E1D.9060504@oracle.com> <5193FBF8.6010605@oracle.com> <5194487E.9090008@oracle.com> <5194CD50.3070707@oracle.com> <5194F95B.5050204@oracle.com> Message-ID: <51950E53.90104@oracle.com> Done -- daniel On 5/16/13 5:20 PM, Jim Gish wrote: > Thanks. > > Daniel -- could you please push > http://cr.openjdk.java.net/~jgish/TestRB.7.2/ > ? > > Jim > > On 05/16/2013 08:13 AM, Alan Bateman wrote: >> On 16/05/2013 03:46, Mandy Chung wrote: >>> On 5/15/2013 2:19 PM, Jim Gish wrote: >>>> Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/ >>> >>> Looks fine. This fix gets the Glassfish to run on jdk8 as an interim >>> fix while allowing us to investigate a proper solution for jdk8. >>> >>> Daniel mentioned the performance overhead of >>> Reflection.getCallerClass() offline that does incur some overhead. >>> Applications that create logger with no resource bundle likely call >>> Logger.getLogger(String name) instead of Logger.getLogger(String >>> name, String rbname). In other words, when Logger.getLogger(name, >>> rbname) is called, it's likely that rbname is non-null. It might >>> incur some performance overhead to applications who resource bundle >>> is visible to TCCL or system class loader as Logger.getLogger(String, >>> String) always obtains the immediate caller but not used. In >>> Glassfish and OSGi environment, there is no performance issue since >>> it has been doing the stack walk in the past. I think it's fine as >>> it is. >>> >>> Nits: L1639, 1712 - better to align with the line above. >>> >>> Thanks for extending the test to cover various cases. >>> >> This looks okay to me too and I agree with Mandy's comment about >> thinking of this as a fix for the short-term. More work will be >> required to figure out what the right thing to do is and maybe the >> methods that take a resource bundle name needed to be deprecated in >> favor of new methods. >> >> -Alan >> > From david.r.chase at oracle.com Thu May 16 17:31:00 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 13:31:00 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <8F76775D-B9C6-475D-99DB-60AAD0E58593@oracle.com> References: <8F76775D-B9C6-475D-99DB-60AAD0E58593@oracle.com> Message-ID: On 2013-05-16, at 12:17 PM, Mike Duigou wrote: > I haven't looked at the details for the PCLMULQDQ instruction but a caryless multiply could be of use to some of the crypto primitives as well (GHASH, GMAC and probably others). Perhaps the property could be "sun.hotspot.x64.clmulSupported" or something less specific to the usage. Note that the instruction also works on 32-bit, and once the builds all use sufficiently modern compilers, the same source code works for both. > What's our actual experience with needing switches like -XX:-UseCLMUL or-XX:-UseAVX for other features? Faulty implementations? Feature misreporting? Performance regressions? Virtualization interactions? I haven't seen any virtualization problems -- I've also been testing on VMs, Ubuntu and Solaris on VMWare. Should I also give it a go in VirtualBox? What should I be looking for? David From kurchi.subhra.hazra at oracle.com Thu May 16 17:48:47 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 16 May 2013 17:48:47 +0000 Subject: hg: jdk8/tl/jdk: 7150552: network test hangs [macosx] Message-ID: <20130516174910.E623248B08@hg.openjdk.java.net> Changeset: a8be9405bb4b Author: khazra Date: 2013-05-16 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8be9405bb4b 7150552: network test hangs [macosx] Summary: Remove usage of test/sun/net/www/httptest Reviewed-by: chegar ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieManagerTest.java ! test/sun/net/www/protocol/http/B6299712.java From kumar.x.srinivasan at oracle.com Thu May 16 18:13:57 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 16 May 2013 18:13:57 +0000 Subject: hg: jdk8/tl/jdk: 8001163: [pack200] should support attributes introduced by JSR-308 Message-ID: <20130516181409.97BD148B0A@hg.openjdk.java.net> Changeset: a13de892cefd Author: ksrini Date: 2013-05-15 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a13de892cefd 8001163: [pack200] should support attributes introduced by JSR-308 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java + test/tools/pack200/BandIntegrity.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java + test/tools/pack200/typeannos/Lambda.java + test/tools/pack200/typeannos/Readme.txt + test/tools/pack200/typeannos/TargetTypes.java + test/tools/pack200/typeannos/TestTypeAnnotations.java + test/tools/pack200/typeannos/TypeUseTarget.java From vincent.x.ryan at oracle.com Thu May 16 20:27:29 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 16 May 2013 20:27:29 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130516202851.8AD0048B18@hg.openjdk.java.net> Changeset: 9abf5dc83823 Author: vinnie Date: 2013-05-14 18:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9abf5dc83823 7194075: Various classes of sunec.jar are duplicated in rt.jar Reviewed-by: mullan, vinnie Contributed-by: Stephen Flores ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! makefiles/CreateJars.gmk + src/share/classes/sun/security/ec/CurveDB.java ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/NamedCurve.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/ssl/JsseJce.java + src/share/classes/sun/security/util/ECKeySizeParameterSpec.java + src/share/classes/sun/security/util/ECUtil.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/ec/TestECDH2.java ! test/sun/security/pkcs11/ec/TestECDSA2.java Changeset: fdf082cddb69 Author: vinnie Date: 2013-05-14 18:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fdf082cddb69 Merge Changeset: a399b8be56ae Author: vinnie Date: 2013-05-15 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a399b8be56ae Merge ! makefiles/CreateJars.gmk - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider Changeset: 5153f5154162 Author: vinnie Date: 2013-05-15 15:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5153f5154162 Merge Changeset: 0465f27f19f5 Author: vinnie Date: 2013-05-16 02:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0465f27f19f5 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java Changeset: 9783f07d43e6 Author: vinnie Date: 2013-05-16 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9783f07d43e6 Merge - test/java/lang/Thread/StackTraces.java - test/java/util/logging/bundlesearch/LoadItUp.java From Mike.Duigou at oracle.COM Thu May 16 21:02:53 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Thu, 16 May 2013 14:02:53 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: <51943FDE.5030009@oracle.com> References: <51943FDE.5030009@oracle.com> Message-ID: <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> On May 15 2013, at 19:09 , Joseph Darcy wrote: > Hi Mike, > > Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? I hadn't actually looked but it turns out the answer was "No, certainly not". I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that. If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those. http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/ Mike > > -Joe > > On 5/15/2013 6:17 PM, Mike Duigou wrote: >> Hello all; >> >> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >> >> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. >> >> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. >> >> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. >> >> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). >> >> Thanks, >> >> Mike > From Alan.Bateman at oracle.com Thu May 16 21:27:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2013 22:27:19 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: Message-ID: <51954F37.6080008@oracle.com> On 16/05/2013 15:50, David Chase wrote: > : > > Parallel performance is a little harder to reason about on big x86 boxes (both Intel and AMD), so I am leaving the threshold high. Dave Dice thought this might be an artifact of cores being put into a power-saving mode and being slow to wake (the particular benchmark I wrote would have been pessimal for this, since it alternated between serial and parallel phases). The eventual speedups were often impressive (6x-12x) but it was unclear how many hardware threads (out of the 32-64 available) I was using to obtain this. Yes, I need to plug this into JMH for fine-tuning. I'm using the system fork-join pool because that initially seemed like the good-citizen thing to do (balance CRC/Adler needs against those of anyone else who might be doing work) but I am starting to wonder if it would make more sense to establish a small private pool with a bounded number of threads, so that I don't need to worry about being a good citizen so much. It occurs to me, late in the game, that using big-ish units of work is another, different way to be a bad citizen. (I would prefer to get this checked in if it represents a net improvement, and then work on the tuning afterwards.) > The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods? -Alan. From david.r.chase at oracle.com Thu May 16 22:09:05 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 18:09:05 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51954F37.6080008@oracle.com> References: <51954F37.6080008@oracle.com> Message-ID: On 2013-05-16, at 5:27 PM, Alan Bateman wrote: > The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods? I'm not sure I understand. Right now, the update methods run in parallel for sufficiently large inputs, otherwise serial. I'm still unsure whether their appetite for tasks should be throttled somewhat above and beyond the size limit. There's benefit to having CRC run 3x faster if it uses 4 threads to do it, but using 32 threads to run 9x faster is maybe not a win, even though it is nominally "faster". And here I mean "threads", not tasks, though I don't have a lot of visibility how much of a multiprocessor I am eating when I break something into 32 or 64 tasks. David From mandy.chung at oracle.com Thu May 16 22:09:08 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 16 May 2013 22:09:08 +0000 Subject: hg: jdk8/tl/jdk: 4487672: (proxy) Proxy constructor should check for null argument Message-ID: <20130516220926.D7A1648B1C@hg.openjdk.java.net> Changeset: 5e8959ab64af Author: mchung Date: 2013-05-16 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e8959ab64af 4487672: (proxy) Proxy constructor should check for null argument Reviewed-by: alanb, lancea ! src/share/classes/java/lang/reflect/Proxy.java ! test/java/lang/reflect/Proxy/Basic1.java From mike.duigou at oracle.com Thu May 16 22:16:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 16 May 2013 15:16:49 -0700 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <8F76775D-B9C6-475D-99DB-60AAD0E58593@oracle.com> Message-ID: <2C251328-DEFD-44CF-897D-BB69F664B4A6@oracle.com> On May 16 2013, at 10:31 , David Chase wrote: > > On 2013-05-16, at 12:17 PM, Mike Duigou wrote: >> I haven't looked at the details for the PCLMULQDQ instruction but a caryless multiply could be of use to some of the crypto primitives as well (GHASH, GMAC and probably others). Perhaps the property could be "sun.hotspot.x64.clmulSupported" or something less specific to the usage. > > Note that the instruction also works on 32-bit, and once the builds all use sufficiently modern compilers, the same source code works for both. Understood, but it's only going to be available on processors that support also support EMT64, correct? I am not sure what the best way to characterize the required architecture should be. >> What's our actual experience with needing switches like -XX:-UseCLMUL or-XX:-UseAVX for other features? Faulty implementations? Feature misreporting? Performance regressions? Virtualization interactions? > > I haven't seen any virtualization problems -- I've also been testing on VMs, Ubuntu and Solaris on VMWare. > Should I also give it a go in VirtualBox? What should I be looking for? I don't know of any specific problems but was more curious whether we really need the ability to disable the feature. Have we seen problems in the past? > David > From david.r.chase at oracle.com Thu May 16 22:23:36 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 18:23:36 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <2C251328-DEFD-44CF-897D-BB69F664B4A6@oracle.com> References: <8F76775D-B9C6-475D-99DB-60AAD0E58593@oracle.com> <2C251328-DEFD-44CF-897D-BB69F664B4A6@oracle.com> Message-ID: On 2013-05-16, at 6:16 PM, Mike Duigou wrote: >> Note that the instruction also works on 32-bit, and once the builds all use sufficiently modern compilers, the same source code works for both. > > Understood, but it's only going to be available on processors that support also support EMT64, correct? I am not sure what the best way to characterize the required architecture should be. According to the Intel docs, it has to provide CLMUL and AVX features, so that's what the code looks for. CLMUL gets you CLMUL, AVX adds the three-operand form that gets you the better code and keeps the guy writing the code from going even more nuts than he already did, because there is no way I want to have 4 versions of that assembly language, never mind that there's not too many chips in the CLMUL-minus-AVX category anyway. David From mike.duigou at oracle.com Thu May 16 23:41:00 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 16 May 2013 16:41:00 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at radix 2, 8, 16 In-Reply-To: <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> References: <51943FDE.5030009@oracle.com> <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> Message-ID: I've cleaned up the test some with feedback from Brian Goetz: http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/ On May 16 2013, at 14:02 , Mike Duigou wrote: > > On May 15 2013, at 19:09 , Joseph Darcy wrote: > >> Hi Mike, >> >> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? > > I hadn't actually looked but it turns out the answer was "No, certainly not". > > I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that. > > If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those. > > http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/ > > Mike > >> >> -Joe >> >> On 5/15/2013 6:17 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >>> >>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. >>> >>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. >>> >>> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. >>> >>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). >>> >>> Thanks, >>> >>> Mike >> > From david.holmes at oracle.com Fri May 17 00:35:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 10:35:15 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1368701316.2716.15.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <518CD83F.30906@gmail.com> <518CF29B.7090202@oracle.com> <518D382A.9000704@oracle.com> <518D53BC.7050804@gmail.c!> <518D5718.1030903@gmail.com> <518D5E3B.6070706@oracle.! com> <518D8695.8090204@oracle.com> <1368701316.2716.15.camel@cirrus> Message-ID: <51957B43.9080707@oracle.com> On 16/05/2013 8:48 PM, Thomas Schatzl wrote: > Hi, > > On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote: >> On 11/05/2013 6:53 AM, Dean Long wrote: >>> On 5/10/2013 1:22 PM, Peter Levart wrote: >>>> >>>> On 05/10/2013 10:08 PM, Peter Levart wrote: >>>>> >>>>> On 05/10/2013 08:10 PM, Dean Long wrote: >>>>>> If you really want to bullet-proof ReferenceHandler (and other >>>>>> system threads) against OOME caused by native allocations, >>>>>> then don't forget about monitor inflation if there is contention for >>>>>> "lock" :-) >> >> >> Right - most C-heap allocation failures in the VM result in an abort but >> some will convert to OOME (such as native thread creation related failures). >> >> Any test that tries to force an OOME at a particular operation is going >> to be fragile because you can't know what other allocations might be >> needed under the covers. As Peter already discovered it might occur >> during the "new" of InterruptedException, or it might happen during the >> load/initialization of InterruptedException. So pre-initializing >> InterruptedException is probably a wise thing to do. >> > > That means what? Should I file a new CR (against what component?) for > that (making InterruptedException a pre-initialized exception)? No I was only referring to the test - the test should preinitialize InterruptedException. David > Thanks, > Thomas > > From david.holmes at oracle.com Fri May 17 00:47:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 10:47:13 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1368701086.2716.13.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> Message-ID: <51957E11.6050608@oracle.com> On 16/05/2013 8:44 PM, Thomas Schatzl wrote: > On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: >> I updated the test program and the patch in java.lang.ref.Reference >> accordingly. >> >> As for the problem of reproducibility, in my tests I had a 100% >> reproduction rate with the previous version of the test. >> >> However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as >> suggested in some other emails. >> >> I will report back with a new webrev after some testing on more >> platforms as suggested by David. > > a new webrev for the patch is at > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ I think the comment is somewhat confusing, but then the details here are quite confusing. I guess the key part of this is that if OOME is thrown we don't want to try and load InterruptedException - though I'm unclear, based on normal exception processing semantics, when that might occur. > Testing: > jprt; manual tests with the test program on a jdk with and without the > patch on linux 32/64 bit, windows 32/64 bit, and sparc 32/64 bit. The > test program showed 100% reproduction of the error without the patch, > and 100% fix success with a jdk containing the patch (each multiple > tries at that). > Note that jprt seems to run all jdk unit tests always anyway. Thanks for the detailed testing and validation. > I also fixed the copyright date in java/lang/ref/Reference.java. Not necessary for JDK code as they rely on periodic updates (in contrast to some hotspot teams). > If this patch is considered acceptable, I need two reviewers as usual > (possibly from GC/hsx team and one from jdk), and one sponsor pushing > the change. (I am still intent on making Peter the author of the patch > as both the change and the test program came from him) > > I am not even author for the jdk, but can act as a non-Reviewer reviewer > for the gc/hsx team. You can count me as a Reviewer and sponsor. I think only a second JDK/TL Reviewer is needed here as no impact on hotspot. Thanks for your efforts with this. David ----- > Thanks a lot, > Thomas > > From david.holmes at oracle.com Fri May 17 01:26:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 11:26:15 +1000 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: Message-ID: <51958737.8040502@oracle.com> Dave, This is certainly significant work! To get the mundane issues out of the way: - C code uses indent of 2 in places instead of 4 There is a lot to try and digest here. Why does the ASM not support Windows compiler? David On 17/05/2013 12:50 AM, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/ > > problem: Some applications spend a surprising amount of time computing CRC32s > (Not sure I'm supposed to be precise on an open mailing list). Recent Intel > architectures provide instructions that might be useful in addressing this. > > See https://jbs.oracle.com/bugs/browse/JDK-7088419 > > I turned this into a general attack on performance in Adler32 and CRC32, partly because the bug report was not clear on the size of the problematic inputs. The general approach turned out to be useful, because it's tricky to get the small-case overheads down for the accelerated-instruction version of the code. > > > fix: > 1) For CRC32 and Adler32, break out the "small" case (single bytes, and up to around 60-80 bytes) > to be computed on the Java side, avoiding JNI overheads. > > 2) For CRC32 and Adler32, figure out the "combine" operations for the checksum of a concatenated pair of byte sequences, and add fork-join parallelism for large-enough inputs. Tuning this is hard, so large "small" buffer sizes were chosen (< 512K for unaccelerated CRC32, 1MB for Adler32 and accelerated CRC32) to make this a safe optimization. This can be disabled by setting the (not-yet-documented, perhaps wrongly named) property "sun.zip.serialOnly=true". I just now noticed that this is not the case for Adler32; assuming we agree on the existence of this flag and its name, this needs to be added there, too. > > 3) For Adler32, defer calculation of the actual "Adler" checksum until it is requested. This is an optimization for byte-at-a-time use. > > 4) For CRC32, use the new-ish PCLMULQDQ instruction (64-bit by 64-bit carryless multiply, yielding a 128-bit result) in the style described in Intel's white paper on using this instruction to compute CRCs. All the constants are different because the CRC32 is bit-reversed from the checksums computed in Intel's paper, but the unrolling is the same, and the fill and drain code is also similar. This is by default enabled whenever CLMUL and AVX features are both present, and can be disabled at the command line with -XX:-UseCLMUL (or -XX:-UseAVX). > > There is a companion webrev that puts information about the availability of the PCLMULQDQ in 3-operand form into a hidden property: > > http://cr.openjdk.java.net/~drchase/8014362/webrev.02/ > > > testing: > > The CRC benchmark test was adjusted to also warm-up the small-stuff case. > > A new test was written that was designed to exercise all the corner cases of the new Adler32 and CRC32 implementations; byte-at-a-time is compared to byte-at-a-time-not-looking is compared to arrays of bytes is compared to DirectBuffers, at a variety of sizes and alignments designed to exercise combinations of non-empty fill and drain for the Intel-accelerated CRC32, and corner cases for the fork-join code. > > The new test takes just under 2 minutes on a T1; that seems like it is cutting it close, so I should either trim the test or give it a little more time. > > Separate C unit tests (not checked in, not sure where to put them) were written to exhaustively test the accelerated code and research its portability to various compilers. > > > problems and justifications: > > Using our currently specified compilers for building the JDK, the C access to the new Intel intrinsics is not available. This is unfortunately also true of the assemblers paired with our currently specified compilers. > ( What IS the specified compiler for building on Linux? Gcc 4.2 on the Mac, if asked for a 16-byte alignment, helpfully tells me that is too big, and it will use 15 instead. This might be an issue on Linux, if 4.2 is the build compiler version there. ) Therefore, the native code for crc32 includes: > > 1) the C code with intrinsics for the accelerated CRC32 kernel (compilable with gcc 4.6 or clang, and almost compilable with Sun Studio 12.3; it parses and optimizes, but triggers a crash in the back end, which needs to be reported). > > 2) the 64-bit version of the assembly language, including commented byte sequences for the instructions that the build-specified assemblers do not recognize. > > 3) the 32-bit version of the assembly language, including commented byte sequences for the instructions that the build-specified assemblers do not recognize. > > My hope is that the assembly language is temporary, though it is only a modest step higher in abstraction from the C code, which is almost entirely intrinsic calls. If we have to wait for the C compilers, perhaps the assemblers will all become modern enough to handle the instructions by their proper names. I have a small tool that I wrote to automatically generate the asm statement from the output lldb x/i. (Where does such a weird little tool belong?) > > I tried to use the instruction just as a stand-alone intrinsic (that might be wrapped in unsafe code and called from Java) but that did not yield a performance gain; it only seems to work well if embedded in an unrolled loop with several independent pipelines of computation running, all feeding 128-bit accumulator registers. That is to say, Intel wrote that white paper for a reason, which was to help guide people like me towards happy results. To my knowledge, we don't support compilation to 128-bit wide xmm registers in hotspot, so this approach was unlikely to work. > > Another possibility is to wrap the entire kernel up as a single 80-instruction intrinsic. This didn't seem like a win to me, and it would require the use of Unsafe code to interface to it. Even then it's not clear it's possible, because the kernel requires that its input be 16-byte aligned. I don't know if the alignment is guaranteed by the garbage collector, and I could not find a way in Unsafe to even get the (temporarily valid) address of a GC-allocated object. It would be helpful to know the address even if it is only probably true, because for fork-join it is helpful to arrange splits so that they land on a 16-byte boundary so that the eventual serial case will (probably) go as fast as possible with empty fill/drain steps. > > Yet another possibility is to move all of "fastcrc32" (the outer fill and drain code written in C) into a single intrinsic, but that's 208 instructions total (I just looked). > > Oh yeah, performance improvements. On an Ivy Bridge laptop (2 cores, 2 threads/core), the accelerated CRC without workstealing is 2.5x faster on large inputs, 2x faster at about 512 bytes. Modest amounts of fork-join parallelism (only fork for work 1M or larger if CLMUL present) provide about 1.5x on top of that, for a 3.75x speedup. > > Fork-join benchmarks pretty well on the Sun T1, T2, T4 series of processors down to somewhat smaller block sizes, but for now I am conservative an use a serial-if-smaller-than setting of 512K. I've observed speedups as high as 13x on a T1 (1(32), dr-evil), 24x on a T2+ ( 4(256), mrspock), and 8x on a T4 (8(64), sc11d1901). > > Parallel performance is a little harder to reason about on big x86 boxes (both Intel and AMD), so I am leaving the threshold high. Dave Dice thought this might be an artifact of cores being put into a power-saving mode and being slow to wake (the particular benchmark I wrote would have been pessimal for this, since it alternated between serial and parallel phases). The eventual speedups were often impressive (6x-12x) but it was unclear how many hardware threads (out of the 32-64 available) I was using to obtain this. Yes, I need to plug this into JMH for fine-tuning. I'm using the system fork-join pool because that initially seemed like the good-citizen thing to do (balance CRC/Adler needs against those of anyone else who might be doing work) but I am starting to wonder if it would make more sense to establish a small private pool with a bounded number of threads, so that I don't need to worry about being a good citizen so much. It occurs to me, late in the game, that! using b ig-ish units of work is another, different way to be a bad citizen. (I would prefer to get this checked in if it represents a net improvement, and then work on the tuning afterwards.) > > Thanks for your consideration, I know that this is large and somewhat late. It took a while to get the "last" bug out. > > David > From david.r.chase at oracle.com Fri May 17 01:52:05 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 21:52:05 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51958737.8040502@oracle.com> References: <51958737.8040502@oracle.com> Message-ID: On 2013-05-16, at 9:26 PM, David Holmes wrote: > Dave, > > This is certainly significant work! > > To get the mundane issues out of the way: > - C code uses indent of 2 in places instead of 4 Okey-doke, I will reformat. > There is a lot to try and digest here. Ask away, I'll do my best. I am unsure what breadcrumbs I need to leave for the future (including my future self); I worked very hard to get that code into a state where I would not need to touch the hairy bits with algebra and unrolling possibly forever, but in fact it is possible that with a little care the drain code could be improved (I was running out of steam, and the bit-reversal affected it significantly). I am least certain of the fork-join code -- I want to be sure that if this code is running in a busy-server environment, that it will not use threads (not tasks, but threads) wastefully. That is, if I'm more than 50% off linear speedup, I think I'm done, and I'd be happier if it was only 75% (which 2 and 4 task splitting seems to get pretty reliably, but less so after that, this on machines with many more than 4 "processors"). > Why does the ASM not support Windows compiler? I literally, actually forgot, and I haven't the faintest idea how to configure a standard Windows build. I'm sure it will be an easy and incredibly pleasant experience. If there is a cheat sheet, I would love to see it, especially the part about installing and configuring software. There is a Windows 7 laptop in my office, so I do have "easy" access to Windows. I guess I had better give this a look. I did Windows development about ten years ago, with both Visual Studio and Cygwin, so it will not be completely foreign to me. > David From david.r.chase at oracle.com Fri May 17 01:58:41 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 21:58:41 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51958737.8040502@oracle.com> References: <51958737.8040502@oracle.com> Message-ID: <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> On 2013-05-16, at 9:26 PM, David Holmes wrote: > Dave, > > This is certainly significant work! > > To get the mundane issues out of the way: > - C code uses indent of 2 in places instead of 4 Are you referring to the #ifdefs and #defines? I just want to be sure, because that's what I see at 2 spaces. David From david.holmes at oracle.com Fri May 17 02:15:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 12:15:00 +1000 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> References: <51958737.8040502@oracle.com> <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> Message-ID: <519592A4.4060203@oracle.com> On 17/05/2013 11:58 AM, David Chase wrote: > > On 2013-05-16, at 9:26 PM, David Holmes wrote: > >> Dave, >> >> This is certainly significant work! >> >> To get the mundane issues out of the way: >> - C code uses indent of 2 in places instead of 4 > > Are you referring to the #ifdefs and #defines? > I just want to be sure, because that's what I see at 2 spaces. No the C code: JNIEXPORT jboolean JNICALL Java_java_util_zip_CRC32_init(JNIEnv *env, jclass cls, jarray b, jboolean use_clmul) { /* Get the CRC table from zip to initialize JNI. Our private copy is missing if not compiled for fastcrc32. */ crc_table = get_crc_table(); jint *buf = (*env)->GetPrimitiveArrayCritical(env, b, 0); if (buf) { /* Don't know for sure how big an unsigned long is, therefore copy one at a time. */ int i; The above has indent 2 initially the moves to 8. BTW while at this code I don't understand the issue with size of long and copying "one at a time". Where are the "unsigned longs"? and should we be using them if we don't even know they will be larger than unsigned ints? David > David > From eliasen at mindspring.com Fri May 17 02:21:06 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Thu, 16 May 2013 20:21:06 -0600 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> Message-ID: <51959412.8040401@mindspring.com> On 05/14/2013 01:54 PM, Brian Burkhalter wrote: > This is the first of an eventual four phases of performance > improvement of BigInteger for large integers. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 > > Webrev: > > http://cr.openjdk.java.net/~bpb/4837946/ > > This contains Alan Eliasen's implementation of Karatsuba and 3-way > Toom-Cook multiplication and squaring, and pow() accelerated by power > of two shifting and accelerated exponentiation by squaring. > > I have reviewed this code including verifying all algorithms against > the references suggested in the code as well as other sources in the > literature. It all looks to be entirely correct and very clean and > clear. Thanks very much for looking this over, Brian! One minor revision to this revision that I must have missed is that the added import for java.util.ArrayList is not actually used until Phase 2, which is improving toString(). (ArrayList is used in the cache for improving toString radix conversion. I didn't use it anywhere in multiply() or pow(). ) More below. > One change which I have *not* made and which seems appropriate to add > to this patch is to modify multiply() to use square() if the > parameter is the BigInteger instance on which the method is invoked, > i.e., to change this snippet > > public BigInteger multiply(BigInteger val) { if (val.signum == 0 || > signum == 0) return ZERO; > > to this > > public BigInteger multiply(BigInteger val) { if (val.signum == 0 || > signum == 0) return ZERO; > > if (val == this) return square(); That seems like a lightweight but acceptable change to me. I have discussed this optimization before, and thought it might improve a small number of cases, but could make the base case of very small non-equal numbers slightly slower. I haven't benchmarked it; I'd doubt that the change would even be detectable in most programs, and if it were triggered, would somewhat improve the performance of certain programs. I was initially concerned that it might create an infinite loop if any of the square() functions called multiply() to do the dirty work but none of them seem to at the moment. The identity comparison is be reasonably fast and lightweight and constant time. This optimization wouldn't catch the case where two identical numbers are passed in but don't point to the same place in memory. It would be more general to call .equals(Object) but that would have more overhead (in the worst case, it's O(n) where n is the number of ints in the BigInteger.) I would probably avoid the latter. If you perform .pow(2) it will automatically square the numbers efficiently and rapidly, but the users won't know that without looking at the implementation, and there is some slight overhead to using pow() compared to a public square() method. In the future, the various squaring routines could benefit from some of the tricks that pow() uses (that is, detecting powers of two in the number and handling those via left-shifts.) This behavior would probably want to be factored out into separate private functions, as it would be useful in pow(), square(), and potentially in division, as I was recently discussing with Tim Buktu. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From david.r.chase at oracle.com Fri May 17 02:26:46 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 22:26:46 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <519592A4.4060203@oracle.com> References: <51958737.8040502@oracle.com> <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> <519592A4.4060203@oracle.com> Message-ID: <142E32B5-1178-48C4-9EE6-719E06A34C86@oracle.com> On 2013-05-16, at 10:15 PM, David Holmes wrote: > BTW while at this code I don't understand the issue with size of long and copying "one at a time". Where are the "unsigned longs"? and should we be using them if we don't even know they will be larger than unsigned ints? The values are well known and invariant -- they depend on the CRC32 properties -- and only contain 32 bits of interesting data each. We need to make a copy of them for the Java code (to enable both the small-array fast path, and the combine operation for fork/join). I think that doing this copy in C code from an existing copy into an array of java int (known 32 bytes) is the fastest and smallest footprint way to do it (vs. interpreting Java array initialization) and we are doing the JNI handshake anyway to be sure that both sides agree on the existence or not of CLMUL acceleration. They're stored in "unsigned long" (that is how zlib declares them) and at least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good idea. When the fast-path algorithm is enabled, this is also the last time that the old crc32 table is referenced (it contains 1024 entries, so it is 8k, versus 1K for this) so we can even claim some small reduction in effective footprint. David From david.holmes at oracle.com Fri May 17 03:06:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 13:06:26 +1000 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <142E32B5-1178-48C4-9EE6-719E06A34C86@oracle.com> References: <51958737.8040502@oracle.com> <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> <519592A4.4060203@oracle.com> <142E32B5-1178-48C4-9EE6-719E06A34C86@oracle.com> Message-ID: <51959EB2.7020300@oracle.com> On 17/05/2013 12:26 PM, David Chase wrote: > > On 2013-05-16, at 10:15 PM, David Holmes wrote: >> BTW while at this code I don't understand the issue with size of long and copying "one at a time". Where are the "unsigned longs"? and should we be using them if we don't even know they will be larger than unsigned ints? > > > The values are well known and invariant -- they depend on the CRC32 properties -- and only contain 32 bits of interesting data each. We need to make a copy of them for the Java code (to enable both the small-array fast path, and the combine operation for fork/join). I think that doing this copy in C code from an existing copy into an array of java int (known 32 bytes) is the fastest and smallest footprint way to do it (vs. interpreting Java array initialization) and we are doing the JNI handshake anyway to be sure that both sides agree on the existence or not of CLMUL acceleration. > > They're stored in "unsigned long" (that is how zlib declares them) and at least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good idea. When the fast-path algorithm is enabled, this is also the last time that the old crc32 table is referenced (it contains 1024 entries, so it is 8k, versus 1K for this) so we can even claim some small reduction in effective footprint. Mac is 64-bit. All our supported platforms either use the ILP32 data model, else the LP64 data model. So on 64-bit does this copying potentially have endian issues? David H. > David > From david.r.chase at oracle.com Fri May 17 03:16:31 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 16 May 2013 23:16:31 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51959EB2.7020300@oracle.com> References: <51958737.8040502@oracle.com> <1F4914AD-6FB7-4EE4-BF58-C61699F20618@oracle.com> <519592A4.4060203@oracle.com> <142E32B5-1178-48C4-9EE6-719E06A34C86@oracle.com> <51959EB2.7020300@oracle.com> Message-ID: On 2013-05-16, at 11:06 PM, David Holmes wrote: > On 17/05/2013 12:26 PM, David Chase wrote: >> >> They're stored in "unsigned long" (that is how zlib declares them) and at least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good idea. When the fast-path algorithm is enabled, this is also the last time that the old crc32 table is referenced (it contains 1024 entries, so it is 8k, versus 1K for this) so we can even claim some small reduction in effective footprint. > > Mac is 64-bit. All our supported platforms either use the ILP32 data model, else the LP64 data model. > > So on 64-bit does this copying potentially have endian issues? No, since I am loading-casting-storing values. And I'm developing on a Mac, which is how I spotted the issue. And I've also tested on both Sparc and Intel, so both endianness, just because it never hurts to check. The accelerated CRC code is fantastically sensitive to endianness, but it only runs on one architecture, so that is okay. David From eliasen at mindspring.com Fri May 17 03:52:02 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Thu, 16 May 2013 21:52:02 -0600 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: References: Message-ID: <5195A962.1070208@mindspring.com> On 05/15/2013 07:17 PM, Mike Duigou wrote: > Hello all; > > This issue was originally part of JDK-8006627 (improve performance of > UUID parsing/formatting) but was split out because it could be split > out. I've been working incrementally on pieces of 8006627 as my time > permits. > > http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ > > Since the last rev I have made a separate implementation > Integer.formatUnsignedInteger for use by Integer rather than sharing > the Long implementation because it's about 30% faster. I suspect the > benefits would be even greater on a 32-bit VM or 32-bit native > platform. Mike, Do your changes affect performance for all radices, or for certain radices as implied in some issue titles? It might be beneficial to coordinate with Brian Burkhalter who is working on integrating my patches to make BigInteger.toString() much faster. As you know, BigInteger.toString() partially uses Long.toString(). Improving the performance of Long.toString() will improve the performance of BigInteger, which is great. However, there is an empirically-found threshold in BigInteger that might benefit from re-tuning if Long.toString becomes significantly faster, though. The threshold is intentionally chosen to be a bit conservative for cases like this, so re-tuning may not have a huge effect. I don't use different thresholds based on the radix, but that's something to consider in the future if it could improve performance. Radices that are powers of 2 shouldn't need the recursive improvements in BigInteger.toString. If you let me know if these changes get checked in, I can see if re-tuning the threshold for BigInteger.toString() can improve performance even further. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From david.holmes at oracle.com Fri May 17 04:36:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2013 14:36:35 +1000 Subject: RFR : 8004015 : (S) Additional Functional Interface instance and static methods In-Reply-To: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> References: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> Message-ID: <5195B3D3.9060004@oracle.com> Hi Mike, A general comment regarding exceptional behaviour. There are a lot of operations that involve composite operations (compose, andThen, or, and, xor etc) and if the first operation throws an exception the second never gets evaluated. Does this need to be spelled out somewhere or is this obviously the only way it would work ? --- BiConsumer.java 54 * Returns a BiConsumer which performs in sequence the {@code accept} 55 * methods of multiple BiConsumers. It doesn't perform for multiple BiConsumers but only the one specified. That may be chained to another and so forth but each chain operation only relates to a single BiConsumer. You might then simply describe this method as: "Returns a BiConsumer which chains this BiConsumer with another BiConsumer. The returned BiConsumer's accept method invokes this BiConsumer's accept method followed by the accept method of the specified BiConsumer." --- BiFunction.java Why is the documentation style for BiFunction.andThen so different to BiConsumer.chain when they effectively do the same thing? Shouldn't andThen be described as: "Returns a BiFunction that composes this BiFunction with another BiFunction ..." + * @param after An additional function "additional" is superfluous - additional to what? --- Consumer.java Same basic comments as for BiConsumer. --- Function.java Same basic comments as BiFunction. --- Thanks, David On 15/05/2013 2:22 PM, Mike Duigou wrote: > Hello all; > > This a fairly small set of additional methods for the existing Java 8 functional interfaces. These methods have been held back until now awaiting support for static interface methods. > > http://cr.openjdk.java.net/~mduigou/JDK-8004015/0/webrev/ > > Mike > From eliasen at mindspring.com Fri May 17 05:48:39 2013 From: eliasen at mindspring.com (Alan Eliasen) Date: Thu, 16 May 2013 23:48:39 -0600 Subject: 4646474 : BigInteger.pow() algorithm slow in 1.4.0 In-Reply-To: <33A2BE33-8D67-4F79-BEAD-231B09C6E101@oracle.com> References: <33A2BE33-8D67-4F79-BEAD-231B09C6E101@oracle.com> Message-ID: <5195C4B7.3030003@mindspring.com> On 05/14/2013 07:11 PM, Brian Burkhalter wrote: > The test in this issue report > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 > > is pretty much useless for comparative purposes after applying > 4837946 as the computed value is just a power of two which will be > handled very quickly by the new algorithm. > > As a single alternate data point I modified the test instead to > compute 17^13466917. The execution time on my MacBookPro5,3 before > applying the 4837946 patch was 2336.975514 seconds and afterwards > 79.202646 seconds: an improvement of about a factor of 30. I am sure > that there are much more extreme examples than this but the result is > good to see. Yes, the extreme examples are ones like in the original bug report, which are literally millions of times faster. If the base contains a power of 2, (which is by far the most common case I see in numeric algorithms,) then performance can be be so drastically improved that it's hard to measure the actual ratio. For example, you've seen the workarounds in BigDecimal for slow 10^x calculations, which will be greatly improved by this patch and the toString() changes in the next phase. Note that when Schoenhage-Strassen multiplication is included, the ratio will be even better. On an eight-core (using just one core) AMD FX-8350 at 4 GHz, the time for your example of 17^13466917 drops from 1412.522 seconds to 15.233 seconds, an improvement of a factor of about 93. > I linked this issue to 4837946 as a duplicate so it will be closed > out at the same time. That'll be great to see. Combined, these two bug reports are old enough to buy us drinks. I'm so proud of them. :) Is there any plan to backport these to earlier JVMs? -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From thomas.schatzl at oracle.com Fri May 17 07:56:34 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 17 May 2013 09:56:34 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <51957E11.6050608@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5182B003.7030305@gmail.com> <1367603276.4723.7.camel@cirrus> <51840F21.9010802@gmail.com> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> <51957E11.6050608@oracle.com> Message-ID: <1368777394.3918.24.camel@cirrus> On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote: > On 16/05/2013 8:44 PM, Thomas Schatzl wrote: > > On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: > >> I updated the test program and the patch in java.lang.ref.Reference > >> accordingly. > >> > >> As for the problem of reproducibility, in my tests I had a 100% > >> reproduction rate with the previous version of the test. > >> > >> However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as > >> suggested in some other emails. > >> > >> I will report back with a new webrev after some testing on more > >> platforms as suggested by David. > > > > a new webrev for the patch is at > > > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ > > I think the comment is somewhat confusing, but then the details here are > quite confusing. I guess the key part of this is that if OOME is thrown > we don't want to try and load InterruptedException - though I'm unclear, > based on normal exception processing semantics, when that might occur. I tried to clarify the comment a little; I also added a dummy instantiation of InterruptedException at the start of the test program to avoid OOME during class loading in this case as suggested by the other email. The new webrev is at http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ I only compiled and tested this webrev that nothing broke locally, as the changes are minimal and mostly concerning comments. Pushing a jdk through jprt also takes a long time. Before sending you a patchset after it has been reviewed, I will push it through jprt again. > You can count me as a Reviewer and sponsor. I think only a second JDK/TL > Reviewer is needed here as no impact on hotspot. Thanks, Thomas From sergey.kuksenko at oracle.com Fri May 17 08:23:03 2013 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Fri, 17 May 2013 12:23:03 +0400 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> Message-ID: <5195E8E7.20500@oracle.com> Hi Brian, In the parallel thread I see a new implementation of CRC32 & Adler32. I don't mean new HW intrinsics, I mean parallel operation using ForkJoinPool. I think BigInteger operations may be a better candidate for such kind of parallelization. For example Karatsuba may be forkjoined naturally. -- Best regards, Sergey Kuksenko From paul.sandoz at oracle.com Fri May 17 08:28:15 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 May 2013 10:28:15 +0200 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <51954F37.6080008@oracle.com> Message-ID: <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> On May 17, 2013, at 12:09 AM, David Chase wrote: > > On 2013-05-16, at 5:27 PM, Alan Bateman wrote: >> The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods? > > I'm not sure I understand. Alan may be suggesting that the caller should explicitly, but unobtrusively, opt in to parallel execution rather than it being something implicit. That is the approach we have taken for the Streams API, parallel sort and parallel prefix of arrays in JDK 8 [*]. It's a least surprise principle of libraries "not eating more compute resources unless you ask it to". I think Adler32 and CRC32 should stick to the same principle and require opt in from the caller, thus implying this behaviour cannot be part of the public API in JDK 7. Paul. [*] In JDK 8 the Arrays.parallelSort methods use an array length threshold of 2^13, arrays <= to that length will be sorted sequentially and arrays > than will be sorted in parallel. IIUC the threshold was chosen to ensure that Arrays.parallelSort is ~ the same as or faster than Arrays.sort. > Right now, the update methods run in parallel for sufficiently large inputs, otherwise serial. I'm still unsure whether their appetite for tasks should be throttled somewhat above and beyond the size limit. There's benefit to having CRC run 3x faster if it uses 4 threads to do it, but using 32 threads to run 9x faster is maybe not a win, even though it is nominally "faster". And here I mean "threads", not tasks, though I don't have a lot of visibility how much of a multiprocessor I am eating when I break something into 32 or 64 tasks. > From Alan.Bateman at oracle.com Fri May 17 10:15:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 May 2013 11:15:19 +0100 Subject: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies In-Reply-To: <5193CE18.9030203@oracle.com> References: <518D64A8.1090906@oracle.com> <5190E9AF.5090504@oracle.com> <5193CE18.9030203@oracle.com> Message-ID: <51960337.8080502@oracle.com> On 15/05/2013 19:04, Dan Xu wrote: > : > > Thanks for your review, I have updated wordings in the java doc. The > new webrev can be reviewed at > http://cr.openjdk.java.net/~dxu/8011136/webrev.01/ > . > > -Dan Thanks for the updates, looks good to me. -Alan From daniel.fuchs at oracle.com Fri May 17 10:22:15 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 17 May 2013 10:22:15 +0000 Subject: hg: jdk8/tl/jdk: 8013900: More warnings compiling jaxp. Message-ID: <20130517102228.AD98548B64@hg.openjdk.java.net> Changeset: 68209420aac2 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68209420aac2 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw + test/javax/xml/jaxp/PrecisionDecimalDV/XPrecisionDecimalToString.java From daniel.fuchs at oracle.com Fri May 17 10:21:54 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 17 May 2013 10:21:54 +0000 Subject: hg: jdk8/tl/jaxp: 8013900: More warnings compiling jaxp. Message-ID: <20130517102159.5ACAF48B63@hg.openjdk.java.net> Changeset: 6443f5627744 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6443f5627744 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw ! src/com/sun/org/apache/bcel/internal/generic/BasicType.java ! src/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java ! src/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java ! src/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java ! src/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java ! src/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java ! src/com/sun/org/apache/bcel/internal/generic/Select.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java ! src/com/sun/org/apache/xerces/internal/util/URI.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java ! src/com/sun/org/apache/xml/internal/serializer/utils/URI.java ! src/com/sun/org/apache/xml/internal/utils/URI.java ! src/com/sun/org/apache/xpath/internal/Arg.java From chris.hegarty at oracle.com Fri May 17 10:54:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 11:54:15 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) Message-ID: <51960C57.9010907@oracle.com> There are a few networking tests failing recently. All have bugs against them. These bugs will be address shortly, but since tl is integrating into master, for b91, next Tuesday, it is best to add them to the ProblemList so that the failures don't escape into master. diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java #7143960 java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all +#8014783 +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all + +#8014720 +java/net/ResponseCache/B6181108.java generic-all + +#8014723 +sun/misc/URLClassPath/ClassnameCharTest.java generic-all + +#8014719 +sun/net/www/http/HttpClient/ProxyTest.java generic-all + -Chris. From Alan.Bateman at oracle.com Fri May 17 11:22:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 May 2013 12:22:22 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <51960C57.9010907@oracle.com> References: <51960C57.9010907@oracle.com> Message-ID: <519612EE.4060202@oracle.com> On 17/05/2013 11:54, Chris Hegarty wrote: > There are a few networking tests failing recently. All have bugs > against them. These bugs will be address shortly, but since tl is > integrating into master, for b91, next Tuesday, it is best to add them > to the ProblemList so that the failures don't escape into master. > > diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt > --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 > +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 > @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java > #7143960 > java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all > > +#8014783 > +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all > + > +#8014720 > +java/net/ResponseCache/B6181108.java generic-all > + > +#8014723 > +sun/misc/URLClassPath/ClassnameCharTest.java generic-all > + > +#8014719 > +sun/net/www/http/HttpClient/ProxyTest.java generic-all > + > > -Chris. For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume that using try-with-resources around the code that opens the .ser files will sort this out (meaning might be as quick to just fix this one). For the rest then I agree, these need to be excluded until HttpURLPermission can support proxying of ftp connections. The long standing format has been to put a space before the bug number, I don't know if we have any grep-like tools that depend on that. As an aside, we need to re-format this file at some point to put the bug numbers onto the same line as the test. That's the format that jtreg prefers and would it be generally more grep-friendly. This needs to be done in conjunction with taking an axe to jdk/test/Makefile and I think on Mike's list. -Alan From david.r.chase at oracle.com Fri May 17 12:56:12 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 May 2013 08:56:12 -0400 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: <5195E8E7.20500@oracle.com> References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> <5195E8E7.20500@oracle.com> Message-ID: <660F0894-EE8E-4CA6-AC22-9D9AAD781043@oracle.com> There's been a little pushback against that use of forkjoin, though (as the author of the CRC/Adler work it seems like a reasonable idea to me). One worry I have had is that in a larger context we are worried not just about speed, but also about efficiency; using 4 threads for a 3x speedup is in fact "less efficient" than using just 1 thread, but not by a lot. Using 32 threads for a 9x speedup is a good deal less efficient. (And note I am saying "threads", not "tasks", there are good reasons for breaking big jobs down into more tasks than threads, since not all tasks take the same time to finish and the straggler determines the overall time). David On 2013-05-17, at 4:23 AM, Sergey Kuksenko wrote: > Hi Brian, > > In the parallel thread I see a new implementation of CRC32 & Adler32. I don't mean new HW intrinsics, I mean parallel operation using ForkJoinPool. I think BigInteger operations may be a better candidate for such kind of parallelization. For example Karatsuba may be forkjoined naturally. > > > -- > Best regards, > Sergey Kuksenko From david.r.chase at oracle.com Fri May 17 13:45:00 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 May 2013 09:45:00 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> Message-ID: On 2013-05-17, at 4:28 AM, Paul Sandoz wrote: > > On May 17, 2013, at 12:09 AM, David Chase wrote: > >> >> On 2013-05-16, at 5:27 PM, Alan Bateman wrote: >>> The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods? >> >> I'm not sure I understand. > > Alan may be suggesting that the caller should explicitly, but unobtrusively, opt in to parallel execution rather than it being something implicit. Right, but I was responding to this in the context of a compiler bug -- they just wanted CRC32 and Adler32 to go faster, and were not asking for a new interface. My intent/assumption was that if I used the System forkjoin pool for this, that if there were a problem with what I might call "obnoxious parallelism", that the person running the application would turn down the parallelism in the system fork-join pool. If we use forkjoin to make other things go faster (e.g., BigInteger arithmetic and/or formatting) they'll have exactly the same problem, and either they'll have to independently try to deal with it there (in the same way that I worry about whether the CRC/Adler code should be self-throttling) or assume that it will be solved by the same knob being turned (by whoever is tuning the whole application). Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision? Another option is to keep an interface, but add a system property enabling or disabling it. I'm not sure that's the right approach; there is a sun. property that I use to check the tuning, but as soon as FJ is widely used (and perhaps statically baked in to some larger modules, even if we adopt the ask-for-parallel method idiom), those selective-disable properties will multiply like bunnies, and I don't think that's a good idea (documentation, testing, arrgh). > That is the approach we have taken for the Streams API, parallel sort and parallel prefix of arrays in JDK 8 [*]. It's a least surprise principle of libraries "not eating more compute resources unless you ask it to". I think Adler32 and CRC32 should stick to the same principle and require opt in from the caller, thus implying this behaviour cannot be part of the public API in JDK 7. > > Paul. > > [*] In JDK 8 the Arrays.parallelSort methods use an array length threshold of 2^13, arrays <= to that length will be sorted sequentially and arrays > than will be sorted in parallel. IIUC the threshold was chosen to ensure that Arrays.parallelSort is ~ the same as or faster than Arrays.sort. I picked a threshold for 512K for slow CRC and 1M for Adler and fast CRC, in a conservative approximation of the same reasoning. David From chris.hegarty at oracle.com Fri May 17 13:49:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 14:49:05 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <519612EE.4060202@oracle.com> References: <51960C57.9010907@oracle.com> <519612EE.4060202@oracle.com> Message-ID: <51963551.4060706@oracle.com> Thanks Alan, I'll make the changes to the formatting ( add space ), remove the addition of HttpURLPermissionTest, then push the change. -Chris. On 17/05/2013 12:22, Alan Bateman wrote: > On 17/05/2013 11:54, Chris Hegarty wrote: >> There are a few networking tests failing recently. All have bugs >> against them. These bugs will be address shortly, but since tl is >> integrating into master, for b91, next Tuesday, it is best to add them >> to the ProblemList so that the failures don't escape into master. >> >> diff -r 06b410feed49 -r 1e860864089a test/ProblemList.txt >> --- a/test/ProblemList.txt Fri May 17 11:05:43 2013 +0100 >> +++ b/test/ProblemList.txt Fri May 17 11:40:54 2013 +0100 >> @@ -205,6 +205,18 @@ java/net/MulticastSocket/Test.java >> #7143960 >> java/net/DatagramSocket/SendDatagramToBadAddress.java macosx-all >> >> +#8014783 >> +java/net/HttpURLPermission/HttpURLPermissionTest.java windows-all >> + >> +#8014720 >> +java/net/ResponseCache/B6181108.java generic-all >> + >> +#8014723 >> +sun/misc/URLClassPath/ClassnameCharTest.java generic-all >> + >> +#8014719 >> +sun/net/www/http/HttpClient/ProxyTest.java generic-all >> + >> >> -Chris. > For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume > that using try-with-resources around the code that opens the .ser files > will sort this out (meaning might be as quick to just fix this one). > > For the rest then I agree, these need to be excluded until > HttpURLPermission can support proxying of ftp connections. > > The long standing format has been to put a space before the bug number, > I don't know if we have any grep-like tools that depend on that. > > As an aside, we need to re-format this file at some point to put the bug > numbers onto the same line as the test. That's the format that jtreg > prefers and would it be generally more grep-friendly. This needs to be > done in conjunction with taking an axe to jdk/test/Makefile and I think > on Mike's list. > > -Alan From dl at cs.oswego.edu Fri May 17 13:55:02 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 17 May 2013 09:55:02 -0400 (EDT) Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> Message-ID: <56339.67.110.254.77.1368798902.squirrel@altair.cs.oswego.edu> A quick note while travelling... >> [*] In JDK 8 the Arrays.parallelSort methods use an array length >> threshold of 2^13, arrays <= to that length will be sorted sequentially >> and arrays > than will be sorted in parallel. IIUC the threshold was >> chosen to ensure that Arrays.parallelSort is ~ the same as or faster >> than Arrays.sort. > > I picked a threshold for 512K for slow CRC and 1M for Adler and fast CRC, > in a conservative approximation of the same reasoning. > The 8K threshold in sort is in part to avoid memory contention across threads, especially for Object/Reference sort, but also overhead vs throughput tradeoffs. For CRC, my offhand guess is that something closer to 64K would be close to optimal on most machines. Perhaps Aleksey and friends could supply a threshold vs throughput plot on a few machines? -Doug From paul.sandoz at oracle.com Fri May 17 14:07:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 May 2013 16:07:14 +0200 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> Message-ID: <6743ACAD-2CD7-487F-8250-C231C107829D@oracle.com> On May 17, 2013, at 3:45 PM, David Chase wrote: > > On 2013-05-17, at 4:28 AM, Paul Sandoz wrote: > >> >> On May 17, 2013, at 12:09 AM, David Chase wrote: >> >>> >>> On 2013-05-16, at 5:27 PM, Alan Bateman wrote: >>>> The current proposal doesn't change the API at this time but I wonder if you have considered adding parallelUpdate methods to complement the serial methods? >>> >>> I'm not sure I understand. >> >> Alan may be suggesting that the caller should explicitly, but unobtrusively, opt in to parallel execution rather than it being something implicit. > > Right, but I was responding to this in the context of a compiler bug -- they just wanted CRC32 and Adler32 to go faster, and were not asking for a new interface. My intent/assumption was that if I used the System forkjoin pool for this, that if there were a problem with what I might call "obnoxious parallelism", that the person running the application would turn down the parallelism in the system fork-join pool. If we use forkjoin to make other things go faster (e.g., BigInteger arithmetic and/or formatting) they'll have exactly the same problem, and either they'll have to independently try to deal with it there (in the same way that I worry about whether the CRC/Adler code should be self-throttling) or assume that it will be solved by the same knob being turned (by whoever is tuning the whole application). > > Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision? > Right. i.e. it's not the responsibility of solely the JDK to make the decision. > Another option is to keep an interface, but add a system property enabling or disabling it. I'm not sure that's the right approach; there is a sun. property that I use to check the tuning, but as soon as FJ is widely used (and perhaps statically baked in to some larger modules, even if we adopt the ask-for-parallel method idiom), those selective-disable properties will multiply like bunnies, and I don't think that's a good idea (documentation, testing, arrgh). > The parallelism of the F/J common pool in JDK 8 can be configured via system property. Ironically for EE environments probably the simplest thing to do is configure it so that there is no parallelism. Perhaps there needs to be some -X flags for java/javac to explicitly enable the use of F/J in the JDK for the case where explicit API control is not possible or suitable? Paul. From david.r.chase at oracle.com Fri May 17 14:18:58 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 May 2013 10:18:58 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <56339.67.110.254.77.1368798902.squirrel@altair.cs.oswego.edu> References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> <56339.67.110.254.77.1368798902.squirrel@altair.cs.oswego.edu> Message-ID: <40E381A8-8FAB-4D52-81FF-2C5985D9646A@oracle.com> On 2013-05-17, at 9:55 AM, Doug Lea

                  wrote: > A quick note while travelling... > >>> [*] In JDK 8 the Arrays.parallelSort methods use an array length >>> threshold of 2^13, arrays <= to that length will be sorted sequentially >>> and arrays > than will be sorted in parallel. IIUC the threshold was >>> chosen to ensure that Arrays.parallelSort is ~ the same as or faster >>> than Arrays.sort. >> >> I picked a threshold for 512K for slow CRC and 1M for Adler and fast CRC, >> in a conservative approximation of the same reasoning. > > The 8K threshold in sort is in part to avoid memory contention > across threads, especially for Object/Reference sort, but also > overhead vs throughput tradeoffs. For CRC, my offhand guess is > that something closer to 64K would be close to optimal on > most machines. Perhaps Aleksey and friends could supply a > threshold vs throughput plot on a few machines? I would hold off a bit on Aleksey's time; following a tip from David Holmes, I added a call to tryUnfork, and it nicely improved both performance and predictability (why is this not the default? Think of the world of naive users out there, ready to shoot themselves in the foot with whatever new toy we hand them.) My plan is to set a bunch of my crappy benchmarks running on a diversity of machines, and concurrently try to figure out how to use JMH. My informally eyeballed threshold, based on extremely preliminary benchmarking, would be 4x or 8x smaller -- so 128 or 256k for fast CRC and Adler, 64k or 128k for slow CRC (fast CRC is about 2.5x faster than slow CRC). Tend higher on Intel, smaller on Sparc, but I'd prefer not to bake that much platform sensitivity into the code. Note that my informal crappy benchmarking does have one positive attribute -- it takes place on a laptop that is doing lots of other stuff, so though the results are a little noisy, they also reflect exactly the sort of contention for resources that has us a little nervous about willy-nilly use of fork join. So far, so good. David From chris.hegarty at oracle.com Fri May 17 14:22:39 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 17 May 2013 14:22:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130517142318.6ED9548B6D@hg.openjdk.java.net> Changeset: 3981ad7ec458 Author: chegar Date: 2013-05-17 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3981ad7ec458 8014791: More ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: fab0e4b682e8 Author: chegar Date: 2013-05-17 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fab0e4b682e8 Merge ! test/ProblemList.txt - test/java/util/logging/bundlesearch/LoadItUp.java From chris.hegarty at oracle.com Fri May 17 14:40:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 May 2013 15:40:44 +0100 Subject: RFR 8014791: More ProblemList.txt updates (5/2013) In-Reply-To: <519612EE.4060202@oracle.com> References: <51960C57.9010907@oracle.com> <519612EE.4060202@oracle.com> Message-ID: <5196416C.8040608@oracle.com> On 17/05/2013 12:22, Alan Bateman wrote: > .... > For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume > that using try-with-resources around the code that opens the .ser files > will sort this out (meaning might be as quick to just fix this one). For this, I propose to simply replace the use of the file as a holder for the serial byte, with ByteArrayOutputStream. hg diff HttpURLPermissionTest.java diff -r fab0e4b682e8 test/java/net/HttpURLPermission/HttpURLPermissionTest.java --- a/test/java/net/HttpURLPermission/HttpURLPermissionTest.java Fri May 17 15:18:40 2013 +0100 +++ b/test/java/net/HttpURLPermission/HttpURLPermissionTest.java Fri May 17 15:34:54 2013 +0100 @@ -187,11 +187,12 @@ public class HttpURLPermissionTest { throws Exception { HttpURLPermission out = new HttpURLPermission(name, actions); - FileOutputStream fos = new FileOutputStream("out.ser"); - ObjectOutputStream o = new ObjectOutputStream(fos); + + ByteArrayOutputStream baos = new ByteArrayOutputStream(); + ObjectOutputStream o = new ObjectOutputStream(baos); o.writeObject(out); - FileInputStream fis = new FileInputStream("out.ser"); - ObjectInputStream i = new ObjectInputStream(fis); + ByteArrayInputStream bain = new ByteArrayInputStream(baos.toByteArray()); + ObjectInputStream i = new ObjectInputStream(bain); HttpURLPermission in = (HttpURLPermission)i.readObject(); if (!in.equals(out)) { System.out.println ("FAIL"); -Chris. From david.r.chase at oracle.com Fri May 17 14:45:45 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 May 2013 10:45:45 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <6743ACAD-2CD7-487F-8250-C231C107829D@oracle.com> References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> <6743ACAD-2CD7-487F-8250-C231C107829D@oracle.com> Message-ID: On 2013-05-17, at 10:07 AM, Paul Sandoz wrote: >> Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision? >> > > Right. i.e. it's not the responsibility of solely the JDK to make the decision. I don't think I explained my point well enough. There are two ways that this choice can not be the JDK's decision. The choice can be made as a system property setting, externally. Or the choice can be made by the programmer, when they choose, statically and for all uses of their code, to run either in serial or parallel. Suppose we decide that it is a static choice. If I write some package of intermediate size that performs sorts and CRCs and perhaps BigInteger arithmetic, I must choose. If I choose serial, it never runs faster, if I choose parallel, then my clients may discover that my choice causes problems for them, and they need to set the system property anyway. That is, turning the parallelism option into a static choice of method name is not a good way to go; it only works for programming in the small, and in general does not remove the need for the system-properties knob. We get all the burdens of extra interfaces, but little win, maybe even a net loss in larger and more complex systems. The default should be parallel, the default parallel settings should be somewhat conservative but not fully serial, and people will tune if it is necessary. David From chris.hegarty at oracle.com Fri May 17 15:46:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 17 May 2013 15:46:14 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130517154656.85C3548B6F@hg.openjdk.java.net> Changeset: 222da3d4692a Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/222da3d4692a 8014783: java/net/HttpURLPermission/HttpURLPermissionTest.java leaves files open Reviewed-by: michaelm ! test/java/net/HttpURLPermission/HttpURLPermissionTest.java Changeset: fed779a87670 Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fed779a87670 Merge - test/java/util/logging/bundlesearch/LoadItUp.java From paul.sandoz at oracle.com Fri May 17 16:13:03 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 May 2013 18:13:03 +0200 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> <6743ACAD-2CD7-487F-8250-C231C107829D@oracle.com> Message-ID: On May 17, 2013, at 4:45 PM, David Chase wrote: > > On 2013-05-17, at 10:07 AM, Paul Sandoz wrote: >>> Baking it in as a static decision is just kicking the can down the road -- once some module that computes CRCs as part of its larger work chooses serial or parallel, what then, if that module's client doesn't like that decision? >>> >> >> Right. i.e. it's not the responsibility of solely the JDK to make the decision. > > I don't think I explained my point well enough. There are two ways that this choice can not be the JDK's decision. The choice can be made as a system property setting, externally. Or the choice can be made by the programmer, when they choose, statically and for all uses of their code, to run either in serial or parallel. > > Suppose we decide that it is a static choice. If I write some package of intermediate size that performs sorts and CRCs and perhaps BigInteger arithmetic, I must choose. If I choose serial, it never runs faster, if I choose parallel, then my clients may discover that my choice causes problems for them, and they need to set the system property anyway. > > That is, turning the parallelism option into a static choice of method name is not a good way to go; it only works for programming in the small, and in general does not remove the need for the system-properties knob. I agree it does not obviate the need for an external controlling mechanism. The static approach also signals programmer intent. Note that for the Stream API there are further reasons for the explicitness (switching from sequential to parallel is not always transparent in terms of the results produced). > We get all the burdens of extra interfaces, but little win, maybe even a net loss in larger and more complex systems. The default should be parallel, the default parallel settings should be somewhat conservative but not fully serial, and people will tune if it is necessary. > I disagree the default should be parallel (conservative or otherwise) since it can change the usage of compute resources from one release to the next, perhaps in ways that are unpredictable and hard to figure out why. That is arguably distributive for a new platform release and even more so for an update release of 7. Paul. From david.r.chase at oracle.com Fri May 17 16:43:40 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 May 2013 12:43:40 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <51954F37.6080008@oracle.com> <1440C2A3-6677-42A4-8F84-429FE8382101@oracle.com> <6743ACAD-2CD7-487F-8250-C231C107829D@oracle.com> Message-ID: <232A716C-6CE8-4112-84E6-BA2AEDC2D5AB@oracle.com> On 2013-05-17, at 12:13 PM, Paul Sandoz wrote: > On May 17, 2013, at 4:45 PM, David Chase wrote: > >> That is, turning the parallelism option into a static choice of method name is not a good way to go; it only works for programming in the small, and in general does not remove the need for the system-properties knob. > > I agree it does not obviate the need for an external controlling mechanism. > > The static approach also signals programmer intent. Note that for the Stream API there are further reasons for the explicitness (switching from sequential to parallel is not always transparent in terms of the results produced). Different results is not an issue for CRC and Adler. > I disagree the default should be parallel (conservative or otherwise) since it can change the usage of compute resources from one release to the next, perhaps in ways that are unpredictable and hard to figure out why. History is rhyming. I've heard much the same said of GC, caches, virtual memory, and threads. I'm all for conservative default settings for the FJ pool, and if we need a few rarely used parallelism kill switches for hard cases, I think that's acceptable. Proliferating interfaces and forcing programmers to make uninformed static choices about parallelism is not a good plan. > That is arguably distributive for a new platform release and even more so for an update release of 7. The forkjoin work won't backport to 7 because it uses that System FJ pool, so that's not an issue, and the accelerated CRC only backports if we keep the ugly assembly language, because 7 builds with old compilers. I would hope to get rid of that assembly language if we move forward to gcc 2.6, Clang, SolStudio 12.3, and VS 2012. They all claim to support the intrinsics, though at least one of those compilers has bugs that need fixing. David From james.laskey at oracle.com Tue May 14 16:43:37 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 14 May 2013 16:43:37 +0000 Subject: hg: jdk8/tl/nashorn: 17 new changesets Message-ID: <20130514164351.74D8648A78@hg.openjdk.java.net> Changeset: b754fb89367d Author: jlaskey Date: 2013-04-30 10:05 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b754fb89367d 8006220: Simplify PropertyMaps Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java Changeset: 80cb02dedc83 Author: hannesw Date: 2013-05-02 09:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/80cb02dedc83 8013729: SwitchPoint invalidation not working over prototype chain Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8013729.js + test/script/basic/JDK-8013729.js.EXPECTED Changeset: 7563c56ca565 Author: jlaskey Date: 2013-05-02 13:22 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7563c56ca565 8013794: JDK-8006220 caused an octane performance regression. Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ObjectCreator.java Changeset: 9c2376a250b6 Author: jlaskey Date: 2013-05-02 13:23 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9c2376a250b6 Merge Changeset: c8023561505b Author: jlaskey Date: 2013-05-02 15:01 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c8023561505b 8013796: load("fx:base.js") should not be in fx:bootstrap.js Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/bootstrap.js Changeset: 5a3f7867e19c Author: lagergren Date: 2013-05-03 15:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5a3f7867e19c 8013477: Node.setSymbol needs to be copy on write - enable IR snapshots for recompilation based on callsite type specialization. [not enabled by default, hidden by a flag for now] Reviewed-by: jlaskey, hannesw ! bin/jjs ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/Attr.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/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/tools/Shell.java + test/script/basic/paramspec.js + test/script/basic/paramspec.js.EXPECTED ! test/script/basic/runsunspider.js + test/script/currently-failing/logcoverage.js - test/script/trusted/logcoverage.js Changeset: 829b06307fb2 Author: lagergren Date: 2013-05-03 16:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/829b06307fb2 8013871: mem usage histograms enabled with compiler logging level set to more specific than or equals to info when --print-mem-usage flag is used Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/ir/debug/ClassHistogramElement.java + src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/tools/Shell.java Changeset: c0f0033d7b08 Author: hannesw Date: 2013-05-03 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c0f0033d7b08 8013878: ClassCastException in Regex Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8013878.js + test/script/basic/JDK-8013878.js.EXPECTED Changeset: f98d22fa3cbc Author: hannesw Date: 2013-05-03 22:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f98d22fa3cbc 8013873: Regexp regression for escaped dash in character class Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8013873.js + test/script/basic/JDK-8013873.js.EXPECTED Changeset: f3dcb12c8439 Author: hannesw Date: 2013-05-03 22:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f3dcb12c8439 8013874: Function argument's prototype seem cached and wrongly reused Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/PropertyMap.java + test/script/basic/JDK-8013874.js + test/script/basic/JDK-8013874.js.EXPECTED Changeset: 544e17632e96 Author: lagergren Date: 2013-05-07 14:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/544e17632e96 8013913: Removed Source field from all nodes except FunctionNode in order to save footprint Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.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/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/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.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/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/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/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/NativeDebug.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/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java Changeset: fb1d7ea3e1b6 Author: lagergren Date: 2013-05-07 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fb1d7ea3e1b6 8013914: Removed explicit LineNumberNodes that were too brittle when code moves around, and also introduced unnecessary footprint. Introduced the Statement node and fixed dead code elimination issues that were discovered by the absense of labels for LineNumberNodes. Reviewed-by: jlaskey, attila ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.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/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java - src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/Statement.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.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/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/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/no_line_numbers.js + test/script/basic/no_line_numbers.js.EXPECTED Changeset: d28180d97c61 Author: attila Date: 2013-05-08 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d28180d97c61 8013912: Nashorn needs to reuse temporary symbols Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.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/FinalizeTypes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TypeOverride.java Changeset: 18ce1cd3026c Author: attila Date: 2013-05-08 16:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18ce1cd3026c 8014225: Rerun only failed 262 tests Reviewed-by: jlaskey, lagergren ! make/project.properties ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java Changeset: 9073bcc4307b Author: lagergren Date: 2013-05-10 13:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9073bcc4307b 8014329: Slim down the label stack structure in CodeGenerator Reviewed-by: attila, jlaskey ! .hgignore ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java Changeset: 098a4cedcaf2 Author: attila Date: 2013-05-14 12:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/098a4cedcaf2 8014492: Make NashornLinker public Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java Changeset: 264bb0af9e4e Author: jlaskey Date: 2013-05-14 09:05 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/264bb0af9e4e Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js From kirkch at googlemail.com Thu May 16 08:19:46 2013 From: kirkch at googlemail.com (Chris Kirk) Date: Thu, 16 May 2013 09:19:46 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> Message-ID: Dropping some of the accrued baggage would be good. Java has gone an incredible distance without having a clear out. I for one believe that it deserves one. The way that @Retired is being proposed to being used makes me think that I misunderstand the intent of @Deprecated. Doesn't @Deprecated mean, move off of this class/method. It has been superseded here are some notes on what has replaced it. We intend to remove it at some point in the future. If you ignore this warning then you risk having your program break in an upgrade of the library. > > > Interesting suggestions but I for one do not think that after 15 years of > > deprecation we need to go to such lengths to keep stop(Throwable) on > > life-support - it is @Deceased in my opinion :) > > > > Hi David, > > In fact, I fully agree for Thread.stop we should probably just do as > you suggest and kill it :) but my interest shifted to the @Retired > annotation which could be a nice general thing to have (Thread.stop > could actually be a test case for it). > > Ideally, by Java 9, we could go through most of the @Deprecated and > convert them to @Retired and give one platform lifetime to make people > adjust their code. Java 10 could be finally free of all those ancient > vestiges of a glorious past :) > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > From mike.duigou at oracle.com Fri May 17 17:41:15 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 May 2013 10:41:15 -0700 Subject: RFR : 8004015 : (S) Additional Functional Interface instance and static methods In-Reply-To: <5195B3D3.9060004@oracle.com> References: <7998400D-A4F1-45DF-A94F-12BD2C4F4CBD@oracle.com> <5195B3D3.9060004@oracle.com> Message-ID: Thank you for the review David. Some of your suggestions had already been applied in the lambda repo but I've applied the rest and some additional cases (Predicate) that were similar. http://cr.openjdk.java.net/~mduigou/JDK-8004015/1/webrev/ Thanks! Mike On May 16 2013, at 21:36 , David Holmes wrote: > Hi Mike, > > A general comment regarding exceptional behaviour. There are a lot of operations that involve composite operations (compose, andThen, or, and, xor etc) and if the first operation throws an exception the second never gets evaluated. Does this need to be spelled out somewhere or is this obviously the only way it would work ? > > --- > > BiConsumer.java > > 54 * Returns a BiConsumer which performs in sequence the {@code accept} > 55 * methods of multiple BiConsumers. > > It doesn't perform for multiple BiConsumers but only the one specified. That may be chained to another and so forth but each chain operation only relates to a single BiConsumer. You might then simply describe this method as: > > "Returns a BiConsumer which chains this BiConsumer with another BiConsumer. The returned BiConsumer's accept method invokes this BiConsumer's accept method followed by the accept method of the specified BiConsumer." > > --- > > BiFunction.java > > Why is the documentation style for BiFunction.andThen so different to BiConsumer.chain when they effectively do the same thing? Shouldn't andThen be described as: > > "Returns a BiFunction that composes this BiFunction with another BiFunction ..." > > > + * @param after An additional function > > "additional" is superfluous - additional to what? > > --- > > Consumer.java > > Same basic comments as for BiConsumer. > > --- > > Function.java > > Same basic comments as BiFunction. > > --- > > Thanks, > David > > > On 15/05/2013 2:22 PM, Mike Duigou wrote: >> Hello all; >> >> This a fairly small set of additional methods for the existing Java 8 functional interfaces. These methods have been held back until now awaiting support for static interface methods. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8004015/0/webrev/ >> >> Mike >> From dan.xu at oracle.com Fri May 17 19:04:51 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 17 May 2013 19:04:51 +0000 Subject: hg: jdk8/tl/jdk: 8011136: FileInputStream.available and skip inconsistencies Message-ID: <20130517190511.F304148B7B@hg.openjdk.java.net> Changeset: 3b1450ee2bb9 Author: dxu Date: 2013-05-17 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b1450ee2bb9 8011136: FileInputStream.available and skip inconsistencies Summary: Correct the behavior of available() and update related java specs for available() and skip() in InputStream and FileInputStream classes. Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/InputStream.java ! src/share/native/java/io/FileInputStream.c ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/FileInputStream/NegativeAvailable.java From aleksej.efimov at oracle.com Fri May 17 19:34:35 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 17 May 2013 23:34:35 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <518E9F55.6030603@oracle.com> References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com> <517E7982.8060803@oracle.com> <517F6DDB.4020809@oracle.com> <518E9F55.6030603@oracle.com> Message-ID: <5196864B.1040003@oracle.com> Alan, David and other team! Resending the previous RFR 8009581 v.1. It might lost among the pack posts. Best regards, Aleksej On 11.05.2013 23:43, Aleksej Efimov wrote: > Hello Alan, David and other experts, > > I presents the second version of fix for XPathException class for your > review: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.1/ > > The serialized form remains the same in this patch, as was suggested. > I have also done some tests with serialization/deserialization of > XPathException class with different JDK versions. The class serialized > on JDK with patch was successfully deserialized by JDK versions > (6,7,8) without fix and vice versa. > > -Aleksej > > On 04/30/2013 11:08 AM, David Holmes wrote: >> 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 jason_mehrens at hotmail.com Fri May 17 19:59:16 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 17 May 2013 14:59:16 -0500 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <5196864B.1040003@oracle.com> References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com>,<517E7982.8060803@oracle.com> <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com> Message-ID: Aleksej, Should readObject call super.initCause instead of this.initCause? Maybe initCause should be only called if scause != null && super.getCause() == null. If super.getCause is not null initCause will always fail. Jason ---------------------------------------- > Date: Fri, 17 May 2013 23:34:35 +0400 > From: aleksej.efimov at oracle.com > To: core-libs-dev at openjdk.java.net; david.holmes at oracle.com; Alan.Bateman at oracle.com > Subject: Re: RFR 8009581: Xpathexception does not honor initcause() > > Alan, David and other team! > Resending the previous RFR 8009581 v.1. It might lost among the pack posts. > > Best regards, > Aleksej > > On 11.05.2013 23:43, Aleksej Efimov wrote: >> Hello Alan, David and other experts, >> >> I presents the second version of fix for XPathException class for your >> review: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.1/ >> >> The serialized form remains the same in this patch, as was suggested. >> I have also done some tests with serialization/deserialization of >> XPathException class with different JDK versions. The class serialized >> on JDK with patch was successfully deserialized by JDK versions >> (6,7,8) without fix and vice versa. >> >> -Aleksej >> >> On 04/30/2013 11:08 AM, David Holmes wrote: >>> 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 jonathan.gibbons at oracle.com Fri May 17 20:49:09 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 17 May 2013 20:49:09 +0000 Subject: hg: jdk8/tl/langtools: 6885876: add comments to javac/util/Convert.java Message-ID: <20130517204912.98CB448B82@hg.openjdk.java.net> Changeset: 0928f2cfbf8e Author: jjg Date: 2013-05-17 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0928f2cfbf8e 6885876: add comments to javac/util/Convert.java Reviewed-by: mduigou ! src/share/classes/com/sun/tools/javac/util/Convert.java From brian.burkhalter at oracle.com Fri May 17 22:47:51 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 17 May 2013 15:47:51 -0700 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: <51959412.8040401@mindspring.com> References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> <51959412.8040401@mindspring.com> Message-ID: On May 16, 2013, at 7:21 PM, Alan Eliasen wrote: >> I have reviewed this code including verifying all algorithms against >> the references suggested in the code as well as other sources in the >> literature. It all looks to be entirely correct and very clean and >> clear. > > Thanks very much for looking this over, Brian! You're welcome. I really did not expect find any problems but I feel better understanding the algorithms and the implementation insofar as possible. > One minor revision to this revision that I must have missed is that > the added import for java.util.ArrayList is not actually used until > Phase 2, which is improving toString(). (ArrayList is used in the cache > for improving toString radix conversion. I didn't use it anywhere in > multiply() or pow(). ) I have cleaned up the imports. > More below. > >> One change which I have *not* made and which seems appropriate to add >> to this patch is to modify multiply() to use square() if the >> parameter is the BigInteger instance on which the method is invoked, >> i.e., to change this snippet >> >> public BigInteger multiply(BigInteger val) { if (val.signum == 0 || >> signum == 0) return ZERO; >> >> to this >> >> public BigInteger multiply(BigInteger val) { if (val.signum == 0 || >> signum == 0) return ZERO; >> >> if (val == this) return square(); > > That seems like a lightweight but acceptable change to me. I have > discussed this optimization before, and thought it might improve a small > number of cases, but could make the base case of very small non-equal > numbers slightly slower. I haven't benchmarked it; I'd doubt that the > change would even be detectable in most programs, and if it were > triggered, would somewhat improve the performance of certain programs. A quick and dirty benchmark gave these results in operations per millisecond (larger value is faster): Before o.s.m.g.t.MyBenchmark.multiplyLarge 1445.571 o.s.m.g.t.MyBenchmark.multiplySmall 8919.505 o.s.m.g.t.MyBenchmark.squareLarge 1462.645 o.s.m.g.t.MyBenchmark.squareSmall 9018.123 After: multiply(this) returns square() o.s.m.g.t.MyBenchmark.multiplyLarge 1460.300 o.s.m.g.t.MyBenchmark.multiplySmall 8814.362 o.s.m.g.t.MyBenchmark.squareLarge 1518.695 o.s.m.g.t.MyBenchmark.squareSmall 8287.958 The base code was the current JDK 8 tip (sans phase 1 changes) and the only change was to call square() if the parameter to multiply == this. In the above, "small" indicates that everything will fit in a long and "large" that it will not. > I was initially concerned that it might create an infinite loop if > any of the square() functions called multiply() to do the dirty work but > none of them seem to at the moment. I don't see that anywhere in the code either. > The identity comparison is be > reasonably fast and lightweight and constant time. This optimization > wouldn't catch the case where two identical numbers are passed in but > don't point to the same place in memory. It would be more general to > call .equals(Object) but that would have more overhead (in the worst > case, it's O(n) where n is the number of ints in the BigInteger.) I > would probably avoid the latter. I concur. > If you perform .pow(2) it will automatically square the numbers > efficiently and rapidly, but the users won't know that without looking > at the implementation, and there is some slight overhead to using pow() > compared to a public square() method. In the future, the various > squaring routines could benefit from some of the tricks that pow() uses > (that is, detecting powers of two in the number and handling those via > left-shifts.) This behavior would probably want to be factored out into > separate private functions, as it would be useful in pow(), square(), > and potentially in division, as I was recently discussing with Tim Buktu. Sounds like a good idea I would be inclined to leave these changes to some later stage, perhaps a "phase 3.5" or some such. Brian From brian.burkhalter at oracle.com Fri May 17 22:54:35 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 17 May 2013 15:54:35 -0700 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> <51959412.8040401@mindspring.com> Message-ID: <5D19B394-E814-4218-82DB-755AD8ACBAE3@oracle.com> On May 17, 2013, at 3:47 PM, Brian Burkhalter wrote: >> That seems like a lightweight but acceptable change to me. I have >> discussed this optimization before, and thought it might improve a small >> number of cases, but could make the base case of very small non-equal >> numbers slightly slower. I haven't benchmarked it; I'd doubt that the >> change would even be detectable in most programs, and if it were >> triggered, would somewhat improve the performance of certain programs. > > A quick and dirty benchmark gave these results in operations per millisecond (larger value is faster): > > Before > > o.s.m.g.t.MyBenchmark.multiplyLarge 1445.571 > o.s.m.g.t.MyBenchmark.multiplySmall 8919.505 > o.s.m.g.t.MyBenchmark.squareLarge 1462.645 > o.s.m.g.t.MyBenchmark.squareSmall 9018.123 > > After: multiply(this) returns square() > > o.s.m.g.t.MyBenchmark.multiplyLarge 1460.300 > o.s.m.g.t.MyBenchmark.multiplySmall 8814.362 > o.s.m.g.t.MyBenchmark.squareLarge 1518.695 > o.s.m.g.t.MyBenchmark.squareSmall 8287.958 > > The base code was the current JDK 8 tip (sans phase 1 changes) and the only change was to call square() if the parameter to multiply == this. In the above, "small" indicates that everything will fit in a long and "large" that it will not. I sent the above prematurely. The "large" values are sub-Karatsuba level so there is no testing of the new algorithms here. These results imply that values which cannot be dealt with entirely within a long will be sped up or unaffected but the "==" test. The values which can be dealt with within a long are slowed down in these results by approximately 1%. These results do not to my mind militate against making this small change. Brian From brian.burkhalter at oracle.com Fri May 17 23:03:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 17 May 2013 16:03:39 -0700 Subject: RFR: 4837946 - Faster multiplication and exponentiation of large integers In-Reply-To: <660F0894-EE8E-4CA6-AC22-9D9AAD781043@oracle.com> References: <578CF1F6-8ADA-4CB9-B664-3A2238F39D11@oracle.com> <5195E8E7.20500@oracle.com> <660F0894-EE8E-4CA6-AC22-9D9AAD781043@oracle.com> Message-ID: <847A4513-4D60-4D7D-8701-3EA08459C5E4@oracle.com> Sergey / David, Thanks for the observations. I am disinclined at this time to try to modify in any major way the algorithmic changes represented by the four previously identified phases of BigInteger performance improvement. These changes have been in the queue for a very long time so I think it would be best to focus on evaluating and integrating them essentially as-is without risking additional delay by attempting further simultaneous modifications. I would suggest that instead, any other prospective ameliorations be tracked by new issues (enhancement requests). Thanks, Brian On May 17, 2013, at 5:56 AM, David Chase wrote: > There's been a little pushback against that use of forkjoin, though (as the author of the CRC/Adler work it seems like a reasonable idea to me). One worry I have had is that in a larger context we are worried not just about speed, but also about efficiency; using 4 threads for a 3x speedup is in fact "less efficient" than using just 1 thread, but not by a lot. Using 32 threads for a 9x speedup is a good deal less efficient. (And note I am saying "threads", not "tasks", there are good reasons for breaking big jobs down into more tasks than threads, since not all tasks take the same time to finish and the straggler determines the overall time). > > David > > On 2013-05-17, at 4:23 AM, Sergey Kuksenko wrote: > >> Hi Brian, >> >> In the parallel thread I see a new implementation of CRC32 & Adler32. I don't mean new HW intrinsics, I mean parallel operation using ForkJoinPool. I think BigInteger operations may be a better candidate for such kind of parallelization. For example Karatsuba may be forkjoined naturally. >> >> >> -- >> Best regards, >> Sergey Kuksenko > From mike.duigou at oracle.com Fri May 17 23:11:02 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 May 2013 16:11:02 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: <5195A962.1070208@mindspring.com> References: <5195A962.1070208@mindspring.com> Message-ID: <78D6E8DB-EC99-412B-B349-768F8C044C39@oracle.com> On May 16 2013, at 20:52 , Alan Eliasen wrote: > On 05/15/2013 07:17 PM, Mike Duigou wrote: >> Hello all; >> >> This issue was originally part of JDK-8006627 (improve performance of >> UUID parsing/formatting) but was split out because it could be split >> out. I've been working incrementally on pieces of 8006627 as my time >> permits. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >> >> Since the last rev I have made a separate implementation >> Integer.formatUnsignedInteger for use by Integer rather than sharing >> the Long implementation because it's about 30% faster. I suspect the >> benefits would be even greater on a 32-bit VM or 32-bit native >> platform. > > Mike, > > Do your changes affect performance for all radices, or for certain > radices as implied in some issue titles? Only the power of two radicies are improved. > It might be beneficial to coordinate with Brian Burkhalter who is > working on integrating my patches to make BigInteger.toString() much > faster. As you know, BigInteger.toString() partially uses > Long.toString(). I think that BigInteger.toString can be improved a lot. In particular, the key to the optimization in Integer/Long.toString at these radicies was the ability to pre-calculate the size of the required character array. For power of 2 radicies I believe BigInteger could perform best by having it's own implementation. > Improving the performance of Long.toString() will > improve the performance of BigInteger, which is great. However, there > is an empirically-found threshold in BigInteger that might benefit from > re-tuning if Long.toString becomes significantly faster, though. The > threshold is intentionally chosen to be a bit conservative for cases > like this, so re-tuning may not have a huge effect. > > I don't use different thresholds based on the radix, but that's > something to consider in the future if it could improve performance. > Radices that are powers of 2 shouldn't need the recursive improvements > in BigInteger.toString. > > If you let me know if these changes get checked in, I can see if > re-tuning the threshold for BigInteger.toString() can improve > performance even further. > > -- > Alan Eliasen > eliasen at mindspring.com > http://futureboy.us/ From mike.duigou at oracle.com Fri May 17 23:42:13 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 May 2013 16:42:13 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: Hi Martin; There's a bug id we can use for this issue, an old RFE, JDK-6792262. I am working on the internal CCC case.... Thanks, Mike On May 10 2013, at 17:15 , Martin Buchholz wrote: > > > > On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > - Could use a @DataProivder for "CharSequence[] seqs = {" style tests. > > OK, so I went and learned about DataProvider. Not too painful. Added in some uses of bleeding edge lambda stuff as well to pretty up the GetChars test. Webrev refreshed. From mike.duigou at oracle.com Sat May 18 00:37:54 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 May 2013 17:37:54 -0700 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: <485E5539-A98F-43E2-9016-D186EA6DFEC8@oracle.com> Hi Martin, I had failed to notice that you were using 6813523 in your changeset. Since 6792262 is more specific can we switch to using that one? Mike On May 17 2013, at 16:42 , Mike Duigou wrote: > Hi Martin; > > There's a bug id we can use for this issue, an old RFE, JDK-6792262. > > I am working on the internal CCC case.... > > Thanks, > > Mike > > On May 10 2013, at 17:15 , Martin Buchholz wrote: > >> >> >> >> On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: >> - Could use a @DataProivder for "CharSequence[] seqs = {" style tests. >> >> OK, so I went and learned about DataProvider. Not too painful. Added in some uses of bleeding edge lambda stuff as well to pretty up the GetChars test. Webrev refreshed. > From weijun.wang at oracle.com Sat May 18 02:16:13 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 18 May 2013 02:16:13 +0000 Subject: hg: jdk8/tl/jdk: 8012261: update policytool to support java.net.HttpURLPermission Message-ID: <20130518021637.F2CF848B91@hg.openjdk.java.net> Changeset: 0f7aaabed25f Author: weijun Date: 2013-05-18 10:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f7aaabed25f 8012261: update policytool to support java.net.HttpURLPermission Reviewed-by: mullan ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java From chris.hegarty at oracle.com Sat May 18 07:57:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 18 May 2013 08:57:16 +0100 Subject: RFR 8010182: Thread safety of Thread get/setName() Message-ID: <5197345C.9070802@oracle.com> Thread getName and setName are not thread-safe. The "expected" usage is to set a name before starting the thread and only read it thereafter. It is desirable to support the setting of thread name dynamically, mainly for monitoring/management/debugging. The typical scenario is the single-writer, multiple-reader case. So, making name volatile is sufficient. However, setName also sets the native thread name. This is currently restricted to the current thread, since there could be a race if the thread is terminating. Making setName synchronized would eliminate that race, and allow for the native thread name to be set from other threads. This issue came up on c-i a while back [1]. http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ -Chris. [1] http://cs.oswego.edu/pipermail/concurrency-interest/2013-March/010935.html From mike.duigou at oracle.com Sun May 19 01:58:34 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sun, 19 May 2013 01:58:34 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20130519020304.C0B5148B9F@hg.openjdk.java.net> Changeset: e8b40b034fcd Author: psandoz Date: 2013-05-15 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b40b034fcd 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit Summary: this changeset also contains some minor, non spec, related fixes to tidy up other areas of the JavaDoc. Reviewed-by: plevart, darcy Contributed-by: John Rose , Mike Duigou , Paul Sandoz ! src/share/classes/java/util/Spliterator.java Changeset: 6bbc2816d936 Author: psandoz Date: 2013-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bbc2816d936 8014133: Spliterator.OfPrimitive Reviewed-by: mduigou, forax Contributed-by: Paul Sandoz , Brian Goetz ! src/share/classes/java/util/Spliterator.java Changeset: dc5cf74c8c9c Author: mduigou Date: 2013-05-17 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc5cf74c8c9c 8004015: Additional static and instance utils for functional interfaces. 8011010: Spec j.u.f.Predicate doesn't specify NPEs thrown by the SE8's Reference Implementation Reviewed-by: briangoetz, dholmes, chegar ! src/share/classes/java/util/function/BiConsumer.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BooleanSupplier.java ! src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/ObjDoubleConsumer.java ! src/share/classes/java/util/function/ObjIntConsumer.java ! src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java ! src/share/classes/java/util/function/ToDoubleFunction.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/ToIntFunction.java ! src/share/classes/java/util/function/ToLongBiFunction.java ! src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 23e75751554a Author: henryjen Date: 2013-05-09 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23e75751554a 8006884: (fs) Add Files.list, lines and find Reviewed-by: briangoetz, mduigou Contributed-by: alan.bateman at oracle.com, henry.jen at oracle.com + src/share/classes/java/nio/file/FileTreeIterator.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/FaultyFileSystem.java ! test/java/nio/file/Files/PassThroughFileSystem.java + test/java/nio/file/Files/StreamTest.java Changeset: b9b26b424bfc Author: mduigou Date: 2013-05-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9b26b424bfc Merge From pdoubleya at gmail.com Sun May 19 11:39:28 2013 From: pdoubleya at gmail.com (Patrick Wright) Date: Sun, 19 May 2013 13:39:28 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> <5194AED4.1090101@oracle.com> <5194CA79.6000004@oracle.com> Message-ID: On Thu, May 16, 2013 at 4:38 PM, Paul Sandoz wrote: > > How about doing a search for usages in all the jars on maven central? > > IMHO it really helps drive the discussions deprecation if we have some > empirical data. > > Paul. If memory serves, Joe Darcy and the Project Coin expert group performed research on a large body of Java code to judge the impact/risk of some PC changes - it's mentioned, for example, in this document http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html (search for "corpus"). Perhaps Joe or one of the people involved in Project Coin could say whether there is any existing infrastructure to perform further ad-hoc searches on the corpus. Patrick PS - It would be great if this were standard practice in these discussions - perhaps someone can sponsor a summer of code project to set it up. Doesn't seem like rocket science... From dawid.weiss at gmail.com Sun May 19 14:38:16 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sun, 19 May 2013 16:38:16 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <519349BA.1010501@geomatys.fr> <519395F5.8080502@univ-mlv.fr> <51945D67.3070000@oracle.com> <5194AED4.1090101@oracle.com> <5194CA79.6000004@oracle.com> Message-ID: > PS - It would be great if this were standard practice in these discussions > - perhaps someone can sponsor a summer of code project to set it up. I've created an issue on MVNCENTRAL (https://issues.sonatype.org/browse/MVNCENTRAL-320) -- wondering if there's a (legal and clean) way to get all that data. Setting up a search index or something would be trivial (and interesting I think). Dawid From Alan.Bateman at oracle.com Sun May 19 16:50:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 May 2013 17:50:28 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: Message-ID: <519902D4.1010305@oracle.com> On 16/05/2013 15:50, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/ > > problem: Some applications spend a surprising amount of time computing CRC32s > (Not sure I'm supposed to be precise on an open mailing list). Recent Intel > architectures provide instructions that might be useful in addressing this. > > See https://jbs.oracle.com/bugs/browse/JDK-7088419 > > I turned this into a general attack on performance in Adler32 and CRC32, partly because the bug report was not clear on the size of the problematic inputs. The general approach turned out to be useful, because it's tricky to get the small-case overheads down for the accelerated-instruction version of the code. > I took a second pass over the webrev. If we've going to have assembly in CRC32.c then it makes me wonder if this should be the place to probe if CLMUL is supported. Clearly there may be others cases where the VM needs to probe too but I'm just wondering if the capability really needs to be communicated via a property (at least for now). The other thing that comes to mind is whether we could re-write it in java in a way that allows C2 to generate code that uses CLMUL. I realize that is probably a much bigger effort but I can imagine other cases (like crypto where it could be useful too). On using Unsafe to get the alignment then you can use Unsafe.getUnsafe() rather than reflection. On my comment about whether a parallelUpdate method has been considered then my personal view this would make it obvious when looking at the code. That is, have the long standing update methods be serial by default and introduce new parallelUpdate methods. For existing code then you could have the system property to opt-in to be parallel when the input length is over the threshold (and that should okay to backport to jdk7u if needed). -Alan. From martinrb at google.com Sun May 19 20:20:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 19 May 2013 13:20:19 -0700 Subject: Add getChars to CharSequence In-Reply-To: <485E5539-A98F-43E2-9016-D186EA6DFEC8@oracle.com> References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> <485E5539-A98F-43E2-9016-D186EA6DFEC8@oracle.com> Message-ID: On Fri, May 17, 2013 at 5:37 PM, Mike Duigou wrote: > Hi Martin, > > I had failed to notice that you were using 6813523 in your changeset. > Since 6792262 is more specific can we switch to using that one? > > Done. From martinrb at google.com Sun May 19 20:25:22 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 19 May 2013 13:25:22 -0700 Subject: Add getChars to CharSequence In-Reply-To: <518D7E07.6070308@oracle.com> References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> <518D7E07.6070308@oracle.com> Message-ID: On Fri, May 10, 2013 at 4:08 PM, Joe Darcy wrote: > On 05/10/2013 03:03 PM, Martin Buchholz wrote: > >> On Wed, May 8, 2013 at 5:30 PM, Mike Duigou >> wrote: >> >> - There's been some informal discussion of packaging commonly used test >>> utils as jtreg @library. This could be a good candidate. >>> ArraysCharSequence >>> is a candidate for testing utils lib. Basic impls that override no >>> defaults >>> are going to be increasingly important for testing. >>> >>> - I like your varargs assertsThrows. I have written a non-varargs one in >>> test/.../Map/Defaults.java. Your varargs one of necessity violates the >>> actual, expected, [message] pattern used by other TestNG assertions but I >>> prefer it. This is also a candidate for utils lib. >>> >>> >>> It's good to see internal jdk support libraries emerging. That has >> been an >> historic problem. >> I can relocate assertThrows and ArrayCharSequence if we can agree on a >> location. >> They both seem to belong in a jdk-wide location. >> >> assertThrows was adapted from a method of the same name in Doug's CVS, >> where it's still being used with junit. >> > > I think it would be a fine idea is we started putting such utilities into > a new JDK-specific package like, "jdk.testing". In the source tree I see: test/lib/testlibrary/jdk/testlibrary but I don't see where that's blessed (via e.g. a README) as __the__ place to put common testing infrastructure. From martinrb at google.com Sun May 19 20:33:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 19 May 2013 13:33:19 -0700 Subject: Add getChars to CharSequence In-Reply-To: <518B98D6.40303@oracle.com> References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> <518B98D6.40303@oracle.com> Message-ID: On Thu, May 9, 2013 at 5:38 AM, Alan Bateman wrote: > On 08/05/2013 23:05, Martin Buchholz wrote: > >> Alan (et al): Ping. >> >> I've looked through the webrev. > > The scary part is subsequenceRaw where the offsets including the position. > I don't see anything obviously wrong and the tests should catch any issues. > I don't see any issue conditionally generating the isDirect/order methods > although it should been harmless. > Yes, it's scary, but it's much scarier to me carrying around relative positions than absolute because position() can change at any time if there is a data race. So after bounds checking we must work with absolute positions, or at least must when working with Unsafe. --- Existing code is a little schizoid about checking for the possibility of limit() < position(), as can happen with a data race. Sometimes checked; sometimes not. Sometimes assert()ed. Sometimes adjusted. Probably the right thing is to check and throw ConcurrentModificationException if detected. But not in this changeset. int pos = this.position(); int lim = this.limit(); assert (pos <= lim); int rem = (pos <= lim ? lim - pos : 0); From david.r.chase at oracle.com Mon May 20 01:24:16 2013 From: david.r.chase at oracle.com (David Chase) Date: Sun, 19 May 2013 21:24:16 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <519902D4.1010305@oracle.com> References: <519902D4.1010305@oracle.com> Message-ID: <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> On 2013-05-19, at 12:50 PM, Alan Bateman wrote: > On 16/05/2013 15:50, David Chase wrote: >> webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/ >> >> problem: Some applications spend a surprising amount of time computing CRC32s >> (Not sure I'm supposed to be precise on an open mailing list). Recent Intel >> architectures provide instructions that might be useful in addressing this. >> >> See https://jbs.oracle.com/bugs/browse/JDK-7088419 >> >> I turned this into a general attack on performance in Adler32 and CRC32, partly because the bug report was not clear on the size of the problematic inputs. The general approach turned out to be useful, because it's tricky to get the small-case overheads down for the accelerated-instruction version of the code. >> > I took a second pass over the webrev. If we've going to have assembly in CRC32.c then it makes me wonder if this should be the place to probe if CLMUL is supported. Clearly there may be others cases where the VM needs to probe too but I'm just wondering if the capability really needs to be communicated via a property (at least for now). The other thing that comes to mind is whether we could re-write it in java in a way that allows C2 to generate code that uses CLMUL. I realize that is probably a much bigger effort but I can imagine other cases (like crypto where it could be useful too). The reason for passing it through as a property is two-fold. First, it's a mess of code to probe that property, and I'd rather not duplicate it. Second, for better of worse, right now we have command-line flags to disable the use of these hardware features, for example -XX:-UseCLMUL, -XX:-UseAES. Routing this through the jvm and a property means that it all goes together. I think it would be a Big Deal to get this working through the compiler in any quick way, but it's being discussed for the future. I tried using the Magic Instruction in simpler idioms, and it was slower, not faster. We also need to be certain of alignment, and that's not possible in the current Unsafe interface (the code that you see there is making a best-effort guess). Also, the reason the assembly language is there is not because it is technically necessary, but rather because we get our build compilers (at least for now, I think it will change soon) from the software museum. I compiled the C version of the algorithm with clang, and with gcc 4.6, and (almost) with Solaris Studio 12.3. Visual Studio 12, the one we're not using yet, also claims to process those intrinsics, though I have not tested it yet. > On using Unsafe to get the alignment then you can use Unsafe.getUnsafe() rather than reflection. Okay, I'll get to that. > On my comment about whether a parallelUpdate method has been considered then my personal view this would make it obvious when looking at the code. That is, have the long standing update methods be serial by default and introduce new parallelUpdate methods. For existing code then you could have the system property to opt-in to be parallel when the input length is over the threshold (and that should okay to backport to jdk7u if needed). I don't like this approach for several reasons. First, we're not done finding places that fork-join parallelism can make things go faster. If, each time we find a new one, we must split it into the parallel and serial versions, we're going to get a tiresome proliferation of interfaces. We'll need to document, test, etc, and programmers will need to spend time choosing "the right one" for each application. This will be another opportunity to split application source bases into "old" and "new" -- these chances are always there, but why add more? Second, this doesn't actually address the bug. This was done for a bug, they want CRC32 to go faster in various places, some of them open source. They were not looking for a different faster CRC, they were looking for the same CRC to go faster. They don't want to edit their source code or split their source base, and as we all know, Java doesn't have #ifdef. Third, I've done a fair amount of benchmarking, one with "unlimited" fork join running down to relatively small task sizes, the other with fork-join capped at 4 threads (or in one case, 2 threads) of parallelism. Across a range of inputs and block sizes I checked the efficiency, meaning the departure from ideal speedup (2x or 4x). For 4M or larger inputs, across a range of machines, with parallelism capped at 2 (laptop, and single-split fork-joins) or 4, efficiency never dropped below 75%. The machines ranged from a core-i5 laptop, to an old T1000, to various Intel boxes, to a good-sized T4. Out of 216 runs (9 machines, inputs 16M/8M/4M, task sizes 32K to 8M), 10 runs had efficiency 75% <= eff < 80% 52 runs, 80% <= eff < 90% 139 runs, 90% <= eff < 110% 15 runs had superlinear speedup of 110% or better "efficiency" (I checked for noisy data, it was not noisy). We can pick a minimum-parallel size that will pretty much assure no inefficient surprises (I think it is 4 megabytes, but once committed to FJ, it looks like a good minimum task size is 128k), and there's a knob for controlling fork-join parallelism if people are in an environment where they noticed these momentary surprises and care (a T-1000/Niagara does about 9 serial 16M CRC32s per second, so it's not a long-lived blip). If necessary/tasteful, we can add a knob for people who want more parallelism than that. If it's appropriate to put the benchmarks (PDF) in a public place, I can do that. Fourth, I think there's actually a bit of needing to lead by example. If we treat fork/join parallelism as something that is so risky and potentially destabilizing that parallelized algorithms deserve their own interface, then what will other people think? I've got plenty of concerns about efficient use of processors, but I also checked what happens if the forkjoin pool is throttled, and it works pretty well. David From david.holmes at oracle.com Mon May 20 02:06:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2013 12:06:22 +1000 Subject: Trivial RFR: 8014857 Enable ergonomic VM selection in arm/jvm.cfg Message-ID: <5199851E.1060304@oracle.com> The contents of the ARM jvm.cfg were put in place for the SE Embedded product, but for the SE ARM implementation we want to enable ergonomics, as we do on other platforms. http://cr.openjdk.java.net/~dholmes/8014857/webrev/ --- old/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:30.424314843 -0400 +++ new/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:29.192246170 -0400 @@ -30,6 +30,6 @@ # "-XXaltjvm=" option, but that too is unsupported # and may not be available in a future release. # --client KNOWN +-client IF_SERVER_CLASS -server -server KNOWN -minimal KNOWN Tested VM selection on both server class and non-server class devices. Thanks, David From david.holmes at oracle.com Mon May 20 03:58:45 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 20 May 2013 03:58:45 +0000 Subject: hg: jdk8/tl/jdk: 8014477: (str) Race condition in String.contentEquals when comparing with StringBuffer Message-ID: <20130520035909.51B0A48BAE@hg.openjdk.java.net> Changeset: 08ebdb2b53cc Author: plevart Date: 2013-05-17 14:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08ebdb2b53cc 8014477: (str) Race condition in String.contentEquals when comparing with StringBuffer Reviewed-by: alanb, mduigou, dholmes ! src/share/classes/java/lang/String.java + test/java/lang/String/StringContentEqualsBug.java From david.holmes at oracle.com Mon May 20 05:48:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2013 15:48:41 +1000 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended Message-ID: <5199B939.105@oracle.com> The change put through for JDK-8013395 (StringBuffer toString cache) has exposed a previously unnoticed bug in the StringBuffer.append(CharSequence cs) method. That method claimed to achieve synchronization (and then correct toStringCache behaviour) by the super.append method calling other StringBuffer methods after narrowing of cs to a specific type. But that is incorrect if cs==null as in that case the AbstractStringBuilder.appendNull method is called directly, with no calls to an overridden StringBuffer method. (I have verified that none of the other methods claiming to not need sync suffer from a similar flaw - this is an isolated case.) Consequently we started failing some existing append(null) tests. The fix is quite simple: append(CharSequence) behaves as for other append methods and is declared synchronized and clears the cache explicitly. The existing test is extended to check append(null). webrev: http://cr.openjdk.java.net/~dholmes/8014814/webrev/ This fix does mean that recursive synchronization will now be used for append(CharSequence) but recursive synchronization is very cheap. An alternative fix suggested by Alan Bateman in the bug report is to override appendNull and add the synchronization there. That requires a change to the accessibility of AbstractStringBuilder.appendNull so I chose the more constrained fix. Alan's fix will also introduce nested synchronization, but only for the append(null) case. As I said I don't think performance will be a concern here. Testing (in progress): JPRT -testset core, SQE test that caught this Thanks, David From martinrb at google.com Mon May 20 06:25:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 19 May 2013 23:25:30 -0700 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <5199B939.105@oracle.com> References: <5199B939.105@oracle.com> Message-ID: Note that my pending change http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch does the same kind of thing, but without recursive lock acquisitions. I'm curious why a recursive lock acquisition would be considered "very" cheap. Is there some hotspot magic, or is it simply that we have another write to a cache line that is already probably owned by the cpu by virtue of the previous cas to acquire? On Sun, May 19, 2013 at 10:48 PM, David Holmes wrote: > The change put through for JDK-8013395 (StringBuffer toString cache) has > exposed a previously unnoticed bug in the StringBuffer.append(**CharSequence > cs) method. That method claimed to achieve synchronization (and then > correct toStringCache behaviour) by the super.append method calling other > StringBuffer methods after narrowing of cs to a specific type. But that is > incorrect if cs==null as in that case the AbstractStringBuilder.**appendNull > method is called directly, with no calls to an overridden StringBuffer > method. (I have verified that none of the other methods claiming to not > need sync suffer from a similar flaw - this is an isolated case.) > > Consequently we started failing some existing append(null) tests. > > The fix is quite simple: append(CharSequence) behaves as for other append > methods and is declared synchronized and clears the cache explicitly. The > existing test is extended to check append(null). > > webrev: > > http://cr.openjdk.java.net/~**dholmes/8014814/webrev/ > > This fix does mean that recursive synchronization will now be used for > append(CharSequence) but recursive synchronization is very cheap. An > alternative fix suggested by Alan Bateman in the bug report is to override > appendNull and add the synchronization there. That requires a change to the > accessibility of AbstractStringBuilder.**appendNull so I chose the more > constrained fix. Alan's fix will also introduce nested synchronization, but > only for the append(null) case. As I said I don't think performance will be > a concern here. > > Testing (in progress): JPRT -testset core, SQE test that caught this > > Thanks, > David > From peter.levart at gmail.com Mon May 20 07:16:22 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 20 May 2013 09:16:22 +0200 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <5199B939.105@oracle.com> References: <5199B939.105@oracle.com> Message-ID: <5199CDC6.90406@gmail.com> On 05/20/2013 07:48 AM, David Holmes wrote: > The change put through for JDK-8013395 (StringBuffer toString cache) > has exposed a previously unnoticed bug in the > StringBuffer.append(CharSequence cs) method. That method claimed to > achieve synchronization (and then correct toStringCache behaviour) by > the super.append method calling other StringBuffer methods after > narrowing of cs to a specific type. But that is incorrect if cs==null > as in that case the AbstractStringBuilder.appendNull method is called > directly, with no calls to an overridden StringBuffer method. (I have > verified that none of the other methods claiming to not need sync > suffer from a similar flaw - this is an isolated case.) > > Consequently we started failing some existing append(null) tests. > > The fix is quite simple: append(CharSequence) behaves as for other > append methods and is declared synchronized and clears the cache > explicitly. The existing test is extended to check append(null). > > webrev: > > http://cr.openjdk.java.net/~dholmes/8014814/webrev/ > > This fix does mean that recursive synchronization will now be used for > append(CharSequence) but recursive synchronization is very cheap. An > alternative fix suggested by Alan Bateman in the bug report is to > override appendNull and add the synchronization there. That requires a > change to the accessibility of AbstractStringBuilder.appendNull so I > chose the more constrained fix. Alan's fix will also introduce nested > synchronization, but only for the append(null) case. As I said I don't > think performance will be a concern here. Hi David, Alan, The third possibility could be the following AbstractStringBuilder.append(CharSequence) method: public AbstractStringBuilder append(CharSequence s) { if (s == null || s instanceof String) return this.append((String)s); if (s instanceof AbstractStringBuilder) return this.append((AbstractStringBuilder)s); return this.append(s, 0, s.length()); } ... and no synchronization in StringBuffer.append(CharSequence)... Regards, Peter > > Testing (in progress): JPRT -testset core, SQE test that caught this > > Thanks, > David From peter.levart at gmail.com Mon May 20 07:25:19 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 20 May 2013 09:25:19 +0200 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <5199CDC6.90406@gmail.com> References: <5199B939.105@oracle.com> <5199CDC6.90406@gmail.com> Message-ID: <5199CFDF.5000008@gmail.com> On 05/20/2013 09:16 AM, Peter Levart wrote: > On 05/20/2013 07:48 AM, David Holmes wrote: >> The change put through for JDK-8013395 (StringBuffer toString cache) >> has exposed a previously unnoticed bug in the >> StringBuffer.append(CharSequence cs) method. That method claimed to >> achieve synchronization (and then correct toStringCache behaviour) by >> the super.append method calling other StringBuffer methods after >> narrowing of cs to a specific type. But that is incorrect if cs==null >> as in that case the AbstractStringBuilder.appendNull method is called >> directly, with no calls to an overridden StringBuffer method. (I have >> verified that none of the other methods claiming to not need sync >> suffer from a similar flaw - this is an isolated case.) >> >> Consequently we started failing some existing append(null) tests. >> >> The fix is quite simple: append(CharSequence) behaves as for other >> append methods and is declared synchronized and clears the cache >> explicitly. The existing test is extended to check append(null). >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8014814/webrev/ >> >> This fix does mean that recursive synchronization will now be used >> for append(CharSequence) but recursive synchronization is very cheap. >> An alternative fix suggested by Alan Bateman in the bug report is to >> override appendNull and add the synchronization there. That requires >> a change to the accessibility of AbstractStringBuilder.appendNull so >> I chose the more constrained fix. Alan's fix will also introduce >> nested synchronization, but only for the append(null) case. As I said >> I don't think performance will be a concern here. > > Hi David, Alan, > > The third possibility could be the following > AbstractStringBuilder.append(CharSequence) method: > > > public AbstractStringBuilder append(CharSequence s) { > if (s == null || s instanceof String) > return this.append((String)s); > if (s instanceof AbstractStringBuilder) > return this.append((AbstractStringBuilder)s); > > return this.append(s, 0, s.length()); > } > > > ... and no synchronization in StringBuffer.append(CharSequence)... > > Regards, Peter But I don't know if the fix for "8010849: (str) Optimize StringBuilder.append(null)" is affected by above change (it would introduce a call-site with dispatch to two subclasses for the null value case in append(CharSequence))... Regards, Peter > >> >> Testing (in progress): JPRT -testset core, SQE test that caught this >> >> Thanks, >> David > From Alan.Bateman at oracle.com Mon May 20 07:33:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 May 2013 08:33:10 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> Message-ID: <5199D1B6.8080303@oracle.com> On 20/05/2013 02:24, David Chase wrote: > : > > I don't like this approach for several reasons. > > First, we're not done finding places that fork-join parallelism can make things go faster. If, each time we find a new one, we must split it into the parallel and serial versions, we're going to get a tiresome proliferation of interfaces. We'll need to document, test, etc, and programmers will need to spend time choosing "the right one" for each application. This will be another opportunity to split application source bases into "old" and "new" -- these chances are always there, but why add more? > > Second, this doesn't actually address the bug. This was done for a bug, they want CRC32 to go faster in various places, some of them open source. They were not looking for a different faster CRC, they were looking for the same CRC to go faster. They don't want to edit their source code or split their source base, and as we all know, Java doesn't have #ifdef. > > Third, I've done a fair amount of benchmarking, one with "unlimited" fork join running down to relatively small task sizes, the other with fork-join capped at 4 threads (or in one case, 2 threads) of parallelism. Across a range of inputs and block sizes I checked the efficiency, meaning the departure from ideal speedup (2x or 4x). For 4M or larger inputs, across a range of machines, with parallelism capped at 2 (laptop, and single-split fork-joins) or 4, efficiency never dropped below 75%. The machines ranged from a core-i5 laptop, to an old T1000, to various Intel boxes, to a good-sized T4. > > Out of 216 runs (9 machines, inputs 16M/8M/4M, task sizes 32K to 8M), > 10 runs had efficiency 75%<= eff< 80% > 52 runs, 80%<= eff< 90% > 139 runs, 90%<= eff< 110% > 15 runs had superlinear speedup of 110% or better "efficiency" (I checked for noisy data, it was not noisy). > > We can pick a minimum-parallel size that will pretty much assure no inefficient surprises (I think it is 4 megabytes, but once committed to FJ, it looks like a good minimum task size is 128k), and there's a knob for controlling fork-join parallelism if people are in an environment where they noticed these momentary surprises and care (a T-1000/Niagara does about 9 serial 16M CRC32s per second, so it's not a long-lived blip). If necessary/tasteful, we can add a knob for people who want more parallelism than that. > > If it's appropriate to put the benchmarks (PDF) in a public place, I can do that. > > Fourth, I think there's actually a bit of needing to lead by example. If we treat fork/join parallelism as something that is so risky and potentially destabilizing that parallelized algorithms deserve their own interface, then what will other people think? I've got plenty of concerns about efficient use of processors, but I also checked what happens if the forkjoin pool is throttled, and it works pretty well. > > David > I think we need to get more experience with parallel operations before considering changing the default behavior of long standing methods. This it why I am suggesting this should be opt-in, meaning you run with something like -Djdk.enableParallelCRC32Update=true to have the existing methods use FJ. Having it opt-in rather than opt-out would also reduce concerns if this is proposed to be back-ported to jdk7u. I don't have an opinion as to whether other tuning knobs are required. At this point, we have Arrays.parallelSort and the Streams API defines the parallel() method to get a stream that is parallel. Having the word "parallel" in the code means it is clear and obvious when reading the code (no surprises). Maybe going forward that this will be unnecessary, meaning it will be transparent. For now though, I think we should at least consider adding parallelUpdate methods. -Alan. From david.holmes at oracle.com Mon May 20 07:44:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2013 17:44:49 +1000 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: References: <5199B939.105@oracle.com> Message-ID: <5199D471.20903@oracle.com> On 20/05/2013 4:25 PM, Martin Buchholz wrote: > Note that my pending change > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch > does the same kind of thing, but without recursive lock acquisitions. I will take a look. > I'm curious why a recursive lock acquisition would be considered "very" > cheap. Is there some hotspot magic, or is it simply that we have > another write to a cache line that is already probably owned by the cpu > by virtue of the previous cas to acquire? Yes "hotspot magic". Acquiring a lock you already own doesn't require a CAS; and if it is locked via biased-locking then it is an even shorter path. Thanks, David > > On Sun, May 19, 2013 at 10:48 PM, David Holmes > wrote: > > The change put through for JDK-8013395 (StringBuffer toString cache) > has exposed a previously unnoticed bug in the > StringBuffer.append(__CharSequence cs) method. That method claimed > to achieve synchronization (and then correct toStringCache > behaviour) by the super.append method calling other StringBuffer > methods after narrowing of cs to a specific type. But that is > incorrect if cs==null as in that case the > AbstractStringBuilder.__appendNull method is called directly, with > no calls to an overridden StringBuffer method. (I have verified that > none of the other methods claiming to not need sync suffer from a > similar flaw - this is an isolated case.) > > Consequently we started failing some existing append(null) tests. > > The fix is quite simple: append(CharSequence) behaves as for other > append methods and is declared synchronized and clears the cache > explicitly. The existing test is extended to check append(null). > > webrev: > > http://cr.openjdk.java.net/~__dholmes/8014814/webrev/ > > > This fix does mean that recursive synchronization will now be used > for append(CharSequence) but recursive synchronization is very > cheap. An alternative fix suggested by Alan Bateman in the bug > report is to override appendNull and add the synchronization there. > That requires a change to the accessibility of > AbstractStringBuilder.__appendNull so I chose the more constrained > fix. Alan's fix will also introduce nested synchronization, but only > for the append(null) case. As I said I don't think performance will > be a concern here. > > Testing (in progress): JPRT -testset core, SQE test that caught this > > Thanks, > David > > From peter.levart at gmail.com Mon May 20 09:12:46 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 20 May 2013 11:12:46 +0200 Subject: Add getChars to CharSequence In-Reply-To: References: <5167151C.6090601@CoSoCo.de> <517609F4.20308@CoSoCo.de> <5177133D.60309@CoSoCo.de> Message-ID: <5199E90E.1080805@gmail.com> On 05/09/2013 02:30 AM, Mike Duigou wrote: > Hi Martin; > > Some notes from a non-exhaustive (ran out of time before dinner) review. > > Mike > > AbstractStringBuilder:: > > - The impls like insert(int dstOffset, CharSequence s) makes me slightly uneasy because the private value field escapes to an unknown class. Who knows what evil (or foolishness) could result? Hi Martin, Another consequence of the change should be considered carefully. Currently methods like append/insert taking String, StringBuffer, StringBuilder or CharSequence arguments are a mix of implementations where one set of them are invoking .getChars() on the argument, and other are iterating explicitly over the characters of the argument (those taking CharSequence and not doing delegation to more specific ones). The proposed patch makes use of CharSequence.getChars() in the later ones too. What changes? Synchronization. When StringBuffer is passed into such method and synchronized .getChars() is invoked, another object monitor is acquired where it was not previously. This could be considered more correct, since the view of the StringBuffer argument is locked for the time the characters are obtained from it, (not entirely correct though, see below), but could this provoke a deadlock in a situation where it didn't before? Use-cases that first come to mind are cases that are plagued with races in current implementation anyway, so they are bugs already. But for valid cases, the additional synchronization is still not enough. For example, the proposed changed implementation of the following method in AbstractStringBuilder: 1052 public AbstractStringBuilder insert(int dstOffset, CharSequence s) { 1053 int tail = count - dstOffset; 1054 if ((dstOffset | tail) < 0) 1055 throw new StringIndexOutOfBoundsException(dstOffset); 1056 if (s == null) 1057 s = "null"; 1058 int len = s.length(); 1059 ensureCapacityInternal(count + len); 1060 System.arraycopy(value, dstOffset, value, dstOffset + len, tail); 1061 s.getChars(value, dstOffset); 1062 count += len; 1063 return this; 1064 } ...is still not entirely correct. If it is invoked with a StringBuffer argument when a concurrent thread is modifying it, the s.length() can be different from the actual length at the time the s.getChars() is called and consequently, IndexOutOfBoundsException can be thrown or characters can be overwritten unintentionally. Regards, Peter > > > Direct-X-Buffer.java:: > > - +#if[rw] public boolean isDirect() : Why would this be conditionalized with rw? > > > Heap-X-Buffer.java:: > > - protected -> private int ix(int i) : Is Alan OK with this change. I've mostly avoided these templates. :-) > > > X-Buffer.java.template:: > > - toString() could use the JavaLangAccess.newUnsafeString() constructor! > > - I prefer your formatting of "return bigEndian ?". > > > test/.../GetChars:: > > - Great to see you've already adopted using TestNG for JTReg tests! > > - ArraysCharSequence.hashCode() could have been Arrays.hashcode(chars) or not implemented at all. > > - Could use a @DataProivder for "CharSequence[] seqs = {" style tests. > > - There's been some informal discussion of packaging commonly used test utils as jtreg @library. This could be a good candidate. ArraysCharSequence is a candidate for testing utils lib. Basic impls that override no defaults are going to be increasingly important for testing. > > - I like your varargs assertsThrows. I have written a non-varargs one in test/.../Map/Defaults.java. Your varargs one of necessity violates the actual, expected, [message] pattern used by other TestNG assertions but I prefer it. This is also a candidate for utils lib. > > On May 1 2013, at 15:19 , Martin Buchholz wrote: > >> Another version of this change is ready. No longer preliminary. Tests >> have been written. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/ >> >> This kind of change is particularly subject to feature creep, and I am >> trying to restrain myself. >> >> I even addressed some of Ulf's suggestions. >> The "Msg" suffix is gone. >> I reverted changes to AbstractStringBuilder.replace. >> I kept the naming convention for getChars parameter names. >> Parameter names and exception details continue to be maddeningly >> unsystematic, but they should be a little better than before. From david.r.chase at oracle.com Mon May 20 09:16:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 05:16:51 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <5199D1B6.8080303@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> Message-ID: <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> On 2013-05-20, at 3:33 AM, Alan Bateman wrote: > I think we need to get more experience with parallel operations before considering changing the default behavior of long standing methods. This it why I am suggesting this should be opt-in, meaning you run with something like -Djdk.enableParallelCRC32Update=true to have the existing methods use FJ. Having it opt-in rather than opt-out would also reduce concerns if this is proposed to be back-ported to jdk7u. I don't have an opinion as to whether other tuning knobs are required. If that's what it takes to get this in, then I suppose -Djdk.enableParallelCRC32Update=true is the way to go. What steps do we/I take to get a public flag like that added? And would you consider instead -Djava.util.zip.CRC32.serialSize=4g, meaning for all inputs smaller than 4g (unsigned, thus larger than any Java array this year), do it in serial? Because there are quite a few boxes that I benchmarked on where you might want to tune that threshold down below 4m (the default that I had proposed). > At this point, we have Arrays.parallelSort and the Streams API defines the parallel() method to get a stream that is parallel. Having the word "parallel" in the code means it is clear and obvious when reading the code (no surprises). Maybe going forward that this will be unnecessary, meaning it will be transparent. For now though, I think we should at least consider adding parallelUpdate methods. I think in a few years we will view this as an anachronism, which is why, if we do it with a flag, we make it a tuning flag that people are likely to want anyhow and just leave the default threshold at "really big" if we are worried about behavioral changes in the near term. This is our future; we're unlikely to see clock speeds 3.6x what we have now, but can we add cores and easily get 3.6x performance boosts on stuff like CRC. David From david.holmes at oracle.com Mon May 20 12:17:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2013 22:17:53 +1000 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <5199D471.20903@oracle.com> References: <5199B939.105@oracle.com> <5199D471.20903@oracle.com> Message-ID: <519A1471.3020102@oracle.com> On 20/05/2013 5:44 PM, David Holmes wrote: > On 20/05/2013 4:25 PM, Martin Buchholz wrote: >> Note that my pending change >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch >> >> does the same kind of thing, but without recursive lock acquisitions. > > I will take a look. So it looks like I can do my push with nested sync with no concern because once you do your getChars update the nested sync will be removed. I like that outcome. That said I'm concerned by your getChars method but I shall take that up on another thread. Thanks, David >> I'm curious why a recursive lock acquisition would be considered "very" >> cheap. Is there some hotspot magic, or is it simply that we have >> another write to a cache line that is already probably owned by the cpu >> by virtue of the previous cas to acquire? > > Yes "hotspot magic". Acquiring a lock you already own doesn't require a > CAS; and if it is locked via biased-locking then it is an even shorter > path. > > Thanks, > David > >> >> On Sun, May 19, 2013 at 10:48 PM, David Holmes > > wrote: >> >> The change put through for JDK-8013395 (StringBuffer toString cache) >> has exposed a previously unnoticed bug in the >> StringBuffer.append(__CharSequence cs) method. That method claimed >> to achieve synchronization (and then correct toStringCache >> behaviour) by the super.append method calling other StringBuffer >> methods after narrowing of cs to a specific type. But that is >> incorrect if cs==null as in that case the >> AbstractStringBuilder.__appendNull method is called directly, with >> no calls to an overridden StringBuffer method. (I have verified that >> none of the other methods claiming to not need sync suffer from a >> similar flaw - this is an isolated case.) >> >> Consequently we started failing some existing append(null) tests. >> >> The fix is quite simple: append(CharSequence) behaves as for other >> append methods and is declared synchronized and clears the cache >> explicitly. The existing test is extended to check append(null). >> >> webrev: >> >> http://cr.openjdk.java.net/~__dholmes/8014814/webrev/ >> >> >> This fix does mean that recursive synchronization will now be used >> for append(CharSequence) but recursive synchronization is very >> cheap. An alternative fix suggested by Alan Bateman in the bug >> report is to override appendNull and add the synchronization there. >> That requires a change to the accessibility of >> AbstractStringBuilder.__appendNull so I chose the more constrained >> fix. Alan's fix will also introduce nested synchronization, but only >> for the append(null) case. As I said I don't think performance will >> be a concern here. >> >> Testing (in progress): JPRT -testset core, SQE test that caught this >> >> Thanks, >> David >> >> From david.holmes at oracle.com Mon May 20 12:22:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2013 22:22:30 +1000 Subject: Add getChars to CharSequence In-Reply-To: References: Message-ID: <519A1586.1070709@oracle.com> Hi Martin, I took a look at this in relation to the other StringBuffer bugs. I have a concern. Looking at this: @@ -453,12 +438,11 @@ public AbstractStringBuilder append(CharSequence s) { if (s == null) return appendNull(); - if (s instanceof String) - return this.append((String)s); - if (s instanceof AbstractStringBuilder) - return this.append((AbstractStringBuilder)s); - - return this.append(s, 0, s.length()); + int len = s.length(); + ensureCapacityInternal(count + len); + s.getChars(0, len, value, count); + count += len; + return this; } it seems that you are passing the ABS internal char[] value, directly to an external method (s.getChars) which could be overridden to do whatever it wants to the passed in array! Am I missing something? David ----- On 11/04/2013 10:40 AM, 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 david.r.chase at oracle.com Mon May 20 13:49:52 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 09:49:52 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> Message-ID: <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. Does that makes this a hair easier? It will still contain the assembly language, and I am still attempting to get anywhere at all on Windows (our official instructions don't work, largely because they seem to depend on a specific version of DirectX from Microsoft that is no longer available for download). This would also make the bug filers somewhat happy, since they were specifically interested in the nifty instruction. No love for Sparc or Vintage Intel, but oh well. David From sundararajan.athijegannathan at oracle.com Mon May 20 13:56:42 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 20 May 2013 13:56:42 +0000 Subject: hg: jdk8/tl/nashorn: 15 new changesets Message-ID: <20130520135653.CBBAA48BB9@hg.openjdk.java.net> Changeset: 80d4db063d5a Author: jlaskey Date: 2013-05-14 11:15 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/80d4db063d5a 8014512: Exclude testing and infrastructure packages from code coverage Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/code_coverage.xml Changeset: eeed4db61215 Author: jlaskey Date: 2013-05-14 11:16 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eeed4db61215 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - test/script/trusted/logcoverage.js Changeset: fc20983ef38e Author: attila Date: 2013-05-14 19:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fc20983ef38e 8011718: binding already bound function with extra arguments fails Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java + test/script/basic/JDK-8011718.js + test/script/basic/JDK-8011718.js.EXPECTED Changeset: f88a4818a4dc Author: lagergren Date: 2013-05-14 19:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f88a4818a4dc 8014426: Original exception no longer thrown away when a finally rethrows Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8014426.js + test/script/basic/JDK-8014426.js.EXPECTED Changeset: 64ef1aeaeb4e Author: attila Date: 2013-05-15 10:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/64ef1aeaeb4e 8014639: Remove debug flag from test runs Reviewed-by: hannesw, lagergren ! make/project.properties Changeset: b37eb709ae27 Author: attila Date: 2013-05-15 14:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b37eb709ae27 8014646: Update the Java interop documentation in the Java Scripting Programmer's Guide Reviewed-by: jlaskey, hannesw, lagergren ! docs/JavaScriptingProgrammersGuide.html Changeset: 1eaa542cc8e2 Author: sundar Date: 2013-05-15 19:45 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1eaa542cc8e2 8012305: Function.bind can't be called on prototype function inside constructor Reviewed-by: lagergren, attila + test/script/basic/JDK-8012305.js + test/script/basic/JDK-8012305.js.EXPECTED Changeset: 6344644b81ec Author: jlaskey Date: 2013-05-15 12:09 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6344644b81ec 8014648: Exclude testing and infrastructure packages from code coverage, round two Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/code_coverage.xml ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/Options.java - src/jdk/nashorn/internal/runtime/options/ValueOption.java ! test/script/basic/allgettersetters.js Changeset: 19e9cd9c7010 Author: attila Date: 2013-05-15 20:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/19e9cd9c7010 8014647: Allow class-based overrides to be initialized with a ScriptFunction Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/basic/JDK-8014647.js + test/script/basic/JDK-8014647.js.EXPECTED Changeset: ac14a1fb0cab Author: sundar Date: 2013-05-16 14:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ac14a1fb0cab 8009141: Avoid netscape.javascript.JSObject in nashorn code Reviewed-by: lagergren, hannesw + src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java - src/netscape/javascript/JSObject.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 4c67a692ef97 Author: lagergren Date: 2013-05-16 13:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4c67a692ef97 8013919: Original exception no longer thrown away when a finally rethrows Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java + test/script/basic/JDK-8013919.js + test/script/basic/JDK-8013919.js.EXPECTED Changeset: 98798a6336de Author: hannesw Date: 2013-05-16 19:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/98798a6336de 8012359: Increase code coverage in Joni Reviewed-by: jlaskey, lagergren ! make/build.xml - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/JdkRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java ! src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java ! src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java ! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java + test/src/jdk/nashorn/internal/runtime/regexp/JdkRegExpTest.java + test/src/jdk/nashorn/internal/runtime/regexp/joni/JoniTest.java Changeset: aa1b6e8c51a0 Author: jlaskey Date: 2013-05-17 14:30 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa1b6e8c51a0 8012694: Smoke test fail: Windows JDK-8008554.js - access denied ("java.io.FilePermission" "//C/aurora/sandbox/nashorn~source/test/script/basic/NASHORN-99.js" "read") Reviewed-by: jlaskey Contributed-by: konstantin.shefov at oracle.com Changeset: a92be4c0063b Author: jlaskey Date: 2013-05-17 16:12 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a92be4c0063b Merge - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: 1d5a8f1f416e Author: jlaskey Date: 2013-05-17 16:44 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1d5a8f1f416e 8014823: Reprise - Smoke test fail: Windows JDK-8008554.js - access denied ("java.io.FilePermission" "//C/aurora/sandbox/nashorn~source/test/script/basic/NASHORN-99.js" "read") Reviewed-by: jlaskey Contributed-by: konstantin.shefov at oracle.com ! test/script/basic/JDK-8008554.js From amy.lu at oracle.com Mon May 20 15:07:41 2013 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 20 May 2013 23:07:41 +0800 Subject: Code review request 8014892: More ProblemList.txt updates (5/2013) Message-ID: <519A3C3D.3040504@oracle.com> More ProblemList updates to remove three tests, the related issues have been fixed. Please review: https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html Thanks, From vladimir.kozlov at oracle.com Mon May 20 15:28:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 May 2013 08:28:52 -0700 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> Message-ID: <519A4134.2060701@oracle.com> On 5/20/13 6:49 AM, David Chase wrote: > Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. Yes, please, do that. > > Does that makes this a hair easier? It will still contain the assembly language, and I am still attempting to get anywhere at all on Windows (our official instructions don't work, largely because they seem to depend on a specific version of DirectX from Microsoft that is no longer available for download). > This would also make the bug filers somewhat happy, since they were specifically interested in the nifty instruction. No love for Sparc or Vintage Intel, but oh well. You still don't want to do it in VM as intrinsic/stubs? ;) You would not have all these C++ issues and I can help you with that. Thanks, Vladimir > > David > From david.r.chase at oracle.com Mon May 20 17:14:44 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 13:14:44 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <519A4134.2060701@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A4134.2060701@oracle.com> Message-ID: On 2013-05-20, at 11:28 AM, Vladimir Kozlov wrote: > On 5/20/13 6:49 AM, David Chase wrote: >> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. > > Yes, please, do that. And, before I waste more time tearing my hair out, suppose that I punt on accelerating Windows until we are using a more modern Visual Studio? Because I went a looked at the problem, the assembly language has a completely different syntax, it would double the amount of ugly asm in that file, and the people with the performance problem were not running Windows. > You still don't want to do it in VM as intrinsic/stubs? ;) I think that would be a lovely idea. Can we get 16-byte alignment guaranteed from the GCC, and use of 128-bit wide xmm registers compiled in? > You would not have all these C++ issues and I can help you with that. It is clear that the compiler internals are the land of don't-ask-don't-tell. Perhaps we could slip a little fork-join parallelism in there, too? :-) David From david.r.chase at oracle.com Mon May 20 17:24:10 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 13:24:10 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A4134.2060701@oracle.com> Message-ID: PS, the code generated by Visual Studio 2012 from the C version of the source is nowhere near as good as what comes from gcc 2.6 or clang. Getting good code would require hand conversion of 80 lines of assembler to the microsoft dialect, never mind the calling conventions. That suggests disabling this optimization for Windows. David On 2013-05-20, at 1:14 PM, David Chase wrote: > > On 2013-05-20, at 11:28 AM, Vladimir Kozlov wrote: > >> On 5/20/13 6:49 AM, David Chase wrote: >>> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. >> >> Yes, please, do that. > > And, before I waste more time tearing my hair out, suppose that I punt on accelerating Windows until we are using a more modern Visual Studio? > Because I went a looked at the problem, the assembly language has a completely different syntax, it would double the amount of ugly asm in that file, and the people with the performance problem were not running Windows. > >> You still don't want to do it in VM as intrinsic/stubs? ;) > > I think that would be a lovely idea. > Can we get 16-byte alignment guaranteed from the GCC, and use of 128-bit wide xmm registers compiled in? > >> You would not have all these C++ issues and I can help you with that. > > It is clear that the compiler internals are the land of don't-ask-don't-tell. > Perhaps we could slip a little fork-join parallelism in there, too? :-) > > David > From Alan.Bateman at oracle.com Mon May 20 17:45:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 May 2013 18:45:24 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> Message-ID: <519A6134.8010902@oracle.com> On 20/05/2013 14:49, David Chase wrote: > Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part. > : > This make sense. -Alan. From martinrb at google.com Mon May 20 17:55:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 20 May 2013 10:55:40 -0700 Subject: Add getChars to CharSequence In-Reply-To: <519A1586.1070709@oracle.com> References: <519A1586.1070709@oracle.com> Message-ID: This is __the__ fundamental question of whether to add CharSequence.getChars at all. If none of the objects in the jdk can trust any of the others, they will spend all of their time making defensive copies and unmodifiable wrappers. This is the reverse side of whether you can trust any collection class to not retain a pointer to the array returned by toArray. Alternatively, we could add a security check to every use of getChars, but that gets in the way of the performance we're trying to achieve here. On Mon, May 20, 2013 at 5:22 AM, David Holmes wrote: > Hi Martin, > > I took a look at this in relation to the other StringBuffer bugs. > > I have a concern. Looking at this: > > @@ -453,12 +438,11 @@ > public AbstractStringBuilder append(CharSequence s) { > if (s == null) > return appendNull(); > - if (s instanceof String) > - return this.append((String)s); > - if (s instanceof AbstractStringBuilder) > - return this.append((**AbstractStringBuilder)s); > - > - return this.append(s, 0, s.length()); > + int len = s.length(); > + ensureCapacityInternal(count + len); > + s.getChars(0, len, value, count); > + count += len; > + return this; > } > > it seems that you are passing the ABS internal char[] value, directly to > an external method (s.getChars) which could be overridden to do whatever it > wants to the passed in array! Am I missing something? > > David > ----- > > > On 11/04/2013 10:40 AM, 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 brian.burkhalter at oracle.com Mon May 20 18:26:48 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 20 May 2013 11:26:48 -0700 Subject: 4646474 : BigInteger.pow() algorithm slow in 1.4.0 In-Reply-To: <5195C4B7.3030003@mindspring.com> References: <33A2BE33-8D67-4F79-BEAD-231B09C6E101@oracle.com> <5195C4B7.3030003@mindspring.com> Message-ID: <524A8A4B-2122-4AE7-A035-B92E3C4F981C@oracle.com> Thought I sent this last week but it was saved in Drafts ? On May 16, 2013, at 10:48 PM, Alan Eliasen wrote: > Yes, the extreme examples are ones like in the original bug report, > which are literally millions of times faster. If the base contains a > power of 2, (which is by far the most common case I see in numeric > algorithms,) then performance can be be so drastically improved that > it's hard to measure the actual ratio. For example, you've seen the > workarounds in BigDecimal for slow 10^x calculations, which will be > greatly improved by this patch and the toString() changes in the next phase. > > Note that when Schoenhage-Strassen multiplication is included, the > ratio will be even better. On an eight-core (using just one core) AMD > FX-8350 at 4 GHz, the time for your example of 17^13466917 drops from > 1412.522 seconds to 15.233 seconds, an improvement of a factor of about 93. Great! >> I linked this issue to 4837946 as a duplicate so it will be closed >> out at the same time. > > That'll be great to see. Combined, these two bug reports are old > enough to buy us drinks. I'm so proud of them. :) Dry vodka martini or single malt? > Is there any plan to backport these to earlier JVMs? That would be decided by the release team for the VM version in question. Unfortunately the JDK 8 version of BigInteger prior to applying the phase 1 changes already has nearly 600 lines of diffs versus the JDK 7 repository version. Some of these changes (new public APIs for example) would not be amenable to backporting. I think however that the phase 1 changes are mostly if not entirely disjoint with the other post-7 changes, so I doubt that the presence of these other diffs would be an impediment. I would prefer however to get the code integrated into the JDK 8 train first and some time subsequently worry about any backports. Brian From xueming.shen at oracle.com Mon May 20 18:59:29 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 20 May 2013 18:59:29 +0000 Subject: hg: jdk8/tl/jdk: 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Message-ID: <20130520185952.A40F548BC7@hg.openjdk.java.net> Changeset: 6a9148865139 Author: sherman Date: 2013-05-20 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a9148865139 8004789: (zipfs) zip provider doesn't work correctly with file systems providers rather than the default Summary: to use Files.createTempFile(...) to create the temp file on the same fs as the targeted path. Reviewed-by: alanb, sherman Contributed-by: philippe.marschall at gmail.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java From huizhe.wang at oracle.com Mon May 20 20:15:15 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 20 May 2013 13:15:15 -0700 Subject: RFR (JAXP) : 8014891 : incorrect handling FEATURE_SECURE_PROCESSING in jdk xerces Message-ID: <519A8453.7090500@oracle.com> Hi, This is a patch to remove redundant property settings. In the previous patch, the new jaxp properties were set while copying features onto DOM/SAX parsers. However, this is already done during the initialization of DOM/SAX parsers (before setFeatures is called). It was removed in the standalone JAXP 1.5 implementation but was mistakenly left in the JDK patch. webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8014891/webrev/ Thanks, Joe From joe.darcy at oracle.com Mon May 20 21:10:13 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 20 May 2013 14:10:13 -0700 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement Message-ID: <519A9135.9000002@oracle.com> Hello, Please review the patch below which implements 8014836: Have GenericDeclaration extend AnnotatedElement All the existing implementations of GenericDeclaration in the JDK already implement AnnotatedElement. Some code in java.lang.Class needed to be adjusted slightly since AnnotatedElement declares a default method and calling an interface's default method in an implementing class has to go through the direct interface type. Thanks, -Joe --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 2013 -0700 +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 2013 -0700 @@ -28,6 +28,7 @@ import java.lang.reflect.AnnotatedElement; import java.lang.reflect.Array; import java.lang.reflect.GenericArrayType; +import java.lang.reflect.GenericDeclaration; import java.lang.reflect.Member; import java.lang.reflect.Field; import java.lang.reflect.Executable; @@ -115,9 +116,9 @@ * @since JDK1.0 */ public final class Class implements java.io.Serializable, - java.lang.reflect.GenericDeclaration, - java.lang.reflect.Type, - java.lang.reflect.AnnotatedElement { + GenericDeclaration, + Type, + AnnotatedElement { private static final int ANNOTATION= 0x00002000; private static final int ENUM = 0x00004000; private static final int SYNTHETIC = 0x00001000; @@ -3182,7 +3183,7 @@ */ @Override public boolean isAnnotationPresent(Class annotationClass) { - return AnnotatedElement.super.isAnnotationPresent(annotationClass); + return GenericDeclaration.super.isAnnotationPresent(annotationClass); } /** diff -r 6a9148865139 src/share/classes/java/lang/reflect/GenericDeclaration.java --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon May 20 11:56:46 2013 -0700 +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon May 20 14:07:15 2013 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 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 @@ -30,7 +30,7 @@ * * @since 1.5 */ -public interface GenericDeclaration { +public interface GenericDeclaration extends AnnotatedElement { /** * Returns an array of {@code TypeVariable} objects that * represent the type variables declared by the generic From forax at univ-mlv.fr Mon May 20 21:28:41 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 20 May 2013 23:28:41 +0200 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement In-Reply-To: <519A9135.9000002@oracle.com> References: <519A9135.9000002@oracle.com> Message-ID: <519A9589.9040002@univ-mlv.fr> On 05/20/2013 11:10 PM, Joe Darcy wrote: > Hello, > > Please review the patch below which implements > > 8014836: Have GenericDeclaration extend AnnotatedElement > > All the existing implementations of GenericDeclaration in the JDK > already implement AnnotatedElement. Some code in java.lang.Class > needed to be adjusted slightly since AnnotatedElement declares a > default method and calling an interface's default method in an > implementing class has to go through the direct interface type. GenericDeclaration is a public interface, so you will break the code of everyone that implements it. By example, Guava's Invokable also implements GenericDeclaration http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/reflect/Invokable.html > > Thanks, > > -Joe R?mi > > --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 > 2013 -0700 > +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 > 2013 -0700 > @@ -28,6 +28,7 @@ > import java.lang.reflect.AnnotatedElement; > import java.lang.reflect.Array; > import java.lang.reflect.GenericArrayType; > +import java.lang.reflect.GenericDeclaration; > import java.lang.reflect.Member; > import java.lang.reflect.Field; > import java.lang.reflect.Executable; > @@ -115,9 +116,9 @@ > * @since JDK1.0 > */ > public final class Class implements java.io.Serializable, > - java.lang.reflect.GenericDeclaration, > - java.lang.reflect.Type, > - java.lang.reflect.AnnotatedElement { > + GenericDeclaration, > + Type, > + AnnotatedElement { > private static final int ANNOTATION= 0x00002000; > private static final int ENUM = 0x00004000; > private static final int SYNTHETIC = 0x00001000; > @@ -3182,7 +3183,7 @@ > */ > @Override > public boolean isAnnotationPresent(Class > annotationClass) { > - return > AnnotatedElement.super.isAnnotationPresent(annotationClass); > + return > GenericDeclaration.super.isAnnotationPresent(annotationClass); > } > > /** > diff -r 6a9148865139 > src/share/classes/java/lang/reflect/GenericDeclaration.java > --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon > May 20 11:56:46 2013 -0700 > +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon > May 20 14:07:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 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 > @@ -30,7 +30,7 @@ > * > * @since 1.5 > */ > -public interface GenericDeclaration { > +public interface GenericDeclaration extends AnnotatedElement { > /** > * Returns an array of {@code TypeVariable} objects that > * represent the type variables declared by the generic > From Lance.Andersen at oracle.com Mon May 20 21:59:21 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 20 May 2013 17:59:21 -0400 Subject: RFR (JAXP) : 8014891 : incorrect handling FEATURE_SECURE_PROCESSING in jdk xerces In-Reply-To: <519A8453.7090500@oracle.com> References: <519A8453.7090500@oracle.com> Message-ID: <958C5EDD-8BBC-44C2-B6EA-C29A982EAF1F@oracle.com> looks fine Joe On May 20, 2013, at 4:15 PM, huizhe wang wrote: > Hi, > > This is a patch to remove redundant property settings. In the previous patch, the new jaxp properties were set while copying features onto DOM/SAX parsers. However, this is already done during the initialization of DOM/SAX parsers (before setFeatures is called). It was removed in the standalone JAXP 1.5 implementation but was mistakenly left in the JDK patch. > > webrevs: > http://cr.openjdk.java.net/~joehw/jdk8/8014891/webrev/ > > Thanks, > Joe -------------- 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 huizhe.wang at oracle.com Mon May 20 22:41:49 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 20 May 2013 15:41:49 -0700 Subject: RFR (JAXP) : 8014891 : incorrect handling FEATURE_SECURE_PROCESSING in jdk xerces In-Reply-To: <958C5EDD-8BBC-44C2-B6EA-C29A982EAF1F@oracle.com> References: <519A8453.7090500@oracle.com> <958C5EDD-8BBC-44C2-B6EA-C29A982EAF1F@oracle.com> Message-ID: <519AA6AD.5080105@oracle.com> Thanks! On 5/20/2013 2:59 PM, Lance Andersen - Oracle wrote: > looks fine Joe > On May 20, 2013, at 4:15 PM, huizhe wang wrote: > >> Hi, >> >> This is a patch to remove redundant property settings. In the previous patch, the new jaxp properties were set while copying features onto DOM/SAX parsers. However, this is already done during the initialization of DOM/SAX parsers (before setFeatures is called). It was removed in the standalone JAXP 1.5 implementation but was mistakenly left in the JDK patch. >> >> webrevs: >> http://cr.openjdk.java.net/~joehw/jdk8/8014891/webrev/ >> >> Thanks, >> Joe > > > 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 huizhe.wang at oracle.com Mon May 20 23:12:35 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Mon, 20 May 2013 23:12:35 +0000 Subject: hg: jdk8/tl/jaxp: 8014891: Redundant setting of external access properties in setFeatures Message-ID: <20130520231237.47F0948BD0@hg.openjdk.java.net> Changeset: a7cec93e4682 Author: joehw Date: 2013-05-20 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7cec93e4682 8014891: Redundant setting of external access properties in setFeatures Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java From huizhe.wang at oracle.com Mon May 20 23:26:49 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 20 May 2013 16:26:49 -0700 Subject: RFR (JAXP): 8012683 : Some ObjectFactory classes should be removed. Message-ID: <519AB139.8070301@oracle.com> Hi, This is a quick fix to remove a copy of obsolete ObjectFactory classes. They should have been removed in a previous consolidation work (7053556) but were mistakenly kept in the repo. http://cr.openjdk.java.net/~joehw/jdk8/8012683/webrev/ Thanks, Joe From lance.andersen at oracle.com Mon May 20 23:49:42 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Mon, 20 May 2013 19:49:42 -0400 Subject: RFR (JAXP): 8012683 : Some ObjectFactory classes should be removed. In-Reply-To: <519AB139.8070301@oracle.com> References: <519AB139.8070301@oracle.com> Message-ID: <56035FFB-030F-404F-8C8F-68F76BAA0746@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 May 20, 2013, at 7:26 PM, huizhe wang wrote: > Hi, > > This is a quick fix to remove a copy of obsolete ObjectFactory classes. They should have been removed in a previous consolidation work (7053556) but were mistakenly kept in the repo. > > http://cr.openjdk.java.net/~joehw/jdk8/8012683/webrev/ > > Thanks, > Joe From david.holmes at oracle.com Tue May 21 00:30:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 10:30:50 +1000 Subject: Add getChars to CharSequence In-Reply-To: References: <519A1586.1070709@oracle.com> Message-ID: <519AC03A.70505@oracle.com> On 21/05/2013 3:55 AM, Martin Buchholz wrote: > This is __the__ fundamental question of whether to add > CharSequence.getChars at all. > > If none of the objects in the jdk can trust any of the others, they will > spend all of their time making defensive copies and unmodifiable wrappers. But you are not limiting this to objects in the jdk! The CharSequence could come from anywhere. If the CharSequence is actually a String/StringBuffer/StringBuilder then use the optimization. But otherwise you are just violating encapsulation. David ----- > This is the reverse side of whether you can trust any collection class to > not retain a pointer to the array returned by toArray. > > Alternatively, we could add a security check to every use of getChars, but > that gets in the way of the performance we're trying to achieve here. > > > > On Mon, May 20, 2013 at 5:22 AM, David Holmes wrote: > >> Hi Martin, >> >> I took a look at this in relation to the other StringBuffer bugs. >> >> I have a concern. Looking at this: >> >> @@ -453,12 +438,11 @@ >> public AbstractStringBuilder append(CharSequence s) { >> if (s == null) >> return appendNull(); >> - if (s instanceof String) >> - return this.append((String)s); >> - if (s instanceof AbstractStringBuilder) >> - return this.append((**AbstractStringBuilder)s); >> - >> - return this.append(s, 0, s.length()); >> + int len = s.length(); >> + ensureCapacityInternal(count + len); >> + s.getChars(0, len, value, count); >> + count += len; >> + return this; >> } >> >> it seems that you are passing the ABS internal char[] value, directly to >> an external method (s.getChars) which could be overridden to do whatever it >> wants to the passed in array! Am I missing something? >> >> David >> ----- >> >> >> On 11/04/2013 10:40 AM, 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 david.holmes at oracle.com Tue May 21 00:34:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 10:34:04 +1000 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <519A6134.8010902@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> Message-ID: <519AC0FC.9040300@oracle.com> On 21/05/2013 3:45 AM, Alan Bateman wrote: > On 20/05/2013 14:49, David Chase wrote: >> Suppose I split this bug (i.e., file a new bug) into the >> Intel-acceleration part and the fork-join part. >> : >> > This make sense. I agree. I also don't have an issue with eliding the optimization on Windows for the time being. David > -Alan. From kurchi.subhra.hazra at oracle.com Tue May 21 00:42:02 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 20 May 2013 17:42:02 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <518D8429.7060903@oracle.com> References: <518D8429.7060903@oracle.com> Message-ID: <519AC2DA.5090302@oracle.com> Hi, Please review this change to fix 718655. The bug complaints about continuous BackingStoreExceptions printed on the console, the user is just seeing logged warnings from BackingStoreExceptions raised in periodic attempts to sync preferences. Preferences use sun.util.logging.PlatformLogger.java which is enabled by default, and has a default level of INFO. Changing the logging in this file to FINE prevents the user from seeing information that he/she is not interested in. Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ Thanks, - Kurchi From martinrb at google.com Tue May 21 01:07:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 20 May 2013 18:07:40 -0700 Subject: Add getChars to CharSequence In-Reply-To: <519AC03A.70505@oracle.com> References: <519A1586.1070709@oracle.com> <519AC03A.70505@oracle.com> Message-ID: On Mon, May 20, 2013 at 5:30 PM, David Holmes wrote: > On 21/05/2013 3:55 AM, Martin Buchholz wrote: > >> This is __the__ fundamental question of whether to add >> CharSequence.getChars at all. >> >> If none of the objects in the jdk can trust any of the others, they will >> spend all of their time making defensive copies and unmodifiable wrappers. >> > > But you are not limiting this to objects in the jdk! The CharSequence > could come from anywhere. If the CharSequence is actually a > String/StringBuffer/**StringBuilder then use the optimization. But > otherwise you are just violating encapsulation. > David, Yes, I understand. It's far less obviously bad than having an API that returns an internal array. Here there would have to be a malicious CharSequence, and the owner of the StringB**er has to be willing to call the append method on it. Like I said, This is __the__ fundamental question of whether to add CharSequence.getChars at all. I can appreciate the argument that getChars is simply too insecure to be found in a public interface. But it would be sad if we couldn't enable optimizations like this. From joe.darcy at oracle.com Tue May 21 01:16:00 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 20 May 2013 18:16:00 -0700 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement In-Reply-To: <519A9589.9040002@univ-mlv.fr> References: <519A9135.9000002@oracle.com> <519A9589.9040002@univ-mlv.fr> Message-ID: <519ACAD0.1030505@oracle.com> Hi Remi, On 5/20/2013 2:28 PM, Remi Forax wrote: > On 05/20/2013 11:10 PM, Joe Darcy wrote: >> Hello, >> >> Please review the patch below which implements >> >> 8014836: Have GenericDeclaration extend AnnotatedElement >> >> All the existing implementations of GenericDeclaration in the JDK >> already implement AnnotatedElement. Some code in java.lang.Class >> needed to be adjusted slightly since AnnotatedElement declares a >> default method and calling an interface's default method in an >> implementing class has to go through the direct interface type. > > GenericDeclaration is a public interface, so you will break the code > of everyone that implements it. > By example, Guava's Invokable also implements GenericDeclaration > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/reflect/Invokable.html > That is technically true; in effect adding several methods to GenericDeclaration would break implementations outside of the JDK that do not already implement annotated element. However, this is (only) a source incompatible change and not a binary incompatible change so is possible in-bounds for a platform release like JDK 8: http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy The Invokable type you reference is the moral equivalent of the "Executable" superclass of Constructor and Method added earlier in JDK 8. The Invokable type itself is marked as "@Beta" to warn users that it could change or even to away. Therefore, I'm not very concerned about "breaking" a type like this, which could easily be retrofitted to also implement AnnotatedElement as it already a wrapper around a Method or a Constructor. (Also interesting to see a "Parameter" class in Guava given that we have added a Parameter class to java.lang.reflect.) Thanks, -Joe > >> >> Thanks, >> >> -Joe > > R?mi > >> >> --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 >> 2013 -0700 >> +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 >> 2013 -0700 >> @@ -28,6 +28,7 @@ >> import java.lang.reflect.AnnotatedElement; >> import java.lang.reflect.Array; >> import java.lang.reflect.GenericArrayType; >> +import java.lang.reflect.GenericDeclaration; >> import java.lang.reflect.Member; >> import java.lang.reflect.Field; >> import java.lang.reflect.Executable; >> @@ -115,9 +116,9 @@ >> * @since JDK1.0 >> */ >> public final class Class implements java.io.Serializable, >> - java.lang.reflect.GenericDeclaration, >> - java.lang.reflect.Type, >> - java.lang.reflect.AnnotatedElement { >> + GenericDeclaration, >> + Type, >> + AnnotatedElement { >> private static final int ANNOTATION= 0x00002000; >> private static final int ENUM = 0x00004000; >> private static final int SYNTHETIC = 0x00001000; >> @@ -3182,7 +3183,7 @@ >> */ >> @Override >> public boolean isAnnotationPresent(Class >> annotationClass) { >> - return >> AnnotatedElement.super.isAnnotationPresent(annotationClass); >> + return >> GenericDeclaration.super.isAnnotationPresent(annotationClass); >> } >> >> /** >> diff -r 6a9148865139 >> src/share/classes/java/lang/reflect/GenericDeclaration.java >> --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon >> May 20 11:56:46 2013 -0700 >> +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon >> May 20 14:07:15 2013 -0700 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2003, 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 >> @@ -30,7 +30,7 @@ >> * >> * @since 1.5 >> */ >> -public interface GenericDeclaration { >> +public interface GenericDeclaration extends AnnotatedElement { >> /** >> * Returns an array of {@code TypeVariable} objects that >> * represent the type variables declared by the generic >> > From david.holmes at oracle.com Tue May 21 02:12:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 12:12:50 +1000 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <519A1471.3020102@oracle.com> References: <5199B939.105@oracle.com> <5199D471.20903@oracle.com> <519A1471.3020102@oracle.com> Message-ID: <519AD822.1060501@oracle.com> So I propose to push ahead with this fix in my offered form. I still need an official Review to do so, or else objections against the proposal. Thanks, David On 20/05/2013 10:17 PM, David Holmes wrote: > On 20/05/2013 5:44 PM, David Holmes wrote: >> On 20/05/2013 4:25 PM, Martin Buchholz wrote: >>> Note that my pending change >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch >>> >>> >>> does the same kind of thing, but without recursive lock acquisitions. >> >> I will take a look. > > So it looks like I can do my push with nested sync with no concern > because once you do your getChars update the nested sync will be > removed. I like that outcome. > > That said I'm concerned by your getChars method but I shall take that up > on another thread. > > Thanks, > David > >>> I'm curious why a recursive lock acquisition would be considered "very" >>> cheap. Is there some hotspot magic, or is it simply that we have >>> another write to a cache line that is already probably owned by the cpu >>> by virtue of the previous cas to acquire? >> >> Yes "hotspot magic". Acquiring a lock you already own doesn't require a >> CAS; and if it is locked via biased-locking then it is an even shorter >> path. >> >> Thanks, >> David >> >>> >>> On Sun, May 19, 2013 at 10:48 PM, David Holmes >> > wrote: >>> >>> The change put through for JDK-8013395 (StringBuffer toString cache) >>> has exposed a previously unnoticed bug in the >>> StringBuffer.append(__CharSequence cs) method. That method claimed >>> to achieve synchronization (and then correct toStringCache >>> behaviour) by the super.append method calling other StringBuffer >>> methods after narrowing of cs to a specific type. But that is >>> incorrect if cs==null as in that case the >>> AbstractStringBuilder.__appendNull method is called directly, with >>> no calls to an overridden StringBuffer method. (I have verified that >>> none of the other methods claiming to not need sync suffer from a >>> similar flaw - this is an isolated case.) >>> >>> Consequently we started failing some existing append(null) tests. >>> >>> The fix is quite simple: append(CharSequence) behaves as for other >>> append methods and is declared synchronized and clears the cache >>> explicitly. The existing test is extended to check append(null). >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~__dholmes/8014814/webrev/ >>> >>> >>> This fix does mean that recursive synchronization will now be used >>> for append(CharSequence) but recursive synchronization is very >>> cheap. An alternative fix suggested by Alan Bateman in the bug >>> report is to override appendNull and add the synchronization there. >>> That requires a change to the accessibility of >>> AbstractStringBuilder.__appendNull so I chose the more constrained >>> fix. Alan's fix will also introduce nested synchronization, but only >>> for the append(null) case. As I said I don't think performance will >>> be a concern here. >>> >>> Testing (in progress): JPRT -testset core, SQE test that caught this >>> >>> Thanks, >>> David >>> >>> From weijun.wang at oracle.com Tue May 21 03:36:15 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 May 2013 11:36:15 +0800 Subject: Code review request, JDK-8010814, More buffers are stored or returned without cloning In-Reply-To: <5194AC53.2070805@oracle.com> References: <5194A21B.2000906@oracle.com> <5194A55A.9070204@oracle.com> <5194AC53.2070805@oracle.com> Message-ID: <519AEBAF.30504@oracle.com> On 5/16/13 5:52 PM, Xuelei Fan wrote: > On 5/16/2013 5:22 PM, Weijun Wang wrote: >> Hi Xuelei >> >> I'm busy on something else, so probably have no time (or cannot >> concentrate) to read in details. >> > Not urgent fix, so please review these request only when you available. > >> In my opinion, there are several cases as to whether to clone or not: >> >> 1. MUST NOT clone, because the value must be shared so that change at >> one side appears on the other side. >> >> 2. MUST clone, public available methods that leads to security issues. >> >> 3. So so, although public methods, cannot be used to do bad things. >> >> 4. Not an issue. Internal methods. >> >> In the patch, are the first two cases #1 or #3. >> > It's #2. I mean the cases in BerDecoder and BerEncoder. You only add comments // shared buffer, be careful to use this class > > For #1 and #3, I added a few comment lines in 8010815. > >> Sorry I also have no time to read >> >> JDK-8010814, More buffers are stored or returned without cloning >> http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ >> >> but I am not sure if those env cases belong to #1. >> > I think both fixes are for #2. I'm not sure. Take Continuation for example, the class is used to continue a previous method. For me it looks like the environment should be shared between them. Can you give an example that shows the environment should not be shared? Thanks Max > > Xuelei > >> Thanks >> Max >> >> >> On 5/16/13 5:08 PM, Xuelei Fan wrote: >>> Hi, >>> >>> There is another fix to avoid the use of mutable objects. >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ >>> >>> Thanks, >>> Xuelei >>> > From david.holmes at oracle.com Tue May 21 04:36:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 14:36:52 +1000 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <5197345C.9070802@oracle.com> References: <5197345C.9070802@oracle.com> Message-ID: <519AF9E4.105@oracle.com> No surprise it is a thumbs up from me :) Thanks, David On 18/05/2013 5:57 PM, Chris Hegarty wrote: > Thread getName and setName are not thread-safe. The "expected" usage is > to set a name before starting the thread and only read it thereafter. > > It is desirable to support the setting of thread name dynamically, > mainly for monitoring/management/debugging. The typical scenario is the > single-writer, multiple-reader case. So, making name volatile is > sufficient. However, setName also sets the native thread name. This is > currently restricted to the current thread, since there could be a race > if the thread is terminating. Making setName synchronized would > eliminate that race, and allow for the native thread name to be set from > other threads. > > This issue came up on c-i a while back [1]. > > http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ > > -Chris. > > [1] > http://cs.oswego.edu/pipermail/concurrency-interest/2013-March/010935.html From david.holmes at oracle.com Tue May 21 05:02:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 15:02:11 +1000 Subject: Trivial RFR: 8014857 Enable ergonomic VM selection in arm/jvm.cfg In-Reply-To: <5199851E.1060304@oracle.com> References: <5199851E.1060304@oracle.com> Message-ID: <519AFFD3.6050808@oracle.com> Anybody? :( David On 20/05/2013 12:06 PM, David Holmes wrote: > The contents of the ARM jvm.cfg were put in place for the SE Embedded > product, but for the SE ARM implementation we want to enable ergonomics, > as we do on other platforms. > > http://cr.openjdk.java.net/~dholmes/8014857/webrev/ > > --- old/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:30.424314843 -0400 > +++ new/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:29.192246170 -0400 > @@ -30,6 +30,6 @@ > # "-XXaltjvm=" option, but that too is unsupported > # and may not be available in a future release. > # > --client KNOWN > +-client IF_SERVER_CLASS -server > -server KNOWN > -minimal KNOWN > > Tested VM selection on both server class and non-server class devices. > > Thanks, > David From mike.duigou at oracle.com Tue May 21 05:07:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 20 May 2013 22:07:44 -0700 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <5197345C.9070802@oracle.com> References: <5197345C.9070802@oracle.com> Message-ID: Looks good. Since the char array is never modified it could use the String(char[], boolean) constructor. This has advantages for cases such as logging which may read the thread name very many times. Mike On May 18 2013, at 00:57 , Chris Hegarty wrote: > Thread getName and setName are not thread-safe. The "expected" usage is to set a name before starting the thread and only read it thereafter. > > It is desirable to support the setting of thread name dynamically, mainly for monitoring/management/debugging. The typical scenario is the single-writer, multiple-reader case. So, making name volatile is sufficient. However, setName also sets the native thread name. This is currently restricted to the current thread, since there could be a race if the thread is terminating. Making setName synchronized would eliminate that race, and allow for the native thread name to be set from other threads. > > This issue came up on c-i a while back [1]. > > http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ > > -Chris. > > [1] http://cs.oswego.edu/pipermail/concurrency-interest/2013-March/010935.html From joe.darcy at oracle.com Tue May 21 05:13:46 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 20 May 2013 22:13:46 -0700 Subject: Trivial RFR: 8014857 Enable ergonomic VM selection in arm/jvm.cfg In-Reply-To: <519AFFD3.6050808@oracle.com> References: <5199851E.1060304@oracle.com> <519AFFD3.6050808@oracle.com> Message-ID: <519B028A.3060808@oracle.com> Approved. -Joe On 05/20/2013 10:02 PM, David Holmes wrote: > Anybody? :( > > David > > On 20/05/2013 12:06 PM, David Holmes wrote: >> The contents of the ARM jvm.cfg were put in place for the SE Embedded >> product, but for the SE ARM implementation we want to enable ergonomics, >> as we do on other platforms. >> >> http://cr.openjdk.java.net/~dholmes/8014857/webrev/ >> >> --- old/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:30.424314843 >> -0400 >> +++ new/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:29.192246170 >> -0400 >> @@ -30,6 +30,6 @@ >> # "-XXaltjvm=" option, but that too is unsupported >> # and may not be available in a future release. >> # >> --client KNOWN >> +-client IF_SERVER_CLASS -server >> -server KNOWN >> -minimal KNOWN >> >> Tested VM selection on both server class and non-server class devices. >> >> Thanks, >> David From david.holmes at oracle.com Tue May 21 05:18:38 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 21 May 2013 05:18:38 +0000 Subject: hg: jdk8/tl/jdk: 8014857: Enable ergonomic VM selection in arm/jvm.cfg Message-ID: <20130521051851.0FA6348BDB@hg.openjdk.java.net> Changeset: 1baf3d7fe2f1 Author: dholmes Date: 2013-05-21 01:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1baf3d7fe2f1 8014857: Enable ergonomic VM selection in arm/jvm.cfg Reviewed-by: darcy ! src/solaris/bin/arm/jvm.cfg From fweimer at redhat.com Tue May 21 06:32:42 2013 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 21 May 2013 08:32:42 +0200 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: References: <5197345C.9070802@oracle.com> Message-ID: <519B150A.3010104@redhat.com> On 05/21/2013 07:07 AM, Mike Duigou wrote: > Since the char array is never modified it could use the String(char[], boolean) constructor. This has advantages for cases such as logging which may read the thread name very many times. Couldn't we store the original string instead? -- Florian Weimer / Red Hat Product Security Team From david.holmes at oracle.com Tue May 21 06:43:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 16:43:00 +1000 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <519B150A.3010104@redhat.com> References: <5197345C.9070802@oracle.com> <519B150A.3010104@redhat.com> Message-ID: <519B1774.1040904@oracle.com> On 21/05/2013 4:32 PM, Florian Weimer wrote: > On 05/21/2013 07:07 AM, Mike Duigou wrote: >> Since the char array is never modified it could use the String(char[], >> boolean) constructor. This has advantages for cases such as logging >> which may read the thread name very many times. > > Couldn't we store the original string instead? We can't** use a String instead of the char[] because of interaction from the VM with JNI attached threads. Do you mean we should store the String as well? That would add to the memory footprint at a time when we are looking a reducing memory footprint (ala class instance size reductions). David ----- ** rather we won't. There is a lot of history here and using a String is not impossible, but not worth the churn. From huizhe.wang at oracle.com Tue May 21 06:47:43 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 21 May 2013 06:47:43 +0000 Subject: hg: jdk8/tl/jaxp: 8012683: Remove unused, obsolete ObjectFactory classes Message-ID: <20130521064745.7E3E248BDF@hg.openjdk.java.net> Changeset: 37b73984640a Author: joehw Date: 2013-05-20 23:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/37b73984640a 8012683: Remove unused, obsolete ObjectFactory classes Reviewed-by: lancea - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java From david.holmes at oracle.com Tue May 21 06:57:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 16:57:02 +1000 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: References: Message-ID: <519B1ABE.10303@oracle.com> Adding core-libs as this is actually a launcher change. David On 21/05/2013 4:36 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > http://bugs.sun.com/view_bug.do?bug_id=8009911 > The webrev is available at: > http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ > > The problem: > When launching java with -XstatrOnFirstThread we were using dispatch_sync to start a Java main on the main thread. This blocked the main dispatch queue, so all the subsequent calls to GCD were never invoked. GCD is used a bit in our code, but it is used inside Cocoa, for example for fullscreen. > > The solution: > We now launch Java main using a performSelectorOnMaintThread, so we do not block GCD. > > Notes: > 1. This also fixes the following SWT bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 > 2. Although I have added OBJC syntax into java_md_macosx.c file, I did not rename it to .m, because: > a. It is hard to update an old build system to compile with the new file name. > b. It is already compiled with -x objective-c, so I will compile > c. We would have lost all the hg history for this file. > > With best regards. Petr. > From sundararajan.athijegannathan at oracle.com Tue May 21 07:27:37 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 21 May 2013 07:27:37 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130521072740.0FC5B48BE0@hg.openjdk.java.net> Changeset: 92164a5742db Author: lagergren Date: 2013-05-20 16:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/92164a5742db 8006069: Range analysis first iteration, runtime specializations Reviewed-by: jlaskey, sundar ! 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/MethodEmitter.java + src/jdk/nashorn/internal/codegen/RangeAnalyzer.java + src/jdk/nashorn/internal/codegen/types/Range.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/ranges_disabled.js + test/script/basic/ranges_disabled.js.EXPECTED + test/script/basic/ranges_enabled.js + test/script/basic/ranges_enabled.js.EXPECTED + test/script/basic/ranges_payload.js Changeset: b558e19d5de5 Author: sundar Date: 2013-05-20 23:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b558e19d5de5 8014909: ant test compilation error with JoniTest.java Reviewed-by: jlaskey ! make/build.xml Changeset: 1fd18f40ab52 Author: attila Date: 2013-05-20 21:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1fd18f40ab52 8014797: rename Java.toJavaArray/toJavaScriptArray to Java.to/from, respectively. Reviewed-by: jlaskey, sundar ! docs/JavaScriptingProgrammersGuide.html ! docs/source/javaarray.js ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/NASHORN-556.js ! test/script/basic/javaarrayconversion.js ! test/script/currently-failing/logcoverage.js ! test/script/trusted/NASHORN-638.js ! test/script/trusted/NASHORN-653.js From Alan.Bateman at oracle.com Tue May 21 07:53:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 08:53:11 +0100 Subject: Code review request 8014892: More ProblemList.txt updates (5/2013) In-Reply-To: <519A3C3D.3040504@oracle.com> References: <519A3C3D.3040504@oracle.com> Message-ID: <519B27E7.8010204@oracle.com> On 20/05/2013 16:07, Amy Lu wrote: > More ProblemList updates to remove three tests, the related issues > have been fixed. > > Please review: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html > > > Thanks, > Good to catch cases where we neglected to remove the tests from the exclude list. The change looks fine to me. -Alan From Alan.Bateman at oracle.com Tue May 21 07:58:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 08:58:09 +0100 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <5197345C.9070802@oracle.com> References: <5197345C.9070802@oracle.com> Message-ID: <519B2911.2080305@oracle.com> On 18/05/2013 08:57, Chris Hegarty wrote: > Thread getName and setName are not thread-safe. The "expected" usage > is to set a name before starting the thread and only read it thereafter. > > It is desirable to support the setting of thread name dynamically, > mainly for monitoring/management/debugging. The typical scenario is > the single-writer, multiple-reader case. So, making name volatile is > sufficient. However, setName also sets the native thread name. This is > currently restricted to the current thread, since there could be a > race if the thread is terminating. Making setName synchronized would > eliminate that race, and allow for the native thread name to be set > from other threads. > > This issue came up on c-i a while back [1]. > > http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ Looks fine to me too. -Alan From alan.bateman at oracle.com Tue May 21 07:58:57 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 May 2013 07:58:57 +0000 Subject: hg: jdk8/tl/jdk: 8014892: More ProblemList.txt updates (5/2013) Message-ID: <20130521075910.6E4FC48BE3@hg.openjdk.java.net> Changeset: 20925206aef8 Author: alanb Date: 2013-05-21 08:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20925206aef8 8014892: More ProblemList.txt updates (5/2013) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From amy.lu at oracle.com Tue May 21 08:08:00 2013 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 21 May 2013 16:08:00 +0800 Subject: Code review request 8014892: More ProblemList.txt updates (5/2013) In-Reply-To: <519B27E7.8010204@oracle.com> References: <519A3C3D.3040504@oracle.com> <519B27E7.8010204@oracle.com> Message-ID: <519B2B60.60700@oracle.com> On 5/21/13 3:53 PM, Alan Bateman wrote: > On 20/05/2013 16:07, Amy Lu wrote: >> More ProblemList updates to remove three tests, the related issues >> have been fixed. >> >> Please review: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8014892/webrev/index.html >> >> >> Thanks, >> > Good to catch cases where we neglected to remove the tests from the > exclude list. The change looks fine to me. > > -Alan Thank you Alan for review. Alan/Chris, I'm not sure who can help to check-in this change. Thank you in advance. Thanks, Amy From mandy.chung at oracle.com Tue May 21 08:21:19 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 May 2013 09:21:19 +0100 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519AC2DA.5090302@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> Message-ID: <519B2E7F.7090005@oracle.com> On 5/21/2013 1:42 AM, Kurchi Hazra wrote: > > Hi, > > Please review this change to fix 718655. The bug complaints about > continuous BackingStoreExceptions > printed on the console, the user is just seeing logged warnings from > BackingStoreExceptions raised in periodic attempts to sync > preferences. Preferences use sun.util.logging.PlatformLogger.java > which is enabled by default, and has a default level of INFO. Changing > the logging in this file to FINE prevents the user from seeing > information that he/she is not interested in. > Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 > Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ > Looks good and L116 emits a INFO log message that should be changed to FINE too. Mandy From Alan.Bateman at oracle.com Tue May 21 08:26:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 09:26:16 +0100 Subject: RFR: 8014814 (str) StringBuffer "null" is not appended In-Reply-To: <519AD822.1060501@oracle.com> References: <5199B939.105@oracle.com> <5199D471.20903@oracle.com> <519A1471.3020102@oracle.com> <519AD822.1060501@oracle.com> Message-ID: <519B2FA8.4060209@oracle.com> On 21/05/2013 03:12, David Holmes wrote: > So I propose to push ahead with this fix in my offered form. > > I still need an official Review to do so, or else objections against > the proposal. I think what you have is fine, the other candidates were fine too. This issue is another reminder that we need to take care when touching this area, seems like most of the changes recently have caused or uncovered a problem (but luckily found quickly). -Alan From mandy.chung at oracle.com Tue May 21 08:35:44 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 May 2013 09:35:44 +0100 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519B2E7F.7090005@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> Message-ID: <519B31E0.3010605@oracle.com> Kurchi, The windows implementation also emits warning messages that should be fixed up too since we don't want to emit anything to interfere the application logging. The default logging configuration (default level is INFO) should apply to the application logging and the runtime like this case should have a different default level (e.g SEVERE) so that our implementation can use the appropriate level rather than forcing to use FINE etc. This is something for future enhancement (I'll file a RFE). For this bug, have you considered setting the level to SEVERE and change its default instead of changing to FINE? Mandy On 5/21/2013 9:21 AM, Mandy Chung wrote: > On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >> >> Hi, >> >> Please review this change to fix 718655. The bug complaints about >> continuous BackingStoreExceptions >> printed on the console, the user is just seeing logged warnings from >> BackingStoreExceptions raised in periodic attempts to sync >> preferences. Preferences use sun.util.logging.PlatformLogger.java >> which is enabled by default, and has a default level of INFO. >> Changing the logging in this file to FINE prevents the user from >> seeing information that he/she is not interested in. >> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >> > > Looks good and L116 emits a INFO log message that should be changed to > FINE too. > > Mandy From yong.huang at oracle.com Tue May 21 08:53:42 2013 From: yong.huang at oracle.com (yong.huang at oracle.com) Date: Tue, 21 May 2013 08:53:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130521085406.EFDE748BE7@hg.openjdk.java.net> Changeset: 63c7e92e5e6d Author: yhuang Date: 2013-05-20 23:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63c7e92e5e6d 7074882: Locale data needs correction (Month names for Maltese language) Reviewed-by: naoto ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 1fba35ef4360 Author: yhuang Date: 2013-05-21 01:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fba35ef4360 Merge From joel.franck at oracle.com Tue May 21 10:02:59 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 21 May 2013 10:02:59 +0000 Subject: hg: jdk8/tl/langtools: 8013180: Qualified type reference with annotations in throws list crashes compiler Message-ID: <20130521100302.A893E48BE8@hg.openjdk.java.net> Changeset: 67cbd6d756f4 Author: jfranck Date: 2013-05-21 12:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67cbd6d756f4 8013180: Qualified type reference with annotations in throws list crashes compiler Reviewed-by: jjg + test/tools/javac/annotations/typeAnnotations/8013180/QualifiedName.java From vicente.romero at oracle.com Tue May 21 10:42:05 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 10:42:05 +0000 Subject: hg: jdk8/tl/langtools: 7177168: Redundant array copy in UnsharedNameTable Message-ID: <20130521104209.7400548BEB@hg.openjdk.java.net> Changeset: 824932ecdbc8 Author: vromero Date: 2013-05-21 11:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/824932ecdbc8 7177168: Redundant array copy in UnsharedNameTable Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java From aleksej.efimov at oracle.com Tue May 21 11:02:28 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 21 May 2013 15:02:28 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com> <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com> <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com> Message-ID: <519B5444.7060701@oracle.com> Jason, Thank you for looking into this patch. Actually, the readObject calls the super.initCause, because there is no initCause in XPathException. About 'super.getCause() == null' check: yes it can be done in such way. In current version I caught the IllegalStateException to correctly process the situation when the cause was already initialized. If you think its better to use getCause() instead of it - I'll fix it in final review version. -Aleksej On 05/17/2013 11:59 PM, Jason Mehrens wrote: > Aleksej, > > Should readObject call super.initCause instead of this.initCause? Maybe initCause should be only called if scause != null && super.getCause() == null. If super.getCause is not null initCause will always fail. > > Jason > > ---------------------------------------- >> Date: Fri, 17 May 2013 23:34:35 +0400 >> From: aleksej.efimov at oracle.com >> To: core-libs-dev at openjdk.java.net; david.holmes at oracle.com; Alan.Bateman at oracle.com >> Subject: Re: RFR 8009581: Xpathexception does not honor initcause() >> >> Alan, David and other team! >> Resending the previous RFR 8009581 v.1. It might lost among the pack posts. >> >> Best regards, >> Aleksej >> >> On 11.05.2013 23:43, Aleksej Efimov wrote: >>> Hello Alan, David and other experts, >>> >>> I presents the second version of fix for XPathException class for your >>> review: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.1/ >>> >>> The serialized form remains the same in this patch, as was suggested. >>> I have also done some tests with serialization/deserialization of >>> XPathException class with different JDK versions. The class serialized >>> on JDK with patch was successfully deserialized by JDK versions >>> (6,7,8) without fix and vice versa. >>> >>> -Aleksej >>> >>> On 04/30/2013 11:08 AM, David Holmes wrote: >>>> 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 anthony.petrov at oracle.com Tue May 21 11:18:46 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 21 May 2013 15:18:46 +0400 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <519B1ABE.10303@oracle.com> References: <519B1ABE.10303@oracle.com> Message-ID: <519B5816.5080705@oracle.com> Hi Petr, The fix looks good to me. We still need a review from someone who maintains the Launcher code. Kumar? Also, you could use the @autoreleasepool directive to simplify it a bit, although I'm fine with the explicit syntax, too. One comment regarding your remark: > c. We would have lost all the hg history for this file. We wouldn't. Mercurial handles renaming of files very well. See `hg help rename` for more details. (I'm not suggesting to rename this file though.) -- best regards, Anthony On 05/21/2013 10:57 AM, David Holmes wrote: > Adding core-libs as this is actually a launcher change. > > David > > On 21/05/2013 4:36 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> http://bugs.sun.com/view_bug.do?bug_id=8009911 >> The webrev is available at: >> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >> >> The problem: >> When launching java with -XstatrOnFirstThread we were using >> dispatch_sync to start a Java main on the main thread. This blocked >> the main dispatch queue, so all the subsequent calls to GCD were never >> invoked. GCD is used a bit in our code, but it is used inside Cocoa, >> for example for fullscreen. >> >> The solution: >> We now launch Java main using a performSelectorOnMaintThread, so we do >> not block GCD. >> >> Notes: >> 1. This also fixes the following SWT bug: >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did >> not rename it to .m, because: >> a. It is hard to update an old build system to compile with the >> new file name. >> b. It is already compiled with -x objective-c, so I will compile >> c. We would have lost all the hg history for this file. >> >> With best regards. Petr. >> From vicente.romero at oracle.com Tue May 21 11:18:20 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 11:18:20 +0000 Subject: hg: jdk8/tl/langtools: 7060779: test/tools/javac/diags/Example.java leaves directories in tempdir Message-ID: <20130521111823.EE51348BEC@hg.openjdk.java.net> Changeset: 3d9750039fff Author: vromero Date: 2013-05-21 12:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d9750039fff 7060779: test/tools/javac/diags/Example.java leaves directories in tempdir Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java From joel.franck at oracle.com Tue May 21 11:49:17 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 21 May 2013 13:49:17 +0200 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement In-Reply-To: <519A9135.9000002@oracle.com> References: <519A9135.9000002@oracle.com> Message-ID: Hi Joe, I applied the patch and built a jdk, looks good to me. (Not a Reviewer kind of reviewer tough.) cheers /Joel On 20 maj 2013, at 23:10, Joe Darcy wrote: > Hello, > > Please review the patch below which implements > > 8014836: Have GenericDeclaration extend AnnotatedElement > > All the existing implementations of GenericDeclaration in the JDK already implement AnnotatedElement. Some code in java.lang.Class needed to be adjusted slightly since AnnotatedElement declares a default method and calling an interface's default method in an implementing class has to go through the direct interface type. > > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 2013 -0700 > +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 2013 -0700 > @@ -28,6 +28,7 @@ > import java.lang.reflect.AnnotatedElement; > import java.lang.reflect.Array; > import java.lang.reflect.GenericArrayType; > +import java.lang.reflect.GenericDeclaration; > import java.lang.reflect.Member; > import java.lang.reflect.Field; > import java.lang.reflect.Executable; > @@ -115,9 +116,9 @@ > * @since JDK1.0 > */ > public final class Class implements java.io.Serializable, > - java.lang.reflect.GenericDeclaration, > - java.lang.reflect.Type, > - java.lang.reflect.AnnotatedElement { > + GenericDeclaration, > + Type, > + AnnotatedElement { > private static final int ANNOTATION= 0x00002000; > private static final int ENUM = 0x00004000; > private static final int SYNTHETIC = 0x00001000; > @@ -3182,7 +3183,7 @@ > */ > @Override > public boolean isAnnotationPresent(Class annotationClass) { > - return AnnotatedElement.super.isAnnotationPresent(annotationClass); > + return GenericDeclaration.super.isAnnotationPresent(annotationClass); > } > > /** > diff -r 6a9148865139 src/share/classes/java/lang/reflect/GenericDeclaration.java > --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon May 20 11:56:46 2013 -0700 > +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java Mon May 20 14:07:15 2013 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 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 > @@ -30,7 +30,7 @@ > * > * @since 1.5 > */ > -public interface GenericDeclaration { > +public interface GenericDeclaration extends AnnotatedElement { > /** > * Returns an array of {@code TypeVariable} objects that > * represent the type variables declared by the generic > From aleksey.shipilev at oracle.com Tue May 21 12:35:26 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 21 May 2013 16:35:26 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended Message-ID: <519B6A0E.5060304@oracle.com> Hi, It is time to add the proper Javadoc to @Contended: http://cr.openjdk.java.net/~shade/8014966/webrev.01/ Testing: - built jdk8-tl on Linux x86_64/release without a hitch. Please review and sponsor! Thanks, -Aleksey. From vicente.romero at oracle.com Tue May 21 12:51:37 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 12:51:37 +0000 Subject: hg: jdk8/tl/langtools: 8005207: test has 2 @bug tags Message-ID: <20130521125141.2FAA948BF3@hg.openjdk.java.net> Changeset: 37295244f534 Author: vromero Date: 2013-05-21 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37295244f534 8005207: test has 2 @bug tags Reviewed-by: mcimadamore ! test/tools/doclint/RunTest.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/policy/test3/Test.java From vicente.romero at oracle.com Tue May 21 13:33:41 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 21 May 2013 13:33:41 +0000 Subject: hg: jdk8/tl/langtools: 7164114: Two jtreg tests are not run due to no file extension on the test files Message-ID: <20130521133343.D6F9F48BF5@hg.openjdk.java.net> Changeset: 08daea43a7f8 Author: vromero Date: 2013-05-21 14:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/08daea43a7f8 7164114: Two jtreg tests are not run due to no file extension on the test files Reviewed-by: mcimadamore - test/tools/javac/HiddenAbstractMethod/Test + test/tools/javac/HiddenAbstractMethod/Test.java - test/tools/javac/NonAmbiguousField/Test + test/tools/javac/NonAmbiguousField/Test.java ! test/tools/javac/NonAmbiguousField/two/Child2.java From kurchi.subhra.hazra at oracle.com Tue May 21 14:01:59 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 21 May 2013 07:01:59 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519B31E0.3010605@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> <519B31E0.3010605@oracle.com> Message-ID: <519B7E57.1090207@oracle.com> On 5/21/13 1:35 AM, Mandy Chung wrote: > Kurchi, > > The windows implementation also emits warning messages that should be > fixed up too since we don't want to emit anything to interfere the > application logging. The default logging configuration (default level > is INFO) should apply to the application logging and the runtime like > this case should have a different default level (e.g SEVERE) so that > our implementation can use the appropriate level rather than forcing > to use FINE etc. This is something for future enhancement (I'll file > a RFE). > > For this bug, have you considered setting the level to SEVERE and > change its default instead of changing to FINE? Thanks for the review. That did occur to me, but I was not sure which one is preferable. I will do the relevant changes and get back with another webrev. - Kurchi > > Mandy > > On 5/21/2013 9:21 AM, Mandy Chung wrote: >> On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >>> >>> Hi, >>> >>> Please review this change to fix 718655. The bug complaints about >>> continuous BackingStoreExceptions >>> printed on the console, the user is just seeing logged warnings from >>> BackingStoreExceptions raised in periodic attempts to sync >>> preferences. Preferences use sun.util.logging.PlatformLogger.java >>> which is enabled by default, and has a default level of INFO. >>> Changing the logging in this file to FINE prevents the user from >>> seeing information that he/she is not interested in. >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >>> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >>> >> >> Looks good and L116 emits a INFO log message that should be changed >> to FINE too. >> >> Mandy > From chris.hegarty at oracle.com Tue May 21 15:58:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 21 May 2013 16:58:48 +0100 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: References: <5197345C.9070802@oracle.com> Message-ID: <519B99B8.7090703@oracle.com> On 05/21/2013 06:07 AM, Mike Duigou wrote: > Looks good. > > Since the char array is never modified it could use the String(char[], boolean) constructor. This has advantages for cases such as logging which may read the thread name very many times. Thanks Mike, this would be a nice improvement. Final webrev: http://cr.openjdk.java.net/~chegar/8010182/webrev.01/webrev/ -Chris. > > Mike > > On May 18 2013, at 00:57 , Chris Hegarty wrote: > >> Thread getName and setName are not thread-safe. The "expected" usage is to set a name before starting the thread and only read it thereafter. >> >> It is desirable to support the setting of thread name dynamically, mainly for monitoring/management/debugging. The typical scenario is the single-writer, multiple-reader case. So, making name volatile is sufficient. However, setName also sets the native thread name. This is currently restricted to the current thread, since there could be a race if the thread is terminating. Making setName synchronized would eliminate that race, and allow for the native thread name to be set from other threads. >> >> This issue came up on c-i a while back [1]. >> >> http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ >> >> -Chris. >> >> [1] http://cs.oswego.edu/pipermail/concurrency-interest/2013-March/010935.html > From mike.duigou at oracle.com Tue May 21 16:40:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 09:40:39 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519B2E7F.7090005@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> Message-ID: Any chance that it would be possible to stop the periodic attempts to sync preferences? The log spamming is a symptom, not the cause. Could the prefs code be enhanced to better determine if writing is possible before attempting and failing? Mike On May 21 2013, at 01:21 , Mandy Chung wrote: > On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >> >> Hi, >> >> Please review this change to fix 718655. The bug complaints about continuous BackingStoreExceptions >> printed on the console, the user is just seeing logged warnings from BackingStoreExceptions raised in periodic attempts to sync preferences. Preferences use sun.util.logging.PlatformLogger.java which is enabled by default, and has a default level of INFO. Changing the logging in this file to FINE prevents the user from seeing information that he/she is not interested in. >> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >> > > Looks good and L116 emits a INFO log message that should be changed to FINE too. > > Mandy From mike.duigou at oracle.com Tue May 21 16:45:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 09:45:44 -0700 Subject: Trivial RFR: 8014857 Enable ergonomic VM selection in arm/jvm.cfg In-Reply-To: <519AFFD3.6050808@oracle.com> References: <5199851E.1060304@oracle.com> <519AFFD3.6050808@oracle.com> Message-ID: I don't have any way to verify this change but comparing it to the other jvm.cfg files it appears to be correct. Mike On May 20 2013, at 22:02 , David Holmes wrote: > Anybody? :( > > David > > On 20/05/2013 12:06 PM, David Holmes wrote: >> The contents of the ARM jvm.cfg were put in place for the SE Embedded >> product, but for the SE ARM implementation we want to enable ergonomics, >> as we do on other platforms. >> >> http://cr.openjdk.java.net/~dholmes/8014857/webrev/ >> >> --- old/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:30.424314843 -0400 >> +++ new/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:29.192246170 -0400 >> @@ -30,6 +30,6 @@ >> # "-XXaltjvm=" option, but that too is unsupported >> # and may not be available in a future release. >> # >> --client KNOWN >> +-client IF_SERVER_CLASS -server >> -server KNOWN >> -minimal KNOWN >> >> Tested VM selection on both server class and non-server class devices. >> >> Thanks, >> David From jason_mehrens at hotmail.com Tue May 21 16:51:03 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 21 May 2013 11:51:03 -0500 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <519B5444.7060701@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> Message-ID: Aleksej, > Actually, the readObject calls the super.initCause, because there is no > initCause in XPathException. I would think that subclasses of XPE will see calls to this.initCause from readObject. That wouldn't have happened prior to this change. > About 'super.getCause() == null' check: yes it can be done in such way. > In current version I caught the IllegalStateException to correctly > process the situation when the cause was already initialized. I think you'll always have to catch ISE. If super.getCause is not null you know initCause will fail. I would think it would be cheaper to null check than to fillStackTrace. But, I haven't tested that. Jason From kurchi.subhra.hazra at oracle.com Tue May 21 16:53:59 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 21 May 2013 09:53:59 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> Message-ID: <519BA6A7.5040400@oracle.com> On 5/21/13 9:40 AM, Mike Duigou wrote: > Any chance that it would be possible to stop the periodic attempts to sync preferences? - I did think of that too - but the syncing may fail(temporarily) if the prefs object could not retrieve the lock to the associated prefs file. We could stop syncing attempts if the sync fails say n number of times - but I do not think that is a good solution. We may however be able to stop the syncing attempts if we are guaranteed by some error code that any future writing attempts will fail. I'll check on that. - Kurchi > > The log spamming is a symptom, not the cause. > > Could the prefs code be enhanced to better determine if writing is possible before attempting and failing? > > Mike > > On May 21 2013, at 01:21 , Mandy Chung wrote: > >> On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >>> Hi, >>> >>> Please review this change to fix 718655. The bug complaints about continuous BackingStoreExceptions >>> printed on the console, the user is just seeing logged warnings from BackingStoreExceptions raised in periodic attempts to sync preferences. Preferences use sun.util.logging.PlatformLogger.java which is enabled by default, and has a default level of INFO. Changing the logging in this file to FINE prevents the user from seeing information that he/she is not interested in. >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >>> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >>> >> Looks good and L116 emits a INFO log message that should be changed to FINE too. >> >> Mandy From kurchi.subhra.hazra at oracle.com Tue May 21 17:04:53 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 21 May 2013 10:04:53 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519BA6A7.5040400@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> <519BA6A7.5040400@oracle.com> Message-ID: <519BA935.3090407@oracle.com> On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote: > On 5/21/13 9:40 AM, Mike Duigou wrote: >> Any chance that it would be possible to stop the periodic attempts to >> sync preferences? > > - I did think of that too - but the syncing may fail(temporarily) if > the prefs object could not retrieve the lock to the > associated prefs file. We could stop syncing attempts if the sync > fails say n number of times - but I do not think > that is a good solution. - Just to add, why I don't think the above is a good solution, one might be trying to acquire lock on a remote file over NFS, and the syncing may fail temporarily because of an erratic network connection. > We may however be able to stop the syncing attempts if we are > guaranteed by some error code that any future > writing attempts will fail. I'll check on that. > > - Kurchi > >> >> The log spamming is a symptom, not the cause. >> >> Could the prefs code be enhanced to better determine if writing is >> possible before attempting and failing? >> >> Mike >> >> On May 21 2013, at 01:21 , Mandy Chung wrote: >> >>> On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> Please review this change to fix 718655. The bug complaints >>>> about continuous BackingStoreExceptions >>>> printed on the console, the user is just seeing logged warnings >>>> from BackingStoreExceptions raised in periodic attempts to sync >>>> preferences. Preferences use sun.util.logging.PlatformLogger.java >>>> which is enabled by default, and has a default level of INFO. >>>> Changing the logging in this file to FINE prevents the user from >>>> seeing information that he/she is not interested in. >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >>>> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >>>> >>> Looks good and L116 emits a INFO log message that should be changed >>> to FINE too. >>> >>> Mandy > From mike.duigou at oracle.com Tue May 21 17:19:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 10:19:46 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519BA6A7.5040400@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> <519BA6A7.5040400@oracle.com> Message-ID: <53D85673-5A3F-4A40-B176-E2545E38D7CA@oracle.com> On May 21 2013, at 09:53 , Kurchi Subhra Hazra wrote: > On 5/21/13 9:40 AM, Mike Duigou wrote: >> Any chance that it would be possible to stop the periodic attempts to sync preferences? > > - I did think of that too - but the syncing may fail(temporarily) if the prefs object could not retrieve the lock to the > associated prefs file. We could stop syncing attempts if the sync fails say n number of times - but I do not think > that is a good solution. My experience with this problem is that the prefs code tries again forever at once per second for the entire life of the VM. This never seemed appropriate. This issue has been around a very long time as: http://bugs.sun.com/view_bug.do?bug_id=4532628 java.util.prefs system prefs directory setup should be added to install script and the oldest one I could find: http://bugs.sun.com/view_bug.do?bug_id=4398496 Usually this is caused by installing Java on a system from the tarballs rather than using the installer. BTW, whoever decided to name the prefs files in /etc ".java/" and ".systemPrefs/" was evil and/or foolish. Mike > We may however be able to stop the syncing attempts if we are guaranteed by some error code that any future > writing attempts will fail. I'll check on that. > > - Kurchi > >> >> The log spamming is a symptom, not the cause. >> >> Could the prefs code be enhanced to better determine if writing is possible before attempting and failing? >> >> Mike >> >> On May 21 2013, at 01:21 , Mandy Chung wrote: >> >>> On 5/21/2013 1:42 AM, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> Please review this change to fix 718655. The bug complaints about continuous BackingStoreExceptions >>>> printed on the console, the user is just seeing logged warnings from BackingStoreExceptions raised in periodic attempts to sync preferences. Preferences use sun.util.logging.PlatformLogger.java which is enabled by default, and has a default level of INFO. Changing the logging in this file to FINE prevents the user from seeing information that he/she is not interested in. >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555 >>>> Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/ >>>> >>> Looks good and L116 emits a INFO log message that should be changed to FINE too. >>> >>> Mandy > From mike.duigou at oracle.com Tue May 21 17:28:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 10:28:46 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: <519BA935.3090407@oracle.com> References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> <519BA6A7.5040400@oracle.com> <519BA935.3090407@oracle.com> Message-ID: On May 21 2013, at 10:04 , Kurchi Subhra Hazra wrote: > On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote: >> On 5/21/13 9:40 AM, Mike Duigou wrote: >>> Any chance that it would be possible to stop the periodic attempts to sync preferences? >> >> - I did think of that too - but the syncing may fail(temporarily) if the prefs object could not retrieve the lock to the >> associated prefs file. We could stop syncing attempts if the sync fails say n number of times - but I do not think >> that is a good solution. > - Just to add, why I don't think the above is a good solution, one might be trying to acquire lock on a remote file > over NFS, and the syncing may fail temporarily because of an erratic network connection. Understood. The flip side of this is that we could have an unproductive process that consumes network resources every second for the entire life of the VM. Some kind of compromise that handles transient failures while also not mindlessly making attempts that will never work is needed. Mike From kurchi.subhra.hazra at oracle.com Tue May 21 18:46:08 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 21 May 2013 11:46:08 -0700 Subject: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux In-Reply-To: References: <518D8429.7060903@oracle.com> <519AC2DA.5090302@oracle.com> <519B2E7F.7090005@oracle.com> <519BA6A7.5040400@oracle.com> <519BA935.3090407@oracle.com> Message-ID: <519BC0F0.2090005@oracle.com> Right - I think I can disable syncing attempts for a file once we get an EACCESS error code . Locked files should return EAGAIN. I'll have to check on how this works on Solaris/Linux/Mac and will follow up. Thanks for digging up the history. - Kurchi On 5/21/2013 10:28 AM, Mike Duigou wrote: > On May 21 2013, at 10:04 , Kurchi Subhra Hazra wrote: > >> On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote: >>> On 5/21/13 9:40 AM, Mike Duigou wrote: >>>> Any chance that it would be possible to stop the periodic attempts to sync preferences? >>> - I did think of that too - but the syncing may fail(temporarily) if the prefs object could not retrieve the lock to the >>> associated prefs file. We could stop syncing attempts if the sync fails say n number of times - but I do not think >>> that is a good solution. >> - Just to add, why I don't think the above is a good solution, one might be trying to acquire lock on a remote file >> over NFS, and the syncing may fail temporarily because of an erratic network connection. > Understood. The flip side of this is that we could have an unproductive process that consumes network resources every second for the entire life of the VM. Some kind of compromise that handles transient failures while also not mindlessly making attempts that will never work is needed. > > Mike -- -Kurchi From petr.pchelko at oracle.com Tue May 21 11:07:47 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 21 May 2013 15:07:47 +0400 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <519B1ABE.10303@oracle.com> References: <519B1ABE.10303@oracle.com> Message-ID: <0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com> Added macosx-port-dev On May 21, 2013, at 10:57 AM, David Holmes wrote: > Adding core-libs as this is actually a launcher change. > > David > > On 21/05/2013 4:36 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> http://bugs.sun.com/view_bug.do?bug_id=8009911 >> The webrev is available at: >> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >> >> The problem: >> When launching java with -XstatrOnFirstThread we were using dispatch_sync to start a Java main on the main thread. This blocked the main dispatch queue, so all the subsequent calls to GCD were never invoked. GCD is used a bit in our code, but it is used inside Cocoa, for example for fullscreen. >> >> The solution: >> We now launch Java main using a performSelectorOnMaintThread, so we do not block GCD. >> >> Notes: >> 1. This also fixes the following SWT bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did not rename it to .m, because: >> a. It is hard to update an old build system to compile with the new file name. >> b. It is already compiled with -x objective-c, so I will compile >> c. We would have lost all the hg history for this file. >> >> With best regards. Petr. >> From david.r.chase at oracle.com Tue May 21 21:15:43 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 21 May 2013 17:15:43 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <519AC0FC.9040300@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> Message-ID: <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> http://cr.openjdk.java.net/~drchase/7088419/webrev.03/ Newer, slimmer webrev. No fork/join, the related code is removed (except the native init routine still returns a boolean, which is currently ignored, indicating if it supports the faster crc32). What remains is: 1) no-JNI fast-path for short CRCs and Adlers 2) reformulated faster-Adler for byte-at-a-time 3) For 32/64 Linux/Solaris/MacOS x86 Sandy Bridge or better (with CLMUL and AVX), fast code for CRCs. For now it uses assembly language, the C-with-intrinsics is included, and compiles with current clang and gcc. It tickles a bug in Solaris Studio 12.3 which has been reported. Optimization for Windows is disabled because the assembler syntax is too different The code has been tested by-hand across Linux (32), Solaris (32 and 64), MacOS (64) and has also passed JPRT (which is to say, the failures were unrelated, hand examination of the runs showed that the new CRCandAdler test was successful. Anyone checking my most recent run will notice that I am not very good at specifying tests to run, but there is an earlier run. I'm trying again, just to see if I can figure out how to make it behave.) There is a companion webrev on the hotspot side that sets the secret property that is used and reset by this code. I hope this will be more easily regarded as a "bug fix" and less as an interface change. David On 2013-05-20, at 8:34 PM, David Holmes wrote: > On 21/05/2013 3:45 AM, Alan Bateman wrote: >> On 20/05/2013 14:49, David Chase wrote: >>> Suppose I split this bug (i.e., file a new bug) into the >>> Intel-acceleration part and the fork-join part. >>> : >>> >> This make sense. > > I agree. > > I also don't have an issue with eliding the optimization on Windows for the time being. > > David > >> -Alan. From mike.duigou at oracle.com Tue May 21 22:42:22 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 15:42:22 -0700 Subject: RFR : 8014819 : set max size for jtreg test vms Message-ID: <49CC7B8A-CC29-4055-AF7C-47ED93F322AC@oracle.com> Hello all; A lot more people have been playing with using concurrency lately with JTReg and most have found that tests will frequently fail or error out because of OOM errors. The problem is that the jdk/test/Makefile currently doesn't specify a size for the vm instances used for running tests. This results in "VM Ergonomics" sizing being used and the test VMs which get created are generally too large to run very many of them. This patch sets a specific size to the vm instances created to run tests, 512MB. This value has been successfully used to run tests by our internal SQE team and by Alan Bateman for quite some time. It also seems to work for me. Individual tests which require more memory can specify their requirements using explicit -Xmx options in @run tags. http://cr.openjdk.java.net/~mduigou/JDK-8014819/0/webrev/ Thanks, Mike From mike.duigou at oracle.com Tue May 21 22:45:05 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 May 2013 15:45:05 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> References: <51943FDE.5030009@oracle.com> <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> Message-ID: <7EBBDD2B-38D0-45E6-AC73-CF8C939BE83F@oracle.com> Ping! I need a final review on this issue. Thanks, Mike On May 16 2013, at 14:02 , Mike Duigou wrote: > > On May 15 2013, at 19:09 , Joseph Darcy wrote: > >> Hi Mike, >> >> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? > > I hadn't actually looked but it turns out the answer was "No, certainly not". > > I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that. > > If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those. > > http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/ > > Mike > >> >> -Joe >> >> On 5/15/2013 6:17 PM, Mike Duigou wrote: >>> Hello all; >>> >>> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >>> >>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. >>> >>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. >>> >>> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. >>> >>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). >>> >>> Thanks, >>> >>> Mike >> > From joe.darcy at oracle.com Wed May 22 00:01:21 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 21 May 2013 17:01:21 -0700 Subject: RFR : 8014819 : set max size for jtreg test vms In-Reply-To: <49CC7B8A-CC29-4055-AF7C-47ED93F322AC@oracle.com> References: <49CC7B8A-CC29-4055-AF7C-47ED93F322AC@oracle.com> Message-ID: <519C0AD1.6000300@oracle.com> Looks fine. -Joe On 5/21/2013 3:42 PM, Mike Duigou wrote: > Hello all; > > A lot more people have been playing with using concurrency lately with JTReg and most have found that tests will frequently fail or error out because of OOM errors. The problem is that the jdk/test/Makefile currently doesn't specify a size for the vm instances used for running tests. This results in "VM Ergonomics" sizing being used and the test VMs which get created are generally too large to run very many of them. > > This patch sets a specific size to the vm instances created to run tests, 512MB. This value has been successfully used to run tests by our internal SQE team and by Alan Bateman for quite some time. It also seems to work for me. Individual tests which require more memory can specify their requirements using explicit -Xmx options in @run tags. > > http://cr.openjdk.java.net/~mduigou/JDK-8014819/0/webrev/ > > Thanks, > > Mike From joe.darcy at oracle.com Wed May 22 03:20:30 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 21 May 2013 20:20:30 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: <7EBBDD2B-38D0-45E6-AC73-CF8C939BE83F@oracle.com> References: <51943FDE.5030009@oracle.com> <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> <7EBBDD2B-38D0-45E6-AC73-CF8C939BE83F@oracle.com> Message-ID: <519C397E.8010307@oracle.com> Hello Mike, The TestNG data provider framework is unfamiliar to me, so my first reaction is that it is overkill for this problem as opposed to a one-off approach, but that may be driven my lack of experience with it. However, in the test code 153 private static final long[] SOME_PRIMES = { 154 3L, 5L, 7L, 11L, 13L, 17L, 19L, 23L, 29L, 31L, 37L, 41L, 43L, 47L, 53L, 155 59L, 61L, 71L, 73L, 79L, Long.MIN_VALUE }; the name of the array is incorrect since Long.MIN_VALUE = -2^63 which is composite. Perhaps you were thinking of Integer.MAX_VALUE which is a Mersenne prime? (2^61 -1 is a Mersenne prime; 2^63 - 1 is not.) -Joe On 5/21/2013 3:45 PM, Mike Duigou wrote: > Ping! > > I need a final review on this issue. > > Thanks, > > Mike > > On May 16 2013, at 14:02 , Mike Duigou wrote: > >> On May 15 2013, at 19:09 , Joseph Darcy wrote: >> >>> Hi Mike, >>> >>> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? >> I hadn't actually looked but it turns out the answer was "No, certainly not". >> >> I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that. >> >> If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/ >> >> Mike >> >>> -Joe >>> >>> On 5/15/2013 6:17 PM, Mike Duigou wrote: >>>> Hello all; >>>> >>>> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >>>> >>>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. >>>> >>>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. >>>> >>>> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. >>>> >>>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). >>>> >>>> Thanks, >>>> >>>> Mike From david.holmes at oracle.com Wed May 22 04:17:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2013 14:17:18 +1000 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <519B99B8.7090703@oracle.com> References: <5197345C.9070802@oracle.com> <519B99B8.7090703@oracle.com> Message-ID: <519C46CE.1080409@oracle.com> Still okay with me. Thanks, David On 22/05/2013 1:58 AM, Chris Hegarty wrote: > On 05/21/2013 06:07 AM, Mike Duigou wrote: >> Looks good. >> >> Since the char array is never modified it could use the String(char[], >> boolean) constructor. This has advantages for cases such as logging >> which may read the thread name very many times. > > Thanks Mike, this would be a nice improvement. > > Final webrev: > http://cr.openjdk.java.net/~chegar/8010182/webrev.01/webrev/ > > -Chris. > >> >> Mike >> >> On May 18 2013, at 00:57 , Chris Hegarty wrote: >> >>> Thread getName and setName are not thread-safe. The "expected" usage >>> is to set a name before starting the thread and only read it thereafter. >>> >>> It is desirable to support the setting of thread name dynamically, >>> mainly for monitoring/management/debugging. The typical scenario is >>> the single-writer, multiple-reader case. So, making name volatile is >>> sufficient. However, setName also sets the native thread name. This >>> is currently restricted to the current thread, since there could be a >>> race if the thread is terminating. Making setName synchronized would >>> eliminate that race, and allow for the native thread name to be set >>> from other threads. >>> >>> This issue came up on c-i a while back [1]. >>> >>> http://cr.openjdk.java.net/~chegar/8010182/webrev.00/webrev/ >>> >>> -Chris. >>> >>> [1] >>> http://cs.oswego.edu/pipermail/concurrency-interest/2013-March/010935.html >>> >> From joe.darcy at oracle.com Wed May 22 05:33:52 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 21 May 2013 22:33:52 -0700 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <519B5816.5080705@oracle.com> References: <519B1ABE.10303@oracle.com> <519B5816.5080705@oracle.com> Message-ID: <519C58C0.4010309@oracle.com> Hello, Yes; Kumar should be one of the reviewers here. Thanks, -Joe On 05/21/2013 04:18 AM, Anthony Petrov wrote: > Hi Petr, > > The fix looks good to me. We still need a review from someone who > maintains the Launcher code. Kumar? > > Also, you could use the @autoreleasepool directive to simplify it a > bit, although I'm fine with the explicit syntax, too. > > One comment regarding your remark: >> c. We would have lost all the hg history for this file. > > We wouldn't. Mercurial handles renaming of files very well. See `hg > help rename` for more details. (I'm not suggesting to rename this file > though.) > > -- > best regards, > Anthony > > On 05/21/2013 10:57 AM, David Holmes wrote: >> Adding core-libs as this is actually a launcher change. >> >> David >> >> On 21/05/2013 4:36 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the issue: >>> http://bugs.sun.com/view_bug.do?bug_id=8009911 >>> The webrev is available at: >>> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >>> >>> The problem: >>> When launching java with -XstatrOnFirstThread we were using >>> dispatch_sync to start a Java main on the main thread. This blocked >>> the main dispatch queue, so all the subsequent calls to GCD were never >>> invoked. GCD is used a bit in our code, but it is used inside Cocoa, >>> for example for fullscreen. >>> >>> The solution: >>> We now launch Java main using a performSelectorOnMaintThread, so we do >>> not block GCD. >>> >>> Notes: >>> 1. This also fixes the following SWT bug: >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >>> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did >>> not rename it to .m, because: >>> a. It is hard to update an old build system to compile with the >>> new file name. >>> b. It is already compiled with -x objective-c, so I will compile >>> c. We would have lost all the hg history for this file. >>> >>> With best regards. Petr. >>> From Alan.Bateman at oracle.com Wed May 22 08:14:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2013 09:14:43 +0100 Subject: RFR : 8014819 : set max size for jtreg test vms In-Reply-To: <49CC7B8A-CC29-4055-AF7C-47ED93F322AC@oracle.com> References: <49CC7B8A-CC29-4055-AF7C-47ED93F322AC@oracle.com> Message-ID: <519C7E73.20405@oracle.com> On 21/05/2013 23:42, Mike Duigou wrote: > Hello all; > > A lot more people have been playing with using concurrency lately with JTReg and most have found that tests will frequently fail or error out because of OOM errors. The problem is that the jdk/test/Makefile currently doesn't specify a size for the vm instances used for running tests. This results in "VM Ergonomics" sizing being used and the test VMs which get created are generally too large to run very many of them. > > This patch sets a specific size to the vm instances created to run tests, 512MB. This value has been successfully used to run tests by our internal SQE team and by Alan Bateman for quite some time. It also seems to work for me. Individual tests which require more memory can specify their requirements using explicit -Xmx options in @run tags. > > http://cr.openjdk.java.net/~mduigou/JDK-8014819/0/webrev/ > > Thanks, > > Mike Looks okay to me, I've always used -Xmx512m when running with agentvm and that value seems to work well for the jdk tests. -Alan From Alan.Bateman at oracle.com Wed May 22 08:15:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2013 09:15:00 +0100 Subject: RFR 8010182: Thread safety of Thread get/setName() In-Reply-To: <519C46CE.1080409@oracle.com> References: <5197345C.9070802@oracle.com> <519B99B8.7090703@oracle.com> <519C46CE.1080409@oracle.com> Message-ID: <519C7E84.2020207@oracle.com> On 22/05/2013 05:17, David Holmes wrote: > Still okay with me. > Still okay with me too. -Alan From chris.hegarty at oracle.com Wed May 22 12:52:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 22 May 2013 12:52:14 +0000 Subject: hg: jdk8/tl/jdk: 8010182: Thread safety of Thread get/setName() Message-ID: <20130522125238.761DE48C39@hg.openjdk.java.net> Changeset: 48e8a6e0c805 Author: chegar Date: 2013-05-22 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48e8a6e0c805 8010182: Thread safety of Thread get/setName() Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/lang/Thread.java From forax at univ-mlv.fr Wed May 22 15:36:02 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 22 May 2013 17:36:02 +0200 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement In-Reply-To: <519ACAD0.1030505@oracle.com> References: <519A9135.9000002@oracle.com> <519A9589.9040002@univ-mlv.fr> <519ACAD0.1030505@oracle.com> Message-ID: <519CE5E2.2020901@univ-mlv.fr> On 05/21/2013 03:16 AM, Joseph Darcy wrote: > Hi Remi, > > On 5/20/2013 2:28 PM, Remi Forax wrote: >> On 05/20/2013 11:10 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the patch below which implements >>> >>> 8014836: Have GenericDeclaration extend AnnotatedElement >>> >>> All the existing implementations of GenericDeclaration in the JDK >>> already implement AnnotatedElement. Some code in java.lang.Class >>> needed to be adjusted slightly since AnnotatedElement declares a >>> default method and calling an interface's default method in an >>> implementing class has to go through the direct interface type. >> >> GenericDeclaration is a public interface, so you will break the code >> of everyone that implements it. >> By example, Guava's Invokable also implements GenericDeclaration >> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/reflect/Invokable.html >> > > That is technically true; in effect adding several methods to > GenericDeclaration would break implementations outside of the JDK that > do not already implement annotated element. > > However, this is (only) a source incompatible change and not a binary > incompatible change so is possible in-bounds for a platform release > like JDK 8: > > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy > > > The Invokable type you reference is the moral equivalent of the > "Executable" superclass of Constructor and Method added earlier in JDK > 8. The Invokable type itself is marked as "@Beta" to warn users that > it could change or even to away. Therefore, I'm not very concerned > about "breaking" a type like this, which could easily be retrofitted > to also implement AnnotatedElement as it already a wrapper around a > Method or a Constructor. For me, it's not just a source incompatible change, let suppose that I use Guava reflection API in my program and the jdk8, I will be able to get a GenericDeclaration that will fail at runtime if I try to call a method of AnnotatedElement on it. So this change make the existing Guava library not forward compatible. With the introduction of default methods, we now have a way to make change in interfaces backward compatible, I don't say that we should use default methods here, I don't know. But I think it worth to think about that. I've just seen that AnnotatedElement also includes new new abstract methods. > > (Also interesting to see a "Parameter" class in Guava given that we > have added a Parameter class to java.lang.reflect.) yes, but there is no getName() :) > > Thanks, > > -Joe cheers, R?mi > >> >>> >>> Thanks, >>> >>> -Joe >> >> R?mi >> >>> >>> --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 >>> 2013 -0700 >>> +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 >>> 2013 -0700 >>> @@ -28,6 +28,7 @@ >>> import java.lang.reflect.AnnotatedElement; >>> import java.lang.reflect.Array; >>> import java.lang.reflect.GenericArrayType; >>> +import java.lang.reflect.GenericDeclaration; >>> import java.lang.reflect.Member; >>> import java.lang.reflect.Field; >>> import java.lang.reflect.Executable; >>> @@ -115,9 +116,9 @@ >>> * @since JDK1.0 >>> */ >>> public final class Class implements java.io.Serializable, >>> - java.lang.reflect.GenericDeclaration, >>> - java.lang.reflect.Type, >>> - java.lang.reflect.AnnotatedElement { >>> + GenericDeclaration, >>> + Type, >>> + AnnotatedElement { >>> private static final int ANNOTATION= 0x00002000; >>> private static final int ENUM = 0x00004000; >>> private static final int SYNTHETIC = 0x00001000; >>> @@ -3182,7 +3183,7 @@ >>> */ >>> @Override >>> public boolean isAnnotationPresent(Class >>> annotationClass) { >>> - return >>> AnnotatedElement.super.isAnnotationPresent(annotationClass); >>> + return >>> GenericDeclaration.super.isAnnotationPresent(annotationClass); >>> } >>> >>> /** >>> diff -r 6a9148865139 >>> src/share/classes/java/lang/reflect/GenericDeclaration.java >>> --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java >>> Mon May 20 11:56:46 2013 -0700 >>> +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java >>> Mon May 20 14:07:15 2013 -0700 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2003, 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 >>> @@ -30,7 +30,7 @@ >>> * >>> * @since 1.5 >>> */ >>> -public interface GenericDeclaration { >>> +public interface GenericDeclaration extends AnnotatedElement { >>> /** >>> * Returns an array of {@code TypeVariable} objects that >>> * represent the type variables declared by the generic >>> >> > From alexey.utkin at oracle.com Wed May 22 16:07:59 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Wed, 22 May 2013 20:07:59 +0400 Subject: Review request: JDK-8014394 (fs) WatchService failing when watching \\server\$d Message-ID: <519CED5F.5030309@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-8014394 http://bugs.sun.com/view_bug.do?bug_id=8014394 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.00/ Summary: The problem source is the ERROR_MORE_DATA warning event that was treated as error. The suggested fix contains limited refactoring that can be critical for further support. The main changes are: -- The [WAKEUP_COMPLETION_KEY] constant was introduced instead "magic" zero value. -- The capacity of the completion key set was extended for x64 platform in accordance with MS documentation. -- The [OVERLAPPED] structure is initialized correctly in native code. I regret about the absence of a common code with [sun.nio.ch] package that has similar problems. Regards, -uta From mike.duigou at oracle.com Wed May 22 17:01:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 22 May 2013 17:01:19 +0000 Subject: hg: jdk8/tl/jdk: 8014819: set max size for jtreg testvms Message-ID: <20130522170130.DB0FB48C45@hg.openjdk.java.net> Changeset: 4b555b53dc57 Author: mduigou Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b555b53dc57 8014819: set max size for jtreg testvms Reviewed-by: alanb, darcy ! test/Makefile From mike.duigou at oracle.com Wed May 22 17:53:05 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 22 May 2013 10:53:05 -0700 Subject: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 In-Reply-To: <519C397E.8010307@oracle.com> References: <51943FDE.5030009@oracle.com> <8377D69D-67A8-4077-82ED-4989B568B107@oracle.COM> <7EBBDD2B-38D0-45E6-AC73-CF8C939BE83F@oracle.com> <519C397E.8010307@oracle.com> Message-ID: <3F972D2C-DEB8-468C-BEB8-4440A1901920@oracle.com> On May 21 2013, at 20:20 , Joseph Darcy wrote: > Hello Mike, > > The TestNG data provider framework is unfamiliar to me, so my first reaction is that it is overkill for this problem as opposed to a one-off approach, but that may be driven my lack of experience with it. Yes, quite possibly overkill for this test. > However, in the test code > > 153 private static final long[] SOME_PRIMES = { > 154 3L, 5L, 7L, 11L, 13L, 17L, 19L, 23L, 29L, 31L, 37L, 41L, 43L, 47L, 53L, > 155 59L, 61L, 71L, 73L, 79L, Long.MIN_VALUE }; The Long.MIN_VALUE was used as a terminator rather than as a prime. I have changed the loop processing so that a terminator value is not needed. > the name of the array is incorrect since Long.MIN_VALUE = -2^63 which is composite. Perhaps you were thinking of Integer.MAX_VALUE which is a Mersenne prime? (2^61 -1 is a Mersenne prime; 2^63 - 1 is not.) Integer.MAX_VALUE now added along with some other primes near powers of two boundaries. Updated webrev: http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/ Thanks! Mike > -Joe > > On 5/21/2013 3:45 PM, Mike Duigou wrote: >> Ping! >> >> I need a final review on this issue. >> >> Thanks, >> >> Mike >> >> On May 16 2013, at 14:02 , Mike Duigou wrote: >> >>> On May 15 2013, at 19:09 , Joseph Darcy wrote: >>> >>>> Hi Mike, >>>> >>>> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests? >>> I hadn't actually looked but it turns out the answer was "No, certainly not". >>> >>> I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that. >>> >>> If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/ >>> >>> Mike >>> >>>> -Joe >>>> >>>> On 5/15/2013 6:17 PM, Mike Duigou wrote: >>>>> Hello all; >>>>> >>>>> This issue was originally part of JDK-8006627 (improve performance of UUID parsing/formatting) but was split out because it could be split out. I've been working incrementally on pieces of 8006627 as my time permits. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >>>>> >>>>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in , and found that using the digits table was still faster. >>>>> >>>>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit. >>>>> >>>>> Since the last rev I have made a separate implementation Integer.formatUnsignedInteger for use by Integer rather than sharing the Long implementation because it's about 30% faster. I suspect the benefits would be even greater on a 32-bit VM or 32-bit native platform. >>>>> >>>>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting). >>>>> >>>>> Thanks, >>>>> >>>>> Mike > From lana.steuck at oracle.com Wed May 22 19:10:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:35 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130522191041.2549C48C48@hg.openjdk.java.net> Changeset: c8286839d0df Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c8286839d0df Added tag jdk8-b89 for changeset fe4150590ee5 ! .hgtags Changeset: 8f7ffb296385 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8f7ffb296385 Added tag jdk8-b90 for changeset c8286839d0df ! .hgtags From lana.steuck at oracle.com Wed May 22 19:10:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:46 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130522191052.83F2548C4A@hg.openjdk.java.net> Changeset: 67ca019e3713 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/67ca019e3713 Added tag jdk8-b89 for changeset 45ce27fbe272 ! .hgtags Changeset: 4ce88eec5078 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4ce88eec5078 Added tag jdk8-b90 for changeset 67ca019e3713 ! .hgtags Changeset: 6b9f41203800 Author: lana Date: 2013-05-17 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6b9f41203800 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js Changeset: e955e64fd15d Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e955e64fd15d Merge From lana.steuck at oracle.com Wed May 22 19:10:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:39 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130522191052.0425148C49@hg.openjdk.java.net> Changeset: 3e5b9ea5ac35 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3e5b9ea5ac35 Added tag jdk8-b89 for changeset 88838e08e4ef ! .hgtags Changeset: 0bb1a9fa56b0 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/0bb1a9fa56b0 Added tag jdk8-b90 for changeset 3e5b9ea5ac35 ! .hgtags From lana.steuck at oracle.com Wed May 22 19:10:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:36 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20130522191037.28CF948C47@hg.openjdk.java.net> Changeset: 69b773a221b9 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/69b773a221b9 Added tag jdk8-b89 for changeset 892a0196d10c ! .hgtags Changeset: 83b519cafa68 Author: katleman Date: 2013-05-16 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/83b519cafa68 Added tag jdk8-b90 for changeset 69b773a221b9 ! .hgtags Changeset: 40bba0507f76 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/40bba0507f76 Merge From lana.steuck at oracle.com Wed May 22 19:10:43 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:10:43 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130522191101.4839A48C4B@hg.openjdk.java.net> Changeset: 668acc0e1034 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/668acc0e1034 Added tag jdk8-b89 for changeset 893d2ba8bbea ! .hgtags Changeset: f39d61028d2f Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f39d61028d2f Added tag jdk8-b90 for changeset 668acc0e1034 ! .hgtags Changeset: e3065fb07877 Author: lana Date: 2013-05-17 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e3065fb07877 Merge Changeset: 0765806dcc58 Author: lana Date: 2013-05-22 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0765806dcc58 Merge From lana.steuck at oracle.com Wed May 22 19:11:05 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:11:05 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130522191126.05AF248C4C@hg.openjdk.java.net> Changeset: e19283cd30a4 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e19283cd30a4 Added tag jdk8-b89 for changeset ec434cfd2752 ! .hgtags Changeset: 9717b9523d46 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9717b9523d46 Added tag jdk8-b90 for changeset e19283cd30a4 ! .hgtags Changeset: 997c0fae2b12 Author: lana Date: 2013-05-17 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/997c0fae2b12 Merge - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java Changeset: 31344e8e3343 Author: lana Date: 2013-05-22 09:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31344e8e3343 Merge From lana.steuck at oracle.com Wed May 22 19:11:40 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:11:40 +0000 Subject: hg: jdk8/tl/hotspot: 86 new changesets Message-ID: <20130522191500.B5E4848C4D@hg.openjdk.java.net> Changeset: 7d56b68a9672 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d56b68a9672 Added tag jdk8-b89 for changeset 9c1fe0b419b4 ! .hgtags Changeset: 625ddb0052e1 Author: amurillo Date: 2013-05-03 08:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/625ddb0052e1 8013800: new hotspot build - hs25-b32 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c456f4510385 Author: sla Date: 2013-05-03 12:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c456f4510385 8008453: JvmtiClassFileReconstituter does not recognize default methods Reviewed-by: acorn, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 0380df7c3cd0 Author: sla Date: 2013-05-03 12:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0380df7c3cd0 8013785: Respect EXTRA_CFLAGS on windows Reviewed-by: mgronlun, rbackman, kvn ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make Changeset: 31a4e55f8c9d Author: fparain Date: 2013-05-03 05:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31a4e55f8c9d 8004095: Add support for JMX interface to Diagnostic Framework and Commands Reviewed-by: acorn, sla ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/serviceThread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 39fba0d6d9ad Author: fparain Date: 2013-05-03 05:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39fba0d6d9ad Merge Changeset: bf089b838c9e Author: ccheung Date: 2013-05-02 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf089b838c9e 8012641: Perf_CreateLong creates perf counter of incorrect type Reviewed-by: mchung, hseigel, coleenp ! src/share/vm/prims/perf.cpp Changeset: a55b7b8c34af Author: zgu Date: 2013-05-03 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a55b7b8c34af Merge Changeset: 9c8e2f44228d Author: dcubed Date: 2013-05-03 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c8e2f44228d Merge Changeset: 800078be49d2 Author: hseigel Date: 2013-05-06 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/800078be49d2 8013648: Guarantee(VerifyBeforeGC || VerifyDuringGC || VerifyBeforeExit || VerifyAfterGC) failed: too expensive Summary: Fix code to call correct version of function find_class(). Reviewed-by: coleenp, rdurbin, dcubed ! src/share/vm/classfile/systemDictionary.cpp Changeset: c18152e0554e Author: zgu Date: 2013-05-06 11:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c18152e0554e 8013120: NMT: Kitchensink crashes with assert(next_region == NULL || !next_region->is_committed_region()) failed: Sanity check Summary: Fixed NMT to deal with releasing virtual memory region when there are still committed regions within it Reviewed-by: acorn, coleenp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/services/memSnapshot.cpp + test/runtime/NMT/ReleaseCommittedMemory.java Changeset: da4d87770781 Author: zgu Date: 2013-05-06 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da4d87770781 Merge Changeset: d9b08d62b95e Author: acorn Date: 2013-05-02 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9b08d62b95e 8010783: assert(s->refcount() != 0) failed: for create_overpasses Reviewed-by: kvn, dcubed ! src/share/vm/classfile/bytecodeAssembler.cpp Changeset: b7f3bf2ba33b Author: acorn Date: 2013-05-06 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7f3bf2ba33b Merge - agent/doc/c2replay.html Changeset: f916d5986c86 Author: acorn Date: 2013-05-06 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f916d5986c86 Merge Changeset: 187154b7a226 Author: sla Date: 2013-05-06 19:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/187154b7a226 8009615: JvmtiClassFileReconstituter does not create BootstrapMethod attributes Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 3ecc6b9940de Author: sla Date: 2013-05-07 01:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3ecc6b9940de Merge Changeset: b5fef8013a95 Author: sla Date: 2013-05-07 14:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5fef8013a95 8014044: Spelling error in JDK-8009615: boostrapmethod Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: f6a055fcf47d Author: sla Date: 2013-05-07 14:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6a055fcf47d 8005038: remove crufty '_g' support from SA Reviewed-by: coleenp, mgronlun, rbackman ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java Changeset: 33bcd9ead1d5 Author: ctornqvi Date: 2013-05-07 21:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33bcd9ead1d5 8009577: Test test/closed/runtime/classunload broken Summary: Fixed tests to use new way of utilizing the WB API, fixed issue with where custom classloader got the classes from Reviewed-by: collins, mgerdin, zgu + test/runtime/ClassUnload/KeepAliveClass.java + test/runtime/ClassUnload/KeepAliveClassLoader.java + test/runtime/ClassUnload/KeepAliveObject.java + test/runtime/ClassUnload/KeepAliveSoftReference.java + test/runtime/ClassUnload/UnloadTest.java + test/runtime/ClassUnload/classes/test/Empty.java + test/runtime/testlibrary/ClassUnloadCommon.java Changeset: 58bb870a0cbd Author: emc Date: 2013-05-07 13:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58bb870a0cbd 8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Summary: Update JNIEXPORT and JNIIMPORT to work with other compilers that don't necessarily have the __attribute__ type qualifier Reviewed-by: dholmes, dcubed, coleenp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h Changeset: 7243490a6847 Author: coleenp Date: 2013-05-07 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7243490a6847 Merge Changeset: e60b3fce2b02 Author: jiangli Date: 2013-05-06 19:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e60b3fce2b02 8013067: Zero builds are broken after 8010862. Summary: Fixed broken Zero build. Reviewed-by: twisti, coleenp, kvn ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp Changeset: 27d2d456cd96 Author: jiangli Date: 2013-05-06 20:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27d2d456cd96 Merge Changeset: 6b388e7d4905 Author: bpittore Date: 2013-05-07 10:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b388e7d4905 8013633: Cleanup platform ifdefs in unsafe.cpp Summary: Replace ifdefs with SUPPORTS_NATIVE_CX8 set in platform include file Reviewed-by: dholmes, dlong ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/share/vm/prims/unsafe.cpp Changeset: a258a8351528 Author: vladidan Date: 2013-05-07 10:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a258a8351528 Merge - agent/doc/c2replay.html Changeset: d3c98423c146 Author: jiangli Date: 2013-05-09 16:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3c98423c146 Merge Changeset: 1d0fba8a2a6d Author: brutisso Date: 2013-05-02 22:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d0fba8a2a6d 8013574: PrintMalloc conflicts with the command line parsing Summary: Make sure that _num_jvm_args is not updated until the new entry to _jvm_args_array has been added Reviewed-by: johnc, tamao, tschatzl ! src/share/vm/runtime/arguments.cpp Changeset: f14063dcd52a Author: brutisso Date: 2013-05-06 09:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f14063dcd52a 8013791: G1: G1CollectorPolicy::initialize_flags() may set min_alignment > max_alignment Summary: Make sure max alignemnt is at least as large as min alignment Reviewed-by: johnc, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/g1/TestRegionAlignment.java Changeset: 30860066ae8f Author: jwilhelm Date: 2013-05-06 13:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30860066ae8f Merge ! src/share/vm/runtime/arguments.cpp Changeset: d17700c82d7d Author: tschatzl Date: 2013-05-06 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d17700c82d7d 8006088: Incompatible heap size flags accepted by VM Summary: Make processing of minimum, initial and maximum heap size more intiutive by removing previous limitations on allowed values, and make error reporting consistent. Further, fix errors in ergonomic heap sizing. Reviewed-by: johnc, jwilhelm, tamao ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b0d20fa374b4 Author: brutisso Date: 2013-05-06 21:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0d20fa374b4 8013872: G1: HeapRegionSeq::shrink_by() has invalid assert Summary: Refactored shrink_by() to only use region counts and not byte sizes Reviewed-by: johnc, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + test/gc/g1/TestShrinkToOneRegion.java Changeset: a9d568b7df60 Author: jmasa Date: 2013-05-08 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9d568b7df60 8013032: CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) failed: used: 0 used_after_gc: 292080 capacity: 1431699456 Reviewed-by: tschatzl, mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/CheckAllocateAndSystemGC.java Changeset: 06ab37f08701 Author: jmasa Date: 2013-05-08 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06ab37f08701 8013184: CMS: Call reset_after_compaction() only if a compaction has been done Reviewed-by: mgerdin, johnc, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/concurrentMarkSweep/SystemGCOnForegroundCollector.java Changeset: 923ac8d1df95 Author: jwilhelm Date: 2013-05-09 12:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/923ac8d1df95 Merge Changeset: 194f52aa2f23 Author: johnc Date: 2013-05-09 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/194f52aa2f23 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap Summary: Refactor G1's hot card cache and card counts table into their own files. Simplify the card counts table, including removing the encoding of the card index in each entry. The card counts table now has a 1:1 correspondence with the cards spanned by heap. Space for the card counts table is reserved from virtual memory (rather than C heap) during JVM startup and is committed/expanded when the heap is expanded. Changes were also reviewed-by Vitaly Davidovich. Reviewed-by: tschatzl, jmasa ! make/excludeSrc.make ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/g1CardCounts.cpp + src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp + src/share/vm/gc_implementation/g1/g1HotCardCache.cpp + src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 73652d89e7c4 Author: stefank Date: 2013-05-10 09:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73652d89e7c4 Merge Changeset: 69494caf5790 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69494caf5790 Merge Changeset: 1ae0472ff3a0 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ae0472ff3a0 Added tag hs25-b32 for changeset 69494caf5790 ! .hgtags Changeset: 1cdbd42c3e49 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cdbd42c3e49 Added tag jdk8-b90 for changeset 1ae0472ff3a0 ! .hgtags Changeset: 6114c49b31b5 Author: amurillo Date: 2013-05-10 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6114c49b31b5 8014279: new hotspot build - hs25-b33 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 712a1e9c91f3 Author: coleenp Date: 2013-05-07 09:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/712a1e9c91f3 8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free Summary: Clear out class_file_bytes so they aren't deallocated twice Reviewed-by: dcubed, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4674e409a9e6 Author: coleenp Date: 2013-05-07 18:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4674e409a9e6 8014024: NPG: keep compiled ic methods from being deallocated in redefine classes Summary: Walk the compiledIC relocation records to keep Method* from being deallocated. Reviewed-by: dlong, kvn ! src/share/vm/code/nmethod.cpp Changeset: a1cc1d1e7ce5 Author: coleenp Date: 2013-05-07 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1cc1d1e7ce5 Merge Changeset: 28ae1d38d296 Author: coleenp Date: 2013-05-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28ae1d38d296 Merge Changeset: 64340da5b68c Author: hseigel Date: 2013-05-08 08:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64340da5b68c 8007018: RFE: -XX:+UseLargePages does not work with CDS Summary: Remove command line restriction. It should just work. Reviewed-by: ctornqvi, coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: cbfe859bd244 Author: sla Date: 2013-05-08 15:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbfe859bd244 8013591: compiler/ciReplay/TestSA.sh fails in nightly Reviewed-by: coleenp, rbackman, dholmes ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java Changeset: 0dc028fd5101 Author: sla Date: 2013-05-08 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0dc028fd5101 Merge Changeset: 39ead0411f07 Author: bharadwaj Date: 2013-05-08 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39ead0411f07 8013875: Incorrect vtable index being set during methodHandle creation for static Summary: Set vtable index as appropriate for static interface methods and for interface methods invoked via invokespecial. To be improved in a later enhancement to CallInfo. Reviewed-by: jrose, twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 711016f146fd Author: dholmes Date: 2013-05-08 19:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/711016f146fd 8006997: ContendedPaddingWidth should be range-checked Summary: Constrain between zero and 8K Reviewed-by: dholmes, rbackman Contributed-by: Aleksey Shipilev ! src/share/vm/runtime/arguments.cpp Changeset: 9b77ca4ce35e Author: dholmes Date: 2013-05-08 19:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b77ca4ce35e Merge ! src/share/vm/runtime/arguments.cpp Changeset: c272092594bd Author: dholmes Date: 2013-05-08 21:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c272092594bd Merge Changeset: 0b7f78069732 Author: rbackman Date: 2013-05-08 11:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b7f78069732 8008255: jvmtiExport.cpp::post_to_env() does not check malloc() return Reviewed-by: coleenp, dholmes, sla ! src/share/vm/prims/jvmtiExport.cpp Changeset: 735c995bf1a1 Author: rbackman Date: 2013-05-13 07:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/735c995bf1a1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 92ef81e2f571 Author: minqi Date: 2013-05-10 08:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/92ef81e2f571 8003557: NPG: Klass* const k should be const Klass* k. Summary: With NPG, const KlassOop klass which is in fact a definition converted to Klass* const, which is not the original intention. The right usage is converting them to const Klass*. Reviewed-by: coleenp, kvn Contributed-by: yumin.qi at oracle.com ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 1fcfc045b229 Author: minqi Date: 2013-05-10 19:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fcfc045b229 Merge Changeset: 8b40495b9381 Author: minqi Date: 2013-05-13 18:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b40495b9381 Merge ! src/share/vm/oops/method.hpp Changeset: 43083e670adf Author: coleenp Date: 2013-05-13 15:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43083e670adf 8005056: NPG: Crash after redefining java.lang.Object Summary: Need to walk array class vtables replacing old methods too if j.l.o redefined Reviewed-by: sspitsyn, dcubed, ctornqvi ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp + test/runtime/RedefineObject/Agent.java + test/runtime/RedefineObject/TestRedefineObject.java ! test/testlibrary/ClassFileInstaller.java Changeset: a9270d9ecb13 Author: shade Date: 2013-05-14 11:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9270d9ecb13 8014448: Purge PrintCompactFieldsSavings Summary: Remove obsolete debugging code. Reviewed-by: dholmes, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: f944ba972151 Author: hseigel Date: 2013-05-14 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f944ba972151 8014138: Add VM option to facilitate the writing of CDS tests Summary: Added the -XX:SharedArchiveFile option. Reviewed-by: coleenp, ccheung, acorn, dcubed, zgu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/SharedArchiveFile/SharedArchiveFile.java Changeset: f9be75d21404 Author: minqi Date: 2013-05-14 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9be75d21404 8012902: remove use of global operator new - take 2 Summary: The fix of 8010992, disable use of global operator new and new[] which caused failure on some tests. This takes two of the bugs also add ALLOW_OPERATOR_NEW_USAGE to prevent crash for third party code calling operator new of jvm on certain platforms. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/vm.make ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 513a5298c1dd Author: minqi Date: 2013-05-14 17:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513a5298c1dd Merge Changeset: d15464bfd4d0 Author: roland Date: 2013-05-03 09:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d15464bfd4d0 8012037: Test8009761.java "Failed: init recursive calls: 7224. After deopt 58824" Summary: test shouldn't be run with a modified CompileThreshold Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: e76dd894b984 Author: roland Date: 2013-04-24 14:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e76dd894b984 8012292: optimized build with GCC broken Summary: Some #ifndef PRODUCT should be #ifdef ASSERT Reviewed-by: kvn, twisti Contributed-by: gdub ! make/jprt.properties ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: d73c88e524ff Author: kvn Date: 2013-05-03 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d73c88e524ff Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: f0bc60565ba8 Author: twisti Date: 2013-05-06 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0bc60565ba8 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact Reviewed-by: jrose, kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: aabf54ccedb1 Author: twisti Date: 2013-05-06 19:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aabf54ccedb1 8008772: remove gamma launcher Reviewed-by: kvn, neliasso, ctornqvi ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make + make/hotspot.script ! make/linux/makefiles/buildtree.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/projectfiles/common/Makefile - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h Changeset: 6f3fd5150b67 Author: kvn Date: 2013-05-08 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f3fd5150b67 6934604: enable parts of EliminateAutoBox by default Summary: Resurrected autobox elimination code and enabled part of it by default. Reviewed-by: roland, twisti ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/6934604/TestByteBoxing.java + test/compiler/6934604/TestDoubleBoxing.java + test/compiler/6934604/TestFloatBoxing.java + test/compiler/6934604/TestIntBoxing.java + test/compiler/6934604/TestLongBoxing.java + test/compiler/6934604/TestShortBoxing.java Changeset: 70120f47d403 Author: kvn Date: 2013-05-09 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70120f47d403 8014189: JVM crash with SEGV in ConnectionGraph::record_for_escape_analysis() Summary: Add NULL checks and asserts for Type::make_ptr() returned value. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/subnode.cpp Changeset: 8bcfd9ce2c6b Author: twisti Date: 2013-05-13 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bcfd9ce2c6b Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da5d70655e9 Author: kvn Date: 2013-05-13 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1da5d70655e9 8014286: failed java/lang/Math/DivModTests.java after 6934604 changes Summary: Corrected escape state for the result of boxing method. Added force inlining executed boxing methods. Reviewed-by: twisti ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/escape.cpp Changeset: cd6f6fccd287 Author: iignatyev Date: 2013-05-15 22:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd6f6fccd287 8014068: TEST_BUG: compiler/ciReplay/TestSA.sh fails on Windows: core wasn't generated Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh Changeset: e484fe2abebd Author: twisti Date: 2013-05-16 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e484fe2abebd Merge - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 7a95933197d0 Author: tschatzl Date: 2013-05-13 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a95933197d0 8014058: Regression tests for 8006088 Summary: The patch for 8006088 misses regression tests after a merge error, this CR provides them. Reviewed-by: jwilhelm, tamao, jmasa ! src/share/vm/memory/collectorPolicy.cpp + test/gc/arguments/TestCMSHeapSizeFlags.java + test/gc/arguments/TestG1HeapSizeFlags.java + test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMinInitialErgonomics.java + test/gc/arguments/TestParallelHeapSizeFlags.java + test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 4868caa99ecf Author: brutisso Date: 2013-05-13 14:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4868caa99ecf 8014339: Improve assert and remove some dead code from parMarkBitMap.hpp/cpp Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 0a2986f36965 Author: tschatzl Date: 2013-05-14 17:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a2986f36965 8014489: tests/gc/arguments/Test(Serial|CMS|Parallel|G1)HeapSizeFlags jtreg tests invoke wrong class Summary: Some jtreg tests reference unknown classes in the @run and @build lines. This change fixes them. Reviewed-by: stefank, ehelin ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 12f651e29f6b Author: tschatzl Date: 2013-05-15 11:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12f651e29f6b 6843347: Boundary values in some public GC options cause crashes Summary: Setting some public integer options to specific values causes crashes or undefined GC behavior. This patchset adds the necessary argument checking for these options. Reviewed-by: jmasa, brutisso ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eba99d16dc6f Author: tamao Date: 2013-05-15 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba99d16dc6f 8007763: Refactoring: split up compute_generation_free_space() into two functions for class PSAdaptiveSizePolicy Summary: split up compute_generation_free_space() into two functions: compute_eden_space_size() + compute_old_gen_free_space(), each of which (if needed) can be reused without executing an overhead of the other. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: bed55d125e37 Author: johnc Date: 2013-05-15 22:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bed55d125e37 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Summary: Mismatch in the card number calculation between next and previous committed sizes of the card counts table. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 05a17f270c7e Author: tschatzl Date: 2013-05-16 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05a17f270c7e 8014240: G1: Add remembered set size information to output of G1PrintRegionLivenessInfo Summary: Improve the output of G1PrintRegionLivenessInfo by adding a per-region remembered set size information column Reviewed-by: jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 48391ab0687e Author: johnc Date: 2013-05-16 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48391ab0687e 8010738: G1: Output for full GCs with +PrintGCDetails should contain perm gen size/meta data change info Summary: Include metaspace information (used, allocated, reserved) in the PrintGCDetails output for full GCs. Reviewed-by: poonam, jmasa, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + test/gc/g1/TestPrintGCDetails.java Changeset: acac2b03a07f Author: tschatzl Date: 2013-05-16 23:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acac2b03a07f 8014765: VM exits if MaxTenuringThreshold is set below the default InitialTenuringThreshold, and InitialTenuringThreshold is not set Summary: The VM exits when the condition in the subject line applies. The fix sets InitialTenuringThreshold to MaxTenuringThreshold if it is larger than MaxTenuringThreshold and InitialTenuringThreshold has not been set (is default). Reviewed-by: jwilhelm, jmasa, brutisso, johnc ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestInitialTenuringThreshold.java Changeset: 2958af1d8c5a Author: jwilhelm Date: 2013-05-17 06:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2958af1d8c5a Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2f9ac66165e6 Author: jwilhelm Date: 2013-05-17 08:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f9ac66165e6 Merge - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: b19517cecc2e Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b19517cecc2e Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: 7cbdf0e3725c Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7cbdf0e3725c Added tag hs25-b33 for changeset b19517cecc2e ! .hgtags From lana.steuck at oracle.com Wed May 22 19:12:58 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 22 May 2013 19:12:58 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20130522191804.C371B48C4E@hg.openjdk.java.net> Changeset: b8e7d145abc2 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8e7d145abc2 Added tag jdk8-b89 for changeset 845025546e35 ! .hgtags Changeset: 1f1699686504 Author: katleman Date: 2013-05-09 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f1699686504 8014289: JDK8 b89 source with GPL header errors Reviewed-by: mchung, mduigou, tbell, dsamersoff ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/StringJoiner.java ! test/java/lang/CharSequence/DefaultTest.java ! test/java/util/StringJoiner/StringJoinerTest.java Changeset: c63eda8f6300 Author: katleman Date: 2013-05-14 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c63eda8f6300 Merge Changeset: 08c28cdacd7b Author: katleman Date: 2013-05-16 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08c28cdacd7b Added tag jdk8-b90 for changeset c63eda8f6300 ! .hgtags Changeset: 4dd6f7bb8bbd Author: simonis Date: 2013-05-06 12:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4dd6f7bb8bbd 7191872: Xrender: No text displayed using 64 bit JDK on solaris11-sparc Reviewed-by: prr, ceisserer ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/GlyphList.java ! src/solaris/classes/sun/font/XRGlyphCacheEntry.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 23f7ff502a89 Author: jgodinez Date: 2013-05-07 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23f7ff502a89 8011069: Printing: NullPointerException since jdk8 b82 showing native Page Setup Dialog. Reviewed-by: bae, prr ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 8a995d335d59 Author: lana Date: 2013-05-09 19:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a995d335d59 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 103f492d8ce7 Author: vadim Date: 2013-05-17 17:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/103f492d8ce7 4892259: GIF ImageReader does not call passComplete in IIOReadUpdateListener Reviewed-by: prr, bae ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java + test/javax/imageio/plugins/gif/GIFPassListenerTest.java Changeset: 4ee85e865a83 Author: vadim Date: 2013-05-17 14:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ee85e865a83 8000936: Enable Java2D D3D pipeline on newer Intel chipsets : Intel HD and later Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 51f5e544c88b Author: lana Date: 2013-05-17 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51f5e544c88b Merge Changeset: 90b67c9a7eb2 Author: serb Date: 2013-05-06 16:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90b67c9a7eb2 7161575: [macosx] On MacOSX port java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWToolkit.java Changeset: 7982299cd11c Author: serb Date: 2013-05-08 15:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7982299cd11c 8013841: [macosx] Animations not disabled for CALayers used via JAWT Reviewed-by: anthony, alexsch ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 5fe0a4da863d Author: lana Date: 2013-05-09 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe0a4da863d Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: a466a4192fea Author: pchelko Date: 2013-05-14 16:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a466a4192fea 8002045: Auto failed and threw exception:java.lang.UnsatisfiedLinkError: Reviewed-by: serb, anthony ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mapfile-vers-linux ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux Changeset: b1a7cc79f13d Author: serb Date: 2013-05-14 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1a7cc79f13d 8014423: [macosx] The scrollbar's block increment performs incorrectly Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java Changeset: 722ee3129ce0 Author: ant Date: 2013-05-15 16:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/722ee3129ce0 8014227: JLightweightFrame needs another synchronization policy Reviewed-by: art ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 7a8a8e31a126 Author: pchelko Date: 2013-05-17 11:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8a8e31a126 7079254: Toolkit eventListener leaks memory Reviewed-by: serb, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Changeset: e944b78812a8 Author: kshefov Date: 2013-05-17 14:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e944b78812a8 8014721: TEST_BUG: java/awt/TrayIcon/DragEventSource/DragEventSource.java fails with java.lang.UnsupportedOperationException Reviewed-by: anthony, serb ! test/java/awt/TrayIcon/DragEventSource/DragEventSource.java Changeset: 281add053efe Author: kshefov Date: 2013-05-17 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/281add053efe 8013426: TEST_BUG: java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java fails with "RuntimeException: The data should be available" on Linux Reviewed-by: anthony, serb ! test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java Changeset: 49871f1581b8 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49871f1581b8 Merge Changeset: 30101f69e66f Author: lana Date: 2013-05-17 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30101f69e66f Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Base64.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: bcfab7056195 Author: lana Date: 2013-05-22 09:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcfab7056195 Merge Changeset: 760d4187597a Author: lana Date: 2013-05-22 12:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/760d4187597a Merge From Alan.Bateman at oracle.com Wed May 22 19:58:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2013 20:58:57 +0100 Subject: Review request: JDK-8014394 (fs) WatchService failing when watching \\server\$d In-Reply-To: <519CED5F.5030309@oracle.com> References: <519CED5F.5030309@oracle.com> Message-ID: <519D2381.1030007@oracle.com> On 22/05/2013 17:07, Alexey Utkin wrote: > Bug description: > https://jbs.oracle.com/bugs/browse/JDK-8014394 > http://bugs.sun.com/view_bug.do?bug_id=8014394 > > Here is the suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.00/ > > Summary: > The problem source is the ERROR_MORE_DATA warning event that was > treated as error. > The suggested fix contains limited refactoring that can be critical > for further support. > > : Thanks for finding the ERROR_MORE_DATA case, that was missed in the original implementation and I can only assume just hasn't been noticed (maybe because watching a directory over CIFS wouldn't be as common as local). On expanding on the width of the completion key then this this increases the footprint of the key to WatchKey map which doesn't seem necessary (we originally choose an int as it should be more than enough for extreme usage over an extended period). Maybe it would be better to keep the WindowsNativeDispatcher.* changes to use jlong/ ULONG_PTR but revert the usage in WindowsWatchService to avoid the blot. -Alan. From kumar.x.srinivasan at oracle.com Wed May 22 20:30:08 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 22 May 2013 13:30:08 -0700 Subject: RFR: 8007333: [launcher] removes multiple back slashes / trivial fix Message-ID: <519D2AD0.8070901@oracle.com> Hello, Please review trivial fix where the launcher did not parse multiple back-slashes correctly. I also added some additional test contributed by Jim Holmlund. http://cr.openjdk.java.net/~ksrini/8007333/webrev.0/ Thanks Kumar From joe.darcy at oracle.com Wed May 22 20:34:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 22 May 2013 20:34:18 +0000 Subject: hg: jdk8/tl/langtools: 8010680: Clarify "present" and annotation ordering in javax.lang.model Message-ID: <20130522203421.0DEDA48C59@hg.openjdk.java.net> Changeset: 3bd22f99d408 Author: darcy Date: 2013-05-22 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3bd22f99d408 8010680: Clarify "present" and annotation ordering in javax.lang.model Reviewed-by: abuckley, jjg ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/util/Elements.java From brent.christian at oracle.com Wed May 22 20:50:37 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 22 May 2013 13:50:37 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51911943.7000106@oracle.com> References: <51911943.7000106@oracle.com> Message-ID: <519D2F9D.9010203@oracle.com> I have updated the changes as follows: * TreeBin.createEntryForNode() + the anonymous TreeBin subclass in [Linked]HashMap have been replaced by a TreeBin.map reference back to the containing map, enabling TreeBin to just call newEntry() directly. * TreeNode.entry was made final * Added a top-level comment in HashMap giving a brief overview of how balanced trees are used * Updated the TreeBinSplitBackToEntries test for TREE_THRESHOLD=16 * Test code was updated to not need to be on the bootclasspath. LaunchOnBootClass.java was removed from the changes (and would not have been needed anyway, due to the recent jtreg update) The new webrev is here: http://cr.openjdk.java.net/~bchristi/8005698/webrev.01/ Thanks, -Brent On 5/13/13 9:48 AM, Brent Christian wrote: > Hi, > > Please review my changes for 8005698 : Handle Frequent HashMap > Collisions with Balanced Trees. > > For HashMap and LinkedHashMap, we would like to duplicate the technique > (and some of the code) that the latest ConcurrentHashMap[1] uses for > handling hash collisions: use of balanced trees to store map entries in > hash bins containing many collisions. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/8005698/webrev.00/ > > Some high-level details copied from the JEP[2]: > > Earlier work in this area in JDK 8, namely the alternative > string-hashing implementation[3], improved collision performance for > string-valued keys only, and it did so at the cost of adding a new > (private) field to every String instance. > > The changes proposed here will improve collision performance for any key > type that implements Comparable. The alternative string-hashing > mechanism, including the private hash32 field added to the String class, > can then be removed. > > The principal idea is that once the number of items in a hash bucket > grows beyond a certain threshold, that bucket will switch from using a > linked list of entries to a balanced tree. > > We will not implement this for the Hashtable class - some legacy code > that uses it is known to depend upon iteration order. Instead, Hashtable > will be reverted to its state prior to the introduction of the > alternative string-hashing implementation, and will maintain its > historical iteration order. > > We also will not implement this technique in WeakHashMap. An attempt was > made, but the complexity of having to account for weak keys resulted in > an unacceptable drop in microbenchmark performance. WeakHashMap will > also be reverted to its prior state. > > Thanks! > -Brent > > 1. > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?view=log > > 2. http://openjdk.java.net/jeps/180 > 3. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e From joe.darcy at oracle.com Wed May 22 23:42:13 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 22 May 2013 16:42:13 -0700 Subject: JDK 8 code review request for 8014836: Have GenericDeclaration extend AnnotatedElement In-Reply-To: <519CE5E2.2020901@univ-mlv.fr> References: <519A9135.9000002@oracle.com> <519A9589.9040002@univ-mlv.fr> <519ACAD0.1030505@oracle.com> <519CE5E2.2020901@univ-mlv.fr> Message-ID: <519D57D5.40906@oracle.com> Hi Remi, On 5/22/2013 8:36 AM, Remi Forax wrote: > On 05/21/2013 03:16 AM, Joseph Darcy wrote: >> Hi Remi, >> >> On 5/20/2013 2:28 PM, Remi Forax wrote: >>> On 05/20/2013 11:10 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the patch below which implements >>>> >>>> 8014836: Have GenericDeclaration extend AnnotatedElement >>>> >>>> All the existing implementations of GenericDeclaration in the JDK >>>> already implement AnnotatedElement. Some code in java.lang.Class >>>> needed to be adjusted slightly since AnnotatedElement declares a >>>> default method and calling an interface's default method in an >>>> implementing class has to go through the direct interface type. >>> >>> GenericDeclaration is a public interface, so you will break the code >>> of everyone that implements it. >>> By example, Guava's Invokable also implements GenericDeclaration >>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/reflect/Invokable.html >>> >> >> That is technically true; in effect adding several methods to >> GenericDeclaration would break implementations outside of the JDK >> that do not already implement annotated element. >> >> However, this is (only) a source incompatible change and not a binary >> incompatible change so is possible in-bounds for a platform release >> like JDK 8: >> >> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy >> >> >> The Invokable type you reference is the moral equivalent of the >> "Executable" superclass of Constructor and Method added earlier in >> JDK 8. The Invokable type itself is marked as "@Beta" to warn users >> that it could change or even to away. Therefore, I'm not very >> concerned about "breaking" a type like this, which could easily be >> retrofitted to also implement AnnotatedElement as it already a >> wrapper around a Method or a Constructor. > > For me, it's not just a source incompatible change, > let suppose that I use Guava reflection API in my program and the jdk8, > I will be able to get a GenericDeclaration that will fail at runtime > if I try to call a method of AnnotatedElement on it. > So this change make the existing Guava library not forward compatible. Again, that part of Guava is marked as "@Beta" to warn against relying on it too much. The JDK generally makes weaker promises about runtime reflection modeling as compared to compile-time or non-reflective runtime behavior. > > With the introduction of default methods, we now have a way to make > change in interfaces backward compatible, > I don't say that we should use default methods here, I don't know. > But I think it worth to think about that. > > I've just seen that AnnotatedElement also includes new new abstract > methods. For now, I'm going to push the changes to GenericDeclaration as-is. If there are undo compatibility issues, default methods for the AnnotatedElement methods could be added later in 8 (but they would be a bit disappointing since they could have to either return nothing or throw Unsupporte-Operation-Exception.) Thanks, -Joe > >> >> (Also interesting to see a "Parameter" class in Guava given that we >> have added a Parameter class to java.lang.reflect.) > > yes, but there is no getName() :) More reason to upgrade to JDK 8 :-) > >> >> Thanks, >> >> -Joe > > cheers, > R?mi > >> >>> >>>> >>>> Thanks, >>>> >>>> -Joe >>> >>> R?mi >>> >>>> >>>> --- a/src/share/classes/java/lang/Class.java Mon May 20 11:56:46 >>>> 2013 -0700 >>>> +++ b/src/share/classes/java/lang/Class.java Mon May 20 14:07:15 >>>> 2013 -0700 >>>> @@ -28,6 +28,7 @@ >>>> import java.lang.reflect.AnnotatedElement; >>>> import java.lang.reflect.Array; >>>> import java.lang.reflect.GenericArrayType; >>>> +import java.lang.reflect.GenericDeclaration; >>>> import java.lang.reflect.Member; >>>> import java.lang.reflect.Field; >>>> import java.lang.reflect.Executable; >>>> @@ -115,9 +116,9 @@ >>>> * @since JDK1.0 >>>> */ >>>> public final class Class implements java.io.Serializable, >>>> - java.lang.reflect.GenericDeclaration, >>>> - java.lang.reflect.Type, >>>> - java.lang.reflect.AnnotatedElement { >>>> + GenericDeclaration, >>>> + Type, >>>> + AnnotatedElement { >>>> private static final int ANNOTATION= 0x00002000; >>>> private static final int ENUM = 0x00004000; >>>> private static final int SYNTHETIC = 0x00001000; >>>> @@ -3182,7 +3183,7 @@ >>>> */ >>>> @Override >>>> public boolean isAnnotationPresent(Class >>>> annotationClass) { >>>> - return >>>> AnnotatedElement.super.isAnnotationPresent(annotationClass); >>>> + return >>>> GenericDeclaration.super.isAnnotationPresent(annotationClass); >>>> } >>>> >>>> /** >>>> diff -r 6a9148865139 >>>> src/share/classes/java/lang/reflect/GenericDeclaration.java >>>> --- a/src/share/classes/java/lang/reflect/GenericDeclaration.java >>>> Mon May 20 11:56:46 2013 -0700 >>>> +++ b/src/share/classes/java/lang/reflect/GenericDeclaration.java >>>> Mon May 20 14:07:15 2013 -0700 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2003, 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 >>>> @@ -30,7 +30,7 @@ >>>> * >>>> * @since 1.5 >>>> */ >>>> -public interface GenericDeclaration { >>>> +public interface GenericDeclaration extends AnnotatedElement { >>>> /** >>>> * Returns an array of {@code TypeVariable} objects that >>>> * represent the type variables declared by the generic >>>> >>> >> > From naoto.sato at oracle.com Wed May 22 23:43:48 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2013 23:43:48 +0000 Subject: hg: jdk8/tl/jdk: 7056126: DateFormatSymbols documentation has incorrect description about DateFormat; ... Message-ID: <20130522234408.E489648C66@hg.openjdk.java.net> Changeset: 50fde3eeb48c Author: naoto Date: 2013-05-22 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50fde3eeb48c 7056126: DateFormatSymbols documentation has incorrect description about DateFormat 7083668: Sample code in ListResourceBundle is still not correct Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/util/ListResourceBundle.java From david.holmes at oracle.com Thu May 23 00:22:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 23 May 2013 00:22:14 +0000 Subject: hg: jdk8/tl/jdk: 8014814: (str) StringBuffer "null" is not appended Message-ID: <20130523002227.DFDD648C67@hg.openjdk.java.net> Changeset: a1a8e71e130a Author: dholmes Date: 2013-05-22 20:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1a8e71e130a 8014814: (str) StringBuffer "null" is not appended Reviewed-by: alanb ! src/share/classes/java/lang/StringBuffer.java ! test/java/lang/StringBuffer/ToStringCache.java From joe.darcy at oracle.com Thu May 23 03:04:11 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 May 2013 03:04:11 +0000 Subject: hg: jdk8/tl/jdk: 8014836: Have GenericDeclaration extend AnnotatedElement Message-ID: <20130523030435.BAA4248C7C@hg.openjdk.java.net> Changeset: e764bb01567e Author: darcy Date: 2013-05-22 20:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e764bb01567e 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java From alexey.utkin at oracle.com Thu May 23 09:34:46 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 23 May 2013 13:34:46 +0400 Subject: Review request: JDK-8014394 (fs) WatchService failing when watching \\server\$d In-Reply-To: <519D2381.1030007@oracle.com> References: <519CED5F.5030309@oracle.com> <519D2381.1030007@oracle.com> Message-ID: <519DE2B6.6040701@oracle.com> Hi Alan, The era of 32 is over in Apple world. Seems that is the time switching to x64 everywhere. "640K ought to be enough for anybody ". The problem is in program up-time. If we are discussing about GUI application, 0xFFFFFFFF is infinity. But from a service point of view it is not so clear. (Webkit source-save server is a good example, but, yes, it isn't on Windows.) I rollback the changes in WindowsWatchService to avoid the blot. Regards, -uta On 5/22/2013 11:58 PM, Alan Bateman wrote: > On 22/05/2013 17:07, Alexey Utkin wrote: >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-8014394 >> http://bugs.sun.com/view_bug.do?bug_id=8014394 >> >> Here is the suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.00/ >> >> Summary: >> The problem source is the ERROR_MORE_DATA warning event that was >> treated as error. >> The suggested fix contains limited refactoring that can be critical >> for further support. >> >> : > Thanks for finding the ERROR_MORE_DATA case, that was missed in the > original implementation and I can only assume just hasn't been noticed > (maybe because watching a directory over CIFS wouldn't be as common as > local). > > On expanding on the width of the completion key then this this > increases the footprint of the key to WatchKey map which doesn't seem > necessary (we originally choose an int as it should be more than > enough for extreme usage over an extended period). Maybe it would be > better to keep the WindowsNativeDispatcher.* changes to use jlong/ > ULONG_PTR but revert the usage in WindowsWatchService to avoid the blot. > > -Alan. From aleksey.shipilev at oracle.com Thu May 23 09:51:34 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 13:51:34 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519B6A0E.5060304@oracle.com> References: <519B6A0E.5060304@oracle.com> Message-ID: <519DE6A6.3050304@oracle.com> On 05/21/2013 04:35 PM, Aleksey Shipilev wrote: > Hi, > > It is time to add the proper Javadoc to @Contended: > http://cr.openjdk.java.net/~shade/8014966/webrev.01/ > > Testing: > - built jdk8-tl on Linux x86_64/release without a hitch. > > Please review and sponsor! Friendly reminder. -Aleksey. From dl at cs.oswego.edu Thu May 23 12:20:55 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 23 May 2013 08:20:55 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519D2F9D.9010203@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> Message-ID: <519E09A7.7040304@cs.oswego.edu> Sorry that it has taken me a while to take a look at this. Here are some initial comments/questions: * Given that balanced trees are not used in WeakHashMap or Hashtable, I wonder why the TreeNode etc classes are not just nested inside HashMap (usable from subclass LinkedHashMap). And if so, it would be simpler, faster, and less code-intensive to declare TreeNode as a subclass of the internal Entry class. Plus some further gymnastics to overcome the unfortunate decision to make LinkedHashMap a subclass of HashMap. Had you considered this? I might take a shot at exploring it. * The comparableClassFor code turns out to be a bottleneck (and is bypassed in the particular case of String) in tests of the analogous code in ConcurrentHashMap, mainly because the only available reflection methods allocate little objects while checking for the form "class C implements Comparable" At some point, someone might want to implement a JDK-internal streamlined form. * Notice that if trees were ever to be used in WeakHashMap, the nodes would surely need to be declared as WeakReference subclasses, as are the current Entry nodes. The whole thought of doing this though is suspect (so I'm happy to see it not being done) because at that point, you would be most of the way to creating a ConcurrentWeakHashMap, which is itself controversial -- Eviction policies? Identity vs equality? Weak values? Soft refs? Ephemeron-style? etc. -Doug On 05/22/13 16:50, Brent Christian wrote: > I have updated the changes as follows: > > * TreeBin.createEntryForNode() + the anonymous TreeBin subclass in > [Linked]HashMap have been replaced by a TreeBin.map reference back to the > containing map, enabling TreeBin to just call newEntry() directly. > > * TreeNode.entry was made final > > * Added a top-level comment in HashMap giving a brief overview of how balanced > trees are used > > * Updated the TreeBinSplitBackToEntries test for TREE_THRESHOLD=16 > > * Test code was updated to not need to be on the bootclasspath. > LaunchOnBootClass.java was removed from the changes (and would not have been > needed anyway, due to the recent jtreg update) > > > The new webrev is here: > http://cr.openjdk.java.net/~bchristi/8005698/webrev.01/ > > Thanks, > -Brent > > On 5/13/13 9:48 AM, Brent Christian wrote: >> Hi, >> >> Please review my changes for 8005698 : Handle Frequent HashMap >> Collisions with Balanced Trees. >> >> For HashMap and LinkedHashMap, we would like to duplicate the technique >> (and some of the code) that the latest ConcurrentHashMap[1] uses for >> handling hash collisions: use of balanced trees to store map entries in >> hash bins containing many collisions. >> >> Webrev is here: >> http://cr.openjdk.java.net/~bchristi/8005698/webrev.00/ >> >> Some high-level details copied from the JEP[2]: >> >> Earlier work in this area in JDK 8, namely the alternative >> string-hashing implementation[3], improved collision performance for >> string-valued keys only, and it did so at the cost of adding a new >> (private) field to every String instance. >> >> The changes proposed here will improve collision performance for any key >> type that implements Comparable. The alternative string-hashing >> mechanism, including the private hash32 field added to the String class, >> can then be removed. >> >> The principal idea is that once the number of items in a hash bucket >> grows beyond a certain threshold, that bucket will switch from using a >> linked list of entries to a balanced tree. >> >> We will not implement this for the Hashtable class - some legacy code >> that uses it is known to depend upon iteration order. Instead, Hashtable >> will be reverted to its state prior to the introduction of the >> alternative string-hashing implementation, and will maintain its >> historical iteration order. >> >> We also will not implement this technique in WeakHashMap. An attempt was >> made, but the complexity of having to account for weak keys resulted in >> an unacceptable drop in microbenchmark performance. WeakHashMap will >> also be reverted to its prior state. >> >> Thanks! >> -Brent >> >> 1. >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?view=log >> >> >> 2. http://openjdk.java.net/jeps/180 >> 3. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e > From james.laskey at oracle.com Thu May 23 12:54:03 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Thu, 23 May 2013 12:54:03 +0000 Subject: hg: jdk8/tl/nashorn: 9 new changesets Message-ID: <20130523125410.DE26E48C9B@hg.openjdk.java.net> Changeset: 833a9a584b64 Author: attila Date: 2013-05-21 13:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/833a9a584b64 8014953: Have NativeJavaPackage throw a ClassNotFoundException when invoked Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + test/script/basic/JDK-8014953.js + test/script/basic/JDK-8014953.js.EXPECTED Changeset: 288ff54da2a5 Author: jlaskey Date: 2013-05-21 10:17 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/288ff54da2a5 8014827: readLine should accept a prompt as an argument Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 07cefc062032 Author: sundar Date: 2013-05-22 16:39 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/07cefc062032 8008947: ScriptEnvironment ctor should be public Reviewed-by: lagergren, attila ! .hgignore ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java Changeset: 66685c69bdb3 Author: sundar Date: 2013-05-22 19:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66685c69bdb3 8014735: Typed Array, BYTES_PER_ELEMENT should be a class property Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + test/script/basic/JDK-8014735.js + test/script/basic/JDK-8014735.js.EXPECTED ! test/script/basic/NASHORN-377.js Changeset: 8f7553df4503 Author: hannesw Date: 2013-05-22 16:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8f7553df4503 8010804: Review long and integer usage conventions Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8010804.js + test/script/basic/JDK-8010804.js.EXPECTED Changeset: 1c1453863ea8 Author: attila Date: 2013-05-23 12:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1c1453863ea8 8015267: Allow conversion of JS arrays to Java List/Deque Reviewed-by: lagergren, sundar ! make/build.xml ! src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8015267.js + test/script/basic/JDK-8015267.js.EXPECTED Changeset: f7eb4436410e Author: lagergren Date: 2013-05-23 13:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f7eb4436410e 8012083: Array literal constant folding issue Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8012083.js + test/script/basic/JDK-8012083.js.EXPECTED Changeset: 704bc91a0c41 Author: attila Date: 2013-05-23 13:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/704bc91a0c41 8015278: Revert accidental changes to build.xml Reviewed-by: jlaskey, lagergren ! make/build.xml Changeset: 8af550dee961 Author: jlaskey Date: 2013-05-23 09:49 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8af550dee961 Merge From nils.loodin at oracle.com Thu May 23 13:54:01 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Thu, 23 May 2013 13:54:01 +0000 Subject: hg: jdk8/tl/jdk: 8014048: Online user guide of jconsole points incorrect link Message-ID: <20130523135413.A8A2B48CA9@hg.openjdk.java.net> Changeset: 0da6485cf656 Author: nloodin Date: 2013-05-23 15:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0da6485cf656 8014048: Online user guide of jconsole points incorrect link Reviewed-by: mchung, sla, jbachorik ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties From Thomas.Salter at unisys.com Thu May 23 13:59:53 2013 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Thu, 23 May 2013 08:59:53 -0500 Subject: Windows command line processing Message-ID: <63D5DCACD1E9E34C89C8203C64F521C30136763B76F3@USEA-EXCH7.na.uis.unisys.com> I've observed issues with passing non-ASCII characters through the command line to a Java program on Windows. It seems that even though I can invoke java.exe through CreateProcess, passing a full range of Unicode characters, and even though the Java main accepts strings of Unicode characters, the launcher's C main function converts the Unicode to the local ANSI code page. Thus any characters not in the local code page are lost. This seems like a bug to me. As a proof of concept, I changed jdk/src/share/bin/main.c to call GetCommanLineW instead of GetCommandLine, and then converted that string to UTF-8. For my test, I set sun.jnu.encoding to UTF-8 so that makePlatformString in LauncherHelper would just work. -------------------------------------? Tom Salter? |? Software Engineer? |? Java & Middleware Development Unisys? |? 2476 Swedesford Road? |? Malvern, PA? 19355?? |? 610-648-2568 | ?N385-2568 From mike.duigou at oracle.com Thu May 23 14:33:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 May 2013 07:33:39 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519DE6A6.3050304@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> Message-ID: <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> Looks good. If you haven't found someone to push it by tomorrow then I can. (I am travelling today). A class level annotation on a class containing no annotated fields has no effect, correct? Mike On May 23 2013, at 02:51 , Aleksey Shipilev wrote: > On 05/21/2013 04:35 PM, Aleksey Shipilev wrote: >> Hi, >> >> It is time to add the proper Javadoc to @Contended: >> http://cr.openjdk.java.net/~shade/8014966/webrev.01/ >> >> Testing: >> - built jdk8-tl on Linux x86_64/release without a hitch. >> >> Please review and sponsor! > > Friendly reminder. > > -Aleksey. > From kumar.x.srinivasan at oracle.com Thu May 23 14:40:59 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 23 May 2013 07:40:59 -0700 Subject: Windows command line processing In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C30136763B76F3@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C30136763B76F3@USEA-EXCH7.na.uis.unisys.com> Message-ID: <519E2A7B.2030809@oracle.com> Hello Thomas, There are long standing bugs in this area, it all depends what arguments are being passed with Unicode code pages. This is somewhat a convoluted, as the JNI invocation APIs are not Unicode friendly. Also we have a common code base for shared launcher logic between the *nixes and Windows. However as you pointed, we can pass UTF8 parameters such as main class, and application arguments to JVM as UTF-8. We already have tests to exercises these conditions, please see jdk/test/tools/launcher, however on Windows the Regional Settings must be set correctly for the locale. Thanks Kumar > I've observed issues with passing non-ASCII characters through the command line to a Java program on Windows. It seems that even though I can invoke java.exe through CreateProcess, passing a full range of Unicode characters, and even though the Java main accepts strings of Unicode characters, the launcher's C main function converts the Unicode to the local ANSI code page. Thus any characters not in the local code page are lost. This seems like a bug to me. > > As a proof of concept, I changed jdk/src/share/bin/main.c to call GetCommanLineW instead of GetCommandLine, and then converted that string to UTF-8. For my test, I set sun.jnu.encoding to UTF-8 so that makePlatformString in LauncherHelper would just work. > > ------------------------------------- > Tom Salter | Software Engineer | Java & Middleware Development > Unisys | 2476 Swedesford Road | Malvern, PA 19355 | 610-648-2568 | N385-2568 > > > From amy.lu at oracle.com Thu May 23 14:48:50 2013 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 23 May 2013 22:48:50 +0800 Subject: Code Review Request: More tests for 7184826: (reflect) Add support for Project Lambda concepts in core reflection Message-ID: <519E2C52.20203@oracle.com> Please help to review: More tests for 7184826: (reflect) Add support for Project Lambda concepts in core reflection This includes: 1. improvement for existing tests with more situations 2. Test for invoking interface default/static method by j.l.r.Method 3. Test for invoking interface default/static method by MethodHandle https://dl.dropboxusercontent.com/u/5812451/yl153753/7184826/webrev.00/index.html Thanks, Amy From peter.levart at gmail.com Thu May 23 15:57:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 23 May 2013 17:57:34 +0200 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> Message-ID: <519E3C6E.4070501@gmail.com> On 05/23/2013 04:33 PM, Mike Duigou wrote: > Looks good. If you haven't found someone to push it by tomorrow then I can. (I am travelling today). > > A class level annotation on a class containing no annotated fields has no effect, correct? Hi Mike, As far as I understand the javadoc, it means the same as if all fields were annotated with the same tag. Each instance of annotation has either a named tag or an anonymous tag (when left as default). Annotation on the class level "tags" all un-annotated fields with the same tag (either named or anonymous). Fields with same tag are grouped in separate contention group. Fields with no tag are left out and are not "padded" from the start or end of object. So the difference between plain class and class with single @Contended() annotation on the class level is that in the later case there will be padding at start of object and at end of object, but in former case there will be no padding. Have I understood this correctly? Regards, Peter > Mike > > On May 23 2013, at 02:51 , Aleksey Shipilev wrote: > >> On 05/21/2013 04:35 PM, Aleksey Shipilev wrote: >>> Hi, >>> >>> It is time to add the proper Javadoc to @Contended: >>> http://cr.openjdk.java.net/~shade/8014966/webrev.01/ >>> >>> Testing: >>> - built jdk8-tl on Linux x86_64/release without a hitch. >>> >>> Please review and sponsor! >> Friendly reminder. >> >> -Aleksey. >> From david.r.chase at oracle.com Thu May 23 16:06:27 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 23 May 2013 12:06:27 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> Message-ID: <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> So where do we stand on this? Can we call it a bug and eligible for inclusion? And are there other issues to deal with? I would be happy to discuss exactly what is going on in the mysterious intrinsic-ful code, if that is an issue for anyone (and sooner is better than later, else I'll forget the exciting details). David On 2013-05-21, at 5:15 PM, David Chase wrote: > > http://cr.openjdk.java.net/~drchase/7088419/webrev.03/ > > Newer, slimmer webrev. No fork/join, the related code is removed (except the > native init routine still returns a boolean, which is currently ignored, indicating if > it supports the faster crc32). > > What remains is: > > 1) no-JNI fast-path for short CRCs and Adlers > 2) reformulated faster-Adler for byte-at-a-time > 3) For 32/64 Linux/Solaris/MacOS x86 Sandy Bridge or better (with CLMUL and AVX), > fast code for CRCs. > > For now it uses assembly language, the C-with-intrinsics is included, and compiles > with current clang and gcc. It tickles a bug in Solaris Studio 12.3 which has been reported. > Optimization for Windows is disabled because the assembler syntax is too different > > The code has been tested by-hand across Linux (32), Solaris (32 and 64), MacOS (64) > and has also passed JPRT (which is to say, the failures were unrelated, hand examination > of the runs showed that the new CRCandAdler test was successful. Anyone checking my > most recent run will notice that I am not very good at specifying tests to run, but there is > an earlier run. I'm trying again, just to see if I can figure out how to make it behave.) > > There is a companion webrev on the hotspot side that sets the secret property > that is used and reset by this code. > > I hope this will be more easily regarded as a "bug fix" and less as an interface change. > > David > > On 2013-05-20, at 8:34 PM, David Holmes wrote: > >> On 21/05/2013 3:45 AM, Alan Bateman wrote: >>> On 20/05/2013 14:49, David Chase wrote: >>>> Suppose I split this bug (i.e., file a new bug) into the >>>> Intel-acceleration part and the fork-join part. >>>> : >>>> >>> This make sense. >> >> I agree. >> >> I also don't have an issue with eliding the optimization on Windows for the time being. >> >> David >> >>> -Alan. > From aleksey.shipilev at oracle.com Thu May 23 16:16:26 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 20:16:26 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E3C6E.4070501@gmail.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E3C6E.4070501@gmail.com> Message-ID: <519E40DA.7000705@oracle.com> On 05/23/2013 07:57 PM, Peter Levart wrote: > Have I understood this correctly? Yes. @Contended on class is currently the shorthand for the @Contended with the same (but unknown) tag over all the fields. However, in future this might change, because @Contended on class might also guard the object header, as soon as we are brave enough to tap into the GC interface to allocate the @C objects aligned for the cache line boundary. -Aleksey. From aleksey.shipilev at oracle.com Thu May 23 16:17:08 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 20:17:08 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> Message-ID: <519E4104.6070007@oracle.com> On 05/23/2013 06:33 PM, Mike Duigou wrote: > A class level annotation on a class containing no annotated fields > has no effect, correct? It does have the effect, see the last paragraph in the Javadoc. Should we refine this a bit? -Aleksey. From mike.duigou at oracle.com Thu May 23 16:20:06 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 May 2013 09:20:06 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E4104.6070007@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> Message-ID: <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> You could add one more sentence to cover the effect of @C on class with no @C on any field. The response to Peter is great info (but too much detail for JavaDoc). Mike On May 23 2013, at 09:17 , Aleksey Shipilev wrote: > On 05/23/2013 06:33 PM, Mike Duigou wrote: >> A class level annotation on a class containing no annotated fields >> has no effect, correct? > > It does have the effect, see the last paragraph in the Javadoc. Should > we refine this a bit? > > -Aleksey. From aleksey.shipilev at oracle.com Thu May 23 16:47:18 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 20:47:18 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> Message-ID: <519E4816.1080500@oracle.com> Ummm... I think that's exactly what the last paragraph says. What if we rephrase it as follows? ------------- 8< ----------------------------------------------- When the annotation is used at the class level, the effect is roughly equivalent to placing the {@code @Contended} annotation with the anonymous tag over all the unannotated fields of the object. With the class level annotation, the implementations may choose different approach to protect the entire object, rather than protecting only the distinct fields. ------------- 8< ----------------------------------------------- -Aleksey. On 05/23/2013 08:20 PM, Mike Duigou wrote: > You could add one more sentence to cover the effect of @C on class > with no @C on any field. The response to Peter is great info (but too > much detail for JavaDoc). > > Mike > > On May 23 2013, at 09:17 , Aleksey Shipilev wrote: > >> On 05/23/2013 06:33 PM, Mike Duigou wrote: >>> A class level annotation on a class containing no annotated >>> fields has no effect, correct? >> >> It does have the effect, see the last paragraph in the Javadoc. >> Should we refine this a bit? >> >> -Aleksey. > From aleksey.shipilev at oracle.com Thu May 23 16:48:47 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 20:48:47 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E4816.1080500@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> Message-ID: <519E486F.8060407@oracle.com> Also, let's wait for David Holmes to glance over it. He has the immense capability to spot the weaknesses in the specifications. -Aleksey. On 05/23/2013 08:47 PM, Aleksey Shipilev wrote: > Ummm... I think that's exactly what the last paragraph says. What if we > rephrase it as follows? > > ------------- 8< ----------------------------------------------- > When the annotation is used at the class level, the effect is > roughly equivalent to placing the {@code @Contended} annotation > with the anonymous tag over all the unannotated fields of the > object. With the class level annotation, the implementations may > choose different approach to protect the entire object, rather > than protecting only the distinct fields. > ------------- 8< ----------------------------------------------- > > -Aleksey. > > On 05/23/2013 08:20 PM, Mike Duigou wrote: >> You could add one more sentence to cover the effect of @C on class >> with no @C on any field. The response to Peter is great info (but too >> much detail for JavaDoc). >> >> Mike >> >> On May 23 2013, at 09:17 , Aleksey Shipilev wrote: >> >>> On 05/23/2013 06:33 PM, Mike Duigou wrote: >>>> A class level annotation on a class containing no annotated >>>> fields has no effect, correct? >>> >>> It does have the effect, see the last paragraph in the Javadoc. >>> Should we refine this a bit? >>> >>> -Aleksey. >> > From chris.hegarty at oracle.com Thu May 23 16:57:01 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 May 2013 17:57:01 +0100 Subject: RFR 8014076: Arrays parallel and serial sorting improvements In-Reply-To: <14899129-669F-4151-982B-C1BA9EA25CE2@oracle.com> References: <518914E7.80109@oracle.com> <01588489-4150-4D3B-8333-0A3185D350D9@oracle.com> <51893635.4070300@oracle.com> <8728767A-E79C-483D-B9D2-44D332EDF2F6@oracle.com> <518B702E.3060405@oracle.com> <518B70B0.30703@oracle.com> <518B7670.4080405@oracle.com> <518B8B67.2060502@cs.oswego.edu> <518D00C3.5040803@oracle.com> <14899129-669F-4151-982B-C1BA9EA25CE2@oracle.com> Message-ID: <519E4A5D.3000104@oracle.com> On 05/11/2013 12:46 AM, Mike Duigou wrote: > > On May 10 2013, at 07:14 , Chris Hegarty wrote: > >> Updated webrev and specdiff. >> >> http://cr.openjdk.java.net/~chegar/8014076/ver.01/specdiff/java/util/Arrays.html > > Docs changes look fine to me. > >> http://cr.openjdk.java.net/~chegar/8014076/ver.01/webrev/ > > ArraysParallelSortHelpers:: > > - It's strange to see serialversionid defined for classes that will never be serialized. I think this is mainly to keep the compiler happy. We could suppress the warning, rather than add the serialVersionUID, but I don't think it is worth changing at this point. It can be revisited later if necessary. > ParallelSorting:: > > - Arrays.MIN_ARRAY_SORT_GRAN does this reference still work? Thanks, it has been removed. -Chris. > Otherwise changes look good to me. (Depending very much on regression testing to ensure correctness of the algorithm). > >> >> I incorporated the feedback so far, and reverted the change to make MIN_ARRAY_SORT_GRAN public ( there doesn't appear to be enough justification for this ). >> >> -Chris. > From mike.duigou at oracle.com Thu May 23 17:05:53 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 May 2013 10:05:53 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E4816.1080500@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> Message-ID: <7ECDA648-03FE-4C5E-BC80-3C0431B579EA@oracle.com> This is a good improvement. I agree that David Holmes is your possible best reviewer. :-) Mike On May 23 2013, at 09:47 , Aleksey Shipilev wrote: > Ummm... I think that's exactly what the last paragraph says. What if we > rephrase it as follows? > > ------------- 8< ----------------------------------------------- > When the annotation is used at the class level, the effect is > roughly equivalent to placing the {@code @Contended} annotation > with the anonymous tag over all the unannotated fields of the > object. With the class level annotation, the implementations may > choose different approach to protect the entire object, rather > than protecting only the distinct fields. > ------------- 8< ----------------------------------------------- > > -Aleksey. > > On 05/23/2013 08:20 PM, Mike Duigou wrote: >> You could add one more sentence to cover the effect of @C on class >> with no @C on any field. The response to Peter is great info (but too >> much detail for JavaDoc). >> >> Mike >> >> On May 23 2013, at 09:17 , Aleksey Shipilev wrote: >> >>> On 05/23/2013 06:33 PM, Mike Duigou wrote: >>>> A class level annotation on a class containing no annotated >>>> fields has no effect, correct? >>> >>> It does have the effect, see the last paragraph in the Javadoc. >>> Should we refine this a bit? >>> >>> -Aleksey. >> > From chris.hegarty at oracle.com Thu May 23 17:36:06 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 23 May 2013 17:36:06 +0000 Subject: hg: jdk8/tl/jdk: 8014076: Arrays parallel and serial sorting improvements Message-ID: <20130523173631.03B9748CB0@hg.openjdk.java.net> Changeset: 3b23e3529ab3 Author: dl Date: 2013-05-23 18:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b23e3529ab3 8014076: Arrays parallel and serial sorting improvements Reviewed-by: chegar, mduigou ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/ArraysParallelSortHelpers.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/TimSort.java ! test/java/util/Arrays/ParallelSorting.java From peter.levart at gmail.com Thu May 23 17:37:54 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 23 May 2013 19:37:54 +0200 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E40DA.7000705@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E3C6E.4070501@gmail.com> <519E40DA.7000705@oracle.com> Message-ID: <519E53F2.8070802@gmail.com> Hi Aleksey, What's not very clear is whether the class-level @Contended is the same as class-level @Contended("group") - is the tag used or ignored when specified on the class-level. What does the following do? @Contended("x") class C { @Contended("x") int a; @Contended("y") int b; int c; } Regards, Peter On 05/23/2013 06:16 PM, Aleksey Shipilev wrote: > On 05/23/2013 07:57 PM, Peter Levart wrote: >> Have I understood this correctly? > Yes. @Contended on class is currently the shorthand for the @Contended > with the same (but unknown) tag over all the fields. However, in future > this might change, because @Contended on class might also guard the > object header, as soon as we are brave enough to tap into the GC > interface to allocate the @C objects aligned for the cache line boundary. > > -Aleksey. From aleksey.shipilev at oracle.com Thu May 23 18:23:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 May 2013 22:23:28 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E53F2.8070802@gmail.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E3C6E.4070501@gmail.com> <519E40DA.7000705@oracle.com> <519E53F2.8070802@gmail.com> Message-ID: <519E5EA0.7050001@oracle.com> Oh yes, the tag on the class-level annotation has no effect. -Aleksey. On 05/23/2013 09:37 PM, Peter Levart wrote: > Hi Aleksey, > > What's not very clear is whether the class-level @Contended is the same > as class-level @Contended("group") - is the tag used or ignored when > specified on the class-level. What does the following do? > > @Contended("x") > class C { > @Contended("x") int a; > @Contended("y") int b; > int c; > } > > > Regards, Peter > > > On 05/23/2013 06:16 PM, Aleksey Shipilev wrote: >> On 05/23/2013 07:57 PM, Peter Levart wrote: >>> Have I understood this correctly? >> Yes. @Contended on class is currently the shorthand for the @Contended >> with the same (but unknown) tag over all the fields. However, in future >> this might change, because @Contended on class might also guard the >> object header, as soon as we are brave enough to tap into the GC >> interface to allocate the @C objects aligned for the cache line boundary. >> >> -Aleksey. > From brent.christian at oracle.com Thu May 23 19:02:07 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 23 May 2013 12:02:07 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519E09A7.7040304@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> Message-ID: <519E67AF.7090504@oracle.com> Thank you for having a look, Doug. Comments inline... On 5/23/13 5:20 AM, Doug Lea wrote: > * Given that balanced trees are not used in WeakHashMap > or Hashtable, I wonder why the TreeNode etc classes are > not just nested inside HashMap (usable from subclass LinkedHashMap). > And if so, it would be simpler, faster, and less code-intensive > to declare TreeNode as a subclass of the internal Entry class. > Plus some further gymnastics to overcome the unfortunate > decision to make LinkedHashMap a subclass of HashMap. > Had you considered this? I definitely did. I wanted a cleaner class hierarchy for Entry/TreeNode, but LinkedHashMap makes it difficult, since its Entries need extra before/after references. I couldn't work out a TreeNode class that could be used by both HashMap and LinkedHashMap, since LHM would need a TreeNode derived from LinkedHashMap.Entry, not HashMap.Entry. So instead I used composition, where TreeNode has-a [Linked]HashMap.Entry. > * The comparableClassFor code turns out to be a bottleneck > (and is bypassed in the particular case of String) > in tests of the analogous code in ConcurrentHashMap, mainly > because the only available reflection methods allocate little > objects while checking for the form "class C implements Comparable" > At some point, someone might want to implement a JDK-internal > streamlined form. OK > * Notice that if trees were ever to be used in WeakHashMap, > the nodes would surely need to be declared as WeakReference > subclasses, as are the current Entry nodes. Full-disclosure: I did have a working version of WeakHashMap with balanced trees. Here again, composition helped: TreeNode has-a WeakReference instead of being-a WeakReference. But guaranteeing that TreeBin was protected from encountering null/cleared keys took some contortions. In the end, the extra complexity wasn't worth it, so it's not included. > The whole thought > of doing this though is suspect (so I'm happy to see it > not being done) Glad to hear that taking it out was the right move. :) Thanks, -Brent > On 05/22/13 16:50, Brent Christian wrote: >> I have updated the changes as follows: >> >> * TreeBin.createEntryForNode() + the anonymous TreeBin subclass in >> [Linked]HashMap have been replaced by a TreeBin.map reference back to the >> containing map, enabling TreeBin to just call newEntry() directly. >> >> * TreeNode.entry was made final >> >> * Added a top-level comment in HashMap giving a brief overview of how >> balanced >> trees are used >> >> * Updated the TreeBinSplitBackToEntries test for TREE_THRESHOLD=16 >> >> * Test code was updated to not need to be on the bootclasspath. >> LaunchOnBootClass.java was removed from the changes (and would not >> have been >> needed anyway, due to the recent jtreg update) >> >> >> The new webrev is here: >> http://cr.openjdk.java.net/~bchristi/8005698/webrev.01/ >> >> Thanks, >> -Brent >> >> On 5/13/13 9:48 AM, Brent Christian wrote: >>> Hi, >>> >>> Please review my changes for 8005698 : Handle Frequent HashMap >>> Collisions with Balanced Trees. >>> >>> For HashMap and LinkedHashMap, we would like to duplicate the technique >>> (and some of the code) that the latest ConcurrentHashMap[1] uses for >>> handling hash collisions: use of balanced trees to store map entries in >>> hash bins containing many collisions. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~bchristi/8005698/webrev.00/ >>> >>> Some high-level details copied from the JEP[2]: >>> >>> Earlier work in this area in JDK 8, namely the alternative >>> string-hashing implementation[3], improved collision performance for >>> string-valued keys only, and it did so at the cost of adding a new >>> (private) field to every String instance. >>> >>> The changes proposed here will improve collision performance for any key >>> type that implements Comparable. The alternative string-hashing >>> mechanism, including the private hash32 field added to the String class, >>> can then be removed. >>> >>> The principal idea is that once the number of items in a hash bucket >>> grows beyond a certain threshold, that bucket will switch from using a >>> linked list of entries to a balanced tree. >>> >>> We will not implement this for the Hashtable class - some legacy code >>> that uses it is known to depend upon iteration order. Instead, Hashtable >>> will be reverted to its state prior to the introduction of the >>> alternative string-hashing implementation, and will maintain its >>> historical iteration order. >>> >>> We also will not implement this technique in WeakHashMap. An attempt was >>> made, but the complexity of having to account for weak keys resulted in >>> an unacceptable drop in microbenchmark performance. WeakHashMap will >>> also be reverted to its prior state. >>> >>> Thanks! >>> -Brent >>> >>> 1. >>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?view=log >>> >>> >>> >>> 2. http://openjdk.java.net/jeps/180 >>> 3. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e >> > From Alan.Bateman at oracle.com Thu May 23 20:24:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 May 2013 21:24:25 +0100 Subject: RFR: 8007333: [launcher] removes multiple back slashes / trivial fix In-Reply-To: <519D2AD0.8070901@oracle.com> References: <519D2AD0.8070901@oracle.com> Message-ID: <519E7AF9.4080707@oracle.com> On 22/05/2013 21:30, Kumar Srinivasan wrote: > Hello, > > Please review trivial fix where the launcher did not parse multiple > back-slashes > correctly. I also added some additional test contributed by Jim Holmlund. > > http://cr.openjdk.java.net/~ksrini/8007333/webrev.0/ > > Thanks > Kumar > This looks okay to me. -Alan From jeffhain at rocketmail.com Thu May 23 20:47:30 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 23 May 2013 21:47:30 +0100 (BST) Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <1369341178.67767.YahooMailNeo@web171701.mail.ir2.yahoo.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <1369341178.67767.YahooMailNeo@web171701.mail.ir2.yahoo.com> Message-ID: <1369342050.58257.YahooMailNeo@web171705.mail.ir2.yahoo.com> Hello. Implementing some RB-tree I found out that a lot of the null checks from CLR code could be removed from balancing operations. Looking at TreeBin (http://cr.openjdk.java.net/~bchristi/8005698/webrev.01/) I found some places where such checks could also be removed. In putTreeNode(...) (see comments): ??????? if (x == xp.right) { ??????????? rotateLeft(x = xp); ??????????? // Rotation adds a parent, ??????????? // and xpp was not null, so the new xpp ??????????? // is not null either (even though we ??????????? // did x = xp). ??????????? //xpp = (xp = x.parent) == null ? null : xp.parent; ??????????? xpp = (xp = x.parent).parent; ??????? } ??????? //if (xp != null) { ??????????? xp.red = false; ??????????? //if (xpp != null) { ??????????????? xpp.red = true; ??????????????? rotateRight(xpp); ??????????? //} ??????? //} (...) ??????? if (x == xp.left) { ??????????? rotateRight(x = xp); ??????????? // Rotation adds a parent, ??????????? // and xp was not null, so the new xp ??????????? // is not null either (even though we ??????????? // did x = xp). ??????????? //xpp = (xp = x.parent) == null ? null : xp.parent; ??????????? xpp = (xp = x.parent).parent; ??????? } ??????? //if (xp != null) { ??????????? xp.red = false; ??????????? if (xpp != null) { ??????????????? xpp.red = true; ??????????????? rotateLeft(xpp); ??????????? } ??????? //} (...) ??????? // p is not null so root is not null. ??????? //if (r != null && r.red) { ??????? if (r.red) { ??????????? r.red = false; ??????? } Similar rotation-related simplifications could be done in deleteTreeNode(...). Doing a lot of random add/remove calls (for integers in bounded ranges, for removes to actually work not too rarely), it seemed that null checks could actually be removed for all remaining calls to leftOf/rightOf/setColor (not for getColor), but since I didn't figure out why I didn't? touch these. -Jeff From david.holmes at oracle.com Thu May 23 23:58:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2013 09:58:52 +1000 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519E486F.8060407@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> Message-ID: <519EAD3C.7080803@oracle.com> On 24/05/2013 2:48 AM, Aleksey Shipilev wrote: > Also, let's wait for David Holmes to glance over it. He has the immense > capability to spot the weaknesses in the specifications. Wow talk about pressure! Now I'm obligated to find a weakness. ;-) Luckily Mike and Peter already touched on a few things so ... 1. I prefer the rephrasing below to make it clear that @Contended on a field-less class need not be a no-op. 2. I think something needs to be said about this property and inheritance. 3. I think this: The (optional) contention group tag should be The (optional) field contention group tag and we should also say in the main paragraph that a tag at the class level is ignored. 4. I'm a little unclear about the group tags. It states: "A default annotation without a tag indicates contention with all other fields, including other {@code @Contended} ones." That seems to imply that given: class A { @Contended Object a1; @Contended Object a2; } then a1 and a2 are in different contention groups. ??? Yet I would expect the default annotation value to simply imply a single un-named contention group. Just as the annotation at the class level implies a single un-named group for all unannotated fields. But does that also imply that given: @Contended class A { @Contended Object a1; Object a2; } there are two un-named contention groups? I'm not sure that anyone without knowledge of the implementation will be able to use contention groups effectively. David ----- > -Aleksey. > > On 05/23/2013 08:47 PM, Aleksey Shipilev wrote: >> Ummm... I think that's exactly what the last paragraph says. What if we >> rephrase it as follows? >> >> ------------- 8< ----------------------------------------------- >> When the annotation is used at the class level, the effect is >> roughly equivalent to placing the {@code @Contended} annotation >> with the anonymous tag over all the unannotated fields of the >> object. With the class level annotation, the implementations may >> choose different approach to protect the entire object, rather >> than protecting only the distinct fields. >> ------------- 8< ----------------------------------------------- >> >> -Aleksey. >> >> On 05/23/2013 08:20 PM, Mike Duigou wrote: >>> You could add one more sentence to cover the effect of @C on class >>> with no @C on any field. The response to Peter is great info (but too >>> much detail for JavaDoc). >>> >>> Mike >>> >>> On May 23 2013, at 09:17 , Aleksey Shipilev wrote: >>> >>>> On 05/23/2013 06:33 PM, Mike Duigou wrote: >>>>> A class level annotation on a class containing no annotated >>>>> fields has no effect, correct? >>>> >>>> It does have the effect, see the last paragraph in the Javadoc. >>>> Should we refine this a bit? >>>> >>>> -Aleksey. >>> >> > From kumar.x.srinivasan at oracle.com Fri May 24 00:51:15 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 23 May 2013 17:51:15 -0700 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <519C58C0.4010309@oracle.com> References: <519B1ABE.10303@oracle.com> <519B5816.5080705@oracle.com> <519C58C0.4010309@oracle.com> Message-ID: <519EB983.4070302@oracle.com> Hi Petr, Sorry for the delay, I somehow missed this one. I don't understand objective-c, if Mr Petrov is happy I am ok with it. There seems to be indenting issues 1049-1051 Is there a regression test for this somewhere ? Thanks Kumar > Hello, > > Yes; Kumar should be one of the reviewers here. > > Thanks, > > -Joe > > On 05/21/2013 04:18 AM, Anthony Petrov wrote: >> Hi Petr, >> >> The fix looks good to me. We still need a review from someone who >> maintains the Launcher code. Kumar? >> >> Also, you could use the @autoreleasepool directive to simplify it a >> bit, although I'm fine with the explicit syntax, too. >> >> One comment regarding your remark: >>> c. We would have lost all the hg history for this file. >> >> We wouldn't. Mercurial handles renaming of files very well. See `hg >> help rename` for more details. (I'm not suggesting to rename this >> file though.) >> >> -- >> best regards, >> Anthony >> >> On 05/21/2013 10:57 AM, David Holmes wrote: >>> Adding core-libs as this is actually a launcher change. >>> >>> David >>> >>> On 21/05/2013 4:36 PM, Petr Pchelko wrote: >>>> Hello, AWT Team. >>>> >>>> Please review the fix for the issue: >>>> http://bugs.sun.com/view_bug.do?bug_id=8009911 >>>> The webrev is available at: >>>> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >>>> >>>> The problem: >>>> When launching java with -XstatrOnFirstThread we were using >>>> dispatch_sync to start a Java main on the main thread. This blocked >>>> the main dispatch queue, so all the subsequent calls to GCD were never >>>> invoked. GCD is used a bit in our code, but it is used inside Cocoa, >>>> for example for fullscreen. >>>> >>>> The solution: >>>> We now launch Java main using a performSelectorOnMaintThread, so we do >>>> not block GCD. >>>> >>>> Notes: >>>> 1. This also fixes the following SWT bug: >>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >>>> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did >>>> not rename it to .m, because: >>>> a. It is hard to update an old build system to compile with the >>>> new file name. >>>> b. It is already compiled with -x objective-c, so I will compile >>>> c. We would have lost all the hg history for this file. >>>> >>>> With best regards. Petr. >>>> > From yiming.wang at oracle.com Fri May 24 04:19:45 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 24 May 2013 12:19:45 +0800 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: <519EEA61.2050400@oracle.com> Hi Dan & All, I have updated the test based on your comments, Can you please review the fix? Thanks! http://cr.openjdk.java.net/~ewang/8009258/webrev.02/ Regards, Eric On 2013/4/17 14:36, Dan Xu wrote: > 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 david.holmes at oracle.com Fri May 24 04:26:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2013 14:26:10 +1000 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> Message-ID: <519EEBE2.6070409@oracle.com> On 22/05/2013 2:51 AM, Jason Mehrens wrote: > Aleksej, >> Actually, the readObject calls the super.initCause, because there is no >> initCause in XPathException. > I would think that subclasses of XPE will see calls to this.initCause from readObject. That wouldn't have happened prior to this change. I think this is why super.initCause() (or super.getCause()) must be called here. If you invoke this.xxx() then you may well be invoking a subclass specialization and you don't know what it will do. >> About 'super.getCause() == null' check: yes it can be done in such way. >> In current version I caught the IllegalStateException to correctly >> process the situation when the cause was already initialized. > I think you'll always have to catch ISE. If super.getCause is not null you know initCause will fail. I would think it would be cheaper to null check than to fillStackTrace. But, I haven't tested that. I think readObject only needs to account for deserializing an older version of the exception which will have a non-null local cause, but Throwable.cause is null. That should be rare. The common case would be deserializing the new form, in which case initCause would fail. So I agree with Jason that checking super.getCause() is more efficient than always calling initCause. David > Jason > From david.holmes at oracle.com Fri May 24 04:30:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2013 14:30:34 +1000 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1368777394.3918.24.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> <51957E11.6050608@oracle.com> <1368777394.3918.24.camel@cirrus> Message-ID: <519EECEA.8000908@oracle.com> Thomas, Are we still waiting for a second core-libs reviewer on this? David On 17/05/2013 5:56 PM, Thomas Schatzl wrote: > On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote: >> On 16/05/2013 8:44 PM, Thomas Schatzl wrote: >>> On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: >>>> I updated the test program and the patch in java.lang.ref.Reference >>>> accordingly. >>>> >>>> As for the problem of reproducibility, in my tests I had a 100% >>>> reproduction rate with the previous version of the test. >>>> >>>> However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as >>>> suggested in some other emails. >>>> >>>> I will report back with a new webrev after some testing on more >>>> platforms as suggested by David. >>> >>> a new webrev for the patch is at >>> >>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ >> >> I think the comment is somewhat confusing, but then the details here are >> quite confusing. I guess the key part of this is that if OOME is thrown >> we don't want to try and load InterruptedException - though I'm unclear, >> based on normal exception processing semantics, when that might occur. > > I tried to clarify the comment a little; I also added a dummy > instantiation of InterruptedException at the start of the test program > to avoid OOME during class loading in this case as suggested by the > other email. > > The new webrev is at > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ > > I only compiled and tested this webrev that nothing broke locally, as > the changes are minimal and mostly concerning comments. Pushing a jdk > through jprt also takes a long time. > > Before sending you a patchset after it has been reviewed, I will push it > through jprt again. > >> You can count me as a Reviewer and sponsor. I think only a second JDK/TL >> Reviewer is needed here as no impact on hotspot. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Fri May 24 07:20:48 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 May 2013 09:20:48 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <519EECEA.8000908@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> <51957E11.6050608@oracle.com> <1368777394.3918.24.camel@cirrus> <519EECEA.8000908@oracle.com> Message-ID: <1369380048.2610.1.camel@cirrus> Hi all, On Fri, 2013-05-24 at 14:30 +1000, David Holmes wrote: > Thomas, > > Are we still waiting for a second core-libs reviewer on this? Yes. Would some additional core-libs reviewer be so kind and look at this issue? http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ Thomas > > David > > On 17/05/2013 5:56 PM, Thomas Schatzl wrote: > > On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote: > >> On 16/05/2013 8:44 PM, Thomas Schatzl wrote: > >>> On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote: > >>>> I updated the test program and the patch in java.lang.ref.Reference > >>>> accordingly. > >>>> > >>>> As for the problem of reproducibility, in my tests I had a 100% > >>>> reproduction rate with the previous version of the test. > >>>> > >>>> However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as > >>>> suggested in some other emails. > >>>> > >>>> I will report back with a new webrev after some testing on more > >>>> platforms as suggested by David. > >>> > >>> a new webrev for the patch is at > >>> > >>> http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/ > >> > >> I think the comment is somewhat confusing, but then the details here are > >> quite confusing. I guess the key part of this is that if OOME is thrown > >> we don't want to try and load InterruptedException - though I'm unclear, > >> based on normal exception processing semantics, when that might occur. > > > > I tried to clarify the comment a little; I also added a dummy > > instantiation of InterruptedException at the start of the test program > > to avoid OOME during class loading in this case as suggested by the > > other email. > > > > The new webrev is at > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ > > > > I only compiled and tested this webrev that nothing broke locally, as > > the changes are minimal and mostly concerning comments. Pushing a jdk > > through jprt also takes a long time. > > > > Before sending you a patchset after it has been reviewed, I will push it > > through jprt again. > > > >> You can count me as a Reviewer and sponsor. I think only a second JDK/TL > >> Reviewer is needed here as no impact on hotspot. > > > > Thanks, > > Thomas > > > > From Alan.Bateman at oracle.com Fri May 24 08:09:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 09:09:16 +0100 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <1369380048.2610.1.camel@cirrus> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> <51957E11.6050608@oracle.com> <1368777394.3918.24.camel@cirrus> <519EECEA.8000908@oracle.com> <1369380048.2610.1.camel@cirrus> Message-ID: <519F202C.90907@oracle.com> On 24/05/2013 08:20, Thomas Schatzl wrote: > Hi all, > > On Fri, 2013-05-24 at 14:30 +1000, David Holmes wrote: >> Thomas, >> >> Are we still waiting for a second core-libs reviewer on this? > Yes. Would some additional core-libs reviewer be so kind and look at > this issue? > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ > > Thomas > Only one reviewer is required but if you want a second then the proposed change looks fine to me (and I'm happy the discussion got to the issue, it wasn't initially clear). For the test then I guess I'd probably rename it to ReferenceHandlerOOME but that's a minor comment. -Alan From thomas.schatzl at oracle.com Fri May 24 08:25:43 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 May 2013 10:25:43 +0200 Subject: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread In-Reply-To: <519F202C.90907@oracle.com> References: <1367333840.2722.118.camel@cirrus> <5184C171.8040702@gmail.com> <5185603D.9080904@gmail.com> <1367827347.2653.24.camel@cirrus> <5187C649.60903@oracle.com> <518807AE.7040708@gmail.com> <51882426.2060801@gmail.com> <51886782.60908@oracle.com> <1367913081.2658.7.camel@cirrus> <5188FDA8.3080303@gmail.com> <1367933196.2658.87.camel@cirrus> <51890B47.2010002@gmail.com> <1367939345.2658.102.camel@cirrus> <1368026888.2658.31.camel@cirrus> <518B39DE.9020802@oracle.com> <518B5FED.1050505@gmail.com> <518B7446.6060108@oracle.com> <518B8597.50209@gmail.com> <518B8982.20305@oracle.com> <518B92F6.6030105@gmail.com> <518C6779.5060802@oracle.com> <518CD15F.70503@gmail.com> <1368446108.2909.29.camel@cirrus> <1368701086.2716.13.camel@cirrus> <51957E11.6050608@oracle.com> <1368777394.3918.24.camel@cirrus> <519EECEA.8000908@oracle.com> <1369380048.2610.1.camel@cirrus> <519F202C.90907@oracle.com> Message-ID: <1369383943.2610.11.camel@cirrus> Hi, On Fri, 2013-05-24 at 09:09 +0100, Alan Bateman wrote: > On 24/05/2013 08:20, Thomas Schatzl wrote: > > Hi all, > > > > On Fri, 2013-05-24 at 14:30 +1000, David Holmes wrote: > >> Thomas, > >> > >> Are we still waiting for a second core-libs reviewer on this? > > Yes. Would some additional core-libs reviewer be so kind and look at > > this issue? > > > > http://cr.openjdk.java.net/~tschatzl/7038914/webrev.3/ > > > > Thomas > > > Only one reviewer is required but if you want a second then the proposed > change looks fine to me (and I'm happy the discussion got to the issue, > it wasn't initially clear). For the test then I guess I'd probably > rename it to ReferenceHandlerOOME but that's a minor comment. > > -Alan thanks Alan, David and Peter and all others who contributed to this patch. I will move it further through the process then. Thanks a lot, Thomas From henry.jen at oracle.com Fri May 24 08:30:54 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 24 May 2013 01:30:54 -0700 Subject: RFR: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported Message-ID: <519F253E.3070003@oracle.com> Hi, Please review a fix for 8014855. http://cr.openjdk.java.net/~henryjen/tl/8014855.0/webrev/ The fix ensure we only test symbolic link related scenario on systems support it. Cheers, Henry From weijun.wang at oracle.com Fri May 24 09:34:50 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 24 May 2013 09:34:50 +0000 Subject: hg: jdk8/tl/jdk: 8014196: ktab creates a file with zero kt_vno Message-ID: <20130524093523.B5AC848D07@hg.openjdk.java.net> Changeset: 6816afd70a68 Author: weijun Date: 2013-05-24 17:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6816afd70a68 8014196: ktab creates a file with zero kt_vno Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java + test/sun/security/krb5/tools/KtabZero.java + test/sun/security/krb5/tools/ktzero.sh From dl at cs.oswego.edu Fri May 24 11:18:17 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 24 May 2013 07:18:17 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <1369342050.58257.YahooMailNeo@web171705.mail.ir2.yahoo.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <1369341178.67767.YahooMailNeo@web171701.mail.ir2.yahoo.com> <1369342050.58257.YahooMailNeo@web171705.mail.ir2.yahoo.com> Message-ID: <519F4C79.3040405@cs.oswego.edu> On 05/23/13 16:47, Jeff Hain wrote: > Hello. > > > > Implementing some RB-tree I found out that > > a lot of the null checks from CLR code > could be removed from balancing operations. Yes and no. Some of those not logically needed prevent infinite looping in the case of concurrent interference. (This class is not thread-safe.) While we don't want to encourage people to write racy programs, it's better to maximize the probability that they'll eventually get a CME or related exception rather than a stuck loop. -Doug From jeffhain at rocketmail.com Fri May 24 12:27:53 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 24 May 2013 13:27:53 +0100 (BST) Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519F4C79.3040405@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <1369341178.67767.YahooMailNeo@web171701.mail.ir2.yahoo.com> <1369342050.58257.YahooMailNeo@web171705.mail.ir2.yahoo.com> <519F4C79.3040405@cs.oswego.edu> Message-ID: <1369398473.25736.YahooMailNeo@web171705.mail.ir2.yahoo.com> Doug Lea wrote: >maximize the probability that they'll eventually >get a CME or related exception rather than a stuck loop. ? ? Yes, but I was only considering?removing?logically not needed null checks, just before dereferencing the pointer, and I don't see how it could (directly, i.e. without wrapping catch(NPE)) hurt: If the?pointer is not null, it has no effect. If the?pointer is null, a NPE will be thrown so no stuck loop. ? ? On the contrary, it could even help with a NPE getting us out of an otherwise infinite loop. ? ? -Jeff From Alan.Bateman at oracle.com Fri May 24 13:18:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 14:18:37 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <5192494F.6040609@oracle.com> References: <5192494F.6040609@oracle.com> Message-ID: <519F68AD.9010505@oracle.com> Thanks to everyone for the discussions and suggestions on this topic. I would like to proceed with the original proposal to change stop(Throwable) to throw UOE unconditionally. This means so special casing for ThreadDeath or the current thread. The no-arg Thread.stop() is not impacted. I think it's reasonable to say that this method is not widely used. Mandy did a static analysis of thousands of unique artifacts in maven and we found only a tiny number of usages. Other corpora were searched too. A number of people mailed me privately to report sightings, in almost all cases the usages were completely broken and never worked (incorrect assumption that Thread.stop would wake-up threads blocked in I/O in at least two cases). Clearly this change is significant and will need to documented in compatibility notes and migration documentation. The webrev with the proposed changes is here. As I mentioned in one of the replies, there are 4 j.u.c tests that need to be updated so I've changed these tests to use Unsafe.throwException. http://cr.openjdk.java.net/~alanb/7059085/webrev/ -Alan. From Alan.Bateman at oracle.com Fri May 24 13:39:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 14:39:03 +0100 Subject: RFR: 8012665: CharSequence.chars, CharSequence.codePoints In-Reply-To: <517EA523.1020509@oracle.com> References: <51799135.5020801@oracle.com> <517A7F5D.8050206@oracle.com> <517EA523.1020509@oracle.com> Message-ID: <519F6D77.90603@oracle.com> On 29/04/2013 17:51, Henry Jen wrote: > On 04/26/2013 06:21 AM, Alan Bateman wrote: >> : >> 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. > Just to follow-up on this thread from a few weeks ago. I did a few tests with CharBuffer.chars() and the default implementation performs very poorly as expected. This is easily fixed by adding a spliterator with direct access to the buffer contents and that is straight-forward to do: http://cr.openjdk.java.net/~alanb/8014854/webrev/ I've changed the templates used to generated the buffer classes so that ints/longs/doubles() could be added to Int/Long/DoubleBuffer if needed (which might be interesting when the buffers are backed by memory outside of the heap). The yak shaving in CompileJavaClasses.gmk is because the changes to the generated CharBuffer exposes a bug in the build of JObjC.jar on Mac. -Alan. From chris.hegarty at oracle.com Fri May 24 13:43:20 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 May 2013 14:43:20 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519F68AD.9010505@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <519F6E78.1030807@oracle.com> All looks good to me. -Chris. On 24/05/2013 14:18, Alan Bateman wrote: > > Thanks to everyone for the discussions and suggestions on this topic. I > would like to proceed with the original proposal to change > stop(Throwable) to throw UOE unconditionally. This means so special > casing for ThreadDeath or the current thread. The no-arg Thread.stop() > is not impacted. > > I think it's reasonable to say that this method is not widely used. > Mandy did a static analysis of thousands of unique artifacts in maven > and we found only a tiny number of usages. Other corpora were searched > too. A number of people mailed me privately to report sightings, in > almost all cases the usages were completely broken and never worked > (incorrect assumption that Thread.stop would wake-up threads blocked in > I/O in at least two cases). > > Clearly this change is significant and will need to documented in > compatibility notes and migration documentation. > > The webrev with the proposed changes is here. As I mentioned in one of > the replies, there are 4 j.u.c tests that need to be updated so I've > changed these tests to use Unsafe.throwException. > > http://cr.openjdk.java.net/~alanb/7059085/webrev/ > > -Alan. From Alan.Bateman at oracle.com Fri May 24 14:02:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 15:02:06 +0100 Subject: RFR: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported In-Reply-To: <519F253E.3070003@oracle.com> References: <519F253E.3070003@oracle.com> Message-ID: <519F72DE.80805@oracle.com> On 24/05/2013 09:30, Henry Jen wrote: > Hi, > > Please review a fix for 8014855. > > http://cr.openjdk.java.net/~henryjen/tl/8014855.0/webrev/ > > The fix ensure we only test symbolic link related scenario on systems > support it. > Thanks for taking one. One idea is to just create empty files when sym links are supported. That way only the test for Files.walk following sym links needs to be skipped when sym links aren't supported. -Alan. From Alan.Bateman at oracle.com Fri May 24 14:07:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 15:07:54 +0100 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <519EEA61.2050400@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> <516E42D6.5020309@oracle.com> <519EEA61.2050400@oracle.com> Message-ID: <519F743A.5020509@oracle.com> On 24/05/2013 05:19, Eric Wang wrote: > Hi Dan & All, > > I have updated the test based on your comments, Can you please review > the fix? Thanks! > http://cr.openjdk.java.net/~ewang/8009258/webrev.02/ I think this is okay. Dan is going to sponsor this one. -Alan From maurizio.cimadamore at oracle.com Fri May 24 14:29:32 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 24 May 2013 14:29:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130524142952.35A1E48D10@hg.openjdk.java.net> Changeset: 58329d9f6b68 Author: mcimadamore Date: 2013-05-24 15:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58329d9f6b68 8014643: Parser regression in JDK 8 when compiling super.x Summary: Fixed latent bug in JavacParser.analyzeParens() Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/8014643/T8014643.java Changeset: 97a9b4b3e63a Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97a9b4b3e63a 8014649: Regression: bug in Resolve.resolveOperator Summary: Missing curly braces causes Resolve.findMethod to be called spuriously Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/PrimitiveBinopOverload.java Changeset: 6e5076af4660 Author: mcimadamore Date: 2013-05-24 15:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e5076af4660 8014494: javac crashes when varargs element of a method reference is inferred from the context Summary: varargs element is not refreshed after type-inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/TargetType73.java From john.zavgren at oracle.com Fri May 24 15:04:08 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Fri, 24 May 2013 11:04:08 -0400 Subject: RFR JDK-8015299 Message-ID: <519F8168.7000505@oracle.com> Greetings: I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_solinux.c and I posted a webrev image of the changes at: http://cr.openjdk.java.net/~jzavgren/8015299/webrev.01/ (I also edited a comment.) Thanks! John -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From rob.mckenna at oracle.com Fri May 24 15:11:43 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 24 May 2013 16:11:43 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <51921E4C.506@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> Message-ID: <519F832F.7020205@oracle.com> Thanks Alan, Updated webrev at: http://cr.openjdk.java.net/~robm/7038105/webrev.02/ -Rob On 14/05/13 12:21, Alan Bateman wrote: > On 14/05/2013 02:59, Rob McKenna wrote: >> Hi folks, >> >> Looking for a review of this suggested fix from Fujitsu. >> GetFileAttributesExW() returns ERROR_SHARING_VIOLATION for >> pagefile.sys and hiberfi.sys so we're falling back to FindFirstFile >> instead: >> >> http://cr.openjdk.java.net/~robm/7038105/webrev.01/ >> >> -Rob > Thanks for taking this one and removed the crud that is the harding of > c:\pagefile.sys. > > Using FindFirstFile when GetFileAttributesExW fails when > ERROR_SHARING_VIOLATION is the right approach but it needs an > additional check on the attributes to see if they contain a reparse > point, otherwise you return the attributes of the reparse point rather > than the final file (try it with a symbolic link and you'll see what I > mean). When it contains a reparse point then you can use > getFileInformation to attempt to open the file (with sharing) and > obtain the attributes. > > One other idea is to rename it to getFinalAttributes and move it up to > near the top so that it's with the other support functions. > > -Alan. > From Alan.Bateman at oracle.com Fri May 24 15:48:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 16:48:57 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <519F832F.7020205@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> <519F832F.7020205@oracle.com> Message-ID: <519F8BE9.4060404@oracle.com> On 24/05/2013 16:11, Rob McKenna wrote: > Thanks Alan, > > Updated webrev at: http://cr.openjdk.java.net/~robm/7038105/webrev.02/ > > -Rob This looks much better except that I assume it should only fallback to FindFirstFileW if the error is ERROR_SHARING_VIOLATION. If I read it correctly then it will do the fallback for every error, say the file doesn't exist. -Alan > > On 14/05/13 12:21, Alan Bateman wrote: >> On 14/05/2013 02:59, Rob McKenna wrote: >>> Hi folks, >>> >>> Looking for a review of this suggested fix from Fujitsu. >>> GetFileAttributesExW() returns ERROR_SHARING_VIOLATION for >>> pagefile.sys and hiberfi.sys so we're falling back to FindFirstFile >>> instead: >>> >>> http://cr.openjdk.java.net/~robm/7038105/webrev.01/ >>> >>> -Rob >> Thanks for taking this one and removed the crud that is the harding >> of c:\pagefile.sys. >> >> Using FindFirstFile when GetFileAttributesExW fails when >> ERROR_SHARING_VIOLATION is the right approach but it needs an >> additional check on the attributes to see if they contain a reparse >> point, otherwise you return the attributes of the reparse point >> rather than the final file (try it with a symbolic link and you'll >> see what I mean). When it contains a reparse point then you can use >> getFileInformation to attempt to open the file (with sharing) and >> obtain the attributes. >> >> One other idea is to rename it to getFinalAttributes and move it up >> to near the top so that it's with the other support functions. >> >> -Alan. >> > From chris.hegarty at oracle.com Fri May 24 16:12:54 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 May 2013 17:12:54 +0100 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 Message-ID: <519F9186.8040000@oracle.com> The final outstanding task from JEP 155 is to add CHMv8, and update the remainder of the j.u.c implementation, add spliterator implementation for concurrent collections, etc 8004138: Resync java.util.concurrent classes with Dougs CVS - 05/2013 8005704: Update ConcurrentHashMap to v8 specdiff: http://cr.openjdk.java.net/~chegar/8004138/ver.00/specdiff/java/util/concurrent/package-summary.html webrev http://cr.openjdk.java.net/~chegar/8004138/ver.00/webrev/ As per usual all changes are coming from Doug, and others. Most of the changes have been baking in the lambda repo for some time now. I'm not expecting an in dept review per say. All regression tests and JCK will be run. I guess the main focus should be on the new CHM API's -Chris. From martinrb at google.com Fri May 24 16:15:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 May 2013 09:15:45 -0700 Subject: RFR JDK-8015299 In-Reply-To: <519F8168.7000505@oracle.com> References: <519F8168.7000505@oracle.com> Message-ID: Hi John, The memory leak fix looks good. --- IIRC I was the author of the comment, so it is not surprising that I might prefer that version. "nul" is ___not___ a typo for NULL. It makes no sense to speak of character arrays being NULL-terminated. It also isn't quite right to say that readlink "generates" an array - it simply writes into one. However, it is more correct to spell "nul" "NUL" as in ASCII(7). If you wanted to be more precise about which readlink, you could write readlink(2) instead of readlink() to disambiguate from readlink(1) On Fri, May 24, 2013 at 8:04 AM, John Zavgren wrote: > Greetings: > > I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** > solinux.c > and I posted a webrev image of the changes at: > http://cr.openjdk.java.net/~**jzavgren/8015299/webrev.01/< > http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/ > > > > (I also edited a comment.) > > Thanks! > John > > -- > John Zavgren > john.zavgren at oracle.com > 603-821-0904 > US-Burlington-MA > > From rob.mckenna at oracle.com Fri May 24 16:50:16 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 24 May 2013 17:50:16 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <519F8BE9.4060404@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> <519F832F.7020205@oracle.com> <519F8BE9.4060404@oracle.com> Message-ID: <519F9A48.6030509@oracle.com> http://cr.openjdk.java.net/~robm/7038105/webrev.03/ -Rob On 24/05/13 16:48, Alan Bateman wrote: > On 24/05/2013 16:11, Rob McKenna wrote: >> Thanks Alan, >> >> Updated webrev at: http://cr.openjdk.java.net/~robm/7038105/webrev.02/ >> >> -Rob > This looks much better except that I assume it should only fallback to > FindFirstFileW if the error is ERROR_SHARING_VIOLATION. If I read it > correctly then it will do the fallback for every error, say the file > doesn't exist. > > -Alan > > >> >> On 14/05/13 12:21, Alan Bateman wrote: >>> On 14/05/2013 02:59, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> Looking for a review of this suggested fix from Fujitsu. >>>> GetFileAttributesExW() returns ERROR_SHARING_VIOLATION for >>>> pagefile.sys and hiberfi.sys so we're falling back to FindFirstFile >>>> instead: >>>> >>>> http://cr.openjdk.java.net/~robm/7038105/webrev.01/ >>>> >>>> -Rob >>> Thanks for taking this one and removed the crud that is the harding >>> of c:\pagefile.sys. >>> >>> Using FindFirstFile when GetFileAttributesExW fails when >>> ERROR_SHARING_VIOLATION is the right approach but it needs an >>> additional check on the attributes to see if they contain a reparse >>> point, otherwise you return the attributes of the reparse point >>> rather than the final file (try it with a symbolic link and you'll >>> see what I mean). When it contains a reparse point then you can use >>> getFileInformation to attempt to open the file (with sharing) and >>> obtain the attributes. >>> >>> One other idea is to rename it to getFinalAttributes and move it up >>> to near the top so that it's with the other support functions. >>> >>> -Alan. >>> >> > From Alan.Bateman at oracle.com Fri May 24 17:06:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 May 2013 18:06:01 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <519F9A48.6030509@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> <519F832F.7020205@oracle.com> <519F8BE9.4060404@oracle.com> <519F9A48.6030509@oracle.com> Message-ID: <519F9DF9.90200@oracle.com> On 24/05/2013 17:50, Rob McKenna wrote: > http://cr.openjdk.java.net/~robm/7038105/webrev.03/ > > -Rob Good, it's right now. Just a few comment comments: - I'd suggest changing the comment on the function to something like "Read and return the attributes of the final target" as "special cases" is a bit confusing. - The comment on line 230 says "pagefile.sys is a special case" but this covers all sharing issues now so I suggest removing it. - For L230/231 then it might be clearer as: } else if (GetLastError() == ERROR_SHARING_VIOLATION) { but that just a preference thing, what you have is okay too. -Alan. From brian.burkhalter at oracle.com Fri May 24 17:09:22 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 May 2013 10:09:22 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Message-ID: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Originally posted one month ago today. http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016355.html https://www.youtube.com/watch?v=D9kv_V5lhiE Thanks, Brian From forax at univ-mlv.fr Fri May 24 17:27:58 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 24 May 2013 19:27:58 +0200 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519F68AD.9010505@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <519FA31E.3070400@univ-mlv.fr> On 05/24/2013 03:18 PM, Alan Bateman wrote: > > Thanks to everyone for the discussions and suggestions on this topic. > I would like to proceed with the original proposal to change > stop(Throwable) to throw UOE unconditionally. This means so special > casing for ThreadDeath or the current thread. The no-arg Thread.stop() > is not impacted. > > I think it's reasonable to say that this method is not widely used. > Mandy did a static analysis of thousands of unique artifacts in maven > and we found only a tiny number of usages. Other corpora were searched > too. A number of people mailed me privately to report sightings, in > almost all cases the usages were completely broken and never worked > (incorrect assumption that Thread.stop would wake-up threads blocked > in I/O in at least two cases). > > Clearly this change is significant and will need to documented in > compatibility notes and migration documentation. > > The webrev with the proposed changes is here. As I mentioned in one of > the replies, there are 4 j.u.c tests that need to be updated so I've > changed these tests to use Unsafe.throwException. > > http://cr.openjdk.java.net/~alanb/7059085/webrev/ > > -Alan. looks good, thumb up. R?mi From joe.darcy at oracle.com Fri May 24 17:31:43 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 May 2013 10:31:43 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519F68AD.9010505@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <519FA3FF.5030808@oracle.com> Looks good Alan and good riddance to Thread.stop(Throwable)! -Joe On 05/24/2013 06:18 AM, Alan Bateman wrote: > > Thanks to everyone for the discussions and suggestions on this topic. > I would like to proceed with the original proposal to change > stop(Throwable) to throw UOE unconditionally. This means so special > casing for ThreadDeath or the current thread. The no-arg Thread.stop() > is not impacted. > > I think it's reasonable to say that this method is not widely used. > Mandy did a static analysis of thousands of unique artifacts in maven > and we found only a tiny number of usages. Other corpora were searched > too. A number of people mailed me privately to report sightings, in > almost all cases the usages were completely broken and never worked > (incorrect assumption that Thread.stop would wake-up threads blocked > in I/O in at least two cases). > > Clearly this change is significant and will need to documented in > compatibility notes and migration documentation. > > The webrev with the proposed changes is here. As I mentioned in one of > the replies, there are 4 j.u.c tests that need to be updated so I've > changed these tests to use Unsafe.throwException. > > http://cr.openjdk.java.net/~alanb/7059085/webrev/ > > -Alan. From mike.duigou at oracle.com Fri May 24 17:46:32 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 24 May 2013 10:46:32 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519F68AD.9010505@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: I wonder if perhaps the the NPE check on the passed exception and the security permission check should be retained. I am otherwise fine with Thread.stop(Throwable) unconditionally throwing UOE. Mike On May 24 2013, at 06:18 , Alan Bateman wrote: > > Thanks to everyone for the discussions and suggestions on this topic. I would like to proceed with the original proposal to change stop(Throwable) to throw UOE unconditionally. This means so special casing for ThreadDeath or the current thread. The no-arg Thread.stop() is not impacted. > > I think it's reasonable to say that this method is not widely used. Mandy did a static analysis of thousands of unique artifacts in maven and we found only a tiny number of usages. Other corpora were searched too. A number of people mailed me privately to report sightings, in almost all cases the usages were completely broken and never worked (incorrect assumption that Thread.stop would wake-up threads blocked in I/O in at least two cases). > > Clearly this change is significant and will need to documented in compatibility notes and migration documentation. > > The webrev with the proposed changes is here. As I mentioned in one of the replies, there are 4 j.u.c tests that need to be updated so I've changed these tests to use Unsafe.throwException. > > http://cr.openjdk.java.net/~alanb/7059085/webrev/ > > -Alan. From martinrb at google.com Fri May 24 18:14:43 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 May 2013 11:14:43 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519F68AD.9010505@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: On Fri, May 24, 2013 at 6:18 AM, Alan Bateman wrote: > > The webrev with the proposed changes is here. As I mentioned in one of the > replies, there are 4 j.u.c tests that need to be updated so I've changed > these tests to use Unsafe.throwException. > Alan, you're telling everyone there's no need for Thread.stop, but you are replacing usages in tests with calls to Unsafe, which is not available to normal code. So you have a kind of moral obligation here to replace usages with "ordinary" java code. There are other ways to do sneakyThrow, and perhaps a sneakyRethrow method should be added to the jdk test library. Ordinary java code should be able to simply catch and rethrow a Throwable if type analysis can "prove" that the exception is not an Exception. As a data point, Doug uses this: (Doug, it's not obvious to me why you handle Error and RuntimeException specially) /** * A version of "sneaky throw" to relay exceptions */ static void rethrow(final Throwable ex) { if (ex != null) { if (ex instanceof Error) throw (Error)ex; if (ex instanceof RuntimeException) throw (RuntimeException)ex; ForkJoinTask.uncheckedThrow(ex); } } /** * The sneaky part of sneaky throw, relying on generics * limitations to evade compiler complaints about rethrowing * unchecked exceptions */ @SuppressWarnings("unchecked") static void uncheckedThrow(Throwable t) throws T { if (t != null) throw (T)t; // rely on vacuous cast } From joe.darcy at oracle.com Fri May 24 18:26:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 24 May 2013 18:26:28 +0000 Subject: hg: jdk8/tl/langtools: 8014836: Have GenericDeclaration extend AnnotatedElement Message-ID: <20130524182635.1F03048D20@hg.openjdk.java.net> Changeset: 0f8e9a0e5d9a Author: darcy Date: 2013-05-24 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f8e9a0e5d9a 8014836: Have GenericDeclaration extend AnnotatedElement Reviewed-by: jfranck ! src/share/sample/language/model/CoreReflectionFactory.java From xueming.shen at oracle.com Fri May 24 18:53:15 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 24 May 2013 11:53:15 -0700 Subject: RFR JDK-8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Message-ID: <519FB71B.7030103@oracle.com> Hi, Please help review the change for JDK-8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method http://cr.openjdk.java.net/~sherman/8001750/webrev/ The bug description is actually not accurate, the replacement field of CharsetDecoder class is String, not a byte[], so CharsetDecoder does not have the "defensive copy" issue described. CharsetEncoder class however appears to have this issue (replacementWith() and replacement() don't make defensive copy when set/get its internal data field), which has the byte[] type replacement. The change is to (1) return a copy of the replacement when replacement() is invoked (2) save a defensive copy of the new replacement when set via replacementWith() To return a defensive copy of replacement from replacement() may trigger minor performance "regression" when internal interface ArrayEncoder.encode() is invoked (from StringCoding and ZipCoder), so some corresponding updates in UTF8, DoubleByte and HKSCS clases to save copy of the replacement byte array or byte (SingleByte class already makes its own copy). Thanks, -Sherman From dl at cs.oswego.edu Fri May 24 18:58:28 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 24 May 2013 14:58:28 -0400 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <519FB854.5050701@cs.oswego.edu> On 05/24/13 14:14, Martin Buchholz wrote: > Ordinary java code should be able to simply catch and rethrow a Throwable if > type analysis can "prove" that the exception is not an Exception. > > As a data point, Doug uses this: > > (Doug, it's not obvious to me why you handle Error and RuntimeException specially) > This was initially done when the unchecked-throw was via Unsafe.throwException, needed only in those cases. But then we switched to using sneaky-throw, relying on the same javac type-check limitation everyone else relies on these days. Which makes it more portable across JVMs, but could in theory stop working someday. But until then, those checks aren't needed and can/should go away. -Doug > /** > * A version of "sneaky throw" to relay exceptions > */ > static void rethrow(final Throwable ex) { > if (ex != null) { > if (ex instanceof Error) > throw (Error)ex; > if (ex instanceof RuntimeException) > throw (RuntimeException)ex; > ForkJoinTask.uncheckedThrow(ex); > } > } > > /** > * The sneaky part of sneaky throw, relying on generics > * limitations to evade compiler complaints about rethrowing > * unchecked exceptions > */ > @SuppressWarnings("unchecked") static > void uncheckedThrow(Throwable t) throws T { > if (t != null) > throw (T)t; // rely on vacuous cast > } > > From xueming.shen at oracle.com Fri May 24 19:22:04 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 24 May 2013 12:22:04 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files Message-ID: <519FBDDC.2030806@oracle.com> I'm trying to address the following two issues 6303183: Support NTFS and Unix-style timestamps for entries in Zip files 7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone. which mainly is about the "mtime" field in both loc and cen tables are dos format, (it means the default time stamp of a zip entry is 2-second granularity time stamp and timezone sensitive (the time is interpreted as the "local time" of the timezone the system is running on, it does not count the time zone difference) The proposed change here is to (1) add a Info-ZIP timestamp in entry's extra data (like zip/unzip does), which uses typical "unix style" second granularity time stamp and is in UTC/GMT timezone (2) change the ZipEntry.time (renamed to mtime) to be the new unix-style-second granularity/UTC time, instead of the current "dos style-2-second granularity and local-time" time stamp, so the set/getTime() can just do the set/get directly without conversion, however the ZipIn/OutputStream and ZipFile need to handle the conversion when dealing with the ZIP formatted time stamp. (3) the "ZipEntry" from ZipOutputStream/ZipFile now has a better time stamp if the zip file has the Info-ZIP formatted time stamp or the NTFS style time stamp (which has the microsecond granularity) (4) For ZipFileSytem, it now output the NTFS style time stamp on Windows platfrom and Info-ZIP style on non-Windows platform. http://cr.openjdk.java.net/~sherman/6303183/webrev/ I'm yet to run the full regression tests on it, comment/opinions are appreciated. Thanks, -Sherman PS. There is a more "complete" alternative, in which the creation time and last access time are supported via ZipEntry with the NTFS/Info-ZIP time stamp, but I guess there might be no string request for it for now, so it might be better to stay with the "simple" version for now. http://cr.openjdk.java.net/~sherman/6303183/webrev.full/ This proposal is to add two new fields, atime and ctime into ZipEntry and generate NTFS and Info-ZIP's extended timestamp based on the platform os the jvm is running on. From rob.mckenna at oracle.com Fri May 24 20:24:04 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 24 May 2013 21:24:04 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <519F9DF9.90200@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> <519F832F.7020205@oracle.com> <519F8BE9.4060404@oracle.com> <519F9A48.6030509@oracle.com> <519F9DF9.90200@oracle.com> Message-ID: <519FCC64.5040707@oracle.com> Will do Alan, thanks. If its ok I'll just do this with the push as opposed to posting another review. -Rob On 24/05/13 18:06, Alan Bateman wrote: > On 24/05/2013 17:50, Rob McKenna wrote: >> http://cr.openjdk.java.net/~robm/7038105/webrev.03/ >> >> -Rob > Good, it's right now. > > Just a few comment comments: > > - I'd suggest changing the comment on the function to something like > "Read and return the attributes of the final target" as "special > cases" is a bit confusing. > > - The comment on line 230 says "pagefile.sys is a special case" but > this covers all sharing issues now so I suggest removing it. > > - For L230/231 then it might be clearer as: > > } else if (GetLastError() == ERROR_SHARING_VIOLATION) { > > but that just a preference thing, what you have is okay too. > > -Alan. From brian.goetz at oracle.com Fri May 24 20:29:14 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 24 May 2013 16:29:14 -0400 Subject: RFR 8015402 -- lambda metafactory simplifications Message-ID: <519FCD9A.8030108@oracle.com> The following webrev describes changes to the lambda metafactory enabled by the compiler generating bridge methods in interfaces, and therefore the metafactory need not try and guess which other methods should be bridged to the main SAM method. The compiler can optionally generate a specific list of alternate signatures to be bridged. http://cr.openjdk.java.net/~briangoetz/JDK-8015402 From martinrb at google.com Fri May 24 22:53:39 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 May 2013 15:53:39 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: <519FBDDC.2030806@oracle.com> References: <519FBDDC.2030806@oracle.com> Message-ID: Thanks very much for adding this support. Users will be happy. You could make it clearer in the javadoc that you are storing and returning times in seconds since the epoch, and that the epoch is Jan 1, 1980. Note that we now have both kinds of epochs: 1970 and 1980, for extra confusion. Also, I guess the zip world doesn't have any kind of year 2038 strategy? Probably roll over as we get close to 2038 and pray? Probably include links to both appnotes, the pkware one and info-zip's modified version. On Fri, May 24, 2013 at 12:22 PM, Xueming Shen wrote: > > I'm trying to address the following two issues > > 6303183: Support NTFS and Unix-style timestamps for entries in Zip files > 7012868: (zipfs) file times of entry in zipfs should always be the same > regardless of TimeZone. > > which mainly is about the "mtime" field in both loc and cen tables are dos > format, > (it means the default time stamp of a zip entry is 2-second granularity > time stamp > and timezone sensitive (the time is interpreted as the "local time" of > the timezone > the system is running on, it does not count the time zone difference) > > The proposed change here is to > > (1) add a Info-ZIP timestamp in entry's extra data (like zip/unzip does), > which uses > typical "unix style" second granularity time stamp and is in UTC/GMT > timezone > > (2) change the ZipEntry.time (renamed to mtime) to be the new > unix-style-second > granularity/UTC time, instead of the current "dos style-2-second > granularity and > local-time" time stamp, so the set/getTime() can just do the set/get > directly without > conversion, however the ZipIn/OutputStream and ZipFile need to handle the > conversion > when dealing with the ZIP formatted time stamp. > > (3) the "ZipEntry" from ZipOutputStream/ZipFile now has a better time > stamp if > the zip file has the Info-ZIP formatted time stamp or the NTFS style time > stamp > (which has the microsecond granularity) > > (4) For ZipFileSytem, it now output the NTFS style time stamp on Windows > platfrom > and Info-ZIP style on non-Windows platform. > > http://cr.openjdk.java.net/~**sherman/6303183/webrev/ > > I'm yet to run the full regression tests on it, comment/opinions are > appreciated. > > Thanks, > -Sherman > > PS. > There is a more "complete" alternative, in which the creation time and last > access time are supported via ZipEntry with the NTFS/Info-ZIP time stamp, > but I guess there might be no string request for it for now, so it might be > better to stay with the "simple" version for now. > > http://cr.openjdk.java.net/~**sherman/6303183/webrev.full/ > > This proposal is to add two new fields, atime and ctime into ZipEntry and > generate > NTFS and Info-ZIP's extended timestamp based on the platform os the jvm is > running > on. > > > From martinrb at google.com Fri May 24 22:57:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 May 2013 15:57:55 -0700 Subject: RFR JDK-8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method In-Reply-To: <519FB71B.7030103@oracle.com> References: <519FB71B.7030103@oracle.com> Message-ID: Looks good. On Fri, May 24, 2013 at 11:53 AM, Xueming Shen wrote: > Hi, > > Please help review the change for > > JDK-8001750: CharsetDecoder.replacement should not be changeable except > via replaceWith method > > http://cr.openjdk.java.net/~**sherman/8001750/webrev/ > > The bug description is actually not accurate, the replacement field > of CharsetDecoder class is String, not a byte[], so CharsetDecoder > does not have the "defensive copy" issue described. CharsetEncoder > class however appears to have this issue (replacementWith() and > replacement() don't make defensive copy when set/get its internal > data field), which has the byte[] type replacement. > > The change is to > (1) return a copy of the replacement when replacement() is invoked > (2) save a defensive copy of the new replacement when set via > replacementWith() > > To return a defensive copy of replacement from replacement() may > trigger minor performance "regression" when internal interface > ArrayEncoder.encode() is invoked (from StringCoding and ZipCoder), > so some corresponding updates in UTF8, DoubleByte and HKSCS clases > to save copy of the replacement byte array or byte (SingleByte class > already makes its own copy). > > Thanks, > -Sherman > > > From kumar.x.srinivasan at oracle.com Fri May 24 23:01:01 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 24 May 2013 16:01:01 -0700 Subject: RFR: 8007333: [launcher] removes multiple back slashes / trivial fix In-Reply-To: <519E7AF9.4080707@oracle.com> References: <519D2AD0.8070901@oracle.com> <519E7AF9.4080707@oracle.com> Message-ID: <519FF12D.5060405@oracle.com> After some hallway conversation with Akhil, I added some more tests with progressive number of \ handling, just to make sure, besides that there are no other changes. full webrev: http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/ delta webrev http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/webrev.delta/index.html If there are no more comments I will push this by Tuesday. Thanks Kumar > On 22/05/2013 21:30, Kumar Srinivasan wrote: >> Hello, >> >> Please review trivial fix where the launcher did not parse multiple >> back-slashes >> correctly. I also added some additional test contributed by Jim >> Holmlund. >> >> http://cr.openjdk.java.net/~ksrini/8007333/webrev.0/ >> >> Thanks >> Kumar >> > This looks okay to me. > > -Alan From xueming.shen at oracle.com Sat May 25 00:03:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 24 May 2013 17:03:01 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: References: <519FBDDC.2030806@oracle.com> Message-ID: <519FFFB5.7090202@oracle.com> On 5/24/13 3:53 PM, Martin Buchholz wrote: > Thanks very much for adding this support. Users will be happy. > > You could make it clearer in the javadoc that you are storing and > returning times in seconds since the epoch, and that the epoch is Jan > 1, 1980. This change actually also "partially" fixeds that ZipEntry dos 1980 epoch bug as well since the ZipEntry.set/getEntry() no longer do the java<->dos conversion. While the time stamp in the loc/cen time field still stores the dos formatted time stamp (therefor still has the 1980 issue), with the additional Info-ZIP's extra time stamp the ZipEntry from those zip file should now have the time stamp of the "normal" 1970 epoch. -Sherman > > Note that we now have both kinds of epochs: 1970 and 1980, for extra > confusion. > Also, I guess the zip world doesn't have any kind of year 2038 > strategy? Probably roll over as we get close to 2038 and pray? > > Probably include links to both appnotes, the pkware one and info-zip's > modified version. > > > > On Fri, May 24, 2013 at 12:22 PM, Xueming Shen > > wrote: > > > I'm trying to address the following two issues > > 6303183: Support NTFS and Unix-style timestamps for entries in Zip > files > 7012868: (zipfs) file times of entry in zipfs should always be the > same regardless of TimeZone. > > which mainly is about the "mtime" field in both loc and cen tables > are dos format, > (it means the default time stamp of a zip entry is 2-second > granularity time stamp > and timezone sensitive (the time is interpreted as the "local > time" of the timezone > the system is running on, it does not count the time zone difference) > > The proposed change here is to > > (1) add a Info-ZIP timestamp in entry's extra data (like zip/unzip > does), which uses > typical "unix style" second granularity time stamp and is in > UTC/GMT timezone > > (2) change the ZipEntry.time (renamed to mtime) to be the new > unix-style-second > granularity/UTC time, instead of the current "dos style-2-second > granularity and > local-time" time stamp, so the set/getTime() can just do the > set/get directly without > conversion, however the ZipIn/OutputStream and ZipFile need to > handle the conversion > when dealing with the ZIP formatted time stamp. > > (3) the "ZipEntry" from ZipOutputStream/ZipFile now has a better > time stamp if > the zip file has the Info-ZIP formatted time stamp or the NTFS > style time stamp > (which has the microsecond granularity) > > (4) For ZipFileSytem, it now output the NTFS style time stamp on > Windows platfrom > and Info-ZIP style on non-Windows platform. > > http://cr.openjdk.java.net/~sherman/6303183/webrev/ > > > I'm yet to run the full regression tests on it, comment/opinions > are appreciated. > > Thanks, > -Sherman > > PS. > There is a more "complete" alternative, in which the creation time > and last > access time are supported via ZipEntry with the NTFS/Info-ZIP time > stamp, > but I guess there might be no string request for it for now, so it > might be > better to stay with the "simple" version for now. > > http://cr.openjdk.java.net/~sherman/6303183/webrev.full/ > > > This proposal is to add two new fields, atime and ctime into > ZipEntry and generate > NTFS and Info-ZIP's extended timestamp based on the platform os > the jvm is running > on. > > > From akhil.arora at oracle.com Sat May 25 00:50:10 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Fri, 24 May 2013 17:50:10 -0700 Subject: RFR: 8007333: [launcher] removes multiple back slashes / trivial fix In-Reply-To: <519FF12D.5060405@oracle.com> References: <519D2AD0.8070901@oracle.com> <519E7AF9.4080707@oracle.com> <519FF12D.5060405@oracle.com> Message-ID: <51A00AC2.3050508@oracle.com> looks good On 05/24/2013 04:01 PM, Kumar Srinivasan wrote: > After some hallway conversation with Akhil, I added some more tests > with progressive number of \ handling, just to make sure, besides that > there > are no other changes. > > full webrev: > http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/ > > delta webrev > http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/webrev.delta/index.html > > If there are no more comments I will push this by Tuesday. > > Thanks > Kumar > > >> On 22/05/2013 21:30, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review trivial fix where the launcher did not parse multiple >>> back-slashes >>> correctly. I also added some additional test contributed by Jim >>> Holmlund. >>> >>> http://cr.openjdk.java.net/~ksrini/8007333/webrev.0/ >>> >>> Thanks >>> Kumar >>> >> This looks okay to me. >> >> -Alan > From kumar.x.srinivasan at oracle.com Sat May 25 01:54:53 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 25 May 2013 01:54:53 +0000 Subject: hg: jdk8/tl/jdk: 8007333: [launcher] removes multiple back slashes Message-ID: <20130525015529.0B9A248D30@hg.openjdk.java.net> Changeset: 5e769206f036 Author: ksrini Date: 2013-05-24 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e769206f036 8007333: [launcher] removes multiple back slashes Reviewed-by: alanb, akhil ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java From mike.duigou at oracle.com Sat May 25 03:17:46 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 24 May 2013 20:17:46 -0700 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <519F9186.8040000@oracle.com> References: <519F9186.8040000@oracle.com> Message-ID: <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> Hi Chris; There's an awful lot here! - I found it hard to read the javadoc changes with all of the -> {@code} changes. I made webrev with only the non- changes: http://cr.openjdk.java.net/~mduigou/concurrent.after.tt.code/0/webrev/ - Martin had pushed the changes for "7178639: Deque.push specifies that it returns a value but the method is void" to Doug's repo. Can we include it? - It was surprising (and somewhat disappointing) to see changes like the following in various places. Is iterator creation that expensive? I'd hate to have to go back to using old style for loops everywhere. - List> futures = new ArrayList>(tasks.size()); + ArrayList> futures = new ArrayList>(tasks.size()); Why not 'List> futures = new ArrayList<>(tasks.size());' ? and - for (Future f : futures) - f.cancel(true); + for (int i = 0, size = futures.size(); i < size; i++) + futures.get(i).cancel(true); Use forEach(f -> { f.cancel(true);}) ? - Empty diffs in CompletableFuture and elsewhere are whitespace only changes? - The default for getOrDefault() in ConcurrentMap shouldn't be removed. - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not normally order preserving. - I find TimeUnit.NANOSECONDS to be less ambiguous than static import of NANOSECONDS. Personal taste I guess. - I have reviewed only up to AtomicBoolean in the webrev and not reviewed the specdiff yet. (But I or someone should). I will continue on Tuesday. Mike On May 24 2013, at 09:12 , Chris Hegarty wrote: > The final outstanding task from JEP 155 is to add CHMv8, and update the remainder of the j.u.c implementation, add spliterator implementation for concurrent collections, etc > > 8004138: Resync java.util.concurrent classes with Dougs CVS - 05/2013 > 8005704: Update ConcurrentHashMap to v8 > > specdiff: > http://cr.openjdk.java.net/~chegar/8004138/ver.00/specdiff/java/util/concurrent/package-summary.html > webrev > http://cr.openjdk.java.net/~chegar/8004138/ver.00/webrev/ > > As per usual all changes are coming from Doug, and others. Most of the changes have been baking in the lambda repo for some time now. > > I'm not expecting an in dept review per say. All regression tests and JCK will be run. I guess the main focus should be on the new CHM API's > > -Chris. From henry.jen at oracle.com Sat May 25 03:44:34 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 24 May 2013 20:44:34 -0700 Subject: RFR: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported In-Reply-To: <519F72DE.80805@oracle.com> References: <519F253E.3070003@oracle.com> <519F72DE.80805@oracle.com> Message-ID: <45E7FDC5-3D25-4B92-9CE3-1511AA25EB07@oracle.com> On May 24, 2013, at 7:02 AM, Alan Bateman wrote: > On 24/05/2013 09:30, Henry Jen wrote: >> Hi, >> >> Please review a fix for 8014855. >> >> http://cr.openjdk.java.net/~henryjen/tl/8014855.0/webrev/ >> >> The fix ensure we only test symbolic link related scenario on systems >> support it. >> > Thanks for taking one. > > One idea is to just create empty files when sym links are supported. That way only the test for Files.walk following sym links needs to be skipped when sym links aren't supported. > If I didn't misunderstand you, that's implemented in earlier test for walk in this same file. This fix is for SecurityException cases. Cheers, Henry > -Alan. > From aleksej.efimov at oracle.com Sat May 25 08:37:35 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sat, 25 May 2013 12:37:35 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <519EEBE2.6070409@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> <519EEBE2.6070409@oracle.com> Message-ID: <51A0784F.8090800@oracle.com> David, Jason, Thank you for your comments and suggestions. They all were taken in account and as a result - the new webrev: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/ On 05/24/2013 08:26 AM, David Holmes wrote: > On 22/05/2013 2:51 AM, Jason Mehrens wrote: >> Aleksej, >>> Actually, the readObject calls the super.initCause, because there is no >>> initCause in XPathException. >> I would think that subclasses of XPE will see calls to this.initCause >> from readObject. That wouldn't have happened prior to this change. > > I think this is why super.initCause() (or super.getCause()) must be > called here. If you invoke this.xxx() then you may well be invoking a > subclass specialization and you don't know what it will do. Agree with that, we want to call the specific 'initCause', not the subclass specialization. > >>> About 'super.getCause() == null' check: yes it can be done in such way. >>> In current version I caught the IllegalStateException to correctly >>> process the situation when the cause was already initialized. >> I think you'll always have to catch ISE. If super.getCause is not >> null you know initCause will fail. I would think it would be cheaper >> to null check than to fillStackTrace. But, I haven't tested that. > > I think readObject only needs to account for deserializing an older > version of the exception which will have a non-null local cause, but > Throwable.cause is null. That should be rare. The common case would be > deserializing the new form, in which case initCause would fail. So I > agree with Jason that checking super.getCause() is more efficient than > always calling initCause. Also agree, the ' super.getCause() == null' check added to readObject. > > David > > >> Jason >> Aleksej From Alan.Bateman at oracle.com Sat May 25 11:23:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 May 2013 12:23:49 +0100 Subject: RFR: 7038105 - File.isHidden() should return true for pagefile.sys and hiberfil.sys In-Reply-To: <519FCC64.5040707@oracle.com> References: <51919A9B.4030700@oracle.com> <51921E4C.506@oracle.com> <519F832F.7020205@oracle.com> <519F8BE9.4060404@oracle.com> <519F9A48.6030509@oracle.com> <519F9DF9.90200@oracle.com> <519FCC64.5040707@oracle.com> Message-ID: <51A09F45.3070706@oracle.com> On 24/05/2013 21:24, Rob McKenna wrote: > Will do Alan, thanks. If its ok I'll just do this with the push as > opposed to posting another review. > > -Rob Sure, that's fine, we've done enough rounds on this. -Alan From Alan.Bateman at oracle.com Sat May 25 11:35:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 May 2013 12:35:04 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <51A0A1E8.1000604@oracle.com> On 24/05/2013 19:14, Martin Buchholz wrote: > : > > Alan, you're telling everyone there's no need for Thread.stop, but you > are replacing usages in tests with calls to Unsafe, which is not > available to normal code. So you have a kind of moral obligation here > to replace usages with "ordinary" java code. There are other ways to > do sneakyThrow, and perhaps a sneakyRethrow method should be added to > the jdk test library. For these the tests then it shouldn't really matter but if you or Doug would prefer if they are changed to use sneakyThrow then we can do that. -Alan. From Alan.Bateman at oracle.com Sat May 25 15:22:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 May 2013 16:22:39 +0100 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: References: <519FBDDC.2030806@oracle.com> Message-ID: <51A0D73F.9070908@oracle.com> On 24/05/2013 23:53, Martin Buchholz wrote: > Thanks very much for adding this support. Users will be happy. > > You could make it clearer in the javadoc that you are storing and returning > times in seconds since the epoch, and that the epoch is Jan 1, 1980. > > Note that we now have both kinds of epochs: 1970 and 1980, for extra > confusion. > Also, I guess the zip world doesn't have any kind of year 2038 strategy? > Probably roll over as we get close to 2038 and pray? > > Probably include links to both appnotes, the pkware one and info-zip's > modified version. > I agree, it's good to add this. The package-info already has a link to APPNOTE.TXT and also the Info-ZIP format. However it might be good to at least have ZipEntry.getTime's javadoc mention that the time may be coming from extra block. This would provide coverage for cases where they don't match. -Alan. From Alan.Bateman at oracle.com Sat May 25 15:41:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 May 2013 16:41:50 +0100 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A0784F.8090800@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com> Message-ID: <51A0DBBE.2060501@oracle.com> On 25/05/2013 09:37, Aleksej Efimov wrote: > David, Jason, > Thank you for your comments and suggestions. They all were taken in > account and as a result - the new webrev: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/ I think this looks better. I assume that since the super.getCause() is null that there is no need to handle IllegalStateException now. I think the test could be beefed up to cover the serialization/de-serialization too (since this is new code and doesn't appear to be exercised by other tests). -Alan From scolebourne at joda.org Sat May 25 22:50:58 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 25 May 2013 23:50:58 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <51A0A1E8.1000604@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> <51A0A1E8.1000604@oracle.com> Message-ID: I'd humbly suggest that a sneakyThrow would be a very desirable addition to the public JDK API. Stephen On 25 May 2013 12:35, Alan Bateman wrote: > On 24/05/2013 19:14, Martin Buchholz wrote: >> >> : >> >> Alan, you're telling everyone there's no need for Thread.stop, but you are >> replacing usages in tests with calls to Unsafe, which is not available to >> normal code. So you have a kind of moral obligation here to replace usages >> with "ordinary" java code. There are other ways to do sneakyThrow, and >> perhaps a sneakyRethrow method should be added to the jdk test library. > > For these the tests then it shouldn't really matter but if you or Doug would > prefer if they are changed to use sneakyThrow then we can do that. > > -Alan. From peter.levart at gmail.com Sun May 26 11:02:15 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 26 May 2013 13:02:15 +0200 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519E67AF.7090504@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> Message-ID: <51A1EBB7.4020200@gmail.com> On 05/23/2013 09:02 PM, Brent Christian wrote: > On 5/23/13 5:20 AM, Doug Lea wrote: >> * Given that balanced trees are not used in WeakHashMap >> or Hashtable, I wonder why the TreeNode etc classes are >> not just nested inside HashMap (usable from subclass LinkedHashMap). >> And if so, it would be simpler, faster, and less code-intensive >> to declare TreeNode as a subclass of the internal Entry class. >> Plus some further gymnastics to overcome the unfortunate >> decision to make LinkedHashMap a subclass of HashMap. >> Had you considered this? > > I definitely did. I wanted a cleaner class hierarchy for > Entry/TreeNode, but LinkedHashMap makes it difficult, since its > Entries need extra before/after references. > > I couldn't work out a TreeNode class that could be used by both > HashMap and LinkedHashMap, since LHM would need a TreeNode derived > from LinkedHashMap.Entry, not HashMap.Entry. > > So instead I used composition, where TreeNode has-a > [Linked]HashMap.Entry. Hi Brent, It's unfortunate, because composition increases memory footprint. Here's my attempt at merging HashMap.Entry with TreeNode into same object: http://cr.openjdk.java.net/~plevart/jdk8-tl/HM.balancedTrees/merge_TreeNode_and_HashMap_Entry_into_same_object.patch ...this is a patch against your webrev. Diamond inheritance is solved by making LinkedHashMap.Entry an interface and exposing get/set[Before,After] methods instead of before/after fields. The hierarchy is as follows: class HashMap.Entry implements Map.Entry class TreeNode extends HashMap.Entry interface LinkedHashMap.Entry extends Map.Entry class LinkedHashMap.EntryImpl implements LinkedHashMap.Entry class LinkedHashMap.LinkedTreeNode extends TreeNode implements LinkedHashMap.Entry I also added two factory methods to HashMap which are overriden in LinkedHashMap for constructing TreeNode/LinkedHashMap.LinkedTreeNode objects. The TreeNode still contains the final 'entry' field, which is initialized to 'this' because there are a lot of references to it. These would have to be replaced in code, but would make the patch much larger and more difficult to grasp, so I left this exercise for later. So what do you think? I know that with this patch, the access to before/after links in LinkedHashMap.Entry is not direct field access any more and goes through invokeinterface and can therefore be slower, because there are two implementing classes (LHM.EntryImpl and LHM.LinkedTreeNode). But on the other hand, the space savings can be noticeable if lots of buckets are transformed into TreeBins... Regards, Peter From kustos at gmx.net Sun May 26 11:04:34 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 26 May 2013 13:04:34 +0200 Subject: AutoCloseable XMLStreamReader and XMLStreamWriter? Message-ID: <51A1EC42.1000407@gmx.net> Hi It would be nice if javax.xml.stream.XMLStreamReader and javax.xml.stream.XMLStreamWriter could be made to extend java.lang.AutoCloseable so that they can be used in a try-with-resouces statement. The some does for XMLEventReader and XMLEventReader. I'm not sure this is the right mailing list. I already sent a mail to users at sjsxp.java.net but it seems to be dead. Cheers Philippe From kustos at gmx.net Sun May 26 11:22:37 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 26 May 2013 13:22:37 +0200 Subject: ConcurrentMap.putIfAbsent(Object, Supplier)? Message-ID: <51A1F07D.3030602@gmx.net> Hi I often find myself writing code like this: ConcurrentMap map = ...; Object value = map.get(key); if (value == null) { Object newValue = expensiveComputation(); Object previous = map.putIfAbsent(key, newValue); if (previous != null) { value = previous; } else { value = newValue; } } return value; This is quite error prone and tedious. If we had a method: V putIfAbsent(K key, Supplier Supplier) it could be replaced with return map.get(key, () -> expensiveComputation()); It could even be implemented with a default method assuming null values aren't allowed which is the same as for the new #getOrDefault default method. Cheers Philippe From peter.levart at gmail.com Sun May 26 11:25:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 26 May 2013 13:25:34 +0200 Subject: ConcurrentMap.putIfAbsent(Object, Supplier)? In-Reply-To: <51A1F07D.3030602@gmx.net> References: <51A1F07D.3030602@gmx.net> Message-ID: <51A1F12E.70806@gmail.com> Hi Philippe, I think you are looking for Map.computeIfAbsent(K, Supplier) which was added to Map interface recently. Regards, Peter On 05/26/2013 01:22 PM, Philippe Marschall wrote: > Hi > > I often find myself writing code like this: > > ConcurrentMap map = ...; > Object value = map.get(key); > if (value == null) { > Object newValue = expensiveComputation(); > Object previous = map.putIfAbsent(key, newValue); > if (previous != null) { > value = previous; > } else { > value = newValue; > } > } > return value; > > This is quite error prone and tedious. If we had a method: > > V putIfAbsent(K key, Supplier Supplier) > > it could be replaced with > > return map.get(key, () -> expensiveComputation()); > > It could even be implemented with a default method assuming null > values aren't allowed which is the same as for the new #getOrDefault > default method. > > Cheers > Philippe From kustos at gmx.net Sun May 26 11:30:51 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 26 May 2013 13:30:51 +0200 Subject: ConcurrentMap.putIfAbsent(Object, Supplier)? In-Reply-To: <51A1F12E.70806@gmail.com> References: <51A1F07D.3030602@gmx.net> <51A1F12E.70806@gmail.com> Message-ID: <51A1F26B.7040705@gmx.net> On 26.05.2013 13:25, Peter Levart wrote: > Hi Philippe, > > I think you are looking for Map.computeIfAbsent(K, Supplier) which was > added to Map interface recently. Yes I am, thanks. Philippe From dl at cs.oswego.edu Sun May 26 11:34:04 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 26 May 2013 07:34:04 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A1EBB7.4020200@gmail.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A1EBB7.4020200@gmail.com> Message-ID: <51A1F32C.9070503@cs.oswego.edu> On 05/26/13 07:02, Peter Levart wrote: >> >> I couldn't work out a TreeNode class that could be used by both HashMap and >> LinkedHashMap, since LHM would need a TreeNode derived from >> LinkedHashMap.Entry, not HashMap.Entry. >> >> So instead I used composition, where TreeNode has-a [Linked]HashMap.Entry. > > Hi Brent, > > It's unfortunate, because composition increases memory footprint. Here's my > attempt at merging HashMap.Entry with TreeNode into same object: > I had a similar thought: Even if you waste space for the before/after links in TreeNode, you come out ahead, and don't penalize LinkedHashMap as much. I'm in the midst of exploring this. Another alternative that arises each time deep HashMap surgery is contemplated is that you can almost completely ignore the HashMap implementation inside LinkedHashMap, which is likely to speed both up at the price of more code. -Doug From peter.levart at gmail.com Sun May 26 12:08:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 26 May 2013 14:08:12 +0200 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A1F32C.9070503@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A1EBB7.4020200@gmail.com> <51A1F32C.9070503@cs.oswego.edu> Message-ID: <51A1FB2C.2050905@gmail.com> On 05/26/2013 01:34 PM, Doug Lea wrote: > On 05/26/13 07:02, Peter Levart wrote: > >>> >>> I couldn't work out a TreeNode class that could be used by both >>> HashMap and >>> LinkedHashMap, since LHM would need a TreeNode derived from >>> LinkedHashMap.Entry, not HashMap.Entry. >>> >>> So instead I used composition, where TreeNode has-a >>> [Linked]HashMap.Entry. >> >> Hi Brent, >> >> It's unfortunate, because composition increases memory footprint. >> Here's my >> attempt at merging HashMap.Entry with TreeNode into same object: >> > > I had a similar thought: Even if you waste space for the > before/after links in TreeNode, you come out ahead, > and don't penalize LinkedHashMap as much. I'm in the midst > of exploring this. Hi Doug, Clever idea. So your common TreeNode would extend LinkedHashMap.Entry. > > Another alternative that arises each time deep HashMap > surgery is contemplated is that you can almost completely ignore the > HashMap implementation inside LinkedHashMap, which is > likely to speed both up at the price of more code. > > -Doug > That would certainly be the fastest and most optimal approach, but the price? Regards, Peter From dl at cs.oswego.edu Sun May 26 12:46:47 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 26 May 2013 08:46:47 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A1FB2C.2050905@gmail.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A1EBB7.4020200@gmail.com> <51A1F32C.9070503@cs.oswego.edu> <51A1FB2C.2050905@gmail.com> Message-ID: <51A20437.8030504@cs.oswego.edu> On 05/26/13 08:08, Peter Levart wrote: > Clever idea. So your common TreeNode would extend LinkedHashMap.Entry. Right. (Or renamings/refactorings of these). And that begets other improvements in part by guaranteeing root is first node of bin, so doesn't need TreeBins (which I cannot do in CHM because links are pinned.) So far, I haven't gotten this to the point of realistically comparing performance etc, and wasn't going to post until I did, but then figured I'd save you some effort. >> >> Another alternative that arises each time deep HashMap >> surgery is contemplated is that you can almost completely ignore the >> HashMap implementation inside LinkedHashMap, which is >> likely to speed both up at the price of more code. It might be close. There's a bunch of code in HashMap that exists solely to support LinkedhashMap hooks, that would go away. -Doug From david.holmes at oracle.com Mon May 27 02:57:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 12:57:49 +1000 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A0DBBE.2060501@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com> <51A0DBBE.2060501@oracle.com> Message-ID: <51A2CBAD.7000307@oracle.com> On 26/05/2013 1:41 AM, Alan Bateman wrote: > On 25/05/2013 09:37, Aleksej Efimov wrote: >> David, Jason, >> Thank you for your comments and suggestions. They all were taken in >> account and as a result - the new webrev: >> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/ > I think this looks better. I assume that since the super.getCause() is > null that there is no need to handle IllegalStateException now. I would agree on both counts. David > I think the test could be beefed up to cover the > serialization/de-serialization too (since this is new code and doesn't > appear to be exercised by other tests). > > -Alan From david.holmes at oracle.com Mon May 27 03:03:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 13:03:05 +1000 Subject: RFR JDK-8015299 In-Reply-To: References: <519F8168.7000505@oracle.com> Message-ID: <51A2CCE9.9070406@oracle.com> I concur with Martin on all counts. Confusing NUL and NULL is also a pet peeve of mine :) David On 25/05/2013 2:15 AM, Martin Buchholz wrote: > Hi John, > > The memory leak fix looks good. > --- > IIRC I was the author of the comment, so it is not surprising that I might > prefer that version. "nul" is ___not___ a typo for NULL. It makes no > sense to speak of character arrays being NULL-terminated. It also isn't > quite right to say that readlink "generates" an array - it simply writes > into one. > > However, it is more correct to spell "nul" "NUL" as in ASCII(7). > > If you wanted to be more precise about which readlink, you could write > readlink(2) instead of readlink() to disambiguate from readlink(1) > > > On Fri, May 24, 2013 at 8:04 AM, John Zavgren wrote: > >> Greetings: >> >> I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** >> solinux.c >> and I posted a webrev image of the changes at: >> http://cr.openjdk.java.net/~**jzavgren/8015299/webrev.01/< >> http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/ >>> >> >> (I also edited a comment.) >> >> Thanks! >> John >> >> -- >> John Zavgren >> john.zavgren at oracle.com >> 603-821-0904 >> US-Burlington-MA >> >> From david.holmes at oracle.com Mon May 27 03:38:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 13:38:52 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> Message-ID: <51A2D54C.2030602@oracle.com> On 25/05/2013 4:14 AM, Martin Buchholz wrote: > On Fri, May 24, 2013 at 6:18 AM, Alan Bateman wrote: > >> >> The webrev with the proposed changes is here. As I mentioned in one of the >> replies, there are 4 j.u.c tests that need to be updated so I've changed >> these tests to use Unsafe.throwException. >> > > Alan, you're telling everyone there's no need for Thread.stop, but you are > replacing usages in tests with calls to Unsafe, which is not available to > normal code. So you have a kind of moral obligation here to replace usages > with "ordinary" java code. There are other ways to do sneakyThrow, and > perhaps a sneakyRethrow method should be added to the jdk test library. I disagree. The tests are using stop(x) as a means of fault injection, to simulate something that is "impossible" in correctly written Java code. Now because there are nasty ways to do the "impossible" the test simulated them to see if the code under test was robust. I think that is going above and beyond what the test needed to do. So I find it non-sensical to say that we have to have a Java way of throwing checked exceptions in a way that is impossible in the Java programming language. > Ordinary java code should be able to simply catch and rethrow a Throwable > if type analysis can "prove" that the exception is not an Exception. > > As a data point, Doug uses this: > > (Doug, it's not obvious to me why you handle Error and RuntimeException > specially) > > /** > * A version of "sneaky throw" to relay exceptions > */ > static void rethrow(final Throwable ex) { > if (ex != null) { > if (ex instanceof Error) > throw (Error)ex; > if (ex instanceof RuntimeException) > throw (RuntimeException)ex; > ForkJoinTask.uncheckedThrow(ex); > } > } This is a variation of the rethrow() method "we" have been using since 1996 at least - and the more precise exception typing we have in Java 7 should remove the need to handle Error and RuntimeException this way - we should be able to catch as part of multi-catch and re-throw directly. > /** > * The sneaky part of sneaky throw, relying on generics > * limitations to evade compiler complaints about rethrowing > * unchecked exceptions > */ > @SuppressWarnings("unchecked") static > void uncheckedThrow(Throwable t) throws T { > if (t != null) > throw (T)t; // rely on vacuous cast > } That truly is sneaky. I hadn't realized we had stooped this low ;-) Not 100% sure why this works though. I'd call that a javac bug. David ----- From david.holmes at oracle.com Mon May 27 04:38:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 14:38:54 +1000 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> Message-ID: <51A2E35E.4090308@oracle.com> Hi David, On 24/05/2013 2:06 AM, David Chase wrote: > So where do we stand on this? > Can we call it a bug and eligible for inclusion? > And are there other issues to deal with? I think this form of the optimization is more amenable to inclusion. > I would be happy to discuss exactly what is going on in the mysterious > intrinsic-ful code, if that is an issue for anyone (and sooner is better than > later, else I'll forget the exciting details). I'm not going to attempt to understand any of the details of this. That said I still have an issue with this code: 147 if (buf) { 148 /* Don't know for sure how big an unsigned long is, therefore 149 copy one at a time. */ 150 int i; 151 for (i = 0; i < 256; i++) buf[i] = (jint) (crc_table[i]); 152 (*env)->ReleasePrimitiveArrayCritical(env, b, buf, 0); 153 } buf is an array of 32-bit values; crc_table is either 32-bit or 64-bit depending on platform. So on 64-bit we are truncating all the values in crc_table. So presumably these values all fit in 32-bits anyway? Minor nit: src/share/classes/java/util/zip/CRC32.java + import java.lang.reflect.Field; I don't think this import is needed now. --- test/java/util/zip/TimeChecksum.java You added eg: time(adler32, data, 2*iters, 16); // warmup short case, too which is presumably to ensure both of the primary paths are hit during the warm up. But it isn't obvious to me that the actual test will hit the short case ?? Thanks, David > David > > On 2013-05-21, at 5:15 PM, David Chase wrote: > >> >> http://cr.openjdk.java.net/~drchase/7088419/webrev.03/ >> >> Newer, slimmer webrev. No fork/join, the related code is removed (except the >> native init routine still returns a boolean, which is currently ignored, indicating if >> it supports the faster crc32). >> >> What remains is: >> >> 1) no-JNI fast-path for short CRCs and Adlers >> 2) reformulated faster-Adler for byte-at-a-time >> 3) For 32/64 Linux/Solaris/MacOS x86 Sandy Bridge or better (with CLMUL and AVX), >> fast code for CRCs. >> >> For now it uses assembly language, the C-with-intrinsics is included, and compiles >> with current clang and gcc. It tickles a bug in Solaris Studio 12.3 which has been reported. >> Optimization for Windows is disabled because the assembler syntax is too different >> >> The code has been tested by-hand across Linux (32), Solaris (32 and 64), MacOS (64) >> and has also passed JPRT (which is to say, the failures were unrelated, hand examination >> of the runs showed that the new CRCandAdler test was successful. Anyone checking my >> most recent run will notice that I am not very good at specifying tests to run, but there is >> an earlier run. I'm trying again, just to see if I can figure out how to make it behave.) >> >> There is a companion webrev on the hotspot side that sets the secret property >> that is used and reset by this code. >> >> I hope this will be more easily regarded as a "bug fix" and less as an interface change. >> >> David >> >> On 2013-05-20, at 8:34 PM, David Holmes wrote: >> >>> On 21/05/2013 3:45 AM, Alan Bateman wrote: >>>> On 20/05/2013 14:49, David Chase wrote: >>>>> Suppose I split this bug (i.e., file a new bug) into the >>>>> Intel-acceleration part and the fork-join part. >>>>> : >>>>> >>>> This make sense. >>> >>> I agree. >>> >>> I also don't have an issue with eliding the optimization on Windows for the time being. >>> >>> David >>> >>>> -Alan. >> > From david.holmes at oracle.com Mon May 27 07:10:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 17:10:07 +1000 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <519F9186.8040000@oracle.com> References: <519F9186.8040000@oracle.com> Message-ID: <51A306CF.9070605@oracle.com> Hi Chris, I'm adding this to the top because now I've gone through it I have to say that this really needs to be broken up. We have everything from trivial doc punctuation fixes, through significant performance enhancements, to streamification of various classes - with some actual bugs fixed inbetween! There have to be some existing CRs that cover some of this. :( A few more comments below. On 25/05/2013 2:12 AM, Chris Hegarty wrote: > The final outstanding task from JEP 155 is to add CHMv8, and update the > remainder of the j.u.c implementation, add spliterator implementation > for concurrent collections, etc > > 8004138: Resync java.util.concurrent classes with Dougs CVS - 05/2013 > 8005704: Update ConcurrentHashMap to v8 > > specdiff: > http://cr.openjdk.java.net/~chegar/8004138/ver.00/specdiff/java/util/concurrent/package-summary.html BlockingDeque has a spec update that is not part of your specdiff. Have all spec clarifications gone through CCC? Have all new API's gone through CCC? (Or flagged to go through - eg Executors.newWorkStealingPool ?) > webrev > http://cr.openjdk.java.net/~chegar/8004138/ver.00/webrev/ As Mike said a lot to look at. And thanks Mike for filtering the @code changes :) I agree with Mike that it is a shame to see reversion to old-style code (loops versus iterators) because of performance issues. :( I also find the seemingly gratuitous text reformatting to be somewhat inconvenient in a review of this size. Simple reformatting should be done as a separate item where we can show that despite the change to the source files, there is actually no change to the corresponding specification. As it stands there's no easy way to see if a 'changed' block of text has actually been changed. :( > As per usual all changes are coming from Doug, and others. Most of the > changes have been baking in the lambda repo for some time now. So has the spec for the streamification of CHM been discussed elsewhere? This seems like something that should be part of the lambda work and I don't recall seeing it. Has the terminology been checked for consistency against java.util.stream package docs? I don't see any links from CHM to those docs, and I think there should be. And I see the reduction operation being named "reducer" when the chosen nomenclature was "accumulator". I also question the ConcurrentMap change regarding getOrDefault. I don't know if its removal is accidental or intentional. As ConcurrentMap does not require "no nulls allowed" I'm uncertain about the validity of a default that will only work in that case. Aside: the indentation of the doc-comment block for Map.getOrDefault is wrong. (Not caused by this changeset.) FutureTask.java: the indentation of the changed code is all wrong. atomic/package-info.java: the URL updates (to oracle.com) have been regressed to java.sun.com :( > I'm not expecting an in dept review per say. All regression tests and > JCK will be run. I guess the main focus should be on the new CHM API's There are a number of new APIs and they should be reviewed separately in my opinion. David ----- > -Chris. From sundararajan.athijegannathan at oracle.com Mon May 27 08:21:17 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 27 May 2013 08:21:17 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20130527082121.4BF8A48D51@hg.openjdk.java.net> Changeset: 6fc7b51e83d6 Author: lagergren Date: 2013-05-23 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6fc7b51e83d6 8012522: Clean up lexical contexts - split out stack based functionality in CodeGenerator and generify NodeVisitors based on their LexicalContext type to avoid casts Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.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/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.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/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.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/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.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/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/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/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/DebugLogger.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 Changeset: fdfb4edd78d6 Author: hannesw Date: 2013-05-24 13:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fdfb4edd78d6 8011630: JSON parsing performance issue Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java Changeset: 4d2eca4d4d66 Author: sundar Date: 2013-05-24 18:39 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4d2eca4d4d66 8015354: JSON.parse should not use [[Put]] but use [[DefineOwnProperty]] instead Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Property.java + test/script/basic/JDK-8015354.js Changeset: 751cfefff5eb Author: sundar Date: 2013-05-24 23:27 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/751cfefff5eb 8015351: Nashorn shell does not start with Turkish locale Reviewed-by: jlaskey ! make/project.properties ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java From Alan.Bateman at oracle.com Mon May 27 08:40:40 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 May 2013 09:40:40 +0100 Subject: AutoCloseable XMLStreamReader and XMLStreamWriter? In-Reply-To: <51A1EC42.1000407@gmx.net> References: <51A1EC42.1000407@gmx.net> Message-ID: <51A31C08.5000909@oracle.com> On 26/05/2013 12:04, Philippe Marschall wrote: > Hi > > It would be nice if javax.xml.stream.XMLStreamReader and > javax.xml.stream.XMLStreamWriter could be made to extend > java.lang.AutoCloseable so that they can be used in a > try-with-resouces statement. The some does for XMLEventReader and > XMLEventReader. I don't recall if this one has come up before (there were lots of candidates identified for retrofitting when AutoCloseable was added) but the XML APIs have the complication that they are a "Standalone Technology". I don't know how far back JSR-206/173 needs to be support but if you retrofit these interfaces to extend AutoCloseable then it would rule out usage with jdk6. Joe Wang might know about about this. -Alan From chris.hegarty at oracle.com Mon May 27 08:50:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 27 May 2013 09:50:00 +0100 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <51A306CF.9070605@oracle.com> References: <519F9186.8040000@oracle.com> <51A306CF.9070605@oracle.com> Message-ID: <51A31E38.6050704@oracle.com> Mike, David, Given your feedback I'll slice'n'dice, where appropriate, and try to make this more manageable for review. I'll follow up with separate review emails, taking into account your comments. -Chris. On 27/05/2013 08:10, David Holmes wrote: > Hi Chris, > > I'm adding this to the top because now I've gone through it I have to > say that this really needs to be broken up. We have everything from > trivial doc punctuation fixes, through significant performance > enhancements, to streamification of various classes - with some actual > bugs fixed inbetween! There have to be some existing CRs that cover some > of this. :( > > A few more comments below. > > On 25/05/2013 2:12 AM, Chris Hegarty wrote: >> The final outstanding task from JEP 155 is to add CHMv8, and update the >> remainder of the j.u.c implementation, add spliterator implementation >> for concurrent collections, etc >> >> 8004138: Resync java.util.concurrent classes with Dougs CVS - 05/2013 >> 8005704: Update ConcurrentHashMap to v8 >> >> specdiff: >> http://cr.openjdk.java.net/~chegar/8004138/ver.00/specdiff/java/util/concurrent/package-summary.html >> > > BlockingDeque has a spec update that is not part of your specdiff. > > Have all spec clarifications gone through CCC? > > Have all new API's gone through CCC? (Or flagged to go through - eg > Executors.newWorkStealingPool ?) > >> webrev >> http://cr.openjdk.java.net/~chegar/8004138/ver.00/webrev/ > > As Mike said a lot to look at. And thanks Mike for filtering the @code > changes :) > > I agree with Mike that it is a shame to see reversion to old-style code > (loops versus iterators) because of performance issues. :( > > I also find the seemingly gratuitous text reformatting to be somewhat > inconvenient in a review of this size. Simple reformatting should be > done as a separate item where we can show that despite the change to the > source files, there is actually no change to the corresponding > specification. As it stands there's no easy way to see if a 'changed' > block of text has actually been changed. :( > >> As per usual all changes are coming from Doug, and others. Most of the >> changes have been baking in the lambda repo for some time now. > > So has the spec for the streamification of CHM been discussed elsewhere? > This seems like something that should be part of the lambda work and I > don't recall seeing it. Has the terminology been checked for consistency > against java.util.stream package docs? I don't see any links from CHM to > those docs, and I think there should be. And I see the reduction > operation being named "reducer" when the chosen nomenclature was > "accumulator". > > I also question the ConcurrentMap change regarding getOrDefault. I don't > know if its removal is accidental or intentional. As ConcurrentMap does > not require "no nulls allowed" I'm uncertain about the validity of a > default that will only work in that case. > > Aside: the indentation of the doc-comment block for Map.getOrDefault is > wrong. (Not caused by this changeset.) > > FutureTask.java: the indentation of the changed code is all wrong. > > atomic/package-info.java: the URL updates (to oracle.com) have been > regressed to java.sun.com :( > >> I'm not expecting an in dept review per say. All regression tests and >> JCK will be run. I guess the main focus should be on the new CHM API's > > There are a number of new APIs and they should be reviewed separately in > my opinion. > > David > ----- > >> -Chris. From Alan.Bateman at oracle.com Mon May 27 08:57:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 May 2013 09:57:21 +0100 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A20437.8030504@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A1EBB7.4020200@gmail.com> <51A1F32C.9070503@cs.oswego.edu> <51A1FB2C.2050905@gmail.com> <51A20437.8030504@cs.oswego.edu> Message-ID: <51A31FF1.7020206@oracle.com> On 26/05/2013 13:46, Doug Lea wrote: > On 05/26/13 08:08, Peter Levart wrote: >> Clever idea. So your common TreeNode would extend LinkedHashMap.Entry. > > Right. (Or renamings/refactorings of these). > And that begets other improvements in part by guaranteeing root > is first node of bin, so doesn't need TreeBins (which I cannot do in > CHM because links are pinned.) So far, I haven't gotten > this to the point of realistically comparing performance etc, > and wasn't going to post until I did, but then figured I'd > save you some effort. > Any objection if we move ahead with what Brent has now, at least as first step? There are are other follow-on changes, the removal of String hash32 field/method particular, that we are anxious to get in. -Alan From alexey.utkin at oracle.com Mon May 27 11:26:54 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Mon, 27 May 2013 11:26:54 +0000 Subject: hg: jdk8/tl/jdk: 8014394: (fs) WatchService failing when watching \\server\$d Message-ID: <20130527112721.034A448D58@hg.openjdk.java.net> Changeset: d78f91ab0e96 Author: uta Date: 2013-05-27 15:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d78f91ab0e96 8014394: (fs) WatchService failing when watching \\server\$d Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c From david.holmes at oracle.com Mon May 27 11:34:19 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 27 May 2013 11:34:19 +0000 Subject: hg: jdk8/tl/jdk: 7038914: VM could throw uncaught OOME in ReferenceHandler thread Message-ID: <20130527113433.001D348D5A@hg.openjdk.java.net> Changeset: 0b8dab7fec54 Author: plevart Date: 2013-05-27 09:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b8dab7fec54 7038914: VM could throw uncaught OOME in ReferenceHandler thread Summary: Catch OutOfMemoryError in reference handler thread if caused by allocation of an InterruptedException Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ref/Reference.java + test/java/lang/ref/OOMEInReferenceHandler.java From dl at cs.oswego.edu Mon May 27 11:41:35 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 27 May 2013 07:41:35 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A31FF1.7020206@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A1EBB7.4020200@gmail.com> <51A1F32C.9070503@cs.oswego.edu> <51A1FB2C.2050905@gmail.com> <51A20437.8030504@cs.oswego.edu> <51A31FF1.7020206@oracle.com> Message-ID: <51A3466F.4060708@cs.oswego.edu> On 05/27/13 04:57, Alan Bateman wrote: > Any objection if we move ahead with what Brent has now, at least as first step? > There are are other follow-on changes, the removal of String hash32 field/method > particular, that we are anxious to get in. > Yes, please do. In which case, here's a problem that needs fixing in the current version: The splitTreeBin method can only handle doubling of tables. But it is possible from current HashMap.putAll to skip a doubling step. This almost never happens in practice, but must be avoided by replacing (HashMap.java, approx line 700): if (numKeysToBeAdded > threshold) { int targetCapacity = (int)(numKeysToBeAdded / loadFactor + 1); if (targetCapacity > MAXIMUM_CAPACITY) targetCapacity = MAXIMUM_CAPACITY; int newCapacity = table.length; while (newCapacity < targetCapacity) newCapacity <<= 1; if (newCapacity > table.length) resize(newCapacity); } with: if (numKeysToBeAdded > threshold && table.length < MAXIMUM_CAPACITY) resize(table.length * 2); From aleksey.shipilev at oracle.com Mon May 27 12:44:32 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 27 May 2013 16:44:32 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <519EAD3C.7080803@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> Message-ID: <51A35530.7010404@oracle.com> Thanks! Let's try to re-phrase this as follows (don't mind Javadoc formatting glitches, I'll fix them in the upcoming webrev): --------- 8< ---------------------------------------------------------- /* An annotation expressing that objects and/or their fields are expected to encounter memory contention, generally in the form of "false sharing". This annotation serves as a hint that such objects and fields should reside in locations isolated from those of other objects or fields. Susceptibility to memory contention is a property of the intended usages of objects and fields, not their types or qualifiers. The effects of this annotation will nearly always add significant space overhead to objects. The use of {@code @Contended} is warranted only when the performance impact of this time/space tradeoff is intrinsically worthwhile; for example, in concurrent contexts in which each instance of the annotated object is often accessed by a different thread. A {@code @Contended} field annotation may optionally include a contention group tag. All fields with the same tag are considered as a group with respect to isolation from other groups. A default tag indicates the distinct and anonymous contention group, which implies the contention with all other fields, including all other {@code @Contended} ones. The tag at a class level is meaningless, and ignored. When the annotation is used at the class level, the effect is roughly equivalent to placing the {@code @Contended} annotation with the same anonymous tag over all the unannotated fields of the object. With the class level annotation, the implementations may choose different approach to protect the entire object, rather than protecting only the distinct fields. The {@code @Contended} annotation is not inherited, and acts only within the class it was used on. The effects, however, should be enforced across the inheritance, e.g. the {@code @Contended} fields should be isolated from all the fields in super- and sub-classes. The contention group tags are not inherited as well: the similar tags in two subclasses mean different groups. @since 1.8 */ @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE}) public @interface Contended { /** * The (optional) contention group tag. * This tag is only meaningful for the field-level annotations. */ String value() default ""; } --------- 8< ---------------------------------------------------------- On 05/24/2013 03:58 AM, David Holmes wrote: > 2. I think something needs to be said about this property and inheritance. Added. > 3. I think this: > > The (optional) contention group tag > > should be > > The (optional) field contention group tag This sounds awkward? Would it be better to note it is only meaningful on the fields? > and we should also say in the main paragraph that a tag at the class > level is ignored. Added. > 4. I'm a little unclear about the group tags. It states: > > "A default annotation without a tag indicates contention with all other > fields, including other {@code @Contended} ones." I think this is would be easier to digest if we introduce the concept of anonymous group, see the new text. > That seems to imply that given: > > class A { > @Contended Object a1; > @Contended Object a2; > } > > then a1 and a2 are in different contention groups. ??? Yes, these are different contention groups. > Yet I would expect the default annotation value to simply imply a > single un-named contention group. That's an interesting interpretation. I guess we should stress it is the other way around: the tag-less @C always creates distinct anonymous group, and you can merge two @C with supplying the tag. > Just as the annotation at the class level implies a > single un-named group for all unannotated fields. But does that also > imply that given: > > @Contended > class A { > @Contended Object a1; > Object a2; > } > > there are two un-named contention groups? Yes, that follows from the definition of class-level @C; your example effectively means putting all the _unannotated_ fields in the same anonymous group, i.e.: @Contended class A { @Contended Object a1; Object a2; Object a3; } ...means: class A { @Contended() Object a1; @Contended() Object a2; @Contended() Object a3; } > I'm not sure that anyone without knowledge of the implementation will be > able to use contention groups effectively. Even though this is an internal API, we would like to churn all the major things with the understandable Javadoc, hence this thread. -Aleksey. From vicente.romero at oracle.com Mon May 27 12:44:46 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 27 May 2013 12:44:46 +0000 Subject: hg: jdk8/tl/langtools: 7030476: Fix conflicting use of JCTree/JCExpression Message-ID: <20130527124449.5A3AB48D5F@hg.openjdk.java.net> Changeset: b391ecea538e Author: vromero Date: 2013-05-27 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b391ecea538e 7030476: Fix conflicting use of JCTree/JCExpression Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java From dl at cs.oswego.edu Mon May 27 13:05:32 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 27 May 2013 09:05:32 -0400 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> References: <519F9186.8040000@oracle.com> <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> Message-ID: <51A35A1C.4060108@cs.oswego.edu> On 05/24/13 23:17, Mike Duigou wrote: > There's an awful lot here! (It's been a long time since jdk7 :-) > > - It was surprising (and somewhat disappointing) to see changes like the following in various places. Is iterator creation that expensive? I'd hate to have to go back to using old style for loops everywhere. > > - List> futures = new ArrayList>(tasks.size()); > + ArrayList> futures = new ArrayList>(tasks.size()); > Are you suggesting that we not improve performance? :-) Waiting a decade in wishful-thinking mode about ArrayList traversal seems long enough. (Aside: We addressed this in stream Spliterators to the extent possible at library level. ArrayList.forEach of a fully resolved non-capturing lambda is around twice as fast as iterators.) > > - The default for getOrDefault() in ConcurrentMap shouldn't be removed. > > - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not normally order preserving. > Thanks! Both the results of my not rechecking vs lambda versions (where a lot of this code has been running for a while now). Hopefully no other three-way diffs of jsr166, lambda, tl fell between cracks. -Doug From david.r.chase at oracle.com Mon May 27 13:27:49 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 27 May 2013 09:27:49 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51A2E35E.4090308@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> Message-ID: <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> On 2013-05-27, at 12:38 AM, David Holmes wrote: > Hi David, > That said I still have an issue with this code: > > 147 if (buf) { > 148 /* Don't know for sure how big an unsigned long is, therefore > 149 copy one at a time. */ > 150 int i; > 151 for (i = 0; i < 256; i++) buf[i] = (jint) (crc_table[i]); > 152 (*env)->ReleasePrimitiveArrayCritical(env, b, buf, 0); > 153 } > > buf is an array of 32-bit values; crc_table is either 32-bit or 64-bit depending on platform. So on 64-bit we are truncating all the values in crc_table. So presumably these values all fit in 32-bits anyway? They are guaranteed to. They are residues modulo a 33-bit polynomial -- i.e., bits beyond the 32nd are zero. I'm a little surprised that the CRC32 implementation does not use a uint32_t for them, because not doing this makes their tables (they have 4 for a different optimization) take 8k instead of 4k, at least on LP64 platforms. > Minor nit: > > src/share/classes/java/util/zip/CRC32.java > > + import java.lang.reflect.Field; > > I don't think this import is needed now. Agreed, this is leftover from the old way of getting Unsafe, but the Unsafe code is gone anyway. > --- > > test/java/util/zip/TimeChecksum.java > > You added eg: > > time(adler32, data, 2*iters, 16); // warmup short case, too > > which is presumably to ensure both of the primary paths are hit during the warm up. But it isn't obvious to me that the actual test will hit the short case ?? It certainly did hit the short case. I ran that test, and noticed a significant difference before/after my initial patch, and then back again after I fixed the test. "The short case" is fewer than (if I recall) 80 bytes of CRC or Adler; there, it is quicker to do the calculation in Java rather than paying the JNI call overhead to get to the slightly faster C implementation. Here, seeing is believing (oh, but look, I trashed the output format on the warmup, I should fix that): FIRST, WITH SHORT WARMUP: dr2chase:zip $ $BB/java TimeChecksum ---------- Adler32 ---------- Warmup... 8 1,312 3 4 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 2,000 4,000 (2.00) 8,000 (4.00) checksum=cd00cd 2 2,000 1,500 (0.75) 2,000 (1.00) checksum=1b500e8 4 500 750 (1.50) 750 (1.50) checksum=50e0223 8 250 250 (1.00) 375 (1.50) checksum=148d0475 16 562 312 (0.56) 312 (0.56) checksum=4999083b ... ---------- CRC32 ---------- Warmup... 6 1,250 3 4 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 3,000 3,000 (1.00) 6,000 (2.00) checksum=40d06116 2 1,500 1,500 (1.00) 3,000 (2.00) checksum=acf34351 4 500 750 (1.50) 1,250 (2.50) checksum=bded3e7d 8 375 375 (1.00) 625 (1.67) checksum=699af2a3 16 187 250 (1.33) 312 (1.67) checksum=44ff2ea ... NEXT, WITH SHORT WARMUP REMOVED: dr2chase:zip $ $BB/java TimeChecksum ---------- Adler32 ---------- Warmup... 5 4 3 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 22,000 5,000 (0.23) 7,000 (0.32) checksum=5f005f 2 1,500 1,500 (1.00) 3,000 (2.00) checksum=cd006e 4 500 500 (1.00) 1,250 (2.50) checksum=2860149 8 375 375 (1.00) 500 (1.33) checksum=fa90433 16 312 250 (0.80) 312 (1.00) checksum=45e80933 ... ---------- CRC32 ---------- Warmup... 6 3 4 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 24,000 3,000 (0.13) 4,000 (0.17) checksum=5ed1937e 2 1,500 1,000 (0.67) 2,000 (1.33) checksum=f55e7fb4 4 750 750 (1.00) 1,000 (1.33) checksum=ccf3e842 8 250 375 (1.50) 625 (2.50) checksum=802801ba 16 250 187 (0.75) 250 (1.00) checksum=836ef44b ... David From chris.hegarty at oracle.com Mon May 27 14:26:11 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 27 May 2013 14:26:11 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130527142657.20B0548D61@hg.openjdk.java.net> Changeset: a2dc42667df3 Author: chegar Date: 2013-05-27 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2dc42667df3 8015439: Minor/sync/cleanup of ConcurrentHashMap Reviewed-by: chegar Contributed-by: Doug Lea
                  , Chris Hegarty ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 9bbf2237071e Author: chegar Date: 2013-05-27 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bbf2237071e Merge From chris.hegarty at oracle.com Mon May 27 14:30:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 27 May 2013 15:30:17 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 Message-ID: <51A36DF9.5080207@oracle.com> Since my previous failed attempt to update the j.u.c. world, this review is for the update to j.u.c.ConcurrentHashMap v8 from Doug's CVS. http://cr.openjdk.java.net/~chegar/8005704/ver.00/specdiff/java/util/concurrent/package-summary.html http://cr.openjdk.java.net/~chegar/8005704/ver.00/webrev/ A few initial comments: 1) CHM no longer extends AbstractMap. I guess this should not be a problem in the real world, and I guess users would not be too surprised by instanceof checks. Just worth highlighting the change for compatibility. 2) KeySetView.spliterator() I guess the API should also report CONCURRENT, NONNULL & SUBSIZED? And the implementation should return SIZED too? 3) Value/EntrySpliterator.spliterator() should return SIZED? 4) Does is make sense for KeySetView to be Serializable? It looks a little odd with value as its only field. -Chris. From nils.loodin at oracle.com Mon May 27 15:18:33 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Mon, 27 May 2013 15:18:33 +0000 Subject: hg: jdk8/tl/jdk: 6470730: Disconnect button leads to wrong popup message Message-ID: <20130527151845.4F89448D64@hg.openjdk.java.net> Changeset: bbf6e6222726 Author: nloodin Date: 2013-05-27 17:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbf6e6222726 6470730: Disconnect button leads to wrong popup message Reviewed-by: dcubed, sla, egahlin ! src/share/classes/sun/tools/jconsole/VMPanel.java From david.r.chase at oracle.com Mon May 27 15:29:15 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 27 May 2013 11:29:15 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> Message-ID: <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> On 2013-05-27, at 9:27 AM, David Chase wrote: > Here, seeing is believing (oh, but look, I trashed the output format on the warmup, I should fix that): > > FIRST, WITH SHORT WARMUP: > dr2chase:zip $ $BB/java TimeChecksum > ---------- Adler32 ---------- > Warmup... 8 1,312 3 4 No, I didn't trash the output format. That is 8, 1312, 3, 4. The small-stuff warmup took that long. David From david.holmes at oracle.com Tue May 28 00:11:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2013 10:11:30 +1000 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A35530.7010404@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> Message-ID: <51A3F632.90304@oracle.com> Hi Aleksey, Okay I have some suggested rewordings below and a couple of grammatical corrections. I've trimmed out parts that are unchanged. On 27/05/2013 10:44 PM, Aleksey Shipilev wrote: > A {@code @Contended} field annotation may optionally include a > contention group tag. All fields with the same tag are considered as a > group with respect to isolation from other groups. A default tag > indicates the distinct and anonymous contention group, > which implies the contention with all other fields, including all other > {@code @Contended} ones. The tag at a class level is meaningless, and > ignored. A {@code @Contended} field annotation may optionally include a contention group tag. A contention group defines a set of one or more fields that collectively must be isolated from all other contention groups. With no contention group tag (or with the default empty tag: "") each {@code @Contended} field resides in its own distinct and anonymous contention group. A contention group tag has no meaning in a class level {@code @Contended} annotation, and is ignored. > ... With the class level annotation, the implementations may > choose different approach to protect the entire object, rather > than protecting only the distinct fields. With the class level annotation, implementations may choose different isolation techniques, such as isolating the entire object, rather than isolating distinct fields. > The {@code @Contended} annotation is not inherited, and acts only > within the class it was used on. The effects, however, should be > enforced across the inheritance, e.g. the {@code @Contended} fields > should be isolated from all the fields in super- and sub-classes. The > contention group tags are not inherited as well: the similar tags in two > subclasses mean different groups. The class level {@code @Contended} annotation is not inherited and has no effect on the fields of any sub-classes. The effects of all {@code @Contended} annotations, however, remain in force for all subclass instances, providing isolation of all the defined contention groups. Contention group tags are not inherited, and the same tag used in a superclass and subclass, represent distinct contention groups. > * The (optional) contention group tag. > * This tag is only meaningful for the field-level annotations. Delete "the" in "for the". Check "field-level" vs. "field level" usage; and "class-level" vs "class level" usage. I'm not sure what the JDK conventions are so you may need to find other examples. Just be sure to be internally consistent if there is no clear convention. Thanks, David ------ From mike.duigou at oracle.com Tue May 28 00:26:55 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 27 May 2013 17:26:55 -0700 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <51A35A1C.4060108@cs.oswego.edu> References: <519F9186.8040000@oracle.com> <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> <51A35A1C.4060108@cs.oswego.edu> Message-ID: <2CD1B2FA-DC8F-4932-8144-1AEF7B16974B@oracle.com> On May 27 2013, at 06:05 , Doug Lea wrote: > On 05/24/13 23:17, Mike Duigou wrote: > >> There's an awful lot here! > > (It's been a long time since jdk7 :-) > >> >> - It was surprising (and somewhat disappointing) to see changes like the following in various places. Is iterator creation that expensive? I'd hate to have to go back to using old style for loops everywhere. >> >> - List> futures = new ArrayList>(tasks.size()); >> + ArrayList> futures = new ArrayList>(tasks.size()); >> > > Are you suggesting that we not improve performance? :-) > Waiting a decade in wishful-thinking mode about ArrayList > traversal seems long enough. Nope, merely feeling the same disappointment that using the old style iteration is necessary. > (Aside: We addressed this in stream Spliterators to the > extent possible at library level. ArrayList.forEach of a fully > resolved non-capturing lambda is around twice as fast > as iterators.) > >> >> - The default for getOrDefault() in ConcurrentMap shouldn't be removed. >> >> - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not normally order preserving. >> > > Thanks! Both the results of my not rechecking vs lambda versions > (where a lot of this code has been running for a while now). > Hopefully no other three-way diffs of jsr166, lambda, tl > fell between cracks. I will be especially watchfully this. Comparing this patch applied to TL versus current Lambda was one of the checks I plan to make before completing approval of this issue. Mike From xuelei.fan at oracle.com Tue May 28 01:31:54 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2013 09:31:54 +0800 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <5191017A.7030707@oracle.com> References: <5190F30E.8040805@oracle.com> <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> <5191017A.7030707@oracle.com> Message-ID: <51A4090A.90500@oracle.com> Ping again, any one available to review this changeset? Thanks, Xuelei On 5/13/2013 11:06 PM, Xuelei Fan wrote: > On 5/13/2013 10:52 PM, Wang Weijun wrote: >> I'll read them tomorrow. > OK. It's not a urgent fix. > >> One question: are all of them designed to be call-by-value instead of shareable? >> > I'm not sure I understand the term "call-by-value" or "shareable". From > my understand, they are public classes, and copy-on-write or share-value > is the not right solution. Cloning mutable objects is more robust. > Otherwise, we need to check every caller to the method and the thread > stacks to make sure it is not abused. It's nightmare to maintain such code. > > In the JNDI specification, we normally declare like "This constructor > will not modify environment or save a reference to it, but may save a > clone. Caller should not modify mutable keys and values in environment > after it has been passed to the constructor." > > Thanks, > Xuelei > >> Thanks >> Max >> >> On May 13, 2013, at 10:05 PM, Xuelei Fan wrote: >> >>> Hi, >>> >>> There is some constructors issues about mutable objects in >>> com.sun.jndi.toolkit. >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ >>> >>> Thanks, >>> Xuelei > From david.holmes at oracle.com Tue May 28 02:17:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2013 12:17:32 +1000 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <51A4090A.90500@oracle.com> References: <5190F30E.8040805@oracle.com> <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> <5191017A.7030707@oracle.com> <51A4090A.90500@oracle.com> Message-ID: <51A413BC.3080501@oracle.com> I'm not familiar with these particular APIs but in general making defensive copies of mutable objects is good practice. In this case however it is unclear what the impact may be on existing users of this code. Eg: com/sun/jndi/toolkit/ctx/Continuation.java The "environment" is only stored for later use with the CannotProceedException, at which time the environment is cloned anyway (and cloned again by at least some consumers of that object!). So does it matter that we store a reference to the external object? To me that is more of a concern for the caller "will somebody mess with this if I pass it in?" - they might even be passing you a clone in the first place! If someone is passing in an environment that is subsequently modified, this change will stop that modification from being seen - which might be a good thing and might be a bad thing. There is also the memory usage consideration (how big are these environment tables?). So in terms of the mechanics of making defensive copies this code seems fine. But in terms of whether you _should_ be making defensive copies, that is a much harder question that I can't answer. David ----- On 28/05/2013 11:31 AM, Xuelei Fan wrote: > Ping again, any one available to review this changeset? > > Thanks, > Xuelei > > On 5/13/2013 11:06 PM, Xuelei Fan wrote: >> On 5/13/2013 10:52 PM, Wang Weijun wrote: >>> I'll read them tomorrow. >> OK. It's not a urgent fix. >> >>> One question: are all of them designed to be call-by-value instead of shareable? >>> >> I'm not sure I understand the term "call-by-value" or "shareable". From >> my understand, they are public classes, and copy-on-write or share-value >> is the not right solution. Cloning mutable objects is more robust. >> Otherwise, we need to check every caller to the method and the thread >> stacks to make sure it is not abused. It's nightmare to maintain such code. >> >> In the JNDI specification, we normally declare like "This constructor >> will not modify environment or save a reference to it, but may save a >> clone. Caller should not modify mutable keys and values in environment >> after it has been passed to the constructor." >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>> On May 13, 2013, at 10:05 PM, Xuelei Fan wrote: >>> >>>> Hi, >>>> >>>> There is some constructors issues about mutable objects in >>>> com.sun.jndi.toolkit. >>>> >>>> webrev: http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/ >>>> >>>> Thanks, >>>> Xuelei >> > From staffan.larsen at oracle.com Tue May 28 06:46:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 May 2013 08:46:30 +0200 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: <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> Looks good. You could optimize it a bit by not doing the Arrays.asList() on every methodExit event. /Staffan On 17 apr 2013, at 15:03, 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 petr.pchelko at oracle.com Tue May 28 06:51:28 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 28 May 2013 10:51:28 +0400 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <519EB983.4070302@oracle.com> References: <519B1ABE.10303@oracle.com> <519B5816.5080705@oracle.com> <519C58C0.4010309@oracle.com> <519EB983.4070302@oracle.com> Message-ID: <05CF2EBD-48F8-4FC5-A575-D44ADCB7ECCD@oracle.com> Hello, Kumar. Thank you for the review. > Is there a regression test for this somewhere ? It's quite hard to create a regression test for this issue, as we would need SWT for such test and we do not have any tests which use SWT currently. I have tried to make a test without SWT using some apple's APIs to check we do not block the queue, but it does not look like there's an easy way to do it. So, are you OK with the fix without the test? With best regards. Petr. On May 24, 2013, at 4:51 AM, Kumar Srinivasan wrote: > Hi Petr, > > Sorry for the delay, I somehow missed this one. > > I don't understand objective-c, if Mr Petrov is happy I am ok with it. > There seems to be indenting issues 1049-1051 > > Is there a regression test for this somewhere ? > > Thanks > Kumar > > >> Hello, >> >> Yes; Kumar should be one of the reviewers here. >> >> Thanks, >> >> -Joe >> >> On 05/21/2013 04:18 AM, Anthony Petrov wrote: >>> Hi Petr, >>> >>> The fix looks good to me. We still need a review from someone who maintains the Launcher code. Kumar? >>> >>> Also, you could use the @autoreleasepool directive to simplify it a bit, although I'm fine with the explicit syntax, too. >>> >>> One comment regarding your remark: >>>> c. We would have lost all the hg history for this file. >>> >>> We wouldn't. Mercurial handles renaming of files very well. See `hg help rename` for more details. (I'm not suggesting to rename this file though.) >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 05/21/2013 10:57 AM, David Holmes wrote: >>>> Adding core-libs as this is actually a launcher change. >>>> >>>> David >>>> >>>> On 21/05/2013 4:36 PM, Petr Pchelko wrote: >>>>> Hello, AWT Team. >>>>> >>>>> Please review the fix for the issue: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8009911 >>>>> The webrev is available at: >>>>> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >>>>> >>>>> The problem: >>>>> When launching java with -XstatrOnFirstThread we were using >>>>> dispatch_sync to start a Java main on the main thread. This blocked >>>>> the main dispatch queue, so all the subsequent calls to GCD were never >>>>> invoked. GCD is used a bit in our code, but it is used inside Cocoa, >>>>> for example for fullscreen. >>>>> >>>>> The solution: >>>>> We now launch Java main using a performSelectorOnMaintThread, so we do >>>>> not block GCD. >>>>> >>>>> Notes: >>>>> 1. This also fixes the following SWT bug: >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >>>>> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did >>>>> not rename it to .m, because: >>>>> a. It is hard to update an old build system to compile with the >>>>> new file name. >>>>> b. It is already compiled with -x objective-c, so I will compile >>>>> c. We would have lost all the hg history for this file. >>>>> >>>>> With best regards. Petr. >>>>> >> > From Alan.Bateman at oracle.com Tue May 28 07:50:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 May 2013 08:50:49 +0100 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <51A4090A.90500@oracle.com> References: <5190F30E.8040805@oracle.com> <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> <5191017A.7030707@oracle.com> <51A4090A.90500@oracle.com> Message-ID: <51A461D9.8040902@oracle.com> On 28/05/2013 02:31, Xuelei Fan wrote: > Ping again, any one available to review this changeset? It's good to fix up FindBugs warnings and I think these changes are okay. Can the @SuppressWarnings("unchecked") be removed from GenericURLContext.removeFromEnvironment now? -Alan From xuelei.fan at oracle.com Tue May 28 08:08:12 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 May 2013 16:08:12 +0800 Subject: Code review request, JDK-8010815, some constructors issues in com.sun.jndi.toolkit In-Reply-To: <51A461D9.8040902@oracle.com> References: <5190F30E.8040805@oracle.com> <14CDFAD8-052B-4B2E-8556-724137065FB0@oracle.com> <5191017A.7030707@oracle.com> <51A4090A.90500@oracle.com> <51A461D9.8040902@oracle.com> Message-ID: <51A465EC.4090902@oracle.com> On 5/28/2013 3:50 PM, Alan Bateman wrote: > On 28/05/2013 02:31, Xuelei Fan wrote: >> Ping again, any one available to review this changeset? > It's good to fix up FindBugs warnings and I think these changes are okay. > > Can the @SuppressWarnings("unchecked") be removed from > GenericURLContext.removeFromEnvironment now? > Yes, I should remove the tag. Thanks, Xuelei > -Alan > From paul.sandoz at oracle.com Tue May 28 08:11:05 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 May 2013 10:11:05 +0200 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <51A35A1C.4060108@cs.oswego.edu> References: <519F9186.8040000@oracle.com> <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> <51A35A1C.4060108@cs.oswego.edu> Message-ID: On May 27, 2013, at 3:05 PM, Doug Lea
                  wrote: >> >> - The default for getOrDefault() in ConcurrentMap shouldn't be removed. >> >> - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not normally order preserving. >> > > Thanks! Both the results of my not rechecking vs lambda versions > (where a lot of this code has been running for a while now). > Hopefully no other three-way diffs of jsr166, lambda, tl > fell between cracks. > I flip-flopped on this one, since the use of CopyOnWriteArrayList by CopyOnWriteArraySet is explicitly stated but it is not explictly stated that CopyOnWriteArraySet.add defers to CopyOnWriteArrayList.addIfAbsent. Paul. From paul.sandoz at oracle.com Tue May 28 09:00:54 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 May 2013 11:00:54 +0200 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A36DF9.5080207@oracle.com> References: <51A36DF9.5080207@oracle.com> Message-ID: <75F1229C-2568-489D-9AF4-74C7EDCC009D@oracle.com> Hi Chris, On May 27, 2013, at 4:30 PM, Chris Hegarty wrote: > 2) KeySetView.spliterator() > > I guess the API should also report CONCURRENT, NONNULL & SUBSIZED? > And the implementation should return SIZED too? > > 3) Value/EntrySpliterator.spliterator() should return SIZED? > The CHM spliterators cannot report SIZED/SUBSIZED. On construction of a root spliterator a snapshot of the size is obtained and that size is used as the estimate, but elements can be concurrently added/removed after the size is obtained and during operations on the spliterator. Furthermore, even if the size was known at the root, the spliterators cannot report SUBSIZED since the size at the root spliterator is used as an size estimate for sub-splits, "est >>>= 1", with the assumption that the node table contains an ~ uniform distribution of nodes. See the spliterators of HashMap for such a case when there size is known at the root but not for sub-splits. Size estimates are used when it is costly/impractical to maintain and/or calculate exact sizes. Hth, Paul. From chris.hegarty at oracle.com Tue May 28 09:07:28 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 28 May 2013 10:07:28 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <75F1229C-2568-489D-9AF4-74C7EDCC009D@oracle.com> References: <51A36DF9.5080207@oracle.com> <75F1229C-2568-489D-9AF4-74C7EDCC009D@oracle.com> Message-ID: <51A473D0.70600@oracle.com> Thank you Paul, got it. -Chris. On 05/28/2013 10:00 AM, Paul Sandoz wrote: > Hi Chris, > > On May 27, 2013, at 4:30 PM, Chris Hegarty wrote: >> 2) KeySetView.spliterator() >> >> I guess the API should also report CONCURRENT, NONNULL & SUBSIZED? >> And the implementation should return SIZED too? >> >> 3) Value/EntrySpliterator.spliterator() should return SIZED? >> > > The CHM spliterators cannot report SIZED/SUBSIZED. > > On construction of a root spliterator a snapshot of the size is obtained and that size is used as the estimate, but elements can be concurrently added/removed after the size is obtained and during operations on the spliterator. > > Furthermore, even if the size was known at the root, the spliterators cannot report SUBSIZED since the size at the root spliterator is used as an size estimate for sub-splits, "est >>>= 1", with the assumption that the node table contains an ~ uniform distribution of nodes. See the spliterators of HashMap for such a case when there size is known at the root but not for sub-splits. > > Size estimates are used when it is costly/impractical to maintain and/or calculate exact sizes. > > Hth, > Paul. > From otaviojava at java.net Tue May 28 09:37:51 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Tue, 28 May 2013 06:37:51 -0300 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString Message-ID: diff --git a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java --- a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java +++ b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java @@ -55,9 +55,9 @@ public IncompleteAnnotationException( Class annotationType, String elementName) { - super(annotationType.getName().toString() + + super(annotationType.getName() + " missing element " + - elementName.toString()); + elementName); this.annotationType = annotationType; this.elementName = elementName; -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From dl at cs.oswego.edu Tue May 28 10:09:05 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 28 May 2013 06:09:05 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519E67AF.7090504@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> Message-ID: <51A48241.2030507@cs.oswego.edu> On 05/23/13 15:02, Brent Christian wrote: > On 5/23/13 5:20 AM, Doug Lea wrote: >> * Given that balanced trees are not used in WeakHashMap >> or Hashtable, I wonder why the TreeNode etc classes are >> not just nested inside HashMap (usable from subclass LinkedHashMap). To better enable and simplify future improvements, could you do this -- nest the tree classes within HashMap? Also, a note on spliterators: I had added these in the least disruptive way (knowing that major changes were coming) by checking exact class match for HashMap.class. This is because there aren't LinkedHashMap view classes to attach overrides to. While not wrong, and OK for now, at some point this should be redone. -Doug From dl at cs.oswego.edu Tue May 28 10:29:11 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 28 May 2013 06:29:11 -0400 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A36DF9.5080207@oracle.com> References: <51A36DF9.5080207@oracle.com> Message-ID: <51A486F7.1080104@cs.oswego.edu> On 05/27/13 10:30, Chris Hegarty wrote: > > 1) CHM no longer extends AbstractMap. I guess this should not be a > problem in the real world, and I guess users would not be too > surprised by instanceof checks. Just worth highlighting the change > for compatibility. Yes, thanks. It was a bad idea to extend AbstractMap in the first place, since all of its methods are or should be overridden. But if there is any reason to retain this, it is harmless to do so, at the expense of adding two unused fields to footprint. (The AbstractMap keySet and Values fields cannot be used by CHM because they are package-protected, so it needs to declare its own versions anyway.) > 4) Does is make sense for KeySetView to be Serializable? It looks a > little odd with value as its only field. > (Plus the backing ConcurrentHashMap.) Serialization is needed (or at least desired) because this class is now used for CHM.newKeySet, which finally adds a way to get the equivalent of a ConcurrentHashSet. (You could get one via Collections.newSetFromMap, but then lose the advertised concurrency/atomicity properties.) -Doug From chris.hegarty at oracle.com Tue May 28 10:34:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 28 May 2013 11:34:13 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A486F7.1080104@cs.oswego.edu> References: <51A36DF9.5080207@oracle.com> <51A486F7.1080104@cs.oswego.edu> Message-ID: <51A48825.2020803@oracle.com> Thank you Doug, this addresses my concerns. On 05/28/2013 11:29 AM, Doug Lea wrote: > On 05/27/13 10:30, Chris Hegarty wrote: > >> >> 1) CHM no longer extends AbstractMap. I guess this should not be a >> problem in the real world, and I guess users would not be too >> surprised by instanceof checks. Just worth highlighting the change >> for compatibility. > > Yes, thanks. It was a bad idea to extend AbstractMap in the first place, > since all of its methods are or should be overridden. But if > there is any reason to retain this, it is harmless to do so, OK, this can be the backup plan if this issue arises during CCC. > at the expense of adding two unused fields to footprint. > (The AbstractMap keySet and Values fields cannot be used > by CHM because they are package-protected, so it needs to > declare its own versions anyway.) > >> 4) Does is make sense for KeySetView to be Serializable? It looks a >> little odd with value as its only field. >> > > (Plus the backing ConcurrentHashMap.) Yes, of course. > Serialization is needed (or at least desired) because this class > is now used for CHM.newKeySet, which finally adds a way to > get the equivalent of a ConcurrentHashSet. (You could get one > via Collections.newSetFromMap, but then lose the advertised > concurrency/atomicity properties.) Thanks, -Chris. > > -Doug > > > From david.holmes at oracle.com Tue May 28 11:14:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2013 21:14:50 +1000 Subject: [java.lang.annotation.IncompleteAnnotationException] 9003386: call toString() on String in java.lang.annotation.IncompleteAnnotationException In-Reply-To: <51A47885.5080706@oracle.com> References: <51A47885.5080706@oracle.com> Message-ID: <51A491AA.9060706@oracle.com> On 28/05/2013 7:27 PM, Alan Bateman wrote: > On 28/05/2013 10:15, Ot?vio Gon?alves de Santana wrote: >> diff --git >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> --- >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> +++ >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> @@ -55,9 +55,9 @@ >> public IncompleteAnnotationException( >> Class annotationType, >> String elementName) { >> - super(annotationType.getName().toString() + >> + super(annotationType.getName() + >> " missing element " + >> - elementName.toString()); >> + elementName); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> > I would suggest bring this clean-up to core-libs-dev. Also the bug for > this in the bug database is: > > 8015470: (ann) IncompleteAnnotationException does not need to call toString I don't see this as a bug at all - it is an optimization. The explicit toString() avoids the String.valueOf call (which will call toString() itself) and an additional StringBuffer.append call. Without the toString you have calls to: - StringBuilder.append(Object) - String.valueOf(Object) - Object.toString() - StringBuilder.append(String) with it you have - Object.toString() - StringBuilder.append(String) David > -Alan From david.holmes at oracle.com Tue May 28 11:15:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2013 21:15:50 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: References: Message-ID: <51A491E6.9080707@oracle.com> Please see my reply under your original subject line. This is not a bug. David On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: > diff --git > a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > --- > a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > +++ > b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java > @@ -55,9 +55,9 @@ > public IncompleteAnnotationException( > Class annotationType, > String elementName) { > - super(annotationType.getName().toString() + > + super(annotationType.getName() + > " missing element " + > - elementName.toString()); > + elementName); > > this.annotationType = annotationType; > this.elementName = elementName; > > From vicente.romero at oracle.com Tue May 28 11:46:48 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 28 May 2013 11:46:48 +0000 Subject: hg: jdk8/tl/langtools: 6970173: Debug pointer at bad position Message-ID: <20130528114652.D07EF48D80@hg.openjdk.java.net> Changeset: c6df5b20f9eb Author: vromero Date: 2013-05-28 12:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6df5b20f9eb 6970173: Debug pointer at bad position Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6970173/DebugPointerAtBadPositionTest.java From aleksej.efimov at oracle.com Tue May 28 12:04:59 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 28 May 2013 16:04:59 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A2CBAD.7000307@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , <519B5444.7060701@oracle.com> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com> <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com> Message-ID: <51A49D6B.3020407@oracle.com> Alan, David, thank you for comments - I also agree with all of them. And as a result v3: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ Aleksej On 05/27/2013 06:57 AM, David Holmes wrote: > On 26/05/2013 1:41 AM, Alan Bateman wrote: >> On 25/05/2013 09:37, Aleksej Efimov wrote: >>> David, Jason, >>> Thank you for your comments and suggestions. They all were taken in >>> account and as a result - the new webrev: >>> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/ >> I think this looks better. I assume that since the super.getCause() is >> null that there is no need to handle IllegalStateException now. > > I would agree on both counts. > > David > >> I think the test could be beefed up to cover the >> serialization/de-serialization too (since this is new code and doesn't >> appear to be exercised by other tests). >> >> -Alan From david.holmes at oracle.com Tue May 28 12:48:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2013 22:48:37 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51A491E6.9080707@oracle.com> References: <51A491E6.9080707@oracle.com> Message-ID: <51A4A7A5.8020504@oracle.com> Sorry it didn't register that getName() already returns a String - hence the toString() is redundant - but minimally so. David On 28/05/2013 9:15 PM, David Holmes wrote: > Please see my reply under your original subject line. > > This is not a bug. > > David > > On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: >> diff --git >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> --- >> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> +++ >> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >> >> @@ -55,9 +55,9 @@ >> public IncompleteAnnotationException( >> Class annotationType, >> String elementName) { >> - super(annotationType.getName().toString() + >> + super(annotationType.getName() + >> " missing element " + >> - elementName.toString()); >> + elementName); >> >> this.annotationType = annotationType; >> this.elementName = elementName; >> >> From john.zavgren at oracle.com Tue May 28 13:07:35 2013 From: john.zavgren at oracle.com (John Zavgren) Date: Tue, 28 May 2013 09:07:35 -0400 Subject: RFR JDK-8015299 In-Reply-To: <51A2CCE9.9070406@oracle.com> References: <519F8168.7000505@oracle.com> <51A2CCE9.9070406@oracle.com> Message-ID: <51A4AC17.5000607@oracle.com> Greetings: I fixed the comment line... to correct the "nul", "NULL", "NUL" issue and I disambiguated the readlink() issue. Thanks! John On 05/26/2013 11:03 PM, David Holmes wrote: > I concur with Martin on all counts. > > Confusing NUL and NULL is also a pet peeve of mine :) > > David > > On 25/05/2013 2:15 AM, Martin Buchholz wrote: >> Hi John, >> >> The memory leak fix looks good. >> --- >> IIRC I was the author of the comment, so it is not surprising that I >> might >> prefer that version. "nul" is ___not___ a typo for NULL. It makes no >> sense to speak of character arrays being NULL-terminated. It also isn't >> quite right to say that readlink "generates" an array - it simply writes >> into one. >> >> However, it is more correct to spell "nul" "NUL" as in ASCII(7). >> >> If you wanted to be more precise about which readlink, you could write >> readlink(2) instead of readlink() to disambiguate from readlink(1) >> >> >> On Fri, May 24, 2013 at 8:04 AM, John Zavgren >> wrote: >> >>> Greetings: >>> >>> I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** >>> solinux.c >>> and I posted a webrev image of the changes at: >>> http://cr.openjdk.java.net/~**jzavgren/8015299/webrev.01/< >>> >>> http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/ >>> >>>> >>> >>> (I also edited a comment.) >>> >>> Thanks! >>> John >>> >>> -- >>> John Zavgren >>> john.zavgren at oracle.com >>> 603-821-0904 >>> US-Burlington-MA >>> >>> -- John Zavgren john.zavgren at oracle.com 603-821-0904 US-Burlington-MA From forax at univ-mlv.fr Tue May 28 13:08:15 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 May 2013 15:08:15 +0200 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51A4A7A5.8020504@oracle.com> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> Message-ID: <51A4AC3F.2050200@univ-mlv.fr> On 05/28/2013 02:48 PM, David Holmes wrote: > Sorry it didn't register that getName() already returns a String - > hence the toString() is redundant - but minimally so. > > David The second call to toString() also performs an implicit nullcheck (elementName can not be null). So if we have to fix something, it's only to remove the call to toString() after the call to getName(). cheers, R?mi > > On 28/05/2013 9:15 PM, David Holmes wrote: >> Please see my reply under your original subject line. >> >> This is not a bug. >> >> David >> >> On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: >>> diff --git >>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> >>> >>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> >>> >>> --- >>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> >>> >>> +++ >>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>> >>> >>> @@ -55,9 +55,9 @@ >>> public IncompleteAnnotationException( >>> Class annotationType, >>> String elementName) { >>> - super(annotationType.getName().toString() + >>> + super(annotationType.getName() + >>> " missing element " + >>> - elementName.toString()); >>> + elementName); >>> >>> this.annotationType = annotationType; >>> this.elementName = elementName; >>> >>> From jason_mehrens at hotmail.com Tue May 28 13:41:00 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 28 May 2013 08:41:00 -0500 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A49D6B.3020407@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>,,<517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>,,<518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>,<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>,<51A49D6B.3020407@oracle.com> Message-ID: > Alan, David, > thank you for comments - I also agree with all of them. And as a result v3: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ > >> I think this looks better. I assume that since the super.getCause() is > >> null that there is no need to handle IllegalStateException now. You can still generate a ISE inside readObject by performing "new XPathException(new Exception()).initCause(null)" in the old code and then reading that in the new patch. In the new code that line would fail fast. Jason From jaroslav.bachorik at oracle.com Tue May 28 14:06:25 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 28 May 2013 14:06:25 +0000 Subject: hg: jdk8/tl/jdk: 8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows Message-ID: <20130528140637.E54C248D8B@hg.openjdk.java.net> Changeset: 7d9fab5d86cd Author: jbachorik Date: 2013-05-28 15:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d9fab5d86cd 8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows Reviewed-by: chegar, smarks, dfuchs ! test/ProblemList.txt ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh From aleksej.efimov at oracle.com Tue May 28 14:30:19 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 28 May 2013 18:30:19 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> Message-ID: <51A4BF7B.8040206@oracle.com> Jason, You are absolutely right and my fault that I didn't tested the compatibility of new/old versions. I have tested it with JDK 8(without fix) as a serializer and JDK 8 (with fix) as deserializer. The behavior was as you expected. Thanks for catching it. I'll wait for other comments before generating another webrev. Aleksej On 05/28/2013 05:41 PM, Jason Mehrens wrote: > > Alan, David, > > thank you for comments - I also agree with all of them. And as a > result v3: > > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ > > >> I think this looks better. I assume that since the > super.getCause() is > > >> null that there is no need to handle IllegalStateException now. > > You can still generate a ISE inside readObject by performing "new > XPathException(new Exception()).initCause(null)" in the old code and > then reading that in the new patch. In the new code that line would > fail fast. > > Jason From dmitry.samersoff at oracle.com Tue May 28 14:47:20 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 28 May 2013 14:47:20 +0000 Subject: hg: jdk8/tl/jdk: 8014420: Default JDP address does not match the one assigned by IANA Message-ID: <20130528144753.CA50E48D8D@hg.openjdk.java.net> Changeset: 7d7bfce34a79 Author: dsamersoff Date: 2013-05-28 18:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7bfce34a79 8014420: Default JDP address does not match the one assigned by IANA Summary: JDP protocol defaults changed to IANA assigned values Reviewed-by: dholmes, jbachorik, hirt Contributed-by: fweimer at redhat.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/jdp/package-info.java ! test/sun/management/jdp/JdpTest.sh From rob.mckenna at oracle.com Tue May 28 15:35:11 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 28 May 2013 15:35:11 +0000 Subject: hg: jdk8/tl/jdk: 7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys Message-ID: <20130528153537.D27B148D8F@hg.openjdk.java.net> Changeset: b16a8b4ae6b4 Author: robm Date: 2013-05-28 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16a8b4ae6b4 7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/IsHidden.java From vicente.romero at oracle.com Tue May 28 16:40:30 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 28 May 2013 16:40:30 +0000 Subject: hg: jdk8/tl/langtools: 8012333: javac, ClassFile should have a read(Path) method Message-ID: <20130528164037.CB39048D96@hg.openjdk.java.net> Changeset: d042cba65eab Author: vromero Date: 2013-05-28 17:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d042cba65eab 8012333: javac, ClassFile should have a read(Path) method Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java From kumar.x.srinivasan at oracle.com Tue May 28 17:02:20 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 28 May 2013 10:02:20 -0700 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <05CF2EBD-48F8-4FC5-A575-D44ADCB7ECCD@oracle.com> References: <519B1ABE.10303@oracle.com> <519B5816.5080705@oracle.com> <519C58C0.4010309@oracle.com> <519EB983.4070302@oracle.com> <05CF2EBD-48F8-4FC5-A575-D44ADCB7ECCD@oracle.com> Message-ID: <51A4E31C.6080209@oracle.com> Hi Petr, > Hello, Kumar. > > Thank you for the review. > >> Is there a regression test for this somewhere ? > It's quite hard to create a regression test for this issue, as we would need SWT for such test and we do not have any tests which use SWT currently. > I have tried to make a test without SWT using some apple's APIs to check we do not block the queue, but it does not look like there's an easy way to do it. In that case we need to mark JDK-8009911 with label "noreg-hard", with your explanation as to why a test is infeasible. > > So, are you OK with the fix without the test? Yes go for it. Kumar > > With best regards. Petr. > > On May 24, 2013, at 4:51 AM, Kumar Srinivasan wrote: > >> Hi Petr, >> >> Sorry for the delay, I somehow missed this one. >> >> I don't understand objective-c, if Mr Petrov is happy I am ok with it. >> There seems to be indenting issues 1049-1051 >> >> Is there a regression test for this somewhere ? >> >> Thanks >> Kumar >> >> >>> Hello, >>> >>> Yes; Kumar should be one of the reviewers here. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 05/21/2013 04:18 AM, Anthony Petrov wrote: >>>> Hi Petr, >>>> >>>> The fix looks good to me. We still need a review from someone who maintains the Launcher code. Kumar? >>>> >>>> Also, you could use the @autoreleasepool directive to simplify it a bit, although I'm fine with the explicit syntax, too. >>>> >>>> One comment regarding your remark: >>>>> c. We would have lost all the hg history for this file. >>>> We wouldn't. Mercurial handles renaming of files very well. See `hg help rename` for more details. (I'm not suggesting to rename this file though.) >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 05/21/2013 10:57 AM, David Holmes wrote: >>>>> Adding core-libs as this is actually a launcher change. >>>>> >>>>> David >>>>> >>>>> On 21/05/2013 4:36 PM, Petr Pchelko wrote: >>>>>> Hello, AWT Team. >>>>>> >>>>>> Please review the fix for the issue: >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8009911 >>>>>> The webrev is available at: >>>>>> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ >>>>>> >>>>>> The problem: >>>>>> When launching java with -XstatrOnFirstThread we were using >>>>>> dispatch_sync to start a Java main on the main thread. This blocked >>>>>> the main dispatch queue, so all the subsequent calls to GCD were never >>>>>> invoked. GCD is used a bit in our code, but it is used inside Cocoa, >>>>>> for example for fullscreen. >>>>>> >>>>>> The solution: >>>>>> We now launch Java main using a performSelectorOnMaintThread, so we do >>>>>> not block GCD. >>>>>> >>>>>> Notes: >>>>>> 1. This also fixes the following SWT bug: >>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 >>>>>> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did >>>>>> not rename it to .m, because: >>>>>> a. It is hard to update an old build system to compile with the >>>>>> new file name. >>>>>> b. It is already compiled with -x objective-c, so I will compile >>>>>> c. We would have lost all the hg history for this file. >>>>>> >>>>>> With best regards. Petr. >>>>>> From otaviojava at java.net Tue May 28 17:06:14 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Tue, 28 May 2013 14:06:14 -0300 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51A4AC3F.2050200@univ-mlv.fr> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> Message-ID: Hello everyone my name is Ot?vio Santana and I do part of some Java user groups in Brazil, including SouJava. I know it is not an error, but an optimization. I have studying about OpenJDK and I hope help you. How I am a beginner in OpenJDK, I only can help with simple things like refactoring and clean-up, but I hope help always more and with complex code in the future. On Tue, May 28, 2013 at 10:08 AM, Remi Forax wrote: > On 05/28/2013 02:48 PM, David Holmes wrote: > >> Sorry it didn't register that getName() already returns a String - hence >> the toString() is redundant - but minimally so. >> >> David >> > > The second call to toString() also performs an implicit nullcheck > (elementName can not be null). > So if we have to fix something, it's only to remove the call to toString() > after the call to getName(). > > cheers, > R?mi > > > >> On 28/05/2013 9:15 PM, David Holmes wrote: >> >>> Please see my reply under your original subject line. >>> >>> This is not a bug. >>> >>> David >>> >>> On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: >>> >>>> diff --git >>>> a/src/share/classes/java/lang/**annotation/** >>>> IncompleteAnnotationException.**java >>>> >>>> b/src/share/classes/java/lang/**annotation/** >>>> IncompleteAnnotationException.**java >>>> >>>> --- >>>> a/src/share/classes/java/lang/**annotation/** >>>> IncompleteAnnotationException.**java >>>> >>>> +++ >>>> b/src/share/classes/java/lang/**annotation/** >>>> IncompleteAnnotationException.**java >>>> >>>> @@ -55,9 +55,9 @@ >>>> public IncompleteAnnotationException( >>>> Class annotationType, >>>> String elementName) { >>>> - super(annotationType.getName()**.toString() + >>>> + super(annotationType.getName() + >>>> " missing element " + >>>> - elementName.toString()); >>>> + elementName); >>>> >>>> this.annotationType = annotationType; >>>> this.elementName = elementName; >>>> >>>> >>>> > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From martinrb at google.com Tue May 28 17:34:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 10:34:40 -0700 Subject: RFR JDK-8015299 In-Reply-To: <51A4AC17.5000607@oracle.com> References: <519F8168.7000505@oracle.com> <51A2CCE9.9070406@oracle.com> <51A4AC17.5000607@oracle.com> Message-ID: Thanks. Looks good! On Tue, May 28, 2013 at 6:07 AM, John Zavgren wrote: > Greetings: > > I fixed the comment line... to correct the "nul", "NULL", "NUL" issue and > I disambiguated the readlink() issue. > > Thanks! > John > > > On 05/26/2013 11:03 PM, David Holmes wrote: > >> I concur with Martin on all counts. >> >> Confusing NUL and NULL is also a pet peeve of mine :) >> >> David >> >> On 25/05/2013 2:15 AM, Martin Buchholz wrote: >> >>> Hi John, >>> >>> The memory leak fix looks good. >>> --- >>> IIRC I was the author of the comment, so it is not surprising that I >>> might >>> prefer that version. "nul" is ___not___ a typo for NULL. It makes no >>> sense to speak of character arrays being NULL-terminated. It also isn't >>> quite right to say that readlink "generates" an array - it simply writes >>> into one. >>> >>> However, it is more correct to spell "nul" "NUL" as in ASCII(7). >>> >>> If you wanted to be more precise about which readlink, you could write >>> readlink(2) instead of readlink() to disambiguate from readlink(1) >>> >>> >>> On Fri, May 24, 2013 at 8:04 AM, John Zavgren * >>> *wrote: >>> >>> Greetings: >>>> >>>> I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** >>>> solinux.c >>>> and I posted a webrev image of the changes at: >>>> http://cr.openjdk.java.net/~****jzavgren/8015299/webrev.01/ >>>> >< >>>> >>>> http://cr.openjdk.java.net/%****7Ejzavgren/8015299/webrev.01/<** >>>> http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/> >>>> >>>> >>>>> >>>>> >>>> (I also edited a comment.) >>>> >>>> Thanks! >>>> John >>>> >>>> -- >>>> John Zavgren >>>> john.zavgren at oracle.com >>>> 603-821-0904 >>>> US-Burlington-MA >>>> >>>> >>>> > > -- > John Zavgren > john.zavgren at oracle.com > 603-821-0904 > US-Burlington-MA > > From xueming.shen at oracle.com Tue May 28 17:45:00 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 28 May 2013 17:45:00 +0000 Subject: hg: jdk8/tl/jdk: 8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Message-ID: <20130528174551.2A37B48D9A@hg.openjdk.java.net> Changeset: 7fa2d1dcb8f6 Author: sherman Date: 2013-05-28 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa2d1dcb8f6 8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method Summary: to make defensive copy for set/get replacement byte array Reviewed-by: martin ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java From dan.xu at oracle.com Tue May 28 18:39:49 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 May 2013 11:39:49 -0700 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data Message-ID: <51A4F9F5.3090909@oracle.com> Hi All, When File.createTempFile() is called with some special parameters, it runs into infiniteloop and hangs. It is because it does not always mean a file exists when the method, createFileExclusively(), returns false. This fix is going to solve such issues reported in JDK-8013827 and JDK-8011950.And I also added some testcases to verify it. webrev: http://cr.openjdk.java.net/~dxu/8013827/webrev.00/ bug: http://bugs.sun.com/view_bug.do?bug_id=8011950 -Dan From mike.duigou at oracle.com Tue May 28 19:07:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 May 2013 12:07:39 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A36DF9.5080207@oracle.com> References: <51A36DF9.5080207@oracle.com> Message-ID: <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Hi Chris & Doug; - I don't feel strongly about the removal of AbstractMap. I don't see this as very likely to cause problems in real world code though there is probably some test code somewhere that assigns CHM to an AbstractMap. - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type particularly for newKeySet(). Why not return Set? The additional methods don't seem to offer much that's desirable for the newKeySet() case. - I am reluctant to deprecate contains(Object) here unless we deprecate it in Hashtable as well. I recognize that this has been a source of errors (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one example). Is it time to deprecate it there as well? - I think there could be more complete description of the parallelismThreshold and interaction with common pool. i.e. does "maximal parallelism" mean one thread per element or "size() / getCommonPoolParallelism()". Some advice for choosing in-between values would be good unless "1" is the best advice for cases where you just don't know. It would be a shame to see people shooting themselves in the foot with this. Mike On May 27 2013, at 07:30 , Chris Hegarty wrote: > Since my previous failed attempt to update the j.u.c. world, this review is for the update to j.u.c.ConcurrentHashMap v8 from Doug's CVS. > > http://cr.openjdk.java.net/~chegar/8005704/ver.00/specdiff/java/util/concurrent/package-summary.html > http://cr.openjdk.java.net/~chegar/8005704/ver.00/webrev/ > > A few initial comments: > > 1) CHM no longer extends AbstractMap. I guess this should not be a > problem in the real world, and I guess users would not be too > surprised by instanceof checks. Just worth highlighting the change > for compatibility. > > 2) KeySetView.spliterator() > > I guess the API should also report CONCURRENT, NONNULL & SUBSIZED? > And the implementation should return SIZED too? > > 3) Value/EntrySpliterator.spliterator() should return SIZED? > > 4) Does is make sense for KeySetView to be Serializable? It looks a > little odd with value as its only field. > > -Chris. From aleksey.shipilev at oracle.com Tue May 28 19:43:37 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 28 May 2013 23:43:37 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A3F632.90304@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> Message-ID: <51A508E9.9070405@oracle.com> Hi David, On 05/28/2013 04:11 AM, David Holmes wrote: > Okay I have some suggested rewordings below and a couple of grammatical > corrections. Thank you! The updated webrev is here: http://cr.openjdk.java.net/~shade/8014966/webrev.02/ Changes from the David's version: * added the provisioning for isolation from superclass as well: "The effects of all {@code @Contended} annotations, however, remain in force for all >>>> superclass and <<<< subclass instances, providing isolation of all the defined contention groups." * minor touchups to make doclint happy. I think we are ready to go. Objections, comments, more RFCs? -Aleksey. From kustos at gmx.net Tue May 28 19:44:54 2013 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 28 May 2013 21:44:54 +0200 Subject: AutoCloseable XMLStreamReader and XMLStreamWriter? In-Reply-To: <51A31C08.5000909@oracle.com> References: <51A1EC42.1000407@gmx.net> <51A31C08.5000909@oracle.com> Message-ID: <51A50936.4090108@gmx.net> On 27.05.2013 10:40, Alan Bateman wrote: > On 26/05/2013 12:04, Philippe Marschall wrote: >> Hi >> >> It would be nice if javax.xml.stream.XMLStreamReader and >> javax.xml.stream.XMLStreamWriter could be made to extend >> java.lang.AutoCloseable so that they can be used in a >> try-with-resouces statement. The some does for XMLEventReader and >> XMLEventReader. > I don't recall if this one has come up before (there were lots of > candidates identified for retrofitting when AutoCloseable was added) but > the XML APIs have the complication that they are a "Standalone > Technology". Yes and JEP-185 doesn't make it less confusing. > I don't know how far back JSR-206/173 needs to be support > but if you retrofit these interfaces to extend AutoCloseable then it > would rule out usage with jdk6. Joe Wang might know about about this. Is he watching this list or should I contact him otherwise? Cheers Philippe From martinrb at google.com Tue May 28 19:53:36 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 12:53:36 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <7978F270-3489-455F-956E-3BB66947F381@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: Vaguely related, looking at Map.getOrDefault: --- Whitspace is wonky - we want more whitespace before the '*', less after. /** * Returns the value to which the specified key is mapped, * or {@code defaultValue} if this map contains no mapping * for the key. --- The @param for defaultValue is missing. --- Isn't the following paragraph a leading candidate for one of those newfangled javadoc tags y'all've been creating, so that inheritDoc doesn't snag it? *

                  The default implementation makes no guarantees about synchronization * or atomicity properties of this method. Any implementation providing * atomicity guarantees must override this method and document its * concurrency properties. --- ObConcurrentHashMap: The javadoc for other getOrDefault methods should be sync'ed with Map's. I like: --- src/main/java/util/concurrent/ConcurrentHashMap.java 24 May 2013 03:27:47 -0000 1.216 +++ src/main/java/util/concurrent/ConcurrentHashMap.java 28 May 2013 19:49:22 -0000 @@ -2596,13 +2596,13 @@ } /** - * Returns the value to which the specified key is mapped, - * or the given defaultValue if this map contains no mapping for the key. + * Returns the value to which the specified key is mapped, or the + * given default value if this map contains no mapping for the key. * - * @param key the key + * @param key the key whose associated value is to be returned * @param defaultValue the value to return if this map contains * no mapping for the given key - * @return the mapping for the key, if present; else the defaultValue + * @return the mapping for the key, if present; else the default value * @throws NullPointerException if the specified key is null */ public V getOrDefault(Object key, V defaultValue) { --- src/main/java/util/concurrent/ConcurrentSkipListMap.java 7 May 2013 20:25:36 -0000 1.123 +++ src/main/java/util/concurrent/ConcurrentSkipListMap.java 28 May 2013 19:49:22 -0000 @@ -1513,13 +1513,13 @@ } /** - * Returns the value to which the specified key is mapped, - * or the given defaultValue if this map contains no mapping for the key. + * Returns the value to which the specified key is mapped, or the + * given default value if this map contains no mapping for the key. * - * @param key the key + * @param key the key whose associated value is to be returned * @param defaultValue the value to return if this map contains * no mapping for the given key - * @return the mapping for the key, if present; else the defaultValue + * @return the mapping for the key, if present; else the default value * @throws NullPointerException if the specified key is null * @since 1.8 */ --- Is atomicity part of the contract of ConcurrentMap.getOrDefault? Currently, it doesn't say. Actually, there are two possible guarantees it could make - whether the default implementation ConcurrentMap.getOrDefault is atomic (when the map does not accept nulls) and whether subclasses that override getOrDefault must make this guarantee. --- Curiously, ConcurrentMap doesn't guarantee that get() is atomic. Perhaps it should? --- From martinrb at google.com Tue May 28 20:03:01 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 13:03:01 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: A long-returning size method seems like a framework-level decision. We could add a default method to Collection.java and Map.java default long mappingCount() { return size(); } I'm not sure mappingCount is the best name, but all names will be confusing. Using the name "length()" at least has an onomatopoeic mnemonic advantage - it suggests that it might return a long. /** * Returns the number of mappings. This method should be used * instead of {@link #size} because a ConcurrentHashMap may * contain more mappings than can be represented as an int. The * value returned is an estimate; the actual count may differ if * there are concurrent insertions or removals. * * @return the number of mappings */ public long mappingCount() { long n = sumCount(); return (n < 0L) ? 0L : n; // ignore transient negative values } From brent.christian at oracle.com Tue May 28 20:03:45 2013 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 28 May 2013 13:03:45 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A48241.2030507@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> Message-ID: <51A50DA1.8060502@oracle.com> On 5/28/13 3:09 AM, Doug Lea wrote: > > To better enable and simplify future improvements, could you > do this -- nest the tree classes within HashMap? Done. > Also, a note on spliterators: I had added these in the > least disruptive way (knowing that major changes were coming) > by checking exact class match for HashMap.class. This is because > there aren't LinkedHashMap view classes to attach overrides to. > While not wrong, and OK for now, at some point this should be redone. OK. I will file a bug so this doesn't get forgotten. I also applied the change to how HashMap.putAll() resizes the table (to account for splitTreeBin() only handling doubling of tables). The updated webrev is here: http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ Thanks, -Brent From martinrb at google.com Tue May 28 20:38:47 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 13:38:47 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A508E9.9070405@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> Message-ID: Tricky stuff! --- We don't use closing html tags for things like

                  in javadoc. --- + * in concurrent contexts in which each instance of the annotated + * object is often accessed by a different thread.

                  Hmmm... makes it sound like it applies even if each instance is thread-confined (in a different thread) or is immutable. "objects" are not annotated. Maybe "instances of the annotated class are frequently accessed by multiple threads and have fields that are frequently written". --- Subclassing makes things tricky. I think it would be pretty common to want a subclass field to be in the same contention group as a superclass contention group. --- however, remain in force for all + * superclass and subclass instances "remain in force for superclass instances" doesn't make sense to me. Do you mean "remain in force when fields are inherited in subclasses" --- Do we want final fields to be explicitly exempt from being treated as contended? Or is that Quality of Implementation? Do we want to insert the word "non-final" in "all the unannotated fields" From naoto.sato at oracle.com Tue May 28 21:03:16 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 28 May 2013 21:03:16 +0000 Subject: hg: jdk8/tl/jdk: 6251788: (rb) PropertyResourceBundle doesn't document exceptions Message-ID: <20130528210343.3E15D48DA6@hg.openjdk.java.net> Changeset: b99d56d1aa3f Author: naoto Date: 2013-05-28 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b99d56d1aa3f 6251788: (rb) PropertyResourceBundle doesn't document exceptions Reviewed-by: okutsu ! src/share/classes/java/util/PropertyResourceBundle.java From martinrb at google.com Tue May 28 21:14:48 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 14:14:48 -0700 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <51A306CF.9070605@oracle.com> References: <519F9186.8040000@oracle.com> <51A306CF.9070605@oracle.com> Message-ID: On Mon, May 27, 2013 at 12:10 AM, David Holmes wrote: > > atomic/package-info.java: the URL updates (to oracle.com) have been > regressed to java.sun.com :( > > Doug's CVS has been updated to link to the jdk7 edition of the jls. This improves on the version in openjdk proper by removing stale references to "Third Edition". ./share/classes/java/util/concurrent/locks/Lock.java:125: * The Java Language Specification, Third Edition (17.4 Memory Model): ./share/classes/java/util/concurrent/atomic/package-info.java:99: * The Java Language Specification, Third Edition (17.4 Memory Model): From martinrb at google.com Tue May 28 21:26:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 14:26:19 -0700 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> References: <519F9186.8040000@oracle.com> <60F6D34E-8099-46D8-9DC5-723558442640@oracle.com> Message-ID: On Fri, May 24, 2013 at 8:17 PM, Mike Duigou wrote: > > - It was surprising (and somewhat disappointing) to see changes like the > following in various places. Is iterator creation that expensive? I'd hate > to have to go back to using old style for loops everywhere. > > - List> futures = new ArrayList>(tasks.size()); > + ArrayList> futures = new > ArrayList>(tasks.size()); > > Why not 'List> futures = new ArrayList<>(tasks.size());' ? > > and > > - for (Future f : futures) > - f.cancel(true); > + for (int i = 0, size = futures.size(); i < size; i++) > + futures.get(i).cancel(true); > > Use forEach(f -> { f.cancel(true);}) ? > I don't think we want to use higher-level constructs in the implementation of core libraries until all the popular VM implementations make the overhead unmeasurably small, which is unlikely to happen - at least here, where the cost is only a few bytes, not lines, of code. Elsewhere, I am also on the side of trying to persuade Doug to write slightly less extreme code. From aleksey.shipilev at oracle.com Tue May 28 21:26:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 29 May 2013 01:26:28 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> Message-ID: <51A52104.10509@oracle.com> On 05/29/2013 12:38 AM, Martin Buchholz wrote: > Tricky stuff! You bet! Thanks for the review! I'll wait for more reviews, and update the webrev. > We don't use closing html tags for things like

                  in javadoc. Ok, JDK 8 doclint does not like self-closing entities, and leaving unterminated

                  seems dodgy. Should I revert to

                  to demarcate the start of paragraph? > + * in concurrent contexts in which each instance of the annotated > + * object is often accessed by a different thread.

                  > > Hmmm... makes it sound like it applies even if each instance is > thread-confined (in a different thread) or is immutable. I think all the magic of ignoring @C when VM can prove the instance/fields would not experience contention, should be omitted from the documentation. The practical considerations also apply: since we can not at the moment retransform the class after the publication, it seems a good idea to treat all instances as potentially shared. This eases the reasoning (and documentation) significantly. > "objects" are not annotated. Yes, should be "instances". > Maybe "instances of the annotated class are frequently accessed by > multiple threads and have fields that are frequently written". "Accessed" matters there. False sharing also happens on reads. Also, the innocent read-only classes sometimes also need the protection from the adjacent writers' racket :) > Subclassing makes things tricky. I think it would be pretty common to > want a subclass field to be in the same contention group as a superclass > contention group. Unfortunately, this falls out from being practical. When the superclass fields are already laid out, it is generally too late to squeeze the subclass fields in there. > however, remain in force for all > + * superclass and subclass instances > > > "remain in force for superclass instances" doesn't make sense to me. Do > you mean "remain in force when fields are inherited in subclasses" Yes, that sounds better! > Do we want final fields to be explicitly exempt from being treated as > contended? Or is that Quality of Implementation? Do we want to insert > the word "non-final" in "all the unannotated fields" "final" does not sound to be eligible for any exemption. It is totally fine for the final field to be @Contended, if we want to protect it from being disturbed by the adjacent writes. Although users would probably mark the writable fields in most of the cases, think about the case where I should not absolutely-under-no-curcumstances have the false shared read of the final field. -Aleksey. From martinrb at google.com Tue May 28 21:33:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 14:33:52 -0700 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: <51A306CF.9070605@oracle.com> References: <519F9186.8040000@oracle.com> <51A306CF.9070605@oracle.com> Message-ID: On Mon, May 27, 2013 at 12:10 AM, David Holmes wrote: > > FutureTask.java: the indentation of the changed code is all wrong. > That must be an artifact of the webrev generation (ignoring lines with only whitespace changes?). I don't think the actual code is mis-formatted. From huizhe.wang at oracle.com Tue May 28 22:47:08 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 28 May 2013 15:47:08 -0700 Subject: AutoCloseable XMLStreamReader and XMLStreamWriter? In-Reply-To: <51A50936.4090108@gmx.net> References: <51A1EC42.1000407@gmx.net> <51A31C08.5000909@oracle.com> <51A50936.4090108@gmx.net> Message-ID: <51A533EC.8060900@oracle.com> The JSR 206 spec did not have such requirement, but the RIs of JSR 206/173 still support JDK5. We stopped supporting JDK 1.4 in 2009 in order to move up to features introduced in JDK5. It may be time to consider again. However, even if we do, I think we should move up to JDK6. It may be too steep to move to JDK7. The new features introduced in JEP-185 will not be backported into older JDKs, but it won't change the source level. I saw your email now to users at sjsxp. It sill functions, but like you said, it's "almost" dead since no one is using it :-). Openjdk aliases are the right place for discussions concerning JAXP. Thanks, Joe On 5/28/2013 12:44 PM, Philippe Marschall wrote: > > > On 27.05.2013 10:40, Alan Bateman wrote: >> On 26/05/2013 12:04, Philippe Marschall wrote: >>> Hi >>> >>> It would be nice if javax.xml.stream.XMLStreamReader and >>> javax.xml.stream.XMLStreamWriter could be made to extend >>> java.lang.AutoCloseable so that they can be used in a >>> try-with-resouces statement. The some does for XMLEventReader and >>> XMLEventReader. >> I don't recall if this one has come up before (there were lots of >> candidates identified for retrofitting when AutoCloseable was added) but >> the XML APIs have the complication that they are a "Standalone >> Technology". > > Yes and JEP-185 doesn't make it less confusing. > >> I don't know how far back JSR-206/173 needs to be support >> but if you retrofit these interfaces to extend AutoCloseable then it >> would rule out usage with jdk6. Joe Wang might know about about this. > > Is he watching this list or should I contact him otherwise? > > Cheers > Philippe From huizhe.wang at oracle.com Tue May 28 23:25:46 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 28 May 2013 16:25:46 -0700 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A4BF7B.8040206@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> <51A4BF7B.8040206@oracle.com> Message-ID: <51A53CFA.4000008@oracle.com> Hi Aleksej, Please note that in jdk8 repo, we've added jdk/test/javax/xml/jaxp to hold all new tests for jaxp. All of the existing tests will be migrated to this place in the future. In your case, the new test can be created under a new folder jdk/test/javax/xml/jaxp/XPath/8009579. Daniel's change request 8008738 will also add that in JDK7 repo., so please coordinate with Daniel when your patch is ready for JDK7. I noticed that you're using the 'backport' bug id for this review. According to the process, all commits shall use the main ID. Thanks, Joe On 5/28/2013 7:30 AM, Aleksej Efimov wrote: > Jason, > You are absolutely right and my fault that I didn't tested the > compatibility of new/old versions. > I have tested it with JDK 8(without fix) as a serializer and JDK 8 > (with fix) as deserializer. The behavior was as you expected. Thanks > for catching it. > I'll wait for other comments before generating another webrev. > > Aleksej > > On 05/28/2013 05:41 PM, Jason Mehrens wrote: >> > Alan, David, >> > thank you for comments - I also agree with all of them. And as a >> result v3: >> > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ >> > >> I think this looks better. I assume that since the >> super.getCause() is >> > >> null that there is no need to handle IllegalStateException now. >> >> You can still generate a ISE inside readObject by performing "new >> XPathException(new Exception()).initCause(null)" in the old code and >> then reading that in the new patch. In the new code that line would >> fail fast. >> >> Jason > From martinrb at google.com Wed May 29 00:28:28 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 17:28:28 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A52104.10509@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> Message-ID: On Tue, May 28, 2013 at 2:26 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 05/29/2013 12:38 AM, Martin Buchholz wrote: > > > We don't use closing html tags for things like

                  in javadoc. > > Ok, JDK 8 doclint does not like self-closing entities, and leaving > unterminated

                  seems dodgy. Should I revert to

                  to demarcate the > start of paragraph? > > Yeah, we have the same problem with javadoc issuing very verbose warnings. I've been ignoring/filtering them and hoping they get fixed before jdk8 ships. > > + * in concurrent contexts in which each instance of the annotated > > + * object is often accessed by a different thread.

                  > > > > Hmmm... makes it sound like it applies even if each instance is > > thread-confined (in a different thread) or is immutable. > > I think all the magic of ignoring @C when VM can prove the > instance/fields would not experience contention, should be omitted from > the documentation. The practical considerations also apply: since we can > not at the moment retransform the class after the publication, it seems > a good idea to treat all instances as potentially shared. This eases the > reasoning (and documentation) significantly. > > > "objects" are not annotated. > > Yes, should be "instances". > > I was thinking "classes, not objects, are annotated". > > Maybe "instances of the annotated class are frequently accessed by > > multiple threads and have fields that are frequently written". > > "Accessed" matters there. False sharing also happens on reads. Also, the > innocent read-only classes sometimes also need the protection from the > adjacent writers' racket :) > > Hmmm... tricky ... This also then applies to pure immutable popular objects like Boolean.TRUE. But you want those kinds of objects to all be colocated and tightly packed with other such objects, not give each of them their own cache line. > > Subclassing makes things tricky. I think it would be pretty common to > > want a subclass field to be in the same contention group as a superclass > > contention group. > > Unfortunately, this falls out from being practical. When the superclass > fields are already laid out, it is generally too late to squeeze the > subclass fields in there. > > Sounds like a Quality of Implementation issue. In general, I think you *DO* want the subclass fields to be potentially in the same location as the superclass padding fields. A >: B A layout: ppppaaaapppp B layout: ppppaaaabbbbpppp which is not asking too much of a jit. I believe it is already common for VMs to allocate subclass fields in natural padding space of superclasses. > however, remain in force for all > > + * superclass and subclass instances > > > > > > "remain in force for superclass instances" doesn't make sense to me. Do > > you mean "remain in force when fields are inherited in subclasses" > > Yes, that sounds better! > > > Do we want final fields to be explicitly exempt from being treated as > > contended? Or is that Quality of Implementation? Do we want to insert > > the word "non-final" in "all the unannotated fields" > > "final" does not sound to be eligible for any exemption. It is totally > fine for the final field to be @Contended, if we want to protect it from > being disturbed by the adjacent writes. Although users would probably > mark the writable fields in most of the cases, think about the case > where I should not absolutely-under-no-curcumstances have the false > shared read of the final field. > Good point. I can imagine an "unpopular field" annotation that would allow a field to be used __as__ a pad inside an otherwise contended class. Or unpopular objects can be packed into the same cache line as contended objects. Software is hard. From dan.xu at oracle.com Wed May 29 00:36:13 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 May 2013 17:36:13 -0700 Subject: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently In-Reply-To: <519F743A.5020509@oracle.com> References: <5134DAB8.1070003@oracle.com> <5134DC6D.5010905@oracle.com> <51401CA3.30407@oracle.com> <516E42D6.5020309@oracle.com> <519EEA61.2050400@oracle.com> <519F743A.5020509@oracle.com> Message-ID: <51A54D7D.8050202@oracle.com> On 05/24/2013 07:07 AM, Alan Bateman wrote: > On 24/05/2013 05:19, Eric Wang wrote: >> Hi Dan & All, >> >> I have updated the test based on your comments, Can you please review >> the fix? Thanks! >> http://cr.openjdk.java.net/~ewang/8009258/webrev.02/ > I think this is okay. Dan is going to sponsor this one. > > -Alan Hi Eric, The changes look good. I am going to push it for you today. Thanks for your effort! -Dan From martinrb at google.com Wed May 29 01:23:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 18:23:56 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <519341BC.2000702@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> Message-ID: [+compiler-dev] On Wed, May 15, 2013 at 1:05 AM, David Holmes wrote: > On 15/05/2013 3:16 PM, Martin Buchholz wrote: > >> >> >> General purpose library code sometimes would like to rethrow an >> exception that was previously caught. >> How should it do that? >> > > Umm catch it and throw it. If it is a checked-exception that you want to > propogate then you should have declared it on your method, else you are > going to wrap it in a runtime exception or error. There is no need for such > sleaze. > > Taking a closer look at one use of Thread.stop, I see that we use it to throw a Throwable out of Callable.call. Which I think we should be able to do. But I can't. cat CallableThrow.java && javac CallableThrow.java public class CallableThrow { public static void main(String[] args) throws Throwable { final Throwable t = new Throwable(); new java.util.concurrent.Callable() { public Void call() throws Exception { throw t; }}; } } CallableThrow.java:5: error: unreported exception Throwable; must be caught or declared to be thrown public Void call() throws Exception { throw t; }}; ^ 1 error If I change Exception to Throwable I get: public class CallableThrow { public static void main(String[] args) throws Throwable { final Throwable t = new Throwable(); new java.util.concurrent.Callable() { public Void call() throws Throwable { throw t; }}; } } CallableThrow.java:5: error: call() in cannot implement call() in Callable public Void call() throws Throwable { throw t; }}; ^ overridden method does not throw Throwable where V is a type-variable: V extends Object declared in interface Callable 1 error From david.holmes at oracle.com Wed May 29 01:31:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 11:31:16 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51A4AC3F.2050200@univ-mlv.fr> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> Message-ID: <51A55A64.8060908@oracle.com> On 28/05/2013 11:08 PM, Remi Forax wrote: > On 05/28/2013 02:48 PM, David Holmes wrote: >> Sorry it didn't register that getName() already returns a String - >> hence the toString() is redundant - but minimally so. >> >> David > > The second call to toString() also performs an implicit nullcheck > (elementName can not be null). > So if we have to fix something, it's only to remove the call to > toString() after the call to getName(). Good catch Remi! Otavio: I don't want to dissuade you from getting involved but as Remi indicates your suggested change becomes simply - super(annotationType.getName().toString() + + super(annotationType.getName() + and this is such a minor change to interpreted performance (the JIT will remove the toString call) that I don't think it is worth the process overhead (testing etc) to actually make this change. As I said in other email sometimes there are non-obvious reasons (like null checks :) ) that code has to be kept in its current form. David ----- > cheers, > R?mi > >> >> On 28/05/2013 9:15 PM, David Holmes wrote: >>> Please see my reply under your original subject line. >>> >>> This is not a bug. >>> >>> David >>> >>> On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: >>>> diff --git >>>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>>> >>>> >>>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>>> >>>> >>>> --- >>>> a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>>> >>>> >>>> +++ >>>> b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java >>>> >>>> >>>> @@ -55,9 +55,9 @@ >>>> public IncompleteAnnotationException( >>>> Class annotationType, >>>> String elementName) { >>>> - super(annotationType.getName().toString() + >>>> + super(annotationType.getName() + >>>> " missing element " + >>>> - elementName.toString()); >>>> + elementName); >>>> >>>> this.annotationType = annotationType; >>>> this.elementName = elementName; >>>> >>>> > From david.holmes at oracle.com Wed May 29 01:40:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 11:40:00 +1000 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> Message-ID: <51A55C70.4070403@oracle.com> On 28/05/2013 11:41 PM, Jason Mehrens wrote: >> Alan, David, >> thank you for comments - I also agree with all of them. And as a result v3: >> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ >>>> I think this looks better. I assume that since the super.getCause() is >>>> null that there is no need to handle IllegalStateException now. > > You can still generate a ISE inside readObject by performing "new XPathException(new Exception()).initCause(null)" in the old code and then reading that in the new patch. In the new code that line would fail fast. So what should the result of this be given that the original exception has an inconsistent state (two 'causes')? David > Jason > > From david.holmes at oracle.com Wed May 29 01:43:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 11:43:24 +1000 Subject: Time to put a stop to Thread.stop? In-Reply-To: References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> Message-ID: <51A55D3C.4010601@oracle.com> On 29/05/2013 11:23 AM, Martin Buchholz wrote: > [+compiler-dev] > > > On Wed, May 15, 2013 at 1:05 AM, David Holmes wrote: > >> On 15/05/2013 3:16 PM, Martin Buchholz wrote: >> >>> >>> >>> General purpose library code sometimes would like to rethrow an >>> exception that was previously caught. >>> How should it do that? >>> >> >> Umm catch it and throw it. If it is a checked-exception that you want to >> propogate then you should have declared it on your method, else you are >> going to wrap it in a runtime exception or error. There is no need for such >> sleaze. >> >> > Taking a closer look at one use of Thread.stop, I see that we use it to > throw a Throwable out of Callable.call. Which I think we should be able to > do. But I can't. Why do you think you should be able to throw an arbitrary Throwable from Callable.call? > cat CallableThrow.java && javac CallableThrow.java > > public class CallableThrow { > public static void main(String[] args) throws Throwable { > final Throwable t = new Throwable(); > new java.util.concurrent.Callable() { > public Void call() throws Exception { throw t; }}; > } > } > CallableThrow.java:5: error: unreported exception Throwable; must be caught > or declared to be thrown > public Void call() throws Exception { throw t; }}; > ^ > 1 error > > > If I change Exception to Throwable I get: > > public class CallableThrow { > public static void main(String[] args) throws Throwable { > final Throwable t = new Throwable(); > new java.util.concurrent.Callable() { > public Void call() throws Throwable { throw t; }}; > } > } > CallableThrow.java:5: error: call() in cannot > implement call() in Callable > public Void call() throws Throwable { throw t; }}; > ^ > overridden method does not throw Throwable > where V is a type-variable: > V extends Object declared in interface Callable > 1 error All correct. You can't do this. David From xuelei.fan at oracle.com Wed May 29 01:48:31 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 29 May 2013 01:48:31 +0000 Subject: hg: jdk8/tl/jdk: 8010815: some constructors issues in com.sun.jndi.toolkit Message-ID: <20130529014906.C8A5548DBA@hg.openjdk.java.net> Changeset: 1652a22cf6e7 Author: xuelei Date: 2013-05-28 18:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652a22cf6e7 8010815: some constructors issues in com.sun.jndi.toolkit Reviewed-by: alanb ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java From david.holmes at oracle.com Wed May 29 01:50:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 11:50:04 +1000 Subject: RFR JDK-8015299 In-Reply-To: <51A4AC17.5000607@oracle.com> References: <519F8168.7000505@oracle.com> <51A2CCE9.9070406@oracle.com> <51A4AC17.5000607@oracle.com> Message-ID: <51A55ECC.3030404@oracle.com> Looks good to me. David On 28/05/2013 11:07 PM, John Zavgren wrote: > Greetings: > > I fixed the comment line... to correct the "nul", "NULL", "NUL" issue > and I disambiguated the readlink() issue. > > Thanks! > John > > On 05/26/2013 11:03 PM, David Holmes wrote: >> I concur with Martin on all counts. >> >> Confusing NUL and NULL is also a pet peeve of mine :) >> >> David >> >> On 25/05/2013 2:15 AM, Martin Buchholz wrote: >>> Hi John, >>> >>> The memory leak fix looks good. >>> --- >>> IIRC I was the author of the comment, so it is not surprising that I >>> might >>> prefer that version. "nul" is ___not___ a typo for NULL. It makes no >>> sense to speak of character arrays being NULL-terminated. It also isn't >>> quite right to say that readlink "generates" an array - it simply writes >>> into one. >>> >>> However, it is more correct to spell "nul" "NUL" as in ASCII(7). >>> >>> If you wanted to be more precise about which readlink, you could write >>> readlink(2) instead of readlink() to disambiguate from readlink(1) >>> >>> >>> On Fri, May 24, 2013 at 8:04 AM, John Zavgren >>> wrote: >>> >>>> Greetings: >>>> >>>> I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** >>>> solinux.c >>>> and I posted a webrev image of the changes at: >>>> http://cr.openjdk.java.net/~**jzavgren/8015299/webrev.01/< >>>> >>>> http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/ >>>> >>>>> >>>> >>>> (I also edited a comment.) >>>> >>>> Thanks! >>>> John >>>> >>>> -- >>>> John Zavgren >>>> john.zavgren at oracle.com >>>> 603-821-0904 >>>> US-Burlington-MA >>>> >>>> > > From martinrb at google.com Wed May 29 02:35:06 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 19:35:06 -0700 Subject: Time to put a stop to Thread.stop? In-Reply-To: <51A55D3C.4010601@oracle.com> References: <5192494F.6040609@oracle.com> <59177943caf347f288884ad9a04fdeb9@mane.sumatrasoftware.com> <5192FE65.2000304@oracle.com> <519341BC.2000702@oracle.com> <51A55D3C.4010601@oracle.com> Message-ID: On Tue, May 28, 2013 at 6:43 PM, David Holmes wrote: > On 29/05/2013 11:23 AM, Martin Buchholz wrote: > >> [+compiler-dev] >> >> >> On Wed, May 15, 2013 at 1:05 AM, David Holmes ** >> wrote: >> >> On 15/05/2013 3:16 PM, Martin Buchholz wrote: >>> >>> >>>> >>>> General purpose library code sometimes would like to rethrow an >>>> exception that was previously caught. >>>> How should it do that? >>>> >>>> >>> Umm catch it and throw it. If it is a checked-exception that you want to >>> propogate then you should have declared it on your method, else you are >>> going to wrap it in a runtime exception or error. There is no need for >>> such >>> sleaze. >>> >>> >>> Taking a closer look at one use of Thread.stop, I see that we use it to >> throw a Throwable out of Callable.call. Which I think we should be able >> to >> do. But I can't. >> > > Why do you think you should be able to throw an arbitrary Throwable from > Callable.call? > > Oops. It turns out I didn't know the definition of "checked exception". """ The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are all subclasses of Throwable other than RuntimeException and its subclasses and Error and its subclasses. """ So it's part of the contract of Callable that it must not throw a new Throwable(). Which surprises me. From jason_mehrens at hotmail.com Wed May 29 02:54:08 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 28 May 2013 21:54:08 -0500 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A55C70.4070403@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>,,<517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>,,<518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>,<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>,<51A49D6B.3020407@oracle.com> , <51A55C70.4070403@oracle.com> Message-ID: >> You can still generate a ISE inside readObject by performing "new XPathException(new Exception()).initCause(null)" in the old code and then reading that in the new patch. In the new code that line would fail fast. > > So what should the result of this be given that the original exception > has an inconsistent state (two 'causes')? > Maybe catch ISE and throw InvalidObjectException or StreamCorruptedException? Jason From david.holmes at oracle.com Wed May 29 03:02:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 13:02:59 +1000 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A52104.10509@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> Message-ID: <51A56FE3.5060707@oracle.com> On 29/05/2013 7:26 AM, Aleksey Shipilev wrote: > On 05/29/2013 12:38 AM, Martin Buchholz wrote: >> however, remain in force for all >> + * superclass and subclass instances >> >> >> "remain in force for superclass instances" doesn't make sense to me. Do >> you mean "remain in force when fields are inherited in subclasses" > > Yes, that sounds better! That is why I removed the reference to superclass in my re-wording. Only subclassing needs to be explained. David ----- From martinrb at google.com Wed May 29 03:17:50 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 20:17:50 -0700 Subject: Windows command line processing In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C30136763B76F3@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C30136763B76F3@USEA-EXCH7.na.uis.unisys.com> Message-ID: One historical reason for this class of bugs was the historic support for Windows98 family, which made it much harder to switch to the correct "W" Unicode APIs. Today Windows98 is no longer supported, so some things may appear easy or at least easier. On Thu, May 23, 2013 at 6:59 AM, Salter, Thomas A wrote: > I've observed issues with passing non-ASCII characters through the command > line to a Java program on Windows. It seems that even though I can invoke > java.exe through CreateProcess, passing a full range of Unicode characters, > and even though the Java main accepts strings of Unicode characters, the > launcher's C main function converts the Unicode to the local ANSI code > page. Thus any characters not in the local code page are lost. This seems > like a bug to me. > > As a proof of concept, I changed jdk/src/share/bin/main.c to call > GetCommanLineW instead of GetCommandLine, and then converted that string to > UTF-8. For my test, I set sun.jnu.encoding to UTF-8 so that > makePlatformString in LauncherHelper would just work. > > ------------------------------------- > Tom Salter | Software Engineer | Java & Middleware Development > Unisys | 2476 Swedesford Road | Malvern, PA 19355 | 610-648-2568| N385-2568 > > > > From martinrb at google.com Wed May 29 03:36:50 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 20:36:50 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: <519FBDDC.2030806@oracle.com> References: <519FBDDC.2030806@oracle.com> Message-ID: Looks good to me. --- While you're moving code around, you could fix the typo below and change method comments to javadoc style ('*' => '**'') accidnetly and From david.holmes at oracle.com Wed May 29 04:00:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 14:00:33 +1000 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: <51A57D61.20608@oracle.com> Martin, On 29/05/2013 5:53 AM, Martin Buchholz wrote: > Is atomicity part of the contract of ConcurrentMap.getOrDefault? > Currently, it doesn't say. > Actually, there are two possible guarantees it could make - whether the > default implementation ConcurrentMap.getOrDefault is atomic (when the map > does not accept nulls) and whether subclasses that override getOrDefault > must make this guarantee. I want to re-examine the new methods that ConcurrentMap is inheriting from Map because I think more statements regarding concurrency properties are required. This included getOrDefault even though overridden. > --- > > Curiously, ConcurrentMap doesn't guarantee that get() is atomic. Perhaps > it should? Only composite operations (those that could expressed as a sequence of other operations) need an atomicity guarantee. Operations like get() simply need to be thread-safe. Actually I think we have wandered off-track a little with the use of "atomic" in these API's. To say that a method is "atomic" is pretty meaningless for most map methods. Where it gets meaning is when we say that an operation, like putIfAbsent, acts "as-if xxxx then yyyy, except that it is performed atomically". David ----- > --- > From david.holmes at oracle.com Wed May 29 04:06:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 14:06:13 +1000 Subject: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155 In-Reply-To: References: <519F9186.8040000@oracle.com> <51A306CF.9070605@oracle.com> Message-ID: <51A57EB5.1000000@oracle.com> On 29/05/2013 7:33 AM, Martin Buchholz wrote: > On Mon, May 27, 2013 at 12:10 AM, David Holmes > wrote: > > FutureTask.java: the indentation of the changed code is all wrong. > > That must be an artifact of the webrev generation (ignoring lines with > only whitespace changes?). I don't think the actual code is mis-formatted. No it was a mistake on my part. I thought the new code was meant to be in the if block but it isn't actually a block. David From mike.duigou at oracle.com Wed May 29 04:13:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 May 2013 21:13:35 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A50DA1.8060502@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> Message-ID: <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> Hashtable/WeakHashMap:: - I assume that the JVM falls over dead if the security manager doesn't allow access to the property, correct? I hadn't considered what should happen in the event of a security exception when I originally copied the GetPropertyAction idiom from elsewhere in the JDK. Perhaps add a security manager test to CheckRandomHashSeed? Or two if we want to make sure that - initHashSeed could now return the value with assignment happening in the constructor if we wanted to make hashSeed final. This would mean the unsafe stuff would have to return in Hashtable/HashMap to allow for deserialization. HashMap:: - TreeBin.comparableClassFor() includes "see above for explanation." but it's not clear where that explanation is. - I was really worried about the cost and correctness issues with changing null key handling. I have now put my mind at ease. All of the cases I could think of seem to be handled. - I've spent less time in this round looking at the new Map default operations. Hashing:: - Do we know if ThreadLocalRandom requires that the VM be booted? It may be possible to remove even more stuff here. InPlaceOpsCollisions:: - The @run directives run the wrong class (an error I have made myself...). Mike On May 28 2013, at 13:03 , Brent Christian wrote: > On 5/28/13 3:09 AM, Doug Lea wrote: >> >> To better enable and simplify future improvements, could you >> do this -- nest the tree classes within HashMap? > > Done. > >> Also, a note on spliterators: I had added these in the >> least disruptive way (knowing that major changes were coming) >> by checking exact class match for HashMap.class. This is because >> there aren't LinkedHashMap view classes to attach overrides to. >> While not wrong, and OK for now, at some point this should be redone. > > OK. I will file a bug so this doesn't get forgotten. > > > I also applied the change to how HashMap.putAll() resizes the table (to account for splitTreeBin() only handling doubling of tables). > > The updated webrev is here: > > http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ > > Thanks, > -Brent From martinrb at google.com Wed May 29 04:29:20 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 May 2013 21:29:20 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A57D61.20608@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A57D61.20608@oracle.com> Message-ID: On Tue, May 28, 2013 at 9:00 PM, David Holmes wrote: > Martin, > > > On 29/05/2013 5:53 AM, Martin Buchholz wrote: > >> Is atomicity part of the contract of ConcurrentMap.getOrDefault? >> Currently, it doesn't say. >> Actually, there are two possible guarantees it could make - whether the >> default implementation ConcurrentMap.getOrDefault is atomic (when the map >> does not accept nulls) and whether subclasses that override getOrDefault >> must make this guarantee. >> > > I want to re-examine the new methods that ConcurrentMap is inheriting from > Map because I think more statements regarding concurrency properties are > required. This included getOrDefault even though overridden. > > Agreed. > > --- >> >> Curiously, ConcurrentMap doesn't guarantee that get() is atomic. Perhaps >> it should? >> > > Only composite operations (those that could expressed as a sequence of > other operations) need an atomicity guarantee. Operations like get() simply > need to be thread-safe. > You're right. Let me rephrase: Curiously, ConcurrentMap doesn't guarantee that get() is thread-safe, or that a ConcurrentMap can be used from multiple threads. Perhaps it should? From dan.xu at oracle.com Wed May 29 05:25:24 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 29 May 2013 05:25:24 +0000 Subject: hg: jdk8/tl/jdk: 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Message-ID: <20130529052537.1FE4848DBF@hg.openjdk.java.net> Changeset: e59d7f0f36f7 Author: ewang Date: 2013-05-28 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59d7f0f36f7 8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently Reviewed-by: dxu, alanb Contributed-by: yiming.wang at oracle.com ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java From staffan.larsen at oracle.com Wed May 29 07:43:11 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 29 May 2013 07:43:11 +0000 Subject: hg: jdk8/tl/jdk: 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Message-ID: <20130529074332.6E97C48DC3@hg.openjdk.java.net> Changeset: bd6d3801347b Author: sla Date: 2013-05-29 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6d3801347b 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Summary: Make sure serial gc compacts heap every time Reviewed-by: mchung, brutisso, nloodin ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java From victor2 at ukr.net Wed May 29 07:51:45 2013 From: victor2 at ukr.net (Victor Polischuk) Date: Wed, 29 May 2013 10:51:45 +0300 Subject: Generics in enums Message-ID: <35026.1369813905.3344587357756915712@ffe16.ukr.net> Greetings, > > Some time ago I wanted to migrate our "commons-lang" enums to "java 5" enumerations, but I encountered an issue that it cannot be done without discarding generics since java enums do not support them. Let me show an example: > //------ > public final class ColorEnum extends org.apache.commons.lang.enums.Enum { public static final ColorEnum RED = new ColorEnum("Red"); public static final ColorEnum GREEN = new ColorEnum("Green"); public static final ColorEnum BLUE = new ColorEnum("Blue"); public static final ColorEnum WHITE = new ColorEnum("White") { > @Override > public MixedPixel make() {...} > }; private ColorEnum(String color) {super(color);} > > public boolean filter(T pixel) {...} > > public T make() {...} } > //------ > And I wonder if there is a specific reason why I cannot convert it into something like: > //------ > > public enum Color { RED("Red"), GREEN("Green"), > BLUE ("Blue"), > WHITE("White") { > > @Override > public MixedPixel make() {...} > }; private Color(String color) {...} > > public boolean filter(T pixel) {...} > > public T make() {...} } > //------ Thank you in advance. > > > Sincerely yours, > Victor Polischuk > From david.holmes at oracle.com Wed May 29 08:40:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 18:40:29 +1000 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A57D61.20608@oracle.com> Message-ID: <51A5BEFD.20303@oracle.com> On 29/05/2013 2:29 PM, Martin Buchholz wrote: > On Tue, May 28, 2013 at 9:00 PM, David Holmes > wrote: > On 29/05/2013 5:53 AM, Martin Buchholz wrote: > > Is atomicity part of the contract of ConcurrentMap.getOrDefault? > Currently, it doesn't say. > Actually, there are two possible guarantees it could make - > whether the > default implementation ConcurrentMap.getOrDefault is atomic > (when the map > does not accept nulls) and whether subclasses that override > getOrDefault > must make this guarantee. > > > I want to re-examine the new methods that ConcurrentMap is > inheriting from Map because I think more statements regarding > concurrency properties are required. This included getOrDefault even > though overridden. > > > Agreed. > > > --- > > Curiously, ConcurrentMap doesn't guarantee that get() is atomic. > Perhaps it should? > > > Only composite operations (those that could expressed as a sequence > of other operations) need an atomicity guarantee. Operations like > get() simply need to be thread-safe. > > > You're right. Let me rephrase: > > Curiously, ConcurrentMap doesn't guarantee that get() is thread-safe, or > that a ConcurrentMap can be used from multiple threads. Perhaps it should? Right. I find this: * A {@link java.util.Map} providing additional atomic * {@code putIfAbsent}, {@code remove}, and {@code replace} methods. rather lacking looking at it today. First the list needs updating - though it was suggested by Doug that we stop listing the methods and simply make a general statement. Somewhat disturbingly I now see that some of the new Map methods may not in fact be "atomic". Second it says nothing about thread-safety. The only reference to thread-safety is in the j.u.c package-info docs: " A concurrent collection is thread-safe, but not governed by a single exclusion lock." I went back to my email archives from when we put this altogether back in 2002/2003 and I found no reference to ever actually saying in ConcurrentMap that the Map was thread-safe. This may in part be because what we called ConcurrentMap simply started out as an interface in which to put putIfAbsent and we really only cared about the fact that ConcurrentHashMap would implement it - and we couldn't call it Map. David From alan.bateman at oracle.com Wed May 29 09:28:15 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 29 May 2013 09:28:15 +0000 Subject: hg: jdk8/tl/jdk: 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read Message-ID: <20130529092901.8F87148DCF@hg.openjdk.java.net> Changeset: 2b3242a69a44 Author: alanb Date: 2013-05-29 10:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b3242a69a44 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read Reviewed-by: martin ! src/share/classes/java/nio/file/Files.java From vicente.romero at oracle.com Wed May 29 09:58:03 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 29 May 2013 09:58:03 +0000 Subject: hg: jdk8/tl/langtools: 7053059: VerifyError with double Assignment using a Generic Member of a Superclass Message-ID: <20130529095809.94FF848DD1@hg.openjdk.java.net> Changeset: 92e420e9807d Author: vromero Date: 2013-05-29 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e420e9807d 7053059: VerifyError with double Assignment using a Generic Member of a Superclass Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/T7053059/VerifyErrorWithDoubleAssignmentTest.java From otaviojava at java.net Wed May 29 11:03:40 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Wed, 29 May 2013 08:03:40 -0300 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51A55A64.8060908@oracle.com> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> <51A55A64.8060908@oracle.com> Message-ID: Thank you everyone. I searched classes with this situation and I find these classes: - sun.tools.java.MemberDefinition - sun.rmi.rmic.Main - sun.tools.jconsole.inspector.Utils - com.sun.jndi.toolkit.dir.SearchFilter - javax.swing.text.html.FormView The diffs is in attachment On Tue, May 28, 2013 at 10:31 PM, David Holmes wrote: > On 28/05/2013 11:08 PM, Remi Forax wrote: > >> On 05/28/2013 02:48 PM, David Holmes wrote: >> >>> Sorry it didn't register that getName() already returns a String - >>> hence the toString() is redundant - but minimally so. >>> >>> David >>> >> >> The second call to toString() also performs an implicit nullcheck >> (elementName can not be null). >> So if we have to fix something, it's only to remove the call to >> toString() after the call to getName(). >> > > Good catch Remi! > > Otavio: I don't want to dissuade you from getting involved but as Remi > indicates your suggested change becomes simply > > > - super(annotationType.getName()**.toString() + > + super(annotationType.getName() + > > and this is such a minor change to interpreted performance (the JIT will > remove the toString call) that I don't think it is worth the process > overhead (testing etc) to actually make this change. As I said in other > email sometimes there are non-obvious reasons (like null checks :) ) that > code has to be kept in its current form. > > David > ----- > > > cheers, >> R?mi >> >> >>> On 28/05/2013 9:15 PM, David Holmes wrote: >>> >>>> Please see my reply under your original subject line. >>>> >>>> This is not a bug. >>>> >>>> David >>>> >>>> On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: >>>> >>>>> diff --git >>>>> a/src/share/classes/java/lang/**annotation/** >>>>> IncompleteAnnotationException.**java >>>>> >>>>> >>>>> b/src/share/classes/java/lang/**annotation/** >>>>> IncompleteAnnotationException.**java >>>>> >>>>> >>>>> --- >>>>> a/src/share/classes/java/lang/**annotation/** >>>>> IncompleteAnnotationException.**java >>>>> >>>>> >>>>> +++ >>>>> b/src/share/classes/java/lang/**annotation/** >>>>> IncompleteAnnotationException.**java >>>>> >>>>> >>>>> @@ -55,9 +55,9 @@ >>>>> public IncompleteAnnotationException( >>>>> Class annotationType, >>>>> String elementName) { >>>>> - super(annotationType.getName()**.toString() + >>>>> + super(annotationType.getName() + >>>>> " missing element " + >>>>> - elementName.toString()); >>>>> + elementName); >>>>> >>>>> this.annotationType = annotationType; >>>>> this.elementName = elementName; >>>>> >>>>> >>>>> >> -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From paul.sandoz at oracle.com Wed May 29 11:08:48 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:08:48 +0200 Subject: RFR 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Message-ID: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> Hi, Please review these JavaDoc fixes to j.u.s.StreamBuilder. Paul. # HG changeset patch # User psandoz # Date 1369825073 -7200 # Node ID 303e9d2aff3cbaf27823b2591f2e8570b77afcce # Parent bd6d3801347bfd912507d16dc14488f47e94e626 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: diff -r bd6d3801347b -r 303e9d2aff3c src/share/classes/java/util/stream/StreamBuilder.java --- a/src/share/classes/java/util/stream/StreamBuilder.java Wed May 29 09:42:39 2013 +0200 +++ b/src/share/classes/java/util/stream/StreamBuilder.java Wed May 29 12:57:53 2013 +0200 @@ -38,7 +38,7 @@ *

                  A {@code StreamBuilder} has a lifecycle, where it starts in a building * phase, during which elements can be added, and then transitions to a built * phase, after which elements may not be added. The built phase begins - * when the {@link #build()}} method is called, which creates an ordered + * when the {@link #build()} method is called, which creates an ordered * {@code Stream} whose elements are the elements that were added to the stream * builder, in the order they were added. * @@ -98,7 +98,7 @@ *

                  A stream builder has a lifecycle, where it starts in a building * phase, during which elements can be added, and then transitions to a * built phase, after which elements may not be added. The built phase - * begins when the {@link #build()}} method is called, which creates an + * begins when the {@link #build()} method is called, which creates an * ordered stream whose elements are the elements that were added to the * stream builder, in the order they were added. * @@ -155,7 +155,7 @@ *

                  A stream builder has a lifecycle, where it starts in a building * phase, during which elements can be added, and then transitions to a * built phase, after which elements may not be added. The built phase - * begins when the {@link #build()}} method is called, which creates an + * begins when the {@link #build()} method is called, which creates an * ordered stream whose elements are the elements that were added to the * stream builder, in the order they were added. * @@ -209,6 +209,13 @@ /** * A mutable builder for a {@code DoubleStream}. * + *

                  A stream builder has a lifecycle, where it starts in a building + * phase, during which elements can be added, and then transitions to a + * built phase, after which elements may not be added. The built phase + * begins when the {@link #build()} method is called, which creates an + * ordered stream whose elements are the elements that were added to the + * stream builder, in the order they were added. + * * @see LongStream#builder() * @since 1.8 */ @@ -217,13 +224,6 @@ /** * Adds an element to the stream being built. * - *

                  A stream builder has a lifecycle, where it starts in a building - * phase, during which elements can be added, and then transitions to a - * built phase, after which elements may not be added. The built phase - * begins when the {@link #build()}} method is called, which creates an - * ordered stream whose elements are the elements that were added to the - * stream builder, in the order they were added. - * * @throws IllegalStateException if the builder has already transitioned * to the built state */ From paul.sandoz at oracle.com Wed May 29 11:10:22 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:10:22 +0200 Subject: RFR 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Message-ID: <8EA62D12-E287-4884-968D-D5D2237AB9BB@oracle.com> Hi, Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst. Paul. # HG changeset patch # User psandoz # Date 1369747350 -7200 # Node ID 6be3ce51e61dbdab6766c74223c076a7b3472be6 # Parent 303e9d2aff3cbaf27823b2591f2e8570b77afcce 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: diff -r 303e9d2aff3c -r 6be3ce51e61d src/share/classes/java/util/stream/DoubleStream.java --- a/src/share/classes/java/util/stream/DoubleStream.java Wed May 29 12:57:53 2013 +0200 +++ b/src/share/classes/java/util/stream/DoubleStream.java Tue May 28 15:22:30 2013 +0200 @@ -603,7 +603,7 @@ /** * Returns an {@link OptionalDouble} describing the first element of this * stream (in the encounter order), or an empty {@code OptionalDouble} if - * the stream is empty. If the stream has no encounter order, than any + * the stream is empty. If the stream has no encounter order, then any * element may be returned. * *

                  This is a short-circuiting diff -r 303e9d2aff3c -r 6be3ce51e61d src/share/classes/java/util/stream/IntStream.java --- a/src/share/classes/java/util/stream/IntStream.java Wed May 29 12:57:53 2013 +0200 +++ b/src/share/classes/java/util/stream/IntStream.java Tue May 28 15:22:30 2013 +0200 @@ -588,7 +588,7 @@ /** * Returns an {@link OptionalInt} describing the first element of this * stream (in the encounter order), or an empty {@code OptionalInt} if the - * stream is empty. If the stream has no encounter order, than any element + * stream is empty. If the stream has no encounter order, then any element * may be returned. * *

                  This is a short-circuiting diff -r 303e9d2aff3c -r 6be3ce51e61d src/share/classes/java/util/stream/LongStream.java --- a/src/share/classes/java/util/stream/LongStream.java Wed May 29 12:57:53 2013 +0200 +++ b/src/share/classes/java/util/stream/LongStream.java Tue May 28 15:22:30 2013 +0200 @@ -588,7 +588,7 @@ /** * Returns an {@link OptionalLong} describing the first element of this * stream (in the encounter order), or an empty {@code OptionalLong} if the - * stream is empty. If the stream has no encounter order, than any element + * stream is empty. If the stream has no encounter order, then any element * may be returned. * *

                  This is a short-circuiting diff -r 303e9d2aff3c -r 6be3ce51e61d src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java Wed May 29 12:57:53 2013 +0200 +++ b/src/share/classes/java/util/stream/Stream.java Tue May 28 15:22:30 2013 +0200 @@ -754,7 +754,7 @@ /** * Returns an {@link Optional} describing the first element of this stream * (in the encounter order), or an empty {@code Optional} if the stream is - * empty. If the stream has no encounter order, than any element may be + * empty. If the stream has no encounter order, then any element may be * returned. * *

                  This is a short-circuiting From paul.sandoz at oracle.com Wed May 29 11:12:56 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:12:56 +0200 Subject: RFR 8014731: j.u.stream.StreamSupport class has default constructor generated Message-ID: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> Hi, Please review these changes to j.u.s. StreamSupport to make it final and non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry. Paul. # HG changeset patch # User psandoz # Date 1369825082 -7200 # Node ID bfdc1ed75460c9e6869827cf9acabd4b1a5e9d29 # Parent 6be3ce51e61dbdab6766c74223c076a7b3472be6 8014731: j.u.stream.StreamSupport class has default constructor generated Summary: This change set also fixes broken links Reviewed-by: Contributed-by: Paul Sandoz , Henry Jen diff -r 6be3ce51e61d -r bfdc1ed75460 src/share/classes/java/util/stream/StreamSupport.java --- a/src/share/classes/java/util/stream/StreamSupport.java Tue May 28 15:22:30 2013 +0200 +++ b/src/share/classes/java/util/stream/StreamSupport.java Wed May 29 12:58:02 2013 +0200 @@ -41,7 +41,11 @@ * * @since 1.8 */ -public class StreamSupport { +public final class StreamSupport { + + // Suppresses default constructor, ensuring non-instantiability. + private StreamSupport() {} + /** * Creates a new sequential {@code Stream} from a {@code Spliterator}. * @@ -50,7 +54,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -75,7 +79,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -102,7 +106,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #stream(java.util.Spliterator)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -138,7 +142,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #stream(Spliterator)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -172,7 +176,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)}} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -195,7 +199,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)}} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -220,7 +224,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #intStream(Spliterator.OfInt)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -254,7 +258,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #intStream(Spliterator.OfInt)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -286,7 +290,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -310,7 +314,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -335,7 +339,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #longStream(Spliterator.OfLong)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -369,7 +373,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #longStream(Spliterator.OfLong)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -402,7 +406,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -426,7 +430,7 @@ * *

                  It is strongly recommended the spliterator report a characteristic of * {@code IMMUTABLE} or {@code CONCURRENT}, or be - * late-binding. Otherwise, + * late-binding. Otherwise, * {@link #stream(Supplier, int)} should be used to * reduce the scope of potential interference with the source. See * Non-Interference for @@ -451,7 +455,7 @@ *

                  * For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #doubleStream(Spliterator.OfDouble)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the @@ -485,7 +489,7 @@ * *

                  For spliterators that report a characteristic of {@code IMMUTABLE} * or {@code CONCURRENT}, or that are - * late-binding, it is likely + * late-binding, it is likely * more efficient to use {@link #doubleStream(Spliterator.OfDouble)} instead. * The use of a {@code Supplier} in this form provides a level of * indirection that reduces the scope of potential interference with the From aleksey.shipilev at oracle.com Wed May 29 11:20:12 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 29 May 2013 15:20:12 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> Message-ID: <51A5E46C.5030908@oracle.com> Thanks for the review! On 05/29/2013 04:28 AM, Martin Buchholz wrote: > Yeah, we have the same problem with javadoc issuing very verbose > warnings. I've been ignoring/filtering them and hoping they get fixed > before jdk8 ships. Ok, reverted back to

                  . > > + * in concurrent contexts in which each instance of the annotated > > + * object is often accessed by a different thread.

                  > > > > Hmmm... makes it sound like it applies even if each instance is > > thread-confined (in a different thread) or is immutable. > > I think all the magic of ignoring @C when VM can prove the > instance/fields would not experience contention, should be omitted from > the documentation. The practical considerations also apply: since we can > not at the moment retransform the class after the publication, it seems > a good idea to treat all instances as potentially shared. This eases the > reasoning (and documentation) significantly. > > > "objects" are not annotated. > > Yes, should be "instances". > > I was thinking "classes, not objects, are annotated". Fixed. > > however, remain in force for all >> + * superclass and subclass instances >> >> >> "remain in force for superclass instances" doesn't make sense to me. Do >> you mean "remain in force when fields are inherited in subclasses" > > Yes, that sounds better! Reverted back to David's version. It does sound even cleaner in that version. > > Maybe "instances of the annotated class are frequently accessed by > > multiple threads and have fields that are frequently written". > > "Accessed" matters there. False sharing also happens on reads. Also, the > innocent read-only classes sometimes also need the protection from the > adjacent writers' racket :) > > > Hmmm... tricky ... This also then applies to pure immutable popular > objects like Boolean.TRUE. But you want those kinds of objects to all be > colocated and tightly packed with other such objects, not give each of > them their own cache line. Yes, that's true. I do, however, think we have to have the provisioning for the read-only protected fields/instances. > Sounds like a Quality of Implementation issue. In general, I think you > *DO* want the subclass fields to be potentially in the same location as > the superclass padding fields. > A >: B > A layout: ppppaaaapppp > B layout: ppppaaaabbbbpppp > > which is not asking too much of a jit. > I believe it is already common for VMs to allocate subclass fields in > natural padding space of superclasses. > This gets very tricky even in a slightly complicated case: A >: B A layout: ppppAAppppCCpppp B layout: ppppAABBppCCpppp Note that we can't move CC in B because the fields are bound statically; so we end up ruining the padding for both BB and CC. We can, of course, have the gap in the padding to tolerate this, but before knowing in advance what subclasses will be loaded next, we can not prepare enough; or, we can redefine all the classes up the hierarchy... (Current HotSpot classloader code is completely not ready for things like these). However, implementation issues aside: Allowing contended tags to be inherited will force users to look at the entire hierarchy to search for the colliding tags; or (what's worse) push the superclass maintainers to use cryptic tags so no possible subclasses can collide with the protected fields. IMO, that is way messier than pushing users to aggregate the semantically-close fields in the same class. Hence, I left the inheritance clause as is. The new webrev is here: http://cr.openjdk.java.net/~shade/8014966/webrev.03/ Thanks everyone, writing specs is fun! -Aleksey. From Alan.Bateman at oracle.com Wed May 29 11:34:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 12:34:05 +0100 Subject: RFR 8014731: j.u.stream.StreamSupport class has default constructor generated In-Reply-To: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> References: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> Message-ID: <51A5E7AD.9080203@oracle.com> On 29/05/2013 12:12, Paul Sandoz wrote: > Hi, > > Please review these changes to j.u.s. StreamSupport to make it final and non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry. > > Paul. > This looks okay to me but just to note that making it final is technically an API change to track. -Alan From paul.sandoz at oracle.com Wed May 29 11:35:00 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:35:00 +0200 Subject: RFR 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE Message-ID: <50F2962C-723A-4864-A727-9981ED0128DA@oracle.com> Hi, Please review these changes to j.u.PrimitiveIterator to ensure the default forEachRemaining methods consistently throw an NPE when the consumer is null. I almost produced a webrev for this, but i thought it was just about acceptable size-wise and i hope easy to review in textual form. If this is considered impolite, awkward to review etc please say so and i will produce a webrev. Paul. # HG changeset patch # User psandoz # Date 1369825083 -7200 # Node ID 7ded996200218791c885c0aae4c474066101c7bd # Parent bfdc1ed75460c9e6869827cf9acabd4b1a5e9d29 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE Reviewed-by: diff -r bfdc1ed75460 -r 7ded99620021 src/share/classes/java/util/PrimitiveIterator.java --- a/src/share/classes/java/util/PrimitiveIterator.java Wed May 29 12:58:02 2013 +0200 +++ b/src/share/classes/java/util/PrimitiveIterator.java Wed May 29 12:58:03 2013 +0200 @@ -91,6 +91,7 @@ * @throws NullPointerException if the specified action is null */ default void forEachRemaining(IntConsumer action) { + Objects.requireNonNull(action); while (hasNext()) action.accept(nextInt()); } @@ -123,6 +124,8 @@ forEachRemaining((IntConsumer) action); } else { + // The method reference action::accept is never null + Objects.requireNonNull(action); if (Tripwire.ENABLED) Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfInt.forEachRemainingInt(action::accept)"); forEachRemaining((IntConsumer) action::accept); @@ -162,6 +165,7 @@ * @throws NullPointerException if the specified action is null */ default void forEachRemaining(LongConsumer action) { + Objects.requireNonNull(action); while (hasNext()) action.accept(nextLong()); } @@ -194,6 +198,8 @@ forEachRemaining((LongConsumer) action); } else { + // The method reference action::accept is never null + Objects.requireNonNull(action); if (Tripwire.ENABLED) Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfLong.forEachRemainingLong(action::accept)"); forEachRemaining((LongConsumer) action::accept); @@ -232,6 +238,7 @@ * @throws NullPointerException if the specified action is null */ default void forEachRemaining(DoubleConsumer action) { + Objects.requireNonNull(action); while (hasNext()) action.accept(nextDouble()); } @@ -265,6 +272,8 @@ forEachRemaining((DoubleConsumer) action); } else { + // The method reference action::accept is never null + Objects.requireNonNull(action); if (Tripwire.ENABLED) Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfDouble.forEachRemainingDouble(action::accept)"); forEachRemaining((DoubleConsumer) action::accept); diff -r bfdc1ed75460 -r 7ded99620021 test/java/util/Iterator/PrimitiveIteratorDefaults.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/Iterator/PrimitiveIteratorDefaults.java Wed May 29 12:58:03 2013 +0200 @@ -0,0 +1,115 @@ +/* + * Copyright (c) 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. + * + * 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. + */ + +import org.testng.annotations.Test; + +import java.util.PrimitiveIterator; +import java.util.function.Consumer; +import java.util.function.DoubleConsumer; +import java.util.function.IntConsumer; +import java.util.function.LongConsumer; + +import static org.testng.Assert.assertNotNull; +import static org.testng.Assert.assertTrue; + +/** + * @test + * @run testng PrimitiveIteratorDefaults + * @summary test default methods on PrimitiveIterator + */ + at Test +public class PrimitiveIteratorDefaults { + + public void testIntForEachRemainingWithNull() { + PrimitiveIterator.OfInt i = new PrimitiveIterator.OfInt() { + @Override + public int nextInt() { + return 0; + } + + @Override + public boolean hasNext() { + return false; + } + }; + + executeAndCatch(() -> i.forEachRemaining((IntConsumer) null)); + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); + } + + public void testLongForEachRemainingWithNull() { + PrimitiveIterator.OfLong i = new PrimitiveIterator.OfLong() { + @Override + public long nextLong() { + return 0; + } + + @Override + public boolean hasNext() { + return false; + } + }; + + executeAndCatch(() -> i.forEachRemaining((LongConsumer) null)); + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); + } + + public void testDoubleForEachRemainingWithNull() { + PrimitiveIterator.OfDouble i = new PrimitiveIterator.OfDouble() { + @Override + public double nextDouble() { + return 0; + } + + @Override + public boolean hasNext() { + return false; + } + }; + + executeAndCatch(() -> i.forEachRemaining((DoubleConsumer) null)); + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); + } + + private void executeAndCatch(Runnable r) { + executeAndCatch(NullPointerException.class, r); + } + + private void executeAndCatch(Class expected, Runnable r) { + Exception caught = null; + try { + r.run(); + } + catch (Exception e) { + caught = e; + } + + assertNotNull(caught, + String.format("No Exception was thrown, expected an Exception of %s to be thrown", + expected.getName())); + assertTrue(expected.isInstance(caught), + String.format("Exception thrown %s not an instance of %s", + caught.getClass().getName(), expected.getName())); + } + +} From paul.sandoz at oracle.com Wed May 29 11:36:26 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:36:26 +0200 Subject: RFR 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Message-ID: <3FF25815-046E-49A6-B914-8E72ED5C1E13@oracle.com> Hi, Please review this JavaDoc fixe to j.u.Spliterator.getExactSizeIfKnown. Paul. # HG changeset patch # User psandoz # Date 1369825085 -7200 # Node ID 840469ba82ab8d8238414a5333aa99b8d4035a9b # Parent 7ded996200218791c885c0aae4c474066101c7bd 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Summary: A minor documentation issue (not a spec issue). Reviewed-by: diff -r 7ded99620021 -r 840469ba82ab src/share/classes/java/util/Spliterator.java --- a/src/share/classes/java/util/Spliterator.java Wed May 29 12:58:03 2013 +0200 +++ b/src/share/classes/java/util/Spliterator.java Wed May 29 12:58:05 2013 +0200 @@ -394,9 +394,9 @@ * Convenience method that returns {@link #estimateSize()} if this * Spliterator is {@link #SIZED}, else {@code -1}. * @implSpec - * The default returns the result of {@code estimateSize()} if the - * Spliterator reports a characteristic of {@code SIZED}, and {@code -1} - * otherwise. + * The default implementation returns the result of {@code estimateSize()} + * if the Spliterator reports a characteristic of {@code SIZED}, and + * {@code -1} otherwise. * * @return the exact size, if known, else {@code -1}. */ From dmytro_sheyko at hotmail.com Wed May 29 11:45:54 2013 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 29 May 2013 14:45:54 +0300 Subject: PhantomReference: why not cleared by GC when enqueued? Message-ID: Hello, Why phantom references are not automatically cleared by the garbage collector as they are enqueued? Keeping phantom reachable objects in heap has some drawbacks: 1. At least 2 GC are required in order to reclaim them, even in case when application code pulls references from reference queue and clears them promptly. 2. GC pauses are increased since phantom reachable objects are still to be marked. On the other hand, benefits are not obvious. How we can use referent if it's not accessible? Regards, Dmytro From paul.sandoz at oracle.com Wed May 29 11:49:04 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 13:49:04 +0200 Subject: RFR 8014731: j.u.stream.StreamSupport class has default constructor generated In-Reply-To: <51A5E7AD.9080203@oracle.com> References: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> <51A5E7AD.9080203@oracle.com> Message-ID: <18FD8A88-3FFC-4971-B5FC-5ED6757CF71D@oracle.com> On May 29, 2013, at 1:34 PM, Alan Bateman wrote: > On 29/05/2013 12:12, Paul Sandoz wrote: >> Hi, >> >> Please review these changes to j.u.s. StreamSupport to make it final and non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry. >> >> Paul. >> > This looks okay to me but just to note that making it final is technically an API change to track. > Thanks, i forgot about that, CCC has been kicked off. Paul. From Alan.Bateman at oracle.com Wed May 29 11:54:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 12:54:06 +0100 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51A4F9F5.3090909@oracle.com> References: <51A4F9F5.3090909@oracle.com> Message-ID: <51A5EC5E.7030502@oracle.com> On 28/05/2013 19:39, Dan Xu wrote: > Hi All, > > When File.createTempFile() is called with some special parameters, it > runs into infiniteloop and hangs. It is because it does not always > mean a file exists when the method, createFileExclusively(), returns > false. This fix is going to solve such issues reported in JDK-8013827 > and JDK-8011950.And I also added some testcases to verify it. > > webrev: http://cr.openjdk.java.net/~dxu/8013827/webrev.00/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8011950 > > -Dan Thanks for taking this one. The changes mean that IAE is now thrown for cases where it wasn't thrown previously and I'm wondering if this is worth doing. It might be simpler to just throw IOException on the grounds that creating the file will fail. One other thing to consider is that "\" is a valid name of a file on some platforms. I suspect you'll need to delegate to the FileSystem to check the suffix/prefix. Alternatively in TempDirectory.generateFile you could create a File from prefix/n/suffix and call getName to check that its matches. If not then throw an exception. -Alan. From Alan.Bateman at oracle.com Wed May 29 11:58:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 12:58:19 +0100 Subject: RFR 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder In-Reply-To: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> References: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> Message-ID: <51A5ED5B.2080903@oracle.com> On 29/05/2013 12:08, Paul Sandoz wrote: > Hi, > > Please review these JavaDoc fixes to j.u.s.StreamBuilder. > > Paul. > This looks fine to me. -Alan From Alan.Bateman at oracle.com Wed May 29 12:00:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 13:00:13 +0100 Subject: RFR 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() In-Reply-To: <8EA62D12-E287-4884-968D-D5D2237AB9BB@oracle.com> References: <8EA62D12-E287-4884-968D-D5D2237AB9BB@oracle.com> Message-ID: <51A5EDCD.5060507@oracle.com> On 29/05/2013 12:10, Paul Sandoz wrote: > Hi, > > Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst. > > Paul. I had to look at the diff twice to spot it :-) Looks fine to me. -Alan. From david.r.chase at oracle.com Wed May 29 12:36:47 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 29 May 2013 08:36:47 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> Message-ID: It looks like there's no way to set the random seed from the command line. That's going to make Heisenbugs even less fun than they already are. Ideally, if a VM crashes, that random seed could get mentioned somewhere in the crash, and someone who is debugging might then be able to specify it through a command-line property. It's not a guarantee of a repeatable run, but it at least removes an obstacle. David On 2013-05-29, at 12:13 AM, Mike Duigou wrote: > Hashtable/WeakHashMap:: > > - I assume that the JVM falls over dead if the security manager doesn't allow access to the property, correct? I hadn't considered what should happen in the event of a security exception when I originally copied the GetPropertyAction idiom from elsewhere in the JDK. Perhaps add a security manager test to CheckRandomHashSeed? Or two if we want to make sure that > > - initHashSeed could now return the value with assignment happening in the constructor if we wanted to make hashSeed final. This would mean the unsafe stuff would have to return in Hashtable/HashMap to allow for deserialization. > > > HashMap:: > > - TreeBin.comparableClassFor() includes "see above for explanation." but it's not clear where that explanation is. > > - I was really worried about the cost and correctness issues with changing null key handling. I have now put my mind at ease. All of the cases I could think of seem to be handled. > > - I've spent less time in this round looking at the new Map default operations. > > Hashing:: > > - Do we know if ThreadLocalRandom requires that the VM be booted? It may be possible to remove even more stuff here. > > > InPlaceOpsCollisions:: > > - The @run directives run the wrong class (an error I have made myself...). > > Mike > > On May 28 2013, at 13:03 , Brent Christian wrote: > >> On 5/28/13 3:09 AM, Doug Lea wrote: >>> >>> To better enable and simplify future improvements, could you >>> do this -- nest the tree classes within HashMap? >> >> Done. >> >>> Also, a note on spliterators: I had added these in the >>> least disruptive way (knowing that major changes were coming) >>> by checking exact class match for HashMap.class. This is because >>> there aren't LinkedHashMap view classes to attach overrides to. >>> While not wrong, and OK for now, at some point this should be redone. >> >> OK. I will file a bug so this doesn't get forgotten. >> >> >> I also applied the change to how HashMap.putAll() resizes the table (to account for splitTreeBin() only handling doubling of tables). >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ >> >> Thanks, >> -Brent > From chris.hegarty at oracle.com Wed May 29 12:45:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 13:45:02 +0100 Subject: RFR 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() In-Reply-To: <51A5EDCD.5060507@oracle.com> References: <8EA62D12-E287-4884-968D-D5D2237AB9BB@oracle.com> <51A5EDCD.5060507@oracle.com> Message-ID: <51A5F84E.1010805@oracle.com> On 29/05/2013 13:00, Alan Bateman wrote: > On 29/05/2013 12:10, Paul Sandoz wrote: >> Hi, >> >> Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst. >> >> Paul. > I had to look at the diff twice to spot it :-) Not bad, it took me three times ;-) > Looks fine to me. +1 -Chris. From chris.hegarty at oracle.com Wed May 29 12:49:40 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 13:49:40 +0100 Subject: RFR 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder In-Reply-To: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> References: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> Message-ID: <51A5F964.9080303@oracle.com> Looks fine to me Paul. Trivially, there is an extra space which could be removed. "builder__has..." -Chris. On 29/05/2013 12:08, Paul Sandoz wrote: > Hi, > > Please review these JavaDoc fixes to j.u.s.StreamBuilder. > > Paul. > > # HG changeset patch > # User psandoz > # Date 1369825073 -7200 > # Node ID 303e9d2aff3cbaf27823b2591f2e8570b77afcce > # Parent bd6d3801347bfd912507d16dc14488f47e94e626 > 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder > Summary: Also fixes documentation on StreamBuilder.OfDouble > Reviewed-by: > > diff -r bd6d3801347b -r 303e9d2aff3c src/share/classes/java/util/stream/StreamBuilder.java > --- a/src/share/classes/java/util/stream/StreamBuilder.java Wed May 29 09:42:39 2013 +0200 > +++ b/src/share/classes/java/util/stream/StreamBuilder.java Wed May 29 12:57:53 2013 +0200 > @@ -38,7 +38,7 @@ > *

                  A {@code StreamBuilder} has a lifecycle, where it starts in a building > * phase, during which elements can be added, and then transitions to a built > * phase, after which elements may not be added. The built phase begins > - * when the {@link #build()}} method is called, which creates an ordered > + * when the {@link #build()} method is called, which creates an ordered > * {@code Stream} whose elements are the elements that were added to the stream > * builder, in the order they were added. > * > @@ -98,7 +98,7 @@ > *

                  A stream builder has a lifecycle, where it starts in a building > * phase, during which elements can be added, and then transitions to a > * built phase, after which elements may not be added. The built phase > - * begins when the {@link #build()}} method is called, which creates an > + * begins when the {@link #build()} method is called, which creates an > * ordered stream whose elements are the elements that were added to the > * stream builder, in the order they were added. > * > @@ -155,7 +155,7 @@ > *

                  A stream builder has a lifecycle, where it starts in a building > * phase, during which elements can be added, and then transitions to a > * built phase, after which elements may not be added. The built phase > - * begins when the {@link #build()}} method is called, which creates an > + * begins when the {@link #build()} method is called, which creates an > * ordered stream whose elements are the elements that were added to the > * stream builder, in the order they were added. > * > @@ -209,6 +209,13 @@ > /** > * A mutable builder for a {@code DoubleStream}. > * > + *

                  A stream builder has a lifecycle, where it starts in a building > + * phase, during which elements can be added, and then transitions to a > + * built phase, after which elements may not be added. The built phase > + * begins when the {@link #build()} method is called, which creates an > + * ordered stream whose elements are the elements that were added to the > + * stream builder, in the order they were added. > + * > * @see LongStream#builder() > * @since 1.8 > */ > @@ -217,13 +224,6 @@ > /** > * Adds an element to the stream being built. > * > - *

                  A stream builder has a lifecycle, where it starts in a building > - * phase, during which elements can be added, and then transitions to a > - * built phase, after which elements may not be added. The built phase > - * begins when the {@link #build()}} method is called, which creates an > - * ordered stream whose elements are the elements that were added to the > - * stream builder, in the order they were added. > - * > * @throws IllegalStateException if the builder has already transitioned > * to the built state > */ From chris.hegarty at oracle.com Wed May 29 12:54:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 13:54:26 +0100 Subject: RFR 8014731: j.u.stream.StreamSupport class has default constructor generated In-Reply-To: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> References: <671B6DF8-0C5C-4B13-9434-96C9A7CAC7E1@oracle.com> Message-ID: <51A5FA82.1090104@oracle.com> Looks fine to me. -Chris. On 29/05/2013 12:12, Paul Sandoz wrote: > Hi, > > Please review these changes to j.u.s. StreamSupport to make it final and non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry. > > Paul. > > # HG changeset patch > # User psandoz > # Date 1369825082 -7200 > # Node ID bfdc1ed75460c9e6869827cf9acabd4b1a5e9d29 > # Parent 6be3ce51e61dbdab6766c74223c076a7b3472be6 > 8014731: j.u.stream.StreamSupport class has default constructor generated > Summary: This change set also fixes broken links > Reviewed-by: > Contributed-by: Paul Sandoz, Henry Jen > > diff -r 6be3ce51e61d -r bfdc1ed75460 src/share/classes/java/util/stream/StreamSupport.java > --- a/src/share/classes/java/util/stream/StreamSupport.java Tue May 28 15:22:30 2013 +0200 > +++ b/src/share/classes/java/util/stream/StreamSupport.java Wed May 29 12:58:02 2013 +0200 > @@ -41,7 +41,11 @@ > * > * @since 1.8 > */ > -public class StreamSupport { > +public final class StreamSupport { > + > + // Suppresses default constructor, ensuring non-instantiability. > + private StreamSupport() {} > + > /** > * Creates a new sequential {@code Stream} from a {@code Spliterator}. > * > @@ -50,7 +54,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -75,7 +79,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -102,7 +106,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #stream(java.util.Spliterator)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -138,7 +142,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #stream(Spliterator)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -172,7 +176,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)}} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -195,7 +199,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)}} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -220,7 +224,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #intStream(Spliterator.OfInt)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -254,7 +258,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #intStream(Spliterator.OfInt)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -286,7 +290,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -310,7 +314,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -335,7 +339,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #longStream(Spliterator.OfLong)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -369,7 +373,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #longStream(Spliterator.OfLong)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -402,7 +406,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -426,7 +430,7 @@ > * > *

                  It is strongly recommended the spliterator report a characteristic of > * {@code IMMUTABLE} or {@code CONCURRENT}, or be > - *late-binding. Otherwise, > + *late-binding. Otherwise, > * {@link #stream(Supplier, int)} should be used to > * reduce the scope of potential interference with the source. See > *Non-Interference for > @@ -451,7 +455,7 @@ > *

                  > * For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #doubleStream(Spliterator.OfDouble)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > @@ -485,7 +489,7 @@ > * > *

                  For spliterators that report a characteristic of {@code IMMUTABLE} > * or {@code CONCURRENT}, or that are > - *late-binding, it is likely > + *late-binding, it is likely > * more efficient to use {@link #doubleStream(Spliterator.OfDouble)} instead. > * The use of a {@code Supplier} in this form provides a level of > * indirection that reduces the scope of potential interference with the > From chris.hegarty at oracle.com Wed May 29 13:11:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 14:11:09 +0100 Subject: RFR 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown In-Reply-To: <3FF25815-046E-49A6-B914-8E72ED5C1E13@oracle.com> References: <3FF25815-046E-49A6-B914-8E72ED5C1E13@oracle.com> Message-ID: <51A5FE6D.2040204@oracle.com> Looks good to me. -Chris. On 29/05/2013 12:36, Paul Sandoz wrote: > Hi, > > Please review this JavaDoc fixe to j.u.Spliterator.getExactSizeIfKnown. > > Paul. > > # HG changeset patch > # User psandoz > # Date 1369825085 -7200 > # Node ID 840469ba82ab8d8238414a5333aa99b8d4035a9b > # Parent 7ded996200218791c885c0aae4c474066101c7bd > 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown > Summary: A minor documentation issue (not a spec issue). > Reviewed-by: > > diff -r 7ded99620021 -r 840469ba82ab src/share/classes/java/util/Spliterator.java > --- a/src/share/classes/java/util/Spliterator.java Wed May 29 12:58:03 2013 +0200 > +++ b/src/share/classes/java/util/Spliterator.java Wed May 29 12:58:05 2013 +0200 > @@ -394,9 +394,9 @@ > * Convenience method that returns {@link #estimateSize()} if this > * Spliterator is {@link #SIZED}, else {@code -1}. > * @implSpec > - * The default returns the result of {@code estimateSize()} if the > - * Spliterator reports a characteristic of {@code SIZED}, and {@code -1} > - * otherwise. > + * The default implementation returns the result of {@code estimateSize()} > + * if the Spliterator reports a characteristic of {@code SIZED}, and > + * {@code -1} otherwise. > * > * @return the exact size, if known, else {@code -1}. > */ From paul.sandoz at oracle.com Wed May 29 13:10:41 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 May 2013 15:10:41 +0200 Subject: RFR 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder In-Reply-To: <51A5F964.9080303@oracle.com> References: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> <51A5F964.9080303@oracle.com> Message-ID: <7B21CFC5-924E-420E-BFF5-6FC0D75B4D0F@oracle.com> On May 29, 2013, at 2:49 PM, Chris Hegarty wrote: > Looks fine to me Paul. > > Trivially, there is an extra space which could be removed. > > "builder__has..." > Thanks, i updated the patch/lambda repo. Paul. From dl at cs.oswego.edu Wed May 29 13:11:30 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 29 May 2013 09:11:30 -0400 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <7978F270-3489-455F-956E-3BB66947F381@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: <51A5FE82.20903@cs.oswego.edu> On 05/28/13 15:07, Mike Duigou wrote: > Hi Chris & Doug; > - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type > particularly for newKeySet(). Why not return Set? The additional methods > don't seem to offer much that's desirable for the newKeySet() case. Since we don't have a ConcurrentSet interface, people are reduced to instanceof checks to see if they have a concurrent one. But without exposing the class, they couldn't even do this, so complained. This will arise more frequently with j.u.streams.Collectors. > > > - I am reluctant to deprecate contains(Object) here unless we deprecate it in > Hashtable as well. I recognize that this has been a source of errors > (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one example). > Is it time to deprecate it there as well? Sure, but why bother. Anyone still using Hashtable is not going to care if they get more deprecation warnings :-) > > > - I think there could be more complete description of the > parallelismThreshold and interaction with common pool. i.e. does "maximal > parallelism" mean one thread per element or "size() / > getCommonPoolParallelism()". Some advice for choosing in-between values would > be good unless "1" is the best advice for cases where you just don't know. It > would be a shame to see people shooting themselves in the foot with this. > Changed to: *

                  These bulk operations accept a {@code parallelismThreshold} * argument. Methods proceed sequentially if the current map size is * estimated to be less than the given threshold. Using a value of * {@code Long.MAX_VALUE} suppresses all parallelism. Using a value * of {@code 1} results in maximal parallelism by partitioning into * enough subtasks to utilize all processors. Normally, you would * initially choose one of these extreme values, and then measure * performance of using in-between values that trade off overhead * versus throughput. Parallel forms use the {@link * ForkJoinPool#commonPool()}. * I'd rather not explicitly mention here any particular values for people to try, since any number we might put is likely to be misused. Sometime, we should write up a little how-to document about tuning parallelism separately. -Doug From dl at cs.oswego.edu Wed May 29 13:18:58 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 29 May 2013 09:18:58 -0400 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: <51A60042.5040108@cs.oswego.edu> On 05/28/13 16:03, Martin Buchholz wrote: > A long-returning size method seems like a framework-level decision. We could > add a default method to Collection.java and Map.java > > default long mappingCount() { return size(); } The lambda EG discussed this, and decided not to do it now, and to put off support for 64bit collections until JDK9. But CHM needs this now, so we picked a name that is usable but not likely to clash with some better future name, like length(). -Doug > > I'm not sure mappingCount is the best name, but all names will be confusing. > Using the name "length()" at least has an onomatopoeic mnemonic advantage - it > suggests that it might return a long. > > /** > * Returns the number of mappings. This method should be used > * instead of {@link #size} because a ConcurrentHashMap may > * contain more mappings than can be represented as an int. The > * value returned is an estimate; the actual count may differ if > * there are concurrent insertions or removals. > * > * @return the number of mappings > */ > public long mappingCount() { > long n = sumCount(); > return (n < 0L) ? 0L : n; // ignore transient negative values > } > From vincent.x.ryan at oracle.com Wed May 29 13:59:02 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 29 May 2013 13:59:02 +0000 Subject: hg: jdk8/tl/jdk: 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate Message-ID: <20130529135914.E179548DDF@hg.openjdk.java.net> Changeset: 00ad19610e75 Author: vinnie Date: 2013-05-29 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00ad19610e75 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java From chris.hegarty at oracle.com Wed May 29 14:06:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 15:06:58 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <7978F270-3489-455F-956E-3BB66947F381@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> Message-ID: <51A60B82.8060004@oracle.com> Mike, Doug, On 28/05/2013 20:07, Mike Duigou wrote: > Hi Chris& Doug; > > - I don't feel strongly about the removal of AbstractMap. I don't see this as very likely to cause problems in real world code though there is probably some test code somewhere that assigns CHM to an AbstractMap. I don't feel strongly about this either, but I think it deserves possibly its own bug number and consideration. I have removed it from this review request, and will a file a new bug to track it. > - I am reluctant to deprecate contains(Object) here unless we deprecate it in Hashtable as well. I recognize that this has been a source of errors (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one example). Is it time to deprecate it there as well? Dito for this, removed from this request and should be revisited separately. -Chris. From chris.hegarty at oracle.com Wed May 29 14:07:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 15:07:59 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A60B82.8060004@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A60B82.8060004@oracle.com> Message-ID: <51A60BBF.40607@oracle.com> ... and the links to the updated spedcdiff / webrev http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/ -Chris. On 29/05/2013 15:06, Chris Hegarty wrote: > Mike, Doug, > > On 28/05/2013 20:07, Mike Duigou wrote: >> Hi Chris& Doug; >> >> - I don't feel strongly about the removal of AbstractMap. I don't see >> this as very likely to cause problems in real world code though there >> is probably some test code somewhere that assigns CHM to an AbstractMap. > > I don't feel strongly about this either, but I think it deserves > possibly its own bug number and consideration. I have removed it from > this review request, and will a file a new bug to track it. > >> - I am reluctant to deprecate contains(Object) here unless we >> deprecate it in Hashtable as well. I recognize that this has been a >> source of errors >> (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one >> example). Is it time to deprecate it there as well? > > Dito for this, removed from this request and should be revisited > separately. > > -Chris. From mike.duigou at oracle.com Wed May 29 14:07:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 29 May 2013 07:07:49 -0700 Subject: RFR 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder In-Reply-To: <7B21CFC5-924E-420E-BFF5-6FC0D75B4D0F@oracle.com> References: <4F2B3C32-3E53-4AFD-9274-D02C548083D1@oracle.com> <51A5F964.9080303@oracle.com> <7B21CFC5-924E-420E-BFF5-6FC0D75B4D0F@oracle.com> Message-ID: <082237E4-449B-432E-8120-C7791A8BFACD@oracle.com> Looks fine to me with the space removed as well. Mike On May 29 2013, at 06:10 , Paul Sandoz wrote: > > On May 29, 2013, at 2:49 PM, Chris Hegarty wrote: > >> Looks fine to me Paul. >> >> Trivially, there is an extra space which could be removed. >> >> "builder__has..." >> > > Thanks, i updated the patch/lambda repo. > > Paul. From mike.duigou at oracle.com Wed May 29 14:12:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 29 May 2013 07:12:25 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> Message-ID: <0146AFA2-197D-407D-8CE3-E5FC31D271B3@oracle.com> Understood that it is necessary to have some mechanism to have reproducible results. The command line system property is by default disabled. Enabling it has only the effect of setting the hashSeed to a non-zero XOR value for each instance. Since the randomness is per instance there's no single value to print out. We considered a switch, like python, to allow using the same non-zero seed value to all instances but it didn't seem to offer much additional debugging capability so we opted to not implement it. Mike On May 29 2013, at 05:36 , David Chase wrote: > It looks like there's no way to set the random seed from the command line. That's going to make Heisenbugs even less fun than they already are. Ideally, if a VM crashes, that random seed could get mentioned somewhere in the crash, and someone who is debugging might then be able to specify it through a command-line property. It's not a guarantee of a repeatable run, but it at least removes an obstacle. > David > > On 2013-05-29, at 12:13 AM, Mike Duigou wrote: > >> Hashtable/WeakHashMap:: >> >> - I assume that the JVM falls over dead if the security manager doesn't allow access to the property, correct? I hadn't considered what should happen in the event of a security exception when I originally copied the GetPropertyAction idiom from elsewhere in the JDK. Perhaps add a security manager test to CheckRandomHashSeed? Or two if we want to make sure that >> >> - initHashSeed could now return the value with assignment happening in the constructor if we wanted to make hashSeed final. This would mean the unsafe stuff would have to return in Hashtable/HashMap to allow for deserialization. >> >> >> HashMap:: >> >> - TreeBin.comparableClassFor() includes "see above for explanation." but it's not clear where that explanation is. >> >> - I was really worried about the cost and correctness issues with changing null key handling. I have now put my mind at ease. All of the cases I could think of seem to be handled. >> >> - I've spent less time in this round looking at the new Map default operations. >> >> Hashing:: >> >> - Do we know if ThreadLocalRandom requires that the VM be booted? It may be possible to remove even more stuff here. >> >> >> InPlaceOpsCollisions:: >> >> - The @run directives run the wrong class (an error I have made myself...). >> >> Mike >> >> On May 28 2013, at 13:03 , Brent Christian wrote: >> >>> On 5/28/13 3:09 AM, Doug Lea wrote: >>>> >>>> To better enable and simplify future improvements, could you >>>> do this -- nest the tree classes within HashMap? >>> >>> Done. >>> >>>> Also, a note on spliterators: I had added these in the >>>> least disruptive way (knowing that major changes were coming) >>>> by checking exact class match for HashMap.class. This is because >>>> there aren't LinkedHashMap view classes to attach overrides to. >>>> While not wrong, and OK for now, at some point this should be redone. >>> >>> OK. I will file a bug so this doesn't get forgotten. >>> >>> >>> I also applied the change to how HashMap.putAll() resizes the table (to account for splitTreeBin() only handling doubling of tables). >>> >>> The updated webrev is here: >>> >>> http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ >>> >>> Thanks, >>> -Brent >> > From peter.levart at gmail.com Wed May 29 14:28:42 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 May 2013 16:28:42 +0200 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A60BBF.40607@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A60B82.8060004@oracle.com> <51A60BBF.40607@oracle.com> Message-ID: <51A6109A.2030800@gmail.com> On 05/29/2013 04:07 PM, Chris Hegarty wrote: > ... and the links to the updated spedcdiff / webrev > > > http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html > > http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/ > > -Chris. > > On 29/05/2013 15:06, Chris Hegarty wrote: >> Mike, Doug, >> >> On 28/05/2013 20:07, Mike Duigou wrote: >>> Hi Chris& Doug; >>> >>> - I don't feel strongly about the removal of AbstractMap. I don't see >>> this as very likely to cause problems in real world code though there >>> is probably some test code somewhere that assigns CHM to an >>> AbstractMap. >> >> I don't feel strongly about this either, but I think it deserves >> possibly its own bug number and consideration. I have removed it from >> this review request, and will a file a new bug to track it. Hi, Why not using Unsafe (which is already used in CHM) to re-use the AbstractMap.keySet/values fields? They could even be accessed with normal non-volatile read/write although they are declared volatile in AbstractMap. Is this to "hacky"? Regards, Peter >> >>> - I am reluctant to deprecate contains(Object) here unless we >>> deprecate it in Hashtable as well. I recognize that this has been a >>> source of errors >>> (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one >>> example). Is it time to deprecate it there as well? >> >> Dito for this, removed from this request and should be revisited >> separately. >> >> -Chris. From chris.hegarty at oracle.com Wed May 29 14:37:57 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 15:37:57 +0100 Subject: RFR 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE In-Reply-To: <50F2962C-723A-4864-A727-9981ED0128DA@oracle.com> References: <50F2962C-723A-4864-A727-9981ED0128DA@oracle.com> Message-ID: <51A612C5.6010506@oracle.com> Looks fine to me Paul. On 29/05/2013 12:35, Paul Sandoz wrote: > Hi, > > Please review these changes to j.u.PrimitiveIterator to ensure the default forEachRemaining methods consistently throw an NPE when the consumer is null. > > I almost produced a webrev for this, but i thought it was just about acceptable size-wise and i hope easy to review in textual form. If this is considered impolite, awkward to review etc please say so and i will produce a webrev. I found it a little difficult to review as it lacked some context around the changes. I found myself having to track down the source and compare line numbers. Not a problem, just that you happen to mention it ;-) -Chris > > Paul. > > # HG changeset patch > # User psandoz > # Date 1369825083 -7200 > # Node ID 7ded996200218791c885c0aae4c474066101c7bd > # Parent bfdc1ed75460c9e6869827cf9acabd4b1a5e9d29 > 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE > Reviewed-by: > > diff -r bfdc1ed75460 -r 7ded99620021 src/share/classes/java/util/PrimitiveIterator.java > --- a/src/share/classes/java/util/PrimitiveIterator.java Wed May 29 12:58:02 2013 +0200 > +++ b/src/share/classes/java/util/PrimitiveIterator.java Wed May 29 12:58:03 2013 +0200 > @@ -91,6 +91,7 @@ > * @throws NullPointerException if the specified action is null > */ > default void forEachRemaining(IntConsumer action) { > + Objects.requireNonNull(action); > while (hasNext()) > action.accept(nextInt()); > } > @@ -123,6 +124,8 @@ > forEachRemaining((IntConsumer) action); > } > else { > + // The method reference action::accept is never null > + Objects.requireNonNull(action); > if (Tripwire.ENABLED) > Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfInt.forEachRemainingInt(action::accept)"); > forEachRemaining((IntConsumer) action::accept); > @@ -162,6 +165,7 @@ > * @throws NullPointerException if the specified action is null > */ > default void forEachRemaining(LongConsumer action) { > + Objects.requireNonNull(action); > while (hasNext()) > action.accept(nextLong()); > } > @@ -194,6 +198,8 @@ > forEachRemaining((LongConsumer) action); > } > else { > + // The method reference action::accept is never null > + Objects.requireNonNull(action); > if (Tripwire.ENABLED) > Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfLong.forEachRemainingLong(action::accept)"); > forEachRemaining((LongConsumer) action::accept); > @@ -232,6 +238,7 @@ > * @throws NullPointerException if the specified action is null > */ > default void forEachRemaining(DoubleConsumer action) { > + Objects.requireNonNull(action); > while (hasNext()) > action.accept(nextDouble()); > } > @@ -265,6 +272,8 @@ > forEachRemaining((DoubleConsumer) action); > } > else { > + // The method reference action::accept is never null > + Objects.requireNonNull(action); > if (Tripwire.ENABLED) > Tripwire.trip(getClass(), "{0} calling PrimitiveIterator.OfDouble.forEachRemainingDouble(action::accept)"); > forEachRemaining((DoubleConsumer) action::accept); > diff -r bfdc1ed75460 -r 7ded99620021 test/java/util/Iterator/PrimitiveIteratorDefaults.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/java/util/Iterator/PrimitiveIteratorDefaults.java Wed May 29 12:58:03 2013 +0200 > @@ -0,0 +1,115 @@ > +/* > + * Copyright (c) 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. > + * > + * 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. > + */ > + > +import org.testng.annotations.Test; > + > +import java.util.PrimitiveIterator; > +import java.util.function.Consumer; > +import java.util.function.DoubleConsumer; > +import java.util.function.IntConsumer; > +import java.util.function.LongConsumer; > + > +import static org.testng.Assert.assertNotNull; > +import static org.testng.Assert.assertTrue; > + > +/** > + * @test > + * @run testng PrimitiveIteratorDefaults > + * @summary test default methods on PrimitiveIterator > + */ > + at Test > +public class PrimitiveIteratorDefaults { > + > + public void testIntForEachRemainingWithNull() { > + PrimitiveIterator.OfInt i = new PrimitiveIterator.OfInt() { > + @Override > + public int nextInt() { > + return 0; > + } > + > + @Override > + public boolean hasNext() { > + return false; > + } > + }; > + > + executeAndCatch(() -> i.forEachRemaining((IntConsumer) null)); > + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); > + } > + > + public void testLongForEachRemainingWithNull() { > + PrimitiveIterator.OfLong i = new PrimitiveIterator.OfLong() { > + @Override > + public long nextLong() { > + return 0; > + } > + > + @Override > + public boolean hasNext() { > + return false; > + } > + }; > + > + executeAndCatch(() -> i.forEachRemaining((LongConsumer) null)); > + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); > + } > + > + public void testDoubleForEachRemainingWithNull() { > + PrimitiveIterator.OfDouble i = new PrimitiveIterator.OfDouble() { > + @Override > + public double nextDouble() { > + return 0; > + } > + > + @Override > + public boolean hasNext() { > + return false; > + } > + }; > + > + executeAndCatch(() -> i.forEachRemaining((DoubleConsumer) null)); > + executeAndCatch(() -> i.forEachRemaining((Consumer) null)); > + } > + > + private void executeAndCatch(Runnable r) { > + executeAndCatch(NullPointerException.class, r); > + } > + > + private void executeAndCatch(Class expected, Runnable r) { > + Exception caught = null; > + try { > + r.run(); > + } > + catch (Exception e) { > + caught = e; > + } > + > + assertNotNull(caught, > + String.format("No Exception was thrown, expected an Exception of %s to be thrown", > + expected.getName())); > + assertTrue(expected.isInstance(caught), > + String.format("Exception thrown %s not an instance of %s", > + caught.getClass().getName(), expected.getName())); > + } > + > +} > From dl at cs.oswego.edu Wed May 29 14:40:18 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 29 May 2013 10:40:18 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <519F4C79.3040405@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <1369341178.67767.YahooMailNeo@web171701.mail.ir2.yahoo.com> <1369342050.58257.YahooMailNeo@web171705.mail.ir2.yahoo.com> <519F4C79.3040405@cs.oswego.edu> Message-ID: <51A61352.9040709@cs.oswego.edu> Back to this. (which applies to ConcurrentHashMap, under review). On 05/24/13 07:18, Doug Lea wrote: > On 05/23/13 16:47, Jeff Hain wrote: >> Implementing some RB-tree I found out that >> >> a lot of the null checks from CLR code could be removed from balancing >> operations. > > Yes and no. Some of those not logically needed prevent infinite looping in > the case of concurrent interference. But still, there are several that can go away without forcing so much rare-trap handling. I updated the analogous code in ConcurrentHashMap version to omit a few of them, and also retained in this version an internal checkInvariants method that can be used to further refine. (This is possibly useful to other developers, so worth leaving in rather than pulling out each time I update this code.) I also left asserts to it enabled in a couple of spots to allow more testing with "-ea". If/when I offer an update to plain HashMap, I'll also include. > it seemed that null checks could actually be removed for all remaining calls > to leftOf/rightOf/setColor (not for getColor), but since I didn't figure out > why I didn't touch these. > Right. TreeMap could use some similar improvement someday. That code was based on red-black algorithms that assume the tree is expanded such that all null links go to dummy nodes, which I long ago emulated with these calls in some classes I wrote that in turn got adapted in TreeMap and elsewhere. -Doug From chris.hegarty at oracle.com Wed May 29 14:45:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 15:45:26 +0100 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A6109A.2030800@gmail.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A60B82.8060004@oracle.com> <51A60BBF.40607@oracle.com> <51A6109A.2030800@gmail.com> Message-ID: <51A61486.4000802@oracle.com> On 29/05/2013 15:28, Peter Levart wrote: > ..... >>> I don't feel strongly about this either, but I think it deserves >>> possibly its own bug number and consideration. I have removed it from >>> this review request, and will a file a new bug to track it. > > Hi, > > Why not using Unsafe (which is already used in CHM) to re-use the > AbstractMap.keySet/values fields? They could even be accessed with > normal non-volatile read/write although they are declared volatile in > AbstractMap. Is this to "hacky"? Possibly a little hacky, and I guess may sacrifice a little performance? But this kind of analysis/investigation, and any compatibility concerns, are exactly why I think this deserves its own bug. I'm not saying that it's not worth pursuing, just that we should decouple it from the other changes going on here. (Says me who wanted to resync, in one pass, the complete j.u.c last week!) -Chris. > > Regards, Peter > From chris.hegarty at oracle.com Wed May 29 15:13:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 29 May 2013 16:13:23 +0100 Subject: RFR JDK-8015299 In-Reply-To: <51A55ECC.3030404@oracle.com> References: <519F8168.7000505@oracle.com> <51A2CCE9.9070406@oracle.com> <51A4AC17.5000607@oracle.com> <51A55ECC.3030404@oracle.com> Message-ID: <51A61B13.70007@oracle.com> On 29/05/2013 02:50, David Holmes wrote: > Looks good to me. +1. If you need a sponsor, I can push this for you John. -Chris. > > David > > On 28/05/2013 11:07 PM, John Zavgren wrote: >> Greetings: >> >> I fixed the comment line... to correct the "nul", "NULL", "NUL" issue >> and I disambiguated the readlink() issue. >> >> Thanks! >> John >> >> On 05/26/2013 11:03 PM, David Holmes wrote: >>> I concur with Martin on all counts. >>> >>> Confusing NUL and NULL is also a pet peeve of mine :) >>> >>> David >>> >>> On 25/05/2013 2:15 AM, Martin Buchholz wrote: >>>> Hi John, >>>> >>>> The memory leak fix looks good. >>>> --- >>>> IIRC I was the author of the comment, so it is not surprising that I >>>> might >>>> prefer that version. "nul" is ___not___ a typo for NULL. It makes no >>>> sense to speak of character arrays being NULL-terminated. It also isn't >>>> quite right to say that readlink "generates" an array - it simply >>>> writes >>>> into one. >>>> >>>> However, it is more correct to spell "nul" "NUL" as in ASCII(7). >>>> >>>> If you wanted to be more precise about which readlink, you could write >>>> readlink(2) instead of readlink() to disambiguate from readlink(1) >>>> >>>> >>>> On Fri, May 24, 2013 at 8:04 AM, John Zavgren >>>> wrote: >>>> >>>>> Greetings: >>>>> >>>>> I fixed two memory leaks in the file: jdk/src/solaris/bin/java_md_** >>>>> solinux.c >>>>> and I posted a webrev image of the changes at: >>>>> http://cr.openjdk.java.net/~**jzavgren/8015299/webrev.01/< >>>>> >>>>> >>>>> http://cr.openjdk.java.net/%**7Ejzavgren/8015299/webrev.01/ >>>>> >>>>> >>>>>> >>>>> >>>>> (I also edited a comment.) >>>>> >>>>> Thanks! >>>>> John >>>>> >>>>> -- >>>>> John Zavgren >>>>> john.zavgren at oracle.com >>>>> 603-821-0904 >>>>> US-Burlington-MA >>>>> >>>>> >> >> From james.laskey at oracle.com Wed May 29 16:24:52 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Wed, 29 May 2013 16:24:52 +0000 Subject: hg: jdk8/tl/nashorn: 9 new changesets Message-ID: <20130529162459.4942D48DE8@hg.openjdk.java.net> Changeset: 0bf451c0678d Author: hannesw Date: 2013-05-27 12:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bf451c0678d 8015348: RegExp("[") results in StackOverflowError Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8015348.js + test/script/basic/JDK-8015348.js.EXPECTED Changeset: 1f57afd14cc1 Author: lagergren Date: 2013-05-27 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f57afd14cc1 8014219: Make the run-octane harness more deterministic by not measuring elapsed time every iteration. Also got rid of most of the run logic in base.js and call benchmarks directly for the same purpose Reviewed-by: jlaskey, attila ! make/build-benchmark.xml ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js Changeset: 910fd2849c4c Author: lagergren Date: 2013-05-27 13:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/910fd2849c4c Merge Changeset: 343fd0450802 Author: sundar Date: 2013-05-27 20:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/343fd0450802 8015352: "i".toUpperCase() => currently returns "??", but should be "I" (with Turkish locale) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8015352.js Changeset: e6193dcfe36c Author: lagergren Date: 2013-05-27 17:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e6193dcfe36c 8015447: Octane harness fixes for rhino and entire test runs: ant octane, ant octane-v8, ant octane-rhino Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! test/script/basic/run-octane.js Changeset: d56168970de1 Author: sundar Date: 2013-05-28 16:37 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d56168970de1 8015459: Octane test run fails on Turkish locale Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java Changeset: f472f7046ec9 Author: sundar Date: 2013-05-29 15:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f472f7046ec9 8005979: A lot of tests are named "runTest" in reports Reviewed-by: jlaskey ! make/project.properties Changeset: f69e76417211 Author: lagergren Date: 2013-05-29 14:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f69e76417211 8011023: Math round didn't conform to ECMAScript 5 spec Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/objects/NativeMath.java + test/script/basic/JDK-8011023.js + test/script/basic/JDK-8011023.js.EXPECTED Changeset: a2e2797392b3 Author: sundar Date: 2013-05-29 21:27 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a2e2797392b3 8015349: "abc".lastIndexOf("a",-1) should evaluate to 0 and not -1 Reviewed-by: lagergren, attila, jlaskey ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8015349.js + test/script/basic/JDK-8015349.js.EXPECTED From xueming.shen at oracle.com Wed May 29 17:07:58 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 29 May 2013 10:07:58 -0700 Subject: RFR JDK-8015271: Conversion table for EUC-KR is incorrect Message-ID: <51A635EE.4050605@oracle.com> Hi, Here is proposal to add one mapping entry into the mapping table for EUC-KR to add the "newly" added KS X 1001:2002 code point 2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E) Info regarding this code point http://www.unicode.org/L2/L2004/04267-n2815.pdf Here is the mapping change webrev http://cr.openjdk.java.net/~sherman/8015271/webrev The mapping test webrev, these tests are still in closed repo, hope I can find time to update and bring them to the public repo soon. http://cr.openjdk.java.net/~sherman/8015271/closed Thanks! -Sherman From roger.riggs at oracle.com Wed May 29 17:12:41 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 29 May 2013 13:12:41 -0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A5E46C.5030908@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> Message-ID: <51A63709.1040600@oracle.com> Hi Alexey, I'm not sure I quite understand the purpose or semantics of this annotation. Since it is in sun.misc, it may not be so important and is just an implementation artifact but does not have enough of a standalone description nor connection to the other elements. The description of the annotation is an odd mix of hints about the usage of fields and specification of required behavior of an implementation. I would expect an implementation to be able to ignore the annotation or perhaps to improve on the performance by utilizing runtime available information. It is more useful to say what the annotation does mean than to say what it does not mean. Contention groups are a useful semantic but to say that a contention group " must be isolated from all other contention groups." is something for the implementation to determine. It would be more productive to say that fields in the contention group benefit from being grouped together and have similar access patterns. Thanks for any clarifications or connections to the rest of the functionality, Roger On 5/29/2013 7:20 AM, Aleksey Shipilev wrote: > > The new webrev is here: > http://cr.openjdk.java.net/~shade/8014966/webrev.03/ > > Thanks everyone, writing specs is fun! > > -Aleksey. From brian.burkhalter at oracle.com Wed May 29 18:00:36 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 May 2013 11:00:36 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value Message-ID: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> http://cr.openjdk.java.net/~bpb/8015395/ Fix is to ignore bad value passed for java.lang.Integer.IntegerCache.high property and devolve to the default. Thanks, Brian From aleksey.shipilev at oracle.com Wed May 29 18:02:15 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 29 May 2013 22:02:15 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A63709.1040600@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> Message-ID: <51A642A7.1090500@oracle.com> Hi Roger, On 05/29/2013 09:12 PM, roger riggs wrote: > I'm not sure I quite understand the purpose or semantics of this > annotation. That's the early sign you don't need it! :) I'm actually envious. > Since it is in sun.misc, it may not be so important and is just an > implementation artifact but does not have enough of a standalone > description nor connection to the other elements. See: http://openjdk.java.net/jeps/142 https://blogs.oracle.com/dave/entry/java_contented_annotation_to_help http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html ...for more rationale. > The description of the annotation is an odd mix of hints about the > usage of fields and specification of required behavior of an > implementation. Hm. If there is the issue with the javadoc, I'm failing to see it; maybe because I am exposed to false sharing enough to immediately understand what @C is about. Even though this is an internal API, and we just want to specify @C barely enough to be useful for those who need it, specific examples what is broken with the docs are welcome. > I would expect an implementation to be able to ignore the annotation > or perhaps to improve on the performance by utilizing runtime > available information. It is more useful to say what the annotation > does mean than to say what it does not mean. Yes, hints are by definition ignorable. Should the runtime be able to figure out the memory contention issues on its own, we will just "noop" @C, and be done. But, that Holy Grail is not here. > Contention groups are a useful semantic but to say that a contention > group " must be isolated from all other contention groups." is > something for the implementation to determine. I guess the valid concern is the use of "must"? Implementations may choose to protect the grouped fields on their own if it chooses to do so. -Aleksey. From brent.christian at oracle.com Wed May 29 18:39:32 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 29 May 2013 11:39:32 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> Message-ID: <51A64B64.5080209@oracle.com> On 5/28/13 9:13 PM, Mike Duigou wrote: > Hashtable/WeakHashMap:: > > - I assume that the JVM falls over dead if the security manager > doesn't allow access to the property, correct? I hadn't considered > what should happen in the event of a security exception when I > originally copied the GetPropertyAction idiom from elsewhere in the > JDK. AFAIK a security exception won't happen here as it's called in a doPrivileged(). > Perhaps add a security manager test to CheckRandomHashSeed? > Or two if we want to make sure that ...that what? :) I ran a test to confirm that maps can be created when useRandomSeed=true and a security manager is running (-Djava.security.manager). Attempting to read the property from the test code throws an AccessControlException, as one would expect. CheckRandomHashSeed probably isn't the right place to test this, as the test itself requires permissions to read the property and confirm (via reflection) the value of the hash seed. But I can add a new test case, if you think it's important. > - initHashSeed could now return the value with assignment happening > in the constructor if we wanted to make hashSeed final. This would > mean the unsafe stuff would have to return in Hashtable/HashMap to > allow for deserialization. It would be nice to keep hashSeed final. It would no longer be lazy, but we'll still get the main bottleneck relief of 8006593 by using ThreadLocalRandom in sun.misc.Hashing. I'll work on this. > HashMap:: > > - TreeBin.comparableClassFor() includes "see above for explanation." > but it's not clear where that explanation is. Things got moved around - its referring to the TreeBin docs, which are now "below". Fixed. > Hashing:: > > - Do we know if ThreadLocalRandom requires that the VM be booted? It > may be possible to remove even more stuff here. Indeed. I don't know the answer. > InPlaceOpsCollisions:: > > - The @run directives run the wrong class (an error I have made > myself...). Dang! Thanks - fixed. -Brent > On May 28 2013, at 13:03 , Brent Christian wrote: > >> On 5/28/13 3:09 AM, Doug Lea wrote: >>> >>> To better enable and simplify future improvements, could you >>> do this -- nest the tree classes within HashMap? >> >> Done. >> >>> Also, a note on spliterators: I had added these in the >>> least disruptive way (knowing that major changes were coming) >>> by checking exact class match for HashMap.class. This is because >>> there aren't LinkedHashMap view classes to attach overrides to. >>> While not wrong, and OK for now, at some point this should be redone. >> >> OK. I will file a bug so this doesn't get forgotten. >> >> >> I also applied the change to how HashMap.putAll() resizes the table (to account for splitTreeBin() only handling doubling of tables). >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ >> >> Thanks, >> -Brent > From mike.duigou at oracle.com Wed May 29 18:40:05 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 29 May 2013 11:40:05 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> Message-ID: In other cases similar to this an InternalError is thrown. It seems that for a property like this which can have a dramatic effect on performance silently ignoring bad input may not be the right choice. java -Djava.lang.Integer.IntegerCache.high=foobar Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Integer.valueOf(Integer.java:640) at sun.launcher.LauncherHelper.initHelpMessage(LauncherHelper.java:330) Caused by: java.lang.NumberFormatException: For input string: "foobar" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:492) at java.lang.Integer.parseInt(Integer.java:527) at java.lang.Integer$IntegerCache.(Integer.java:607) ... 2 more Doesn't seem to be that bad to me, but throwing internal error with an appropriate "system property java.lang.Integer.IntegerCache.high must be non-negative integer" message would seem to be superior than silently doing the wrong thing when: java -Djava.lang.Integer.IntegerCache.high=1024-Xmx2g or the less obviously wrong: java -Djava.lang.Integer.IntegerCache.high=1024\ -Xmx2g is encountered. Mike On May 29 2013, at 11:00 , Brian Burkhalter wrote: > http://cr.openjdk.java.net/~bpb/8015395/ > > Fix is to ignore bad value passed for java.lang.Integer.IntegerCache.high property and devolve to the default. > > Thanks, > > Brian From roger.riggs at oracle.com Wed May 29 18:48:51 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 29 May 2013 14:48:51 -0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A642A7.1090500@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> <51A642A7.1090500@oracle.com> Message-ID: <51A64D93.9070708@oracle.com> Hi Aleksey, Thanks for the references. Currently, you are correct, I don't need it. Has it been considered that highly contended field should not be allocated in the object itself anyway but in some pool or structure better suited to its access characteristics? A read-only indirection could provide some ability to allocate contended locks elsewhere where they would not disrupt the allocation mechanism. For example, in a pool of write-only or write-mostly values for the processor/core/thread. Of course, that has an access cost too. But given the credentials of the discussion authors I expect this has been well vetted and I have not much to offer. Limiting the scope of @contended groups prevents being able to groups fields from different classes/subclasses together that might reasonably share access patterns. The language related to 'intrinsically worthwhile' deserves a caution label. History is full of premature optimizations. Since it is mentioned that instrumentation is not available to compute the costs of contention in a particular use case, then only macro level performance of the application would be available to judge the effectiveness of a particular @Contended usage. But the cost in memory is immediate and measurable. Thanks, Roger On 5/29/2013 2:02 PM, Aleksey Shipilev wrote: > Hi Roger, > > On 05/29/2013 09:12 PM, roger riggs wrote: >> I'm not sure I quite understand the purpose or semantics of this >> annotation. > That's the early sign you don't need it! :) I'm actually envious. > >> Since it is in sun.misc, it may not be so important and is just an >> implementation artifact but does not have enough of a standalone >> description nor connection to the other elements. > See: > http://openjdk.java.net/jeps/142 > https://blogs.oracle.com/dave/entry/java_contented_annotation_to_help > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html > > ...for more rationale. > >> The description of the annotation is an odd mix of hints about the >> usage of fields and specification of required behavior of an >> implementation. > Hm. If there is the issue with the javadoc, I'm failing to see it; maybe > because I am exposed to false sharing enough to immediately understand > what @C is about. > > Even though this is an internal API, and we just want to specify @C > barely enough to be useful for those who need it, specific examples what > is broken with the docs are welcome. > >> I would expect an implementation to be able to ignore the annotation >> or perhaps to improve on the performance by utilizing runtime >> available information. It is more useful to say what the annotation >> does mean than to say what it does not mean. > Yes, hints are by definition ignorable. Should the runtime be able to > figure out the memory contention issues on its own, we will just "noop" > @C, and be done. But, that Holy Grail is not here. > >> Contention groups are a useful semantic but to say that a contention >> group " must be isolated from all other contention groups." is >> something for the implementation to determine. > I guess the valid concern is the use of "must"? Implementations may > choose to protect the grouped fields on their own if it chooses to do so. Yep. > > -Aleksey. From brian.burkhalter at Oracle.COM Wed May 29 18:49:12 2013 From: brian.burkhalter at Oracle.COM (Brian Burkhalter) Date: Wed, 29 May 2013 11:49:12 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> Message-ID: <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> On May 29, 2013, at 11:40 AM, Mike Duigou wrote: > In other cases similar to this an InternalError is thrown. It seems that for a property like this which can have a dramatic effect on performance silently ignoring bad input may not be the right choice. > > java -Djava.lang.Integer.IntegerCache.high=foobar > Exception in thread "main" java.lang.ExceptionInInitializerError > at java.lang.Integer.valueOf(Integer.java:640) > at sun.launcher.LauncherHelper.initHelpMessage(LauncherHelper.java:330) > Caused by: java.lang.NumberFormatException: For input string: "foobar" > at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Integer.parseInt(Integer.java:492) > at java.lang.Integer.parseInt(Integer.java:527) > at java.lang.Integer$IntegerCache.(Integer.java:607) > ... 2 more > > Doesn't seem to be that bad to me, but throwing internal error with an appropriate "system property java.lang.Integer.IntegerCache.high must be non-negative integer" message Problem is that the String in the NumberFormatException in this case does not contain the reason, only the offending String. The parseInt() would need to be changed accordingly to make this intelligible. I have no strong preference but it does not seem to me that failing to start the VM is a great plan. Brian > would seem to be superior than silently doing the wrong thing when: > > java -Djava.lang.Integer.IntegerCache.high=1024-Xmx2g > > or the less obviously wrong: > > java -Djava.lang.Integer.IntegerCache.high=1024\ > -Xmx2g > > is encountered. > > Mike > > On May 29 2013, at 11:00 , Brian Burkhalter wrote: > >> http://cr.openjdk.java.net/~bpb/8015395/ >> >> Fix is to ignore bad value passed for java.lang.Integer.IntegerCache.high property and devolve to the default. >> >> Thanks, >> >> Brian > From Alan.Bateman at oracle.com Wed May 29 18:58:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 19:58:30 +0100 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> Message-ID: <51A64FD6.8020406@oracle.com> On 29/05/2013 19:49, Brian Burkhalter wrote: > : > Problem is that the String in the NumberFormatException in this case does not contain the reason, only the offending String. The parseInt() would need to be changed accordingly to make this intelligible. > > I have no strong preference but it does not seem to me that failing to start the VM is a great plan. > > Brian > I think what you have in the webrev is okay because the purpose of this property is to communicate the value of the AutoBoxCacheMax option. In other words, this is a special property that only HotSpot should set, it is not documented/supported and nobody should be setting it on the command as in the bug report. So if -XX:AutoBoxCacheMax= is caught and emits a useful error then I think we are okay. -Alan. From martinrb at google.com Wed May 29 19:29:12 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 May 2013 12:29:12 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A5E46C.5030908@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> Message-ID: Looks good enough to me for a non-public API. I expect more contentious arguments if this is ever made public, since the problems remain very tricky. Only a VM that monitors memory "hot spots" can really get this right ... but the VM we have is already named "hotspot" ... From brian.burkhalter at oracle.com Wed May 29 19:54:13 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 May 2013 12:54:13 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> Message-ID: <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> So if an InternalError were to be used instead, the code would be like: try { int i = parseInt(integerCacheHighPropValue); i = Math.max(i, 127); // Maximum array size is Integer.MAX_VALUE h = Math.min(i, Integer.MAX_VALUE - (-low) -1); } catch(NumberFormatException nfe) { // Recast the exception to an InternalError with a sensible message. throw new InternalError(nfe.toString() + ": cannot parse value specified for java.lang.Integer.IntegerCache.high property"); } But that avoids the real question here, which is whether VM startup should be prevented by the value supplied for an internal property not being able to be parsed. Brian On May 29, 2013, at 11:49 AM, Brian Burkhalter wrote: > Problem is that the String in the NumberFormatException in this case does not contain the reason, only the offending String. The parseInt() would need to be changed accordingly to make this intelligible. > > I have no strong preference but it does not seem to me that failing to start the VM is a great plan. From brent.christian at oracle.com Wed May 29 20:47:12 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 29 May 2013 13:47:12 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A64B64.5080209@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> Message-ID: <51A66950.3020009@oracle.com> Updated webrev is here: http://cr.openjdk.java.net/~bchristi/8005698/webrev.03/ It contains the following changes from Mike's review: * HashMap.comparableClassFor(): corrected reference to TreeBin docs * fixed @run tag in InPlaceOpsCollisions.java * Hashtable & HashMap: hashSeed made final, initialized in constructor, UNSAFE restored and used in readObject(). Thanks, -Brent On 5/29/13 11:39 AM, Brent Christian wrote: > On 5/28/13 9:13 PM, Mike Duigou wrote: >> Hashtable/WeakHashMap:: >> >> - I assume that the JVM falls over dead if the security manager >> doesn't allow access to the property, correct? I hadn't considered >> what should happen in the event of a security exception when I >> originally copied the GetPropertyAction idiom from elsewhere in the >> JDK. > > AFAIK a security exception won't happen here as it's called in a > doPrivileged(). > >> Perhaps add a security manager test to CheckRandomHashSeed? >> Or two if we want to make sure that > > ...that what? :) > > I ran a test to confirm that maps can be created when useRandomSeed=true > and a security manager is running (-Djava.security.manager). Attempting > to read the property from the test code throws an > AccessControlException, as one would expect. > > CheckRandomHashSeed probably isn't the right place to test this, as the > test itself requires permissions to read the property and confirm (via > reflection) the value of the hash seed. But I can add a new test case, > if you think it's important. > >> - initHashSeed could now return the value with assignment happening >> in the constructor if we wanted to make hashSeed final. This would >> mean the unsafe stuff would have to return in Hashtable/HashMap to >> allow for deserialization. > > It would be nice to keep hashSeed final. It would no longer be lazy, > but we'll still get the main bottleneck relief of 8006593 by using > ThreadLocalRandom in sun.misc.Hashing. > > I'll work on this. > >> HashMap:: >> >> - TreeBin.comparableClassFor() includes "see above for explanation." >> but it's not clear where that explanation is. > > Things got moved around - its referring to the TreeBin docs, which are > now "below". Fixed. > >> Hashing:: >> >> - Do we know if ThreadLocalRandom requires that the VM be booted? It >> may be possible to remove even more stuff here. > > Indeed. I don't know the answer. > > >> InPlaceOpsCollisions:: >> >> - The @run directives run the wrong class (an error I have made >> myself...). > > Dang! Thanks - fixed. > > > -Brent > >> On May 28 2013, at 13:03 , Brent Christian wrote: > >>> On 5/28/13 3:09 AM, Doug Lea wrote: >>>> >>>> To better enable and simplify future improvements, could you >>>> do this -- nest the tree classes within HashMap? >>> >>> Done. >>> >>>> Also, a note on spliterators: I had added these in the >>>> least disruptive way (knowing that major changes were coming) >>>> by checking exact class match for HashMap.class. This is because >>>> there aren't LinkedHashMap view classes to attach overrides to. >>>> While not wrong, and OK for now, at some point this should be redone. >>> >>> OK. I will file a bug so this doesn't get forgotten. >>> >>> >>> I also applied the change to how HashMap.putAll() resizes the table >>> (to account for splitTreeBin() only handling doubling of tables). >>> >>> The updated webrev is here: >>> >>> http://cr.openjdk.java.net/~bchristi/8005698/webrev.02/ >>> >>> Thanks, >>> -Brent >> From Alan.Bateman at oracle.com Wed May 29 21:35:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 May 2013 22:35:58 +0100 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> Message-ID: <51A674BE.8080709@oracle.com> On 29/05/2013 20:54, Brian Burkhalter wrote: > So if an InternalError were to be used instead, the code would be like: > > try { > int i = parseInt(integerCacheHighPropValue); > i = Math.max(i, 127); > // Maximum array size is Integer.MAX_VALUE > h = Math.min(i, Integer.MAX_VALUE - (-low) -1); > } catch(NumberFormatException nfe) { > // Recast the exception to an InternalError with a sensible message. > throw new InternalError(nfe.toString() + > ": cannot parse value specified for java.lang.Integer.IntegerCache.high property"); > } > > But that avoids the real question here, which is whether VM startup should be prevented by the value supplied for an internal property not being able to be parsed. > > Brian > It would be good to do a few experiments with -XX:AutoBoxCacheMax= to make sure that bad values dp startup to fail, I expect they should. As regards setting the property directly (which was never the intention and is not supported) then the issue is that the property value is being parsed lazily. If you want to check it early then it requires parsing it in VM.saveAndRemoveProperties, that is the method that is called early in the initialization to stash away these properties. -Alan. From martinrb at google.com Wed May 29 21:56:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 May 2013 14:56:19 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A61486.4000802@oracle.com> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A60B82.8060004@oracle.com> <51A60BBF.40607@oracle.com> <51A6109A.2030800@gmail.com> <51A61486.4000802@oracle.com> Message-ID: On Wed, May 29, 2013 at 7:45 AM, Chris Hegarty wrote: > decouple it from the other changes going on here. (Says me who wanted to > resync, in one pass, the complete j.u.c last week!) > However it gets done, Chris, thanks very much for taking on the big task of syncing jsr166. From xueming.shen at oracle.com Wed May 29 22:17:35 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 29 May 2013 15:17:35 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: References: <519FBDDC.2030806@oracle.com> Message-ID: <51A67E7F.6080800@oracle.com> Hi Martin, Somehow most of your comments are "blank lines" in my mailbox, just wonder if you can send them again. Based on the "hints", I updated those javadoc comments in ZipUtils to "**". The code has been updated slightly (mainly to not output the extra time stamp if it already exists in the passed in/read in/user defined "extra' field. I added a test TestExtraTime to test couple use scenario and also updated couple existing tests (which depend on the hard coded extra field size...). Now all unit/regression tests are passed. http://cr.openjdk.java.net/~sherman/6303183/webrev/ As we discussed in other thread, I will continue to see the possibility of adding atime/ctime support and better time granularity (via NTFS extra field). Thanks! -Sherman On 05/28/2013 08:36 PM, Martin Buchholz wrote: > Looks good to me. > > --- > While you're moving code around, you could fix the typo below and change method comments to javadoc style ('*' => '**'') > accidnetly > and From martinrb at google.com Wed May 29 22:41:17 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 May 2013 15:41:17 -0700 Subject: RFR 6303183: Support NTFS and Unix-style timestamps for entries in Zip files In-Reply-To: <51A67E7F.6080800@oracle.com> References: <519FBDDC.2030806@oracle.com> <51A67E7F.6080800@oracle.com> Message-ID: On Wed, May 29, 2013 at 3:17 PM, Xueming Shen wrote: > Hi Martin, > > Somehow most of your comments are "blank lines" in my mailbox, just wonder > if > you can send them again. Based on the "hints", I updated those javadoc > comments > in ZipUtils to "**". > Sorry, my mail program is a bit too innovative for old fogeys like me. Just that annoying accidnetly typo was missed. Looks OK! From brian.burkhalter at oracle.com Wed May 29 22:44:24 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 May 2013 15:44:24 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <51A674BE.8080709@oracle.com> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> <51A674BE.8080709@oracle.com> Message-ID: <7E1A0E84-4D1B-4A0D-AD08-AC28A6D07DB1@oracle.com> On May 29, 2013, at 2:35 PM, Alan Bateman wrote: > It would be good to do a few experiments with -XX:AutoBoxCacheMax= to make sure that bad values dp startup to fail, I expect they should. Yes, bad values do indeed cause startup to fail, for example: $ java -XX:AutoBoxCacheMax=1024\-Xmx2g HelloWorld Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. > As regards setting the property directly (which was never the intention and is not supported) then the issue is that the property value is being parsed lazily. If you want to check it early then it requires parsing it in VM.saveAndRemoveProperties, that is the method that is called early in the initialization to stash away these properties. Whether this property is parsed early or lazily it seems like the fundamental question remains: given a non-parseable value does one fall back to the default or throw an exception and prevent VM startup? Brian From jonathan.gibbons at oracle.com Wed May 29 22:42:33 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 29 May 2013 22:42:33 +0000 Subject: hg: jdk8/tl/langtools: 8015641: genstubs needs to cope with static interface methods Message-ID: <20130529224240.5958B48E07@hg.openjdk.java.net> Changeset: d685b12b62a4 Author: jjg Date: 2013-05-29 15:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d685b12b62a4 8015641: genstubs needs to cope with static interface methods Reviewed-by: ksrini ! make/tools/genstubs/GenStubs.java From forax at univ-mlv.fr Wed May 29 23:40:03 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 30 May 2013 01:40:03 +0200 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <7E1A0E84-4D1B-4A0D-AD08-AC28A6D07DB1@oracle.com> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> <51A674BE.8080709@oracle.com> <7E1A0E84-4D1B-4A0D-AD08-AC28A6D07DB1@oracle.com> Message-ID: <51A691D3.2070506@univ-mlv.fr> On 05/30/2013 12:44 AM, Brian Burkhalter wrote: > On May 29, 2013, at 2:35 PM, Alan Bateman wrote: > >> It would be good to do a few experiments with -XX:AutoBoxCacheMax= to make sure that bad values dp startup to fail, I expect they should. > Yes, bad values do indeed cause startup to fail, for example: > > $ java -XX:AutoBoxCacheMax=1024\-Xmx2g HelloWorld > Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > >> As regards setting the property directly (which was never the intention and is not supported) then the issue is that the property value is being parsed lazily. If you want to check it early then it requires parsing it in VM.saveAndRemoveProperties, that is the method that is called early in the initialization to stash away these properties. > Whether this property is parsed early or lazily it seems like the fundamental question remains: given a non-parseable value does one fall back to the default or throw an exception and prevent VM startup? In Java, we are used too check arguments of a method and throws an exception if something is wrong, As a user of a method or here of the VM, it's far easier when the VM stop otherwise you have to learn what is the default value that will be used or worst what is the "smart" algorithm that will be used to recover from this problem. That's not the good way to design method/class/sofware, they are and should stay dumb, the intelligence come from the way you connect the things, not from each piece. > > Brian cheers, R?mi From martinrb at google.com Wed May 29 23:57:42 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 May 2013 16:57:42 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: I would like to see the real world-class experts on this scary math stuff (Alan Eliasen, Tim Buktu) be made honorary jdk reviewers, just for their area of specialization, if that was bureaucratically possible. Shouldn't the original authors be cc'ed? The code is awesome. My thorough review found only these defects: Use third person in the first sentence of a javadoc - e.g. s/Retrieve/Retrieves/. --- Don't use the denigrated C style char zero[] = Instead use char[] zero = --- This looks odd: normalized as a//binary* The original comment looked more normal: normalized as a *binary* --- Otherwise, approved! On Fri, May 24, 2013 at 10:09 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Originally posted one month ago today. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016355.html > > https://www.youtube.com/watch?v=D9kv_V5lhiE > > Thanks, > > Brian > From brian.burkhalter at oracle.com Thu May 30 00:20:10 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 May 2013 17:20:10 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: > I would like to see the real world-class experts on this scary math stuff (Alan Eliasen, Tim Buktu) be made honorary jdk reviewers, just for their area of specialization, if that was bureaucratically possible. I'll leave serious comments on this topic to those vested with godlike powers. It would be nice however to have domain experts here, that's for sure. > Shouldn't the original authors be cc'ed? I think (hope) all are on core-libs-dev. > The code is awesome. My thorough review found only these defects: > > Use third person in the first sentence of a javadoc - e.g. s/Retrieve/Retrieves/. > > --- > > Don't use the denigrated C style > char zero[] = > Instead use > char[] zero = > > --- Are the two preceding comments generic, i.e., occurring in multiple places, or each unique? > This looks odd: > normalized as a//binary* > > The original comment looked more normal: > > normalized as a *binary* > --- > > Otherwise, approved! Thanks much! Brian > > > On Fri, May 24, 2013 at 10:09 AM, Brian Burkhalter wrote: > Originally posted one month ago today. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016355.html > > https://www.youtube.com/watch?v=D9kv_V5lhiE > > Thanks, > > Brian > From mandy.chung at oracle.com Thu May 30 00:49:35 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 May 2013 17:49:35 -0700 Subject: RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value In-Reply-To: <7E1A0E84-4D1B-4A0D-AD08-AC28A6D07DB1@oracle.com> References: <5E117AEB-5816-4B89-9062-9B7901AD0687@oracle.com> <2D6FB1B9-13CA-4C0B-A326-794AEDE69410@Oracle.COM> <5D61E0F1-C4AB-41C7-8066-AEA279883184@oracle.com> <51A674BE.8080709@oracle.com> <7E1A0E84-4D1B-4A0D-AD08-AC28A6D07DB1@oracle.com> Message-ID: <51A6A21F.1090106@oracle.com> On 5/29/2013 3:44 PM, Brian Burkhalter wrote: > On May 29, 2013, at 2:35 PM, Alan Bateman wrote: > >> It would be good to do a few experiments with -XX:AutoBoxCacheMax= to make sure that bad values dp startup to fail, I expect they should. > Yes, bad values do indeed cause startup to fail, for example: > > $ java -XX:AutoBoxCacheMax=1024\-Xmx2g HelloWorld > Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. AutoBoxCacheMax is a signed integer argument and I think the VM will check if it contains any non-digit character but it doesn't validate for the range. This could cause the VM to throw OOM: java -XX:AutoBoxCacheMax=8888888888888888888 Error occurred during initialization of VM java.lang.OutOfMemoryError: Java heap space at java.lang.Integer$IntegerCache.(Integer.java:780) at java.lang.Integer.valueOf(Integer.java:808) at sun.misc.Signal.handle(Signal.java:169) at java.lang.Terminator.setup(Terminator.java:60) at java.lang.System.initializeSystemClass(System.java:1192) The VM might truncate the specified AutoBoxCacheMax value as INTX_FORMAT when it passes to the library: // Feed the cache size setting into the JDK char buffer[1024]; sprintf(buffer, "java.lang.Integer.IntegerCache.high=" INTX_FORMAT, AutoBoxCacheMax); add_property(buffer); Probably best to file a bug too. >> As regards setting the property directly (which was never the intention and is not supported) then the issue is that the property value is being parsed lazily. If you want to check it early then it requires parsing it in VM.saveAndRemoveProperties, that is the method that is called early in the initialization to stash away these properties. > Whether this property is parsed early or lazily it seems like the fundamental question remains: given a non-parseable value does one fall back to the default or throw an exception and prevent VM startup? Throwing an exception is a better solution that will make it easier to diagnose the problem. Mandy From xueming.shen at oracle.com Thu May 30 02:53:10 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 30 May 2013 02:53:10 +0000 Subject: hg: jdk8/tl/jdk: 4759491: method ZipEntry.setTime(long) works incorrectly; ... Message-ID: <20130530025333.AE19648E12@hg.openjdk.java.net> Changeset: 90df6756406f Author: sherman Date: 2013-05-29 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f 4759491: method ZipEntry.setTime(long) works incorrectly 6303183: Support NTFS and Unix-style timestamps for entries in Zip files 7012856: (zipfs) Newly created entry in zip file system should set all file times non-null values. 7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone. Summary: to add suuport of Info-ZIP extended timestamp in extra data fields Reviewed-by: martin, alanb ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java + src/share/classes/java/util/zip/ZipUtils.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh ! test/java/util/jar/TestExtra.java ! test/java/util/zip/StoredCRC.java + test/java/util/zip/TestExtraTime.java ! test/java/util/zip/ZipFile/Assortment.java From dan.xu at oracle.com Thu May 30 04:28:29 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 29 May 2013 21:28:29 -0700 Subject: RFR: JDK-8015628 - Test Failure in closed/java/io/pathNames/GeneralSolaris.java Message-ID: <51A6D56D.20902@oracle.com> Hi All, The fix to JDK-8009258 solves the failure in GeneralWin32.java. But the changes in Line 311, 312 in checkNames() method of General.java file, lead to the new failure of GeneralSolaris.java testcase. Because it changes the implicit value of an empty "ask" parameter. This fix is to revert the relevant changes of the above two lines in General.java. And accordingly, it accommodates the code in GeneralWin32.java to the original General.checkNames() method. webrev: http://cr.openjdk.java.net/~dxu/8015628/webrev.00/ Thanks for your review! -Dan From victor2 at ukr.net Thu May 30 06:25:32 2013 From: victor2 at ukr.net (Victor Polischuk) Date: Thu, 30 May 2013 09:25:32 +0300 Subject: Fw: Generics in enums References: <35026.1369813905.3344587357756915712@ffe16.ukr.net> Message-ID: <25884.1369895132.11046637324613910528@ffe12.ukr.net> Greetings, I beg pardon for the previous HTML mail. Some time ago I wanted to migrate our "commons-lang" enums to "java 5" enumerations, but I encountered an issue that it cannot be done without discarding generics since java enums do not support them. Let me show an example: //------ public final class ColorEnum extends org.apache.commons.lang.enums.Enum { public static final ColorEnum RED = new ColorEnum("Red"); public static final ColorEnum GREEN = new ColorEnum("Green"); public static final ColorEnum?BLUE = new ColorEnum("Blue"); public static final ColorEnum WHITE = new ColorEnum("White") { @Override public MixedPixel make() {...}? }; private ColorEnum(String color) {super(color);} public boolean filter(T pixel) {...} public T make() {...} } //------ And I wonder if there is a specific reason why I cannot convert it into something like:? //------ public enum Color { RED("Red"), GREEN("Green"), BLUE("Blue"), WHITE("White") { @Override public MixedPixel make() {...}? }; private Color(String color) {...} public boolean filter(T pixel) {...} public T make() {...} } //------ Thank you in advance. Sincerely yours, Victor Polischuk From martinrb at google.com Thu May 30 06:32:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 May 2013 23:32:14 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: On Wed, May 29, 2013 at 5:20 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: > > > Use third person in the first sentence of a javadoc - e.g. > s/Retrieve/Retrieves/. > > --- > > Don't use the denigrated C style > char zero[] = > Instead use > char[] zero = > > --- > > > Are the two preceding comments generic, i.e., occurring in multiple > places, or each unique? > > Mutliple. From joe.darcy at oracle.com Thu May 30 06:43:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 May 2013 23:43:59 -0700 Subject: Fw: Generics in enums In-Reply-To: <25884.1369895132.11046637324613910528@ffe12.ukr.net> References: <35026.1369813905.3344587357756915712@ffe16.ukr.net> <25884.1369895132.11046637324613910528@ffe12.ukr.net> Message-ID: <51A6F52F.6050105@oracle.com> Hello Victor, On 5/29/2013 11:25 PM, Victor Polischuk wrote: > Greetings, > > I beg pardon for the previous HTML mail. > > Some time ago I wanted to migrate our "commons-lang" enums to "java 5" enumerations, but I encountered an issue that it cannot be done without discarding generics since java enums do not support them. Let me show an example: > > //------ > public final class ColorEnum extends org.apache.commons.lang.enums.Enum { > public static final ColorEnum RED = new ColorEnum("Red"); > public static final ColorEnum GREEN = new ColorEnum("Green"); > public static final ColorEnum?BLUE = new ColorEnum("Blue"); > public static final ColorEnum WHITE = new ColorEnum("White") { > @Override > public MixedPixel make() {...}? > }; > > private ColorEnum(String color) {super(color);} > > public boolean filter(T pixel) {...} > > public T make() {...} > } > //------ > > And I wonder if there is a specific reason why I cannot convert it into something like:? > > //------ > public enum Color { > RED("Red"), > GREEN("Green"), > BLUE("Blue"), > WHITE("White") { > @Override > public MixedPixel make() {...}? > }; > > private Color(String color) {...} > > public boolean filter(T pixel) {...} > > public T make() {...} > } > //------ > > Thank you in advance. > > Sincerely yours, > Victor Polischuk You can approximate this effect by having your enum implement an interface or even a generic interface. For some examples in the JDK see, javax.tools.StandardLocation and java.nio.file.LinkOption. HTH, -Joe From victor2 at ukr.net Thu May 30 07:06:53 2013 From: victor2 at ukr.net (Victor Polischuk) Date: Thu, 30 May 2013 10:06:53 +0300 Subject: Fw: Generics in enums In-Reply-To: <51A6F52F.6050105@oracle.com> References: <35026.1369813905.3344587357756915712@ffe16.ukr.net> <25884.1369895132.11046637324613910528@ffe12.ukr.net> <51A6F52F.6050105@oracle.com> Message-ID: <48787.1369897613.15429353181454925824@ffe15.ukr.net> Good day Joe, Thank you for your prompt reply. If I understood you correctly, it is not the solution which can help me distinguish enum elements by type parameters. I would like to have restrictions on types which can be passed to a enum instance methods and reduce numbers of casts or "instanceof" checks for return values. In case of implementation of an interface I need to write something like: //---- public enum Color implements ColorAspect {...} //---- which is redundant since I can hardcode Pixel type everywhere within the enumeration but the initial intention is to specify type parameters for each enum value independently. Sincerely yours, Victor Polischuk --- Original message --- From: "Joe Darcy" Date: 30 May 2013, 09:44:57 > Hello Victor, > > On 5/29/2013 11:25 PM, Victor Polischuk wrote: > > Greetings, > > > > I beg pardon for the previous HTML mail. > > > > Some time ago I wanted to migrate our "commons-lang" enums to "java 5" enumerations, but I encountered an issue that it cannot be done without discarding generics since java enums do not support them. Let me show an example: > > > > //------ > > public final class ColorEnum extends org.apache.commons.lang.enums.Enum { > > public static final ColorEnum RED = new ColorEnum("Red"); > > public static final ColorEnum GREEN = new ColorEnum("Green"); > > public static final ColorEnum?BLUE = new ColorEnum("Blue"); > > public static final ColorEnum WHITE = new ColorEnum("White") { > > @Override > > public MixedPixel make() {...}? > > }; > > > > private ColorEnum(String color) {super(color);} > > > > public boolean filter(T pixel) {...} > > > > public T make() {...} > > } > > //------ > > > > And I wonder if there is a specific reason why I cannot convert it into something like:? > > > > //------ > > public enum Color { > > RED("Red"), > > GREEN("Green"), > > BLUE("Blue"), > > WHITE("White") { > > @Override > > public MixedPixel make() {...}? > > }; > > > > private Color(String color) {...} > > > > public boolean filter(T pixel) {...} > > > > public T make() {...} > > } > > //------ > > > > Thank you in advance. > > > > Sincerely yours, > > Victor Polischuk > > You can approximate this effect by having your enum implement an > interface or even a generic interface. For some examples in the JDK see, > javax.tools.StandardLocation and java.nio.file.LinkOption. > > HTH, > > -Joe From forax at univ-mlv.fr Thu May 30 07:26:04 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 30 May 2013 09:26:04 +0200 Subject: Fw: Generics in enums In-Reply-To: <48787.1369897613.15429353181454925824@ffe15.ukr.net> References: <35026.1369813905.3344587357756915712@ffe16.ukr.net> <25884.1369895132.11046637324613910528@ffe12.ukr.net> <51A6F52F.6050105@oracle.com> <48787.1369897613.15429353181454925824@ffe15.ukr.net> Message-ID: <51A6FF0C.8040208@univ-mlv.fr> On 05/30/2013 09:06 AM, Victor Polischuk wrote: > Good day Joe, > > Thank you for your prompt reply. If I understood you correctly, it is not the solution which can help me distinguish enum elements by type parameters. I would like to have restrictions on types which can be passed to a enum instance methods and reduce numbers of casts or "instanceof" checks for return values. In case of implementation of an interface I need to write something like: > //---- > public enum Color implements ColorAspect {...} > //---- > which is redundant since I can hardcode Pixel type everywhere within the enumeration but the initial intention is to specify type parameters for each enum value independently. the idea is to do something like this: interface Color { public boolean filter(T pixel) {...} public T make() {...} } public enum PurePixelColor implements Color { RED("Red"), GREEN("Green"), BLUE("Blue"); private PurePixelColor(String color) {...} public boolean filter(PurePixel pixel) {...} public PurePixel make() {...} } public enum MixedPixelColor implements Color { WHITE("White"); private MixedPixelColor(String color) {...} public boolean filter(MixedPixel pixel) {...} public MixedPixel make() {...} } if you compare with your current code, Color objects are not comparable to themselve anymore. and if the code of filter is the same for PurePixelColor and MixedPixelColor you have to extract it somewhere in a static method. The feature you ask was asked several times when java5 was released but was considered as a corner case that doesn't worth the added complexity to the implementation. > > Sincerely yours, > Victor Polischuk cheers, R?mi > --- Original message --- > From: "Joe Darcy" > Date: 30 May 2013, 09:44:57 > > >> Hello Victor, >> >> On 5/29/2013 11:25 PM, Victor Polischuk wrote: >>> Greetings, >>> >>> I beg pardon for the previous HTML mail. >>> >>> Some time ago I wanted to migrate our "commons-lang" enums to "java 5" enumerations, but I encountered an issue that it cannot be done without discarding generics since java enums do not support them. Let me show an example: >>> >>> //------ >>> public final class ColorEnum extends org.apache.commons.lang.enums.Enum { >>> public static final ColorEnum RED = new ColorEnum("Red"); >>> public static final ColorEnum GREEN = new ColorEnum("Green"); >>> public static final ColorEnum?BLUE = new ColorEnum("Blue"); >>> public static final ColorEnum WHITE = new ColorEnum("White") { >>> @Override >>> public MixedPixel make() {...}? >>> }; >>> >>> private ColorEnum(String color) {super(color);} >>> >>> public boolean filter(T pixel) {...} >>> >>> public T make() {...} >>> } >>> //------ >>> >>> And I wonder if there is a specific reason why I cannot convert it into something like:? >>> >>> //------ >>> public enum Color { >>> RED("Red"), >>> GREEN("Green"), >>> BLUE("Blue"), >>> WHITE("White") { >>> @Override >>> public MixedPixel make() {...}? >>> }; >>> >>> private Color(String color) {...} >>> >>> public boolean filter(T pixel) {...} >>> >>> public T make() {...} >>> } >>> //------ >>> >>> Thank you in advance. >>> >>> Sincerely yours, >>> Victor Polischuk >> You can approximate this effect by having your enum implement an >> interface or even a generic interface. For some examples in the JDK see, >> javax.tools.StandardLocation and java.nio.file.LinkOption. >> >> HTH, >> >> -Joe From peter.levart at gmail.com Thu May 30 07:42:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 May 2013 09:42:35 +0200 Subject: Fw: Generics in enums In-Reply-To: <51A6FF0C.8040208@univ-mlv.fr> References: <35026.1369813905.3344587357756915712@ffe16.ukr.net> <25884.1369895132.11046637324613910528@ffe12.ukr.net> <51A6F52F.6050105@oracle.com> <48787.1369897613.15429353181454925824@ffe15.ukr.net> <51A6FF0C.8040208@univ-mlv.fr> Message-ID: <51A702EB.1060308@gmail.com> On 05/30/2013 09:26 AM, Remi Forax wrote: > On 05/30/2013 09:06 AM, Victor Polischuk wrote: >> Good day Joe, >> >> Thank you for your prompt reply. If I understood you correctly, it is >> not the solution which can help me distinguish enum elements by type >> parameters. I would like to have restrictions on types which can be >> passed to a enum instance methods and reduce numbers of casts or >> "instanceof" checks for return values. In case of implementation of >> an interface I need to write something like: >> //---- >> public enum Color implements ColorAspect {...} >> //---- >> which is redundant since I can hardcode Pixel type everywhere within >> the enumeration but the initial intention is to specify type >> parameters for each enum value independently. > > the idea is to do something like this: > > interface Color { > public boolean filter(T pixel) {...} > public T make() {...} > } > > public enum PurePixelColor implements Color { > RED("Red"), > GREEN("Green"), > BLUE("Blue"); > > private PurePixelColor(String color) {...} > > public boolean filter(PurePixel pixel) {...} > > public PurePixel make() {...} > } > > public enum MixedPixelColor implements Color { > WHITE("White"); > private MixedPixelColor(String color) {...} > > public boolean filter(MixedPixel pixel) {...} > > public MixedPixel make() {...} > } > > > if you compare with your current code, > Color objects are not comparable to themselve anymore. > and if the code of filter is the same for PurePixelColor and > MixedPixelColor you have to extract it somewhere in a static method. Or code it as a "default" method in Color interface if you can use JDK8 ;-) Regards, Peter > > The feature you ask was asked several times when java5 was released > but was considered as a corner case that doesn't worth the added > complexity to the implementation. > >> >> Sincerely yours, >> Victor Polischuk > > cheers, > R?mi > >> --- Original message --- >> From: "Joe Darcy" >> Date: 30 May 2013, 09:44:57 >> >>> Hello Victor, >>> >>> On 5/29/2013 11:25 PM, Victor Polischuk wrote: >>>> Greetings, >>>> >>>> I beg pardon for the previous HTML mail. >>>> >>>> Some time ago I wanted to migrate our "commons-lang" enums to "java >>>> 5" enumerations, but I encountered an issue that it cannot be done >>>> without discarding generics since java enums do not support them. >>>> Let me show an example: >>>> >>>> //------ >>>> public final class ColorEnum extends >>>> org.apache.commons.lang.enums.Enum { >>>> public static final ColorEnum RED = new >>>> ColorEnum("Red"); >>>> public static final ColorEnum GREEN = new >>>> ColorEnum("Green"); >>>> public static final ColorEnum?BLUE = new >>>> ColorEnum("Blue"); >>>> public static final ColorEnum WHITE = new >>>> ColorEnum("White") { >>>> @Override >>>> public MixedPixel make() {...}? >>>> }; >>>> private ColorEnum(String color) {super(color);} >>>> public boolean filter(T pixel) {...} >>>> public T make() {...} >>>> } >>>> //------ >>>> >>>> And I wonder if there is a specific reason why I cannot convert it >>>> into something like:? >>>> >>>> //------ >>>> public enum Color { >>>> RED("Red"), >>>> GREEN("Green"), >>>> BLUE("Blue"), >>>> WHITE("White") { >>>> @Override >>>> public MixedPixel make() {...}? >>>> }; >>>> >>>> private Color(String color) {...} >>>> >>>> public boolean filter(T pixel) {...} >>>> >>>> public T make() {...} >>>> } >>>> //------ >>>> >>>> Thank you in advance. >>>> >>>> Sincerely yours, >>>> Victor Polischuk >>> You can approximate this effect by having your enum implement an >>> interface or even a generic interface. For some examples in the JDK >>> see, >>> javax.tools.StandardLocation and java.nio.file.LinkOption. >>> >>> HTH, >>> >>> -Joe > From david.holmes at oracle.com Thu May 30 07:35:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2013 17:35:00 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> <51A55A64.8060908@oracle.com> Message-ID: <51A70124.2070406@oracle.com> Hi Otavio, On 29/05/2013 9:03 PM, Ot?vio Gon?alves de Santana wrote: > Thank you everyone. > I searched classes with this situation and I find these classes: > > * sun.tools.java.MemberDefinition > * sun.rmi.rmic.Main > * sun.tools.jconsole.inspector.Utils > * com.sun.jndi.toolkit.dir.SearchFilter > * javax.swing.text.html.FormView Yes these should be cleaned up - to be good examples if nothing else. Invoking toString() on a String is just silly. The Swing change would need to go through the swing-dev folk to get the okay. > > The diffs is in attachment Attachments to the openjdk mailing lists tend to get stripped. I got it as I was directly cc'd. I'll use it to generate a webrev for you and I will file a bug for this cleanup. Thanks, David > > On Tue, May 28, 2013 at 10:31 PM, David Holmes > wrote: > > On 28/05/2013 11:08 PM, Remi Forax wrote: > > On 05/28/2013 02:48 PM, David Holmes wrote: > > Sorry it didn't register that getName() already returns a > String - > hence the toString() is redundant - but minimally so. > > David > > > The second call to toString() also performs an implicit nullcheck > (elementName can not be null). > So if we have to fix something, it's only to remove the call to > toString() after the call to getName(). > > > Good catch Remi! > > Otavio: I don't want to dissuade you from getting involved but as > Remi indicates your suggested change becomes simply > > > - super(annotationType.getName()__.toString() + > + super(annotationType.getName() + > > and this is such a minor change to interpreted performance (the JIT > will remove the toString call) that I don't think it is worth the > process overhead (testing etc) to actually make this change. As I > said in other email sometimes there are non-obvious reasons (like > null checks :) ) that code has to be kept in its current form. > > David > ----- > > > cheers, > R?mi > > > On 28/05/2013 9:15 PM, David Holmes wrote: > > Please see my reply under your original subject line. > > This is not a bug. > > David > > On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: > > diff --git > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > --- > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > +++ > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > @@ -55,9 +55,9 @@ > public IncompleteAnnotationException( > Class > annotationType, > String elementName) { > - super(annotationType.getName()__.toString() + > + super(annotationType.getName() + > " missing element " + > - elementName.toString()); > + elementName); > > this.annotationType = annotationType; > this.elementName = elementName; > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From david.holmes at oracle.com Thu May 30 07:40:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2013 17:40:50 +1000 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A64D93.9070708@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> <51A642A7.1090500@oracle.com> <51A64D93.9070708@oracle.com> Message-ID: <51A70282.6030200@oracle.com> Roger, I think you may be misunderstanding the purpose of the contention groups. They are, as the docs state, for defining a set of fields that need isolation from other sets of fields. They are not for defining set of fields which would benefit from co-location. David On 30/05/2013 4:48 AM, roger riggs wrote: > Hi Aleksey, > > Thanks for the references. Currently, you are correct, I don't need it. > > Has it been considered that highly contended field should not be allocated > in the object itself anyway but in some pool or structure better suited > to its access characteristics? A read-only indirection could provide > some ability to allocate contended locks elsewhere where they would > not disrupt the allocation mechanism. For example, in a pool > of write-only or write-mostly values for the processor/core/thread. > Of course, that has an access cost too. > > But given the credentials of the discussion authors I expect this has been > well vetted and I have not much to offer. > Limiting the scope of @contended groups prevents being able to > groups fields from different classes/subclasses together that might > reasonably share access patterns. > > The language related to 'intrinsically worthwhile' deserves a caution > label. > History is full of premature optimizations. Since it is mentioned that > instrumentation is not available to compute the costs of contention > in a particular use case, then only macro level performance of the > application > would be available to judge the effectiveness of a particular @Contended > usage. But the cost in memory is immediate and measurable. > > Thanks, Roger > > > > On 5/29/2013 2:02 PM, Aleksey Shipilev wrote: >> Hi Roger, >> >> On 05/29/2013 09:12 PM, roger riggs wrote: >>> I'm not sure I quite understand the purpose or semantics of this >>> annotation. >> That's the early sign you don't need it! :) I'm actually envious. >> >>> Since it is in sun.misc, it may not be so important and is just an >>> implementation artifact but does not have enough of a standalone >>> description nor connection to the other elements. >> See: >> http://openjdk.java.net/jeps/142 >> https://blogs.oracle.com/dave/entry/java_contented_annotation_to_help >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html >> >> >> ...for more rationale. >> >>> The description of the annotation is an odd mix of hints about the >>> usage of fields and specification of required behavior of an >>> implementation. >> Hm. If there is the issue with the javadoc, I'm failing to see it; maybe >> because I am exposed to false sharing enough to immediately understand >> what @C is about. >> >> Even though this is an internal API, and we just want to specify @C >> barely enough to be useful for those who need it, specific examples what >> is broken with the docs are welcome. >> >>> I would expect an implementation to be able to ignore the annotation >>> or perhaps to improve on the performance by utilizing runtime >>> available information. It is more useful to say what the annotation >>> does mean than to say what it does not mean. >> Yes, hints are by definition ignorable. Should the runtime be able to >> figure out the memory contention issues on its own, we will just "noop" >> @C, and be done. But, that Holy Grail is not here. >> >>> Contention groups are a useful semantic but to say that a contention >>> group " must be isolated from all other contention groups." is >>> something for the implementation to determine. >> I guess the valid concern is the use of "must"? Implementations may >> choose to protect the grouped fields on their own if it chooses to do so. > Yep. >> >> -Aleksey. > From aleksey.shipilev at oracle.com Thu May 30 08:46:29 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 30 May 2013 12:46:29 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> Message-ID: <51A711E5.30108@oracle.com> On 05/29/2013 11:29 PM, Martin Buchholz wrote: > Looks good enough to me for a non-public API. I expect more contentious > arguments if this is ever made public, since the problems remain very > tricky. Yes, that's why we want to keep it internal for now. I'd like to hear the final "yes" from David :) -Aleksey. From aleksey.shipilev at oracle.com Thu May 30 08:49:48 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 30 May 2013 12:49:48 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A64D93.9070708@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> <51A642A7.1090500@oracle.com> <51A64D93.9070708@oracle.com> Message-ID: <51A712AC.6020700@oracle.com> Hi Roger, On 05/29/2013 10:48 PM, roger riggs wrote: > Thanks for the references. Currently, you are correct, I don't need it. Now I am envious! > Has it been considered that highly contended field should not be allocated > in the object itself anyway but in some pool or structure better suited > to its access characteristics? A read-only indirection could provide > some ability to allocate contended locks elsewhere where they would > not disrupt the allocation mechanism. For example, in a pool > of write-only or write-mostly values for the processor/core/thread. > Of course, that has an access cost too. That's an interesting idea, and we had discussed it a bit internally. The major problem is a mess in runtime to segregate the accesses to the plain fields and the contended ones. This change is much more intrusive than the smart padding within the instance itself; and the benefits are unclear. You will still have to reserve the space at the allocation time (yes, sophisticated schemes can do that lazily), you still have indirection, etc. That said, it might be our thing to do once we see it is actually required. At this point, we better have the version which works absolutely correct in all the scenarios. -Aleksey. From aleksey.shipilev at oracle.com Thu May 30 08:55:02 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 30 May 2013 12:55:02 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A712AC.6020700@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> <51A642A7.1090500@oracle.com> <51A64D93.9070708@oracle.com> <51A712AC.6020700@oracle.com> Message-ID: <51A713E6.403@oracle.com> On 05/30/2013 12:49 PM, Aleksey Shipilev wrote: > On 05/29/2013 10:48 PM, roger riggs wrote: >> Has it been considered that highly contended field should not be allocated >> in the object itself anyway but in some pool or structure better suited >> to its access characteristics? A read-only indirection could provide >> some ability to allocate contended locks elsewhere where they would >> not disrupt the allocation mechanism. For example, in a pool >> of write-only or write-mostly values for the processor/core/thread. >> Of course, that has an access cost too. > > That's an interesting idea, and we had discussed it a bit internally. > The major problem is a mess in runtime to segregate the accesses to the > plain fields and the contended ones. This change is much more intrusive > than the smart padding within the instance itself; and the benefits are > unclear. You will still have to reserve the space at the allocation time > (yes, sophisticated schemes can do that lazily), you still have > indirection, etc. ...actually the largest trouble: you have to garbage-collect off-instance fields somehow, which includes tracking the reachability, which probably entails write barriers for those fields... Remarkably, this sounds like another use for ephemerons :) [---- I'd like to draw the line for metaphysical discussions here ----] :) -Aleksey. From daniel.fuchs at oracle.com Thu May 30 08:59:29 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 30 May 2013 10:59:29 +0200 Subject: RFR (jaxp): review backport to jdk7u-dev of 8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Message-ID: <51A714F1.2070603@oracle.com> Hi, This is a request for review to backport the changes for: to jdk7u-dev. The changeset for jdk7u-dev only slightly differs from that for jdk 8, on these two counts: 1. JAXP needs to be compiled with the bootstrap JDK - which means that JAXP in jdk 7 cannot depend on new jdk 7 APIs. In Encodings.java I had to replace a try-with-resource by a try-finally. 2. The jdk/test/Makefile needed to be updated in order to add javax/xml/jaxp to the jdk_other target. Here is the webrev for the changeset that was pushed in jdk8: http://cr.openjdk.java.net/~dfuchs/JDK-8008738/webrev.03/ Here is the altered webrev for jdk7u-dev: http://cr.openjdk.java.net/~dfuchs/JDK-8008738/webrev-jdk7u-dev.00/ Best regards, -- daniel The review for the original fix happened for jdk8 on the core-libs-dev list, in these two thread: From daniel.fuchs at oracle.com Thu May 30 10:37:16 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 30 May 2013 12:37:16 +0200 Subject: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp. Message-ID: <51A72BDC.6010900@oracle.com> Hi, This is a request for review of the backport of to jdk7u-dev. The changeset for jdk7u-dev [1] had to be altered on one count compared to the changes pushed in jdk8 [2]: Since jaxp needs to be compiled using the bootstrap compiler, it was not possible to use the new JDK 7 java.util.Objects API. In order to minimize the changes between the two changesets - I added an Objects class emulating the two 'hashCode' and 'equals' methods of java.util.Objects in the util packages of Xerces, Xalan, and Bcel. This way - the only thing that needed to change in the rest of the files was the import clause of the Objects class. Here is the altered changeset for jdk7u-dev: [1] Here is the changeset that was pushed in jdk8: [2] -- daniel Review for the original jdk8 changeset [2] happened on core-libs-dev: From chris.hegarty at oracle.com Thu May 30 11:21:39 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 30 May 2013 11:21:39 +0000 Subject: hg: jdk8/tl/jdk: 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Message-ID: <20130530112205.4794848E23@hg.openjdk.java.net> Changeset: 6df9b071b04d Author: jzavgren Date: 2013-05-30 12:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df9b071b04d 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Reviewed-by: martin, dholmes, chegar, ksrini ! src/solaris/bin/java_md_solinux.c From dmytro_sheyko at hotmail.com Thu May 30 11:32:08 2013 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 30 May 2013 14:32:08 +0300 Subject: FW: PhantomReference: why not cleared by GC when enqueued? In-Reply-To: References: Message-ID: Mark, You are listed as an author of java.lang.ref classes. So you must know more than others. Could you shed light on this? Thank you, Dmytro From: dmytro_sheyko at hotmail.com To: hotspot-gc-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: PhantomReference: why not cleared by GC when enqueued? Date: Wed, 29 May 2013 14:45:54 +0300 Hello, Why phantom references are not automatically cleared by the garbage collector as they are enqueued? Keeping phantom reachable objects in heap has some drawbacks: 1. At least 2 GC are required in order to reclaim them, even in case when application code pulls references from reference queue and clears them promptly. 2. GC pauses are increased since phantom reachable objects are still to be marked. On the other hand, benefits are not obvious. How we can use referent if it's not accessible? Regards, Dmytro From jaroslav.bachorik at oracle.com Thu May 30 11:59:00 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 30 May 2013 11:59:00 +0000 Subject: hg: jdk8/tl/jdk: 8015627: test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails in agentvm mode Message-ID: <20130530115914.63A4F48E25@hg.openjdk.java.net> Changeset: dc22b7241a70 Author: jbachorik Date: 2013-05-30 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc22b7241a70 8015627: test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails in agentvm mode Reviewed-by: alanb, chegar ! test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java From Alan.Bateman at oracle.com Thu May 30 12:31:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 May 2013 13:31:42 +0100 Subject: RFR JDK-8015271: Conversion table for EUC-KR is incorrect In-Reply-To: <51A635EE.4050605@oracle.com> References: <51A635EE.4050605@oracle.com> Message-ID: <51A746AE.9050508@oracle.com> On 29/05/2013 18:07, Xueming Shen wrote: > Hi, > > Here is proposal to add one mapping entry into the mapping table for > EUC-KR > to add the "newly" added KS X 1001:2002 code point > > 2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E) > > Info regarding this code point > http://www.unicode.org/L2/L2004/04267-n2815.pdf > > Here is the mapping change webrev > > http://cr.openjdk.java.net/~sherman/8015271/webrev This looks okay to me. Do you know if we are missing any other mappings? I see a few other "CIRCLED KOREAN CHARACTER", U+327C for example, but I don't know what their status is. -Alan From roger.riggs at oracle.com Thu May 30 13:54:38 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 30 May 2013 09:54:38 -0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A70282.6030200@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A63709.1040600@oracle.com> <51A642A7.1090500@oracle.com> <51A64D93.9070708@oracle.com> <51A70282.6030200@oracle.com> Message-ID: <51A75A1E.6000304@oracle.com> Hi David, I understand that but there may exist some set of contention groups that could be co-located (share a cache line) without causing additional interference but the Annotation does not have a mechanism to express that. Given the restriction on inheritance of @Contended, it is not even possible to express it for known subclasses or related classes. Since this is still a science project, it will be interesting to see how the investigation proceeds. It feels like something that isn't really for the main line and should be co-located (repository wise) with the related implementation work. $.02, Roger On 5/30/2013 3:40 AM, David Holmes wrote: > Roger, > > I think you may be misunderstanding the purpose of the contention > groups. They are, as the docs state, for defining a set of fields that > need isolation from other sets of fields. They are not for defining > set of fields which would benefit from co-location. > > David > > On 30/05/2013 4:48 AM, roger riggs wrote: >> Hi Aleksey, >> >> Thanks for the references. Currently, you are correct, I don't need it. >> >> Has it been considered that highly contended field should not be >> allocated >> in the object itself anyway but in some pool or structure better suited >> to its access characteristics? A read-only indirection could provide >> some ability to allocate contended locks elsewhere where they would >> not disrupt the allocation mechanism. For example, in a pool >> of write-only or write-mostly values for the processor/core/thread. >> Of course, that has an access cost too. >> >> But given the credentials of the discussion authors I expect this has >> been >> well vetted and I have not much to offer. >> Limiting the scope of @contended groups prevents being able to >> groups fields from different classes/subclasses together that might >> reasonably share access patterns. >> >> The language related to 'intrinsically worthwhile' deserves a caution >> label. >> History is full of premature optimizations. Since it is mentioned that >> instrumentation is not available to compute the costs of contention >> in a particular use case, then only macro level performance of the >> application >> would be available to judge the effectiveness of a particular @Contended >> usage. But the cost in memory is immediate and measurable. >> >> Thanks, Roger >> >> >> >> On 5/29/2013 2:02 PM, Aleksey Shipilev wrote: >>> Hi Roger, >>> >>> On 05/29/2013 09:12 PM, roger riggs wrote: >>>> I'm not sure I quite understand the purpose or semantics of this >>>> annotation. >>> That's the early sign you don't need it! :) I'm actually envious. >>> >>>> Since it is in sun.misc, it may not be so important and is just an >>>> implementation artifact but does not have enough of a standalone >>>> description nor connection to the other elements. >>> See: >>> http://openjdk.java.net/jeps/142 >>> https://blogs.oracle.com/dave/entry/java_contented_annotation_to_help >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html >>> >>> >>> >>> ...for more rationale. >>> >>>> The description of the annotation is an odd mix of hints about the >>>> usage of fields and specification of required behavior of an >>>> implementation. >>> Hm. If there is the issue with the javadoc, I'm failing to see it; >>> maybe >>> because I am exposed to false sharing enough to immediately understand >>> what @C is about. >>> >>> Even though this is an internal API, and we just want to specify @C >>> barely enough to be useful for those who need it, specific examples >>> what >>> is broken with the docs are welcome. >>> >>>> I would expect an implementation to be able to ignore the annotation >>>> or perhaps to improve on the performance by utilizing runtime >>>> available information. It is more useful to say what the annotation >>>> does mean than to say what it does not mean. >>> Yes, hints are by definition ignorable. Should the runtime be able to >>> figure out the memory contention issues on its own, we will just "noop" >>> @C, and be done. But, that Holy Grail is not here. >>> >>>> Contention groups are a useful semantic but to say that a contention >>>> group " must be isolated from all other contention groups." is >>>> something for the implementation to determine. >>> I guess the valid concern is the use of "must"? Implementations may >>> choose to protect the grouped fields on their own if it chooses to >>> do so. >> Yep. >>> >>> -Aleksey. >> From paul.sandoz at oracle.com Thu May 30 14:26:18 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 30 May 2013 14:26:18 +0000 Subject: hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Message-ID: <20130530142644.D115248E2A@hg.openjdk.java.net> Changeset: 156ee44cd456 Author: psandoz Date: 2013-05-30 16:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: alanb, chegar, mduigou ! src/share/classes/java/util/stream/StreamBuilder.java From paul.sandoz at oracle.com Thu May 30 14:34:17 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 30 May 2013 14:34:17 +0000 Subject: hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Message-ID: <20130530143434.2119C48E2D@hg.openjdk.java.net> Changeset: b4742d038100 Author: psandoz Date: 2013-05-28 15:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: alanb, chegar ! 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 From huizhe.wang at oracle.com Thu May 30 15:26:09 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 30 May 2013 08:26:09 -0700 Subject: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp. In-Reply-To: <51A72BDC.6010900@oracle.com> References: <51A72BDC.6010900@oracle.com> Message-ID: <51A76F91.4070402@oracle.com> Thanks Daniel! The backport looks good. This would help keep the code in sync between JKD7 and JDK8, which makes it easier for future backports. Joe On 5/30/2013 3:37 AM, Daniel Fuchs wrote: > Hi, > > This is a request for review of the backport of > > to jdk7u-dev. > > The changeset for jdk7u-dev [1] had to be altered on one count > compared to the changes pushed in jdk8 [2]: > > Since jaxp needs to be compiled using the bootstrap > compiler, it was not possible to use the new > JDK 7 java.util.Objects API. > > In order to minimize the changes between the two > changesets - I added an Objects class emulating > the two 'hashCode' and 'equals' methods of java.util.Objects > in the util packages of Xerces, Xalan, and Bcel. > > This way - the only thing that needed to change in the rest of > the files was the import clause of the Objects class. > > Here is the altered changeset for jdk7u-dev: > [1] > > Here is the changeset that was pushed in jdk8: > [2] > > -- daniel > > Review for the original jdk8 changeset [2] happened on core-libs-dev: > > From chris.hegarty at oracle.com Thu May 30 16:09:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 May 2013 17:09:48 +0100 Subject: RFR JDK-8003245 In-Reply-To: <24356968-438c-495a-859a-bab0af138c23@default> References: <24356968-438c-495a-859a-bab0af138c23@default> Message-ID: <51A779CC.9070101@oracle.com> [cc'ing security-dev since this change is in their area] John, http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/ The changes in your above webrev look fine to me. I can sponsor this for you, unless someone from the security area wants to, or even additional reviews. -Chris. On 03/27/2013 04:30 PM, John Zavgren wrote: > Florian: > > Yes, the uninitialized memory will be accessed in some cases, for example: > @@ -1733,10 +1747,12 @@ > CK_X9_42_DH1_DERIVE_PARAMS ckParam; > jfieldID fieldID; > jlong jKdf; > jobject jOtherInfo, jPublicData; > > + memset(&ckParam, 0, sizeof(CK_X9_42_DH1_DERIVE_PARAMS));<--- added initialization > + > /* get kdf */ > jX942Dh1DeriveParamsClass = (*env)->FindClass(env, CLASS_X9_42_DH1_DERIVE_PARAMS); > if (jX942Dh1DeriveParamsClass == NULL) { return ckParam; } > fieldID = (*env)->GetFieldID(env, jX942Dh1DeriveParamsClass, "kdf", "J"); > if (fieldID == NULL) { return ckParam; } > > ----- Original Message ----- > From: fweimer at redhat.com > To: john.zavgren at oracle.com > Cc: core-libs-dev at openjdk.java.net > Sent: Wednesday, March 27, 2013 11:48:57 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR JDK-8003245 > > On 03/20/2013 04:27 PM, John Zavgren wrote: >> Please consider the following changes that eliminate the use of uninitialized memory. > >> http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/ > > Is the uninitialized memory accessed on the error paths? > From brian.burkhalter at oracle.com Thu May 30 16:11:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 May 2013 09:11:05 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: On May 29, 2013, at 11:32 PM, Martin Buchholz wrote: > On Wed, May 29, 2013 at 5:20 PM, Brian Burkhalter wrote: > On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: >> >> Use third person in the first sentence of a javadoc - e.g. s/Retrieve/Retrieves/. >> >> --- >> >> Don't use the denigrated C style >> char zero[] = >> Instead use >> char[] zero = >> >> --- > > Are the two preceding comments generic, i.e., occurring in multiple places, or each unique? > > > Mutliple. All right: I will locate them and update the webrev. Thanks, Brian From chris.hegarty at oracle.com Thu May 30 16:22:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 May 2013 17:22:00 +0100 Subject: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp. In-Reply-To: <51A72BDC.6010900@oracle.com> References: <51A72BDC.6010900@oracle.com> Message-ID: <51A77CA8.9010905@oracle.com> Looks fine to me Daniel, I see you have three copies of Objects.java, is it possible to put it in a common place accessible to all? Or maybe this causes other issues. -Chris. On 05/30/2013 11:37 AM, Daniel Fuchs wrote: > Hi, > > This is a request for review of the backport of > > to jdk7u-dev. > > The changeset for jdk7u-dev [1] had to be altered on one count > compared to the changes pushed in jdk8 [2]: > > Since jaxp needs to be compiled using the bootstrap > compiler, it was not possible to use the new > JDK 7 java.util.Objects API. > > In order to minimize the changes between the two > changesets - I added an Objects class emulating > the two 'hashCode' and 'equals' methods of java.util.Objects > in the util packages of Xerces, Xalan, and Bcel. > > This way - the only thing that needed to change in the rest of > the files was the import clause of the Objects class. > > Here is the altered changeset for jdk7u-dev: > [1] > > Here is the changeset that was pushed in jdk8: > [2] > > -- daniel > > Review for the original jdk8 changeset [2] happened on core-libs-dev: > From huizhe.wang at oracle.com Thu May 30 16:52:07 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 30 May 2013 09:52:07 -0700 Subject: RFR (jaxp): review backport to jdk7u-dev of 8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently In-Reply-To: <51A714F1.2070603@oracle.com> References: <51A714F1.2070603@oracle.com> Message-ID: <51A783B7.10104@oracle.com> Hi Daniel, This looks good. Thanks again for the extra effort to keep JDK7 updated. -Joe On 5/30/2013 1:59 AM, Daniel Fuchs wrote: > Hi, > > This is a request for review to backport the changes for: > > to jdk7u-dev. > > The changeset for jdk7u-dev only slightly differs from that > for jdk 8, on these two counts: > > 1. JAXP needs to be compiled with the bootstrap JDK - which > means that JAXP in jdk 7 cannot depend on new jdk 7 APIs. > > In Encodings.java I had to replace a try-with-resource by > a try-finally. > > 2. The jdk/test/Makefile needed to be updated in order to add > javax/xml/jaxp to the jdk_other target. > > Here is the webrev for the changeset that was pushed in jdk8: > http://cr.openjdk.java.net/~dfuchs/JDK-8008738/webrev.03/ > > Here is the altered webrev for jdk7u-dev: > http://cr.openjdk.java.net/~dfuchs/JDK-8008738/webrev-jdk7u-dev.00/ > > Best regards, > > -- daniel > > The review for the original fix happened for jdk8 on the > core-libs-dev list, in these two thread: > > > > > > > From huizhe.wang at oracle.com Thu May 30 17:30:09 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 30 May 2013 10:30:09 -0700 Subject: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp. In-Reply-To: <51A77CA8.9010905@oracle.com> References: <51A72BDC.6010900@oracle.com> <51A77CA8.9010905@oracle.com> Message-ID: <51A78CA1.2020700@oracle.com> On 5/30/2013 9:22 AM, Chris Hegarty wrote: > Looks fine to me Daniel, > > I see you have three copies of Objects.java, is it possible to put it > in a common place accessible to all? Or maybe this causes other issues. JAXP consists of multiple components. The Xerces and Xalan components specifically are by their own and do not have references across the boundaries. Our next project is modularization in which Xerces and Xalan will definitely be split into difference modules. As for BCEL, since it's always by itself, it's preferable to let it that way, unless it really affects footprint. -Joe > > -Chris. > > On 05/30/2013 11:37 AM, Daniel Fuchs wrote: >> Hi, >> >> This is a request for review of the backport of >> >> to jdk7u-dev. >> >> The changeset for jdk7u-dev [1] had to be altered on one count >> compared to the changes pushed in jdk8 [2]: >> >> Since jaxp needs to be compiled using the bootstrap >> compiler, it was not possible to use the new >> JDK 7 java.util.Objects API. >> >> In order to minimize the changes between the two >> changesets - I added an Objects class emulating >> the two 'hashCode' and 'equals' methods of java.util.Objects >> in the util packages of Xerces, Xalan, and Bcel. >> >> This way - the only thing that needed to change in the rest of >> the files was the import clause of the Objects class. >> >> Here is the altered changeset for jdk7u-dev: >> [1] >> >> Here is the changeset that was pushed in jdk8: >> [2] >> >> -- daniel >> >> Review for the original jdk8 changeset [2] happened on core-libs-dev: >> >> From iris.clark at oracle.com Thu May 30 18:15:20 2013 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 30 May 2013 11:15:20 -0700 (PDT) Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: <9b0c3525-5d3b-416d-835e-865d0fdd001c@default> Hi, Brian. This looks fantastic. The changes in Formatter look fine to me. I also took a quick look at FormattedFloatingDecimal and am thrilled. I think you changes have also addressed this bug: 5057835- FormattedFloatingDecimal: massive code duplication in J2SE http://bugs.sun.com/view_bug.do?bug_id=5057835 I think you're good to go once you verify that you successfully ran the regression tests in test/java/util/Formatter. Thanks! iris -----Original Message----- From: Martin Buchholz [mailto:martinrb at google.com] Sent: Wednesday, May 29, 2013 4:58 PM To: Brian Burkhalter Cc: core-libs-dev Subject: Re: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal I would like to see the real world-class experts on this scary math stuff (Alan Eliasen, Tim Buktu) be made honorary jdk reviewers, just for their area of specialization, if that was bureaucratically possible. Shouldn't the original authors be cc'ed? The code is awesome. My thorough review found only these defects: Use third person in the first sentence of a javadoc - e.g. s/Retrieve/Retrieves/. --- Don't use the denigrated C style char zero[] = Instead use char[] zero = --- This looks odd: normalized as a//binary* The original comment looked more normal: normalized as a *binary* --- Otherwise, approved! On Fri, May 24, 2013 at 10:09 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Originally posted one month ago today. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016355 > .html > > https://www.youtube.com/watch?v=D9kv_V5lhiE > > Thanks, > > Brian > From mike.duigou at oracle.com Thu May 30 18:18:04 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 30 May 2013 11:18:04 -0700 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: <51A5FE82.20903@cs.oswego.edu> References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A5FE82.20903@cs.oswego.edu> Message-ID: On May 29 2013, at 06:11 , Doug Lea wrote: > On 05/28/13 15:07, Mike Duigou wrote: >> Hi Chris & Doug; > >> - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type >> particularly for newKeySet(). Why not return Set? The additional methods >> don't seem to offer much that's desirable for the newKeySet() case. > > Since we don't have a ConcurrentSet interface, people are reduced to > instanceof checks to see if they have a concurrent one. But without > exposing the class, they couldn't even do this, so complained. This > will arise more frequently with j.u.streams.Collectors. I'd rather introduce a vacuous ConcurrentSet than expose ConcurrentHashMap.KeySetView. Any reason not to add it? >> - I am reluctant to deprecate contains(Object) here unless we deprecate it in >> Hashtable as well. I recognize that this has been a source of errors >> (https://issues.apache.org/bugzilla/show_bug.cgi?id=48755 for one example). >> Is it time to deprecate it there as well? > > Sure, but why bother. Anyone still using Hashtable is not going to care > if they get more deprecation warnings :-) Fair enough. I will create a bug for deprecating Hashtable.contains as well but am fine with marking it deprecated here. >> - I think there could be more complete description of the >> parallelismThreshold and interaction with common pool. i.e. does "maximal >> parallelism" mean one thread per element or "size() / >> getCommonPoolParallelism()". Some advice for choosing in-between values would >> be good unless "1" is the best advice for cases where you just don't know. It >> would be a shame to see people shooting themselves in the foot with this. >> > > Changed to: > > *

                  These bulk operations accept a {@code parallelismThreshold} > * argument. Methods proceed sequentially if the current map size is > * estimated to be less than the given threshold. Using a value of > * {@code Long.MAX_VALUE} suppresses all parallelism. Using a value > * of {@code 1} results in maximal parallelism by partitioning into > * enough subtasks to utilize all processors. Normally, you would > * initially choose one of these extreme values, and then measure > * performance of using in-between values that trade off overhead > * versus throughput. Parallel forms use the {@link > * ForkJoinPool#commonPool()}. > * only one change I would make is : Using a value of {@code 1} results in maximal parallelism by partitioning into enough subtasks to fully utilize the {@link ForkJoinPool#commonPool()}. > > I'd rather not explicitly mention here any particular values for people > to try, since any number we might put is likely to be misused. Yes, that would almost certainly be misused. > Sometime, we should write up a little how-to document about > tuning parallelism separately. > > -Doug > > From xueming.shen at oracle.com Thu May 30 18:50:30 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 30 May 2013 11:50:30 -0700 Subject: RFR JDK-8015271: Conversion table for EUC-KR is incorrect In-Reply-To: <51A746AE.9050508@oracle.com> References: <51A635EE.4050605@oracle.com> <51A746AE.9050508@oracle.com> Message-ID: <51A79F76.3090100@oracle.com> On 05/30/2013 05:31 AM, Alan Bateman wrote: > On 29/05/2013 18:07, Xueming Shen wrote: >> Hi, >> >> Here is proposal to add one mapping entry into the mapping table for EUC-KR >> to add the "newly" added KS X 1001:2002 code point >> >> 2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E) >> >> Info regarding this code point >> http://www.unicode.org/L2/L2004/04267-n2815.pdf >> >> Here is the mapping change webrev >> >> http://cr.openjdk.java.net/~sherman/8015271/webrev > This looks okay to me. Do you know if we are missing any other mappings? I see a few other "CIRCLED KOREAN CHARACTER", U+327C for example, but I don't know what their status is. I don't know if there is any missing, don't have a kS X 1001:2002 standard around. But If these characters are not listed in standard, they should not be in mapping. At least I see all four newly added as listed in the "new" KS X 1001:2002 page 10 (as in that attached N2815) are in the mapping now. 0xA2E7 0x00AE # Registered Sign 0xA2E8 0x327E # CIRCLED KOREAN CHARACTER JUEUI (Postal Code Mark) 0xA8A3 0x00AA # FEMININE ORDINAL INDICATOR 0xA8AC 0x00BA # MASCULINE ORDINAL INDICATOR -Sherman > > -Alan From eric.mccorkle at oracle.com Thu May 30 18:53:49 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 30 May 2013 14:53:49 -0400 Subject: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh Message-ID: <51A7A03D.2080103@oracle.com> Hello, Please review this simple patch which fixes an issue with several of the shell script tests, namely that they do not start with #!/bin/sh The webrev is here: http://cr.openjdk.java.net/~emc/8014834/ The bug is here: http://bugs.sun.com/view_bug.do?bug_id=8014834 Thanks, Eric From brian.burkhalter at oracle.com Thu May 30 19:19:43 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 May 2013 12:19:43 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <9b0c3525-5d3b-416d-835e-865d0fdd001c@default> References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> <9b0c3525-5d3b-416d-835e-865d0fdd001c@default> Message-ID: <8B3777DE-F33E-445A-9BC9-371E055234B1@oracle.com> Hi Iris, On May 30, 2013, at 11:15 AM, Iris Clark wrote: > This looks fantastic. Thanks for reviewing this. > The changes in Formatter look fine to me. > > I also took a quick look at FormattedFloatingDecimal and am thrilled. I think you changes have also addressed this bug: > > 5057835- FormattedFloatingDecimal: massive code duplication in J2SE > http://bugs.sun.com/view_bug.do?bug_id=5057835 Thanks for pointing this out. This one http://bugs.sun.com/view_bug.do?bug_id=8008333 actually looks to be a duplicate of that one. > I think you're good to go once you verify that you successfully ran the regression tests in test/java/util/Formatter. Some time back I already ran all the tests in sun/misc, java/lang, java/math, java/text, java/util/Formatter, java/util/Formattable but will do so once more after correcting the things pointed out by Martin. Thanks, Brian From brian.burkhalter at oracle.com Thu May 30 21:18:32 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 May 2013 14:18:32 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: Hi Martin, The changes you suggested below have been made and the webrev updated at http://cr.openjdk.java.net/~bpb/7032154/ All pertinent JTREG and JCK tests have been re-run successfully. Thanks! Brian On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: > The code is awesome. My thorough review found only these defects: > > Use third person in the first sentence of a javadoc - e.g. s/Retrieve/Retrieves/. > > --- > > Don't use the denigrated C style > char zero[] = > Instead use > char[] zero = > > --- > This looks odd: > normalized as a//binary* > > The original comment looked more normal: > > normalized as a *binary* > --- > > Otherwise, approved! From kumar.x.srinivasan at oracle.com Thu May 30 21:45:36 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 30 May 2013 14:45:36 -0700 Subject: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh In-Reply-To: <51A7A03D.2080103@oracle.com> References: <51A7A03D.2080103@oracle.com> Message-ID: <51A7C880.50700@oracle.com> Hi Erik, This looks good, historically the #!shell was inserted after the CopyRight, because it was thought that the automated CR updaters might get confused. I am cc'ing Dave K, just so that he is aware of this. Thanks Kumar > Hello, > > Please review this simple patch which fixes an issue with several of the > shell script tests, namely that they do not start with #!/bin/sh > > The webrev is here: > http://cr.openjdk.java.net/~emc/8014834/ > > The bug is here: > http://bugs.sun.com/view_bug.do?bug_id=8014834 > > Thanks, > Eric From xueming.shen at oracle.com Thu May 30 21:50:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 30 May 2013 21:50:30 +0000 Subject: hg: jdk8/tl/jdk: 8015271: Conversion table for EUC-KR is incorrect Message-ID: <20130530215045.E507448E36@hg.openjdk.java.net> Changeset: b588955b7e5b Author: sherman Date: 2013-05-30 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b588955b7e5b 8015271: Conversion table for EUC-KR is incorrect Summary: to add the requested postal code mark character u+327e Reviewed-by: alanb ! make/tools/CharsetMapping/EUC_KR.map From mike.duigou at oracle.com Thu May 30 23:04:39 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 30 May 2013 16:04:39 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A5E46C.5030908@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> Message-ID: <3117B4B0-2234-49C6-B049-CE70E37B2E49@oracle.com> Hi Aleksey; ????????! (One of the few Russian words I know thanks to the ISS) Since the statements are grouped by fields and classes, move this to the classes paragraph: "A contention + * group tag has no meaning in a class level {@code @Contended} annotation, + * and is ignored." Describing the behaviour of the class annotation by referencing unavailable functionality seems strange: "the effect is + * roughly equivalent to placing the {@code @Contended} annotation + * with the same anonymous tag over all the unannotated fields of + * the object." The reader is left wondering "how would I annotate multiple fields with the same anonymous tag?" Perhaps a statement in the fields paragraph that "To put multiple fields into the same anonymous group use the class level @C annotation". "over all the unannotated fields of + * the object." This refers, of course, to fields without their own @C annotation not fields without annotations. Addition:

                  The class level {@code @Contended} annotation is not inherited and has + * no effect on the fields [defined] in any sub-classes. Addition: "The effects of all + * {@code @Contended} annotations [upon layout of object fields] remain in force for all" As I told Brian during the lambda javadoc efforts, writing specification is the best kind of task--demanding, exacting and tedious! :-) Mike On May 29 2013, at 04:20 , Aleksey Shipilev wrote: > Thanks for the review! > > On 05/29/2013 04:28 AM, Martin Buchholz wrote: >> Yeah, we have the same problem with javadoc issuing very verbose >> warnings. I've been ignoring/filtering them and hoping they get fixed >> before jdk8 ships. > > Ok, reverted back to

                  . > >>> + * in concurrent contexts in which each instance of the annotated >>> + * object is often accessed by a different thread.

                  >>> >>> Hmmm... makes it sound like it applies even if each instance is >>> thread-confined (in a different thread) or is immutable. >> >> I think all the magic of ignoring @C when VM can prove the >> instance/fields would not experience contention, should be omitted from >> the documentation. The practical considerations also apply: since we can >> not at the moment retransform the class after the publication, it seems >> a good idea to treat all instances as potentially shared. This eases the >> reasoning (and documentation) significantly. >> >>> "objects" are not annotated. >> >> Yes, should be "instances". >> >> I was thinking "classes, not objects, are annotated". > > Fixed. > >>> however, remain in force for all >>> + * superclass and subclass instances >>> >>> >>> "remain in force for superclass instances" doesn't make sense to me. Do >>> you mean "remain in force when fields are inherited in subclasses" >> >> Yes, that sounds better! > > Reverted back to David's version. It does sound even cleaner in that > version. > > >>> Maybe "instances of the annotated class are frequently accessed by >>> multiple threads and have fields that are frequently written". >> >> "Accessed" matters there. False sharing also happens on reads. Also, the >> innocent read-only classes sometimes also need the protection from the >> adjacent writers' racket :) >> >> >> Hmmm... tricky ... This also then applies to pure immutable popular >> objects like Boolean.TRUE. But you want those kinds of objects to all be >> colocated and tightly packed with other such objects, not give each of >> them their own cache line. > > Yes, that's true. I do, however, think we have to have the provisioning > for the read-only protected fields/instances. > >> Sounds like a Quality of Implementation issue. In general, I think you >> *DO* want the subclass fields to be potentially in the same location as >> the superclass padding fields. >> A >: B >> A layout: ppppaaaapppp >> B layout: ppppaaaabbbbpppp >> >> which is not asking too much of a jit. >> I believe it is already common for VMs to allocate subclass fields in >> natural padding space of superclasses. >> > > This gets very tricky even in a slightly complicated case: > A >: B > A layout: ppppAAppppCCpppp > B layout: ppppAABBppCCpppp > > Note that we can't move CC in B because the fields are bound statically; > so we end up ruining the padding for both BB and CC. We can, of course, > have the gap in the padding to tolerate this, but before knowing in > advance what subclasses will be loaded next, we can not prepare enough; > or, we can redefine all the classes up the hierarchy... (Current HotSpot > classloader code is completely not ready for things like these). > > However, implementation issues aside: > > Allowing contended tags to be inherited will force users to look at the > entire hierarchy to search for the colliding tags; or (what's worse) > push the superclass maintainers to use cryptic tags so no possible > subclasses can collide with the protected fields. IMO, that is way > messier than pushing users to aggregate the semantically-close fields in > the same class. Hence, I left the inheritance clause as is. > > The new webrev is here: > http://cr.openjdk.java.net/~shade/8014966/webrev.03/ > > Thanks everyone, writing specs is fun! > > -Aleksey. From mike.duigou at oracle.com Thu May 30 23:56:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 30 May 2013 16:56:21 -0700 Subject: RFR: 8015686 : (XS) {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException Message-ID: Hello all; A very small review for a change which was fixed in the lambda repo (JDK-8012691) but escaped into TL: http://cr.openjdk.java.net/~mduigou/JDK-8015686/0/webrev/ Mike From mike.duigou at oracle.com Fri May 31 00:28:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 30 May 2013 17:28:25 -0700 Subject: RFR: 8014854 (was Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints) In-Reply-To: <519F6D77.90603@oracle.com> References: <51799135.5020801@oracle.com> <517A7F5D.8050206@oracle.com> <517EA523.1020509@oracle.com> <519F6D77.90603@oracle.com> Message-ID: The 8014854 changes look good to me after Paul and Henry's suggested improvements. Mike On May 24 2013, at 06:39 , Alan Bateman wrote: > On 29/04/2013 17:51, Henry Jen wrote: >> On 04/26/2013 06:21 AM, Alan Bateman wrote: >>> : >>> 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. >> > Just to follow-up on this thread from a few weeks ago. > > I did a few tests with CharBuffer.chars() and the default implementation performs very poorly as expected. This is easily fixed by adding a spliterator with direct access to the buffer contents and that is straight-forward to do: > > http://cr.openjdk.java.net/~alanb/8014854/webrev/ > > I've changed the templates used to generated the buffer classes so that ints/longs/doubles() could be added to Int/Long/DoubleBuffer if needed (which might be interesting when the buffers are backed by memory outside of the heap). > > The yak shaving in CompileJavaClasses.gmk is because the changes to the generated CharBuffer exposes a bug in the build of JObjC.jar on Mac. > > -Alan. From martinrb at google.com Fri May 31 01:12:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 30 May 2013 18:12:03 -0700 Subject: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <12BD5F43-1F9A-4D8C-A255-CDA3037C3E07@oracle.com> Message-ID: Looks good to me. On Thu, May 30, 2013 at 2:18 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Hi Martin, > > The changes you suggested below have been made and the webrev updated at > > http://cr.openjdk.java.net/~bpb/7032154/ > > All pertinent JTREG and JCK tests have been re-run successfully. > > Thanks! > > Brian > > On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: > > The code is awesome. My thorough review found only these defects: > > Use third person in the first sentence of a javadoc - e.g. > s/Retrieve/Retrieves/. > > --- > > Don't use the denigrated C style > char zero[] = > Instead use > char[] zero = > > --- > This looks odd: > > normalized as a//binary* > > > The original comment looked more normal: > > normalized as a *binary* > > --- > > Otherwise, approved! > > > From david.r.chase at oracle.com Fri May 31 02:17:47 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 30 May 2013 22:17:47 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> Message-ID: <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> Not sure where this stands, given that Vladimir K has a grand plan to turn the assembly language into an intrinsic (this is not how I would normally approach it) but there is another webrev with the unnecessary import removed: http://cr.openjdk.java.net/~drchase/7088419/webrev.04/ On 2013-05-27, at 11:29 AM, David Chase wrote: > > On 2013-05-27, at 9:27 AM, David Chase wrote: >> Here, seeing is believing (oh, but look, I trashed the output format on the warmup, I should fix that): >> >> FIRST, WITH SHORT WARMUP: >> dr2chase:zip $ $BB/java TimeChecksum >> ---------- Adler32 ---------- >> Warmup... 8 1,312 3 4 > > No, I didn't trash the output format. That is 8, 1312, 3, 4. > The small-stuff warmup took that long. > > David > From xuelei.fan at oracle.com Fri May 31 05:03:51 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:03:51 +0000 Subject: hg: jdk8/tl/jdk: 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Message-ID: <20130531050404.EA02048E4B@hg.openjdk.java.net> Changeset: 6407106f1b1c Author: xuelei Date: 2013-05-30 22:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6407106f1b1c 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java From xuelei.fan at oracle.com Fri May 31 05:21:24 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:21:24 +0000 Subject: hg: jdk8/tl/jdk: 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Message-ID: <20130531052135.DD0F348E4D@hg.openjdk.java.net> Changeset: 8402ef8fabde Author: ascarpino Date: 2013-05-30 22:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8402ef8fabde 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Reviewed-by: mullan, xuelei ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/CipherOutputStream.java + test/javax/crypto/Cipher/CipherStreamClose.java From xuelei.fan at oracle.com Fri May 31 05:26:24 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:26:24 +0000 Subject: hg: jdk8/tl/jdk: 8013069: javax.crypto tests fail with new PBE algorithm names Message-ID: <20130531052636.127B448E4E@hg.openjdk.java.net> Changeset: 6cb09d3cd309 Author: valeriep Date: 2013-05-29 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb09d3cd309 8013069: javax.crypto tests fail with new PBE algorithm names Summary: Shouldn't auto-generate default parameters for MAC objects. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/MacClone.java From xuelei.fan at oracle.com Fri May 31 05:36:11 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 31 May 2013 05:36:11 +0000 Subject: hg: jdk8/tl/jdk: 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Message-ID: <20130531053622.DB15D48E4F@hg.openjdk.java.net> Changeset: 918d9ac17740 Author: ascarpino Date: 2013-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/918d9ac17740 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java From peter.levart at gmail.com Fri May 31 07:33:14 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 31 May 2013 09:33:14 +0200 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A5E46C.5030908@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> Message-ID: <51A8523A.2040304@gmail.com> On 05/29/2013 01:20 PM, Aleksey Shipilev wrote: >> In general, I think you >> >*DO* want the subclass fields to be potentially in the same location as >> >the superclass padding fields. >> >A >: B >> >A layout: ppppaaaapppp >> >B layout: ppppaaaabbbbpppp >> > >> >which is not asking too much of a jit. >> >I believe it is already common for VMs to allocate subclass fields in >> >natural padding space of superclasses. >> > > This gets very tricky even in a slightly complicated case: > A >: B > A layout: ppppAAppppCCpppp > B layout: ppppAABBppCCpppp > > Note that we can't move CC in B because the fields are bound statically; > so we end up ruining the padding for both BB and CC. We can, of course, > have the gap in the padding to tolerate this, but before knowing in > advance what subclasses will be loaded next, we can not prepare enough; > or, we can redefine all the classes up the hierarchy... (Current HotSpot > classloader code is completely not ready for things like these). > > However, implementation issues aside: > > Allowing contended tags to be inherited will force users to look at the > entire hierarchy to search for the colliding tags; or (what's worse) > push the superclass maintainers to use cryptic tags so no possible > subclasses can collide with the protected fields. IMO, that is way > messier than pushing users to aggregate the semantically-close fields in > the same class. Hence, I left the inheritance clause as is. Hi Aleksey, Just some ideas for future... Implementation issues aside, the name of the tag specified in the @Contended annotation could be evaluated in the context of the fully qualified class name in which the annotation is used. For example: package pkg; class C { @Contended("g") int x; } ...here the fully qualified name of contention group for field 'x' could be interpreted as "pkg.C.g". When the tag contained at least one dot, it would be interpreted as fully qualified, oterwise as a simple name. Implementation could allow one of the contention groups to be used in a "global" context on the boundary of superclass/subclass, but which one is the one, would have to be anticipated and explicitly or implicitly noted on the superclass, so that the layout logic could group those fields at the end of object as soon as the superclass is loaded. One way to implicitly note the "global" contention group could be: "the global group is the group specified on the last @Contended field in the class as ordered in the source/class file". I don't know if this is useful anyway. Could a superclass correctly anticipate the "global" group in some situations? Regards, Peter From paul.sandoz at oracle.com Fri May 31 07:50:08 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 May 2013 09:50:08 +0200 Subject: RFR: 8015686 : (XS) {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException In-Reply-To: References: Message-ID: <4C46A491-BF46-4AB1-97D0-F8F52906E8EF@oracle.com> On May 31, 2013, at 1:56 AM, Mike Duigou wrote: > Hello all; > > A very small review for a change which was fixed in the lambda repo (JDK-8012691) but escaped into TL: > > http://cr.openjdk.java.net/~mduigou/JDK-8015686/0/webrev/ > +1 (while lacking reviewer mojo) Paul. From paul.sandoz at oracle.com Fri May 31 08:03:03 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 31 May 2013 08:03:03 +0000 Subject: hg: jdk8/tl/jdk: 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Message-ID: <20130531080318.5C1D448E53@hg.openjdk.java.net> Changeset: b47044426bcd Author: psandoz Date: 2013-05-31 09:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b47044426bcd 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown Summary: A minor documentation issue (not a spec issue). Reviewed-by: chegar, dl ! src/share/classes/java/util/Spliterator.java From david.holmes at oracle.com Fri May 31 08:15:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 May 2013 18:15:21 +1000 Subject: RFR: 8015686 : (XS) {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException In-Reply-To: <4C46A491-BF46-4AB1-97D0-F8F52906E8EF@oracle.com> References: <4C46A491-BF46-4AB1-97D0-F8F52906E8EF@oracle.com> Message-ID: <51A85C19.1090008@oracle.com> On 31/05/2013 5:50 PM, Paul Sandoz wrote: > > On May 31, 2013, at 1:56 AM, Mike Duigou wrote: > >> Hello all; >> >> A very small review for a change which was fixed in the lambda repo (JDK-8012691) but escaped into TL: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015686/0/webrev/ >> > > +1 (while lacking reviewer mojo) +mojo ;-) David > Paul. > From chris.hegarty at oracle.com Fri May 31 08:20:55 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 09:20:55 +0100 Subject: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp. In-Reply-To: <51A78CA1.2020700@oracle.com> References: <51A72BDC.6010900@oracle.com> <51A77CA8.9010905@oracle.com> <51A78CA1.2020700@oracle.com> Message-ID: <51A85D67.7090203@oracle.com> On 05/30/2013 06:30 PM, huizhe wang wrote: > > On 5/30/2013 9:22 AM, Chris Hegarty wrote: >> Looks fine to me Daniel, >> >> I see you have three copies of Objects.java, is it possible to put it >> in a common place accessible to all? Or maybe this causes other issues. > > JAXP consists of multiple components. The Xerces and Xalan components > specifically are by their own and do not have references across the > boundaries. Our next project is modularization in which Xerces and Xalan > will definitely be split into difference modules. As for BCEL, since > it's always by itself, it's preferable to let it that way, unless it > really affects footprint. No problem Joe, this addresses my concerns. -Chris. > > -Joe > >> >> -Chris. >> >> On 05/30/2013 11:37 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> This is a request for review of the backport of >>> >>> to jdk7u-dev. >>> >>> The changeset for jdk7u-dev [1] had to be altered on one count >>> compared to the changes pushed in jdk8 [2]: >>> >>> Since jaxp needs to be compiled using the bootstrap >>> compiler, it was not possible to use the new >>> JDK 7 java.util.Objects API. >>> >>> In order to minimize the changes between the two >>> changesets - I added an Objects class emulating >>> the two 'hashCode' and 'equals' methods of java.util.Objects >>> in the util packages of Xerces, Xalan, and Bcel. >>> >>> This way - the only thing that needed to change in the rest of >>> the files was the import clause of the Objects class. >>> >>> Here is the altered changeset for jdk7u-dev: >>> [1] >>> >>> >>> Here is the changeset that was pushed in jdk8: >>> [2] >>> >>> -- daniel >>> >>> Review for the original jdk8 changeset [2] happened on core-libs-dev: >>> >>> > From chris.hegarty at oracle.com Fri May 31 08:32:00 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 31 May 2013 08:32:00 +0000 Subject: hg: jdk8/tl/jdk: 7107883: getNetworkPrefixLength() does not return correct prefix length Message-ID: <20130531083225.EF21548E58@hg.openjdk.java.net> Changeset: dcf42861b5b1 Author: chegar Date: 2013-05-31 09:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcf42861b5b1 7107883: getNetworkPrefixLength() does not return correct prefix length Reviewed-by: alanb, michaelm ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/InterfaceAddress/NetworkPrefixLength.java From vicente.romero at oracle.com Fri May 31 09:05:52 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 31 May 2013 09:05:52 +0000 Subject: hg: jdk8/tl/langtools: 7179353: try-with-resources fails to compile with generic exception parameters Message-ID: <20130531090604.168F148E79@hg.openjdk.java.net> Changeset: 9f11c7676cd5 Author: vromero Date: 2013-05-31 10:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f11c7676cd5 7179353: try-with-resources fails to compile with generic exception parameters Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T7179353/GenericsAndTWRCompileErrorTest.java From paul.sandoz at oracle.com Fri May 31 10:29:02 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 May 2013 12:29:02 +0200 Subject: RFR 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining() Message-ID: <93672AC8-C38B-4596-91F6-E84F6C98500D@oracle.com> Hi, Please review a fix to the key/value/entry spliterators of HashMap/WeakHashMap when mixed traversal is performed: http://cr.openjdk.java.net/~psandoz/tl/JDK-8013649/webrev/ A call to forEachRemaning does not correctly check and set the state to detect/signal all elements have been traversed. There are two conditions for traversal: 1) if the index into the entry table is less than the fence; or 2) if the current entry is not null. forEachRemaining was only checking the first condition before traversing and only setting the state associated with the first condition rendering it false on subsequent calls. If mixed traversal (a combination of tryAdvance and forEachRemaining) is performed this can result in forEachRemaining not traversing elements or tryAdvance traversing previously traversed elements. Note that failure only occurs for certain distributions of elements which is why the current tests did not detect this case. Additional tests have been added that induce the conditions whereby table entries contain 2 or more elements thus enabling tryAdvance to set up condition 2). -- This has already been fixed in the lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d3baf2241054 Paul. From dl at cs.oswego.edu Fri May 31 10:31:51 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 31 May 2013 06:31:51 -0400 Subject: RFR 8005704: Update ConcurrentHashMap to v8 In-Reply-To: References: <51A36DF9.5080207@oracle.com> <7978F270-3489-455F-956E-3BB66947F381@oracle.com> <51A5FE82.20903@cs.oswego.edu> Message-ID: <51A87C17.605@cs.oswego.edu> On 05/30/13 14:18, Mike Duigou wrote: >>> - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type >>> particularly for newKeySet(). Why not return Set? The additional methods >>> don't seem to offer much that's desirable for the newKeySet() case. >> >> Since we don't have a ConcurrentSet interface, people are reduced to >> instanceof checks to see if they have a concurrent one. But without >> exposing the class, they couldn't even do this, so complained. This >> will arise more frequently with j.u.streams.Collectors. > > I'd rather introduce a vacuous ConcurrentSet than expose ConcurrentHashMap.KeySetView. Any reason not to add it? > Thinking this over a bit and asking a few others, it seems that adding ConcurrentSet at this point would cause more problems than it solves. As one example, you'd want all ConcurrentMap.keySet() methods to return one, but we can't retrospectively spec this. Note that CHM.newKeySet gives exactly the same view class for CHM that j.u.HashSet does for j.u.HashMap, but also allows transient projection (method CHM.keySet(value)) that you cannot do with Hash{Map,Set}. We also don't want to waste the name ConcurrentHashSet for this, to leave open the possibility of someday creating a custom unattached class optimized solely for use as Set. >>> - I think there could be more complete description of the >>> parallelismThreshold and interaction with common pool. > only one change > > Using a value of {@code 1} results in maximal parallelism by partitioning into > enough subtasks to fully utilize the {@link ForkJoinPool#commonPool()}. > Sure; thanks. I reworked a little to avoid redundant need for last sentence: *

                  These bulk operations accept a {@code parallelismThreshold} * argument. Methods proceed sequentially if the current map size is * estimated to be less than the given threshold. Using a value of * {@code Long.MAX_VALUE} suppresses all parallelism. Using a value * of {@code 1} results in maximal parallelism by partitioning into * enough subtasks to fully utilize the {@link * ForkJoinPool#commonPool()} that is used for all parallel * computations. Normally, you would initially choose one of these * extreme values, and then measure performance of using in-between * values that trade off overhead versus throughput. From paul.sandoz at oracle.com Fri May 31 10:49:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 May 2013 12:49:14 +0200 Subject: RFR 8014383: StringJoiner example in class description not in sync with streams API Message-ID: Hi, Please review this JavaDoc fix to j.u.StringJoiner to update and move the examples to an api note. -- This has already been fixed in the lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3a44a6038054 Paul. # HG changeset patch # User psandoz # Date 1369996938 -7200 # Node ID 2154bb2da653d83abddc23960a45e29980248ada # Parent 486e5091ed999ebf65a92a6d862bbcf47bf9bc78 8014383: StringJoiner example in class description not in sync with streams API Reviewed-by: diff -r 486e5091ed99 -r 2154bb2da653 src/share/classes/java/util/StringJoiner.java --- a/src/share/classes/java/util/StringJoiner.java Fri May 31 10:53:19 2013 +0200 +++ b/src/share/classes/java/util/StringJoiner.java Fri May 31 12:42:18 2013 +0200 @@ -29,14 +29,6 @@ * by a delimiter and optionally starting with a supplied prefix * and ending with a supplied suffix. *

                  - * For example, the String {@code "[George:Sally:Fred]"} may - * be constructed as follows: - *

                   {@code
                  - *     StringJoiner sj = new StringJoiner(":", "[", "]");
                  - *     sj.add("George").add("Sally").add("Fred");
                  - *     String desiredString = sj.toString();
                  - * }
                  - *

                  * Prior to adding something to the {@code StringJoiner}, its * {@code sj.toString()} method will, by default, return {@code prefix + suffix}. * However, if the {@code setEmptyValue} method is called, the {@code emptyValue} @@ -45,17 +37,28 @@ * "{}", where the {@code prefix} is "{", the * {@code suffix} is "}" and nothing has been added to the * {@code StringJoiner}. + * + * @apiNote + *

                  The String {@code "[George:Sally:Fred]"} may be constructed as follows: + * + *

                   {@code
                  + * StringJoiner sj = new StringJoiner(":", "[", "]");
                  + * sj.add("George").add("Sally").add("Fred");
                  + * String desiredString = sj.toString();
                  + * }
                  *

                  * A {@code StringJoiner} may be employed to create formatted output from a - * collection using lambda expressions as shown in the following example. + * {@link java.util.stream.Stream} using + * {@link java.util.stream.Collectors#toStringJoiner}. For example: * *

                   {@code
                  - *     List people = ...
                  - *     String commaSeparatedNames =
                  - *         people.map(p -> p.getName()).into(new StringJoiner(", ")).toString();
                  + * List numbers = Arrays.asList(1, 2, 3, 4);
                  + * String commaSeparatedNumbers = numbers.stream()
                  + *     .map(i -> i.toString())
                  + *     .collect(Collectors.toStringJoiner(", ")).toString();
                    * }
                  * - * @author Jim Gish + * @see java.util.stream.Collectors#toStringJoiner * @since 1.8 */ public final class StringJoiner { From Alan.Bateman at oracle.com Fri May 31 11:14:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 12:14:10 +0100 Subject: RFR 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: References: Message-ID: <51A88602.1080001@oracle.com> On 31/05/2013 11:49, Paul Sandoz wrote: > Hi, > > Please review this JavaDoc fix to j.u.StringJoiner to update and move the examples to an api note. > > -- This looks okay to me. The only thing is that removing @author can sometimes to a contentious topic. Given that StringJoiner has been significantly simplified and re-worked since its initial version then it might not matter here (but mentioning it anyway). -Alan. From alan.bateman at oracle.com Fri May 31 11:22:33 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 31 May 2013 11:22:33 +0000 Subject: hg: jdk8/tl/jdk: 8014854: (bf) CharBuffer.chars too slow with default implementation Message-ID: <20130531112303.ED0E148E83@hg.openjdk.java.net> Changeset: 243cd682c47b Author: alanb Date: 2013-05-31 12:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/243cd682c47b 8014854: (bf) CharBuffer.chars too slow with default implementation Reviewed-by: erikj, briangoetz, henryjen, psandoz, mduigou ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcBuffer.gmk ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template + src/share/classes/java/nio/CharBufferSpliterator.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/Heap-X-Buffer.java.template ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template + test/java/nio/Buffer/Chars.java From paul.sandoz at oracle.com Fri May 31 11:26:00 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 May 2013 13:26:00 +0200 Subject: RFR 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: <51A88602.1080001@oracle.com> References: <51A88602.1080001@oracle.com> Message-ID: On May 31, 2013, at 1:14 PM, Alan Bateman wrote: > On 31/05/2013 11:49, Paul Sandoz wrote: >> Hi, >> >> Please review this JavaDoc fix to j.u.StringJoiner to update and move the examples to an api note. >> >> -- > This looks okay to me. > Thanks. > The only thing is that removing @author can sometimes to a contentious topic. Given that StringJoiner has been significantly simplified and re-worked since its initial version then it might not matter here (but mentioning it anyway). > I hope no offence is taken, it's not personal. My understanding is the @author tag is no longer something we should be using for new JDK code (and to be egalitarian about it perhaps we should strip out @author tags from all the code!) Paul. From Alan.Bateman at oracle.com Fri May 31 11:29:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 12:29:00 +0100 Subject: RFR: 8015686 : (XS) {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException In-Reply-To: <51A85C19.1090008@oracle.com> References: <4C46A491-BF46-4AB1-97D0-F8F52906E8EF@oracle.com> <51A85C19.1090008@oracle.com> Message-ID: <51A8897C.3010302@oracle.com> On 31/05/2013 09:15, David Holmes wrote: > On 31/05/2013 5:50 PM, Paul Sandoz wrote: >> >> On May 31, 2013, at 1:56 AM, Mike Duigou wrote: >> >>> Hello all; >>> >>> A very small review for a change which was fixed in the lambda repo >>> (JDK-8012691) but escaped into TL: >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8015686/0/webrev/ >>> >> >> +1 (while lacking reviewer mojo) > > +mojo ;-) Looks good to me too so I guess that means your IntSummaryStatistics review stats has had its accept(1) called again. -Alan. From Alan.Bateman at oracle.com Fri May 31 12:19:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 13:19:16 +0100 Subject: RFR (jaxp): review backport to jdk7u-dev of 8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently In-Reply-To: <51A783B7.10104@oracle.com> References: <51A714F1.2070603@oracle.com> <51A783B7.10104@oracle.com> Message-ID: <51A89544.2030101@oracle.com> On 30/05/2013 17:52, huizhe wang wrote: > Hi Daniel, > > This looks good. Thanks again for the extra effort to keep JDK7 updated. > > -Joe This looks okay to me too. BTW: One suggestios for these backports that require small adjustments to what is in jdk8, is to include jdk7u-dev on the review request. That way you can get the approvals in parallel (I think the jdk7u-dev maintainers will regularly "okay" a change pending conclusion of the code review. Also they will regularly approve changes when the small difference to the jdk8 patch is pointed out). -Alan From Alan.Bateman at oracle.com Fri May 31 12:56:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 13:56:55 +0100 Subject: RFR 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: References: <51A88602.1080001@oracle.com> Message-ID: <51A89E17.3060008@oracle.com> On 31/05/2013 12:26, Paul Sandoz wrote: > : > > My understanding is the @author tag is no longer something we should be using for new JDK code (and to be egalitarian about it perhaps we should strip out @author tags from all the code!) I vaguely remember there was discussion on this topic a few years ago. I think (but might be wrong) that the guideline at the time was not to remove @author from existing code. In this case it is new code and if Jim is okay with it then I don't see any issue removing it. -Alan. From aleksej.efimov at oracle.com Fri May 31 13:39:31 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 31 May 2013 17:39:31 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> , <51A55C70.4070403@oracle.com> Message-ID: <51A8A813.9070903@oracle.com> Obviously, we can't throw the ISE - it's not described in docs for readObject() method. Exceptions suggested by Jason have the following descriptions: InvalidClassException: Something is wrong with a class used by serialization. StreamCorruptedException: Control information in the stream is inconsistent. I think InvalidClassException more suitable for our case, because we have here the problem with inconsistent state of serialized class, but not the control information in the stream (invalid stream header, invalid type code and etc). Aleksej On 29.05.2013 6:54, Jason Mehrens wrote: >>> You can still generate a ISE inside readObject by performing "new XPathException(new Exception()).initCause(null)" in the old code and then reading that in the new patch. In the new code that line would fail fast. >> So what should the result of this be given that the original exception >> has an inconsistent state (two 'causes')? >> > Maybe catch ISE and throw InvalidObjectException or StreamCorruptedException? > > Jason From aleksej.efimov at oracle.com Fri May 31 13:43:42 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 31 May 2013 17:43:42 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A53CFA.4000008@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> <51A4BF7B.8040206@oracle.com> <51A53CFA.4000008@oracle.com> Message-ID: <51A8A90E.9070609@oracle.com> Joe, I'll move the tests to jdk/test/javax/xml/jaxp/XPath/ 8009579 in next version of webrev for JDK8. For JDK7 the tests will be in the same folder after Daniel's change. Correct, I'm using the backport ID only for review in this alias, for commits and test header will use the main bug ID. Thanks for bringing this to my attention. -Aleksej On 05/29/2013 03:25 AM, huizhe wang wrote: > Hi Aleksej, > > Please note that in jdk8 repo, we've added jdk/test/javax/xml/jaxp to > hold all new tests for jaxp. All of the existing tests will be > migrated to this place in the future. In your case, the new test can > be created under a new folder jdk/test/javax/xml/jaxp/XPath/8009579. > Daniel's change request 8008738 will also add that in JDK7 repo., so > please coordinate with Daniel when your patch is ready for JDK7. > > I noticed that you're using the 'backport' bug id for this review. > According to the process, all commits shall use the main ID. > > Thanks, > Joe > > On 5/28/2013 7:30 AM, Aleksej Efimov wrote: >> Jason, >> You are absolutely right and my fault that I didn't tested the >> compatibility of new/old versions. >> I have tested it with JDK 8(without fix) as a serializer and JDK 8 >> (with fix) as deserializer. The behavior was as you expected. Thanks >> for catching it. >> I'll wait for other comments before generating another webrev. >> >> Aleksej >> >> On 05/28/2013 05:41 PM, Jason Mehrens wrote: >>> > Alan, David, >>> > thank you for comments - I also agree with all of them. And as a >>> result v3: >>> > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/ >>> > >> I think this looks better. I assume that since the >>> super.getCause() is >>> > >> null that there is no need to handle IllegalStateException now. >>> >>> You can still generate a ISE inside readObject by performing "new >>> XPathException(new Exception()).initCause(null)" in the old code and >>> then reading that in the new patch. In the new code that line would >>> fail fast. >>> >>> Jason >> > From Alan.Bateman at oracle.com Fri May 31 13:52:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 14:52:17 +0100 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> Message-ID: <51A8AB11.7040005@oracle.com> On 31/05/2013 03:17, David Chase wrote: > Not sure where this stands, given that Vladimir K has a grand plan to turn the assembly language into an intrinsic (this is not how I would normally approach it) but there is another webrev with the unnecessary import removed: > > http://cr.openjdk.java.net/~drchase/7088419/webrev.04/ > I guess this comes down to timing and which releases the improvement is required in. If the intrinsic that Vladimir is proposing is more longer term, and you are looking to get this is so that it can also go into jdk7u, then it might be okay to just push your implementation now (as the speed-up is compelling). As I mentioned in one of the mails, then the passing through of the property to enable it is a bit awkward but you explained that detecting the processor feature is complicated and the duplication is best avoid. Also the XX option although if this were compiled C then the XX option wouldn't have any effect. Some minor nits on CRC32 in the latest webrev: - as "javaCRCIfSmallThan" is a constant then it can be final and probably renamed to uppercase to be consistent. Looks like timesXtoThe32 can be final too. - the static initializer is use 2-space indent whereas we usually use 4 Otherwise I don't have any other issues. Are you still planning to adding the parallel version? -Alan. From Alan.Bateman at oracle.com Fri May 31 14:10:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 15:10:15 +0100 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A66950.3020009@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> Message-ID: <51A8AF47.3000802@oracle.com> On 29/05/2013 21:47, Brent Christian wrote: > Updated webrev is here: > http://cr.openjdk.java.net/~bchristi/8005698/webrev.03/ > > It contains the following changes from Mike's review: > > * HashMap.comparableClassFor(): corrected reference to TreeBin docs > > * fixed @run tag in InPlaceOpsCollisions.java > > * Hashtable & HashMap: hashSeed made final, initialized in > constructor, UNSAFE restored and used in readObject(). > > Thanks, > -Brent I've read through the latest webrev, overall very good work. I had to read splitTreeBin a few times to convince myself as to how the keys re-hash. I wonder if would be helpful to beef up the comment on this method. It's good to see a test that specifically targets this. Otherwise I didn't see anything obviously wrong. Minor alignment issue with the comments on Holder. Assuming Doug and Mike are okay with this then I suggest we try to get it into jdk8/tl soon so that it has a few days bake time before Lana grabs the changes from jdk8/tl for b94. I think Mike is going to sponsor this. -Alan. From Alan.Bateman at oracle.com Fri May 31 14:20:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 May 2013 15:20:33 +0100 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A8A813.9070903@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> , <51A55C70.4070403@oracle.com> <51A8A813.9070903@oracle.com> Message-ID: <51A8B1B1.60108@oracle.com> On 31/05/2013 14:39, Aleksej Efimov wrote: > Obviously, we can't throw the ISE - it's not described in docs for > readObject() method. > Exceptions suggested by Jason have the following descriptions: > InvalidClassException: Something is wrong with a class used by > serialization. > StreamCorruptedException: Control information in the stream is > inconsistent. > I think InvalidClassException more suitable for our case, because we > have here the problem with inconsistent state of serialized class, but > not the control information in the stream (invalid stream header, > invalid type code and etc). > > Aleksej Yes, InvalidClassException would be best. I see you've added a serialization/deserialization test (thanks) but it wouldn't have caught this. What would you think about serializing a few XPathException instances with a jdk7 build and use the byte stream in the test to check that they are handled correctly. That would give more confident that there aren't any other holes. -Alan From david.r.chase at oracle.com Fri May 31 14:42:43 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 31 May 2013 10:42:43 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51A8AB11.7040005@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> <51A8AB11.7040005@oracle.com> Message-ID: <7DBFA90C-646C-49AA-A964-D18BE8D2374E@oracle.com> On 2013-05-31, at 9:52 AM, Alan Bateman wrote: > On 31/05/2013 03:17, David Chase wrote: >> Not sure where this stands, given that Vladimir K has a grand plan to turn the assembly language into an intrinsic (this is not how I would normally approach it) but there is another webrev with the unnecessary import removed: >> >> http://cr.openjdk.java.net/~drchase/7088419/webrev.04/ >> > I guess this comes down to timing and which releases the improvement is required in. If the intrinsic that Vladimir is proposing is more longer term, and you are looking to get this is so that it can also go into jdk7u, then it might be okay to just push your implementation now (as the speed-up is compelling). As I mentioned in one of the mails, then the passing through of the property to enable it is a bit awkward but you explained that detecting the processor feature is complicated and the duplication is best avoid. Also the XX option although if this were compiled C then the XX option wouldn't have any effect. The current plumbing for the XX option does affect code flow in the compiled C; that was pretty much the entire point of it. Vladimir has a plan, I think his attitude is that if convert this into an intrinsic then we won't care about compiler version or updating the code to get rid of the assembler, it will just be done, for good. My POV is that for now it's done, and we don't have to touch it for a good long while (except that I left Windows unoptimized). > Some minor nits on CRC32 in the latest webrev: > > - as "javaCRCIfSmallThan" is a constant then it can be final and probably renamed to uppercase to be consistent. Looks like timesXtoThe32 can be final too. > - the static initializer is use 2-space indent whereas we usually use 4 I will get those. I was unsure on whether these things would always be final; if we were willing to admit the existence of platform-dependent performance differences, then they would be different on different platforms (JNI seems to be somewhat more expensive on Sparc, if I recall correctly) and it also differs a little based on use of the "fast crc" path, but it is not a huge difference in either case. > Otherwise I don't have any other issues. > > Are you still planning to adding the parallel version? I would like to do a parallel version, but I would like to get this in to 8 and maybe 7, and it seems to me that leaving out the parallel improvements makes that more likely. I think it is wrong-headed to declare that use of parallelism behind the curtain constitutes an interface change (especially in cases like this where the input/output semantics are exactly specified and followed), but other people seem to think otherwise, and hashing that out will just take time. It would be nice to also deliver some performance boost to Sparc boxes, and the parallel version does this quite nicely. I suppose I should file a bug/RFE for this, thought it would also be interesting to go looking for other parts of the JDK that might be helped by parallelism (as was mentioned in another review, how about those Big Integers?) Another thing, that I think is more pie-in-the-sky, is that we need better interfaces for measurement. We *say* we are worried about power consumption, but do you see any probes for measuring it? When I see slow startup of fork-join, I can't even tell if what I am seeing is some sort of incredibly expensive initialization (consumes power) or a slumbering processor waking up to work (extra time needed does not reflect power consumption -- in fact it reflects a LACK of power consumption). David From aleksey.shipilev at oracle.com Fri May 31 15:06:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 May 2013 19:06:43 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <3117B4B0-2234-49C6-B049-CE70E37B2E49@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <3117B4B0-2234-49C6-B049-CE70E37B2E49@oracle.com> Message-ID: <51A8BC83.1000301@oracle.com> Thanks Mike! The updated webrev is here: http://cr.openjdk.java.net/~shade/8014966/webrev.04/ I think the changes we are doing now are converging. I would like to hear formal OKs from Martin B, Mike D, David H, so we can proceed with pushing this. Last-minute grammar corrections welcome! -Aleksey. Summary of changes below: On 05/31/2013 03:04 AM, Mike Duigou wrote: > Since the statements are grouped by fields and classes, move this to > the classes paragraph: > > "A contention + * group tag has no meaning in a class level {@code > @Contended} annotation, + * and is ignored." Moved. > Describing the behaviour of the class annotation by referencing > unavailable functionality seems strange: > > "the effect is + * roughly equivalent to placing the {@code > @Contended} annotation + * with the same anonymous tag over > all the unannotated fields of + * the object." > > The reader is left wondering "how would I annotate multiple fields > with the same anonymous tag?" Perhaps a statement in the fields > paragraph that "To put multiple fields into the same anonymous group > use the class level @C annotation". Good point, rephrased to: * When the annotation is used at the class level, the effect is * equivalent to grouping all the fields not already having the * {@code @Contended} annotation into the same anonymous group. > "over all the unannotated fields of + * the object." > > This refers, of course, to fields without their own @C annotation not > fields without annotations. Yes, that is fixed as the side-effect of the change above. > Addition: > >

                  The class level {@code @Contended} annotation is not inherited and > has + * no effect on the fields [defined] in any sub-classes. Done. I think "declared" is the more applicable in Java world. > Addition: > > "The effects of all + * {@code @Contended} annotations [upon layout > of object fields] remain in force for all" > I am reluctant to add this, because mentioning field layout seems to mean the particular implementation choice (which limits us from, say, aligning the objects for the cache line). > As I told Brian during the lambda javadoc efforts, writing > specification is the best kind of task--demanding, exacting and > tedious! :-) Yeah. There is still some time before release, and lots of space on cr.openjdk.java.net for the webrevs! From chris.hegarty at oracle.com Fri May 31 15:28:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 May 2013 16:28:15 +0100 Subject: RFR 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining() In-Reply-To: <93672AC8-C38B-4596-91F6-E84F6C98500D@oracle.com> References: <93672AC8-C38B-4596-91F6-E84F6C98500D@oracle.com> Message-ID: <51A8C18F.4000609@oracle.com> The source changes look fine to me Paul. -Chris. On 05/31/2013 11:29 AM, Paul Sandoz wrote: > Hi, > > Please review a fix to the key/value/entry spliterators of HashMap/WeakHashMap when mixed traversal is performed: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8013649/webrev/ > > A call to forEachRemaning does not correctly check and set the state to detect/signal all elements have been traversed. > > There are two conditions for traversal: > 1) if the index into the entry table is less than the fence; or > 2) if the current entry is not null. > > forEachRemaining was only checking the first condition before traversing and only setting the state associated with the first condition rendering it false on subsequent calls. > > If mixed traversal (a combination of tryAdvance and forEachRemaining) is performed this can result in forEachRemaining not traversing elements or tryAdvance traversing previously traversed elements. > > Note that failure only occurs for certain distributions of elements which is why the current tests did not detect this case. Additional tests have been added that induce the conditions whereby table entries contain 2 or more elements thus enabling tryAdvance to set up condition 2). > > -- > > This has already been fixed in the lambda repo: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d3baf2241054 > > Paul. > From aleksey.shipilev at oracle.com Fri May 31 15:44:10 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 May 2013 19:44:10 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A8523A.2040304@gmail.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> Message-ID: <51A8C54A.4020008@oracle.com> Hi Peter, On 05/31/2013 11:33 AM, Peter Levart wrote: > Implementation issues aside, the name of the tag specified in the > @Contended annotation could be evaluated in the context of the fully > qualified class name in which the annotation is used. For example: I thought about implying the fully-qualified names for the tags; but that only makes sense if we allow tag inheritance, and we don't. > When the tag contained at least one dot, it would be interpreted as > fully qualified, otherwise as a simple name. Ugh. Messy... :) > Implementation could allow one of the contention groups to be used > in a "global" context on the boundary of superclass/subclass, but > which one is the one, would have to be anticipated and explicitly or > implicitly noted on the superclass, so that the layout logic could > group those fields at the end of object as soon as the superclass is > loaded. We do something like that for normal oops layout, so that we have the contiguous oops region on the superclass/subclass boundary. This is the corner case though, which does not scale beyond just two classes. I think this case is superficial corner case, and does not deserve the treatment. Anyhow, the contended tags are just the hints within the hint: we communicate that particular fields *can* be grouped together if implementation thinks that is a good idea. The way @C is spec'ed now, we might even ignore the tags at all and pad the fields distinctively, i.e. we say those fields are not required to be isolated pair-wise with any field in the group, but only with all other contended groups and fields. Having said that, I should probably add the sentence in the docs, like this: "A contention group defines a set of one or more fields that collectively must be isolated from all other contention groups. [The fields in the same contention group may not be pair-wise isolated]". > I don't know if this is useful anyway. Could a superclass correctly > anticipate the "global" group in some situations? I think what is being proposed for @C to work across the hierarchy is the overkill, handles no useful cases, but bears the significant development cost to do. That's the recipe for saying "nope!" :) Don't try to turn @Contended into the swiss army knife field layout hint. It is not. -Aleksey. From iris.clark at oracle.com Fri May 31 16:52:43 2013 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 31 May 2013 09:52:43 -0700 (PDT) Subject: RFR 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: <51A89E17.3060008@oracle.com> References: <51A88602.1080001@oracle.com> <51A89E17.3060008@oracle.com> Message-ID: Hi, Alan. That's what I remember too. There were just too many objections to completely removing all @author tags. iris -----Original Message----- From: Alan Bateman Sent: Friday, May 31, 2013 5:57 AM To: Paul Sandoz Cc: core-libs-dev at openjdk.java.net Libs Subject: Re: RFR 8014383: StringJoiner example in class description not in sync with streams API On 31/05/2013 12:26, Paul Sandoz wrote: > : > > My understanding is the @author tag is no longer something we should > be using for new JDK code (and to be egalitarian about it perhaps we > should strip out @author tags from all the code!) I vaguely remember there was discussion on this topic a few years ago. I think (but might be wrong) that the guideline at the time was not to remove @author from existing code. In this case it is new code and if Jim is okay with it then I don't see any issue removing it. -Alan. From vladimir.kozlov at oracle.com Fri May 31 17:43:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 May 2013 10:43:28 -0700 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <7DBFA90C-646C-49AA-A964-D18BE8D2374E@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> <51A8AB11.7040005@oracle.com> <7DBFA90C-646C-49AA-A964-D18BE8D2374E@oracle.com> Message-ID: <51A8E140.5010206@oracle.com> On 5/31/13 7:42 AM, David Chase wrote: > > On 2013-05-31, at 9:52 AM, Alan Bateman wrote: > >> On 31/05/2013 03:17, David Chase wrote: >>> Not sure where this stands, given that Vladimir K has a grand plan to turn the assembly language into an intrinsic (this is not how I would normally approach it) but there is another webrev with the unnecessary import removed: >>> >>> http://cr.openjdk.java.net/~drchase/7088419/webrev.04/ >>> >> I guess this comes down to timing and which releases the improvement is required in. If the intrinsic that Vladimir is proposing is more longer term, and you are looking to get this is so that it can also go into jdk7u, then it might be okay to just push your implementation now (as the speed-up is compelling). As I mentioned in one of the mails, then the passing through of the property to enable it is a bit awkward but you explained that detecting the processor feature is complicated and the duplication is best avoid. Also the XX option although if this were compiled C then the XX option wouldn't have any effect. > > The current plumbing for the XX option does affect code flow in the compiled C; that was pretty much the entire point of it. Vladimir has a plan, I think his attitude is that if convert this into an intrinsic then we won't care about compiler version or updating the code to get rid of the assembler, it will just be done, for good. My POV is that for now it's done, and we don't have to touch it for a good long while (except that I left Windows unoptimized). My biggest concern about the assembler code in jdk is its support. Even if you document how you got ".byte 0xc4,0xe3", next person will have very hard time to fix/modify this code. From my point of view it is dead code. About intrinsic. It will work on all OSs (including Windows) and don't need special versions of gcc, c++. But, it looks like, I need an other week to finish it. And I am worried about startup performance of intrinsic vs asm in jdk. Thanks, Vladimir >> Some minor nits on CRC32 in the latest webrev: >> >> - as "javaCRCIfSmallThan" is a constant then it can be final and probably renamed to uppercase to be consistent. Looks like timesXtoThe32 can be final too. >> - the static initializer is use 2-space indent whereas we usually use 4 > > I will get those. I was unsure on whether these things would always be final; if we were willing to admit the existence of platform-dependent performance differences, then they would be different on different platforms (JNI seems to be somewhat more expensive on Sparc, if I recall correctly) and it also differs a little based on use of the "fast crc" path, but it is not a huge difference in either case. > >> Otherwise I don't have any other issues. >> >> Are you still planning to adding the parallel version? > > I would like to do a parallel version, but I would like to get this in to 8 and maybe 7, and it seems to me that leaving out the parallel improvements makes that more likely. I think it is wrong-headed to declare that use of parallelism behind the curtain constitutes an interface change (especially in cases like this where the input/output semantics are exactly specified and followed), but other people seem to think otherwise, and hashing that out will just take time. It would be nice to also deliver some performance boost to Sparc boxes, and the parallel version does this quite nicely. I suppose I should file a bug/RFE for this, thought it would also be interesting to go looking for other parts of the JDK that might be helped by parallelism (as was mentioned in another review, how about those Big Integers?) > > Another thing, that I think is more pie-in-the-sky, is that we need better interfaces for measurement. We *say* we are worried about power consumption, but do you see any probes for measuring it? When I see slow startup of fork-join, I can't even tell if what I am seeing is some sort of incredibly expensive initialization (consumes power) or a slumbering processor waking up to work (extra time needed does not reflect power consumption -- in fact it reflects a LACK of power consumption). > > David > From dan.xu at oracle.com Fri May 31 18:15:51 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 31 May 2013 11:15:51 -0700 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51A5EC5E.7030502@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> Message-ID: <51A8E8D7.9030208@oracle.com> On 05/29/2013 04:54 AM, Alan Bateman wrote: > On 28/05/2013 19:39, Dan Xu wrote: >> Hi All, >> >> When File.createTempFile() is called with some special parameters, it >> runs into infiniteloop and hangs. It is because it does not always >> mean a file exists when the method, createFileExclusively(), returns >> false. This fix is going to solve such issues reported in JDK-8013827 >> and JDK-8011950.And I also added some testcases to verify it. >> >> webrev: http://cr.openjdk.java.net/~dxu/8013827/webrev.00/ >> bug: http://bugs.sun.com/view_bug.do?bug_id=8011950 >> >> -Dan > Thanks for taking this one. > > The changes mean that IAE is now thrown for cases where it wasn't > thrown previously and I'm wondering if this is worth doing. It might > be simpler to just throw IOException on the grounds that creating the > file will fail. > > One other thing to consider is that "\" is a valid name of a file on > some platforms. I suspect you'll need to delegate to the FileSystem to > check the suffix/prefix. Alternatively in TempDirectory.generateFile > you could create a File from prefix/n/suffix and call getName to check > that its matches. If not then throw an exception. > > -Alan. Thanks for your good review. I have updated my changes. And it is uploaded at, http://cr.openjdk.java.net/~dxu/8013827/webrev.01/. -Dan From naoto.sato at oracle.com Fri May 31 18:21:40 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 31 May 2013 18:21:40 +0000 Subject: hg: jdk8/tl/jdk: 7006052: awt_InputMethod.c cleanup is needed Message-ID: <20130531182153.1C22F48E95@hg.openjdk.java.net> Changeset: 933b1338b99c Author: naoto Date: 2013-05-31 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/933b1338b99c 7006052: awt_InputMethod.c cleanup is needed Reviewed-by: anthony ! src/solaris/native/sun/awt/awt_InputMethod.c From brent.christian at oracle.com Fri May 31 18:27:35 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 31 May 2013 11:27:35 -0700 (PDT) Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A8AF47.3000802@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> Message-ID: <51A8EB97.1010407@oracle.com> On 5/31/13 7:10 AM, Alan Bateman wrote: > > I've read through the latest webrev, overall very good work. > > I had to read splitTreeBin a few times to convince myself as to how the > keys re-hash. I wonder if would be helpful to beef up the comment on > this method. I think that's a good idea: --- 342,355 ---- int loCount = 0, hiCount = 0; TreeNode e = oldTree.first; TreeNode next; ! ! // This method is called when the table has just increased capacity, ! // so indexFor() is now taking one additional bit of hash into ! // account ("bit"). Entries in this TreeBin now belong in one of ! // two bins, "i" or "i+bit", depending on if the new top bit of the ! // hash is set. The trees for the two bins are loTree and hiTree. ! // If either tree ends up containing fewer than TREE_THRESHOLD ! // entries, it is converted back to a linked list. while (e != null) { > Otherwise I didn't see anything obviously wrong. Minor alignment issue > with the comments on Holder. Fixed, thanks. -Brent From david.r.chase at oracle.com Fri May 31 18:52:41 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 31 May 2013 14:52:41 -0400 Subject: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32 In-Reply-To: <51A8E140.5010206@oracle.com> References: <519902D4.1010305@oracle.com> <4038C601-2140-47F2-A1C0-8D8A6E3A93F0@oracle.com> <5199D1B6.8080303@oracle.com> <33B10FE0-2D3E-42D8-86B4-F64824ADAB8F@oracle.com> <33B7F0F1-55B4-470A-B867-9067B307D015@oracle.com> <519A6134.8010902@oracle.com> <519AC0FC.9040300@oracle.com> <20546E25-DE3E-4EA3-BE67-776435C0EFA1@oracle.com> <7470D982-F9EE-4FD1-92A3-0BEEBA6B18FB@oracle.com> <51A2E35E.4090308@oracle.com> <2BF3BF7F-A3C9-4F63-9F90-06C82A6535DC@oracle.com> <2B569ED4-C633-4424-A13C-A620C9741171@oracle.com> <1574A405-1EC5-41B8-B965-802889ADBA3D@oracle.com> <51A8AB11.7040005@oracle.com> <7DBFA90C-646C-49AA-A964-D18BE8D2374E@oracle.com> <51A8E140.5010206@oracle.com> Message-ID: <75FF6042-AADF-4B04-9AC3-15101C7E9BDC@oracle.com> On 2013-05-31, at 1:43 PM, Vladimir Kozlov wrote: > On 5/31/13 7:42 AM, David Chase wrote: >> >> The current plumbing for the XX option does affect code flow in the compiled C; that was pretty much the entire point of it. Vladimir has a plan, I think his attitude is that if convert this into an intrinsic then we won't care about compiler version or updating the code to get rid of the assembler, it will just be done, for good. My POV is that for now it's done, and we don't have to touch it for a good long while (except that I left Windows unoptimized). > > My biggest concern about the assembler code in jdk is its support. Even if you document how you got ".byte 0xc4,0xe3", next person will have very hard time to fix/modify this code. From my point of view it is dead code. To modify it would be to break it :-). I see this mostly as a matter of division of concerns; the only reason I know of to modify it would be if the scheduling on some future processor was radically different; I did get different code from clang and gcc, but not substantially different, and I could not tell if there was a reliable difference in run times. Unless we put ourselves in the business of knowing how those particular intrinsics like to be scheduled on different processors -- and I cannot see that being worth our time unless there is a huge difference -- I assume we're going to be about as inflexible as pre-compiled assembly language, and if a big change occurs, by then we can recompile the C code. And unless we plan to derive the schedule algorithmically, even if we do generate specific schedules for specific machines, we'll probably just have them canned in the compiler -- probably a larger text footprint than just precompiling both versions of the code and choosing a function pointer to the better one at runtime. > About intrinsic. It will work on all OSs (including Windows) and don't need special versions of gcc, c++. But, it looks like, I need an other week to finish it. And I am worried about startup performance of intrinsic vs asm in jdk. It would be nice if we updated the reference versions of the compilers for jdk8, so that they were no longer "special". David From dan.xu at oracle.com Fri May 31 20:35:00 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 31 May 2013 20:35:00 +0000 Subject: hg: jdk8/tl/jdk: 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java Message-ID: <20130531203521.796F148E9A@hg.openjdk.java.net> Changeset: f522bbdf2859 Author: dxu Date: 2013-05-31 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f522bbdf2859 8015628: Test Failure in closed/java/io/pathNames/GeneralSolaris.java Reviewed-by: alanb ! test/java/io/pathNames/General.java ! test/java/io/pathNames/GeneralWin32.java From kurchi.subhra.hazra at oracle.com Fri May 31 20:59:32 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 31 May 2013 20:59:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130531205955.2370E48E9D@hg.openjdk.java.net> Changeset: 11cdcf87ad5d Author: jzavgren Date: 2013-05-31 15:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cdcf87ad5d 8008972: Memory leak: Java_java_net_TwoStacksPlainDatagramSocketImpl_receive0 [parfait] Summary: Modified the code so that "jumbo frames" are truncated before buffer allocation is considered. This makes the buffer length a reliable indication that a buffer has been allocated, and it can then be used during clean up. Reviewed-by: chegar, khazra, alanb Contributed-by: john.zavgren at oracle.com ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: f6e6c27c19f3 Author: jzavgren Date: 2013-05-31 15:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6e6c27c19f3 7188517: Check on '$' character is missing in the HttpCookie class constructor Summary: Modified the constructor code so that the cookie names are examined for leading dollar signs and if they do, an illegal argument exception is thrown. Reviewed-by: chegar, khazra, michaelm Contributed-by: john.zavgren at oracle.com ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java From kirk at kodewerk.com Thu May 30 13:21:47 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 30 May 2013 15:21:47 +0200 Subject: PhantomReference: why not cleared by GC when enqueued? In-Reply-To: References: Message-ID: <32159FF6-A1BF-432E-90C4-D0D982B3609C@kodewerk.com> The only useful use case that I've come up with for PhantomReference is to subclass it. In one case it was used as a wrapper so that we'd know when an object was being collected so that we could reap life-cycle information from it. The behaviour was triggered by an JMX control. I suppose there were other ways to do this but given I only wanted to collect when the object was about to be GC'ed..... Regards, Kirk On 2013-05-30, at 1:32 PM, Dmytro Sheyko wrote: > Mark, > > You are listed as an author of java.lang.ref classes. So you must know more than others. Could you shed light on this? > > Thank you, > Dmytro > > From: dmytro_sheyko at hotmail.com > To: hotspot-gc-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: PhantomReference: why not cleared by GC when enqueued? > Date: Wed, 29 May 2013 14:45:54 +0300 > > Hello, > > Why phantom references are not automatically cleared by the garbage collector as they are enqueued? > > Keeping phantom reachable objects in heap has some drawbacks: > 1. At least 2 GC are required in order to reclaim them, even in case when application code pulls references from reference queue and clears them promptly. > 2. GC pauses are increased since phantom reachable objects are still to be marked. > > On the other hand, benefits are not obvious. How we can use referent if it's not accessible? > > Regards, > Dmytro > From nick at transparentech.com Sun May 26 18:33:51 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Sun, 26 May 2013 20:33:51 +0200 Subject: [8] Review Request for 8009911 : [macosx] SWT app freeze when going full screen using Java 7 on Mac In-Reply-To: <0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com> References: <519B1ABE.10303@oracle.com> <0578C755-5F93-403B-A872-84B9D0CAF20A@oracle.com> Message-ID: +1 for this patch. (Thanks, Petr!) I have tried it in the latest jdk8 (b91) and it fixes both of the SWT+OpenJDK7&8 bugs that I submitted in the Eclipse bugzilla. Would be great if this could be accepted at least for jdk8 (if not jdk7u too). Cheers, Nick On Tue, May 21, 2013 at 1:07 PM, Petr Pchelko wrote: > Added macosx-port-dev > > On May 21, 2013, at 10:57 AM, David Holmes wrote: > > > Adding core-libs as this is actually a launcher change. > > > > David > > > > On 21/05/2013 4:36 PM, Petr Pchelko wrote: > >> Hello, AWT Team. > >> > >> Please review the fix for the issue: > >> http://bugs.sun.com/view_bug.do?bug_id=8009911 > >> The webrev is available at: > >> http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/ > >> > >> The problem: > >> When launching java with -XstatrOnFirstThread we were using > dispatch_sync to start a Java main on the main thread. This blocked the > main dispatch queue, so all the subsequent calls to GCD were never invoked. > GCD is used a bit in our code, but it is used inside Cocoa, for example for > fullscreen. > >> > >> The solution: > >> We now launch Java main using a performSelectorOnMaintThread, so we do > not block GCD. > >> > >> Notes: > >> 1. This also fixes the following SWT bug: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 > >> 2. Although I have added OBJC syntax into java_md_macosx.c file, I did > not rename it to .m, because: > >> a. It is hard to update an old build system to compile with the > new file name. > >> b. It is already compiled with -x objective-c, so I will compile > >> c. We would have lost all the hg history for this file. > >> > >> With best regards. Petr. > >> > >