ZGC is extremely good work.

https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main

> ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB.

Go's GC is also very good: https://go.dev/blog/greenteagc.

V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.)

I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.

▲

RedComet 3 minutes ago | parent | next [-]

Are any of those actually pauseless like he asked for?

▲

adastra22 2 hours ago | parent | prev | next [-]

A millisecond is an eternity. It is 1/3 of the entire time allocated to a frame update in a modern game.

	▲	treyd an hour ago \| parent \| next [-]
		Game GCs are interesting because you know that the execution is structured like this and you know how much time you have left before you have to switch back to application code for the next frame/time step. There's interesting optimizations you can make around this and could almost completely avoid user-observable GC pauses.
	▲	quotemstr an hour ago \| parent \| prev \| next [-]
		Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack. That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault: You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right? No? You're not doing any of these things? Then why are you worried about 1ms in GC?
	▲	kelseyfrog an hour ago \| parent \| prev [-]
		Exactly. This is why Minecraft Java edition was such a disastrous flop.

▲

platinumrad 2 hours ago | parent | prev [-]

If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.

	▲	phplovesong an hour ago \| parent [-]
		You just described http://www.lisette.run