Bug #53803 [Opn]: circular reference between SPL classes not collected by gc_collect_cycles()
Edit report at http://bugs.php.net/bug.php?id=53803edit=1
ID: 53803
Updated by: cataphr...@php.net
Reported by:oliver at openbrackets dot net
Summary:circular reference between SPL classes not collected
by gc_collect_cycles()
Status: Open
Type: Bug
Package:SPL related
Operating System: FreeBSD
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I don't see how using SplObjectStorage would help, as it's a completely
different class. I'm saying for the time being you should destroy the
cycles manually instead of relying on the GC.
In any case, I'm not marking this Wont Fix.
Previous Comments:
[2011-01-28 10:20:25] oliver at openbrackets dot net
ok, that makes sense.
By saying:
I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
Are you suggesting that it would be possible to rewrite the test Case1
using SplObjectStorage? Or that we have to live with GC not being able
to clean up these circular references for th time being?
[2011-01-27 16:12:04] cataphr...@php.net
The fix for bug #53071 never claimed to fix all circular reference
problems in SPL classes, it fixed only the behavior in
SPLObjectStorage.
In fact, the problem is a design one and it is caused by the inability
of the garbage collector to know an object holds a reference to a
certain variable except through a property contained in the hash table
returned by the get_properties handler.
The fix to bug #53071 is actually a quite a hack; a proper solution
would involve maybe adding an extra object handler for the garbage
collector to use, but that cannot be done in the 5.3 branch. I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
[2011-01-21 13:09:57] oliver at openbrackets dot net
Description:
Circular references between instances of SPL classes are not cleaned
up by gc_collect_cycles().
The code in the test script can be run from cli. It shows growing memory
usage because the circular references between the instances of an
extended ArrayObject class and instances of ArrayIterator are not
cleaned up by gc_collect_cycles.
The long code sample, downloadable from the url provided in test script
section shows:
Case1: SPL classes: expecting gc_collect_cycles to clean up circ
references
Case2: SPL classes: manual clearing of the circular reference
Case3: Userland classes: expecting gc_collect_cycles to clean up circ
references
This looks similar to http://bugs.php.net/53071 , BUT I am running
php5.3.5 which AFAIK includes r304723 and r304724 which were supposed to
fix #53071.
Test script:
---
Short code sample:
class Collection extends ArrayObject implements Serializable
{
protected $iterator;
public function getIterator()
{
$this-iterator = new ArrayIterator($this);
return $this-iterator;
}
public function clearIterator()
{
$this-iterator = null;
}
}
echo Case 1: ArrayObject/ArrayIterator: expecting gc_collect_cycles()
to clean up...\n;
for ($i = 1; $i = 100; $i++)
{
$books = array('war and peace', 'crime and punishment');
$book_collection = new Collection($books);
$iterator = $book_collection-getIterator();
echo gc_collect_cycles() . : . memory_get_peak_usage() . \n;
}
full code sample:
http://www.realtsp.com/download/php_circular_reference_test_code_sample.txt
Expected result:
Expect all test cases (Case1, Case2, Case3) to have constant peak memory
usage.
Actual result:
--
Only Case2 and Case3 have constant memory usage.
In Case1 memory usage grows linearly with loops iterations.
This shows that gc_collect_cycles is not collecting circular references
between SPL classes. Also shown because it returns 0 cycles collected.
In Case 3 (Userland classes) gc_collect_cycles shows 5 cycles
collected each iteration.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53803edit=1
Bug #53803 [Opn]: circular reference between SPL classes not collected by gc_collect_cycles()
Edit report at http://bugs.php.net/bug.php?id=53803edit=1
ID: 53803
User updated by:oliver at openbrackets dot net
Reported by:oliver at openbrackets dot net
Summary:circular reference between SPL classes not collected
by gc_collect_cycles()
Status: Open
Type: Bug
Package:SPL related
Operating System: FreeBSD
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
ok, that makes sense.
By saying:
I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
Are you suggesting that it would be possible to rewrite the test Case1
using SplObjectStorage? Or that we have to live with GC not being able
to clean up these circular references for th time being?
Previous Comments:
[2011-01-27 16:12:04] cataphr...@php.net
The fix for bug #53071 never claimed to fix all circular reference
problems in SPL classes, it fixed only the behavior in
SPLObjectStorage.
In fact, the problem is a design one and it is caused by the inability
of the garbage collector to know an object holds a reference to a
certain variable except through a property contained in the hash table
returned by the get_properties handler.
The fix to bug #53071 is actually a quite a hack; a proper solution
would involve maybe adding an extra object handler for the garbage
collector to use, but that cannot be done in the 5.3 branch. I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
[2011-01-21 13:09:57] oliver at openbrackets dot net
Description:
Circular references between instances of SPL classes are not cleaned
up by gc_collect_cycles().
The code in the test script can be run from cli. It shows growing memory
usage because the circular references between the instances of an
extended ArrayObject class and instances of ArrayIterator are not
cleaned up by gc_collect_cycles.
The long code sample, downloadable from the url provided in test script
section shows:
Case1: SPL classes: expecting gc_collect_cycles to clean up circ
references
Case2: SPL classes: manual clearing of the circular reference
Case3: Userland classes: expecting gc_collect_cycles to clean up circ
references
This looks similar to http://bugs.php.net/53071 , BUT I am running
php5.3.5 which AFAIK includes r304723 and r304724 which were supposed to
fix #53071.
Test script:
---
Short code sample:
class Collection extends ArrayObject implements Serializable
{
protected $iterator;
public function getIterator()
{
$this-iterator = new ArrayIterator($this);
return $this-iterator;
}
public function clearIterator()
{
$this-iterator = null;
}
}
echo Case 1: ArrayObject/ArrayIterator: expecting gc_collect_cycles()
to clean up...\n;
for ($i = 1; $i = 100; $i++)
{
$books = array('war and peace', 'crime and punishment');
$book_collection = new Collection($books);
$iterator = $book_collection-getIterator();
echo gc_collect_cycles() . : . memory_get_peak_usage() . \n;
}
full code sample:
http://www.realtsp.com/download/php_circular_reference_test_code_sample.txt
Expected result:
Expect all test cases (Case1, Case2, Case3) to have constant peak memory
usage.
Actual result:
--
Only Case2 and Case3 have constant memory usage.
In Case1 memory usage grows linearly with loops iterations.
This shows that gc_collect_cycles is not collecting circular references
between SPL classes. Also shown because it returns 0 cycles collected.
In Case 3 (Userland classes) gc_collect_cycles shows 5 cycles
collected each iteration.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53803edit=1
Bug #53803 [Opn]: circular reference between SPL classes not collected by gc_collect_cycles()
Edit report at http://bugs.php.net/bug.php?id=53803edit=1
ID: 53803
Updated by: cataphr...@php.net
Reported by:oliver at openbrackets dot net
Summary:circular reference between SPL classes not collected
by gc_collect_cycles()
Status: Open
Type: Bug
Package:SPL related
Operating System: FreeBSD
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The fix for bug #53071 never claimed to fix all circular reference
problems in SPL classes, it fixed only the behavior in
SPLObjectStorage.
In fact, the problem is a design one and it is caused by the inability
of the garbage collector to know an object holds a reference to a
certain variable except through a property contained in the hash table
returned by the get_properties handler.
The fix to bug #53071 is actually a quite a hack; a proper solution
would involve maybe adding an extra object handler for the garbage
collector to use, but that cannot be done in the 5.3 branch. I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
Previous Comments:
[2011-01-21 13:09:57] oliver at openbrackets dot net
Description:
Circular references between instances of SPL classes are not cleaned
up by gc_collect_cycles().
The code in the test script can be run from cli. It shows growing memory
usage because the circular references between the instances of an
extended ArrayObject class and instances of ArrayIterator are not
cleaned up by gc_collect_cycles.
The long code sample, downloadable from the url provided in test script
section shows:
Case1: SPL classes: expecting gc_collect_cycles to clean up circ
references
Case2: SPL classes: manual clearing of the circular reference
Case3: Userland classes: expecting gc_collect_cycles to clean up circ
references
This looks similar to http://bugs.php.net/53071 , BUT I am running
php5.3.5 which AFAIK includes r304723 and r304724 which were supposed to
fix #53071.
Test script:
---
Short code sample:
class Collection extends ArrayObject implements Serializable
{
protected $iterator;
public function getIterator()
{
$this-iterator = new ArrayIterator($this);
return $this-iterator;
}
public function clearIterator()
{
$this-iterator = null;
}
}
echo Case 1: ArrayObject/ArrayIterator: expecting gc_collect_cycles()
to clean up...\n;
for ($i = 1; $i = 100; $i++)
{
$books = array('war and peace', 'crime and punishment');
$book_collection = new Collection($books);
$iterator = $book_collection-getIterator();
echo gc_collect_cycles() . : . memory_get_peak_usage() . \n;
}
full code sample:
http://www.realtsp.com/download/php_circular_reference_test_code_sample.txt
Expected result:
Expect all test cases (Case1, Case2, Case3) to have constant peak memory
usage.
Actual result:
--
Only Case2 and Case3 have constant memory usage.
In Case1 memory usage grows linearly with loops iterations.
This shows that gc_collect_cycles is not collecting circular references
between SPL classes. Also shown because it returns 0 cycles collected.
In Case 3 (Userland classes) gc_collect_cycles shows 5 cycles
collected each iteration.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53803edit=1
