How to stop garbage collection?

Targets Raspberry Pi
1

Hello,

I am working on some Raspberry Pi electronics projects and when Xojo does garbage collection (via reference counting) then apps that are doing sensitive timing have a large delay which prevents communication and/or causes logic errors in electronics.

Workarounds are to not create new variables and declare all variables that are used as global. This helps a great deal.

Does anyone know how to stop Xojo with garbage collection and/or reference counting?

Thanks :slight_smile:

2

My understanding is that, technically, these are different things designed to achieve the same goal. Xojo uses reference counting where objects are destroyed as soon as there are no more references, but you’d prefer garbage collection where the unused objects are removed periodically during free time. (Someone’s probably going to correct me here.)

You can implement your own garbage collection over reference counting, but how eat that might be will depend on the types of objects that are troubling you.

Or it might just be a matter of coding differently.

3

Thanks Kem :slight_smile: . Yes, I agree that these are two different methods to perform the same thing. Hmm… Maybe I should break this into two different sub-questions.

Reference Counting: When Xojo automatically does reference counting to remove references, then this takes processor time away from electronics that communicate with timing. These delays interfere with the binary data received and sent to electronics. When Xojo performs reference removal of objects then this delay causes spaces in received and sent data with electronics. Since Xojo works on one core, then this core must perform all of the work. Delays in timing are causing issues. I am not sure if it is the reference counting algorithm, the large size of Xojo, or what the issue is, and this delay causes communication error due to timing delays. When I limit the use of reference objects being created or destroyed by only using global variables, then there is less reference counting that occurs. Since these electronic delays still occur, then I am guessing that local variables within Xojo are being used, objects created, and objects are being destroyed, which is causing delays in timing. Is there a way to prevent Xojo from reference counting to allow me to program electronics that require sensitive timing communication with electronics? Maybe this is clearer, or maybe not :slight_smile:

Garbage collection: To my understanding (which could be completely incorrect), garbage collection in Xojo occurs to remove unused objects that have been dereferenced (see Reference counting above). Memory usage seems to increase for a while and then is flushed which lowers the size of the Xojo application in memory. Flushing takes processor time and causes delays in sending/receiving data in electronics. An example is that a binary 1 (on) is kept on for many milliseconds while garbage collection is performing object cleanups. Minimizing the use of local variables and attempting to only use global variables helps limit this issue in Xojo. Is there a way to prevent Xojo from Garbage Collecting unused variables, or at least allow me to delay this operation in the program so that I can complete my communication and then pause the program to allow Xojo to finish its garbage collection?

I have implemented my own garbage collection, and the issue that I am seeing is that Xojo is performing its own reference counting/garbage collection in the background that I have no control over. If I am able to control reference counting or garbage collection then I could program appropriate delays in the program. Right now the delays seem to be random. Is there a way to cause Xojo to perform reference counting or garbage collection at a specific time within the program.

Coding differently by using only global variables does help alot, and not using local variables also minimizes timing issues. My guess (again I could be wrong) is that Xojo performs these operations in the background. I can control what I program, but unfortunately I am not able to change what happens in the Xojo program/background. This is where the issues seem to be coming from.

When I program in assembly, then I am not getting timing issues. I would prefer to use Xojo, and am curious to know if this is an option.

Thanks a bunch :slight_smile:

4

What kinds of objects are you using? Is it your own class or classes, or native ones?

5

Xojo does not have “Garbage” collector. Its just simple reference counting. So when your objects reference count hits zero delete is called.

Since this is not “Garbage collector” then you never have time consuming process going on that is taking time.

Things working for you when global is simply because global variables never go out of scope so their reference count can never be zero.

6

These are my own classes that are created in Xojo.

7

[quote=480480:@Björn Eiríksson]Xojo does not have “Garbage” collector. Its just simple reference counting. So when your objects reference count hits zero delete is called.

Since this is not “Garbage collector” then you never have time consuming process going on that is taking time.

Things working for you when global is simply because global variables never go out of scope so their reference count can never be zero.[/quote]

Thanks Bjorn. Knowing that there is not a garbage collector then greatly helps. There are delays in sending and receiving electronic signals back and forth. I will need to try a few work-arounds to see if there is something that will minimize timing delays in this language.

Much appreciated

8

Such Electronic classes you should see as sort of “Async” classes so you need to ensure some object carries the ownership of tthe last reference until you are sure you no longer need them.

9

This reminds me of this Thread: How to get rid of a Dictionary as fast and efficient as possible?.

In the similar situation of the other Thread, a workaround is bypassing Xojo’s Reference Counting and implementing an own “garbage collection”. So let Xojo’s Reference Counting destroy the no longer needed object at some time later (and/or in a background thread) when it fits the application’s workflow best.

10

I knew this sounded familiar. :slight_smile:

