[GC] Add support for asking GC if a destructor is being run from a finalizer

[schveiguy]

This mirrors the PR on the symgc project:

symmetryinvestments/symgc#16

The inFinalizer support has become necessary due to some latent bugs in phobos that were recently fixed.

Names up for debate. I'm bad at names.

[deadalnix]

I don't really understand what problem does this solve. In general, I'd be suspicious of state addition. Why are we doing this?

[schveiguy]

The GC.inFinalizer call is used to tell when in a destructor, whether it is being called from a finalizer in the GC.

Why might you want to know this? Well, you are not allowed to allocate (in the current GC), so that is one reason. But the main reason I see is, a struct that is on the heap may use references that it thinks are thread-local, but it might be run from another thread. It also may be trying to access GC allocated data that has already been collected. There are some examples on the docs for inFinalizer.

See the note on dlang.org:

Important: The order in which the garbage collector calls destructors for unreferenced objects is not specified. This means that when the garbage collector calls a destructor for an object of a class that has members which are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects.

this actually was happening in Phobos, when running the new GC on windows, and I had to fix it. The fix is to only use the referenced data if not inside a finalizer. See the fix here: dlang/phobos#10788

So the fix needs to use inFinalizer, but this was not supported on the new GC, so I had to add it (see PR above).

[deadalnix]

How does this relates to inFinalizer?

[schveiguy]

The druntime hook needs a method to call on the SDC gc to get the correct information.

See how it's done in symgc (which doesn't have to go through an extern(C) interface): https://github.com/symmetryinvestments/symgc/blob/823e265f1823e10cc084efdc9ff690b1256b3cc0/source/symgc/gcobj.d#L370

[schveiguy]

Note, I did add this in a gap that would be unallocated due to alignment. So this shouldn't add any size to the ThreadCache.