Steven Schveighoffer wrote:
> Its abstracted to the GC, but the current GC is well defined.  If you request to allocate blocks with length of a power of 2 under a page, you will get exactly that length, all the way down to 16 bytes.  If you request to allocate a page or greater, you get a contiguous block of memory that is a multiple of a page.
> 
> With that definition, is the allocator deterministic enough for your needs?

With respect to the current GC, yup. :)  Sticking to powers of 2 (or integral numbers of pages) >= 16 bytes is an easy enough rule.  Of course, I'm just starting out, so experienced game programmers might disagree, but it sounds perfectly reasonable to me.  I suppose the abstraction makes it a QOI though, so depending on the compiler and GC used in the future it could become a question again.  As it stands, I'm less interested in its precise current state and more interested in keeping an eye on its direction and how the spec/compiler/tools will mature over the next few years.

 > I think in the interest of allowing innovative freedom, such
> requirements should be left up to the GC implementor, not the spec or runtime.  Anyone who wants to closely control memory usage should just understand how the GC they are using works.

It's definitely a tradeoff...leaving things unspecified opens the door to innovation and better implementations, but it simultaneously raises issues of inconsistent behavior across multiple platforms where the same compiler/GC might not be able to be used.  To give an extreme example, look where unspecified behavior regarding static initialization order got C++! ;)  I guess I'll just have to see where things go over time, but the predictable allocation with the current GC is a good sign at least.

> No, you would most likely use templates, not void pointers.  D's template system is far advanced past C++, and I used it to implement my custom allocators.  It works great.
> 
> User-defined types are as high performance as builtins as long as the compiler inlines properly.

D's template system is pretty intriguing.  I don't really know anything about it, but I've read that it's less intimidating and tricky than C++'s, and that can only be a good thing for people wanting to harness its power.

> Capacity still exists as a read-only property.  I did like the symmetry, but the point was well taken that the act of setting the capacity was not exact.  It does mean that reserving space can only grow, not shrink.  In fact, the capacity property calls the same runtime function as reserve, just passing 0 as the amount requested to get the currently reserved space.
> 
> You can't use capacity to free space because that could result in dangling pointers.  Freeing space is done through the delete keyword.  We do not want to make it easy to accidentally free space.

It's a shame the asymmetry was necessary, but I agree it makes sense.

> The GC can figure out what page an interior pointer belongs to, and therefore how much memory that block uses.  There is a GC function to get the block info of an interior pointer, which returns a struct that contains the pointer to the block, the length of the block, and its flags (whether it contains pointers or not).  This function is what the array append feature uses to determine how much capacity can be used.  I believe this lookup is logarithmic in complexity.
> 
> -Steve

Thanks!

Mike S wrote:
> bearophile wrote:
>>> How difficult do you think that would be for the compiler devs to implement in the semantic sense?  Assuming it can be done without major hardship or compromising the design of the language, that would be really cool.<
>>
>> They are easy to implement. Even the lazy ones. See ShedSkin "compiler".
> 
> I figured the eager ones wouldn't be a problem, but I wondered whether the lazy ones might be a pain.  Guess not, so cool. :)
> 
>> We can talk about them again for D3. At the moment D2 needs less new features and better implementation/debugging of the already present features.
> 
> That's very true...I'm looking forward to Andrei's book, but I can't imagine how he's finishing it on schedule, considering how quickly both the language itself and the compiler are evolving.

The book is finished and is on schedule. It's been out of my hands for a while - currently in the final copyedit stage. (Walter, last chance to remove octal literals.) I'll publish a schedule on my website soon.

The entire genesis of TDPL and its growth in conjunction with the language itself, was a very interesting process (in addition to being a near-death experience) that I hope I'll find time to write an article about soon. Bottom line, the thing looks like a million 1920 bucks. I fail to see many ways in which the people involved could have made it better. That being said, it's entirely unpredictable how the book's going to fare. I'll be very curious.

> If the language specification and reference compiler are both as incomplete, volatile, and partially implemented as they are now, a June release might do some real damage to D's reputation.

