Re: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2]

2022-01-27 Thread Chris Plummer
> When using -Xcomp, the liveness of some objects the test allocates is more > precisely known, allowing the objects to be collected before the test > expects. This became an issue in the loom repo because it has changes that > result in a full GC when the codecache is swept. This is fixed by us

Re: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2]

2022-01-27 Thread Alan Bateman
On Fri, 28 Jan 2022 07:46:01 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more >> precisely known, allowing the objects to be collected before the test >> expects. This became an issue in the loom repo because it has changes that >> result

Re: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2]

2022-02-01 Thread Alex Menkov
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more >> precisely known, allowing the objects to be collected before the test >> expects. This became an issue in the loom repo because it has changes that >> result

Re: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2]

2022-02-01 Thread Leonid Mesnik
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more >> precisely known, allowing the objects to be collected before the test >> expects. This became an issue in the loom repo because it has changes that >> result

Re: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2]

2022-02-01 Thread Chris Plummer
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more >> precisely known, allowing the objects to be collected before the test >> expects. This became an issue in the loom repo because it has changes that >> result