char buf[50];
char* ptr;
scanf("%s", buf);
ptr = (char*)malloc(sizeof(buf)+1);
//And this, how to know that dynamic allocation is correctly done?
i want to know size of memory pointed by ptr
Standard malloc function does not provide this information.
This is no easy way to know the size of an object pointed by a pointer unless you use custom allocators or add some metadata to keep the size information along with the heap objects(when malloc is called memory is allocated from the heap layout) by interposing the malloc function.
There are solutions to provide this information. There is an idea named fat pointer and several fat pointer libraries can be found like Cello. An improved version of the fat pointer can found in this work.
Related
HVM is a functional runtime which represents pointers as 32-bit values. Its allocator reserves a huge (4 GB) buffer preemptively, which it uses to create internal objects. This is not ideal. Instead, I'd like to use the system allocator, but that's not possible, since it returns 64-bit pointers, which may be larger than the space available to store them. Is there any cross-platform way in Rust to allocate a buffer, such that the pointer to the buffer is guaranteed to fit in an u32? In other words, I'm looking for something akin to:
let ptr = Box::new_with_small_ptr(size);
assert!(ptr as u64 + size < u32::MAX);
There isn't, because it's an extremely niche need and requires a lot of care.
It's not as simple as "just returning a low pointer" - you need to actually allocate that space from the OS. Your entry point into that would be mmap. Be prepared to do some low-level work with MAP_FIXED and reading /proc/self/maps, and also implementing an allocator on top of the memory region you get from mmap.
If your concern is just excess memory usage, note that Linux overcommits memory by default - allocating 4GB of memory won't reserve physical memory unless you actually try to use it all.
I'm trying to find a way to do heap memory allocation in armv8-a assembly, and after looking through syscall tables and trying to look at the Linux Programmer's Manual I can't find any way to allocate and de-allocate memory at runtime without using malloc and free from the c standard library.
I've looked at brk() but that doesn't appear to have any way to de-allocate memory.
mmap with MAP_ANONYMOUS is preferred to sbrk/brk for most purposes in modern programs. Use munmap to free.
By the way, brk can deallocate memory; simply pass an address lower than the current break point. But this does limit you to freeing in a last-in-first-out fashion.
I have a big struct (~200Mb) that I deserialize from a large JSON file from Java using serde_json and this deserialization occurs again when new data is available. The struct has Vecs, a HashMap of strings and structs of strings, etc.
While looking at the man page for mallopt(3), I found that environment variable MALLOC_MMAP_THRESHOLD_ can be set to control how much allocation has to be requested for malloc to allocate using mmap. I want to allocate my struct from mmap because the heap is causing memory fragmentation during reloads. I want the old deallocated memory (the one that is replaced with a new deserialized struct) to be returned to the system immediately (and not kept around by the one of the malloc arenas).
Is there a way to achieve this? Should I be using some other data format?
suppose i want to allocate 3000 bytes like this
malloc(1000);
malloc(1000);
malloc(1000);
and my malloc implementation use mmap() .
So i want to know that:-
is malloc called 3 times mmap().
is mmap allocate 3 separate pages(total allocated memory is 3*4096) or it gives memory to all three requeste from one page(total allocated memory is 4096).
if it allocated three different pages then how i can make my alloc to do it with only one page.
The mmapping behavior of Linux's (that is, GNU libc's) malloc is described in the manpage mallopt(3). malloc uses a "dynamic mmap threshold" that starts off at 128kB, but this may automatically be adjusted upward based on a process's allocation patterns. Smaller allocations are served using an old-school free list, and the initial threshold can be set using environment variables or the mallopt function.
So malloc will almost certainly not mmap three 4kB pages, but whether or not it keeps the allocations in a single page is not guaranteed. You can either do a manual mmap or, if two pages is ok, do a single malloc:
char *a = malloc(3000);
// check for errors
char *b = a + 1000;
char *c = b + 1000;
// don't forget that you must free a, and only a, to free b and c
When I was looking at the way std::string is implemented in gcc I noticed that sizeof(std::string) is exactly equal to the size of pointer (4 bytes in x32 build, and 8 bytes for x64). As string should hold a pointer to string buffer and its length as a bare minimum, this made me think that std::string object in GCC is actually a pointer to some internal structure that holds this data.
As a consequence when new string is created one dynamic memory allocation should occur (even if the string is empty).
In addition to performance overhead this also cause memory overhead (that happens when we are allocating very small chunk of memory).
So I see only downsides of such design. What am I missing? What are the upsides and what is the reason for such implementation in the first place?
Read the long comment at the top of <bits/basic_string.h>, it explains what the pointer points to and where the string length (and reference count) are stored and why it's done that way.
However, C++11 doesn't allow a reference-counted Copy-On-Write std::string so the GCC implementation will have to change, but doing so would break the ABI so is being delayed until an ABI change is inevitable. We don't want to change the ABI, then have to change it again a few months later, then again. When it changes it should only change once to minimise the hassles for users.