Closed Bug 66381 Opened 23 years ago Closed 16 years ago
_Maybe GC should optimize garbage-collected/time-in-GC
15.67 KB, text/html
77.63 KB, patch
|Details | Diff | Splinter Review|
which involves not running too often (to amortize constant costs in GC'ing) and measuring garbage creation rate, filtering it to smooth the GC schedule, and matching garbage collection rate. /be
Will try for mozilla0.8. /be
Moving out, but I will get to this in 0.9 timeframe. /be
Shaver, you wanna take this one? /be
Target Milestone: mozilla0.9 → mozilla0.9.1
shaver wants this, I know it! /be
Assignee: brendan → shaver
Status: ASSIGNED → NEW
Incremental GC, which I think we agree is the right solution to this problem, isn't going to happen for mozilla0.9.1. I'll try to get it working during my period of unemployment, and post progress here. Expect an onslaught of dependent bugs covering interim changes to the GC flags and object locking mechanisms.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Asa just told me that we shipped 0.9.2! Who knew?
Target Milestone: mozilla0.9.2 → mozilla0.9.3
->0.9.5 since we have run out of time
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I don't really know when I will get this done, so I'm removing the lying milestone marker.
Target Milestone: mozilla0.9.5 → ---
cc:ing myself From links to it in other bugs (such as 104127) it sounds like some smart people think this could be important to fix for performance. Hopefully it'll at least make moz 1.0?
Any GC work going to happen for 0.9.9 or 1.0?
shaver's on a road trip, hacking incremental gc! /be
This is not a finished work, but it lets me run all my new GC test cases and the last version of this was happy enough in the browser. I'm going to spin a new build today with this latest stuff, and some other cleanups, and see how it holds up. People who have seen the GC show up in profiles unpleasantly might want to take their lives in their hands and try a profile or two with this patch. The real money (incremental GC) is still a little ways off, but I think the iterative marking might be a useful win anyway. Post here with results!
You probably don't want to use this in software that controls medical equipment, or even your television, but it _should_ actually work in the browser and other apps that don't need GC_MARK_DEBUG. Oh, and I haven't tested it with JS_THREADSAFE at all (might not even compile!). But I'll be damned if I'm not going to back this up everywhere I can, and bugzilla's handy.
Attachment #66003 - Attachment is obsolete: true
On WinNT, trying to test the patch above (id=67618). Here's what's happening: METHOD 1 1. Pull from the tip 2. Apply the patch 3. Compile 4. Run the testsuite 5. RESULT: approx 25 regressions due to the patch; not good. METHOD 2 1. For each file not in the patch, pull from the tip 2. For each file in the patch, pull the version mentioned there (for example, do cvs up -r3.42 jslock.c) 3. Apply the patch 4. Compile 5. RESULT: can't compile: cl -FoWINNT4.0_DBG.OBJ/ -c /MD /Od /Z7 -DXP_PC -DWIN32 -D_WINDOWS -D_WIN32 /nologo /W3 /FpWINNT4.0_DBG.OBJ/js.pch -DDEBUG -DDEBUG_ -DEXPORT_JS_API jsstr.c jsstr.c jsstr.c(2677) : error C2143: syntax error : missing ')' before '(' jsstr.c(2677) : error C2091: function returns function jsstr.c(2677) : error C2373: 'memcpy' : redefinition; different type modifiers C:\PROGRA~1\MICROS~2\VC98\INCLUDE\string.h(101) : see declaration of 'memcpy' jsstr.c(2677) : error C2059: syntax error : 'type' make: *** [WINNT4.0_DBG.OBJ/jsstr.obj] Error 2 make: *** [all] Error 2 I tried hard to verify that the actual differences I have in my js/src correspond exactly to the diffs in the patch, and they seem to. I don't know whether either Method 1 or Method 2 is viable. The problem is, either way I'm not sure my JS src matches Mike's. Mike: would it be possible to provide another patch against the current tip? If that wouldn't be too much trouble, then I could try again...
Well, that sucks. I'm not surprised it's not clean against the trunk, but I am surprised that I'm botching the tests now. I'll take a copy of the test suite to the cottage this weekend. I had some version of this (and I thought it was the attached version) running in the browser for a while, so there's something funky going on here. Sorry about that, all.
Here's the command line I use to run the tests: [//d/JS_TRUNK/mozilla/js/tests] perl jsDriver.pl -e smdebug smopt -k -L lc2 lc3
So, with that test setup, I get 7 failures without my patch, and 6 failures with. (Freaky ones: Math.random, String.prototype.replace, etc.) I'll attach another patch before I hit the cottage, updated to the tip.
I can pass the test suite now, kinda, and I'm spinning a Mozilla build that I can do more testing with as I type this. I get only 7 test failures for smdebug, and they're not all the same as phil's: ecma_3/Function/regress-104584.js ecma_3/RegExp/184.108.40.206-5-n.js ecma_3/RegExp/regress-123437.js ecma_3/String/regress-83293.js js1_5/Array/regress-101964.js js1_5/Exceptions/regress-123002.js js1_5/Object/regress-90596-003.js Of course, I passed the test suite earlier with a jsshell that would crash horribly the second it got into GC, so I'm waiting for my Mozilla build to complete before I get excited.
Attachment #67618 - Attachment is obsolete: true
Don't touch that last patch (#69316). It'll stop you cold, on startup, because of a left-over assertion in the tree I diffed to make the patch. With the patch I'm attaching now, the browser is happy, and so am I. Now I just(!) need to finish the write barrier, and we're in business for 0.9.9. Who can run Ts/Tp/Txul numbers on this for me? I think we should see some light speedup, but I'm mostly interested in validating my assertion that we don't get _hurt_ by this.
Attachment #69316 - Attachment is obsolete: true
I'm seeing a slight Ts win and a 1.5% Txul loss from that latest patch (even once I get rid of the last js_LockGCThing calls in the startup path), but jrgm is reporting huge memory consumption and other incredibly bad things when he tries to generate Tp numbers. More, uh, later today. Happy Valentine's Day!
OS type: Linux attica 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 i686 gcc version 2.95.3 20010315 (release) Mike's latest patch (69337) passes JS testsuite for me in optimized JS shell. The only failures are the current known bugs: Retest List, smopt # 1020 of 1020 test(s) were completed, 9 failures reported. ecma_3/ExecutionContexts/10.1.3-2.js <-- new test of duplicate function params ecma_3/RegExp/regress-85721.js <-- new RegExp performance test ecma_3/RegExp/regress-103087.js ecma_3/RegExp/regress-119909.js ecma_3/RegExp/regress-123437.js js1_5/Object/regress-90596-001.js js1_5/Object/regress-90596-002.js js1_5/Object/regress-90596-003.js js1_5/Array/regress-101964.js HOWEVER, in the debug JS shell, I am getting many crashes on testcases that seem to deal with numeric data. # Retest List, smdebug # 1020 of 1020 test(s) were completed, 31 failures reported. ecma/Expressions/11.10-1.js ecma/Expressions/11.10-2.js ecma/Expressions/11.10-3.js ecma/Expressions/11.4.8.js ecma/Expressions/11.7.1.js ecma/Expressions/11.7.2.js ecma/Expressions/11.7.3.js ecma/GlobalObject/220.127.116.11-3.js ecma/String/18.104.22.168-1.js ecma/String/22.214.171.124-1.js ecma/String/126.96.36.199-2.js ecma/String/188.8.131.52-2.js ecma_2/String/split-002.js ecma_2/String/split-003.js ecma_3/ExecutionContexts/10.1.3-2.js ecma_3/RegExp/regress-103087.js ecma_3/RegExp/regress-119909.js ecma_3/RegExp/regress-123437.js js1_2/String/slice.js js1_2/regexp/alphanumeric.js js1_2/regexp/digit.js js1_2/regexp/whitespace.js js1_2/regexp/word_boundary.js js1_4/Regress/function-002.js js1_5/Regress/regress-89443.js js1_5/Regress/regress-111557.js js1_5/Object/regress-90596-001.js js1_5/Object/regress-90596-002.js js1_5/Object/regress-90596-003.js js1_5/Array/regress-101964.js js1_5/Array/regress-107138.js
The risk/reward for 1.0 doesn't feel right, shamed though I am to still have not solved this. I'll attach patches as I background-hack on this, but 1.1 is the earliest I'm looking to put this on the trunk. I'll cut a branch for this, for easy testing by the brave and willing.
Target Milestone: --- → mozilla1.1
I'm off to resurrect the non-recursive marking part of this patch
Please, bug 76831 is not a meta-bug, is way too broad a bug, and is not obviously blocked by this bug. Even if this bug is fixed, a swapped-out mozilla process is likely to take a long time to page back in. /be
No longer blocks: 76831
Assignee: shaver → nobody
Status: ASSIGNED → NEW
Old bugs never die, they go to live in bugzilla. WONTFIXing this unless someone objects.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.