merge revision(s) 0130e17a410d60a10e7041ce98748b8de6946971,32b7dcfb56a417c1d1c354102351fc1825d653bf,79cc566ab4cdf75f125ecf413a27d353a9756c08: [Backport #18394]

	Always enabled read barrier even on GC.compact

	Some objects can survive the GC before compaction, but get collected in
	the second compaction.  This means we could have objects reference
	T_MOVED during "free" in the second, compacting GC.  If that is the
	case, we need to invalidate those "moved" addresses.  Invalidation is
	done via read barrier, so we need to make sure the read barrier is
	active even during `GC.compact`.

	This also means we don't actually need to do one GC before compaction,
	we can just do the compaction and GC in one step.
	---
	 gc.c | 20 +++-----------------
	 1 file changed, 3 insertions(+), 17 deletions(-)

	Fix more assumptions about the read barrier

	This is a continuation of 0130e17a410d60a10e7041ce98748b8de6946971.  We
	need to always use the read barrier
	---
	 gc.c | 10 ----------
	 1 file changed, 10 deletions(-)

	Make during_compacting flag in GC one bit

	Commit c32218de1ba094223420a4ea017707f48d0009c5 turned during_compacting
	flag to 2 bits to support the case when there is no write barrier. But
	commit 32b7dcfb56a417c1d1c354102351fc1825d653bf changed compaction to
	always enable the write barrier. This commit cleans up some of the
	leftover code.
	---
	 gc.c | 4 ++--
	 1 file changed, 2 insertions(+), 2 deletions(-)

0 files changed, 0 insertions, 0 deletions