Theory vs. Practice
Diagnosis is not the end, but the beginning of practice.
G-WAN's Value: 450x Faster, and C/C++/JS/PHP are Legal again (made "memory-safe")
Does security finally matter? PHP and JS (written in C/C++ and not "memory-safe") are endangered by an executive order:
US President Joe Biden's administration wants software developers to use memory-safe programming languages and ditch vulnerable ones like C and C++.
Only Rust (funded by the GAFAM) would be allowed (due to international regulations) despite Rust created with C/C++, Rust not being really "memory-safe" (search for "memory"), and Rust relying on memory-unsafe OS syscalls written in (you guess it)C.
Under the flawed logic of ever-stretched fallacies justifying administrative transfers of wealth from the masses to a few ever-growing industry players, this ban should include everything written in C/C++ (Rust, Windows, OSX, Linux, Android, all Web browsers, Java, JS, PHP, OpenSSL, NGINX, etc.) – and almost everything written by everyone for the past 50 years.
Only G-WAN+SLIMalloc have escaped this trap: G-WAN and its servlets are "memory-safe", an objective security criteria.
The number of vulnerabilities is also an objective code-quality indicator (from the U.S. gov. database of vulnerabilities):
NGINX: 248 vulnerabilities (since 2004, click the link for the current count of CVEs, Common Vulnerabilities and Exposures)
G-WAN: 0 vulnerabilities (since 2009)
This is despite G-WAN JIT scripted servlets (since 2009) which immensely enlarge the surface of vulnerability as compared to NGINX, that only started recently to add basic scritping to generate dynamic contents (via slow IPC/inter-process communication instead of loading the language runtimes like G-WAN – which is much faster, but far more difficult to do safely).
That was for 2009-2020 when G-WAN and NGINX relied on the same GLibC that SLIMalloc has proved, in graphic details, so unsafe (yet, surprisingly, a bit safer than Microsoft MIMalloc, Google TCmalloc, and Facebook/Meta JEmalloc).
A clear past CVE record is a notable feat for a Web Application Server, but adding some sustainable certainty is certainly better:
SLIMalloc (a memory allocator) secures G-WAN, its servlets, and the loaded languages runtimes and libraries by:
(1) not introducing memory-allocation vulnerabilities (unlike all others),
(2) checking if accessed memory is under/over-written, and,
(3) blocking and reporting memory-violations – without crashing the program (yet another exclusivity).
SLIMalloc (2020) makes G-WAN safer than NGINX – and even safer than the so-called "memory-safe" languages (including Rust, which itself already had memory-safety vulnerabilities) because, unlike SLIMalloc, Rust flatly ignores the memory-violations originating from the OS (usermode and kernel) and third-party libraries... written in C.
This is G-WAN's objective, heavily tested security published on ResearchGate – a clear improvement of the "State of the Art".
Now G-WAN's security was explained, let's focus on objective reproductible performance. And, to make sure that G-WAN would not be criticized for having done cherry-picking (like others), we have used wrk2, a slower, more accurate version of the wrk benchmark written by... the NGINX team.
Why is wrk2 any better than wrk to accurately measure performance?
wrk sends a new request only after it receives a server reply. By not tracking request start/end times, wrk fails to report slow, high-latency server replies. This is what the wrk2 author has properly named (client/server) "Coordinated Omission". Servers can't reply faster than the speed at which clients send their requests, and all the clients I have seen are G-WAN's bottleneck.
With G-WAN v17.2.7, wrk requires days to run a single "wrk -t10k -c10k http://127.0.0.1/100.html" test run... because wrk is unable to swiftly process the 242m G-WAN RPS.
The same NGINX v1.24.0 test runs in 10 seconds because wrk can handle the tiny 550k NGINX RPS on time. With such a tiny number of concurrent server replies, the slow wrk client does not need days.
In contrast, wrk2 sends requests at the user-supplied constant rate to the server (which will fail with I/O errors when overwhelmed). And wrk2 calibrates threads for 10 seconds (versus wrk's 0.5 second). The result is slower RPS scores than wrk, albeit more correct RPS and latency reports.
Since wrk2 sends requests at a constant-rate (unlike wrk which waits for server replies to send new requests), wrk2 will stop the test after 10-second, not days – even with a server like G-WAN (which is much, much faster than wrk and wrk2).
That's how G-WAN performance is objectively measured and reproduced (scientists create and use benchmarks for a reason).
That was a long introduction – as I have for the first time (in my blog) presented the technical arguments before the question.
So, what was the question?
How to Write About G-WAN (How-To with objective metrics and official references)
The technical arguments (security, performance) are listed above. Below, many official "memory-safety" references are listed – just in case you need to (1) read about it from another perspective (mainly stating that there's no silver bullet), or (2) to show your boss or investors that this is a real and serious problem (something that, after six decades of denial and censorship, is finally officially confirmed by several U.S. government agencies):
https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY_V1.1.PDF
https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Recommendations-Memory-Safety_Final_20231205_508.pdf
https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
https://cyberdefensereview.army.mil/Portals/6/Documents/2024-Fall/Yarbrough_Guan_CDRV9N3-Fall-2024.pdf
https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=958266
https://web.mit.edu/ha22286/www/papers/CACM25.pdf
https://www.ic3.gov/CSA/2025/250212.pdf
The market players, their motivations, and the unstoppable march of progress
For commercial reasons (profit, marketshare, inifinite growth required to pay-back an ever-growing debt), the GAFAM slowly make progress in "memory-safety" security (while performance slightly decreases and the number of OS patches explodes).
Yet what they do for Rust is not done for C or C++ (Bjarne noticed it and is now copying Rust's memory-safety in an attempt to save C++ from a regulatory ban – given the size and complexity of the animal, that will not be an easy task).
So, SLIMalloc is the only usable option for C (the OS, and the popular languages derived from the C runtime, like JS, Java, PHP, etc.).
The level of required skills to resolve these (security and multicore) problems will let very few Web servers (and even less App. servers) stay (legally, technically and financially) viable options on the global market.
The foreseeable outcomes
This situation will probably benefit to G-WAN – because:
- from 2009 to 2025, G-WAN has consistently been much faster (and safer) than anything else;
- G-WAN+SLIMalloc will save C/C++/JS/Java/PHP their authors and developers from oblivion;
- less market players will allow end-users better evaluate the competiting products and vendors;
- as time goes – and while the number of CPU Cores grows – G-WAN scales increasingly better;
- AI, Crypto mining, and today's 50BN connected objects (car, watch, TV, smartphone, computer);
- the IoT is expected to grow from 50bn to 100bn connected objects by 2030 (twice the telemetry);
- the rise of the energy prices and of their associated regulatory constraints will pressure everyone;
- the ever-accelerating monetary-mass growth has stopped and will slow-down, restoring parsimony;
- TWD, which I founded in 1998 and that sells G-WAN, has a background of fantastic achievements.
The future looks much brighter to me than the past. I am not sure that our competitors can claim the same.