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