4 ms·

Isn't it great? You don't need a degree to operate the thing. When there are esoteric conditions like the one described in the post, the team is usually super r

Isn't it great? You don't need a degree to operate the thing. When there are esoteric conditions like the one described in the post, the team is usually super responsive to fix them if they're bugs, or give you reasonable and lightweight workarounds when they're not.

mnd999 7y ago
In this case, no. And what they’re doing doesn’t sound all that esoteric either. I’ve got 64gb to use but I’m only going to use 450mb and I’m going to burn a ton of CPU to keep it there does sound like a bug. And yeah, latency but sometimes that’s okay. Agree the JVM is complicated, but you don’t have to be that complicated. A lot of it is legacy anyway.
Dylan16807 7y ago
You don't need a degree to set a max heap.
- dana321 7y ago
  I think their problem was the minimum heap size, thats why they have 10Gb sitting doing nothing, as the GC only doubles/halves its size in go. The way a gaming engine would do it would be to disable the GC and allocate a large chunk of memory and read/write directly to that memory. Its a pretty quick hack, not bad, really.
erik_seaberg 7y ago
You always have to tune GC if you're pushing the limits of the machine. If you can't do it by turning knobs, you have to do it by rewriting code.
- sagichmal 7y ago
  It's Go's position that the language (and/or runtime) should make this unnecessary for the vast majority of use cases, I'm not sure what they're targeting exactly but I'm sure it's 99% or more. The resulting lack of knobs is actually a feature, and one I'm very glad to have. I'm also happy to make my code less allocation-happy or more GC-friendly in the extremely rare circumstances when it matters. Like this article! But I think we probably just work in different environments.
  - erik_seaberg 7y ago
    I would much rather make the concise and clear implementation perform better, than take the readability hit and risk of mistakes from rewriting it (probably more than once).
    - sagichmal 7y ago
      This is sensical for application code, but I think a bad compromise for a language runtime.
  - apta 7y ago
    The golang position is to pretend complexity doesn't exist until it becomes a problem (this already happened before for example with the clock issue). This approach is already evident in the overly simplistic design of the language, which ends up pushing complexity into the code, and causing problems with it.
jayd16 7y ago
How can you read this post of a clear failure case that forced a code hack and think its better than a environment flag? I really find the Go community's disdain for features confounding.
apta 7y ago
Reality is complex by definition. Just because golang pretends it doesn't exist doesn't make it so. Secondly, the JVM GCs allow selecting the best GC for the job, whether it be throughput, very large heaps (mutli-GB to TB sized, which golang fails at), or low latency (ZGC and Shenandoah). Furthermore, the new low latency JVM GCs have very few knobs to set (2-3 last time I checked).

mnd999 7y ago

In this case, no. And what they’re doing doesn’t sound all that esoteric either. I’ve got 64gb to use but I’m only going to use 450mb and I’m going to burn a ton of CPU to keep it there does sound like a bug. And yeah, latency but sometimes that’s okay. Agree the JVM is complicated, but you don’t have to be that complicated. A lot of it is legacy anyway.

Dylan16807 7y ago

You don't need a degree to set a max heap.

dana321 7y ago
I think their problem was the minimum heap size, thats why they have 10Gb sitting doing nothing, as the GC only doubles/halves its size in go. The way a gaming engine would do it would be to disable the GC and allocate a large chunk of memory and read/write directly to that memory. Its a pretty quick hack, not bad, really.

erik_seaberg 7y ago

You always have to tune GC if you're pushing the limits of the machine. If you can't do it by turning knobs, you have to do it by rewriting code.

sagichmal 7y ago
It's Go's position that the language (and/or runtime) should make this unnecessary for the vast majority of use cases, I'm not sure what they're targeting exactly but I'm sure it's 99% or more. The resulting lack of knobs is actually a feature, and one I'm very glad to have. I'm also happy to make my code less allocation-happy or more GC-friendly in the extremely rare circumstances when it matters. Like this article! But I think we probably just work in different environments.
- erik_seaberg 7y ago
  I would much rather make the concise and clear implementation perform better, than take the readability hit and risk of mistakes from rewriting it (probably more than once).
  - sagichmal 7y ago
    This is sensical for application code, but I think a bad compromise for a language runtime.
- apta 7y ago
  The golang position is to pretend complexity doesn't exist until it becomes a problem (this already happened before for example with the clock issue). This approach is already evident in the overly simplistic design of the language, which ends up pushing complexity into the code, and causing problems with it.

jayd16 7y ago

How can you read this post of a clear failure case that forced a code hack and think its better than a environment flag? I really find the Go community's disdain for features confounding.

apta 7y ago

Reality is complex by definition. Just because golang pretends it doesn't exist doesn't make it so. Secondly, the JVM GCs allow selecting the best GC for the job, whether it be throughput, very large heaps (mutli-GB to TB sized, which golang fails at), or low latency (ZGC and Shenandoah). Furthermore, the new low latency JVM GCs have very few knobs to set (2-3 last time I checked).