Re: Page faults and libgcj.so startup time

[Per Bothner <per at bothner dot com>]

Tom Tromey <tromey@redhat.com> writes:

> Another even uglier idea would be to have all the Utf8Consts and other
> static data for a class be written as one big chunk of data, and then
> use offsets into that structure in various places.  This would reduce
> the number of data relocations to one per class.  This would require
> changes all over.

I don't think it would be that bad, and it could save space. Let us
optimize for "short" method descriptors, using 8 bytes per method
instead of 16 (or 32 bytes on 64-bit architectures).

struct _Jv_Method
{
  /* high-order bit set indicates a "long" method descriptor,
     which means the following _Jv_Method is also used for this method.
     rest of bits are access flags etc. */
  u16 flags;

  /* Offsets into class's compressed string table.
     Multiple classes compiled together share a string table. */
  u16 name;
  u16 signature;

  /* If method is virtual, offset into vtable, otherwise offset into
     class's pointer array. */
  u16 code;
};

This halves the metadata needed for methods, assuming we pick some
simple compression scheme for strings that halves the space needed.
We also remove 2 or 3 relocations per method, which not only
improves start-up time, it also reduces disk size even more.

Each class would also have a slot for an array of java.lang.reflect.Method
instances, which would contain the reflective data after uncompression.
This slot is initially null.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/