4 ms·

Well it works much better than the JVM one so they must be doing something right. I never saw processes GC lock up like JVM until I worked on a big Java project

by rb808 6y ago

Well it works much better than the JVM one so they must be doing something right. I never saw processes GC lock up like JVM until I worked on a big Java project.

vips7L 6y ago
Which JVM one? CMS? Parallel? G1? ZGC? Shenandoah?
- rb808 6y ago
  You're right, its getting better. Main problems were older JREs, G1 in 11 is better but still locks up. We haven't used ZGC in prod yet. The main thing is dotnet had this figured out 10 years ago while Java is still struggling.
  - mumblemumble 6y ago
    There are two sides to that coin. .NET, by putting all their efforts into just one GC, has absolutely reaped a lot of benefits in terms of working well without any fuss. .NET also has better ergonomics around memory management. For example, it has much clearer and stronger guarantees about what state the runtime environment will be in after an out-of-memory error. On the other hand, I'm sure that making these guarantees have at times constrained the things that .NET can do with its garbage collector. Java, by making the GC a plugin, has certainly spread its efforts thinner. It's also turned the Java-facing side of the memory management subsystem into a somewhat scary and mysterious black box, since that very swappability means that the application itself can assume almost nothing about its behavior. On the other hand, if ops wants to put the effort into tuning it, Java lets them have a lot more ability to control an application's memory and performance characteristics in production. It also leaves a lot more room for boutique JVMs with their own special memory managers. Which approach to prefer is, I think, as much a matter of personal or organizational values as it is about technical merit.
whateveracct 6y ago
What about throughput?
kqr 6y ago
I could say the same thing with the names swapped. I have never really seen a JVM process stall more than a few hundred ms. The CLR process I work with stalls for multiple seconds every 30 minutes ish. Edit: and by this I don't mean that one of us is wrong. I mean that it might depend more on the application and its memory allocation patterns than the runtime.
- merb 6y ago
  btw. you can't compare the two. dotnet works way closer to the metal than java does. that's due to better interop and also since span exists, which also has more/better control over unmanaged memory in a more accessible way. also struct's exists which eliminates a lot of problems when memory constrained. example most java date objects are classes and use way more memory than any available object/library in dotnet (which are using structs)

by rb808 6y ago

Well it works much better than the JVM one so they must be doing something right. I never saw processes GC lock up like JVM until I worked on a big Java project.

vips7L 6y ago

Which JVM one? CMS? Parallel? G1? ZGC? Shenandoah?

rb808 6y ago
You're right, its getting better. Main problems were older JREs, G1 in 11 is better but still locks up. We haven't used ZGC in prod yet. The main thing is dotnet had this figured out 10 years ago while Java is still struggling.
- mumblemumble 6y ago
  There are two sides to that coin. .NET, by putting all their efforts into just one GC, has absolutely reaped a lot of benefits in terms of working well without any fuss. .NET also has better ergonomics around memory management. For example, it has much clearer and stronger guarantees about what state the runtime environment will be in after an out-of-memory error. On the other hand, I'm sure that making these guarantees have at times constrained the things that .NET can do with its garbage collector. Java, by making the GC a plugin, has certainly spread its efforts thinner. It's also turned the Java-facing side of the memory management subsystem into a somewhat scary and mysterious black box, since that very swappability means that the application itself can assume almost nothing about its behavior. On the other hand, if ops wants to put the effort into tuning it, Java lets them have a lot more ability to control an application's memory and performance characteristics in production. It also leaves a lot more room for boutique JVMs with their own special memory managers. Which approach to prefer is, I think, as much a matter of personal or organizational values as it is about technical merit.

whateveracct 6y ago

What about throughput?

kqr 6y ago

I could say the same thing with the names swapped. I have never really seen a JVM process stall more than a few hundred ms. The CLR process I work with stalls for multiple seconds every 30 minutes ish. Edit: and by this I don't mean that one of us is wrong. I mean that it might depend more on the application and its memory allocation patterns than the runtime.

merb 6y ago
btw. you can't compare the two. dotnet works way closer to the metal than java does. that's due to better interop and also since span exists, which also has more/better control over unmanaged memory in a more accessible way. also struct's exists which eliminates a lot of problems when memory constrained. example most java date objects are classes and use way more memory than any available object/library in dotnet (which are using structs)