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

[David Holmes]

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