Request for review (S) 7012088: jump to 0 address because of lack of memory ordering in SignatureHandler::add
Dmitry Samersoff
Dmitry.Samersoff at oracle.com
Tue Feb 1 12:01:26 PST 2011
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.
-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
>>>>
>>>
>>
>>
>
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
More information about the hotspot-runtime-dev
mailing list