RAM Cleaners in Android

Using RAM management apps in Android which clear the RAM of all applications is, in fact, detrimental to the system and may degrade the performance and battery life instead of conserving battery power.

Conventional belief-
If an app is stored in the RAM, it consumes battery power.
The truth is- When an app is stored in RAM, the bits in the RAM are held as 1s or 0s accordingly, and the memory is cleared whenever the app is removed. Holding a bit as 0 or 1 takes the same power. There is no effect on the power usage if a bit is held as 1 instead of 0, as this involves only data storage and the kind of bit being stored in that memory location does not matter.

It is the CPU usage that affects the battery life, and not the RAM usage. If an app is present in memory and is consuming a lot of battery power, it indicates a high usage of the processor by the app, possibly as a result of weak code management by the developer of the app. Killing or uninstalling such an app may help to increase battery life, but the cause for this is not RAM usage, rather it is the excessive usage of the CPU.

Continue reading

Advertisements

Caches and Scratchpad Memory in RTOS

Cache Replacement Policies

Predictability calculated by RELACS tool

Policy

Assoc.

2

3

4

5

6

7

8

LRU

1

1

1

1

1

1

1

FIFO

1/2

1/3

1/4

1/5

1/6

1/7

1/8

PLRU

1

0

0

RANDOM

0

0

0

0

0

0

0

LRU (Least Recently Used)

Minimal life span (mls) – minimal no. of pairwise different memory blocks needed to evict a just-visited mem block out of cache. Replacement policy with larger mls preferred.

Upper bound of mls = L. mls of LRU = L = no. of cache lines.

Non-LRU policies are considered to be much less predictable than LRU, and it would be very difficult to develop precise and efficient analyses for them. It is recommended to only use LRU caches when timing predictability is a major concern in the system design.

Continue reading

Garbage Collection in RTOSes

The requirements for a garbage collection to be real-time are-

  • Ensure that programs with bounded allocation rates do not run out of memory

  • Provide short blocking times – Specify and maintain a maximum pause time which is short, predictable, eg. 50 ms threshold. There can be many short, frequent GC pauses. Duration of each is kept to a minimum, improving performance.

Issues with incremental GC: The two sources of blocking are root scanning and heap compaction.

The Metronome Collector

The Metronome garbage collector, which is a commonly used RT-GC, limits interruptions to one millisecond and spaces them evenly throughout the application’s execution.

Continue reading