Add WTF::DiscardableMemory.

Add WTF::DiscardableMemory.

This will allow WTF::Vector to be purgeable (only when the client requested so
at construction).

In order to achieve this, the WTFPlatform interface is added to WTF. This
interface is currently nothing more than an abstract factory used to create
instances of WTF::DiscardableMemory.
When the platform layer is initialized, it injects its implementation of this
interface (which is basically a wrapper around a very small subset of
blink::Platform).

As it has always been the case, DiscardableMemory can be a limited resource on
certain platforms (although it's changing on Android:
https://chromiumcodereview.appspot.com/25293002). It is also expensive to
instantiante (due to the syscall incurred and possibly the amount of layers
that have to be crossed) therefore clients (now possibly in WTF) should use it
carefully.

BUG=323454

[Philippe, 2013-11-26 12:31:02]

Hi guys, what do you think?

[eseidel, 2013-11-26 15:47:11]

I don't recall WTF having other interfaces poking out the bottom of it like
this.  It's historically been a leaf of the dependency chain with layers like
Platform having hooks down into the embedder and relying on both WTF and
Web::Platform.

That said, I believe WTF has had settings in the past, and I could imagine
providing it virtual interfaces.  I've CC'd cevans and tsepez who have both been
working with our allocators in WTF recently.

[Philippe, 2013-11-26 15:54:53]

On 2013/11/26 15:47:11, eseidel wrote:
> I don't recall WTF having other interfaces poking out the bottom of it like
> this.  It's historically been a leaf of the dependency chain with layers like
> Platform having hooks down into the embedder and relying on both WTF and
> Web::Platform.
> 
> That said, I believe WTF has had settings in the past, and I could imagine
> providing it virtual interfaces.  I've CC'd cevans and tsepez who have both
been
> working with our allocators in WTF recently.

Thanks Eric! This looks indeed like a new scenario. I would be happy to consider
another approach if you see one (I don't personally :)). Currently I find it a
bit unfortunate to cross all those layers to end up in Chromium's base/ (at the
cost of an heap allocation/indirection for each layer) but DiscardableMemory
should be used carefully anyway.

[abarth-chromium, 2013-11-26 17:35:00]

What's the use case for Vector to be backed by discardable memory?

Thus far, we've avoided introducing dependencies from WTF to blink::Platform. 
WTF is currently a stand-alone library.  blink_plaform is the lowest-level
target that can see blink::Platform.

If there's a good reason to have a Vector backed by discardable memory, I'd
recommend either using std::vector with a customized allocator trait in
blink_platform or adding the ability to customize Vector's allocator similar to
how std::vector works.

not lgtm

[Philippe, 2013-11-26 17:58:37]

On 2013/11/26 17:35:00, abarth wrote:
> What's the use case for Vector to be backed by discardable memory?
> 
> Thus far, we've avoided introducing dependencies from WTF to blink::Platform. 
> WTF is currently a stand-alone library.  blink_plaform is the lowest-level
> target that can see blink::Platform.
> 
> If there's a good reason to have a Vector backed by discardable memory, I'd
> recommend either using std::vector with a customized allocator trait in
> blink_platform or adding the ability to customize Vector's allocator similar
to
> how std::vector works.
> 
> not lgtm

I would like to make SharedBuffer "natively purgeable" (without incurring the
extra copy that we currently do with PurgeableBuffer (which I would like to
delete then)). More details can be found in
https://docs.google.com/a/google.com/document/d/1-JmqmkmzIf8U_72oo0tZgY5Nccf-....
TL;DR: I have a local prototype that allows SharedBuffer:m_data (holding (dead)
resources) to be systematically made purgeable (unlike the current situation)
which lets the kernel purge a couple of megabytes on techcrunch.com (mobile
site) under memory pressure.

Note that this CL doesn't introduce a *compile-time* dependency (not sure what
you exactly meant) from WTF to blink::Platform though (this would be a layering
violation). The only added dependency is from blink::Platform to the newly added
WTF::WTFPlatform (although blink::Platform already depends on WTF). And the
change is not visible by clients since it's self-contained in
exported/Platform.cpp. This means that WTF can still be built and operate
separately. The only thing is that WTF::WTFPlatform::getInstance() will return
NULL (which is not a problem IMO since creation of discardable memory can
already fail).

What do you think?

[abarth-chromium, 2013-11-26 18:15:50]

On 2013/11/26 17:58:37, Philippe wrote:
> What do you think?

