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

[Coleen Phillimore]

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/

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
>>>
>>
>
>