Re: [drlvm] dynamic object layout

[Geir Magnusson Jr.]

Alexei Fedotov 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?

Well, there's a couple of things here.  Any committer is free to go off 
into a sandbox to do something radical.  However, there are features we 
simply need - class unloading, for example - that aren't new features 
being done just for fun.

Things are complicated and we've seen how some features from the past, 
say the TM or invocation API, were done off in a corner, that led to two 
problems when brought forward -

1) There were lots of others that had useful input who weren't able to 
contribute until the feature was finished  and

2) The iterations of discussion about the patch while ongoing progress 
was happening in the trunk made the big patches stale, which made it 
hard for people to examine, test and comment on.

I think that for something like this, we should evaluate the "new ideas" 
on the merit, and decide if it's critical to our goal of a competitive, 
compatible Harmony v1.0 (for example, class unloading) or simply a 
nice-to-have improvement (GCv5, maybe).

We have a really difficult job to do in the next 7.5 months - to get to 
a compatible 1.0* - so I'd like to encourage people to remain as focused 
as we can to get to that point.  That doesn't mean this isn't fun, but 
the way I see it, we have a few focused months of efforts before we 
begin TCK testing, and we probably need to make some hard choices to 
delay stuff.  We're a mighty community, but a relatively small one, so 
the more of us rowing in the same direction, the better.

So if JVMTI is slow?  What's the tradeoff?  My persoal perference would 
be to take stability for now, and revisit the JVMTI  performance later...

geir

* Yeah, I dream of Harmony as the first compatible open source 
implementation of the JDK, beating Sun...



Alexei

On 11/3/06, Weldon Washburn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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