Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]

On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the

Re: RFR: 8283710: JVMTI: Use BitSet for object marking [v4]

On Thu, 7 Apr 2022 15:11:54 GMT, Roman Kennke wrote: > A general thought, maybe for a future RFE: > >We now have BitMap and BitSet, which do almost the same thing. Instead of >having a new class BitSet, whose job is to be sparse, we could give BitMap the >ability to be sparse. We'd save code, r

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

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. > > Test: tier

Re: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent

On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote: > 8277413: Remove unused local variables in jdk.hotspot.agent Lgtm. - Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6329

Re: RFR: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64

On Wed, 17 Nov 2021 20:43:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. Lgtm and trivial - Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6438

Re: Integrated: 8275517: Off-by-one error in allocation

On Tue, 19 Oct 2021 15:31:39 GMT, Markus Grönlund wrote: > Greetings (again), > > The quick fix for > [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an > off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus Lgtm. Fingers cros

Re: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on > linux-all and windows-all. Marked as reviewed by tschatzl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5657

Re: RFR: 8273482: Remove "foreground work" concept from WorkGang

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden wrote: > JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a > special case for use by the HeapDumper. I propose that we remove this code, > since this special use case can be solved without the need for the concept of > "foregro

Re: RFR: 8271396: Spelling errors

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg wrote: > This PR fixes the following spelling errors: > > choosen -> chosen > commad -> command > hiearchy -> hierarchy > leagacy -> legacy > minium -> minimum > subsytem -> subsystem > unamed -> unnamed Lgtm. - Marke

Integrated: 8271043: Rename G1CollectedHeap::g1mm()

On Wed, 21 Jul 2021 14:12:21 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that renames the somewhat cryptic name > `g1mm` with `monitoring_support` which sounds much better to me. > Feel free to suggest a better name or if you think it's

Re: RFR: 8271043: Rename G1CollectedHeap::g1mm()

On Wed, 21 Jul 2021 19:18:01 GMT, Kim Barrett wrote: >> Hi all, >> >> can I have reviews for this change that renames the somewhat cryptic name >> `g1mm` with `monitoring_support` which sounds much better to me. >> Feel free to suggest a better name or if you think it's not worth I can also

Re: RFR: 8270814: ProblemList the failing serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests

On Fri, 16 Jul 2021 06:02:05 GMT, David Holmes wrote: > Two tests have started failing regularly in our CI testing, and also in GHA, > so I'm ProblemListing them until the issue can be resolved. > > Thanks, > David Marked as reviewed by tschatzl (Reviewer). - PR: https://git.open

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

On Wed, 28 Apr 2021 09:41:14 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 with a new target base due > to a merge or a rebase. The pull req

Re: RFR: 8264166: OopStorage should support specifying MEMFLAGS for allocations

On Thu, 25 Mar 2021 07:27:58 GMT, Kim Barrett wrote: > Please review this change to OopStorage to allow the MEMFLAGS value for > associated allocations to be specified when the storage object is > constructed. This allows a subsystem that needs an OopStorage object to > associate its allocati

Re: RFR: 8264050: Remove unused field VM_HeapWalkOperation::_collecting_heap_roots

On Tue, 23 Mar 2021 15:06:02 GMT, Aleksey Shipilev wrote: > SonarCloud reports field `_collecting_heap_roots` is not initialized after > constructor ends. In fact, that field is not used anywhere. It was like that > since the initial load. We can trivially remove it. Lgtm and trivial. ---

Re: RFR: 8259778: Merge MutableSpace and ImmutableSpace

On Thu, 28 Jan 2021 09:01:44 GMT, Thomas Schatzl wrote: >> Please review this change which merges ImmutableSpace into MutableSpace, >> eliminating the former. There were no interesting uses of ImmutableSpace, >> other than as the base class for MutableSpace. The name Immutab

Re: RFR: 8259778: Merge MutableSpace and ImmutableSpace

On Thu, 28 Jan 2021 05:13:57 GMT, David Holmes wrote: >> Please review this change which merges ImmutableSpace into MutableSpace, >> eliminating the former. There were no interesting uses of ImmutableSpace, >> other than as the base class for MutableSpace. The name ImmutableSpace is >> kind of

Re: RFR: 8259778: Merge MutableSpace and ImmutableSpace

On Wed, 27 Jan 2021 23:06:41 GMT, Kim Barrett wrote: > Please review this change which merges ImmutableSpace into MutableSpace, > eliminating the former. There were no interesting uses of ImmutableSpace, > other than as the base class for MutableSpace. The name ImmutableSpace is > kind of a mis

Re: RFR: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB [v3]

On Fri, 22 Jan 2021 10:43:12 GMT, Yasumasa Suenaga wrote: >> G1 heap summary (G1 Heap, summaries for each spaces) is shown on console >> even though I chosen "Heap Parameters" menu on HSDB. It should be shown on >> "Heap Parameters" window on HSDB. > > Yasumasa Suenaga has updated the pull requ

Re: RFR: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB [v2]

On Fri, 22 Jan 2021 06:51:59 GMT, Yasumasa Suenaga wrote: >> G1 heap summary (G1 Heap, summaries for each spaces) is shown on console >> even though I chosen "Heap Parameters" menu on HSDB. It should be shown on >> "Heap Parameters" window on HSDB. > > Yasumasa Suenaga has updated the pull requ

Integrated: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions

On Wed, 11 Nov 2020 11:39:59 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that changes the way how archive regions > are managed in general and specifically by the G1 collector, fixing the > crashes caused by adding the module graph into the arc

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v4]

