rb_gc_register_address and rb_global_variable should read the latest VALUE of the pointer

[eregon]

truffleruby/src/main/c/cext/gc.c

Lines 15 to 20 in 01607d7

	void rb_gc_register_address(VALUE *address) {
	/* TODO: This should guard the address of the pointer, not the
	object pointed to, but we haven't yet found a good way to implement
	that, or a real world use case where it is required. */
	polyglot_invoke(RUBY_CEXT, "rb_gc_register_address", address, rb_tr_unwrap(*address));
	}

truffleruby/src/main/c/cext/gc.c

Lines 61 to 66 in 01607d7

	void rb_global_variable(VALUE *obj) {
	/* TODO: This should guard the address of the pointer, not the
	object pointed to, but we haven't yet found a good way to implement
	that, or a real world use case where it is required. */
	RUBY_CEXT_INVOKE_NO_WRAP("rb_global_variable", *obj);
	}

Originally posted by @eregon in #2720 (comment)

[eregon]

I'm unsure how we can solve this from a quick look, because the variable could be reassigned (and we have no way to know that currently I think) and the new handle holding it wouldn't be kept alive. It might not need a handle though and then it'd stay alive anyway as a managed global variable, but some globals need to go native, and might be even become more frequently the case when executing some functions natively instead of on Sulong.

Maybe we need some help from Sulong to get notified of writes to the variable or so. Or never allow such variables to go native maybe but that sounds restrictive.

[eregon]

One idea is most (all?) usages of rb_gc_register_address()/rb_global_variable() are done during the call to the Init_<mycext> function. So we could just collect all these addresses during that call and then read them all (note, there might already be GCs during the Init_ call so we need to handle that too, but such handles are already preserved automatically in preservedObjects).
If it's not called during Init_<mycext> we could warn/error/read the value at the time.

That at least would cover the common case of these functions being called in Init_ automatically and with no overhead.

An heavy alternative would be to reread all these variables when returning from C back to Ruby, but that would likely be a significant overhead.