Date: Thu, 10 Oct 2013 21:43:39 +0000
| -----Original Message-----
| From: lawrence.crowl_at_[hidden] [mailto:lawrence.crowl_at_[hidden]] On Behalf
| Of Lawrence Crowl
| Sent: Thursday, October 10, 2013 4:33 PM
| To: Gabriel Dos Reis
| Cc: Nevin Liber; ub_at_[hidden]
| Subject: Re: [ub] Justification for < not being a total order on pointers?
|
| On 10/10/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > | At this point, I think we need to ask if we really do want to support machines
| > | with small segments. Does anyone know of any current such machines?
| >
| > That is a good question that we should consider.
| >
| > Another aspect to consider is that, even though this restriction
| > was originally motivated by segmented architecture, it is also useful
| > for other things and implementation techniques (including compacting
| > GCs). One question is whether we believe we want to forgo implementations
| > or implementation techniques that might profit from the current
| > restriction.
|
| Wouldn't compacting GCs fall afoul of the existing std::less problem?
A trivial implementation of std::less certainly would.
| I mean, we could still have an std::less that imposed a total order, but
| that order might change during execution, and I could see that causing
| some difficulties with unordered maps. :-)
|
| > I think this question should be considered independently of whether we
| > still want to support segmented architectures, because that may affect
| > the form of the outcome.
| From: lawrence.crowl_at_[hidden] [mailto:lawrence.crowl_at_[hidden]] On Behalf
| Of Lawrence Crowl
| Sent: Thursday, October 10, 2013 4:33 PM
| To: Gabriel Dos Reis
| Cc: Nevin Liber; ub_at_[hidden]
| Subject: Re: [ub] Justification for < not being a total order on pointers?
|
| On 10/10/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > | At this point, I think we need to ask if we really do want to support machines
| > | with small segments. Does anyone know of any current such machines?
| >
| > That is a good question that we should consider.
| >
| > Another aspect to consider is that, even though this restriction
| > was originally motivated by segmented architecture, it is also useful
| > for other things and implementation techniques (including compacting
| > GCs). One question is whether we believe we want to forgo implementations
| > or implementation techniques that might profit from the current
| > restriction.
|
| Wouldn't compacting GCs fall afoul of the existing std::less problem?
A trivial implementation of std::less certainly would.
| I mean, we could still have an std::less that imposed a total order, but
| that order might change during execution, and I could see that causing
| some difficulties with unordered maps. :-)
|
| > I think this question should be considered independently of whether we
| > still want to support segmented architectures, because that may affect
| > the form of the outcome.
Received on 2013-10-10 23:44:10