Ergebnis für URL: http://bugzilla.mozilla.org/show_bug.cgi?id=378918 #[1]Top [2]Bugzilla@Mozilla
[3]Bugzilla
Quick Search
____________________
* [4]Browse
* [5]Advanced Search
(BUTTON)
* [6]Reports
*
* [7]Quick Search Help
* [8]Documentation
* [9]New Account
* [10]Log In
(BUTTON) Login with GitHub
____________________ ____________________ password____________ [X] Remember
Log in
* [11]Forgot Password
____________________ Reset Password
(BUTTON)
* [12]Mozilla Home
*
* [13]Privacy
* [14]Cookies
* [15]Legal
Please enable JavaScript in your browser to use all the features on this site.
(BUTTON) Copy Summary
(BUTTON) ▾
* Markdown
* Markdown (bug number)
* Plain Text
* HTML
____________________
(BUTTON) View ▾
* Reset Sections
* Expand All Sections
* Collapse All Sections
*
* History
*
* [16]JSON
* [17]XML
Closed [18]Bug 378918 Opened 17 years ago Closed 16 years ago
Corrupted ThreadPrivate gcFreeLists with multiple JSRuntimes
* [19]Summary:
Corrupted ThreadPrivate gcFreeLists with multiple JSRuntimes
Categories
(Core :: JavaScript Engine, defect)
[20]Product:
Core ▾
Core
Shared components used by Firefox and other Mozilla software, including handling
of Web content; Gecko, HTML, CSS, layout, DOM, scripts, images, networking, etc.
Issues with web page layout probably go here, while Firefox user interface issues
belong in the [21]Firefox product. ([22]More info)
[23]See Open Bugs in This Product
[24]File New Bug in This Product
(BUTTON) Watch This Product
[25]Component:
JavaScript Engine ▾
Core :: JavaScript Engine
The interpreter engine for the core JavaScript language, independent of the
browser's object model. File ONLY core JavaScript language bugs in this category.
For bugs involving browser objects such as "window" and "document", use the "DOM"
component. For bugs involving calls between JavaScript and C++, use the
"XPConnect" component.
[26]See Open Bugs in This Component
[27]Recently Fixed Bugs in This Component
[28]File New Bug in This Component
(BUTTON) Watch This Component
[29]Version:
Trunk
[30]Platform:
All
All
[31]Type:
defect
[32]Priority:
Not set
[33]Severity:
major
Points:
---
Tracking
()
[34]Status:
RESOLVED FIXED
[35]Status:
RESOLVED
FIXED
(BUTTON) Mark as Assigned
[36]Milestone:
---
Iteration:
---
[37]Project Flags:
a11y-review [---]
Performance Impact [---]
Webcompat Priority [---]
Accessibility Severity [---]
[38]Tracking Flags:
Tracking Status
relnote-firefox [---]
thunderbird_esr115 [---] [---]
firefox-esr115 [---] [---]
firefox125 [---] [---]
firefox126 [---] [---]
firefox127 [---] [---]
People
(Reporter: MikeM, Assigned: igor)
[39]Assignee:
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=40] [40]igor
[41]Assignee:
[ ] Reset Assignee to default
[42]Mentors:
---
[43]QA Contact:
[ ] Reset QA Contact to default
[44]Reporter:
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=40] [45]MikeM
[46]Triage Owner:
[4fe52ee1503aecf7b6c976b8eb7c1753?d=mm&size=40] [47]willyelm
[48]CC:
11 people
References
[49]Depends on:
---
[50]Blocks:
[51]365048, [52]426529, [53]js1.8src
Dependency [54]tree / [55]graph
[56]Regressions:
---
[57]Regressed by:
---
[58]URL:
[59]See Also:
---
Details
[60]Alias:
---
[61]Keywords:
---
[62]Whiteboard:
---
QA Whiteboard:
---
Has STR:
---
Change Request:
---
[63]Votes:
1
Bug Flags:
[64]brendan
[65]wanted1.9 +
[66]brendan
wanted1.9 [+]
[67]bc
[68]in-testsuite -
[69]bc
in-testsuite [-]
[70]bc
[71]in-litmus -
[72]bc
in-litmus [-]
____________________
behind-pref []
firefox-backlog []
sec-bounty [_]
sec-bounty-hof []
in-qa-testsuite []
____________________
qe-verify []
Crash Data
Signature:
None
Security
(public)
This bug is publicly visible.
User Story
Attachments
(2 files, 8 obsolete files)
[73]proposed fix
[74]17 years ago
[75]Brendan Eich [:brendan]
11.08 KB, patch
[76]Details | [77]Diff | [78]Splinter Review
[79]the changes i have to js/src (for wes to see)
[80]16 years ago
[81]timeless
9.74 KB, patch
[82]Details | [83]Diff | [84]Splinter Review
[85]fix via local list pools
[86]16 years ago
[87]Igor Bukanov
17.70 KB, patch
[88]Details | [89]Diff | [90]Splinter Review
[91]v2
[92]16 years ago
[93]Igor Bukanov
17.75 KB, patch
[94]Details | [95]Diff | [96]Splinter Review
[97]v3
[98]16 years ago
[99]Igor Bukanov
8.47 KB, patch
[100]Details | [101]Diff | [102]Splinter Review
[103]v3 with diff -U8, not -U1
[104]16 years ago
[105]Igor Bukanov
17.76 KB, patch
[106]Details | [107]Diff | [108]Splinter Review
[109]v3b
[110]16 years ago
[111]Igor Bukanov
18.52 KB, patch
[112]Details | [113]Diff | [114]Splinter Review
[115]v4
[116]16 years ago
[117]Igor Bukanov
18.54 KB, patch
brendan
: [118]review+
[119]Details | [120]Diff | [121]Splinter Review
[122]v5
[123]16 years ago
[124]Igor Bukanov
18.62 KB, patch
igor
: [125]review+
[126]Details | [127]Diff | [128]Splinter Review
[129]v6
[130]16 years ago
[131]Igor Bukanov
19.27 KB, patch
igor
: [132]review+
[133]Details | [134]Diff | [135]Splinter Review
(BUTTON) Show Obsolete
(BUTTON) Bottom |v
(BUTTON) Tags ▾
* Reset
(BUTTON) Timeline ▾
* Reset
*
* Collapse All
* Expand All
* Comments Only
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[136]Mike Moening
Reporter
(BUTTON)
[137]Description
o
17 years ago
After pulling down the latest JS trunk I now get the following abort:
Assertion failure: requestDebit requestCount, at .\jsgc.c:2638
Here's the API's being used.
pContext1 = JS_NewContext(...)
JS_SetContextThread(pContext1);
JS_BeginRequest(pContext1);
run script for awhile...
object in script requests to run another script.
Thread runs sub-script using same method as above.
pContext2 = JS_NewContext(...)
JS_SetContextThread(pContext2); //Associate the context with our thread.
JS_BeginRequest(pContext2);
script runs ok...
JS_EndRequest(pContext2);
JS_MaybeGC(pContext2); contextList and JSThread->gcFreeLists get corrupted and contain contexts or
free items from more than 1 JSRuntime.
There needs to be one more level of indirection in the ThreadPrivate storage.
It needs to be JSRuntime specific.
In other words the ThreadPrivate storage needs to be a hash of JSRuntimes to JSThread stru
ct. That way when the gcFreeLists and contextLists cannot be corrupted by usage of one or
more JSRuntime's.
Could somebody please recommend an appropriate storage mechanism for the hash table? Is t
here something you always use?
I would be happy to attempt a patch with a little guidance...
It looks like most of the changes will be in js_GetCurrentThread()...
Mike M
Summary: JS_MaybeGC aborts on (requestDebit requestCount) -> Corrupted
ThreadPrivate gcFreeLists with multiple JSRuntimes
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[146]Brendan Eich [:brendan]
(BUTTON)
[147]Comment 5
o
17 years ago
A workaround: JS_ClearContextThread before switching runtimes in the same thread.
/be
Assignee: general -> brendan
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[148]Mike Moening
Reporter
(BUTTON)
[149]Comment 6
o
17 years ago
That would fix the problem with cx->threadLinks and the GC ASSERT I was hitting.
However, I'm afraid the gcFreeLists might still be messed up since the freeList could cont
ain gc things from another runtime.
Please correct me if I'm wrong...
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[150]Mike Moening
Reporter
(BUTTON)
[151]Comment 7
o
17 years ago
Also this code:
memset(cx->thread->gcFreeLists, JS_FREE_PATTERN,
sizeof(cx->thread->gcFreeLists));
which happens in JS_ClearContextThread() might not be the safest thing to do given two run
times. Does that introduce a leak?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[152]Brendan Eich [:brendan]
(BUTTON)
[153]Comment 8
o
17 years ago
Mike, the workaround applies in all cases because sharing of cx->thread among one or more
cx in a runtime is managed by testing
JS_CLIST_IS_EMPTY(&cx->thread->contextList)
The gcFreeLists member of cx->thread cannot contain gc-things from another runtime if you
always JS_ClearContextThread before using a different cx from another runtime on the same
thread.
The GC rebuilds the global freelist every time, throwing away thread-local freelists.
Please try the workaround before trying to shoot it down, ok?
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[154]Mike Moening
Reporter
(BUTTON)
[155]Comment 9
o
17 years ago
I'm not shooting it down at all. Just thinking through all possible ramifications. For e
xample: What happens if some stuff is added to gcFreeList from runtime #2 and control is
returned to runtime #1 without GC running on #2?
BTW I did try it.
I use a JS_ClearContextThread JS_SetContextThread pair around any thread calls that jump t
o a different runtime.
So far it fixed the ASSERT I was seeing so far with GC being run on the second runtime.
Do you have any anwsers on the question in [156]comment #3? (lastBytes being zero)
Also, what should I do with the bug?
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[157]Mike Moening
Reporter
(BUTTON)
[158]Comment 10
o
17 years ago
Brendan, I just noticed the call to clear the gcFreeLists has a #ifdef DEBUG around it.
I think that will need to be removed. Agree?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[159]Brendan Eich [:brendan]
(BUTTON)
[160]Comment 11
o
17 years ago
(In reply to [161]comment #10)
> Brendan, I just noticed the call to clear the gcFreeLists has a #ifdef DEBUG
> around it.
> I think that will need to be removed. Agree?
No. JS_FREE_PATTERN is not even defined unless DEBUG is defined. This is just to make cras
h skidmarks recognizable.
Again, the thread-local freelists are not consulted by the GC; it rebuilds only the runtim
e-global freelists, linking every single collected gc-thing on the appropriate list. There
's no leaking, and no need to memset in js_ClearContextThread when js_SetContextThread wil
l memset to 0 (null pointers) on reactivation of the JSThread.
I took the bug. I'll work on a patch tomorrow.
/be
Status: NEW -> ASSIGNED
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[162]Brendan Eich [:brendan]
(BUTTON)
[163]Comment 12
o
17 years ago
Attached patch
[164]proposed fix (obsolete) -- [165]Details -- [166]Splinter Review
I haven't tested this, but I wanted to get design feedback as well as code review.
/be
[167]Attachment #263085 - Flags: review?(igor)
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[168]Igor Bukanov
Assignee
(BUTTON)
[169]Comment 13
o
17 years ago
(In reply to [170]comment #12)
> Created an attachment (id=263085) [details]
> proposed fix
>
> I haven't tested this, but I wanted to get design feedback as well as code
> review.
What about simply calling
status = PR_NewThreadPrivateIndex(&threadTPIndex, ptr);
once per runtime?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[171]Brendan Eich [:brendan]
(BUTTON)
[172]Comment 14
o
17 years ago
(In reply to [173]comment #13)
> (In reply to [174]comment #12)
> > Created an attachment (id=263085) [details] [details]
> > proposed fix
> >
> > I haven't tested this, but I wanted to get design feedback as well as code
> > review.
>
> What about simply calling
> status = PR_NewThreadPrivateIndex(&threadTPIndex, ptr);
> once per runtime?
We'd run out of TPindexes in some embeddings. Some embeddings use an unbounded number of r
untimes, one or more per thread. TPIndexes are allocated from a small fixed size array.
/be
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[175]Igor Bukanov
Assignee
(BUTTON)
[176]Comment 15
o
17 years ago
(In reply to [177]comment #14)
> > What about simply calling
> > status = PR_NewThreadPrivateIndex(&threadTPIndex, ptr);
> > once per runtime?
>
> We'd run out of TPindexes in some embeddings. Some embeddings use an unbounded
> number of runtimes, one or more per thread. TPIndexes are allocated from a
> small fixed size array.
I was under impression that PR_NewThreadPrivateIndex uses a hashtable itself. But it indee
d uses a fixed size array.
Then I think using a hashtable for JSThread is a better option rather then trying to worka
round the problem with gcRuntime. The code would be more straightforward and I suspect les
s in size.
[634df1b9e16fb879ac0da8543ca1be8f?d=mm&size=64]
[178]Brian Crowder
(BUTTON)
[179]Updated
o
17 years ago
Blocks: [180]365048
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[181]Brendan Eich [:brendan]
(BUTTON)
[182]Comment 16
o
17 years ago
I don't want every user of cx->thread->gc* to have to hash rt to an entry struct. That rec
omputes what is fixed, since the cx is in only that particular rt and (if the storage is s
table) we could have a cx->rtThread pointer computed once per cx.
But I really don't see how hashing could yield a smaller patch. The multimple rt per threa
d case is frankly weird. So why should we bend the code much for it?
/be
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[183]Igor Bukanov
Assignee
(BUTTON)
[184]Comment 17
o
17 years ago
(In reply to [185]comment #16)
> I don't want every user of cx->thread->gc* to have to hash rt to an entry
> struct.
My suggestion was to create a separated JSThread per runtime in js_GetCurrentThread.
> But I really don't see how hashing could yield a smaller patch.
After looking into this more closely I realized that the code size would be definitely big
ger. First it would be necessary to kill the hashtable and JSThread it holds in js_ThreadD
estructorCB. Then separated code to remove JSThread is necessary in DestroyRuntime.
> The multimple
> rt per thread case is frankly weird. So why should we bend the code much for
> it?
My problem is that the patch adds extra checks per each JS_malloc and js_NewGCThing just t
o support this weired case. Perhaps a simpler solution would be to push the hashing above
to the application? That is, the code can detect multiple runtimes that wants to use the s
ame JSThread and report error requiring to implement some callback?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[186]Brendan Eich [:brendan]
(BUTTON)
[187]Comment 18
o
17 years ago
Mike, have you been running with this patch, or some other patch, or only at most one runt
ime per thread, or what?
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[188]Mike Moening
Reporter
(BUTTON)
[189]Comment 19
o
17 years ago
I was running with the hack around from [190]comment #5...calling JS_ClearContextThread be
fore switching runtimes in the same thread.
I don't like this hack but its better than nothing.
I have not tested the patch.
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[191]timeless
(BUTTON)
[192]Comment 20
o
17 years ago
Comment on [193]attachment 263085 [194][details] [195][diff] [196][review]
proposed fix
I hit an assert using jsdb which this patch fixes.
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[197]timeless
(BUTTON)
[198]Comment 21
o
17 years ago
Comment on [199]attachment 263085 [200][details] [201][diff] [202][review]
proposed fix
I hit an assert using jsdb which this patch fixes.
* Check all contexts on cx->thread->contextList for active requests,
* counting each such context against requestDebit.
This comment needs to be updated to specify "associated with this runtime" or something.
* Set all thread local freelists to NULL.
And this comment.
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[203]Igor Bukanov
Assignee
(BUTTON)
[204]Comment 22
o
17 years ago
(In reply to [205]comment #20)
> (From update of [206]attachment 263085 [207][details] [208][diff] [209][review])
> I hit an assert using jsdb which this patch fixes.
Is this with multiple JSRuntime instances?
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[210]timeless
(BUTTON)
[211]Comment 23
o
17 years ago
yes, jsdb has 4 :).
unfortunately i don't currently have a nice js_spray thing with which to test the threaded
portion of this patch in jsdb (but bug XXXX will provide one to js shell which would give
jsdb a way for free), and i'd probably need to write some amusing debugger script that re
sponded automatically to exceptions. But I believe this patch is correct.
js_ClearContextThread(JSContext *cx)
{
JS_REMOVE_AND_INIT_LINK(&cx->threadLinks);
#ifdef DEBUG
if (JS_CLIST_IS_EMPTY(&cx->thread->contextList)) {
memset(cx->thread->gcFreeLists, JS_FREE_PATTERN,
sizeof(cx->thread->gcFreeLists));
+ cx->thread->gcRuntime = NULL;
That this is in a DEBUG statement whereas its counterpart isn't worries me.
i'd rather:
-#ifdef DEBUG
if (JS_CLIST_IS_EMPTY(&cx->thread->contextList)) {
+#ifdef DEBUG
memset(cx->thread->gcFreeLists, JS_FREE_PATTERN,
sizeof(cx->thread->gcFreeLists));
+#endif
+ cx->thread->gcRuntime = NULL;
}
-#endif
I'm also slightly uncertain about cx->thread->gcRuntime. I'm fairly certain there's no api
to access it, which means that anyone who calls SetContext will step on the previous owne
r, and the previous owner would magically need to know that they've been stepped on.
In js_NewGCThing, I'm wondering why you don't just claim cx->thread->gcRuntime temporarily
for the duration of the call. Only one piece of code can run on a thread at a time, so th
e read-save, write, write-restore pattern shouldn't really hurt anyone.
[634df1b9e16fb879ac0da8543ca1be8f?d=mm&size=64]
[212]Brian Crowder
(BUTTON)
[213]Comment 24
o
17 years ago
[214]Bug 404879 is the bug you want for threaded testing in js-shell.
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[215]Mike Moening
Reporter
(BUTTON)
[216]Comment 25
o
17 years ago
Brian,
That multi-threaded js-shell will not uncover bugs like this one.
It's and entirely different animal.
timless, I share your concern in [217]comment #23.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[218]Brendan Eich [:brendan]
(BUTTON)
[219]Comment 26
o
17 years ago
Comment on [220]attachment 263085 [221][details] [222][diff] [223][review]
proposed fix
Better patch coming soon. It will require embeddings to #define the maximum number of runt
imes used by a thread, which should not be too large.
Timeless: jsdb is its own build with custom SpiderMonkey build, right? It better be, given
the above.
/be
[224]Attachment #263085 - Attachment is obsolete: true
[225]Attachment #263085 - Flags: review?(igor)
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[226]Igor Bukanov
Assignee
(BUTTON)
[227]Comment 27
o
17 years ago
(In reply to [228]comment #26)
> (From update of [229]attachment 263085 [230][details] [231][diff] [232][review])
> Better patch coming soon. It will require embeddings to #define the maximum
> number of runtimes used by a thread, which should not be too large.
But this still would not address the scalability problem with one runtime and many threads
that Mike reported when the free lists are killed when there are other threads that would
like to use them.
Perhaps it is better to decouple thread local free-lists from the JSThread and use a globa
l pool of thread local lists with JS_BeginRequest/JS_EndRequest getting/returning entries
to the pool?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[233]Brendan Eich [:brendan]
(BUTTON)
[234]Updated
o
17 years ago
Flags: wanted1.9+
Priority: -- -> P3
Target Milestone: --- -> mozilla1.9beta4
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[235]Brendan Eich [:brendan]
(BUTTON)
[236]Comment 28
o
17 years ago
(In reply to [237]comment #27)
> (In reply to [238]comment #26)
> > (From update of [239]attachment 263085 [240][details] [241][diff] [242][review] [detai
ls])
> > Better patch coming soon. It will require embeddings to #define the maximum
> > number of runtimes used by a thread, which should not be too large.
>
> But this still would not address the scalability problem with one runtime and
> many threads that Mike reported when the free lists are killed when there are
> other threads that would like to use them.
No, it would -- what I'm working on does not share JSThread.gcFreeList among more than one
runtime, it splits out a JSRuntimeThread per runtime using a JSThread. Patch soon.
> Perhaps it is better to decouple thread local free-lists from the JSThread and
> use a global pool of thread local lists with JS_BeginRequest/JS_EndRequest
> getting/returning entries to the pool?
That's what my patch does, more or less. It uses JS_BeginRequest to select the JSRuntimeTh
read used by the GC for fast lock-free allocation, etc., and "pops" that JSRuntimeThread (
not really on a stack, an MRU list) in JS_EndRequest. But again, you have to #define JS_RU
NTIMES_PER_THREAD to be > 1 to get this code. Without that macro, you get no extra indirec
tion overhead -- you get today's code. This is the decision I'd like to make "stick".
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[243]Mike Moening
Reporter
(BUTTON)
[244]Comment 29
o
17 years ago
>Perhaps it is better to decouple thread local free-lists from the JSThread and
>use a global pool of thread local lists with JS_BeginRequest/JS_EndRequest
>getting/returning entries to the pool?
Yes that would be much better. Another thread running GC should not be sweeping all other
threads free lists every time GC is run. That creates too much thrashing. Once a thread
spins up let it keep its own free lists until the end of the request or maybe thread. Whe
n running many threads like this the total amount of memory consumed is not really that im
portant. Speed and thread contention is the major concern.
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[245]Igor Bukanov
Assignee
(BUTTON)
[246]Comment 30
o
17 years ago
(In reply to [247]comment #27)
> Perhaps it is better to decouple thread local free-lists from the JSThread and
> use a global pool of thread local lists with JS_BeginRequest/JS_EndRequest
> getting/returning entries to the pool?
That in fact suggests a simple approach:
1. Modify JS_GC to assemble a free list as a list of lists where the number of entries on
the each sublist corresponds to the current MAX_THREAD_LOCAL_THINGS.
2. Modify js_NewGCThing to transfer the sublist into JSContext (not JSThread as it is done
now). Since the sublist is already assembled, it should speedup the allocation.
3. Modify js_EndRequest/js_DestroyContext to return the unused list back to the global poo
l.
This should resolve this bug and address the scalability issues as well.
Priority: P3 -> --
Target Milestone: mozilla1.9beta4 -> ---
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[248]Igor Bukanov
Assignee
(BUTTON)
[249]Comment 31
o
17 years ago
(In reply to [250]comment #30)
> This should resolve this bug and address the scalability issues as well.
And this would avoid arbitrary limits on numbers of runtimes per thread.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[251]Brendan Eich [:brendan]
(BUTTON)
[252]Comment 32
o
17 years ago
Igor, there's more at stack in JSThread than the gcFreeList member -- especially the prope
rtyCache should not be thrashed by GC on one of N (small N) runtimes. It is true we could
put gcFreeList in each JSContext, but that's a lot of bloat and potential hoarding in embe
ddings like Firefox that have many (many) contexts per thread.
Let me get this patch together, but please comment (MikeM, timeless: this means you) on th
e #define JS_RUNTIMES_PER_THREAD compile-time configuration requirement that I am proposin
g.
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[253]Brendan Eich [:brendan]
(BUTTON)
[254]Comment 33
o
17 years ago
So long as JSThread exists, we have the # JSRuntimes > 1 vs. JSThread pigeon-hole problem.
You can't avoid it just by moving gcFreeList into JSContext.
We cannot have a property cache per context in Firefox. We must have lock-free, thread-loc
al storage. Therefore JSThread is not going away. Therefore we must have a sane way of mul
tiplexing its members that vary per runtime. By sane I mean "arbitrary", because it is not
desirable to support indefinite number of runtimes per thread.
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[255]Brendan Eich [:brendan]
(BUTTON)
[256]Comment 34
o
17 years ago
(In reply to [257]comment #32)
> Igor, there's more at stack
Heh, "at stake".
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[258]Brendan Eich [:brendan]
(BUTTON)
[259]Comment 35
o
17 years ago
If the number of runtimes that might share a thread can be bounded small enough, then we *
can* just allocate more thread-private indexes from NSPR. That would be an even simpler so
lution.
/be
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[260]Igor Bukanov
Assignee
(BUTTON)
[261]Comment 36
o
17 years ago
(In reply to [262]comment #29)
Another thread running GC should not be
> sweeping all other threads free lists every time GC is run. That creates too
> much thrashing.
This translates into keeping the existing free lists untouched during the GC. But this wil
l prevent releasing arenas without live things back to the system if one wants to avoid sc
anning the free lists an extra time during the GC.
If memory consumption is not that important, it can be a good trade off. But this is defin
itely not for a browser embedding.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[263]Brendan Eich [:brendan]
(BUTTON)
[264]Comment 37
o
17 years ago
(In reply to [265]comment #36)
> (In reply to [266]comment #29)
> Another thread running GC should not be
> > sweeping all other threads free lists every time GC is run. That creates too
> > much thrashing.
I misunderstood MikeM here to be saying unrelated runtimes sharing a thread should not aff
ect one anothers' per-thread-viewed-by-runtime freelists, which I agree with and my patch
addresses. But you are right, that's not what he wrote :-/.
> This translates into keeping the existing free lists untouched during the GC.
> But this will prevent releasing arenas without live things back to the system
> if one wants to avoid scanning the free lists an extra time during the GC.
I don't buy it anyway, since the freelist is refilled on next js_NewGCThing, so it is pure
ly an optimization to amortize runtime freelist locking overhead.
> If memory consumption is not that important, it can be a good trade off. But
> this is definitely not for a browser embedding.
It's not clear MikeM needs it either. Or perhaps I should say: he may really need copying
generational GC etc. -- the works. That is not coming except far down the road, probably v
ia ActionMonkey.
/be
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[267]Igor Bukanov
Assignee
(BUTTON)
[268]Comment 38
o
17 years ago
(In reply to [269]comment #32)
> but that's a
> lot of bloat and potential hoarding in embeddings like Firefox that have many
> (many) contexts per thread.
The bloat is exactly 10*sizeof(void*) bytes per context. And it can be made 4*sizeof(void*
) if one allocates the lists for xml support lazily.
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[270]Igor Bukanov
Assignee
(BUTTON)
[271]Comment 39
o
17 years ago
(In reply to [272]comment #37)
> I don't buy it anyway, since the freelist is refilled on next js_NewGCThing, so
> it is purely an optimization to amortize runtime freelist locking overhead.
The idea is to assemble during the GC the freed cells as a list of lists to skip refiling
overhead in js_NewGCThing.
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[273]Mike Moening
Reporter
(BUTTON)
[274]Comment 40
o
17 years ago
>1. Modify JS_GC to assemble a free list as a list of lists where the number of
>entries on the each sublist corresponds to the current MAX_THREAD_LOCAL_THINGS.
Right now MAX_THREAD_LOCAL_THINGS is set to 8. That doesn't seem like very many things to
me. Maybe I'm not understanding right...
Not sure I like the JS_RUNTIMES_PER_THREAD idea. If I right a piece of software that has
2 runtimes and I sit on top of somebody else's code that has X runtimes I really don't kno
w that to set this value to.
So long as we can start and thread and do as much work as possible with as many JSContexts
as is required without GC interfence I'd be happy. The architecture is a pool of threads
and a pool of contexts and a cache of pre-compiled scripts.
Each thread runs through this basic sequence many times on 1 thread from the pool.
1) Get free JS context from the pool.
2) JS_SetContextThread //Associate the context with our thread.
3) JS_BeginRequest
4) Run 1+ scripts for awhile.
5) JS_SuspendRequest
6) wait for long running thing (like SQL query)
7) JS_ResumeRequest
8) JS_EndRequest(pContext2);
9) JS_MaybeGC(pContext2);
10) JS_SetContextThread(NULL) //Un-associate the context with our thread
11) Return free JS context to pool again.
Unless the thread is shutting down I don't want to give back my GC things.
I'm just going to need them again anyway in a very short while.
That means once the thread is starting let it keep its free lists do GC only on that threa
d. Don't create a contention problem between threads over GC.
In regards to your comment:
>If memory consumption is not that important, it can be a good trade off. But
>this is definitely not for a browser embedding.
Memory consumption is not important at all. We are talking big servers with 2-12 Gigs of
ram. Lock free allocations and GC is what is important.
The multiple runtime thing is still a problem in the scenario too.
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[275]Mike Moening
Reporter
(BUTTON)
[276]Comment 41
o
17 years ago
Why should 1 thread ever have to wait for another thread to run GC?
Think massively parallel here.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[277]Brendan Eich [:brendan]
(BUTTON)
[278]Comment 42
o
17 years ago
Again, you can shrink the gcFreeList space hit on JSContext with more work, but that does
not solve other JSThread members.
And I do not understand the proposal to amortize runtime freelist locking harder by making
the GC assemble a list of lists. How many free things would be pre-filled on the list of
lists? We do not want to hoard. At some point the allocator exhausts the list -- then what
?
We have to be willing to run a GC or simply go to the runtime allocator and refill the thr
ead-local list.
Running the GC is costly. We already have code to refill the thread-local list. That is si
mple (relative to alternatives) and sufficient to amortize the runtime-allocator overhead
down to the noise (we can adjust the number of things prefilled on the thread-local list).
I'm leery of over-engineering for one case here, while still not solving the valid use-cas
es for fast/lock-free thread-local (not per-context) storage.
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[279]Brendan Eich [:brendan]
(BUTTON)
[280]Comment 43
o
17 years ago
Mike: GC is a runtime-wide procedure. If you do not want threads to share objects, give th
em their own runtimes and they'll GC independently. You cannot have it both ways.
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[281]Mike Moening
Reporter
(BUTTON)
[282]Comment 44
o
17 years ago
>Mike: GC is a runtime-wide procedure. If you do not want threads to share
>objects, give them their own runtimes and they'll GC independently. You cannot
>have it both ways.
Why not? Ask for the sky...
Yes we DO want to be able to share objects between threads. However right now every time
GC() runs on any thread it steals the free things away from and blocks all other threads.
Just do this at the end or the thread or the end of the request. Don't keep stealing fre
e things from all threads and then put them back in again in the threads free list 1 micro
second later. That thrashing helps nobody. Right now we do not have fast/lock-free threa
d local allocation because the GC steals the memory back too fast.
Think "How would I architect memory allocation if had to support 3000 concurrent requests
with 8 processors running at the same time?"
>At some point the allocator exhausts the list -- then what?
Make more. Memory is cheap.
I agree this is not something the typical browser would need.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[283]Brendan Eich [:brendan]
(BUTTON)
[284]Comment 45
o
17 years ago
MikeM: it sounds like you are running the GC too often. True?
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[285]Mike Moening
Reporter
(BUTTON)
[286]Comment 46
o
17 years ago
Hard to say.
Right now I do JS_MaybeGC() after every request.
JS_GC() is run every 200 requests.
This might be way too often...???? I do not know how to form a better rule...
How can I get metrics on usage of memory so I can form a better plan?
Here's the runtime and context setup.
JS_NewRuntime() is being passed 1024*1024*128 or 128 megs
JS_NewContext(rt, 8192) is passed 8K
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[287]Brendan Eich [:brendan]
(BUTTON)
[288]Comment 47
o
17 years ago
JS_MaybeGC after every request is probably overkill, but is it actually GC'ing? That would
be interesting to know. Typically it is used from the branch callback, which is not the o
peration count callback, and more efficient and tuning-friendly than before. Joe-Bob says
check it out.
Forcing a GC every 200 requests does not make sense to me. There's nothing about 200 that
says you've got enough garbage for a GC to be worthwhile.
JS_NewRuntime's parameter may be causing JS_MaybeGC to GC. Suggest making it 0xffffffff fo
r now.
JS_NewContext's parameter has nothing to do with GC.
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[289]Brendan Eich [:brendan]
(BUTTON)
[290]Comment 48
o
17 years ago
(In reply to [291]comment #47)
> JS_MaybeGC after every request is probably overkill, but is it actually GC'ing?
> That would be interesting to know. Typically it is used from the branch
> callback, which is not
s/not/now/
> the operation count callback, and more efficient and
> tuning-friendly than before. Joe-Bob says check it out.
See [292]http://lxr.mozilla.org/mozilla/source/js/src/jsapi.h#2130
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[293]Mike Moening
Reporter
(BUTTON)
[294]Comment 49
o
17 years ago
I'm already using operation callback to shut down long running scripts. My limit is set t
o (256*4096).
How can I ask the runtime how much it has left in an efficient way?
Can I use this JS_SetGCCallback() to tell me when GC is being run?
The remainder of this tuning stuff can be done offline via private email.
Lets get back to the bug at hand.
After all that was said how can we solve the bug and improve performance at the same time
without imposing limits on # of runtimes?
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[295]Brendan Eich [:brendan]
(BUTTON)
[296]Comment 50
o
17 years ago
(In reply to [297]comment #49)
> After all that was said how can we solve the bug and improve performance at the
> same time without imposing limits on # of runtimes?
There's no such thing as a free lunch. In other words, you can't always get what you want
(Heinlein and The Stones, wow).
Why do you "need" unlimited numbers of runtimes containing contexts executing scripts in t
he same thread? If you don't, what limited number do you expect, or can you live with?
/be
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[298]Brendan Eich [:brendan]
(BUTTON)
[299]Comment 51
o
17 years ago
"There ain't no such .."..
Not my day.
Happy to stick to the topic in this bug, but if it is distorted by your embedding doing to
o much GC, then we should not design around that distortion!
/be
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[300]Mike Moening
Reporter
(BUTTON)
[301]Comment 52
o
17 years ago
>embedding doing too much GC, then we should not design around that distortion!
Agreed.
>Why do you "need" unlimited numbers of runtimes containing contexts executing
>scripts in the same thread? If you don't, what limited number do you expect, or
>can you live with?
I use two max.
However if somebody used our JSMonkeyWrench DLL in their embedding it could bring up the t
otal of runtimes depending on what they are doing.
Sounds like others us 4? (don't know why...)
So I guess 4...???
Maybe GC shouldn't go through ALL the threads and steal their GC things from the free list
s. Just iterate as many of the thread freelists as it needs but no more. That would cut d
own the thrash quite a bit.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[302]Brendan Eich [:brendan]
(BUTTON)
[303]Comment 53
o
17 years ago
As Igor already noted, the GC could rebuild thread-local freelists, but it cannot just lea
ve (some of) them to dangle -- they are not roots (must not be or you'll have bad leaks),
therefore the things they point to will be swept up from under them and possible allocated
to someone else, behind their back.
/be
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[304]timeless
(BUTTON)
[305]Comment 54
o
16 years ago
Attached patch
[306]the changes i have to js/src (for wes to see) -- [307]Details --
[308]Splinter Review
brendan: i assume you're asking whether I'm running w/ a patch from this bug to deal w/ th
e fact that otherwise I'd be dead, the answer is yes. as for whether it's truly private, n
o, i patch a mozilla source tree and use the js3250 generated from it for jsdb.
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[309]Brendan Eich [:brendan]
(BUTTON)
[310]Comment 55
o
16 years ago
The patch you're using is not the right approach. I'm not supporting it, but I do want to
fix this bug -- after Firefox 3 / Gecko 1.9 priorities are done.
/be
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[311]timeless
(BUTTON)
[312]Comment 56
o
16 years ago
yeah, i understand, i'm not shipping it to any consumers. i just need something that doesn
't crash/corrupt and works well enough to let me investigate other problems, which it does
(i haven't actually gotten around to having much real concurrency, so i have no idea whet
her it actually scales, but for the time being not being patched was fatal).
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[313]Igor Bukanov
Assignee
(BUTTON)
[314]Comment 57
o
16 years ago
Attached patch
[315]fix via local list pools (obsolete) -- [316]Details -- [317]Splinter Review
The new patch implements that idea about pool of free list sets. The context gains a set f
rom the pool during allocation and release the set back to the pool when it exits the requ
ests. This way a set with few free lists available can be reused by another requests/conte
xt.
The new implementation does not store anything in JSThread. As such it is immune to the mu
ltiple runtime problem.
Assignee: brendan -> igor
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[318]Igor Bukanov
Assignee
(BUTTON)
[319]Comment 58
o
16 years ago
Attached patch
[320]v2 (obsolete) -- [321]Details -- [322]Splinter Review
fixing bugs: now the patch passes shell tests.
[323]Attachment #308730 - Attachment is obsolete: true
[75891848cf20f4d04a587ffc68ed5e84?d=mm&size=64]
[324]Mike Moening
Reporter
(BUTTON)
[325]Comment 59
o
16 years ago
Igor, can you land this fix?
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[326]Igor Bukanov
Assignee
(BUTTON)
[327]Comment 60
o
16 years ago
(In reply to [328]comment #59)
> Igor, can you land this fix?
>
First this has to be tested and reviewed.
[634df1b9e16fb879ac0da8543ca1be8f?d=mm&size=64]
[329]Brian Crowder
(BUTTON)
[330]Comment 61
o
16 years ago
Igor: Any testing I can help with? You just want suite/mochis?
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[331]timeless
(BUTTON)
[332]Comment 62
o
16 years ago
Comment on [333]attachment 308772 [334][details] [335][diff] [336][review]
v2
+ if (keepCount != 0) {
+ do {
+ } while (--keepCount != 0);
+ }
given that you aren't using keepCount outside or inside this block,
while (keepCount--) {
...
}
should be fine.
ReleaseGCFreeListsPool
is this correctly named? the early return makes me worry.
+ freeLists = (JSGCFreeListSet *) malloc(sizeof *freeLists);
+ if (!freeLists)
+ return NULL;
+ memset(freeLists, 0, sizeof *freeLists);
what's wrong w/ calloc?
a comment explaining why you aren't using JS_malloc might be a good idea (I'm assuming it'
s because the callers handle error reporting themselves).
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[337]Igor Bukanov
Assignee
(BUTTON)
[338]Comment 63
o
16 years ago
(In reply to [339]comment #61)
> Igor: Any testing I can help with? You just want suite/mochis?
>
suite/mochi/sunspider numbers (should not regress in the browser)/testing with firebug (it
uses multiple runtimes)
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[340]Igor Bukanov
Assignee
(BUTTON)
[341]Comment 64
o
16 years ago
Attached patch
[342]v3 (obsolete) -- [343]Details -- [344]Splinter Review
The patch addresses the issues from the [345]comment 62, see the delta below.
timeless: I renamed ReleaseGCFreeListsPool into EmptyGCFreeListsPool. Does the new name re
flects "remove all except the given amount of lists from the pool" semantics of the functi
on?
--- /home/igor/m/ff/mozilla/quilt.F21961/js/src/jsgc.c 2008-03-28 14:24:15.000000000 +010
0
+++ js/src/jsgc.c 2008-03-28 14:23:03.000000000 +0100
@@ -1410,3 +1410,3 @@ CheckLeakedRoots(JSRuntime *rt);
static void
-ReleaseGCFreeListsPool(JSRuntime *rt, uintN keepCount);
+EmptyGCFreeListsPool(JSRuntime *rt, uintN keepCount);
@@ -1424,3 +1424,3 @@ js_FinishGC(JSRuntime *rt)
#ifdef JS_THREADSAFE
- ReleaseGCFreeListsPool(rt, 0);
+ EmptyGCFreeListsPool(rt, 0);
JS_ASSERT(!rt->gcFreeListsPool);
@@ -1689,3 +1689,3 @@ const JSGCFreeListSet js_GCEmptyFreeList
static void
-ReleaseGCFreeListsPool(JSRuntime *rt, uintN keepCount)
+EmptyGCFreeListsPool(JSRuntime *rt, uintN keepCount)
{
@@ -1694,9 +1694,9 @@ ReleaseGCFreeListsPool(JSRuntime *rt, ui
cursor = &rt->gcFreeListsPool;
- if (keepCount != 0) {
- do {
- if (!(freeLists = *cursor))
- return;
- memset(freeLists->array, 0, sizeof freeLists->array);
- cursor = &freeLists->link;
- } while (--keepCount != 0);
+ while (keepCount != 0) {
+ --keepCount;
+ freeLists = *cursor;
+ if (!freeLists)
+ return;
+ memset(freeLists->array, 0, sizeof freeLists->array);
+ cursor = &freeLists->link;
}
@@ -1739,6 +1739,8 @@ EnsureLocalFreeList(JSContext *cx)
} else {
- freeLists = (JSGCFreeListSet *) malloc(sizeof *freeLists);
+ /*
+ * No JS_malloc as the caller reports out-of-memory itself.
+ */
+ freeLists = (JSGCFreeListSet *) calloc(1, sizeof *freeLists);
if (!freeLists)
return NULL;
- memset(freeLists, 0, sizeof *freeLists);
}
@@ -3491,3 +3493,3 @@ js_GC(JSContext *cx, JSGCInvocationKind
*/
- ReleaseGCFreeListsPool(rt, 2);
+ EmptyGCFreeListsPool(rt, 2);
#endif
[346]Attachment #308772 - Attachment is obsolete: true
[347]Attachment #312275 - Flags: review?(brendan)
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[348]Igor Bukanov
Assignee
(BUTTON)
[349]Comment 65
o
16 years ago
Attached patch
[350]v3 with diff -U8, not -U1 (obsolete) -- [351]Details -- [352]Splinter Review
[353]Attachment #312275 - Attachment is obsolete: true
[354]Attachment #312276 - Flags: review?(brendan)
[355]Attachment #312275 - Flags: review?(brendan)
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[356]timeless
(BUTTON)
[357]Comment 66
o
16 years ago
offhand, I think "Trim" is better than "Empty" or "Release", I think I *finally* understan
d what the function is doing.
wrt jsdb, I finally have jsdb itself handling threads. Sadly jsd doesn't handle them prope
rly and jsd is going to need some serious work to get there. (scatter currently asserts in
jsd!jsd_GetValueString when called from any of the other threads). Once jsd itself is abl
e to handle threads properly, I should have more feedback.
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[358]Igor Bukanov
Assignee
(BUTTON)
[359]Comment 67
o
16 years ago
Attached patch
[360]v3b (obsolete) -- [361]Details -- [362]Splinter Review
The new version syncs the patch with CVS head and renames EmptyGCFreeListsPool into uses T
rimGCFreeListsPool.
[363]Attachment #312276 - Attachment is obsolete: true
[364]Attachment #312906 - Flags: review?(brendan)
[365]Attachment #312276 - Flags: review?(brendan)
[e4a0566b254d665aa267b7874726fbbf?d=mm&size=64]
[366]timeless
(BUTTON)
[367]Updated
o
16 years ago
Blocks: [368]426529
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[369]Brendan Eich [:brendan]
(BUTTON)
[370]Updated
o
16 years ago
Blocks: [371]js1.8src
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[372]Igor Bukanov
Assignee
(BUTTON)
[373]Updated
o
16 years ago
Blocks: [374]437325
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[375]Igor Bukanov
Assignee
(BUTTON)
[376]Updated
o
16 years ago
No longer blocks: [377]437325
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[378]Igor Bukanov
Assignee
(BUTTON)
[379]Comment 68
o
16 years ago
Attached patch
[380]v4 (obsolete) -- [381]Details -- [382]Splinter Review
The patch is a port of the v3b version to mozilla-central. In addition I made sure that it
compiles with !JS_THREADSAFE.
[383]Attachment #312906 - Attachment is obsolete: true
[384]Attachment #325543 - Flags: review?(brendan)
[385]Attachment #312906 - Flags: review?(brendan)
[ee4c7c6351b45c4655e16993a29979b0?d=mm&size=64]
[386]Bob Clary [:bc] (inactive)
(BUTTON)
[387]Updated
o
16 years ago
No longer blocks: [388]js1.8src
[ee4c7c6351b45c4655e16993a29979b0?d=mm&size=64]
[389]Bob Clary [:bc] (inactive)
(BUTTON)
[390]Updated
o
16 years ago
Blocks: [391]js1.8
[ee4c7c6351b45c4655e16993a29979b0?d=mm&size=64]
[392]Bob Clary [:bc] (inactive)
(BUTTON)
[393]Updated
o
16 years ago
No longer blocks: [394]js1.8
[ee4c7c6351b45c4655e16993a29979b0?d=mm&size=64]
[395]Bob Clary [:bc] (inactive)
(BUTTON)
[396]Updated
o
16 years ago
Blocks: [397]js1.8src
[c936d5fc7ef09504480b9d8aafb7e8a0?d=mm&size=64]
[398]Brendan Eich [:brendan]
(BUTTON)
[399]Comment 69
o
16 years ago
Comment on [400]attachment 325543 [401][details] [402][diff] [403][review]
v4
Looks great -- want to get a cvs.mozilla.org version of this for js1.8src, feel free to at
tach one if handy. Thanks,
/be
[404]Attachment #325543 - Flags: review?(brendan) -> review+
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[405]Igor Bukanov
Assignee
(BUTTON)
[406]Comment 70
o
16 years ago
Attached patch
[407]v5 (obsolete) -- [408]Details -- [409]Splinter Review
Here is a version for check in
[410]Attachment #325543 - Attachment is obsolete: true
[411]Attachment #326472 - Flags: review+
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[412]Igor Bukanov
Assignee
(BUTTON)
[413]Comment 71
o
16 years ago
I pushed the patch from the [414]comment 70 to mozilla-central:
author Igor Bukanov
Tue Jun 24 15:17:52 2008 +0200 (at Tue Jun 24 15:17:52 2008 +0200)
changeset 15493 4699797259f1
parent 15487 0c8e64474660
parent 15492 76caed42cf7c
child 15494 631c0cb99782
[[416]Bug 378918] Scallable free lists for GC, r=brendan
Status: ASSIGNED -> RESOLVED
Closed: 16 years ago
Resolution: --- -> FIXED
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[417]Igor Bukanov
Assignee
(BUTTON)
[418]Comment 72
o
16 years ago
I backed out the patch to investigate the leak problem on tinderbox:
changeset: 15509:0442f945a866
tag: tip
user: Igor Bukanov
date: Tue Jun 24 18:55:06 2008 +0200
summary: [[420]Bug 378918] backing out to investigate the tinderbox leak problem
Status: RESOLVED -> REOPENED
Resolution: FIXED -> ---
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[421]Igor Bukanov
Assignee
(BUTTON)
[422]Comment 73
o
16 years ago
Attached patch
[423]v6 -- [424]Details -- [425]Splinter Review
The new version is v5 synchronized with the trunk. I cannot reproduce the original leak fa
ils locally so I will try to land this again assuming that the original failures were unre
lated to the patch.
[426]Attachment #326472 - Attachment is obsolete: true
[427]Attachment #339961 - Flags: review+
[78556976aa7c7e7980d6865f27df11b8?d=mm&size=64]
[428]Igor Bukanov
Assignee
(BUTTON)
[429]Comment 74
o
16 years ago
landed - [430]http://hg.mozilla.org/mozilla-central/rev/5aaa5bcc6024
Status: REOPENED -> RESOLVED
Closed: 16 years ago -> 16 years ago
Resolution: --- -> FIXED
[ee4c7c6351b45c4655e16993a29979b0?d=mm&size=64]
[431]Bob Clary [:bc] (inactive)
(BUTTON)
[432]Updated
o
16 years ago
Flags: in-testsuite-
Flags: in-litmus-
[4f93ff57856ea72121bf4e3db5ca593c?d=mm&size=64]
[433]ash_mozilla
(BUTTON)
[434]Comment 75
o
15 years ago
I think this bug has been fixed in CVS (for a SM1.8RC2), but jscntxt.c seems quite differe
nt to the version in these patches.
You need to [435]log in before you can comment on or make changes to this bug.
(BUTTON) Top ^|
Attachment
(BUTTON) (BUTTON) (BUTTON) Hide Details (BUTTON)
General
Creator:
[436]Brendan Eich [:brendan]
Created:
Updated:
Size:
Description
____________________
File Name
____________________
Content Type
____________________
(BUTTON) Raw (BUTTON) Diff (BUTTON) Splinter Review
References
Visible links:
1. https://bugzilla.mozilla.org/
2. https://bugzilla.mozilla.org/search_plugin.cgi
3. https://bugzilla.mozilla.org/home
4. https://bugzilla.mozilla.org/describecomponents.cgi
5. https://bugzilla.mozilla.org/query.cgi?format=advanced
6. https://bugzilla.mozilla.org/report.cgi
7. https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html
8. https://bmo.readthedocs.io/en/latest/
9. https://bugzilla.mozilla.org/createaccount.cgi
10. https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=1
11. https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=1#forgot
12. https://www.mozilla.org/
13. https://www.mozilla.org/privacy/websites/
14. https://www.mozilla.org/privacy/websites/#cookies
15. https://www.mozilla.org/about/legal/
16. https://bugzilla.mozilla.org/rest/bug/378918
17. https://bugzilla.mozilla.org/show_bug.cgi?ctype=xml&id=378918
18. https://bugzilla.mozilla.org/show_bug.cgi?id=378918
19. https://wiki.mozilla.org/BMO/UserGuide/BugFields#short_desc
20. https://bugzilla.mozilla.org/describecomponents.cgi?product=Core
21. https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox
22. https://wiki.mozilla.org/Modules/All#Core
23. https://bugzilla.mozilla.org/buglist.cgi?product=Core&bug_status=__open__
24. https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
25. https://bugzilla.mozilla.org/describecomponents.cgi?product=Core&component=JavaScript%20Engine#JavaScript%20Engine
26. https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=JavaScript%20Engine&bug_status=__open__
27. https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=JavaScript%20Engine&chfield=resolution&chfieldfrom=-6m&chfieldvalue=FIXED&bug_status=__closed__
28. https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=JavaScript%20Engine
29. https://wiki.mozilla.org/BMO/UserGuide/BugFields#version
30. https://wiki.mozilla.org/BMO/UserGuide/BugFields#rep_platform
31. https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_type
32. https://wiki.mozilla.org/BMO/UserGuide/BugFields#priority
33. https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity
34. https://wiki.mozilla.org/BMO/UserGuide/BugStatuses
35. https://wiki.mozilla.org/BMO/UserGuide/BugStatuses
36. https://wiki.mozilla.org/BMO/UserGuide/BugFields#target_milestone
37. https://wiki.mozilla.org/BMO/UserGuide#Project_Flags
38. https://wiki.mozilla.org/BMO/UserGuide#Tracking_Flags
39. https://wiki.mozilla.org/BMO/UserGuide/BugFields#assigned_to
40. https://bugzilla.mozilla.org/user_profile?user_id=50763
41. https://wiki.mozilla.org/BMO/UserGuide/BugFields#assigned_to
42. https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_mentor
43. https://wiki.mozilla.org/BMO/UserGuide/BugFields#qa_contact
44. https://wiki.mozilla.org/BMO/UserGuide/BugFields#reporter
45. https://bugzilla.mozilla.org/user_profile?user_id=212318
46. https://wiki.mozilla.org/BMO/UserGuide/BugFields#triage_owner
47. https://bugzilla.mozilla.org/user_profile?user_id=714609
48. https://wiki.mozilla.org/BMO/UserGuide/BugFields#cc
49. https://wiki.mozilla.org/BMO/UserGuide/BugFields#dependson
50. https://wiki.mozilla.org/BMO/UserGuide/BugFields#blocks
51. https://bugzilla.mozilla.org/show_bug.cgi?id=365048
52. https://bugzilla.mozilla.org/show_bug.cgi?id=426529
53. https://bugzilla.mozilla.org/show_bug.cgi?id=428420
54. https://bugzilla.mozilla.org/showdependencytree.cgi?id=378918&hide_resolved=1
55. https://bugzilla.mozilla.org/showdependencygraph.cgi?id=378918
56. https://wiki.mozilla.org/BMO/UserGuide/BugFields#regresses
57. https://wiki.mozilla.org/BMO/UserGuide/BugFields#regressed_by
58. https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_file_loc
59. https://wiki.mozilla.org/BMO/UserGuide/BugFields#see_also
60. https://wiki.mozilla.org/BMO/UserGuide/BugFields#alias
61. https://bugzilla.mozilla.org/describekeywords.cgi
62. https://wiki.mozilla.org/BMO/UserGuide/Whiteboard
63. https://wiki.mozilla.org/BMO/UserGuide/BugFields#votes
64. https://bugzilla.mozilla.org/user_profile?user_id=1214
65. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#a25226715_1214
66. https://bugzilla.mozilla.org/user_profile?user_id=1214
67. https://bugzilla.mozilla.org/user_profile?user_id=23402
68. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#a55040742_23402
69. https://bugzilla.mozilla.org/user_profile?user_id=23402
70. https://bugzilla.mozilla.org/user_profile?user_id=23402
71. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#a55040742_23402
72. https://bugzilla.mozilla.org/user_profile?user_id=23402
73. https://bugzilla.mozilla.org/attachment.cgi?id=263085
74. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c12
75. https://bugzilla.mozilla.org/user_profile?user_id=1214
76. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
77. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
78. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
79. https://bugzilla.mozilla.org/attachment.cgi?id=307300
80. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c54
81. https://bugzilla.mozilla.org/user_profile?user_id=15223
82. https://bugzilla.mozilla.org/attachment.cgi?id=307300&action=edit
83. https://bugzilla.mozilla.org/attachment.cgi?id=307300&action=diff
84. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=307300
85. https://bugzilla.mozilla.org/attachment.cgi?id=308730
86. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c57
87. https://bugzilla.mozilla.org/user_profile?user_id=50763
88. https://bugzilla.mozilla.org/attachment.cgi?id=308730&action=edit
89. https://bugzilla.mozilla.org/attachment.cgi?id=308730&action=diff
90. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=308730
91. https://bugzilla.mozilla.org/attachment.cgi?id=308772
92. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c58
93. https://bugzilla.mozilla.org/user_profile?user_id=50763
94. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=edit
95. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=diff
96. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=308772
97. https://bugzilla.mozilla.org/attachment.cgi?id=312275
98. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c64
99. https://bugzilla.mozilla.org/user_profile?user_id=50763
100. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=edit
101. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=diff
102. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312275
103. https://bugzilla.mozilla.org/attachment.cgi?id=312276
104. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c65
105. https://bugzilla.mozilla.org/user_profile?user_id=50763
106. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=edit
107. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=diff
108. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312276
109. https://bugzilla.mozilla.org/attachment.cgi?id=312906
110. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c67
111. https://bugzilla.mozilla.org/user_profile?user_id=50763
112. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=edit
113. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=diff
114. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312906
115. https://bugzilla.mozilla.org/attachment.cgi?id=325543
116. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c68
117. https://bugzilla.mozilla.org/user_profile?user_id=50763
118. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c69
119. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
120. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=diff
121. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=325543
122. https://bugzilla.mozilla.org/attachment.cgi?id=326472
123. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c70
124. https://bugzilla.mozilla.org/user_profile?user_id=50763
125. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c70
126. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=edit
127. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=diff
128. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=326472
129. https://bugzilla.mozilla.org/attachment.cgi?id=339961
130. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c73
131. https://bugzilla.mozilla.org/user_profile?user_id=50763
132. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918#c73
133. https://bugzilla.mozilla.org/attachment.cgi?id=339961&action=edit
134. https://bugzilla.mozilla.org/attachment.cgi?id=339961&action=diff
135. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=339961
136. https://bugzilla.mozilla.org/user_profile?user_id=212318
137. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c0
138. https://bugzilla.mozilla.org/user_profile?user_id=1214
139. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c1
140. https://bugzilla.mozilla.org/user_profile?user_id=212318
141. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c2
142. https://bugzilla.mozilla.org/user_profile?user_id=212318
143. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c3
144. https://bugzilla.mozilla.org/user_profile?user_id=212318
145. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c4
146. https://bugzilla.mozilla.org/user_profile?user_id=1214
147. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c5
148. https://bugzilla.mozilla.org/user_profile?user_id=212318
149. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c6
150. https://bugzilla.mozilla.org/user_profile?user_id=212318
151. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c7
152. https://bugzilla.mozilla.org/user_profile?user_id=1214
153. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c8
154. https://bugzilla.mozilla.org/user_profile?user_id=212318
155. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c9
156. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c3
157. https://bugzilla.mozilla.org/user_profile?user_id=212318
158. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c10
159. https://bugzilla.mozilla.org/user_profile?user_id=1214
160. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c11
161. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c10
162. https://bugzilla.mozilla.org/user_profile?user_id=1214
163. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c12
164. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
165. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
166. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
167. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
168. https://bugzilla.mozilla.org/user_profile?user_id=50763
169. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c13
170. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c12
171. https://bugzilla.mozilla.org/user_profile?user_id=1214
172. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c14
173. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c13
174. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c12
175. https://bugzilla.mozilla.org/user_profile?user_id=50763
176. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c15
177. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c14
178. https://bugzilla.mozilla.org/user_profile?user_id=253737
179. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a248686_253737
180. https://bugzilla.mozilla.org/show_bug.cgi?id=365048
181. https://bugzilla.mozilla.org/user_profile?user_id=1214
182. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c16
183. https://bugzilla.mozilla.org/user_profile?user_id=50763
184. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c17
185. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c16
186. https://bugzilla.mozilla.org/user_profile?user_id=1214
187. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c18
188. https://bugzilla.mozilla.org/user_profile?user_id=212318
189. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c19
190. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c5
191. https://bugzilla.mozilla.org/user_profile?user_id=15223
192. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c20
193. https://bugzilla.mozilla.org/attachment.cgi?id=263085
194. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
195. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
196. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
197. https://bugzilla.mozilla.org/user_profile?user_id=15223
198. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c21
199. https://bugzilla.mozilla.org/attachment.cgi?id=263085
200. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
201. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
202. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
203. https://bugzilla.mozilla.org/user_profile?user_id=50763
204. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c22
205. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c20
206. https://bugzilla.mozilla.org/attachment.cgi?id=263085
207. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
208. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
209. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
210. https://bugzilla.mozilla.org/user_profile?user_id=15223
211. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c23
212. https://bugzilla.mozilla.org/user_profile?user_id=253737
213. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c24
214. https://bugzilla.mozilla.org/show_bug.cgi?id=404879
215. https://bugzilla.mozilla.org/user_profile?user_id=212318
216. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c25
217. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c23
218. https://bugzilla.mozilla.org/user_profile?user_id=1214
219. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c26
220. https://bugzilla.mozilla.org/attachment.cgi?id=263085
221. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
222. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
223. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
224. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
225. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
226. https://bugzilla.mozilla.org/user_profile?user_id=50763
227. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c27
228. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c26
229. https://bugzilla.mozilla.org/attachment.cgi?id=263085
230. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
231. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
232. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
233. https://bugzilla.mozilla.org/user_profile?user_id=1214
234. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a25226715_1214
235. https://bugzilla.mozilla.org/user_profile?user_id=1214
236. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c28
237. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c27
238. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c26
239. https://bugzilla.mozilla.org/attachment.cgi?id=263085
240. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=edit
241. https://bugzilla.mozilla.org/attachment.cgi?id=263085&action=diff
242. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=263085
243. https://bugzilla.mozilla.org/user_profile?user_id=212318
244. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c29
245. https://bugzilla.mozilla.org/user_profile?user_id=50763
246. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c30
247. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c27
248. https://bugzilla.mozilla.org/user_profile?user_id=50763
249. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c31
250. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c30
251. https://bugzilla.mozilla.org/user_profile?user_id=1214
252. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c32
253. https://bugzilla.mozilla.org/user_profile?user_id=1214
254. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c33
255. https://bugzilla.mozilla.org/user_profile?user_id=1214
256. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c34
257. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c32
258. https://bugzilla.mozilla.org/user_profile?user_id=1214
259. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c35
260. https://bugzilla.mozilla.org/user_profile?user_id=50763
261. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c36
262. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c29
263. https://bugzilla.mozilla.org/user_profile?user_id=1214
264. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c37
265. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c36
266. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c29
267. https://bugzilla.mozilla.org/user_profile?user_id=50763
268. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c38
269. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c32
270. https://bugzilla.mozilla.org/user_profile?user_id=50763
271. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c39
272. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c37
273. https://bugzilla.mozilla.org/user_profile?user_id=212318
274. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c40
275. https://bugzilla.mozilla.org/user_profile?user_id=212318
276. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c41
277. https://bugzilla.mozilla.org/user_profile?user_id=1214
278. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c42
279. https://bugzilla.mozilla.org/user_profile?user_id=1214
280. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c43
281. https://bugzilla.mozilla.org/user_profile?user_id=212318
282. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c44
283. https://bugzilla.mozilla.org/user_profile?user_id=1214
284. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c45
285. https://bugzilla.mozilla.org/user_profile?user_id=212318
286. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c46
287. https://bugzilla.mozilla.org/user_profile?user_id=1214
288. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c47
289. https://bugzilla.mozilla.org/user_profile?user_id=1214
290. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c48
291. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c47
292. http://lxr.mozilla.org/mozilla/source/js/src/jsapi.h#2130
293. https://bugzilla.mozilla.org/user_profile?user_id=212318
294. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c49
295. https://bugzilla.mozilla.org/user_profile?user_id=1214
296. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c50
297. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c49
298. https://bugzilla.mozilla.org/user_profile?user_id=1214
299. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c51
300. https://bugzilla.mozilla.org/user_profile?user_id=212318
301. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c52
302. https://bugzilla.mozilla.org/user_profile?user_id=1214
303. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c53
304. https://bugzilla.mozilla.org/user_profile?user_id=15223
305. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c54
306. https://bugzilla.mozilla.org/attachment.cgi?id=307300&action=diff
307. https://bugzilla.mozilla.org/attachment.cgi?id=307300&action=edit
308. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=307300
309. https://bugzilla.mozilla.org/user_profile?user_id=1214
310. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c55
311. https://bugzilla.mozilla.org/user_profile?user_id=15223
312. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c56
313. https://bugzilla.mozilla.org/user_profile?user_id=50763
314. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c57
315. https://bugzilla.mozilla.org/attachment.cgi?id=308730&action=diff
316. https://bugzilla.mozilla.org/attachment.cgi?id=308730&action=edit
317. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=308730
318. https://bugzilla.mozilla.org/user_profile?user_id=50763
319. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c58
320. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=diff
321. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=edit
322. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=308772
323. https://bugzilla.mozilla.org/attachment.cgi?id=308730&action=edit
324. https://bugzilla.mozilla.org/user_profile?user_id=212318
325. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c59
326. https://bugzilla.mozilla.org/user_profile?user_id=50763
327. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c60
328. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c59
329. https://bugzilla.mozilla.org/user_profile?user_id=253737
330. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c61
331. https://bugzilla.mozilla.org/user_profile?user_id=15223
332. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c62
333. https://bugzilla.mozilla.org/attachment.cgi?id=308772
334. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=edit
335. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=diff
336. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=308772
337. https://bugzilla.mozilla.org/user_profile?user_id=50763
338. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c63
339. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c61
340. https://bugzilla.mozilla.org/user_profile?user_id=50763
341. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c64
342. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=diff
343. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=edit
344. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312275
345. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c62
346. https://bugzilla.mozilla.org/attachment.cgi?id=308772&action=edit
347. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=edit
348. https://bugzilla.mozilla.org/user_profile?user_id=50763
349. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c65
350. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=diff
351. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=edit
352. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312276
353. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=edit
354. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=edit
355. https://bugzilla.mozilla.org/attachment.cgi?id=312275&action=edit
356. https://bugzilla.mozilla.org/user_profile?user_id=15223
357. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c66
358. https://bugzilla.mozilla.org/user_profile?user_id=50763
359. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c67
360. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=diff
361. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=edit
362. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=312906
363. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=edit
364. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=edit
365. https://bugzilla.mozilla.org/attachment.cgi?id=312276&action=edit
366. https://bugzilla.mozilla.org/user_profile?user_id=15223
367. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a29552730_15223
368. https://bugzilla.mozilla.org/show_bug.cgi?id=426529
369. https://bugzilla.mozilla.org/user_profile?user_id=1214
370. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a30458050_1214
371. https://bugzilla.mozilla.org/show_bug.cgi?id=428420
372. https://bugzilla.mozilla.org/user_profile?user_id=50763
373. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a35064509_50763
374. https://bugzilla.mozilla.org/show_bug.cgi?id=437325
375. https://bugzilla.mozilla.org/user_profile?user_id=50763
376. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a35069795_50763
377. https://bugzilla.mozilla.org/show_bug.cgi?id=437325
378. https://bugzilla.mozilla.org/user_profile?user_id=50763
379. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c68
380. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=diff
381. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
382. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=325543
383. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=edit
384. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
385. https://bugzilla.mozilla.org/attachment.cgi?id=312906&action=edit
386. https://bugzilla.mozilla.org/user_profile?user_id=23402
387. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a36605786_23402
388. https://bugzilla.mozilla.org/show_bug.cgi?id=428420
389. https://bugzilla.mozilla.org/user_profile?user_id=23402
390. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a36606103_23402
391. https://bugzilla.mozilla.org/show_bug.cgi?id=380236
392. https://bugzilla.mozilla.org/user_profile?user_id=23402
393. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a36630431_23402
394. https://bugzilla.mozilla.org/show_bug.cgi?id=380236
395. https://bugzilla.mozilla.org/user_profile?user_id=23402
396. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a36630489_23402
397. https://bugzilla.mozilla.org/show_bug.cgi?id=428420
398. https://bugzilla.mozilla.org/user_profile?user_id=1214
399. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c69
400. https://bugzilla.mozilla.org/attachment.cgi?id=325543
401. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
402. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=diff
403. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=325543
404. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
405. https://bugzilla.mozilla.org/user_profile?user_id=50763
406. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c70
407. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=diff
408. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=edit
409. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=326472
410. https://bugzilla.mozilla.org/attachment.cgi?id=325543&action=edit
411. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=edit
412. https://bugzilla.mozilla.org/user_profile?user_id=50763
413. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c71
414. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c70
415. mailto:igor@mir2.org
416. https://bugzilla.mozilla.org/show_bug.cgi?id=378918
417. https://bugzilla.mozilla.org/user_profile?user_id=50763
418. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c72
419. mailto:igor@mir2.org
420. https://bugzilla.mozilla.org/show_bug.cgi?id=378918
421. https://bugzilla.mozilla.org/user_profile?user_id=50763
422. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c73
423. https://bugzilla.mozilla.org/attachment.cgi?id=339961&action=diff
424. https://bugzilla.mozilla.org/attachment.cgi?id=339961&action=edit
425. https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=378918&attachment=339961
426. https://bugzilla.mozilla.org/attachment.cgi?id=326472&action=edit
427. https://bugzilla.mozilla.org/attachment.cgi?id=339961&action=edit
428. https://bugzilla.mozilla.org/user_profile?user_id=50763
429. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c74
430. http://hg.mozilla.org/mozilla-central/rev/5aaa5bcc6024
431. https://bugzilla.mozilla.org/user_profile?user_id=23402
432. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#a55040742_23402
433. https://bugzilla.mozilla.org/user_profile?user_id=297688
434. https://bugzilla.mozilla.org/show_bug.cgi?id=378918#c75
435. https://bugzilla.mozilla.org/show_bug.cgi?id=378918&GoAheadAndLogIn=1
436. https://bugzilla.mozilla.org/user_profile?user_id=1214
Hidden links:
438. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918
439. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918
440. https://bugzilla.mozilla.org:443/show_bug.cgi?id=378918
Usage: http://www.kk-software.de/kklynxview/get/URL
e.g. http://www.kk-software.de/kklynxview/get/http://www.kk-software.de
Errormessages are in German, sorry ;-)