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;
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, Roge
jdk sources
that nobody ever gets around to.
On Fri, Mar 27, 2015 at 2:51 PM, Lev Priima <mailto:lev.pri...@oracle.com>> wrote:
Updated and put some more final in other(not @Deprecated) methods:
http://cr.openjdk.java.net/~lpriima/8071571/2/
<http://cr.openjdk.java.ne
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 <mailto:lev.pri...@oracle.com>> wrote:
Martin,
You mean it
t len = 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 <mailto:lev.pri..
yours,
Ivan
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.
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
66 + "m";
And if it's null then we 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
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
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
forms.
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
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
adict
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 -vmop
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:
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
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
incr
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
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,
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 t
his issue may be closed as dup 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 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, if the
ag
and made 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!
I
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
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 80
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
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 fa
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 th
"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,
er 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/brows
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
/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 <mailto:lev.pri...@oracle.com>> wrote:
And these thread will be cleaned only when whole TPE finished.
Is this re
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 ArrayBlockingQueue(1) {
public Runnable take() throws InterruptedException {
throw new Runtim
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 wrote:
The second space should not be omitted in first line(status-line) of a http
response message: http
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 -jdk:jdk9/dev/bui
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:
http://cr.openjdk.java.net/~lpriima/8067471/webr
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 e
CountCP() {
return new 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
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 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
re . Do we 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 rej
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
43 matches
Mail list logo
