Nicholas Clark wrote: > <digression> > Which in C terms scares me, as *how* can the allocator know for sure? > Sure it can stack walk, and probe all the CPU registers for pointers to buffers, > but there are defined C behaviours you can do (such as storing only a pointer > somewhere into your buffer at fixed known-to-you offset.
This is all disallowed[1]. All memory allocated must be identified by DOD. [1] if you have a PMC with a custom destroy method, you can allocate what you like, _if_ you release it in vtable->destroy. The interpreter PMC will be such a case. If we use a _real_ GC system like Boehm gc, then we don't need DOD either - if this works (I would be a little bit scared, when GC is walking inside the JIT machine, OTOH this is allocated memory too ;-). Our current approach is, that we know all memory usage, so we can free it, copy it around or whatever. >>Yes, when our interface is malloc/realloc/free, any allocator could be >>plugged in. >> > > Which is what I was thinking when I left work. If we're only allocating, > tracking and garbage collecting buffers, what stops us having the option > of getting and returning memory from the system's malloc()? Nothing. My patch, to be sent in some minutes, contains this option: perl Configure --gc=libc > Nicholas Clark leo
