violation of GC safety

[vtjnash]

the MVector violates gc safety when it contains non-bitstypes (it lacks a write barrier), resulting in the possibility that the gc will lose the object and delete the objects in the array while still in-use:

StaticArrays.jl/src/MVector.jl

Lines 49 to 50 in 1e18069

	else # TODO check that this isn't crazy. Also, check it doesn't cause problems with GC...
	unsafe_store!(Base.unsafe_convert(Ptr{Ptr{Void}}, Base.data_pointer_from_objref(v.data)), Base.data_pointer_from_objref(val), i)

[andyferris]

Thank you very much Jameson! I was quite worried about this, and was hoping someone more knowledgeable/cleverer than I would take a look someday. (You might be able to tell from the comment).

Can you point me somewhere that explains the correct procedure, or an example of where the correct procedure is implemented? Otherwise I'll have to make that branch an error for now (it's probably not used in the wild).

[vtjnash]

I don't think it's possible to implement correctly, maybe @yuyichao can say for certain?

[yuyichao]

In additional to gc safety issue, this also violate the immutability since the tuple is not inlined if the type is not a bits type so this is not really fixable.

The GC safety can be worked around (does not apply here due to the immutable issue) by writing llvm code using llvmcall that triggers the write barrier manually. (Do note that the llvm code is different on 0.4 and 0.5). This is not recommended for obvious reasons.

[andyferris]

In additional to gc safety issue, this also violate the immutability since the tuple is not inlined if the type is not a bits type so this is not really fixable.

I don't understand this. I'm not sure what you mean by inlined. I think I've found the correct bit of memory to write the pointers to. MVector is not an immutable type - it's immutable fields can be replaced (wholly, or partially as an optimization, right?). setindex! is not defined on SVector.

The GC safety can be worked around (does not apply here due to the immutable issue) by writing llvm code using llvmcall that triggers the write barrier manually. (Do note that the llvm code is different on 0.4 and 0.5). This is not recommended for obvious reasons.

Or calling an appropriate C function, I assume? Maybe there is something I'm missing.

[yuyichao]

AFAICT MVector is a mutable type and the field cannot be partially replace if not inlined.

Or calling an appropriate C function

Sure, if you write your own.

[yuyichao]

Inlined means the memory of the field is, .... well ...., inlined and the field is not a reference to another piece of memory.

[andyferris]

Inlined means the memory of the field is, .... well ...., inlined and the field is not a reference to another piece of memory.

Right. From playing it seems that the pointer to my MVector is like a C-array of pointers to the elements, if T isn't isbits but is concrete (i.e. a heap-allocated NTuple of references/pointers). Currently it just copies the pointer across to the new location, and I figured the GC would find it on its next scan.

Is the problem with GC that some of my code might be executed in-between this GC scan and the actual deletion? During this function a reference to the new data should exist on the stack, so at all times there should be at least one or at least two references to the to-be copied value. But if the function exits and my MVector is not rescanned is there a moment the GC thinks no reference exists? Sorry, I'd just like to understand better... I don't even know what the write barrier is used for (what exactly do we not want to be written to?). My understanding of GC is pretty simplistic - it scans the stack and its references and all their references and so-on, and deletes all the stuff it doesn't find - and obviously execution has to be paused somehow while this occurs.

[yuyichao]

There are two problems immutability and GC safety. The inlining of the field has nothing to do with the GC, only the immutability.

1. Immutability

   It is not allowed to modify immutable memory after it's created. Immuable memory is memory that is allocated for a immutable object (i.e. object of immuable type). For non isbits type, the data field is immutable memory and must not be modified.

2. GC safety

   Simply speaking, updating a field need to do more than just storing to the memory location for a generation GC (or most GC except the most naive ones) to work correctly, i.e. unsafe_store! may not be enough to make the GC discover the mutation.

[andyferris]

It is not allowed to modify immutable memory after it's created. Immutable memory is memory that is allocated for a immutable object (i.e. object of immuable type).

Definitely true on the stack. It is possible to mutate global consts even if they are immutable, but I suspect that is not "allowed" by the language and constitutes undefined behaviour. Julia is successful at stopping you getting stack pointers to immutables, which is really nice that we can enforce the language semantic there but it is damn frustrating when you want to pass a small stack-allocated vector to BLAS without slow allocation/GC.

