3 ms·

Another point there is that JS has always gone to great lengths not to expose the GC in any way. For example, you can’t enumerate a WeakSet, because that would

Another point there is that JS has always gone to great lengths not to expose the GC in any way. For example, you can’t enumerate a WeakSet, because that would cause behavior to be GC dependent. Calling dispose when an object is collected would very explicitly cause the GC to have semantic effects, and I think that goes strongly against the JS philosophy.

masklinn 1y ago
FinalizationRegistry was added, like, 5 years ago.
- rafram 1y ago
  Finalizers aren’t destructors. The finalizer doesn’t get access to the object being GC’d, for one. But even more crucially, the spec allows the engine to call your finalizer anywhere between long after the object has been GC’d, and never. They’re basically a nice convenience for noncritical resource cleanup. You can’t rely on them.
  - masklinn 1y ago
    Yes? Congratulation you know what a finalizer is? I was replying to this: > would very explicitly cause the GC to have semantic effects, and I think that goes strongly against the JS philosophy. Do you disagree that a finalizer provides for exactly that and thus can not be "strongly against the JS philosophy"?
    - mistercow 1y ago
      I mean it’s an explicit violation of that philosophy as noted in the proposal: > For this reason, the W3C TAG Design Principles recommend against creating APIs that expose garbage collection. It's best if WeakRef objects and FinalizationRegistry objects are used as a way to avoid excess memory usage, or as a backstop against certain bugs, rather than as a normal way to clean up external resources or observe what's allocated.
- pwdisswordfishz 1y ago
  Yes, it and WeakRef are exceptions, but they are the only ones, designed to be deniable – if you delete globalThis.WeakRef; and delete globalThis.FinalizationRegistry; you go back to not exposing GC at all. WeakRef even has a special exception in the spec in that the .constructor property is optional, specifically so that handing a weak reference to some code does not necessarily enable it to create more weak references, so you can be also limited as to which objects' GC you can observe. Though another problem is that the spec does not clearly specify when an object may be collected or allow the programmer to control GC in any way, which means relying on FinalizationRegistry may lead to leaks/failure to finalize unused resources (bad, but sometimes tolerable) or worse, use-after-free bugs (outright fatal) – see e.g. https://github.com/tc39/ecma262/issues/2650 https://github.com/tc39/ecma262/issues/2650
- mistercow 1y ago
  Fair, I wasn’t aware of that. But even so, there’s a big difference between a wonky feature intended for niche cases and documented almost entirely in terms of caveats, and “this is the new way to dispose of resources”. And the point that this kind of thing is against the JS philosophy is pretty explicit: https://w3ctag.github.io/design-principles/#js-gc https://w3ctag.github.io/design-principles/#js-gc

masklinn 1y ago

FinalizationRegistry was added, like, 5 years ago.

rafram 1y ago
Finalizers aren’t destructors. The finalizer doesn’t get access to the object being GC’d, for one. But even more crucially, the spec allows the engine to call your finalizer anywhere between long after the object has been GC’d, and never. They’re basically a nice convenience for noncritical resource cleanup. You can’t rely on them.
- masklinn 1y ago
  Yes? Congratulation you know what a finalizer is? I was replying to this: > would very explicitly cause the GC to have semantic effects, and I think that goes strongly against the JS philosophy. Do you disagree that a finalizer provides for exactly that and thus can not be "strongly against the JS philosophy"?
  - mistercow 1y ago
    I mean it’s an explicit violation of that philosophy as noted in the proposal: > For this reason, the W3C TAG Design Principles recommend against creating APIs that expose garbage collection. It's best if WeakRef objects and FinalizationRegistry objects are used as a way to avoid excess memory usage, or as a backstop against certain bugs, rather than as a normal way to clean up external resources or observe what's allocated.
pwdisswordfishz 1y ago
Yes, it and WeakRef are exceptions, but they are the only ones, designed to be deniable – if you delete globalThis.WeakRef; and delete globalThis.FinalizationRegistry; you go back to not exposing GC at all. WeakRef even has a special exception in the spec in that the .constructor property is optional, specifically so that handing a weak reference to some code does not necessarily enable it to create more weak references, so you can be also limited as to which objects' GC you can observe. Though another problem is that the spec does not clearly specify when an object may be collected or allow the programmer to control GC in any way, which means relying on FinalizationRegistry may lead to leaks/failure to finalize unused resources (bad, but sometimes tolerable) or worse, use-after-free bugs (outright fatal) – see e.g. https://github.com/tc39/ecma262/issues/2650 https://github.com/tc39/ecma262/issues/2650
mistercow 1y ago
Fair, I wasn’t aware of that. But even so, there’s a big difference between a wonky feature intended for niche cases and documented almost entirely in terms of caveats, and “this is the new way to dispose of resources”. And the point that this kind of thing is against the JS philosophy is pretty explicit: https://w3ctag.github.io/design-principles/#js-gc https://w3ctag.github.io/design-principles/#js-gc