hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition

[serguei.spitsyn at oracle.com]

I've filed a bug on this:
   https://jbs.oracle.com/bugs/browse/JDK-8012162

Thanks,
Serguei

On 4/12/13 3:12 PM, John Rose wrote:
> On Apr 2, 2013, at 2:09 PM, Coleen Phillimore 
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> 
> wrote:
>
>>> Also, the decision how to represent the MNT depends on its future 
>>> usage by the compiler team.
>>> As we agreed, the compiler team is going to adjust the MNT to their 
>>> needs
>>> at some point when it is more convenient for them.
>>> So that, could we make a final decision when the whole picture is ready?
>>> It would be better to approach it in some steps.
>>> Currently, this bug blocks other work on the JVMTI support of jsr-292.
>>
>> I don't know what the jsr 292 team has in store for this field but 
>> it's still a footprint cost that's for only a special case.  So this 
>> is okay if you file a bug so that we can remove it and reimplement 
>> this table to be global or a hashtable.
>
> FTR, I would prefer to reimplement it as an optional attribute of 
> java.lang.Class, so that JDK code can access it.  This will cut down 
> on the number of native-to-Java transitions (JNI calls).  By "optional 
> attribute" I mean something like ReflectionData, or even a field of 
> ReflectionData itself.
>
> — John