You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Joris Van Remoortere (JIRA)" <ji...@apache.org> on 2015/04/02 22:10:57 UTC

[jira] [Updated] (MESOS-1991) Remove dynamic allocation from Option

     [ https://issues.apache.org/jira/browse/MESOS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joris Van Remoortere updated MESOS-1991:
----------------------------------------
    Shepherd: Benjamin Mahler  (was: Benjamin Hindman)

> Remove dynamic allocation from Option
> -------------------------------------
>
>                 Key: MESOS-1991
>                 URL: https://issues.apache.org/jira/browse/MESOS-1991
>             Project: Mesos
>          Issue Type: Improvement
>          Components: stout
>            Reporter: Joris Van Remoortere
>            Assignee: Joris Van Remoortere
>            Priority: Minor
>
> Remove dynamic allocations from Option class.
> The motivation for this is 3-fold:
> 1. Reduce dynamic allocations. These can cause latency jitter as process lifetime grows. This kind of jitter can make it hard to grasp the upper bound of latency on certain operations under locks. This modification only moves the allocated space of T, it does not reduce or increase the number of actual construction / move calls unless the new move constructor is used.
> 2. The commonly understood implication of Optional / Option / Nullable is that it augments the type field by 1 bit in order to allow representation of an unknown or null state. This is handy in cases where a type such as int64_t fully utilizes its 64 bit storage space, and representing unknown would otherwise require us to steal a number (such as INT64_MAX). This class should not take on the additional responsibility of managing memory for the augmented type.
> 3. It can be very deceptive to a newcomer when Option<int64_t> does a dynamic allocation. Intuitively you would not expect a type such as int64_t to do a dynamic allocation or be expensive to copy. Naturally Option<BigType> would be expected to be expensive to copy, and so a developer would be more inclined to do something like std::shared_ptr<Option<BigType>>.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)