Re: [Gc] C optimizer hazards in practice

On 07/14/2014 06:43 AM, Hans Boehm wrote:
> Are we talking about more than one kind of problem?

Yes, although I took a tangent when asking if anyone is using a
disguised pointer scheme,
because that would make it somewhat more likely to run into these kinds
of problems.

The reason for this is that most if not all ABIs require passing
"normal" pointers, which will
make them end up on the stack or in registers undisguised, rooting them
even if the compiler
uses fancy addressing mode tricks like the one described in the initial
report.

>
> I think the question was about a compiler, under the covers,
> maintaining the last pointer in a form no longer recognizable by a
> conservative garbage collector, possibly only temporarily.  The case
> of this I remember from many years ago is that the preferred way to
> add a large constant offset to a pointer on POWER was to first add a
> multiple of 2^16, and then use a 16 bit signed displacement to access
> the referenced value.  This often means that the pointer after the
> initial addition points to past the end of the object and is not
> recognizable by the GC.  But such signed constant offsets are
> exceedingly rare, and a compiler can easily avoid this problem if it's
> aware of the issue.

After studying the MPS report further I was pretty astonished that the
Microsoft CC hides pointers like this,
however it does make sense as an optimization that tries to use more
efficient shorter-range addressing modes,
just as you describe on POWER.

Indeed this is something that really needs to be addressed at the
compiler level.

> I could construct an example of this in contrived code.  I vaguely
> recall one or two instances of people pointing out such problems in
> real code, but I don't recall the details.
>
> Compiler dead variable elimination is a problem only in the sense that
> cases like this don't matter if the compiler also keeps a copy of the
> original base variable around.
>
> Compiler dead variable elimination by itself  can case finalizers on
> an object to run while a method on the object is still executing.  But
> I think that's a different issue.
>

Greetings
  prom