It's a great idea. I love it. However, there are only two ways I can see something like that getting built: the large way or the small way. The large way would be as a tool designed to work with one of the major languages/environments. It would have to deal with all the bloatedness that implies, plus the fact that those environments were never designed to provide this sort of transparency or hackability. It would probably be a large corporate project that took years and cost millions; this probably won't happen. The small way would be because one or more hackers decided to build something new that stayed close to the hardware and was designed for this sort of thing. That's much more doable, but puts you well out of the mainstream for a long time.

I wouldn't be surprised if people eventually come around to this point of view. It will take a while, though. The current thought is that parallelism will save everything. It could take a decade before people figure out that that isn't going to happen. Maybe then there will be a renaissance of going back and rebuilding things from the ground up. But I'm rambling.

"People who are serious about software have to be serious about hardware"... that Alan Kay has a gift for putting his finger on things.

I can see a way to build it fairly simply.

The object information is readily accessible when you compile your program with -pg, the memory map is accessible through /proc, it shouldn't be too hard to couple the one to the other and make a nice display. If you are clever about it you might even be able to fish out what memory is filled with what type of data, and colour the map accordingly.

No millions required, unix is pretty clean when it comes to stuff like this.

Some joker had written a shell replacement based on 'doom' where you could literally shoot the processes. You had to hunt them down first of course...

I see now that you're talking about the OS level where I was thinking more at the language level. Still cool. Let me know when it's ready :)