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

[Vitaly Davidovich]

Hi Markus,

Ticks and Tickspan don't seem too optimal of names.  What about
TimeInstance and TimeSpan?

You have some operator overloads for these that can compare them against
jlongs - doesn't that still make it easy to mix up what you're comparing?
Personally, since these are value types I'd make their API work only
against these new types and make caller create the right type for
comparison.

Just my $.02, feel free to ignore :).

Thanks

Sent from my phone
On Nov 12, 2013 6:16 AM, "Markus Gronlund" <markus.gronlund at oracle.com>
wrote:

> 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/d6a7b8fa/attachment.html