Not at all. Consider the state of C++, Perl, Java, or Ruby definitions and implementations at the time when their first "hello, world" book was printed. If anything, TDPL is slightly later, not earlier, than average. Even K&R's classic does not cover the entire language (even as it was defined back in the time) and has things like prototype-less calls, which C has since dropped like a bad habit.

> As far as D3 goes though:  Obviously nothing about it has really been discussed at length, but is the general idea that it would be another backwards-incompatible overhaul, or is the plan to make D2 the target for backwards compatibility from here on out?

The incompatibility with D1 was a one-off thing. D2 is the flagship of D going forward. If you ask me, I predict that the schism of D2 from D1 will go down as Walter's smartest gambit ever.


Andrei

On Thu, 01 Apr 2010 11:01:38 -0400, Mike S <mikes@notarealaddresslololololol.com> wrote:

> I suppose the abstraction makes it a QOI though, so depending on the compiler and GC used in the future it could become a question again.  As it stands, I'm less interested in its precise current state and more interested in keeping an eye on its direction and how the spec/compiler/tools will mature over the next few years.

As an aside, because the GC is implemented all in runtime, you can swap out the GC for something else that suits your needs.  Therefore, the issue of having to deal with different GCs on different platforms can be circumvented by inventing a GC that works the way you want on all platforms :)

Also, I don't see the major attributes of the GC changing anytime soon.

-Steve

Mike S:

> I figured the eager ones wouldn't be a problem, but I wondered whether the lazy ones might be a pain.  Guess not, so cool. :)

Lazy ones are just a struct/class instance that contains an opApply method (or that follows the Range protocol methods). Very easy.


> As far as D3 goes though:  Obviously nothing about it has really been discussed at length, but is the general idea that it would be another backwards-incompatible overhaul, or is the plan to make D2 the target for backwards compatibility from here on out?

From what I've seen, D3 will probably be backwards compatible with D2.
(But maybe D3 will feel free to fix few backwards incompatible warts/errors found in the meantime, I don't know, like un-flattening tuples).

Bye,
bearophile

Andrei Alexandrescu:
> The book is finished and is on schedule. It's been out of my hands for a while - currently in the final copyedit stage. (Walter, last chance to remove octal literals.) I'll publish a schedule on my website soon.

Walter doesn't want to change octals, so I think it's a waste of time to keep talking about that.
There are several other small problems in D2 that deserve a look. They are small but important things. Please talk about those.
I list most of them here in approximate order of decreasing importance:

Syntax & semantics for array assigns http://d.puremagic.com/issues/show_bug.cgi?id=3971

[module system] Tiding up the imports http://d.puremagic.com/issues/show_bug.cgi?id=3819

Signed lengths (and other built-in values)
http://d.puremagic.com/issues/show_bug.cgi?id=3843

[missing error] Array literal length doesn't match
Array literal assign to array of different length
http://d.puremagic.com/issues/show_bug.cgi?id=3849
http://d.puremagic.com/issues/show_bug.cgi?id=3948

opCast(bool) in classes is bug-prone
http://d.puremagic.com/issues/show_bug.cgi?id=3926

Require opEquals/opCmp in a class the defines toHash http://d.puremagic.com/issues/show_bug.cgi?id=3844

automatic joining of adjacent strings is bad http://d.puremagic.com/issues/show_bug.cgi?id=3827

pure/nothrow functions/delegates are a subtype of the nonpure/throw ones http://d.puremagic.com/issues/show_bug.cgi?id=3833

const arguments/instance attributes in conditions/invariants http://d.puremagic.com/issues/show_bug.cgi?id=3856

bool opEquals() for structs instead of int opEquals()
http://d.puremagic.com/issues/show_bug.cgi?id=3967

byte ==> sbyte http://d.puremagic.com/issues/show_bug.cgi?id=3936 http://d.puremagic.com/issues/show_bug.cgi?id=3850

A bug-prone situation with AAs http://d.puremagic.com/issues/show_bug.cgi?id=3825

Arguments and attributes with the same name http://d.puremagic.com/issues/show_bug.cgi?id=3878

More useful and more clean 'is' http://d.puremagic.com/issues/show_bug.cgi?id=3981

Those things are small breaking changes, so it's much better to think about them sooner. If you want I can explain better each one of them.

Bye,
bearophile