Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add

[Coleen Phillimore]

On 2/1/2011 3:01 PM, Dmitry Samersoff wrote:
> On 2011-02-01 22:48, Coleen Phillimore wrote:
>> On 2/1/2011 2:42 PM, Dmitry Samersoff wrote:
>>> Coleen,
>>>
>>> Should we NULL-check _handlers in the code also, before accessing it?
>> No, because we create and initialize it just before the code. If 'new'
>> comes back as null, it'll vm_exit_out_of_memory().
>>
>> see: http://cr.openjdk.java.net/~coleenp/7012088_2/
>
> fine for me.

Thanks Dmitry for finding the assert race.

Coleen
>
> -Dmitry
>
>>
>> Thanks,
>> Coleen
>>>
>>> -Dmitry
>>>
>>>
>>> On 2011-02-01 21:20, Coleen Phillimore wrote:
>>>>
>>>> Dmitry, You are absolutely right. We should check _handlers under the
>>>> lock too. It could be created in a separate thread.
>>>>
>>>> Thanks!
>>>> Coleen
>>>>
>>>> On 2/1/2011 1:14 PM, Dmitry Samersoff wrote:
>>>>> Coleen,
>>>>>
>>>>> assert code is not clean for me:
>>>>>
>>>>> if (_handlers != NULL){
>>>>> }
>>>>>
>>>>> _handlers never checked for NULL before e.g. during printing we
>>>>> use _handlers->length() etc.
>>>>>
>>>>> if we are fighting against race I guess we should take a lock before
>>>>> null check.
>>>>>
>>>>> i.e.
>>>>>
>>>>> MutexLocker mu(SignatureHandlerLibrary_lock);
>>>>> if (_handlers != NULL) {
>>>>> ....
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2011-02-01 19:48, Coleen Phillimore wrote:
>>>>>> Summary: Write method signature handler under lock to prevent race
>>>>>> with
>>>>>> growable array resizing
>>>>>>
>>>>>> Also includes a fix to 6704010 which was broken with
>>>>>> -XX:-UseFastSignatureHandlers
>>>>>>
>>>>>> This change was submitted and tested by the customer.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7012088/
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7012088
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>
>>>>
>>>
>>>
>>
>
>