Name Description Size
components.conf 473
moz.build 765
nsIStartupCacheInfo.idl NOTE: this interface is completely undesigned, not stable and likely to change 1354
StartupCache.cpp 31239
StartupCache.h The StartupCache is a persistent cache of simple key-value pairs, where the keys are null-terminated c-strings and the values are arbitrary data, passed as a (char*, size) tuple. Clients should use the GetSingleton() static method to access the cache. It will be available from the end of XPCOM init (NS_InitXPCOM3 in XPCOMInit.cpp), until XPCOM shutdown begins. The GetSingleton() method will return null if the cache is unavailable. The cache is only provided for libxul builds -- it will fail to link in non-libxul builds. The XPCOM interface is provided only to allow compiled-code tests; clients should avoid using it. The API provided is very simple: GetBuffer() returns a buffer that was previously stored in the cache (if any), and PutBuffer() inserts a buffer into the cache. GetBuffer returns a new buffer, and the caller must take ownership of it. PutBuffer will assert if the client attempts to insert a buffer with the same name as an existing entry. The cache makes a copy of the passed-in buffer, so client retains ownership. InvalidateCache() may be called if a client suspects data corruption or wishes to invalidate for any other reason. This will remove all existing cache data. Additionally, the static method IgnoreDiskCache() can be called if it is believed that the on-disk cache file is itself corrupt. This call implicitly calls InvalidateCache (if the singleton has been initialized) to ensure any data already read from disk is discarded. The cache will not load data from the disk file until a successful write occurs. Finally, getDebugObjectOutputStream() allows debug code to wrap an objectstream with a debug objectstream, to check for multiply-referenced objects. These will generally fail to deserialize correctly, unless they are stateless singletons or the client maintains their own object data map for deserialization. Writes before the final-ui-startup notification are placed in an intermediate cache in memory, then written out to disk at a later time, to get writes off the startup path. In any case, clients should not rely on being able to GetBuffer() data that is written to the cache, since it may not have been written to disk or another client may have invalidated the cache. In other words, it should be used as a cache only, and not a reliable persistent store. Some utility functions are provided in StartupCacheUtils. These functions wrap the buffers into object streams, which may be useful for serializing objects. Note the above caution about multiply-referenced objects, though -- the streams are just as 'dumb' as the underlying buffers about multiply-referenced objects. They just provide some convenience in writing out data. 11258
StartupCacheInfo.cpp 1493
StartupCacheInfo.h 692
StartupCacheUtils.cpp At this point, if both underGre and underApp are true, it can be one of the two following cases: - the GRE directory points to a subdirectory of the APP directory, meaning spec points under GRE. - the APP directory points to a subdirectory of the GRE directory, meaning spec points under APP. Checking the GRE and APP path length is enough to know in which case we are. 6941
StartupCacheUtils.h 3318
test