BIND 10 #2088: introduce MemorySegment class

[BIND 10 Development]

#2088: introduce MemorySegment class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120717
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by muks):

 Hi Jinmei

 Replying to [comment:9 jinmei]:
 > Some quick comments:
 >
 > - I myself am not really sure, but I guess we'd probably like allocate
 >   to throw when it fails to allocate the memory.

 "Fails to allocate memory" depends on the implementation, so whether it
 would throw or not would depend on the implementation.

 For the `malloc()` implementation, `malloc()` could return NULL. There are
 arguments both for and against NULL-testing this pointer, and I side with
 not NULL testing it unless we think it's reasonable for it to fail (such
 as for very large buffers). For small sizes if it returns NULL, in typical
 programs it is a fatal situation. Throwing here isn't likely to help and
 could have issues of its own. If large sizes are requested, then it's
 better left to the caller to handle a NULL return. For a well-written
 program running on a system reasonably configured for it, there should not
 be an unexpected out-of-memory issue in `malloc()`. If there is, it would
 be due to some programming (leak) or system configuration error.

 There is one more issue. In some demand paging kernels (Linux included),
 allocations are over committed in the default configuration (unless it's a
 very very large buffer requested or some other conditions exist). For
 typical `malloc()`s, it will never return NULL. libc requests more memory
 and the kernel always allows the `brk()` to pass and creates table
 entries. Only when there's a page fault does the kernel try to find a
 frame for it and OOMs processes if necessary then. So NULL checking of
 `malloc()` output won't be useful.

 NULL checking could be useful in other MemorySegment implementations.

 > - what if ptr is NULL in deallocate?  What if size is too large?

 Deallocating NULL would be a fatal programming mistake, not something that
 catching can fix. It's better for the process to segfault and dump its
 core then.

 If size is too large, we can probably add a trivial check against the
 allocated count. It will only catch larger than allocated count problems.
 It could be caught in the system's implementation if the implementation
 takes the size of memory to deallocate. Even in the case of `free()`, at
 the end we'd have a non-zero allocated count pointing to a bug. But we can
 add this check as it'd catch one type of problem.

 > - unittest: test body can be in an unnamed namespace, and we normally
 >   do so.

 Fixed. :)

 > - there are some style issues, mainly about the position of *, e.g.
 > {{{#!cpp
 > +    void *ptr = malloc(size);
 > }}}

 Fixed. :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/2088#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development