> - enable parallel heap inspecton for ShenandoahHeap
> - preliminary evaluation:
> Time of jmap histo on (8GB heap with 4GB objects)
> * before: 5.186s
> * after : 1.698s
Lin Zang has refreshed the contents of this pull request, and previous commits
have been removed. The increment
On Fri, 11 Sep 2020 13:54:38 GMT, Zhengyu Gu wrote:
>> Thank you, we'll take a look next week.
>
> Hi Lin,
>
> 1) The patch does not compile with assertion on
> @@ -1490,7 +1490,7 @@ private:
>cl->do_object(obj);
>obj->oop_iterate(&oops);
> }
> -assert(q.is_empty(), "sho
On Thu, 10 Sep 2020 23:38:45 GMT, Leonid Mesnik wrote:
> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
> with NULL to pass testing
> with -XX:+CheckUnhandledOops.
This pull request has now been integrated.
Changeset: 306b1663
Author:Leonid Mesnik
URL: ht
On Fri, 11 Sep 2020 18:26:03 GMT, Coleen Phillimore wrote:
>> This is a specific of "CheckUnhandledOops"
>> I've written in bug comment "Another possible fix would be to disable
>> corruption of NULL unhandled oops. They couldn't
>> be changed really."
>> We discussed it with Coleen and seems th
On Fri, 11 Sep 2020 02:56:26 GMT, Leonid Mesnik wrote:
>> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
>> with NULL to pass testing
>> with -XX:+CheckUnhandledOops.
>
> Leonid Mesnik has updated the pull request incrementally with one additional
> commit since the
On Fri, 11 Sep 2020 03:37:55 GMT, Leonid Mesnik wrote:
>> I'm missing something. How can a NULL oop get corrupted even if there is a
>> GC?
>
> This is a specific of "CheckUnhandledOops"
> I've written in bug comment "Another possible fix would be to disable
> corruption of NULL unhandled oops.
On Fri, 11 Sep 2020 02:56:26 GMT, Leonid Mesnik wrote:
>> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
>> with NULL to pass testing
>> with -XX:+CheckUnhandledOops.
>
> Leonid Mesnik has updated the pull request incrementally with one additional
> commit since the
On Fri, 11 Sep 2020 04:00:35 GMT, Chris Plummer wrote:
>> The change fixes the regression introduced by
>> https://bugs.openjdk.java.net/browse/JDK-8241080.
>>
>> Method validateAssignment() in com.sun.tools.jdi.ObjectReferenceImpl now
>> always retrieves the reference type and that
>> require
On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy
wrote:
>> 1) This is un-necessary churn.
>> 2) I can't even be sure I am finding the ones in my area because there's so
>> much here
>> 3) The ones I can find have no need of whatever performance improvement this
>> might bring.
>> I think th
On Fri, 11 Sep 2020 10:54:42 GMT, Aleksey Shipilev wrote:
>> Hi @shipilev,
>> I have update a PR that trying to reuse code in serial and parallel
>> heap iteration.
>> would you like to review again? Thanks
>> -Lin
>
> Thank you, we'll take a look next week.
Hi Lin,
1) The patch does
On Fri, 11 Sep 2020 09:54:50 GMT, Erik Helin wrote:
>
>
> Sorry, now I see. Yes, please remove `, 8233915` from the title!
Thanks for helping. The commit message does look better now.
-
PR: https://git.openjdk.java.net/jdk/pull/119
On Fri, 11 Sep 2020 09:05:53 GMT, Lin Zang wrote:
>> Thanks @shipilev， This is shenandoah support based on parallel heap
>> inspection enabling in serviceability (tracked with
>> https://bugs.openjdk.java.net/browse/JDK-8215624). hope it is helpful for
>> your review.
>
> Hi @shipilev,
> I
> - enable parallel heap inspecton for ShenandoahHeap
> - preliminary evaluation:
> Time of jmap histo on (8GB heap with 4GB objects)
> * before: 5.186s
> * after : 1.698s
Lin Zang has refreshed the contents of this pull request, and previous commits
have been removed. The increment
On Wed, 9 Sep 2020 03:00:26 GMT, Lin Zang wrote:
>> Thanks, this looks interesting.
>>
>> I need more time to digest this. It feels like we can merge together the
>> parallel (new) and serial (old) heap iteration
>> code for better maintainability. I could try to do so later.
>
> Thanks @shipil
On Tue, 8 Sep 2020 23:44:58 GMT, David Holmes wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8247589: Implementation of Alpine Linux/x64 Port
>
> make/autoconf/platform.m4 line 536:
>
>> 534: AC_SUBST(H
> - enable parallel heap inspection for ZCollectedHeap
> - preliminary evaluation:
> Time of jmap histo on 8GB heap with ~5GB objects
> * before: 7.103s
> * after : 2.734s (with 4 parallel threads)
Lin Zang has refreshed the contents of this pull request, and previous commits
have been remo
On Sun, 6 Sep 2020 01:13:48 GMT, Lin Zang wrote:
> - Parallel heap iteration support for PSS
> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103
Dear All,
May I ask your help to review this PR? Thanks!
-Lin
-
PR: https://git.openjdk.java.net/jdk/pull/25
On Thu, 10 Sep 2020 09:57:29 GMT, Lin Zang wrote:
>> Just looked at this briefly. My initial comment is that we need to avoid all
>> the code duplicated from ZHeapIterator and
>> isolate all this a bit better. Perhaps folding everything into one iterator,
>> that can be used by both object_iter
On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote:
>> **isEmpty** is faster + has less byte code + easier to read. Benchmarks
>> could be found
>>
>> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
>
> 1) This is un-necessary churn.
> 2) I can'
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
This pull request has been closed without
> continuing the review thread from here
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
>
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test
21 matches
Mail list logo
