review for 7086585: make Java field injection more flexible (original) (raw)

Tom Rodriguez tom.rodriguez at oracle.com
Fri Sep 9 10:41:40 PDT 2011


On Sep 9, 2011, at 10:39 AM, Vladimir Kozlov wrote:

I don't see why you can't calculate offset before calling initialize().

We certainly don't right now so it just seemed silly to require passing 0. I can pass it explicitly if you want.

tom

Vladimir Tom Rodriguez wrote: On Sep 9, 2011, at 10:06 AM, Vladimir Kozlov wrote:

I'm not sure how to factor that in a way that would improve it much. Any suggestions? I mostly worry if later we try to do the same initialization in an other place we will forgot to update some values. So it would be nice to do it by just calling one method: Good point. I dropped the offset argument since that is always filled in later. void initialize(u2 accessflags, u2 nameindex, u2 signatureindex, u2 initvalindex, u2 genericsignatureindex) { shorts[accessflagsoffset] = accessflags; shorts[nameindexoffset] = nameindex; shorts[signatureindexoffset] = signatureindex; shorts[initvalindexoffset] = initvalindex; shorts[genericsignatureoffset] = genericsignatureindex; setoffset(0); // The offset gets filled in later } tom RawFieldDescriptor::init(u2 accessflags, u2 nameindex, u2 signatureindex, u2 initvalindex, u2 genericsignatureindex, u4 offset) { shorts[accessflagsoffset] = accessflags; shorts[nameindexoffset] = nameindex; shorts[signatureindexoffset] = signatureindex; shorts[initvalindexoffset] = initvalindex; shorts[genericsignatureoffset] = genericsignatureindex; setoffset(offset); }

Vladimir Tom Rodriguez wrote: On Sep 8, 2011, at 6:56 PM, Vladimir Kozlov wrote: Thank you, Tom

Very nice cleanup. Thanks. I think there's another possible round of this to simplify the field layout and javaClasses some more but I didn't want to tangle it up with the injection changes. classFileParser.cpp: Can we use an arrays instead of switch to map type to allocation type in FieldAllocationCount::update()? I considered doing that. I'll go ahead and add it. Can we factor out next sequence since it is used in two places?: + RawFieldDescriptor* field = RawFieldDescriptor::fromfieldarray(fields(), n); + field->setaccessflags(accessflags.asshort()); + field->setnameindex(nameindex); + field->setsignatureindex(signatureindex); + field->setinitvalindex(constantvalueindex); + field->setgenericsignatureindex(genericsignatureindex); I'm not sure how to factor that in a way that would improve it much. Any suggestions? tom Thanks, Vladimir Tom Rodriguez wrote: http://cr.openjdk.java.net/~never/7086585 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg 7086585: make Java field injection more flexible Reviewed-by: Classes which are special to the JVM often need fields for the VM's use. Currently the mechanism for this is adhoc or relies on the Java code declaring the needed fields. We need a mechanism for flexibly injecting needed fields. The basic idea is to built a standard mechanism for declaring injected fields and to inject them during class file parsing so that they get laid out and tracked like normal fields. This is also means that they can simply be looked up when CDS is used so we don't have to rely on hardcoding them. To do this I hide the encoding of the fields array and replaced all existing iteration with a new set of *FieldStream classes. JavaFieldStream only iterates true Java fields so the behavious of existing code is completely unchanged. The new fields use a special access flag JVMACCINTERNAL to describe themselves and instead of having the nameindex and signatureindex refer to the constant pool they are vmSymbols::SID so they are looked up directly from the vmSymbols. All of this is hidden inside the RawFieldDescriptor class which is responsible for decoding fields from the field array. I also cleaned up the field layout code a bit. I eliminated the ALIGNED AllocationType since there's no longer any difference in how we align double word types. I turned FieldAllocationCount into a real class and moved some of the layout code into it. I deleted the nonexistent MethodHandle::vmslot field. I moved ClassLoader::parallelCapable into javalangClassLoader. I deleted some dead field injection like the Reference.discovered field which has existed since 1.5, and the existing logic for java.lang.Class fields since it now uses the field injection machinery. Tested with runthese, the sajdi tests, the tmtools suite, the nsk regression, jdb, jdi, jvmti, hprof and jit subsuites along with vm/mlvm, but with and without the JDK changes that remove these fields and rely on injection to introduce them. They will be removed under 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481.



More information about the hotspot-compiler-dev mailing list