[¤1] Pegasus Enhancement Proposal (PEP) 341
[¤2]

[¤3] PEP#: 341

[¤4] PEP Type: Concept

[¤5] Title: Single chunk memory CIM Object 

[¤6] Version: 0.2

[¤7] Created: 24th February 2009

[¤8] Authors: Thilo Boehm

[¤9] Status:  draft

[¤10]  

[¤11] Version History:

[¤27]  

[¤28] Abstract: This PEP proposes the replacement of the internal representation of CIM objects with an single chunk memory implementation.
[¤29]

[¤30] Definition of the Problem

[¤31] The CIM Server has been optimized for speed a lot. Strings, reference counting and ordered-set are well known examples. But while these types of enhancements have been exhausted, the server efficiency is still not sufficient for scenarios where the server has to deal with a large number of objects or a larger number of clients.
[¤32] One of the performance gluttons is the object oriented structure of the internal data representation. The keeping of data for CIM objects in a tree of objects causes fragmentation of memory, handling of virtual function tables, handling of destructor's and other overhead introduced by C++ temporary object creation/destruction.
[¤33] To further optimize the CIM Server for performance, the CIM Server has to be structurally remodeled.
[¤34]

[¤35] Proposed Solution

[¤36] To reduce memory fragmentation, this PEP proposes the replacement of the current implementation of CIMObject and related CIM data structures like CIMInstance and CIMClass into a single chunk memory implementation. This implementation is further referenced as SCMO = Singe Chunk Memory Object.
[¤37]

[¤38] The goal of the SCMO implementation is to gain performance by eliminating the large number of allocations and frees that occurs today for each CIM object being created in the server. Also keeping the CIM objects together in a single chunk of memory allow them to be efficiently copied, streamed and shared across address spaces.
[¤39] A mockup implementation shows for an EnumeratInstances request with 100 instances, that there is the potential up to 80% instruction savings for CMPI providers and about 20% instruction savings for standard C++ providers. The main savings stem from not creating interim C++ objects in the providers and at the aggregation of the single instances to the whole response the instance objects are not copied.
[¤40]

[¤42] Requirement for SCMO

1. [¤45] SCMO is changing the internal representation of CIM objects  into in a single memory representation to avoid memory fragmentation.
2. [¤46] An CIM object like an instance must be easily transferable.
3. [¤47] The SCMO implementation must be able to represent dynamic CIM objects. For example, a provider is able to add a property to a CIM Instance even it is not part of the CIM Class.
   [¤48]
4. [¤49] The external interface for clients and providers keeps unchanged.
5. [¤50] The external interface has to be separated form the common code into a separate library, to be able to introduce the SCMO and to keep the external interface consistence.
   [¤51]
• [¤52] The Common library ( Pegasus/Common ) is splitted into a common part, containing the external interface, and an internal part containing the internal functions and the SCMO implementation of CIM objects.The splitting of Common library is discussed in PEP 342.
6. [¤53] There needs glue code to be written to map the external interface/representation of CIM objects into the internal SCMO.
7. [¤54] The internals of the server ( like provider managers, XML writer ) are exploiting the new SCMO structure to gain in performance.
• [¤55] The path length form CMPI provider to the XML writer has to be reduced by 50%
  [¤56]

[¤57] Schedule

[¤58] OpenPegasus 2.10
[¤59]

[¤60] Discussion

[¤62]
[¤63] Licensed to The Open Group (TOG) under one or more contributor license agreements. Refer to the OpenPegasusNOTICE.txt file distributed with this work for additional information regarding copyright ownership. Each contributor licenses this file to you under the OpenPegasus Open Source License; you may not use this file except in compliance with the License.

[¤64] Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

[¤65] The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

[¤66] THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[¤67]  

[¤68] Template last modified: December 18th 2008 by Martin Kirk
[¤69] Template version: 1.12