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

[Zhengyu Gu]

  623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, memflags)                  \
  624   {                                                                                 \
  625     if (array_name != NULL) {                                                       \
  626       for (int index = 0; index < size; index ++) {                                 \
  627         /* placement to call dtor on type */                                        \
  628         ((type*)&array_name[index])->~type();                                       \
  629       }                                                                             \
  630       FREE_C_HEAP_ARRAY(type, array_name, memflags);                                \
  631     }                                                                               \
  632   }


I really don't like this, calling dtor ...

Thanks,

-Zhengyu


On 4/15/2013 1:41 PM, Yumin Qi wrote:
> new webrev at:
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>
> Can I have a review from GC team for this change?
>
> Thanks
> Yumin
>
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap 
>> allocated HandleMark in the Thread() constructor is a bit of a hack. 
>> HandleMarks should be stack-allocated. Plus we seem to leak that 
>> CHeap allocated HandleMark as we don't keep any pointer to it! I 
>> think this needs to be re-visited, but as a separate CR.
>>
>> ---
>>
>> 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 ?
>>
>> ---
>>
>> 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.
>>
>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130415/4b102058/attachment.html