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

[Vladimir Ivanov]

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?

Best regards,
Vladimir Ivanov