harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration
Date Sun, 15 Oct 2006 20:45:05 GMT
Agree on all points.
-- 
Best regards,
Ivan
Intel Enterprise Solutions Software Division

On 10/15/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Weldon, I'll try to answer some of your questions. Ivan and Salikh will
> correct me.
>
> On 10/16/06, Weldon Washburn < weldonwjw@gmail.com> wrote:
> >
> > 1)
> > Mikhail Fursov said, "With this fix JIT precaches all offsets for
> > mananaged
> > pointers in a method before reporting".  Is there a problem if a given
> > live
> > reference appears in several different stack frames of the same thread?
>
>
> You can't have one reference in several stack frames. You can have one
> object with multiple references from different stack
> frames. While enumerating each method in a stack GC set ups "forwarding bit"
> to the old object location and knows how to update all subsequent
> references that point to the old object
> location.
> The problem was with managed pointers with unknown offsets
> only. To calculate the offset during an enumeration JIT subtracts
> the object address (obtained from the references from the current stack
> frame) from the mptr address. If the object is moved during the
> enumeration, the reference is updated and you can't no longer use it to
> find  the offset. With the patch applied JIT calculates offsets before any
> references in a frame are updated.
> Since mptrs live range does not cross the method boundaries, the problem was
> frame local only.
>
> 2)
> > Does this patch include Jitrino.JET, Jitrino.OPT  and the
> > interpreter?  Have
> > all three been tested?
>
>
> AFAIK Jitrino.JET and  interpreter never report MPTRs. So the fix is needed
> for Jitrino.OPT only.
>
> 3)
> > Does this patch comprehend "parallel GC" running on a SMP box?  For
> > example,
> > 4 CPUs simultaneously enumerating 4 java thread stacks that happen to
> > contain live reference pointers to the exact same objects.  Is there a
> > test
> > that demonstrates this behavoir?
>
>
> Since the problem is frame local it is  thread-local too.  I see no problems
> with it.
>
> 4)
> > On Oct 6, Mikhail Fursov said, "I'm agree that GC should not move objects
> > during the enumeration".    But then provided a patch on October 9.  Was
> > the
> > decision to allow objects to move during enumeration documented somewhere?
>
>
> I do not remember such a discussion. The patch makes JIT more flexible. With
> this patch JIT does not need to care if objects are moved or not during the
> enumeration.
>
>
> 5)
> > Is there any impact of the above on GCV5?
>
>
> IMHO No.
>
> 6)
> > Does GCV4 work with jit_gc.diff?
>
>
> Yes. The rootset reported by JIT is the same. The only change is that
> instead of the method 'enumerate(mptr, base)' JIT uses the method
> 'enumerate(mptr, offset)' that was used before only for mptrs with static
> offsets (offsets known during compilation of a method)
>
> 7)
> > Instead of applying jit_gc.diff what about applying
> > retrieve_root_set.diff?
> > If it is now too hard to rollback SVN, how about reopening JIRA1862 and
> > also
> > applying retrieve_root_set.diff also?  The rationale is that there has not
> > been adequate discussion on modifying the semantics of JIT/GC interface.
>
>
> I vote not to rollback JIT patch. JIT is more flexible with this patch
> without any additional cost. The  code is slightly increased (4-6 lines) but
> it makes debugging simpler :)
>
> 8)
> > Note that retrieve_root_set.diff does not impact JIT/VM/GC interfaces.  It
> > is only local to gcv4.1.  Also note retrieve_root_set.diff patch line
> > count
> > is 13 and jit_gc.diff line count is 179.
>
>
> In the JIT patch I cleaned unused enumeration methods from JIT interface,
> added comments and replaced the one large loop with two of smaller
> size(precaching, reporting). The real number of new lines is less than 10.
>
> So IMO the correct fix for this problem is in the trunk. GC has cmd-line
> option to disable object moving during the enumeration and it's enough.
>
>
>
> --
> Mikhail Fursov

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message