Short version:
Cache the value returned by toString and use it to copy-construct a new
String on subsequent calls to toString(). Clear the cache on any
mutating operation.
webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/
Testing: microbenchmark for toString performance; new
Hi David,
Would it be beneficial to push the toStringCache up to
AbstractStringBuilder so that StringBuilder.toString() benefits from this
cache as well? It seems like this would affect both StringBuilder and
StringBuffer for repeated calls to toString(), although StringBuffer would
obviously
On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
While it's a burden, but somehow it serves as a test case pretty well.
The transitions are
being built the old jdk way and threeten way, if
Peter,
you're absolutely right: I was thinking about thread local values (object
instances) and not ThreadLocal keys !
I think ThreadLocal name is confusing as it does not correspond to values !
Several times I wonder if false sharing can happen between my thread local
values (i.e. different
One other quick comment, if the toStringCache is non-null during invocation
of toString(), that seems to imply that the StringBuffer/StringBuilder has
not been mutated since the last invocation of toString(), is there any
reason to still use the String copy constructor? This would address the
Hi Dave,
On 10/05/2013 4:25 PM, David Schlosnagle wrote:
Hi David,
Would it be beneficial to push the toStringCache up to
AbstractStringBuilder so that StringBuilder.toString() benefits from
this cache as well? It seems like this would affect both StringBuilder
and StringBuffer for repeated
Hi David,
One remote incompatibility note: the String returned from
StringBuffer.toString() is retained by StringBuffer until the next call
to StringBuffer mutating method. This can be observed for example if the
returned String object is wrapped by a WeakReference. This is really a
remotely
Hello everybody!
GzipInputStream uses SequenceInputStream to concatenate the underlying
stream with some data that reside in memory.
SequenceInputStream is implementing in such a way that it closes the
stream when it reaches EOS.
The solution is to wrap the underlying stream with extended
On 10/05/2013 07:03, David Holmes wrote:
Short version:
Cache the value returned by toString and use it to copy-construct a
new String on subsequent calls to toString(). Clear the cache on any
mutating operation.
webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/
Testing:
Hi,
This is a quick fix for a javadoc error in the JAXP 1.5 patch.
http://cr.openjdk.java.net/~joehw/jdk8/8014333/webrev/
Thanks,
Joe
Looks ok
Lance
--
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPhone
On May 10, 2013, at 5:11 AM, huizhe wang huizhe.w...@oracle.com wrote:
Hi,
This is a quick
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8012975/webrev.01/
Thanks
-Sundar
On Friday 03 May 2013 02:56 PM, Alan Bateman wrote:
On 03/05/2013 07:47, A. Sundararajan wrote:
Thanks. Looks like the first one has not been removed. But second one
was removed: hg stat
On 10/05/2013 10:26, A. Sundararajan wrote:
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8012975/webrev.01/
Thanks
-Sundar
PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed.
refs.allowed isn't quite right, the last line needs to be removed
On May 10, 2013, at 5:33 AM, David Holmes david.hol...@oracle.com wrote:
Looks good to me Mike!
+1
Paul.
On 5/10/2013 3:30 PM, Xueming Shen wrote:
On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
While it's a burden, but somehow it serves as a test case pretty well.
The transitions are
being
com/sun/script/util is generic utility package for script engine
implementations. Only com/sun/script/javascript package is being
removed. Since we include javax/script for profile 3, should we also
include com/sun/script/util ?
On refs.allowed, I'll remove it. How should I check this?
On 10/05/2013 11:23, A. Sundararajan wrote:
com/sun/script/util is generic utility package for script engine
implementations. Only com/sun/script/javascript package is being
removed. Since we include javax/script for profile 3, should we also
include com/sun/script/util ?
Is
Hi David, Thomas,
I think I understand you now, David. You want to minimize the
possibility of vacuously passing the test. So here's my attempt at that:
public class OOMEInReferenceHandler {
static Object[] fillHeap() {
Object[] first = null, last = null;
int size = 1
On 05/09/13 10:19, Peter Levart wrote:
Hi Aleksey,
Wouldn't it be even better if just threadLocalRandom* fields were annotated with
@Contended(ThreadLocal) ?
Some fields within the Thread object are accessed from non-local threads. I
don't know how frequently, but isolating just
On 05/10/13 02:31, Laurent Bourgès wrote:
Peter,
you're absolutely right: I was thinking about thread local values (object
instances) and not ThreadLocal keys !
I think ThreadLocal name is confusing as it does not correspond to values !
Several times I wonder if false sharing can happen
Okay, thanks. com.sun.script.util is not supported API (no CCC done for
it in the past). I'll remove it as suggested and run make profiles to
check
Thanks
-Sundar
On Friday 10 May 2013 04:09 PM, Alan Bateman wrote:
On 10/05/2013 11:23, A. Sundararajan wrote:
com/sun/script/util is generic
Hi Peter,
So it would appear that it is not in fact the new that causes the OOME
but the classloading of InterruptedException ?
I'm not sure I can quite get my head around this late on a Friday night :)
David
On 10/05/2013 9:21 PM, Peter Levart wrote:
On 05/10/2013 12:52 PM, Peter Levart
Hi again,
While the below patch works and keeps Reference Handler running in all
scenarios, the evaluation exposed a weakness of JVM. If loading of a
class fails because of OOME, this class can not be used in this
incarnation of the VM even if OOME was just a transient condition.
Regards,
On 05/10/2013 03:14 PM, David Holmes wrote:
Hi Peter,
So it would appear that it is not in fact the new that causes the
OOME but the classloading of InterruptedException ?
Depends on whether the InterruptedException class was already loaded or
not when new is attempted.
I'm not sure I
On 2013-05-10, at 2:47 AM, David Holmes david.hol...@oracle.com wrote:
Right this was our first thought too, but the specification for toString
states that a new String is created. So to go this path we'd also have to
push through a spec change for StringBuilder/StringBuffer. Given this is an
On 10.05.2013, at 16:17, Doug Lea d...@cs.oswego.edu wrote:
On 05/09/13 10:19, Peter Levart wrote:
Hi Aleksey,
Wouldn't it be even better if just threadLocalRandom* fields were annotated
with
@Contended(ThreadLocal) ?
Some fields within the Thread object are accessed from non-local
Updated webrev and specdiff.
http://cr.openjdk.java.net/~chegar/8014076/ver.01/specdiff/java/util/Arrays.html
http://cr.openjdk.java.net/~chegar/8014076/ver.01/webrev/
I incorporated the feedback so far, and reverted the change to make
MIN_ARRAY_SORT_GRAN public ( there doesn't appear to be
Hi Sundar
Looks like you have resolved the subtleties of profiles with Alan.
The rest looks good to me.
Tim
On 05/10/13 05:47 AM, A. Sundararajan wrote:
Okay, thanks. com.sun.script.util is not supported API (no CCC done
for it in the past). I'll remove it as suggested and run make
Please review this minor correction to DivModTests to address this issue:
http://bugs.sun.com/view_bug.do?bug_id=8014296
With autoboxing of mixed types primitive and Object, the operators == and !=
are interpreted as reference compare instead of value compares.
The compiler is silent about
Changeset: ce7e1674eb73
Author:alanb
Date: 2013-05-10 16:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce7e1674eb73
8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that
javax.script is in compact1
Reviewed-by: mchung
!
On 05/10/2013 08:02 AM, roger riggs wrote:
Please review this minor correction to DivModTests to address this issue:
http://bugs.sun.com/view_bug.do?bug_id=8014296
With autoboxing of mixed types primitive and Object, the operators ==
and !=
are interpreted as reference compare instead of
Thanks, the webrev now has the correct copyright change.
On 5/10/2013 11:14 AM, Joe Darcy wrote:
On 05/10/2013 08:02 AM, roger riggs wrote:
Please review this minor correction to DivModTests to address this
issue:
http://bugs.sun.com/view_bug.do?bug_id=8014296
With autoboxing of mixed
Good to push.
-Joe
On 05/10/2013 08:25 AM, roger riggs wrote:
Thanks, the webrev now has the correct copyright change.
On 5/10/2013 11:14 AM, Joe Darcy wrote:
On 05/10/2013 08:02 AM, roger riggs wrote:
Please review this minor correction to DivModTests to address this
issue:
Thanks, I'll need help with the push (I'm not a committer for JDK).
On 5/10/2013 11:39 AM, Joe Darcy wrote:
Good to push.
-Joe
On 05/10/2013 08:25 AM, roger riggs wrote:
Thanks, the webrev now has the correct copyright change.
On 5/10/2013 11:14 AM, Joe Darcy wrote:
On 05/10/2013 08:02
Pushed; cheers,
-Joe
On 05/10/2013 08:40 AM, roger riggs wrote:
Thanks, I'll need help with the push (I'm not a committer for JDK).
On 5/10/2013 11:39 AM, Joe Darcy wrote:
Good to push.
-Joe
On 05/10/2013 08:25 AM, roger riggs wrote:
Thanks, the webrev now has the correct copyright
Changeset: 2490769abdfa
Author:mduigou
Date: 2013-05-10 09:51 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2490769abdfa
8014316: Use Method Refs in j.u.stream.MatchOps
Reviewed-by: dholmes
! src/share/classes/java/util/stream/MatchOps.java
Changeset: 9891e4d7d5b3
Author:
The implementation looks OK to me. I like Peter's suggestion of caching the
char[] rather than string.
I do wish that the cache could be in a soft reference but understand that there
are tradeoffs to doing so. I am worried about leaks with this implementation.
Another possibility, to go
Hello,
Please review this small refactoring of types in
sun.reflect.generics.reflectiveObjects.* to use methods in
java.util.Objects and the new method in JDK 8 Types.getTypeName.
Webrev at
http://cr.openjdk.java.net/~darcy/8014357.0/
patch below.
Thanks,
-Joe
diff -r c26e0d29249a
Thanks for the review.
I have updated the Charset.java to use the init-on-depand holder idiom.
I don't think MSISO2022JP/ISO2022_JP_2 are really worth the cost of adding
two more classes, so I leave them asis.
Agreed that the ExtendedCahrsets change can be separated, but since we're here
The fix looks reasonable to me.
Mike
On May 10 2013, at 01:03 , Ivan Gerasimov wrote:
Hello everybody!
GzipInputStream uses SequenceInputStream to concatenate the underlying stream
with some data that reside in memory.
SequenceInputStream is implementing in such a way that it closes the
If you really want to bullet-proof ReferenceHandler (and other system
threads) against OOME caused by native allocations,
then don't forget about monitor inflation if there is contention for
lock :-)
dl
On 5/10/2013 6:14 AM, David Holmes wrote:
Hi Peter,
So it would appear that it is not in
On 05/10/2013 05:27 PM, Aleksey Shipilev wrote:
Although I just tried what Peter had suggested, and got even more
boost on my microbenchmark. This counter-intuitive for me, since no
memory layout differences could explain this in my tests. I will have
to untangle this today, hold on.
Ok, I
On 5/10/2013 10:40 AM, Joe Darcy wrote:
Hello,
Please review this small refactoring of types in
sun.reflect.generics.reflectiveObjects.* to use methods in
java.util.Objects and the new method in JDK 8 Types.getTypeName.
Webrev at
http://cr.openjdk.java.net/~darcy/8014357.0/
Looks
On Fri, May 10, 2013 at 10:36 AM, Mike Duigou mike.dui...@oracle.comwrote:
The implementation looks OK to me. I like Peter's suggestion of caching
the char[] rather than string.
I do wish that the cache could be in a soft reference but understand that
there are tradeoffs to doing so. I am
Here's an updated webrev for this fix:
http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-failure.2/
http://cr.openjdk.java.net/%7Ejgish/Bug7184195-global-logger-failure.2/
The changes from the previous one are:
- breaking apart the two tests so that logger initialization in the
basic
On 05/10/2013 11:18 AM, Mandy Chung wrote:
On 5/10/2013 10:40 AM, Joe Darcy wrote:
Hello,
Please review this small refactoring of types in
sun.reflect.generics.reflectiveObjects.* to use methods in
java.util.Objects and the new method in JDK 8 Types.getTypeName.
Webrev at
Changeset: f84b5498b2bb
Author:darcy
Date: 2013-05-10 12:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f84b5498b2bb
8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.*
Reviewed-by: mchung
!
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really want to bullet-proof ReferenceHandler (and other system
threads) against OOME caused by native allocations,
then don't forget about monitor inflation if there is contention for
lock :-)
Aren't monitors C++ objects? Are they allocated
On 05/10/2013 10:08 PM, Peter Levart wrote:
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really want to bullet-proof ReferenceHandler (and other system
threads) against OOME caused by native allocations,
then don't forget about monitor inflation if there is contention for
lock :-)
On 5/10/2013 1:22 PM, Peter Levart wrote:
On 05/10/2013 10:08 PM, Peter Levart wrote:
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really want to bullet-proof ReferenceHandler (and other
system threads) against OOME caused by native allocations,
then don't forget about monitor inflation
Hello,
Please (re)review this change to introduce Objects.requireNonNull(T,
SupplierString):
http://cr.openjdk.java.net/~darcy/8014365.0/
The original change had to be pulled out because of a build issue
(8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs
build); I'll be
On May 9, 2013, at 5:28 PM, Brian Burkhalter wrote:
I just went ahead and filed 8014319 and 8014320 for phases 3 and 4,
respectively. They will show up onhttp://bugs.sun.com/bugdatabase after some
unspecified delay, probably about a day. Verbiage may be updated as needed.
Indeed these
Hi,
The FileInputStream.available() method can return a negative value when
the file position is beyond the endof afile. This is an unspecified
behaviour that has the potential to break applications that expect
available to return a value of 0 or greater. The
FileInputStream.skip(long)
Changeset: 1c43236f6d69
Author:darcy
Date: 2013-05-10 14:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1c43236f6d69
8014365: Restore Objects.requireNonNull(T, SupplierString)
Reviewed-by: jjg
! makefiles/BuildLangtools.gmk
On Wed, May 8, 2013 at 5:30 PM, Mike Duigou mike.dui...@oracle.com wrote:
AbstractStringBuilder::
- The impls like insert(int dstOffset, CharSequence s) makes me slightly
uneasy because the private value field escapes to an unknown class. Who
knows what evil (or foolishness) could result?
The proposed fix does solve the issue.
However it appears it does not fix the root cause that triggers this problem.
The root cause, or the direct trigger of this bug is the fact that
ZipInputStream
.availble() is really NOT reliable to tell us whether or not there is any byte
available to be
Hi,
The normalize() implementations in UnixFileSystem.java and
WinNTFileSystem.java can be improved to make it simpler, easier, and
more efficient. I have refactoredthecode when working on JDK-8003992.
And Iwould like to send it out for a review in this separate bug. Thanks!
webrev:
On 05/10/2013 03:03 PM, Martin Buchholz wrote:
On Wed, May 8, 2013 at 5:30 PM, Mike Duigou mike.dui...@oracle.com wrote:
- There's been some informal discussion of packaging commonly used test
utils as jtreg @library. This could be a good candidate. ArraysCharSequence
is a candidate for
On 11/05/2013 6:53 AM, Dean Long wrote:
On 5/10/2013 1:22 PM, Peter Levart wrote:
On 05/10/2013 10:08 PM, Peter Levart wrote:
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really want to bullet-proof ReferenceHandler (and other
system threads) against OOME caused by native allocations,
On May 10 2013, at 07:14 , Chris Hegarty wrote:
Updated webrev and specdiff.
http://cr.openjdk.java.net/~chegar/8014076/ver.01/specdiff/java/util/Arrays.html
Docs changes look fine to me.
http://cr.openjdk.java.net/~chegar/8014076/ver.01/webrev/
ArraysParallelSortHelpers::
- It's
Sherman,
The charsetForName, charsets and aliasesFor methods call init() first and
then access the maps with no synchronization. While the maps are being
accessed by one thread and system initialization completes, another thread
calls charsetForName() that calls init() which will update the
On Wed, May 8, 2013 at 5:30 PM, Mike Duigou mike.dui...@oracle.com wrote:
- Could use a @DataProivder for CharSequence[] seqs = { style tests.
OK, so I went and learned about DataProvider. Not too painful. Added in
some uses of bleeding edge lambda stuff as well to pretty up the GetChars
62 matches
Mail list logo
