Better testing for finalization

[headius]

While attempting to write a spec for jruby/jruby#7267 I ran into various issues and questions...

1. There are no specs testing that GC eventually finalizes objects. This is obviously difficult to predict, but it is behavior I believe we should be testing one way or another.
2. I was testing that exceptions in one finalizer are not seen by the next finalizer, but could not figure out a way to eliminate the warning output from Ruby indicating that a finalizer raised an exception.

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.

  it "hides raised exceptions from one finalizer to the next" do
    def scoped(result)
        Proc.new { result << "ok" if $!.nil?; raise }
    end
    def test(result)
      obj = "Test"
      # finalizer order may vary so both handlers check $! and raise an error
      ObjectSpace.define_finalizer(obj, scoped(result))
      ObjectSpace.define_finalizer(obj, scoped(result))
    end

    result = []
    begin
      old_verbose, $VERBOSE = $VERBOSE, false
      test(result)
    ensure
      $VERBOSE = old_verbose
    end

    100.times { GC.start; break if result.size == 2 }

    result.should == ["ok", "ok"]
  end

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.

[eregon]

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 .

See

spec/core/objectspace/define_finalizer_spec.rb

Lines 4 to 10 in 8059e59

	# Why do we not test that finalizers are run by the GC? The documentation
	# says that finalizers are never guaranteed to be run, so we can't
	# spec that they are. On some implementations of Ruby the finalizers may
	# run asynchronously, meaning that we can't predict when they'll run,
	# even if they were guaranteed to do so. Even on MRI finalizers can be
	# very unpredictable, due to conservative stack scanning and references
	# left in unused memory.

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

[eregon]

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.