Request for reviews (S): 6834177: Running jsynprog on Solaris Nevada can cause JVM crash

[Tom Rodriguez]

Looks good.

tom

On Apr 29, 2009, at 11:11 AM, Vladimir Kozlov wrote:

> Done. I also added missing resource marks.
>
> http://cr.openjdk.java.net/~kvn/6834177/webrev.02
>
> Vladimir
>
> Tom Rodriguez wrote:
>> Can you make the i2c/c2i use the shared BufferBlob so it's all  
>> consistent?  This also gets rid of _buffer.
>> tom
>> On Apr 28, 2009, at 4:15 PM, Vladimir Kozlov wrote:
>>> Thanks, Tom
>>>
>>> Yes, I forgot to free BufferBlob.
>>> I am thinking to use static BufferBlob buffer, initialize it lazily
>>> and reuse it. It should be safe since all is done inside of
>>> AdapterHandlerLibrary lock.
>>>
>>> http://cr.openjdk.java.net/~kvn/6834177/webrev.01
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> It's surprising we got away with that for so long.  Don't you  
>>>> need to release the BufferBlob at the end?
>>>> tom
>>>> On Apr 27, 2009, at 2:40 PM, Vladimir Kozlov wrote:
>>>>> http://cr.openjdk.java.net/~kvn/6834177/webrev.00
>>>>>
>>>>> Fixed 6834177: Running jsynprog on Solaris Nevada can cause JVM  
>>>>> crash
>>>>>
>>>>> Problem:
>>>>> The code which generates a native call wrapper and a dtrace  
>>>>> nmethod
>>>>> uses VM's static buffer AdapterHandlerLibrary::_buffer for the  
>>>>> code
>>>>> generation before moving it into CodeCache.
>>>>> During the code generation in the static buffer a runtime call  
>>>>> distance
>>>>> is < 32 bits and the short form of a call instruction is  
>>>>> generated.
>>>>> It may cause problem for 64-bit VM when the relative call distance
>>>>> to runtime from these methods may not fit into 32-bit if address
>>>>> distance between CodeCache and VM's code > 32 bits.
>>>>>
>>>>> Solution:
>>>>> Use CodeCache buffer blob for the native wrapper and dtrace  
>>>>> nmethod
>>>>> code generation. Also throw an exception in dtrace runtime if  
>>>>> nmethod
>>>>> was not generated.
>>>>>
>>>>> Note: it is ok to use the static buffer for i2c and c2i adapters  
>>>>> since
>>>>> they don't have calls to runtime.
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Fix verified (y/n): y, bugs case
>>>>>
>>>>> Other testing:
>>>>> JPRT
>>>>>