When applying bitwise operations, such as counting the number of set bits (popcount), on signed integers, there can be unexpected behavior due to the sign bit. Specifically, the sign bit can propagate during operations, potentially leading to incorrect results or undefined behavior.
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
void my_handler(int s){
printf("Caught signal %d\n",s);
exit(1);
}
int main(int argc,char** argv)
{
struct sigaction sigIntHandler;
sigIntHandler.sa_handler = my_handler;
sigemptyset(&sigIntHandler.sa_mask);
sigIntHandler.sa_flags = 0;
sigaction(SIGINT, &sigIntHandler, NULL);
pause();
return 0;
}#include <iomanip>#include <iostream>#include <ranges>#include <string>#include <string_view>
using namespace std::literals;// returns the splitted stringauto splittedWords3 = std::views::split("one:two:three", ':');for (const auto word : splittedWords3)std::cout << std::quoted(std::string_view(word));
String literals always end with a null-terminator, so ":.:" is actually a range with the last element of \0 and a size of 4.Since the original string does not contain such a pattern, it is not split.
using namespace std::literals;// returns the original string (not splitted)auto splittedWords1 = std::views::split("one:.:two:.:three", ":.:");for (const auto word : splittedWords1)std::cout << std::quoted(std::string_view(word));std::cout << std::endl;// returns the splitted stringauto splittedWords2 = std::views::split("one:.:two:.:three", ":.:"sv);for (const auto word : splittedWords2)std::cout << std::quoted(std::string_view(word));std::cout << std::endl;// returns the original string (not splitted)auto splittedWords4 = std::views::split("one:two:three", ":");for (const auto word : splittedWords4)std::cout << std::quoted(std::string_view(word));
template <class C> constexpr auto empty(const C& c) -> decltype(c.empty()); // (since c++17, until c++20) template <class C> [[nodiscard]] constexpr auto empty(const C& c) -> decltype(c.empty()); (since C++20) // (since c++20)
std::empty is useful for scenarios where a container may or may not provide a member function empty() for types providing a member function empty, std::empty provides a default implementation, but for a custom type not providing this function you can provide a function empty at namespace scope for use in templates; thanks to argument dependent lookup the function in the same namespace as the parameter will be used as fallback
namespace Custom{struct Container{bool m_empty;};constexpr bool empty(Container const& c) // custom implementation for our own type{return c.m_empty;}}template<class T>void PrintEmpty(char const* containerName, T&& container){using namespace std;std::cout << containerName << " is " << (empty(container) ? "empty" : "not empty");}int main(){PrintEmpty("std::vector<int>()", std::vector<int>());PrintEmpty("Container{}", Custom::Container{});PrintEmpty("Container{ true }", Custom::Container{ true });}
#include <stdio.h>int add(a, b)int a, b;{return a + b;}int main(){printf("%d\n", add(5, 6));}
Versions of C up to and including C89 (i.e. the language version standardised in 1989; note this was the last major revision to the C standard before 1999) allowed variables to be declared only at the beginning of a scope, which forces you into the style shown in your first snippet.
int main()
{
int i;
for (i=0; i<10; i++)
{
printf("hello\n");
}
return 0;
}Under the hood, GNU malloc uses various data structures to make memory allocations more efficient. One such data structure is a collection of heaps. When the application calls malloc, one of these heaps is searched for a contiguous free chunk of memory big enough to fit the request. When the application calls free, a chunk of the heap frees up, which can be reused by a future malloc call. An important detail is that only the topmost chunk of each heap is available for returning to the OS. All empty chunks in the middle of heaps will technically be unused, but still count towards the memory the application is using. This is a very simplified view of what’s happening; check the glibc wiki for a complete overview of GNU malloc internals.
As you might imagine, there could be many chunks in the malloc heaps just sitting around empty, depending on the pattern of malloc and free calls an application executes. At this point we were wondering if this kind of memory fragmentation could explain the Fulfillment Service’s ever growing memory usage. While investigating possible ways to confirm this, we happened upon an excellent article from the LinkedIn engineering team, describing a problem extremely similar to ours. However, instead of using the gdb-heap tool the LinkedIn team used, we decided to confirm our hypothesis in a slightly more direct way.
It turns out that GNU malloc already exposes some statistics which are suitable for roughly quantifying memory fragmentation. The statistics we are interested in are: the total size of memory in use by the application, the total size of memory in malloc’s heaps but not in use by the application and the part of that memory allowed to be returned to the OS. GNU malloc’s mallinfo function returns these as the uordblks, fordblks and keepcost fields respectively. So, calculating 1 — uordblks / (fordblks — keepcost) gives the ratio of unused memory that cannot be returned to the OS, a measure of memory fragmentation.
Having learned this, we created a local testing setup of the Fulfillment Service. This setup consisted of a Docker container with gdb (the GNU debugger for debugging native code), OpenJDK with debug symbols and glibc with debug symbols. This setup allowed us to attach gdb to the JVM and call the mallinfo function from the gdb prompt.
These two functions, malloc and free, are implemented in their own library. The default on most flavors of Linux is GNU malloc, but it can be swapped out for other implementations. One such implementation is jemalloc, which conveniently also allows tracking where malloc is being called from. This gives us the opportunity to see whether there are any native functions allocating increasing amounts of memory.
On Linux, jemalloc can be enabled by bundling its shared library with an application and setting the LD_PRELOAD environment variable to the location of libjemalloc.so before running Java. Memory profiling can be enabled through the MALLOC_CONF environment variable. The jemalloc wiki contains some useful examples. You can check the jemalloc man page for a full reference of these options. Now our application writes .heap files after a set volume of allocations. These files can be parsed using the jeprof command into something human-readable.
Jemalloc only samples memory allocations instead of measuring every single malloc call to prevent excessive resource consumption. Therefore, the output of jeprof cannot be directly interpreted as the number of bytes currently in use. However, it does allow us to spot any suspicious functions allocating native memory. Additionally, we could also spot functions that are holding on to significantly more memory relative to others (potentially indicating a memory leak).
export LD_PRELOAD=/usr/local/lib/libjemalloc.so# tell jemalloc to write a profile to the disk every few 1Gb allocations# and record a stack trace (referenced from the blog):export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17# jeprof*.heap. isimli dosyalar oluşur# dosyalardan rapor oluşturjeprof --show_bytes --gif /path/to/jvm/bin/java jeprof*.heap > /tmp/app-profiling.gif
TCMalloc assigns each thread a thread-local cache. Small allocations are satisfied from the thread-local cache. Objects are moved from central data structures into a thread-local cache as needed, and periodic garbage collections are used to migrate memory back from a thread-local cache into the central data structures.
... concept like std::integral constrains the deduced type to be an integral type, such as int or long, but not float, or std::string.
std::integral auto something(){
return 0;
}
int main(){
const auto x = something();
return x;
}