Weldon, I'll try to answer some of your questions. Ivan and Salikh will correct me.
On 10/16/06, Weldon Washburn < [EMAIL PROTECTED]> 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
