tc39/proposal-asset-references

Allowing asset reference GC

bmeck opened this issue · 1 comments

bmeck commented

Per the README

Another issue is that a string doesn't have a life time associated with it. If the asset has some kind of temporary memory representation associated with it, there is no way to clean it up on garbage collection since the string could be recreated. This is a problem that the URL.createObjectURL() API suffers from.

We should ensure that we can actually destroy these references. I think ensuring the binding is mutable and/or deletable is enough, but if we do not allow it to be destroyed we will suffer the same problem.

// preload could start fetching this a ways before eval starts
asset dict from 'dictionary';
const dictionary = await (await fetch(dict)).json();

// ensure that we don't hold onto the response/binary blob
// we already have the json turned into an object
dict = null;

Since browsers do not let modules be removed from the Module Map, we have to let the bindings GC without necessarily relying on the Module being GC'd.

bmeck commented

Due to GC being desirable, and mutability of bindings being a way to achieve this. I think a statement about ensuring that multiple statements are not idempotent is probably necessary:

asset A from '_';
asset B from '_';
assert(A !== B);

If A and B are equal we could get into trouble if dynamic forms ever are able to produce values at runtime and do not return the same value as the original A or B. We could keep mappings to a specifier alive only as long as a reference for that specifier exists, but I don't see a large benefit to this if it requires extra lookups in a table and GC handling to be further added.