On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
> On 2014-05-12 19:14, Dicebot wrote:
>
>> It lacks any good static reflection though. And this stuff is damn
>> addictive when you try it of D caliber.
>
> It has macros, that basically requires great support for static reflection to be usable.

Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hygienic version of C macros.

On Tue, 13 May 2014 02:12:44 -0400, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
>
> On 13.05.2014 00:15, Martin Nowak wrote:
>> On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
>>>
>>> 1. Use a scheme that takes a snapshot of the heap, stack and registers
>>> at the moment of collection and do the actual collection in another
>>> thread/process while the application can continue to run. This is the
>>> way Leandro Lucarellas concurrent GC works
>>> (http://dconf.org/2013/talks/lucarella.html), but it relies on "fork"
>>> that doesn't exist on every OS/architecture. A manual copy of the memory
>>> won't scale to very large memory, though it might be compressed to
>>> possible pointers. Worst case it will need twice as much memory as the
>>> current heap.
>>
>> There is a problem with this scheme, copy-on-write is extremely
>> expensive when a mutation happens. That's one page fault (context
>> switch) + copying a whole page + mapping the new page.
>
> I agree that this might be critical, but it is a one time cost per page. It seems unrealistic to do this with user mode exceptions, but the OS should have this optimized pretty well.
>
>  > It's much worse
>  > with huge pages (2MB page size).
>
> How common are huge pages nowadays?

I know this is coming from a position of extreme ignorance, but why do we have to do copy on write? What about pause on write? In other words, if a thread tries to write to a page that's being used by the collector, it pauses the thread until the page is no longer being used by the GC.

This doesn't fix everything, but it's at least as good as today's GC, which preemptively pauses threads.

My ignorance is that I have no idea if this is even possible, and I also have no idea how it would affect performance.

-Steve

On 05/13/2014 03:56 PM, Dicebot wrote:
> On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
>> On 2014-05-12 19:14, Dicebot wrote:
>>
>>> It lacks any good static reflection though. And this stuff is damn
>>> addictive when you try it of D caliber.
>>
>> It has macros, that basically requires great support for static
>> reflection to be usable.
>
> Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
> those are not full-blown AST macros like ones you have been proposing,
> more like hygienic version of C macros.

https://github.com/huonw/brainfuck_macro/blob/master/lib.rs

On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote:
> I know this is coming from a position of extreme ignorance, but why do we have to do copy on write? What about pause on write?

Not sure how that will help? Pointers may still escape collection?

(but you get that with transactional memory, on the cache level)

On Tuesday, 13 May 2014 at 16:14:07 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote:
> Not sure how that will help? Pointers may still escape collection?

(as in not being traced, leading to freeing live memory)

On Tue, 13 May 2014 12:14:06 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote:
>> I know this is coming from a position of extreme ignorance, but why do we have to do copy on write? What about pause on write?
>
> Not sure how that will help? Pointers may still escape collection?
>
> (but you get that with transactional memory, on the cache level)

My understanding is that the way the fork collector works is that it makes pages copy-on-write. Then if the original process writes to one of the pages, the page is copied, which may be expensive in terms of total memory and time consumed.

The idea I had was to make them pause-on-write. This means, when the original process attempts to write to the page, it gets a page-fault, which pauses the thread until the collector is done with it. This causes the same halting that normally happens with stop-the-world, but only on-demand, instead of preemptively. If a thread is doing only reads, or is only touching non-Scanned memory, it continues.

A collector may be able to take advantage of this knowledge to avoid as many pauses as possible, but I'm not sure.

Just an idea, I make no claims to its actual benefits :)

-Steve

"Steven Schveighoffer"  wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...

> If a thread is doing only reads, or is  only touching non-Scanned memory, it continues.

How long do threads usually go without touching the stack? 

On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
>
>> If a thread is doing only reads, or is  only touching non-Scanned memory, it continues.
>
> How long do threads usually go without touching the stack?

The stack would have to be COW.

-Steve

On Tue, 13 May 2014 13:37:05 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
>
>> "Steven Schveighoffer"  wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
>>
>>> If a thread is doing only reads, or is  only touching non-Scanned memory, it continues.
>>
>> How long do threads usually go without touching the stack?
>
> The stack would have to be COW.

No sorry, the stack only contains roots, so it can be marked as "safe to use" pretty quickly.

-Steve

On 2014-05-13 15:56, Dicebot wrote:

> Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
> those are not full-blown AST macros like ones you have been proposing,
> more like hygienic version of C macros.

Hmm, I haven't looked at Rust macros that much.

-- 
/Jacob Carlborg