On Tue, 17 Nov 2020 14:52:35 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - sjohanss review >> - Remove code that "activates" dormant objects as now

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v5]

y empty: we do want to profit from the sharing > across VMs as much as possible. > > Testing: tier1-5, one or two 6-8 runs > > The appcds changes were done by @iklam. These changes are described in this > document: > https://wiki.openjdk.java.net/display/HotSpot/CDS+Archiv

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v3]

On Tue, 17 Nov 2020 10:16:28 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' of https://git.openjdk.

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v4]

y empty: we do want to profit from the sharing > across VMs as much as possible. > > Testing: tier1-5, one or two 6-8 runs > > The appcds changes were done by @iklam. These changes are described in this > document: > https://wiki.openjdk.java.net/display/HotSpot/CDS+Archiv

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v3]

On Mon, 16 Nov 2020 09:34:51 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' of https://git.openjdk.java.ne

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v3]

y empty: we do want to profit from the sharing > across VMs as much as possible. > > Testing: tier1-5, one or two 6-8 runs > > The appcds changes were done by @iklam. These changes are described in this > document: > https://wiki.openjdk.java.net/display/HotSpot/CDS+Archiv

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions [v2]

y empty: we do want to profit from the sharing > across VMs as much as possible. > > Testing: tier1-5, one or two 6-8 runs > > The appcds changes were done by @iklam. These changes are described in this > document: > https://wiki.openjdk.java.net/display/HotSpot/CDS+Archiv

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

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](h

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

On Wed, 11 Nov 2020 15:19:05 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> ayang review > > A general comment for future PRs: I think it's best to

Re: RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions

On Wed, 11 Nov 2020 11:39:59 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that changes the way how archive regions > are managed in general and specifically by the G1 collector, fixing the > crashes caused by adding the module graph into the arc

RFR: 8253081: G1 fails on stale objects in archived module graph in Open Archive regions

Hi all, can I have reviews for this change that changes the way how archive regions are managed in general and specifically by the G1 collector, fixing the crashes caused by adding the module graph into the archive in [JDK-8244778](https://bugs.openjdk.java.net/browse/JDK-8244778)? Previousl

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

On Wed, 11 Nov 2020 15:09:44 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> ayang review > > test/hotspot/jtreg/TEST.ROOT line 78: > >> 76:

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

e no > additional procedural issues to take. > > I tried to remove all but a few minor cleanups that I thought useful, but of > course this is very subjective. > > Testing: hs-tier1-5 Thomas Schatzl has updated the pull request incrementally with one additional commit since the

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

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/JDK-8202286) due to being - not used by anyone - not maintained by a

Re: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing

On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It > later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load > barrier to that handle and self-heals it in

Re: RFR: 8253815: Remove unused HeapRegionManager::_num_committed from SA

On Tue, 29 Sep 2020 18:29:57 GMT, Stefan Johansson wrote: > While doing some refactoring I wanted to move > HeapRegionManager::_num_committed and realized that I needed to update > the SA. After some looking around it turns out that it is unused and I can > remove the numCommittedField from the

Re: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints

Hi Dan and Serguei, thanks for your reviews. On 22.07.20 19:04, Daniel D. Daugherty wrote: jdk15: http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full) src/hotspot/share/prims/jvmtiEnvBase.cpp     old L1029:   ResourceMark rm;     It's not clear (to me anyway) why

