<p dir="ltr">Similar issue with the Ticks versions.</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Nov 12, 2013 8:17 PM, "Vitaly Davidovich" <<a href="mailto:vitalyd@gmail.com">vitalyd@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Yeah, naming things is often a pain.</p>
<p dir="ltr"> 51 inline bool operator<=(const Tickspan& lhs, const Tickspan& rhs) {<br>
52 return !operator<(lhs,rhs);<br>
53 }<br>
54 <br>
55 inline bool operator>=(const Tickspan& lhs, const Tickspan& rhs) {<br>
56 return !operator<(lhs,rhs);<br>
57 }</p>
<p dir="ltr">These look like bugs; first one should probably be !operator>(lhs,rhs) and !operator<(lhs,rhs), respectively.</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Nov 12, 2013 10:32 AM, "Markus Gronlund" <<a href="mailto:markus.gronlund@oracle.com" target="_blank">markus.gronlund@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="SV" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Vitaly,<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for you input!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p><span lang="EN-US">“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.”<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for spotting these – the compare against jlongs in from an older version of the webrev where this was allowed – you are right, it should not be allowed, I thought I had updated this, will remove them – many thanks for spotting…<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As for the names, <u></u><u></u></span></p><p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">“</span><span lang="EN-US">Ticks and Tickspan don't seem too optimal of names. What about TimeInstance and TimeSpan?”<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I agree with you that the names could possibly be improved, believe me I have tried to use multiple names – one thing I wanted was to emphasize that these types (currently) are only based on counter’s (i.e ticks), and do not represent any higher “time” abstraction. That is, the implementation is tied to data from counters (based on ticks with a specific ticks frequency). In my current context, I use these values to talk about “time” (as you saw from the original post), but “time” can mean many things to different people, esp. many implementations and clock sources. <u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also, there already exist a few “Time/Timer” types (although they are not as good as I want them to be for current purposes), for example there is a type called Timestamp (in runtime/timers.hpp).<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I have come to the conclusion that in order to address the overall time abstractions in Hotspot, we would need to make a larger effort – this we should indeed do, but it’s outside the current scope.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also I am pretty sure that when we do revisit the time abstractions, the names for these types will most likely change – that made me leave the names to emphasize the “ticks” sources.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for your input.<u></u><u></u></span></p><p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best regards<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Markus<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Vitaly Davidovich [mailto:<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>] <br>
<b>Sent:</b> den 12 november 2013 15:37<br><b>To:</b> Markus Gronlund<br><b>Cc:</b> serviceability-dev; <a href="mailto:hotspot-runtime-dev@openjdk.java.net" target="_blank">hotspot-runtime-dev@openjdk.java.net</a>; <a href="mailto:hotspot-gc-dev@openjdk.java.net" target="_blank">hotspot-gc-dev@openjdk.java.net</a><br>
<b>Subject:</b> Re: RFR(M): 8028128: Add a type safe alternative for working with counter based data<u></u><u></u></span></p></div><p class="MsoNormal"><u></u> <u></u></p><p>Hi Markus,<u></u><u></u></p><p>Ticks and Tickspan don't seem too optimal of names. What about TimeInstance and TimeSpan?<u></u><u></u></p>
<p style="margin-left:65.2pt">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.<u></u><u></u></p>
<p>Just my $.02, feel free to ignore :).<u></u><u></u></p><p>Thanks<u></u><u></u></p><p>Sent from my phone<u></u><u></u></p><div><p class="MsoNormal">On Nov 12, 2013 6:16 AM, "Markus Gronlund" <<a href="mailto:markus.gronlund@oracle.com" target="_blank">markus.gronlund@oracle.com</a>> wrote:<u></u><u></u></p>
<div><div><p class="MsoNormal">Greetings,<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Kindly asking for reviews for the following changeset:</span><u></u><u></u></p><p class="MsoNormal">
<span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal">Webrev: <a href="http://cr.openjdk.java.net/~mgronlun/8028128/webrev01/" target="_blank">http://cr.openjdk.java.net/~mgronlun/8028128/webrev01/</a> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Bug: </span><a href="https://bugs.openjdk.java.net/browse/JDK-8028128" target="_blank"><span lang="EN-US">https://bugs.openjdk.java.net/browse/JDK-8028128</span></a><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><b>Description:</b><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">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: <br>
<br>1. a single instance in time, for example a "now" timestamp <br>2. a time duration, a timespan, for example the duration between "now" - "then" <br><br>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. <br>
<br>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. <br>
<br>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. <br>
<br>I will therefore add two new types in src/share/vm/utilities: <br><br>1. "Ticks" - represents a single counter based timestamp, a single instance in time.<br>2. "Tickspan" - represents a counter based duration, a timespan, between two "Ticks" </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Please see the added files:</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p><span lang="EN-US">-</span><span lang="EN-US" style="font-size:7.0pt"> </span><span lang="EN-US">src/share/vm/utilities/ticks.hpp</span><u></u><u></u></p><p><span lang="EN-US">-</span><span lang="EN-US" style="font-size:7.0pt"> </span><span lang="EN-US">src/share/vm/utilities/ticks.inline.hpp</span><u></u><u></u></p>
<p><span lang="EN-US">-</span><span lang="EN-US" style="font-size:7.0pt"> </span><span lang="EN-US">src/share/vm/utilities/ticks.cpp</span><u></u><u></u></p><p><span lang="EN-US"> </span><u></u><u></u></p><p><span lang="EN-US">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><b><span lang="EN-US">Testing completed:</span></b><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p class="MsoNormal">nsk.stress.testlist (UTE/Aurora)<u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">GC nightlies (Aurora)</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">gc/gctests/* (UTE/Aurora)</span><u></u><u></u></p>
<p class="MsoNormal">nsk.gc.testlist (UTE/Aurora)<u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">SpecJBB2013 (no regression)</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">SpecJBB2005 (no regression)</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">Kitchensink (locally Windows) runs for +> 9 days (still running…)<br><br>Thanks in advance<br>Markus</span><u></u><u></u></p></div></div></div></div></div></blockquote></div>
</blockquote></div>