harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] dynamic object layout
Date Sat, 04 Nov 2006 21:18:37 GMT
On 11/4/06, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
>
> Weldon,
>
> I agree with you that it is nearly impossible to achieve stability for
> a branch under active development.
>
> From the other side, adding new features is fun, and also has a reason
> behind it. If we strive for a complete implementation of J2SE, we
> cannot avoid this type of activity.
>
> So my suggestion is to create separate branches for new features which
> could be merged into the main branch when mature enough to achieve an
> appropriate level of stability. What do you think?


As much as I hate it, I don't know how to avoid branching.  Also, we
probably need some sort of JIRA coding to reflect which branch has which
patches.


Alexei
>
> On 11/3/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > Salikh,
> >  I glanced at the patch.  What you propose below looks reasonable.  I
> really
> > don't see any other way to do it and still get "usable" performance.
> >
> > All,
> > My only worry is disturbing highly critical code like object
> layout.  Given
> > that this JIRA has been open a long time, I guess its OK to apply the
> > patch.  At some point, we need to stop adding functionality and focus on
> > stability.
> >
> >
> >
> > On 11/3/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > >
> > > Hi,
> > >
> > > I am currently continuing to work on improving JVMTI Heap Iteration
> > > (HARMONY-1635),
> > > particularly, tagging objects.
> > >
> > > The use case that I've heard of is tagging *all* objects for the
> purpose
> > > of memory
> > > profiling. According to what I've heard it causes 60x slowdown on
> Sun's
> > > VM.
> > > However, the initial tags implementation that I've uploaded to
> > > HARMONY-1635
> > > is far worse, as it uses linear search for get/set tag operations.
> > >
> > > (* for those who didn't read JVMTI spec, tags are jlong (8 byte
> integer)
> > > values,
> > > which can be attached to arbitrary objects in get/set manner *)
> > >
> > > The alternative approach I came up with is to use (mostly) constant
> time
> > > algorithms
> > > for get/set operations, is to store a tag pointer in each object.
> > > Storing tag itself in an object is not an option, as JVMTI requires to
> > > send
> > > OBJECT_FREE events with tags for each reclaimed objects, and this
> > > information would not be
> > > available if the tag would be reclaimed together with the object.
> > >
> > > However, since the general consensus was that increasing object header
> is
> > > highly undesired,
> > > I've tried to implement the _conditional_ increase in object header.
> > > Additional object header field is allocated in case JVMTI Agent has
> > > requested
> > > can_tag_objects capability.
> > >
> > > The modified object layout I used is as follows:
> > >
> > > +-------------------+
> > > |   VTable pointer  |
> > > +-------------------+
> > > |      lockword     |
> > > +-------------------+
> > > |   [array length]  |
> > > +-------------------+
> > > |   [tag pointer]   |
> > > +-------------------+
> > > |    [padding]      |
> > > +-------------------+
> > > | fields or elements|
> > > |       ...         |
> > > +-------------------+
> > >
> > > Where [array length] is only present in array objects,
> > > [tag pointer] is only present when can_tag_capability has been enabled
> at
> > > startup
> > > [padding] is only present in arrays of longs and doubles for natural
> > > 8-byte alignment.
> > >
> > > VTable pointer is really uint32 offset on em64t/x86_64 and ipf/ia64.
> > >
> > > The only difference with current object layout is introduction of tag
> > > pointer field.
> > >
> > > I've modified gc_cc to take the changed dynamic object layout into
> > > account,
> > > and surprisingly it took only one modification:
> > >
> > > * use VM function vector_first_element_offset_unboxed() instead of
> > > hardcoding
> > > first array element offset. This is done once for each class done at
> > > loading stage,
> > > and gc_cc caches this offset for later uses.
> > >
> > > I've experimented with putting tag pointer at fixed location before
> array
> > > length,
> > > but it looks expensive, as it will add one more read to GC array
> scanning,
> > > and
> > > we obviously do not want optimize at the expense of common case.
> > >
> > > The latest version of the patch is attached to HARMONY-1635 (
> > > heap-iteration-optimized.patch),
> > > I would appreciate any comments and concerns.
> > >
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
> --
> Thank you,
> Alexei
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message