Java GC is only efficient if you allow it to be wasteful. I'm regularly running hundreds of different ocaml programs on a single machine and I trust ocaml GC to actually collect the garbage. I would not trust tens of java processes in default GC mode, which seems to be tuned for cases where a single process own the whole machine.

Hopefully, the multicore GC will be as good, or one will be able to disable multicore abilities when not in use (which is going to be most of the time, I believe)

what i know is that it is inherently harder to have good GC performance with mutable language

and as i said D has a very small community Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance, and still today, Java optimization is a specialized experts job

> Java optimization is a specialized experts job

No its not. Modern Java GC's require 0 tuning. ZGC with default settings can achieve submillisecond pauses.

> and as i said D has a very small community Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance

This wasn't your argument. You stated that mutability was the reason that D couldn't have a good GC, not the size of its community or resources. According to tiobe D is more popular than OCaml as well.

D also suffers from the community always racing after the next big thing without fixing the current set of issues.