RFR: 7950: Better DisjointBuilder performance for events not ordered by event end attribute

[Erik Gahlin]

On Wed, 9 Nov 2022 16:04:57 GMT, Henrik Dafgård <hdafgard at openjdk.org> wrote:

> > When I wrote the original code in 2010 collisions were rare. I think I saw a few cases of 2-3 lanes (for the same event type and thread), typically when doing recursive events. I wonder what has changed, if this is no longer a case? The JVM usually doesn't write overlapping events.  Is it thread buffers coming out of order?
> 
> @egahlin As far as I've investigated the issue is prevalent in JVM applications running with Amazon Kinesis. It can produce tens of thousands of overlapping File Read events.

Interesting. I took a look at the FileRead events in the JDK I think I found a bug that could explain the issue:

         try {
            start = EventConfiguration.timestamp();
            write(b);
            bytesWritten = b.length;
        } finally {
            long duration = EventConfiguration.timestamp();
            if (eventConfiguration.shouldCommit(duration)) {
                FileWriteEvent.commit(start, duration, path, bytesWritten);
            }
        }

It should be:

    long duration = EventConfiguration.timestamp() - start;

This regression was introduced in JDK 15. I will prepare a fix. Should be backported.
https://hg.openjdk.java.net/jdk/jdk/rev/dd0caf00b05c

The fix to JMC still makes sense.

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

PR: https://git.openjdk.org/jmc/pull/449