Another idea: Make your classes a subclass of a new GarbageCollector class. Its Constructor will add itself to a shared Dictionary. Periodically, or when you say, that Dictionary will be cleaned up by:

  1. Pulling the values into an array.
  2. Clearing the Dictionary.
  3. Pop each value, convert it to a WeakRef, then nil the variable that holds that object.
  4. If the WeakRef.Value is nil, it’s gone. Otherwise, add it back to the Dictionary for next time.

(Untested concept.)

11

I will try this concept.

Thanks for the great answers everyone!

12

[quote=480473:@Eugene Dakin]Hello,

I am working on some Raspberry Pi electronics projects and when Xojo does garbage collection (via reference counting) then apps that are doing sensitive timing have a large delay which prevents communication and/or causes logic errors in electronics.

Workarounds are to not create new variables and declare all variables that are used as global. This helps a great deal.

Does anyone know how to stop Xojo with garbage collection and/or reference counting?

Thanks :)[/quote]

There is NO “garbage collection” - at least not in the same way that Java has
When an items reference count goes to 0 it is immediately destroyed
The only way to avoid this is to never have the reference count go to 0 - which means you retain everything always forever

Now you may have something like a module with an array of objects that has a factory methods.
That factory method could just be the API that fronts a pool of existing objects.
And those obejcts are never really released.
Instead when you destroy one they just mark themselves as “freed” and then you can reuse them.
The factory could track these and return any freed object before actually creating a new one.
At least that way you slow the memory growth and you dont suffer any penalty from possibly freeing a top level object that refers to others and so on down a long chain of references that can take time to free

13

I think what you are seeing is the event loop that services the UI, sockets, keyboard, etc. This is very pronounced on Windows and occurs every 13 milliseconds or so, if memory serves.

In my opinion, no, Xojo is not a good choice for this.

14

I am curious what kind of thing youÂ’re doing and what timing issues youÂ’re seeing with this. I know that the older or smaller piÂ’s are not particularly quick in the CPU department but IÂ’ve done lots of with with them and xojo and python and even C. IÂ’ve never had a communications problem with anything from Xojo due to reference counting. But then IÂ’ve also never tried to bit bang high frequency protocols out a GPIO pin or something like that. So perhaps what youÂ’re trying to do is just beyond the easy reach of a userland app? I know that in order to do the really fast refresh code for certain individually addressable RGB ledÂ’s that people have resorted to actually writing kernel code in order to get guaranteed CPU time. If you need something like that then Xojo isnÂ’t going to do it for you, but for anything at a more leisurely level of speed should happen OK reference counting or not. Do you have a lot going on in the destructor methods of classes? Or are you just dealing with so much memory and object usage that getting rid of them really does slow things down that much? If itÂ’s really that bad on the Pi then perhaps there is actually a problem with the memory allocation philosophy on the Pi or on linux in general? That might be worth a bug report or an example project if you can show that returning memory to the system is taking unusually long in some circumstances. In any case IÂ’m very interested in a little bit more info on what youÂ’re doing, some vague numbers of the numbers of classes or the amount of memory youÂ’re using an how long it is really taking to finish the release and come back to you code. There might be something actionable in there for Xojo.

15

Hi James,

I am seeing general issues from high frequency Bit-Banging (reading a pressure sensor with millisecond data), to communication with integrated circuits (the binary hand-shaking shows up with lower and higher duration times on my oscilloscope and prevents successful hand-shakes), to something simple like the timing on a stepper motor (slow motor turn rates and the motor stopping). Again, checking the oscilloscope shows the bits are not evenly spaced.

Running the exact same programs on a competitive IDEs in other languages works well. Xojo programs on the Raspberry Pi work better when global variables are used and the performance is poor. Shrug, I don’t know what else to say?

16

Thanks Tim.

13 milliseconds is a lifetime in some of this work. A logic-logic handshake will have a difficult time working with this large of a delay.

Thanks!

17

WHAT - no social distancing ?

would splitting the reading part into a helper app improve thigns much (despite the work involved) ?

what does this “other IDE” do that seems to make its app perform better ? maybe there’s something to be learned from that ?

18

I’m curious what sort of bit banging is being done. My experience doing this has always involved a clock line and a data line, and variation in timing has never been a problem, as long as the clock and data line transitions occur in the correct order. I can see there would be a problem using a USART type serial interface with a single data line where timing is critical.

19

Thats hilarious :slight_smile: Thanks for the humour, I needed that.

I haven’t tried, and I could give it a try. It does seem like another workaround.

Most of these IDE’s are just glorified text editors that have some simple autocomplete syntax for each of the languages. I am not sure if these IDE’s do something special under-the-hood, as I am not exactly sure what Xojo does under-the-hood. Sure, I know the general things that are done with the IDE, and nothing seems extraordinarily special.

20

[quote=480636:@Eugene Dakin]I haven’t tried, and I could give it a try. It does seem like another workaround.
[/quote]
it is often whats available

[/quote]
Sure - a lot of IDE’s are JUST text editors and not a lot else really
Guess what I’m wondering is what other languages ?
Are we comparing a GUI app to a console app ?
That alone could be a big difference