🇳🇱
@icedquinn Not sure I agree. The whole point of the GC not being explicit is to reduce human error, and it does a good job at that. Java performance compared to many other interpreted languages is exceptional (not so much .net).
You also do have the ability to "suggest" the invocation of garbage collection should you need to add some explicit control to speed things up. but it rarely makes much of a difference.
) so we could collect between game frames. the hoard of c# games doesn't scavenge time when its opportune and just framedrops at random ass times.there's a lot of deployments where its actually fine for the GC to stop the world, it just needs to tell the load balancer about it ahead of time
> 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.
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
"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.
:bing: 
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
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.
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.
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.
