[Nestmates] RFR (S): Dynamic nestmate update
david.holmes at oracle.com
Mon Oct 29 23:35:13 UTC 2018
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.
> 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
More information about the valhalla-dev