[amelius]

Interesting! Yes, that would help a lot, but I'm not sure how growing heaps will be modeled then (are they allocated block by block?) And how is a growing heap communicated in practice between threads? Is every read-operation to be guarded by a check if the corresponding block is available in the current thread?

[azakai]

Growing heaps are in progress,

http://discourse.specifiction.org/t/request-for-comments-swi...

(It's unclear how that would work with heaps shared between threads, but so are most issues regarding threads - still just fairly early experimentation there, last I heard.)

[TazeTSchnitzel]

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.

[sunfish]

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

[amelius]

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?

[sunfish]

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.

[amelius]

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?