Non recursive gc trace

[HalidOdat]

This Pull Request fixes/closes #1848 .

It changes the following:

• Unify GcBoxHeader and EphemeronBoxHeader into GcHeader (duplicate code).
• Use a work queue to traverse the gc ojects.

The reproducible code in the issue has been made into a test for both boa_gc and boa_engine (reduced the chain object from 100_000_000 to 1_000_000, takes too long to finish).

Note: Marking it as a draft. There are still some things that need to be sorted out. like the vtable extraction and construction without rust-lang/rust#81513 will be much harder to do.

Reason for moving vtable to Gc object: Because we have <T: Trace + ?Sized> Trace for Gc<T> we cannot get a NonNull<GcBox<dyn Trace>> from Gc<dyn Trace> so we can enque it (we can implement a special case for Gc<dyn Trace> but types like Gc<VTableObject<dyn Trace>> cannot be done), because it would require us to have double DST, which is not possible. Moving the vtable to the GcBox<T> allow us to construct a GcBox<dyn Trait> at any time. This also has the advantage of reducing by half the NonNull<GcBox<dyn Trace>> pointers in the gc strong vec, also while gc collecting and tracing queue. Could also have some interesting other optimization, since we could have a ThinGc<dyn Trace> that is pointer width while being erased.

Solved by create a custom VTable with all the required function, and other metadata like size. Being able to put pretty much anything in the vtable, this approach may be more flexible than working with rust-lang/rust#81513.
The tests run fine with strict provenance under miri.

Once the warnings, documentation, some code clean up is done, will mark it ready for review.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	95,960	95,960	0
Passed	76,534	76,534	0
Ignored	18,477	18,477	0
Failed	949	949	0
Panics	0	0	0
Conformance	79.76%	79.76%	0.00%

[codecov]

Codecov Report

Attention: 66 lines in your changes are missing coverage. Please review.

Comparison is base (47351ef) 49.01% compared to head (0b56b10) 48.88%.
Report is 2 commits behind head on main.

Files	Patch %	Lines
core/macros/src/lib.rs	0.00%	26 Missing ⚠️
core/gc/src/trace.rs	75.00%	10 Missing ⚠️
core/gc/src/internals/gc_header.rs	82.35%	6 Missing ⚠️
core/gc/src/lib.rs	87.80%	5 Missing ⚠️
core/engine/src/error.rs	0.00%	4 Missing ⚠️
core/engine/src/builtins/promise/mod.rs	0.00%	3 Missing ⚠️
core/engine/src/module/source.rs	0.00%	2 Missing ⚠️
core/engine/src/builtins/function/mod.rs	0.00%	1 Missing ⚠️
core/engine/src/builtins/generator/mod.rs	0.00%	1 Missing ⚠️
core/engine/src/builtins/intl/collator/mod.rs	0.00%	1 Missing ⚠️
... and 7 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3508      +/-   ##
==========================================
- Coverage   49.01%   48.88%   -0.13%     
==========================================
  Files         469      471       +2     
  Lines       48186    48492     +306     
==========================================
+ Hits        23618    23705      +87     
- Misses      24568    24787     +219     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[HalidOdat]

Ran the benchmarks and the seems to be a slight speed improvement (not sure why, expected the opposite since we need to reach into the object to be able to trace it).

Also just realized that with the queue it would be easier to implement an incremental GC since we can stop at anytime during the tracing and continue afterwards

---

Main

PROGRESS Richards
RESULT Richards 49.2
PROGRESS DeltaBlue
RESULT DeltaBlue 53.4
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 54.3
PROGRESS RayTrace
RESULT RayTrace 162
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 148
PROGRESS Splay
RESULT Splay 155
PROGRESS NavierStokes
RESULT NavierStokes 103
SCORE 91.8

PR

PROGRESS Richards
RESULT Richards 49.9
PROGRESS DeltaBlue
RESULT DeltaBlue 53.9
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 53.5
PROGRESS RayTrace
RESULT RayTrace 162
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 153
PROGRESS Splay
RESULT Splay 156
PROGRESS NavierStokes
RESULT NavierStokes 103
SCORE 92.3
undefined

[jedel1043]

Really nice fix! And yeah, this could simplify a LOT the implementation of a concurrent GC.
Just have some critical comments about some methods of Trace, and the rest are just nitpicks.

[jedel1043]

Good work!

[raskad]

Nice work!