If I have a special hardware unit with some storage in it is connected to the computer and is memory mapped, so that
its storage is accessible in the address range 0x55500000 – 0x555fffff how an I interface this hardware unit to
my C++ program so that dynamic memory is allocated in this hardware unit, not in my computer’s memory?
I need to implement a class which has the following function in it.
void * allocMemoryInMyHardware(int numberOfBytesToAllocate);
which returns a pointer to the allocated memory chunk, or null if unable to allocate.
You need to write your own allocator. Search internet for a sample code and tweak it. If you have simple requirements, basic allocator can be written from scratch in 2-4 hours. This approach will work if your platform does not have virtual memory management and code can access your range of addresses directly. Otherwise you need to dive into the driver development on your platform.
Typical strategy is to add header to each allocated unit and organize a double linked list for free memory areas. NT heaps work in similar way.
I think you can use the placement new syntax for this purpose. Using this, you can tell where objects shall be constructed:
char memory[10];
int* i = new (memory) int(42);
Related
If a class needs to allocate memory dynamically (e.g. std::vector), is it acceptable for the class to simply allocate and deallocate the memory internally, using operator new or malloc?
The answer isn't entirely obvious to me. The lack of a system managing the memory allocation like in garbage collected languages is obviously empowering; but on the other hand, it is precisely this lack of coordination that ends up wasting memory. For instance, it would be quite trivial to make a 'fake' allocator that just passes stack memory to an object which would, under normal circumstances, require dynamic memory, but which the programmer can assert will never need more than X amount of bytes.
Perhaps you think that this issue is irrelevant in the days of large address spaces, but it feels a bit lame to fall back on the hardware, this is C++ after all.
EDIT
I realize now how cryptic I was with the question... Let me explain it a bit better.
When I say 'wasting memory', I specifically mean the kind of memory-wasting that happens with heap fragmentation. Reducing heap fragmentation is the most compelling point of making a memory managing system in C++, since (as many comments have pointed out) destructors already handle the resource management side of things. When your allocations are essentially random (you don't know where your new memory is in relation to other allocated memory) and every class could potentially allocate, you run into the sort of problem that data oriented design tries to fix: poor data locality.
So the question is: would it make sense for there to be a class that does the memory management, object management, heap compaction, and maybe statistics tracking (for debugging purposes) to make the most efficient use of memory and data locality?
[In this view, every class or function that allocates memory dynamically has to get a reference to that class, somehow.]
Or is it better to let every class be able to allocate without necessarily making it part of the interface of that class?
If a class needs to allocate memory dynamically (e.g. std::vector), is it acceptable for the class to simply allocate and deallocate the memory internally, using operator new or malloc?
Usually, we have two kinds of classes:
managers of resources (including dynamic memory);
"business logic" classes.
Most of the times we shouldn't mix the layers of resource management and domain logic.
So, if your class is a manager of a raw resource, it allocates/deallocates, initializes/deinitializes its only resource and does nothing else. In this case, new is OK and even necessary (e.g. you can't instead use std::vector when writing your own dynamic array, otherwise you don't need to write it at all). See RAII.
If your class contains some app logic, it is not permitted to explicitly allocate dynamic memory, open sockets etc., but it uses other RAII-classes for that. At this high level C++ provides you with something that GC languages don't: it makes RAII-owners manage files, sockets etc. - any kind of resource, not just raw bytes of heap memory, so you don't need manual Java/C#-style try-with-resources everywhere you create a not-of-raw-memory manager object - the compiler does it for you as soon as you have a RAII class for that.
Hell'o
I want to create my own dynamic array (vector) class, but don't know how to allocate memory on addres whom I point to. In function add I added line like:
int * object = new (this->beginning + this->lenght) int (paramValue); But visual studio shows me an error message "operator new cannot be called with the given arguments". How to make it works, which arguments should I send to the new operator?
(I am not sure to understand your question, but....)
You might want to use the placement new operator (but to implement a <vector> like thing you don't need that). Then you'll need to #include <new>
But you probably don't need that. Just call plain new from your constructor, and plain delete from your destructor. Something like int*arr = new int[length]; (in constructor) and later delete[] arr; (in destructor).
(it looks that you are misunderstanding something; I recommend spending several days reading a good C++ programming book)
how to allocate memory on address whom I point to
Insufficient information -- what kind of system? custom hardware? OS?
On a desktop, you could use 2 steps. You allocate a block of bytes using something like:
uint8_t* myMemoryBlock = new uint8_t[1000]; // 1000 byte block
Then you might contemplate using placement new at the address "you point to" using 'myMemoryBlock', with a cast.
On a desktop, the dynamic memory system can be used this way...
But if you are planning to create a user defined type any way, just new that type, and let the dynamic memory fall where it may, as opposed to positioning it on myMemoryBlock.
On a desktop, there is (generally) no memory your user-privilege level executable can access with 'new'. All other memory is protected.
mmap on Linux maps devices or files into your executables memory range. I am unfamiliar with such devices, but I have used mmap with files.
update 2017/03/19
Note 1 - user-privilege level tasks are typically blocked from accessing other / special memory.
Note 2 - memory addresses, such as 'myMemoryBlock' above, are virtual, not physical. This includes code addresses, automatic memory addresses, dynamic memory addresses. If your processor has memory management hardware support, your coding has special efforts to access physical addresses, in memory or otherwise.
On a single-board-computer (SBC), (with or without an OS) I would expect that the address you wish to 'allocate' will not be within the 'dynamic' memory set up by the board support package (BSP).
On this kind of embedded system (on a SBC), someone (an architect) has 'mapped' this 'special' memory to an address range not in use for other purposes (i.e. not part of dynamic memory). Here, you simply find out what the address is, and use it by casting the uintXX_t value to a pointer of appropriate type. Something like:
myDataType* p = reinterpret_cast<myDataType*>(premappedAddress);
For more info, you should seek out other sites discussing embedded systems.
Can someone give a clear explanation of how the new and delete keywords would behave if called from __device__ or __global__ code in CUDA 4.2?
Where does the memory get allocated, if its on the device is it local or global?
It terms of context of the problem I am trying to create neural networks on the GPU, I want a linked representation (Like a linked list, but each neuron stores a linked list of connections that hold weights, and pointers to the other neurons), I know I could allocate using cudaMalloc before the kernel launch but I want the kernel to control how and when the networks are created.
Thanks!
C++ new and delete operate on device heap memory. The device allows for a portion of the global (i.e. on-board) memory to be allocated in this fashion. new and delete work in a similar fashion to device malloc and free.
You can adjust the amount of device global memory available for the heap using a runtime API call.
You may also be interested in the C++ new/delete sample code.
CC 2.0 or greater is required for these capabilities.
How do memory leak detectors actually work? What are the underlying concepts in general? Can take C++ as the language to explain this.
There are a couple of different ways that leak detectors work. You can replace the implementation of malloc and free with ones that can track more information during allocation and are not concerned with performance. This is similar to how dmalloc works. In general, any address that is malloc'ed but not free'd is leaked.
The basic implementation is actually pretty simple. You just maintain a lookup table of every allocation and its line number, and remove the entry when it is freed. Then when the program is done you can list all leaked memory. The hard part is determining when and where the allocation should have been freed. This is even harder when there are multiple pointers to the same address.
In practice, you'll probably want more than just the single line number, but rather a stack trace for the lost allocations.
Another approach is how valgrind works which implements an entire virtual machine to keep track of addresses and memory references and associated bookkeeping. The valgrind approach is much more expensive, but also much more effective as it can also tell you about other types of memory errors like out of bounds reads or writes.
Valgrind essentially instruments the underlying instructions and can track when a given memory address has no more references. It can do this by tracking assignments of addresses, and so it can tell you not just that a piece of memory was lost, but exactly when it became lost.
C++ makes things a little harder for both types of leak detectors because it adds the new and delete operators. Technically new can be a completely different source of memory than malloc. However, in practice many real C++ implementations just use malloc to implement new or have an option to use malloc instead of the alternate approach.
Also higher level languages like C++ tend to have alternative higher level ways of allocating memory like std::vector or std::list. A basic leak detector would report the potentially many allocations made by the higher level modes separately. That's much less useful than saying the entire container was lost.
Here's a published technical paper on how our CheckPointer tool works.
Fundamentally it tracks the lifetimes of all values (heap and stack), and their sizes according their types as defined by the language. This allows CheckPointer to find not only leaks, but out-of-array bound accesses, even for arrays in the stack, which valgrind won't do.
In particular, it analyzes the source code to find all pointer uses.
(This is quite the task just by itself).
It keeps track of pointer meta data for each pointer, consisting of
A reference to the object meta data for the heap-allocated object or global or local variable orfunction pointed to by the pointer and
The address range of the (sub)object of the object that the pointer may currently access. This may be smaller than the address range of the
whole object; e.g. if you take the address of a struct member, the instrumented source code will only allow access to that member when using the resulting pointer.
It also tracks the kind and location of each object, i.e. whether
it is a function, a global, thread-local or local variable, heap-allocated memory, or a string literal constant:
The address range of the object that may be safely accessed, and
For each pointer stored in the heap-allocated object or variable, a reference to the pointer metadata for that pointer.
All this tracking is accomplished by transforming the original program source, into a program which does what the original program does, and interleaves various meta-data checking or updating routines. The resulting program is compiled and run. Where a meta-data check fails at runtime, a backtrace is provided with a report of the type of failure (invalid pointer, pointer outside valid bounds, ...)
This is tagged C and C++ and no operating system is mentioned. This answer is for Windows.
C
Windows has the concept of virtual memory. Any memory a process can get is virtual memory. This is done through VirtualAlloc() [MSDN]. You can imagine the leak detector to put a breakpoint on that function and whenever it is called, it gets the callstack and saves it somewhere. Then it can do similar for VirtualFree()[MSDN].
The difference can then be identified and shown along with the callstacks that have been saved.
C++
C++ has a different concept: it takes the large 64kb blocks which it gets from VirtualAlloc() and splits it into smaller pieces, called the Heap. The C++ heap manager comes from Microsoft and offers new methods HeapAlloc() [MSDN] and HeapFree()[MSDN].
Then, you could do the same as before, but actually, that feature is already built-in. Microsoft's GFlags [MSDN] tool can enable the tracking:
In this case it will save up to 50 MB of callstack information for C++ heap manager calls.
Since that settings can also be enabled via the Windows Registry, a memory leak detector can make use of it easily.
General concept
As you can see, the general concept is to keep track of allocations and deallocations, compare them and show the callstacks of the difference.
I need some clarification about c++ memory management and MISRA guidelines..
I have to implement one program that it's MISRA compatible so I have to respect a important rule: is not possible to use 'new' operator (dynamic memory heap).
In this case, for any custom object, I must use static allocation:
For example:
I have my class Student with a constructor Student(int age).
Whenever I have to instantiate a Student object I must do it this way:
int theAge = 18;
Student exampleOfStudent(theAge);
This creates an Student object exampleOfStudent.
In this way I do not to have to worry about I do not use destructors.
Is this correct all this?
Are there other ways to use static memory management?
Can I use in the same way std::vector or other data structure?
Can I add, for example, a Student instance (that I created as Student exampleOfStudent(theAge)) into a std::vector.
Student exampleOfStudent(theAge); is an automatic variable, not static.
As far as I remember, MISRA rules disallow all forms of dynamic memory. This includes both malloc and new and std::vector (with the default allocator).
You are left with only automatic variables and static variables.
If your system has a limited amount of RAM you don't want to use dynamic memory because of the risk you will ask for more memory than is available. Heap fragmentation is also an issue. This prevents you from writing provably correct code. If you use variables with automatic or static storage a static analysis application can, for instance, output the maximum amount of memory your application will use. This number you can check against your system RAM.
The idea behind the rule is not that malloc and new, specifically, are unsafe, but that memory allocation is (usually) a lazy workaround for not understanding, or managing, the memory requirements of your program.
pre-allocating your calculated maximum input, and trapping overruns
providing a packet, stream, or other line-oriented means of managing input
use of an alternative pre-allocated data structure to manage non-uniform elements
Particularly in the context of a small, non-MMU, embedded system that lack of design depth frequently leads to an unstable system, that crashes outright in those odd, "corner case" exceptions. Small memory, short stack, is a system killer.
A few, of many, strategies that avoid the assumption that you do not have infinite memory, or even much memory in that inexpensive, embedded system - and force you to deal with the faults that might be important in your application.
Don't write your own malloc.
For MISRA compliance, placement-new is not a problem, as there is no dynamic allocation happening.
A library could be written (like an STL allocator) in such a way as to reference a statically allocated memory region as it's memory pool for such a purpose.
Advantages: deterministic, fast.
Disadvantages: memory inefficient.
A favorable trade off for deterministic real-time systems.
All needed RAM has to be there at program startup, or the program won't run.
If the program starts, it's unaffected by available heap size, fragmentation etc..
Writing ones own allocator can be complex and out-of-memory conditions (static memory pool size is fixed after all) still have to be dealt with.
I once wrote a library that had to comply to the MISRA rules. I needed dynamic memory as well, so I came up with a trick:
My lib was written in C, but my trick may work for you.
Part of the header-file looked like this:
/* declare two function pointers compatible to malloc and free: */
typedef void * (*allocatorFunc)(size_t size);
typedef void (*freeFunc) (void * data);
/* and let the library user pass them during lib-init: */
int library_init (allocatorFunc allocator, freeFunc deallocator);
Inside the library I never called malloc/free directly. I always used the supplied function-pointers. So I delegated the problem how to the dynamic memory allocation should look like to someone else.
The customer actually liked this solution. He was aware of the fact that my library would not work without dynamic memory allocation and it gave him freedom to implement his own memory scheme using preallocated pools or whatnot.
In C++ you can do the same, just use the malloc function and do the object creation using placement new.