3 ms·

> there would be clear benefits in also delegating basic dynamic memory management to the host. It would be quite hard to spec malloc/free into the Web platfor

by azakai 8y ago

> there would be clear benefits in also delegating basic dynamic memory management to the host. It would be quite hard to spec malloc/free into the Web platform, because of the necessary detail: the behavior of that malloc/free pair would need to be identical (same pointers returned from malloc) in all browsers, for every possible sequence of allocations and deallocations. GC is actually easier to spec since so much of the underlying details are unobservable. It's not impossible in theory, but it seems like it would mandate all browsers use the exact same allocator implementation (say, dlmalloc version x.y.z). In addition, this would not allow optimization over time, again, unlike GC. In the non-browser case, server-side implementations may not need to worry about specs, so more options may be open there.

pedrocr 8y ago
>the behavior of that malloc/free pair would need to be identical (same pointers returned from malloc) in all browsers, for every possible sequence of allocations and deallocations Why would you ever spec it like that? That doesn't seem needed at all. Plenty of programs run across platforms with wildly different mallocs and everything runs file. Replacing the malloc with LD_PRELOAD tricks is even done sometimes.
- azakai 8y ago
  For almost all platforms that's true, but the culture of standardization on the Web is unique. It comes from wanting a Web page to have the maximal chance of running across all standard-compliant browsers, forever - that's just not the case for practically every other platform.
  - pedrocr 8y ago
    If only that was true. Javascript has had all plenty of inconsistent behaviors across browsers and the feature matrix for what is and isn't supported in each browser is hugely complex. And even if that was true standardizing the results of malloc makes no sense, it gives you no extra compatibility guarantees for any sane programs and no one cares about insane ones.
  - int_19h 8y ago
    I've yet to see a standard-conforming C app that relied solely on the standard library - which, of course, includes malloc/free - to not run across all platforms (that have a filesystem and a console, or some equivalent input/output facilities, anyway).

by azakai 8y ago

pedrocr 8y ago

>the behavior of that malloc/free pair would need to be identical (same pointers returned from malloc) in all browsers, for every possible sequence of allocations and deallocations Why would you ever spec it like that? That doesn't seem needed at all. Plenty of programs run across platforms with wildly different mallocs and everything runs file. Replacing the malloc with LD_PRELOAD tricks is even done sometimes.

azakai 8y ago
For almost all platforms that's true, but the culture of standardization on the Web is unique. It comes from wanting a Web page to have the maximal chance of running across all standard-compliant browsers, forever - that's just not the case for practically every other platform.
- pedrocr 8y ago
  If only that was true. Javascript has had all plenty of inconsistent behaviors across browsers and the feature matrix for what is and isn't supported in each browser is hugely complex. And even if that was true standardizing the results of malloc makes no sense, it gives you no extra compatibility guarantees for any sane programs and no one cares about insane ones.
- int_19h 8y ago
  I've yet to see a standard-conforming C app that relied solely on the standard library - which, of course, includes malloc/free - to not run across all platforms (that have a filesystem and a console, or some equivalent input/output facilities, anyway).