Is there functionality to disable all automatic gc() without actually hardcoding it in the code? In certain cases, say if you make a game (no, I don't have an actual project - it's theoretical), you definitely would want to limit gc to predictable times (such as right after loading a new level - get any gc needed from the level loading and the previous level).
In what code would it be hardcoding? Is Pike.gc_parameters in 7.5 what you're looking for?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-04 22:04: Subject: Predictable gc == manual
Is there functionality to disable all automatic gc() without actually hardcoding it in the code? In certain cases, say if you make a game (no, I don't have an actual project - it's theoretical), you definitely would want to limit gc to predictable times (such as right after loading a new level - get any gc needed from the level loading and the previous level).
/ David Hedbor
Yes, that looks likely. In 7.4 or before you have to go into the C-code to disable gc().
/ David Hedbor
Previous text:
2003-04-04 22:08: Subject: Predictable gc == manual
In what code would it be hardcoding? Is Pike.gc_parameters in 7.5 what you're looking for?
/ Martin Stjernholm, Roxen IS
That's right. In earlier versions you can still control the gc somewhat by making explicit gc() calls sufficiently frequently, but that's typically not a solution.
If there's a demand for it in 7.4 I wouldn't be against backporting Pike.gc_parameters.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-04 22:10: Subject: Predictable gc == manual
Yes, that looks likely. In 7.4 or before you have to go into the C-code to disable gc().
/ David Hedbor
The main goal is to call it less often I'd say (or at least KNOW where it's called). Of course, for most normal sized projects, you wouldn't ever get to a stage where gc time matters.
/ David Hedbor
Previous text:
2003-04-04 22:16: Subject: Predictable gc == manual
That's right. In earlier versions you can still control the gc somewhat by making explicit gc() calls sufficiently frequently, but that's typically not a solution.
If there's a demand for it in 7.4 I wouldn't be against backporting Pike.gc_parameters.
/ Martin Stjernholm, Roxen IS
It does in AIDO. It takes about 1-2 frames to do a gc().
/ Per Hedbor ()
Previous text:
2003-04-04 22:33: Subject: Predictable gc == manual
The main goal is to call it less often I'd say (or at least KNOW where it's called). Of course, for most normal sized projects, you wouldn't ever get to a stage where gc time matters.
/ David Hedbor
Breaking it up is not impossible, but tricky. Running it in a separate thread wouldn't accomplish anything since it needs to hold the interpreter lock.
One could do a gc that only takes a randomly chosen thing and follows references from it. If it turns out that there are no external references then it's freed. This way the gc only inspects a small part of the linked lists in every run and it no longer takes linear time wrt the total number of allocated things.
There are problems with this approach, though. One is to tune the gc intervals to ensure that the gc isn't "starved", i.e. that garbage is generated at such a rate that the gc never manages to complete a single run through all things. Weak references are also tricky to solve; it's probably necessary to add an extra refcount field and a flag in every gc handled thing.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-05 16:15: Subject: Predictable gc == manual
It isn't possible to break up the gc() routine or run it in another thread, is it?
/ Mirar
pike-devel@lists.lysator.liu.se
-
David Hedbor ＠ Pike developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum