JS Garbage Collection

Posted on
  • I'm rewriting a clock appliction with intgrated touch launcher to a buffer-based app. I'm using a 1 bpp array buffer and the app is meanwhile getting big. When I start the app I'm using 53% of the memory (including buffer). When I retrieve the app list from the storage I'm running into memory problems. My idea was to free the buffer for the launcher part by assigning an empty array and afterwards to reallocate the buffer for clock operation. However I'm running into memory issues since it seems that the garbage collector of JS is slower than a user can interact with the watch, e.g by pressing the assigned exit list button, which then clears the list and quickly reallocates the buffer.
    Is there any way to get rid of this memory problem?

  • The actual garbage collect should be pretty quick (2ms or so) so I'm not 100% sure that's the issue.

    It is possible that if you're removing the buffer then trying to reallocate it's unable to find a contiguous block of memory any more and has to defragment though.

    Are you using the same code to load the apps as here: https://github.com/espruino/BangleApps/b­lob/master/apps/launch/app.js#L2

    That's a lot more efficient with memory than blindly loading all apps into memory as it only keeps the data that's needed for the launcher. The JSON contains a lot of stuff (eg lists of files) that's not needed and would just eat up RAM.

  • Thank you Gordon, yep I did it this way. The strange thing is that the maximum memory usage is 73% when it is out of memory. I implemented a workaround: The clock launches an external launch.js and in the end it launches the clock if nothing else is launched. Works "ok" since it flickers, but it works.

  • the maximum memory usage is 73% when it is out of memory.

    If you're checking via the widget, the widget only updates every minute or so if I recall so you may not be getting an accurate figure?

    It's also possible that at some point a function does something that uses a lot of memory for a short while?

  • I have traced the memory status via console.log. I can't see a huge memory allocation in the code. All memory consuming variables are local with a strict scope and all timer-related ones global, so that there can't be duplicates caused by timers. I meanwhile think that launching the external js is the best solution since it leaves some more memory for new functions :-)

    By the way: I got for the first time today a "storage is corrupt" while uploading the app. The firmware handles this in a good way and leaves the device functional although everything must be reinstalled.


    1 Attachment

    • 2020-06-01_19-04.png
  • for the first time today a "storage is corrupt" while uploading the app

    Wow, that's interesting. I wonder what happened - the main reason for the check is when first running Espruino on Bangle.js, or when the change went in to increase filename length. It's not supposed to happen normally.

    If you find a way to reliably reproduce this, please can you let me know?

  • Whoops it did it again ... It happens when I detach timers and the LCD sleeps.
    Last code is:

    Bangle.on('lcdPower',on=>{
     console.log("LCD Event"); 
     if (on) {
        console.log("LCD Event ON");
        //state.screen=scrnClock;
        b.clear();
        if (state.screen==scrnClock) {
          writeTime();
          writeCircles();
          state.clockDots=false;
          writeClockDots();
          handleSecondClock=setInterval(clockUpdat­e, 1000);
        }
        if (state.screen==scrnDate) {
          writeDate();
        }
        g.drawImage({width:240,height:190,bpp:1,­buffer:b.buffer, palette: color},0,48);
      }else {
        if (handleSecondClock){
          console.log("LCD Event: Clearhandle");
          clearInterval(handleSecondClock);
          handleSecondClock = undefined;
      }
     }
    });
    

    1 Attachment

    • 2020-06-02_11-28.png
  • Hmm - that's odd though since none of that code would appear to write to Storage.

    Could be coincidence about the LCD Event stuff, or can you reproduce it every time?

  • No, it's random while the watch sleeps. The watch behaves strange since the last firmware update. I'm recovering from the latest erase and it takes five minutes to get the code on the bangle. I'll try to go to the latest stable firmware version.

  • Stable fixed the BLE problem. Hopefully also the erase problem. The watch felt slow even after the unwanted erase without any code.
    At the moment I also got with this the old font back, which looks definitly more elegant than the new one. Is there any possibility to load the old font on a Bangle with a newer firmware?

  • Is there any possibility to load the old font on a Bangle with a newer firmware?

    The vector font? I'm afraid not - it's one of the things that is built in.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

JS Garbage Collection

Posted by Avatar for Tx @Tx

Actions