review for 7086585: make Java field injection more flexible

Christian Thalinger christian.thalinger at
Fri Sep 9 02:05:36 PDT 2011

On Sep 8, 2011, at 10:38 PM, Tom Rodriguez wrote:

> 1577 lines changed: 621 ins; 612 del; 344 mod; 65541 unchg


1120                 // TypeArray klfields = kls.getFields();

You want to keep this line?

Otherwise this looks good.

> 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 JVM_ACC_INTERNAL to describe
> themselves and instead of having the name_index and signature_index
> 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 java_lang_ClassLoader.  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

That looks good too.

-- Christian

More information about the hotspot-compiler-dev mailing list