On 31.12.2014 16:26, Lev Priima wrote:
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
I would say I'm Okay with the latest variant, if the performance team
doesn't have any objections.
Sincerely yours,
Ivan
Best Regards,
Lev
On 01/12/2015 01:03 PM, Ivan Gerasimov wrote:
On 31.12.2014 16:26, Lev Priima wrote:
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
I would say I'm Okay with the latest variant, if the performance team
doesn't have any objections.
No objection from
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
Best Regards,
Lev
Hi Lev!
When you'll be preparing the final webrev, can you please also include a
typo fix in it?
s/dstbegin/dstBegin/g
This typo is found in a couple of places in String.java.
Sincerely yours,
Ivan
Thanks Ivan,
As I understood dstbegin typo was only in comments. I've changed it to
camelCase as in code.
I've also applied benchmarked by Claes patch from
http://cr.openjdk.java.net/~redestad/8067471/webrev.03/
Please review latest changeset:
On 12/19/2014 03:41 AM, Lev Priima wrote:
By naive glance, new constructor thrpt is bigger(jdk9/dev vs 9b42
in attach) on:
@Benchmark
public String getNewString() {
return new String();
}
This is how you do it:
http://cr.openjdk.java.net/~shade/8067471/
Hi again,
I just had a nagging thought. For applications reporting some or a lot
of different empty String objects,
this might be due not to use of this constructor, but due to things like
an empty StringBuilder.toString() ending
up calling java.lang.String(char[] value, int offset, int count)
Aleksey,
Thanks for exhaustive research. Looks formal enough to claim that both
variants of change bring only perf advantages, but, as I understand,
which one is better is not so straightforward.
On 12/19/2014 04:11 PM, Aleksey Shipilev wrote:
On 12/19/2014 03:41 AM, Lev Priima wrote:
By
Hi everyone!
I guess something like the following might be used to avoid slowing down
the common route:
194 if (count = 0) {
if (count == 0) {
this.value = .value;
}
195 throw new
Claes,
Is the source of arrays in these benchmarks unpredictable enough to
avoid branch checks elimination in compiled code?
On 12/19/2014 05:25 PM, Claes Redestad wrote:
Hi again,
I just had a nagging thought. For applications reporting some or a lot
of different empty String objects,
On 21.12.2014 18:37, Lev Priima wrote:
Thanks for exhaustive research. Looks formal enough to claim that both
variants of change bring only perf advantages, but, as I understand,
which one is better is not so straightforward.
Both are sound performance-wise, and you can see that they produce
Agree, but it's not just style. More formal, Implementation of same
requirements(both performance and functional) in less code, is an src
quality metric.
On 12/19/2014 08:52 PM, Aleksey Shipilev wrote:
On 21.12.2014 18:37, Lev Priima wrote:
Thanks for exhaustive research. Looks formal enough
No, as mentioned, I didn't check for mixed inputs, which is probably
necessary to ensure we don't slow down the typical case due
to adding an extra branch, so I went about and made an attempt to write
a microbenchmark to capture this[1] by making the count
parameter unpredictable without
On 19.12.2014 18:36, Ivan Gerasimov wrote:
Hi everyone!
I guess something like the following might be used to avoid slowing
down the common route:
Sorry, it was meant to be:
if (count = 0) {
if (count 0) {
throw new
On Fri, Dec 19, 2014 at 11:14 AM, Ivan Gerasimov
ivan.gerasi...@oracle.com wrote:
Sorry, it was meant to be:
if (count = 0) {
if (count 0) {
throw new StringIndexOutOfBoundsException(count);
}
if (offset =
Claes,
Thanks for cool suggestion:
http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
public java.lang.String();
Signature: ()V
flags: ACC_PUBLIC
LineNumberTable:
line 137: 0
line 138: 4
line 139: 13
Code:
stack=2, locals=1, args_size=1
0:
Hi Rémi,
Sure this examples will not be affected, but we have to concern about
other applications which are probably using this constructor. Could you
suggest such applications?
On 17.12.2014 21:49, Remi Forax wrote:
On 12/17/2014 11:22 AM, Lev Priima wrote:
Hi,
Please review space
Hi,
Please review space optimization in no args String constructor.
Originally, it was already rejected once by suggestion in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html w/o
formal justification of pros and contras. And enhancement was requested
again by Nathan
On 2014-12-17 11:22, Lev Priima wrote:
Hi,
Please review space optimization in no args String constructor.
Originally, it was already rejected once by suggestion in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html
w/o formal justification of pros and contras. And
On 17.12.2014 18:58, Claes Redestad wrote:
On 2014-12-17 11:22, Lev Priima wrote:
Please review space optimization in no args String constructor.
Originally, it was already rejected once by suggestion in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html
w/o formal
On 12/17/2014 11:22 AM, Lev Priima wrote:
Hi,
Please review space optimization in no args String constructor.
Originally, it was already rejected once by suggestion in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html
w/o formal justification of pros and contras.
21 matches
Mail list logo
