[Nestmates] RFR (S): Dynamic nestmate update

[David Holmes]

Hi Lois,

Here's an update:

http://cr.openjdk.java.net/~dholmes/dynamic-nestmates/webrev.v2

Now we push the dynamic_nest_host through to the 
KlassFactory::create_from_stream level, where we set the nest-host 
directly after ClassFileParser.create_instance_klass has been called. 
That should ensure the class is not findable until after the nest-host 
has successfully been set, and doesn't require any further cleanup (as 
far as I can see) if the setting of the nest-host fails.

No changes to InstanceKlass::set_nest_host from previous version (sorry 
I'm not setup to do incremental webrevs ... need to fix that).

I've also removed Mandy's temporary nestmate access check code in 
reflection.cpp as it is not needed. So InstanceKlass:raw_nest_host() is 
also removed.

I also reworked jvm_lookup_define_class a little - the use of "const" 
caused flow-on problems that were simpler to avoid by not using "const".

Thanks,
David

On 30/10/2018 9:35 AM, David Holmes wrote:
> Hi Lois,
> 
> On 30/10/2018 6:01 AM, Lois Foltan wrote:
>> On 10/29/2018 2:37 AM, David Holmes wrote:
>>
>>> webrev: http://cr.openjdk.java.net/~dholmes/dynamic-nestmates/webrev/
>>>
>>> This fleshes out Mandy's initial implementation with additional error 
>>> checking on the VM side to match the defineClass API, and with an 
>>> additional VM test.
>>>
>>> Thanks,
>>> David
>> Hi David,
>>
>> I have a couple of concerns about this approach longer term for 
>> setting the nest host post return from either 
>> SystemDictionary::resolve_from_stream or 
>> SystemDictionary::parse_stream within jvm_lookup_define_class().
>>
>> - for a findable class as soon as that class is added to the 
>> SystemDictionary, is there any concern that another thread could 
>> request that class and access it before its nest host is legitimately 
>> set? Would it be better to pass nest host down into ClassFileParser so 
>> it is known at the point the InstanceKlass is created?
> 
> Good question. I hadn't looked at exactly how and when the defineClass 
> logic set the nest host, I was only only updating the actual 
> set_nest_host internal logic.
> 
> There are a couple of concerns here:
> 
> 1. Finding the class before the nest-host has been set
> 2. Cleaning up in the case that setting the nest-host failed
> 
> I don't think either are currently handled correctly - and my change 
> triggers #2. We need a way to make the complete logical operation 
> atomic. That most likely requires pushing the setting of the nest-host 
> deeper into the class loading logic - possibly immediately after IK 
> creation as you suggest.
> 
>> - At the time class file nest members attributes are parsed and the 
>> nest host setting within the byte stream matches the nest host used 
>> when jvm_lookup_define_class() is invoked, than in my opinion an error 
>> should not result.
> 
> I disagree. You're either using dynamic nest membership or you're using 
> static nest membership - using both, even if the end result would be the 
> same, seems an error in the programming model to me. Afterall if the 
> defined class is already a valid static nest member then you don't need 
> to use the NESTMATE property to inject it. And it is definitely an error 
> to claim a static nest-host when the host does not statically list you 
> as a member!
> 
>> - Finally, should the setting of nest_host be known at the point class 
>> file load hook is processed?
> 
> I'm not sure what you mean. At what point in the current code would the 
> byte[] passed to defineClass be replaced by one from the CLFH? As long 
> as the byte[] is final before we actually set_nest_host, I don't think 
> it matters.
> 
> Thanks,
> David
> 
>> Thanks,
>> Lois