https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.cc
File src/optimizing-compiler-thread.cc (right):
https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.cc#newcode186
src/optimizing-compiler-thread.cc:186: FlushOutputQueue(false);
Shouldn't you also empty the osr buffer here too?
https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.cc#newcode304
src/optimizing-compiler-thread.cc:304: delete info;
Maybe you want DisposeOptimizingCompiler(stale, false)? That way, all
the deletes go through the same code path.
https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.h
File src/optimizing-compiler-thread.h (right):
https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.h#newcode122
src/optimizing-compiler-thread.h:122: List<OptimizingCompiler*>
osr_candidates_;
First, I am not even sure why you need two buffers here.
Second, It looks like this two buffer scheme can leak
OptimizingCompilers. You are using the osr_candidates_ as a list of the
OSR compilation requests. When the compilation request finishes, it gets
moved from the osr_candidates_ to the osr_buffer_, the latter of which
is a fixed-size buffer. But that buffer holds onto those
OptimizingCompilers until they are either removed by
FindReadyOsrCandidate or until they are overwritten by the next
AddToOsrBuffer. That's a problem, since an Optimizing compiler holds
onto potentially a lot of memory--the entire hydrogen and lithium
graphs, I think.
https://codereview.chromium.org/24237009/
--
--
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.
