Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mike.fursov@gmail.com designates
 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=c9lMayX6S5d6bWF7B4R6m4dcNNZ0KrDSQ5Ygv3U1lpS6UjyiBPHRtNq48/L5qvW3uMsvhbY/hPUWu+tgYqhvjv0voBobkEs3mbCNjHo3XmJb2wfGP4U72ZQg4IheRwv57xUfj5JQHSb1h9Kfedj/wfbHegFTylXzxhdn1PDtLPo=
Message-ID: <bc79dd600610151257r58e0a8f9ka19306e39cf43b64@mail.gmail.com>
Date: Mon, 16 Oct 2006 02:57:05 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][JIT/GC] Questions on JIRA-1682, incorrect gc enumeration
In-Reply-To: <4dd1f3f00610151128g2492238bpff3c2480a89d5782@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_40991_6045292.1160942225348"
References: <4dd1f3f00610151128g2492238bpff3c2480a89d5782@mail.gmail.com>

------=_Part_40991_6045292.1160942225348
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_40991_6045292.1160942225348--