RFR (S): 8022494: Make compilation IDs sequential
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().
> 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
>> 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...
More information about the hotspot-compiler-dev