Details
-
Type:
Sub-task
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.1.0
-
Labels:None
-
Number of attachments :
Description
In green threads, it was very important for the performance of the adaptive system to avoid attributing samples to threads that were only running for a very small piece of the interval (sample the thread that was interrupted by the timer interrupt, not the thread that was being scheduled).
We need to get similar functionality into the timer-driven sampling being done with native threading. Right now, the hottest methods in some profiles I've looked at are all related to threads being suspended and then taking samples when they resume execution. For example, here's the 4 most important methods in luindex according to the sampling.
11899.0 (31.142692629815745%) Lorg/jikesrvm/adaptive/measurements/organizers/Organizer;.run ()V BOOT
4582.0 (11.992252931323282%) Lorg/jikesrvm/scheduler/FinalizerThread;.run ()V BOOT
4488.0 (11.746231155778894%) Lorg/jikesrvm/adaptive/OSROrganizerThread;.run ()V BOOT
2730.0 (7.1451005025125625%) Lorg/jikesrvm/scheduler/RVMThread;.waitImpl (Ljava/lang/Object;ZJ)V BOOT
In other words, we think we're spending almost 60% of executing cycles in these methods. This is a gross enough mistake that it will badly distort the decisions being made by the adaptive system.
The same problem can also be seen in the call graph profile, which will impact inlining decisions.