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

[Tom Rodriguez]

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