Less aggressive polling when concurrently compiling for OSR.

src/optimizing-compiler-thread.h

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 36 matching lines @@
  public:
   explicit OptimizingCompilerThread(Isolate *isolate) :
       Thread("OptimizingCompilerThread"),
 #ifdef DEBUG
       thread_id_(0),
 #endif
       isolate_(isolate),
       stop_semaphore_(0),
       input_queue_semaphore_(0),
       osr_candidates_(2),
-      ready_for_osr_(2),
+      osr_cursor_(0),
       osr_hits_(0),
       osr_attempts_(0) {
     NoBarrier_Store(&stop_thread_, static_cast<AtomicWord>(CONTINUE));
     NoBarrier_Store(&queue_length_, static_cast<AtomicWord>(0));
+    for (int i = 0; i < kOsrBufferSize; i++) osr_buffer_[i] = NULL;
   }
   ~OptimizingCompilerThread() {}
 
   void Run();
   void Stop();
   void Flush();
   void QueueForOptimization(OptimizingCompiler* optimizing_compiler);
   void InstallOptimizedFunctions();
   OptimizingCompiler* FindReadyOSRCandidate(Handle<JSFunction> function,
                                             uint32_t osr_pc_offset);
@@ skipping 15 matching lines @@
     return (current_length < FLAG_concurrent_recompilation_queue_length);
   }
 
 #ifdef DEBUG
   bool IsOptimizerThread();
 #endif
 
  private:
   enum StopFlag { CONTINUE, STOP, FLUSH };
 
-  // Remove the oldest OSR candidates that are ready so that we
-  // only have |limit| left waiting.
-  void RemoveStaleOSRCandidates(int limit = kReadyForOSRLimit);
-
   void FlushInputQueue(bool restore_function_code);
   void FlushOutputQueue(bool restore_function_code);
   void CompileNext();
 
+  // Add a recompilation task for OSR to the cyclic buffer, awaiting OSR entry.
+  // Tasks evicted from the cyclic buffer are discarded.
+  void AddToOsrBuffer(OptimizingCompiler* compiler);
+
+  static const int kOsrBufferSize = 8;
+
 #ifdef DEBUG
   int thread_id_;
   Mutex thread_id_mutex_;
 #endif
 
   Isolate* isolate_;
   Semaphore stop_semaphore_;
   Semaphore input_queue_semaphore_;
 
   // Queue of incoming recompilation tasks (including OSR).
   UnboundQueue<OptimizingCompiler*> input_queue_;
   // Queue of recompilation tasks ready to be installed (excluding OSR).
   UnboundQueue<OptimizingCompiler*> output_queue_;
   // List of recompilation tasks for OSR in the input queue.
   List<OptimizingCompiler*> osr_candidates_;

[titzer, 2013/09/24 09:42:01]

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.

[Yang, 2013/09/24 10:07:11]

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.

 

-  // List of recompilation tasks ready for OSR.
-  List<OptimizingCompiler*> ready_for_osr_;
+  // Cyclic buffer of recompilation tasks ready for OSR.
+  OptimizingCompiler* osr_buffer_[kOsrBufferSize];
+  // Cursor for the cyclic buffer.
+  int osr_cursor_;
 
   volatile AtomicWord stop_thread_;
   volatile Atomic32 queue_length_;
   TimeDelta time_spent_compiling_;
   TimeDelta time_spent_total_;
 
   // TODO(yangguo): remove this once the memory leak has been figured out.
   Mutex queue_mutex_;
-  Mutex osr_list_mutex_;
   int osr_hits_;
   int osr_attempts_;
-
-  static const int kReadyForOSRLimit = 4;
 };
 
 } }  // namespace v8::internal
 
 #endif  // V8_OPTIMIZING_COMPILER_THREAD_H_