soundness や decidability といった性質と計算オーダーが重要な分野から、ベンチマークで速ければ勝ち・なおベンチマーク結果はプラットフォーム毎に変わるぞみたいな分野への移行、結構ギャップがあっておもろい

なんかいっぱい図は溢れてるし、こうやったら速くなりそうみたいなアイデアも溢れてるんだが、実際の実装テクニックは溢れてない

メモリ管理、GC よりまず先に考えることが色々あるのだが、その知見があまり巷に転がってない (探し方が悪いのかもしれない)

メモリ管理初心者なので、初めての GC 実装でめっちゃ知見を得ている

Twitter がヘイトの溜まり場になって問題と言われるが、じゃあ Mastodon / Bluesky がそれを解決してるかって言われると微妙なとこだよな。つまりヘイトの溜まり場になることを一般ユーザが望んでおり、単に敷居が高くてそういうユーザが流れ込んできてないのが今の Mastodon / Bluesky だったとしたら、そもそも色々根底がアレだし

技術屋としては、技術でどのように解決するかを考えがちだけど、技術で解決できることなのかを本来考えるべきなのよなとは思う。思うが、まあ技術で解決できると思った方が色々楽しいのはそう

Bluesky は招待コードが届かないのでまだ見ぬエデンって感じ

これすき

なんとなくで Mastodon 管理をやってるので、キャッシュとメディアの違いもわからない

tootctl 分からなすぎ

アイコンが死んでる人のアイコンを復活させる方法 [検索]
#マストドン管理部

このテクニックは malloc 併用にも一役買ってるらしい。つまり、fixed size の細切れ object 置く arena はこの予約した領域で管理し、後は必要になったら mmap で領域足せば良いわけか

> A note about virtual memory
> This guide has largely focused on the physical memory use of the GC, but a question that comes up regularly is what exactly that means and how it compares to virtual memory (typically presented in programs like top as "VSS").
https://tip.golang.org/doc/gc-guide#A_note_about_virtual_memory
#miteru #Golang

cgoとunsafeについてのメモ
https://hnakamur.github.io/blog/2019/12/29/cgo-and-unsafe/
#miteru #Golang

まあ、まさかメモリ容量が短期間でここまで膨れ上がるとは誰も思わんよ

system allocator だけで事が足りてた時代 (というか分割できるほどのメモリがなかった) にできた API だからな

> Interaction with the system malloc
> It is usually best not to mix garbage-collected allocation with the system malloc-free. If you do, you need to be careful not to store pointers to the garbage-collected heap in memory allocated with the system malloc.
https://www.hboehm.info/gc/simple_example.html

感覚的にはそんな感じがしていたが、世の中の allocator はやっぱ基本的には併用は考えられておらず、持ってても non-management heap 発行する機能ぐらいみたいな状況なのかな？

Cloudflare が死んだら、諸々の情報発信が死ぬ感じになった

Rust、めちゃくちゃなんとなくコンパイラに言われた通り書いてるが、自分で何書いてるのかよく分からない (圧倒的知見不足)

まあ、最近の malloc だとあんまりそういうことないのかな？

allocator 独自実装ってそもそもするものなんかな？まあでもしたいよな、malloc で適当に配置されてせっかく fragmentation 対策したのに malloc 側で fragmentation 起きても微妙だし

どうにもよく分からんので、質問してみた
https://prog-lang-sys-ja.zulipchat.com/#narrow/stream/343525-.E8.B3.AA.E5.95.8F/topic/allocator.20.E7.8B.AC.E8.87.AA.E5.AE.9F.E8.A3.85.E3.81.A8.20malloc/near/361682620
> 最近メモリ管理と GC について勉強し始めて、かなり初心者の状態で右も左も分からないという感じなのですが、GC でヒープ管理をする場合 libc malloc に頼らず allocator 独自実装したい場合も多いと思うのですが、その場合 libc malloc との併用は考えない場合が多いのでしょうか？またその場合、malloc がもしよばれてしまった場合のケアなどをするデファクトの方法などはあるのでしょうか？

そもそも malloc & free span が短い arena において、GC marking bit だけ局所化したところで局所化とは？って感じやしな

巷には、bitmap marking で変更を局所化できて嬉しいとかいう記事が出回ってるわけだけど、それいうための前提条件めっちゃ多いよね？という感じだ

当たり前のことだが、Allocator がないと Vec / Box とかも気軽には使えないわけだ

Rust で no std 縛り、めんどくさくなったので malloc 実装は諦め

Glibc malloc internal
https://www.slideshare.net/kosaki55tea/glibc-malloc
#miteru