Re: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints

Hi, On 22.07.20 02:42, David Holmes wrote: Hi Thomas, I've looked at the incremental update and I am happy with that. In the response to Serguei's review there were some comment updates and new webrevs. I also, prompted by you mentioning it, took a deeper look at the biased-locking code

Re: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints

Hi Serguei, thanks for your review. On 22.07.20 04:13, serguei.spit...@oracle.com wrote: Hi Thomas, The fix looks okay to me. The 15 fix is identical to 16. no :) It is very subtle. As mentioned, in jvmtiEnvBase.cpp in the original code, in jdk15 we had: line 1029: ResourceMark

Re: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints

Hi Coleen and David, thanks for your reviews. On 21.07.20 03:29, David Holmes wrote: Hi Thomas, On 21/07/2020 12:49 am, Thomas Schatzl wrote: Forwarding to hotspot-dev where it belongs after wrongly sending to hotspot-gc-dev. This touches serviceability code as well so cc'ing for

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (hotspot)

Hi, On 07.05.20 07:35, Mikael Vidstedt wrote: New webrev here: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/hotspot/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/hotspot.incr/open/webrev/ Remaining items: * File follow-up to

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (hotspot)

Hi, On 04.05.20 10:28, Stefan Karlsson wrote: Hi Mikael, On 2020-05-04 07:12, Mikael Vidstedt wrote: Please review this change which implements part of JEP 381: JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/hotspot

Re: RFR 8227178: Backout of 8215523

Hi, On Wed, 2019-07-03 at 07:24 -0700, Poonam Parhar wrote: > Hello, > > Please review the changeset that reverses the changes done with > JDK-8215523 . > > JDK-8227178 : > Backout > of 8215523

Re: RFR 8215523: jstat reports incorrect values for OU for CMS GC

Hi, On Tue, 2019-07-02 at 10:10 +0200, Aleksey Shipilev wrote: > Hi, > > On 6/21/19 10:30 PM, Poonam Parhar wrote: > > On 6/21/19 12:21 PM, Poonam Parhar wrote: > > > Bug 8215523 : > > > jstat reports incorrect values for > > > OU for CMS GC > >

Re: RFR 8215523: jstat reports incorrect values for OU for CMS GC

Hi, On Fri, 2019-06-28 at 07:19 -0700, Poonam Parhar wrote: > Hello, > > Thomas Schatzl pointed out that the recalculate_used_stable() call > in collect_in_background() may not be necessary. Testing the changes > after removing that call confirmed that. Here's the up

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

Hi, On Thu, 2018-11-29 at 16:07 +0100, Per Liden wrote: > There's no support for SA heap walking when using ZGC. Hence the > tests > for this should not execute when ZGC is enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214484 > Webrev: http://cr.openjdk.java.net/~pliden/8214484/web

