# Inputmanager module - Memory handling

Copyright © 2004-2008 Opera Software ASA. All rights reserved. This file is part of the Opera web browser. It may not be distributed under any circumstances.

## Used OOM policies

Softcore will usually return OP_STATUS, except for functions calling lots of functions that LEAVE, where the functions in Softcore also will Leave (to avoid lots of TRAPs)

## Who is handling OOM?

Softcore will do its best to stay in a consistent state, and not leak memory already allocated in case of OOM. Caller should always check for OpStatus::ERR_NO_MEMORY

## Description of flow

-

## Heap memory usage

Places where a large object is created often, is the OpInputActionObjects used in OpInputManager::InvokeAction and OpInputManager::InvokeActionInternal (pre-filter).

## Stack memory usage

OpInputActions might be sent from input_context to its parent input_context (and then to its parent input context), but this will always be a finite, fairly small number of layers. There are no really recursive functions.

## Static memory usage

-

## Caching and freeing memory

-

## Freeing memory on exit

-

## Temp buffers

No temp buffers are used by the inputmanager.

## Memory tuning

-

## Tests

-

## Coverage

Run selftests in limited memory profiles.

## Design choices

Some parts of the code does NOT have a design choice based on memory (most notably, OpInputManager and OpInputAction). Quite a few other parts are designed to load and keep data at startup, and save (if needed) and free data at shutdown. Depending on rate of access, data is either kept as compact as possible, or as quickly accessible as possible.

## Suggestions of improvements

OpInputManager/OpInputAction should be made memory safe.