Martin,
So I've updated webrev w/o adding final everywhere:
http://cr.openjdk.java.net/~lpriima/8071571/3/ .
Lev
On 03/28/2015 01:15 AM, Lev Priima wrote:
On 03/28/2015 12:59 AM, Martin Buchholz wrote:
I was only suggesting using final in the stylized
final Type foo = this.foo;
Using
Please review small cleanup in java.lang.String:
Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.
--
Lev
On 27.03.2015 17:56, Lev Priima wrote:
Please review small cleanup in java.lang.String:
Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.
= value.length;
2889 int st = 0;
2890 char[] val = value;/* avoid getfield opcode */
Also, 'beg' and 'end' would be much better names for the locals 'st'
and 'len'.
On Fri, Mar 27, 2015 at 12:54 PM, Lev Priima lev.pri...@oracle.com
mailto:lev.pri...@oracle.com wrote:
Hi
Updated and put some more final in other(not @Deprecated) methods:
http://cr.openjdk.java.net/~lpriima/8071571/2/
Lev
On 03/27/2015 11:50 PM, Martin Buchholz wrote:
On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima lev.pri...@oracle.com
mailto:lev.pri...@oracle.com wrote:
Martin,
You
I'm closer to Martins opinion. In my opinion, Immutability really
improves readability of code, but longer declaration doesn't. That's why
some contemporary languages use shorter var/val for declarations.
Lev
On 03/28/2015 01:01 AM, Martin Buchholz wrote:
On Fri, Mar 27, 2015 at 2:57 PM,
are on 32bit vm, don't have big oops and can
run test with 385m at least.
Lev
On 03/18/2015 03:25 PM, David Holmes wrote:
On 18/03/2015 9:46 PM, Lev Priima wrote:
On 03/18/2015 01:52 PM, David Holmes wrote:
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update:
http://cr.openjdk.java.net/~lpriima/8075071/1/webrev
On 03/18/2015 01:52 PM, David Holmes wrote:
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap
.
David
On 17/03/2015 10:15 PM, Lev Priima wrote:
Yes.
Lev
On 03/17/2015 02:56 PM, David Holmes wrote:
On 17/03/2015 9:15 PM, Lev Priima wrote:
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default
InitialHeapSize in
case
with each other.
Lev
On 03/17/2015 07:40 AM, David Holmes wrote:
Hi Lev,
On 17/03/2015 6:30 AM, Lev Priima wrote:
Please reviewand push:
Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
Tested locally:
jtreg -vmoptions
Yes.
Lev
On 03/17/2015 02:56 PM, David Holmes wrote:
On 17/03/2015 9:15 PM, Lev Priima wrote:
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
case if -Xms also wasn't set explicitly). In other
Please reviewand push:
Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
Tested locally:
jtreg -vmoptions:-XX:MaxRAMFraction=9223372036854775807
-XX:-UseCompressedOops test/java/util/Arrays/TimSortStackSize2.java
Test results:
this cleanup is also required to fix this:
https://bugs.openjdk.java.net/browse/JDK-8073959
Lev
On 02/26/2015 02:01 PM, Lev Priima wrote:
Thanks David,
Are OK with pushing this
http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?
Lev
On 02/26/2015 10:20 AM, David Holmes wrote
Hi Seth,
No. But, General direction of openjdk is mostly care about do not
introduce regression in next release. All performance improvements are
introduced with a very conservative way with checking that we do not
slow down any previous behavior/benchmarks. I'm almost sure that simple
Thanks David,
Are OK with pushing this
http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?
Lev
On 02/26/2015 10:20 AM, David Holmes wrote:
On 24/02/2015 8:39 PM, Lev Priima wrote:
I've updated summary and description.
Okay - thanks.
David
Lev
On 02/23/2015 04:55 AM, David
Thanks a lot, David!
Lev
On 02/27/2015 01:10 AM, David Holmes wrote:
Okay I will push this for you Lev.
Thanks,
David
On 27/02/2015 6:53 AM, Lev Priima wrote:
this cleanup is also required to fix this:
https://bugs.openjdk.java.net/browse/JDK-8073959
Lev
On 02/26/2015 02:01 PM, Lev Priima
I've updated summary and description.
Lev
On 02/23/2015 04:55 AM, David Holmes wrote:
On 20/02/2015 7:57 PM, Lev Priima wrote:
Functional is pretty same, but:
- make it run with a single argument '67108864' by moving @summary tag
strait down to line after the @run tag
- '-Xmx385
of JDK-8073354 and test will
pass after applying JDK-8073354. But I just want to use this RFE ID to
make test run with a single argument ( as you noticed previously ).
Lev
On 02/20/2015 05:26 AM, David Holmes wrote:
On 19/02/2015 11:23 PM, Lev Priima wrote:
After Jespers comments I removed catch
it start with a single argument.
Please review and push:
http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
Lev
On 02/17/2015 09:55 AM, David Holmes wrote:
On 17/02/2015 3:43 PM, Lev Priima wrote:
Thanks David!
Is this expected
After Jespers comments I removed catch of OOME and added minimum heap
size required for test(-Xms385) to overcome default ergonomics for client.
Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
Lev
On 02/19/2015 03:00 PM, Lev Priima wrote:
There is also a problem
Thanks David!
Is this expected behavior of this annotation ?
Lev
On 02/17/2015 03:20 AM, David Holmes wrote:
On 16/02/2015 9:20 PM, David Holmes wrote:
On 16/02/2015 6:59 PM, Lev Priima wrote:
Thanks, David,
Could you please push it ?
I will if Roger doesn't get to it first. It'll be 11
Thanks, David,
Could you please push it ?
Lev
On 02/16/2015 08:55 AM, David Holmes wrote:
On 14/02/2015 12:03 AM, Lev Priima wrote:
Please review and push:
http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8073124
I hadn't realized 8072909
Please review and push:
http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8073124
Lev
On 02/13/2015 05:20 AM, David Holmes wrote:
Hi Lev,
On 13/02/2015 2:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on worst
case, generated by test, it starts to fail on length 67108864.
After increasing stack size of runs to merge, Arrays.sort(T[]) works
also on maximum possible array for HotSpot JVM.
Roger, David,
I've updated
Thanks!
Lev
On 02/12/2015 02:53 PM, Roger Riggs wrote:
Hi Lev,
ok, looks fine,
I'll sponsor it and push it.
Roger
On 2/12/2015 11:56 AM, Lev Priima wrote:
Christos,
Test may fail on shorter arrays(page 8 of paper). For instance, on
worst case, generated by test, it starts to fail
Hi,
Stack length increased previously by JDK-8011944 was insufficient for
some cases.
Please review and push:
webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
issue: https://bugs.openjdk.java.net/browse/JDK-8072909
--
Lev
to
reestablish the invariant?
Roger
On 2/11/2015 11:29 AM, Lev Priima wrote:
Hi,
Stack length increased previously by JDK-8011944 was insufficient for
some cases.
Please review and push:
webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
issue: https://bugs.openjdk.java.net/browse/JDK
49 is also mentioned in the paper as possible solution. I've run test
from webrev with array length 2147483644 (Integer.MAX_VALUE-4) and
TimSort passed.
Lev
On 02/11/2015 10:57 PM, David Holmes wrote:
On 12/02/2015 5:14 AM, Lev Priima wrote:
Just briefly looked at it, w/o evaluating formal
/01/2015 7:03 AM, Lev Priima wrote:
Yes. And if we have BlockingQueue w/ some amount of tasks which fail
with exceptions, same amount of threads(not limited by neither
maximumPoolSize/corePoolSize) will hang under TPE which takes tasks from
this queue.
It may cause problems if queue has a big
and we eventually get OOME while unable to create new native thread.
Lev
On 01/27/2015 11:31 PM, Martin Buchholz wrote:
On Tue, Jan 27, 2015 at 7:43 AM, Lev Priima lev.pri...@oracle.com
mailto:lev.pri...@oracle.com wrote:
And these thread will be cleaned only when whole TPE finished
Using TPE w/ custom BlockingQueue and if RuntimeException happens in
blocking BlockingQueue.take() method then this code
new ThreadPoolExecutor(1, 1, 0, TimeUnit.NANOSECONDS,
new ArrayBlockingQueueRunnable(1) {
public Runnable take() throws InterruptedException {
throw
The second space should not be omitted in first line(status-line) of a
http response message: http://tools.ietf.org/html/rfc7230#section-3.1.2 .
Issue: http://bugs.openjdk.java.net/browse/JDK-8068795
Patch: http://cr.openjdk.java.net/~lpriima/8068795/webrev.00/
Testing:
$ jtreg
Thanks Chris,
Could you please push it?
Best Regards,
Lev
On 01/16/2015 09:14 PM, Chris Hegarty wrote:
This looks ok to me Lev.
-Chris.
On 16 Jan 2015, at 17:02, Lev Priima lev.pri...@oracle.com wrote:
The second space should not be omitted in first line(status-line) of a http
response
Thanks Ivan!
I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.
Best Regards,
Lev
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:
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
String(emptyIntArray, 0, 0);
}
@Benchmark
public String singleStringCount() {
return new String(singleCharArray, 0, 1);
}
@Benchmark
public String singleStringCountCP() {
return new String(singleIntArray, 0, 1);
}
On 2014-12-19 01:41, Lev Priima wrote
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
have bigapps-like benchmarks
which may show regression on this?
On 17.12.2014 21:10, Aleksey Shipilev wrote:
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
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
42 matches
Mail list logo