But I have to disagree when the immutable thing descends from a mutable type somewhere. An obvious case: I can always reinterpret a Vector{NTuple{N,Float64}} as a Matrix{Float64} with N rows. I can create the vector as immutable tuples. and according to your statement, I must only replace entire tuples since each is "immutable memory that is allocated for an immutable object", and never mutate their elements. But after the reinterpretation into a matrix, I can happily replace one Float64 at a time, and the original Vector has changed accordingly. Quite useful, especially for large N.

This idea must generalize to mutables with immutable fields, because (a) it would be super weird if Array was special and (b) those fields can always be mutated in practice (e.g. you can pass a pointer to the mutable to a C function) and I would say consequentially we should not be trying to maintain their immutability when they live on the heap like that. Only immutable fields of immutable objects (of immutable objects, etc, all the way to global scope consts or the stack) should be assumed constant by the compiler/user.

The idea of reinterpreting a length-1 Vector of an NTuple{N,Float64} as a length-N Vector{Float64} is exactly what I'm going for in MVector{N,Float64} in this package.

[yuyichao]

Definitely true on the stack.

What do you mean? On the stack or not is totally irrelevant. Whether it is inlined into mutable object is.

It is possible to mutate global consts even if they are immutable

What do you mean by global consts? And again global consts has nothing to do with this.

An obvious case: I can always reinterpret a Vector{NTuple{N,Float64}} as a Matrix{Float64} with N rows. I can create the vector as immutable tuples.

Correct.

and according to your statement, I must only replace entire tuples since each is "immutable memory that is allocated for an immutable object", and never mutate their elements.

No this is NOT what I'm saying. For isbits type, the immutable type is inlined into mutable memory, which is why mutating it is OK. This is what JuliaLang/julia#17115 is all about.

This idea must generalize to mutables with immutable fields,

Not in general. Again, only when the immutable field is inlined.

because (a) it would be super weird if Array was special and

Therefore you can't do that when the immutable object is not inlined into the array either.

(b) those fields can always be mutated in practice

For non-inline object the memory holding the immutable object is never mutated. Only the reference to the memory (the pointer stored in the field).

(e.g. you can pass a pointer to the mutable to a C function)

FWIW, this is a really bad way to tell if it's okay to mutate the memory. You can generally pass pointers to immutable memory using Any ccall parameter type but that's a contract that the called code understands julia and won't do things that violate the julia semantics, including not mutating immutable memory.

and I would say consequentially we should not be trying to maintain their immutability when they live on the heap like that.

Only when inlined.

The idea of reinterpreting a length-1 Vector of an NTuple{N,Float64} as a length-N Vector{Float64} is exactly what I'm going for in MVector{N,Float64} in this package.

isbits type is fine since they are inlined. Non-isbits type is not since they are not inlined. Please read JuliaLang/julia#17115 to understand when mutating is ok and when it is not.

As an unrelated piece of information what you might need to know before hitting it yourself, it is undefined if you creates an actual array from the memory belongs to a non-array object (i.e. call unsafe_wrap on a pointer you get from pointer_from_objref) and julia will actually return the wrong result if you do it that way. I didn't check if you are doing it, just mentioning it.

[andyferris]

First, thank you @yuyichao for a thorough response. Sorry if I've seemed a little slow, or perhaps assertive, but I prefer my misconceptions to be corrected :)

I think I finally figured out where we are getting our wires crossed. My mental model of T in MVector{N,T} was either isbits immutable, or mutable. So the case in interest is an MVector{T} where T is mutable, i.e. a mutable type MVector with an immutable field of Tuple (comprising of a memory-consecutive list of pointers?) which has mutable fields of type T. The immutable I was referring to was definitely the Tuple, not T. The code I've got attempts to update the references/pointers to mutable T and I now fully appreciate that quite possibly won't work the same for non-isbits immutable T.

I guess I think of non-inline immutables as anomalies that will go away in Julia v0.6 (fingers crossed). I'm happy not to support them for now. Some responses:

Definitely true on the stack.

What do you mean? On the stack or not is totally irrelevant. Whether it is inlined into mutable object is.

Right. Inlined == T is isbits immutable == T would be on the stack if it is a variable in a function, unless it is a global const immutable, in which case it appears to be unboxed on the heap. I can get a pointer to the latter but never the former. I think this fact is an implementation detail rather than anything else.

and according to your statement, I must only replace entire tuples since each is "immutable memory that is allocated for an immutable object", and never mutate their elements.

