RFR (S): 8022494: Make compilation IDs sequential

[Albert Noll]

Hi,

here is an updated version of this bug. In this version, compilation IDs 
are generated by using Atomic::add().
As a result, we should not need locks to provide a unique ID for each 
request.

Also, in AdapterHandlerLibrary::create_native_wrapper(), set_code() is 
now called while holding
the AdapterHandlerLibrary_lock. This should be fine, since set_code() 
does not use locks.

Here is the updated webrev:
http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ 
<http://cr.openjdk.java.net/%7Eanoll/8022494/webrev.03/>

Many thanks in advance,
Albert


On 08.08.2013 04:26, Vladimir Kozlov wrote:
> I think the simplest solution would be to make 
> CompileBroker::assign_compile_id() public (note, it is static method) 
> and call it from create_native_wrapper().
>
> Vladimir
>
> On 8/7/13 6:50 PM, John Rose wrote:
>> On Aug 6, 2013, at 10:55 PM, Albert Noll <albert.noll at oracle.com
>> <mailto:albert.noll at oracle.com>> wrote:
>>
>>> please review this small patch.
>>
>> It looks like you moved the test (for NULL) of method->code() outside of
>> AdapterHandlerLibrary_lock.
>>
>> This means that there will be races where multiple threads race to
>> request a native wrapper.  They will all generate the code, sequentially
>> grabbing AdapterHandlerLibrary_lock.  I think this is unnecessary
>> concurrency.  I suggest that you keep the lines marked "See if somebody
>> beat us to it".
>>
>> --- John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/e07e8cae/attachment-0001.html