Re: RFR: 8256499: Zero: enable Epsilon GC

2020-11-19 Thread Aleksey Shipilev
On Wed, 18 Nov 2020 09:52:22 GMT, Magnus Ihse Bursie wrote: >> Following the >> [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) improvement >> that ditched the inline contiguous alloc use from Zero, we can now rely on >> GC interface to hook the GCs properly. Epsilon GC does no

Integrated: 8256499: Zero: enable Epsilon GC

2020-11-19 Thread Aleksey Shipilev
On Tue, 17 Nov 2020 19:11:45 GMT, Aleksey Shipilev wrote: > Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) > improvement that ditched the inline contiguous alloc use from Zero, we can > now rely on GC interface to hook the GCs properly. Epsilon GC does not > requ

Re: RFR: 8256497: Zero: enable G1 and Shenandoah GCs [v2]

2020-11-19 Thread Aleksey Shipilev
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) > improvement that ditched the inline contiguous alloc use from Zero, we can > now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a > bit special here, because they require special `Reference.ge

Re: RFR: 8256497: Zero: enable G1 and Shenandoah GCs [v2]

2020-11-19 Thread Magnus Ihse Bursie
On Thu, 19 Nov 2020 08:32:14 GMT, Aleksey Shipilev wrote: >> Following the >> [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) improvement >> that ditched the inline contiguous alloc use from Zero, we can now rely on >> GC interface to hook the GCs properly. G1 and Shenandoah ar

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

2020-11-19 Thread Serguei Spitsyn
On Thu, 19 Nov 2020 00:39:52 GMT, Kim Barrett wrote: >> Hi Coleen, >> It looks good to me. >> Just a couple of nits below. >> >> src/hotspot/share/prims/jvmtiTagMap.cpp: >> >> There is a double-check for _needs_cleaning, so the one at line 136 can be >> removed: >> 136 if (_needs_cleaning &

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

2020-11-19 Thread Coleen Phillimore
On Thu, 19 Nov 2020 10:10:06 GMT, Serguei Spitsyn wrote: >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp: >>> >>> The change below is not needed as the call to >>> nsk_jvmti_aod_disableEventAndFinish() does exactly the same: >>> >>> ``` >>> -nsk_jv

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

2020-11-19 Thread Coleen Phillimore
On Thu, 19 Nov 2020 12:36:46 GMT, Coleen Phillimore wrote: >> @kimbarrett >> Okay, thank you for explanation. >> I agree, it'd make sense to improve the comment a little bit. >> Thanks, >> Serguei > > So should nsk_jvmti_aod_disableEventAndFinish pass the address of success > instead? Why didn'

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

2020-11-19 Thread Coleen Phillimore
On Thu, 19 Nov 2020 12:51:11 GMT, Coleen Phillimore wrote: >> So should nsk_jvmti_aod_disableEventAndFinish pass the address of success >> instead? Why didn't it fail before this change? >> Ok, with this change, it's not posted yet and the success variable for >> nsk_aod_agentFinished is the l

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

2020-11-19 Thread Coleen Phillimore
> This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the > table to follow oops and then to rehash the table, this table poin

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

2020-11-19 Thread Coleen Phillimore
> This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the > table to follow oops and then to rehash the table, this table poin

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

2020-11-19 Thread Coleen Phillimore
On Thu, 19 Nov 2020 12:54:23 GMT, Coleen Phillimore wrote: >> /* Flush any pending ObjectFree events, which will set global success >> variable to 1 >>for any pending ObjectFree events. */ >> How about this? The word 'global' helps me. > > With remerging into shenandoah, all the jdi te

Integrated: 8212879: Make JVMTI TagMap table concurrent

2020-11-19 Thread Coleen Phillimore
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote: > This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the > table

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v2]

2020-11-19 Thread Robin Westberg
> We should be more explicit about OS and compiler versions used in the GitHub > Actions builds, to avoid problems caused by unexpected changes to the > defaults. This patch changes the OS and GCC versions used from ubuntu-latest > (currently 18.04, but will change to 20.04 sometime soon) / defa

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v2]

2020-11-19 Thread Robin Westberg
On Mon, 16 Nov 2020 15:12:25 GMT, Magnus Ihse Bursie wrote: >> .github/workflows/submit.yml line 190: >> >>> 188: run: | >>> 189: sudo apt-get install libxrandr-dev libxtst-dev libcups2-dev >>> libasound2-dev >>> 190: sudo update-alternatives --install /usr/bin/gcc g

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v3]

2020-11-19 Thread Robin Westberg
> We should be more explicit about OS and compiler versions used in the GitHub > Actions builds, to avoid problems caused by unexpected changes to the > defaults. This patch changes the OS and GCC versions used from ubuntu-latest > (currently 18.04, but will change to 20.04 sometime soon) / defa

Re: RFR: 8256393: Github Actions build on Linux should define OS and GCC versions [v3]

2020-11-19 Thread Magnus Ihse Bursie
On Thu, 19 Nov 2020 16:22:20 GMT, Robin Westberg wrote: >> We should be more explicit about OS and compiler versions used in the GitHub >> Actions builds, to avoid problems caused by unexpected changes to the >> defaults. This patch changes the OS and GCC versions used from ubuntu-latest >> (c

Re: RFR: 8255526: Enable jcheck whitespace checking of build system files [v2]

2020-11-19 Thread Magnus Ihse Bursie
On Thu, 29 Oct 2020 00:54:41 GMT, Magnus Ihse Bursie wrote: >> I need to put this on hold for a while. It turned out that the Skara jcheck >> disallows initial tabs, which makes sense for sane source code formats >> (java, c++) but is unfortunately an incorrect assumption for makefiles. >> >>

Re: RFR: 8255526: Enable jcheck whitespace checking of build system files [v2]

2020-11-19 Thread Magnus Ihse Bursie
> With the new Skara tooling, we can finally enable whitespace testing for > build system files (makefiles and autoconf files). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add ignore-tabs - Changes: - all: h

Re: RFR: 8255526: Enable jcheck whitespace checking of build system files [v2]

2020-11-19 Thread Aleksey Shipilev
On Fri, 20 Nov 2020 00:31:17 GMT, Magnus Ihse Bursie wrote: >> With the new Skara tooling, we can finally enable whitespace testing for >> build system files (makefiles and autoconf files). > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the