RFR: 8027429: Add diagnostic command VM.info to get hs_err print-out
David Holmes
david.holmes at oracle.com
Thu Oct 29 00:48:47 UTC 2015
I agree with Fred, this kind of info reporting should not be
piggy-backed onto VMError handling for the reasons stated (and the error
handling logic is complicated enough as it is!). For things like thread
lists there are already safe management functions that can/should be used.
Thanks,
David H.
On 29/10/2015 3:29 AM, Frederic Parain wrote:
> Hi David,
>
> I haven't review all the code yet, but I'm concerned with the
> fact that the diagnostic command is calling VMError::report().
> This method has been implemented to be executed in the particular
> context of fatal errors, and its usage while the VM is running
> normally seems dangerous.
>
> For instance, VMError::report() consciously avoids grabbing locks
> because of the risk of deadlock during the error reporting.
> The consequence is that some data structures are browsed in
> an unsafe way. One example: VMError::report() calls
> Threads::print_on_error() which iterates over the thread
> list *without owning the Threads_lock*.
>
> The implementation of the diagnostic command seems also to
> exclude a lot of reporting from the initial VMError::report()
> method. Have you considered implementing a new MT-safe reporting
> method rather than trying to modify the special VMError::report()
> methods? (Note that some code factorization between VMError::report()
> and this new method should be possible).
>
> Thanks,
>
> Fred
>
> On 28/10/2015 17:18, david buck wrote:
>> Hi!
>>
>> Please review my change for this small enhancement.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8027429
>> webrev: http://cr.openjdk.java.net/~dbuck/8027429_jdk9_01/
>>
>> Cheers,
>> -Buck
>
More information about the hotspot-runtime-dev
mailing list