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)
Tracking
()
RESOLVED
DUPLICATE
of bug 508707
People
(Reporter: gal, Assigned: gal)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•15 years ago
|
||
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
Assignee | ||
Comment 2•15 years ago
|
||
Looks like thats an unrelated problem im vanilla TM.
Assignee | ||
Comment 3•15 years ago
|
||
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.
Updated•15 years ago
|
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
Comment 4•15 years ago
|
||
Important to avoid physical commits. This means no more posix_memalign (no mmap, no VirtualAlloc) support.
/be
Assignee | ||
Comment 5•15 years ago
|
||
latest version from my queue
Attachment #390386 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•