-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Provide a mechanism in VM that allows embedders to free native resources on isolate shutdown (to avoid relying on GC) #51387
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
Comments
/cc @brianquinlan @aam |
Another suggestion that @rmacnak-google had was to move |
As part of fixing #42312 we have settled on a design where we have auto-deleting finalizable handles and non-auto-deleting weak persistent handles. For the ladder: Once GC collects a weak persistent handle it will invoke the associated callback with peer pointer. That callback is allowed to call The way one could work around this is to make the persistent handles store a back-pointer to the isolate. So the handle deletion functions would find the right isolate to delete the handle from at expense of an extra word for each handle. It would make our isolates a bit more heavyweight (e.g. We could consider having both: handles that are per-isolate group and ones that are per-isolate. wdyt? |
There seems to be some reservations about having per-isolate-group handles. Is this use case that you describe above of sharing deeply immutable objects in C++ using per-isolate-group-handles something that is used pervasively in some customer code? The same sharing could probably also be achieved by creaing per-isolate handles I would presume. |
Could you elaborate a bit more on those reservations?
This is one use case I'm aware - there may be more I don't know about. Wouldn't call it "pervasive".
The point is to share those unmodifiable bytes across isolates. The cache continues to exist and continues to have handles to bytes - even if an isolate dies and a newly created one performs lookups in the cache. So I don't think per-isolate handles would be sufficient here. One could work around this by managing the memory manually by If we had separate "isolate group handle"s one could restrict them to point only to deeply immutable objects (just as we only allow sharing deeply immutable objects in inter-isolate message passing). |
flutter/flutter#120535 is blocked on this, we don't seem to have an owner for this issue. |
Native resources (e.g. files) should ideally be managed by the developer and freed once not needed anymore. We do support letting those resources be freed automatically using weak persistent handles / finalizable handles. Doing so will make the GC eventually free up the native resources.
In context of isolates it may be desirable that unused native resources get eagerly freed on isolate shutdown - instead of waiting for the next GC to happen.
As such we could provide a mechanism in the VM that allows embedders (which e.g. implement
dart:io
) to free resources eagerly on isolate shutdown.See for motivating use case: flutter/flutter#120535
The text was updated successfully, but these errors were encountered: