GC mark-loop rewrite

[d-netto]

Previous work

Since #21590, the GC mark-loop was implemented by keeping two manually managed stacks: one of which contained iterator states used to keep track of the object currently being marked. As an example, to mark arrays, we would pop the corresponding iterator state from the stack, iterate over the array until we found an unmarked reference, and if so, we would update the iterator state (to reflect the index we left off), "repush" it into the stack and proceed with marking the reference we just found.

This PR

This PR eliminates the need of keeping the iterator states by modifying the object graph traversal code. We keep a single stack of jl_value_t * currently being processed. To mark an object, we first pop it from the stack, push all unmarked references into the stack and proceed with marking.

I believe this doesn't break any invariant from the generational GC. Indeed, the age bits are set after marking (if the object survived one GC cycle it's moved to the old generation), so this new traversal scheme wouldn't change the fact of whether an object had references to old objects or not. Furthermore, we must not update GC metadata for objects in the remset, and we ensure this by calling gc_mark_outrefs in gc_queue_remset with meta_updated set to 1.

Additional advantages

1. There are no recursive function calls in the GC mark-loop code (one of the reasons why Implement GC mark loop #21590 was implemented).
2. Keeping a single GC queue will greatly simplify work-stealing in the multi-threaded GC we are working on (c.f. [rfc] parallel marking #45639).
3. Arrays of references, for example, are now marked on a regular stride fashion, which could help with hardware prefetching.
4. We can easily modify the traversal mode (to breadth first, for example) by only changing the jl_gc_markqueue_t(from LIFO to FIFO, for example) methods without touching the mark-loop itself, which could enable further exploration on the GC in the future.

Since this PR changes the mark-loop graph traversal code, there are some changes in the heap-snapshot, though I'm not familiar with that PR.

Some benchmark results are here: https://hackmd.io/@Idnmfpb3SxK98-OsBtRD5A/H1V6QSzvs.

[vchuravy]

@nanosoldier runtests(ALL, vs = ":master")

[vchuravy]

@nanosoldier runbenchmarks(!"scalar", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[vchuravy]

@nanosoldier runtests(["AbstractLogic", "AutomotiveVisualization", "Bonsai", "Contour", "FastTabular", "HydrophoneCalibrations", "IntervalTrees", "JET", "LuxLib", "MITgcmTools", "MixedAnova", "MixedModels", "OceanStateEstimation", "OutlierDetectionData", "PalmerPenguins", "Parsers", "Permanents", "ProtoBuf", "SlackThreads", "SoapySDR", "WaterWaves1D"], vs = ":master")

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[KristofferC]

The IOError thing is a Pkg bug (which might hide some other real bug).

Edit: Actually, a rebase should probably update to a Pkg where it is fixed.

[vtjnash]

Some minor comments from looking this over with you, but it seems to look good to me as a whole. Really solid work, Diogo.

[vtjnash]

Should we multiply by * (elem_end - elem_begin) for the number of pointers in each element?

[vtjnash]

2 MB seems rather large (though 8k does seem a little small)

[d-netto]

I think the chunk-queue shouldn't be large (the number of chunks grows with the depth of graphs of objarrays).

[vtjnash]

This is over 2 MB per thread though, which seems large

[d-netto]

@vtjnash any idea of what could be causing the error in analyzegc?

[vtjnash]

Try annotating the jl_raise_debugger function declaration with JL_NOTSAFEPOINT:

JL_DLLEXPORT void jl_raise_debugger(void) JL_NOTSAFEPOINT;

It is a heuristic evaluation tool, so any changes to the code can sometime arbitrarily change what branches it considers and what errors it thinks it might have found. You can run it locally with make -C src install-analysis-deps clang-sagc-gc

[vchuravy]

@nanosoldier runtests(ALL)

[d-netto]

@nanosoldier runtests(ALL)

[maleadt]

Hm, not sure why this didn't went through. Let's try again:

@nanosoldier runtests(ALL)

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[d-netto]

I'm seeing some regressions after the rebase, so not good to merge yet.

[d-netto]

NVM, I was running with obj pools disabled.

[vchuravy]

@nanosoldier runtests()

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[d-netto]

Bump

[giordano]

This is already defined in

julia/src/support/MurmurHash3.c

Line 15 in d775750

#define FORCE_INLINE inline __attribute__((always_inline))

and now causes a warning during compilation:

In file included from /home/mose/repo/julia/src/support/hashing.c:51:
/home/mose/repo/julia/src/support/MurmurHash3.c:15: warning: "FORCE_INLINE" redefined
   15 | #define FORCE_INLINE inline __attribute__((always_inline))
      | 
In file included from /home/mose/repo/julia/src/support/hashing.c:7:
/home/mose/repo/julia/src/support/dtypes.h:120: note: this is the location of the previous definition
  120 | #define FORCE_INLINE static inline __attribute__((always_inline))
      |