Open headius opened 2 years ago
We've tried in the past and it seems near-impossible to have a reliable test for this unfortunately. PR welcome of course if you find one way.
GC in a loop is also something I tried but it's 1) very slow 2) still doesn't finalize sometimes. Also on CRuby because of the conservative GC it's completely possible some object never gets finalized even though it is semantically unreachable.
My take is: no one should rely on finalizers on Ruby, they run unreliably (on all Ruby impls) and always late. Releasing resources should always be done promptly with an ensure
or block pattern .
TruffleRuby also tried using TruffleRuby-specific methods but even that spuriously fails: https://github.com/oracle/truffleruby/blob/4054469bbd985db7dc5c86299004ff86a2835baf/spec/truffle/objspace/define_finalizer_spec.rb#L17-L27
One possibility might be to rely on the fact CRuby runs finalizers on exit, and use that as a way of testing finalizers aspects other than "they happen when the object is GC'd". However, IIRC that's actually tricky to implement as there might be ordering rules between objects (based on what they reference) and which object should finalize first. I'm not sure how CRuby deals with that.
While attempting to write a spec for jruby/jruby#7267 I ran into various issues and questions...
The spec I attempted is below, but only makes a best attempt at forcing GC-oriented finalization and still does not suppress the error output.
I don't want to leave the fix for jruby/jruby#7267 untested, but I'm unsure how we should move forward to improve the GC-triggered finalization specs.