Re: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Hi, On Wed, 2018-10-24 at 11:57 +0200, Thomas Schatzl wrote: > Hi again, > > On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote: > > Hi Paul, > > > > sorry for the long wait. > > > > On Mon, 2018-10-08 at 23:49 +, Hohensee, Paul wrote: > >

Re: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Hi again, On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote: > Hi Paul, > > sorry for the long wait. > > On Mon, 2018-10-08 at 23:49 +, Hohensee, Paul wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 > > CSR: https://bugs.openjdk.

Re: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Hi Paul, sorry for the long wait. On Mon, 2018-10-08 at 23:49 +, Hohensee, Paul wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 > Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.02/ Note that I reviewed the lates

Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

Hi Paul, On Fri, 2018-10-12 at 00:03 +, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The

Re: RFR(L): 8196989: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

Hi Paul, On Thu, 2018-08-02 at 18:14 +, Hohensee, Paul wrote: > Inline. > > On 8/1/18, 12:03 PM, "Thomas Schatzl" > wrote: > > Hi, > > On Mon, 2018-07-30 at 19:18 +, Hohensee, Paul wrote: > > At JVMLS, so can't look in de

Re: RFR(L): 8196989: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

d. I was not soliciting reviews yet, but thanks anyway :) I will take these into consideration in the proper review. Thanks, Thomas > > Thanks, > > Paul > > On 7/30/18, 6:04 AM, "Thomas Schatzl" > wrote: > > Hi Paul, > > did some

Re: RFR(L): 8196989: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

Hi Paul, did some prototyping and wanted to show you the results and get your input: On Thu, 2018-07-26 at 16:06 +0200, Thomas Schatzl wrote: > [...] > Could we work together on first refactoring the code before adding > new > kinds of spaces to the MXBeans? > > Looking

Re: RFR(L): 8196989: Revamp G1 JMX MemoryPoolMXBean, GarbageCollectorMXBean, and jstat counter definitions

Hi Paul, Erik may not have time in the next few months to review such a large change. But it would also be better to do the changes in steps for other reviewers. Also see below. On Mon, 2018-07-23 at 21:33 +, Hohensee, Paul wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/b

Re: committed > max in MemoryMXBean#getHeapMemoryUsage()

On Fri, 2018-07-13 at 10:30 +0200, Daniel Mitterdorfer wrote: > Hi Erik, > > > > Do you any kind of GC logging from the test run where you > > encountered the bug? > > Unfortunately, we don't have GC logging enabled by default in our > test suite so the exception trace is all I got. I am now repe

Re: [URGENT] RFR: 8205096: Add missing files for 8203394

Hi, On Fri, 2018-06-15 at 19:23 +1000, David Holmes wrote: > Ship it! +1 Thomas

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi, On Mon, 2018-05-14 at 13:02 -0700, JC Beyler wrote: > Hi Robbin and all, > > Thank you for your continuous help! > > Done then! Here is the new webrev: > http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.20/ > > and the incremental is: > http://cr.openjdk.java.net/~jcbeyler/8171119/he

Re: PING: RFR: JDK-8153333: [REDO] STW phases at Concurrent GC should count in PerfCounter

Hi Yasumasa, On Wed, 2018-03-07 at 21:18 +0900, Yasumasa Suenaga wrote: > PING: Could you review it? > >http://cr.openjdk.java.net/~ysuenaga/JDK-815/webrev.08/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-815 > CSR: https://bugs.openjdk.java.net/browse/JDK-8196862 > > This chan

Re: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion

Hi, On Wed, 2018-01-31 at 09:49 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > > > looks good to me - however there is another (pre-existing) bug: > > > the > > > shift in that code should be a logical shift, not an arithmetic > > > shift. > > > > > > I.e. ">>" instead of ">>>". > > > > > >

Re: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion

