Oilpan and memory pressure

[Jeremy Roman]

I've been measuring the performance of the new structured-clone logic on Nexus 4 (and by extension, other Android devices), and I've noticed that doing an extra copy from the std::vector (on the malloc heap) used inside V8 to build the data into the WTF::String that SerializedScriptValue holds can be a large amount of time spent, especially for long strings.

The natural solution to this is to not do the copy, and move the std::vector into the SSV. Unfortunately, this has an unintended side effect: the performance tests OOM on Nexus 4 (and use gigabytes of memory on desktop).

Why? Because the Oilpan heap doesn't collect the MessageEvent objects that own the SerializedScriptValue objects. Even though SSV does report its external memory usage to V8 (though at present it's off by a factor of two), Oilpan seems to look only at the size of objects allocated on the Oilpan and PartitionAlloc heaps.

Making V8 allocate using PartitionAlloc is awkward at best (because PartitionAlloc is inside Blink, it would have to be a virtual allocator, and it would complicate vector's type). It seems to me that having this memory usage be reported to the Oilpan heap is the "right solution" (possibly by having ThreadState offer a method similar to v8::Isolate::AdjustAmountOfExternalAllocatedMemory).

What do you think? The performance test is a bit of a pathological case because it creates a lot of 8MB serialized values in a row, but it's still something that we should be able to handle.

The full ownership path looks like:

V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

[Kentaro Hara]

GC interaction between V8 and Oilpan is complex.

The fundamental assumption is that V8 is a "master" GC and Oilpan is a "slave" GC; i.e., if we are under high memory pressure, V8 should be aware of the fact and V8's GC should be triggered first. Oilpan's GC should follow. This is because there're many strong references from V8 wrappers to DOM objects in Oilpan.

The full ownership path looks like:
V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

In this example, it's not helpful to make Oilpan understand the high memory pressure and trigger Oilpan's GC, because it anyway cannot collect the std::vector until V8's GC collects the V8MessageEvent.

So a right solution would be to make V8 (not Oilpan) understand the high memory pressure using AdjustAmountOfExternalMemory. If V8's GC is triggered, Oilpan's GC will follow hopefully shortly. That way the objects will be collected.

BTW, who allocates the std::vector?

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CACuR13djbGbEV1%3D9hLAPMATcBnjmtSpVu-vWpu2A_-SLgHdjGg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Jeremy Roman]

On Tue, Nov 8, 2016 at 8:11 PM, Kentaro Hara <har...@chromium.org> wrote:

GC interaction between V8 and Oilpan is complex.

The fundamental assumption is that V8 is a "master" GC and Oilpan is a "slave" GC; i.e., if we are under high memory pressure, V8 should be aware of the fact and V8's GC should be triggered first. Oilpan's GC should follow. This is because there're many strong references from V8 wrappers to DOM objects in Oilpan.

The full ownership path looks like:
V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

In this example, it's not helpful to make Oilpan understand the high memory pressure and trigger Oilpan's GC, because it anyway cannot collect the std::vector until V8's GC collects the V8MessageEvent.

So a right solution would be to make V8 (not Oilpan) understand the high memory pressure using AdjustAmountOfExternalMemory. If V8's GC is triggered, Oilpan's GC will follow hopefully shortly. That way the objects will be collected.

The problem is that V8 does understand, and Oilpan's GC epilogue is executing, but it's looking at the Oilpan heap size and deciding that it doesn't need to collect after all. Exposing it to Oilpan will make Oilpan actually realize that the V8 objects that were freed correspond to collection needed on the Oilpan heap (as opposed to just being a collection of data internal to the V8 heap that doesn't correspond to an Oilpan object).

 

BTW, who allocates the std::vector?

V8 does, to store the serialized data it writes.

I noticed after this that under some circumstances use of malloc here is actually horrendously slow on Android (dominating serialization time by taking 30 ms to allocate an 8MB buffer and another 60 to free it, each time), so I'm doing additional investigation to figure out what I can do about that (perhaps plumbing in PartitionAlloc, even though it's awkward -- I'm really not sure at this point). Depending on the result of that, I may not need a resolution to this (though I think the problem could come up again in the future).

 

On Wed, Nov 9, 2016 at 5:31 AM, Jeremy Roman <jbr...@chromium.org> wrote:

I've been measuring the performance of the new structured-clone logic on Nexus 4 (and by extension, other Android devices), and I've noticed that doing an extra copy from the std::vector (on the malloc heap) used inside V8 to build the data into the WTF::String that SerializedScriptValue holds can be a large amount of time spent, especially for long strings.

The natural solution to this is to not do the copy, and move the std::vector into the SSV. Unfortunately, this has an unintended side effect: the performance tests OOM on Nexus 4 (and use gigabytes of memory on desktop).

Why? Because the Oilpan heap doesn't collect the MessageEvent objects that own the SerializedScriptValue objects. Even though SSV does report its external memory usage to V8 (though at present it's off by a factor of two), Oilpan seems to look only at the size of objects allocated on the Oilpan and PartitionAlloc heaps.

Making V8 allocate using PartitionAlloc is awkward at best (because PartitionAlloc is inside Blink, it would have to be a virtual allocator, and it would complicate vector's type). It seems to me that having this memory usage be reported to the Oilpan heap is the "right solution" (possibly by having ThreadState offer a method similar to v8::Isolate::AdjustAmountOfExternalAllocatedMemory).

What do you think? The performance test is a bit of a pathological case because it creates a lot of 8MB serialized values in a row, but it's still something that we should be able to handle.

The full ownership path looks like:

V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CACuR13djbGbEV1%3D9hLAPMATcBnjmtSpVu-vWpu2A_-SLgHdjGg%40mail.gmail.com.

[Kentaro Hara]

On Thu, Nov 10, 2016 at 8:26 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Nov 8, 2016 at 8:11 PM, Kentaro Hara <har...@chromium.org> wrote:

GC interaction between V8 and Oilpan is complex.

The fundamental assumption is that V8 is a "master" GC and Oilpan is a "slave" GC; i.e., if we are under high memory pressure, V8 should be aware of the fact and V8's GC should be triggered first. Oilpan's GC should follow. This is because there're many strong references from V8 wrappers to DOM objects in Oilpan.

The full ownership path looks like:
V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

In this example, it's not helpful to make Oilpan understand the high memory pressure and trigger Oilpan's GC, because it anyway cannot collect the std::vector until V8's GC collects the V8MessageEvent.

So a right solution would be to make V8 (not Oilpan) understand the high memory pressure using AdjustAmountOfExternalMemory. If V8's GC is triggered, Oilpan's GC will follow hopefully shortly. That way the objects will be collected.

The problem is that V8 does understand, and Oilpan's GC epilogue is executing, but it's looking at the Oilpan heap size and deciding that it doesn't need to collect after all. Exposing it to Oilpan will make Oilpan actually realize that the V8 objects that were freed correspond to collection needed on the Oilpan heap (as opposed to just being a collection of data internal to the V8 heap that doesn't correspond to an Oilpan object). 

 

Thanks, now I understand the situation.

BTW, who allocates the std::vector?

V8 does, to store the serialized data it writes.

I noticed after this that under some circumstances use of malloc here is actually horrendously slow on Android (dominating serialization time by taking 30 ms to allocate an 8MB buffer and another 60 to free it, each time), so I'm doing additional investigation to figure out what I can do about that (perhaps plumbing in PartitionAlloc, even though it's awkward -- I'm really not sure at this point). Depending on the result of that, I may not need a resolution to this (though I think the problem could come up again in the future). 

Our plan is to move PartitionAlloc to base/ and use PartitionAlloc for more things. Also Toon and I are thinking about using PartitionAlloc as an underlying allocator of V8's ZoneAllocator (by registering PartitionAlloc's malloc/free function pointers to V8). Maybe do you want to experiment with the idea for your std::vector case?

If it doesn't work, I'm okay with introducing an AdjustAmountOfMemory API to Oilpan.

 

On Wed, Nov 9, 2016 at 5:31 AM, Jeremy Roman <jbr...@chromium.org> wrote:

I've been measuring the performance of the new structured-clone logic on Nexus 4 (and by extension, other Android devices), and I've noticed that doing an extra copy from the std::vector (on the malloc heap) used inside V8 to build the data into the WTF::String that SerializedScriptValue holds can be a large amount of time spent, especially for long strings.

The natural solution to this is to not do the copy, and move the std::vector into the SSV. Unfortunately, this has an unintended side effect: the performance tests OOM on Nexus 4 (and use gigabytes of memory on desktop).

Why? Because the Oilpan heap doesn't collect the MessageEvent objects that own the SerializedScriptValue objects. Even though SSV does report its external memory usage to V8 (though at present it's off by a factor of two), Oilpan seems to look only at the size of objects allocated on the Oilpan and PartitionAlloc heaps.

Making V8 allocate using PartitionAlloc is awkward at best (because PartitionAlloc is inside Blink, it would have to be a virtual allocator, and it would complicate vector's type). It seems to me that having this memory usage be reported to the Oilpan heap is the "right solution" (possibly by having ThreadState offer a method similar to v8::Isolate::AdjustAmountOfExternalAllocatedMemory).

What do you think? The performance test is a bit of a pathological case because it creates a lot of 8MB serialized values in a row, but it's still something that we should be able to handle.

The full ownership path looks like:

V8MessageEvent (v8 heap) --> MessageEvent (Oilpan heap) --> SerializedScriptValue (ThreadSafeRefCounted, PartitionAlloc) --> std::vector (malloc heap)

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CACuR13djbGbEV1%3D9hLAPMATcBnjmtSpVu-vWpu2A_-SLgHdjGg%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan