C++とJSを跨ぐ クロスコンポーネント ガベージコレクタ 服部慶士(keishi@chromium.org) 2021-08-31 https://bit.ly/3DzLRBs 1
なぜ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
どうも!@yokotaso です! 2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。 現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。 発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます! 発表資料は、speakerdeck にあります。はじまり〜はじまり〜 はじめに 今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。 現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。 さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。 次にShenandoahGC、ZGC、E
この記事でのバージョン Unity 2017.1.0f3 はじめに 今回は『Unite 2017 Tokyo』の講演の動画を見て、要点をまとめたり、追加で調べたり、 実際に手を動かしたりしながら、記事にもしちゃおうという感じの記事です。 そして、題材にする講演は、「最適化をする前に覚えておきたい技術」です! 講演者:黒河 優介(ユニティ・テクノロジーズ・ジャパン合同会社) こんな人におすすめ ・最適化したいが、何をしてよいかわからず困っている人 ・効率的に最適化を行いたい人 受講者が得られる知見 ・Unity Profilerに関するノウハウ ・最適化の目算、見積もりをする技術 目次 はじめに 目次 最適化とは 最適化の手順 Profilerの基本的な使い方 メモリの使用量が多い場合 メモリリーク メモリ使用量が多いのはC#?Unity? Unityのメモリ使用量が多い場合 C#のメモリ使
2017.02.17JavaScriptで起こるメモリリークのパターン2014年1月25日に Frontrend in Fukuoka というイベントが開催された(もう3年前か…)。その時に Browser Computing Structure というタイトルで、ブラウザの仕組みやらスクリプト処理について発表している。 たまたま当時の資料を掘り起こす機会があったので、メモリリークのサンプルを直したついでにリークする JavaScript のパターンについて書き起こしてみる。サンプルは 1000ch/memory-leak に公開してあり、手順通り操作するとメモリリークを再現できるようになっている。 GCで回収されないオブジェクトJavaScript はランタイム上で動的にメモリを確保する GC(ガベージコレクション)を採用しているので、JavaScript の書き手がメモリの確保・開放を
(編注:誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか? もしできるならどうやって?」 このブログ記事ではGoのガベージコレクタを、どのように機能し(トリコロールアルゴリズム)、なぜ機能し(こんなに短いGCによる一時停止時間の実現)、そして何よりも、それが機能するのかどうか(GCによる
こんにちは。Aiming エンジニアの久保田です。 僕の携わっているプロジェクトでは、近頃、Unity製クライアントのパフォーマンスの調査や改善を行っている最中です。 プロファイラを眺めていると、僕達が書くアプリケーションレイヤのコードが目立って遅い、ということは珍しいのですが、代わりにC#世界のスパイクとしてよく顔を出すのが、GC実行時間です。 C#は、タイプセーフでありながら人間にやさしく、getter/setter、async/await、Rx、ロケットなラムダ式、他他他…最新型の言語への影響も多大な、ファッション的にも◎な言語です。しかし、闇雲に全ての機能をタダで……というわけにはいかず、ことパフォーマンス面においては、GCというなかなか高い代償を支払うことになりかねないわけですね。 結論としては、UnityのGCは、皆が期待していたほど高性能ではなく、現状では僕達が書くC#が発生
DA88 luôn là điểm đến mà bất kỳ cược thủ nào cũng muốn lựa chọn để tận hưởng trải nghiệm tốt nhất. Bạn sẽ có cơ hội tiếp cận nhiều loại hình giải trí hấp dẫn và các dịch vụ tiện ích. Nội dung cập nhật bên dưới đây về địa chỉ sẽ giúp bạn có thêm thông tin trước khi quyết định đăng ký. Cách Thức Liên Hệ Tổng Đài DA88 Cực Nhanh Và Chi TiếtChính Sách Bảo Mật DA88 Đang Áp Dụng Với Mọi Cược ThủChơi game
クックパッドの社員が発表するCookpad TechConfというイベントの第一回が今日行われ、「Railsアプリ開発環境の高速化」というテーマで話してきた。 開発環境の改善について 僕が技術部に入る前、サービス開発をやる中で一番不満だったのが開発環境のパフォーマンスだったので、技術部に配属されたころからこの仕事をやりたいと思っていた。 今回は先輩方が既に行っていた開発環境のパフォーマンスチューニング - クックパッド開発者ブログの一部を紹介しつつ、その続きとして自分がやってきたことを発表した。 業務で出した成果のうちいままで外部で発表したのはbyebugの高速化くらいだったので、普段僕がどんな仕事をやっているのか紹介する良い機会になった。 発表内容の補足 思ったより15分の枠で話せたことが少なかったので、発表内で話し足りなかったことについて書く。 libsassおすすめです 急いでて全然
横浜Android and モバイルOS プラットフォーム部で発表した資料です。 資料はAndroidアプリ開発者をターゲットにまとめました。OutofMemoryErrorの発生原理とメモリ管理について最新事情を加味してまとめました(新版、なのはAndroid 1.xのころの発表が古いのにまだ参照されていたりで、さすがに最新事情に合わせて更新したかったのです)。 Androidアプリにおけるメモリ事情は(初期に比べたら)改善していますが、OpenCVなど画像処理の需要、高解像度対応を踏まえると依然として十分とは言いがたいユースケースもあります。そんな中でメモリ資源をうまく使うための指標となれば幸いです。 資料にもある通り書きかけの状態ですのでコメントやmentionなど「こんな情報があるから書き加えて」「ここ調べて」「こういうのがおすすめ」「ここ間違えてる!」というご意見いただければ嬉し
プログラムの実行時イメージ 突然だが、本章を始めるに先立ち、プログラム実行時のメモリ空間の状態につ いて予習をしておこうと思う。この章ではコンピュータの低レベルな部分にか なり踏み込んでいくことになるので、あらかじめある程度の知識を仕入れてお かないと太刀打ちできないのだ。それにこの後の章になればいずれ必要になっ てくる。ここで一回やってしまえば後が楽だ。 セグメント 一般的なCプログラムではメモリ空間の中に以下の部分を持つ。 テキスト領域 スタティック変数やグローバル変数の置場 マシンスタック ヒープ テキスト領域はコードが置いてあるところ。二番目は見ての通り。マシンスタッ クには関数の引数やローカル変数が積まれる。ヒープはmalloc()で割り当てて もらうところだ。 三つめのマシンスタックについてもう少し話そう。マシン「スタック」と言う くらいだから当然スタック構造をしている。つまり
Vous pouvez dès à présent lui associer un hébergement, en choisissant la solution la plus adaptée à vos besoins : Hébergement Web Une solution économique pour héberger vos projets Web : site Internet, boutique en ligne, landing page... En savoir plus VPS Alliez la flexibilité du Cloud à la liberté du dédié avec nos solutions VPS clef en main. Accompagnez vos projets Web vers une nouvelle étape. En
参照方法によってメモリの解放タイミングが異なる Android ではオブジェクトがヒープ領域にたまりメモリ不足が生じたとき、 ガベージコレクション(GC) が起動して不要なオブジェクトのメモリを開放してくれます。 実装コードではすべてのオブジェクトを手動で開放する必要はなく、基本的には GC の挙動に任せることでメモリ圧迫を軽減できます。特に「不要なオブジェクト」という点が重要で、GC はオブジェクトの参照状態を見て不要かどうか判断します。 参照方法にはいくつか種類があります。通常の参照方法は強参照と呼ばれますが、そのほかにソフト参照(SoftReference)や弱参照(WeakReference)と呼ばれる参照方法があります。これらの参照方法によって GC でメモリから開放されるタイミングが異なるというわけです。 ということで今回は SoftReference と WeakRefere
Android、いかがですか。 今日もOut Of Memory、出していますでしょうか。 そんなあなたに朗報です。 少しでもメモリにやさしいプログラムを。 今日はSoftReferenceのお話です。 トレードオフ Androidで(というよりもJavaで)パフォーマンスに最も影響を与えるのはインスタンス生成の部分ではないでしょうか。 ループの中でインスタンスを生成しようものなら、たちまちあなたのUIは機敏さを失うことになるでしょう。 インスタンス生成はGCの源です。ストップザワールドを少しでも避けるためには極力newなどは控えなければなりません。 となると、インスタンスを作らないことが究極なのですが、全く作らないというわけにはいきません。ならば、一度作ったインスタンスは再利用しようではありませんか。 その時に役に立つのがキャッシュです。一度作ったインスタンスはキャッシュに保持し
そういえば C++ のヘッダファイルを #include するだけで使える GC を書きました。使い方は下のサンプルコードを見てもらえばいいとして、特徴としては、 ヘッダファイルを #include するだけで使える C++ の標準機能だけを使っているのでポータブル*1 mark-and-sweep, precise GC ってなあたりでしょうか。コードは GitHub - kazuho/picogc: a tiny, portable, precise, mark-and-sweep GC in C++ にあります。 C++ のプロジェクトで、ちょっとここだけは GC がほしいんだけど、ってなケースで使いやすいと思います。速度も、そこそこでるんじゃないかな*2。 というわけで、以下、サンプルコード。軽く説明しておくと、 GC を使うクラスは picogc::gc_object を継承する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く