RFR: 8256382: Use try_lock for hs_err EventLog printing [v2]

[Stefan Karlsson]

On Wed, 25 Nov 2020 07:49:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Don't we have to check not only VMError::is_error_reported, but that it is the current thread that is doing the reporting?
>> 
>> I also think the Thread::current_or_null()==NULL case has to mean we are doing the error reporting very early in VM init - else how can we get in here in a "non attached" thread? Even then I'm not sure that is actually possible either - at what point in VM init have we installed our crash handler?
>
>> Don't we have to check not only VMError::is_error_reported, but that it is the current thread that is doing the reporting?
>> 
> 
> You mean my proposal of just not locking altogether?
> Its a calculated risk. The chance of someone printing out the even log concurrently to the hs-err reporter doing it is extremely low, and since we have secondary crash reporting the only risk we run is an interrupted error reporting step.
> 
>> I also think the Thread::current_or_null()==NULL case has to mean we are doing the error reporting very early in VM init - else how can we get in here in a "non attached" thread?
> 
> Thread::current_or_null()==NULL if we crash in a non attached thread or at/before VM init. The former case is typical if the VM is embedded into another launcher and foreign code crashes (not uncommon).
> 
> Arguably, in both cases the event log is not very interesting, but I'd still attempt to print it.
> 
>> Even then I'm not sure that is actually possible either - at what point in VM init have we installed our crash handler?

@tstuefe @dholmes-ora What's the path forward with this PR? Have your reconciled and come to a conclusion about what you want me to change?

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

PR: https://git.openjdk.java.net/jdk/pull/1408