Site Tools


Table of Contents

The Wiki page memory management design describes a major long term issue with memory management in IoTivity. The Wiki page memory management design II describes the strategies for improving IoTivity's memory management and tactics for implementing those changes.

This article describes a fork of IoTivity that incorporates most of the changes suggested in the second article.


My group is tasked with discovering how small and useful an OIC server can be in the face of highly constrained resources. Memory is not the only constrained resource we are considering, but it is probably the most important. Two types of memory are important: code size and RAM usage.

The fork is currently not public because of the nature of our exploration. While we have made major modifications to the IoTivity code, we have moved fast, so the results are not always pretty. We are not currently willing to share the code, but that can be a subject of discussion.

The fork runs an OIC server and interoperates with IoTivity. All primary server functionality is complete, though not all of it is tested.

Here are several characteristics of the fork unrelated to memory management. (For comparison purposes the current size of the IoTivity RI layer is about 52K bytes.)

  • The complete RI layer in RELEASE mode is about 38K bytes.
  • A build option allows the fork to be built without client capability. Without client capability, the complete RI layer is about 26K bytes.
  • A configuration option allows the server to be built without a variety of capabilites, saving code memory:
    • no presence: save 1400 bytes
    • no collections: save 2500 bytes
    • no resource construction API: save 7000 bytes
  • A working client RI layer without all three of these capabilities can be as small as 18K bytes.
  • Almost all copying of data structures is eliminated, saving much CPU time, also a constrained resource.

I mention these non-memory issues because they are also applicable to many places IoTivity will be targeted, and we want to show what is possible in those cases.

memory management

The fork provide the following improvements for memory management:

  • Mallocs in RI layer: 7 (down from 187 in IoTivity)
    • resource description (resource construction only)
    • request/response received from network
    • decoded payload after receive
    • observer description (observer only)
    • collection element responses (collections only)
    • slow response parameters (slow response only)
    • encoded payload for sending
  • Each of these structure is fully characterized and tunable.

The code size and number of mallocs are both dramatically reduced in the forked version of the Connnectivity Abstraction (CA) layer. The mallocs are more difficult to reduce in CA because libcoap performs internal mallocs and forces calling code to do more mallocs. This work is ongoing.

Things not done yet in the fork include memory pools and a dedicated error path.


While the fork is intended as an OIC server in a highly constrained environment, I believe much of what was learned by the exercise can be applied to IoTivity. With some additional work, it could be an alternate branch for building OIC servers in general. Or the code could be mined for individual improvements to the IoTivity code base.

At the very least, the fork provides an existence proof that a more robust OIC server can be built and provides hints about how that might be done.

John Light
Intel OTC OIC development

memory_management_design_iii.txt · Last modified: 2015/11/20 20:28 by rightbrain