Request for reviews (XS): 7032849: 7022998 changes broke hs_err compile task print

Tom Rodriguez tom.rodriguez at oracle.com
Thu Mar 31 15:55:31 PDT 2011


Oh ok.  That's an interesting API.  ;)  Why do we allows time stamps that aren't relative to the start of the VM?  The ostream constructor should always init _stamp using update_to(0) which would allow us to get rid of all the places where we explicitly reset the stamp to 0:

/Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:733:    tty->time_stamp().update_to(1);
/Users/never/ws/hs/src/share/vm/utilities/ostream.cpp:748:      gclog->time_stamp().update_to(tty->time_stamp().ticks());
/Users/never/ws/hs/src/share/vm/utilities/xmlstream.cpp:55:    _out->time_stamp().update_to(1);

Actually why doesn't TimeStamp just default to that?  Anyone who wants something different should have to ask for it.  Anyway, that's probably a cleanup for another day.

Maybe your change should be part of staticBufferStream instead?

tom

On Mar 31, 2011, at 3:18 PM, Vladimir Kozlov wrote:

> No. 0 (I can use 1) means it is from the start of VM. This value (_counter) is subtracted from elapsed time in TimeStamp::milliseconds() used by print compilation:
> 
> void TimeStamp::update_to(jlong ticks) {
>  _counter = ticks;
>  if (_counter == 0)  _counter = 1;
>  assert(is_updated(), "must not look clear");
> }
> 
> jlong TimeStamp::milliseconds() const {
>  assert(is_updated(), "must not be clear");
> 
>  jlong new_count = os::elapsed_counter();
>  jlong count = new_count - _counter;
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> Don't you just want to update it to the current time with update()?
>> tom
>> On Mar 31, 2011, at 2:38 PM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/7032849/webrev
>>> 
>>> Fixed 7032849: 7022998 changes broke hs_err compile task print
>>> 
>>> Initialize the time stamp on ostream used for dumping.



More information about the hotspot-compiler-dev mailing list