«前の日(02-06) 最新 次の日(02-08)» 追記

Matzにっき


2004年02月07日

_ [言語]新(?)GC手法

いつまでも引っ張ってもしょうがないので、公開。

材料

  • KSMのGC手法。生成したオブジェクトをテーブル(registry)に登録することで、 Cスタックをスキャンしないconservative GCを実現
  • write barrier。木山くんの世代別GCで実現されている
  • single thread下でのCスタックのスキャン。Rubyをはじめ多くの実装がある。

作り方

  • あるスレッドで生成したオブジェクトは全部スレッドごとのテーブル(registry)に登録
  • ヒープから参照されたオブジェクトにはwrite barrierでマークをつける
  • テーブルがいっぱいになるかフリーリストが空になるとminor GC。
    • ローカル変数とCスタックから参照されているオブジェクトに(上記とは別の)マークをつける(再帰しない)
    • テーブルをスキャンして、ヒープからの参照マークも、ローカルからの参照マークも付いてないものはゴミ。回収。
  • minor GCで回収したオブジェクトが十分になかったりすると、major GC。 たぶん全スレッドを止めてmark and sweep。 あるいはdirty bitを使ったconcurrentなものにする余地もあるが、そこまですることはないかなと。

multi thread環境では、minor GCがスレッド独立で行うことができるので、性能が期待できる。 single thread環境では、minor GCでは全オブジェクトをスキャンしないので、live objectが多くても性能が期待できる。

問題は、minor GCで回収できるのはヒープから参照されたことがないオブジェクトだけなので、 あまりに保守的過ぎて性能向上が十分でないかもしれないということ。いくら非再帰で軽いからと言っても、 あまり頻繁に行われては意味がない。実際に実装してみないとなあ。

なお、yarvメーリングリストで、富士通研の中村さんらの「動的に割付け戦略を最適化するJavaメモリ管理機構」(情報処理学会 トランザクション 「プログラミング」 アブストラクト Vol.44 No.SIG13 - 002)が似てるということを教えてもらいました。

別に真似したわけではありませんが、完全に独創的というものを作り出すのは難しいものです。 ってtraitの時にも似たようなことを書いたような。ヒープを別に持たない点などはちょっと独自かも。

なお、このアイディアはそのうち論文にする予定です。だが、まず実装しないとな。 いつになるやら。


2005年02月07日

_ [映画] ペイチェック 消された記憶

ペイチェック 消された記憶 [DVD](フィリップ・K・ディック/ディーン・ジョーガリス)

具合が悪くて出かける気にもなれなかったので、数日前にレンタルしておいた映画を見る。

...これは面白い。伏線がぴたりと決まるのも満足感があるし、 アクションも十分だ。そうか、ジョン・ウー監督か。 原作はP. K. Dickか。短編が原作なのも成功の理由かもしれない。 長編が原作だとどうしても尺に収まらない(ので説明不足になる)ことが多いから。

あえて気に入らなかった点をあげると、

  • 「マシン」の動作原理の解説が陳腐。 たぶん、原作のままなんだろうけど、もう21世紀なんだから通用しないだろう。 ここはばっさり削っても良かったのでは。
  • 「鳩」の登場の仕方がわざとらしすぎ。監督の「サイン」なのはわかったから、 もうちょっと自然にするわけにはいかんのだろうか。いかんのだろうな。

ハンサムでアクションもこなせるエンジニアにリアリティがない、なんてことは この際問題にしないことにしよう。

4点(5点満点)。

昼間休みすぎて、夜寝られなかったので、20のアイテムを使った順序で思い出してみる。 なかなか頭の体操になる。


2006年02月07日

_ [原稿] 日経Linux

「オープンソースマガジン」と「るびま」はほぼ完了。「るびま」の原稿はshiroさんからチェックをもらって、事実誤認に気がつく。公開前に気づいてよかった。

それに対して「日経Linux」は難産である。分量が多い(OSMは2ページ、るびまも紙なら2ページくらいなのに対して、日経Linuxは8ページ) のもあるが、内容が難しい。編集の人からも「やや難しめなのでもうちょっとやさしく」と注文を受けたばかりというのに。

で、例によって泥縄ではあるが、改めて継承について勉強する。 Webを見ると、私が『オブジェクト指向スクリプト言語』に書いた言葉が独り歩きしているのを発見する。

古い番組の言葉を借りれば「継承は最後の武器だ」ということでしょうか。

これをもって、私が継承を使わないようにと言っているかのように読んだページ(たいていは古いものだが)いくつもあった。実際にはそのすぐ後には

結局は使うんですけど。:-)

とあるのは無視らしい。また、

...無理して継承を使う必要はありません。 is a 関係に対してだけ継承を使うべきでしょう。継承関係はスーパークラスの内部構造にまでアクセスできる依存度の高い関係であることを忘れないでください。

とも書いたんだけどなあ。

あと、多重継承についても否定的に書いたように読まれている。古い文章ではあるが、ちゃんと読んでもらうってのは難しいなあ。

_ 日本国民全員にプログラマになってほしい

Windowsの新しいプラットフォームについて語る、マイクロソフト執行役 デベロッパー&プラットフォーム統括本部長の鈴木 協一郎氏。

−マイクロソフトはVisual Studio Express Editionを,1年間の限定ながら無償配布しました。その目的はどこにあるのでしょうか。

私は日本国民全員にプログラマになってほしいと考えています。今以上にソフトウエア開発業界が発展するために,新しい才能がこの業界に入ってきてほしいと思っています。少しでもソフトウエア開発に興味を持っている人たちに対して道具を無償提供することで,この分野に入ってくるきっかけを作りたいと考えています。

