[Webkit-unassigned] [Bug 33178] Segmented SharedBuffer: SharedBuffer doesn't have to be a flat memory block

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33178





--- Comment #7 from Darin Adler <darin at apple.com>  2010-01-04 13:33:26 PST ---
(In reply to comment #6)
> (In reply to comment #3)
> > (From update of attachment 45821 [details] [details])
> > Looks OK. But with no clients using the getSomeData function, it seems like
> > it's scaffolding for some future work and functions like getSomeData are not
> > tested. And this change will make things less efficient until the major clients
> > adopt.
> 
> I have 3 more patches that make all script decoders, jpeg decoder and png
> decoder support decoding from segmented SharedBuffer. Will post them soon.

I think that means that after your work image decoding on Mac OS X, iPhone, and
some other platforms will be less efficient than it is today, because the image
decoder in question is not a script decoder, JPEG decoder, or PNG decoder.

> > Do you know what adding this temporary extra work does to page loading time? I
> > don't want to get stuck with that.
> 
> Probably it's because it doesn't need extra memory copying. But I'm not sure. I
> did the test just because I want to make sure it doesn't slow down desktop
> browsers.

Sorry, I don't understand. This patch will allocate separate segments and then
merge them later, which will make things slower for clients that use it the old
way. That seems like it will make things slower and will require allocating two
copies of everything at one point.

You say "did the test". What test did you do?

> > This patch also changes behavior when running out of memory. The new code will
> > abort when running out of memory, whereas the old code would drop data. I think
> > that probably should be changed in a separate patch rather than as a side
> > effect of this one.
> 
> The current patch calls fastMalloc and I remember fastMalloc calls abort() upon
> OOM already. In the future, the allocation of segments can be done in other
> ways for better performance. We could directly allocate a page of virtual
> memory although I'm not sure if it helps.

Yes, that's just the problem. The old code calls Vector::append, which does not
call abort. There is tryFastMalloc, which does not call abort. You could use
that and keep the semantics the same. Or you could change the semantics if you
think there is a good reason.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.