Details
-
Bug
-
Resolution: Fixed
-
P2
-
8
-
b119
-
Not verified
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8029903 | 7u60 | Markus Grönlund | P2 | Closed | Fixed | b03 |
JDK-8029061 | hs25 | Markus Grönlund | P2 | Closed | Fixed | b61 |
Description
Currently, when working with counter based data, the primary data type representation in the VM are raw jlong's. jlong's are employed to represent both:
1. a single instance in time, for example a "now" timestamp
2. a time duration, a timespan, for example the duration between "now" - "then"
Having a raw jlong type represent both of these shifts the responsibility to the programmer to always ensure the correct, without any assistance either at compile or at runtime.
The event based tracing framework relies heavily on counter based data in order to keep track of time and timing related information and we have seen counter data errors where the representation sent to the tracing framework has submitted the wrong time, i.e. a timespan when a time instant was expected and vice versa.
We should therefore add an alternative to jlongs for representing counter based data. We should enlist the help of the type system to enforce the correct data types at compile time as well as introduce strong runtime asserts in order to reduce the number of potential bugs.
I will therefore add two new type's in src/share/vm/utilities:
1. "Ticks" - represents a single counter based timestamp.
2. "Tickspan" - represents a counter based duration, a timespan, between two "Ticks"
I will also update the existing event based tracing "event sites" to employ the stronger types.
Thanks
Markus
1. a single instance in time, for example a "now" timestamp
2. a time duration, a timespan, for example the duration between "now" - "then"
Having a raw jlong type represent both of these shifts the responsibility to the programmer to always ensure the correct, without any assistance either at compile or at runtime.
The event based tracing framework relies heavily on counter based data in order to keep track of time and timing related information and we have seen counter data errors where the representation sent to the tracing framework has submitted the wrong time, i.e. a timespan when a time instant was expected and vice versa.
We should therefore add an alternative to jlongs for representing counter based data. We should enlist the help of the type system to enforce the correct data types at compile time as well as introduce strong runtime asserts in order to reduce the number of potential bugs.
I will therefore add two new type's in src/share/vm/utilities:
1. "Ticks" - represents a single counter based timestamp.
2. "Tickspan" - represents a counter based duration, a timespan, between two "Ticks"
I will also update the existing event based tracing "event sites" to employ the stronger types.
Thanks
Markus
Attachments
Issue Links
- backported by
-
JDK-8029061 Add a type safe alternative for working with counter based data
- Closed
-
JDK-8029903 Add a type safe alternative for working with counter based data
- Closed