On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Regan Heath, el 22 de October a las 10:41 me escribiste:
>> >NO, this is completely false, and why I think you are not entirely
>> >familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects
>> >ALL, EACH and EVERY program for example. D or not D. Every single
>> >dynamically linked program.
>>
>> True.  And the reason these behave this way is because we *always*
>> want them to - the same is NOT true of the proposed vars for D.
>
> No, not at all, you very rarely want to change LD_PRELOAD and
> LD_LIBRARY_PATH globaly.

Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these.

The same is not true of many potential D GC/allocation/debug flags, we do not necessarily want them to propagate at all and in fact we may want to target a single exe in a process tree i.e.

parent     <- not this
  child1   <- this one
    child2 <- not this

> My conclusion is we don't agree mainly on this:
>
> I think there are cases where you want runtime configuration to
> propagate or be set more or less globally.

I agree that there are cases we might want it to propagate *from a parent exe downwards* or similar but this is not what I would call "more or less globally" it's very much less than globally.  The scope we want is going to be either a single exe, or that exe and some or all of it's children and possibly only for a single execution.

Sure, you *could* wrap a single execution in it's own session and only set the envvar within that session but it's far simpler just to pass a command line arg.  Likewise, you could set an envvar in a session and run multiple executions within that session, but again it's simpler just to pass an arg each time.

Basically, I don't see what positive benefit you get from an envvar over a command line switch, especially if you assume/agree that the most sensible default these switches is 'off' and that they should be enabled specifically.

I think what we disagree about here is the scope it should apply and whether propagation should be the default behaviour.

> You think no one will ever want some runtime option to propagate.

Nope, I never said that.

> Also, I don't have much of a problem with having command-line options to
> configure the runtime too, although I think in linux/unix is much less
> natural.

Surely not, unix is the king of command line switches.

> Runtime configuration will be most of the time some to be done
> either by the developer (in which case it would be nicer to have a
> programatic way to configure it)

Agreed.

> or on a system level, by a system
> administrator / devops (in which case for me environment variables are
> superior for me).

Disagree.  It's not something we ever want at a system level, it's somewhere within the range of a single session <-> single execution.

> Usually runtime options will be completely meaningless
> for a regular user. Also, will you document them when you use --help?

Or course not, just as you would not document the envvar(s).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Regan Heath, el 23 de October a las 17:24 me escribiste:
> On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:
> 
> >Regan Heath, el 22 de October a las 10:41 me escribiste:
> >>>NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program.
> >>
> >>True.  And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D.
> >
> >No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly.
> 
> Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these.

No, not at all, specially with LD_PRELOAD, I think you almost never want to propagate it. I think LD_PRELOAD is the closest example to what one would want to do with runtime options (and some of the stuff, like replacing the GC, could be done using LD_PRELOAD, actually, but you have to replace it all, you have much less fine grained control, is major surgery).

> >Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural.
> 
> Surely not, unix is the king of command line switches.

Is not about quantity, is about separation of concerns. Historically in Linux a program only manages the switches it really knows, is not common to hijack programs arguments in Linux (even when is done by some applications, like GTK+, but is all under your control, you explicitly pass the command-line arguments to the library, so it's quite a different case). Anything that you don't control in your program, is handled by environment variables.

> >or on a system level, by a system
> >administrator / devops (in which case for me environment variables are
> >superior for me).
> 
> Disagree.  It's not something we ever want at a system level, it's somewhere within the range of a single session <-> single execution.

Why? On a single core I want ALL my applications by default NOT to use the concurrent GC, as it will make things slower, while on a multi-core I want to use the concurrent GC by default. You have an use case right there. If I have tons of memory, I would want to have all my programs preallocate 100MiB to speed up things. There might be more in the future, who knows...


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Parece McGuevara's o CheDonald's

On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote:
> We could experiment with separately linking the GC.  It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.

Can't it work like any other user library?

On Friday, 24 October 2014 at 06:50:05 UTC, Kagamin wrote:
> On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote:
>> We could experiment with separately linking the GC.  It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.
>
> Can't it work like any other user library?

Well, on linux at least I think you might have to list it twice. Once before and once after libdruntime. I don't know if there's a portable linker flag that indicates that it should try and resolve dependencies in libraries listed later in the link line.

This means, the program should link with object file instead of a library. Alternatively it can be pulled eagerly by the proposed `init` function if it will explicitly depend on a symbol from a gc library - the linker could resolve the symbol early.

On Friday, 17 October 2014 at 11:30:48 UTC, Marc Schütz wrote:
> Marginally related: Page fault handling in user space.
> http://lwn.net/Articles/615086/
>
> Maybe this can be used as an alternative to forking.

Definitely good news for moving GCs.

On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze wrote:
> I'm benchmarking my Windows version of a concurrent GC with it. It does quite a lot of allocations, and this is causing some serious trouble because marking cannot compete with the rate of allocation, causing some tests to allocate a lot of memory, slowing down marking even more. I'm still looking for a solution...

Well ultimatively you got to throttle your mutators to a throughput that the GC can handle. That's actually a nice thing about the forking GC, the mutator has to pay for the COW page faults, so there is some built-in throttling.
How does your GC work?

On 30.10.2014 04:02, Martin Nowak wrote:
> On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze wrote:
>> I'm benchmarking my Windows version of a concurrent GC with it. It
>> does quite a lot of allocations, and this is causing some serious
>> trouble because marking cannot compete with the rate of allocation,
>> causing some tests to allocate a lot of memory, slowing down marking
>> even more. I'm still looking for a solution...
>
> Well ultimatively you got to throttle your mutators to a throughput that
> the GC can handle. That's actually a nice thing about the forking GC,
> the mutator has to pay for the COW page faults, so there is some
> built-in throttling.
> How does your GC work?

There's sort of a description here: http://rainers.github.io/visuald/druntime/concurrentgc.html

There are actually two variations:

- one uses "Memory-Write-Watches" to detect modified pages and rescans all pages modified during a background scan. It could be improved to reschedule the second scan to the background, again, until there are only few modified pages.

- the other uses COW protection on the pool memory, but has to copy modified memory back when restoring unprotected memory mappings.