Hi all, On Tue, 2018-01-30 at 11:06 +0100, Thomas Schatzl wrote: > Hi, > > On Tue, 2018-01-30 at 07:00 +1000, David Holmes wrote: > > Added in hotspot-gc-dev. Although this is in the SA it is about the > > SA interaction with G1 and so likely needs someone familiar wit

Re: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion

Hi, On Tue, 2018-01-30 at 07:00 +1000, David Holmes wrote: > Added in hotspot-gc-dev. Although this is in the SA it is about the > SA interaction with G1 and so likely needs someone familiar with G1 > to review it. > > David > > On 28/01/2018 10:41 PM, Yasumasa Suenaga wrote: > > PING: Could you

Re: Low-Overhead Heap Profiling

On Tue, 2017-11-21 at 13:50 -0800, JC Beyler wrote: > Hi all, > > I have a new webrev here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ > > With the incremental one here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ > > I think I did most items from Thomans and Robbi

Re: Low-Overhead Heap Profiling

Hi JC, sorry for the long wait. On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > Dear all, > > Here is the next webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > Incremental since the rebase: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > (I'm still

Re: Low-Overhead Heap Profiling

Hi Jc, sorry for taking a bit long to respond ;) On Mon, 2017-10-23 at 08:27 -0700, JC Beyler wrote: > Dear all, > > Small update this week with this new webrev: >   - http://cr.openjdk.java.net/~rasbold/8171119/webrev.13/ >   - Incremental is here: http://cr.openjdk.java.net/~rasbold/8171

Re: Low-Overhead Heap Profiling

Hi,   here's a first cut of my thoughts of the latest changes. The compilation problems (at the bottom) prevented me to dig further into it a bit. Please strongly consider providing incremental webrevs, it takes some effort to find changes otherwise. On Tue, 2017-06-27 at 15:04 -0700, JC Beyler

Re: Low-Overhead Heap Profiling

Hi, On Wed, 2017-06-28 at 09:51 +0200, Robbin Ehn wrote: > Hi, > > On 06/21/2017 10:45 PM, JC Beyler wrote: > > > > Hi all, > > > > First off: Thanks again to Robbin and Thomas for their reviews :) > > > > Next, I've uploaded a new webrev: > > http://cr.openjdk.java.net/~rasbold/8171119/webrev

Re: Low-Overhead Heap Profiling

o I am fine with not adding another style (like kMaxStackDepth with the "k" in front with some unknown meaning) is fine. (Chances are you will find that style somewhere used anyway too, apologies if so :/) > PS: I've also inlined my answers to Thomas below: > > On Tue, Jun 13,

Re: Low-Overhead Heap Profiling

Hi all, On Mon, 2017-06-12 at 11:11 -0700, JC Beyler wrote: > Dear all, > > I've continued working on this and have done the following webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.05/ [...] > Things I still need to do: >    - Have to fix that TLAB case for the FastTLABRefill >  

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Hi, On Mon, 2017-02-06 at 01:17 -0500, Kim Barrett wrote: > > > > On Feb 6, 2017, at 1:10 AM, sangheon > > wrote: > > > > Hi Kim and Thomas, > > > > Here's webrev.2 with Thomas' comment version. > > http://cr.openjdk.java.net/~sangheki/8173013/webrev.2 > > > > > > 1538 #i

Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

Hi Sangheon, On Thu, 2017-02-02 at 20:00 -0800, sangheon wrote: > Hi David, > > Thank you for looking at this! > > On 02/02/2017 05:20 PM, David Holmes wrote: > > > > Hi Sangheon, > > > > On 3/02/2017 5:11 AM, sangheon wrote: > > > > > > Hi all, > > > > > > Could I have some reviews for this

Re: RFR: JDK-8151674: STW phases at Concurrent GC should count in PerfCounter

