On Thursday 11 April 2002 07:03 pm, Michel J Lambert wrote: > Dan Sugalski wrote: > > That's because GC_DEBUG is fundamentally broken by design. It's doing > > things it shouldn't be doing--the system is such that it shouldn't > > ever trigger GC before the memory allocation system is set up. > > > > If this patch disables the GC only when GC_DEBUG is in place, I'll put it in. > > So you're saying that the calls to get memory during interpreter > initialization are somehow guaranteed to not require more memory (and thus > a dod or collection run)? Currently, this guarantee is not expressed in
I don't understand the "thus." Nothing states that requesting memory mandates a DOD/GC run. > code, comments, or documentation, from what I can tell. And I personally > hate implicit assumptions like these...they're the cause of all that magic > voodo, far away from where it's obvious what the problem is. We have no > idea of knowing how much is 'enough' for the GC to allocate at startup, > aside from the following the code and tracking allocations, which can be > a pain. I guess it depends on what you consider to be initialization. Little, if any, of what the interpreter itself demands in memory - including memory for the GC itself - is going to be reclaimable; it's all mostly persistent throughout the life of the interpreter. If there's not enough memory to bootstrap the interpreter and the GC, then even if the GC *could* reclaim enough to satisfy subsequent requests, there's not going to be nearly enough memory left to do anything. So why bother? (Just) enough of the interpreter needs to start up to start up the memory allocator and the GC subsystem. If it needs more memory to do so, it should simply be given more memory. After the GC is up and running, the interpreter/bootstrapping process can trigger a GC run to free up as much memory as it can. The remainder of the interpreter can then start up, running through the GC. -- Bryan C. Warnock [EMAIL PROTECTED]
