van eeshan wrote:
> 
> Perhaps you haven't had the opportunity to write resiliant software? For
> example, halting an entire web-site, because some file is not in the correct
> format, is just not a solution. Frankly, I'm really surprised you'd
> encourage something so obviously naiive in this day and age.

I think Walter meant that this is typically the proper behavior for an out of memory condition.  He also notes that an exception is thrown so "resilient software" has a chance to do something about the problem instead of aborting.  C++ behaves the exact same way, however C++ does not automatically catch the error and display a meaningful message if the programmer forgot to write a try/catch block.


Sean

"Michael" <Michael_member@pathlink.com> wrote in message news:cfhr6d$9qj$1@digitaldaemon.com...
> Just out of curiosity, how does alloca() work? I guess it just manipulates
the
> Stack and Base Pointers?
>
> My apologies for going a bit off topic, I've just never seen alloca()
before.

It manipulates the ESP register. There is some complexity in it due to needing to 'touch' each 4k page allocated, and to relocate expression temporaries that are pushed on the stack. The source for it comes on the DMC++ CD.

"van eeshan" <vanee@hotmail.net> wrote in message news:cfhv05$bl9$1@digitaldaemon.com...
> > Uninitialized data can be a source of bugs and trouble, as I pointed out
> in
> > my other posting, even when used correctly. One design goal of D is to improve reliability and portability by eliminating sources of undefined behavior, and uninitialized data is one huge source of undefined, unportable, erratic and unpredictable behavior. I'm trying to squeeze
that
> > out of the normal constructs in D - but access to C functions and inline assembler is there for folks who really need it.
>
> But here's where that position truly falls apart ... what about those multitude of cases where buffers are reused over and over again? What
about
> thread-local workspaces? What about pooled buffers?  what about all those
X,
> Y, and Z variations? They do /not/ get automagically re-initialized.

Right, they don't. However, data buffers are unlikely to contain garbage that looks like pointers into the gc heap, whereas garbage on the stack *is* very likely to. Next, detritus in recycled data buffers is not going to consist of objects that are no longer valid, the source of the other problem I mentioned. And lastly, D can't close every hole, but that doesn't mean it shouldn't close what it can.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cfhoe3$793$1@digitaldaemon.com...
> In article <cfhhbe$3jf$1@digitaldaemon.com>, Walter says...
>
> >I know how to build a gc that will compact
> >memory to deal with fragmentation when it does arise, so although this is
> >not in the current D it is not a technical problem to do it.
>
> That's probably good news, but:
>
> Will it be possible to mark specific arrays on the heap as "immovable"?
(Please
> say yes. I'm sure it is not a technical problem).

Yes. It's called "pinning". And I can guess why you need this feature <g>.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cfhppt$97t$1@digitaldaemon.com...
> In article <cfhhbe$3jf$1@digitaldaemon.com>, Walter says...
> >3) Large arrays on the stack bring up the specter of stack exhaustion
with
> >even modest amounts of recursion.
>
> I'm not sure about this one. I thought that in the 80386+ architecture,
the
> stack(s) can grow indefinitely. Or is it just that Windows doesn't take advantage of this possibility.

Stacks are allocated a range of memory. Once that's filled up, since the stack cannot be relocated, the program comes to a (crashing) halt. The problem gets worse if you create a lot of threads, because each thread will necessarilly have a fixed maximum stack size.

The stack size only appears to be infinite to those of us used to 16 bit machines <g>.

With respect Andy, the programmer was quite explicit about where the memory should come from ... it's a locally-declared array, and the language documentation points out such declarations are place on the stack (just like C/C++) because there are some very good reasons to do so. If you abstract that notion away, then we're not discussing D anymore. Note that the declaration does not have static, const, or any other qualifier either.


"Andy Friesen" <andy@ikagames.com> wrote in message news:cfim8j$nq2$1@digitaldaemon.com...
> Arcane Jill wrote:
>
> > /another/ option is for the compiler, on seeing the code:
> >
> > #    char[1024*32] workspace;
> >
> > would think to itself: "Hmmm. Now 1024*32 - that's 32768. That's a
mighty large
> > number of bytes to be putting on the stack. I think I'll allocate it
from the
> > heap instead. The programmer won't care. Hell, the programmer won't even /notice/ unless they start looking at the generated assembler!"
>
> I like this approach.  The programmer didn't say where he wants the memory to come from, so it's only logical to assume that he isn't thinking about it and is therefore relying on the compiler to do the right thing for him.
>
> If the programmer wants to force the storage to one place or another, he can say so explicitly. (using calloc, malloc, gc.malloc, etc)
>
>   -- andy

That's a very nice idea Ben ...

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:cfiam0$hhc$1@digitaldaemon.com...
>
> > Because, if not, then the following modification is the sort of (keyword qualifier) thing that would hand control back to the programmer:
> >
> > {
> >     uninitialized char[1024 * 32] workspace;
> >
> >     formatter (workspace);
> > }
> >
> > That's perhaps not the best name for it, but you get the idea.
>
> another option is to look for "void" as an initialization value:
> {
>   char[1024*32] workspace = void;
>   formatter (workspace);
> }
> that way we don't need another keyword. If the initializer is void the
> variable isn't initialized.

