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

[Vladimir Kozlov]

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