On 2014/09/18 13:48:22, Sven Panne wrote:
On 2014/09/18 13:02:03, rmcilroy wrote:
> 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?
KISS: Trying to outsmart some unknown new[] implementation is a bad idea,
and
failed in the end in every project I've seen so far.
I wasn't suggesting trying to out-smart malloc (I was not suggesting that
we do
the size binning), I was just mentioning this since I don't necessarily
think
it's worth having the extra complexity of allocating different sized buffers
given that we are only likely to have one (or a small number) of masm
objects
about at any one time. It doesn't really add much complexity though so I'm
fine
with this either way.
lgtm.
https://codereview.chromium.org/555943003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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 v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
