asr wrote in Mon Jan 20, 2020 10:42 am:I'd like to have a look at how the GC works and what diagnostics are exported (if any).
See:
http://wiki.flightgear.org/How_the_Nasal_GC_worksI believe Richard reworked the GC to provide a new option so that it can be partially run outside the main loop.
Also, Richard mentioned on several occasions that he exposed additional Nasal GC at the property tree level, to track what's going on.
For details, I'd suggest to search the forum/commit logs or ask Richard directly. If in doubt, it might make sense to document those options on the wiki.
In addition, it might be a good idea to add such runtime info to the help/about dialog, or a dedicated "diagnostics" dialog, which should ideally also show if the new GC is enabled or not - possibly in conjunction with a checkbox (boolean) and a userarchive attribute, so that people can customize this on demand.
That being said, the number of active references/objects, as well as types/pools are fairly easy to retrieve from the GC, but there is some added complexity.
We can really only identify trigger points, but a GC run being triggered may not necessarily point to the line causing this.
As a matter of fact, the legacy GC defaults were far too inadequate for modern FG versions, i.e. pool size and other defaults can benefit from being customized, and possibly being exposed to the property tree.
Back when I last checked Nasal memory occupancy, it would require 16 MB of RAM, whereas the Nasal defaults were far too low.
Once these GC stats are exposed, it is also possible to plot those properties at runtime, and possibly add them to the OSG stats handler to tell what's going on.
Anyway, all that we can obtain at that point is the file name/line number last executed - which makes more sense to use for callback tracking (timers & listeners).
But like I previously said, exposing these Nasal internals at the property tree level would make sense for a number of reasons, i.e. better troubleshooting, but also fine-tuning/tweaking.
Given that we have a rather powerful autopilot/property rule system, we could even set up a dedicated PID controller instance to control currently hard-coded Nasal GC defaults at runtime by using frame rate and frame-spacing to drive the whole, which is an idea that both, James and Stuart repeatedly mentioned on the devel list in the context of benchmarking and dynamic feature scaling:
http://wiki.flightgear.org/FlightGear_Benchmarkhttp://wiki.flightgear.org/Feature_ScalingComing up with a property-tree interface for the built-in OSG/FGStatsHandler is another long-standing suggestion dating back to the early 2010s:
http://wiki.flightgear.org/OSG_on_screen_statshttp://wiki.flightgear.org/Towards_bett ... time_stuffhttp://wiki.flightgear.org/Resource_Tra ... atsHandlerhttp://wiki.flightgear.org/Canvas_Troub ... _Osg_Stats Given how well XML and the property tree work together, it would be kinda cool to provide a corresponding XML/property-enabled wrapper, so that arbitrary properties could be added to the OSG on-screen stats - at that point, exposing things like Nasal GC internals, would merely be a matter of turning C++ PODs into propertyObjects<>:
http://wiki.flightgear.org/Howto:Use_Pr ... ee_Objects