私も国民全員がプログラマになってほしいと思っている。 Visual Studio Express Editionの無償提供がどれくらい有効かはわからないけど。


2007年02月07日

_ 朝食

同じ朝食。今日はウェイターが「なににする?」と聞いてきた。 「目玉焼きとベーコン」を注文。そうか、これがFull American Breakfastの正体か。

_ ITOCHU Technology

視察に全面的に協力してくれているCTCさんの計らいで ITOCHU Technologyのオフィスを訪問。

移動中のバスの中ではずっと寝ているので、 訪問先の位置関係とかが全然わからない。

シリコンバレーについていろいろと学ぶ。 ここが非常に特異な場所であることがよくわかる。 そんな場所が日本のどこに生まれるだろうか...無理かな。

アメリカのVCの1/3がここにあるのだそうだ。 また、ドットコムバブルの影響もほぼ抜けているとか。 確かにグラフを見る限り投資額は前の水準に戻りつつあるように見える。

ミーティング終了後、お弁当をご馳走してもらったのだが、 和食弁当であった。ちゃんとご飯とみそ汁も付いている。 が、やっぱりサイズはアメリカンであった。

おなか一杯。

_ JETRO BIC

JETROのSan Joneオフィスへ。 Business Innovation Centerといって、 シリコンバレーに進出したい人に(十分な審査の上)オフィスを貸したり、 ビジネス展開を支援したりするのだそうだ。

最近は大変盛況で、 今年だけで過去5年間と同じくらいの数の会社を支援したとか。

またまたシリコンバレーの特異性とか住みやすさについて、熱く語られる。 ちょっとビジネス色が濃くて、(さっきとは別の意味で)おなか一杯。

その後、ちょっとだけ観光してから夕食へ。

_ 観光

観光した場所

  • Apple本社。

    なにをするかというと、Apple Storeで買い物という。 ここぞとばかりにいろいろ買ってる人もいた。マカーおそるべし。

  • Stanford University

    もうかなり暗かったのだが、ちょっと離れたところに塔が見えた。 「これはSather Towerか」と一生懸命写真を撮ったのだが、 どうも違うTower(Hoover Tower)らしい。 っていうか、そもそもSather TowerはBerkeleyなのか。勘違い。

_ 寿司

で、夕食に連れられていったら寿司屋(Fuki-Sushi)だった。

着いたら、Tim BrayとCharles Nutterもいた。Sunの人がアレンジしてくださったらしい。 ありがたい。

で、日本食を食べながら日本や日本文化について語った。 この二人はRubyKaigiにも来ると言ってた。今回はインターナショナルだな。

この店の日本食は大変おいしかった。 日本語も通じるし(中には日本人顔してるのに通じない人もいたけど)。

でも、量が多い。とても多い。

_ [原稿] 日経Linux 2007年4月号

だいたい出張中に三本も原稿を引き受けちゃうのはどうかしてると思う。 っていうか、前からわかってるんだから、せめてその内の何本かは あらかじめ書いておくとかできないものなんだろうか。

毎月同じ愚痴を書いてるってことはできないってことなんだろうな。

日経Linux 2007年4月号はAJAXについての後編。

前回はAJAXの概要とJavaScript言語についての説明で終わってしまったので、 今回は実際にAJAXなアプリを作ってみることにする。

しかし、HTMLだけである程度の動作するブラウザアプリが書けるってのは 面白いもんだよね。ちょっとデバッグが大変だけど。 これでFirebugがなかったらと思うとちょっとクラクラする。

IEでバグが出たら泣くしかないよな。

_ [言語] Liskell - the language

S式でHaskell。

個人的にはHaskell(オフサイド)文法のLispがほしいかも。 その場合はHaspか。


2008年02月07日

_ microBlog >> Bounties for bug fixers: a bug-tracker plugin

バグを直してもらうためにバグトラッカー(Trac)に懸賞金機能を追加するプラグイン、 Fund-a-bugについて。

以前、このようなものを夢想したことがある身としては、 大変興味深い。ただ、多くのオープンソースプロジェクトは 無償の奉仕だからこそ動機が維持できている側面もあるようで、 このようにお金が絡んだ時に、それがプラスに働くばかりではないように思う。

Rubyでも似たような仕組みを導入して (私以外の)開発者がおこづかいを稼げるようになったら どうなるだろう。喜ぶ?

それともやる気がなくなる?

その辺は実際にやってみないとわからないわけで、 そういう意味でも Fund-a-bugの今後の 動向に関心がある。

_ Years of irrelevance - (37signals)

Rails作者DHHのコラム。 「よく経験何年って言うけど基本的に無意味だよね」という話。

新しい技術を学ぶ過程で学習曲線ってのは(曲線ってぐらいだから)、 線形にまっすぐ伸びることはなく、ある程度まで急激に伸びてから その後は停滞する傾向がある。DHHの経験だとサチるまでの期間は だいたい半年から1年ってところか。

だとすると、求人などでよく見かける「経験n年」はnが2以上の時に無意味だろう。 単に経験が長い人材よりは、むしろ新しい技術をより短い時間で身につける 「活きのいい」人材の方がよっぽど価値がある。

「一生勉強」というような職人ならともかく、IT技術に関して年数を問うのは馬鹿らしい。

もっとも、Ruby経験10年以上の技術者となれば、それはそれで欲しい人材ではあるが。 Rails経験10年以上という技術者がいたら追い返すけど。


«前の日(02-06) 最新 次の日(02-08)» 追記