Type of data
- Strings returned by get_string() and other methods.
- Average length 54 characters, UTF-8 encoded.
There are two main caches used by the core_string_manager - the on-diskcache and in-memory cache.
The on-disk cache is used to cache the result of language packs merging. Merging is an operation where official translations are combined with eventual local customizations. Missing strings are filled using the parent language or the English (which is the implicit parent for all languages). At the end of the merge, there is some value defined for each existing string in the given language.
The in-memory cache is used to cache the strings once they are read from the on-disk cache. If we need a string from the given component, eg. via get_string('foo', 'mod_bar') call, we load all the mod_bar component from the on-disk cache into the in-memory cache and pick the string from it. If another string from the same component is needed, the in-memory cache is hit.
The in-memory cache is currently implemented as a three-dimensional associative array $cache[$langcode][$component][$stringid].
When it gets stored
Both caches are populated on-the-fly when the given string component is accessed for the first time.
If some string from the component mod_bar is requested and the component mod_bar is not loaded into the memory yet, the core_string_manager reads the whole component from the on-disk cache.
If the component mod_bar is not found in the on-disk cache yet, all the possible sources of the strings from this component are merged together and stored.
Where it gets stored
The core_string_manager (which is a singleton) stores the in-memory cache in its protected $this->cache property.
The on-disk cache is stored in files in $CFG->langcacheroot which is $CFG->cachedir.'/lang' by default (where $CFG->cachedir itself defaults to $CFG->dataroot.'/cache').
How it gets read
In core_string_manager::load_component_strings() that is used by get_string() and friends.
Does it need locking?
Yes it does. Especially when the on-disk cache is recreated, two concurrent requests may check for the file existence and either try to use the incomplete data or start overwriting the file again. Petr did recently some tweaks to minimize this race conditions (see d7b44d5e959a66cd3da2e212d0ac1bdcf139d075), some solid solution would be nice for sure.
How it gets cleared?
The in-memory cache is a request cache and is cleared automatically at the end of the request.
The on-disk cache is cleared as a part of the purge_all_caches() call. So it can be cleared manually via the Purge all caches feature, is automatically cleared on core upgrades etc.
The in-memory cache has typically 600KB - 1MB for students and something about 2MB for admins.
Safeguards in place
None currently implemented.