Fork me on GitHub

Good Morning!

Jakob Durstberger07:08:16

Happy Friday 🙂

🎉 3

Morn' 😃

Ben Hammond10:08:43

does anyone know of a jdk setting that can make finalization more aggressve; I'm stuck with an IBM library that relies upon finalize , its haemorrhaging memory because it seems the finalizer cannot keep up


Sounds painful… There’s nothing I know of; as far as I recall you can’t rely on when finalizers are called… I’m guessing they’re determined by the GC algorithm/strategy though; so perhaps switching the garbage collector would help? clutches straws


My memory is pretty hazy though; I usually end up having to immerse myself in jvm docs whenever I need to tweak this stuff.


I think you're right.


Any chance you have leftover references? Very easy in clojure with anonymous functions

Ben Hammond11:08:52

this is actually in ahem Kotlin

Ben Hammond11:08:43

I've got tothe point of just tweaking bits to see what kind of effect it has on memory usage

Ben Hammond11:08:59

none of this is on-heap; the heap looks fine

Ben Hammond11:08:26

and non-heap standard stuff looks fine; its all under-the-radar native allocatino that's got a problem


I've seen interesting stuff off heap before. I think I saw it at a terabyte once with datomic.

Ben Hammond11:08:16

what was the underlying cause?


Big datomic database. It was for a mobile phone provider, but not the one we did together, the one before that.


We were putting click data into datomic.