RFR (trivial) 8197772: metaspace uses global operator new/delete for gtest testing

[coleen.phillimore at oracle.com]

On 2/14/18 9:47 AM, Thomas Stüfe wrote:
> Hi Coleen,
>
> On Wed, Feb 14, 2018 at 3:21 PM, <coleen.phillimore at oracle.com 
> <mailto:coleen.phillimore at oracle.com>> wrote:
>
>
>     Thank you Thomas, I just pushed it.
>
>     Now all three places where we call global operator new and delete
>     are fixed.   We'd like to remove ValueObj and VALUE_OBJ_CLASS_SPEC
>     and add a link time check.   See
>     https://bugs.openjdk.java.net/browse/JDK-8173070
>     <https://bugs.openjdk.java.net/browse/JDK-8173070> .  Do you
>     object to this change?
>
>     thanks,
>     Coleen
>
>
> No, I think it makes sense. Is the intent to get 100% coverage for c++ 
> allocated objects in NMT?

Yes.  I think historically it was to encourage arena allocation.

>
> But would a global operator new() not replace the operator new() for 
> any library in process space, including third party libraries? We 
> played around with replacing the global operator new some years ago 
> for memory tracking purposes but in the end refrained from doing it 
> because of this. But my knowledge on this is several years out of 
> date, I may be wrong.

We haven't had that problem although there used to be a comment about 
this.  The current jvm replaces all the global operators with ones with 
asserts in src/share/memory/operator_new.cpp .
>
> As for the linker tool mentioned in the issue description, we did just 
> that, run nm on all object files to find offending news and raw mallocs.
>

Oh, very good.  Did you add it to the build? Do you have a patch?

Thanks!
Coleen

> Best Regards, Thomas
>
>
>
>     On 2/14/18 3:24 AM, Thomas Stüfe wrote:
>>     Hi Coleen, thanks for fixing this.
>>
>>     Kind Regards, Thomas
>>
>>     On Wed, Feb 14, 2018 at 12:23 AM, <coleen.phillimore at oracle.com
>>     <mailto:coleen.phillimore at oracle.com>> wrote:
>>
>>         Summary: Inherit ChunkManagerReturnTestImpl from CHeapObj
>>
>>         open webrev at
>>         http://cr.openjdk.java.net/~coleenp/8197772.01/webrev
>>         <http://cr.openjdk.java.net/%7Ecoleenp/8197772.01/webrev>
>>         bug link https://bugs.openjdk.java.net/browse/JDK-8197772
>>         <https://bugs.openjdk.java.net/browse/JDK-8197772>
>>
>>         Tested with gtest that uses it.
>>
>>         Thanks,
>>         Coleen
>>
>>
>
>