undefined | Better HN

0 pointsxxpor3y ago0 comments

An uncommon but not unheard method around that (in services that have diurnal patterns) is to throw memory at it and collect once a day during the down time. You can take the server out of service, restart it, and put it back in service.

0 comments

plandis3y ago

This is kind of hard to do in practice unless you’re really watching where you’re allocating memory. It’s very easy in Java to end up accidentally throwing a bunch of allocated memory on the heap without realizing it.

Fwiw, the JVM now has a noop garbage collector so this is easy enough to benchmark.

vbezhenar3y ago

Can you provide an examples of accidentally allocating memory? The only example I'm aware of is autoboxing which is huge misfeature IMO.

lenocinor3y ago

Concatenating lots of Strings instead of using a StringBuffer will do the trick. Sure, people who are familiar with Java know not to do that. But I’ve seen plenty of production code that concatenates.

kaba03y ago

Any method call could allocate objects in their call trees, and it may not even behave consistently with new versions.

But it is easy to monitor with Java’s killer observability.

ska3y ago

I read this was semi-standard memory management in the early lisp machine days, because that gc was so slow.

bitwize3y ago

Early Lisp (even pre-lispm) had no GC at all -- it just allocated until it ran out. Memory reclamation was done by saving the heap to tape and then reading it back -- only live objects were saved. So it was kind of GC with extra steps; the first GC algorithms removed the steps.

lispm3y ago

Nah, Lisp had GC in 1960 already. McCarthy invented the mark & sweep GC.

Lisp I Programmers Manual, 1960

https://www.softwarepreservation.org/projects/LISP/book/LISP...

Chapter 6.3, Page 95, The Free-Storage List and the Garbage Collector

User233y ago

To this day the Common Lisp standard doesn’t require GC.

j / k navigate · click thread line to collapse