November 19

On Friday, 19 November 2021 at 15:46:15 UTC, Tejas wrote:

>

On Friday, 19 November 2021 at 15:37:04 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 15:20:06 UTC, IGotD- wrote:

>

[...]

That would be affine/linear types, the best ergonomics for them is to combine a tracing GC, with such types.

Instead of having them all around the program, only make use of them when performance requirements so demand them.

This is the approach being taken by Swift, Haskell, OCaml, and even D with @life.

It would be interesting to see @life + GC settle all discussions on D's approach to memory management, but somehow I feel it won't happen.

What do you think about Nim's ARC + GC solution? They call it ORC :
https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

It is an old idea that goes back to systems like Mesa/Cedar in the early 1980's.

https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837

Used to create this workstation OS at Xerox PARC,

https://m.youtube.com/watch?v=z_dt7NG38V4

November 19

On Friday, 19 November 2021 at 17:41:23 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 15:46:15 UTC, Tejas wrote:

>

On Friday, 19 November 2021 at 15:37:04 UTC, Paulo Pinto wrote:

>

[...]

What do you think about Nim's ARC + GC solution? They call it ORC :
https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

It is an old idea that goes back to systems like Mesa/Cedar in the early 1980's.

https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837

Used to create this workstation OS at Xerox PARC,

https://m.youtube.com/watch?v=z_dt7NG38V4

Mesa/Cedar used deferred reference counting plus a cycle collector, that's Nim's old default GC, ORC is completely different... But hey, what do I know, I only implemented both.

November 19

On Friday, 19 November 2021 at 19:02:45 UTC, Araq wrote:

>

On Friday, 19 November 2021 at 17:41:23 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 15:46:15 UTC, Tejas wrote:

>

On Friday, 19 November 2021 at 15:37:04 UTC, Paulo Pinto wrote:

>

[...]

What do you think about Nim's ARC + GC solution? They call it ORC :
https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

It is an old idea that goes back to systems like Mesa/Cedar in the early 1980's.

https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837

Used to create this workstation OS at Xerox PARC,

https://m.youtube.com/watch?v=z_dt7NG38V4

Mesa/Cedar used deferred reference counting plus a cycle collector, that's Nim's old default GC, ORC is completely different... But hey, what do I know, I only implemented both.

Different in what way, given the optimizations referred in the paper and plans for future work, which unfortunately never realised given the team's move into Olivetti, where they eventually created Modula-2+ and Modula-3.

November 19

On Friday, 19 November 2021 at 19:02:45 UTC, Araq wrote:

>

On Friday, 19 November 2021 at 17:41:23 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 15:46:15 UTC, Tejas wrote:

>

[...]

It is an old idea that goes back to systems like Mesa/Cedar in the early 1980's.

https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837

Used to create this workstation OS at Xerox PARC,

https://m.youtube.com/watch?v=z_dt7NG38V4

Mesa/Cedar used deferred reference counting plus a cycle collector, that's Nim's old default GC, ORC is completely different... But hey, what do I know, I only implemented both.

Love your work on Nim btw

/Secret fan

November 20
On 20/11/2021 2:37 AM, Ola Fosheim Grøstad wrote:
> On Friday, 19 November 2021 at 12:45:45 UTC, rikki cattermole wrote:
>> I'm more in favor of ARC completely. Tie it into scope, and the compiler can elide the calls. Add an operator overload so that you can get a non-scope reference to memory and it might be a very nice situation for us.
> 
> That is more conventional, and in some sense easier because it is more homogeneous.
> 
> I think some people will complain about performance, but I am not against it.

For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.

But yeah, a fiber aware GC that could clean things up as it goes along would be absolutely amazing for stuff like web development.
November 20

On Saturday, 20 November 2021 at 00:55:36 UTC, rikki cattermole wrote:

>

For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.

Yes. Regardless, ARC requires more compiler restructuring.

Right now regular RC + local GC is the easy implementation...

But regular RC is not convincing anyone, sigh...

November 20
On 20/11/2021 2:21 PM, Ola Fosheim Grøstad wrote:
> On Saturday, 20 November 2021 at 00:55:36 UTC, rikki cattermole wrote:
>> For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.
> 
> Yes. Regardless, ARC requires more compiler restructuring.

To me ARC is just what we have now with a couple of compiler hooks. So it shouldn't need restructuring for this.

> Right now regular RC + local GC is the easy implementation...
> 
> But regular RC is not convincing anyone, sigh...

I use it, but it is expensive, I know this. But it is the only way to make the resources go away guaranteed (unless something messes with the thread state).

However a lot of the usage of the RC could work with scope and possibly even const. So there is a lot of potential easy optimizations being missed due to the fact that we don't have the methods to call specifically for RC.

I.e.

void someFunc(scope RCData data) {
	someOtherFunc(data);
}

At no point from that point forward would RC methods need to be called. But copy constructors, postblit and destructors would need to be called regardless on a struct. Its a real shame.
November 20

On Saturday, 20 November 2021 at 01:59:07 UTC, rikki cattermole wrote:

>

On 20/11/2021 2:21 PM, Ola Fosheim Grøstad wrote:

>

On Saturday, 20 November 2021 at 00:55:36 UTC, rikki cattermole wrote:

>

For system resources, I think this is the best way forward. Due to the fact that threads actually matter here, and you really need to "free" resources where they were allocated. But also allow references to leak to other threads.

Yes. Regardless, ARC requires more compiler restructuring.

To me ARC is just what we have now with a couple of compiler hooks. So it shouldn't need restructuring for this.

I had an idea for a LLVM hack, but Apple ARC engineers pointed out that there were issues to me so I consider that to be unworkable. Meaning: I trust their experience. So you have to do it over a suitable high level IR. I don't think D has that... At least not to my knowledge.

November 20
On 20/11/2021 4:27 PM, Ola Fosheim Grøstad wrote:
> I had an idea for a LLVM hack, but Apple ARC engineers pointed out that there were issues to me so I consider that to be unworkable. Meaning: I trust their experience. So you have to do it over a suitable high level IR. I don't think D has that... At least not to my knowledge.

Yeah, the DFA probably does get gnarly beyond certain patterns.

And truth be told I think we *do* need to build that IR at some point, because right now with the return ref and all those attributes its just garbage that humans have to write that rather than letting the compiler figure it out.
November 20
On Saturday, 20 November 2021 at 03:38:01 UTC, rikki cattermole wrote:
> And truth be told I think we *do* need to build that IR at some point, because right now with the return ref and all those attributes its just garbage that humans have to write that rather than letting the compiler figure it out.

The compiler already does figure most of it out. That's how it can emit compile time error messages for missing or incorrect attributes, or implementation violations of an attribute's guarantees. The attributes exist primarily for two reasons:

1) To verify programmer intent, that the inferred attributes of the code written match the intended attributes.

2) To specify APIs independent of implementation, for `extern` linking, `interface`s and base `class`es with multiple implementations that might imply different attributes, etc.

Attribute soup is unavoidable for (2) public APIs in general; there is nowhere else the information *can* come from in many cases except from an explicit specification, regardless of how sophisticated the compiler is.

Redundant specification of attributes for (1) verification purposes could be dropped, but I'd rather not since I find the compiler frequently catches mistakes or fuzzy thinking on my part by comparing explicit attributes to inferred.
1 2 3 4 5 6 7 8 9 10 11 12 13