YAGSL beating up memory?

Been tracking down problems we have been having with running out of memory. The problem appeared after we merged our swerve code into (using YAGSL).

Just before the merge, the java process would grow to about 250M VSZ (using top to observe), and stay there; no problems.

After the merge, it grows to 250M, then the GC kicks off, it drops to 180M or so, and goes right back up to 250M, and occasionally throws the OOM error.

It seems that our code (or YAGSL) is allocating and abandoning objects very quickly, working the GC very hard, and occasionally getting to the point where the GC can’t keep up (can that happen?)

Is any one else having problems with YAHSL using code getting sporadic out of memory errors?

I have profiled the memory usage of YAGSL, the most significant part of it is JSON reading. Are you using any opencv features? Do you have the roboRIO web server enabled?

(When you use the team number setter in VSCode it should be possible to disable it now)

However if you wanted to reduce the memory footprint as much as possible turn off telemetry. Telemetry takes about 19MB in my profiled runs on the newest versions.

It’s not by default disabled. The user still has to hit the button to disable it if they want it disabled.

1 Like

The Alert class is very memory hungry. I may remove that in the future since this was only included to be a nice sendable for AdvantageScope and Elastic. If you want to to remove it yourself to test it out, please do!

Set to NONE, still spooling up to 279Mb using the G1 GC.

How are you profiling? (I’m not questioning your results, I want to know how it’s done; I can’t figure out how to use visualvm any with the new Java 17 JVM).

I cheat and use InteliJ Pro. I have been successful with visualvm too but i havent tried on a RIO this season.

how do you connect to the JVM? I am having no luck getting in with JMX.

@Daltz3 wrote this documentation a while ago that hasn’t been merged yet.

back before this was written it i had relied on this and newknowledge of gradle.

1 Like

This works. I don’t need jstatd anymore. I wasn’t specifying the JRE to use when starting visualvm, that was my problem.

My heap is only 16Mb, I have a VSZ of 291M. Need to go on a code diet.

1 Like

I just analyzed it and merged an update with TheGamer to address this. It should use about 1MB/s memory allocations (mainly not through YAGSL and now vendors).


this was a 30second run.

1 Like

1 MB/s??? That seems INSANE.

1 Like

It does! I am not quite sure why it’s like that yet but will look into it later.

InteliJ is pointing to REVLibError, specifically this function which clones all of the enums every time it is called.


Found out why. It’s bc in simulation i set the position of the encoder every time the func is called.

It happens in sim only to keep the encoder up to date. Still not a good problem to have if someone accidentally made this so it happens on a real robot. Like advantagekit swerve example…

      if (SwerveDriveTelemetry.isSimulation)
      {
        encoder.setPosition(setpoint);
      }