RFR: 6643: Make VM Operations rule consider close consecutive events in score

[Henrik Dafgård]

On Thu, 30 Jan 2020 20:01:57 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch modifies the VM Operations rule's score calculation so that is considers blocking that could result from the combination of multiple close consecutive operations.  Right now an application's score only takes into account the longest event in its calculation. 
> 
> At the moment I have determined two events to be "close" if they occur within 0.01 s of one another.

Changes requested by hdafgard (Reviewer).

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/VMOperationRule.java line 185:

> 184: 		return sortedEvents;
> 185: 	}
> 186: 

This is fairly expensive and unnecessary, during parsing events are stored in lanes by type that are disjoint (for events with durations) and sorted. You could use that fact and check for the time between two events in the same lane instead, possibly with a second pass over the IItemCollection if there are multiple lanes.

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/VMOperationRule.java line 134:

> 133: 
> 134: 	private void findLongestEventInfo(IItemCollection items) {
> 135: 		List<IItem> sortedEvents = sortEventsByStartTime(items);

For this method it would be much better to use the established pattern for iterating through IItemCollections:
`for (IItemIterable itemIterable : items) {
  // get your accessors here
  IMemberAccessor<IQuantity, IItem> startTime = JfrAttributes.START_TIME.getAccessor(itemIterable.getType());
  for (IItem item : itemIterable) {
    IQuantity time = startTime.getMember(item);
  }
}`

Each IItemIterable represents one event lane of one event type of disjoint events, sorted by timestamp.

-------------

PR: https://git.openjdk.java.net/jmc/pull/42