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