Go does not need a Java-style GC

That’s neat, but a lot of applications will never need 16TB.

FWIW, I used to write some high-performance JavaScript. One of the tricks of the trade was to allocate early and make sure you avoid allocating once the loading phase has started, hence avoiding triggering the garbage-collector (in most runtimes/languages, gc phases are typically triggered by the allocator). This involved writing very non-idiomatic code, to a large extent reimplementing a form of high-level custom allocator on top of the existing allocator/gc, but it worked.

I'd be very surprised if the same wasn't possible in Java.

I don't know if this is how gRPC is written but it could explain an apparent contradiction.

> In a multithreaded program, a bump allocator requires locks. That kills their performance advantage.

Wait, what?

What's wrong with:

    char theHeap[0x1000000];
    atomic_ulong bumpPtr;

    void* bump_malloc(int size){
        uint32_t returnCandidate = bumpPtr.fetch_add(size, std::memory_order_relaxed); 
        if(returnCandidate + size >= HEAP_SIZE){
            // Garbage collect. Super complicated, lets ignore it lol.
            // Once garbage collect is done, try to malloc again. If fail then panic().
        }
        return &theHeap[returnCandidate];
    }

------

You don't even need acq_release consistency here, as far as I can tell. Even purely relaxed memory ordering seems to work, which means you definitely don't need locks or even memory barriers.

The exception is maybe the garbage-collect routine. Locking for garbage collect is probably reasonable (other programmers accept that garbage-collection is heavy and may incur a large running + synchronization costs), but keeping locks outside of the "hot path" is the goal.

------

This is what I do with my GPU test programs, where locking is a very, very bad idea (but possible to do). Even atomics are kinda-bad in the GPU world but relaxed-atomics are quite fast.

-------

> In Java, this requires 15 000 separate allocations, each producing a separate reference that must be managed.

Wait, what?

    points [] array = new points[15000];

This is a singular alloc in Java. 15000 _constructors_ will be called IIRC (My Java is rusty though, someone double-check me on that), but that's not the same as 15000 allocs being called, not by a long shot.

------

Frankly, it seems like this poster is reasonably good at understanding Go performance, but doesn't seem to know much about Java performance or implementations.

> Java is a language that basically outsourced memory management entirely to its garbage collector. This turned out to be a big mistake.

Given that Java is not far behind C and C++ for many kinds of workload and in quite some scenarios can outperform C code, I'm not sure that I buy this line of reasoning.

> Doing these updates requires freezing all threads.

Eh, what? There are multi-threaded GCs, what is this article even talking about?

> However, this does not put C# and Java on equal footing with languages like Go and C/C++ in terms of memory management flexibility

In which world are Go and C in the same worlds when it comes to memory management flexibility? That's like comparing a language that uses a Garbage Collector to one that requires manual memory management. Because - it is.

> Modern Languages Don’t Need Compacting GCs

> If need be, the Pacer slows down allocation while speeding up marking.

So, you just traded in one drawback for another?

Heck, I get it. The JVM is not a thin graceful fawn. It's a complicated beast that requires years of experience to tame it - and even then it will come back from time to time an bite you. There are many good points to critique the JVM - but I don't get the feeling that the author of this article has spent much time with modern JVMs because he's not pointing out any of them.

[flagged]