Note that my pending change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/getChars.patch
does the same kind of thing, but without recursive lock acquisitions.
I'm curious why a recursive lock acquisition would be considered "very"
cheap. Is there some hotspot magic, or is it simply
The change put through for JDK-8013395 (StringBuffer toString cache) has
exposed a previously unnoticed bug in the
StringBuffer.append(CharSequence cs) method. That method claimed to
achieve synchronization (and then correct toStringCache behaviour) by
the super.append method calling other Stri
Changeset: 08ebdb2b53cc
Author:plevart
Date: 2013-05-17 14:41 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08ebdb2b53cc
8014477: (str) Race condition in String.contentEquals when comparing with
StringBuffer
Reviewed-by: alanb, mduigou, dholmes
! src/share/classes/java/lan
The contents of the ARM jvm.cfg were put in place for the SE Embedded
product, but for the SE ARM implementation we want to enable ergonomics,
as we do on other platforms.
http://cr.openjdk.java.net/~dholmes/8014857/webrev/
--- old/src/solaris/bin/arm/jvm.cfg 2013-05-19 22:03:30.424314843
On 2013-05-19, at 12:50 PM, Alan Bateman wrote:
> On 16/05/2013 15:50, David Chase wrote:
>> webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
>>
>> problem: Some applications spend a surprising amount of time computing CRC32s
>> (Not sure I'm supposed to be precise on an open mail
On Thu, May 9, 2013 at 5:38 AM, Alan Bateman wrote:
> On 08/05/2013 23:05, Martin Buchholz wrote:
>
>> Alan (et al): Ping.
>>
>> I've looked through the webrev.
>
> The scary part is subsequenceRaw where the offsets including the position.
> I don't see anything obviously wrong and the tests shou
On Fri, May 10, 2013 at 4:08 PM, Joe Darcy wrote:
> On 05/10/2013 03:03 PM, Martin Buchholz wrote:
>
>> On Wed, May 8, 2013 at 5:30 PM, Mike Duigou
>> wrote:
>>
>> - There's been some informal discussion of packaging commonly used test
>>> utils as jtreg @library. This could be a good candidate
On Fri, May 17, 2013 at 5:37 PM, Mike Duigou wrote:
> Hi Martin,
>
> I had failed to notice that you were using 6813523 in your changeset.
> Since 6792262 is more specific can we switch to using that one?
>
>
Done.
On 16/05/2013 15:50, David Chase wrote:
webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
problem: Some applications spend a surprising amount of time computing CRC32s
(Not sure I'm supposed to be precise on an open mailing list). Recent Intel
architectures provide instructions tha
> PS - It would be great if this were standard practice in these discussions
> - perhaps someone can sponsor a summer of code project to set it up.
I've created an issue on MVNCENTRAL
(https://issues.sonatype.org/browse/MVNCENTRAL-320) -- wondering if
there's a (legal and clean) way to get all tha
On Thu, May 16, 2013 at 4:38 PM, Paul Sandoz wrote:
>
> How about doing a search for usages in all the jars on maven central?
>
> IMHO it really helps drive the discussions deprecation if we have some
> empirical data.
>
> Paul.
If memory serves, Joe Darcy and the Project Coin expert group per
11 matches
Mail list logo
