Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

It is just struggling.  Or maybe it's really that CPU bound on these targets, but I don't think so

I can see the GCs happening in the debugger

or is the comparison == via pants.ini.isolated ?

```jvm_options: [
    '-Xmx6500m', '-XX:MaxPermSize=512m', '-XX:+UseConcMarkSweepGC', '-XX:ParallelGCThreads=4',
    # GC perf tuning per DPB-5913
    '-XX:NewSize=2000m', '-XX:NewRatio=2', '-XX:SurvivorRatio=8',
    # bigger cache size for our big projects (default is just 5)
    '-Dzinc.analysis.cache.limit=1000',
  ]```

AFAICT once old gen grows it never shrinks again

to be completely transparent, we have noticed slowdowns for large graphs, but so far have only fingered io

<@U053HNE90>: with CMS it will not shrink again, correct. with the default GC it will

it's entirely possible that there is a leak somewhere.

It rocketed through 9gb of heap with no problem

But if the GC algorithm is pinned I doubt it matters

(I think we might have actually been pinning to OldParallelGC before, which maybe explains this)

while you're experimenting, might also see how G1 does for you.

So it looks like switching to CMS might actually work here