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

2015-04-09 Thread Joris Van Remoortere (JIRA)

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

Joris Van Remoortere updated MESOS-1991:

Target Version/s: 0.23.0
  Labels: c++11  (was: )

> 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
>  Labels: c++11
>
> 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 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 would 
> be expected to be expensive to copy, and so a developer would be more 
> inclined to do something like std::shared_ptr>.



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


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

2015-04-02 Thread Joris Van Remoortere (JIRA)

 [ 
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 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 would 
> be expected to be expensive to copy, and so a developer would be more 
> inclined to do something like std::shared_ptr>.



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


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

2014-11-06 Thread Joris Van Remoortere (JIRA)

 [ 
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 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 would 
> be expected to be expensive to copy, and so a developer would be more 
> inclined to do something like std::shared_ptr>.



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


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

2014-11-03 Thread Benjamin Hindman (JIRA)

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

Benjamin Hindman updated MESOS-1991:

Sprint: Mesosphere Q4 Sprint 2  (was: Mesosphere Q4 Sprint 1 10/31)

> 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 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 would 
> be expected to be expensive to copy, and so a developer would be more 
> inclined to do something like std::shared_ptr>.



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