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

[Vladimir Kozlov]

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