[
https://issues.apache.org/jira/browse/MESOS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380862#comment-14380862
]
Benjamin Mahler commented on MESOS-1991:
----------------------------------------
[~jvanremoortere] As per the discussion in
[MESOS-1008|https://issues.apache.org/jira/browse/MESOS-1008?focusedCommentId=13902219&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13902219],
can we just use C\+\+11's unrestricted union that landed in gcc 4.6 to address
this? Was the lack of C\+\+11 support what motivated using the memory aligned
storage?
Are you planning to address this for our other core abstractions (Try, Result,
Future) as well?
> 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)
