Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v6]

2022-05-09 Thread Albert Mingkun Yang
> Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - merge - review - comment - Rework reference type initialization Sign

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

2022-04-29 Thread Albert Mingkun Yang
On Fri, 29 Apr 2022 10:56:49 GMT, Kim Barrett wrote: >> The current approach limits the knowledge of non-strong ref types to >> `instanceRefKlass` file. > > The `_reference_type` used to be initialized correctly in most cases, but > needed fixing up for a few cases during bootstrapping. With thi

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

2022-04-28 Thread Albert Mingkun Yang
On Thu, 28 Apr 2022 11:05:45 GMT, Kim Barrett wrote: >> Albert Mingkun Yang has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - comment >> - Rework reference type initialization >> >>S

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v5]

2022-04-28 Thread Albert Mingkun Yang
> Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review - Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - n

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

2022-04-28 Thread Albert Mingkun Yang
> Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - comment - Rework reference type initialization Signed-off-by: Albert Yang - Changes

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3]

2022-04-28 Thread Albert Mingkun Yang
On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one > additional commit since the last revision: > > Remove REF_

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3]

2022-04-27 Thread Albert Mingkun Yang
On Wed, 27 Apr 2022 12:35:56 GMT, Coleen Phillimore wrote: >> Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only >> an InstanceKlass, not an InstanceRefKlass. > > Yeah, please add a short comment in the is_java_lang_ref_Reference_subclass > function that this is the ca

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v2]

2022-04-22 Thread Albert Mingkun Yang
On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one > additional commit since the last revision: > > review I

Re: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v3]

2022-04-22 Thread Albert Mingkun Yang
> Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: Remove REF_ enum for java.lang.ref.Reference Signed-off-by: Albert Yang - Changes: - a

Re: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2]

2022-04-22 Thread Albert Mingkun Yang
On Fri, 22 Apr 2022 08:03:42 GMT, Stefan Karlsson wrote: > Using REF_SOFT seems too hacky. Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. // in vmClasses::resolve_all vmClasses::Reference_klass()->set_reference_type(REF_SOFT); // setting ref-type of Sof

Re: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2]

2022-04-21 Thread Albert Mingkun Yang
On Thu, 21 Apr 2022 12:19:20 GMT, Stefan Karlsson wrote: > had hoped to fine a way to just get rid of it instead of finding a better > name. `vmClasses::Reference_klass()->set_reference_type(REF_SOFT);` works. In fact, anything other than `REF_NONE` works. The correct ref-type for each subclas

Re: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2]

