Add GC metric last_incremental_sweep

[li1]

Records the time that the last incremental sweep ran.

This allows an application that explicitly runs GC when idle or at convenient points to be more intelligent about it.

Related: #50018

[kpamnany]

Cc: @gbaraldi, @vchuravy

The set of useful/necessary GC metrics keeps growing and making this struct larger and messier. Maybe we should consider a way to reorganize and retrieve these metrics?

[gbaraldi]

I think we shoud separate this struct into a couple things, it currently has a bunch of things that the user shouldn't really care about. #50144 adds a new struct that has the heuristics only. I think we should have 3 structs, a per thread gc_num that just counts allocations. A global one that tracks the timings and such, and the global heap tracking one I added in that PR.

With this we can remove a bunch of things, freed doesn't really mean much on the per thread thing for example

[oscardssmith]

Do we need the per thread one? If we track pages rather than bytes (with your PR), we don't need to ever look at how much each thread allocated. (since the decision on when to GC happens when we ask for a new page which can take a lock to check the global heap one)

[gbaraldi]

We need the per thread one to see how much a function call allocated for example for @time.

[oscardssmith]

How does that work if the function switches threads while running (or spawns work onto another thread?)

[gbaraldi]

I think it just gets it wrong? I haven't tested it

[oscardssmith]

if so, would it be much worse to delete the per thread one and assume that people using @time to track allocations aren't also running allocating code on another thread?

[gbaraldi]

The page based thing isn't precise for number of allocations, it just measures the heap it doesn't know anything about what is being done with it, so if you allocate 100GB but never go over 500mb of max heap that's what it will show.

[oscardssmith]

makes sense.

[kpamnany]

Happy to have this reorganized, but for now...

i686-w64-mingw32 failed with:

2023-06-20 04:10:26 EDT	Collecting and executing precompile statements
2023-06-20 04:10:26 EDT	└ Collect (Basic: ✓ 819, REPL 38/39: ◐ 1818) => Execute ◐ 1956LLVM ERROR: out of memory
2023-06-20 04:10:26 EDT	Allocation failed
2023-06-20 04:10:26 EDT	
2023-06-20 04:10:26 EDT	[6312] signal (22): SIGABRT
2023-06-20 04:10:26 EDT	in expression starting at none:0
2023-06-20 04:10:26 EDT	crt_sig_handler at C:/workdir/src\signals-win.c:100
2023-06-20 04:10:26 EDT	raise at C:\Windows\System32\msvcrt.dll (unknown line)
2023-06-20 04:10:26 EDT	abort at C:\Windows\System32\msvcrt.dll (unknown line)
2023-06-20 04:10:26 EDT	.text$_ZN4llvm22report_bad_alloc_errorEPKcb at C:\workdir\usr\bin\libLLVM-15jl.dll (unknown line)
2023-06-20 04:10:26 EDT	Allocations: 86146492 (Pool: 86098271; Big: 48221); GC: 249

Any idea what to do about this? Need a larger build machine?

[d-netto]

#50205