I remember ASP.NET used a weird collection class to store javascript snippets that were to be included in the page being generated. The class internally used an array and then switched to a hashtable once the number of items in the collection went beyond some pre-tuned limit. As a result, if you tried to register too many javascript blocks to be included on the page, you found that they got included out of order, because the internal storage was now a hashtable with a non-deterministic order for keys.

I spent an entire night debugging this issue.

  Although it is necessary in Java, it is entirely pointless to
  specify the length of an array ahead of time in JavaScript. [...]
  Rather, you can just set up an empty array and allow it to grow as
  you fill it in. Not only is the code shorter, but it runs faster too.

As it happens, I had occasion to test this a few months ago.

  function preallocate(len) {
      var arr = new Array(len);
      for (var n = 0; n < len; n += 1) {
          arr[n] = n;
      };
      return arr;
  }

  function noPreallocate(len) {
      var arr = [];
      for (var n = 0; n < len; n += 1) {
          arr[n] = n;
      };
      return arr;
  }

Arguably, they still do.

    function f() {
      var some = [];
      while(some.length < 1e6) {
        some.push(some.length);
      }
      function g() { some; }
      return function() {};
    }

    var a = [];
    var interval = setInterval(function() {
       var len = a.push(f());
       if(len >= 500) {
         clearInterval(interval);
       }
     }, 10);

     function f() {
       var some = [];
        while(some.length < 1e6) {
          some.push(some.length);
        }
         function g() { some; }
     }

     var a = [];
     var interval = setInterval(function() {
       var len = a.push(f());
       if(len >= 500) {
          clearInterval(interval);
       }
     }, 10);

https://stackoverflow.com/questions/19798803/how-javascript-...

https://blog.meteor.com/an-interesting-kind-of-javascript-me...

I had to work around the DOM limitations of V8 heap snapshots by building a JavaScript 'mirror' of DOM state that I could examine in the snapshots [1]. Perhaps I'll be able to strip out that logic and rely on the improved snapshots!

[0] http://plasma-umass.org/BLeak/

[1] Discussed in Section 5.3.2 of the preprint of our PLDI 2018 paper: https://github.com/plasma-umass/BLeak/raw/master/paper.pdf

> This code is in JS because it has to run in the browser, so it is not super fast.

Try profiling heap allocations in Chrome Debugger. In my experience especially array-allocation can slow down JS-code a lot.

In my side project, which is a high performance web app, I was able to get an extra ~20fps by virtually removing all garbage created each frame. And there's a lot of ways to accidentally create garbage.

Prime example is the Iterator protocol, which creates a new object with two keys for every step of the iteration. Changing one for loop from for...of back to old-style made GC pauses happen about half as much. But you can't iterate over a Map or Set without the Iterator protocol, so now all my data structures are hand-built, or simply Arrays.

I would like to see new language features be designed with a GC cost model that isn't "GC is free!" But I doubt that JavaScript is designed for me and my sensibilities....

The cachable code is kept in a big function source->bytecode hash table.

The cacheable bytecode is then “linked” to a bytecode that is optimized for execution speed. That bytecode has things like create_array, etc that can take the immutable backing store object we generated earlier.

This means that if you have multiple functions with identical source code you only have to do the expensive parse+compile step once, and you end up with multiple independent functions using the same constant/immutable backing stores. This saves memory and helps performance.

Unfortunately it adds complexity - now the mutable is objects have “immutable” backing stores, so you have to implement copy-on-write semantics in order to not share state between different instances of the linked code. In this case it appears that a required CoW check was missing :(

You say a larger heap has marginal impact on performance and that locality and working set size are what matter. If larger pointers make the heap bigger, then the working set is going to grow as well, and locality will be worse because the larger pointers mean less objects fit into a cache line.

They don't even need that. Any garbage collection strategy (including refcounting) have no trouble reclaiming cycle (the only GC type which may have problems are refcounting GCs, and they usually have a cycle detector for exactly that purpose).

The only way for this issue to arise is to involve two runtimes, each with its own garbage collector, able to create references between one another.

A cycle crossing the boundary will not be detectable by either GC, and will lead to a leak.

This is exactly what happens in Internet Explorer up to (and including) version 7: JavaScript lives in the jscript engine and the DOM lives in COM, each has its own GC, and they can have references to objects living in the other runtime.

And then they continue to make use of the Javascript's GC in order to do effective memory management... at gmail scale...