Hacker News new | ask | show | jobs
by TazeTSchnitzel 4244 days ago
I don't know either. I'm aware that asm.js currently doesn't allow expanding the heap (it's always a fixed-size allocation), but that might change.

If you mean allocating from that heap, I imagine it'd work as it currently does: the program implements its own allocator.
2 comments
sunfish 4243 days ago
asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1].

[0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

link
amelius 4243 days ago
What I'm wondering is what a pointer-dereference would look like. Is every pointer dereference in asm.js implemented by TWO dereferences (one to find the heap, and then one to find the index within the heap)? And are there mutexes (or other synchronization directives) used per dereference in a typical implementation?
link
sunfish 4243 days ago
It's still being designed, but we're unlikely to do anything that would require a double dereference or synchronization on each access -- that would be a lot og overhead. We'll likely seek a way to keep accesses fast by doing more work at heap resizing time, since heap resizing ought to be infrequent.
link
amelius 4243 days ago
I guess the allocator would be able to manage blocks so you could view them as a single heap. At least, that's how I'd like to deal with memory as a "user". However, a "pointer" then has two parts: first, it should point to the block, and second it should have the index within that block. A stored pointer (a pointer stored within the heap) then would need 2 lookups for a dereference (first, determine the block-number, look up the block from a small array, and then lookup the index within that block). This sounds a little convoluted to me. Shouldn't there be a simpler and more efficient way to deal with growing memory?
link