P4
If we ever need to bump the major version of the file format, which we haven’t done since JDK 9/11 and have no intention of doing now, we should address all the issues mentioned in this enhancement:
- Introduce a chunk sequence number. Relying on the timestamp for ordering is problematic.
- Write down the size of the header first, so it can be expanded in later versions without breaking forward compatibility. Currently, it's locked at 68 bytes. We have reserved 32 extension bits, but we need more.
- A field value can be constant="false" or constant="true". If true, the ID is written and the value is looked up in the constant pool. We should make this dynamic, perhaps by using constant="auto". If the first byte has a specific bit pattern, the parser can select whether it is an ID or a value. This is similar to how strings are handled today, but we should make it generic to any type.
- Introduce a ChunkSegment event that is hidden to the user, but written when a segment starts. This would make the format better suited for a binary data stream which can be compressed / encrypted on the fly. Currently, segment information is hidden in the constant pool at the end.
- Maybe create a new format for stack traces so we can reuse parts of other stack traces.
Any major change needs to be coordinated with the JMC, so there exists an updated JMC parser and version when the JDK is released.
- Introduce a chunk sequence number. Relying on the timestamp for ordering is problematic.
- Write down the size of the header first, so it can be expanded in later versions without breaking forward compatibility. Currently, it's locked at 68 bytes. We have reserved 32 extension bits, but we need more.
- A field value can be constant="false" or constant="true". If true, the ID is written and the value is looked up in the constant pool. We should make this dynamic, perhaps by using constant="auto". If the first byte has a specific bit pattern, the parser can select whether it is an ID or a value. This is similar to how strings are handled today, but we should make it generic to any type.
- Introduce a ChunkSegment event that is hidden to the user, but written when a segment starts. This would make the format better suited for a binary data stream which can be compressed / encrypted on the fly. Currently, segment information is hidden in the constant pool at the end.
- Maybe create a new format for stack traces so we can reuse parts of other stack traces.
Any major change needs to be coordinated with the JMC, so there exists an updated JMC parser and version when the JDK is released.