Re: Tech directions for Delphi?

No, you really don't. To the other thread, it's just another pointer.
To the creating thread, the other thread is just another root keeping
the data alive.

Nope, the gen 0 heap isn't just a bunch of pointers in a graph, it's also data bytes kept together so that you can perform incremental allocations.

http://www.mcse.ms/archive112-2004-10-1193662.html
See step 1-6 description, pay particular attention to step 5.

Nothing special. The data is promoted to gen 1, and relocated, same as
always. Yes, it's moved out of the per-thread gen-0 heap, but so is
any other data that's still alive.

This is a movement a classic allocator doesn't necessitate.

There's nothing special about having a cross-thread reference, here.

Well, there is one: cross-thread data is by nature "more alive" (it's life times can't be isolated to a single thread), and GC'ing it requires to either freeze all the threads involved (server GC), or not GC until all the threads involved have stopped their activity (workstation GC).
I'll refer you back to step 5 and 6 above as to why. This also explains the conclusion of my previous post.

Yes. Garbage collection suspends all managed threads. So?

And you have... no problem with that?
We're talking different physical processing units, not a single CPU running multiple threads... that makes this constraint something from the Win3.1 era.

That's impressive, as alloc on .NET is not much more than advancing a
pointer.

It's the same with FastMM, you just have less hoops around advancing the pointer (the code is open-source, you can check it).

Interesting choices of words. "Insane" is not the normal experience.

When doing... what exactly? Short-lived tasks as in a web server?
Or with a mostly-at-0%-CPU-usage-DB-client? Yes, if that's your normality.

Not really. Most desktop apps build a relatively modest working set (a
few forms, say) and don't add to it all that much.

I don't know which desktop applications you're referring to, for those I'm dealing with, the working set represented by the forms themselves is very negligible compared to their actual working set, of which only part is surfaced on the forms.

Each event handler may involve some string bashing or collection manipulation,
> but in most cases the temps go away with the event handler.

I would rather say that each event handler deals with application data, reads some of it, modify some of it, adds some new data... but temporary stuff?
What there is of it is very small. Sure the OnPaint event of TLabels may be only doing temporary stuff, but anything more complex will be dealing with doublebuffering, declaring and maintaining interactivity regions, fade regions, bitmaps, DB components will update their caches and move their cursors, and a myriad of other entities which will live after the event.

An event that creates structures that go away as soon as the event handler terminates is either doing some very complex stuff producing a very simple result (like finding the answer to the meaning of the universe), or more likely, it's doing unnecessary work that could have been avoided, anticipated, deferred... or as we say here: it's code in need of a shift+del refactoring ;)

> Apps that keep building their working set (symbol tables, or various sorts
> of event logs) are commonly used but are a small proportion of apps written.

Symbol tables and event logs weren't the kind of data I'm thinking of.

A few years back, a Borland R&D guy told me that he'd done some
profiling, and most Delphi apps spent most of their time in the memory
manager. If FastMM means that this is no longer true, that's very
impressive.

The old memory manager could turn into an absolute horror in multithreading. Actually, you didn't truly need multithreading (there are very short snippet that could trigger the issues), but multithreading made the issues much more visible.
What's surprising is that Borland never cared to address this issue earlier: there have been alternative Delphi MMs for years, for as far as I remember (though I don't remember before Delphi 2, since I didn't use Delphi before that one). Quite a few of the FastCode MM entries had roots dating way back, and when dealing with multithreading, all of them (even basic wrappers of the WinAPI heap, which I suppose should have been the minimum for Borland to try) did better than the stock MM.

> The real point of .NET is the productivity that you get
from automatic memory management;

There are different ways to achieve automatic memory management, GC is just one of them, and it's one that comes at a price, that of complexity of implementation *and* usage.
The GC not being deterministic means you don't have simple ways of diagnostic for leaks (aka forgotten references), witness all the .Net applications out there that have a high memory usage and are commonly plagued by leaks.
I wouldn't be surprised if MS weren't to introduce different-from-GC automatic memory management in .Net at some point, they already have it in some extent for C++/CLI, and IMO they'll need it at some point.

As for leaks today, a great eye-opener is to try and run "normal" C# samples on a CF.Net device, where every leak will bite quick and hard. You can trust OpenNetCF, but the rest is rather risky business...

In practice, of course, .NET apps don't do "a whole system lockup
every few minutes."

Well, if they stay at 0% they won't of course, but .Net isn't marketed as a replacement for VBA and other low-load application development tools.
If you assume low-load and plenty of memory, of course it well do well, but so would just about anything, there is no challenge and no glory.

> but it really is a rare app that uses hundreds of megabytes of working memory.

And 640 kB is enough for everyone? ;)

I know Bill never said that, but apps that use hundreds of megabytes aren't that rare anymore, to reuse an argument, keep in mind that one of today's high resolution *icons* takes more memory than the first PCs could accomodate, and that a .Net "hello world" would barely fit in the memory of the first Win95 machines...

No impact on the foreground apps; no system lockups;

That's because your system's OS isn't .Net-based, freezing of the .Net threads thus affects only the .Net threads, leaving the rest of the OS and applications responsive.

You can always write bad code.

And the role of an OS/framework is in making sure a piece of bad code won't affect the rest (especially if the rest in is other threads), that other applications will keep running as long as possible unaffected, that time-critical threads (all multimedia and interactive animated UI stuff) won't be paused for more than a handful of milliseconds, etc.

Eric
.

Relevant Pages

  • Re: ptrs validity
    ... I have a pointer that points to an unknown heap memory block, ... hardware checked segment for each allocation. ...
    (comp.lang.c)
  • Re: What Kind of DataStructures C using? ( Heap or Tree ??)
    ... > Some were said heap, ... instructions and data is put on a stack. ... reserve memory on the heap and ... return a pointer to this memory area. ...
    (comp.lang.c)
  • Re: loading csv-files: too much memory-consumption
    ... contain an assumed pointer to heap data. ... to see the memory map of your lisp implementation. ... use this kind of non-initializing memory allocation, the probability ...
    (comp.lang.lisp)
  • Re: Pointer validity
    ... Implementations are allowed to do whatever ... impossible to classify a pointer value as stack or non-stack ... >> Pointers to valid memory locations can come from an external ... >> friends, for locating heap corruption, dangling references, etc. ...
    (comp.lang.c)
  • Re: .NET anger.
    ... with a heap system, but it's an expensive no-no with a heap, too. ... Most apps do not continually ... build state that must be relocated; most apps do use memory very ...
    (borland.public.delphi.non-technical)