This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: tools to make non-conservative GC feasible.






>Not really. If you're interfacing with arbitrary c code, the c code is
>already doing it's own 'memory management'. If you need to pass it
>objects from scheme, then you have to convert it to something the
>program recognizes and handle that, but the actual operation of the c
>code is something you don't have to care about.

Well, I could use the same argument in  favour of precise gc. If the C
code is doing its own memory management, who cares about the tiny bit
of work needed in the scheme wrappers to allow precise gc.

>The question is, how often does this actually happen in a real
>program? In order for a dead object to never be collected, there has
>to be a place on the stack that never changes, or a value that is put
>on the stack quite frequently, that corresponds to an object that
>guile knows about. It can and does happen, but it's very unlikely that
>it will happen with a significant number of objects.

I agree that the odds of it happening are extremely small. I can just
picture this program running one day and it just happens on this
particular day to be doing calculations that just happen to be right
smack in the address space of the process. Agreed that I will probably
never live to see this day, but it just bothers me. Would you trust
your medical equipment to it? Would you trust your nuclear arsenal to it?

>In the file descriptor case, unless I'm missing something, files are
>expected to be explicitly closed by scheme, so you aren't really
>wasting fds if it stays live, just the space held by the fd structure
>(this is unfortunate, because it lessens the reliability of guardians,
>although I really doubt you'd see a situation where you ran out of
>fd's because they were all being held up by the stack... you'd need
>some really bad luck).

Agreed, very very bad luck. But imagine if you allocated 100 fds for some
daemon. Then for some reason it did some recursive function that calculated
a sequence in that very range. I don't think I'll ever see the day,
but there may be critical applications that you don't want to take the
chance.

>Even the performance of some widely used algorithms (quicksort, for
>one, which probably isn't the best example since there are a lot of
>work arounds to make the bad case almost completely unlikely, but it's
>the first thing that pops to mind) have such a bad worst case that
>they could end up executing forever. Generally, it doesn't happen, so
>we accept the unlikely possibility and move on. This is a case where I
>think you have to consistantly see incorrect behavior in a real
>program before you chuck a very useful feature that, by all accounts,
>works quite well.

Well, at least quicksort will still work correctly, so I think that's
really a bit different.

You are right of course. It just goes against my grain to ignore border
line cases.