[bitc-dev] Capture problem with by-ref

[Swaroop Sridhar]

Jonathan S. Shapiro wrote:
> On Wed, 2008-03-12 at 14:14 -0400, Swaroop Sridhar wrote:
>> This is actually not precise wrt what I said yesterday.  I said (or at
>> least meant to say) that a capture of a by-ref formal variable (x) by an
>> inner lambda (L) is safe only if:
>>
>> (1) L does not escape,   or
>> (2) The body of L does not use x as an lvalue that is a target of an
>>      assignment.
>>
>> If (1) holds, we don't have a problem since nothing escapes. However,
>> this requires that we perform a closure escape analysis.
>>
>> If (2) holds, we only need a copy of the by-ref argument in the closure.
>> That is, the closure contains a de-referenced shallowly immutable
>> version of the by-reference argument.
> 
> Unfortunately, your statement [2] is wrong. Counter-example:
> 
>   (define (g)
>     (let ((local : (mutable int32)  1)
>       (letrec ((closure
>                  ((lambda (lref:(by-ref (mutable 'a)))
>                     (lambda (x)
>                       (set! lref (+ lref 1))
>                       (+ lref x))) local)))
>         (pair (closure 1) (closure 1)))))
> 
> If your theory were correct, the result should be (2, 2). But it is
> clear here that the outer lambda has closed over "local" by means of
> application, and the correct answer must be (2, 3).

I don't see why (2) is wrong here. The inner lambda (with parameter x)
escapes because it is being returned, so (1) is not satisfied). It
assigns a non-local by-ref variable lref so (2) is not satisfied. So,
this definition would be rejected by the compiler.

Maybe what went wrong is that when I said L is an inner lambda, it was
not clear that x is a non-local by-ref variable? Functions should
definitely be able to mutate their own by-ref variables.

I think I misunderstand the real problem you are pointing out.

> SIMPLE:  No captured formal parameter of BY-REF type is permitted to
>          escape.
> 
> REFINED: A BY-REF parameter can be captured and allowed to escape
>          exactly if the compiler can statically determine that the
>          aliased actual parameter can be heapified.
> 
> For now, I think it is best to go with the simpler rule. The refined
> rule can be handled by an escape analysis pass that re-writes those
> cases of BY-REF into simple REF. Since that is a backwards-compatible
> relaxation of language constraints, it can be done later. Better still,
> adding it later will not impact the later pass that checks the simple
> rule.

Regardless of my above paragraph, I agree that the simple solution is
probably best and sufficient to solve the problem.

Swaroop.