[HN Gopher] Ways I handled my OutOfMemoryErrors
       ___________________________________________________________________
        
       Ways I handled my OutOfMemoryErrors
        
       Author : 4pkjai
       Score  : 22 points
       Date   : 2021-09-27 13:04 UTC (1 days ago)
        
 (HTM) web link (bankstatementconverter.com)
 (TXT) w3m dump (bankstatementconverter.com)
        
       | ryanisnan wrote:
       | Regarding your change to `isEqualFromIndex()`, wouldn't the
       | results of the `lowercase()` calls be freed on successive
       | iterations? Does this only happen on the function termination?
        
       | Joker_vD wrote:
       | I don't like how the GC generally interact with externally-
       | imposed memory limits, and that example with isEqualFromIndex()
       | is a great example actually: sure, the loop allocates lot of
       | garbage but since it's garbage, nothing prevents GC from kicking
       | in when the memory usage is close to the allowed maximum and
       | reclaiming it, right? Except apparently in this case GC thinks
       | there is still plenty of memory, the OS thinks otherwise, and the
       | program gets killed.
       | 
       | It probably makes sense for unmanaged code to die just on OOM: it
       | (presumably) has "accurate" memory tracking so if it runs out of
       | memory, then it actually can't progress forward. But for managed
       | environments OOM just means that it's time to do a stop-the-
       | world, process-wide GC in every allocated heap.
       | 
       | I've seen several cases in Erlang where a long-living process
       | would do some heavy processing with binaries (they live in a
       | separate binary heap devoted specifically to storing binaries),
       | send the results and then go to sleep. It leads to the situation
       | where there would be a large amount of unneeded binaries
       | polluting the heap that can't be collected because they are still
       | referenced by some process; if that process did a GC, those
       | references would go away but it didn't because those references
       | are quite small and don't make the process's heap large enough to
       | trigger GC. And since in Erlang GC is done only per process, not
       | globally, there is not much one can do besides judicious
       | sprinkling of "erlang:garbage_collect()" and "hibernate" through
       | the codebase.
        
       | spullara wrote:
       | Out of memory errors are extremely dangerous in concurrent code.
       | It is one of the few ways that will leave things in an
       | inconsistent state as it releases the monitors and you likely
       | aren't catching them and fixing things up. I highly recommend all
       | Java production JVMs have one of these set:
       | 
       | -XX:+ExitOnOutOfMemoryError
       | 
       | -XX:+CrashOnOutOfMemoryError
        
       | papercrane wrote:
       | Unless I'm missing something that isEqualsFromIndex is
       | reimplementing String's regionMatches method.
       | 
       | E.g. text.regionMatches(true, index, substring, 0,
       | substring.length())
        
       ___________________________________________________________________
       (page generated 2021-09-28 23:02 UTC)