Theoretically maybe. Could you give more info on why?

I have a pod. And on the pod side I have objects on the heap. And on the bb side I can new those objects. And the bb gets a keyword to refer to the instance, and uses that keyword to refer to it in future calls. This is all cool, except the instance may get garbage collected over on the pod. So, I can keep a reference to it so it doesn't. But then I need a delete call on the bb side to clean that up. And the user needs to manage those instances or they will build up and use more and more ram. It would be great if the bb side could automatically send those delete calls when the referering keyword (or other object) on the bb side gets garbage collected. Essentially moving the life-cycle management from the pod to the bb garbage collector.

There are two ways I can think of achieving this. One is to have the referring object on the bb side call something in its finalize. This could be a finalize on a clojure.lang.Keyword, but that may be difficult/impossible even in clojure (https://clojure.atlassian.net/browse/CLJ-911). Or the object with finalize may not be a keyword, but a keyword-like re-implementation. A reified instance implementing all the protocols that a Keyword does (IFn, Comparable, Named, Serializable, IHashEq).

The other way might be to have a java.util.WeakHashMap, java.lang.ref.WeakReference and a java.lang.ref.ReferenceQueue to register the keywords into and trigger the appropriate delete calls on GC.

(bb has java.util.WeakHashMap exposed, but not java.lang.ref.WeakReference or java.lang.ref.ReferenceQueue)

I would appreciate your learned perspective on which approach to use in bb 🙂

Ok this morning I have been doing some experiments with weakreferences. Added java.lang.ref.WeakReference to bb. Some interesting discoveries. Triggering GC in clojure doesn't destruct keywords. But it does destruct java Objects. And in bb also keywords don't destruct. But sometimes objects do, and sometimes they do not. I wonder if something holds a reference to keywords inside clojure. And similarly in bb with Objects (but only sometimes?)

Here is my test-code

(ns test
  (:import [java.lang.ref WeakReference]))

(def weakref (atom nil))

(defn gc []
  (println "gc")
  (System/gc)
  (System/runFinalization)
  (println "gc done")
  )

(defn force-gc []
  (println "force-gc")
  (let [t (atom (Object.))
        wr (WeakReference. @t)]
    (reset! t nil)
    (while (.get wr)
      (System/gc)
      (System/runFinalization)))
  (println "force-gc done"))

(defn main []
  (let [a (Object.)]
    (println "inside")
    (reset! weakref (WeakReference. a))
    (println "a:" a)
    (println "wr:" (.get @weakref))
    (force-gc)
    (println "a:" a)
    (println "wr:" (.get @weakref)))
  (println "outside")
  (println "wr:" (.get @weakref))
  (force-gc)
  (println "wr:" (.get @weakref))
  )

(main)

I have a standard gc call (that may or may not actually trigger a gc) and a force-gc which blocks until it does

a is being set to an Object instance here

using clojure:

$ clj test/bb-gc.clj
inside
a: #object[java.lang.Object 0x5167268 java.lang.Object@5167268]
wr: #object[java.lang.Object 0x5167268 java.lang.Object@5167268]
force-gc
force-gc done
a: #object[java.lang.Object 0x5167268 java.lang.Object@5167268]
wr: #object[java.lang.Object 0x5167268 java.lang.Object@5167268]
outside
wr: #object[java.lang.Object 0x5167268 java.lang.Object@5167268]
force-gc
force-gc done
wr: nil

so the final force GC does destruct the Object (`wr: nil`)

in bb:

$ bb test/bb-gc.clj
inside
a: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]
wr: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]
force-gc
force-gc done
a: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]
wr: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]
outside
wr: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]
force-gc
force-gc done
wr: #object[java.lang.Object 0x2d3102ab java.lang.Object@2d3102ab]

it does not

but it's interesting... because the WeakReference used to check if GC had actually run, used inside force-gc does work in bb

so one Object gets destroyed by GC, but the other does not, as if something hidden is holding a reference to it

OK... bit more info... making the end of this test code:

(main)
(force-gc)
(println "wr:" (.get @weakref))

