TC39 General
2025-01-23
plaintext logs
prev next
source on github
01:54
<Sacha Greif>
I'm not sure if this is of interest to this group, but our next survey will focus on AI tools for web developement. Currently in the preview/feedback phase if you want to make some suggestions: https://github.com/Devographics/surveys/issues/278
04:43
<Meghan Denny>
make sure to have "do not use" options
05:55
<ljharb>
also "use but never want on by default"
21:46
<ljharb>

does anyone know of an available-by-default way to trigger a GC - any GC whatsoever as long as I can first make a weakref to it - so i can test .deref behavior?

if i make my tests spin for like 10-20 seconds, then i can make it happen, but obviously i'd rather not do that

21:56
<Ashley Claymore>
I've seen test262 harnesses create lots of array buffers to try and trigger memory pressure 
22:03
<shu>
ah but there's no guarantee that a GC will clear a weakref
22:03
<shu>
there is no ironclad way really
22:04
<shu>
also you want to trigger a GC async
22:04
<shu>
because on-stack roots with a JS stack can retain things in ways that are completely nonobvious at the JS source level
22:07
<Ashley Claymore>
`window.reload()`should work 
22:08
<Chris de Almeida>
ljharb: in what env?
22:09
<ljharb>
ideally in node and the 3 browsers, at least :-)
22:09
<ljharb>
async is totally fine, just ideally it doesn't sleep my tests so much
22:09
<shu>
this is also what i see in exploit chains that depend on a GC
22:09
<ljharb>

the way i do it now is:

			var holder = { x: {} };
			var ref = new WeakRef(holder.x);
			delete holder.x;
			holder = null;
			setTimeout(function () {
				// assertion on ref.deref()
			}, 20e3);
22:09
<Chris de Almeida>
no finalizationregistry?
22:10
<Chris de Almeida>
node has: https://nodejs.org/docs/v22.13.1/api/cli.html#--expose-gc
22:10
<Ashley Claymore>
this is also what i see in exploit chains that depend on a GC
I promise it wasn't me 
22:10
<ljharb>
a finalization registry would be more efficient and reliable than a settimeout, true, but my tests would still have to pause until it was collected. node's expose-gc won't work because i don't want to have to use flags, and that won't work in browsers anyways
22:10
<shu>
i don't hate on exploit writers, they're better than me
22:11
<Ashley Claymore>
rising tide
22:11
<shu>
ljharb: a portable way basically doesn't exist
22:11
<shu>
like, by design, it doesn't exist
22:11
<Chris de Almeida>
looks like you've gotta fork every browser, friend
22:11
<ljharb>
right
22:11
<ljharb>
it's fine if i have to do a different way for each engine :-p i just hoped there'd be some way to make it pretty likely it happens
22:12
<Chris de Almeida>
what sorcery are you doing this for anyway?
22:12
<shu>
i think allocating a lot of big-ish ArrayBuffers (but not so big that a single allocation will throw a RangeError) is a good high-likelihood way
22:13
<Ashley Claymore>
https://chromedevtools.github.io/devtools-protocol/tot/HeapProfiler/#method-collectGarbage if the test runner has access 
22:13
<shu>
any sustained allocation, really
22:14
<shu>
    for (let i = 0; i < 10000; i++) {
      let s = new String("AAAA" + Math.random());
    }
22:14
<shu>
i've seen that in some fuzz tests
22:17
<shu>
your sleep test i think is depending on "idle gc", which engines try to schedule a GC task when nothing else seems to be happening
22:19
<ljharb>
that was indeed the intent, i hadn't thought about memory pressure