3.19   Javascript memory leaks   - Web browser choice.


This section discusses the issue of web browser javascript memory leaks.
It arises because piWebCAT is making up to twenty client <> server transactions per second
(Many web browser applications sit there doing nothing until you use the keyboard or mouse)


My primary concern was that piWebCAT should be able to run for 2  hours or more without

slowing enough to need a restart. This is achieved.
(A restart is by clicking the Control button .... and only takes about five seconds)
The situation varies between web browsers. Chrome on PC and on Android are good.


Memory leaks
Computer programs need to dynamically make recurring temporary usage of memory.
The memory reserve is often referred to as the heap.

Some of this heap memory is used for variables which are defined and used locally within a

particular  function. Memory is allocated from the heap for the duration of the function and then

returned to the heap when the function exits. (jargon:   procedure  = function   =  subroutine )


A memory leak is when some of the allocated memory is not returned to the heap and therefore

remains in an unused and inaccessible state.

Repetitive calling of a leaky procedure can result in a in growing unusable section of the heap.


Microprocessors
Small microprocessors often have very limited RAM memory
(eg: the ATxmega192A3  processor in my EncoderCAT project has only 16k bytes.

When programmed in a language such as C,  complete avoidance of an memory leak is essential
and fortunately easy to achieve.


Web browsers - javascipt

Javscript is the programming language that runs on web browser  (ie: web client)

Simply googling 'javascipt memory leaks' reveals that:

- memory leaks are a common problem

- they are somewhat browser dependant.

- they are often not completely suppressed.

 

A javascipt memory leak and other issues can gradually slow down performance and even end up with
the screen image fragmenting.


piWebCAT  and memory leaks

I become aware of potential memory leak issues very late in the development, because:

  • During most of the development, it was unusual to leave piWebCAT running for long periods:
      - the development process is very much a repetitive cycle of modify - run - observe 
      rather than staring at the browser for long periods!
  • Late in  development, I increased the client <> server command rate (up to 20Hz) which potentially
    increases any memory leakage rate.


The memory leakage issue in piWebCAT arises because it is making up to 20 client <> server
transactions per second....  whereas most web browser applications just sit there doing nothing

until you press a key !!


One important cause of memory leakage in javascript is defining global variables within a function.

Javascipt will let you do this.
A global variable is a data storage item that is available throughout the javascipt code.
It is said to have global scope. You can set or read it's value from inside any function in the whole
of the web page javascript code.


A global variable, (eg: freqMain) should not be defined inside a a function.
If it is defined within a function, then a new instance of it will be created every time that function is called.
Some functions in piWebCAT are called 10 or 20 times per second.


Variables that are only for use with in function should be defined within the function as: var variableName,
Memory is then grabbed from the heap when the function is called and released when the function exits..


I discovered late in the development the insertion use of "use strict"; at the start of each program module.
This makes illegal the declaration of globals within a function. The system fails to run. The web browser
debugging facility then locates the offending items.


I carefully removed all such items and also other identifiable known causes of memory leaks.
However, some gradual memory leakage remains.

An internet search for help on this reveals that I am not alone in not completely removing leaks.


Web browser choice:

At the time of writing, acceptable duration of operation depends on web browser choice.

  • Firefox (and Firefox developer) can slow down unacceptably and fail in under two hours.
  • Chrome for Windows and Android are much better choices in this respect.

However, Firefox has the advantage of being able to use the mouse thumbwheel for fine slider adjustment.
This is excellent for an RIT control.   So far, I have not achieved this feature with other browsers.


Javascript's heap memory management is said to use a so called 'garbage collection' system.
This means that discarded heap memory is not restored to available heap on termination of the function
that uses it. The garbage collection system periodically collects unused memory and restores it to the heap.

The system is a web browser facility and appears to have quite different performance on different browsers.


eg: Running piWebCAT over 1.5 hours, Firefox developer increased its stated heap size by 70 Mbytes
whereas Chrome reported less than 1.5 Mbytes.