[wasm] Increase WebAssembly.Memory maximum size to ~2GB

test/mjsunit/mjsunit.status

 # Copyright 2012 the V8 project authors. All rights reserved.
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are
 # met:
 #
 #     * Redistributions of source code must retain the above copyright
 #       notice, this list of conditions and the following disclaimer.
 #     * Redistributions in binary form must reproduce the above
 #       copyright notice, this list of conditions and the following
 #       disclaimer in the documentation and/or other materials provided
@@ skipping 321 matching lines @@
   'packed-elements': [SKIP],
   'regexp-global': [SKIP],
   'math-floor-of-div': [PASS, SLOW],
   'math-floor-of-div-nosudiv': [PASS, SLOW],
   'unicodelctest': [PASS, SLOW],
   'unicodelctest-no-optimization': [PASS, SLOW],
   # Issue 3219:
   'getters-on-elements': [PASS, ['gc_stress == True', FAIL]],
 }],  # 'arch == arm64 and mode == debug and simulator_run == True'
 
+['arch == arm and simulator_run == True or arch == ppc and simulator_run == True', {

[Eric Holk, 2017/06/13 16:19:47]

Should these be wrapped to 80 chararacters?

[gdeepti, 2017/06/13 21:25:43]

I don't know if there's a way to wrap around in status files, this is consistent
with the way long conditionals are handled in the rest of the file. 

[Eric Holk, 2017/06/13 22:37:20]

sgtm

+  # Because of how allocations in the simulator work, simulator run assumes
+  # everything to be in the lower 4-gb address space, which fails this test
+  # on 32 bit arch simulators

[Eric Holk, 2017/06/13 16:19:47]

I'm not sure I understand this. Just to make sure, we're talking about running
the simulator on a 64-bit host, right? Otherwise everything is in the lower 4gb
address space. I'm surprised the simulator can assume the memory is in the lower
4GB space. Can't the OS put the allocation anywhere?

[gdeepti, 2017/06/13 21:25:43]

My comment is not indicative of what is actually happening (fixed comment) -
some more context for what is happening here: The right phrasing is that the
allocator assumes address space to be in the signed int32 range, because of this
when using a large offset the computation exceeds a signed 32-bit type, the
addresses wrap around and hit DCHECKS which work as expected on hardware. As per
my understanding ARM, PPC simulators are run on 32 bit hosts for the respective
target architecture, and ARM64 etc. on 64 bit hosts. 

See test that fails here - causing this computation to exceed a signed 32-bit
type

[Eric Holk, 2017/06/13 22:37:20]

sgtm

+  'wasm/large-offset': [SKIP],
+}],  # 'arch == arm and simulator_run == True or arch == ppc and simulator_run == True'
+
 ##############################################################################
 ['asan == True', {
   # Skip tests not suitable for ASAN.
   'big-array-literal': [SKIP],
   'big-object-literal': [SKIP],
   'regress/regress-crbug-178790': [SKIP],
 
   # https://bugs.chromium.org/p/v8/issues/detail?id=4639
   # The failed allocation causes an asan/msan/tsan error
   'es6/typedarray-construct-offset-not-smi': [SKIP],
@@ skipping 296 matching lines @@
   'lithium/*': [SKIP],
   'third_party/*': [SKIP],
   'tools/*': [SKIP],
   'apply': [SKIP],
   'math-*': [SKIP],
   'unicode-test': [SKIP],
   'whitespaces': [SKIP],
 }],  # variant == wasm_traps
 
 ]