*shudder* external garbage collection outside of an interpreter scares me
i imagine things running rampant...
i know you're a PERL guy, but Python will show you gods you havent seen :P

What's the state of Python GC these days?

With 2.3 there were some weird takedown issues, but nothing that should affect the day-to-day hacker- so- solid as always :)

When I see comments like this, I get curious whether those making them are familliar with Perl... Most who I know well don't know Perl. The fact that you've capitalized PERL makes me wonder ;)

Mayhap I should learn Python right now and find out for myself :)

Yes- I'm familiar with PERL- judging by productivity output, it is in fact my language of choice- but with a higher calling I've embraced Python- ESR said it correctly in "you can contain it entirely inside your mindspace" (paraphrased)- in PERL there are just too many ways to do things- in Python there is only "The Way" :P
And Capitalization?
Pattern Extraction and R(shit- cant remember) Language

a) R = Reporting
b) "Python fits your brain."

Practical Extraction and Report Language. And it's a unix command, so it really should be perl(1), no? =:)

That's what they call a "backronym." People kept asking what Perl stood for (it didn't :), so Larry made up a couple of acronyms:

Practical Extraction and Report Language
or
Pathologically Eclectic Rubbish Lister

Hmmm as someone else commented, it's apparently a "backronym" hahah:

People kept asking what Perl stood for (it didn't
:), so
Larry made up a couple of acronyms:

Practical Extraction and Report Language or Pathologically Eclectic
Rubbish Lister

Here's the official blurb from Larry:

You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl isn't really an acronym, apocryphal folklore and post-facto expansions notwithstanding.

So Perl it is then :)

Yay code, but yayer pizza. Now I'm all hungry...

It's not necessarily a safe assumption that GC is unreliable or that it will make your program slower. The Boehm GC is an incremental collector that won't interrupt your program. In particular, see the Allocation and GC Myths for a set of slides outlining some of the common misconceptions about memory allocation. The only way to be sure about performance is to measure it.

At least how I have it now, the allocation/freeing is centralized, so I can easily benchmark:

* pure GC
* my maybe-ghetto freelists
* a C library to do just those allocations (if it comes to that)

Careful. Most GC algorithms have a time complexity of
O(amount of active storage). Freelists of objects that require tracing will increase the amount of work for the garbage collector.

looks nifty... but the first "NULL" "bug in linux" that i looked at doesn't seem like a bug... complaining that

priv		    = drm_alloc(sizeof(*priv), DRM_MEM_FILES);

is accessing uninitialized memory... but sizeof is purely a compile time operator as far as i know (is there some gcc extension that is at work here?)... and most of the NULL bugs looked like that...

the other categories of bugs look pretty interesting... ie blocking issues... although i can't comment on the severity (if any) of most of them...

--scott

You might want to consider slab caches, which are data structures that are specifically designed to be used in cases where you have lots of small objects that are allocated/freed rapidly, especially if some state can be retained in the object between allocation/freeing (your object has three fields, but typically only one changes between uses).

See BONWICK, J. The slab allocator: An object-caching kernel memory allocator. In USENIX Summer 1994 Technical Conference (1994).

And there's a follow up paper I can't find at the moment for SMP'ing slab caches. Neat stuff. And hey, Linux uses it, so it must be great.

Yeah, memcached uses a slab allocator.

It doesn't really work in C# because you can't allocate arbitrary chunks of memory and cast them as whatever. (C#'s all safe, ya know?)

Hence the freelists. (which make more sense because I'm only allocating two types of objects often...)

Why do you need arbitrary chunks of memory? a simplistic slab is just an array of objects _of a given type_. Dynamically allocate the slab, and then allocate/free objects from that slab. Surely you have some semblance of dynamic allocation in C#?

Hmm, I should get pizza for my code upgrading party.. But its not much of a party when there is only one of you..