How should initializers as functions interact with any stack trace/debugger API?

[littledan]

@bmeurer raised the question, if initializers are specified as methods, will this have runtime overhead? It would be nice if frontends could trivially inline initializers in the normal case. There are a few ways that this might be observable, though none of them are in the ECMAScript specification:

• In function.caller: This one doesn't actually come up, since the entire class body is in strict mode. As a result, referring to the caller will throw (or sometimes return null in V8), even if it's calling out to sloppy mode code outside of the class body. It would never reveal the initializer method.
• In the stack traces: I'm not sure whether or not initializers should show up separately in stack traces from the constructor (or wherever else super is called from). I'm guessing maybe they should, as they're not organized linearly, and having both pieces of information (where the constructor starts/super is called, and which line of code the initializer is on) are separately useful.
• In introspective stack trace APIs: I have not looked across multiple engines, but it seems like in V8, getting the actual function identity from a stack trace is only available for sloppy mode code, and not strict mode code. This seems to mean that we would never leak the function for the initializer, even through the stack trace API.

Ultimately, it's a non-normative choice whether we use a method for initializers or fashion the scope in a more direct way. Methods are used in the current spec text to minimize the diversity of representations of scopes, to keep things analogous to other code, and to reduce the amount of spec machinery. But earlier drafts fashioned the scopes more directly. I'd be fine to switch back if it would be helpful.

cc @bmeurer @jaro-sevcik @bterlson @syg @kmiller68 @xanlpz @ajklein

[annevk]

I suspect that would allow for creation of a high-resolution timer and would therefore need to be behind the cross-origin isolated flag (COOP+COEP) at least in some host environments.

[ckknight]

Given that one could fill an ArrayBuffer with random data and then manually copy that data (in an atomic way, even) to a SharedArrayBuffer, then it seems like the safest default is to forbid SharedArrayBuffer. In the future, I could imagine a SharedArrayBuffer.fillRandom that may have different semantics where atomicity is controlled.

[vapier]

Considering platforms might be able to mitigate the hrtimer attack (e.g. Chrome's site isolation), it seems wrong for the spec to ban. Leave it to the platform to decide whether it may be safely supported.

[annevk]

Chrome's site isolation is not sufficient mitigation and they also plan to migrate to a more restrictive environment: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes.

[vapier]

So you agree that the spec shouldn't be banning it, but leaving it to implementations to decide whether & when it is supported.

[annevk]

I'm saying that if it's allowed there needs to be a hook for host environments that can indicate whether it's supported so it can plug into the cross-origin isolated flag in HTML, for instance.

[vapier]

Sure, but that's an implementation consideration/problem, not something the spec needs to be mandating.

[annevk]

No it's not, it's a host problem and something the host needs to have a say over. I.e., it's a spec problem.

[vapier]

I have no idea what you mean by "host". The spec is not a host.

Whether implementations are able to support shared buffers safely as a backend (or whether the concerns at hand are even relevant) is something only implementations can possibly know. The spec should not be forbidding behavior simply because some implementations (which don't even support SharedArrayBuffer now for webcrypto APIs) don't take into consideration all the factors.

[annevk]

https://tc39.es/ecma262/#sec-overview second sentence.

[vapier]

The second sentence doesn't define "host" precisely. But the high level statement seems to agree with/match my points.

The only thing that knows whether shared array buffers may be used safely is the host environment, not the spec. Hence the spec should not be banning its usage.

Simply fix the spec to say that shared array buffers are permitted, but the host environment may block its usage, and then include a non-normative section giving examples of where that might come up.