Any pointers on an ARC design?

[Gozala]

Is the mechanism based on some paper ? If so could you please share the details ?

Thanks

[appcypher]

There may be papers out there that explain this technique, but I'm not aware of any of them. Its just something I thought of and started implementing.

I like calling it Automatic Reference Journalling cos it does more than just counting references.
I've tested it on some simple programs and it worked quite well, however since I've not tried it on more complex programs, I can't claim that it will always work in all cases. I have a strong feeling it will though.

The problem with the method now is that it does deep analysis of each object which might hurt compile time, but then I've not spent enough time with it to optimize it.

[appcypher]

I'm closing this issue. I believe I've provided answer to the question asked.

[MaxGraey]

Hi, I have another question about ARC implementation.

How you resolve cyclic references which cause to memory leak without special hints? For example Objective-C/Swift use special week references define like:

@property (nonatomic, weak) NSObject* a;

Rust provide much wider patterns to resolve this like RefCell, Weak, and Rc.

Some languages like Alef/Limbo has ARC with fallback to GC for resolving this case.
Someone use cyclic reference counter (CRC)

So which way will you choose?

[appcypher]

Sorry, I got this late.

The ARC method I'm employing is not like Objective-C/Swift, nor like Alef/Limbo ARC-tracing hybrid.
I've tried looking for papers that explain the method I'm using and these papers come close:

• Detlefs, D. (2004). Automatic Inference of Reference-Count Invariants.
• Goldberg, B., & Park, Y.G. (1991). Reference Escape Analysis: Optimizing Reference Counting based on the Lifetime of References. PEPM.
• Joisha, P.G. (2008). A principled approach to nondeferred reference-counting garbage collection. VEE.

But none of them goes into details of how this can be extended to concurrent programs, which is the same caveat mine has.

For non-concurrent programs, objects can be freed deterministically without any runtime cost apart from calling free.

In concurrent programs, the system falls apart since an async function may free an object in use by another async function after it exits.

The exit order of invoked async functions can be unpredictable, so some sort of runtime synchronization is needed to handle that.

You may need to take a look at the first paper I linked, it describes my method well.
Maybe I will create time to explain what I have in mind later.