スタックオーバーフローのハンドリング (Stack Overflow Handling)
作成日：2004.04.12 更新日：2006.02.19 更新記録 (2004.04.12) 3/6、 3/11、 3/13 の日記をまとめて作成。 (2004.05.07) 文章を修正。サンプルコードを追加。 (2005.01.20) alternative → alterante に修正。 (2005.02.13) 追記を記述。 (2006.02.17) linux_stack_info.cpp の実装に誤りがあったので修正。 (2006.02.19) BSD 系OS でのスタック領域情報の取得の仕方を追加 初めに C/C++ でプログラムをしているとつい忘れてしまうのがスレッドのスタックオーバーフローの問題。 最近の OS はスレッド当たり 2〜8MB のスタック領域を持っているため、よほどのことがない限りスタックが溢れてしまうことはない。 だが、再帰や alloca を積極的に使
書き込み時に reader lock を取るテクニック - 兼雑記
昔、データを書く時に reader lock を取って、読み時に writer lock を取るワザがある、っていうのを聞いたのを覚えていて、詳細を忘れてたんですが、最近思い出す機会があったので書いておきます。 thread local storage を使って各スレッドにあるキャッシュなんかだと、当然読み書きする時にロックはいらないわけです。ただ、例えばダッシュボードの URL にアクセスされた時にキャッシュの使ってるメモリの総量が知りたいなど、 worker たちを管理しているスレッドが、各スレッドのキャッシュの状態全てにアクセスしたい、なんてことがあったりします。 こういう時に、普通に lock を取ってしまうと、 thread local storage を使って lock しなくて良いようにしてあるメリットが失われてしまう、と、そういう時に使うワザっぽいです。 具体的には、各 w
Cell/B.E. - w_o’s diary
ネットワークレイテンシ縮めるにはどうすればいいか考えてたときにひょっとしたら「CBEならできんじゃね？」とか思って、つまり、NICから直接SPEのLSに入れて、SPEからNICのレジスタ叩けば、DRAMのレイテンシも存在しないTCP/IPアプリケーションが作れるのではないかと思ったんですよね。 まあ、実験環境ないのでそう思った以上のことは無いけど… そのついでに、どのぐらいCBEがよく考えられていたか書いてもいいかなと思ったので書いておく。 (個人的に、Cellという表記/呼びかたはなんかあまり好きではなくて、Cell/B.E.もしくは、CBEと呼ぶので、以下、CBEはそういう意味で読んでほしい) はじめに CBEがあんまり普及しなかったとか、半導体業界の背景とか色々あって、多分新規アーキテクチャで世界制覇目指すとかやるのはCBEが最後になる可能性があるし(狭い部分では新規アーキテクチャと
あなとみー おぶ mrubyのJIT (その8) - miura1729の日記
かなり間が空いちゃいました。その間にmrubyのJITをコーティングしたりお祭りの資料を作ったりしていました。結構内容が変わって、例えばこれまで説明していたものがjit.cからvm.cに移ったりしています。そんなこんなで結構速度が上がって(多くがwannabe53さんのおかげ)、もうすぐオリジナルの2倍速くらいか(単純なループなら4倍くらいだけどメソッドコールが入ると速度が落ちる)というところまで来ています。 さて、今回はjitcode.ccの説明です。 const void * mrbjit_emit_code(mrb_state *mrb, mrbjit_vmstatus *status) { MRBJitCode *code = (MRBJitCode *)mrb->compile_info.code_base; const void *rc = mrbjit_emit_code_a
あなとみー おぶ mrubyのJIT (その7) - miura1729の日記
祝その7、前回(ytljitの型推論)も前々回(yarv2llvm)も第６回くらいで挫折したんだよな。まああいつらよりは説明しやすいのですが。 そういうことで、無事にかは知らんけど拡張asmを超えて続きを説明します。ちなみに、今やっているのはjit.cのmrbjit_dispatchです。前回２回使って70行くらいしか説明していなんだな。どうでもいいことだけど。 ネイティブコードを実行して、無事戻ってきたところからです。 irep = *status->irep; regs = *status->regs; n = ISEQ_OFFSET_OF(*ppc); if (irep->ilen < NO_INLINE_METHOD_LEN) { caller_pc = mrb->ci->pc; } else { caller_pc = NULL; mrb->compile_info.nest_l
あなとみー おぶ mrubyのJIT (その6) - miura1729の日記
かなり間があいちゃったけど、予告通りgccの拡張asmをつかったネイティブコードの呼び出し部分の説明を行います。gccの拡張asmはインラインアセンブラのくせに最適化して書いたコードのようにアセンブラを生成してくれないことがあるばかりか、変数が割り当てられたレジスタとかも警告なしで破壊してくれます。自分の足を撃つことができる言語っていうフレーズが良く使われていますが、血管や神経を避けて常に足に向けて撃つのが拡張asmです。 拡張asmは文法が複雑なんですが、さすがにこんなお化けを相手にする人は優秀な人が多くて(ここに例外がいるが・・・)、解説記事はどれも分かりやすいです。たとえば、これとか http://d.hatena.ne.jp/wocota/20090628/1246188338 それでは、具体的に解説していきます。拡張asmやX86の命令の説明をその都度行っていこうかと思います。ネ
Know yourengines velocity2011
1. Know Your Engines How to Make Your JavaScript Fast Dave Mandelin June 15, 2011 O’Reilly Velocity 2. 5 years of progress... 10 JavaScript 7.5 C run time vs. C 5 2.5 0 2006 2008 2011 one program on one popular browser: 10x faster! 3. ...lost in an instant! function f() { var sum = 0; for (var i = 0; i < N; ++i) { sum += i; } } function f() { eval(“”); var sum = 0; for (var i = 0; i < N; ++i) { su
2011-08-01 - valgrind 論文読んだメモ - 兼雑記
時々 valgrind はオーパーツだとかそういう主張をしてたりします。コードとか論文とかチラ見くらいはしてたのですが、まあちゃんと眺めてみたのでメモ。 Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation http://valgrind.org/docs/valgrind2007.pdf 1. イントロ 1.1 DBA and DBI Dynamic binary analysis って種類のツールがあるんですよ、と紹介。その手のツールは Dynamic binary instrumentation で実装されてることが多いですよ、と。つまり実行時にコード埋めるって話。 DBI ってのはすげー汎用性あるんですけどイマイチ注目されてなくてよろしくない、と。 1.2 Shadow Value Tools an
Intel® Implicit SPMD Program Compiler
An open-source compiler for high-performance SIMD programming on the CPU and GPU Overview ispc is a compiler for a variant of the C programming language, with extensions for "single program, multiple data" (SPMD) programming. Under the SPMD model, the programmer writes a program that generally appears to be a regular serial program, though the execution model is actually that a number of program i
maloader - a mach-o loader for linux - 兼雑記
https://github.com/shinh/maloader Linux で動く Mach-O loader を書いています。何ができるかというと、 Mac のバイナリが Linux でそれなりに動きます。今のところ、 gcc 、 otool 、 nm などの、いくつかのコマンドラインツールと、その gcc が生成した簡単なプログラムなんかが動きます。 Safari とか iTunes とかはもちろん動きませんし、動くようにしたいとも思ってないです。 仕組みとしては、引数に与えられた Mach-O バイナリを適当に読み込んで、指定された通りに mmap して、未定義なシンボルは linux の世界から探してきて再配置して、でエントリポイントに jmp する、と。まぁローダの説明そのまんまという感じです。 ローダはまぁ Mach-O のフォーマットが mach-o/loader.h か
Network Attached Processing の Pauseless GC
更新履歴 (2005.11.18) 脚注*2を加筆。 (2005.11.17) 文章を推敲。 (2005.11.14) NMT bit の read barrier について嘘を書いていたので修正。 目次 前置き Pauseless GC Marking Phase Relocation & Remap Phase おしまい 参考文献 Azul Sysmtes (米日) は Java や .NET に特化した専用計算機 Network Attached Processing (NAP) を提唱し、 製品として Azul Compute Appliance を開発した。 Azul Compute Appliance は、 すでに稼動中の Solaris/Linux の J2SE/J2EE システムの Java VM を Azul Systems が提供するスタブ JVM に置き換えるだけで、
メモリバリアを理解するために必要な3つのこと - yamasaのネタ帳
Togetter - 「メモリバリアとガチャピン先生」 上の話において、「メモリバリア」の意味するところをもう少し明確にすべきかなあと思ったので、簡単にまとめてみます。 「メモリバリア」が満たすべき性質は、以下の3つに分類することができます。 atomicity release/acquire fence sequential consistency これらの性質は、C++0xのmemory_orderと以下のように対応しています。 C++0x memory_order 持っている性質 memory_order_relaxed atomicity memory_order_acquire, memory_order_release, memory_order_acq_rel atomicity + release/acquire fence memory_order_seq_cst ato
ytljitの型推論の説明(その5) - miura1729の日記
今回は、collect_candidate_typeの説明です。candidateとは候補とかそういった意味です。つまり、そのノードの型になる候補(複数かもしれないし0かもしれない)を収集します。前回説明したとおり、この候補から型を選び出すのが、decide_type_onceです。 collect_candidate_typeは引数にcontextを１つとり*1、contextを返します。 collect_candidate_typeの中で別に何をしてもよいのですが、主に行うのは次の3つです。このうち最初の２つの操作については、すべてのノードのスーパークラスのBaseNodeクラスでメソッドが定義されているのでこれを使います。 型候補を加える(add_type) 他のノードと同じ型だよということを設定する(same_type) 他のノードに対して、 collect_candidate_t
X86-64 Instruction Encoding - OSDev Wiki
1: When any REX prefix is used, SPL, BPL, SIL and DIL are used. Otherwise, without any REX prefix AH, CH, DH and BH are used. Legacy Prefixes Each instruction can have up to four prefixes. Sometimes a prefix is required for the instruction while it loses it's original meaning (i.e. a 'mandatory prefix'). The following prefixes can be used, the order does not matter: Prefix group 1 0xF0: LOCK prefi
ytljitの型推論の説明(その4) - miura1729の日記
ytljitでao benchが動いたらruby-listにアナウンスするんだ！と決めているのですが、なかなか動かなくて苦労しています。 さて、型推論の説明の続きです。ytljitではYARVの命令列をノードと呼ぶオブジェクトのグラフ(VMと呼んでいる)に変換し、その後そのグラフをトラバースして機械語に変換します。ちょうどノードはYARVと機械語の中間くらいの命令に相当します。YARVや機械語のようにシーケンシャル(ジャンプはあるけど)ではなく、グラフ構造になっているのは型推論のためです。関連のあるノードを素早く(O(1)で)アクセスするためです。 型推論はこんな手順で行います データフロー解析を行ってデータの依存関係を調べる。例えば、ローカル変数の参照を表すノードなら、この変数に値を設定したノード(分岐やジャンプがあるので1つとは限らない)を集める 次のようなことを各ノードについて行う。
ytljitの型推論の説明(その3) - miura1729の日記
しつこいようですが、シグネチャーはメソッド呼び出しの際の引数を推論した結果の型オブジェクトの配列です。そして、型推論の際には必ずシグネチャが必要になります。 この2つのことから勘のいい人は気づくかも知れませんが(私はプログラムしてバグるまで気づかなかった)、シグネチャーを作るのにシグネチャーがいるのです。普通のメソッドだとそれほど問題ではないのですが、ブロック付きのメソッドの場合、シグネチャの型が一発で決まらないので、この辺の話が重くのしかかります。これが(その1)で書いたバグの根本の原因であろう(まだ取れてないので想像)と思うのですが、この辺はよくわかってないので分かったら書きます。 次にメソッドの引数の話をします。ytljitではユーザが指定する普通の引数のほかに隠れ引数を渡します。隠れ引数は現在のところ次の3つです(例外処理とかで増えるかもしれない)。 親のブロックまたはメソッドのフ
ytljitの型推論の説明(その2) - miura1729の日記
2回目はシグネチャーを作る話です。シグネチャーはメソッドの引数の型オブジェクトを配列でまとめたものです。型オブジェクトという未定義の言葉が出てきたので、これから説明します。 型オブジェクトはRubyのクラスをWrapしたオブジェクトです。型オブジェクトはBOXING/UNBOXINGの2種類があり、Rubyのクラスと独立して設定できます。つまり、BOXINGなFixnumもUNBOXINGなArrayなんてのも表現可能です。それぞれの型オブジェクトは、次のようなメソッドを持っていて、コード生成時にあんまり型による場合分けとかせずに、型推論の結果による最適化が出来るようになっています。 gen_boxing (BOX化するアセンブラコードを生成する) gen_unboxing (UNBOX化するアセンブラコードを生成する) gen_copy (そのクラスのデータをコピーするコードを生成する)
ytljitの型推論の説明(その1) - miura1729の日記
今、ytljitでうまく推論出来ないプログラムがあっていろいろ直しています。うまくいかないプログラムはこんな感じのものです。 def f yield end f { 1 + 1} f { "abc"} このバグの話の詳細を書くと訳わからなくなるし、詳細はどんどん変わっいるのでそれは書きません。その代り大元の考え方を書いて考えを整理します。つまり、自分のための日記です。 Rubyの型推論ということで余り型を厳しくしてしまうと使いにくくなってしまいます。ytljitのポリシーとして型によるプログラムの検証は一切無視、できるだけオリジナルのRubyのプログラムを受け入れるとします。そうすると例えば、こんな感じのプログラムは推論したいところです。 def id(x) x end id(1.0) id("abc") メソッド単位で型付けをすると考えるとidの戻り値の型は決められない(またはObjec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Exploits and defenses - Exploits and defenses
そろそろvolatileについて一言いっておくか - yamasaのネタ帳
