I've just found that Dromaeo jslib-modify-jquery crashes with ToT. And I checked that this does not crashes on STP 30.
Bisected by using WebKit Nightly Archive. https://trac.webkit.org/log/webkit/?stop_rev=216759&rev=216778
Since the process is killed by SIGKILL, I guess this is caused by r216772.
Oh that's pretty nasty. Do you know why that test grows so huge? Are we not GC'ing often/aggressively enough? Tip: If you run Safari with the "resource usage overlay" enabled (from the internal Debug menu), you can see when the next scheduled eden and full collections are going to happen. It sounds strange that this test should have to exceed 4GB footprint, no? I would think that the objects created for each iteration would be transient.
Or hmm, looking at the test, IIUC it measures jQuery performance by creating this fragment: <strong>some text</strong> ...and inserting as many of them as possible into the document in a certain time. This kind of test is indeed going to hit our memory limits now that they are down to 4GB, since computers (and WebKit!) are too damn fast. :|
(In reply to Andreas Kling from comment #4) > Or hmm, looking at the test, IIUC it measures jQuery performance by creating > this fragment: > > <strong>some text</strong> > > ...and inserting as many of them as possible into the document in a certain > time. This kind of test is indeed going to hit our memory limits now that > they are down to 4GB, since computers (and WebKit!) are too damn fast. :| Yeah, I've just checked it with resource overlay and seen that bmalloc memory becomes huge while GC heap is still ~300MB.
(In reply to Yusuke Suzuki from comment #5) > (In reply to Andreas Kling from comment #4) > > Or hmm, looking at the test, IIUC it measures jQuery performance by creating > > this fragment: > > > > <strong>some text</strong> > > > > ...and inserting as many of them as possible into the document in a certain > > time. This kind of test is indeed going to hit our memory limits now that > > they are down to 4GB, since computers (and WebKit!) are too damn fast. :| > > Yeah, I've just checked it with resource overlay and seen that bmalloc > memory becomes huge while GC heap is still ~300MB. Most of that bmalloc memory is very likely a bajillion DOM nodes (<strong> elements and Text nodes), I bet. They probably all have a JS DOM wrapper each, but even if we could GC those we'd only recover the wrapper memory, since the nodes are still physically inserted in the DOM. I'm unsure what the right solution would be here. I mean, if we raise the limit, there will still come a day when we get so fast at creating and inserting DOM nodes, that we exceed the new limit :) +CC Geoff and Michael for thoughts
This stinks. Is Dromaeo still maintained? Maybe we can report this as a bug, and suggest a change to the test to insert a fixed number of nodes and time the action, as opposed to inserting a fixed amount of time and counting the nodes.
(In reply to Geoffrey Garen from comment #7) > This stinks. Is Dromaeo still maintained? Maybe we can report this as a bug, > and suggest a change to the test to insert a fixed number of nodes and time > the action, as opposed to inserting a fixed amount of time and counting the > nodes. Related issue is found. https://bugzilla.mozilla.org/show_bug.cgi?id=1279035