[9] RFR (XS): 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list

[Vladimir Ivanov]

I assume you are not satisfied with the proposed fix :-)

The downside of #2 is more complicated start-up. I'll experiment to see how it shapes out.

Best regards,
Vladimir Ivanov

> On 11 февр. 2016 г., at 13:27, David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 11/02/2016 7:26 PM, Vladimir Ivanov wrote:
>> Vladimir, David, thanks for the feedback!
>> 
>>> Static ++_count could be also problem since you incremented it before
>>> adding 'this' to list. Can you look?
>> It's not a problem, because there's always a single writer (at least,
>> right now).
>> 
>>> Should we go though all our static fields and see if they have the same
>>> concurrent access problem?
>> Ideally, yes :-) But it's tedious, and not reliable. I'll do a shallow
>> inspecion for other occurences.
>> 
>>> On 2/11/16 4:47 AM, David Holmes wrote:
>>> Are entries ever removed from the list?
>> 
>> No. They are only added (in StubCodeDesc ctor).
>> 
>>> The multi-threading aspects of this code are unclear. The on demand
>>> nature of method handle adapters may be exposing this code to
>>> concurrency issues that the code doesn't expect. ??
>> It definitely stretches the code in unexpected ways. Proposed fix is
>> enough for now, but it doesn't protect from possible modifications.
>> 
>> I see 2 alternatives:
>>   (1) guard all accesses by a lock (or do modifications in a lock-free
>> manner);
>> 
>>   (2) change the way how method handle adapters are generated: do it
>> early enough, so compilers always see the same list.
>> 
>> #2 looks more attractive. I don't see a compelling reason to generate MH
>> adapters on-demand anymore, they can be part of the regular start-up
>> procedure. Also, it would allow to add additional verification logic to
>> ensure StubCodeDesc::_list isn't modified after it is read.
>> 
>> What do you think?
> 
> Immutability is always preferable to having to synchronize code to deal with concurrent modification. :)
> 
> David
> 
>> Best regards,
>> Vladimir Ivanov