Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This still doesn't fix the biggest issue with running non-javascript code in the browser: browsers still offer no way to know when a value is collected.

e.g. if I allocate a callback function, and hand it to setTimeout, I have no way to know when to collect it.

Sure, you can encode rules about some of the common functions; but as soon as you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow all the different code paths.

Every time a proposal comes up to fix this:

  - GC callbacks
  - Weak valued maps
  - Proxy with collection trap
The proposal gets squashed.

Unless this is attended to Javascript remains the required language on the web.



Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn.

Note turn-based notification. No way will exact GC schedule be leaked via callbacks from the GC. Ditto anything like Java's post-mortem finalization.

But your "e.g." is unclear, though. Why do you need to manually deallocate a callback function passed to setTimeout?


> Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn.

Got a link to the memo? I haven't heard about this one.

> Why do you need to manually deallocate a callback function passed to setTimeout?

One of my use cases is running lua in the browser. see lua.vm.js: https://kripken.github.io/lua.vm.js/repl.html

When you pass a lua function to a javascript function, I create a 'proxy' object that holds a reference to the function in the lua VM. Only if javascript tells me it's "done" with it can I drop the ref inside the lua VM.


FWIW, this is exactly the same problem we had with making it possible for Embind to allow passing C++ functions into setTimeout.

We'd need to synthesize a JavaScript function that holds a wrapper object for the C++ function, and that wrapper object would need to be deallocated when the timer is done. For general callbacks, this is a hard problem, and finalizers would provide a clean way to solve it.


See, e.g.,

https://esdiscuss.org/topic/weak-event-listener#content-2

It's hard to find something fresh. I will stir the pot at the July TC39 meeting and get the committee on the record for weak refs with turn-delayed notification, or bust!


> See, e.g.,

> https://esdiscuss.org/topic/weak-event-listener#content-2

> It's hard to find something fresh. I will stir the pot at the July TC39 meeting and get the committee on the record for weak refs with turn-delayed notification, or bust!

As recently as September last year you told me it may happen... but with an indeterminate timeframe: https://mail.mozilla.org/pipermail/es-discuss/2014-September...


Yeah, it needs an active champion. I'll poke likely champs.


Weak refs are actually going in??? I got the impression they were dead because TC39 disliked them so much.


You and I had this exact conversation at Eataly a few months back. WeakMaps are cool, but JS is a garbage-collected language. All you have to do to GC something is stop referencing it.

WeakMaps are only really useful when you don't control the referenced object's lifecycle. Even then, you can simply invert your map or check in your callback.


> JS is a garbage-collected language. All you have to do to GC something is stop referencing it.

That works well for JS... but if you are trying to use asm.js (or now wasm), you need to act on things getting garbage collected inside of your code.


You're talking about implementing your own GC inside JS. A valid use case, but a niche one. JS the language doesn't really need to expose GC internals. JS the compile target does. (Though it can be worked around).


> You're talking about implementing your own GC inside JS. A valid use case, but a niche one.

Any asm.js code that calls into DOM apis is going to need this. Otherwise they don't know when to free stuff.

Most of the current asm.js code out there just binds a single canvas element, and works with that. But if you want to actually call anything else....




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: