That would be some Java-based Scheme e.g. SISC or Kawa, running on the Shenandoah-OpenJDK JVM.
Many older "concurrent GC" algorithms don't scale in the respect that they break down (as in start to have really bad STW:s) around some single-digit number of GB of heap size, so they provide a certain offset to the STW problem but not a remedy.
(I'd wonder what GC algo the current V8 and Firefox JSVM:s use, especially what GC:s are there out there that are concurrent in the sense doing collection work in a separate GC thread and then only syncing with the VM threads for some kind of last checkpoint e.g. to checkpoint the stack bindings as roots. In that case the only time VM code would be affected by the GC (minus load/store barrier overhead) would be stall due to object allocations running out of memory. I wonder does any algo like that exist?)