On 2013/10/11 13:01:43, Hannes Payer wrote:
On 2013/10/11 09:20:14, Yury Semikhatsky wrote:
> On 2013/10/11 08:27:11, Hannes Payer wrote:
> > On 2013/10/11 05:59:32, loislo wrote:
> > > On 2013/10/10 18:54:39, Hannes Payer wrote:
> > > > I would propose to turn off allocation folding when you turn on
object
> > > tracking
> > > > and vice versa. FLAG_use_allocation_folding = false
> > > > Doing that will give you all the objects with corresponding sizes.
> > >
> > > If the flag doesn't change the sizes or count of the objects in the
heap
we
> > will
> > > use it.
> > > Otherwise that trick will give us the results that doesn't reflect
the
real
> > > 'allocations picture' for the page.
> >
> > The flag does not change the size and objects that get allocated. It
may
just
> > result
> > in more memory fragmentation when folding is turned on. For example,
> > new A()
> > if (condition)
> > new B()
> > else
> > new C()
> > Folding will allocate A+B+C together but will later at runtime only
use
A+B
or
> > A+C. B or C will be fragmentation, there will not be an objects at
that
> > location,
> > just free space filler memory.
> >
> > I guess it is fine to turn it off.
> >
> I agree that it would be fine to turn this optimization off when
tracking
> allocations. Can you provide some pointers on where to put the flag
disabling
> coalesced allocations in the optimizing copiler?
Setting the flag to false does not really work, because if it is set by
the
embedder
to false StopHeapAllocationsRecording would turn it on again.
In void HAllocate::HandleSideEffectDominator
I would change the line
if (!FLAG_use_allocation_folding) return;
to
if (!FLAG_use_allocation_folding
&& !profiler->is_tracking_allocations())
I see there is already a flag for this, I was under the impression that you
were
suggesting us add it. Thanks for clarifying this.
I don't mind turning allocation folding off when using the tracker. If we
find
that there is a noticeable effect of turning the folding off we can address
this
later in a separate change. Is it the only major concern about the CL? This
change has been up for review for 1.5 month already and it's been blocking
further development of the feature on v8 side. I believe that the main
criterion
for the implementation is 0-impact on the performance when the tracking is
off
and it was addressed. There are certainly other issues like tracking
coalesced
allocations that we will have to resolve but I don't think we should try to
address everything in one CL.
https://codereview.chromium.org/22852024/
--
--
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/groups/opt_out.
