[Nestmates] RFR (S): Dynamic nestmate update
mandy.chung at oracle.com
Tue Oct 30 16:06:23 UTC 2018
On 10/30/18 7:00 AM, Karen Kinnear wrote:
> Agree with setting the dynamic_nest_host before publishing.
> Agree with disallowing mixing static and dynamic membership.
> JVMTI - not clear on this one. The CFLH generally does not follow the JVMTI restrictions, since it
> is viewed as completely replacing the class file before it is ever seen, so there are currently (AFAICT)
> no restrictions on what can be done at this time.
> I don’t know the best way to handle that. One approach would be to just throw the current ClassFormatError
> and agent authors will learn that they can not define NestHost or NestMembers even at CFLH time.
That's one option. This will fail fast to catch the agent error early
in particular useful when multiple agents enable CFLH event and may
modify the same class. This incurs additional class file parsing
overhead for each modified byte stream that may be a concern to
monitoring agents that are deployed in production.
The other option (which is what I was referring to) is to detect the
error when the modified byte stream is parsed, i.e. the same behavior as
when the bytes passed from Lookup::defineClass contains NestHost or
NestMembers attribute. When multiple agents enable CFLH event, it's
harder to diagnose the issue. This is an error case and CFE will be
thrown. Adding the overhead verifying each modified byte stream seems
too high to catch an uncommon error case.
> They certainly have no way to distinguish dynamically defined classes from statically defined classes.
> Perhaps it would make sense to add the the JVMTI specification that this is true even at CFLH time?
> If so, we would need to perform a before/after check.
>> On Oct 30, 2018, at 12:17 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 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