Values round tripped Julia -> R -> Julia -> R are lost

[frankier]

Values round tripped Julia -> R -> Julia -> R are lost.

Not keeping handles on references (see: #444 ) is a reasonably probable cause.

using RCall

get_arg(arg) = arg
get_arg_r(arg) = R"""$(arg)"""
get_r_val() = R"""42"""
get_roundtripped() = R"""$(get_r_val())"""

print("# Trips that don't contain Julia -> R -> Julia -> R are okay")
@info "Julia -> R -> Julia (okay)" get_arg_r(42)
@info "Julia -> R -> Julia (okay)" R"""$(get_arg(42))"""
println("R -> Julia -> R (okay, from R)")
R"""print($(get_r_val()))"""
@info "R -> Julia -> R -> Julia (okay)" R"""$(get_r_val())"""
println()

println("# Julia -> R -> Julia -> R gets lost")
println("Julia -> R -> Julia -> R (lost, from R)")
R"""print($(get_arg_r(42)))"""
println()

println("# Trips containing Julia -> R -> Julia -> R get lost")
@info "Julia -> R -> Julia -> R -> Julia (lost)" R"""$(get_arg_r(42))"""
println("R -> Julia -> R -> Julia -> R (lost, from R)")
R"""print($(get_roundtripped()))"""

# Trips that don't contain Julia -> R -> Julia -> R are okay┌ Info: Julia -> R -> Julia (okay)
│   get_arg_r(42) =
│    RObject{IntSxp}
│    [1] 42
└
┌ Info: Julia -> R -> Julia (okay)
│   R"$(get_arg(42))" =
│    RObject{IntSxp}
│    [1] 42
└
R -> Julia -> R (okay, from R)
[1] 42
┌ Info: R -> Julia -> R -> Julia (okay)
│   R"$(get_r_val())" =
│    RObject{RealSxp}
│    [1] 42
└

# Julia -> R -> Julia -> R gets lost
Julia -> R -> Julia -> R (lost, from R)
NULL

# Trips containing Julia -> R -> Julia -> R get lost
┌ Info: Julia -> R -> Julia -> R -> Julia (lost)
│   R"$(get_arg_r(42))" =
│    RObject{NilSxp}
│    NULL
└
R -> Julia -> R -> Julia -> R (lost, from R)
NULL
RObject{NilSxp}
NULL

[palday]

Hmmm, I think this is actually maybe acceptable behavior? If you had a named variable on either side, i.e. if the value had an associated binding, then that would stop garbage collection. But both R and Julia allow unbound values to be garbage collected.

Did you discover this in a more complicated context? I'm wondering if a slightly less minimal example would help me better understand the problem-in-practice vs. wat-in-principle.

This is also related to the somewhat surprising behavior of == with wrapped objects (#512).

[frankier]

Yes, I did encounter this in actual code. As you see above there are round trip scenarios where it does not occur (or at least doesn't occur deterministically) so this is perhaps the reason it's not been encountered a lot yet in real code.

I thought a minimal example would be more useful, but here is (almost) the exact code snippet in practice:

function _get_par_int(config)
    return R"""c(
        $(config.lower),
        $(config.upper),
        $(config.nqp)
    )"""
end

function _update_theta_est(config)
    config.theta = R"""
    thetaEst(
        extract_items($(config.item_bank), $(config.responses.indices)),
        $(config.responses.values),
        D=$(config.d_constant), 
        method=$(config.method),
        priorDist=$(config.prior_dist),
        priorPar=$(config.prior_par),
        parInt=$(_get_par_int(config))
    )
    """
end

Note that this caused quite confusing errors within thetaEst where a res variable that is definitely assigned said to be not found (REvalError: Error in thetaEst(extract_items(#JL$(config.item_bank), #JL$(config.responses.indices)), : object 'res' not found). It took me a while to track down this problem to RCall. https://github.com/cran/catR/blob/112a2efb6621fed446a5df4b1467e4bfe937ab81/R/thetaEst.R#L4

Of course this opens us up to criticising this code and working around the problem -- but there's no need -- I agree it's not the best way to go about doing this and know how to deal workaround the issue/restructure the code to be better. Nevertheless, it doesn't remove the underlying correctness issue and is sufficient to show that this problem can be encountered in practice.

If you had a named variable on either side, i.e. if the value had an associated binding, then that would stop garbage collection. But both R and Julia allow unbound values to be garbage collected.

But in this example, should there not be a reference kept the whole time? I'm not 100% sure yet what the exact cause is, but if it is to do with reference counting/garbage collection as seems most likely then e.g. the reference count should be incremented from Julia before it's decremented in R, so that the object doesn't disappear. In general in most languages we don't expect to have give things values bindings to stop them disappearing, so these expected semantics should be preserved in our "Julia + R language" if possible. (And if it's not possible we should add something to the documentation about situations where this can occur.)

But both R and Julia allow unbound values to be garbage collected.

I don't think that's true. Otherwise I couldn't have composite expressions like a = 40 + (1 + 1), because 1 + 1 would be collected before it could be added to 40.

This is also related to the somewhat surprising behavior of == with wrapped objects (#512).

I'm not sure if I see the connection -- equality-as-identity is a bit less surprising and IIRC is how it works for objects in Java (although it's not my preference).

---

At any rate, if you accept this as an issue let me know if you want to tackle it yourself or have me take a deeper look myself at some point.

[palday]

I thought a minimal example would be more useful

Almost always, yes! But I like to understand both the technical problem and the use problem. 😄

But both R and Julia allow unbound values to be garbage collected.

I don't think that's true. Otherwise I couldn't have composite expressions like a = 40 + (1 + 1), because 1 + 1 would be collected before it could be added to 40.

The lack of a reference is exactly the criterion for garbage collection. In the case of 1 + 1, the formal semantics are that an object representing the vale "1" is created for each 1. In practice that's not the case due to various optimizations (some related to immutability, some related to the isbits nature of integers, some additional ones) but also the resulting entity isn't unbound because it's being passed as a second argument to +. The issue when you cross the language boundary is that each runtime is keeping a separate reference and the associated variables fall out of scope and thus the values unbound when moving back and forth. The interpolation used in evaluating various expressions adds another layer of indirection that makes it easy to lose the reference.

I'm not surprised by this behavior, but I think fully fixing it will require a fairly massive refactoring (which I have been working for a while now on when I have a few minutes).

This is also related to the somewhat surprising behavior of == with wrapped objects (#512).

Ah by this I meant not the == vs. === distinction, but rather that the fallback is used at all because == is evaluated on the Julia side instead of the R side. So you get some wonky behavior like

julia> robject(R"42").p
Ptr{RealSxp}(0x0000000016ca2060)

julia> robject(R"42").p
Ptr{RealSxp}(0x0000000019ea9780)

R> d <- 42

julia> robject(R"d").p
Ptr{RealSxp}(0x000000001a27df88)

julia> robject(R"d").p
Ptr{RealSxp}(0x000000001a27df88)

For the literal 42, R creates a new object each time and so the value of the pointers are different. But for the binding d, there is only object so the pointer values are the same.

So in your example, you have

function _get_par_int(config)
    return R"""c(
        $(config.lower),
        $(config.upper),
        $(config.nqp)
    )"
end

I suspect the issue is related to the interpolation bit. I vaguely remember that interpolated RObjects (that don't have a reference on the R side -- we actually do notify R that we have a pointer to prevent garbage collection, but there is no associated binding on the R side) can be weird.

(I also got very confused by something similar when I was initially developing JellyMe4.jl)

Can you try

function _get_par_int(config)
    return rcopy(R"""c(
        $(config.lower),
        $(config.upper),
        $(config.nqp)
    )""")
end

?

[frankier]

Adding rcopy doesn't make a difference:

using RCall

get_arg(arg) = arg
get_arg_r(arg) = rcopy(R"""$(arg)""")
get_r_val() = rcopy(R"""42""")
get_roundtripped() = rcopy(R"""$(get_r_val())""")

print("# Trips that don't contain Julia -> R -> Julia -> R are okay")
@info "Julia -> R -> Julia (okay)" get_arg_r(42)
@info "Julia -> R -> Julia (okay)" R"""$(get_arg(42))"""
println("R -> Julia -> R (okay, from R)")
R"""print($(get_r_val()))"""
@info "R -> Julia -> R -> Julia (okay)" R"""$(get_r_val())"""
println()

println("# Julia -> R -> Julia -> R gets lost")
println("Julia -> R -> Julia -> R (lost, from R)")
R"""print($(get_arg_r(42)))"""
println()

println("# Trips containing Julia -> R -> Julia -> R get lost")
@info "Julia -> R -> Julia -> R -> Julia (lost)" R"""$(get_arg_r(42))"""
println("R -> Julia -> R -> Julia -> R (lost, from R)")
R"""print($(get_roundtripped()))"""

# Trips that don't contain Julia -> R -> Julia -> R are okay┌ Info: Julia -> R -> Julia (okay)
└   get_arg_r(42) = 42
┌ Info: Julia -> R -> Julia (okay)
│   R"$(get_arg(42))" =
│    RObject{IntSxp}
│    [1] 42
└
R -> Julia -> R (okay, from R)
[1] 42
┌ Info: R -> Julia -> R -> Julia (okay)
│   R"$(get_r_val())" =
│    RObject{RealSxp}
│    [1] 42
└

# Julia -> R -> Julia -> R gets lost
Julia -> R -> Julia -> R (lost, from R)
NULL

# Trips containing Julia -> R -> Julia -> R get lost
┌ Info: Julia -> R -> Julia -> R -> Julia (lost)
│   R"$(get_arg_r(42))" =
│    RObject{NilSxp}
│    NULL
└
R -> Julia -> R -> Julia -> R (lost, from R)
NULL

Good luck with your refactoring!