harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Thu, 05 Oct 2006 12:08:36 GMT
On 05 Oct 2006 18:35:23 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
> > So once managed pointer has no known static offset (the offset is
> > MAX_INT) the base is searched in runtime as I described above.
> should we document this? :)

I think  we should document the whole JIT.  The question is when :) ? I hope
the internal testing framework for Jitrino.OPT compiler will quicken it.

I don't quite well understand how an object reference is not reported
> at compile-time, but found at runtime.. Sniffing refs on a stack
> frame? Hm, is there any reason I thought Jitrino is not like that?...

 The log you pointed to is the log from MPTR resolving algorithm. This
algorithms is not interested in bases.
If you want to know all items that are reported to GC you should look for
GCInfoPseudoInst that are interested by GCMap pass. GCMap pass inserts these
insts after each call only for the logging purpose. The same
GCInfoPseudoInst is inserted by 'gcpoints' pass on the beginning of code
generation to extend bases life range for managed pointers with unknown
Doing this we can guarantee that for every managed pointer with unknown
offset we have valid base pointer at every call.

So, the only way to detect all reported objects on a call-site is to
> stop on the call-site at runtime during enumeration? Not
> impressed. Does it log to the runtime log (rt.log) currently? I tried
> "-Djit.log=rt", but it produced no result. Is that a bug?

No, try -Djit.arg.log=rt or -Djit.CS_OPT.arg.log=rt to enable runtime
logging category.

Mikhail Fursov

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