RFR(M): 8028128: Add a type safe alternative for working with counter based data

[Markus Gronlund]

Greetings,

 

Kindly asking for reviews for the following changeset:

 

Webrev: http://cr.openjdk.java.net/~mgronlun/8028128/webrev01/ 

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8028128

 

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 validity of the counter data, without any assistance either at compile time 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 help with the correct usage of time and to reduce the number of potential bugs. 

I will therefore add two new types in src/share/vm/utilities: 

1. "Ticks" - represents a single counter based timestamp, a single instance in time.
2. "Tickspan" - represents a counter based duration, a timespan,  between two "Ticks" 

 

Please see the added files:

 

-          src/share/vm/utilities/ticks.hpp

-          src/share/vm/utilities/ticks.inline.hpp

-          src/share/vm/utilities/ticks.cpp

 

I have also updated some of the existing event based tracing "event sites" to employ usage of these new types as well as updated a few places in the event based tracing framework implementation to accommodate these types.

 

Testing completed:

 

nsk.stress.testlist (UTE/Aurora)

GC nightlies (Aurora)

gc/gctests/* (UTE/Aurora)

nsk.gc.testlist (UTE/Aurora)

SpecJBB2013 (no regression)

SpecJBB2005 (no regression)

Kitchensink (locally Windows) runs for +> 9 days (still running.)

Thanks in advance
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20131112/04447f61/attachment.html