RFR (S): 8022494: Make compilation IDs sequential
Albert Noll
albert.noll at oracle.com
Thu Oct 24 01:01:38 PDT 2013
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
More information about the hotspot-compiler-dev
mailing list