[
https://issues.apache.org/jira/browse/MESOS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-1991:
----------------------------------------
Sprint: (was: Mesosphere Q4 Sprint 2 - 11/14)
> 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)
