nestmates JVMTI spec proposal changes

[Remi Forax]

Given that we will have a NestMate phase 2, i agree with Dan, we can revisit that point later. 

Rémi 

> De: "Daniel Heidinga" <Daniel_Heidinga at ca.ibm.com>
> À: "Karen Kinnear" <karen.kinnear at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 20 Décembre 2017 16:58:03
> Objet: Re: nestmates JVMTI spec proposal changes

> We're on board with this proposal. Any change to the NestMembers, adding or
> removing members, should fail redefinition. As should changes to NestHost.
> Taking this approach now eases the implementation costs and allows us to
> re-examine this in the future.
> --Dan

>> ----- Original message -----
>> From: Karen Kinnear <karen.kinnear at oracle.com>
>> Sent by: "valhalla-spec-experts"
>> <valhalla-spec-experts-bounces at openjdk.java.net>
>> To: valhalla-spec-experts <valhalla-spec-experts at openjdk.java.net>
>> Cc:
>> Subject: nestmates JVMTI spec proposal changes
>> Date: Tue, Dec 19, 2017 5:47 PM

>> I believe we are all in agreement that:
>> 1. Redefinition should NOT be allowed to change the NestHost attribute and
>> 2. Redefinition should NOT be allowed to remove NestMembers (equivalent to
>> reducing access controls)
>> The question was - should we allow Redefinition to add NestMembers or not?
>> Hotspot team would like to propose that at least for the initial nestmates
>> release - we do NOT allow
>> Redefinition to add NestMembers.
>> In all cases, NOT allow would mean a failure to redefine a class.
>> Open to suggestions on error that should be returned.
>> This is the least risky approach and allows future reducing restrictions if we
>> find we need to. It is
>> extremely difficult to increase restrictions.
>> Discussion:
>> JVMTI redefinition restrictions today:
>> The redefinition may change method bodies, the constant pool and attributes. The
>> redefinition must not add, remove or rename fields or methods, change the
>> signatures of methods, change modifiers, or change inheritance. These
>> restrictions may be lifted in future versions. See the error return description
>> below for information on error codes returned if an unsupported redefinition is
>> attempted. The class file bytes are not verified or installed until they have
>> passed through the chain of [
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_8_docs_platform_jvmti_jvmti.html-23ClassFileLoadHook&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=o8e88cUxfs0Xn3ibrFYJf9-m6XEnAau1Hr_tRPsFNqE&s=J0Lf6yC70kW4MaNf8VLwXaPcEPV4wj0IAIH3yWGvI7Q&e=
>> | ClassFileLoadHook ] events, thus the returned error code reflects the result
>> of the transformations applied to the bytes passed into [
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_8_docs_platform_jvmti_jvmti.html-23RedefineClasses.class-5Fdefinitions&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=o8e88cUxfs0Xn3ibrFYJf9-m6XEnAau1Hr_tRPsFNqE&s=F0smHtdTXv7JiNt8sNItG9TAJfAT4UHZdHEId0HXWpQ&e=
>> | class_definitions ] . If any error code is returned other than
>> JVMTI_ERROR_NONE , none of the classes to be redefined will have a new
>> definition installed. When this function returns (with the error code of
>> JVMTI_ERROR_NONE ) all of the classes to be redefined will have their new
>> definitions installed.
>> Note that redefinition today is not allowed to change modifiers or change
>> inheritance, so no changes that could change access control
>> behavior.
>> The jigsaw AddExports allows dynamic increasing of access to types. To ensure
>> that resolution
>> of a constant pool type entries that fails always fails in the same way, the
>> implementation must cache those
>> failures.
>> If we were to allow dynamic increases in member access, to ensure that
>> resolution of content pool member
>> entries (fields, methods) would fail in the same way, the implementation would
>> need to cache those
>> resolution failures, which is non-trivial, and would need to ensure that the
>> redefinition implementation
>> retained errors for resolution from other types.
>> Note that Redefinition is allowed to change inner class attributes today;
>> however those do not
>> have any affect on the JVM, they just change what reflection returns.
>> Redefinition does not
>> allow adding trampoline methods.
>> thanks,
>> Karen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20171220/d2670fab/attachment.html>