@icedquinn

> they stop the world without telling the process

No not really. The GC doesnt freeze your program, it is smart enough to work within the idle time most of the time. You'd be hard pressed to get the GC to glitch your program or slow things down compared to manually doing it. If you do it manually and do a really good job in almost all situations I you will likely get improvements so minimal you could barely measure it.

@freemo not talking about the total clock time to collect. ref counting does constantly pay that cost. talking about the response time.

with a GC there i always a threat of sudden syncopation

@icedquinn If you are worried about momentary latency at moments when latency is super critical then use the Java Real-time specification, JSR1

@freemo it's really not that hard to communicate with a GC in the form of

"hey, this is a good stop point. do you want to stop?" and if yes, signal the service down and go to sleep until its done repacking the 8gb heap.

java/c# don't let you do that, though.

@icedquinn @freemo

So many Enterprise software and server solutions still use Java for their critical infrastructure today.

I worked for an S3-compatible company that uses Cassandra for the DB and all the other components were made in Java....GC definitely caused issues. The GC disadvantages must not outway the benefits of Java

@verita84 @freemo the enterprise people are where i read about monstrously sized stacks and heaps with nontrivial processing times.

you can route around some of it at the mq layer, like telling rabbit to only dispense one message per acknowledgement. then when the app server inevitably takes its shit, only two requests in flight are stalled. or one job, in a pull system.

you get stuff like shenandoah which is a very complex collector. but you won't get an interrupt "GC IS ABOUT TO HAPPEN! PANIC!" or an option to pre-emptively warn the system. there is typically a command to attempt a collection right now, but its not probative. if the gc was doing to do it it takes that as an invitation to do it now, rather than let you prep for it.

afaik enterprise code just invests in more gcs that strive to be better at being invisible, rather than cooperative ones.

@icedquinn

Nah, usually the problem is the coders are just clueless as to how to properly work with the GC. Its very common to have shitty coders when it comes to performance issues.

@verita84

Just changed a variable to a constant (already known by the app) in an bunch of sql queries to speed up by 10000. This reduces the runtime from 4.5 yrs to 3 hrs - much more reasonable.

@sdgathman

You joke but to be fair what seperates an expert from a noob is nuance like this. An expert probably wouldnt make those sorts of little mistakes too often to begin with.

@icedquinn @verita84

@verita84

I have heard that claim many times... every single time when I investigated it wasnt true and came down to user error (or a lack of understanding in the mechanics of the GC)... Probably 200 times in my career as the guy consultant people call in to fix other peoples mess.

Pbviously in your case I cant say much more without seeing the code or knowing more of the problem... but not once has the GC ever actually turned out to be the problem in the end.

@icedquinn

In 35 years of using GC in various forms, the only real tradeoff I've ever encountered is increased memory use. Typically, it is double, but if you reuse objects (add to collect to "free"), that can be reduced (at the expense of now introducing possible "reuse while still in use" bugs).

@sdgathman

Yea absolutely, the inefficient usage of memory in terms of spaces is entirely legit. In fact thats part of the reason its so fast, because it pre-slates the memory too (meaning it uses the memory regardless of if you use it or not)... but also object storage can be more expensive since it wont clean up right away...

The age old tradeoff of more space being consumed for the advantage of faster speed.

@icedquinn @verita84

Also, C-Python has a very space efficient GC by using reference counting in addition to normal GC. The vast majority of objects are collected when their refcnt goes to 0. The GC is needed for the occasional cycles. The refcnt overhead is trivial compared to the interpreter overhead.

@sdgathman

I mean, if you need a space-effecient GC there are quite a few options. Of course the issue with Python is the GIL, less of an issue in C-Python though.

@icedquinn @verita84

@icedquinn

Java lets you do that.

System.gc()

If you call that it prioritized the GC, except you dont need to stop. you can keep running and the GC will clean up the 8gb heap without needing to stop your program at all (though you are welcome to stop if you have nothign to do and speed up the GC a bit I guess).

@freemo i guess you’re not reading anything i’m saying before responding, because there are only so many ways i can rephrase the following

if gc.needs_to_run: consul.health_check = hcStop defer: consul.health_check = hcGood gc.collect

@icedquinn

Did you read what I said... as I said you can do that... you just have no need to stop and restart the health check. Though you can if you really want to for some reason.

System.gc(), call it when you have downtime, you now just accomplished what you wanted.

@freemo i did have some curiosity about the arena allocators for application servers, but that's going so far against the grain you end up having to code the entire framework yourself

but.. no memory leaks ever that way, so that's fun

@icedquinn If you use C and traditional malloc and free calls to allocate memory as needed on a per object basis, it is actually **significantly** slower than Java's GC and memory allocation, for example.

If you use a library to pre-slate your memory and do a few really special stuff (thus removing you from access to malloc directly) you will get speeds comparable to Java at best.

You would have a really hard time beating Java's GC manually.

@icedquinn @freemo I remember reading that Erlang has a funny way of handling that. It has a stop-the-world GC, except it's per process and Erlang is optimised to handle things with a crapton of small processes with small heaps. So your program cleans up tiny patches of garbage all the time, each process fast enough to be imperceptible.

I always wanted to make something in Erlang but never had a good project idea that fits it. Elixir also sounds interesting but again, wtf do I use it for, I'm not about to start implementing an nth Pleroma.

@Amikke

Java has several GC options that wont stop the world and ones that are super low latency as well as ones that are time constant (takes the same time to freeup a 100 TB heap as it does a 1KB heap)..

It is quite extrodinary how performant the Java GC is, out of all the memory managed languages it is probably the most efficient, if you know how to use it.

@icedquinn