This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-21
Channels
- # announcements (1)
- # babashka (39)
- # beginners (91)
- # cider (9)
- # clj-kondo (10)
- # cljsrn (1)
- # clojure (54)
- # clojure-europe (45)
- # clojure-italy (2)
- # clojure-nl (1)
- # clojure-spec (39)
- # clojure-uk (21)
- # clojurescript (7)
- # core-typed (1)
- # cursive (9)
- # data-science (1)
- # datomic (2)
- # docker (3)
- # emacs (11)
- # figwheel-main (11)
- # fulcro (19)
- # java (1)
- # juxt (1)
- # kaocha (68)
- # malli (7)
- # meander (5)
- # off-topic (76)
- # pedestal (1)
- # re-frame (6)
- # reveal (1)
- # rum (2)
- # shadow-cljs (48)
- # sql (6)
- # tools-deps (47)
- # vim (8)
- # xtdb (23)
morning
¡måning!
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.
Any chance you have leftover references? Very easy in clojure with anonymous functions
this is actually in ahem Kotlin
I've got tothe point of just tweaking bits to see what kind of effect it has on memory usage
none of this is on-heap; the heap looks fine
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.
what was the underlying cause?