Bugzilla

cf comment 10, in principle we can partially revert / further refine the change that always creates a stack map when debugging is enabled.  We need a map when the JS return value field may become a pointer that needs to be traced.  This is true for multi-value but as Wingo notes, also when we return an i64 because that can turn into a BigInt.  And of course it's true for any ref return type.  In the current universe, where multi-value and reftypes are rare (and i64-typed functions are fairly rare too), such a change would drastically reduce the number of stack maps and the time used to compute them and the memory occupied by them.

However, in the universe of the future, with ubiquitous use of reftypes or memory64, the problem will come back.

Since the more subtle attribute is also a bit brittle (it depends on how JS chooses to represent wasm values) it seems to me that it is not a great idea to do further work here; we should focus instead on (a) [not turning on debug code just because the console is open](https://bugzilla.mozilla.org/show_bug.cgi?id=1654590#c4) and (b) properly documenting why we're currently doing what we're doing (bug 1715514) and (c) reducing the memory consumption of stack maps and the time it takes to compute and allocate them (bug 1715456).

cf comment 10, in principle we can partially revert / further refine the change that always creates a stack map when debugging is enabled.  We need a map when the JS return value field may become a pointer that needs to be traced.  This is true for multi-value but as Wingo notes, also when we return an i64 because that can turn into a BigInt.  And of course it's true for any ref return type.  In the current universe, where multi-value and reftypes are rare (and i64-typed functions are fairly rare too), such a change would drastically reduce the number of stack maps and the time used to compute them and the memory occupied by them.

However, in the universe of the future, with ubiquitous use of reftypes or memory64, the problem will come back.

Since the more subtle attribute is also a bit brittle (it depends on how JS chooses to represent wasm values) it seems to me that it is not a great idea to do further work here; we should focus instead on (a) [not turning on debug code just because the console is open](https://bugzilla.mozilla.org/show_bug.cgi?id=1654590#c4) and (b) properly documenting why we're currently doing what we're doing (bug 1715514) and (c) reducing the memory consumption of stack maps and the time it takes to compute and allocate them (bug 1715456).

(Edit: I'm doubting myself.  Why would we need a stack map for every breakpoint (== safepoint) if it is only at or near the return point that the pointer fields in the DebugFrame might become populated?)

cf comment 10, in principle we can partially revert / further refine the change that always creates a stack map when debugging is enabled.  We need a map when the JS return value field may become a pointer that needs to be traced.  This is true for multi-value but as Wingo notes, also when we return an i64 because that can turn into a BigInt.  And of course it's true for any ref return type.  In the current universe, where multi-value and reftypes are rare (and i64-typed functions are fairly rare too), such a change would drastically reduce the number of stack maps and the time used to compute them and the memory occupied by them.

However, in the universe of the future, with ubiquitous use of reftypes or memory64, the problem will come back.

Since the more subtle attribute is also a bit brittle (it depends on how JS chooses to represent wasm values) it seems to me that it is not a great idea to do further work here; we should focus instead on (a) [not turning on debug code just because the console is open](https://bugzilla.mozilla.org/show_bug.cgi?id=1654590#c4) and (b) properly documenting why we're currently doing what we're doing (bug 1715514) and (c) reducing the memory consumption of stack maps and the time it takes to compute and allocate them (bug 1715456).

(Edit: I'm doubting myself.  Why would we need a stack map for every breakpoint (== safepoint) if it is only at or near the return point that the pointer fields in the DebugFrame might become populated?  It is true that a "pointer field" is introduced in the DebugFrame in bug 1628426.  But this field is known to be null (really uninitialized, though there's a flag that says so) throughout almost the entire function.  Generating a stack map everywhere is correct but unnecessary; the field can be ignored because it is known to be null, and null need never be updated by the GC.)