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);
On 2013/09/24 09:42:01, titzer wrote:
Shouldn't you also empty the osr buffer here too?
This is already done in FlushOutputQueue.
https://codereview.chromium.org/24237009/diff/3001/src/optimizing-compiler-thread.cc#newcode304
src/optimizing-compiler-thread.cc:304: delete info;
On 2013/09/24 09:42:01, titzer wrote:
Maybe you want DisposeOptimizingCompiler(stale, false)? That way, all
the
deletes go through the same code path.
Done.
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_;
On 2013/09/24 09:42:01, titzer wrote:
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.
osr_candidates_ simply mirrors OSR jobs that are either still in the
input_queue_, being processed by CompileNext(), or waiting in the
output_queue_. Once a job ends up in the osr_buffer_, it's removed from
osr_candidates_. Assuming that the recompile loop doesn't block
somewhere, it always gets removed from osr_candidates_ eventually. It's
used to check whether we already have a certain OSR job (function x ast
id), since the back edge state is not 100% reliable for this purpose.
The problem of osr_buffer_ holding onto OptimizingCompiler objects is
unrelated to this. It seems unavoidable since we don't know when or
whether a completed OSR job actually gets used for OSR entry, so we have
to have a number of recent ones waiting. The best solution I could think
of for now is to somehow install hooks at the point when we enter
optimized code for a function to remove all other waiting OSR jobs for
that function. For now all we do is flushing osr_buffer_ at context
(V8::Context) change.
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.
