Mike Lambert wrote: >>First and foremost, is there any compelling reason, to have totally >>different structures for PMCs and Buffers? >>- Both have a ->data aka ->bufstart >>- Both have ->flags, that have vastly the same meaning. >> > > As jason said in another message, Dan has changed his mind from > yesteryear, and decided that buffers and pmcs should be the same > structure. There are a few ideas of my own that would be better > implemented if we unified the two,
Are there any additional hints or pointers regarding this? > ... but unfortunately, I haven't have the > motivation to unify them. I made a few passes at it, and the task is just > monumental, in terms of lots of search and replaces, and lots of debugging > to track down why the semantics have broken. :) Yes, changing internals like these, would yield huge patches and isn't easy. > I could attempt a piecemeal conversion, submitting patches that get us a > bit closer, except that each patch would not be acceptable on its own due > to the confusion introduced. ie, having PMC use BUFFER_*_FLAGs, The internals during changes could be hidden with some #defines. So the surface would stay the same. > ... or having > worse memory usage/dod-speeds because of the larger size of buffers/pmcs > after they are unified, etc. Don't think so, that a unified type has to be larger. I tried to layout a data hierarchy, which basically should work, when other usages of e.g. "flags" and "buflen" in other structures or protypes are first renamed (s. attached test prog, native types used for brevity). [ recursive marking ] > So while it may seem more memory efficient to not use next_for_GC, it > actually isn't. A linked list of 500 elements would cause 500 recursive > calls and use more memory than would a next_for_GC solution. I'm not aware of such a deeply nested list. But as marking now knows of e.g. array of PMCs, it could mark a linked list of PMCs as well, w/o deep recursion. >> SYNC *synchronize; /* undocumented + unused */ > This is for multi-threaded access, where you need to synchronize on > something as a way to control access to the PMC. Of course, this is > entirely placeholder, as we don't have multi-threading or multiple > interpreters. :) Would a "in_use" bit not suffice? >>What are: arena_base->extra_buffer_headers; > ... and > maybe we should force all headers to come from header pools. I think, we need just the sized pools, keeping things of same size together and one unsized pool. Both in two variants for vars/constants. > ... But there is > no compelling reason to do so, at this point in time. (I have some ideas > that would require it, tho) Could you elaborate on these ideas? [ sized pools slot ] > ...If there are no objects of a > given size, then there is just a null pointer in the array. Are you seeing > something else? For some reason I misread the code, and thought the unused pools were allocated. > ... I don't think we want interpreters appearing and > disapppearing with references...they should be explicitly created and > destroyed. Actually, it's not a big difference, how they are destroyed, but we have already a "newinterp" opcode, so a interpreter PMC class just needs a custom destroy method - that get called too ;-) Though, if nested structures inside the interpreter are all buffers, destroying them would neatlessly fit into the framework. > Hope this helps answer your questions, Yes, thanks you for the detailled answers. > Mike Lambert leo