May I point you towards this post, which has an attempted summary of the discussion thus far? news:cfhqhu$9jj$1@digitaldaemon.com

Would very much appreciate your comments on those points.

I think, perhaps, this unfolding picture indicates it's not a question of ideology per se; but one of stack-usage being somewhat incompatible with the current GC design. If there were some means to quickly eliminate what look like old GC references from the (reused) portion of the stack that's still live, then what Ben has suggested would presumably be more palatable? Currently, the method employed to achieve this is to wipe everything to a predefined default value; which can be agonizingly slow compared to the C/C++ approach.

Is that a fair assessment?


"Walter" <newshound@digitalmars.com> wrote in message news:cfisfb$s39$1@digitaldaemon.com...
> "van eeshan" <vanee@hotmail.net> wrote in message news:cfhv05$bl9$1@digitaldaemon.com...
> > > Uninitialized data can be a source of bugs and trouble, as I pointed
out
> > in
> > > my other posting, even when used correctly. One design goal of D is to improve reliability and portability by eliminating sources of
undefined
> > > behavior, and uninitialized data is one huge source of undefined, unportable, erratic and unpredictable behavior. I'm trying to squeeze
> that
> > > out of the normal constructs in D - but access to C functions and
inline
> > > assembler is there for folks who really need it.
> >
> > But here's where that position truly falls apart ... what about those multitude of cases where buffers are reused over and over again? What
> about
> > thread-local workspaces? What about pooled buffers?  what about all
those
> X,
> > Y, and Z variations? They do /not/ get automagically re-initialized.
>
> Right, they don't. However, data buffers are unlikely to contain garbage that looks like pointers into the gc heap, whereas garbage on the stack
*is*
> very likely to. Next, detritus in recycled data buffers is not going to consist of objects that are no longer valid, the source of the other
problem
> I mentioned. And lastly, D can't close every hole, but that doesn't mean
it
> shouldn't close what it can.
>
>

van eeshan wrote:
> With respect Andy, the programmer was quite explicit about where the memory
> should come from ... it's a locally-declared array, and the language
> documentation points out such declarations are place on the stack (just like
> C/C++) because there are some very good reasons to do so. If you abstract
> that notion away, then we're not discussing D anymore. Note that the
> declaration does not have static, const, or any other qualifier either.

One of the greatest things about D is that we have a chance to change it.  Therefore, we are discussing D even if we abstract that notion away, because D itself may follow suit if we can convince Walter. :)

The declaration, taken purely at face value:

    char[1024 * 32] workspace;

declares 32768 consecutive chars under the name 'workspace'.  Since the 'new' keyword is not used, this storage is only guaranteed to exist within the function's scope.

It doesn't necessarily have to say any more than that: the D language (not the D compiler implementation) is much more than spec for a portable assembler, (as C was) and it makes perfect sense to describe it in conceptual terms where possible because concepts are by far the most common use case. (code is rarely optimized before it is written :) )

Ideally, the compiler knows what the output has to do, but is completely free to achieve that any way it wants. (this is the main reason O'Caml is so fast, as I understand it)

However, there's no denying that D is a systems language, so it goes without saying that there absolutely must be a convenient way to say that you *do* care precisely where that storage comes from and how you want it to be handled.

I like how C# handles this: it has a 'stackalloc' keyword which, true to its name, allocates stack storage.  By being a language primitive, it presents plenty of information to the code optimizer.

So, hypothetically, we would be able to write

    // want chars.  Don't care where they came from.
    char[1024*32] workspace;

    // get 'new' storage from the GC.
    char[] workspace = new char[1024*32];

    // allocate stack storage
    char[] workspace = stackalloc char[1024*32];

 -- andy

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cfhvbq$bra$1@digitaldaemon.com...
> In article <cfhqhu$9jj$1@digitaldaemon.com>, van eeshan says...
>
> >>Since the
> >> uninitialized data consists of old D stack frames, it is highly likely
that
> >> some of that garbage will look like references into the gc heap, and
the
> >> gc memory will not get freed.
>
> >Are you really saying that the D GC is incompatible
> >with long-term stack content? That is, if I place some arbitrary values
in a
> >stack array during main(), will those values cause the GC confusion throughout the remainder of program execution if they happen to look like
GC
> >references?
>
> I think you may have misunderstood Walter. Arbitrary random data can
indeed give
> the GC false positives, but this usually doesn't matter, since it is rare.
What
> Walter said is that uninitialized stack data is /not random/ - in that it
is
> almost certain to contain fragments of some previous stack frame, and
therefore
> also /real, valid/ (but out-of-date) references to GC-controlled memory.
So the
> number of false positives will shoot up from "almost none" to "very many".

You're right, I'd forgotten to make that clear. Uninitialized data is "garbage", but that's not at all the same thing as "random". In my extensive experiments with this, text and integer "garbage" rarely looks like a valid pointer into the gc heap, but old stack frames are very likely to.

Also, it is not a matter of "incompatibility" with gc, it's more a matter of the gc being more effective.