Language-Level Memory Management (C/C++/Rust) Questions

If algorithmic complexity is fixed, I would optimize how the CPU feeds on data. The first step is measurement, not guessing. I would profile the hot loop with a sampling profiler and hardware counters to see branch misses, cache misses, stalled cycles, and whether the compiler auto-vectorized the loop.

Changes I would consider:

• Make memory access contiguous so the CPU can prefetch efficiently.
• Reduce pointer chasing and indirect calls.
• Rewrite unpredictable branches into separate hot and cold paths when it helps.
• Hoist invariant work out of the loop.
• Use a layout that suits the access pattern, such as struct-of-arrays instead of array-of-structs.
• Let the compiler vectorize, and only use intrinsics if profiling proves they matter.

Concrete example: 20,000,000 records at 64 bytes each means about 1.28 GB of data moved through caches. If every record also hits an unpredictable if, branch mispredicts can dominate runtime even when the algorithm is still O(n).

What I would not do: premature micro-optimizations without evidence. I would use profiling to pick the top bottleneck, make one change, then re-measure. On CPU-bound code, throughput usually improves most from better locality, fewer branches, and fewer loads and stores.

This is usually copy-on-write, which is expected behavior after fork. Copy-on-write means the parent and child initially share the same physical memory pages. The kernel copies a page only when one process writes to it. So a memory spike right after fork often reflects accounting or page faults, not a full duplicate of the whole heap.

What I would inspect:

• RSS versus PSS. RSS can make both processes look large, while PSS shows shared memory more honestly.
• /proc/<pid>/smaps to see private dirty pages.
• Page-fault counts and whether the child writes to large regions of memory.
• Whether huge pages or allocator arenas are causing more pages to be copied than expected.

Concrete example: if the parent has a 4 GB heap and the child reads only, the child does not get 4 GB of new physical memory. If the child writes to 100 MB of pages, then roughly that much becomes private to the child.

How I would judge it: if RSS jumps but PSS stays stable and the child exits quickly, the spike is probably expected. If private dirty memory keeps growing, the child is touching too much state and the fork pattern may need redesign, such as using a worker pool or reducing the amount of writable memory inherited at fork time.

I would inspect three things immediately: alignment, endianness, and object layout. Casting a raw byte buffer to a struct is fragile because the file format and the C++ struct are not guaranteed to match. x86 often tolerates unaligned access, while ARM may fault or behave differently, which is why the bug can appear only on ARM.

What I would check:

• Whether the struct has padding inserted by the compiler.
• Whether the buffer address satisfies the struct's alignment requirements.
• Whether the file format uses little-endian or big-endian byte order.
• Whether the code violates strict aliasing by treating bytes as a different type.

Concrete example: if the file stores a 32-bit length as bytes 01 00 00 00, that means 1 in little-endian. A direct struct cast assumes the host layout matches the file, but that is not safe across platforms.

Safer approach: parse fields from bytes explicitly, or copy bytes into fixed-width integers and convert them. For example:

bool parse_len(const unsigned char* b, std::uint32_t& len) {
    len = std::uint32_t(b[0]) |
          (std::uint32_t(b[1]) << 8) |
          (std::uint32_t(b[2]) << 16) |
          (std::uint32_t(b[3]) << 24);
    return true;
}

That keeps the parser portable, alignment-safe, and explicit about byte order.

I would not store a raw user_data pointer without a lifetime rule. A callback is just a function called later, and user_data is the context pointer passed back to it. Because the callback may run long after registration, the event loop needs a handle that owns that context or holds a reference to it.

My rules would be:

• Registration returns an opaque handle.
• The handle keeps the context alive while the callback can still run.
• unregister marks the handle cancelled and waits for any in-flight callback to finish before freeing context.
• If callbacks can run on another thread, protect the handle with a mutex or atomic refcount.

Concrete example: if the context is struct request { int fd; char *name; }, the callback can read it safely only while the handle is active. If the caller unregisters, the loop first prevents future dispatch, then waits until the current callback exits, then frees the request.

That is safer than telling callers to free the context whenever they want. In interviews, I would say the API should make dangling pointers impossible by construction, or at least very hard to create.

Best design
I would not hand out a bare char ** with mixed ownership and no metadata. I would return a small list object that carries the tokens plus one ownership flag per slot.

Rule: if owned[i] is true, the caller frees items[i]. If it is false, the token is a slice into the original buffer and must not be freed. The caller owns the container and releases it with one cleanup function that walks the list, frees only owned tokens, then frees the arrays.

Concrete example: token 0 could be strdup("abc") and token 1 could point into the input line abc def. If the caller filters out token 0, it frees that string, but leaves token 1 alone. I would also require the source buffer to stay alive until cleanup, or duplicate everything if I want the simplest contract.

for (size_t i = 0; i < list->len; ++i) {
    if (list->owned[i]) free(list->items[i]);
}
free(list->items);
free(list->owned);