Earlier quoted context omitted.
Java is pretty greedy with the memory it claims. Especially historically it was pretty hard to get the JVM to release memory back to the OS. To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak.
This only really ends up being a problem on windows. On systems with proper virtual memory setups, the cost of unused memory is very low (since the the OS can just page it out)
Meta’s renewed commitment to jemalloc
191–200 of 259 posts
Re: Meta’s renewed commitment to jemalloc
#192Earlier quoted context omitted.
This only really ends up being a problem on windows. On systems with proper virtual memory setups, the cost of unused memory is very low (since the the OS can just page it out)
Unfortunately, the JVM and collectors like the JVM's plays really bad with virtual memory. (Actually, G1 might play better. Everything else does not). The issue is that through the standard course of a JVM application running, every allocated page will ultimately be touched. The JVM fills up new gen, runs a minor collection, moves old objects to old gen, and continues until old gen gets filled. When old gen is filled…
Re: Meta’s renewed commitment to jemalloc
#193Earlier quoted context omitted.
Like "never work at Meta unless you can out-toxic your coworkers".
Yea I knew meta was toxic, but publicly beefing over something over a decade ago is a whole other matter. I can’t even remember what I was working on 10 years ago, and even if I did I wouldn’t be bringing people down that much later.
On a more serious note, it seems like any hyper competitive company eventually spirals into an awful, toxic working env.
Re: Meta’s renewed commitment to jemalloc
#194when i preloaded jemalloc , memory remained at significantly lower levels, and - more importantly - it was stable.
there seems to be no single correct solution to memory allocation, depending on the workload
Re: Meta’s renewed commitment to jemalloc
#195Re: Meta’s renewed commitment to jemalloc
#196Re: Meta’s renewed commitment to jemalloc
#197Earlier quoted context omitted.
doesn't java also? I heard that was a common complaint for minecraft
Minecraft for somewhat silly reasons was largely stuck using Java8 for ~a decade longer than it should have which meant that it was using some fairly outdated GC algorithms.
decade seems a usual timescale for that, considering f.e. python 2->3
Re: Meta’s renewed commitment to jemalloc
#198Earlier quoted context omitted.
Java is pretty greedy with the memory it claims. Especially historically it was pretty hard to get the JVM to release memory back to the OS. To an outsider, that looks like the JVM heap just steadily growing, which is easy to mistake for a memory leak.
Java has a quite strict max heap setting, it's very uncommon to let it allocate up to 25% of the system memory (the default). It won't grow past that point, though. Baring bugs/native leaks - Java has a very predictable memory allocation.
we are talking about DEallocation
Re: Meta’s renewed commitment to jemalloc
#199Earlier quoted context omitted.
For the peanut gallery more: I worked with both of these guys at Meta on this. The "servers are only on for a few hours" thing was like never true so I have no idea where that claim is coming from. The web performance test took more than a few hours to run alone and we had way more aggressive soaks for other workloads. My recollection was that "write zeroes" just became a cheaper operation between '12 and '14. A fun…
[flagged]
For what it's worth, 20 years ago all programming newsgroups were like this. I grew my thick skin on alt.lang.perl lol
Re: Meta’s renewed commitment to jemalloc
#200This doesn't quite read properly to me. What does it actually mean, does anyone know?