Stanislav Malyshev wrote:
Hi!
Yes, I like this idea better as it's more flexible but I wasn't sure
if we wanted that much visibility into the global variables of the
allocator. I suppose though, as with other things of this nature, if
you're mucking with this data then you should be doing so at your own
risk etc. ;-)
Well, messing up AG is not worse than messing up EG or CG - you'll end
up crashing pretty soon anyway :) Only problem might be that it may
introduce binary dependencies that will limit what we can do in memory
manager between versions, so we need to consider this carefully.
Yeah, definitely makes sense. I'm also going on the assumption that this might
be useful at some point later on, rather than my single use case. Of course if
it isn't then we don't have to worry about binary compatibility either lol.
I hadn't considered creating a hybrid approach to this, perhaps that might be a
good alternative. Rather than exposing the entire structure or creating
one-off access functions (which has it's own BC issues), perhaps we should
expose a new structure that is just a portion of the existing heap structure so
we can expose only those items that we're willing to support. This won't fix
everything, but at least it might mitigate problems associated with opening up
the entire existing heap structure and allow some flexibility with BC if it
does change.
If it's interesting to everyone and saves you some time I can work up a patch
so we can see what that might look like too.
Thanks!
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