No this is NOT what I'm saying. For isbits type, the immutable type is inlined into mutable memory, which is why mutating it is OK. This is what JuliaLang/julia#17115 is all about.

This idea must generalize to mutables with immutable fields,

Not in general. Again, only when the immutable field is inlined.

because (a) it would be super weird if Array was special and

Therefore you can't do that when the immutable object is not inlined into the array either.

(b) those fields can always be mutated in practice

For non-inline object the memory holding the immutable object is never mutated. Only the reference to the memory (the pointer stored in the field).

and I would say consequentially we should not be trying to maintain their immutability when they live on the heap like that.

Only when inlined.

I think here I'm talking about isbits immutables and mutables, and you're talking about non-isbits immutables. :) Does that seem right?

(e.g. you can pass a pointer to the mutable to a C function)

FWIW, this is a really bad way to tell if it's okay to mutate the memory. You can generally pass pointers to immutable memory using Any ccall parameter type but that's a contract that the called code understands julia and won't do things that violate the julia semantics, including not mutating immutable memory.

I assume using Any will return a pointer to a Julia box on the heap, right? I'm trying to avoid allocations, and I can't ccall a pointer to the stack frame of an isbits immutable. (as an aside, I want to use mutating C functions to instantiate an SVector on the stack of a Julia function, but this seems impossible. I could do it with extra C functions or hand-written llvmcall but I'd still probably have to copy the stack frame object unnecessarily at least once). I agree that this a bad way to tell if its "okay" by the language standard but Julia is young language with a history of quite successful and useful hacks (I always think of FastAnonymous.jl) that were probably only possible due to unintended implementation details.

As an unrelated piece of information what you might need to know before hitting it yourself, it is undefined if you creates an actual array from the memory belongs to a non-array object (i.e. call unsafe_wrap on a pointer you get from pointer_from_objref) and julia will actually return the wrong result if you do it that way. I didn't check if you are doing it, just mentioning it.

OK now you have really piqued my interest. I was considering this kind of thing for the future. What is going on here?

Thanks again for all the information! :)

[andyferris]

Also, to be clear, what I'm not trying to do is update the memory references in SVector{N,T} for mutable (or non-isbits) T, which would clearly violate the immutability contract.

[yuyichao]

immutable field of Tuple

The field is mutable in that the you can reassign the field. The object referenced by/stored in the field is not. This is possible to guess what you mean but it's confusing.

I guess I think of non-inline immutables as anomalies that will go away in Julia v0.6 (fingers crossed).

There will still be cases a immutable can't be inlined.

Right. Inlined == T is isbits immutable == T would be on the stack if it is a variable in a function, unless it is a global const immutable, in which case it appears to be unboxed on the heap.

No. It is not necessarily unboxed on the stack and it's not unboxed on the heap as const global. It's NOT OK to overwrite the memory of a global const immutable since it's nothing different from any immutable object.

I can get a pointer to the latter but never the former. I think this fact is an implementation detail rather than anything else.

You get a pointer to both with pointer_to_objref, which is unsafe to use in either case.

I think here I'm talking about isbits immutables and mutables, and you're talking about non-isbits immutables. :) Does that seem right?

I'm talking about immutable objects in general. You can't overwrite the memory owned by a immutable object. A immutable object inlined into another (possibly mutable) object (or array if it matters) doesn't own the memory.

I assume using Any will return a pointer to a Julia box on the heap, right?

I'm talking about function argument, not return value.

I agree that this a bad way to tell if its "okay" by the language standard but Julia is young language with a history of quite successful and useful hacks (I always think of FastAnonymous.jl) that were probably only possible due to unintended implementation details.

FastAnonymous.jl is reasonably defined. Direct memory access bypassing julia's runtime is totally different.

OK now you have really piqued my interest. I was considering this kind of thing for the future. What is going on here?

Arrays are not allowed to alias memory of normal object, that's all.

[yuyichao]

Also, to be clear, what I'm not trying to do is update the memory references in SVector{N,T} for mutable (or non-isbits) T, which would clearly violate the immutability contract.

FWIW, I never talked anything about your SVector. I'm only talking about the code Jameson linked above which is the setindex! of MVector.

[c42f]

So to summarize, this isn't fixable, except by replacing the MVector's data with an entirely new tuple with the associated ith element swapped out. Why don't we just do that? MVector will presumably then be quite slow for non-isbits, but do we care about this for any use case right now?

Presumably JuliaLang/julia#17115 or something equivalent will then come along make all this just work nicely.