Re: [Gc] C optimizer hazards in practice

On 16 Jul 2014, at 04:02, "Richard A. O'Keefe" <ok-JtFlkrn/[email protected]> wrote:

> 
> On 16/07/2014, at 3:02 AM, Ingo Albrecht wrote:
> 
>> 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.
> 
> There are actually two senses in which a pointer may be "disguised".
> (1) The TYPE of the pointer may be disguised.
> (2) The VALUE of the pointer may disguised.
> 
> My reading of the MPS report is that case (1) applied.
> In the C code, pointers were being passed around as
> suitably sized integers, then being converted at the
> point of use.  The Microsoft compiler applied optimisations
> to the integer value that were perfectly valid as integer
> optimisations.  This meant that (2) was being injected by
> the compiler itself.
> 
> My Smalltalk system has types
>    Word  (= uintptr_t)
>    SWord (= intptr_t)
>    Ptr = Word*
> and everything gets passed around as a Word.  This is
> definitely case (1).  I'm not doing anything weird to
> the bits (except for adding 1), but I *am* effectively
> lying to the compiler about the type.  I'm wondering
> whether I ought to replace Word by Ptr.
> 

Two points:

1. Casting pointers through integers is a common way to manipulate them in runtime systems and so the optimisation does reduce the set of programs we can successfully work with. Bear in mind that in many cases we (the GC implementors) have no power to alter the source code of the mutator program, and that requiring changes reduces the value of conservative drop-in GC.

2. We believe we have a repro using pointer types. We're working on inducing a failure with it now.

Extra bonus point:

3. The MPS has no difficulty with disguised references provided the client program's registers a decoding scanner.