[Nestmates] RFR (S): Dynamic nestmate update
mandy.chung at oracle.com
Tue Oct 30 04:17:51 UTC 2018
On 10/29/18 4:35 PM, David Holmes wrote:
>> - 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!
I also considered whether it should be accepted or an error if the
NestHost attribute exists and matches the nest host class being injected
it. I agree with David to separate the static nest membership model
from dynamic nest membership. We can revisit that when there is a good
use case to accept NestHost attribute matching the nest host in the future.
>> - 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.
JVM TI currently restricts that the retransformation must not change the
NestHost or NestMembers attributes. If the class bytes are transformed,
it will remain as a dynamic nestmate and no NestHost and NestMembers
attributes. It seems that the nest host does not need to be known by CFLH.
More information about the valhalla-dev