-
Waldo
mm, yeah
-
Waldo
I think I am going to split this puppy up
-
Waldo
...tomorrow
-
sfink
unfortunate metaphor
-
pbone
good morning.
-
pbone
sfink: pfft. After my friend turned the 3-colour GC abstraction into a race thing, plus all the "evicting the nursery" etc metaphors we have I'm not sure puppy-slicing is all that bad.
-
sfink
well, ok, I cannot deny your points
-
pbone
I think we can agree there are many many unfortunate metaphors here.
-
sfink
yes, I guess when we're depending on high infant mortality for things to work well, we can't exactly take the high road
-
pbone
that's the one.. yes.
-
Waldo
doubtful anything will ever beat
quotes.burntelectrons.org/4823
-
» pbone usually doesn't spell it out.. not since he said it in a presentation to 100s of people.
-
Waldo
aaaaaaaaaaaanyway
-
Waldo
later all
-
pbone
Doh, forgot to "moz-phab submit" yesterday.
-
sdetar
pbone: 1:1?
-
pbone
Oh.
-
pbone
damn. forgetting all my meetings.
-
pbone
sdetar: I'm joining now.
-
pbone
confession: Landing
Bug 1569840
-
confession
-
firebot
bugzil.la/1569840 — ASSIGNED, pbone⊙mc — Add a gcNurseryBytes runtime parameter
-
pbone
sfink: Regarding your PTO, I already put you as a reviewer for something. If you don't have time feel free to re-assign it.
-
pbone
jandem: regarding
Bug 1568410
-
firebot
bugzil.la/1568410 — ASSIGNED, pbone⊙mc — Make JS_DestroyContext to call Mutex::ShutDown()
-
pbone
jandem: is calling this in JS_DestroyContext() safe?
-
pbone
or do the helper threads need this to stay in their Main function.
-
pbone
We were trying to move it to avoid repeating that for each thread's main function.
-
pbone
jandem: Oh sorry, I thought your comment happend in the last few minutes, so assumed you were awake.
-
jandem
pbone: posted a suggestion in phabricator. Curious what you think
-
jandem
wingo: ping; not sure if you get phabricator email still but I requested review on a BigInt patch a few days ago :)
-
wingo
jandem: hi! tx for ping, i was out of office and just got back today
-
wingo
i'll have a look :)
-
jandem
wingo: ah, no rush, thanks
-
pbone
jandem: okay thanks. I might take a look tonight. If not Monday. Thursday & Friday are PTO.
-
jandem
pbone: sounds good. Enjoy your PTO
-
jandem
jonco: ping
-
jonco
jandem: hey
-
jandem
jonco: hey. When we have a shutdown gc leak, do we still end up releasing those pages eventually or are they leaked too?
-
jonco
jandem: good question, I think we still release the pages
-
jandem
jonco: trying to decide what's the sanest thing to do for
bug 1569655. I could force release those pools in debug builds to prevent more assertion failures later on in the process-wide allocator...
-
firebot
bugzil.la/1569655 — NEW, nobody⊙mo — Don't crash debug Firefox builds when we're leaking ExecutablePool
-
jandem
alternative is to add a process wide "leaked some runtime" flag
-
jonco
yes we do free the pages
-
jonco
jandem: I was looking at this a while ago
-
jandem
the advantage there is that we can assert it's false in the shell, which is nice
-
jonco
jandem: I was going to indicate to the leak checker that GC things leaked, and finalize them anyway
-
jonco
which would make all our shutdown assertions pass even if there was a leak
-
jandem
jonco: if we could finalize them anyway that would be really nice. These things are pretty annoying for sanity check asserts
-
jonco
yes, this bothers me too
-
jonco
-
firebot
bugzil.la/1407593 — NEW, jcoppeard⊙mc — Embedding leaks make it harder to assert shutdown correctness
-
jonco
I guess I'll try and look at that again
-
jandem
jonco: nice, it already has a patch. Do you think it's a matter of rebasing it or were there other issues? If the former maybe i should wait for that instead of doing anything about
bug 1569655
-
jonco
it was more work that than, however I think it's the best way forward for this problem
-
jonco
I can take a look this afternoon
-
jandem
great, thanks!
-
wingo
is there a way to make the js shell wait until a promise is resolved, before exiting?
-
jonco
-
firebot
bugzil.la/1501154 — FIXED, jcoppeard⊙mc — Assertion failure: throwing, at js/src/vm/JSContext.cpp:1449
-
wingo
jonco: tx for the link
-
wingo
that will probably work
-
jonco
np
-
arai
jonco: review ping for
bug 1562102
-
firebot
Bug
bugzil.la/1562102 is not accessible
-
jonco
arai: sorry, this didn't show up in my review queue
-
jonco
I'll have a look
-
jonco
arai: LGTM
-
arai
thanks!
-
jonco
arai: if I understand what's happening here, we usually allow creation of Handles of base types like this, horrible though it is:
searchfox.org/mozilla-central/source/js/public/RootingAPI.h#1211-1218
-
Waldo
the memory allocator bug is
bug 1546442
-
firebot
bugzil.la/1546442 — REOPENED, gpascutto⊙mc — Leading guard pages for normal allocations
-
smaug
denispal: (and jonco) I wonder is ScriptLoader could use
searchfox.org/mozilla-central/source/js/src/gc/GCRuntime.h#357 for now
-
jonco
JS::IsIncrementalGCInProgress would be the public API for this
-
smaug
ah, thanks
-
smaug
jonco: ... just to not do offthemainthread stuff for now if we have GC running
-
jonco
smaug: is this
bug 1501608?
-
firebot
bugzil.la/1501608 — NEW, dpalmeiro⊙mc — Investigate reducing size of ScriptSourceObject by moving DOM related fields outside the engine
-
smaug
jonco: just a way to improve situation a bit before
bugzilla.mozilla.org/1543806 gets fixed
-
firebot
Bug 1543806 — NEW, mgaudet⊙mc — Incremental GC can block off-thread parsing
-
jorendorff
baseline interpreter not translating to mobile seems impossible
-
jorendorff
what
-
jonco
smaug: we only need to avoid this if we're collecting the atoms zone
-
smaug
jonco: aha. Is there an API to check that already?
-
jonco
smaug: denispal: the best place to try this is to change CanDoOffThread to always return false if OffThreadParsingMustWaitForGC here
searchfox.org/mozilla-central/sourc…ffThreadScriptCompilation.cpp#48-61
-
smaug
right
-
smaug
add some small tweak there to return false if we're collecting atoms zone
-
jonco
smaug: the good news is that mgaudet is working on
bug 1544117 which will fix this problem
-
firebot
bugzil.la/1544117 — NEW, nobody⊙mo — [meta] Parse JS without allocating on the GC
-
smaug
sure sure, this change would be just a small tweak before that all lands
-
smaug
(mentioned during JS perf meeting)
-
jonco
ok cool
-
smaug
-
jonco
smaug: we do that, but we still allow off-thread compilation for large scripts
-
jonco
smaug: I don't know if we ever tested what a suitable definition of 'large' was
-
Waldo
this |this|-in-derived-constructors perf thing looks kind of silly
-
jonco
smaug: anyway, it makes sense to disallow this for all scripts and see what happens
-
smaug
oops, I wasn't reading all of CanDoOffThread :)
-
smaug
jonco: yup
-
smaug
thanks
-
Waldo
this is really basically identical to the problem of TDZ checks for lexical bindings, and we eliminate a lot of those via strict-domination checks
-
Waldo
seems like we should be able to fit |this| into that framework somehow without insane difficulty
-
Waldo
and just treat super() as doing the same thing as evaluating a lexical declaration does, in terms of disabling subsequent TDZ checks of the binding
-
jorendorff
Waldo: agree
-
smaug
jonco: and silly me, I apparently have pushed
try/bc3d5ce21c69c5a270d488d1dbe8c37ae62337b6 once to tryserver
-
jonco
heh
-
denispal
smaug: did you see any improvements?
-
smaug
denispal: looks like I have lost the data
-
smaug
I'm just pushing that again
-
denispal
smaug: ah ok
-
denispal
jonco: ping. I am hitting one issue with the CC in
bug 1501608, was wondering if you maybe had an idea of what may be going wrong
-
firebot
bugzil.la/1501608 — NEW, dpalmeiro⊙mc — Investigate reducing size of ScriptSourceObject by moving DOM related fields outside the engine
-
denispal
jonco: when I create a LoadedScript in the EventListenerManager and then later use the callback to get the element from it, the CC has removed the mFetchOptions element and set it to null
-
denispal
seems to only reproduce on the try server for 1-2 tests, but not sure if I'm maybe doing something wrong. we do call HostAddRefTopLevelScript() on the LoadedScript, but is there something stronger I would need?
-
jonco
denispal: is the LoadedScript being freed then?
-
jonco
HostAddRefTopLevelScript should keep it alive
-
denispal
jonco: It doesn't seem like HostReleaseTopLevelScript is ever called for those scripts, so I wonder if it's being freed somewhere else?
-
denispal
not up to the crash at least
-
jonco
denispal: the patch looks fine
-
smaug
jonco: FWIW, I didn't quite understand memory management in general
-
smaug
is it not possible to have cycle SSO -> LoadedScript ->... something something ... SSO
-
jonco
smaug: the cycle collector knows about the SSO -> LoadedScript edge and can collect those cycles
-
smaug
ok, great. I just didn't see where that is handled
-
tcampbell
Waldo: yeah, that makes sense
-
jonco
-
smaug
aha
-
smaug
thanks
-
smaug
I was looking for JSCLASS_PRIVATE_IS_NSISUPPORTS usage or such
-
jonco
smaug: it wasn't possible to reuse that for this case unfortunately
-
jonco
there's a bug on file to clean this up
-
smaug
yeah
-
jonco
denispal: I take it ScriptSourceObject::setPrivate is getting called and calling the AddRef hook?
-
jonco
denispal: it seems strange that this would get collected…
-
denispal
jonco: yeah I did check that AddRef is being called
-
jonco
cool
-
denispal
very bizarre, I can't reproduce it on any machine locally
-
denispal
only on try, and very consistently
-
denispal
I will keep hacking away at it though, should figure it out eventually
-
jonco
ugh, annoying
-
mgaudet
denispal: what platform?
-
denispal
mgaudet: It's pretty consistent on Windows, and 70% reproducible on Linux
-
mgaudet
denispal: You should email b.holley, and get pernosco access -- this sounds like a case right up its alley
-
denispal
mgaudet: I did :) Although it doesn't seem like pernosco can reproduce it either
-
mgaudet
denispal: Darn
-
denispal
it sends me emails about other intermittent failures, but never these specific tests unfortunately
-
mgaudet
:(
-
Waldo
mrgiggles: pun
-
mrgiggles
Waldo: Some Spanish government employees are Seville servants.
-
» Waldo mutters
-
Waldo
paging in the parser and frontend and name analysis and how names get declared and used, what fun
-
tcampbell
sfink: ping?
-
tcampbell
how does AutoKeepAtoms actually work when you release it
-
tcampbell
like, we use it the frontend before we start handing around naked JSAtom pointers, but those get stored in GC thing
-
tcampbell
presumably we can release the AutoKeepAtoms during an incremental-gc
-
jonco
tcampbell: it only does anything when it's live
-
jonco
(sfink is on PTO I think)
-
tcampbell
so there needs to be a final markAtoms before releasing it?
-
jonco
tcampbell: no
-
tcampbell
Is this where traceKeptAtoms kicks in?
-
jonco
tcampbell: all the atoms you've have must be written into GC things before AKA dies
-
jonco
tcampbell: that is called during root marking
-
jonco
atoms that are created after root marking during an incremental GC will end up marked automatically, by the normal rules for an incremental GC
-
tcampbell
... starting to make sense
-
jonco
the problem is only when we mark the roots and don't know which atoms the parser has live in the parse tree
-
tcampbell
so the atomCache are the roots for that case?
-
tcampbell
while the ASA is live
-
jonco
yes we mark everything in the zone's atom cache in this case
-
tcampbell
cool. The source of my questions is that we want to call Handle::fromMarkedLocation on a JSAtom* generated in parser while both are under ASA
-
tcampbell
*both the atomization and the fromMarkedLocation are under ASA
-
tcampbell
I *think* that is all fine
-
jonco
please avoid fromMarkedLocation if at all possible
-
jonco
yes, this sounds like it's fine
-
tcampbell
the future is that we will eventually make parser atoms different than JSAtom
-
tcampbell
which will get rid of the whole ASA mess entirely
-
jonco
that would be great
-
jonco
in the mean time is it possible to root the atom?
-
tcampbell
jonco: see:
phabricator.services.mozilla.com/D39771 the 'FunctionCreationData'
-
jonco
(I guess not or you wouldn't ask, but…)
-
tcampbell
were just trying to avoid having to trace and root the temporary now
-
tcampbell
let me look at how exactly it is used at the end of patch series
-
tcampbell
jonco: is a Handle<T*> any slower than a T* for non-gc types?
-
tcampbell
(A Handle<Cell*> is a Cell**, right?)
-
jonco
tcampbell: yeah Handle<T> is basically T*
-
tcampbell
ah right
-
tcampbell
okay, I'm tempted to use the fromMarkedLocation for the first landing, but try and make it rooted pretty soon
-
tcampbell
lots of moving pieces to juggle =\
-
jonco
can you enforce that you are always under AutoKeepAtoms somehow?
-
tcampbell
assert immediately before it
-
tcampbell
can make it a diagnostic assert even
-
jonco
the use of 'fromMarkedLocation' when it's used on a location that is not marked explicitly kind of grates…
-
tcampbell
hmm
-
jonco
tcampbell: also assert in the struct's destructor to check it doesn't get released?
-
tcampbell
at that point I need to plumb in the cx stuff and should just fix the root immediately
-
jonco
use TLS in the assert?
-
tcampbell
interesting
-
tcampbell
let me redownload the stack and look at what just fixing the rooting will do to the stack
-
tcampbell
jonco: so I should use a HeapPtr<JSAtom>?
-
jonco
tcampbell: this is heap allocated, right? if you're going to trace it as a root then JSAtom* is fine
-
tcampbell
eventually heap allocated and rooted in the Parser
-
tcampbell
okay, will do
-
jonco
great
-
tcampbell
that mostly avoids the cx then
-
jonco
yep
-
jonco
feel free to tag me for review if you like
-
tcampbell
jonco: thanks. I'm going put together a patch in the middle of stack that replaces the fromMutableHandle with tracing and I will flag you.
-
jonco
great, thanks for doing this
-
tcampbell
jonco: so I have a Handle<FunctionCreateData>.. to get a HandleAtom out of the jsatom* field, I still need frommarkedlocation, correct?
-
jonco
tcampbell: yes (but it will really be from a marked location now)
-
tcampbell
mgaudet: let me know when you have some time to go through this stack again
-
mgaudet
tcampbell: I'm just working through feedback as we speak; so, anytime now.
-
tcampbell
mgaudet: can we do a call in 5 min?
-
mgaudet
Sure; gives me just enough time to sneak up and make a coffee
-
tcampbell
:)
-
mgaudet
tcampbell: will ping on return
-
mgaudet
tcampbell: just tell me where :)
-
mgaudet
tcampbell: Just an IRC review of the hasGuessedAtomChange to make sure I'm reading it right:
-
mgaudet
-
» Waldo mutters
-
tcampbell
mgaudet: yeah, that looks right
-
mgaudet
tcampbell: thanks for gut check.
-
Waldo
mrgiggles: pun
-
mrgiggles
Waldo: I used to be a tap dancer until I fell in the sink.
-
elexis
hello everyone!
-
elexis
I'm one of the 0ad developers, the game uses SpiderMonkey. As such I ended up wondering whether JS::PersistentRooted is more, less or equal performant to JS::Heap (assuming that the object has a long lifetime)?
-
elexis
JS::PersistentRooted leaves much cleaner code, so it seems that would be preferable
pastebin.com/hz2J9wyz
-
elexis
there are a bunch of JSObjects created each time the user opens a GUI page, and opening / closing GUI pages happens rarely, so the only performance relevant part would be the GC treatment
-
tcampbell
-
tcampbell
the biggest risk of persistentrooted is usually memory leaks
-
elexis
we had that problem too (one array with many JS objects vs one JS object with many items)
-
elexis
if no JS object owns a C++ object, there can't be a leak, right?
-
tcampbell
yep
-
tcampbell
(I think)
-
elexis
great!
-
tcampbell
the persistentrooted moves means the GC takes longer for the root-marking stage, rather than spreading over incremental slices
-
mgaudet
tcampbell: Like a dummy I just queued the first four patches for landing before actually making the FunctionBoxVector change; I'll get you a follow up patch for that right now.
-
tcampbell
mgaudet: lol.. I just noticed that
-
mgaudet
tcampbell: autoland being closed makes me wish there was an "oops" button on lando
-
tcampbell
elexis: my general advice would be that avoiding the persistentrooted forces you to be a bit more disciplined about GC tracing
-
elexis
right now by design no JS object owns a C++ object, so leaks arent of concern
-
elexis
so I wonder why we want this Tracer code to begin with if we could use a PersistentRooted
-
elexis
unless there is a performance reason
-
tcampbell
if you have many objects, then a single Rooted<Foo> with an array of JS objects will be much faster than an array of PersistentRooted
-
elexis
the situation is basically as follow: user clicks on a button -> GUI page opens -> maybe 100 GUI objects are created -> each GUI object is represented by one JS object -> user closes page -> JS objects deleted
-
elexis
GUI Page stores GUI Objects (button, dropdown, text, ...), each GUI Object is a C++ class that owns one JS object, so can't really change that to be only one JS object without entering dangerous territory
-
elexis
so the question is only: Is one JS::Heap object faster to keep track of for the GC than one JS::PersistentRooted object
-
elexis
(not considering allocation and deallocation)
-
tcampbell
marginally
-
tcampbell
elexis: I'm skimming the code. What the the name of an example GUI type?
-
tcampbell
oh, I see your pastebin
-
elexis
every GUI object type inherits the IGUIObject class, which keeps track of all of that
-
elexis
-
elexis
user opens a GUI page -> JS object is created -> 30 seconds pass -> user closes page
-
elexis
so the few microseconds upon opening / closing the page is not so relevant, more what happens during the 30 seconds
-
tcampbell
ah, so for that lifetime, the GCs will be marginally slower (but not really noticeable if you have ~100 objects)
-
elexis
I suppose there are < 500 objects tops on the ingame GUI page
-
tcampbell
PersistentRooted is definitely an improvement over JS_RemoveExtraGCRootsTracer
-
elexis
depending on whether theres a significant performance difference, it'd be the recommended default for future patches, and the codebase would probably be changed for one or the other
-
elexis
the code definitely looks nicer with PersistentRooted
-
tcampbell
so the idea of using Heap over PersistentRooted, is that you would have a single PersistentRooted for the top-level, and then your GUI would know have to traverse the tree
-
tcampbell
and then trace the Heap that hang off each GUI node
-
tcampbell
if there isn't already a GUI tree relation, that might be ackward though
-
tcampbell
*awkward
-
elexis
there is a tree, but it's C++
-
tcampbell
that is fine
-
tcampbell
the trace methods are written in C++ in your code
-
tcampbell
-
tcampbell
that is the recommended pattern that spidermonkey and gecko try to follow
-
tcampbell
mgaudet: just stack another patch for the rename FunctionBoxVector and I can stamp it
-
mgaudet
tcampbell: working on it -- took a couple extra minutes while I puzzled through what I wanted to do with the existing FunctionBoxVector type :P
-
tcampbell
ah, got it
-
tcampbell
hmm.. I didn't realize that existed
-
mgaudet
tcampbell: Neither did I
-
mgaudet
so I sunk it to its use, (nice for shortening the dependent declaration, but doesn't need huge scope like it has)
-
mgaudet
and have declared our function box type near AtomVector
-
tcampbell
nice
-
tcampbell
elexis: do you happen to know what version of spidermonkey the codebase is on?
-
elexis
38, but we're working on it :->
-
tcampbell
cool
-
elexis
(45 patch for review, 52 in some branch, and we wont stop there by the looks of things)
-
mgaudet
\o/
-
tcampbell
nice
-
elexis
performance improvements will be more relevant for the ingame simulation, with thousands of units walking around, each having 10-20 JS objects representing their components
-
elexis
I just wanted to know whether I'm adding a performance regression for the GUI when I change the JS::Heap to JS::PersistentRooted, but if its not signfiicant for < 500 objects that are only rooted / unrooted once every 10ish seconds, then it should be fine
-
elexis
in theory I thought JS::PersistentRooted would be faster, because the GC could always ignore it until its destroyed
-
tcampbell
persistentrooted means the gc has to check it every time during the beginning of a GC, and can't spread it over incremental
-
tcampbell
every edge still needs to be tested during the GC process
-
tcampbell
but the GC can split the work over mutliple slices that interleave with application work
-
elexis
I see
-
elexis
so the same amount of work, just not as well spread
-
tcampbell
elexis: so one example in your pastebin. With m_ScriptHandlers, it would be preferred to have the map contain Heap<T> and then you could have a single PersistentRooted around your this pointer. Then implement the little trace method that looks at the map.
-
tcampbell
that would reduce the number of roots
-
elexis
so only one PeristentRooted globally, hence the GC only has to iterate over one GC thing, but in order to access one of the items, one has to resolve / unwrap that PersistentRooted again, which also adds overhead, doesnt it?
-
elexis
std::map<string, JSObject> could be changed to a JSObject containing the JSObjects however
-
elexis
that might be less complex than introducing a wrapper class
-
elexis
(did I get that right?)
-
elexis
if the trace method is needed, then why add the PersistentRooted pointer
-
elexis
only advantage would be spreading GC workload over multiple slices?
-
elexis
its currently already Heap, so I guess one doesnt need another persistentrooted container
-
gkw
sfink:
bug 1570465 - bisecting now but I think this is yours
-
firebot
Bug
bugzil.la/1570465 is not accessible
-
Waldo
gkw: allegedly he's on PTO, the scoundrel
-
gkw
lol
-
tcampbell
elexis: so one has to start roots somewhere. A few of the ways one can do that are JS::PersistentRooted, using a Rooted<T> on stack, using the (deprecated) JS_RemoveExtraGCRootsTracer
-
tcampbell
generally you want to minimize the number of them and minimize how often they are come and go
-
tcampbell
those roots then point to an arbitrary number of objects in some sort of C++ graph that is your data structures
-
tcampbell
we use Heap<T> (and inside spidermonkey GCPtr which is fast but less safe) to connect up the graph. The GC can then traverse the graph in slices and split up the work and avoid repetition in some cases
-
mgaudet
elexis: (If you haven't seen this,
github.com/spidermonkey-embedders/s…/esr60/docs/GC%20Rooting%20Guide.md, some of the rooting reasoning is covered in there too)
-
mgaudet
tcampbell: I'm feeling slow; if I have a Rooted<FunctionCreationData>, and I pass and |Handle<FnctionCreationData> data|, what magic am I missing to make it so |data.<member>| works without needing to do |data.get().<member>|
-
tcampbell
oh right.. I ran into that :(.. I really hope the answer isn't that we need WrappedPtrOperations
-
mgaudet
-
tcampbell
-
tcampbell
=\
-
mgaudet
oh dear.
-
tcampbell
yeah.... bleh
-
tcampbell
I know if you have Rooted<UniquePtr<T>> you get sane behaviour
-
mgaudet
hrm. Heap allocation, or some extra .get() calls?
-
tcampbell
the eternal question
-
tcampbell
I.. don't know =\\
-
mgaudet
I"m leaning get()
-
mgaudet
but we'll see what you say when you see it in-situ
-
tcampbell
That will get() the job done
-
mgaudet
I suppose a third option is to have a const FunctionCreationData& local to the function; which seems even nicer
-
tcampbell
not the worst. We know the FunctionCreationData aint moving
-
elexis
I didn't know one can use JS::Rooted<T> for T that isn't a GC thing but a class that provides a trace method
-
tcampbell
yeah, still only on stack though
-
elexis
but the GC process still has to iterate over everything, it just can spread it better?
-
elexis
only the process of rooting every single item falls away?
-
tcampbell
correct
-
tcampbell
spidermonkey has to worry about keeping memory leaks quite a bit, so we avoid persistentrooted
-
elexis
sure
-
elexis
SM has to work with all applications in all circumstances
-
elexis
i.e. under the highest workload too
-
tcampbell
there is a minor thing that with one root you cross the library boundary less which is faster
-
tcampbell
there are a bunch of little optimizations that the GC team has done about when we need virtual calls and when we don't. I'm not really sure about the precise tradeoffs
-
mgaudet
confession: Reworking GC management in patch stack. how to root/handle tree is now tomorrow-Matthew's problem.
-
confession
-
mgaudet
confession: Landed preq patches for allocation deferral
-
confession
ok, got it
-
elexis
then the paste is a bad idea because the PersistentRootedObject will consume a little more time (rooting as opposed to not rooting when using heap) - so much time that it would be significant if it was an order of magnitude more objects (5000?), thus setting a bad precedent, even if memory leaks are of no concern
-
elexis
the IGUIObject class could be Rooted, sounds only a little bit like a monster
-
tcampbell
elexis: yeah, I think I'd agree with both of those
-
elexis
(I guess not the CGUI class, since that defines its own JSContext / JSRuntime to operate in)
-
elexis
(which is one instance per GUI page)
-
elexis
thank you a lot for taking the time and nerves to explain that tcampbell!
-
elexis
I will cleanup those classes that have almost not been touched since 2004, and I'll see where it can be taken with new SM technology :->
-
tcampbell
:)
-
tcampbell
mccr8: did we decide if having a NukeNonCCWProxy was a good or bad idea? I'm trying to figure out the state of your patch
-
mccr8
tcampbell: I wrote it!
-
mccr8
tcampbell: it actually turns out to be useful for the Xray waiver issue I was having.
-
tcampbell
ah, cool
-
mccr8
well, I don't need the finalize part of it.
-
mccr8
tcampbell: I got distracted with other stuff for a few days, but I'm back on this again. I'm going to put a patch up with the nuke non CCW thing and the waiver fix in
bug 1570484.
-
firebot
bugzil.la/1570484 — NEW, continuation⊙gc — Nuke Xray waivers for remote outer window proxies
-
tcampbell
that's fine. I was just making sure I wasn't a bottleneck on reviews
-
sstangl
confession: Made a start on threading jumps as part of the relaxation pass.
-
confession