Hi, On Fri, 2016-03-18 at 12:45 -0700, Jon Masamitsu wrote: > > On 3/18/2016 7:14 AM, Yasumasa Suenaga wrote: > > Hi, > > > > > I added a comment to JBS about G1 initial mark. > > > I will upload new webrev after discussing for it. > > > > We discussed about it on JBS, and we decided not to cou

Re: (S) RFR: 8150506: Remove unused locks

Hi David, On Wed, 2016-02-24 at 17:03 +1000, David Holmes wrote: > I stumbled across the fact that the following locks are no longer > being > used in the VM: > > Runtime: > - Interrupt_lock > - ProfileVM_lock > - ObjAllocPost_lock > > Serviceability: > -JvmtiPendingEvent_lock > > GC:

Re: RFR: JDK-8066441 - Add PLAB trace event

On Tue, 2014-12-02 at 10:50 -0800, Staffan Friberg wrote: > Hi, > > As noted in the original thread [1] about this event we split up the > commit in 4 different steps. This is the first step that only adds the > event and methods to send them, but the usage will be added separately > for the 3

Re: RFR: JDK-8055845 - Add trace event for promoted objects

Hi, On Mon, 2014-09-15 at 14:44 -0700, Staffan Friberg wrote: > Hi, > > The latter messes up the method signatures, and in any case (when using > > option one or three) this code is slightly racy as we might report too > > many events as another thread might have claimed the object. (Parallel > >

Re: RFR: JDK-8055845 - Add trace event for promoted objects

Hi, On Mon, 2014-09-15 at 14:32 -0700, Staffan Friberg wrote: > Hi Thomas, > > I feel that this is outside of the scope of this event and change. It is > probably a good thing to track to understand if an application wastes > more memory than wanted. > Perhaps open an RFE for a separate event a

Re: RFR: JDK-8055845 - Add trace event for promoted objects

allocation regions during GC. Thanks, Thomas On Mon, 2014-09-15 at 14:57 +0200, Thomas Schatzl wrote: > Hi, > > On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: > > Hi, > > > > I have uploaded a new webrev here, > > cr.openjdk.java.net/~sfriberg/80558

Re: RFR: JDK-8055845 - Add trace event for promoted objects

Hi, On Fri, 2014-09-05 at 15:20 -0700, Staffan Friberg wrote: > Hi, > > I have uploaded a new webrev here, > cr.openjdk.java.net/~sfriberg/8055845/webrev.03 > > It contains several changes > > - Split event into two events (PromoteObjectInNewPLAB, > PromoteObjectOutsidePLAB) > - Moved e

Re: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq"

Hi, On Wed, 2013-10-16 at 10:48 +0200, Staffan Larsen wrote: > Looks good! > Thanks Staffan and Mikael for the reviews! Thomas

Re: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq"

Hi, On Tue, 2013-10-15 at 15:04 +0200, Mikael Gerdin wrote: > Thomas, > > On Tuesday 15 October 2013 12.53.25 Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following change? It updates the SA agent > > that got out of date after the

RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq"

Hi all, can I have reviews for the following change? It updates the SA agent that got out of date after the changes for JDK-7163191 where the HeapRegionSeq class has been refactored. The changes mirror the changes in the C++ code of that revision, adding a G1HeapRegionTable java class, and the

Re: Fwd: Re: Fix to 8025925

Hi, On Mon, 2013-10-14 at 17:11 +0400, aleksey.timof...@oracle.com wrote: > Hello, Thomas. Did you see this simple diff? no :) I am not on servicability-dev. Thanks for making me aware of this. > Looks good to me, but I'd like Thomas' opinion as well. > > Thanks, > /Staffan > > On 9 okt 201

Re: RFR: 8012902: remove use of global operator new - take 2

Hi, On Thu, 2013-04-25 at 23:48 -0700, Yumin Qi wrote: > HI, all > >This bug is filed after this bug >8010992: Remove calls to global ::operator new[] and new >was anti-delta'ed due to testing failure on JVMTI. Now it takes both. > >http://cr.openjdk.java.net/~minqi/8012902/webre