[VM-corelib] Improve performance for very big maps and sets.

[VM-corelib] Improve performance for very big maps and sets.

This is rather experimental.  It's an attempt to fix some
bad interactions between the write barrier/remembered set
and very large hash maps (1 million entries). Large maps and
sets are broken up into chunks which don't have to move when
the map grows and which are not dirtied with writes if we are
mainluy adding to the map.

Currently, performance on small maps suffers too much for this
to be viable, so this is not currently intended for committing.

R=sra@google.com
BUG=

[erikcorry, 2017-08-17 01:28:57]

This doesn't actually improve performance for big maps and sets...

[sra1, 2017-08-17 18:33:17]

https://codereview.chromium.org/3001763002/diff/1/runtime/lib/compact_hash.dart
File runtime/lib/compact_hash.dart (right):

https://codereview.chromium.org/3001763002/diff/1/runtime/lib/compact_hash.da...
runtime/lib/compact_hash.dart:80: // entries.
It might be better not to have the hybrid scheme where the main list holds both
pairs and sub-arrays.
With a pure 1-level or 2-level scheme, it should be possible to choose the
1-level or 2-level code with a simple comparison on the mask.
Also, on the transition between 1-level and 2-level, _data can become the first
page without copying (but it still needs to be rehashed)

https://codereview.chromium.org/3001763002/diff/1/runtime/lib/compact_hash.da...
runtime/lib/compact_hash.dart:561: current = null;
If the current sublist from _data is held in a field '_sublist', the logic to
scan would be the same as the old version except at this point we check to move
to the next sublist. Most of this switch to the next sublist could be in a
separate method call. Hopefully the inner loop _sublist scan gets inlined even
if the switch-over does not.

[erikcorry, 2017-09-04 11:21:16]

I have done a writeup of this experiment at
https://docs.google.com/document/d/1jKiwY9JlRi8xLfl67_CjOGim0C7-PTl4jW8po_BZ_...

Results were very good (more than double speed) for an artificial hashmap
benchmark with very large maps.  However for very small maps this was a
regression.  Dart2js on small programs showed a 2% speed regression and there
was no noticeable improvement on dart2js runs on a huge program.

I'm probably not going to spend more time on this unless new benchmark result
turn up to indicate it might be a win.  I don't think sra's alternative
suggestion would be any faster, but if someone wants to try it they are welcome
to build on this change to do the experiment.  Microbenchmarks are in the doc
linked above.