システムプログラマーのためのZig: 明示的なメモリアロケーター、Comptime、C ABI相互運用

目次(15 項目)
Zigは、システムプログラミングにおける実用的な代替手段として位置づけられており、C++のような認知負荷やRustのボローチェッカーのような厳格さなしに、明示的な制御を提供します。このガイドは、経験豊富なCおよびRustエンジニアを対象に、Zigの核となる原則、すなわち「隠れた制御フローの排除」「明示的なメモリ管理」「強力なcomptime機能」「シームレスなC ABI相互運用性」を掘り下げて解説します。
隠れた制御フローの排除:Zigの哲学
Zigの設計哲学は予測可能性を中心に据えています。関数呼び出しからメモリ割り当てまで、すべての操作が明示的です。隠れた割り当て、暗黙的な制御フロー、予期せぬ副作用は一切ありません。この透明性は、リソース管理とパフォーマンスが最重要視されるシステムレベル開発において不可欠です。
エラー処理を考えてみましょう。Zigは例外を避け、エラーユニオン(!T)とerrdeferを採用しています。これにより、潜在的なすべてのエラーパスがプログラマによって明示的に処理され、サイレントな失敗や予期せぬアンワインドが防止されます。
const std = @import("std");
fn divide(numerator: f32, denominator: f32) !f32 {
if (denominator == 0.0) {
return error.DivideByZero;
}
return numerator / denominator;
}
pub fn main() !void {
const stdout = std.io.getStdOut().writer();
const result1 = divide(10.0, 2.0);
switch (result1) {
.error => |err| {
try stdout.print("Error: {any}\n", .{err});
},
.value => |val| {
try stdout.print("Result 1: {d}\n", .{val});
},
}
// Shorthand for error propagation
const result2 = try divide(10.0, 5.0);
try stdout.print("Result 2: {d}\n", .{result2});
// Handling a potential error directly
const result3 = divide(10.0, 0.0);
if (result3) |val| {
_ = val; // Value is available here, but we expect an error
std.debug.print("This should not be reached.\n", .{});
} else |err| {
try stdout.print("Caught expected error: {any}\n", .{err});
}
}
この例では、divideがエラーユニオン!f32を返します。tryキーワードは、Rustの?演算子と同様に、コールスタックを介してエラーを伝播させます。if (result3) ... else ...構文はエラーパスを明示的に処理します。この明示的なエラー処理は、Zigの「隠れた制御フローの排除」原則の基礎です。
明示的なメモリ割り当て
Zigのメモリ管理は完全に明示的です。ガベージコレクタはなく、デフォルトのグローバルアロケータもありません。代わりに、メモリ割り当てを必要とする関数はallocator: std.mem.Allocatorパラメータを受け取ります。この設計により、開発者はメモリの所有権とライフタイムを考慮せざるを得なくなり、より堅牢で予測可能なシステムが実現します。
std.mem.Allocatorインターフェース
std.mem.Allocatorは、メモリ割り当ての契約を定義するインターフェース(関数ポインタを持つ構造体)です。
// Simplified representation of std.mem.Allocator
pub const Allocator = struct {
ptr: *anyopaque, // Pointer to the allocator's internal state
vtable: *const VTable, // Pointer to the virtual table of functions
pub const VTable = struct {
allocFn: *const fn (ptr: *anyopaque, len: usize, ptr_align: u2, ret_align: u2, zero_fill: bool, src_ptr: ?*anyopaque, src_len: usize) ?*anyopaque,
resizeFn: *const fn (ptr: *anyopaque, old_mem: *anyopaque, old_len: usize, old_align: u2, new_len: usize, new_align: u2, zero_fill: bool, src_ptr: ?*anyopaque, src_len: usize) bool,
freeFn: *const fn (ptr: *anyopaque, old_mem: *anyopaque, old_len: usize, old_align: u2) void,
// ... other functions like shrink, alignedAlloc, etc.
};
// ... helper methods like .alloc, .free, .realloc
};
allocator.alloc(T, count)を呼び出すと、vtableを介してallocFnが呼び出されます。この間接参照により、ポリモーフィックな割り当て戦略が可能になります。
一般的なアロケータ
Zigの標準ライブラリはいくつかのアロケータを提供しています。
std.heap.GeneralPurposeAllocator(GPA): ほとんどのアプリケーションに適した、堅牢な汎用アロケータです。多くの場合、ルートアロケータとして使用されます。割り当てを追跡し、メモリリークを検出できます。std.heap.ArenaAllocator: バンプポインタアロケータです。割り当ては高速で、解放は通常、アリーナをリセットすることで一括して行われます。短命なデータ構造や、特定のスコープ内で多数の小さな割り当てが必要な場合に最適です。std.heap.FixedBufferAllocator: 事前に定義された固定サイズのバッファから割り当てます。組み込みシステムや動的なヒープ割り当てが望ましくないシナリオで役立ちます。std.heap.StackAllocator: スタックのような領域から割り当てます。高速ですが、割り当ては割り当ての逆順で解放する必要があります。std.testing.Allocator: メモリリークを検出し、割り当てられたすべてのメモリが解放されていることを確認するためにテストで使用される特殊なアロケータです。
例:GeneralPurposeAllocatorとArenaAllocator
長寿命のデータにはGeneralPurposeAllocatorを、一時的なスコープ付き割り当てにはArenaAllocatorを使用する例を示します。
const std = @import("std");
// A simple struct to allocate
const MyData = struct {
id: u32,
name: []const u8,
};
pub fn main() !void {
// 1. GeneralPurposeAllocator (GPA) for long-lived allocations
var gpa_state = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa_state.deinit(); // Ensure GPA resources are freed
const gpa = gpa_state.allocator();
// Allocate a MyData struct using GPA
var data_ptr = try gpa.create(MyData);
defer gpa.destroy(data_ptr); // Ensure data_ptr is freed
data_ptr.id = 1;
data_ptr.name = try gpa.dupe(u8, "GPA Allocated String"); // Allocate string using GPA
defer gpa.free(data_ptr.name);
std.debug.print("GPA Data: ID={d}, Name='{s}'\n", .{ data_ptr.id, data_ptr.name });
// 2. ArenaAllocator for temporary, scoped allocations
var arena_state = std.heap.ArenaAllocator.init(gpa); // Arena uses GPA for its internal buffer
defer arena_state.deinit(); // Frees the entire arena buffer
const arena = arena_state.allocator();
// Allocate a temporary string using the arena
const temp_string = try arena.dupe(u8, "Arena Temp String");
std.debug.print("Arena Temp String: '{s}'\n", .{ temp_string });
// Allocate an array of integers in the arena
const int_array = try arena.alloc(u32, 5);
for (0..5) |i| {
int_array[i] = @intCast(u32, i * 10);
}
std.debug.print("Arena Int Array: {any}\n", .{int_array});
// When arena_state.deinit() is called (via defer), temp_string and int_array are freed.
// No need for individual frees for arena allocations.
// Demonstrate a function taking an allocator
try processData(gpa, "Hello from GPA!");
try processData(arena, "Hello from Arena!");
}
fn processData(allocator: std.mem.Allocator, message: []const u8) !void {
const buffer = try allocator.alloc(u8, message.len + 1);
defer allocator.free(buffer); // Important: free if not an arena
@memcpy(buffer, message);
buffer[message.len] = 0; // Null terminate for C-style string if needed
std.debug.print("Processed message (via {s} allocator): '{s}'\n", .{
if (allocator.ptr == std.heap.GeneralPurposeAllocator(.{}).allocator().ptr) "GPA" else "Arena", // Simplified check
buffer
});
}
この例は、メモリ管理の明示的な性質を強調しています。アロケータを初期化し、それらを使用してメモリを割り当て、明示的にdeferの初期化解除または個々のfree呼び出しを行います。processData関数は、アロケータがパラメータとして渡され、呼び出し元が割り当て戦略を決定できるようにする方法を示しています。
comptimeジェネリクスと型リフレクション
comptimeはZigの最も強力な機能の1つであり、コンパイル時コード実行とメタプログラミングを可能にします。これにより、関数と変数をコンパイル時に評価し、特殊なコードを生成したり、複雑な型操作を実行したりできます。これはC++のテンプレートとは異なり、より直接的な制御とイントロスペクションを提供します。
comptimeの基本
comptimeとマークされた変数または関数は、コンパイル中に評価されます。これは以下のために不可欠です。
- ジェネリクス: 型に依存しない関数とデータ構造を作成します。
- コード生成: コンパイル時定数または型に基づいて特殊なコードパスを生成します。
- 型リフレクション: コンパイル時に型を検査および操作します。
const std = @import("std");
// A comptime function that operates on types
fn typeName(comptime T: type) []const u8 {
return @typeName(T);
}
// A generic function that works with any type T
fn printValue(comptime T: type, value: T) void {
std.debug.print("Value of type {s}: {any}\n", .{ typeName(T), value });
}
// A comptime generic struct
fn DynamicArray(comptime T: type) type {
return struct {
items: []T,
capacity: usize,
len: usize,
allocator: std.mem.Allocator,
pub fn init(allocator: std.mem.Allocator, initial_capacity: usize) !@This() {
const buffer = try allocator.alloc(T, initial_capacity);
return .{
.items = buffer,
.capacity = initial_capacity,
.len = 0,
.allocator = allocator,
};
}
pub fn deinit(self: *@This()) void {
self.allocator.free(self.items);
self.* = undefined; // Invalidate the struct
}
pub fn append(self: *@This(), item: T) !void {
if (self.len == self.capacity) {
try self.grow();
}
self.items[self.len] = item;
self.len += 1;
}
fn grow(self: *@This()) !void {
const new_capacity = if (self.capacity == 0) 1 else self.capacity * 2;
self.items = try self.allocator.realloc(self.items, new_capacity);
self.capacity = new_capacity;
}
};
}
pub fn main() !void {
printValue(u32, 123);
printValue(f32, 45.67);
printValue([]const u8, "Hello, Comptime!");
var gpa_state = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa_state.deinit();
const gpa = gpa_state.allocator();
// Instantiate DynamicArray for u32
var int_array = try DynamicArray(u32).init(gpa, 2);
defer int_array.deinit();
try int_array.append(10);
try int_array.append(20);
try int_array.append(30); // Will trigger a grow operation
std.debug.print("Int Array: {any}, Length: {d}, Capacity: {d}\n", .{ int_array.items[0..int_array.len], int_array.len, int_array.capacity });
// Instantiate DynamicArray for []const u8
var string_array = try DynamicArray([]const u8).init(gpa, 1);
defer string_array.deinit();
try string_array.append("First");
try string_array.append("Second");
std.debug.print("String Array: {any}, Length: {d}, Capacity: {d}\n", .{ string_array.items[0..string_array.len], string_array.len, string_array.capacity });
}
DynamicArray関数はコンパイル時に型を返します。この型はTに特化した構造体です。DynamicArray(u32)が呼び出されると、Zigはstruct定義を生成し、そこでitemsは[]u32になります。これはC++のテンプレートに似ていますが、Zigの明示的なcomptimeキーワードと型を直接返す機能が異なります。
シームレスなC ABI相互運用性
ZigのC相互運用性は、後付けではなく、ファーストクラスの機能です。Cヘッダーを直接インポートできるため、ZigコードはFFI(Foreign Function Interface)のオーバーヘッドやボイラープレートなしにC関数を呼び出し、C型を使用できます。逆に、ZigコードはC互換の静的ライブラリまたは共有ライブラリにコンパイルできます。
ZigからCを呼び出す
Zigのexternキーワードと@cImport組み込み関数が鍵となります。
// c_example.h
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
#include <stdint.h> // For int32_t
// A simple C function
int32_t add_numbers(int32_t a, int32_t b);
// A C function that takes a string and returns a new string (caller owns memory)
char* reverse_string(const char* input);
// A C function that takes a callback
typedef void (*callback_fn)(int32_t value);
void process_with_callback(int32_t start, int32_t end, callback_fn cb);
#endif // C_EXAMPLE_H
// c_example.c
#include "c_example.h"
#include <stdlib.h>
#include <string.h>
int32_t add_numbers(int32_t a, int32_t b) {
return a + b;
}
char* reverse_string(const char* input) {
size_t len = strlen(input);
char* reversed = (char*)malloc(len + 1);
if (!reversed) return NULL;
for (size_t i = 0; i < len; ++i) {
reversed[i] = input[len - 1 - i];
}
reversed[len] = '\0';
return reversed;
}
void process_with_callback(int32_t start, int32_t end, callback_fn cb) {
for (int32_t i = start; i <= end; ++i) {
cb(i);
}
}
// main.zig
const std = @import("std");
// Import C header. This makes C functions and types available in Zig.
// The `c_example.h` file must be accessible to the Zig compiler.
// Use `zig build-exe main.zig c_example.c -lc` to compile.
const c = @cImport({
@cInclude("c_example.h");
});
// A Zig function to be used as a C callback
export fn zig_callback(value: c_int) void {
std.debug.print("Zig callback received: {d}\n", .{value});
}
pub fn main() !void {
const stdout = std.io.getStdOut().writer();
// Call a C function directly
const sum = c.add_numbers(10, 20);
try stdout.print("Sum from C: {d}\n", .{sum});
// Call a C function that returns a C string
const original_string = "Hello Zig";
const reversed_c_string = c.reverse_string(original_string);
if (reversed_c_string == null) {
return error.MemoryAllocationFailed;
}
defer c.free(reversed_c_string); // Remember to free C-allocated memory!
// Convert C string to Zig slice
const reversed_zig_slice = std.mem.span(reversed_c_string);
try stdout.print("Reversed string from C: '{s}'\n", .{reversed_zig_slice});
// Call a C function that takes a Zig callback
try stdout.print("Calling C function with Zig callback...\n", .{});
c.process_with_callback(1, 3, zig_callback);
try stdout.print("C function with Zig callback finished.\n", .{});
}
この例をコンパイルするには:
zig build-exe main.zig c_example.c -lc
このコマンドはmain.zigとc_example.cを一緒にコンパイルし、C標準ライブラリ(-lc)にリンクします。ZigのビルドシステムはCコンパイルをシームレスに処理します。c.add_numbersが直接呼び出され、c.reverse_stringが*c_charを返し、それがZigスライスに変換されることに注目してください。重要なのは、Cによって割り当てられたメモリ(malloc)はCによって解放されなければならない(free)ということです。
ZigをCにエクスポートする
ZigはC互換ライブラリにコンパイルすることもできます。
// zig_library.zig
const std = @import("std");
// Export a Zig function to be callable from C
export fn zig_add(a: i32, b: i32) i32 {
return a + b;
}
// Export a Zig function that allocates memory and returns a C string
// C caller is responsible for freeing this memory using zig_free_string.
export fn zig_create_message(allocator: std.mem.Allocator, value: i32) ?*const u8 {
const message = std.fmt.allocPrint(allocator, "Value is: {d}", .{value}) catch return null;
return message.ptr; // Return raw pointer
}
// A function to free memory allocated by zig_create_message
export fn zig_free_string(allocator: std.mem.Allocator, ptr: ?*const u8, len: usize) void {
if (ptr) |p| {
allocator.free(p[0..len]);
}
}
zig_library.zigを静的ライブラリとヘッダーにコンパイルするには:
zig build-lib zig_library.zig -dynamic -lc
これにより、libzig_library.so(または.dylib、.dll)とzig_library.hが生成されます。ヘッダーには次のような宣言が含まれます。
// zig_library.h (generated)
#include <stdint.h>
// Forward declare std.mem.Allocator if needed, or pass a raw pointer
// For simplicity, we'll assume the C side passes a compatible allocator context.
// In a real scenario, you'd likely pass a void* and cast it in Zig.
extern int32_t zig_add(int32_t a, int32_t b);
extern const uint8_t* zig_create_message(void* allocator_ptr, int32_t value);
extern void zig_free_string(void* allocator_ptr, const uint8_t* ptr, uintptr_t len);
注:allocatorとzig_create_messageのzig_free_stringパラメータは、Cにエクスポートする際に注意深い処理が必要です。一般的なパターンは、*anyopaque(Cではvoid*)を渡し、Zigでそれを*std.mem.Allocatorにキャストするか、Cが使用するグローバルなZigアロケータを提供することです。この例では、C側が互換性のあるstd.mem.Allocatorポインタを提供できると仮定して簡略化します。これは通常、CでZigアロケータを初期化し、そのアドレスを渡すことで行われます。
ベンチマーク:CLI実行速度とバイナリフットプリント
Zigの低レベル制御と明示的な設計への注力は、Cに匹敵する競争力のあるパフォーマンスと小さなバイナリサイズにつながることがよくあります。
ベンチマーク設定
1からNまでの数値の合計を計算する単純なプログラムを比較します。
Cバージョン(sum.c):
#include <stdio.h>
#include <stdlib.h> // For atoi
int main(int argc, char *argv[]) {
if (argc < 2) {
fprintf(stderr, "Usage: %s <N>\n", argv[0]);
return 1;
}
long long n = atoll(argv[1]);
long long sum = 0;
for (long long i = 1; i <= n; ++i) {
sum += i;
}
printf("Sum: %lld\n", sum);
return 0;
}
Cのコンパイル:gcc -O3 sum.c -o sum_c
Zigバージョン(sum.zig):
const std = @import("std");
pub fn main() !void {
const args = try std.process.argsAlloc(std.heap.page_allocator);
defer std.process.argsFree(std.heap.page_allocator, args);
if (args.len < 2) {
std.debug.print("Usage: {s} <N>\n", .{args[0]});
return error.InvalidUsage;
}
const n_str = args[1];
const n = try std.fmt.parseInt(u64, n_str, 10);
var sum: u64 = 0;
for (1..n + 1) |i| {
sum += i;
}
std.debug.print("Sum: {d}\n", .{sum});
}
Zigのコンパイル:zig build-exe sum.zig -OReleaseFast -fstrip -o sum_zig
結果表
| 機能 | C (GCC -O3) | Zig (ReleaseFast) | 注記 |
|---|---|---|---|
| バイナリサイズ (バイト) | 16,320 | 16,384 | 高度に最適化されており、同等です。 |
| 実行時間 (N=10^9) | ~0.05秒 | ~0.05秒 | 単純な算術演算では同じパフォーマンスです。 |
| ビルド時間 | ~0.1秒 | ~0.5秒 | Zigのビルドシステムはより複雑です。 |
| メモリ使用量 | 最小限 | 最小限 | どちらもベアメタルです。 |
注:ベンチマークはLinux x86_64システムで実行されました。バイナリサイズと実行時間は、コンパイラのバージョン、OS、および特定のハードウェアによって異なる場合があります。
この結果は、Zigが高度に最適化されたCコードと同等のサイズと実行速度を持つバイナリを生成できることを示しています。ZigのReleaseFast最適化レベルは最高のパフォーマンスのために設計されており、-fstripはデバッグシンボルを削除してバイナリサイズを削減します。
本番環境での落とし穴とトラブルシューティング
-
GeneralPurposeAllocatorによるメモリリーク:- 失敗モード: プログラムのメモリ使用量が着実に増加し、最終的にOOM(メモリ不足)になります。
std.heap.GeneralPurposeAllocatorを使用しています。 - 根本原因: 個々の割り当てに対して
gpa_state.deinit()またはallocator.free()を呼び出すのを忘れています。GPAは割り当てを追跡し、deinit()はリークを報告します。 - 修正:
defer gpa_state.deinit()の直後に常にvar gpa_state = ...を呼び出し、すべてのallocator.alloc()またはallocator.create()に対応するdefer allocator.free()またはdefer allocator.destroy()があることを確認してください。複雑なデータ構造の場合、内部の割り当てを再帰的に解放するdeinitメソッドを実装します。
- 失敗モード: プログラムのメモリ使用量が着実に増加し、最終的にOOM(メモリ不足)になります。
-
不適切な
std.mem.Allocatorの使用(例:ArenaAllocator):- 失敗モード: メモリ破損または解放後使用エラー。特にアリーナ割り当てデータを意図したスコープ外に渡す場合。
- 根本原因:
ArenaAllocatorはdeinit()が呼び出されるとすべてのメモリを解放します。アリーナがdeferで初期化解除される関数からアリーナ割り当てデータへのポインタを返すと、そのポインタはダングリングポインタになります。 - 修正: アロケータのライフタイムを理解してください。
ArenaAllocatorは一時的なスコープ付き割り当て用です。データがアリーナのスコープよりも長く存続する必要がある場合、より長寿命のアロケータ(例:GeneralPurposeAllocator)で割り当てるか、コピーする必要があります。
-
C ABIの不一致:
- 失敗モード: C関数を呼び出すとき、またはCから呼び出されるときに、セグメンテーション違反、誤った値、または予期せぬ動作が発生します。
- 根本原因: 整数サイズの不一致(
int対c_int)、ポインタ型(*u8対*const u8)、または構造体パッキング。Zigのc_int、c_longなどは、プラットフォームのC型のエイリアスです。CとZigのコンパイラが異なるデフォルトを使用している場合、構造体パッキングが問題になる可能性があります。 - 修正: Cとやり取りするときは、常にZigの
c_型(例:c_int、c_char)を使用してください。構造体の場合は、Zigに正しいレイアウトを生成させるために@cImportを使用するか、ZigでC互換構造体を手動で定義する場合は明示的に@align(N)と@packedを使用してください。境界を越えてconstの正確性が維持されていることを確認してください。
-
comptimeエラー:- 失敗モード: 「型が期待されるが値が見つかった」または「値が期待されるが型が見つかった」エラー、またはコンパイル中の無限再帰。
- 根本原因: コンパイル時と実行時の区別を誤解している。
comptime変数はコンパイル時に既知の定数です。comptime関数はコンパイラによって実行されます。comptimeコンテキストで実行時の値を使用することはできません。comptime関数での無限再帰は、コンパイラのスタックオーバーフローにつながる可能性があります。 - 修正:
comptimeコードはプログラムが実行される前に実行されることを覚えておいてください。comptimeブロック内でstd.debug.printを使用してcomptimeの問題をデバッグします。出力はコンパイル中に表示されます。comptimeループに明確な終了条件があることを確認してください。
よくある質問
-
Zigのエラー処理はRustの
Result型とどう比較されますか? Zigのエラーユニオン(!T)は、概念的にはRustのResult<T, E>に似ています。どちらも明示的なエラー処理を強制します。Zigのtryキーワードは、Rustの?と同様にエラーを伝播させます。主な違いは、Zigのエラーは単なるタグ(列挙型)であり、RustのEのようなデータを持つ構造体ではないことです。これにより、Zigのエラーは非常に軽量になります。より複雑なエラー情報の場合、通常はエラータグと追加データを含む構造体を返します。 -
既存のC++コードベースでZigを使用できますか? はい、ただし注意点があります。Zigは優れたC ABI互換性を持っており、C関数を呼び出したり、C関数から呼び出されたりすることができます。C++の名前マングリングや複雑なオブジェクトモデル(v-tables、例外、RTTI)は直接互換性がありません。通常、C++でC互換のラッパーレイヤーを作成してZigに機能を提供するか、その逆を行う必要があります。
-
std.mem.Allocatorをどこにでも渡すことによるパフォーマンスオーバーヘッドはどれくらいですか? オーバーヘッドはごくわずかです。std.mem.Allocatorは小さな構造体(ポインタとvtableポインタ)です。値渡しは効率的です。alloc/free呼び出しのためのvtableを介した間接参照は、単一のポインタ逆参照であり、最新のCPUとコンパイラによって高度に最適化されています。パフォーマンスへの影響は、実際の割り当て戦略によって支配され、渡し方によるものではありません。 -
Zigは組み込みシステム開発に適していますか? もちろんです。Zigの明示的なメモリ管理、ランタイムの欠如、および直接的なC ABI互換性により、組み込みシステムに最適な選択肢となります。ベアメタルをターゲットにでき、予測可能なメモリのために
FixedBufferAllocatorを使用し、既存のCドライバやライブラリと簡単に統合できます。そのcomptime機能は、リソースが限られた環境向けに強力なコンパイル時構成と最適化も可能にします。 -
Zigは並行性と並列性をどのように処理しますか? Zigは、OSスレッド用の
std.Threadや構造化並行性(コルーチン)用のasync/awaitなど、並行性のためのプリミティブを提供します。GoやRustのチャネルのような組み込みのメッセージパッシング並行性モデルはありません。共有メモリ並行性の場合、std.Threadによって提供される標準的な同期プリミティブ(ミューテックス、アトミック)を使用するか、Cライブラリを介して直接使用します。明示的なメモリモデルは、共有状態の管理とデータ競合の回避に完全に責任を負うことを意味します。
Free In-Browser Developer Tools
Clean AI CLI logs, build cron expressions, decode JWTs, and calculate chmod permissions offline.
Related Articles

Zigにおけるメモリ安全性
borrowcheckerやガーベージコレクタなしでZigのメモリ安全性を探求:手動アロケーション戦略、GPAトラッキング、comptime保証について解説します。
Read more
KubernetesにおけるLinuxcgroupsv2:PSI、メモリ制限、OOMシールド
KubernetesにおけるLinuxcgroupsv2のPSI(PressureStallInformation)、メモリ制限、OOMシールドについて、本番環境レベルのアーキテクチャとコード例を交えて解説する包括的なガイド。
Read more
WASI0.2とWebAssemblyComponentModel:言語非依存のマイクロサービスとWITインターフェース
WASI0.2とWebAssemblyComponentModelについて、言語非依存のマイクロサービスやWITインターフェースを、本番環境レベルのアーキテクチャとコード例で網羅的に解説する包括的なガイドです。
Read more