December 27, 2011
On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
> On 12/26/11 10:29 AM, deadalnix wrote:
>> Do you know what is the impact of 64bits on false positive proportion
>> when the GC isn't precise ?
>
> No.

I would think it would dramatically reduce it.

December 27, 2011
On 12/26/11 6:36 PM, Walter Bright wrote:
> On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
>> On 12/26/11 10:29 AM, deadalnix wrote:
>>> Do you know what is the impact of 64bits on false positive proportion
>>> when the GC isn't precise ?
>>
>> No.
>
> I would think it would dramatically reduce it.

At the same time, false positives are not the only reason for which precision is good. Precision reduces the amount of work done by the scanner, allows e.g. using distinct regions for objects with/without embedded pointers, and allows moving objects.

Andrei

December 27, 2011
Walter Bright wrote:

>      bool notFeature;

Counterexample:

|       bool sense;

I do not believe, that a majority of developers evaluates `nonsense' as being equal to `!sense'.

-manfred
December 27, 2011
Le 27/12/2011 02:07, Andrei Alexandrescu a écrit :
> On 12/26/11 6:36 PM, Walter Bright wrote:
>> On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
>>> On 12/26/11 10:29 AM, deadalnix wrote:
>>>> Do you know what is the impact of 64bits on false positive proportion
>>>> when the GC isn't precise ?
>>>
>>> No.
>>
>> I would think it would dramatically reduce it.
>
> At the same time, false positives are not the only reason for which
> precision is good. Precision reduces the amount of work done by the
> scanner, allows e.g. using distinct regions for objects with/without
> embedded pointers, and allows moving objects.
>
> Andrei
>

Using different region for object that or may not contains pointers is something that can be achieved with the current state of D.

Agreed for everythign else.
December 27, 2011
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
>
> As a first step, we must make all allocations except stack type-aware,
> and leave only the stack to be imprecise.
>

Couldn't the GC'ing the stack be handled in a similar style to how the Windows x64 ABI functions with respect to exception handling?

The unwinding code lives outside the normal program flow to reduce runtime overhead as much as posisble, at least until an exception is thrown.  At which point the exception handlers traverse this data structure to unwind the stack from wherever you are in your function (and its caller and so on).

I would imagine a GC system could do something very similar.  There are a few MSDN blogs with a bunch of useful links out to more detailed information:

http://blogs.msdn.com/b/freik/archive/2006/01/04/509372.aspx

http://blogs.msdn.com/b/freik/archive/2005/03/17/398200.aspx

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

December 27, 2011
On 2011-12-26 21:55, Walter Bright wrote:
> On 12/26/2011 3:47 AM, Jacob Carlborg wrote:
>> It's like when you see code like this (Ruby):
>>
>> unless !foo
>>
>> end
>>
>> Double negation. Code like the snippet above can be really annoying.
>
> In general, variables and conditions should never be labeled with negation:
>
> bool notFeature;

I agree.

-- 
/Jacob Carlborg
December 27, 2011
On 2011-12-27 00:23, Robert Jacques wrote:
> On Mon, 26 Dec 2011 07:43:46 -0800, Jacob Carlborg <doob@me.com> wrote:
>> On 2011-12-26 15:52, Andrei Alexandrescu wrote:
>>> On 12/26/11 6:53 AM, Jacob Carlborg wrote:
>>>> What about the parallel/concurrent collector that has been linked a
>>>> couple of times in this newsgroup. Would that be possible and a good
>>>> idea to implement?
>>>
>>> A parallel collector would be, of course, a valuable addition.
>>>
>>> Andrei
>>
>> This is the collector I was referring to:
>> http://www.artima.com/lejava/articles/azul_pauseless_gc.html
>
> The C4 pause-less GC, while very cool, is its own operating system. It
> doesn't run on-top of Windows, Linux, Mac, etc. CDGC, on the other hand,
> is a concurrent collector that only runs on *nixes. Thread-local GCs are
> a form of mostly parallel/concurrent collectors which are a good match
> for D, but requires our memory model to support/include regions. There
> has also been some work recently in making fully precise collectors for
> C, which would be directly applicable to D.

That's why I said if possible to implement.

-- 
/Jacob Carlborg
December 28, 2011
On Tue, 27 Dec 2011 10:35:02 -0800, Sean Cavanaugh <WorksOnMyMachine@gmail.com> wrote:

> On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
>>
>> As a first step, we must make all allocations except stack type-aware,
>> and leave only the stack to be imprecise.
>>
>
> Couldn't the GC'ing the stack be handled in a similar style to how the
> Windows x64 ABI functions with respect to exception handling?
>
> The unwinding code lives outside the normal program flow to reduce
> runtime overhead as much as posisble, at least until an exception is
> thrown.  At which point the exception handlers traverse this data
> structure to unwind the stack from wherever you are in your function
> (and its caller and so on).
>
> I would imagine a GC system could do something very similar.  There are
> a few MSDN blogs with a bunch of useful links out to more detailed
> information:
>
> http://blogs.msdn.com/b/freik/archive/2006/01/04/509372.aspx
>
> http://blogs.msdn.com/b/freik/archive/2005/03/17/398200.aspx
>
> http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

Fully precise collectors for C have been done; e.g. MAGPIE: PRECISE GARBAGE COLLECTION FOR C
February 09, 2012
On 24/12/2011 12:42, bearophile wrote:
> A new blog post by the very good John Carmack, I like how well readable this post is:
> http://altdevblogaday.com/2011/12/24/static-code-analysis/
>

Nice article! I particularly liked this comment:
"The classic hacker disdain for “bondage and discipline languages” is short sighted – the needs of large, long-lived, multi-programmer projects are just different than the quick work you do for yourself."
that throws a jab at a lot of the obsession with dynamic languages that goes on out there.
It's something I've echoed in the past, especially when people start comparing languages to one another using small code snippets, and picking on issues/advantages that actually are only significant when writing small sized code, but not at all for medium/large sized apps. (the Hello-World Snippet Fallacy?)


-- 
Bruno Medeiros - Software Engineer
February 09, 2012
On 24/12/2011 23:27, Adam D. Ruppe wrote:
> On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
>> I was talking about the abundance of (({}){()}) and not about
>> identifiers length.
>
> It's the same fallacy. I can't read Carmack's mind, but
> I'm sure he's talking about shortening code the same way
> I would mean it if I said it - simpler concepts, fewer cases,
> less repetition.
>
> It's about how much you have to think about, now how much you
> have to read/write.

Exactly.
Reminds me of the issues that some people have with Java closures/lambdas. You do closures/lambdas in Java by means of creating an anonymous class and then implementing a method, and this is much more verbose than a plain lambda syntax, like D has (or many other functional languages). But although it is much more verbose, it is actually not that much more complex, it doesn't add much more to think about.
There is however another issue with Java's closures/lambdas which is not complained or mentioned as much as the above, but is actually much more annoying because it adds more semantic complexity: the closure can't modify (the immediate/head value of) the outer variables. So when modifying is necessary, you often see code where people instantiate a one element array, the closure accesses the array (the array reference is not modified), it then modifies the element inside, in index 0, and then that is retrieved by the outer code when the closure finishes. This on the other is a much more serious issue, and adds more complexity to the code beyond just verbosity.


-- 
Bruno Medeiros - Software Engineer