[Nestmates] RFR (S): Dynamic nestmate update

David Holmes david.holmes at oracle.com
Mon Oct 29 23:35:13 UTC 2018


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


More information about the valhalla-dev mailing list