20,741
edits
How the Nasal GC works: Difference between revisions
Jump to navigation
Jump to search
m
→Problem
m (→Problem) |
|||
| Line 59: | Line 59: | ||
= Problem = | = Problem = | ||
{{FGCquote | |||
|we now know that regular and unpleasant stuttering is caused by Nasals garbage collector | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27338887/ | |||
|title=<nowiki>[Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 Hz | |||
rate)</nowiki> | |||
|author=<nowiki>Robert</nowiki> | |||
|date=<nowiki>2011-04-10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
| the garbage collection pass must be done in a single atomic step, otherwise it would leave the heap in an inconsistent state and adversely affect the scripts. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27338915/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
|author=<nowiki>Curtis Olson</nowiki> | |||
|date=<nowiki>2011-04-10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|There are algorithms for incremental and/or concurrent and/or parallel garbage collection out there. They most likely not easy to implement and as far as I have seen so far would require (at least for concurrent and /or parallel GC) all writes of pointers to the Nasal heap (and possibly reads) to be redirected via wrapper functions (also known as (GC) read/write barriers). | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27338998/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2011-04-10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|This will not be an easy task but in my opinion it would be a promising option. It might be possible to use a GC module from a GPL:d Java vm or similar. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27338998/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2011-04-10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|just running the normal (mutually exclusive) Nasal GC in another thread than the main loop is not hard - but since it is mutually exclusive to executing Nasal functions it doesn't help much when it comes to reducing the worst case latency. | |||
The small changes needed to add a separate GC thread are available here:* http://www.gidenstam.org/FlightGear/misc/test/sg-gc-2.diff | |||
* http://www.gidenstam.org/FlightGear/misc/test/fg-gc-1.diff | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27338998/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2011-04-10</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
| the result is very similar to the standard FG since even if the GC is run on a different thread it still takes the same amount of time and while it is running the main thread will be blocked waiting for it as soon as it tries to run some Nasal code. | |||
Note that there is a spurious change in simgear/nasal/code.c that makes variable creation without the var keyword illegal. I use that to make sure my Nasal scripts are clean in this regard but there are plenty of scripts in fgdata that do not pass that test (and, well, they are still valid Nasal). I'll update the patch file ASAP but please revert that file to the standard one in the meanwhile. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27340770/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal Garbage Collector (was Stuttering at 1 | |||
Hz rate)</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2011-04-11</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|there is still the issue that you can't execute Nasal while the GC is running (for that you'd need a concurrent GC which is most likely not so easily implemented). The implication is that if the time required for a collection exceeds the frame dealy you'll still notice it even when the GC runs in a different thread. | |||
I have updated my experimental patch from last year, which should also work on Windows now (and it has even been tested there): | |||
* http://sleipner.gidenstam.org/users/anders/FlightGear/sg-gc-4.diff | |||
* http://sleipner.gidenstam.org/users/anders/FlightGear/fg-gc-3.diff | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29306592/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal performance</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2012-05-23</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|It doesn't solve the bigger problem of the current Nasal GC needing to run uninterrupted and in mutual exclusion - but I see very few GC runs in the main loop here (the patch prints "** Nasal GC in main thread **" in the console when that happens) except a few during startup. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29306592/ | |||
|title=<nowiki>Re: [Flightgear-devel] Nasal performance</nowiki> | |||
|author=<nowiki>Anders Gidenstam</nowiki> | |||
|date=<nowiki>2012-05-23</nowiki> | |||
}} | |||
}} | |||
The [[Nasal]] language is a dynamic programming language, where memory is not manually allocated and freed by the programmer, but instead the Nasal virtual machine automatically allocates memory from so called "memory pools", every so often these memory pools must be checked, to see how many references (i.e. objects like variables) are still reachable, so that the unreachable ones can be removed from the memory pool and/or so that memory blocks in each pool can be allocated or freed. This is called "garbage management" or "garbage collection". | The [[Nasal]] language is a dynamic programming language, where memory is not manually allocated and freed by the programmer, but instead the Nasal virtual machine automatically allocates memory from so called "memory pools", every so often these memory pools must be checked, to see how many references (i.e. objects like variables) are still reachable, so that the unreachable ones can be removed from the memory pool and/or so that memory blocks in each pool can be allocated or freed. This is called "garbage management" or "garbage collection". | ||