dsgrieve
commented
2 years ago From @kirk-microsoft:
At the moment, the G1 parser (well all of the concurrent parsers) will issue events in time order of when they started. The events themselves have immutable properties of; the type of event (represented by the class), the time the event started, and how long the event lasted. Generally we don’t see how long the event lasted until we see the last record. Thus we can’t create the event until we’ve seen that record. This leaves us with the problem of, how do we retain data until that event has been seen.. the answer is, we use a forward reference and then have that forward reference build the event and then emit it.. a variation of the builder pattern. When I first started this code, the amount of data collected in the forward reference wasn’t huge. The lazy implementation was to use a single forward reference implementation for all G1 phases and cycles. Now, this isn’t the case and it’s time to specialize the forward reference implantations to ease the confusion.
G1GCForwardReference grew organically and needs to be looked at to see if it could be refactored into something more extensible. One thought is to have a G1GCForwardReference interface with specific implementation for the different patterns. But this may lead to unwanted casting.