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)
23.43 KB,
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
•