and the GC does clean up the object in bb. So it seems that internally it doesnt hold a ref in the use of the atom (inside force-gc), it doesn't hold a ref on exit from a function (`main`) but it does hold a ref on exit from a let body

I think a java.lang.ref.WeakReference might be enough to move pod object lifecycle control into bb mainline...

I will do some test code and see if I can get it working

ok.. some more info for the interested. Keywords do GC, but not if they are every used as a literal (obvious in retrospect). So (keyword "foo") behaves just like (Object.). But :foo never GCs

Ah right

You can add finalize to reify/src/babashka/impl/reify2.clj to experiment with this

and if that works for you, then make a PR

awesome, yes. I am in full experiment mode atm so is a good time to do it

so by the looks of it, bb reify can only reify a single interface?

first here: https://github.com/babashka/babashka/blob/master/reify/src/babashka/impl/reify2.clj#L56

interfaces is a set, too. So if you do a multi interface reify, which interface actually has its methods implemented is not obvious

yes, only a single interface is supported. supporting multiple would lead to a combinatorial explosion

user=> (def a (reify java.lang.Object (toString [_] "do") clojure.lang.Seqable (seq [_] '(1 2 3))))
#'user/a
user=> (seq a)
(1 2 3)
user=> (str a)
"babashka.impl.clojure.lang.Seqable@615b1baf"

yeah I can see that

Object / toString is a bit of an exception I would say, we could hardcode that

I reimplemented toString to get an optional toString method with the finalize

then came across the single interface issue

we could special case object probably

atm, you cant leave out toString

user=> (reify java.lang.Object)         
java.lang.ClassCastException: class clojure.lang.Symbol cannot be cast to class java.lang.Throwable (clojure.lang.Symbol is in unnamed module of loader 'app'; java.lang.Throwable is in module java.base of loader 'bootstrap') [at <repl>:7:1]

I special cased this in defrecord, you could take a peek there

I got finalize and toString working together optionally

I will PR so you can take a peek

not even sure about this finalize approach now... because take a look at this:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java#L568-L591

https://github.com/babashka/babashka/pull/1347/files

looks good to me

It might not be... Just putting some examples on the PR

the multiple finalize happens in clojure too.

I think there may be multiple instances created

but in clojure it doesnt happen while the var binding is still in place

and after finalization, can you still use the object?

Ill try

also worth testing in bb on JVM vs bb compiled to native

aaah Im actually testing on JVM...

that could be something...

ok

wonder if native image is different. it has a different GC

what are you testing on the JVM, both?

yeah I can still use the object

but then defing nil, and gcing, I get the final finalize

like there are temporary instances being created, and they get finalized in the first gc

let me compare to native-image

I think an artifact of how SCI implements reify perhaps?

could it be there are more objects created elsewhere?

yes looks like it

perhaps a bug in SCI even

totally different behavior on native-image

it may also be repl related... I will try a script

Nothing!

I think graalvm has deprecated finalize

WeakReference is the way...

dinnertime bbl

closed that finalize PR. But made this one with what I discovered along the way https://github.com/babashka/babashka/pull/1348

@U1QQJJK89 please don't use finalize, the thing you are looking for is a Cleaner

(ns test
  (:import [java.lang.ref Cleaner]))

(def global-cleaner (Cleaner/create))

(defn cleanup-code [internals]
  (println "cleaning up object" internals))

(deftype ThingCleanup
  [thing]
  Runnable
  (run [_]
    (cleanup-code thing)))

(defn do-thing 
  []
  (let [object {:name "bob"
                :whatever 123}]
    (.register global-cleaner
               object 
               ;; Can't hold a ref to the object itself
               (->ThingCleanup (into {} object)))
    123))

(defn main
  []
  (do-thing)
  (loop []
    (Thread/sleep 100)))

(future (main))

just noticing we're in babashka...

welp that won't work 👀

but that is the proper mechanism usually - cleaner runs a thread that consumes from a queue of weakrefs

Thanks @U3JH98J4R I will experiment. It could be made to work...