はてなブックマーク

G1GC 2012-09-14 www.narihiro.info i @yamaz @takahashim @alohakun Koichi Kimura Kohei Yashiro Koichiro Ohba @yukihiro_matz @kakutani @mnishikawa @tmpz84 @kiwanami @eitoball @tmaeda @nuna Anonymous @natsutan @sho_hashimoto @rane_hs @tmoro @suzumura_ss Kenta Murata @ryuone ii @littlestarling @kumagi @joenaha @LuckOfWise Anonymous @miura1729 Hiroshi SHIBATA Anonymous @takekazuomi Yuki Yuki @inuzini_ji

K&Rにのってたmalloc/freeを作ってみました。（約60分） 正気の沙汰とは思えないほど長いですね。反省。 まろっくはむずかしい #include <stdio.h> #include <stddef.h> #include <stdlib.h> /* K&R malloc Heap +--------------------------------------------------------------------- | alloc |header next ...........| allocated |header next.... | +--------------------------------------------------------------------- ^ +-----------------------------^ +-------------

第2章　オブジェクト管理機能 HotspotVMではさまざまなGCアルゴリズムを選択できる機能があります。Javaの起動オプションで「-XX:+UseParallelGC」などと指定するアレのことです。GCはそれぞれ管理するヒープの形状が異なり、また当然ですがGCアルゴリズム自体も異なります。本書ではHotspotVMのヒープやGCをまとめてオブジェクト管理機能と呼ぶこととし、本章ではオブジェクト管理機能の全体像を見ていきます。 2.1　オブジェクト管理機能のインタフェース 図2.1にオブジェクト管理機能のインタフェースイメージを示します。 オブジェクト管理機能はVMに対して主に次の3種類のインタフェースを公開します。 オブジェクトの割り当て 明示的なGCの実行 オブジェクトの位置や形状に依存した処理 1.は、VMがオブジェクトの種類を指定すると、VMヒープの内部に割り当てたオブジェクトの

本書はOpenJDK7のG1GCの実装と、それに関連する技術を解説します。 目次 スポンサーのみなさま はじめに 1.準備 2.オブジェクト管理機能 3.アロケータ 4.ヒープ構造 5.オブジェクト構造 6.HotspotVMのスレッド管理 7.スレッドの排他制御 8.GCスレッド（並列編） 9.GCスレッド（並行編） 10.並行マーキング 11.退避 12.予測とスケジューリング 13.正確なGCへの道 14.ライトバリアのコスト さらに勉強したい人へ その他参考文献 以下から（ある時点で）最新のebookをダウンロードできます。 徹底解剖「G1GC」実装編-20120915.epub 徹底解剖「G1GC」実装編-20120914.mobi 徹底解剖「G1GC」実装編-20120914.pdf 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ

原文 翻訳: 中村 成洋 Introduction Java言語の仕様はGCによって未使用領域を再利用することが規定されており、手動のメモリデアロケーションを禁止する。 GCは必要とされないオブジェクトを解放するという心配事からプログラマを解放する。 また、GCはいくらかの一般的なバグの発生を防ぐ、たとえばメモリリーク、ダングリング・ポインタのバグ、二重freeバグである。 GCは明瞭なアドバンテージを持つが、いくらかの問題も持っている。 もっとも重要な問題は、GCの実用的な実装（商用Javaランタイム）が大抵予測不能な「ポーズ」をコレクション時に伴うのである。 Javaプログラムのサイズと複雑さが拡大するにつれ、GCのポーズは、Javaソフトウェアアーキテクトのますます重要な問題となっている。 これを回避するためにエンタープライズJavaで広く使用されている技術は、プログラムを分散させる

原文1、 原文2、 原文3 更新 2011/02/27 fililさんからのご指摘でtypoを修正。TODO部分に対して、考えていただいた訳を反映。 更新 2011/02/14 miura1729さんからのご指摘で誤訳を修正 翻訳: 中村 成洋 SGenは、我々が2年間熱心に取り組み、ここ数ヶ月の間で安定性と十分な競争力を持ってきた、Monoの新しいGCです。 これからの一連のブログの記事として、このGCの一般的な働きと、特別な働き、どのようにしてこのGCがベストな性能をえられるかを紹介し、そして最後に未来のプランを説明します。 なぜ新しいGCなのか？ 多くのGC付きのランタイムのように、Monoは開発当時からBoehm-Demers-Weiser collectorを使っていた。以降、これをBoehmと略します。 Boehmの基本的な利点は移植性と安定性があり、楽に組み込むことができる点

原文 翻訳：中村 成洋 更新 2010/09/19 るとさんからのご指摘で誤訳を修正 更新 2010/09/18 nminoruさんと、Dominion525さんのご指摘で誤訳を修正 oopってなに？　なんで圧縮する必要があるの？ Hotspotの専門用語である「oop（ordinary object pointer:通常のオブジェクトポインタ）」はオブジェクトへの管理ポインタのことだ。 通常はネイティブなポインタサイズと同じになる。つまり、LP64の環境であれば64ビットになるということだ。 ILP32の環境では、最大ヒープサイズは4GBより幾分か少なくなる。これは多くのアプリケーションにとって不十分だ。 じゃあ、LP64の環境ではというと、ほとんどの場合のヒープは、対応するIPL32の環境と比べて約1.5倍になってしまう（どちらも同じ状況と仮定）。 管理ポインタのサイズが増大してしまう

K&Rにのってたmalloc/freeを作ってみました。（約60分） 正気の沙汰とは思えないほど長いですね。反省。 まろっくはむずかしい #include <stdio.h> #include <stddef.h> #include <stdlib.h> /* K&R malloc Heap +--------------------------------------------------------------------- | alloc |header next ...........| allocated |header next.... | +--------------------------------------------------------------------- ^ +-----------------------------^ +-------------

English

[PR] フロアコーティング (help authorNari) あほ������ ������やろう。 (show struct)

[PR] 蛹ｻ蟶ｫ縲�繧｢繝ｫ繝舌う繝� Ruby On Editor ﾎｲ # Let's shout "I Love Ruby" class RubyLover def initialize @authorNari = "http://d.hatena.ne.jp/authorNari/" end def shout_love_ruby puts "I Love Ruby" end end

[PR] 消費者金融　金利 サイトについて あとで読むver