4 ms·
> The GC is not suited to functional programs (lots of small, short-lived allocations) WUT? That's _exactly_ the thing the GC is good at, and it's that way not
by soc88 15y ago
> The GC is not suited to functional programs (lots of small, short-lived allocations)
WUT? That's _exactly_ the thing the GC is good at, and it's that way not since yesterday.
The limiting factor is the speed of allocation (no GC involved), not GC.
- tomp 15y agoThe design of the GC can limit the speed of allocation as well. If your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions: add to the current top of young heap, and check for overflow. That's how OCaml does it. I'm not sure how to do it concurrency-safe, though. Maybe using small per-thread heaps that get collected whenever an object is shared between threads, or by statically inferring which objects can be shared and which are thread-local.
- lemming 15y agoIf your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions... That's how OCaml does it. That's also how the JVM does it. You can criticise the JVM on some things, but GC performance is not one of them. You should really make sure you're better informed before posting FUD like this.
- tomp 15y agoI'm sorry. I was reading soc88's complaint about the speed of allocation, and blindly assumed that this was the problem with JVM. Please downvote my comment so that other people won't read it.