Bugzilla

> Any argument could be a problem, not just later ones.

To be clear, the code generated for a Web IDL function with, say, 3 args, looks like this, in pseudo-code:

   doStuff(cx, argc, vp) {
     let arg1 = convertArg1();
     let arg2 = convertArg2();
     let arg3 = convertArg3();
     callC++Function(arg1, arg2, arg3);
   }

the convertArgN() calls can trigger GC in many cases, but are most definitely sequenced in a particular order (required by the IDL spec and easily observable in various ways in many cases).  The call to the C++ function, which has unsequenced things going on, shouldn't do GC stuff to argN at that point.

> you could just do the GC-ing argument computation into temporaries just before the call

Right, that is what we already do.  ;)

> For cases where you want to access strings chars and GC, there's AutoStableStringChars

Ah.  That might just address Henri's use cases in the simplest way.  It will still copy under the hood sometimes, but only if needed...

> but it seems like it would be possible to do all GCing operations before retrieving pointers to the chars?

Yes.

> probably using the concrete class AutoCheckCannotGC on the stack

And this will trigger the static analysis to make sure the C++ callee can't GC?  We can certainly do that.

> Or do you need a Span<> that is GC-aware, so that you can't let it escape or the analysis will scream at you? 

I don't think we do: callees of binding methods shouldn't expect their args to outlive returning to the bindings unless they explicitly copy.  I may end up creating a struct that bundles up a Span and AutoCheckCannotGC anyway, just to make the binding code and codegen simpler, but we don't need that as part of JSAPI if all the pieces are.  That's assuming we don't just use AutoStableStringChars.

> Any argument could be a problem, not just later ones.

To be clear, the code generated for a Web IDL function with, say, 3 args, looks like this, in pseudo-code:

```
   doStuff(cx, argc, vp) {
     let arg1 = convertArg1();
     let arg2 = convertArg2();
     let arg3 = convertArg3();
     callC++Function(arg1, arg2, arg3);
   }
```

the convertArgN() calls can trigger GC in many cases, but are most definitely sequenced in a particular order (required by the IDL spec and easily observable in various ways in many cases).  The call to the C++ function, which has unsequenced things going on, shouldn't do GC stuff to argN at that point.

> you could just do the GC-ing argument computation into temporaries just before the call

Right, that is what we already do.  ;)

> For cases where you want to access strings chars and GC, there's AutoStableStringChars

Ah.  That might just address Henri's use cases in the simplest way.  It will still copy under the hood sometimes, but only if needed...

> but it seems like it would be possible to do all GCing operations before retrieving pointers to the chars?

Yes.

> probably using the concrete class AutoCheckCannotGC on the stack

And this will trigger the static analysis to make sure the C++ callee can't GC?  We can certainly do that.

> Or do you need a Span<> that is GC-aware, so that you can't let it escape or the analysis will scream at you? 

I don't think we do: callees of binding methods shouldn't expect their args to outlive returning to the bindings unless they explicitly copy.  I may end up creating a struct that bundles up a Span and AutoCheckCannotGC anyway, just to make the binding code and codegen simpler, but we don't need that as part of JSAPI if all the pieces are.  That's assuming we don't just use AutoStableStringChars.