Hacker News Reader

Comment by legulere | Hacker News Reader

Isn’t garbage collection going to introduce jitter?

Not necessarily, there are several OSes written in GC enabled systems programming languages.

Just because a language has a GC it doesn't mean it is the only means to allocate memory.

Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them.

And make use of profilers as well.

For example, on performance critical paths always use a standard for loop, never a for range one.

> For example, on performance critical paths always use a standard for loop, never a for range one.

i am curious, why would one use a normal for loop, instead of a range one?

A range one might introduce boxing depending on the types being iterated.

Or use a language with reified generics :)

Go maps are reified generics, and very efficient ones at that.

What you mean is it's a set of C macros, except built-in to the compiler. Great if it's exactly what you need. And you're prepared for severe WTF moments (e.g. equality on map values is ... not the same as equality on variables of the same type containing the same thing). Also, expect the whole thing to be useless if you need slight complexity (e.g. you can use strings as keys, but not bytes (either Bytes, or []byte, but you can use [5]byte for example).

Oh ... you actually need it to be a red-black tree, or a custom hash function ? Tough.

GC will always introduce jitter.

You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter.

Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it.

There is a reason why the GC-enabled OSs aren't used for anything in reality.

BTW: There should be no difference between for and for-range loops given an optimiser thats working.

> GC will always introduce jitter.

> You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter.

It only introduces jitter if it runs at all.

If one really wants to be drastic in performance critical code, in most GC runtimes it is possible to just turn it off.

On Go's case a runtime.SetGCPercent(-1) will take care of that.

> There is a reason why the GC-enabled OSs aren't used for anything in reality.

And me thinking I had two running on my phones, go figure.

And the default is 100, which means a double in newly allocated memory space. I have written several servers that after starting up (and running uselessly the GC once), never need to run it again.

Care to say which GC-enabled OS you have on your phone?

I'm not talking about GC-enabled runtimes such as a JVM or ObjC/Swift runtime, they're application-level.

Both Mach(IOS) and Linux(Android) are non-GC-enabled OSs.

> GC will always introduce jitter.

Hard real-time garbage collectors (including real-time reference counting approaches) can be used in such a way as to eliminate memory-management jitter.

Region allocation - a form of GC - can be used in such a way as to avoid memory-management jitter.

> GC-enabled OSs aren't used for anything in reality.

You might have a narrow definition of what you consider to be an OS. I would argue that things like the JVM, the Erlang BEAM, and even the browser are OS-like enough to qualify.

Not in general, though of course lots of production language runtimes do involve a certain amount of GC-related jitter. But even where such jitter is introduced, it might not be a very big deal for something like TCP/IP.

Reply on news.ycombinator.com