Hi all There seem to be some constraints on the way the CpuProfiler works.
The CpuProfiler is usually set to take samples every 1ms. The CpuProfiler uses a lock-free unbounded queue to receive code events from the VM thread (as described in https://code.google.com/p/v8/source/detail?r=4706) to reduce any delays incurred by the VM thread to be relatively short and consistent. On Windows the sleep granularity varies from 1ms-15ms depending on the (global) time period. On Linux (and other POSIX platforms, presumably) the sleep granularity is much lower (eg 50us). To reduce CPU usage I would like to (one of): use a condition variable, sleep or (at least) yield timeslices. (AFAICT:) In 3.14 the implementation yields timeslices. In 3.28 (and newer) it does not. *Condition variable?*Introducing a condition variable would allow the processing loop to only do work when there is at least one code event on the queue (actually there's multiple queues, but it should be fine to reduce this to a condition where any queue contains an event). Using a condition variable would introduce a mutex into the VM thread if we want to guarantee a notify would be received by the waiting thread. This would only need to be taken around the notify and only when the queue went from empty to non-empty (since the receiving thread only needs to ensure the notify does not occur between the checking if the queue is empty and waiting on the condition variable). However, if the thread were to wait (indefinitely) on a condition variable it would not be able to properly take samples at the necessary interval. So, either the wait needs a timeout, or the samples need to be started on a different thread. The problem with a timeout is that (as far as I know) it is subject to the same granularity as sleeping. Therefore, particularly on Windows, the timeout may not be accurate for the sub-millisecond times that would be required to get timely samples. If samples were taken on a different thread to the code event processing, then the code event processing could proceed with a wait/notify. The sample scheduling thread would be able to sleep for 1ms and take samples in a timely manner (assuming best granularity on Windows). The cost of performing a mutex lock to do the notify would need to be checked to ensure it does not delay the VM thread significantly (is it always completed in a short and consistent time). *Sleep?*Introducing a sleep into the processing loop when it has no work to do would reduce the amount of busy looping repeatedly checking the queue(s). A sleep at the smallest period would be rounded up to the sleep granularity. On Windows, this would probably be problematic if samples and code events need to be processed on the same thread, since even the smallest granularity is very close to the typical 1ms sample period. On Linux (and POSIX?) the granularity is small enough (eg 50us) not to delay 1ms samples very much, and some busy looping could be done to improve the accuracy further at the cost of a bit of CPU if necessary. If samples were taken on a different thread to the code event processing, then the code event processing could proceed with a sleep when there is no work to do. The sample scheduling thread would be able to sleep for 1ms and take samples in a timely manner (assuming best granularity on Windows). *Yield timeslices?*Introducing a yield into the processing loop when it has no work to do would allow other threads to use the CPU if needed. The CPU usage still would still be high since the loop will still consume CPU when no other thread needs it. Samples should not be delayed in any significant way. Regards Michael -- -- 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/d/optout.
