2026-09-10 [09:04:41.0326] Meeting starting now, last chance for feedback before plenary 2026-09-24 [08:03:04.0149] Are we meeting today? [08:04:28.0942] I am technically off today but can join the meeting [08:06:00.0389] I got confused due to this message [08:44:18.0060] guybedford: I have some questions regarding the source phase imports PR if you don't mind :) If I understand it correctly, then the current version of the proposal basically does not allow us to garbage collect a source module ever. Because at any later point in time, somebody might import source the same source text from the same url and is guaranteed to not observer any module body code being executed, right? [08:45:40.0508] So the PR improves on that situation and basically ties the module to the specific source import execution. That is certainly better, but as nicolo-ribaudo pointed out, as soon as we post-message the source module to another thread, we always have to expect to get the same handle back. [08:47:13.0394] If that is correct, it basically makes the collection of source modules from impossible to too difficult to implement (distributed GC is a research topic for good reasons). And yes, due to the possibility of cycles in your message passing, you need proper tracing for it. [08:49:04.0389] Granted, I got it correct so far, I was wondering how to rectify the problem. And I had one complicated and one trivial idea. The complicated one is to disallow sending it back to the same worker that sent it out. The trivial idea was to only allow one clone. 2026-09-25 [18:32:50.0028] Olivier Flückiger: great questions, you've exactly understood the design here yes it does enable _better_ GC by having source-identities as they are a weak map of source identities to instances. We discussed this in the modules meeting today and determined that neither of those solutions you suggested here are ideal - the reason being that putting a limit on transfer count seems arbitrarily restrictive to virtualization systems. Instead we discussed having weak identity at the per-agent level instead. The idea being that we can make the per-agent module identity itself collectible within each agent individually when the module source is collected and the module identity has no remaining references. Then the weak map of module identity to module instance can be cleared as well. Avoiding the cross-thread GC problems, while maintaining the concept of shared identity. Under that design the gap would mostly be if you had a source module import() it and get an instance, then transfer it away while the registry was cleared (say if it came from an iframe), and then if transfer the source back in you would get the same identity, but the instance would have been cleared away already. This seems totally fine though, and in line with what one would expect of proper module GC I think. I've updated the identity PR to include this new invariant now. [01:00:55.0196] ah, I thought you wanted the mapping to be strong. if it can be weak then that does sound like a good solution to me. 2026-09-27 [14:00:43.0943] what's the status of the export defer? in particular I want to know if we should be prioritizing reviewing the tests [14:00:48.0570] * what's the status of export defer? in particular I want to know if we should be prioritizing reviewing the tests [14:01:39.0435] No, it's on the agenda for 2.7 only. The proposal changed quite a bit since when the tests were written, they first need work on our side [14:10:33.0702] Great thanks