YamaKen
yamak****@bp*****
2006年 4月 19日 (水) 00:45:07 JST
ヤマケンです。 今日も逃げ水のようなゴールを目指してr5rsブランチをさまよってます。 At Mon, 17 Apr 2006 18:11:56 -0700, jun.l****@gmail***** wrote: > Macro の bug を潰し終わったので compaction に手をつけたんですが、 > performance と hackability の二面で不満があります。改造しようとしたん > ですが、変更箇所が広すぎるので書き直しました。 そろそろ何とかしないといけなくなってきてたんで助かります。trunk に移すまでには少なくとも保守性を確保したいんで。 ざっとソースを読ませてもらいましたが、第三者がいじれるレベルに収 まっていると思うし、現状のstorage-compact.hに手を入れるより楽に sigscheme/TODOの項目を達成できそうな感じなので、これへの挿し替え を支持しておきます。 とりあえず試行錯誤中はlog書かないでもいいんでcommitしてもらえま すか? 細かいバグとか直したいし。現在のstorage-compact.hとは別名 でしばらく併存させながらいじりましょう。 以下個別にコメントしますが、引用すらしてない部分は議論の余地なく 賛成と取ってください。 > (2) 関連部分が散らばっている > > これは fatty にも言えることですが、小さな変更をするにも変更箇所が沢山 > あり、全てを把握 & 確実に変更 + coherency を確保するのは大変です。実際、 > macro を実装するにあたって型を二つ追加しようとしただけなのに、 > > -構造体を追加 > -検索+移動 > -MAKE_* を追加 > -検索+移動 > -Accessor を追加 実験段階ならここらあたりで適当に端折っとくのがいいと思います。 こんなんでどうでしょう。 storage-fatty.h: inline ScmObj MAKE_HOGE(fuga, hoga) { return hoge(fuga, hoga); } > -別 file に移動 > -SAL_ のついてないものを追加 > -別 file に移動 > -make_* を書く > -別 file に移動 > -gc に追加 > -code を書いてみると、違う構成を試したくなりました。あるいは収拾がつか > なくなってきたので svn revert で reset したくなりました。 > 振出に戻る×4回 (実話) > > と実に長々と単調で error-prone な作業をするはめになりました。まず > compile を通すまで集中力が続きません。ていうか LISP 系の define を吐け > る macro が欲しくてたまりません。 > > 一月以上だらだらと進展せずにやってたのは、まあ macro の semantics が鬼 > のように tricky なのが主因ですが、この面倒臭さにかなりやる気を削がれた > のも事実です。試行錯誤に時間がかかりすぎ。 > > GC と make_* がバラけるのは仕方ありませんが、他はなるべく関係のある > code を密に集合させて、大局的な構造と局所的な調整を区切るべきです。 > SAL_ もやっぱり無駄だと思います。特にこれだけ冗長に prefix を付けてい > るなら。 冗長なprefixというのがcompact内の名前を指すなら、それはSALを使う 側の層には関係のない話です。 SALの目的は今後も新たな実装が現れる予定になっているストレージ層 の安全な分離と挿し替えにあるので、インタフェイスを明確に規定する 必要があります。SAL_プリフィクス付きのマクロを無くしたとしてもこ の規定は文書等によって為される必要があり、さらに機械的なチェック ができなくなるのでストレージ実装者もlibsscmユーザも間違いを起こ す可能性が高まります。これらの点から見て、現状のSAL_プリフィクス 付きのマクロによるAPI規定層を一段噛ませた方が開発・保守コストが 低くなると考えています。 > (3) 初期化と終期化(?) 専用に macro が欲しい > > Finalization を header に放りこむのは (2) によります。初期化のときも、 > 置いて良い仮定が既に初期化された object と食い違う可能性があるので > packaging しておきたいところです。Code size も低減できますし。それから > ENTYPE() を減らせます。即値には init も fin も作らない方が賢明に思われ > ます。 ENTYPEを無くしてくれると私も嬉しいです。SALで規定してはいますが、 いずれ廃止したいと思って非公開としてsigschemeinternal.hの方に置 いたはずだし、storage-compact.hにも即値は直接生成しようよとコメ ントしてあります。storage.cのコード共有はむしろ減らした方が compactとfattyの双方に嬉しいと思います。 しかしfinalizationの分離は嬉しいですか? 現状のfree_cell()を見る 限り、GC視点で集約してある方がコンパクトで読みやすいように思うし、 ほとんど追加される機会のない新オブジェクトタイプのコードの書きや すさより、GC全体の切口での保守しやすさの方が重要と思います。 オブジェクト側のタイプ毎に責任を集約したいという気持ちはわかりま すが。 > (5) やっぱ名前長すぎ (略) > SCM_IMM_TAG_NULL > (Tag というよりは object 全体) ここは私が一番気になってたとこです([Anthy-dev 2776])。実態と合わ ない名前は保守を難しくするので。 > (6) Terminology 整理 > > 言い出しっぺの私が用語を明確に定義しなかったのが原因で名前が ad-hoc だっ > たりわかりにくかったりする箇所がありますね。とりあえず > > S & 6 → primary tag (ptag) > S->y についてる tag → miscellaneous tag (mtag) level 1〜3 > 即値とその種類を示す tag → immediate tag (itag) > itag の内、特に何の種類の即値かを示す部分 → immediate type ID (immid) > > としてみたんですがどんなもんでしょう。特に others は > context-independent な理解が困難なので変えた方がいいと思います。 tagの区分については視認性・意味的なわかりやすさとも大変良いと思 います。特にmiscはいい選択ですね。 個々の操作ではピンとこない名前もありましたが、デザインの根幹では ないので当面は井上さんが分かりやすければそれでいいと思います。 > (7) 即値型への破壊的操作 > > 無い方が良いと思います。Compact か fatty かで動作が変わってしまい、怪 > しい bug の温床になります (siod に debug 機能をつけたときに経験済み)。 INT_SET_VALUE()とかの事なら私も賛成です。MAKE_INTで置き換えて問 題ないでしょう。 私からの希望としては、[Anthy-dev 2532]とstorage-compact.hの SCM_INT_MSB付近のコメントに書いたように、元の実装ではstringや vectorのlengthがintegerより無駄に広かったり符号ビットが未使用だっ たりすところを最適化して欲しいです。 あとは細かい点をいくつか。 - SCM_STRIP_TAG_INFO()はSCM_STRIP_TAG()の方が誤解がなくて良い * 例えば、対になっているSCM_UNTAGGEDP()には'INFO'が含まれていない - #define SCM_STRIP_PTR(o) ((ScmCell*)SCM_STRIP_TAG_INFO(o)) * 直感的におかしい。ポインタの方が捨てられるように感じる * 実際、SCM_STRIP_TAG_INFO()は同じ名前構造でTAGの方を捨ててい るので一貫性がない * せめてSCM_STRIPPED_PTR()とか? - #if SCM_GCBIT_UNMARKED /* Marked words are never dereferenced. */ * 名前と論理が逆のように見える * コメント無しでも理解できるぐらい自明な名前が欲しい。 SCM_NO_MARKED_OBJ_DEREFERENCEとか? -#define SCM_IMMP(o) SCM_PTAG((o), SCM_PTAG_IMM) +#define SCM_IMMP(o) SCM_PTAG_EQ((o), SCM_PTAG_IMM) ------------------------------- ヤマケン yamak****@bp*****
