RFR (S): 8022494: Make compilation IDs sequential

Albert Noll albert.noll at oracle.com
Thu Oct 24 01:01:38 PDT 2013


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 

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:

Many thanks in advance,

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 

More information about the hotspot-compiler-dev mailing list