Looks good David.
Mike
On May 13 2013, at 22:10 , David Holmes wrote:
> On 14/05/2013 5:05 AM, Alan Bateman wrote:
>> On 13/05/2013 08:12, David Holmes wrote:
>>> Thanks for all the feedback and discussion. I've rewritten the patch
>>> to use Peter's suggestion of caching the char[] instead of t
On 14/05/2013 06:10, David Holmes wrote:
:
I'm not sure what to say about the copy-on-change-after-toString
approach. As the offset/count fields have been removed from String then
it could only be the count == value.length case. It would clearly be a
win in some cases but no help in others.
R
On 05/14/2013 07:10 AM, David Holmes wrote:
[...]
So here is hopefully final webrev:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/
It is the same approach as v3, but as Florian pointed out the cache
should be cleared before the mutating action - just in case there is
an exception.
Right, sb.length() should be used. I will correct that as soon as I get to
the keyboard.
Regards, Peter
On May 14, 2013 7:22 AM, "David Holmes" wrote:
> Thanks Peter! I've filed
>
> 8014477
> Race condition in String.contentEquals when comparing with StringBuffer
>
> On 14/05/2013 8:34 AM, Peter
Thanks Peter! I've filed
8014477
Race condition in String.contentEquals when comparing with StringBuffer
On 14/05/2013 8:34 AM, Peter Levart wrote:
On 05/14/2013 12:09 AM, Peter Levart wrote:
I noticed a synchronization bug in String.contentEquals method. If
called with a StringBuffer argument
On 14/05/2013 5:05 AM, Alan Bateman wrote:
On 13/05/2013 08:12, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/
I too am
On 05/14/2013 12:09 AM, Peter Levart wrote:
I noticed a synchronization bug in String.contentEquals method. If
called with a StringBuffer argument while concurrent thread is
modifying the StringBuffer, the method can either throw
ArrayIndexOutOfBoundsException or return true even though the co
On 05/13/2013 09:05 PM, Alan Bateman wrote:
On 13/05/2013 08:12, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/
I to
On 13/05/2013 08:12, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/
I too am concerned that any form of caching that a
On 05/10/2013 08:03 AM, David Holmes wrote:
Short version:
Cache the value returned by toString and use it to copy-construct a new
String on subsequent calls to toString(). Clear the cache on any
mutating operation.
webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/
Shouldn't you
On 13/05/2013 6:39 PM, Peter Levart wrote:
On 05/13/2013 10:07 AM, Remi Forax wrote:
Hi David,
On 05/13/2013 09:12 AM, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://
On 05/13/2013 10:07 AM, Remi Forax wrote:
Hi David,
On 05/13/2013 09:12 AM, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webre
On 13/05/2013 6:07 PM, Remi Forax wrote:
Hi David,
On 05/13/2013 09:12 AM, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v
Hi David,
On 05/13/2013 09:12 AM, David Holmes wrote:
Thanks for all the feedback and discussion. I've rewritten the patch
to use Peter's suggestion of caching the char[] instead of the actual
String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/
I too am concerned that any form of
Thanks for all the feedback and discussion. I've rewritten the patch to
use Peter's suggestion of caching the char[] instead of the actual String:
http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/
I too am concerned that any form of caching that avoids the array-copy
(which is the crux of
On Fri, May 10, 2013 at 10:36 AM, Mike Duigou wrote:
> The implementation looks OK to me. I like Peter's suggestion of caching
> the char[] rather than string.
>
> I do wish that the cache could be in a soft reference but understand that
> there are tradeoffs to doing so. I am worried about leaks
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 totall
On 2013-05-10, at 2:47 AM, David Holmes wrote:
> Right this was our first thought too, but the specification for toString
> states that a new String is created. So to go this path we'd also have to
> push through a spec change for StringBuilder/StringBuffer. Given this is an
> obscure corner ca
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: microb
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
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 cal
Hi David,
On 10/05/2013 4:39 PM, David Schlosnagle wrote:
One other quick comment, if the toStringCache is non-null during
invocation of toString(), that seems to imply that the
StringBuffer/StringBuilder has not been mutated since the last
invocation of toString(), is there any reason to still
One other quick comment, if the toStringCache is non-null during invocation
of toString(), that seems to imply that the StringBuffer/StringBuilder has
not been mutated since the last invocation of toString(), is there any
reason to still use the String copy constructor? This would address the
http:
Hi David,
Would it be beneficial to push the toStringCache up to
AbstractStringBuilder so that StringBuilder.toString() benefits from this
cache as well? It seems like this would affect both StringBuilder and
StringBuffer for repeated calls to toString(), although StringBuffer would
obviously have
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 reg
25 matches
Mail list logo