IMHO, you shouldn't change anything about Vector.  Instead, you should do the
work directly in SharedBuffer.  The underlying storage used by shared buffer is
already opaque to clients.  In some cases, clients can extract memory from
SharedBuffer more efficiently if the memory happens to be stored in a Vector
already.  We'll need to think about how we want to handle these cases...

Do you have experiments that show the existing memcpy is bad for performance? 
You doc has a bunch of data about memory usage, but I don't see any data about
why eliminating this memcpy is important.

At a higher level, you should think of WTF a bit like an implementation of the
STL.  Over time, we'd like to replace WTF with STL where performance permits. 
Adding these sorts of dependencies to WTF is just as inappropriate as adding
them to STL and will just make that transition harder.

[Philippe, 2013-11-26 19:09:40]

On 2013/11/26 18:15:50, abarth wrote:
> On 2013/11/26 17:58:37, Philippe wrote:
> > What do you think?
> 
> IMHO, you shouldn't change anything about Vector.  Instead, you should do the
> work directly in SharedBuffer.  The underlying storage used by shared buffer
is
> already opaque to clients.  In some cases, clients can extract memory from
> SharedBuffer more efficiently if the memory happens to be stored in a Vector
> already.  We'll need to think about how we want to handle these cases...
> 
> Do you have experiments that show the existing memcpy is bad for performance? 
> You doc has a bunch of data about memory usage, but I don't see any data about
> why eliminating this memcpy is important.
> 
> At a higher level, you should think of WTF a bit like an implementation of the
> STL.  Over time, we'd like to replace WTF with STL where performance permits. 
> Adding these sorts of dependencies to WTF is just as inappropriate as adding
> them to STL and will just make that transition harder.

Agreed. I initially took this path since I also want(ed) to make StringImpl
purgeable ideally to allow dead JavaScript source files to be purged (the
ScriptResource class steals and decode the raw data contained in
Resource::m_data therefore making SharedBuffer purgeable is not enough). The
memcpy() scared me more in terms of memory peak than CPU usage although I
haven't carefully measured it to be honest. 

My local prototype doesn't fully support (yet) StringImpl purging anyway so it
seems indeed reasonable to have this purging logic directly in SharedBuffer at
least as an initial step. We will see later if it's worth addressing StringImpl
(I did see dead JavaScript source files of several MBytes sticking around
though).

Thanks,
Philippe.

[eseidel, 2013-11-29 20:23:59]

If we need to make specific things like script source purgable, we should just
do so at a higher level. :)  StringImpl and Vector are too low level.

SharedBuffer is a vector-like wrapper which used to wrap NSData on Mac and wraps
other possibly-shared, possibly-purgable memory regions on other platforms.

We also have a ScriptSourceCode wrapper around StringImpl which we could instead
use to wrap something purgable if necessary.

For better or worse, we have to keep the source code around in the DOM for web
compatiblity.  We talked about adding an attribute to <script> to allow it to be
purgeable from the DOM.  Big apps like Gmail would probably want something like
that.

[Philippe, 2013-12-02 17:14:30]

On 2013/11/29 20:23:59, eseidel wrote:
> If we need to make specific things like script source purgable, we should just
> do so at a higher level. :)  StringImpl and Vector are too low level.
> 
> SharedBuffer is a vector-like wrapper which used to wrap NSData on Mac and
wraps
> other possibly-shared, possibly-purgable memory regions on other platforms.
> 
> We also have a ScriptSourceCode wrapper around StringImpl which we could
instead
> use to wrap something purgable if necessary.
> 
> For better or worse, we have to keep the source code around in the DOM for web
> compatiblity.  We talked about adding an attribute to <script> to allow it to
be
> purgeable from the DOM.  Big apps like Gmail would probably want something
like
> that.

Yes, thanks Eric. I will implement this in SharedBuffer instead. I was too
ambitious by doing it in Vector :) I will probably do some independent changes
in SharedBuffer too to be more DiscardableMemory friendly. Currently
SharedBuffer has a fixed-size allocation granularity of a single page (it
maintains a vector of pointers to single pages). I would like to make
SharedBuffer allocate segments whose size would grow exponentially in order to
decrease the amount of allocations (DiscardableMemory can be expensive to
allocate) and more importantly have less chunks but bigger ones. This would mean
less work for the kernel which has to manage evictable ranges. I will update the
bug shortly and you guys can let me know how you feel about it before I send a
CL.

Purging JavaScript source files looks much harder to tackle. I will focus on
SharedBuffer first.