-
Notifications
You must be signed in to change notification settings - Fork 504
Some internal data structures seem to stick around and start filling memory #580
Comments
Maybe a bit more simpler example adapted from your test case volatile-objects.phpt:
|
I have committed a fix to make var_export and var_dump consistent ... However, the problem isn't going to go away ... when you unset() you can only unset the member in your own thread, you unset it from the shared properties table too, but it is impossible to unset it in another threads standard property store, it will be retained in that store until the object is destroyed. Let me think about this a while ... it really is impossible to free anything on another contexts heap, but maybe we can do something ... |
Ok, so I had a think about it ... we can synchronize the store on read of a property, and on synchronized ... so committed these changes ... it means you have to take special action, but volatile things are volatile ... it should not hamper the performance of non-volatile objects ... have a test with that, workable ? |
Could it be an option to trigger a cleanup function per thread in userland? |
Ok, I see, I can understand that. I've tried the new version, var_export and var_dump seem the same now. However, it still seems to consume memory until it maxes out the machine though, if I add 100000 at a time and then remove them all and then repeat. When you say 'take special action', what do you mean? I tried wrapping the adds and removes in a synchronized to see if that helped, but it didnt. |
hmm ... synchronized should have done it .. solution will probably change, but for now it should cleanup on synchronized or reading a property, which is what I meant by special action ... I might have messed something up, let me come back with a clear head and look at the problem again tomorrow ... |
Ok cool, no probs. When you get the time. Just to show you what I'm doing, so I dont waste your time if I'm doing something bad.... ;) I can see memory in 'top' going up and up, and eventually php fatals and says out of memory.
|
Hi, Any thoughts or ideas on this one? I'm having problems with running out of memory quite a bit now. Thanks. |
Sorry, I'm not ignoring you, just super busy :( I'll get to it, when I can ... |
Ok sure, thanks. :) |
@RobDonovan |
Environment
Summary
When using Volatile arrays, it seems that 'unsetting' the array elements doesnt fully remove the data. The thread that unsets them seems fine, var_dump($this) & var_export($this,true) shows that. But the thread that actually set the data still has the data locally somewhere. It doesnt show with var_dump($this), but it does show with var_export($this,true). Not sure why, and I couldn't find what the diff was with dump or export.
If you loop this to make the creator thread create batches of 100000 and then the deleting thread delete them all, and then loop, and leave it running, eventually all memory is consumed.
It seems to be to do with myRec being 'Threaded'. If its not threaded its fine, but I then cant set individual members like in setData1() as it just ignores the set.
Sorry for a not so simple test case, but this was the simplest way I could show it happening in a test case.
(Ignore the unsafe waiting and notifying, its just for the example, and the sleep is just to make it easier to show this happening rather than a more complex wait/notify.)
Reproducing Code
Expected Output
Actual Output
The text was updated successfully, but these errors were encountered: