Repository navigation
Preserve EventBlock events - #126
Merged
Merged
Conversation
TeofilC
force-pushed
the
wip/preserve-blocks
branch
5 times, most recently
from
December 29, 2025 18:35
0a2956b to
f07b3b8
Compare
TeofilC
force-pushed
the
wip/preserve-blocks
branch
from
December 29, 2025 18:49
f07b3b8 to
c5e55e1
Compare
TeofilC
marked this pull request as ready for review
December 29, 2025 18:49
TeofilC
commented
Dec 29, 2025
TeofilC
force-pushed
the
wip/preserve-blocks
branch
from
December 30, 2025 11:12
c5e55e1 to
3af1d9b
Compare
TeofilC
force-pushed
the
wip/preserve-blocks
branch
from
February 18, 2026 17:18
3af1d9b to
a350cad
Compare
The eventlog format consists a stream of blocks. Each of these blocks starts with an EventBlock event, which tells us the capability the block belongs to, the size and the end time. Note that the difference between the time of the last block and the start of the current one denotes the time spent writing the eventlog to disk (neat!). The events in each block are sorted since each is exclusively owned by own capability. Currently, ghc-events just discards these events. When we want to write stuff to disk again, we group all events from each capability together and create an artificial EventBlock. This creates a valid eventlog but we lose a great deal of information, and lose some nice properties. Chunks are guaranteed to be smaller than GHC's eventlog buffer size, and when using eventlog-flush-interval they are also limited in time. If we have a chunk from each capability loaded into memory then we can efficiently sort our events without having to load the entire eventlog. In practice, we are merging a sorted stream for each capability. Unfortunately this change on its own is not enough to allow roundtripping eventlogs faithfully, but it is a step towards doing so. We still need to preserve information about the order of blocks in the eventlog. Resolves #99
TeofilC
force-pushed
the
wip/preserve-blocks
branch
from
February 18, 2026 17:20
a350cad to
8836ecb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The eventlog format consists a stream of blocks. Each of these blocks starts with an
EventBlockevent, which tells us the capability the block belongs to, the size and the end time. Note that the difference between the time of the last block and the start of the current one denotes the time spent writing the eventlog to disk (neat!). The events in each block are sorted since each is exclusively owned by own capability.Currently,
ghc-eventsjust discards these events. When we want to write stuff to disk again, we group all events from each capability together and create an artificialEventBlock. This creates a valid eventlog but we lose a great deal of information, and lose some nice properties.Chunks are guaranteed to be smaller than GHC's eventlog buffer size, and when using
eventlog-flush-intervalthey are also limited in time. If we have a chunk from each capability loaded into memory then we can efficiently sort our events without having to load the entire eventlog. In practice, we are merging a sorted stream for each capability.Unfortunately this change on its own is not enough to allow roundtripping eventlogs faithfully, but it is a step towards doing so. We still need to preserve information about the order of blocks in the eventlog.
Resolves #99