On Wed, 2 Feb 2022 16:21:05 GMT, Chris Plummer wrote:
> Actually it's not, and that's why I check the Eden gen.
Yes sorry, should have said it's a good bet to find a String when only checking
one generation. Carry on...
-
PR: https://git.openjdk.java.net/jdk/pull/7295
On Wed, 2 Feb 2022 09:49:26 GMT, Kevin Walls wrote:
> For the scanoops for a type, it seems like a reasonable assumption that there
> will be a String in the old gen!
Actually it's not, and that's why I check the Eden gen. If a GC is not
triggered, the old gen will be empty. It not actually gu
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
On Wed, 2 Feb 2022 00:14:06 GMT, Serguei Spitsyn wrote:
> There is minor duplication but it is okay as there is no good way to get rid
> of it.
I considered a loop or common method, but it seemed not to be worth it and
likely less readable.
-
PR: https://git.openjdk.java.net/jdk/
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
The test is failing to find certain types in the scanoops output when run with
-Xcomp. This is happening in the loom repo. The reason it is happening there is
because loom introduced a full GC during codecache sweeping. The test only runs
scanoops on the eden gen, and the full GC is causing obje
