Closed Bug 506174 Opened 15 years ago Closed 15 years ago

Use one single GC heap virtual mapping, avoiding frequent mmap and malloc calls

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 508707

People

(Reporter: gal, Assigned: gal)

References

Details

Attachments

(1 file, 1 obsolete file)

      No description provided.
Attached patch patch (obsolete) — Splinter Review
Patch crashes spectacularly:

==16607== Invalid read of size 4
==16607==    at 0xB1AE2: js_Enumerate (jsobj.cpp:4912)
==16607==    by 0x9CCB8: InitNativeIterator(JSContext*, JSObject*, JSObject*, unsigned int) (jsiter.cpp:150)
==16607==    by 0x9D546: js_ValueToIterator (jsiter.cpp:398)
==16607==    by 0x72B55: js_Interpret (jsinterp.cpp:3480)
==16607==    by 0x99E97: js_Execute (jsinterp.cpp:1644)
==16607==    by 0x1E06F: JS_ExecuteScript (jsapi.cpp:5055)
==16607==    by 0x7ED2: Process(JSContext*, JSObject*, char*, int) (shell/js.cpp:408)
==16607==    by 0x9705: ProcessArgs(JSContext*, JSObject*, char**, int) (shell/js.cpp:816)
==16607==    by 0xABA7: main (shell/js.cpp:4755)
==16607==  Address 0xaab0e34 is 4 bytes inside a block of size 28 free'd
==16607==    at 0x2837FB: free (vg_replace_malloc.c:324)
==16607==    by 0xDD7A: JS_free (jsapi.cpp:1881)
==16607==    by 0xB2178: js_TraceNativeEnumerators (jsobj.cpp:5064)
==16607==    by 0x697C9: js_TraceRuntime (jsgc.cpp:2776)
==16607==    by 0x6A272: js_GC (jsgc.cpp:3203)
==16607==    by 0x19CB2: JS_GC (jsapi.cpp:2482)
==16607==    by 0x3271: GC(JSContext*, unsigned int, long*) (shell/js.cpp:1080)
==16607==    by 0x861FF: js_Interpret (jsinterp.cpp:5191)
==16607==    by 0x99E97: js_Execute (jsinterp.cpp:1644)
==16607==    by 0x1E06F: JS_ExecuteScript (jsapi.cpp:5055)
==16607==    by 0x7ED2: Process(JSContext*, JSObject*, char*, int) (shell/js.cpp:408)
==16607==    by 0x9705: ProcessArgs(JSContext*, JSObject*, char**, int) (shell/js.cpp:816)

Investigating.
Assignee: general → gal
Looks like thats an unrelated problem im vanilla TM.
Congratulations to Apple for the probably shittiest memory subsystem/page fault handler in the history of time:

Sunspider score when allocating a 32MB GC heap, without warming it up:

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  904.5ms +/- 0.2%
--------------------------------------------

  3d:                   135.7ms +/- 0.5%
    cube:                38.7ms +/- 1.8%
    morph:               27.6ms +/- 0.5%
    raytrace:            69.4ms +/- 0.2%

  access:               136.6ms +/- 0.4%
    binary-trees:        37.6ms +/- 0.4%
    fannkuch:            55.8ms +/- 0.3%
    nbody:               24.6ms +/- 0.7%
    nsieve:              18.6ms +/- 0.9%

  bitops:                34.2ms +/- 0.7%
    3bit-bits-in-byte:    1.6ms +/- 8.6%
    bits-in-byte:         8.0ms +/- 0.0%
    bitwise-and:          2.4ms +/- 5.8%
    nsieve-bits:         22.2ms +/- 0.5%

  controlflow:           32.6ms +/- 0.4%
    recursive:           32.6ms +/- 0.4%

  crypto:                52.8ms +/- 0.8%
    aes:                 30.2ms +/- 1.3%
    md5:                 14.4ms +/- 1.0%
    sha1:                 8.2ms +/- 1.4%

  date:                 131.3ms +/- 0.2%
    format-tofte:        61.4ms +/- 0.2%
    format-xparb:        69.9ms +/- 0.2%

  math:                  29.5ms +/- 0.5%
    cordic:              10.3ms +/- 1.3%
    partial-sums:        13.0ms +/- 0.0%
    spectral-norm:        6.1ms +/- 1.5%

  regexp:                41.1ms +/- 0.3%
    dna:                 41.1ms +/- 0.3%

  string:               310.8ms +/- 0.3%
    base64:              17.0ms +/- 0.5%
    fasta:               61.0ms +/- 0.8%
    tagcloud:            98.2ms +/- 0.4%
    unpack-code:        104.9ms +/- 0.1%
    validate-input:      29.7ms +/- 0.5%

Now the same with the following 1-liner:

     if (!heap)
         return false;
     rt->gcBase = rt->gcPtr = heap;
     rt->gcEnd = heap + maxbytes;
+    memset((void*)rt->gcBase, 0, maxbytes);
 
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  870.2ms +/- 0.1%
--------------------------------------------

  3d:                   128.7ms +/- 0.1%
    cube:                34.9ms +/- 0.3%
    morph:               25.4ms +/- 0.6%
    raytrace:            68.3ms +/- 0.2%

  access:               127.4ms +/- 0.3%
    binary-trees:        35.4ms +/- 0.4%
    fannkuch:            56.0ms +/- 0.5%
    nbody:               21.2ms +/- 0.7%
    nsieve:              14.7ms +/- 0.9%

  bitops:                33.0ms +/- 0.7%
    3bit-bits-in-byte:    1.5ms +/- 9.8%
    bits-in-byte:         8.0ms +/- 0.5%
    bitwise-and:          2.3ms +/- 5.7%
    nsieve-bits:         21.2ms +/- 0.6%

  controlflow:           32.6ms +/- 0.4%
    recursive:           32.6ms +/- 0.4%

  crypto:                51.7ms +/- 0.7%
    aes:                 29.2ms +/- 1.2%
    md5:                 14.4ms +/- 1.0%
    sha1:                 8.1ms +/- 1.1%

  date:                 125.2ms +/- 0.2%
    format-tofte:        58.7ms +/- 0.3%
    format-xparb:        66.5ms +/- 0.2%

  math:                  29.6ms +/- 0.6%
    cordic:              10.5ms +/- 1.4%
    partial-sums:        13.0ms +/- 0.3%
    spectral-norm:        6.1ms +/- 1.1%

  regexp:                41.2ms +/- 0.3%
    dna:                 41.2ms +/- 0.3%

  string:               300.9ms +/- 0.3%
    base64:              16.2ms +/- 0.8%
    fasta:               58.0ms +/- 0.4%
    tagcloud:            96.0ms +/- 0.5%
    unpack-code:        102.2ms +/- 0.4%
    validate-input:      28.4ms +/- 0.5%

35ms speedup (almost 5%) for warming up the GC heap.
Blocks: 402614
Blocks: 505308
Summary: Use one single GC heap chunk, avoiding frequent mmap and malloc calls → Use one single GC heap virtual mapping, avoiding frequent mmap and malloc calls
Important to avoid physical commits. This means no more posix_memalign (no mmap, no VirtualAlloc) support.

/be
Attached patch patchSplinter Review
latest version from my queue
Attachment #390386 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
No longer blocks: 505308
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: