Go 1.20リリース連載が始まります＆メモリアリーナの紹介＆落ち穂拾い | フューチャー技術ブログ
しかし、これでもリファレンスは表示されず、パッケージドキュメントしか表示されません。 この機能はオプトインで動くもので、ビルドの時に環境変数が必要だったことを思い出し、これを指定するとようやく見れました！機能はシンプルですね。 ちなみに、これを書く時にまったく違う同名のライブラリを見て、ふむふむと読んでいたのですが、本家の方は検索では出てこないのでみなさまもお気をつけください。 使い方はシンプルですね。 まずは arena.NewArena()で*Arenaを作成 使い終わったら Free()メソッドを呼び出す arena.MakeSlice[Type](arena)やarena.New[Type](arena)といった関数を使ってアリーナ内部のメモリを利用 arena.Clone(obj)を使うと、アリーナが終了しても残るよう、ヒープに値を移動する(浅いコピー) Goはメソッドのジェネリ
GoのGC (garbage collector)について理解する
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
［速報］Java 13が登場。ZGCの改善やSwitch式の実現など新機能。 Oracle Code One 2019 － Publickey
2017年9月に登場したJava 9以降、Javaは6カ月ごとに「フィーチャーリリース」と呼ばれるメジャーアップデートが行われています。Java 13は、今年3月に登場したJava 12に続くメジャーアップデートです。 Java 13のおもな新機能は、Application Class-Data Sharing機能を拡張した「Dynamic CDS Archives（JEP 350）」、ZGCガベージコレクタを改善し使われていないヒープメモリを返却する「ZGC: Uncommit Unused Memory（JEP 351）」、Project Loomの一部として既存のSocket APIを再実装した「Reimplement the Legacy Socket API（JEP 353）」、Switch式を可能にする「Switch Expressions（JEP 354）」（プレビュー）、J
Python 3.8 では空dictが小さくなる - Qiita
Python 3.7 では {} で作った空 dict よりも、 dict.clear() で作った空 dict の方が省メモリでした。 >>> import sys >>> d = {} >>> sys.getsizeof(d) 240 >>> d.clear() >>> sys.getsizeof(d) 72 これは dict オブジェクトを新規作成するときに最小サイズのハッシュテーブルを確保し初期化するのに対して、 dict.clear() は shared key dict の仕組みを使って空 dict 専用の共有テーブル（書き込み禁止）を利用しているからです。 空の dict の数は無視できないくらいにはあるので、Python 3.8 で新規に dict オブジェクトを作るときも dict.clear() の結果と同じ共有領域を使うようにしました。 なお Python 3.7 の
Go言語のGCについて - LINE ENGINEERING
なぜGo言語はコンパクションを採用していないのか GoogleのRick Hudson氏によるISMM 2018 Keynote “Getting To Go”を参照すると、以下のことがわかります。 2014年の時点では”Read barrier free concurrent copying GC”を計画していた しかし期間的な制約から断念し、CMSに舵を切った（この時期に彼らは、ランタイムをCからGoに書き換える作業も行う必要がありました。Changes to the runtime） TCMallocをベースとしたメモリアロケーターを採用することで、断片化およびアロケーションの速度の問題を解決した Go言語のメモリアロケーションについては、ランタイムのコードのコメントにも詳しく記載されています。 malloc.go This was originally based on tcmal
Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
How to optimize garbage collection in Go
After publishing \\[a post about why we chose Go for CockroachDB](https://www.cockroachlabs.com/blog/why-go-was-the-right-choice-for-cockroachdb/), we received questions about how we deal with some of Go’s known issues — especially those related to performance, garbage collection, and deadlocks. In this post, we’ll share a few powerful optimizations that mitigate many of the performance problems c
GolangのGCを追う
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された．この変更について「ちゃんと」理解するため，アルゴリズムレベルでGoのGCについて追ってみた． まずGoのGCの現状をパフォーマンス（レイテンシ）の観点からまとめる．次に具体的なアルゴリズムについて，そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する． GoのGCの今 最初にGoのGCの最近の流れ（2016年5月まで）をまとめる． Go1.4までは単純なStop The World（STW）GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された．導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった．Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた． 以下は公開されているベンチマーク．まずはGo1.5を見る． Gophe
Go 1.6 will Make its Garbage Collector Faster
The InfoQ Trends Reports 2023 eMag The InfoQ trends reports provide a snapshot of emerging software technology and ideas. We create the reports and accompanying graphs to aid software engineers and architects in evaluating what trends may help them design and build better software. Our editorial teams also use them to help focus our content on innovator and early adopter trends.
java.lang.OutOfMemoryError: GC overhead limit exceeded - Develop with pleasure!
Javaなエンジニアであればお馴染みのOutOfMemoryError。 こないだ単体テストを全件流してたら途中で java.lang.OutOfMemoryError: GC overhead limit exceeded が発生。お馴染みのOutOfMemoryErrorかと思ったけどメッセージに「GC overhead limit exceeded」とある。 いつもの「Java heap space」とかいうメッセージじゃないので気になって調べてみる。 この「GC overhead limit exceeded 」は、HotSpot VMの1.6からデフォルトで有効になったポリシーで、ヒープ領域が不足する前に早期に潜在的なOutOfMemoryErrorの検出するために導入された模様。このポリシーはGCの経過時間と頻度が基準になってて、経過時間が長かったり頻繁にFull GCが発生す
Pythonの粗大ゴミ - atsuoishimoto's diary
なんかgcネタが続いてしまうが、先日のPython Hack-a-thon で発表した中で、「ジェネレータオブジェクトが解放されない場合がある」というのは、あまり知られていないようだ。Python公式ドキュメントを確認してみると、どうやらこちらにも書かれていない。知らないとハマってしまう場合もあるので、もうちょっと詳しく解説しておこう。 ガベージコレクションで解放されないオブジェクト まず、ちょっと復習しておこう。Pythonのガベージコレクション機構では、__del__() メソッドを持ったオブジェクトで循環参照を作ってしまうと、そのオブジェクトは自動的には解放されなくなってしまう。 例えば、次のように __del__() メソッドを持つクラスを定義する。 class UnCollectable: "__del__()メソッド付きクラス" def __del__(self): print
Pythonのガベージコレクタは「マーク&スイープ」？ - atsuoishimoto's diary
昨日公開した Pythonのガベージコレクション にこんな突っ込みをいただいた。 マークアンドスイープGCじゃないそうです PythonのGarbageCollection http://www.narihiro.info/translate/garbage_collection_for_python_jp.html 確かに、Pythonで使用しているのは教科書で言うマーク&スイープとは異なるアルゴリズムである。上記のページにあるように、いわゆるマーク&スイープは、ルートオブジェクトと呼ばれる生きていることが確実なオブジェクトを見つけ出し、そこから参照されているオブジェクトをどんどん探り出して、最終的に誰からも参照されていないオブジェクトをあぶり出すというものだ。Pythonではルートからオブジェクトを探すというアプローチを取っておらず、私も会場の説明では「マークアンドスイープの一種」のよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The OMR GC talk - Ruby Kaigi 2015