RFR: 8010992: Remove calls to global ::operator new[] and new

[David Holmes]

On 16/04/2013 3:01 AM, Yumin Qi wrote:
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>> before deallocating ?
>>
> In fact, CardTableRS and CardTableModRefBS are only created once when GC
> flavor specified. It will be cleaned at JVM exit, this is why there is
> no memory leak. To keep a better coding practice, I will add
> FREE_C_HEAP_OBJECT_ARRAY to call dtos, also to free other allocated
> arrays during ctos called.

Thanks. Just because those uses are not freed it doesn't mean this won't 
get used for something else.

>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would
>> expect all platforms to need to the same headers here.
>>
> This is due to SunStudio compilation setting. It will issue error on
> solaris like:
>
> src/share/vm/utilities/quickSort.cpp", line 192: Error: The function
> "AllocateHeap" must have a prototype.
>
> in precompiled.hpp:
>
> // Precompiled headers are turned off for Sun Studion,
> // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles.
>
> #ifndef DONT_USE_PRECOMPILED_HEADER
>
> I could add the including for all platforms, since it will be excluded
> by other platforms except for solaris --- precompiled.hpp already
> includes those two files. Adding #ifdef SOLARIS here to indicate they
> are only needed for Solaris.

The solaris case is showing you that this only works if precompiled 
headers are enabled. If you disable them you should find this fails to 
compile on the other platforms too. There is a missing #include needed 
for the allocation header.

David
-----


> I will send new webrev out.
>
> Thanks
> Yumin
>
>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>