[Nestmates] RFR (S): Dynamic nestmate update

[Karen Kinnear]

Code looks good. Thank you for the test cases.

Karen

> On Oct 30, 2018, at 3:28 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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