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) (deleted) — 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 patch (deleted) — Splinter 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: