On Apr 2, 2013, at 2:09 PM, Coleen Phillimore <coleen.phillim...@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
