RFR: 8307517: Add VMErrorCallback infrastructure to extend hs_err dumping

[Stefan Karlsson]

On Fri, 5 May 2023 13:46:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Sometimes when we crash in the GC we'd like to get some more information about what was going on the crashing thread. One example is when Generational ZGC crashes during store barrier flushing. From https://github.com/openjdk/zgc/blob/349cf9ae38664991879402a90c5e23e291f1c1c3/src/hotspot/share/gc/z/zStoreBarrierBuffer.cpp#L245
>> 
>> 
>> class ZStoreBarrierBuffer::OnError : public VMErrorCallback {
>> private:
>>   ZStoreBarrierBuffer* _buffer;
>> 
>> public:
>>   OnError(ZStoreBarrierBuffer* buffer) :
>>       _buffer(buffer) {}
>> 
>>   virtual void call(outputStream* st) {
>>     _buffer->on_error(st);
>>   }
>> };
>> 
>> void ZStoreBarrierBuffer::on_error(outputStream* st) {
>>   st->print_cr("ZStoreBarrierBuffer: error when flushing");
>>   st->print_cr(" _last_processed_color: " PTR_FORMAT, _last_processed_color);
>>   st->print_cr(" _last_installed_color: " PTR_FORMAT, _last_installed_color);
>> 
>>   for (int i = current(); i < (int)_buffer_length; ++i) {
>>     st->print_cr(" [%2d]: base: " PTR_FORMAT " p: " PTR_FORMAT " prev: " PTR_FORMAT,
>>         i,
>>         untype(_base_pointers[i]),
>>         p2i(_buffer[i]._p),
>>         untype(_buffer[i]._prev));
>>   }
>> }
>> 
>> void ZStoreBarrierBuffer::flush() {
>>   if (!ZBufferStoreBarriers) {
>>     return;
>>   }
>> 
>>   OnError on_error(this);
>>   VMErrorCallbackMark mark(&on_error);
>> 
>>   for (int i = current(); i < (int)_buffer_length; ++i) {
>>     const ZStoreBarrierEntry& entry = _buffer[i];
>>     const zaddress addr = ZBarrier::make_load_good(entry._prev);
>>     ZBarrier::mark_and_remember(entry._p, addr);
>>   }
>> 
>>   clear();
>> }
>> 
>> 
>> If we crash in ZStoreBarrierBuffer::flush, we print the information above into the hs_err file.
>> 
>> We've found this information to be useful and would like to upstream the infrastructure separately from the much larger Generational ZGC PR.
>> 
>> Testing: this has been brewing and been used in the Generational ZGC repository for a long time.
>
> src/hotspot/share/utilities/vmError.hpp line 232:
> 
>> 230: 
>> 231: class VMErrorCallbackMark : public StackObj {
>> 232:   Thread* _thread;
> 
> Why would we need the thread here? Why not use Thread::current in dtor? This object is only used as stack object, right?

I was treading in Runtime code and Coleen usually wants to use cached-away Thread pointers instead of calling Thread::current() repeatedly. I'm fine with either solution.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13824#discussion_r1186299053