RFR: 8149591 - Prepare hotspot for GTest

[Jesper Wilhelmsson]

Looks good!
/Jesper


Den 30/4/16 kl. 03:47, skrev Igor Ignatyev:
> Hi,
>
> I’d like to renew this RFR.
>
> besides updated previous changes, new webrev contains two new things:
>  - new vm-flag — ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in “death” tests (the tests which intentionally cause crashes/asserts)
>  - if CreateCoredumpOnCrash is false, we don't determine default core path
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591
>
> Thanks,
> — Igor
>
>> On Feb 11, 2016, at 7:20 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Jesper,
>>
>> On 11/02/2016 5:47 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Please review this change to prepare the Hotspot code for the Google
>>> unit test framework. From the RFE:
>>>
>>> A few changes are needed in the hotspot code to start using the Google
>>> Test framework.
>>>
>>> 1. The new() operator as defined in allocation.cpp can not be used
>>> together with GTest. This needs to be moved to a separate file so that
>>> we can avoid compiling it when building the GTest enabled JVM.
>>
>> I presume that is because GTest will use the real global operator new?
>>
>> The name of the new file, given it contains new and delete, seems one-sided. But I can't think of anything better. :)
>>
>>> 2. In management.cpp there is a local variable called err_msg. This
>>> variable is shadowing a global variable in debug.hpp. In the GTest work
>>> the global err_msg variable is used in the vmassert macro and this
>>> creates a conflict with the local variable in management.cpp.
>>
>> Renaming seems trivially fine.
>>
>>> 3. If SuppressFatalErrorMessage is set ALL error messages should be
>>> suppressed, even the ones in error_is_suppressed() in debug.cpp.
>>
>> Took me a while to think this one through. Not sure what purpose SuppressFatalErrorMessages is intended to serve. The idea that the VM can just vanish without any kind of message to the user just seems like a bad idea. I wonder if there is a SuppressFatalErrorMessages test somewhere that actually relies on the output from error_is_suppressed to determine that a crash really did happen? ;-)
>>
>> Cheers,
>> David
>>
>>> This is what is done by this change.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8149591
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8149591/webrev.00/index.html
>>>
>>> Thanks,
>>> /Jesper
>