From kim.barrett at oracle.com Fri Feb 1 06:25:18 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 01:25:18 -0500 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions Message-ID: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> Please review this renaming of some G1-specific classes and associated files to follow our usual naming conventions. Renamed files: dirtyCardQueue.[ch]pp => g1DirtyCardQueue.[ch]pp Added "G1" prefix to class names CardTableEntryClosure, DirtyCardQueue, and DirtyCardQueueSet. Also did a little bit of #include list and forward declaration list maintenance related to these changes. CR: https://bugs.openjdk.java.net/browse/JDK-8218089 Webrev: http://cr.openjdk.java.net/~kbarrett/8218089/open.00/ Testing: mach5 tier1-3 From kim.barrett at oracle.com Fri Feb 1 06:31:38 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 01:31:38 -0500 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions In-Reply-To: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> References: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> Message-ID: <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> > On Feb 1, 2019, at 1:25 AM, Kim Barrett wrote: > > Please review this renaming of some G1-specific classes and associated > files to follow our usual naming conventions. > > Renamed files: > dirtyCardQueue.[ch]pp => g1DirtyCardQueue.[ch]pp > > Added "G1" prefix to class names CardTableEntryClosure, > DirtyCardQueue, and DirtyCardQueueSet. > > Also did a little bit of #include list and forward declaration list > maintenance related to these changes. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218089 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8218089/open.00/ > > Testing: > mach5 tier1-3 I forgot to mention that these changes touch a couple of S390 and PPC files in fairly obvious ways. I haven?t tested those changes; they look trivial, and hopefully I didn?t botch them. From thomas.stuefe at gmail.com Fri Feb 1 09:25:59 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 1 Feb 2019 10:25:59 +0100 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: <59e0668c-11f5-7b3f-d4a4-da83a9a609ab@gmail.com> References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> <45386bc559484f78ec07e16b63a51eb38240fe57.camel@oracle.com> <59e0668c-11f5-7b3f-d4a4-da83a9a609ab@gmail.com> Message-ID: Hi Yasumasa, looks good to me as well. I like the added comment but would suggest making it more precise: "Try to increase metaspace size by v bytes" reads like it does anything of substance like allocating memory etc, but it does nothing but increase the limit variable. How about this: "Try to increase the _capacity_until_GC limit counter by v bytes. Returns true if it succeeded. It may fail if either another thread concurrently increased the limit or the new limit would be larger than MaxMetaspaceSize." Maybe also indicate that can_retry is only defined if function returns false, new_cap_until_GC and old_cap_until_GC only if return value is true: - // Optionally returns new and old metaspace capacity in + // On success, optionally returns new and old metaspace capacity in - // Optionally sets can_retry to indicate whether if there is actually + // On error, optionally sets can_retry to indicate whether if there is actually If you change the comment, I am fine with the patch as it is and do not need another webrev. Thank you, Thomas On Thu, Jan 31, 2019 at 3:00 PM Yasumasa Suenaga wrote: > Thanks Thomas! > > I will add the comment to inc_capacity_until_GC() declaration. > > I'm waiting for second reviewer. > > > Yasumasa > > > On 2019/01/31 18:16, Thomas Schatzl wrote: > > Hi Yasumasa, > > > > On Thu, 2019-01-31 at 14:09 +0900, Yasumasa Suenaga wrote: > >> Hi Thomas, > >> > >> I uploaded new webrev: > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.03/ > >> > >> I agree with you that inc_capacity_until_GC() returns additional > >> bool value whether new HWM is exceeded MaxMetaspaceSize. > >> > >> I added `can_retry` to argument of inc_capacity_until_GC(). > >> It will be set to false if `new_value` exceeds MaxMetaspaceSize. > >> Then inc_capacity_until_GC() returns false, but it is not break > >> assert() in compute_new_size() because inc_capacity_until_GC() > >> is called with `expand_bytes` which is limited by MaxMetaspaceSize. > >> (It is ensured by this change) > >> > >> This change has passed vmTestbase/metaspace, gc/metaspace, and > >> submit repo tests. > > > > looks good to me. Can you add some documentation to the declaration > > of inc_capacity_until_GC() like: > > > > // Try to increase metaspace size by v bytes. Returns true if > > // succeeded, false if not due to competing threads trying. > > // Optionally returns new and old metaspace capacity in > > // new_cap_until_GC and old_cap_until_GC respectively. > > // Optionally sets can_retry to indicate whether if there is actually > > // enough space remaining to satisfy the request. > > > > No need for a re-review for that (or something similar potentially > > better worded description. > > > > Thanks, > > Thomas > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Feb 1 09:34:23 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Feb 2019 18:34:23 +0900 Subject: PING: RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize In-Reply-To: References: <5bde0aee-ddb0-4638-8142-cbb7d9a8a5a1@nttcom.co.jp> <421438e3-a487-b61e-a0b8-611761c38b34@nttcom.co.jp> <015da8fc-30be-3337-9858-ba737db5acf9@nttcom.co.jp> <4a8d71eebcefa8e658252d8043baf599bf28c699.camel@oracle.com> <6f2514238398826ff7420ba3977727dfb2057246.camel@oracle.com> <3bcd2ecc-0c22-442d-d1a7-79463a9d038c@gmail.com> <4b5b89f55464c3d6a9fb62c123d11ede2ca36036.camel@oracle.com> <5207430f-e39a-6260-3a13-dfb71a1a7bc9@gmail.com> <57da999f81831e8321529da05b818ff420f292d9.camel@oracle.com> <45386bc559484f78ec07e16b63a51eb38240fe57.camel@oracle.com> <59e0668c-11f5-7b3f-d4a4-da83a9a609ab@gmail.com> Message-ID: Thanks Thomas! I will change the comment. Yasumasa 2019?2?1?(?) 18:26?Thomas St?fe ???thomas.stuefe at gmail.com???????: > Hi Yasumasa, > > looks good to me as well. > > I like the added comment but would suggest making it more precise: "Try to > increase metaspace size by v bytes" reads like it does anything of > substance like allocating memory etc, but it does nothing but increase the > limit variable. How about this: > > "Try to increase the _capacity_until_GC limit counter by v bytes. > Returns true if it succeeded. It may fail if either another thread > concurrently increased the limit or the new limit would be larger than > MaxMetaspaceSize." > > Maybe also indicate that can_retry is only defined if function returns > false, new_cap_until_GC and old_cap_until_GC only if return value is true: > > - // Optionally returns new and old metaspace capacity in > + // On success, optionally returns new and old metaspace capacity in > > - // Optionally sets can_retry to indicate whether if there is actually > + // On error, optionally sets can_retry to indicate whether if there is > actually > > If you change the comment, I am fine with the patch as it is and do not > need another webrev. > > Thank you, Thomas > > > > > > > On Thu, Jan 31, 2019 at 3:00 PM Yasumasa Suenaga > wrote: > >> Thanks Thomas! >> >> I will add the comment to inc_capacity_until_GC() declaration. >> >> I'm waiting for second reviewer. >> >> >> Yasumasa >> >> >> On 2019/01/31 18:16, Thomas Schatzl wrote: >> > Hi Yasumasa, >> > >> > On Thu, 2019-01-31 at 14:09 +0900, Yasumasa Suenaga wrote: >> >> Hi Thomas, >> >> >> >> I uploaded new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.03/ >> >> >> >> I agree with you that inc_capacity_until_GC() returns additional >> >> bool value whether new HWM is exceeded MaxMetaspaceSize. >> >> >> >> I added `can_retry` to argument of inc_capacity_until_GC(). >> >> It will be set to false if `new_value` exceeds MaxMetaspaceSize. >> >> Then inc_capacity_until_GC() returns false, but it is not break >> >> assert() in compute_new_size() because inc_capacity_until_GC() >> >> is called with `expand_bytes` which is limited by MaxMetaspaceSize. >> >> (It is ensured by this change) >> >> >> >> This change has passed vmTestbase/metaspace, gc/metaspace, and >> >> submit repo tests. >> > >> > looks good to me. Can you add some documentation to the declaration >> > of inc_capacity_until_GC() like: >> > >> > // Try to increase metaspace size by v bytes. Returns true if >> > // succeeded, false if not due to competing threads trying. >> > // Optionally returns new and old metaspace capacity in >> > // new_cap_until_GC and old_cap_until_GC respectively. >> > // Optionally sets can_retry to indicate whether if there is actually >> > // enough space remaining to satisfy the request. >> > >> > No need for a re-review for that (or something similar potentially >> > better worded description. >> > >> > Thanks, >> > Thomas >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Feb 1 12:53:00 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 1 Feb 2019 13:53:00 +0100 Subject: Thoughts about improving the metaspace allocator Message-ID: Hi all, (not sure which mailing list is the best fit, I start with hs-gc. Please feel free to move it.) JEP "Dynamic Max Memory Limit" has the aim to increase elasticity of java heap memory consumption. I wonder whether the same would make sense for metaspace? Granted, we typically use way less memory for metaspace than for the heap, but there are quite a few corners where memory is wasted - mainly in situations where many classloaders come and go leaving metaspace chunks marooned in the VM. In particular, the following two areas waste the most memory: - metaspace memory in freelist (not owned by any loader) - metaspace wasted where chunks in use by loaders do not allocate anymore, so the memory is pinned to the loader. All this memory is wasted in the sense that though it could be reused in the future should new classes be loaded, this may never happen and the memory is still part of the VM process. -- How is metaspace currently returned to the OS: Memory for metaspace is allocated in 2MB sized mappings (VirtualSpaceNode) and kept in a chain. Chain grows if more memory is allocated. When a Loader requests metaspace, a chunk (Metachunk) is carved off the top VirtualSpaceNode and handed out. These Metachunks exist in various sizes between 1K and 64K in size. When a classloader dies, it returns all its Metachunks to the metaspace allocator, which puts them into a freelist for possible reuse by a future class loader. Should all chunks in a VirtualSpaceNode become free, the VirtualSpaceNode itself is removed from its chain and unmapped. This means memory is returned a bit arbitrarily: all chunks within a 2MB area must be freed, only then is the node unmapped. Whether or not this works highly depends on the fragmentation. A single classloader holding a 1K chunk in this node hostage will keep the whole 2MB node alive. In addition, this does not work at all for the compressed class space. There, we do not have a chain of mappings but just one large mapping, which never gets unmapped. So, memory for the compressed class space is never returned to the OS. ----- First idea: uncommit free meta chunks Metachunks are returned to the freelist and there they do no good, so one could theoretically uncommit them as long as they are not needed, no? While keeping the address range still intact? But the problem is that Metachunks are not guaranteed to span multiple pages, may often in fact be smaller than one page. Also the Metachunk header must not be compromised, so we cannot uncommit the first page of a metachunk since it contains its header. So, in reality we would only be able to uncommit the payload area of larger chunks (medium and humongous) which are 32K or larger. Fortunately all this has been greatly simplified - more out of accident - by "8198423: Improve metaspace chunk allocation": There, we made it so that chunks which are returned to the freelist are automatically fused with neighboring chunks to form larger chunks. Also, with that change we introduced the rule that all chunks must be aligned to their size, so e.g. 4K chunks are 4K aligned etc. This means that we have a natural tendency for free metachunks to form larger chunks, and that those are aligned nicely. That makes uncommitting their payload easy and rewarding. Here is a patch which does just that. The patch is very minimal: http://cr.openjdk.java.net/~stuefe/webrevs/autouncommit-metachunks/webrev.00/webrev/index.html To test whether this works, I wrote a small test which creates 1000 class loaders, each loading 10 classes, which uses up ~200M of metaspace. Then I started unloading them in a random fashion, until all are unloaded. The random unloading causes high fragmentation. In the stock hotspot, we can see that the released memory is kept in the freelist, but almost no memory is given back to the OS until almost to the end: Alive RSS(kb) freelist(kb) 1000 377780 28 900 378412 18428 800 375168 37012 700 375240 55412 600 375328 73996 500 375328 92028 400 375328 110428 300 372136 128758 200 372008 145110 100 357672 149357 That is not surprising, since the memory is highly fragmented and only at the last step a node was completely free and could be unmapped. With my patch, one sees RSS dipping way more early: Alive RSS(kb) freelist(kb) 1000 390464 18 900 380564 18418 800 366232 36818 700 351504 55218 600 326172 73618 500 310928 92570 400 296396 110418 300 280360 128748 200 264948 145110 100 245540 149357 The freelist content is identical, but it is now filled with chunks whose payload was uncommitted, therefore RSS starts going down. At the last step, with 100 loaded still alive, we have given about 100MB back to the system. Of course this random scenario benefits most from my patch. Savings are smaller when classloaders are released in a lifo fashion, because metaspace is more clustered and the chance of Metachunks neighboring with chunks of the same loaders is higher. (We may improve this patch by moving the headers out of the Metachunks alltogether, keeping chunk information separate from the payloads) (I did not look closely at the cost of commiting/uncommiting. One may have to do this a bit smarter than I did in this patch to avoid expensive commit/uncommit cycles, e.g. always leave a certain number of free chunks committed.) So, this may be a valid - more fluid and smooth - alternative way to give memory back to the OS than unmapping VirtualSpaceNode nodes. ----- Thinking further: do we then even need the virtual space list? IIUC the VirtualSpaceList exists for two reasons: 1) to make it possible to grow infinitely without having to deal an upper limit. 2) to make it possible to give freed memory back to the OS (1) one could argue this is a goal we never really reached. Most of our customers actually specify MaxMetaspaceSize to limit the metaspace. More importantly, we have to specify CompressedClassSpaceSize in any case, and that limits metaspace growth even if MaxMetaspaceSize is not specified. (2) would arguably be not needed anymore with my patch - especially if we moved the Metachunk headers somewhere else. So, instead of the virtual space list we could allocate the non-class metaspace portion as one contiguous region upfront, same as the class space, and then commit them as needed. We only have to sacrifice the notion of limitless expansion. Getting rid of VirtualSpaceList in favor of one large mapping would have the following advantages: - Simplicity. The metaspace coding has gotten quite complex over time and every bit we retire is nice for maintenance. - Fewer mappings: The virtual space list can get quite large and that shows up as a lot of memory mappings, at least on Linux. There is actually a limit to the number of mappings a process may have and we have hit this in the past with customers. These mappings also cause overhead in the linux kernel. - Waste at the VirtualSpaceNode level. Not large by any means but it still counts. ---------- Thinking even further: Do we still need the class/non-class dichotomy? (This is more of an actual question, I am really unsure about this) Lets say we get rid of the virtual space list and now have two large memory mappings side by side, the non-class and the class space. Why do we need two? We could theoretically combine them to just one area, which would be just "the metaspace" and contain both class and non-class data. This would have the following pros and cons: + Again, Simplicity. Getting rid of this dichotomy would really simplify the coding. Also easier to understand, explain to customers. Only one switch needed for sizing. + We would save quite a bit of wasted memory, especially with many small loaders which load many small chunks. Currently, each loader has to allocate at least two chunks, which effectively doubles the overhead. But I see some cons too: - For compressed class pointers to work, the total size of the class space must not exceed 3G. This limit would now apply to the combined size of class and non-class metadata. I do not know - do we ever exceed 3G total metaspace? - Increasing the size may make it less probable to fit into the lower 32gb address space and use zero based addressing for the compressed Klass* pointers. --- Thank you for your time. What do you think? Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Sat Feb 2 20:19:11 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 2 Feb 2019 21:19:11 +0100 Subject: Thoughts about improving the metaspace allocator In-Reply-To: References: Message-ID: Small correction, my first sentence refers to "JEP 346: Promptly Return Unused Committed Memory from G1", not "JEP Dynamic Max Memory Limit", but I hope the rest of my mail still made sense :) Cheers, Thomas On Fri, Feb 1, 2019 at 1:53 PM Thomas St?fe wrote: > Hi all, > > (not sure which mailing list is the best fit, I start with hs-gc. Please > feel free to move it.) > > JEP "Dynamic Max Memory Limit" has the aim to increase elasticity of java > heap memory consumption. I wonder whether the same would make sense for > metaspace? Granted, we typically use way less memory for metaspace than > for the heap, but there are quite a few corners where memory is wasted - > mainly in situations where many classloaders come and go leaving metaspace > chunks marooned in the VM. > > In particular, the following two areas waste the most memory: > - metaspace memory in freelist (not owned by any loader) > - metaspace wasted where chunks in use by loaders do not allocate anymore, > so the memory is pinned to the loader. > > All this memory is wasted in the sense that though it could be reused in > the future should new classes be loaded, this may never happen and the > memory is still part of the VM process. > > -- > > How is metaspace currently returned to the OS: > > Memory for metaspace is allocated in 2MB sized mappings (VirtualSpaceNode) > and kept in a chain. Chain grows if more memory is allocated. When a Loader > requests metaspace, a chunk (Metachunk) is carved off the top > VirtualSpaceNode and handed out. These Metachunks exist in various sizes > between 1K and 64K in size. > > When a classloader dies, it returns all its Metachunks to the metaspace > allocator, which puts them into a freelist for possible reuse by a future > class loader. Should all chunks in a VirtualSpaceNode become free, the > VirtualSpaceNode itself is removed from its chain and unmapped. > > This means memory is returned a bit arbitrarily: all chunks within a 2MB > area must be freed, only then is the node unmapped. Whether or not this > works highly depends on the fragmentation. A single classloader holding a > 1K chunk in this node hostage will keep the whole 2MB node alive. > > In addition, this does not work at all for the compressed class space. > There, we do not have a chain of mappings but just one large mapping, which > never gets unmapped. So, memory for the compressed class space is never > returned to the OS. > > ----- > > First idea: uncommit free meta chunks > > Metachunks are returned to the freelist and there they do no good, so one > could theoretically uncommit them as long as they are not needed, no? While > keeping the address range still intact? > > But the problem is that Metachunks are not guaranteed to span multiple > pages, may often in fact be smaller than one page. Also the Metachunk > header must not be compromised, so we cannot uncommit the first page of a > metachunk since it contains its header. So, in reality we would only be > able to uncommit the payload area of larger chunks (medium and humongous) > which are 32K or larger. > > Fortunately all this has been greatly simplified - more out of accident - > by "8198423: Improve metaspace chunk allocation": There, we made it so that > chunks which are returned to the freelist are automatically fused with > neighboring chunks to form larger chunks. Also, with that change we > introduced the rule that all chunks must be aligned to their size, so e.g. > 4K chunks are 4K aligned etc. > > This means that we have a natural tendency for free metachunks to form > larger chunks, and that those are aligned nicely. That makes uncommitting > their payload easy and rewarding. > > Here is a patch which does just that. The patch is very minimal: > > > http://cr.openjdk.java.net/~stuefe/webrevs/autouncommit-metachunks/webrev.00/webrev/index.html > > To test whether this works, I wrote a small test which creates 1000 class > loaders, each loading 10 classes, which uses up ~200M of metaspace. Then I > started unloading them in a random fashion, until all are unloaded. The > random unloading causes high fragmentation. > > In the stock hotspot, we can see that the released memory is kept in the > freelist, but almost no memory is given back to the OS until almost to the > end: > > Alive RSS(kb) freelist(kb) > 1000 377780 28 > 900 378412 18428 > 800 375168 37012 > 700 375240 55412 > 600 375328 73996 > 500 375328 92028 > 400 375328 110428 > 300 372136 128758 > 200 372008 145110 > 100 357672 149357 > > That is not surprising, since the memory is highly fragmented and only at > the last step a node was completely free and could be unmapped. > > With my patch, one sees RSS dipping way more early: > > Alive RSS(kb) freelist(kb) > 1000 390464 18 > 900 380564 18418 > 800 366232 36818 > 700 351504 55218 > 600 326172 73618 > 500 310928 92570 > 400 296396 110418 > 300 280360 128748 > 200 264948 145110 > 100 245540 149357 > > The freelist content is identical, but it is now filled with chunks whose > payload was uncommitted, therefore RSS starts going down. At the last step, > with 100 loaded still alive, we have given about 100MB back to the system. > > Of course this random scenario benefits most from my patch. Savings are > smaller when classloaders are released in a lifo fashion, because metaspace > is more clustered and the chance of Metachunks neighboring with chunks of > the same loaders is higher. > > (We may improve this patch by moving the headers out of the Metachunks > alltogether, keeping chunk information separate from the payloads) > > (I did not look closely at the cost of commiting/uncommiting. One may have > to do this a bit smarter than I did in this patch to avoid expensive > commit/uncommit cycles, e.g. always leave a certain number of free chunks > committed.) > > So, this may be a valid - more fluid and smooth - alternative way to give > memory back to the OS than unmapping VirtualSpaceNode nodes. > > ----- > > Thinking further: do we then even need the virtual space list? > > IIUC the VirtualSpaceList exists for two reasons: > > 1) to make it possible to grow infinitely without having to deal an upper > limit. > 2) to make it possible to give freed memory back to the OS > > (1) one could argue this is a goal we never really reached. Most of our > customers actually specify MaxMetaspaceSize to limit the metaspace. More > importantly, we have to specify CompressedClassSpaceSize in any case, and > that limits metaspace growth even if MaxMetaspaceSize is not specified. > (2) would arguably be not needed anymore with my patch - especially if we > moved the Metachunk headers somewhere else. > > So, instead of the virtual space list we could allocate the non-class > metaspace portion as one contiguous region upfront, same as the class > space, and then commit them as needed. We only have to sacrifice the notion > of limitless expansion. > > Getting rid of VirtualSpaceList in favor of one large mapping would have > the following advantages: > > - Simplicity. The metaspace coding has gotten quite complex over time and > every bit we retire is nice for maintenance. > - Fewer mappings: The virtual space list can get quite large and that > shows up as a lot of memory mappings, at least on Linux. There is actually > a limit to the number of mappings a process may have and we have hit this > in the past with customers. These mappings also cause overhead in the linux > kernel. > - Waste at the VirtualSpaceNode level. Not large by any means but it still > counts. > > ---------- > > Thinking even further: Do we still need the class/non-class dichotomy? > (This is more of an actual question, I am really unsure about this) > > Lets say we get rid of the virtual space list and now have two large > memory mappings side by side, the non-class and the class space. Why do we > need two? > > We could theoretically combine them to just one area, which would be just > "the metaspace" and contain both class and non-class data. > > This would have the following pros and cons: > > + Again, Simplicity. Getting rid of this dichotomy would really simplify > the coding. Also easier to understand, explain to customers. Only one > switch needed for sizing. > + We would save quite a bit of wasted memory, especially with many small > loaders which load many small chunks. Currently, each loader has to > allocate at least two chunks, which effectively doubles the overhead. > > But I see some cons too: > > - For compressed class pointers to work, the total size of the class space > must not exceed 3G. This limit would now apply to the combined size of > class and non-class metadata. I do not know - do we ever exceed 3G total > metaspace? > - Increasing the size may make it less probable to fit into the lower 32gb > address space and use zero based addressing for the compressed Klass* > pointers. > > --- > > Thank you for your time. What do you think? > > Kind Regards, Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Sun Feb 3 21:43:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sun, 03 Feb 2019 16:43:00 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> Message-ID: <1549230180.31327.172.camel@redhat.com> > > No sorry I didn't review it. Not at all familiar with TLAB or these > stats. Isn't this more a GC than runtime issue? > I think it is more on GC side, but JDK-8194084 was fixed under Runtime. Cc'd gc-dev. Thanks, -Zhengy > David > ----- > > > -Zhengyu > > > > > > > > > > Thanks, > > > David > > > ----- > > > > > > > > > > > Thanks, > > > > > > > > -Zhengyu > > > > > > > > > > > > > > > > > > David > > > > > ----- > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > > > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev. > > > > > > 00/ > > > > > > > > > > > > Test: > > > > > > hotspot_runtime, hotspot_serviceability, > > > > > > vmTestbase_nsk_monitoring, > > > > > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, > > > > > > vmTestbase_vm_jdwp > > > > > > on Linux x64 > > > > > > > > > > > > Eyeball output of jsnap > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -Zhengyu > > > > > > From chihiro.ito at oracle.com Mon Feb 4 17:12:31 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Tue, 5 Feb 2019 02:12:31 +0900 Subject: PING: Re: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> Message-ID: Hi Thomas and Per, Could you review this? webrev: http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ JBS: https://bugs.openjdk.java.net/browse/JDK-8214236 Regards, Chihiro On 2019/01/31 22:13, Chihiro Ito wrote: > Hi Thomas and Per, > > I renamed counter names as follows referencing jstat. Could you review > these? > > -XX:+UseSerialGC > sun.gc.collector.0.name="Serial young collection pauses" > sun.gc.collector.1.name="Serial full collection pauses" > > -XX:+UseParallelGC > sun.gc.collector.0.name="Parallel young collection pauses" > sun.gc.collector.1.name="Parallel full collection pauses" > > -XX:+UseParallelGC -XX:-UseParallelOldGC > sun.gc.collector.0.name="Parallel young collection pauses" > sun.gc.collector.1.name="Serial full collection pauses" > > -XX:+UseConcMarkSweepGC > sun.gc.collector.0.name="CMS young collection pauses" > sun.gc.collector.1.name="CMS full collection pauses" > sun.gc.collector.2.name="CMS concurrent cycle pauses" > > -XX:+UseG1GC > sun.gc.collector.0.name="G1 young collection pauses" > sun.gc.collector.1.name="G1 full collection pauses" > sun.gc.collector.2.name="G1 concurrent cycle pauses" > > -XX:+UnlockExperimentalVMOptions -XX:+UseZGC > sun.gc.collector.2.name="Z concurrent cycle pauses" > > > I uploaded webrev. I already have run the changes through test-tier1 > test sets and saw no sign of regression. > > webrev: > http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8214236 > > Regards, > Chihiro > > > > On 2019/01/16 23:49, Chihiro Ito wrote: >> Hi Thomas, >> >> I try to rename for all collections. >> >> Regards, >> Chihiro >> >> On 2019/01/16 22:41, Thomas Schatzl wrote: >>> Hi Chihiro, >>> >>> On Wed, 2019-01-16 at 00:30 +0900, Chihiro Ito wrote: >>>> Hi Thomas and Per, >>>> >>>> I fixed counter name in G1, CMS and Z. >>>> Could you review it ? >>>> >>>> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.01/ >>>> >>>> >>>> For your information, output of PerfCounter.print is following. >>>> >>>> G1GC: >>>> sun.gc.collector.0.name="G1 incremental collection pauses" >>>> sun.gc.collector.1.name="G1 full collection pauses" >>>> sun.gc.collector.2.name="G1 concurrent cycle pauses" >>>> >>>> CMS: >>>> sun.gc.collector.2.name="CMS concurrent cycle pauses" >>>> >>>> ZGC: >>>> sun.gc.collector.2.name="Z concurrent cycle pauses" >>> Fine with me - since we are there, maybe you are interested in >>> revisiting the names for the other CollectorCounters too? >>> >>> I found the following: >>> >>> Parallel GC: >>> >>> "PSScavenge" >>> "PSParallelCompact" >>> "PSMarkSweep" >>> >>> CMS: >>> >>> "CMS" >>> "MSC" >>> >>> Serial: >>> >>> "PCopy" (I have no idea what this is supposed to be; this is serial >>> young gc) >>> >>> We can skip them too if we can't find better names. >>> >>> Thanks, >>> Thomas >>> >>> >>> >> >> > From thomas.schatzl at oracle.com Mon Feb 4 17:17:58 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 04 Feb 2019 18:17:58 +0100 Subject: PING: Re: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> Message-ID: Hi Chihiro, On Tue, 2019-02-05 at 02:12 +0900, Chihiro Ito wrote: > Hi Thomas and Per, > > Could you review this? > > webrev: > http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8214236 > looks good to me. Thanks, Thomas From sangheon.kim at oracle.com Mon Feb 4 18:50:20 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Mon, 4 Feb 2019 10:50:20 -0800 Subject: RFR: 8217332: JTREG: Clean up, use generics instead of raw types In-Reply-To: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> References: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> Message-ID: <68082c23-4573-0831-6d09-3449a071373c@oracle.com> Hi Leo, On 1/18/19 1:11 AM, Leo Korinth wrote: > Hi, > > This webrev fixes lack of generics usage in the jtreg/gc folder. > > This fix is somewhat based/dependent on "8214799: Add package > declaration to each JTREG test case in the gc folder". That fix is out > for review. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217332 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217332/00 Looks good. Thanks, Sangheon > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc > > Thanks, > Leo From sangheon.kim at oracle.com Mon Feb 4 18:52:18 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Mon, 4 Feb 2019 10:52:18 -0800 Subject: RFR: 8217385: JTREG: Clean up, make sure to close resources In-Reply-To: References: Message-ID: Hi Leo, On 1/18/19 8:00 AM, Leo Korinth wrote: > Hi, > > This clean up closes resources in some test cases in the jtreg/gc folder. > > This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8217385 > > Webrev: > http://cr.openjdk.java.net/~lkorinth/8217385/00 Looks good to me. Thanks, Sangheon > > Testing: > passed locally: open/test/hotspot/jtreg/:hotspot_gc > > Thanks, > Leo From thomas.schatzl at oracle.com Tue Feb 5 08:49:32 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 05 Feb 2019 09:49:32 +0100 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions In-Reply-To: <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> References: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> Message-ID: Hi Kim, On Fri, 2019-02-01 at 01:31 -0500, Kim Barrett wrote: > > On Feb 1, 2019, at 1:25 AM, Kim Barrett > > wrote: > > > > Please review this renaming of some G1-specific classes and > > associated files to follow our usual naming conventions. > > > > Renamed files: > > dirtyCardQueue.[ch]pp => g1DirtyCardQueue.[ch]pp > > > > Added "G1" prefix to class names CardTableEntryClosure, > > DirtyCardQueue, and DirtyCardQueueSet. > > > > Also did a little bit of #include list and forward declaration list > > maintenance related to these changes. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8218089 > > > > Webrev: > > http://cr.openjdk.java.net/~kbarrett/8218089/open.00/ > > > > Testing: > > mach5 tier1-3 > > I forgot to mention that these changes touch a couple of S390 and PPC > files in fairly obvious ways. I haven?t tested those changes; they > look trivial, and hopefully I didn?t botch them. Looks good. Thomas From kim.barrett at oracle.com Tue Feb 5 14:36:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Feb 2019 09:36:49 -0500 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions In-Reply-To: References: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> Message-ID: <42AAA48D-4290-4C5D-AC89-704E5F4522F0@oracle.com> > On Feb 5, 2019, at 3:49 AM, Thomas Schatzl wrote: > > Hi Kim, > > On Fri, 2019-02-01 at 01:31 -0500, Kim Barrett wrote: >>> On Feb 1, 2019, at 1:25 AM, Kim Barrett >>> wrote: >>> >>> Please review this renaming of some G1-specific classes and >>> associated files to follow our usual naming conventions. >>> >>> Renamed files: >>> dirtyCardQueue.[ch]pp => g1DirtyCardQueue.[ch]pp >>> >>> Added "G1" prefix to class names CardTableEntryClosure, >>> DirtyCardQueue, and DirtyCardQueueSet. >>> >>> Also did a little bit of #include list and forward declaration list >>> maintenance related to these changes. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8218089 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8218089/open.00/ >>> >>> Testing: >>> mach5 tier1-3 >> >> I forgot to mention that these changes touch a couple of S390 and PPC >> files in fairly obvious ways. I haven?t tested those changes; they >> look trivial, and hopefully I didn?t botch them. > > Looks good. > > Thomas Thanks! From leo.korinth at oracle.com Tue Feb 5 16:12:21 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 5 Feb 2019 17:12:21 +0100 Subject: RFR: 8217332: JTREG: Clean up, use generics instead of raw types In-Reply-To: <68082c23-4573-0831-6d09-3449a071373c@oracle.com> References: <73a46554-d6a5-e87d-993d-a4f62ecda404@oracle.com> <68082c23-4573-0831-6d09-3449a071373c@oracle.com> Message-ID: Thanks for the review Sangheon! /Leo On 04/02/2019 19:50, sangheon.kim at oracle.com wrote: > Hi Leo, > > On 1/18/19 1:11 AM, Leo Korinth wrote: >> Hi, >> >> This webrev fixes lack of generics usage in the jtreg/gc folder. >> >> This fix is somewhat based/dependent on "8214799: Add package >> declaration to each JTREG test case in the gc folder". That fix is out >> for review. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217332 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217332/00 > Looks good. > > Thanks, > Sangheon > > >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc >> >> Thanks, >> Leo > From leo.korinth at oracle.com Tue Feb 5 16:14:42 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 5 Feb 2019 17:14:42 +0100 Subject: RFR: 8217385: JTREG: Clean up, make sure to close resources In-Reply-To: References: Message-ID: <12a1ab60-ef08-7dcc-8dc0-4dc1398d3987@oracle.com> Thanks for the review Sangheon! /Leo On 04/02/2019 19:52, sangheon.kim at oracle.com wrote: > Hi Leo, > > On 1/18/19 8:00 AM, Leo Korinth wrote: >> Hi, >> >> This clean up closes resources in some test cases in the jtreg/gc folder. >> >> This fix is somewhat based/dependent on the rest of my "JTREG:" webrevs. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8217385 >> >> Webrev: >> http://cr.openjdk.java.net/~lkorinth/8217385/00 > Looks good to me. > > Thanks, > Sangheon > > >> >> Testing: >> passed locally: open/test/hotspot/jtreg/:hotspot_gc >> >> Thanks, >> Leo > From manc at google.com Tue Feb 5 16:25:55 2019 From: manc at google.com (Man Cao) Date: Tue, 5 Feb 2019 08:25:55 -0800 Subject: RFR (XS): 8218192: Remove copy constructor for MemRegion Message-ID: Hi all, Could I have reviews for this small patch? Webrev: https://cr.openjdk.java.net/~manc/8218192/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8218192 This will improve G1 write barrier performance for jython in DaCapo, when building HotSpot with LLVM. More Background and performance numbers are included in the JBS. Thanks, Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Feb 5 16:32:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 05 Feb 2019 17:32:01 +0100 Subject: RFR (XS): 8218192: Remove copy constructor for MemRegion In-Reply-To: References: Message-ID: Hi, On Tue, 2019-02-05 at 08:25 -0800, Man Cao wrote: > Hi all, > > Could I have reviews for this small patch? > Webrev: https://cr.openjdk.java.net/~manc/8218192/webrev.00/ > RFE: https://bugs.openjdk.java.net/browse/JDK-8218192 > > This will improve G1 write barrier performance for jython in DaCapo, > when building HotSpot with LLVM. More Background and performance > numbers are included in the JBS. looks good. Now we would only need to know whether there could be more similar issues around.... Thomas From kim.barrett at oracle.com Tue Feb 5 18:42:05 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Feb 2019 13:42:05 -0500 Subject: RFR (XS): 8218192: Remove copy constructor for MemRegion In-Reply-To: References: Message-ID: <49752809-086D-42DA-85F9-B8CD21CDED00@oracle.com> > On Feb 5, 2019, at 11:25 AM, Man Cao wrote: > > Hi all, > > Could I have reviews for this small patch? > Webrev: https://cr.openjdk.java.net/~manc/8218192/webrev.00/ > RFE: https://bugs.openjdk.java.net/browse/JDK-8218192 > > This will improve G1 write barrier performance for jython in DaCapo, when building HotSpot with LLVM. More Background and performance numbers are included in the JBS. > > Thanks, > Man Looks good. The only thing I might suggest is adding a comment that the destructor and copy constructor must be trivial, to support optimization of pass by value. I don't need a new webrev if you add such a comment. The explicit copy constructor is clearly interfering with the expected optimization on Linux-x64, and likely other platforms where I didn't examine the generated assembly. The SysV ABI describes passing such an object in a pair of registers for the members, but only when the destructor and copy constructor are trivial. (An older version of the ABI required the class to be POD, which is unnecessarily restrictive; gcc through 4.9 (I think) used that.) There are a handful of places that are passing MemRegions by const-ref rather than by value that probably ought to be looked at, but that can be done separately. I did some performance testing of this change as well. Seemed pretty much in the noise. From shade at redhat.com Wed Feb 6 09:19:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 10:19:00 +0100 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: <6531a332-af3e-fdc4-7b9a-1f2e7cedc73a@redhat.com> References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> <6531a332-af3e-fdc4-7b9a-1f2e7cedc73a@redhat.com> Message-ID: <125939bd-ac49-dad8-5412-8b895c12959c@redhat.com> On 1/30/19 4:40 PM, Aleksey Shipilev wrote: > On 1/24/19 4:37 PM, Aleksey Shipilev wrote: >> Okay, another attempt. This restructures the code a little bit, which IMO makes the flow more >> understandable. It also eliminates a few flags. Then, the placement for GCTraceTime becomes natural. >> Well, almost, because it requires some dance around should_do_full_collection, if we want to include >> young-only epilog into timing. >> >> See: >> http://cr.openjdk.java.net/~shade/8215221/webrev.02/ >> >> This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. >> then. > > The webrev above passes jdk-submit. No takers? :) -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From manc at google.com Wed Feb 6 11:13:49 2019 From: manc at google.com (Man Cao) Date: Wed, 6 Feb 2019 03:13:49 -0800 Subject: RFR (XS): 8218192: Remove copy constructor for MemRegion In-Reply-To: <49752809-086D-42DA-85F9-B8CD21CDED00@oracle.com> References: <49752809-086D-42DA-85F9-B8CD21CDED00@oracle.com> Message-ID: Thank you both for the reviews and suggestions. I will add such comment in this patch. It is really helpful to know these little details. For those other places that pass MemRegions by const-ref, do you think we should change them to pass-by-value if we validate that the compiler generates the same code as pass-by-ref? I still think it might be better to just pass by const-ref for most places, as it will prevent this issue from happening even if the compiler failed to apply the optimization for pass-by-value. -Man On Tue, Feb 5, 2019 at 10:42 AM Kim Barrett wrote: > > On Feb 5, 2019, at 11:25 AM, Man Cao wrote: > > > > Hi all, > > > > Could I have reviews for this small patch? > > Webrev: https://cr.openjdk.java.net/~manc/8218192/webrev.00/ > > RFE: https://bugs.openjdk.java.net/browse/JDK-8218192 > > > > This will improve G1 write barrier performance for jython in DaCapo, > when building HotSpot with LLVM. More Background and performance numbers > are included in the JBS. > > > > Thanks, > > Man > > Looks good. > > The only thing I might suggest is adding a comment that the destructor > and copy constructor must be trivial, to support optimization of pass > by value. I don't need a new webrev if you add such a comment. > > The explicit copy constructor is clearly interfering with the expected > optimization on Linux-x64, and likely other platforms where I didn't > examine the generated assembly. The SysV ABI describes passing such > an object in a pair of registers for the members, but only when the > destructor and copy constructor are trivial. (An older version of the > ABI required the class to be POD, which is unnecessarily restrictive; > gcc through 4.9 (I think) used that.) > > There are a handful of places that are passing MemRegions by const-ref > rather than by value that probably ought to be looked at, but that can > be done separately. > > I did some performance testing of this change as well. Seemed pretty > much in the noise. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Wed Feb 6 14:23:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 15:23:53 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549230180.31327.172.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> Message-ID: <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> On 2/3/19 10:43 PM, zgu at redhat.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ Looks fine code-wise. *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why this whole thing is removed? I would expect "just" the rename of slow_refill_waste() to refill_waste() and removing fast_refill_waste() here, leaving everything else untouched. 105 // statistics 106 107 int number_of_refills() const { return _number_of_refills; } 108 int fast_refill_waste() const { return _fast_refill_waste; } 109 int slow_refill_waste() const { return _slow_refill_waste; } 110 int gc_waste() const { return _gc_waste; } 111 int slow_allocations() const { return _slow_allocations; } 112 Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Wed Feb 6 14:34:11 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 06 Feb 2019 09:34:11 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> Message-ID: <1549463651.31327.188.camel@redhat.com> Thanks, Aleksey. On Wed, 2019-02-06 at 15:23 +0100, Aleksey Shipilev wrote: > On 2/3/19 10:43 PM, zgu at redhat.com wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > Looks fine code-wise. > > *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why > this whole thing is removed? I > would expect "just" the rename of slow_refill_waste() to > refill_waste() and removing > fast_refill_waste() here, leaving everything else untouched. > > 105 // statistics > 106 > 107 int number_of_refills() const { return _number_of_refills; } > 108 int fast_refill_waste() const { return _fast_refill_waste; } > 109 int slow_refill_waste() const { return _slow_refill_waste; } > 110 int gc_waste() const { return _gc_waste; } > 111 int slow_allocations() const { return _slow_allocations; } > 112 They are dead code. Do they worth for another cleanup RFE for the trivial cleanup? -Zhengyu > > > Thanks, > -Aleksey > From shade at redhat.com Wed Feb 6 14:48:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 15:48:27 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549463651.31327.188.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> Message-ID: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> On 2/6/19 3:34 PM, zgu at redhat.com wrote: >> *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why >> this whole thing is removed? I >> would expect "just" the rename of slow_refill_waste() to >> refill_waste() and removing >> fast_refill_waste() here, leaving everything else untouched. >> >> 105 // statistics >> 106 >> 107 int number_of_refills() const { return _number_of_refills; } >> 108 int fast_refill_waste() const { return _fast_refill_waste; } >> 109 int slow_refill_waste() const { return _slow_refill_waste; } >> 110 int gc_waste() const { return _gc_waste; } >> 111 int slow_allocations() const { return _slow_allocations; } >> 112 > > They are dead code. Do they worth for another cleanup RFE for the > trivial cleanup? Okay. I thought the patch was about fast refills only. But indeed, we can clean these unused definitions in the same patch. On one hand, removing trivial unused getters would require us to add them back when they are needed. On the other hand, it seems that TLAB does every statistic internally, and we should instead force callers to use higher-level TLAB methods to access and interpret them. Code looks good! I think we still need Serviceability to acknowledge this is okay to do. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Wed Feb 6 15:01:52 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 06 Feb 2019 10:01:52 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> Message-ID: <1549465312.31327.196.camel@redhat.com> On Wed, 2019-02-06 at 15:48 +0100, Aleksey Shipilev wrote: > On 2/6/19 3:34 PM, zgu at redhat.com wrote: > > > *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why > > > this whole thing is removed? I > > > would expect "just" the rename of slow_refill_waste() to > > > refill_waste() and removing > > > fast_refill_waste() here, leaving everything else untouched. > > > > > > 105 // statistics > > > 106 > > > 107 int number_of_refills() const { return _number_of_refills; > > > } > > > 108 int fast_refill_waste() const { return _fast_refill_waste; > > > } > > > 109 int slow_refill_waste() const { return _slow_refill_waste; > > > } > > > 110 int gc_waste() const { return _gc_waste; } > > > 111 int slow_allocations() const { return _slow_allocations; > > > } > > > 112 > > > > They are dead code. Do they worth for another cleanup RFE for the > > trivial cleanup? > > Okay. I thought the patch was about fast refills only. But indeed, we > can clean these unused > definitions in the same patch. On one hand, removing trivial unused > getters would require us to add > them back when they are needed. On the other hand, it seems that TLAB > does every statistic > internally, and we should instead force callers to use higher-level > TLAB methods to access and > interpret them. > > Code looks good! I think we still need Serviceability to acknowledge > this is okay to do. Serguei okayed. Serguei, does it still okay with you? Thanks, -Zhengyu > > -Aleksey > > > > > > > From kim.barrett at oracle.com Thu Feb 7 00:10:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Feb 2019 19:10:16 -0500 Subject: RFR (XS): 8218192: Remove copy constructor for MemRegion In-Reply-To: References: <49752809-086D-42DA-85F9-B8CD21CDED00@oracle.com> Message-ID: > On Feb 6, 2019, at 6:13 AM, Man Cao wrote: > > Thank you both for the reviews and suggestions. > I will add such comment in this patch. > It is really helpful to know these little details. > > For those other places that pass MemRegions by const-ref, > do you think we should change them to pass-by-value if we > validate that the compiler generates the same code as pass-by-ref? > > I still think it might be better to just pass by const-ref for most > places, as it will prevent this issue from happening even if the > compiler failed to apply the optimization for pass-by-value. This isn?t a compiler optimization, it?s part of the ABI-specified calling convention, so not optional. It?s also not the same as pass-by-ref. The ABI says that when various criteria are met that a struct is passed-by-value as its individual members in registers. Passed-by-ref passes a pointer to the struct, always. From kim.barrett at oracle.com Thu Feb 7 00:26:47 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Feb 2019 19:26:47 -0500 Subject: RFR (L): 8217330: Split CollectionSetChooser into collection set candidate container and the chooser algorithm In-Reply-To: References: <49d3c2a3-ee8d-f715-eb6d-833843c0b0f7@oracle.com> Message-ID: <648F3B19-07BD-49DF-8455-5345A6412691@oracle.com> > On Jan 25, 2019, at 9:11 AM, Thomas Schatzl wrote: > All fixed in > http://cr.openjdk.java.net/~tschatzl/8217330/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8217330/webrev.1 (full) > > Thanks, > Thomas Looks good. Just a couple minor nits, for which I don't need another webrev. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectionSet.hpp 28 #include "gc/g1/g1CollectionSetCandidates.hpp" ... 132 void clear_candidates() { 133 delete _candidates; 134 _candidates = NULL; 135 } I think that if clear_candidates were not inlined here, the #include could be replaced with a forward declaration. Of course, then some using files would need the #include, but they probably should anyway, to avoid implicit dependencies. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/collectionSetChooser.hpp 37 class CollectionSetChooser : public AllStatic { ... 40 CollectionSetChooser(); Derived from AllStatic, so should no longer have a constructor. ------------------------------------------------------------------------------ From per.liden at oracle.com Thu Feb 7 09:20:02 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 7 Feb 2019 10:20:02 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> Message-ID: <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> Hi, On 2/6/19 3:48 PM, Aleksey Shipilev wrote: > On 2/6/19 3:34 PM, zgu at redhat.com wrote: >>> *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why >>> this whole thing is removed? I >>> would expect "just" the rename of slow_refill_waste() to >>> refill_waste() and removing >>> fast_refill_waste() here, leaving everything else untouched. >>> >>> 105 // statistics >>> 106 >>> 107 int number_of_refills() const { return _number_of_refills; } >>> 108 int fast_refill_waste() const { return _fast_refill_waste; } >>> 109 int slow_refill_waste() const { return _slow_refill_waste; } >>> 110 int gc_waste() const { return _gc_waste; } >>> 111 int slow_allocations() const { return _slow_allocations; } >>> 112 >> >> They are dead code. Do they worth for another cleanup RFE for the >> trivial cleanup? > > Okay. I thought the patch was about fast refills only. But indeed, we can clean these unused > definitions in the same patch. On one hand, removing trivial unused getters would require us to add > them back when they are needed. On the other hand, it seems that TLAB does every statistic > internally, and we should instead force callers to use higher-level TLAB methods to access and > interpret them. > > Code looks good! I think we still need Serviceability to acknowledge this is okay to do. Thanks for cleaning this up. GC changes look good. Just one minor thing, please align the assignment here: @@ -147,8 +145,7 @@ void ThreadLocalAllocBuffer::reset_statistics() { _number_of_refills = 0; - _fast_refill_waste = 0; - _slow_refill_waste = 0; + _refill_waste = 0; _gc_waste = 0; _slow_allocations = 0; _allocated_size = 0; I agree that Serviceability should ack the jstat change. cheers, Per From zgu at redhat.com Thu Feb 7 14:03:25 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 07 Feb 2019 09:03:25 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> Message-ID: <1549548205.31327.224.camel@redhat.com> Thanks, Per. > Thanks for cleaning this up. GC changes look good. Just one minor > thing, > please align the assignment here: > > @@ -147,8 +145,7 @@ > > void ThreadLocalAllocBuffer::reset_statistics() { > _number_of_refills = 0; > - _fast_refill_waste = 0; > - _slow_refill_waste = 0; > + _refill_waste = 0; > _gc_waste = 0; > _slow_allocations = 0; > _allocated_size = 0; > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ -Zhengyu > > I agree that Serviceability should ack the jstat change. > > cheers, > Per From per.liden at oracle.com Thu Feb 7 14:05:52 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 7 Feb 2019 15:05:52 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549548205.31327.224.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> <1549548205.31327.224.camel@redhat.com> Message-ID: <60470a03-e95b-38f5-8d89-1ede02f1df27@oracle.com> On 2019-02-07 15:03, zgu at redhat.com wrote: > Thanks, Per. >> Thanks for cleaning this up. GC changes look good. Just one minor >> thing, >> please align the assignment here: >> >> @@ -147,8 +145,7 @@ >> >> void ThreadLocalAllocBuffer::reset_statistics() { >> _number_of_refills = 0; >> - _fast_refill_waste = 0; >> - _slow_refill_waste = 0; >> + _refill_waste = 0; >> _gc_waste = 0; >> _slow_allocations = 0; >> _allocated_size = 0; >> >> > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ Thanks, looks good. /Per > > -Zhengyu > >> >> I agree that Serviceability should ack the jstat change. >> >> cheers, >> Per From thomas.schatzl at oracle.com Fri Feb 8 10:01:52 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 08 Feb 2019 11:01:52 +0100 Subject: RFR (L): 8217330: Split CollectionSetChooser into collection set candidate container and the chooser algorithm In-Reply-To: <648F3B19-07BD-49DF-8455-5345A6412691@oracle.com> References: <49d3c2a3-ee8d-f715-eb6d-833843c0b0f7@oracle.com> <648F3B19-07BD-49DF-8455-5345A6412691@oracle.com> Message-ID: Hi Kim, On Wed, 2019-02-06 at 19:26 -0500, Kim Barrett wrote: > > On Jan 25, 2019, at 9:11 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > All fixed in > > http://cr.openjdk.java.net/~tschatzl/8217330/webrev.0_to_1 (diff) > > http://cr.openjdk.java.net/~tschatzl/8217330/webrev.1 (full) > > > > Thanks, > > Thomas > > Looks good. > > Just a couple minor nits, for which I don't need another webrev. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectionSet.hpp > 28 #include "gc/g1/g1CollectionSetCandidates.hpp" > ... > 132 void clear_candidates() { > 133 delete _candidates; > 134 _candidates = NULL; > 135 } > > I think that if clear_candidates were not inlined here, the #include > could be replaced with a forward declaration. > > Of course, then some using files would need the #include, but they > probably should anyway, to avoid implicit dependencies. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/collectionSetChooser.hpp > 37 class CollectionSetChooser : public AllStatic { > ... > 40 CollectionSetChooser(); > > Derived from AllStatic, so should no longer have a constructor. > thanks for your review. Going to fix all this before pushing. Thomas From stefan.karlsson at oracle.com Mon Feb 11 07:53:26 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 08:53:26 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly Message-ID: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> Hi all, Please review this small patch to resolve ZPageAllocator::_physical as a value object instead of a pointer. https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218732 This fixes the Heap Parameters view. Thanks, StefanK From stefan.karlsson at oracle.com Mon Feb 11 08:13:47 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 09:13:47 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() Message-ID: Hi all, Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() and instead force all GCs to provide their own implementations. https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218733 This was found while running serviceability/sa/TestHeapDumpForLargeArray.java on an experimental implementation of heap dumping in ZGC. ZGC didn't provide a ZCollectedHeap.used() function and CollectedHeap.used() was used instead at: ????????// Check weather we should dump the heap as segments ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; Because of this we incorrectly did not use segmented heap dumps, and therefore overflowed later in the code Aleksey and Roman, Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? Thanks, StefanK From shade at redhat.com Mon Feb 11 09:39:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Feb 2019 10:39:33 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> On 2/11/19 9:13 AM, Stefan Karlsson wrote: > Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() > and instead force all GCs to provide their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ Looks good. > Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity > for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you > want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? Epsilon change looks trivially correct. For Shenandoah, I think this would suffice: @Override public long capacity() { - // FIXME - return 0; + return numOfRegions() * ShenandoahHeapRegion.regionSizeBytes(); } -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefan.karlsson at oracle.com Mon Feb 11 09:52:06 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 10:52:06 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> References: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> Message-ID: <94b6a59b-4642-ba0b-6de6-1c8d1bcdf9fa@oracle.com> On 2019-02-11 10:39, Aleksey Shipilev wrote: > On 2/11/19 9:13 AM, Stefan Karlsson wrote: >> Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() >> and instead force all GCs to provide their own implementations. >> >> https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > > Looks good. Thanks! > > >> Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity >> for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you >> want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? > > Epsilon change looks trivially correct. > > For Shenandoah, I think this would suffice: > > @Override > public long capacity() { > - // FIXME > - return 0; > + return numOfRegions() * ShenandoahHeapRegion.regionSizeBytes(); > } I'll incorporate that into the patch. Thanks, StefanK > > -Aleksey > From per.liden at oracle.com Mon Feb 11 10:31:24 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 11 Feb 2019 11:31:24 +0100 Subject: PING: Re: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> Message-ID: Looks good to me. /Per On 02/04/2019 06:17 PM, Thomas Schatzl wrote: > Hi Chihiro, > > On Tue, 2019-02-05 at 02:12 +0900, Chihiro Ito wrote: >> Hi Thomas and Per, >> >> Could you review this? >> >> webrev: >> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8214236 >> > > looks good to me. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Feb 11 11:32:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 11 Feb 2019 12:32:20 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates Message-ID: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Hi all, can I have reviews for this one-liner fix caused by passing parameters in the wrong order to some internal data structure during calculation of old collection set candidates? CR: https://bugs.openjdk.java.net/browse/JDK-8218680 Webrev: http://cr.openjdk.java.net/~tschatzl/8218680/webrev Testing: The very quickly (<1min, right the first time it calculates old collection set candidates) crashing application, BigRAMTester, now runs more than 30mins. Thanks, Thomas From shade at redhat.com Mon Feb 11 11:38:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Feb 2019 12:38:11 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Message-ID: <704a24d7-1cff-607f-6750-33fe30b7e6d2@redhat.com> On 2/11/19 12:32 PM, Thomas Schatzl wrote: > CR: > https://bugs.openjdk.java.net/browse/JDK-8218680 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218680/webrev Yes, looks good. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Mon Feb 11 11:40:26 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 11 Feb 2019 12:40:26 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Message-ID: On Mon, 2019-02-11 at 12:32 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this one-liner fix caused by passing (originally it had been a one-liner, but then I thought that it would be nicer to fix the order of parameters in the declarations to keep them in line with other uses than just changing the order in the call to the G1BuildCandidateArray constructor). > parameters in the wrong order to some internal data structure during > calculation of old collection set candidates? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218680 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218680/webrev > Testing: > The very quickly (<1min, right the first time it calculates old > collection set candidates) crashing application, BigRAMTester, now > runs more than 30mins. There is no additional regression test at this time because later CI tests not checked in the initial commit (tier7) also fail with the same assert. I may be able to come up with a separate regression test if needed, but I think the problem and the fix is relatively trivial. If you insist I would prefer to do a regression test as a separate CR to remove the noise from our testing. Thanks, Thomas From thomas.schatzl at oracle.com Mon Feb 11 11:41:07 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 11 Feb 2019 12:41:07 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: <704a24d7-1cff-607f-6750-33fe30b7e6d2@redhat.com> References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> <704a24d7-1cff-607f-6750-33fe30b7e6d2@redhat.com> Message-ID: <94ce9a7ce8b1f6b76944e1576ba52fcc3dda88ca.camel@oracle.com> Hi, On Mon, 2019-02-11 at 12:38 +0100, Aleksey Shipilev wrote: > On 2/11/19 12:32 PM, Thomas Schatzl wrote: > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8218680 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8218680/webrev > > Yes, looks good. > thanks for your review. Thomas From shade at redhat.com Mon Feb 11 11:46:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Feb 2019 12:46:24 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Message-ID: <33228921-f484-4e42-c830-46608538ee65@redhat.com> On 2/11/19 12:40 PM, Thomas Schatzl wrote: > I may be able to come up with a separate regression test if needed, but > I think the problem and the fix is relatively trivial. If you insist I > would prefer to do a regression test as a separate CR to remove the > noise from our testing. I think it is trivial enough to ignore the regression test. I really wish type system would check this for us, but it seems to be another hassle that is not worth it here. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefan.karlsson at oracle.com Mon Feb 11 12:00:42 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 13:00:42 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> References: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> Message-ID: <3f1968db-1db7-d535-c397-f5c544ce1224@oracle.com> Thanks, Jini. StefanK On 2019-02-11 13:00, Jini George wrote: > Hi Stefan, > > Looks good to me. > > Thanks, > Jini. > > On 2/11/2019 1:43 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the broken implementation of >> CollectedHeap used() and capacity() and instead force all GCs to >> provide their own implementations. >> >> https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218733 >> >> This was found while running >> serviceability/sa/TestHeapDumpForLargeArray.java on an experimental >> implementation of heap dumping in ZGC. >> >> ZGC didn't provide a ZCollectedHeap.used() function and >> CollectedHeap.used() was used instead at: >> ?????????// Check weather we should dump the heap as segments >> ?????????useSegmentedHeapDump = vm.getUniverse().heap().used() > >> HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; >> >> Because of this we incorrectly did not use segmented heap dumps, and >> therefore overflowed later in the code >> >> Aleksey and Roman, >> >> Could you verify that the implementation for Epsilon is correct? I >> also haven't implemented capacity for Shenandoah, as the information >> isn't trivially available in the ShenandoahHeap SA class. Do you want >> to fix it as part of this patch, or should I create a separate RFE for >> Shenandoah? >> >> Thanks, >> StefanK From jini.george at oracle.com Mon Feb 11 12:00:24 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Feb 2019 17:30:24 +0530 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> Hi Stefan, Looks good to me. Thanks, Jini. On 2/11/2019 1:43 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the broken implementation of > CollectedHeap used() and capacity() and instead force all GCs to provide > their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218733 > > This was found while running > serviceability/sa/TestHeapDumpForLargeArray.java on an experimental > implementation of heap dumping in ZGC. > > ZGC didn't provide a ZCollectedHeap.used() function and > CollectedHeap.used() was used instead at: > ????????// Check weather we should dump the heap as segments > ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; > > Because of this we incorrectly did not use segmented heap dumps, and > therefore overflowed later in the code > > Aleksey and Roman, > > Could you verify that the implementation for Epsilon is correct? I also > haven't implemented capacity for Shenandoah, as the information isn't > trivially available in the ShenandoahHeap SA class. Do you want to fix > it as part of this patch, or should I create a separate RFE for Shenandoah? > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Feb 11 12:36:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 13:36:57 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps Message-ID: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Hi all, Please review this patch to add support for large bitmaps in the SA. http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218743 I've added a minimal interface (at, atPut, clear) that uses longs instead of ints, and changed MarkBits to use this interface. I've implemented a segmented bitmap that, currently, all GCs use when asked for a bitmap in MarkBits. Later ZGC will provide its own discontiguous bitmap, implementing the new interface, but that will be sent out as a separate RFE. I've tested this with a temporary patch that lowers the segment size and implements a jtreg test: http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 I ran through the all the tests in serviceability/sa with both these patches. Thanks, StefanK From stefan.karlsson at oracle.com Mon Feb 11 13:55:15 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 14:55:15 +0100 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC Message-ID: Hi all, Please review this patch to implement a discontiuous bitmap for ZGC in the SA. http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218746 ZGC uses a 16TB virtual memory address range, so the normal scheme to map a bitmap over the entire address range uses too much memory. This patch lazily creates smaller bitmaps per ZPage, when at() or atPut() is called. This patch builds upon JDK-8218743. Tested with serviceability/sa and manually running Reverse Object Analysis in the SA. Thanks, StefanK From leo.korinth at oracle.com Mon Feb 11 14:36:46 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 11 Feb 2019 15:36:46 +0100 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Message-ID: <9413f4ae-0516-6585-21a4-68dbbfeec5a9@oracle.com> The change looks good to me. Thanks, Leo On 11/02/2019 12:32, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this one-liner fix caused by passing > parameters in the wrong order to some internal data structure during > calculation of old collection set candidates? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218680 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218680/webrev > Testing: > The very quickly (<1min, right the first time it calculates old > collection set candidates) crashing application, BigRAMTester, now runs > more than 30mins. > > Thanks, > Thomas > > From jini.george at oracle.com Mon Feb 11 18:00:04 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Feb 2019 23:30:04 +0530 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> Message-ID: <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> Hi Stefan, Looks good to me overall. One point though. physicalFieldOffset = type.getAddressField("_physical").getOffset(); Wrt the line above, is there any reason due to which getAddressField() instead of getField() was used ? getAddressField() is typically used when the field to be read in is a pointer. I feel getField() might be more appropriate in this situation. Thanks, Jini. On 2/11/2019 1:23 PM, Stefan Karlsson wrote: > Hi all, > > Please review this small patch to resolve ZPageAllocator::_physical as a > value object instead of a pointer. > > https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218732 > > This fixes the Heap Parameters view. > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Feb 11 18:09:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 19:09:29 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> Message-ID: <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> Hi Jini, On 2019-02-11 19:00, Jini George wrote: > Hi Stefan, > > Looks good to me overall. One point though. > > physicalFieldOffset = type.getAddressField("_physical").getOffset(); > > Wrt the line above, is there any reason due to which getAddressField() > instead of getField() was used ? getAddressField() is typically used > when the field to be read in is a pointer. I feel getField() might be > more appropriate in this situation. No, this is just an oversight. I have the same issue in my later OopHandle patch. I'll change this. Thanks for reviewing, StefanK > > > Thanks, > Jini. > > On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this small patch to resolve ZPageAllocator::_physical >> as a value object instead of a pointer. >> >> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218732 >> >> This fixes the Heap Parameters view. >> >> Thanks, >> StefanK From kim.barrett at oracle.com Mon Feb 11 19:47:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Feb 2019 14:47:17 -0500 Subject: RFR (XXS): 8218680: G1 crashes during calculation of old collection set candidates In-Reply-To: References: <290c5c4aac70ea98ce0bb44b98ae3eba9539aa0e.camel@oracle.com> Message-ID: <82AFF104-470F-4DE7-94D4-27C9D8E84185@oracle.com> > On Feb 11, 2019, at 6:40 AM, Thomas Schatzl wrote: > > On Mon, 2019-02-11 at 12:32 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this one-liner fix caused by passing > > (originally it had been a one-liner, but then I thought that it would > be nicer to fix the order of parameters in the declarations to keep > them in line with other uses than just changing the order in the call > to the G1BuildCandidateArray constructor). > >> parameters in the wrong order to some internal data structure during >> calculation of old collection set candidates? >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8218680 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8218680/webrev >> Testing: >> The very quickly (<1min, right the first time it calculates old >> collection set candidates) crashing application, BigRAMTester, now >> runs more than 30mins. Looks good. From chihiro.ito at oracle.com Tue Feb 12 00:03:48 2019 From: chihiro.ito at oracle.com (Chihiro Ito) Date: Tue, 12 Feb 2019 09:03:48 +0900 Subject: PING: Re: RFR: JDK-8214236: sun.gc.collector.2.name should be changed In-Reply-To: References: <4a4020b1-e0fc-b98e-4222-7fb495441278@oracle.com> <84f30c04-d958-20e2-c59c-2d76f9527b11@oracle.com> <0cabe730673ffc3eb1f56b4a896920136d9a8f54.camel@oracle.com> <94f91596-b72d-d7ec-d417-38d3062d8bf3@oracle.com> <4686c43079e7cd593da4e150515841bdefdb67ac.camel@oracle.com> <4889c69a-5bbf-c660-cc6f-3f21dec71186@oracle.com> <9c46c1ca-5723-2306-647c-3d3dcea2ee38@oracle.com> Message-ID: Hi Thomas and Per, Thanks for reviewing. Could you sponsor this and push to the repository? I uploaded the changeset as follows, http://cr.openjdk.java.net/~cito/JDK-8214236/JDK-8214236-changeset Regards, Chihiro On 2019/02/11 19:31, Per Liden wrote: > Looks good to me. > > /Per > > On 02/04/2019 06:17 PM, Thomas Schatzl wrote: >> Hi Chihiro, >> >> On Tue, 2019-02-05 at 02:12 +0900, Chihiro Ito wrote: >>> Hi Thomas and Per, >>> >>> Could you review this? >>> >>> webrev: >>> http://cr.openjdk.java.net/~cito/JDK-8214236/webrev.02/ >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8214236 >>> >> >> looks good to me. >> >> Thanks, >> Thomas >> >> > From jini.george at oracle.com Wed Feb 13 04:53:07 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 13 Feb 2019 10:23:07 +0530 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Message-ID: <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> Hi Stefan, Looks good to me. Nits: pls do change the copyright year. Thanks, Jini. On 2/11/2019 6:06 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add support for large bitmaps in the SA. > > http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218743 > > I've added a minimal interface (at, atPut, clear) that uses longs > instead of ints, and changed MarkBits to use this interface. > > I've implemented a segmented bitmap that, currently, all GCs use when > asked for a bitmap in MarkBits. Later ZGC will provide its own > discontiguous bitmap, implementing the new interface, but that will be > sent out as a separate RFE. > > I've tested this with a temporary patch that lowers the segment size and > implements a jtreg test: > http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 > > I ran through the all the tests in serviceability/sa with both these > patches. > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Feb 13 08:42:36 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 09:42:36 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> Message-ID: <8f12f472-cf66-5fa1-187b-b260ad8ba8eb@oracle.com> Hi Jini, On 2019-02-13 05:53, Jini George wrote: > Hi Stefan, > > Looks good to me. Nits: pls do change the copyright year. Thanks for reviewing. I'll update the copyright years. Thanks, StefanK > > Thanks, > Jini. > > On 2/11/2019 6:06 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to add support for large bitmaps in the SA. >> >> http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218743 >> >> I've added a minimal interface (at, atPut, clear) that uses longs >> instead of ints, and changed MarkBits to use this interface. >> >> I've implemented a segmented bitmap that, currently, all GCs use when >> asked for a bitmap in MarkBits. Later ZGC will provide its own >> discontiguous bitmap, implementing the new interface, but that will be >> sent out as a separate RFE. >> >> I've tested this with a temporary patch that lowers the segment size >> and implements a jtreg test: >> http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 >> >> I ran through the all the tests in serviceability/sa with both these >> patches. >> >> Thanks, >> StefanK From leo.korinth at oracle.com Wed Feb 13 11:55:08 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 13 Feb 2019 12:55:08 +0100 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions In-Reply-To: <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> References: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> Message-ID: Looks good, thanks for cleaning! Add copyright (ranges) in the files below before pushing: src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_*.cpp src/hotspot/share/gc/g1/g1ThreadLocalData.hpp Thanks, Leo On 01/02/2019 07:31, Kim Barrett wrote: >> On Feb 1, 2019, at 1:25 AM, Kim Barrett wrote: >> >> Please review this renaming of some G1-specific classes and associated >> files to follow our usual naming conventions. >> >> Renamed files: >> dirtyCardQueue.[ch]pp => g1DirtyCardQueue.[ch]pp >> >> Added "G1" prefix to class names CardTableEntryClosure, >> DirtyCardQueue, and DirtyCardQueueSet. >> >> Also did a little bit of #include list and forward declaration list >> maintenance related to these changes. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8218089 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8218089/open.00/ >> >> Testing: >> mach5 tier1-3 > > I forgot to mention that these changes touch a couple of S390 and PPC > files in fairly obvious ways. I haven?t tested those changes; they look > trivial, and hopefully I didn?t botch them. > > From zgu at redhat.com Wed Feb 13 14:12:59 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 13 Feb 2019 09:12:59 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549548205.31327.224.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> <1549548205.31327.224.camel@redhat.com> Message-ID: <1550067179.20944.51.camel@redhat.com> Thanks, Per. > > Thanks for cleaning this up. GC changes look good. Just one minor > > thing, > > please align the assignment here: > > > > @@ -147,8 +145,7 @@ > > > > void ThreadLocalAllocBuffer::reset_statistics() { > > _number_of_refills = 0; > > - _fast_refill_waste = 0; > > - _slow_refill_waste = 0; > > + _refill_waste = 0; > > _gc_waste = 0; > > _slow_allocations = 0; > > _allocated_size = 0; > > > > > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ > > -Zhengyu > > > > > I agree that Serviceability should ack the jstat change. Ping, anyone from Serviceability! Thanks, -Zhengyu > > > > cheers, > > Per From stefan.karlsson at oracle.com Wed Feb 13 14:52:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 15:52:05 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC Message-ID: Hi all, Please review / comment on this patch to enable a best-effort live heap region iteration implementation in ZGC. http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218922 The SA has functionally that relies on live heap region information from the GCs. This is problematic when dead objects are left in the heap, and their classes have been unloaded. Because of this ZGC has so far not implemented this feature. However, we could provide a best-effort implementation that most likely will work if classes are not unloaded (or class unloading is turned off), and otherwise might fail to fully parse and report all live heap regions. For active, non-relocating pages the patch simply returns [start, top) and for pages being actively relocated, it reports regions containing the non-forwarded objects, the other objects are either dead or could be found in one of the to-regions. With this patch I'm able to get heap histograms with ZGC. Maybe this is enough to enable a bit more SA debugging capabilities when running with ZGC? What do you think, should we bring in this change? To be able to implement this more cleanly I've restructured the live region collection, and pushed GC specific code into the specific GCs. There are some extra usage of generics to make the code a bit easier to read and develop. Thanks, StefanK From kim.barrett at oracle.com Wed Feb 13 22:39:30 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Feb 2019 17:39:30 -0500 Subject: RFR(tedious): 8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions In-Reply-To: References: <26A39BBF-E80E-454E-A2B1-CA5A2050B185@oracle.com> <787B9F67-3843-4711-A373-102C8AD4DFAC@oracle.com> Message-ID: <536C0F1F-A2BE-497B-BF27-46FFB79B4316@oracle.com> > On Feb 13, 2019, at 6:55 AM, Leo Korinth wrote: > > Looks good, thanks for cleaning! > > Add copyright (ranges) in the files below before pushing: > src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_*.cpp > src/hotspot/share/gc/g1/g1ThreadLocalData.hpp Oops, thanks for noticing those. From erik.osterlund at oracle.com Thu Feb 14 08:26:40 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 09:26:40 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> Message-ID: <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> Hi Stefan, Given that the remark from Jini is fixed, this looks good. I don't need another webrev. Thanks, /Erik On 2019-02-11 19:09, Stefan Karlsson wrote: > Hi Jini, > > On 2019-02-11 19:00, Jini George wrote: >> Hi Stefan, >> >> Looks good to me overall. One point though. >> >> physicalFieldOffset = type.getAddressField("_physical").getOffset(); >> >> Wrt the line above, is there any reason due to which getAddressField() >> instead of getField() was used ? getAddressField() is typically used >> when the field to be read in is a pointer. I feel getField() might be >> more appropriate in this situation. > > No, this is just an oversight. I have the same issue in my later > OopHandle patch. I'll change this. > > Thanks for reviewing, > StefanK >> >> >> Thanks, >> Jini. >> >> On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this small patch to resolve ZPageAllocator::_physical >>> as a value object instead of a pointer. >>> >>> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8218732 >>> >>> This fixes the Heap Parameters view. >>> >>> Thanks, >>> StefanK > From erik.osterlund at oracle.com Thu Feb 14 08:38:07 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 09:38:07 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <1f1bdf2f-c108-960d-99fe-e39347a3da07@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-02-11 09:13, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the broken implementation of > CollectedHeap used() and capacity() and instead force all GCs to provide > their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218733 > > This was found while running > serviceability/sa/TestHeapDumpForLargeArray.java on an experimental > implementation of heap dumping in ZGC. > > ZGC didn't provide a ZCollectedHeap.used() function and > CollectedHeap.used() was used instead at: > ????????// Check weather we should dump the heap as segments > ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; > > Because of this we incorrectly did not use segmented heap dumps, and > therefore overflowed later in the code > > Aleksey and Roman, > > Could you verify that the implementation for Epsilon is correct? I also > haven't implemented capacity for Shenandoah, as the information isn't > trivially available in the ShenandoahHeap SA class. Do you want to fix > it as part of this patch, or should I create a separate RFE for Shenandoah? > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:10:37 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:10:37 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> Message-ID: <8558a94f-96bb-4a90-7f1f-ed54f629b021@oracle.com> Thanks, Erik. Stefank On 2019-02-14 09:26, Erik ?sterlund wrote: > Hi Stefan, > > Given that the remark from Jini is fixed, this looks good. I don't need > another webrev. > > Thanks, > /Erik > > On 2019-02-11 19:09, Stefan Karlsson wrote: >> Hi Jini, >> >> On 2019-02-11 19:00, Jini George wrote: >>> Hi Stefan, >>> >>> Looks good to me overall. One point though. >>> >>> physicalFieldOffset = type.getAddressField("_physical").getOffset(); >>> >>> Wrt the line above, is there any reason due to which >>> getAddressField() instead of getField() was used ? getAddressField() >>> is typically used when the field to be read in is a pointer. I feel >>> getField() might be more appropriate in this situation. >> >> No, this is just an oversight. I have the same issue in my later >> OopHandle patch. I'll change this. >> >> Thanks for reviewing, >> StefanK >>> >>> >>> Thanks, >>> Jini. >>> >>> On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this small patch to resolve ZPageAllocator::_physical >>>> as a value object instead of a pointer. >>>> >>>> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8218732 >>>> >>>> This fixes the Heap Parameters view. >>>> >>>> Thanks, >>>> StefanK >> From erik.osterlund at oracle.com Thu Feb 14 09:11:53 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:11:53 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Message-ID: <930d2dc8-c5d6-9c0e-19dd-b40c198af858@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-02-11 13:36, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add support for large bitmaps in the SA. > > http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218743 > > I've added a minimal interface (at, atPut, clear) that uses longs > instead of ints, and changed MarkBits to use this interface. > > I've implemented a segmented bitmap that, currently, all GCs use when > asked for a bitmap in MarkBits. Later ZGC will provide its own > discontiguous bitmap, implementing the new interface, but that will be > sent out as a separate RFE. > > I've tested this with a temporary patch that lowers the segment size and > implements a jtreg test: > http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 > > I ran through the all the tests in serviceability/sa with both these > patches. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:12:18 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:12:18 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <930d2dc8-c5d6-9c0e-19dd-b40c198af858@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> <930d2dc8-c5d6-9c0e-19dd-b40c198af858@oracle.com> Message-ID: <5b55d335-b9b5-fef2-9f78-7844f86dd844@oracle.com> Thanks, Erik. Stefank On 2019-02-14 10:11, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. > > Thanks, > /Erik > > On 2019-02-11 13:36, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to add support for large bitmaps in the SA. >> >> http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218743 >> >> I've added a minimal interface (at, atPut, clear) that uses longs >> instead of ints, and changed MarkBits to use this interface. >> >> I've implemented a segmented bitmap that, currently, all GCs use when >> asked for a bitmap in MarkBits. Later ZGC will provide its own >> discontiguous bitmap, implementing the new interface, but that will be >> sent out as a separate RFE. >> >> I've tested this with a temporary patch that lowers the segment size >> and implements a jtreg test: >> http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 >> >> I ran through the all the tests in serviceability/sa with both these >> patches. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:10:50 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:10:50 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: <1f1bdf2f-c108-960d-99fe-e39347a3da07@oracle.com> References: <1f1bdf2f-c108-960d-99fe-e39347a3da07@oracle.com> Message-ID: Thanks, Erik. Stefank On 2019-02-14 09:38, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. > > Thanks, > /Erik > > On 2019-02-11 09:13, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the broken implementation of >> CollectedHeap used() and capacity() and instead force all GCs to >> provide their own implementations. >> >> https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218733 >> >> This was found while running >> serviceability/sa/TestHeapDumpForLargeArray.java on an experimental >> implementation of heap dumping in ZGC. >> >> ZGC didn't provide a ZCollectedHeap.used() function and >> CollectedHeap.used() was used instead at: >> ?????????// Check weather we should dump the heap as segments >> ?????????useSegmentedHeapDump = vm.getUniverse().heap().used() > >> HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; >> >> Because of this we incorrectly did not use segmented heap dumps, and >> therefore overflowed later in the code >> >> Aleksey and Roman, >> >> Could you verify that the implementation for Epsilon is correct? I >> also haven't implemented capacity for Shenandoah, as the information >> isn't trivially available in the ShenandoahHeap SA class. Do you want >> to fix it as part of this patch, or should I create a separate RFE for >> Shenandoah? >> >> Thanks, >> StefanK From erik.osterlund at oracle.com Thu Feb 14 09:22:35 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:22:35 +0100 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC In-Reply-To: References: Message-ID: <1e4b73a7-9dd1-290f-5ddc-74fb6406b7a6@oracle.com> Hi Stefan, At ZExternalBitMap line 22: * Maybe add a bounds check for offsets < 0 as well. At ZExternalBitMap line 45: * Remove weird whitespace in argument list. * Consider inverting the condition to early exit. Don't mind if you choose to do that or not. Otherwise looks good. Don't need another webrev. Thanks, /Erik On 2019-02-11 14:55, Stefan Karlsson wrote: > Hi all, > > Please review this patch to implement a discontiuous bitmap for ZGC in > the SA. > > http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218746 > > ZGC uses a 16TB virtual memory address range, so the normal scheme to > map a bitmap over the entire address range uses too much memory. This > patch lazily creates smaller bitmaps per ZPage, when at() or atPut() is > called. > > This patch builds upon JDK-8218743. > > Tested with serviceability/sa and manually running Reverse Object > Analysis in the SA. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:59:19 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:59:19 +0100 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC In-Reply-To: <1e4b73a7-9dd1-290f-5ddc-74fb6406b7a6@oracle.com> References: <1e4b73a7-9dd1-290f-5ddc-74fb6406b7a6@oracle.com> Message-ID: On 2019-02-14 10:22, Erik ?sterlund wrote: > Hi Stefan, > > At ZExternalBitMap line 22: > * Maybe add a bounds check for offsets < 0 as well. > > At ZExternalBitMap line 45: > * Remove weird whitespace in argument list. > * Consider inverting the condition to early exit. Don't mind if you > choose to do that or not. > > Otherwise looks good. Don't need another webrev. I'll fix. Thanks for reviewing. StefanK > > Thanks, > /Erik > > On 2019-02-11 14:55, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to implement a discontiuous bitmap for ZGC in >> the SA. >> >> http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218746 >> >> ZGC uses a 16TB virtual memory address range, so the normal scheme to >> map a bitmap over the entire address range uses too much memory. This >> patch lazily creates smaller bitmaps per ZPage, when at() or atPut() >> is called. >> >> This patch builds upon JDK-8218743. >> >> Tested with serviceability/sa and manually running Reverse Object >> Analysis in the SA. >> >> Thanks, >> StefanK From erik.osterlund at oracle.com Thu Feb 14 09:58:32 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:58:32 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: References: Message-ID: <3d056b0e-aa9a-b1d3-0085-c2866aa59962@oracle.com> Hi Stefan, I think this makes things better. I like the cleanups and I like the partial support for heap parsing. I think we should bring this in, and it looks good to me. Of course we can always improve this further at some point in the future to deal with broken Klass pointers better. Thanks, /Erik On 2019-02-13 15:52, Stefan Karlsson wrote: > Hi all, > > Please review / comment on this patch to enable a best-effort live heap > region iteration implementation in ZGC. > > http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218922 > > The SA has functionally that relies on live heap region information from > the GCs. This is problematic when dead objects are left in the heap, and > their classes have been unloaded. > > Because of this ZGC has so far not implemented this feature. However, we > could provide a best-effort implementation that most likely will work if > classes are not unloaded (or class unloading is turned off), and > otherwise might fail to fully parse and report all live heap regions. > > For active, non-relocating pages the patch simply returns [start, top) > and for pages being actively relocated, it reports regions containing > the non-forwarded objects, the other objects are either dead or could be > found in one of the to-regions. > > With this patch I'm able to get heap histograms with ZGC. > > Maybe this is enough to enable a bit more SA debugging capabilities when > running with ZGC? What do you think, should we bring in this change? > > To be able to implement this more cleanly I've restructured the live > region collection, and pushed GC specific code into the specific GCs. > There are some extra usage of generics to make the code a bit easier to > read and develop. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 10:13:00 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 11:13:00 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <3d056b0e-aa9a-b1d3-0085-c2866aa59962@oracle.com> References: <3d056b0e-aa9a-b1d3-0085-c2866aa59962@oracle.com> Message-ID: <549809fc-2bd6-6a7e-701a-f655f62b3f5b@oracle.com> Thanks for taking a look at this! StefanK On 2019-02-14 10:58, Erik ?sterlund wrote: > Hi Stefan, > > I think this makes things better. I like the cleanups and I like the > partial support for heap parsing. I think we should bring this in, and > it looks good to me. > > Of course we can always improve this further at some point in the future > to deal with broken Klass pointers better. > > Thanks, > /Erik > > On 2019-02-13 15:52, Stefan Karlsson wrote: >> Hi all, >> >> Please review / comment on this patch to enable a best-effort live >> heap region iteration implementation in ZGC. >> >> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218922 >> >> The SA has functionally that relies on live heap region information >> from the GCs. This is problematic when dead objects are left in the >> heap, and their classes have been unloaded. >> >> Because of this ZGC has so far not implemented this feature. However, >> we could provide a best-effort implementation that most likely will >> work if classes are not unloaded (or class unloading is turned off), >> and otherwise might fail to fully parse and report all live heap regions. >> >> For active, non-relocating pages the patch simply returns [start, top) >> and for pages being actively relocated, it reports regions containing >> the non-forwarded objects, the other objects are either dead or could >> be found in one of the to-regions. >> >> With this patch I'm able to get heap histograms with ZGC. >> >> Maybe this is enough to enable a bit more SA debugging capabilities >> when running with ZGC? What do you think, should we bring in this change? >> >> To be able to implement this more cleanly I've restructured the live >> region collection, and pushed GC specific code into the specific GCs. >> There are some extra usage of generics to make the code a bit easier >> to read and develop. >> >> Thanks, >> StefanK From erik.osterlund at oracle.com Thu Feb 14 11:55:39 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 12:55:39 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush Message-ID: Hi, An nmethod goes from being is_alive() to being !is_alive() and eventually being freed in nmethod::flush. Native structures for nmethods are freed in nmethod::flush when we free the nmethod. Except for a few things, including GC data. This enhancement proposes to fix that to make the life cycle of nmethods and their native data more intuitive. In particular ZGC has per-nmethod data. The data is removed when unlinking nmethods, as opposed to when they are deleted. This is a bit awkward and makes things more difficult than they need to be. This patch adds a new CollectedHeap::flush_nmethod() function. In there ZGC deletes its attached GC data. Bug: https://bugs.openjdk.java.net/browse/JDK-8218974 Webrev: http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ Thanks, /Erik From stefan.karlsson at oracle.com Thu Feb 14 13:17:30 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 14:17:30 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: References: Message-ID: If this patch is accepted we also need this patch to turn on the SA hprof implementation: http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ StefanK On 2019-02-13 15:52, Stefan Karlsson wrote: > Hi all, > > Please review / comment on this patch to enable a best-effort live heap > region iteration implementation in ZGC. > > http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218922 > > The SA has functionally that relies on live heap region information from > the GCs. This is problematic when dead objects are left in the heap, and > their classes have been unloaded. > > Because of this ZGC has so far not implemented this feature. However, we > could provide a best-effort implementation that most likely will work if > classes are not unloaded (or class unloading is turned off), and > otherwise might fail to fully parse and report all live heap regions. > > For active, non-relocating pages the patch simply returns [start, top) > and for pages being actively relocated, it reports regions containing > the non-forwarded objects, the other objects are either dead or could be > found in one of the to-regions. > > With this patch I'm able to get heap histograms with ZGC. > > Maybe this is enough to enable a bit more SA debugging capabilities when > running with ZGC? What do you think, should we bring in this change? > > To be able to implement this more cleanly I've restructured the live > region collection, and pushed GC specific code into the specific GCs. > There are some extra usage of generics to make the code a bit easier to > read and develop. > > Thanks, > StefanK From jini.george at oracle.com Thu Feb 14 16:04:13 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 14 Feb 2019 21:34:13 +0530 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC In-Reply-To: References: Message-ID: Hi Stefan, Looks good to me. Nit: Could you please modify the copyright year? And don't we have to add the copyright message to the new file ZExternalBitMap.java ? Thanks! Jini. On 2/11/2019 7:25 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to implement a discontiuous bitmap for ZGC in > the SA. > > http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218746 > > ZGC uses a 16TB virtual memory address range, so the normal scheme to > map a bitmap over the entire address range uses too much memory. This > patch lazily creates smaller bitmaps per ZPage, when at() or atPut() is > called. > > This patch builds upon JDK-8218743. > > Tested with serviceability/sa and manually running Reverse Object > Analysis in the SA. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 16:53:42 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 17:53:42 +0100 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC In-Reply-To: References: Message-ID: <808dde5b-f929-53f4-6938-3f309571d646@oracle.com> On 2019-02-14 17:04, Jini George wrote: > Hi Stefan, > > Looks good to me. Nit: Could you please modify the copyright year? And > don't we have to add the copyright message to the new file > ZExternalBitMap.java ? Thanks. I've gone through all my SA patches and updated the copyright year. StefanK > > Thanks! > Jini. > > On 2/11/2019 7:25 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to implement a discontiuous bitmap for ZGC >> in the SA. >> >> http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218746 >> >> ZGC uses a 16TB virtual memory address range, so the normal scheme to >> map a bitmap over the entire address range uses too much memory. This >> patch lazily creates smaller bitmaps per ZPage, when at() or atPut() >> is called. >> >> This patch builds upon JDK-8218743. >> >> Tested with serviceability/sa and manually running Reverse Object >> Analysis in the SA. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Feb 14 17:12:48 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 18:12:48 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> Message-ID: <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> Hi again, I've separated the live regions iteration refactoring into this patch: https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ And use this RFE for the ZGC specific parts: https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ Thanks, StefanK On 2019-02-14 14:39, Stefan Karlsson wrote: > Hi Yasumasa, > > On 2019-02-14 14:11, Yasumasa Suenaga wrote: >> Hi Stefan, >> >>> Maybe this is enough to enable a bit more SA debugging capabilities >>> when >>> running with ZGC? What do you think, should we bring in this change? >> >> I think it should be brought this in. >> I filed same issue as JDK-8207843, but I've not yet worked. >> So I will close it as duplicate of your change. >> >> >>> To be able to implement this more cleanly I've restructured the live >>> region collection, and pushed GC specific code into the specific GCs. >>> There are some extra usage of generics to make the code a bit easier to >>> read and develop. >> >> IMHO refactoring for live region collection and ZGC related changes >> should >> be separated. What do you think? > > Yes. I think that would be good. I'll separate this out into two changes. > >> >> >> Your change looks good to me. >> BTW, did you check `jhsdb jmap --binaryheap` with this change? >> > > Yes, when testing this I ran all tests in serviceability/sa and > manually tested the command above. > > While testing this I also had this patch applied to enable SA hprof > for ZGC: > http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ > > And used this patch to turn off the ZGC filtering in the tests: > http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ > > I'm currently rerunning the tests to see that the latest changes > didn't break anything. > > Thanks, > StefanK >> >> Thanks, >> >> Yasumasa >> >> >> >> On 2019/02/13 23:52, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review / comment on this patch to enable a best-effort live heap >>> region iteration implementation in ZGC. >>> >>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>> >>> The SA has functionally that relies on live heap region information >>> from >>> the GCs. This is problematic when dead objects are left in the heap, >>> and >>> their classes have been unloaded. >>> >>> Because of this ZGC has so far not implemented this feature. >>> However, we >>> could provide a best-effort implementation that most likely will >>> work if >>> classes are not unloaded (or class unloading is turned off), and >>> otherwise might fail to fully parse and report all live heap regions. >>> >>> For active, non-relocating pages the patch simply returns [start, top) >>> and for pages being actively relocated, it reports regions containing >>> the non-forwarded objects, the other objects are either dead or >>> could be >>> found in one of the to-regions. >>> >>> With this patch I'm able to get heap histograms with ZGC. >>> >>> Maybe this is enough to enable a bit more SA debugging capabilities >>> when >>> running with ZGC? What do you think, should we bring in this change? >>> >>> To be able to implement this more cleanly I've restructured the live >>> region collection, and pushed GC specific code into the specific GCs. >>> There are some extra usage of generics to make the code a bit easier to >>> read and develop. >>> >>> Thanks, >>> StefanK >>> From yasuenag at gmail.com Fri Feb 15 00:54:04 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Feb 2019 09:54:04 +0900 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> Message-ID: Hi Stefan, Both changes look good to me! Thanks, Yasumasa 2019?2?15?(?) 2:12 Stefan Karlsson : > > Hi again, > > I've separated the live regions iteration refactoring into this patch: > https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ > > And use this RFE for the ZGC specific parts: > https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ > > Thanks, > StefanK > > On 2019-02-14 14:39, Stefan Karlsson wrote: > > Hi Yasumasa, > > > > On 2019-02-14 14:11, Yasumasa Suenaga wrote: > >> Hi Stefan, > >> > >>> Maybe this is enough to enable a bit more SA debugging capabilities > >>> when > >>> running with ZGC? What do you think, should we bring in this change? > >> > >> I think it should be brought this in. > >> I filed same issue as JDK-8207843, but I've not yet worked. > >> So I will close it as duplicate of your change. > >> > >> > >>> To be able to implement this more cleanly I've restructured the live > >>> region collection, and pushed GC specific code into the specific GCs. > >>> There are some extra usage of generics to make the code a bit easier to > >>> read and develop. > >> > >> IMHO refactoring for live region collection and ZGC related changes > >> should > >> be separated. What do you think? > > > > Yes. I think that would be good. I'll separate this out into two changes. > > > >> > >> > >> Your change looks good to me. > >> BTW, did you check `jhsdb jmap --binaryheap` with this change? > >> > > > > Yes, when testing this I ran all tests in serviceability/sa and > > manually tested the command above. > > > > While testing this I also had this patch applied to enable SA hprof > > for ZGC: > > http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ > > > > And used this patch to turn off the ZGC filtering in the tests: > > http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ > > > > I'm currently rerunning the tests to see that the latest changes > > didn't break anything. > > > > Thanks, > > StefanK > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> > >> On 2019/02/13 23:52, Stefan Karlsson wrote: > >>> Hi all, > >>> > >>> Please review / comment on this patch to enable a best-effort live heap > >>> region iteration implementation in ZGC. > >>> > >>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ > >>> https://bugs.openjdk.java.net/browse/JDK-8218922 > >>> > >>> The SA has functionally that relies on live heap region information > >>> from > >>> the GCs. This is problematic when dead objects are left in the heap, > >>> and > >>> their classes have been unloaded. > >>> > >>> Because of this ZGC has so far not implemented this feature. > >>> However, we > >>> could provide a best-effort implementation that most likely will > >>> work if > >>> classes are not unloaded (or class unloading is turned off), and > >>> otherwise might fail to fully parse and report all live heap regions. > >>> > >>> For active, non-relocating pages the patch simply returns [start, top) > >>> and for pages being actively relocated, it reports regions containing > >>> the non-forwarded objects, the other objects are either dead or > >>> could be > >>> found in one of the to-regions. > >>> > >>> With this patch I'm able to get heap histograms with ZGC. > >>> > >>> Maybe this is enough to enable a bit more SA debugging capabilities > >>> when > >>> running with ZGC? What do you think, should we bring in this change? > >>> > >>> To be able to implement this more cleanly I've restructured the live > >>> region collection, and pushed GC specific code into the specific GCs. > >>> There are some extra usage of generics to make the code a bit easier to > >>> read and develop. > >>> > >>> Thanks, > >>> StefanK > >>> > From stefan.karlsson at oracle.com Fri Feb 15 09:12:17 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Feb 2019 10:12:17 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> Message-ID: <9a9f913b-0eb9-3e38-292d-fd65566af3f3@oracle.com> Thanks, Yasumasa! StefanK On 2019-02-15 01:54, Yasumasa Suenaga wrote: > Hi Stefan, > > Both changes look good to me! > > > Thanks, > > Yasumasa > > 2019?2?15?(?) 2:12 Stefan Karlsson : >> >> Hi again, >> >> I've separated the live regions iteration refactoring into this patch: >> https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ >> >> And use this RFE for the ZGC specific parts: >> https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ >> >> Thanks, >> StefanK >> >> On 2019-02-14 14:39, Stefan Karlsson wrote: >>> Hi Yasumasa, >>> >>> On 2019-02-14 14:11, Yasumasa Suenaga wrote: >>>> Hi Stefan, >>>> >>>>> Maybe this is enough to enable a bit more SA debugging capabilities >>>>> when >>>>> running with ZGC? What do you think, should we bring in this change? >>>> >>>> I think it should be brought this in. >>>> I filed same issue as JDK-8207843, but I've not yet worked. >>>> So I will close it as duplicate of your change. >>>> >>>> >>>>> To be able to implement this more cleanly I've restructured the live >>>>> region collection, and pushed GC specific code into the specific GCs. >>>>> There are some extra usage of generics to make the code a bit easier to >>>>> read and develop. >>>> >>>> IMHO refactoring for live region collection and ZGC related changes >>>> should >>>> be separated. What do you think? >>> >>> Yes. I think that would be good. I'll separate this out into two changes. >>> >>>> >>>> >>>> Your change looks good to me. >>>> BTW, did you check `jhsdb jmap --binaryheap` with this change? >>>> >>> >>> Yes, when testing this I ran all tests in serviceability/sa and >>> manually tested the command above. >>> >>> While testing this I also had this patch applied to enable SA hprof >>> for ZGC: >>> http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ >>> >>> And used this patch to turn off the ZGC filtering in the tests: >>> http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ >>> >>> I'm currently rerunning the tests to see that the latest changes >>> didn't break anything. >>> >>> Thanks, >>> StefanK >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> On 2019/02/13 23:52, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review / comment on this patch to enable a best-effort live heap >>>>> region iteration implementation in ZGC. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>>>> >>>>> The SA has functionally that relies on live heap region information >>>>> from >>>>> the GCs. This is problematic when dead objects are left in the heap, >>>>> and >>>>> their classes have been unloaded. >>>>> >>>>> Because of this ZGC has so far not implemented this feature. >>>>> However, we >>>>> could provide a best-effort implementation that most likely will >>>>> work if >>>>> classes are not unloaded (or class unloading is turned off), and >>>>> otherwise might fail to fully parse and report all live heap regions. >>>>> >>>>> For active, non-relocating pages the patch simply returns [start, top) >>>>> and for pages being actively relocated, it reports regions containing >>>>> the non-forwarded objects, the other objects are either dead or >>>>> could be >>>>> found in one of the to-regions. >>>>> >>>>> With this patch I'm able to get heap histograms with ZGC. >>>>> >>>>> Maybe this is enough to enable a bit more SA debugging capabilities >>>>> when >>>>> running with ZGC? What do you think, should we bring in this change? >>>>> >>>>> To be able to implement this more cleanly I've restructured the live >>>>> region collection, and pushed GC specific code into the specific GCs. >>>>> There are some extra usage of generics to make the code a bit easier to >>>>> read and develop. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >> From kevin.walls at oracle.com Fri Feb 15 12:14:52 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 15 Feb 2019 12:14:52 +0000 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> Message-ID: <826b7b9f-3647-aa2a-d9d2-e319a4c84797@oracle.com> Hi Stefan, This is great - if I want to try it out, what order do the changes apply, does the 8218746 webrev apply to create ZExternalBitMap.java and then the 8218922 webrev? Thanks Kevin On 14/02/2019 17:12, Stefan Karlsson wrote: > Hi again, > > I've separated the live regions iteration refactoring into this patch: > https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ > > And use this RFE for the ZGC specific parts: > https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ > > Thanks, > StefanK > > On 2019-02-14 14:39, Stefan Karlsson wrote: >> Hi Yasumasa, >> >> On 2019-02-14 14:11, Yasumasa Suenaga wrote: >>> Hi Stefan, >>> >>>> Maybe this is enough to enable a bit more SA debugging capabilities >>>> when >>>> running with ZGC? What do you think, should we bring in this change? >>> >>> I think it should be brought this in. >>> I filed same issue as JDK-8207843, but I've not yet worked. >>> So I will close it as duplicate of your change. >>> >>> >>>> To be able to implement this more cleanly I've restructured the live >>>> region collection, and pushed GC specific code into the specific GCs. >>>> There are some extra usage of generics to make the code a bit >>>> easier to >>>> read and develop. >>> >>> IMHO refactoring for live region collection and ZGC related changes >>> should >>> be separated. What do you think? >> >> Yes. I think that would be good. I'll separate this out into two >> changes. >> >>> >>> >>> Your change looks good to me. >>> BTW, did you check `jhsdb jmap --binaryheap` with this change? >>> >> >> Yes, when testing this I ran all tests in serviceability/sa and >> manually tested the command above. >> >> While testing this I also had this patch applied to enable SA hprof >> for ZGC: >> http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ >> >> And used this patch to turn off the ZGC filtering in the tests: >> http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ >> >> I'm currently rerunning the tests to see that the latest changes >> didn't break anything. >> >> Thanks, >> StefanK >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> On 2019/02/13 23:52, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review / comment on this patch to enable a best-effort live >>>> heap >>>> region iteration implementation in ZGC. >>>> >>>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>>> >>>> The SA has functionally that relies on live heap region information >>>> from >>>> the GCs. This is problematic when dead objects are left in the >>>> heap, and >>>> their classes have been unloaded. >>>> >>>> Because of this ZGC has so far not implemented this feature. >>>> However, we >>>> could provide a best-effort implementation that most likely will >>>> work if >>>> classes are not unloaded (or class unloading is turned off), and >>>> otherwise might fail to fully parse and report all live heap regions. >>>> >>>> For active, non-relocating pages the patch simply returns [start, top) >>>> and for pages being actively relocated, it reports regions containing >>>> the non-forwarded objects, the other objects are either dead or >>>> could be >>>> found in one of the to-regions. >>>> >>>> With this patch I'm able to get heap histograms with ZGC. >>>> >>>> Maybe this is enough to enable a bit more SA debugging capabilities >>>> when >>>> running with ZGC? What do you think, should we bring in this change? >>>> >>>> To be able to implement this more cleanly I've restructured the live >>>> region collection, and pushed GC specific code into the specific GCs. >>>> There are some extra usage of generics to make the code a bit >>>> easier to >>>> read and develop. >>>> >>>> Thanks, >>>> StefanK >>>> > From thomas.schatzl at oracle.com Fri Feb 15 13:27:36 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 14:27:36 +0100 Subject: RFR (XS): 8218672: AOT code root scanning shows in the wrong position in the logs Message-ID: Hi all, can I have reviews for this small change that fixes the position of the "AOT Code Root Scan" phase, moving it to appear under the "Ext Root Scan" phase where it is handled in? CR: https://bugs.openjdk.java.net/browse/JDK-8218672 Webrev: http://cr.openjdk.java.net/~tschatzl/8218672/webrev/ Testing: hs-tier5 (there is some jfr test case that complains if the phase names were messed up) Thanks, Thomas From thomas.schatzl at oracle.com Fri Feb 15 13:34:58 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 14:34:58 +0100 Subject: RFR (XS): 8218920: Scan HCC should be on the same level as Update RS etc. in the log Message-ID: Hi all, can I have reviews for this change that moves the "Scan HCC" phase into the correct position (corresponding to the execution) in the log? CR: https://bugs.openjdk.java.net/browse/JDK-8218920 Webrev: http://cr.openjdk.java.net/~tschatzl/8218920/webrev/ Testing: modified test case passes, log file looks correct now Thanks, Thomas From thomas.schatzl at oracle.com Fri Feb 15 13:43:00 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 14:43:00 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging Message-ID: Hi, can I have reviews for this change that merges the termination statistics into the regular log file (there were only two metrics left, LAB waste and LAB undo waste), and remove the termination stats afterwards? I (very) rarely use these metrics, so I thought it would be better to keep them (and not just removing the entire termination stats). I was undecided whether it would be good to hide these under the gc+phases=trace level though, so opinions welcome. CR: https://bugs.openjdk.java.net/browse/JDK-8219096 Webrev: http://cr.openjdk.java.net/~tschatzl/8219096/webrev/ Testing: log output verification, test case update Thanks, Thomas From thomas.schatzl at oracle.com Fri Feb 15 13:47:41 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 14:47:41 +0100 Subject: RFR (T): 8219097: Move comment about using weak code blobs closure for code root scanning to correct place Message-ID: <354f93ed39b46e2db864e4fd47d20120176de5d0.camel@oracle.com> Hi all, can I have reviews for moving a comment to the correct place? Sometime in the 9-11 timeframe the code moved without the comment. CR: https://bugs.openjdk.java.net/browse/JDK-8219097 Webrev: http://cr.openjdk.java.net/~tschatzl/8219097/webrev/ Testing: compilation Thomas From thomas.schatzl at oracle.com Fri Feb 15 13:51:56 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 14:51:56 +0100 Subject: RFR (S): 8219098: Make output of region strings more regular in error messages Message-ID: Hi all, can I have reviews for this change that improves (regularizes) the output of verification error messages to use the existing HR_FORMAT/HR_FORMAT_PARAMS that include the HeapRegion number instead of fixing this in every message? The HeapRegion number is much more easy to read and understand than a set of addresses. I.e. this has been the n-th time I had added region numbers to these messages manually while debugging some other changes, and so I thought it would be worthwhile fixing this in mainline. CR: https://bugs.openjdk.java.net/browse/JDK-8219098 Webrev: http://cr.openjdk.java.net/~tschatzl/8219098/webrev/ Testing: compilation Thanks, Thomas From stefan.karlsson at oracle.com Fri Feb 15 19:06:58 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Feb 2019 20:06:58 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <826b7b9f-3647-aa2a-d9d2-e319a4c84797@oracle.com> References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> <826b7b9f-3647-aa2a-d9d2-e319a4c84797@oracle.com> Message-ID: <5a43cff8-9167-eb56-5e2a-c6c7e38be332@oracle.com> Hi Kevin, On 2019-02-15 13:14, Kevin Walls wrote: > Hi Stefan, > > This is great - if I want to try it out, what order do the changes > apply, does the 8218746 webrev apply to create ZExternalBitMap.java > and then the 8218922 webrev? This is my patch queue of outgoing patches: ?zSA.fixVMObjectFactory.8218731 ?zSA.fixPhysical.8218732 ?zSA.heapUsedCapacity.8218733 ?zSA.resolveOopHandle.8218734 ?zSA.bitMapsSegmented.8218743 ?zSA.bitMapsZ.8218746 ?zSA.pagesIterate.refactor.8219003 ?zSA.pagesIterate.8218922.Z ?zSA.turnOnHprof.8218970 ?zSA.turnOnTests.8218978 I've created one big webrev over all these changes: ?https://cr.openjdk.java.net/~stefank/zgc/zSABitMapsAndLiveRegions/webrev/ StefanK > > Thanks > Kevin > > > On 14/02/2019 17:12, Stefan Karlsson wrote: >> Hi again, >> >> I've separated the live regions iteration refactoring into this patch: >> https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ >> >> And use this RFE for the ZGC specific parts: >> https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ >> >> Thanks, >> StefanK >> >> On 2019-02-14 14:39, Stefan Karlsson wrote: >>> Hi Yasumasa, >>> >>> On 2019-02-14 14:11, Yasumasa Suenaga wrote: >>>> Hi Stefan, >>>> >>>>> Maybe this is enough to enable a bit more SA debugging >>>>> capabilities when >>>>> running with ZGC? What do you think, should we bring in this change? >>>> >>>> I think it should be brought this in. >>>> I filed same issue as JDK-8207843, but I've not yet worked. >>>> So I will close it as duplicate of your change. >>>> >>>> >>>>> To be able to implement this more cleanly I've restructured the live >>>>> region collection, and pushed GC specific code into the specific GCs. >>>>> There are some extra usage of generics to make the code a bit >>>>> easier to >>>>> read and develop. >>>> >>>> IMHO refactoring for live region collection and ZGC related changes >>>> should >>>> be separated. What do you think? >>> >>> Yes. I think that would be good. I'll separate this out into two >>> changes. >>> >>>> >>>> >>>> Your change looks good to me. >>>> BTW, did you check `jhsdb jmap --binaryheap` with this change? >>>> >>> >>> Yes, when testing this I ran all tests in serviceability/sa and >>> manually tested the command above. >>> >>> While testing this I also had this patch applied to enable SA hprof >>> for ZGC: >>> http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ >>> >>> And used this patch to turn off the ZGC filtering in the tests: >>> http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ >>> >>> I'm currently rerunning the tests to see that the latest changes >>> didn't break anything. >>> >>> Thanks, >>> StefanK >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> On 2019/02/13 23:52, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review / comment on this patch to enable a best-effort live >>>>> heap >>>>> region iteration implementation in ZGC. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>>>> >>>>> The SA has functionally that relies on live heap region >>>>> information from >>>>> the GCs. This is problematic when dead objects are left in the >>>>> heap, and >>>>> their classes have been unloaded. >>>>> >>>>> Because of this ZGC has so far not implemented this feature. >>>>> However, we >>>>> could provide a best-effort implementation that most likely will >>>>> work if >>>>> classes are not unloaded (or class unloading is turned off), and >>>>> otherwise might fail to fully parse and report all live heap regions. >>>>> >>>>> For active, non-relocating pages the patch simply returns [start, >>>>> top) >>>>> and for pages being actively relocated, it reports regions containing >>>>> the non-forwarded objects, the other objects are either dead or >>>>> could be >>>>> found in one of the to-regions. >>>>> >>>>> With this patch I'm able to get heap histograms with ZGC. >>>>> >>>>> Maybe this is enough to enable a bit more SA debugging >>>>> capabilities when >>>>> running with ZGC? What do you think, should we bring in this change? >>>>> >>>>> To be able to implement this more cleanly I've restructured the live >>>>> region collection, and pushed GC specific code into the specific GCs. >>>>> There are some extra usage of generics to make the code a bit >>>>> easier to >>>>> read and develop. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >> From stefan.karlsson at oracle.com Fri Feb 15 19:25:54 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Feb 2019 20:25:54 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: References: Message-ID: <93c4eff6-b88a-ecb7-9e4b-f4bc602735c9@oracle.com> Testing showed that the re-enabling of the retiring of TLABs was broken. This has been fixed with this patch: http://cr.openjdk.java.net/~stefank/8218922/webrev.03.delta http://cr.openjdk.java.net/~stefank/8218922/webrev.03 During mark start we change what's considered the "good" view of the heap, and if -XX:+ZUnmapBadViews is turned on we actually unmap the previous good view. This happens before TLABs are retired and filler objects get written. This used to work when we didn't create filler objects for TLABs, but know that we do, we need to ensure that the TLAB pointers have the correct colors, otherwise we'll end up crashing when -XX:+ZUnmapBadViews are used. With this fix, the patches passes tier1,tier2, and tier3 testing. Thanks, StefanK On 2019-02-13 15:52, Stefan Karlsson wrote: > Hi all, > > Please review / comment on this patch to enable a best-effort live > heap region iteration implementation in ZGC. > > http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218922 > > The SA has functionally that relies on live heap region information > from the GCs. This is problematic when dead objects are left in the > heap, and their classes have been unloaded. > > Because of this ZGC has so far not implemented this feature. However, > we could provide a best-effort implementation that most likely will > work if classes are not unloaded (or class unloading is turned off), > and otherwise might fail to fully parse and report all live heap regions. > > For active, non-relocating pages the patch simply returns [start, top) > and for pages being actively relocated, it reports regions containing > the non-forwarded objects, the other objects are either dead or could > be found in one of the to-regions. > > With this patch I'm able to get heap histograms with ZGC. > > Maybe this is enough to enable a bit more SA debugging capabilities > when running with ZGC? What do you think, should we bring in this change? > > To be able to implement this more cleanly I've restructured the live > region collection, and pushed GC specific code into the specific GCs. > There are some extra usage of generics to make the code a bit easier > to read and develop. > > Thanks, > StefanK From kim.barrett at oracle.com Fri Feb 15 20:47:03 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:47:03 -0500 Subject: RFR (S): 8219098: Make output of region strings more regular in error messages In-Reply-To: References: Message-ID: > On Feb 15, 2019, at 8:51 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this change that improves (regularizes) the > output of verification error messages to use the existing > HR_FORMAT/HR_FORMAT_PARAMS that include the HeapRegion number instead > of fixing this in every message? > > The HeapRegion number is much more easy to read and understand than a > set of addresses. > > I.e. this has been the n-th time I had added region numbers to these > messages manually while debugging some other changes, and so I thought > it would be worthwhile fixing this in mainline. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219098 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219098/webrev/ > Testing: > compilation > > Thanks, > Thomas Looks good. From kim.barrett at oracle.com Fri Feb 15 20:50:30 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:50:30 -0500 Subject: RFR (XS): 8218920: Scan HCC should be on the same level as Update RS etc. in the log In-Reply-To: References: Message-ID: <5F1D0E84-D5BC-4B96-813F-58AFEFF5E37D@oracle.com> > On Feb 15, 2019, at 8:34 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this change that moves the "Scan HCC" phase > into the correct position (corresponding to the execution) in the log? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218920 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218920/webrev/ > Testing: > modified test case passes, log file looks correct now > > Thanks, > Thomas Looks good. From kim.barrett at oracle.com Fri Feb 15 20:48:51 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:48:51 -0500 Subject: RFR (T): 8219097: Move comment about using weak code blobs closure for code root scanning to correct place In-Reply-To: <354f93ed39b46e2db864e4fd47d20120176de5d0.camel@oracle.com> References: <354f93ed39b46e2db864e4fd47d20120176de5d0.camel@oracle.com> Message-ID: <47D79302-6BC1-415A-820F-15300FAB0556@oracle.com> > On Feb 15, 2019, at 8:47 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for moving a comment to the correct place? > Sometime in the 9-11 timeframe the code moved without the comment. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219097 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219097/webrev/ > Testing: > compilation > > Thomas Looks good, and trivial. From kim.barrett at oracle.com Fri Feb 15 21:23:13 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 16:23:13 -0500 Subject: RFR (XS): 8218672: AOT code root scanning shows in the wrong position in the logs In-Reply-To: References: Message-ID: > On Feb 15, 2019, at 8:27 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this small change that fixes the position of > the "AOT Code Root Scan" phase, moving it to appear under the "Ext Root > Scan" phase where it is handled in? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218672/webrev/ > Testing: > hs-tier5 (there is some jfr test case that complains if the phase names > were messed up) > > Thanks, > Thomas Looks good. It took a while for me to figure out where the printing of the AOT Code Roots time had gone. It might be nice to have a couple of named constants for the range of ExtRootScan sub-phases, for use as the iteration bounds in print_evacuate_collection_set. From kim.barrett at oracle.com Fri Feb 15 21:31:39 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 16:31:39 -0500 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: References: Message-ID: <153447B9-E776-4EA1-8E90-644EE62292A6@oracle.com> > On Feb 15, 2019, at 8:43 AM, Thomas Schatzl wrote: > > Hi, > > can I have reviews for this change that merges the termination > statistics into the regular log file (there were only two metrics left, > LAB waste and LAB undo waste), and remove the termination stats > afterwards? > > I (very) rarely use these metrics, so I thought it would be better to > keep them (and not just removing the entire termination stats). > > I was undecided whether it would be good to hide these under the > gc+phases=trace level though, so opinions welcome. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219096 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219096/webrev/ > Testing: > log output verification, test case update > > Thanks, > Thomas Looks good. From per.liden at oracle.com Mon Feb 18 06:44:19 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 07:44:19 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: References: Message-ID: Hi Erik, On 02/14/2019 12:55 PM, Erik ?sterlund wrote: > Hi, > > An nmethod goes from being is_alive() to being !is_alive() and > eventually being freed in nmethod::flush. Native structures for nmethods > are freed in nmethod::flush when we free the nmethod. Except for a few > things, including GC data. This enhancement proposes to fix that to make > the life cycle of nmethods and their native data more intuitive. > > In particular ZGC has per-nmethod data. The data is removed when > unlinking nmethods, as opposed to when they are deleted. This is a bit > awkward and makes things more difficult than they need to be. This patch > adds a new CollectedHeap::flush_nmethod() function. In there ZGC deletes > its attached GC data. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8218974 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ Do we need to introduce a new flush_nmethod()? Would it instead be possible to move/adjust where unregister_nmethod() is called to get the same effect? When just looking at the API, the relationship between unregister and flush is not super obvious. Determining which one will be called first and what a GC allowed/supposed to do in each of them kind of requires you to inspect the call-sites. cheers, Per From erik.osterlund at oracle.com Mon Feb 18 08:11:06 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 18 Feb 2019 09:11:06 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: References: Message-ID: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> Hi Per, On 2019-02-18 07:44, Per Liden wrote: > Hi Erik, > > On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >> Hi, >> >> An nmethod goes from being is_alive() to being !is_alive() and >> eventually being freed in nmethod::flush. Native structures for >> nmethods are freed in nmethod::flush when we free the nmethod. Except >> for a few things, including GC data. This enhancement proposes to fix >> that to make the life cycle of nmethods and their native data more >> intuitive. >> >> In particular ZGC has per-nmethod data. The data is removed when >> unlinking nmethods, as opposed to when they are deleted. This is a bit >> awkward and makes things more difficult than they need to be. This >> patch adds a new CollectedHeap::flush_nmethod() function. In there ZGC >> deletes its attached GC data. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8218974 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ > > Do we need to introduce a new flush_nmethod()? Would it instead be > possible to move/adjust where unregister_nmethod() is called to get the > same effect? When just looking at the API, the relationship between > unregister and flush is not super obvious. Determining which one will be > called first and what a GC allowed/supposed to do in each of them kind > of requires you to inspect the call-sites. I think of it this way: unregister_nmethod is tied to the lifecycle of the nmethod oops, and flush_nmethod is for the nmethod itself. In particular, we call unregister_nmethod when an nmethod dies (becomes !is_alive()). When an nmethod has died, the oops should not be retained. In fact, when the nmethod becomes unloaded, it dies specifically because the oops are dead, forcing us to kill the nmethod. Then we unregister to tell the GC not to look at those oops again. If we moved unregister_nmethod to nmethod::flush, we would keep around nmethods with broken oops in GC data structures, and the GC could no longer trust those data structures, unless we rewrote them to take into consideration that the oops they maintain could be dead if the host nmethod has silently died. But I don't think that would be an improvement. Because of this, I think it is wise to separate between GC events for the nmethod dying, and being deleted, because they have different implications. Thanks, /Erik > cheers, > Per From erik.osterlund at oracle.com Mon Feb 18 09:35:15 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 18 Feb 2019 10:35:15 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <93c4eff6-b88a-ecb7-9e4b-f4bc602735c9@oracle.com> References: <93c4eff6-b88a-ecb7-9e4b-f4bc602735c9@oracle.com> Message-ID: <19497024-7f34-aba3-4e04-dc320315ae6c@oracle.com> Hi Stefan, Looks good! Thanks, /Erik On 2019-02-15 20:25, Stefan Karlsson wrote: > Testing showed that the re-enabling of the retiring of TLABs was > broken. This has been fixed with this patch: > > http://cr.openjdk.java.net/~stefank/8218922/webrev.03.delta > http://cr.openjdk.java.net/~stefank/8218922/webrev.03 > > During mark start we change what's considered the "good" view of the > heap, and if -XX:+ZUnmapBadViews is turned on we actually unmap the > previous good view. This happens before TLABs are retired and filler > objects get written. This used to work when we didn't create filler > objects for TLABs, but know that we do, we need to ensure that the > TLAB pointers have the correct colors, otherwise we'll end up crashing > when -XX:+ZUnmapBadViews are used. > > With this fix, the patches passes tier1,tier2, and tier3 testing. > > Thanks, > StefanK > > On 2019-02-13 15:52, Stefan Karlsson wrote: >> Hi all, >> >> Please review / comment on this patch to enable a best-effort live >> heap region iteration implementation in ZGC. >> >> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218922 >> >> The SA has functionally that relies on live heap region information >> from the GCs. This is problematic when dead objects are left in the >> heap, and their classes have been unloaded. >> >> Because of this ZGC has so far not implemented this feature. However, >> we could provide a best-effort implementation that most likely will >> work if classes are not unloaded (or class unloading is turned off), >> and otherwise might fail to fully parse and report all live heap >> regions. >> >> For active, non-relocating pages the patch simply returns [start, >> top) and for pages being actively relocated, it reports regions >> containing the non-forwarded objects, the other objects are either >> dead or could be found in one of the to-regions. >> >> With this patch I'm able to get heap histograms with ZGC. >> >> Maybe this is enough to enable a bit more SA debugging capabilities >> when running with ZGC? What do you think, should we bring in this >> change? >> >> To be able to implement this more cleanly I've restructured the live >> region collection, and pushed GC specific code into the specific GCs. >> There are some extra usage of generics to make the code a bit easier >> to read and develop. >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Mon Feb 18 09:37:45 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 18 Feb 2019 10:37:45 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <19497024-7f34-aba3-4e04-dc320315ae6c@oracle.com> References: <93c4eff6-b88a-ecb7-9e4b-f4bc602735c9@oracle.com> <19497024-7f34-aba3-4e04-dc320315ae6c@oracle.com> Message-ID: <39c4e19e-db41-42af-0b01-bf461cfb5766@oracle.com> Thanks, Erik. StefanK On 2019-02-18 10:35, Erik ?sterlund wrote: > Hi Stefan, > > Looks good! > > Thanks, > /Erik > > On 2019-02-15 20:25, Stefan Karlsson wrote: >> Testing showed that the re-enabling of the retiring of TLABs was >> broken. This has been fixed with this patch: >> >> http://cr.openjdk.java.net/~stefank/8218922/webrev.03.delta >> http://cr.openjdk.java.net/~stefank/8218922/webrev.03 >> >> During mark start we change what's considered the "good" view of the >> heap, and if -XX:+ZUnmapBadViews is turned on we actually unmap the >> previous good view. This happens before TLABs are retired and filler >> objects get written. This used to work when we didn't create filler >> objects for TLABs, but know that we do, we need to ensure that the >> TLAB pointers have the correct colors, otherwise we'll end up crashing >> when -XX:+ZUnmapBadViews are used. >> >> With this fix, the patches passes tier1,tier2, and tier3 testing. >> >> Thanks, >> StefanK >> >> On 2019-02-13 15:52, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review / comment on this patch to enable a best-effort live >>> heap region iteration implementation in ZGC. >>> >>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>> >>> The SA has functionally that relies on live heap region information >>> from the GCs. This is problematic when dead objects are left in the >>> heap, and their classes have been unloaded. >>> >>> Because of this ZGC has so far not implemented this feature. However, >>> we could provide a best-effort implementation that most likely will >>> work if classes are not unloaded (or class unloading is turned off), >>> and otherwise might fail to fully parse and report all live heap >>> regions. >>> >>> For active, non-relocating pages the patch simply returns [start, >>> top) and for pages being actively relocated, it reports regions >>> containing the non-forwarded objects, the other objects are either >>> dead or could be found in one of the to-regions. >>> >>> With this patch I'm able to get heap histograms with ZGC. >>> >>> Maybe this is enough to enable a bit more SA debugging capabilities >>> when running with ZGC? What do you think, should we bring in this >>> change? >>> >>> To be able to implement this more cleanly I've restructured the live >>> region collection, and pushed GC specific code into the specific GCs. >>> There are some extra usage of generics to make the code a bit easier >>> to read and develop. >>> >>> Thanks, >>> StefanK >> > From shade at redhat.com Mon Feb 18 10:54:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 11:54:43 +0100 Subject: RFR (S) 8215221: Serial GC misreports young GC time In-Reply-To: References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> Message-ID: On 1/24/19 4:37 PM, Aleksey Shipilev wrote: > Okay, another attempt. This restructures the code a little bit, which IMO makes the flow more > understandable. It also eliminates a few flags. Then, the placement for GCTraceTime becomes natural. > Well, almost, because it requires some dance around should_do_full_collection, if we want to include > young-only epilog into timing. > > See: > http://cr.openjdk.java.net/~shade/8215221/webrev.02/ > > This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. > then. Friendly reminder. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Feb 18 14:08:44 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Feb 2019 15:08:44 +0100 Subject: RFR(T): 8219232: Unit of concurrent active time logging is wrong Message-ID: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> Hi, please review this trivial fix: diff -r 2a78b2963793 src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp --- a/src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp Wed Feb 13 13:27:17 2019 +0100 +++ b/src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp Mon Feb 18 15:05:56 2019 +0100 @@ -2761,7 +2761,7 @@ CMSPhaseAccounting::~CMSPhaseAccounting() { _collector->gc_timer_cm()->register_gc_concurrent_end(); _collector->stopTimer(); - log_debug(gc)("Concurrent active time: %.3fms", TimeHelper::counter_to_seconds(_collector->timerTicks())); + log_debug(gc)("Concurrent active time: %.3fms", TimeHelper::counter_to_millis(_collector->timerTicks())); log_trace(gc)(" (CMS %s yielded %d times)", _title, _collector->yields()); } Thanks, Tobias From shade at redhat.com Mon Feb 18 14:13:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 15:13:31 +0100 Subject: RFR(T): 8219232: Unit of concurrent active time logging is wrong In-Reply-To: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> References: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> Message-ID: On 2/18/19 3:08 PM, Tobias Hartmann wrote: > diff -r 2a78b2963793 src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp > --- a/src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp Wed Feb 13 13:27:17 2019 +0100 > +++ b/src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp Mon Feb 18 15:05:56 2019 +0100 > @@ -2761,7 +2761,7 @@ > CMSPhaseAccounting::~CMSPhaseAccounting() { > _collector->gc_timer_cm()->register_gc_concurrent_end(); > _collector->stopTimer(); > - log_debug(gc)("Concurrent active time: %.3fms", > TimeHelper::counter_to_seconds(_collector->timerTicks())); > + log_debug(gc)("Concurrent active time: %.3fms", > TimeHelper::counter_to_millis(_collector->timerTicks())); > log_trace(gc)(" (CMS %s yielded %d times)", _title, _collector->yields()); > } Looks good to me. I assume you have eyeballed the output to make sense now? -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Feb 18 14:26:11 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Feb 2019 15:26:11 +0100 Subject: RFR(T): 8219232: Unit of concurrent active time logging is wrong In-Reply-To: References: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> Message-ID: Thanks Aleksey. On 18.02.19 15:13, Aleksey Shipilev wrote: > Looks good to me. I assume you have eyeballed the output to make sense now? Yes, before: [0,383s][info ][gc] GC(8) Concurrent Mark [0,391s][debug][gc] GC(8) Concurrent active time: 0,008ms And after: [0,371s][info ][gc] GC(8) Concurrent Mark [0,379s][debug][gc] GC(8) Concurrent active time: 7,069ms Best regards, Tobias From shade at redhat.com Mon Feb 18 14:29:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 15:29:07 +0100 Subject: RFR(T): 8219232: Unit of concurrent active time logging is wrong In-Reply-To: References: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> Message-ID: On 2/18/19 3:26 PM, Tobias Hartmann wrote: > Thanks Aleksey. > > On 18.02.19 15:13, Aleksey Shipilev wrote: >> Looks good to me. I assume you have eyeballed the output to make sense now? > > Yes, before: > [0,383s][info ][gc] GC(8) Concurrent Mark > [0,391s][debug][gc] GC(8) Concurrent active time: 0,008ms > > And after: > [0,371s][info ][gc] GC(8) Concurrent Mark > [0,379s][debug][gc] GC(8) Concurrent active time: 7,069ms Excellent. Ship it. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Feb 18 14:34:31 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Feb 2019 15:34:31 +0100 Subject: RFR(T): 8219232: Unit of concurrent active time logging is wrong In-Reply-To: References: <24e6d317-f109-08c6-eb63-81d7d75552e7@oracle.com> Message-ID: <2b204670-1bce-1424-b8d5-068322b73522@oracle.com> Thanks, pushed. Best regards, Tobias On 18.02.19 15:29, Aleksey Shipilev wrote: > On 2/18/19 3:26 PM, Tobias Hartmann wrote: >> Thanks Aleksey. >> >> On 18.02.19 15:13, Aleksey Shipilev wrote: >>> Looks good to me. I assume you have eyeballed the output to make sense now? >> >> Yes, before: >> [0,383s][info ][gc] GC(8) Concurrent Mark >> [0,391s][debug][gc] GC(8) Concurrent active time: 0,008ms >> >> And after: >> [0,371s][info ][gc] GC(8) Concurrent Mark >> [0,379s][debug][gc] GC(8) Concurrent active time: 7,069ms > > Excellent. Ship it. > > -Aleksey > From kevin.walls at oracle.com Mon Feb 18 16:07:10 2019 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 18 Feb 2019 16:07:10 +0000 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC In-Reply-To: <5a43cff8-9167-eb56-5e2a-c6c7e38be332@oracle.com> References: <1e2187a4-8074-0a01-cc55-466d7136d871@gmail.com> <090b1f1a-1a1f-e624-9d9c-2fd81bd21912@oracle.com> <826b7b9f-3647-aa2a-d9d2-e319a4c84797@oracle.com> <5a43cff8-9167-eb56-5e2a-c6c7e38be332@oracle.com> Message-ID: Great, thanks Stefan, that collection of changes builds for me and I've seem the histogram from a live process using ZGC, and a core of the same.? Fantastic. 8-) On 15/02/2019 19:06, Stefan Karlsson wrote: > Hi Kevin, > > On 2019-02-15 13:14, Kevin Walls wrote: >> Hi Stefan, >> >> This is great - if I want to try it out, what order do the changes >> apply, does the 8218746 webrev apply to create ZExternalBitMap.java >> and then the 8218922 webrev? > This is my patch queue of outgoing patches: > ?zSA.fixVMObjectFactory.8218731 > ?zSA.fixPhysical.8218732 > ?zSA.heapUsedCapacity.8218733 > ?zSA.resolveOopHandle.8218734 > ?zSA.bitMapsSegmented.8218743 > ?zSA.bitMapsZ.8218746 > ?zSA.pagesIterate.refactor.8219003 > ?zSA.pagesIterate.8218922.Z > ?zSA.turnOnHprof.8218970 > ?zSA.turnOnTests.8218978 > > I've created one big webrev over all these changes: > ?https://cr.openjdk.java.net/~stefank/zgc/zSABitMapsAndLiveRegions/webrev/ > > > StefanK > >> >> Thanks >> Kevin >> >> >> On 14/02/2019 17:12, Stefan Karlsson wrote: >>> Hi again, >>> >>> I've separated the live regions iteration refactoring into this patch: >>> https://cr.openjdk.java.net/~stefank/8219003/webrev.01/ >>> >>> And use this RFE for the ZGC specific parts: >>> https://cr.openjdk.java.net/~stefank/8218922/webrev.02/ >>> >>> Thanks, >>> StefanK >>> >>> On 2019-02-14 14:39, Stefan Karlsson wrote: >>>> Hi Yasumasa, >>>> >>>> On 2019-02-14 14:11, Yasumasa Suenaga wrote: >>>>> Hi Stefan, >>>>> >>>>>> Maybe this is enough to enable a bit more SA debugging >>>>>> capabilities when >>>>>> running with ZGC? What do you think, should we bring in this change? >>>>> >>>>> I think it should be brought this in. >>>>> I filed same issue as JDK-8207843, but I've not yet worked. >>>>> So I will close it as duplicate of your change. >>>>> >>>>> >>>>>> To be able to implement this more cleanly I've restructured the live >>>>>> region collection, and pushed GC specific code into the specific >>>>>> GCs. >>>>>> There are some extra usage of generics to make the code a bit >>>>>> easier to >>>>>> read and develop. >>>>> >>>>> IMHO refactoring for live region collection and ZGC related >>>>> changes should >>>>> be separated. What do you think? >>>> >>>> Yes. I think that would be good. I'll separate this out into two >>>> changes. >>>> >>>>> >>>>> >>>>> Your change looks good to me. >>>>> BTW, did you check `jhsdb jmap --binaryheap` with this change? >>>>> >>>> >>>> Yes, when testing this I ran all tests in serviceability/sa and >>>> manually tested the command above. >>>> >>>> While testing this I also had this patch applied to enable SA hprof >>>> for ZGC: >>>> http://cr.openjdk.java.net/~stefank/8218970/webrev.01/ >>>> >>>> And used this patch to turn off the ZGC filtering in the tests: >>>> http://cr.openjdk.java.net/~stefank/8218978/webrev.01/ >>>> >>>> I'm currently rerunning the tests to see that the latest changes >>>> didn't break anything. >>>> >>>> Thanks, >>>> StefanK >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> >>>>> On 2019/02/13 23:52, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review / comment on this patch to enable a best-effort >>>>>> live heap >>>>>> region iteration implementation in ZGC. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8218922 >>>>>> >>>>>> The SA has functionally that relies on live heap region >>>>>> information from >>>>>> the GCs. This is problematic when dead objects are left in the >>>>>> heap, and >>>>>> their classes have been unloaded. >>>>>> >>>>>> Because of this ZGC has so far not implemented this feature. >>>>>> However, we >>>>>> could provide a best-effort implementation that most likely will >>>>>> work if >>>>>> classes are not unloaded (or class unloading is turned off), and >>>>>> otherwise might fail to fully parse and report all live heap >>>>>> regions. >>>>>> >>>>>> For active, non-relocating pages the patch simply returns [start, >>>>>> top) >>>>>> and for pages being actively relocated, it reports regions >>>>>> containing >>>>>> the non-forwarded objects, the other objects are either dead or >>>>>> could be >>>>>> found in one of the to-regions. >>>>>> >>>>>> With this patch I'm able to get heap histograms with ZGC. >>>>>> >>>>>> Maybe this is enough to enable a bit more SA debugging >>>>>> capabilities when >>>>>> running with ZGC? What do you think, should we bring in this change? >>>>>> >>>>>> To be able to implement this more cleanly I've restructured the live >>>>>> region collection, and pushed GC specific code into the specific >>>>>> GCs. >>>>>> There are some extra usage of generics to make the code a bit >>>>>> easier to >>>>>> read and develop. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>> > From rkennke at redhat.com Mon Feb 18 17:13:43 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Feb 2019 18:13:43 +0100 Subject: RFR: JDK-8219245: Shenandoah: Resolve oops in SATB filter Message-ID: When updating reference is piggy-backed on marking phase, we need to resolve oops that we get in SATB buffers before checking if they are marked, because from-space oops never get marked. This generates unnecessary traffic in SATB. Fix is to add template to requires_marking() that optionally resolves the object, and use that when we may see forwarded objects. Bug: https://bugs.openjdk.java.net/browse/JDK-8219245 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8219245/webrev.00/ Testing: hotspot_gc_shenandoah looks good Ok? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Feb 18 17:17:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 18:17:34 +0100 Subject: RFR: JDK-8219245: Shenandoah: Resolve oops in SATB filter In-Reply-To: References: Message-ID: <7f5e09ef-ee17-6a08-91eb-cd777f2afcf4@redhat.com> On 2/18/19 6:13 PM, Roman Kennke wrote: > When updating reference is piggy-backed on marking phase, we need to > resolve oops that we get in SATB buffers before checking if they are > marked, because from-space oops never get marked. This generates > unnecessary traffic in SATB. > > Fix is to add template to requires_marking() that optionally resolves > the object, and use that when we may see forwarded objects. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219245 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8219245/webrev.00/ Um. I think true/false are swapped here: 68 if (_heap->has_forwarded_objects()) { 69 apply_filter(ShenandoahSATBMarkQueueFilterFn(_heap), queue); 70 } else { 71 apply_filter(ShenandoahSATBMarkQueueFilterFn(_heap), queue); 72 } ...if there are forwarded objects, you want to resolve. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Mon Feb 18 17:23:32 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Feb 2019 18:23:32 +0100 Subject: RFR: JDK-8219245: Shenandoah: Resolve oops in SATB filter In-Reply-To: <7f5e09ef-ee17-6a08-91eb-cd777f2afcf4@redhat.com> References: <7f5e09ef-ee17-6a08-91eb-cd777f2afcf4@redhat.com> Message-ID: <5151f8f7-ff14-c8d9-fe95-6610ac1b6ae9@redhat.com> >> When updating reference is piggy-backed on marking phase, we need to >> resolve oops that we get in SATB buffers before checking if they are >> marked, because from-space oops never get marked. This generates >> unnecessary traffic in SATB. >> >> Fix is to add template to requires_marking() that optionally resolves >> the object, and use that when we may see forwarded objects. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219245 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8219245/webrev.00/ > > Um. I think true/false are swapped here: > > 68 if (_heap->has_forwarded_objects()) { > 69 apply_filter(ShenandoahSATBMarkQueueFilterFn(_heap), queue); > 70 } else { > 71 apply_filter(ShenandoahSATBMarkQueueFilterFn(_heap), queue); > 72 } > > ...if there are forwarded objects, you want to resolve. NOOOOOOOOoooooooooooo........... I just made one of the most embarrasing bugs an order of magnitude more embarrassing. Nobody has seen this, ok? http://cr.openjdk.java.net/~rkennke/JDK-8219245/webrev.01/ Ok now? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Feb 18 17:26:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 18:26:20 +0100 Subject: RFR: JDK-8219245: Shenandoah: Resolve oops in SATB filter In-Reply-To: <5151f8f7-ff14-c8d9-fe95-6610ac1b6ae9@redhat.com> References: <7f5e09ef-ee17-6a08-91eb-cd777f2afcf4@redhat.com> <5151f8f7-ff14-c8d9-fe95-6610ac1b6ae9@redhat.com> Message-ID: <24272976-533a-5069-c960-625865c33f4b@redhat.com> On 2/18/19 6:23 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8219245/webrev.01/ Looks good. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From leo.korinth at oracle.com Tue Feb 19 10:16:09 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 19 Feb 2019 11:16:09 +0100 Subject: RFR (XS): 8218672: AOT code root scanning shows in the wrong position in the logs In-Reply-To: References: Message-ID: Looks good. Thanks, Leo On 15/02/2019 14:27, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change that fixes the position of > the "AOT Code Root Scan" phase, moving it to appear under the "Ext Root > Scan" phase where it is handled in? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218672/webrev/ > Testing: > hs-tier5 (there is some jfr test case that complains if the phase names > were messed up) > > Thanks, > Thomas > From leo.korinth at oracle.com Tue Feb 19 11:01:48 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 19 Feb 2019 12:01:48 +0100 Subject: RFR (XS): 8218920: Scan HCC should be on the same level as Update RS etc. in the log In-Reply-To: References: Message-ID: Looks good. Thanks, Leo On 15/02/2019 14:34, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that moves the "Scan HCC" phase > into the correct position (corresponding to the execution) in the log? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218920 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218920/webrev/ > Testing: > modified test case passes, log file looks correct now > > Thanks, > Thomas > From thomas.schatzl at oracle.com Tue Feb 19 11:45:14 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 19 Feb 2019 12:45:14 +0100 Subject: RFR (XS): 8218672: AOT code root scanning shows in the wrong position in the logs In-Reply-To: References: Message-ID: <8aa2e9e0e39881b2cc1aa39aec5179a10b90afcb.camel@oracle.com> Hi Leo, Kim, On Fri, 2019-02-15 at 16:23 -0500, Kim Barrett wrote: > > On Feb 15, 2019, at 8:27 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this small change that fixes the position > > of the "AOT Code Root Scan" phase, moving it to appear under the > > "Ext Root Scan" phase where it is handled in? > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8218672 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8218672/webrev/ > > Testing: > > hs-tier5 (there is some jfr test case that complains if the phase > > names > > were messed up) > > > > Thanks, > > Thomas > > Looks good. > thanks for your review. > It took a while for me to figure out where the printing of the AOT > Code Roots time had gone. It might be nice to have a couple of named > constants for the range of ExtRootScan sub-phases, for use as the > iteration bounds in print_evacuate_collection_set. I will add these in a separate CR. Thomas From thomas.schatzl at oracle.com Tue Feb 19 11:43:40 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 19 Feb 2019 12:43:40 +0100 Subject: RFR (XS): 8218920: Scan HCC should be on the same level as Update RS etc. in the log In-Reply-To: References: Message-ID: Hi Kim and Leo, On Tue, 2019-02-19 at 12:01 +0100, Leo Korinth wrote: > Looks good. > > Thanks, > Leo > thanks for your reviews. Thomas From thomas.schatzl at oracle.com Tue Feb 19 11:48:26 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 19 Feb 2019 12:48:26 +0100 Subject: RFR (T): 8219097: Move comment about using weak code blobs closure for code root scanning to correct place In-Reply-To: <47D79302-6BC1-415A-820F-15300FAB0556@oracle.com> References: <354f93ed39b46e2db864e4fd47d20120176de5d0.camel@oracle.com> <47D79302-6BC1-415A-820F-15300FAB0556@oracle.com> Message-ID: <5e6a993366535aa0c2163c23eccaad46fd11e075.camel@oracle.com> Hi Kim, On Fri, 2019-02-15 at 15:48 -0500, Kim Barrett wrote: > > On Feb 15, 2019, at 8:47 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for moving a comment to the correct place? > > Sometime in the 9-11 timeframe the code moved without the comment. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8219097 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8219097/webrev/ > > Testing: > > compilation > > > > Thomas > > Looks good, and trivial. > thanks for your review. Thomas From thomas.schatzl at oracle.com Tue Feb 19 12:15:52 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 19 Feb 2019 13:15:52 +0100 Subject: RFR (S): 8219098: Make output of region strings more regular in error messages In-Reply-To: References: Message-ID: <28c8b9c5f3c4c5cb9a02b3b560d9d5e1e5a32011.camel@oracle.com> Hi, On Fri, 2019-02-15 at 15:47 -0500, Kim Barrett wrote: > > On Feb 15, 2019, at 8:51 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this change that improves (regularizes) the > > [...] > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8219098 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8219098/webrev/ > > Testing: > > compilation > > > > Thanks, > > Thomas > > Looks good. > thanks for your review, Thomas From per.liden at oracle.com Tue Feb 19 13:40:22 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Feb 2019 14:40:22 +0100 Subject: RFR: 8219331: ZGC: Unify TLAB retire/remap handling Message-ID: Unify TLAB retire/remap handling. Bug: https://bugs.openjdk.java.net/browse/JDK-8219331 Webrev: http://cr.openjdk.java.net/~pliden/8219331/webrev.0 /Per From per.liden at oracle.com Tue Feb 19 13:40:26 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Feb 2019 14:40:26 +0100 Subject: RFR: 8219332: ZGC: Improve ZRootsIteratorClosure abstraction Message-ID: <462d7937-737e-7383-269b-b200d2882ddd@oracle.com> Remove the need to call the super class in all implementors of ZRootsIteratorClosure::do_thread() . Bug: https://bugs.openjdk.java.net/browse/JDK-8219332 Webrev: http://cr.openjdk.java.net/~pliden/8219332/webrev.0 /Per From per.liden at oracle.com Tue Feb 19 13:40:30 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 19 Feb 2019 14:40:30 +0100 Subject: RFR: 8218767: ZGC: Do not assume that r12 is a special register in C2 Message-ID: The C2 load barrier code for ZGC assumes that r12 is not used as a general purpose register. However, JDK-8217909 might change that, so ZGC should not be making this assumption. Bug: https://bugs.openjdk.java.net/browse/JDK-8218767 Webrev: http://cr.openjdk.java.net/~pliden/8218767/webrev.0 /Per From stefan.karlsson at oracle.com Tue Feb 19 13:59:38 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Feb 2019 14:59:38 +0100 Subject: RFR: 8219331: ZGC: Unify TLAB retire/remap handling In-Reply-To: References: Message-ID: Looks good. StefanK On 2019-02-19 14:40, Per Liden wrote: > Unify TLAB retire/remap handling. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219331 > Webrev: http://cr.openjdk.java.net/~pliden/8219331/webrev.0 > > /Per From stefan.karlsson at oracle.com Tue Feb 19 14:00:24 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Feb 2019 15:00:24 +0100 Subject: RFR: 8219332: ZGC: Improve ZRootsIteratorClosure abstraction In-Reply-To: <462d7937-737e-7383-269b-b200d2882ddd@oracle.com> References: <462d7937-737e-7383-269b-b200d2882ddd@oracle.com> Message-ID: <1d13a094-28e5-6313-27df-1998d46f429c@oracle.com> Looks good. StefanK On 2019-02-19 14:40, Per Liden wrote: > Remove the need to call the super class in all implementors of > ZRootsIteratorClosure::do_thread() . > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219332 > Webrev: http://cr.openjdk.java.net/~pliden/8219332/webrev.0 > > /Per From leo.korinth at oracle.com Tue Feb 19 14:52:19 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 19 Feb 2019 15:52:19 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: References: Message-ID: Hi! On 15/02/2019 14:43, Thomas Schatzl wrote: > Hi, > > can I have reviews for this change that merges the termination > statistics into the regular log file (there were only two metrics left, > LAB waste and LAB undo waste), and remove the termination stats > afterwards? > > I (very) rarely use these metrics, so I thought it would be better to > keep them (and not just removing the entire termination stats). > > I was undecided whether it would be good to hide these under the > gc+phases=trace level though, so opinions welcome. I have no opinion on this. However, I dislike the conversion from heap words to bytes in the middle of everything. I would prefer to have the conversion as early as possible, or maybe better, as late as possible (as it was before). It is easy to miss that size_t G1ParScanThreadState::lab_waste() and size_t G1PLABAllocator::waste() use different "units". However if this was done on purpose with good reasons, just ignore my comment. That, and update copyrights and the change looks good to me. Thanks, Leo > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219096 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219096/webrev/ > Testing: > log output verification, test case update > > Thanks, > Thomas > > From leo.korinth at oracle.com Tue Feb 19 15:55:37 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Tue, 19 Feb 2019 16:55:37 +0100 Subject: RFR (S): 8219098: Make output of region strings more regular in error messages In-Reply-To: References: Message-ID: Hi! Thanks for making output more regular, change looks great except update of copyright years. Maybe you should do a fast visual examination of logs if you have not already done that, format string errors are easy to make... Thanks, Leo On 15/02/2019 14:51, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that improves (regularizes) the > output of verification error messages to use the existing > HR_FORMAT/HR_FORMAT_PARAMS that include the HeapRegion number instead > of fixing this in every message? > > The HeapRegion number is much more easy to read and understand than a > set of addresses. > > I.e. this has been the n-th time I had added region numbers to these > messages manually while debugging some other changes, and so I thought > it would be worthwhile fixing this in mainline. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219098 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219098/webrev/ > Testing: > compilation > > Thanks, > Thomas > From kim.barrett at oracle.com Tue Feb 19 22:18:40 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Feb 2019 17:18:40 -0500 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> Message-ID: <1A7E2F33-2E26-4451-8CBD-9B5804941C0D@oracle.com> > On Jan 24, 2019, at 10:37 AM, Aleksey Shipilev wrote: > > On 12/18/18 4:52 PM, Kim Barrett wrote: >>> On Dec 11, 2018, at 3:23 PM, Aleksey Shipilev wrote: >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8215221 >>> >>> One of our guys pointed out the oddity in Serial GC logs: "Pause Young" includes the timing for Full >>> collection, and wrecks up GCId order as well. This is because GCTraceTime-s are nested on those >>> paths, and putting them in proper order, closer to collect_generation, fixes it. >>> >>> The downside is that some of the cleanup actions are now outside the GCTraceTime. Those look >>> innocuous to omit to me, though. >> >> ClassLoaderDataGraph::purge() doesn?t look so innocuous. I haven?t >> looked hard at other stuff being omitted from accounting by this change. >> >> It seems to me that fixing this reporting problem might require some >> restructuring of this rather complicated and flag-filled function. > > Okay, another attempt. This restructures the code a little bit, which IMO makes the flow more > understandable. It also eliminates a few flags. Then, the placement for GCTraceTime becomes natural. > Well, almost, because it requires some dance around should_do_full_collection, if we want to include > young-only epilog into timing. > > See: > http://cr.openjdk.java.net/~shade/8215221/webrev.02/ > > This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. > then. > > -Aleksey Thanks; this looks somewhat better to me. It seems like there should be more opportunities for cleanup here, but doing much more might require a complete top to bottom rewrite of this function. Since I don't have any concrete suggestions for further changes right now, looks good. From shade at redhat.com Wed Feb 20 09:15:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Feb 2019 10:15:03 +0100 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: <1A7E2F33-2E26-4451-8CBD-9B5804941C0D@oracle.com> References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> <1A7E2F33-2E26-4451-8CBD-9B5804941C0D@oracle.com> Message-ID: <26b1b5d2-40b1-0219-213d-ab34f185dd2d@redhat.com> On 2/19/19 11:18 PM, Kim Barrett wrote: >> See: >> http://cr.openjdk.java.net/~shade/8215221/webrev.02/ >> >> This passes hotspot_tier1 and my ad-hoc tests. If this is the way to go, I would do jdk-submit, etc. >> then. >> >> -Aleksey > > Thanks; this looks somewhat better to me. It seems like there should > be more opportunities for cleanup here, but doing much more might > require a complete top to bottom rewrite of this function. Since I > don't have any concrete suggestions for further changes right now, > looks good. Thanks. I have been looking into how to improve this more, and it seems there are no easy opportunities there that do not involve rewriting the *callers* of GenCollectedHeap::do_collection. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Wed Feb 20 09:33:11 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 20 Feb 2019 10:33:11 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: References: Message-ID: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> Hi, On Tue, 2019-02-19 at 15:52 +0100, Leo Korinth wrote: > Hi! > > On 15/02/2019 14:43, Thomas Schatzl wrote: > > Hi, > > > > can I have reviews for this change that merges the termination > > statistics into the regular log file (there were only two metrics > > left, LAB waste and LAB undo waste), and remove the termination > > stats afterwards? > > > > I (very) rarely use these metrics, so I thought it would be better > > to keep them (and not just removing the entire termination stats). > > > > I was undecided whether it would be good to hide these under the > > gc+phases=trace level though, so opinions welcome. > > I have no opinion on this. > > However, I dislike the conversion from heap words to bytes in the > middle of everything. I would prefer to have the conversion as early > as possible, or maybe better, as late as possible (as it was before). > It is easy to miss that size_t G1ParScanThreadState::lab_waste() and > size_t G1PLABAllocator::waste() use different "units". However if > this was done on purpose with good reasons, just ignore my comment. > > That, and update copyrights and the change looks good to me. All fixed in http://cr.openjdk.java.net/~tschatzl/8219096/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8219096/webrev.1 (full) Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 20 09:52:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 20 Feb 2019 10:52:20 +0100 Subject: RFR (S): 8219098: Make output of region strings more regular in error messages In-Reply-To: References: Message-ID: Hi, On Tue, 2019-02-19 at 16:55 +0100, Leo Korinth wrote: > Hi! > > Thanks for making output more regular, change looks great except > update of copyright years. Done before pushing. Thanks for your review :) Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 20 10:15:17 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 20 Feb 2019 11:15:17 +0100 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases Message-ID: Hi all, can I have reviews for this change that has been suggested as part of another review to improve readability of the ExtRootScan sub-phase printing? In particular, it introduces a few new named constants in the GCParPhases enum that indicate start and end of the ext root scan sub- phases. These are then used in the iteration. CR: https://bugs.openjdk.java.net/browse/JDK-8219369 Webrev: http://cr.openjdk.java.net/~tschatzl/8219369/webrev/ testing: hs-tier1,hs-tier2 (includes log output testing for completeness) Thanks, Thomas From per.liden at oracle.com Wed Feb 20 10:46:17 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 20 Feb 2019 11:46:17 +0100 Subject: RFR: 8219332: ZGC: Improve ZRootsIteratorClosure abstraction In-Reply-To: <1d13a094-28e5-6313-27df-1998d46f429c@oracle.com> References: <462d7937-737e-7383-269b-b200d2882ddd@oracle.com> <1d13a094-28e5-6313-27df-1998d46f429c@oracle.com> Message-ID: <0c5a4e51-0049-f349-d209-5aa5d6a4ab02@oracle.com> Thanks Stefan! /Per On 2/19/19 3:00 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-02-19 14:40, Per Liden wrote: >> Remove the need to call the super class in all implementors of >> ZRootsIteratorClosure::do_thread() . >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219332 >> Webrev: http://cr.openjdk.java.net/~pliden/8219332/webrev.0 >> >> /Per From per.liden at oracle.com Wed Feb 20 10:46:25 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 20 Feb 2019 11:46:25 +0100 Subject: RFR: 8219331: ZGC: Unify TLAB retire/remap handling In-Reply-To: References: Message-ID: <3abe54d4-a350-22bf-fc6c-4a3792c20f04@oracle.com> Thanks Stefan! /Per On 2/19/19 2:59 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-02-19 14:40, Per Liden wrote: >> Unify TLAB retire/remap handling. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219331 >> Webrev: http://cr.openjdk.java.net/~pliden/8219331/webrev.0 >> >> /Per From per.liden at oracle.com Wed Feb 20 11:00:52 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 20 Feb 2019 12:00:52 +0100 Subject: RFR: 8218767: ZGC: Do not assume that r12 is a special register in C2 In-Reply-To: References: Message-ID: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> Updated version rebased on top of JDK-8217909 (which Roman will push soonish). http://cr.openjdk.java.net/~pliden/8218767/webrev.1 cheers, Per On 2/19/19 2:40 PM, Per Liden wrote: > The C2 load barrier code for ZGC assumes that r12 is not used as a > general purpose register. However, JDK-8217909 might change that, so ZGC > should not be making this assumption. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218767 > Webrev: http://cr.openjdk.java.net/~pliden/8218767/webrev.0 > > /Per From rkennke at redhat.com Wed Feb 20 11:08:21 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 Feb 2019 12:08:21 +0100 Subject: RFR: 8218767: ZGC: Do not assume that r12 is a special register in C2 In-Reply-To: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> References: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> Message-ID: Looks ok to me. Thanks, Roman > Updated version rebased on top of JDK-8217909 (which Roman will push > soonish). > > http://cr.openjdk.java.net/~pliden/8218767/webrev.1 > > cheers, > Per > > On 2/19/19 2:40 PM, Per Liden wrote: >> The C2 load barrier code for ZGC assumes that r12 is not used as a >> general purpose register. However, JDK-8217909 might change that, so >> ZGC should not be making this assumption. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218767 >> Webrev: http://cr.openjdk.java.net/~pliden/8218767/webrev.0 >> >> /Per -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From erik.osterlund at oracle.com Wed Feb 20 11:21:26 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 20 Feb 2019 12:21:26 +0100 Subject: RFR: 8218767: ZGC: Do not assume that r12 is a special register in C2 In-Reply-To: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> References: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> Message-ID: <0a55ffa8-878c-51f0-5e0b-f0a0aa6cfc68@oracle.com> +1 /Erik On 2019-02-20 12:00, Per Liden wrote: > Updated version rebased on top of JDK-8217909 (which Roman will push > soonish). > > http://cr.openjdk.java.net/~pliden/8218767/webrev.1 > > cheers, > Per > > On 2/19/19 2:40 PM, Per Liden wrote: >> The C2 load barrier code for ZGC assumes that r12 is not used as a >> general purpose register. However, JDK-8217909 might change that, so >> ZGC should not be making this assumption. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218767 >> Webrev: http://cr.openjdk.java.net/~pliden/8218767/webrev.0 >> >> /Per From per.liden at oracle.com Wed Feb 20 11:27:18 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 20 Feb 2019 12:27:18 +0100 Subject: RFR: 8218767: ZGC: Do not assume that r12 is a special register in C2 In-Reply-To: References: <73f36768-097d-d460-14b8-ea5683eb586c@oracle.com> Message-ID: <17017f74-db2d-1709-a23d-36dd0982d815@oracle.com> Thanks Roman and Erik! /Per On 2/20/19 12:08 PM, Roman Kennke wrote: > Looks ok to me. > > Thanks, > Roman > >> Updated version rebased on top of JDK-8217909 (which Roman will push >> soonish). >> >> http://cr.openjdk.java.net/~pliden/8218767/webrev.1 >> >> cheers, >> Per >> >> On 2/19/19 2:40 PM, Per Liden wrote: >>> The C2 load barrier code for ZGC assumes that r12 is not used as a >>> general purpose register. However, JDK-8217909 might change that, so >>> ZGC should not be making this assumption. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218767 >>> Webrev: http://cr.openjdk.java.net/~pliden/8218767/webrev.0 >>> >>> /Per > From leo.korinth at oracle.com Wed Feb 20 13:21:55 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 20 Feb 2019 14:21:55 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> References: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> Message-ID: <9a1bcb67-c286-9a27-f03f-4bca0d864bad@oracle.com> Looks good! Thanks, Leo On 20/02/2019 10:33, Thomas Schatzl wrote: > Hi, > > On Tue, 2019-02-19 at 15:52 +0100, Leo Korinth wrote: >> Hi! >> >> On 15/02/2019 14:43, Thomas Schatzl wrote: >>> Hi, >>> >>> can I have reviews for this change that merges the termination >>> statistics into the regular log file (there were only two metrics >>> left, LAB waste and LAB undo waste), and remove the termination >>> stats afterwards? >>> >>> I (very) rarely use these metrics, so I thought it would be better >>> to keep them (and not just removing the entire termination stats). >>> >>> I was undecided whether it would be good to hide these under the >>> gc+phases=trace level though, so opinions welcome. >> >> I have no opinion on this. >> >> However, I dislike the conversion from heap words to bytes in the >> middle of everything. I would prefer to have the conversion as early >> as possible, or maybe better, as late as possible (as it was before). >> It is easy to miss that size_t G1ParScanThreadState::lab_waste() and >> size_t G1PLABAllocator::waste() use different "units". However if >> this was done on purpose with good reasons, just ignore my comment. >> >> That, and update copyrights and the change looks good to me. > > All fixed in > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.1 (full) > > Thanks, > Thomas > > From kim.barrett at oracle.com Wed Feb 20 13:29:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 20 Feb 2019 08:29:16 -0500 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> References: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> Message-ID: > On Feb 20, 2019, at 4:33 AM, Thomas Schatzl wrote: > All fixed in > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.1 (full) > > Thanks, > Thomas Still looks good. From thomas.schatzl at oracle.com Wed Feb 20 13:27:22 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 20 Feb 2019 14:27:22 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: <9a1bcb67-c286-9a27-f03f-4bca0d864bad@oracle.com> References: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> <9a1bcb67-c286-9a27-f03f-4bca0d864bad@oracle.com> Message-ID: <229fc2d59c990bd29d3948daef91d7e4849bebfb.camel@oracle.com> Hi, On Wed, 2019-02-20 at 14:21 +0100, Leo Korinth wrote: > Looks good! > > Thanks, > Leo > > thanks! Thomas From thomas.schatzl at oracle.com Wed Feb 20 13:31:45 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 20 Feb 2019 14:31:45 +0100 Subject: RFR (S/M): 8219096: Merge print_termination_stats code with current logging In-Reply-To: References: <892cdc64f7fee97559aacc29ed2754050b41cb44.camel@oracle.com> Message-ID: <4db970e27c3727b0756f73d411437ba9a77995bc.camel@oracle.com> Hi Kim, On Wed, 2019-02-20 at 08:29 -0500, Kim Barrett wrote: > > On Feb 20, 2019, at 4:33 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > All fixed in > > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.0_to_1 (diff) > > http://cr.openjdk.java.net/~tschatzl/8219096/webrev.1 (full) > > > > Thanks, > > Thomas > > Still looks good. > thanks for your review. Thomas From stefan.karlsson at oracle.com Thu Feb 21 08:50:24 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 21 Feb 2019 09:50:24 +0100 Subject: RFR: ZGC ZNMethodTable changes 8219462, 8219463, 8219464, 8219466, 8219467, 8219468, 82194629 Message-ID: Hi all, Please review these patches that mostly restructures the ZNMethodTable code. The intent is to make ZNMethodTable a slimmed down table implementation, while the ZGC specific class unloading code is pulled out to a new ZNMethod sub component. A webrev of all patches can be found here: http://cr.openjdk.java.net/~stefank/zgc/zNMethod/webrev/ ------------------------------------------------------------------------ 8219462: ZGC: Use wait/notify in ZNMethodTable https://bugs.openjdk.java.net/browse/JDK-8219462 http://cr.openjdk.java.net/~stefank/8219462/webrev.01/ The nmethod sweeper is not allowed to unregister an nmethod while the GC is iterating over the ZNMethodTable. The current code spins in a loop releasing the lock and sleeping for 1 ms. I propose that we replace this with wait and notify. ------------------------------------------------------------------------ 8219463: ZGC: Remove redundant ZNMethodTable::_iter_lock https://bugs.openjdk.java.net/browse/JDK-8219463 http://cr.openjdk.java.net/~stefank/8219463/webrev.01/ The ZNMethodTable lock guards accesses with both the CodeCache_lock and it's own _iter_lock. This used to necessary because there was a path that didn't take the CodeCache_lock. A recent bug fix changed this and we always hold the CodeCache_lock when we take the _iter_lock. I propose that we remove the _iter_lock. ------------------------------------------------------------------------ 8219464: ZGC: Move nmethod oop properties from ZNMethodTableEntry to ZNMethodData https://bugs.openjdk.java.net/browse/JDK-8219464 http://cr.openjdk.java.net/~stefank/8219464/webrev.01/ The ZNMethodTableEntry contains two cached values, regarding the properties of an nmethod. The first is whether the nmethod has "immediate oops" in the code. The second property is used to indicate if the nmethod has "non immediate oop", which probably is a bad name, but it tells if there are oop-derived immediates that need to be fixed when Objects have been moved. I propose that we move these properties to the ZNMethodData objects that are attached to the nmethods via the gc specific gc_data. This allows for a cleaner separation of the proper table code in ZNMethodTable and the class ZGC class unloading code. ------------------------------------------------------------------------ 8219466: ZGC: Extract allocation functionality into a new ZNMethodAllocator class https://bugs.openjdk.java.net/browse/JDK-8219466 http://cr.openjdk.java.net/~stefank/8219466/webrev.01/ ZNMethodData delegates the responsibility to safely free it's memory to ZNMethodTable. I propose we break this dependency by introducing a ZNMethodAllocator class that both classes can use. ZNMethodTable will notify ZNMethodAllocator when its unsafe to free data and when it's time to execute the deferred frees. ZNMethodData will then simply use ZNMethodAllocator to allocate and free, and ZNMethodAllocator will handle the deferred frees under the hood. ------------------------------------------------------------------------ 8219467: ZGC: Move ZNMethodData to its own file https://bugs.openjdk.java.net/browse/JDK-8219467 http://cr.openjdk.java.net/~stefank/8219467/webrev.01/ A simple move of the code. ------------------------------------------------------------------------ 8219468: ZGC: Extract iteration functionality into a new ZNMethodTableIteration class https://bugs.openjdk.java.net/browse/JDK-8219468 http://cr.openjdk.java.net/~stefank/8219468/webrev.01/ Extracts the iteration code into its own class. This patch also changes the how tables are deleted when an iteration is in progress, to use the new ZNMethodAllocator class instead. ------------------------------------------------------------------------ 8219469: ZGC: Extract functions out from ZNMethodTable into new ZNMethod class https://bugs.openjdk.java.net/browse/JDK-8219469 http://cr.openjdk.java.net/~stefank/8219469/webrev.01/ This patch moves the non-table specific ZGC nmethod handling code out to a new ZNMethod class. ------------------------------------------------------------------------ Tested with: tier1,tier2,tier3, gc-test-suite Thanks, StefanK From shade at redhat.com Thu Feb 21 10:19:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Feb 2019 11:19:24 +0100 Subject: RFR (S) 8219524: Shenandoah misreports "committed" size in MemoryMXBean Message-ID: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8219524 Fix: http://cr.openjdk.java.net/~shade/8219524/webrev.01/ See the backing story in the bug. Arguably, this is due Shenandoah departing from what shared code believes GC implementation should be doing, i.e. returning the amount of committed memory with CollectedHeap::capacity(). Would that be a fair characterization? Even so, rewiring Shenandoah to match the shared code expectations would require more work, but we can plug the current failure with this patch meanwhile. Testing: hotspot_gc_shenandoah, new check in test Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Thu Feb 21 10:50:43 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Feb 2019 11:50:43 +0100 Subject: RFR (S) 8219524: Shenandoah misreports "committed" size in MemoryMXBean In-Reply-To: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> References: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> Message-ID: Looks good to me! Thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219524 > > Fix: > http://cr.openjdk.java.net/~shade/8219524/webrev.01/ > > See the backing story in the bug. Arguably, this is due Shenandoah departing from what shared code > believes GC implementation should be doing, i.e. returning the amount of committed memory with > CollectedHeap::capacity(). Would that be a fair characterization? Even so, rewiring Shenandoah to > match the shared code expectations would require more work, but we can plug the current failure with > this patch meanwhile. > > Testing: hotspot_gc_shenandoah, new check in test > > Thanks, > -Aleksey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From per.liden at oracle.com Thu Feb 21 12:06:26 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 21 Feb 2019 13:06:26 +0100 Subject: RFR: ZGC ZNMethodTable changes 8219462, 8219463, 8219464, 8219466, 8219467, 8219468, 82194629 In-Reply-To: References: Message-ID: <2a919008-11b6-4b10-f64e-f5a12c2a8535@oracle.com> On 2/21/19 9:50 AM, Stefan Karlsson wrote: > Hi all, > > Please review these patches that mostly restructures the ZNMethodTable > code. The intent is to make ZNMethodTable a slimmed down table > implementation, while the ZGC specific class unloading code is pulled > out to a new ZNMethod sub component. > > A webrev of all patches can be found here: > http://cr.openjdk.java.net/~stefank/zgc/zNMethod/webrev/ Since I've seen this code before Stefan sent it out I only have a few minor nits. src/hotspot/share/gc/z/zNMethodClosure.hpp ------------------------------------------ - It seems general enough to be named NMethodClosure and placed in iterator.hpp. src/hotspot/share/gc/z/zNMethodData.hpp --------------------------------------- - Include guard missing. - immediates_begin/immediates_end alignment. src/hotspot/share/gc/z/zNMethodAllocator.hpp -------------------------------------------- - "public AllStatic" - allocate/free alignment. src/hotspot/share/gc/z/zNMethod.hpp ----------------------------------- I'd like to avoid having "nmethod" in the function names, as it's given by the class context. However, calling a function "register" is problematic so I'm ok with leaving it as is for now. Other than that, looks good. /Per > > ------------------------------------------------------------------------ > 8219462: ZGC: Use wait/notify in ZNMethodTable > https://bugs.openjdk.java.net/browse/JDK-8219462 > http://cr.openjdk.java.net/~stefank/8219462/webrev.01/ > > The nmethod sweeper is not allowed to unregister an nmethod while the GC > is iterating over the ZNMethodTable. The current code spins in a loop > releasing the lock and sleeping for 1 ms. I propose that we replace this > with wait and notify. > > ------------------------------------------------------------------------ > 8219463: ZGC: Remove redundant ZNMethodTable::_iter_lock > https://bugs.openjdk.java.net/browse/JDK-8219463 > http://cr.openjdk.java.net/~stefank/8219463/webrev.01/ > > The ZNMethodTable lock guards accesses with both the CodeCache_lock and > it's own _iter_lock. This used to necessary because there was a path > that didn't take the CodeCache_lock. A recent bug fix changed this and > we always hold the CodeCache_lock when we take the _iter_lock. I propose > that we remove the _iter_lock. > > ------------------------------------------------------------------------ > 8219464: ZGC: Move nmethod oop properties from ZNMethodTableEntry to > ZNMethodData > https://bugs.openjdk.java.net/browse/JDK-8219464 > http://cr.openjdk.java.net/~stefank/8219464/webrev.01/ > > The ZNMethodTableEntry contains two cached values, regarding the > properties of an nmethod. The first is whether the nmethod has > "immediate oops" in the code. The second property is used to indicate if > the nmethod has "non immediate oop", which probably is a bad name, but > it tells if there are oop-derived immediates that need to be fixed when > Objects have been moved. > > I propose that we move these properties to the ZNMethodData objects that > are attached to the nmethods via the gc specific gc_data. This allows > for a cleaner separation of the proper table code in ZNMethodTable and > the class ZGC class unloading code. > > ------------------------------------------------------------------------ > 8219466: ZGC: Extract allocation functionality into a new > ZNMethodAllocator class > https://bugs.openjdk.java.net/browse/JDK-8219466 > http://cr.openjdk.java.net/~stefank/8219466/webrev.01/ > > ZNMethodData delegates the responsibility to safely free it's memory to > ZNMethodTable. I propose we break this dependency by introducing a > ZNMethodAllocator class that both classes can use. ZNMethodTable will > notify ZNMethodAllocator when its unsafe to free data and when it's time > to execute the deferred frees. ZNMethodData will then simply use > ZNMethodAllocator to allocate and free, and ZNMethodAllocator will > handle the deferred frees under the hood. > > ------------------------------------------------------------------------ > 8219467: ZGC: Move ZNMethodData to its own file > https://bugs.openjdk.java.net/browse/JDK-8219467 > http://cr.openjdk.java.net/~stefank/8219467/webrev.01/ > > A simple move of the code. > > ------------------------------------------------------------------------ > 8219468: ZGC: Extract iteration functionality into a new > ZNMethodTableIteration class > https://bugs.openjdk.java.net/browse/JDK-8219468 > http://cr.openjdk.java.net/~stefank/8219468/webrev.01/ > > Extracts the iteration code into its own class. > > This patch also changes the how tables are deleted when an iteration is > in progress, to use the new ZNMethodAllocator class instead. > > ------------------------------------------------------------------------ > 8219469: ZGC: Extract functions out from ZNMethodTable into new ZNMethod > class > https://bugs.openjdk.java.net/browse/JDK-8219469 > http://cr.openjdk.java.net/~stefank/8219469/webrev.01/ > > This patch moves the non-table specific ZGC nmethod handling code out to > a new ZNMethod class. > > ------------------------------------------------------------------------ > > Tested with: > tier1,tier2,tier3, gc-test-suite > > Thanks, > StefanK From per.liden at oracle.com Thu Feb 21 12:18:38 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 21 Feb 2019 13:18:38 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> References: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> Message-ID: <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> On 2/18/19 9:11 AM, Erik ?sterlund wrote: > Hi Per, > > On 2019-02-18 07:44, Per Liden wrote: >> Hi Erik, >> >> On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >>> Hi, >>> >>> An nmethod goes from being is_alive() to being !is_alive() and >>> eventually being freed in nmethod::flush. Native structures for >>> nmethods are freed in nmethod::flush when we free the nmethod. Except >>> for a few things, including GC data. This enhancement proposes to fix >>> that to make the life cycle of nmethods and their native data more >>> intuitive. >>> >>> In particular ZGC has per-nmethod data. The data is removed when >>> unlinking nmethods, as opposed to when they are deleted. This is a >>> bit awkward and makes things more difficult than they need to be. >>> This patch adds a new CollectedHeap::flush_nmethod() function. In >>> there ZGC deletes its attached GC data. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8218974 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ >> >> Do we need to introduce a new flush_nmethod()? Would it instead be >> possible to move/adjust where unregister_nmethod() is called to get >> the same effect? When just looking at the API, the relationship >> between unregister and flush is not super obvious. Determining which >> one will be called first and what a GC allowed/supposed to do in each >> of them kind of requires you to inspect the call-sites. > > I think of it this way: unregister_nmethod is tied to the lifecycle of > the nmethod oops, and flush_nmethod is for the nmethod itself. > In particular, we call unregister_nmethod when an nmethod dies (becomes > !is_alive()). When an nmethod has died, the oops should not be retained. > In fact, when the nmethod becomes unloaded, it dies specifically because > the oops are dead, forcing us to kill the nmethod. Then we unregister to > tell the GC not to look at those oops again. > > If we moved unregister_nmethod to nmethod::flush, we would keep around > nmethods with broken oops in GC data structures, and the GC could no > longer trust those data structures, unless we rewrote them to take into > consideration that the oops they maintain could be dead if the host > nmethod has silently died. But I don't think that would be an improvement. > > Because of this, I think it is wise to separate between GC events for > the nmethod dying, and being deleted, because they have different > implications. I hear you. I like how this simplifies the nmethod data life cycle. Just one minor thing, ZNMethodTable::lock_for_nmethod() could now be just: return gc_data(nm)->lock(); Other than that, look good. We might want to think about how/if this relates to the BarrierSet::on_* functions, with regards to naming and where they live. But that's a separate patch. cheers, Per From erik.osterlund at oracle.com Thu Feb 21 12:20:28 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 21 Feb 2019 13:20:28 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> References: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> Message-ID: <2485a254-d664-a6ce-62de-b8eeb2f0d2cd@oracle.com> Hi Per, Thanks for the review. /Erik On 2019-02-21 13:18, Per Liden wrote: > On 2/18/19 9:11 AM, Erik ?sterlund wrote: >> Hi Per, >> >> On 2019-02-18 07:44, Per Liden wrote: >>> Hi Erik, >>> >>> On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> An nmethod goes from being is_alive() to being !is_alive() and >>>> eventually being freed in nmethod::flush. Native structures for >>>> nmethods are freed in nmethod::flush when we free the nmethod. >>>> Except for a few things, including GC data. This enhancement >>>> proposes to fix that to make the life cycle of nmethods and their >>>> native data more intuitive. >>>> >>>> In particular ZGC has per-nmethod data. The data is removed when >>>> unlinking nmethods, as opposed to when they are deleted. This is a >>>> bit awkward and makes things more difficult than they need to be. >>>> This patch adds a new CollectedHeap::flush_nmethod() function. In >>>> there ZGC deletes its attached GC data. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8218974 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ >>> >>> Do we need to introduce a new flush_nmethod()? Would it instead be >>> possible to move/adjust where unregister_nmethod() is called to get >>> the same effect? When just looking at the API, the relationship >>> between unregister and flush is not super obvious. Determining which >>> one will be called first and what a GC allowed/supposed to do in >>> each of them kind of requires you to inspect the call-sites. >> >> I think of it this way: unregister_nmethod is tied to the lifecycle >> of the nmethod oops, and flush_nmethod is for the nmethod itself. >> In particular, we call unregister_nmethod when an nmethod dies >> (becomes !is_alive()). When an nmethod has died, the oops should not >> be retained. In fact, when the nmethod becomes unloaded, it dies >> specifically because the oops are dead, forcing us to kill the >> nmethod. Then we unregister to tell the GC not to look at those oops >> again. >> >> If we moved unregister_nmethod to nmethod::flush, we would keep >> around nmethods with broken oops in GC data structures, and the GC >> could no longer trust those data structures, unless we rewrote them >> to take into consideration that the oops they maintain could be dead >> if the host nmethod has silently died. But I don't think that would >> be an improvement. >> >> Because of this, I think it is wise to separate between GC events for >> the nmethod dying, and being deleted, because they have different >> implications. > > I hear you. I like how this simplifies the nmethod data life cycle. > Just one minor thing, ZNMethodTable::lock_for_nmethod() could now be > just: > > ? return gc_data(nm)->lock(); > > Other than that, look good. > > We might want to think about how/if this relates to the > BarrierSet::on_* functions, with regards to naming and where they > live. But that's a separate patch. > > cheers, > Per From zgu at redhat.com Thu Feb 21 12:58:09 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 21 Feb 2019 07:58:09 -0500 Subject: RFR (S) 8219524: Shenandoah misreports "committed" size in MemoryMXBean In-Reply-To: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> References: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> Message-ID: <1550753889.4234.0.camel@redhat.com> Looks good. -Zhengyu On Thu, 2019-02-21 at 11:19 +0100, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219524 > > Fix: > http://cr.openjdk.java.net/~shade/8219524/webrev.01/ > > See the backing story in the bug. Arguably, this is due Shenandoah > departing from what shared code > believes GC implementation should be doing, i.e. returning the amount > of committed memory with > CollectedHeap::capacity(). Would that be a fair characterization? > Even so, rewiring Shenandoah to > match the shared code expectations would require more work, but we > can plug the current failure with > this patch meanwhile. > > Testing: hotspot_gc_shenandoah, new check in test > > Thanks, > -Aleksey > From shade at redhat.com Thu Feb 21 14:53:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Feb 2019 15:53:49 +0100 Subject: RFR (S) 8219524: Shenandoah misreports "committed" size in MemoryMXBean In-Reply-To: <1550753889.4234.0.camel@redhat.com> References: <0745a7d6-5a8b-8561-d710-376852af6bab@redhat.com> <1550753889.4234.0.camel@redhat.com> Message-ID: <8f755c88-fdc6-68d6-7c48-c14ca13968e0@redhat.com> Thanks, pushed. -Aleksey On 2/21/19 1:58 PM, zgu at redhat.com wrote: > Looks good. > > -Zhengyu > > On Thu, 2019-02-21 at 11:19 +0100, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219524 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8219524/webrev.01/ >> >> See the backing story in the bug. Arguably, this is due Shenandoah >> departing from what shared code >> believes GC implementation should be doing, i.e. returning the amount >> of committed memory with >> CollectedHeap::capacity(). Would that be a fair characterization? >> Even so, rewiring Shenandoah to >> match the shared code expectations would require more work, but we >> can plug the current failure with >> this patch meanwhile. >> >> Testing: hotspot_gc_shenandoah, new check in test >> >> Thanks, >> -Aleksey >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From manc at google.com Fri Feb 22 03:43:16 2019 From: manc at google.com (Man Cao) Date: Thu, 21 Feb 2019 19:43:16 -0800 Subject: RFR (XS) 8215221: Serial GC misreports young GC time In-Reply-To: <26b1b5d2-40b1-0219-213d-ab34f185dd2d@redhat.com> References: <45b4e84d-bbbe-80fb-d7ff-57535e4ea3e5@redhat.com> <4EAF3B14-D5EA-43F9-9497-261921BEE868@oracle.com> <1A7E2F33-2E26-4451-8CBD-9B5804941C0D@oracle.com> <26b1b5d2-40b1-0219-213d-ab34f185dd2d@redhat.com> Message-ID: Hi Aleksey, The patch looks mostly good to me but I think I found a minor behavior change (bug). It seems it causes double counting on CollectedHeap._total_full_collections, if complete==true && do_young_collection==true && do_full_collection==true. The cause is the following: 645 if (!do_young_collection) { 646 gc_prologue(complete); 647 increment_total_collections(); 648 } 649 increment_total_full_collections(); I can expose the issue with the following command: $ java -XX:+UseSerialGC -XX:+ScavengeBeforeFullGC -Xlog:gc*,gc+heap=debug -Xmx30m -jar dacapo-9.12-bach.jar fop -n 5 Then compare the number of lines with "Pause Full" against the full count in the line "Heap after GC invocations=XX (full XX)" after last GC. I found the following could fix the problem (yes, it's ugly, but I couldn't find cleaner way that works in all cases): if (!do_young_collection) { gc_prologue(complete); increment_total_collections(complete); } if (!complete) { increment_total_full_collections(); } I also found that CollectedHeap._total_collections seems wrong with or without this change, for SerialGC and CMS. It is smaller than the actual number of collections according to the GC ID. Reproduction recipe is the same as above. -Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri Feb 22 09:46:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Feb 2019 10:46:32 +0100 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails Message-ID: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> Please review the backport to 11u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8214118 Original fix: http://hg.openjdk.java.net/jdk/jdk/rev/c9325aa887da The patch does not apply cleanly to 11u, because there are minute differences in the code. Notably, there is no closed_archive_heap_ranges, and as I see from the code, string_ranges is the old name for it. It was renamed in JDK-8212995. I also see there is Oracle-closed backport to 11u-oracle, can we compare the patches with Oracle folks, maybe? 11u webrev: http://cr.openjdk.java.net/~shade/8214118/webrev.11u.01/ Testing: Linux x86_64 tier1 Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jianglizhou at google.com Fri Feb 22 15:47:23 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 22 Feb 2019 07:47:23 -0800 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails In-Reply-To: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> Message-ID: Hi Aleksey, The backport looks good to me. On Fri, Feb 22, 2019 at 1:48 AM Aleksey Shipilev wrote: > Please review the backport to 11u. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8214118 > > Original fix: > http://hg.openjdk.java.net/jdk/jdk/rev/c9325aa887da > > The patch does not apply cleanly to 11u, because there are minute > differences in the code. Notably, > there is no closed_archive_heap_ranges, and as I see from the code, > string_ranges is the old name > for it. It was renamed in JDK-8212995. > Right. The renaming happened when graphs of non-string objects were supported in the closed region. Thanks, Jiangli > I also see there is Oracle-closed backport to 11u-oracle, can we compare > the patches with Oracle > folks, maybe? > > 11u webrev: > http://cr.openjdk.java.net/~shade/8214118/webrev.11u.01/ > > Testing: Linux x86_64 tier1 > > Thanks, > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri Feb 22 16:06:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Feb 2019 17:06:19 +0100 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails In-Reply-To: <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com> References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com> Message-ID: <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com> On 2/22/19 5:05 PM, Aleksey Shipilev wrote: > On 2/22/19 4:47 PM, Jiangli Zhou wrote: >> The backport looks good to me.? > > Thanks. I am going to push to 11u soon then. Wait. Christoph, please eyeball as well? -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Fri Feb 22 16:05:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Feb 2019 17:05:45 +0100 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails In-Reply-To: References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> Message-ID: <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com> On 2/22/19 4:47 PM, Jiangli Zhou wrote: > The backport looks good to me.? Thanks. I am going to push to 11u soon then. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Fri Feb 22 17:37:20 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Feb 2019 18:37:20 +0100 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails In-Reply-To: <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com> References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com> <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com> Message-ID: <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com> On 2/22/19 5:06 PM, Aleksey Shipilev wrote: > On 2/22/19 5:05 PM, Aleksey Shipilev wrote: >> On 2/22/19 4:47 PM, Jiangli Zhou wrote: >>> The backport looks good to me.? >> >> Thanks. I am going to push to 11u soon then. > > Wait. Christoph, please eyeball as well? Or not. Jiangli's review in CDS area should be good enough. Pushed. -Aleksey, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph.langer at sap.com Fri Feb 22 22:06:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 22 Feb 2019 22:06:02 +0000 Subject: [11u] RFR (S) 8214118: HeapRegions marked as archive even if CDS mapping fails In-Reply-To: <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com> References: <7c4d7949-5619-a611-837a-445cc06ccc1b@redhat.com> <98c313be-864b-8b82-00a5-a92afe2b7996@redhat.com> <727c84d3-d004-09c0-eef9-378f3cf72f4d@redhat.com> <54fb7dcf-1377-59bb-b97e-41f4a7cde906@redhat.com> Message-ID: <2a8ccf3c22a9484aa41e56a7f7923793@sap.com> > > Wait. Christoph, please eyeball as well? > > Or not. Jiangli's review in CDS area should be good enough. Pushed. Yes. I could not have added to the value of this review ? Thanks guys. From per.liden at oracle.com Mon Feb 25 09:48:12 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 10:48:12 +0100 Subject: RFR: 8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize Message-ID: The size of the unit of memory managed by ZGC is currently called ZPageSizeMin. However, this constant is used in places where we're not necessarily dealing with a ZPage, so calling it ZPageSizeMin isn't quite right. Rename ZPageSizeMin to ZGranuleSize. Bug: https://bugs.openjdk.java.net/browse/JDK-8219633 Webrev: http://cr.openjdk.java.net/~pliden/8219633/webrev.0 /Per From per.liden at oracle.com Mon Feb 25 09:48:16 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 10:48:16 +0100 Subject: RFR: 8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap Message-ID: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> The ZAddressRangeMap currently takes an AddressRangeShift template argument. However, that argument is always ZPageSizeMinShift (ZGranuleSizeShift after JDK-8219633). Simplify ZAddressRangeMap by removing the AddressRangeShift template argument and rename it ZGranuleMap to signal that it's always dealing with granules. Bug: https://bugs.openjdk.java.net/browse/JDK-8219634 Webrev: http://cr.openjdk.java.net/~pliden/8219634/webrev.0 /Per From erik.osterlund at oracle.com Mon Feb 25 11:46:44 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 12:46:44 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: <2485a254-d664-a6ce-62de-b8eeb2f0d2cd@oracle.com> References: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> <2485a254-d664-a6ce-62de-b8eeb2f0d2cd@oracle.com> Message-ID: Hi, Rebase over Stefan Karlssons recent ZGC cleanups: http://cr.openjdk.java.net/~eosterlund/8218974/webrev.01/ Thanks, /Erik On 2019-02-21 13:20, Erik ?sterlund wrote: > Hi Per, > > Thanks for the review. > > /Erik > > On 2019-02-21 13:18, Per Liden wrote: >> On 2/18/19 9:11 AM, Erik ?sterlund wrote: >>> Hi Per, >>> >>> On 2019-02-18 07:44, Per Liden wrote: >>>> Hi Erik, >>>> >>>> On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> An nmethod goes from being is_alive() to being !is_alive() and >>>>> eventually being freed in nmethod::flush. Native structures for >>>>> nmethods are freed in nmethod::flush when we free the nmethod. >>>>> Except for a few things, including GC data. This enhancement >>>>> proposes to fix that to make the life cycle of nmethods and their >>>>> native data more intuitive. >>>>> >>>>> In particular ZGC has per-nmethod data. The data is removed when >>>>> unlinking nmethods, as opposed to when they are deleted. This is a >>>>> bit awkward and makes things more difficult than they need to be. >>>>> This patch adds a new CollectedHeap::flush_nmethod() function. In >>>>> there ZGC deletes its attached GC data. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8218974 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ >>>> >>>> Do we need to introduce a new flush_nmethod()? Would it instead be >>>> possible to move/adjust where unregister_nmethod() is called to get >>>> the same effect? When just looking at the API, the relationship >>>> between unregister and flush is not super obvious. Determining >>>> which one will be called first and what a GC allowed/supposed to do >>>> in each of them kind of requires you to inspect the call-sites. >>> >>> I think of it this way: unregister_nmethod is tied to the lifecycle >>> of the nmethod oops, and flush_nmethod is for the nmethod itself. >>> In particular, we call unregister_nmethod when an nmethod dies >>> (becomes !is_alive()). When an nmethod has died, the oops should not >>> be retained. In fact, when the nmethod becomes unloaded, it dies >>> specifically because the oops are dead, forcing us to kill the >>> nmethod. Then we unregister to tell the GC not to look at those oops >>> again. >>> >>> If we moved unregister_nmethod to nmethod::flush, we would keep >>> around nmethods with broken oops in GC data structures, and the GC >>> could no longer trust those data structures, unless we rewrote them >>> to take into consideration that the oops they maintain could be dead >>> if the host nmethod has silently died. But I don't think that would >>> be an improvement. >>> >>> Because of this, I think it is wise to separate between GC events >>> for the nmethod dying, and being deleted, because they have >>> different implications. >> >> I hear you. I like how this simplifies the nmethod data life cycle. >> Just one minor thing, ZNMethodTable::lock_for_nmethod() could now be >> just: >> >> ? return gc_data(nm)->lock(); >> >> Other than that, look good. >> >> We might want to think about how/if this relates to the >> BarrierSet::on_* functions, with regards to naming and where they >> live. But that's a separate patch. >> >> cheers, >> Per > From erik.osterlund at oracle.com Mon Feb 25 12:15:54 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 13:15:54 +0100 Subject: RFR: 8219638: ZGC: Free ZNMethodDataOops using GlobalCounter Message-ID: <96d531fc-fb6c-6f3e-1f52-8198ac547f59@oracle.com> Hi, Today, the ZNMethodDataOops use a custom deferred freeing mechanism to handle the case where C1 performs code patching that generates more immediate oops, while the GC is concurrently walking the code cache for class unloading. It would be nice to use GlobalCounter instead, which is a more standardized way of doing it. Webrev: http://cr.openjdk.java.net/~eosterlund/8219638/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219638 Thanks, /Erik From per.liden at oracle.com Mon Feb 25 12:45:58 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 13:45:58 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: References: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> <2485a254-d664-a6ce-62de-b8eeb2f0d2cd@oracle.com> Message-ID: Looks good! /Per On 2/25/19 12:46 PM, Erik ?sterlund wrote: > Hi, > > Rebase over Stefan Karlssons recent ZGC cleanups: > http://cr.openjdk.java.net/~eosterlund/8218974/webrev.01/ > > Thanks, > /Erik > > On 2019-02-21 13:20, Erik ?sterlund wrote: >> Hi Per, >> >> Thanks for the review. >> >> /Erik >> >> On 2019-02-21 13:18, Per Liden wrote: >>> On 2/18/19 9:11 AM, Erik ?sterlund wrote: >>>> Hi Per, >>>> >>>> On 2019-02-18 07:44, Per Liden wrote: >>>>> Hi Erik, >>>>> >>>>> On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> >>>>>> An nmethod goes from being is_alive() to being !is_alive() and >>>>>> eventually being freed in nmethod::flush. Native structures for >>>>>> nmethods are freed in nmethod::flush when we free the nmethod. >>>>>> Except for a few things, including GC data. This enhancement >>>>>> proposes to fix that to make the life cycle of nmethods and their >>>>>> native data more intuitive. >>>>>> >>>>>> In particular ZGC has per-nmethod data. The data is removed when >>>>>> unlinking nmethods, as opposed to when they are deleted. This is a >>>>>> bit awkward and makes things more difficult than they need to be. >>>>>> This patch adds a new CollectedHeap::flush_nmethod() function. In >>>>>> there ZGC deletes its attached GC data. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8218974 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ >>>>> >>>>> Do we need to introduce a new flush_nmethod()? Would it instead be >>>>> possible to move/adjust where unregister_nmethod() is called to get >>>>> the same effect? When just looking at the API, the relationship >>>>> between unregister and flush is not super obvious. Determining >>>>> which one will be called first and what a GC allowed/supposed to do >>>>> in each of them kind of requires you to inspect the call-sites. >>>> >>>> I think of it this way: unregister_nmethod is tied to the lifecycle >>>> of the nmethod oops, and flush_nmethod is for the nmethod itself. >>>> In particular, we call unregister_nmethod when an nmethod dies >>>> (becomes !is_alive()). When an nmethod has died, the oops should not >>>> be retained. In fact, when the nmethod becomes unloaded, it dies >>>> specifically because the oops are dead, forcing us to kill the >>>> nmethod. Then we unregister to tell the GC not to look at those oops >>>> again. >>>> >>>> If we moved unregister_nmethod to nmethod::flush, we would keep >>>> around nmethods with broken oops in GC data structures, and the GC >>>> could no longer trust those data structures, unless we rewrote them >>>> to take into consideration that the oops they maintain could be dead >>>> if the host nmethod has silently died. But I don't think that would >>>> be an improvement. >>>> >>>> Because of this, I think it is wise to separate between GC events >>>> for the nmethod dying, and being deleted, because they have >>>> different implications. >>> >>> I hear you. I like how this simplifies the nmethod data life cycle. >>> Just one minor thing, ZNMethodTable::lock_for_nmethod() could now be >>> just: >>> >>> ? return gc_data(nm)->lock(); >>> >>> Other than that, look good. >>> >>> We might want to think about how/if this relates to the >>> BarrierSet::on_* functions, with regards to naming and where they >>> live. But that's a separate patch. >>> >>> cheers, >>> Per >> > From erik.osterlund at oracle.com Mon Feb 25 13:29:59 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 14:29:59 +0100 Subject: RFR: 8219638: ZGC: Free ZNMethodDataOops using GlobalCounter In-Reply-To: <96d531fc-fb6c-6f3e-1f52-8198ac547f59@oracle.com> References: <96d531fc-fb6c-6f3e-1f52-8198ac547f59@oracle.com> Message-ID: <9620f1ab-d0d4-85fa-1af4-697d6e394d5c@oracle.com> Hi, After discussing this with Per, we found that nowadays we don't even need RCU. We can just swap the oop cache under the per nmethod lock, which makes the code even simpler. New webrev: http://cr.openjdk.java.net/~eosterlund/8219638/webrev.01/ Thanks, /Erik On 2019-02-25 13:15, Erik ?sterlund wrote: > Hi, > > Today, the ZNMethodDataOops use a custom deferred freeing mechanism to > handle the case where C1 performs code patching that generates more > immediate oops, while the GC is concurrently walking the code cache > for class unloading. > It would be nice to use GlobalCounter instead, which is a more > standardized way of doing it. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219638/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219638 > > Thanks, > /Erik From per.liden at oracle.com Mon Feb 25 13:35:51 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 14:35:51 +0100 Subject: RFR: 8219638: ZGC: Free ZNMethodDataOops using GlobalCounter In-Reply-To: <9620f1ab-d0d4-85fa-1af4-697d6e394d5c@oracle.com> References: <96d531fc-fb6c-6f3e-1f52-8198ac547f59@oracle.com> <9620f1ab-d0d4-85fa-1af4-697d6e394d5c@oracle.com> Message-ID: <3a2b8cf4-96a9-119e-4d20-b2c69da27783@oracle.com> Looks good! /Per On 2/25/19 2:29 PM, Erik ?sterlund wrote: > Hi, > > After discussing this with Per, we found that nowadays we don't even > need RCU. We can just swap the oop cache under the per nmethod lock, > which makes the code even simpler. > > New webrev: > http://cr.openjdk.java.net/~eosterlund/8219638/webrev.01/ > > Thanks, > /Erik > > On 2019-02-25 13:15, Erik ?sterlund wrote: >> Hi, >> >> Today, the ZNMethodDataOops use a custom deferred freeing mechanism to >> handle the case where C1 performs code patching that generates more >> immediate oops, while the GC is concurrently walking the code cache >> for class unloading. >> It would be nice to use GlobalCounter instead, which is a more >> standardized way of doing it. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8219638/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219638 >> >> Thanks, >> /Erik > From erik.osterlund at oracle.com Mon Feb 25 14:00:50 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:00:50 +0100 Subject: RFR: 8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize In-Reply-To: References: Message-ID: <60df1afb-bc1a-9012-4cc6-8a273923b1fe@oracle.com> Hi Per, Seems like this will break the SA. Otherwise it looks good. Thanks, /Erik On 2019-02-25 10:48, Per Liden wrote: > The size of the unit of memory managed by ZGC is currently called > ZPageSizeMin. However, this constant is used in places where we're not > necessarily dealing with a ZPage, so calling it ZPageSizeMin isn't > quite right. Rename ZPageSizeMin to ZGranuleSize. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219633 > Webrev: http://cr.openjdk.java.net/~pliden/8219633/webrev.0 > > /Per From erik.osterlund at oracle.com Mon Feb 25 14:07:12 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:07:12 +0100 Subject: RFR: 8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap In-Reply-To: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> References: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> Message-ID: <793beb1e-d1ce-39ab-e673-73f70563e7a1@oracle.com> Hi Per, This will probably also break the SA. Looks good otherwise. /Erik On 2019-02-25 10:48, Per Liden wrote: > The ZAddressRangeMap currently takes an AddressRangeShift template > argument. However, that argument is always ZPageSizeMinShift > (ZGranuleSizeShift after JDK-8219633). Simplify ZAddressRangeMap by > removing the AddressRangeShift template argument and rename it > ZGranuleMap to signal that it's always dealing with granules. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219634 > Webrev: http://cr.openjdk.java.net/~pliden/8219634/webrev.0 > > /Per From per.liden at oracle.com Mon Feb 25 14:15:00 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 15:15:00 +0100 Subject: RFR: 8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize In-Reply-To: <60df1afb-bc1a-9012-4cc6-8a273923b1fe@oracle.com> References: <60df1afb-bc1a-9012-4cc6-8a273923b1fe@oracle.com> Message-ID: <54902fe7-947d-eb67-443a-c0e209f44e51@oracle.com> Doh! http://cr.openjdk.java.net/~pliden/8219633/webrev.1 /Per On 2/25/19 3:00 PM, Erik ?sterlund wrote: > Hi Per, > > Seems like this will break the SA. Otherwise it looks good. > > Thanks, > /Erik > > On 2019-02-25 10:48, Per Liden wrote: >> The size of the unit of memory managed by ZGC is currently called >> ZPageSizeMin. However, this constant is used in places where we're not >> necessarily dealing with a ZPage, so calling it ZPageSizeMin isn't >> quite right. Rename ZPageSizeMin to ZGranuleSize. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219633 >> Webrev: http://cr.openjdk.java.net/~pliden/8219633/webrev.0 >> >> /Per > From erik.osterlund at oracle.com Mon Feb 25 14:14:05 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:14:05 +0100 Subject: RFR: 8218974: Free GC native structures in nmethod::flush In-Reply-To: References: <7464cc2e-214c-e2f7-6f25-301c5f5067e6@oracle.com> <102c2f18-33d6-c8b0-3374-2d6c0874850d@oracle.com> <2485a254-d664-a6ce-62de-b8eeb2f0d2cd@oracle.com> Message-ID: <7979dad3-66b6-adef-9ad8-61b7562de742@oracle.com> Hi Per, Thanks for the review. /Erik On 2019-02-25 13:45, Per Liden wrote: > Looks good! > > /Per > > On 2/25/19 12:46 PM, Erik ?sterlund wrote: >> Hi, >> >> Rebase over Stefan Karlssons recent ZGC cleanups: >> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.01/ >> >> Thanks, >> /Erik >> >> On 2019-02-21 13:20, Erik ?sterlund wrote: >>> Hi Per, >>> >>> Thanks for the review. >>> >>> /Erik >>> >>> On 2019-02-21 13:18, Per Liden wrote: >>>> On 2/18/19 9:11 AM, Erik ?sterlund wrote: >>>>> Hi Per, >>>>> >>>>> On 2019-02-18 07:44, Per Liden wrote: >>>>>> Hi Erik, >>>>>> >>>>>> On 02/14/2019 12:55 PM, Erik ?sterlund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> An nmethod goes from being is_alive() to being !is_alive() and >>>>>>> eventually being freed in nmethod::flush. Native structures for >>>>>>> nmethods are freed in nmethod::flush when we free the nmethod. >>>>>>> Except for a few things, including GC data. This enhancement >>>>>>> proposes to fix that to make the life cycle of nmethods and >>>>>>> their native data more intuitive. >>>>>>> >>>>>>> In particular ZGC has per-nmethod data. The data is removed when >>>>>>> unlinking nmethods, as opposed to when they are deleted. This is >>>>>>> a bit awkward and makes things more difficult than they need to >>>>>>> be. This patch adds a new CollectedHeap::flush_nmethod() >>>>>>> function. In there ZGC deletes its attached GC data. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8218974 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8218974/webrev.00/ >>>>>> >>>>>> Do we need to introduce a new flush_nmethod()? Would it instead >>>>>> be possible to move/adjust where unregister_nmethod() is called >>>>>> to get the same effect? When just looking at the API, the >>>>>> relationship between unregister and flush is not super obvious. >>>>>> Determining which one will be called first and what a GC >>>>>> allowed/supposed to do in each of them kind of requires you to >>>>>> inspect the call-sites. >>>>> >>>>> I think of it this way: unregister_nmethod is tied to the >>>>> lifecycle of the nmethod oops, and flush_nmethod is for the >>>>> nmethod itself. >>>>> In particular, we call unregister_nmethod when an nmethod dies >>>>> (becomes !is_alive()). When an nmethod has died, the oops should >>>>> not be retained. In fact, when the nmethod becomes unloaded, it >>>>> dies specifically because the oops are dead, forcing us to kill >>>>> the nmethod. Then we unregister to tell the GC not to look at >>>>> those oops again. >>>>> >>>>> If we moved unregister_nmethod to nmethod::flush, we would keep >>>>> around nmethods with broken oops in GC data structures, and the GC >>>>> could no longer trust those data structures, unless we rewrote >>>>> them to take into consideration that the oops they maintain could >>>>> be dead if the host nmethod has silently died. But I don't think >>>>> that would be an improvement. >>>>> >>>>> Because of this, I think it is wise to separate between GC events >>>>> for the nmethod dying, and being deleted, because they have >>>>> different implications. >>>> >>>> I hear you. I like how this simplifies the nmethod data life cycle. >>>> Just one minor thing, ZNMethodTable::lock_for_nmethod() could now >>>> be just: >>>> >>>> ? return gc_data(nm)->lock(); >>>> >>>> Other than that, look good. >>>> >>>> We might want to think about how/if this relates to the >>>> BarrierSet::on_* functions, with regards to naming and where they >>>> live. But that's a separate patch. >>>> >>>> cheers, >>>> Per >>> >> From erik.osterlund at oracle.com Mon Feb 25 14:14:21 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:14:21 +0100 Subject: RFR: 8219638: ZGC: Free ZNMethodDataOops using GlobalCounter In-Reply-To: <3a2b8cf4-96a9-119e-4d20-b2c69da27783@oracle.com> References: <96d531fc-fb6c-6f3e-1f52-8198ac547f59@oracle.com> <9620f1ab-d0d4-85fa-1af4-697d6e394d5c@oracle.com> <3a2b8cf4-96a9-119e-4d20-b2c69da27783@oracle.com> Message-ID: Hi Per, Thanks for the review. /Erik On 2019-02-25 14:35, Per Liden wrote: > Looks good! > > /Per > > On 2/25/19 2:29 PM, Erik ?sterlund wrote: >> Hi, >> >> After discussing this with Per, we found that nowadays we don't even >> need RCU. We can just swap the oop cache under the per nmethod lock, >> which makes the code even simpler. >> >> New webrev: >> http://cr.openjdk.java.net/~eosterlund/8219638/webrev.01/ >> >> Thanks, >> /Erik >> >> On 2019-02-25 13:15, Erik ?sterlund wrote: >>> Hi, >>> >>> Today, the ZNMethodDataOops use a custom deferred freeing mechanism >>> to handle the case where C1 performs code patching that generates >>> more immediate oops, while the GC is concurrently walking the code >>> cache for class unloading. >>> It would be nice to use GlobalCounter instead, which is a more >>> standardized way of doing it. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8219638/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8219638 >>> >>> Thanks, >>> /Erik >> From per.liden at oracle.com Mon Feb 25 14:15:05 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 15:15:05 +0100 Subject: RFR: 8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap In-Reply-To: <793beb1e-d1ce-39ab-e673-73f70563e7a1@oracle.com> References: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> <793beb1e-d1ce-39ab-e673-73f70563e7a1@oracle.com> Message-ID: Doh! Doh! http://cr.openjdk.java.net/~pliden/8219634/webrev.1 /Per On 2/25/19 3:07 PM, Erik ?sterlund wrote: > Hi Per, > > This will probably also break the SA. Looks good otherwise. > > /Erik > > On 2019-02-25 10:48, Per Liden wrote: >> The ZAddressRangeMap currently takes an AddressRangeShift template >> argument. However, that argument is always ZPageSizeMinShift >> (ZGranuleSizeShift after JDK-8219633). Simplify ZAddressRangeMap by >> removing the AddressRangeShift template argument and rename it >> ZGranuleMap to signal that it's always dealing with granules. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219634 >> Webrev: http://cr.openjdk.java.net/~pliden/8219634/webrev.0 >> >> /Per > From erik.osterlund at oracle.com Mon Feb 25 14:22:32 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:22:32 +0100 Subject: RFR: 8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize In-Reply-To: <54902fe7-947d-eb67-443a-c0e209f44e51@oracle.com> References: <60df1afb-bc1a-9012-4cc6-8a273923b1fe@oracle.com> <54902fe7-947d-eb67-443a-c0e209f44e51@oracle.com> Message-ID: Hi Per, Looks good. Thanks, /Erik On 2019-02-25 15:15, Per Liden wrote: > Doh! > > http://cr.openjdk.java.net/~pliden/8219633/webrev.1 > > /Per > > On 2/25/19 3:00 PM, Erik ?sterlund wrote: >> Hi Per, >> >> Seems like this will break the SA. Otherwise it looks good. >> >> Thanks, >> /Erik >> >> On 2019-02-25 10:48, Per Liden wrote: >>> The size of the unit of memory managed by ZGC is currently called >>> ZPageSizeMin. However, this constant is used in places where we're >>> not necessarily dealing with a ZPage, so calling it ZPageSizeMin >>> isn't quite right. Rename ZPageSizeMin to ZGranuleSize. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219633 >>> Webrev: http://cr.openjdk.java.net/~pliden/8219633/webrev.0 >>> >>> /Per >> From erik.osterlund at oracle.com Mon Feb 25 14:22:41 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:22:41 +0100 Subject: RFR: 8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap In-Reply-To: References: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> <793beb1e-d1ce-39ab-e673-73f70563e7a1@oracle.com> Message-ID: <744f7771-6a64-ac05-0749-42a9849076d7@oracle.com> Hi Per, Looks good. Thanks, /Erik On 2019-02-25 15:15, Per Liden wrote: > Doh! Doh! > > http://cr.openjdk.java.net/~pliden/8219634/webrev.1 > > /Per > > On 2/25/19 3:07 PM, Erik ?sterlund wrote: >> Hi Per, >> >> This will probably also break the SA. Looks good otherwise. >> >> /Erik >> >> On 2019-02-25 10:48, Per Liden wrote: >>> The ZAddressRangeMap currently takes an AddressRangeShift template >>> argument. However, that argument is always ZPageSizeMinShift >>> (ZGranuleSizeShift after JDK-8219633). Simplify ZAddressRangeMap by >>> removing the AddressRangeShift template argument and rename it >>> ZGranuleMap to signal that it's always dealing with granules. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219634 >>> Webrev: http://cr.openjdk.java.net/~pliden/8219634/webrev.0 >>> >>> /Per >> From per.liden at oracle.com Mon Feb 25 15:36:21 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 16:36:21 +0100 Subject: RFR: 8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize In-Reply-To: References: <60df1afb-bc1a-9012-4cc6-8a273923b1fe@oracle.com> <54902fe7-947d-eb67-443a-c0e209f44e51@oracle.com> Message-ID: Thanks Erik! /Per On 02/25/2019 03:22 PM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-02-25 15:15, Per Liden wrote: >> Doh! >> >> http://cr.openjdk.java.net/~pliden/8219633/webrev.1 >> >> /Per >> >> On 2/25/19 3:00 PM, Erik ?sterlund wrote: >>> Hi Per, >>> >>> Seems like this will break the SA. Otherwise it looks good. >>> >>> Thanks, >>> /Erik >>> >>> On 2019-02-25 10:48, Per Liden wrote: >>>> The size of the unit of memory managed by ZGC is currently called >>>> ZPageSizeMin. However, this constant is used in places where we're >>>> not necessarily dealing with a ZPage, so calling it ZPageSizeMin >>>> isn't quite right. Rename ZPageSizeMin to ZGranuleSize. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219633 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8219633/webrev.0 >>>> >>>> /Per >>> > From per.liden at oracle.com Mon Feb 25 15:36:26 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Feb 2019 16:36:26 +0100 Subject: RFR: 8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap In-Reply-To: <744f7771-6a64-ac05-0749-42a9849076d7@oracle.com> References: <4c8f87db-cbf1-2548-6d70-a60916d59909@oracle.com> <793beb1e-d1ce-39ab-e673-73f70563e7a1@oracle.com> <744f7771-6a64-ac05-0749-42a9849076d7@oracle.com> Message-ID: <103ea867-1ceb-c1c8-1cdd-195e7fef8d59@oracle.com> Thanks Erik! /Per On 02/25/2019 03:22 PM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On 2019-02-25 15:15, Per Liden wrote: >> Doh! Doh! >> >> http://cr.openjdk.java.net/~pliden/8219634/webrev.1 >> >> /Per >> >> On 2/25/19 3:07 PM, Erik ?sterlund wrote: >>> Hi Per, >>> >>> This will probably also break the SA. Looks good otherwise. >>> >>> /Erik >>> >>> On 2019-02-25 10:48, Per Liden wrote: >>>> The ZAddressRangeMap currently takes an AddressRangeShift template >>>> argument. However, that argument is always ZPageSizeMinShift >>>> (ZGranuleSizeShift after JDK-8219633). Simplify ZAddressRangeMap by >>>> removing the AddressRangeShift template argument and rename it >>>> ZGranuleMap to signal that it's always dealing with granules. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219634 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8219634/webrev.0 >>>> >>>> /Per >>> > From kim.barrett at oracle.com Tue Feb 26 03:27:38 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 25 Feb 2019 22:27:38 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues Message-ID: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> Please review this change to G1 and Shenandoah to use the already extent thread-local PtrQueues in NonJavaThreads, rather than using shared queues that require locking. This is a step toward addressing JDK-8209974, JDK-8173211, and JDK-8170020. There are several parts to the change: The existing BarrierSet::on_thread_(attach|detach) functions get extended to apply to and be called for all threads, not just Java threads. A few implementations need to limit some of their behavior to Java threads, but others can just apply most or all of their existing behavior to non-Java threads too. This includes ZGC. Most operations involving shared queues are now applied to the corresponding thread-local queue, irrespective of whether the thread is a Java thread or not. Previously, a non-Java thread had to use the appropriate shared queue. Various iterations over threads get expanded to apply to all threads, rather than only Java threads. This change eliminates the single shared SATB queue and the associated (access-rank) lock. It does not eliminate the shared dirty card queues, as there is one use that can't be switched to using the thread-local queue. Because of that, the support for shared queues in PtrQueue (_lock and _permanent members and associated behavior) is still needed too. I have more changes in progress to address that. https://bugs.openjdk.java.net/browse/JDK-8219613 Webrev: http://cr.openjdk.java.net/~kbarrett/8219613/open.01/ gc/shared/barrierSet.cpp is in the webrev, but ended up not being changed. I'll update copyrights before pushing. Shenandoah changes provided with the help of Aleksey Shipilev. Testing: mach5 tier1-3, hs-tier4-5 jtreg: hotspot_gc_shenandoah From shade at redhat.com Tue Feb 26 08:59:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Feb 2019 09:59:17 +0100 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> Message-ID: On 2/26/19 4:27 AM, Kim Barrett wrote: > Webrev: > http://cr.openjdk.java.net/~kbarrett/8219613/open.01/ Shenandoah changes still look good. Passes hotspot_gc_shenandoah. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From erik.osterlund at oracle.com Tue Feb 26 12:23:14 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 26 Feb 2019 13:23:14 +0100 Subject: RFR: 8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops Message-ID: <8891dda7-b835-a262-38e5-cf8a5a1df07f@oracle.com> Hi, Accessing ZNMethodDataOops outside of concurrent code cache iteration used to be unsafe. It is now safe. Therefore, we should utilize this in the nmethod entry barriers and nmethod::is_unloading. Webrev: http://cr.openjdk.java.net/~eosterlund/8219718/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219718 Thanks, /Erik From erik.osterlund at oracle.com Tue Feb 26 12:44:24 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 26 Feb 2019 13:44:24 +0100 Subject: RFR: 8219724: ZGC: Make inline cache cleaning more robust Message-ID: <926a34d7-c23b-ee03-de2a-aeec299d6758@oracle.com> Hi, Today, during the nmethod unlinking phase, the per-nmethod lock is held across first an is_unloading() call on the nmethod and then inline cache cleaning, which may take the nmethod locks of all nmethods referred to from the inline caches. If care is not taken, an nmethod A can have an inline cache pointing at nmethod B, and B can have an inline cache pointing back at A. This could potentially cause a deadlock. Today it is subtly safe, because between calling is_unloading() and cleaning the inline caches, the nmethod entry barrier is disarmed, which causes an mfence in the patching code. This ensures that the racing threads do not enter a deadlock situation, because they will observe the is_unloading state that was published by the other thread in the race. I would like to move the locks so that this becomes more robust. Webrev: http://cr.openjdk.java.net/~eosterlund/8219724/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219724 Thanks, /Erik From zgu at redhat.com Tue Feb 26 15:58:40 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 26 Feb 2019 10:58:40 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> Message-ID: <1551196720.18805.58.camel@redhat.com> Hi Kim, Probably not directly relates to this RFR, but I see a couple of issues with this BarrierSet::on_thread_xxx mechanism. 1) When creating worker thread, it is added to WorkGang's thread first, and on_thread_attach() is not called until worker thread starts to run. If I use on_thread_attach() to initialize something (e.g. gclab), I may hit this timing gap, because WorkGang::threads_do() may hit uninitialized data (e.g. gclab) 2) The alternative is to use on_thread_create(), but it is called from Thread's constructor, therefore, I can not tell what kind of thread it is. Pleas let me know if I miss something. Thanks, -Zhengyu On Mon, 2019-02-25 at 22:27 -0500, Kim Barrett wrote: > Please review this change to G1 and Shenandoah to use the already > extent thread-local PtrQueues in NonJavaThreads, rather than using > shared queues that require locking. > > This is a step toward addressing JDK-8209974, JDK-8173211, and > JDK-8170020. > > There are several parts to the change: > > The existing BarrierSet::on_thread_(attach|detach) functions get > extended to apply to and be called for all threads, not just Java > threads. A few implementations need to limit some of their behavior > to Java threads, but others can just apply most or all of their > existing behavior to non-Java threads too. This includes ZGC. > > Most operations involving shared queues are now applied to the > corresponding thread-local queue, irrespective of whether the thread > is a Java thread or not. Previously, a non-Java thread had to use > the > appropriate shared queue. > > Various iterations over threads get expanded to apply to all threads, > rather than only Java threads. > > This change eliminates the single shared SATB queue and the > associated > (access-rank) lock. It does not eliminate the shared dirty card > queues, as there is one use that can't be switched to using the > thread-local queue. Because of that, the support for shared queues > in > PtrQueue (_lock and _permanent members and associated behavior) is > still needed too. I have more changes in progress to address that. > > https://bugs.openjdk.java.net/browse/JDK-8219613 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8219613/open.01/ > > gc/shared/barrierSet.cpp is in the webrev, but ended up not being > changed. > > I'll update copyrights before pushing. > > Shenandoah changes provided with the help of Aleksey Shipilev. > > Testing: > mach5 tier1-3, hs-tier4-5 > jtreg: hotspot_gc_shenandoah > From per.liden at oracle.com Tue Feb 26 21:07:11 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 26 Feb 2019 22:07:11 +0100 Subject: RFR: 8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops In-Reply-To: <8891dda7-b835-a262-38e5-cf8a5a1df07f@oracle.com> References: <8891dda7-b835-a262-38e5-cf8a5a1df07f@oracle.com> Message-ID: Looks good! /Per On 02/26/2019 01:23 PM, Erik ?sterlund wrote: > Hi, > > Accessing ZNMethodDataOops outside of concurrent code cache iteration > used to be unsafe. It is now safe. Therefore, we should utilize this in > the nmethod entry barriers and nmethod::is_unloading. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219718/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219718 > > Thanks, > /Erik From erik.osterlund at oracle.com Tue Feb 26 21:13:50 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 26 Feb 2019 22:13:50 +0100 Subject: RFR: 8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops In-Reply-To: References: <8891dda7-b835-a262-38e5-cf8a5a1df07f@oracle.com> Message-ID: <58062618-FB52-4735-971F-140AAD7CC4BE@oracle.com> Hi Per, Thanks for the review! /Erik > On 26 Feb 2019, at 22:07, Per Liden wrote: > > Looks good! > > /Per > >> On 02/26/2019 01:23 PM, Erik ?sterlund wrote: >> Hi, >> Accessing ZNMethodDataOops outside of concurrent code cache iteration used to be unsafe. It is now safe. Therefore, we should utilize this in the nmethod entry barriers and nmethod::is_unloading. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8219718/webrev.00/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219718 >> Thanks, >> /Erik From per.liden at oracle.com Tue Feb 26 21:17:22 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 26 Feb 2019 22:17:22 +0100 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> Message-ID: <292cbafd-cdcb-bcce-32eb-e826450ee863@oracle.com> On 02/26/2019 04:27 AM, Kim Barrett wrote: > Please review this change to G1 and Shenandoah to use the already > extent thread-local PtrQueues in NonJavaThreads, rather than using > shared queues that require locking. > > This is a step toward addressing JDK-8209974, JDK-8173211, and > JDK-8170020. > > There are several parts to the change: > > The existing BarrierSet::on_thread_(attach|detach) functions get > extended to apply to and be called for all threads, not just Java > threads. A few implementations need to limit some of their behavior > to Java threads, but others can just apply most or all of their > existing behavior to non-Java threads too. This includes ZGC. > > Most operations involving shared queues are now applied to the > corresponding thread-local queue, irrespective of whether the thread > is a Java thread or not. Previously, a non-Java thread had to use the > appropriate shared queue. > > Various iterations over threads get expanded to apply to all threads, > rather than only Java threads. > > This change eliminates the single shared SATB queue and the associated > (access-rank) lock. It does not eliminate the shared dirty card > queues, as there is one use that can't be switched to using the > thread-local queue. Because of that, the support for shared queues in > PtrQueue (_lock and _permanent members and associated behavior) is > still needed too. I have more changes in progress to address that. > > https://bugs.openjdk.java.net/browse/JDK-8219613 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8219613/open.01/ ZGC changes look good! /Per > > gc/shared/barrierSet.cpp is in the webrev, but ended up not being changed. > > I'll update copyrights before pushing. > > Shenandoah changes provided with the help of Aleksey Shipilev. > > Testing: > mach5 tier1-3, hs-tier4-5 > jtreg: hotspot_gc_shenandoah > From kim.barrett at oracle.com Tue Feb 26 22:10:38 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Feb 2019 17:10:38 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <1551196720.18805.58.camel@redhat.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> Message-ID: <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> > On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: > > Hi Kim, > > Probably not directly relates to this RFR, but I see a couple of issues > with this BarrierSet::on_thread_xxx mechanism. > > 1) When creating worker thread, it is added to WorkGang's thread first, > and on_thread_attach() is not called until worker thread starts to run. > If I use on_thread_attach() to initialize something (e.g. gclab), I may > hit this timing gap, because WorkGang::threads_do() may hit > uninitialized data (e.g. gclab) > > 2) The alternative is to use on_thread_create(), but it is called from > Thread's constructor, therefore, I can not tell what kind of thread it > is. > > Pleas let me know if I miss something. I think you might be correct that there is a problem, but I think the problem is in Shenandoah code, and pre-exists this patch. ShenandoahHeap::make_parsable and ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the gclab data of non-Java threads, and going to some effort to do so. But the per-thread gclab info only gets initialized for Java threads. Neither of those are changed by this patch. In pre-RFR discussion with Aleksey about the Shenandoah part of this patch, he said non-Java threads don't use the gclab mechanism, so only initializing the per-thread gclab data for Java threads was (and remains) correct. But make_parsable and retire_and_reset_gclabs are looking at that data anyway. WorkGang::threads_do is very little used, and could _almost_ go away. It's there to support gc_threads_do and some related things, which are (I think only) used for error printing and the like. MemoryService also uses gc_threads_do, to count the number of threads (a count that doesn't seem to get updated as the GC lazily allocates additional threads, which seems like a separate bug). Something like WorkGang::threads_do might be needed for destroying work gangs, but we don't ever do that at present. From sangheon.kim at oracle.com Tue Feb 26 22:32:26 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Tue, 26 Feb 2019 14:32:26 -0800 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: References: Message-ID: <6a427655-97d8-c580-9328-afdac7ed97a3@oracle.com> Hi Thomas, On 2/20/19 2:15 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that has been suggested as part of > another review to improve readability of the ExtRootScan sub-phase > printing? > > In particular, it introduces a few new named constants in the > GCParPhases enum that indicate start and end of the ext root scan sub- > phases. These are then used in the iteration. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219369 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219369/webrev/ Looks good. Thanks, Sangheon > testing: > hs-tier1,hs-tier2 (includes log output testing for completeness) > > Thanks, > Thomas > From kim.barrett at oracle.com Tue Feb 26 22:35:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Feb 2019 17:35:57 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> Message-ID: <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> > On Feb 26, 2019, at 5:10 PM, Kim Barrett wrote: > >> On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: >> >> Hi Kim, >> >> Probably not directly relates to this RFR, but I see a couple of issues >> with this BarrierSet::on_thread_xxx mechanism. >> >> 1) When creating worker thread, it is added to WorkGang's thread first, >> and on_thread_attach() is not called until worker thread starts to run. >> If I use on_thread_attach() to initialize something (e.g. gclab), I may >> hit this timing gap, because WorkGang::threads_do() may hit >> uninitialized data (e.g. gclab) >> >> 2) The alternative is to use on_thread_create(), but it is called from >> Thread's constructor, therefore, I can not tell what kind of thread it >> is. >> >> Pleas let me know if I miss something. > > I think you might be correct that there is a problem, but I think the > problem is in Shenandoah code, and pre-exists this patch. > > ShenandoahHeap::make_parsable and > ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the > gclab data of non-Java threads, and going to some effort to do so. > But the per-thread gclab info only gets initialized for Java threads. > Neither of those are changed by this patch. > > In pre-RFR discussion with Aleksey about the Shenandoah part of this > patch, he said non-Java threads don't use the gclab mechanism, so only > initializing the per-thread gclab data for Java threads was (and > remains) correct. But make_parsable and retire_and_reset_gclabs are > looking at that data anyway. Also, ShenandoahHeap::post_initialize applies the ShenandoahInitGCLABClosure to "all" threads (via Threads::threads_do), and some worker threads (via WorkGang::threads_do on the various work gangs), which will double call the closure (unless one is "lucky" and hits the race.) From kim.barrett at oracle.com Tue Feb 26 22:49:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Feb 2019 17:49:08 -0500 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: References: Message-ID: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> > On Feb 20, 2019, at 5:15 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this change that has been suggested as part of > another review to improve readability of the ExtRootScan sub-phase > printing? > > In particular, it introduces a few new named constants in the > GCParPhases enum that indicate start and end of the ext root scan sub- > phases. These are then used in the iteration. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219369 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219369/webrev/ > testing: > hs-tier1,hs-tier2 (includes log output testing for completeness) > > Thanks, > Thomas Looks good, but... I have something of a preference against cluttering enums with such pseudo-enumerators, and instead prefer class constants. But I'll leave it up to you. From zgu at redhat.com Tue Feb 26 22:53:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 26 Feb 2019 17:53:00 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> Message-ID: <1551221580.18805.69.camel@redhat.com> On Tue, 2019-02-26 at 17:10 -0500, Kim Barrett wrote: > > On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: > > > > Hi Kim, > > > > Probably not directly relates to this RFR, but I see a couple of > > issues > > with this BarrierSet::on_thread_xxx mechanism. > > > > 1) When creating worker thread, it is added to WorkGang's thread > > first, > > and on_thread_attach() is not called until worker thread starts to > > run. > > If I use on_thread_attach() to initialize something (e.g. gclab), I > > may > > hit this timing gap, because WorkGang::threads_do() may hit > > uninitialized data (e.g. gclab) > > > > 2) The alternative is to use on_thread_create(), but it is called > > from > > Thread's constructor, therefore, I can not tell what kind of thread > > it > > is. > > > > Pleas let me know if I miss something. > > I think you might be correct that there is a problem, but I think the > problem is in Shenandoah code, and pre-exists this patch. > > ShenandoahHeap::make_parsable and > ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the > gclab data of non-Java threads, and going to some effort to do so. > But the per-thread gclab info only gets initialized for Java threads. > Neither of those are changed by this patch. > > In pre-RFR discussion with Aleksey about the Shenandoah part of this > patch, he said non-Java threads don't use the gclab mechanism, so > only > initializing the per-thread gclab data for Java threads was (and > remains) correct. But make_parsable and retire_and_reset_gclabs are > looking at that data anyway. Yes, we current use other mechanism to initialize worker's gclab, so it works correctly right now. I were hoping I could use on_thread_xxx mechanism to replace our mechanism, so we can simplify a few things. I still have a couple of concerns regarding current on_thread_xxx implementation. 1) on_thread_create() callback, actually sees partially constructed thread if the thread is a subclass of Thread. 2) For JavaThread, on_thread_attach() is called from creator's thread, but non-Java thread is from the thread itself. Thanks, -Zhengyu > > WorkGang::threads_do is very little used, and could _almost_ go away. > It's there to support gc_threads_do and some related things, which > are > (I think only) used for error printing and the like. MemoryService > also uses gc_threads_do, to count the number of threads (a count that > doesn't seem to get updated as the GC lazily allocates additional > threads, which seems like a separate bug). > > Something like WorkGang::threads_do might be needed for destroying > work gangs, but we don't ever do that at present. > From shade at redhat.com Tue Feb 26 22:58:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Feb 2019 23:58:40 +0100 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> Message-ID: On 2/26/19 11:35 PM, Kim Barrett wrote: >> On Feb 26, 2019, at 5:10 PM, Kim Barrett wrote: >>> On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: >>> Probably not directly relates to this RFR, but I see a couple of issues >>> with this BarrierSet::on_thread_xxx mechanism. >>> >>> 1) When creating worker thread, it is added to WorkGang's thread first, >>> and on_thread_attach() is not called until worker thread starts to run. >>> If I use on_thread_attach() to initialize something (e.g. gclab), I may >>> hit this timing gap, because WorkGang::threads_do() may hit >>> uninitialized data (e.g. gclab) I think this is resolved specially in Shenandoah::post_initialize, when GC workers get their initial GCLABs. Zhengyu, can you confirm this? >> ShenandoahHeap::make_parsable and >> ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the >> gclab data of non-Java threads, and going to some effort to do so. >> But the per-thread gclab info only gets initialized for Java threads. >> Neither of those are changed by this patch. >> >> In pre-RFR discussion with Aleksey about the Shenandoah part of this >> patch, he said non-Java threads don't use the gclab mechanism, so only >> initializing the per-thread gclab data for Java threads was (and >> remains) correct. But make_parsable and retire_and_reset_gclabs are >> looking at that data anyway. I think this is still correct. Worker threads are indeed non-Java threads, but they are handled specially in ShenandoahWorkGang::install_worker, where their gclab is getting initialized. This "exception" is why make_parsable, retire_and_reset_gclab and friends are applying closure to GC worker threads. And why ShenandoahInitGCLABClosure applies to all threads, and then filter by (thread->is_Java_thread() || thread->is_Worker_thread()) -- this is needed to resolve some initialization races. > Also, ShenandoahHeap::post_initialize applies the ShenandoahInitGCLABClosure > to "all" threads (via Threads::threads_do), and some worker threads > (via WorkGang::threads_do on the various work gangs), which will > double call the closure (unless one is "lucky" and hits the race.) Oh, double-visiting is not nice indeed! Need to fix that, thanks. This issue does not block this patch. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Tue Feb 26 23:01:35 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 26 Feb 2019 18:01:35 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> Message-ID: <1551222095.18805.75.camel@redhat.com> On Tue, 2019-02-26 at 17:35 -0500, Kim Barrett wrote: > > On Feb 26, 2019, at 5:10 PM, Kim Barrett > > wrote: > > > > > On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: > > > > > > Hi Kim, > > > > > > Probably not directly relates to this RFR, but I see a couple of > > > issues > > > with this BarrierSet::on_thread_xxx mechanism. > > > > > > 1) When creating worker thread, it is added to WorkGang's thread > > > first, > > > and on_thread_attach() is not called until worker thread starts > > > to run. > > > If I use on_thread_attach() to initialize something (e.g. gclab), > > > I may > > > hit this timing gap, because WorkGang::threads_do() may hit > > > uninitialized data (e.g. gclab) > > > > > > 2) The alternative is to use on_thread_create(), but it is called > > > from > > > Thread's constructor, therefore, I can not tell what kind of > > > thread it > > > is. > > > > > > Pleas let me know if I miss something. > > > > I think you might be correct that there is a problem, but I think > > the > > problem is in Shenandoah code, and pre-exists this patch. > > > > ShenandoahHeap::make_parsable and > > ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the > > gclab data of non-Java threads, and going to some effort to do so. > > But the per-thread gclab info only gets initialized for Java > > threads. > > Neither of those are changed by this patch. > > > > In pre-RFR discussion with Aleksey about the Shenandoah part of > > this > > patch, he said non-Java threads don't use the gclab mechanism, so > > only > > initializing the per-thread gclab data for Java threads was (and > > remains) correct. But make_parsable and retire_and_reset_gclabs > > are > > looking at that data anyway. > > Also, ShenandoahHeap::post_initialize applies the > ShenandoahInitGCLABClosure > to "all" threads (via Threads::threads_do), and some worker threads > (via WorkGang::threads_do on the various work gangs), which will > double call the closure (unless one is "lucky" and hits the race.) Yes, I am aware of that we initialize some threads' gclab twice, especially now, JavaThread has gclab initialized in on_thread_attach(). I am working on this. Thanks, -Zhengyu > From zgu at redhat.com Tue Feb 26 23:11:10 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 26 Feb 2019 18:11:10 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> Message-ID: <1551222670.18805.83.camel@redhat.com> Sorry for the confusion. As I stated early, my comments are not directly related to this RFR. By no means, it should block this patch. On Tue, 2019-02-26 at 23:58 +0100, Aleksey Shipilev wrote: > On 2/26/19 11:35 PM, Kim Barrett wrote: > > > On Feb 26, 2019, at 5:10 PM, Kim Barrett > > > wrote: > > > > On Feb 26, 2019, at 10:58 AM, zgu at redhat.com wrote: > > > > Probably not directly relates to this RFR, but I see a couple > > > > of issues > > > > with this BarrierSet::on_thread_xxx mechanism. > > > > > > > > 1) When creating worker thread, it is added to WorkGang's > > > > thread first, > > > > and on_thread_attach() is not called until worker thread starts > > > > to run. > > > > If I use on_thread_attach() to initialize something (e.g. > > > > gclab), I may > > > > hit this timing gap, because WorkGang::threads_do() may hit > > > > uninitialized data (e.g. gclab) > > I think this is resolved specially in Shenandoah::post_initialize, > when GC workers get their initial > GCLABs. Zhengyu, can you confirm this? Yes. > > > > ShenandoahHeap::make_parsable and > > > ShenandoahHeap::retire_and_reset_gclabs seem to be looking at the > > > gclab data of non-Java threads, and going to some effort to do > > > so. > > > But the per-thread gclab info only gets initialized for Java > > > threads. > > > Neither of those are changed by this patch. > > > > > > In pre-RFR discussion with Aleksey about the Shenandoah part of > > > this > > > patch, he said non-Java threads don't use the gclab mechanism, so > > > only > > > initializing the per-thread gclab data for Java threads was (and > > > remains) correct. But make_parsable and retire_and_reset_gclabs > > > are > > > looking at that data anyway. > > I think this is still correct. Worker threads are indeed non-Java > threads, but they are handled > specially in ShenandoahWorkGang::install_worker, where their gclab is > getting initialized. This > "exception" is why make_parsable, retire_and_reset_gclab and friends > are applying closure to GC > worker threads. And why ShenandoahInitGCLABClosure applies to all > threads, and then filter by > (thread->is_Java_thread() || thread->is_Worker_thread()) -- this is > needed to resolve some > initialization races. Yes, that's how Shenandoah currently works. However, I feel we should ought to be able to use on_thread_xxx mechanism to replace it, cause it sounds more straight forward. > > > Also, ShenandoahHeap::post_initialize applies the > > ShenandoahInitGCLABClosure > > to "all" threads (via Threads::threads_do), and some worker threads > > (via WorkGang::threads_do on the various work gangs), which will > > double call the closure (unless one is "lucky" and hits the race.) > > Oh, double-visiting is not nice indeed! Need to fix that, thanks. > This issue does not block this patch. Yes, I am working on this. and yes, it should not block this patch. Thanks, -Zhengyu > > -Aleksey > From shade at redhat.com Tue Feb 26 23:14:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 00:14:19 +0100 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <1551222670.18805.83.camel@redhat.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> <36EFEE11-4E6D-440B-BCA7-7B1DE1C0BAFA@oracle.com> <1551222670.18805.83.camel@redhat.com> Message-ID: <1e71c260-2ba2-717c-222f-bcaf3f05c4ff@redhat.com> On 2/27/19 12:11 AM, zgu at redhat.com wrote: >> Oh, double-visiting is not nice indeed! Need to fix that, thanks. >> This issue does not block this patch. > Yes, I am working on this. and yes, it should not block this patch. Thanks! Do note that it would be easier not to deviate too much, because it might complicate backports. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kim.barrett at oracle.com Tue Feb 26 23:20:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Feb 2019 18:20:08 -0500 Subject: RFR: 8219613: Use NonJavaThread PtrQueues In-Reply-To: <1551221580.18805.69.camel@redhat.com> References: <4743AEAF-EF2D-4BC5-BF2B-8365C170B36A@oracle.com> <1551196720.18805.58.camel@redhat.com> <26A91386-3CDC-4BFC-A3C4-8E2B0EB8EC92@oracle.com> <1551221580.18805.69.camel@redhat.com> Message-ID: <7EAFF34F-CC2C-4121-938D-17299FF94E6C@oracle.com> > On Feb 26, 2019, at 5:53 PM, zgu at redhat.com wrote: > Yes, we current use other mechanism to initialize worker's gclab, so it > works correctly right now. I were hoping I could use on_thread_xxx > mechanism to replace our mechanism, so we can simplify a few things. > > I still have a couple of concerns regarding current on_thread_xxx > implementation. > > 1) on_thread_create() callback, actually sees partially constructed > thread if the thread is a subclass of Thread. (Since Thread is (at least conceptually) abstract, the object is necessarily an instance of a derived class.) on_thread_create is intended to be called as part of construction. Similarly on_thread_destroy and destruction. > 2) For JavaThread, on_thread_attach() is called from creator's thread, > but non-Java thread is from the thread itself. If this is a problem, you could add a handshake between the creator and the new thread's run function, so the creator knows the new thread has been added to the thread list before proceeding to use it. From per.liden at oracle.com Wed Feb 27 08:47:54 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 27 Feb 2019 09:47:54 +0100 Subject: RFR: 8219817: Remove unused CollectedHeap::block_size() Message-ID: CollectedHeap::block_size() is never called. We should remove it and the implementations provided by the different collectors. Bug: https://bugs.openjdk.java.net/browse/JDK-8219817 Webrev: http://cr.openjdk.java.net/~pliden/8219817/webrev.0 /Per From thomas.schatzl at oracle.com Wed Feb 27 09:29:47 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 10:29:47 +0100 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held Message-ID: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> Hi all, can I have reviews for this change that fixes execution of periodic GCs in G1? In the current implementation, if periodic GC is triggered when the gc locker is held, the VM crashes because the GC locker is supposed to be only held by Java threads - but the periodic GCs are triggered by some GC thread. The fix is to ignore the periodic GC request if the GC locker is held - after all this means that the application is active anyway, and a GC will be triggered anyway as soon as the critical section ends. To make it clear to end users that the periodic GC has been cancelled due to that reason, the change prints a cancellation reason too if appropriate logging is enabled. The change itself is pretty small, it's just the test that's a bit longer but straightforward. I will backport this to 12u later. CR: https://bugs.openjdk.java.net/browse/JDK-8218880 Webrev: http://cr.openjdk.java.net/~tschatzl/8218880/webrev/ Testing: New test case, hs-tier1-5 Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 27 09:37:18 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 10:37:18 +0100 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> References: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> Message-ID: <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> Hi, On Tue, 2019-02-26 at 17:49 -0500, Kim Barrett wrote: > > On Feb 20, 2019, at 5:15 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this change that has been suggested as part > > of another review to improve readability of the ExtRootScan sub- > > phase printing? > > > [...] > > Looks good, but... > > I have something of a preference against cluttering enums with such > pseudo-enumerators, and instead prefer class constants. But I'll > leave it up to you. > Fixed in http://cr.openjdk.java.net/~tschatzl/8219369/webrev.0_to_1/ (diff) http://cr.openjdk.java.net/~tschatzl/8219369/webrev.1/ (full) Yeah, looks better. Thanks for making me look at this option. Testing: compilation. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 27 10:09:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 11:09:01 +0100 Subject: RFR (M): 8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap Message-ID: Hi all, can I have reviews for this renaming change that removes some "g1_" prefixes to some G1CollectedHeap members? They are simply unnecessary within the context of G1. There has also been a "g1_collector_policy" method - after looking at its uses I decided to remove it and add a specific whitebox support method for it to G1CollectedHeap instead. CR: https://bugs.openjdk.java.net/browse/JDK-8219747 Webrev: http://cr.openjdk.java.net/~tschatzl/8219747/webrev/ Testing: local compilation Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 27 10:18:11 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 11:18:11 +0100 Subject: RFR (M): 8219748: Add and use getter for the timing object in G1 Message-ID: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> Hi, can I have reviews that adds a "phase_times()" getter to G1CollectedHeap to avoid the 50+ times of using "policy()- >phase_times()" instead? CR: https://bugs.openjdk.java.net/browse/JDK-8219748 Webrev: http://cr.openjdk.java.net/~tschatzl/8219748/webrev/ Testing: local compilation Thanks, Thomas From shade at redhat.com Wed Feb 27 10:29:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 11:29:26 +0100 Subject: RFR: 8219817: Remove unused CollectedHeap::block_size() In-Reply-To: References: Message-ID: On 2/27/19 9:47 AM, Per Liden wrote: > CollectedHeap::block_size() is never called. We should remove it and the implementations provided by > the different collectors. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219817 > Webrev: http://cr.openjdk.java.net/~pliden/8219817/webrev.0 Code change looks fine to me. There are comments in collectedHeap.hpp and g1CollectedHeap.hpp that sill mention block size: 1176 // one block. The defining characteristic of a block is that it is 1177 // possible to find its size, and thus to progress forward to the next 1178 // block. (Blocks may be of different sizes.) Thus, blocks may Aside, I wonder why block_* facility is even there. It seems to have the only use here: oop oopDesc::oop_or_null(address addr) { if (is_valid(oop(addr))) { // We were just given an oop directly. return oop(addr); } // Try to find addr using block_start. HeapWord* p = Universe::heap()->block_start(addr); if (p != NULL && Universe::heap()->block_is_obj(p)) { if (!is_valid(oop(p))) return NULL; return oop(p); } // If we can't find it it just may mean that heap wasn't parsable. return NULL; } ...so I wonder if we should just purge this use of CollectedHeap::block_* by returning NULL when addr does not hit the exact object, and then purge all relevant members from CollectedHeap? -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Wed Feb 27 10:36:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 11:36:01 +0100 Subject: RFR (M): 8219748: Add and use getter for the timing object in G1 In-Reply-To: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> References: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> Message-ID: On 2/27/19 11:18 AM, Thomas Schatzl wrote: > Hi, > > can I have reviews that adds a "phase_times()" getter to > G1CollectedHeap to avoid the 50+ times of using "policy()- >> phase_times()" instead? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219748 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219748/webrev/ Looks good! While you are at it, fix the indentation here? 2780 phase_times()->record_fast_reclaim_humongous_stats(time, 2781 cl.total_humongous(), 2782 cl.candidate_humongous()); -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Wed Feb 27 10:41:04 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 11:41:04 +0100 Subject: RFR (M): 8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap In-Reply-To: References: Message-ID: <9b2decb0-c57d-efe2-e052-15dbbfa187c2@redhat.com> On 2/27/19 11:09 AM, Thomas Schatzl wrote: > can I have reviews for this renaming change that removes some "g1_" > prefixes to some G1CollectedHeap members? They are simply unnecessary > within the context of G1. > > There has also been a "g1_collector_policy" method - after looking at > its uses I decided to remove it and add a specific whitebox support > method for it to G1CollectedHeap instead. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219747 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219747/webrev/ Looks good. It is a bit confusing to see the rename is_hetero_heap -> is_heap_heterogeneous in this changeset that talks about g1_ prefix removal, though. Nits: *) Indentation in g1CollectedHeap.cpp: 864 if (policy()->need_to_start_conc_mark("concurrent humongous allocation", 865 word_size)) { 4449 policy()->phase_times()->record_fast_reclaim_humongous_time_ms((os::elapsedTime() - start_time) * 1000.0, 4450 cl.humongous_objects_reclaimed()); *) Not sure if you want to rename locals too, like in g1ConcurrentMarkThread.cpp: 246 G1Policy* g1_policy = g1h->policy(); -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Wed Feb 27 10:50:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 11:50:47 +0100 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> Message-ID: <74082ad7-e73e-66a4-0005-c51e5ee1ef30@redhat.com> On 2/27/19 10:29 AM, Thomas Schatzl wrote: > CR: > https://bugs.openjdk.java.net/browse/JDK-8218880 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218880/webrev/ Nits: *) "pause_succeeded" is a confusing name. "vmop_succeeded" adds to confusion. Maybe both locals and the methods should be called "gc_succeeded"? 2151 vmop_succeeded = op.pause_succeeded(); *) I think burning here without backoff is not nice for the test, maybe sleep a little? libTestPeriodicCollectionJNI.c: 40 while (!release_critical) /* empty */; Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From thomas.schatzl at oracle.com Wed Feb 27 11:59:24 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 12:59:24 +0100 Subject: RFR (M): 8219748: Add and use getter for the timing object in G1 In-Reply-To: References: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> Message-ID: Hi, On Wed, 2019-02-27 at 11:36 +0100, Aleksey Shipilev wrote: > On 2/27/19 11:18 AM, Thomas Schatzl wrote: > > Hi, > > > > can I have reviews that adds a "phase_times()" getter to > > G1CollectedHeap to avoid the 50+ times of using "policy()- > > > phase_times()" instead? > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8219748 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8219748/webrev/ > > Looks good! > > While you are at it, fix the indentation here? > > 2780 phase_times()->record_fast_reclaim_humongous_stats(time, > 2781 > cl.total_humongous(), > 2782 > cl.candidate_humongous()); > > -Aleksey > fixed in place (twice). Thomas From thomas.schatzl at oracle.com Wed Feb 27 12:42:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 13:42:05 +0100 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <74082ad7-e73e-66a4-0005-c51e5ee1ef30@redhat.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> <74082ad7-e73e-66a4-0005-c51e5ee1ef30@redhat.com> Message-ID: <4a7b63855fed036ce409d3fba984b3b496db07ee.camel@oracle.com> Hi, thanks for your review. On Wed, 2019-02-27 at 11:50 +0100, Aleksey Shipilev wrote: > On 2/27/19 10:29 AM, Thomas Schatzl wrote: > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8218880 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8218880/webrev/ > > Nits: > > *) "pause_succeeded" is a confusing name. "vmop_succeeded" adds to > confusion. Maybe both locals and > the methods should be called "gc_succeeded"? > > 2151 vmop_succeeded = op.pause_succeeded(); Fixed by using "gc" everywhere (I hope). > > > *) I think burning here without backoff is not nice for the test, > maybe sleep a little? > > libTestPeriodicCollectionJNI.c: > 40 while (!release_critical) /* empty */; > > I have been hesitant to go this way because of the many platforms we support, however it seems enough to just special-case Windows. I also added and extern "C" declaration to the test like many (but not all) other similar JNI code. New webrevs: http://cr.openjdk.java.net/~tschatzl/8218880/webrev.0_to_1/ (diff) http://cr.openjdk.java.net/~tschatzl/8218880/webrev.1/ (full) Test passes on all Oracle platforms. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 27 12:44:33 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 13:44:33 +0100 Subject: RFR (M): 8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap In-Reply-To: <9b2decb0-c57d-efe2-e052-15dbbfa187c2@redhat.com> References: <9b2decb0-c57d-efe2-e052-15dbbfa187c2@redhat.com> Message-ID: <31c1132269cdaa8d1234217419cf888f70999ddb.camel@oracle.com> Hi, thanks for your review. On Wed, 2019-02-27 at 11:41 +0100, Aleksey Shipilev wrote: > On 2/27/19 11:09 AM, Thomas Schatzl wrote: > > can I have reviews for this renaming change that removes some > > "g1_" prefixes to some G1CollectedHeap members? They are simply > > unnecessary within the context of G1. > > > > There has also been a "g1_collector_policy" method - after looking > > at its uses I decided to remove it and add a specific whitebox > > support method for it to G1CollectedHeap instead. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8219747 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8219747/webrev/ > > Looks good. It is a bit confusing to see the rename is_hetero_heap -> > is_heap_heterogeneous in this > changeset that talks about g1_ prefix removal, though. I removed this and will file separately. > Nits: > > *) Indentation in g1CollectedHeap.cpp: > > 864 if (policy()->need_to_start_conc_mark("concurrent humongous > allocation", > 865 word_size)) { > > 4449 policy()->phase_times()- > >record_fast_reclaim_humongous_time_ms((os::elapsedTime() - > start_time) * 1000.0, > 4450 > cl.humongous_objects_reclaimed()); > > *) Not sure if you want to rename locals too, like in > g1ConcurrentMarkThread.cpp: > > 246 G1Policy* g1_policy = g1h->policy(); > Fixed (also local names). http://cr.openjdk.java.net/~tschatzl/8219747/webrev.0_to_1/ (diff) http://cr.openjdk.java.net/~tschatzl/8219747/webrev.1/ (full) Still compiles locally. Thanks, Thomas From thomas.schatzl at oracle.com Wed Feb 27 12:54:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 27 Feb 2019 13:54:21 +0100 Subject: RFR (S): 8219856: Spell out G1CollectorPolicy::is_hetero_heap Message-ID: Hi all, can I have reviews for this small change in naming of the method G1CollectorPolicy::is_hetero_heap() which includes the (to me) really uncommon abbreviation for heterogeneous as hetero? Every time I read this I ask myselves what this means in context of G1. CR: https://bugs.openjdk.java.net/browse/JDK-8219856 Webrev: http://cr.openjdk.java.net/~tschatzl/8219856/webrev/ Testing: local compilation Thanks, Thomas From zgu at redhat.com Wed Feb 27 16:42:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 27 Feb 2019 11:42:00 -0500 Subject: RFR(S) 8219857: Shenandoah GC may initialize thread's gclab twice Message-ID: <1551285720.18805.112.camel@redhat.com> Please review this small patch to avoid initializing early worker's gclab twice. Bug: https://bugs.openjdk.java.net/browse/JDK-8219857 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8219857/webrev.00/ Test: tier1, 2, 3_gc_shenandoah on Linux x64 (fastdebug and release) Thanks, -Zhengyu From kim.barrett at oracle.com Wed Feb 27 17:23:25 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 12:23:25 -0500 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> References: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> Message-ID: <8C590E83-EF9B-4F61-86BE-55F36A9A53C5@oracle.com> > On Feb 27, 2019, at 4:37 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2019-02-26 at 17:49 -0500, Kim Barrett wrote: >>> On Feb 20, 2019, at 5:15 AM, Thomas Schatzl < >>> thomas.schatzl at oracle.com> wrote: >>> >>> Hi all, >>> >>> can I have reviews for this change that has been suggested as part >>> of another review to improve readability of the ExtRootScan sub- >>> phase printing? >>> >> [...] >> >> Looks good, but... >> >> I have something of a preference against cluttering enums with such >> pseudo-enumerators, and instead prefer class constants. But I'll >> leave it up to you. >> > > Fixed in > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.1/ (full) > > Yeah, looks better. Thanks for making me look at this option. > > Testing: compilation. > > Thanks, > Thomas Looks good. From rkennke at redhat.com Wed Feb 27 17:59:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Feb 2019 18:59:40 +0100 Subject: RFR(S) 8219857: Shenandoah GC may initialize thread's gclab twice In-Reply-To: <1551285720.18805.112.camel@redhat.com> References: <1551285720.18805.112.camel@redhat.com> Message-ID: <67009320-376e-a9a2-4d3b-726058a8e481@redhat.com> Looks ok. Thanks! Roman > Please review this small patch to avoid initializing early worker's > gclab twice. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219857 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8219857/webrev.00/ > > Test: > tier1, 2, 3_gc_shenandoah on Linux x64 (fastdebug and release) > > Thanks, > > -Zhengyu > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From sangheon.kim at oracle.com Wed Feb 27 19:14:11 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Wed, 27 Feb 2019 11:14:11 -0800 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> References: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> Message-ID: Hi Thomas, On 2/27/19 1:37 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2019-02-26 at 17:49 -0500, Kim Barrett wrote: >>> On Feb 20, 2019, at 5:15 AM, Thomas Schatzl < >>> thomas.schatzl at oracle.com> wrote: >>> >>> Hi all, >>> >>> can I have reviews for this change that has been suggested as part >>> of another review to improve readability of the ExtRootScan sub- >>> phase printing? >>> >> [...] >> >> Looks good, but... >> >> I have something of a preference against cluttering enums with such >> pseudo-enumerators, and instead prefer class constants. But I'll >> leave it up to you. >> > Fixed in > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.1/ (full) > > Yeah, looks better. Thanks for making me look at this option. Still looks good. Thanks, Sangheon > > Testing: compilation. > > Thanks, > Thomas > > From kim.barrett at oracle.com Wed Feb 27 21:44:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 16:44:22 -0500 Subject: RFR (M): 8219748: Add and use getter for the timing object in G1 In-Reply-To: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> References: <0e3cde14df7d268c633ecbf6fc3198d344d0070a.camel@oracle.com> Message-ID: <8054E638-17DD-4635-A2A4-432E0852FDD5@oracle.com> > On Feb 27, 2019, at 5:18 AM, Thomas Schatzl wrote: > > Hi, > > can I have reviews that adds a "phase_times()" getter to > G1CollectedHeap to avoid the 50+ times of using "policy()- >> phase_times()" instead? > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219748 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219748/webrev/ > Testing: > local compilation > > Thanks, > Thomas Looks good. From kim.barrett at oracle.com Wed Feb 27 21:53:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 16:53:09 -0500 Subject: RFR (S): 8219856: Spell out G1CollectorPolicy::is_hetero_heap In-Reply-To: References: Message-ID: > On Feb 27, 2019, at 7:54 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this small change in naming of the method > G1CollectorPolicy::is_hetero_heap() which includes the (to me) really > uncommon abbreviation for heterogeneous as hetero? > > Every time I read this I ask myselves what this means in context of G1. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219856 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219856/webrev/ > Testing: > local compilation > > Thanks, > Thomas Thanks for making this change. Looks good. From kim.barrett at oracle.com Wed Feb 27 22:19:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 17:19:35 -0500 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> Message-ID: <62EA39D8-3DC0-4A89-A14E-ABC5333CCD90@oracle.com> > On Feb 27, 2019, at 4:29 AM, Thomas Schatzl wrote: > > Hi all, > > can I have reviews for this change that fixes execution of periodic > GCs in G1? > > In the current implementation, if periodic GC is triggered when the gc > locker is held, the VM crashes because the GC locker is supposed to be > only held by Java threads - but the periodic GCs are triggered by some > GC thread. > > The fix is to ignore the periodic GC request if the GC locker is held - > after all this means that the application is active anyway, and a GC > will be triggered anyway as soon as the critical section ends. > > To make it clear to end users that the periodic GC has been cancelled > due to that reason, the change prints a cancellation reason too if > appropriate logging is enabled. > > The change itself is pretty small, it's just the test that's a bit > longer but straightforward. > > I will backport this to 12u later. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218880 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8218880/webrev/ > Testing: > New test case, hs-tier1-5 > > Thanks, > Thomas I think I would prefer "try_collect" rather than "attempt_collect". At first I was thinking this seems very specific to the particular bug at hand, and there is a need for something more general. But I've decided I'm okay with this change as is, and leaving generalization to the still-in-progress work on improving the whitebox control mechanism. So other than the possible name change, looks good. From sangheon.kim at oracle.com Thu Feb 28 04:36:31 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Wed, 27 Feb 2019 20:36:31 -0800 Subject: RFR (S): 8219856: Spell out G1CollectorPolicy::is_hetero_heap In-Reply-To: References: Message-ID: Hi Thomas, On 2/27/19 4:54 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change in naming of the method > G1CollectorPolicy::is_hetero_heap() which includes the (to me) really > uncommon abbreviation for heterogeneous as hetero? > > Every time I read this I ask myselves what this means in context of G1. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219856 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8219856/webrev/ Looks good to me too. Thanks, Sangheon > Testing: > local compilation > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Thu Feb 28 09:24:20 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 28 Feb 2019 10:24:20 +0100 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <62EA39D8-3DC0-4A89-A14E-ABC5333CCD90@oracle.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> <62EA39D8-3DC0-4A89-A14E-ABC5333CCD90@oracle.com> Message-ID: <02eda7053c550ac1b570a2e042c4d5583c973600.camel@oracle.com> Hi Kim, thanks for your review. On Wed, 2019-02-27 at 17:19 -0500, Kim Barrett wrote: > > On Feb 27, 2019, at 4:29 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > > > can I have reviews for this change that fixes execution of > > periodic GCs in G1? > > > > In the current implementation, if periodic GC is triggered when the > > gc locker is held, the VM crashes because the GC locker is supposed > > to be only held by Java threads - but the periodic GCs are > > triggered by some GC thread. > > > > The fix is to ignore the periodic GC request if the GC locker is > > held - after all this means that the application is active anyway, > > and a GC will be triggered anyway as soon as the critical section > > ends. > > > > To make it clear to end users that the periodic GC has been > > cancelled due to that reason, the change prints a cancellation > > reason too if appropriate logging is enabled. > > > > The change itself is pretty small, it's just the test that's a bit > > longer but straightforward. > > > > I will backport this to 12u later. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8218880 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8218880/webrev/ > > Testing: > > New test case, hs-tier1-5 > > > > Thanks, > > Thomas > > I think I would prefer "try_collect" rather than "attempt_collect". > Done. > At first I was thinking this seems very specific to the particular > bug at hand, and there is a need for something more general. But I've > decided I'm okay with this change as is, and leaving generalization > to the still-in-progress work on improving the whitebox control > mechanism. Thanks. Please also consider that this change is supposed to be backported. > > So other than the possible name change, looks good. > New webrevs: http://cr.openjdk.java.net/~tschatzl/8218880/webrev.1_to_2/ (diff) http://cr.openjdk.java.net/~tschatzl/8218880/webrev.2/ (full) Thanks, Thomas From thomas.schatzl at oracle.com Thu Feb 28 09:25:32 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 28 Feb 2019 10:25:32 +0100 Subject: RFR (S): 8219856: Spell out G1CollectorPolicy::is_hetero_heap In-Reply-To: References: Message-ID: Hi Sangheon, Kim, On Wed, 2019-02-27 at 20:36 -0800, sangheon.kim at oracle.com wrote: > Hi Thomas, > > On 2/27/19 4:54 AM, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for [...] > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8219856 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8219856/webrev/ > > Looks good to me too. > > Thanks, > Sangheon On Wed, 2019-02-27 at 16:53 -0500, Kim Barrett wrote: > > On Feb 27, 2019, at 7:54 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi all, > > [...] > Thanks for making this change. > > Looks good. > Thanks for your reviews, Thomas From thomas.schatzl at oracle.com Thu Feb 28 09:28:15 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 28 Feb 2019 10:28:15 +0100 Subject: RFR (S): 8219369: Add named constants for iterating ExtRootScan phases In-Reply-To: <8C590E83-EF9B-4F61-86BE-55F36A9A53C5@oracle.com> References: <9D95EE27-D214-45E3-A92A-903CA647CA82@oracle.com> <5492fc7c3472b8ad386d7b1c9fea2b078a29ec1e.camel@oracle.com> <8C590E83-EF9B-4F61-86BE-55F36A9A53C5@oracle.com> Message-ID: <107a46787b93d53187a2ad26656094090f73197c.camel@oracle.com> Hi Kim, Sangheon, On Wed, 2019-02-27 at 12:23 -0500, Kim Barrett wrote: > > On Feb 27, 2019, at 4:37 AM, Thomas Schatzl < > > thomas.schatzl at oracle.com> wrote: > > > > Hi, > > [...] > > > I have something of a preference against cluttering enums with > > > such pseudo-enumerators, and instead prefer class constants. But > > > I'll leave it up to you. > > > > > > > Fixed in > > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.0_to_1/ (diff) > > http://cr.openjdk.java.net/~tschatzl/8219369/webrev.1/ (full) > > > > Yeah, looks better. Thanks for making me look at this option. > > > Looks good. > On Wed, 2019-02-27 at 11:14 -0800, sangheon.kim at oracle.com wrote: > Hi Thomas, > > On 2/27/19 1:37 AM, Thomas Schatzl wrote: > > Hi, [...] > > Yeah, looks better. Thanks for making me look at this option. > > Still looks good. > > Thanks, > Sangheon > thanks for your reviews. Thomas From zgu at redhat.com Thu Feb 28 13:27:35 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 28 Feb 2019 08:27:35 -0500 Subject: RFR(S) 8219857: Shenandoah GC may initialize thread's gclab twice In-Reply-To: <67009320-376e-a9a2-4d3b-726058a8e481@redhat.com> References: <1551285720.18805.112.camel@redhat.com> <67009320-376e-a9a2-4d3b-726058a8e481@redhat.com> Message-ID: <1551360455.18805.113.camel@redhat.com> On Wed, 2019-02-27 at 18:59 +0100, Roman Kennke wrote: > Looks ok. Thanks! > Roman Thanks, Roman. -Zhengyu > > > Please review this small patch to avoid initializing early worker's > > gclab twice. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219857 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8219857/webrev.00/ > > > > Test: > > tier1, 2, 3_gc_shenandoah on Linux x64 (fastdebug and release) > > > > Thanks, > > > > -Zhengyu > > > > From kim.barrett at oracle.com Thu Feb 28 20:48:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 28 Feb 2019 15:48:04 -0500 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <02eda7053c550ac1b570a2e042c4d5583c973600.camel@oracle.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> <62EA39D8-3DC0-4A89-A14E-ABC5333CCD90@oracle.com> <02eda7053c550ac1b570a2e042c4d5583c973600.camel@oracle.com> Message-ID: <395C93E6-491F-4434-B962-14F98E7F3A6D@oracle.com> > On Feb 28, 2019, at 4:24 AM, Thomas Schatzl wrote: > > Hi Kim, > > thanks for your review. > > On Wed, 2019-02-27 at 17:19 -0500, Kim Barrett wrote: >> At first I was thinking this seems very specific to the particular >> bug at hand, and there is a need for something more general. But I've >> decided I'm okay with this change as is, and leaving generalization >> to the still-in-progress work on improving the whitebox control >> mechanism. > > Thanks. Please also consider that this change is supposed to be > backported. Good point. >> So other than the possible name change, looks good. >> > > New webrevs: > > http://cr.openjdk.java.net/~tschatzl/8218880/webrev.1_to_2/ (diff) > http://cr.openjdk.java.net/~tschatzl/8218880/webrev.2/ (full) > > Thanks, > Thomas Looks good. From shade at redhat.com Thu Feb 28 22:00:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 Feb 2019 23:00:32 +0100 Subject: RFR (M): 8218880: G1 crashes when issuing a periodic GC while the GCLocker is held In-Reply-To: <02eda7053c550ac1b570a2e042c4d5583c973600.camel@oracle.com> References: <6cd39241e3e33811ced64ff42a1b15ab2044bbef.camel@oracle.com> <62EA39D8-3DC0-4A89-A14E-ABC5333CCD90@oracle.com> <02eda7053c550ac1b570a2e042c4d5583c973600.camel@oracle.com> Message-ID: <8bf353b3-5273-7106-2a86-10949d72f028@redhat.com> On 2/28/19 10:24 AM, Thomas Schatzl wrote: > http://cr.openjdk.java.net/~tschatzl/8218880/webrev.1_to_2/ (diff) > http://cr.openjdk.java.net/~tschatzl/8218880/webrev.2/ (full) I realized I never replied to this, sorry. Looks good. The test looks ugly with ifdefs, but oh well, I can't think of better version. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Thu Feb 28 22:01:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 Feb 2019 23:01:53 +0100 Subject: RFR (M): 8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap In-Reply-To: <31c1132269cdaa8d1234217419cf888f70999ddb.camel@oracle.com> References: <9b2decb0-c57d-efe2-e052-15dbbfa187c2@redhat.com> <31c1132269cdaa8d1234217419cf888f70999ddb.camel@oracle.com> Message-ID: <9cd6d187-f82e-a62d-be0e-458efd6dad47@redhat.com> On 2/27/19 1:44 PM, Thomas Schatzl wrote: > http://cr.openjdk.java.net/~tschatzl/8219747/webrev.0_to_1/ (diff) > http://cr.openjdk.java.net/~tschatzl/8219747/webrev.1/ (full) Looks good! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: