Gc: GC of code

[fgmccabe]

I believe that being able to GC code fragments is also important.

[xtuc]

What code fragments are you refering to? or do you mean the closures?

[fgmccabe]

I mean GC-ing code that can no longer be referenced and therefore executed.
I do not mean closures. I assume that the closure itself will go away.
But there are compelling use cases where code itself should go away;
particularly with long-running processes.

On Tue, Dec 18, 2018 at 8:15 AM Sven Sauleau [e-mail]
wrote:

What code fragments are you refering to? or do you mean the closures?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebAssembly/gc/issues/52#issuecomment-448276971, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAL0KGOvuFdGH5ucxvwU1O8VPJtgQNSks5u6RSpgaJpZM4ZXnBu
.

--
Francis McCabe
SWE

[lars-t-hansen]

If you mean unreachable instances or modules, I expect implementations currently GC them (at least in a browser embedding, where this makes sense). Certainly Firefox has set things up in this way; the module can be GC'd if it becomes unreachable before the instances that are made from it, and the instances are individually GC'able.

If you mean removing the code for individual wasm functions that can no longer be called, this is going to be hard, and is at cross purposes with other desirable properties. In general, a module and all its instances will share a single piece of compiled code (also across workers, in browser embeddings). Thus a function in that compiled code can only be GC'd if it can be known that it will never be called in any of the instances. After the start function has returned the roots for determining this will be all exported functions and all functions whose addresses are taken. Clearly some code will be found unreachable, but since the set of exported functions never shrinks it's not clear how much code can be collected in this manner.

In any case, for web embeddings the ability to have one compiled binary per module that is shared across all its instances is important, and may trump any desire to GC parts of that binary.

[aardappel]

Even if it could be determined that a function will never be called again, it is probably up to the implementation (engine), and thus not part of the WebAssembly / GC spec.

I agree with @lars-t-hansen that it is probably not worth it for an engine to even attempt this, especially since WebAssembly cannot currently generate new code at runtime (inside a module).

The tools (LLD etc.) should already have done a good job with static culling of dead functions where possible.

[fgmccabe]

At the risk of beating a dead horse, I am not referring to 'never executed
code'. I am referring to code that is used once for example to implement
initialization; or for long-running services that re

On Thu, Dec 20, 2018 at 11:45 AM Wouter van Oortmerssen <
[email protected]> wrote:

Even if it could be determined that a function will never be called again,
it is probably up to the implementation (engine), and thus not part of the
WebAssembly / GC spec.

I agree with @lars-t-hansen https://github.com/lars-t-hansen that it is
probably not worth it for an engine to even attempt this, especially since
WebAssembly cannot currently generate new code at runtime (inside a module).

The tools (LLD etc.) should already have done a good job with static
culling of dead functions where possible.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebAssembly/gc/issues/52#issuecomment-449114469, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAL0GT7EkOWuUgSIv4odbL9B-hWz9wrks5u6-i8gaJpZM4ZXnBu
.

--
Francis McCabe
SWE

[fgmccabe]

... that require online revision (without being stopped).

On Thu, Dec 20, 2018 at 12:55 PM Francis McCabe [e-mail] wrote:

At the risk of beating a dead horse, I am not referring to 'never executed
code'. I am referring to code that is used once for example to implement
initialization; or for long-running services that re

On Thu, Dec 20, 2018 at 11:45 AM Wouter van Oortmerssen <
[email protected]> wrote:

Even if it could be determined that a function will never be called
again, it is probably up to the implementation (engine), and thus not part
of the WebAssembly / GC spec.

I agree with @lars-t-hansen https://github.com/lars-t-hansen that it
is probably not worth it for an engine to even attempt this, especially
since WebAssembly cannot currently generate new code at runtime (inside a
module).

The tools (LLD etc.) should already have done a good job with static
culling of dead functions where possible.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebAssembly/gc/issues/52#issuecomment-449114469, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAL0GT7EkOWuUgSIv4odbL9B-hWz9wrks5u6-i8gaJpZM4ZXnBu
.

--
Francis McCabe
SWE

--
Francis McCabe
SWE

[lars-t-hansen]

@fgmccabe, I think in both the case of initialization and on-line revision you can get effective GC of the pieces you want by factoring code: put the code that is discardable into a separate module, which you load, compile, instantiate, and run separately from the "permanent" program. With plausible tool support this is little more than a dynamic library type situation so it should be possible for the GCable and permanent programs to agree on offsets in the common memory, say. These special modules, when no longer referenced, are then GCable, provided you don't hang onto neither module nor instance.

Of course it's possible that you want to hang onto a Module object without hanging onto its compiled code, but in that case you may as well just hang onto the wasm bytecode; it'll need to be recompiled anyway. So there doesn't seem to be a need to do anything special for this case.

[lars-t-hansen]

"Someday" wasm may have good support for jit-compiled code of some kind (likely under program control, for implementing jitted languages); at that point, this calculus changes and some kind of support for removing dynamically dead code will probably be desirable.

[titzer]

I think having smaller-than-module granularity of code is a practical inevitability, given that we've (predictably) already seen a use case already involves generating a new module per function, resulting in thousands of modules. However, I think this functionality can be added without any new Wasm constructs besides typed funcrefs, e.g. by an embedder API that accepts a memory range that contains bytecode for a new 'anonymous' function to be compiled into the currently module, returning it as a funcref, with the expectation that whenever the funcref is no longer reachable, its backing machine code and metadata is freed. Or another design is to offer explicit destruction of code references, but again I think this should be done through an embedder API.