2022-04-21 Thread Albert Mingkun Yang
On Thu, 21 Apr 2022 11:36:35 GMT, Stefan Karlsson wrote: > Maybe the latter could be changed to REF_NONE? `vmClasses::Reference_klass()->set_reference_type(REF_NONE);` fails in `make images`. The relevant code is: ClassFileParser::post_process_parsed_stream(...) { ... _rt = (NULL ==_supe

Re: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2]

2022-04-21 Thread Albert Mingkun Yang
> Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review - Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - n

RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER

2022-04-21 Thread Albert Mingkun Yang
Simple rename and some comments update. Test: build - Commit messages: - ref-rename Changes: https://git.openjdk.java.net/jdk/pull/8332/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285364 Stats: 9 li

Re: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration

2022-03-21 Thread Albert Mingkun Yang
On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang wrote: > Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to > see the actual (small) change, such as dropping the `virtual` modifier, > introducing small helper methods to avoid naming collision, etc.

Integrated: 8281879: Serial: Merge CardGeneration into TenuredGeneration

2022-03-21 Thread Albert Mingkun Yang
On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang wrote: > Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to > see the actual (small) change, such as dropping the `virtual` modifier, > introducing small helper methods to avoid naming collision, etc.

Re: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration

2022-03-07 Thread Albert Mingkun Yang
On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang wrote: > Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to > see the actual (small) change, such as dropping the `virtual` modifier, > introducing small helper methods to avoid naming collision, etc.

RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration

2022-02-15 Thread Albert Mingkun Yang
Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc. Test: tier1-6 - Commit messages: - flatten-cardgen Changes: https:/

Re: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

2021-10-19 Thread Albert Mingkun Yang
On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. Marked as reviewed by ayang (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5697

Re: RFR: 8275035: Clean up worker thread infrastructure

2021-10-13 Thread Albert Mingkun Yang
On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to > remove abstractions we no longer need (after CMS was removed, MutexDispatcher > was removed, Parallel is now using WorkGang, etc) and adjusting names as > follows:

Integrated: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer

2021-05-25 Thread Albert Mingkun Yang
On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 > (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in > various counter names. This pull request has now been integrated.

Re: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer

2021-05-25 Thread Albert Mingkun Yang
On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 > (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in > various counter names. Thanks for the review. -

RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer

2021-05-21 Thread Albert Mingkun Yang
Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. - Commit messages: - alias map - second - first Changes: https://git.openjdk.java.net/jdk/pull/4146/files Webrev: https

Re: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3]

2021-05-19 Thread Albert Mingkun Yang
On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and >> `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one > additional

Integrated: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set

2021-05-19 Thread Albert Mingkun Yang
On Wed, 28 Apr 2021 09:23:31 GMT, Albert Mingkun Yang wrote: > It has some cascading effect; two performance variables, `fastWaste` and > `maxFastWaste`, can be removed also. This pull request has now been integrated. Changeset: 99fcc410 Author:Albert Mingkun Yang URL:

Re: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3]

2021-04-29 Thread Albert Mingkun Yang
On Thu, 29 Apr 2021 08:46:57 GMT, Per Liden wrote: > Maybe this could be a follow up refinement? Sure, will do so after this PR. - PR: https://git.openjdk.java.net/jdk/pull/3756

Re: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3]

2021-04-29 Thread Albert Mingkun Yang
> It has some cascading effect; two performance variables, `fastWaste` and > `maxFastWaste`, can be removed also. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review - Changes: - all:

Re: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v2]

2021-04-28 Thread Albert Mingkun Yang
> It has some cascading effect; two performance variables, `fastWaste` and > `maxFastWaste`, can be removed also. Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - merge -

RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set

2021-04-28 Thread Albert Mingkun Yang
It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. - Commit messages: - refill Changes: https://git.openjdk.java.net/jdk/pull/3756/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=00 Issue: https://

Re: RFR: 8265136: ZGC: Expose GarbageCollectorMXBeans for both pauses and cycles

2021-04-18 Thread Albert Mingkun Yang
On Wed, 14 Apr 2021 07:13:50 GMT, Per Liden wrote: > JDK-8240679 introduced a change where the information exposed via the > GarbageCollectorMXBean went from being related to the GC pauses to instead be > related to the GC cycles. This helped provide more accurate heap usage > information. How

Re: RFR: 8256181: Remove Allocation of old generation on alternate memory devices functionality

2020-11-11 Thread Albert Mingkun Yang
On Wed, 11 Nov 2020 11:11:25 GMT, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change that removes the "Allocation of old > generation of Java heap on alternate memory devices" functionality introduced > with JDK 12 with > [JDK-8202286](https://bugs.openjdk.java.net/browse

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

2020-11-03 Thread Albert Mingkun Yang
On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> ta

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-28 Thread Albert Mingkun Yang
On Mon, 28 Sep 2020 11:54:17 GMT, Erik Österlund wrote: >> Thank you for the comments and diagrams; they make the code much more >> digestible. From that diagram, I get the >> impression that the watermark is associated with stack pointer, so it should >> be 1:1 relation, but `class Thread` >>

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-24 Thread Albert Mingkun Yang
On Thu, 24 Sep 2020 15:49:36 GMT, Erik Österlund wrote: >> To be clear, my comments about boolean parameters to vframeStream/RegMap can >> be addressed in a follow up RFE. That >> would be better. > >> To be clear, my comments about boolean parameters to vframeStream/RegMap can >> be addressed

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3]

2020-09-23 Thread Albert Mingkun Yang
On Wed, 23 Sep 2020 14:27:55 GMT, Stefan Karlsson wrote: >> Erik Österlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Review: SteafanK CR 2 > > Marked as reviewed by stefank (Reviewer). Given names like `StackWatermarkSet::lowest_w