Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing asset reference GC #6

Open
bmeck opened this issue Nov 16, 2018 · 1 comment
Open

Allowing asset reference GC #6

bmeck opened this issue Nov 16, 2018 · 1 comment

Comments

@bmeck
Copy link
Member

bmeck commented Nov 16, 2018

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 bmeck changed the title Allowing asset GC Allowing asset reference GC Nov 16, 2018
@bmeck
Copy link
Member Author

bmeck commented Nov 29, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant