On 2014/09/18 13:02:03, rmcilroy wrote:
On 2014/09/18 12:52:42, ulan wrote:
> Hi Ross, Rodolph.
>
> Could you please take a look? This fixes chrome crashes. Another
solution
would
> be to reduce FLAG_stack_size by 120KB for ARM.
>
> I will check benchmarks before landing.
This seems fine to me, but I would just always allocate
kMaxNumPending32/64RelocInfo if you are wanting to be cautious (for merge
into
m38). If malloc is smart enough to keep the allocation in a size-binned
free-list then this would be both faster (since it would always just
re-use
the
same memory) and potentially use less memory since it wouldn't cause
fragmentation due to different size being requested. WDYT?
Thanks! I'll think about this, not sure how to test if malloc is smart.
I ran Octane and collected how many different buffer_sizes are requested:
cnt: 59341, buffer size: 256
cnt: 21086, buffer size: 44
cnt: 13577, buffer size: 40
cnt: 10101, buffer size: 4096
cnt: 2436, buffer size: 36
cnt: 364, buffer size: 2164
cnt: 224, buffer size: 2116
cnt: 204, buffer size: 1024
cnt: 78, buffer size: 884
cnt: 72, buffer size: 1972
cnt: 66, buffer size: 2100
cnt: 46, buffer size: 2132
cnt: 42, buffer size: 2148
cnt: 32, buffer size: 876
cnt: 30, buffer size: 868
cnt: 24, buffer size: 1924
cnt: 18, buffer size: 860
cnt: 16, buffer size: 852
cnt: 16, buffer size: 776
cnt: 16, buffer size: 2196
cnt: 16, buffer size: 16384
cnt: 8, buffer size: 772
cnt: 8, buffer size: 2180
cnt: 8, buffer size: 1892
cnt: 6, buffer size: 1876
https://codereview.chromium.org/555943003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
