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 Mon, 09 Oct 2006 11:54:38 GMT
On 09 Oct 2006 14:25:58 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
> BTW, what is mptr? is it 'base + offset' by definition? today I am
> more about dummy questions :)
> 'offset' is sometimes an operand (a mem location or a register) and
> not a mere int. As in our example, when arrays are accessed. Do I get
> it right?

Egor,  the managed (or interior) pointer is a pointer to the middle of the
object. This can be a field pointer, an array element pointer or a pointer
to VM's data in object that is usually stored in the first bytes of an

'offset' usually is const 'int' value if it's known during the compilationt
time. In this case  mptr points to the field of an object. Offset is a
value placed in register or in memory if mptr is a pointer into the middle
of an array and there are no constant offset exists.

In the test that fails the offset within the array is unknown during the
compilation time: it changes inside of the loop.

Is it always easy to deduce which mem address relates to which base
> and preserve that information throughout all high-level optimizations?

I think yes. HLO operations are type safe and CG relies on it.

One example that does not let me sleep well at night.
> Some optimization (strength reduction) can convert a code like this:
> for (int i = 0; i < length; i++) {
>     A[A.base + i * sizeof(elem)] = X
> }
> to something like:
> for (int i = A.base; i < A.base + length * sizeof(elem);
>      i += sizeof(elem) ) {
>     A[i] = X
> }
> we need to report 'i' as a base + offset. Where is the base? Reporting
> 'i' as interior (to search A.base at runtime) has been easy, but now
> it is not supposed to work. What do we offer instead?
> Mikhail, maybe, your strategy covers that situation well, I just want
> be happy understanding all these things.
> In this case we do not know the offset during the compilation time. So
Jitrino.OPT will do the following
1) Make the base (the array opnd) to live through the whole loop
2) When reporting mptr Jitrino.OPT look for the nearest known base in memory
and report it as base for the managed pointer.
Subtracting the base address from mptr address we get the offset. The bug
reason is that GCv4.1 moves base object before we found the valid offset.

Mikhail Fursov

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