Jun Inoue
jun.l****@gmail*****
2006年 4月 19日 (水) 08:52:37 JST
YamaKen <yamak****@bp*****> writes: > ヤマケンです。 > 今日も逃げ水のようなゴールを目指してr5rsブランチをさまよってます。 今日もですか。 > とりあえず試行錯誤中はlog書かないでもいいんでcommitしてもらえま > すか? 細かいバグとか直したいし。現在のstorage-compact.hとは別名 > でしばらく併存させながらいじりましょう。 (済) >> (2) 関連部分が散らばっている >> >> これは fatty にも言えることですが、小さな変更をするにも変更箇所が沢山 >> あり、全てを把握 & 確実に変更 + coherency を確保するのは大変です。実際、 >> macro を実装するにあたって型を二つ追加しようとしただけなのに、 >> >> -構造体を追加 >> -検索+移動 >> -MAKE_* を追加 >> -検索+移動 >> -Accessor を追加 > > 実験段階ならここらあたりで適当に端折っとくのがいいと思います。 > こんなんでどうでしょう。 > > storage-fatty.h: > inline ScmObj > MAKE_HOGE(fuga, hoga) > { > return hoge(fuga, hoga); > } んー、どういう意味かよくわかりません。私が問題にしてるのは、移動が必要 以上に多い (一緒に変更する部分が離れてる→見通しが悪い+面倒) という点 であって、MAKE_* とか個別の interface がどう実装されてるかという話では 無いんですが。 >> GC と make_* がバラけるのは仕方ありませんが、他はなるべく関係のある >> code を密に集合させて、大局的な構造と局所的な調整を区切るべきです。 >> SAL_ もやっぱり無駄だと思います。特にこれだけ冗長に prefix を付けてい >> るなら。 > > 冗長なprefixというのがcompact内の名前を指すなら、それはSALを使う > 側の層には関係のない話です。 Prefix は compact/fatty 内の名前の事です。Fatty では内部 local な名前 があんまりありませんが。 > SALの目的は今後も新たな実装が現れる予定になっているストレージ層 > の安全な分離と挿し替えにあるので、インタフェイスを明確に規定する > 必要があります。SAL_プリフィクス付きのマクロを無くしたとしてもこ > の規定は文書等によって為される必要があり、さらに機械的なチェック > ができなくなるのでストレージ実装者もlibsscmユーザも間違いを起こ > す可能性が高まります。これらの点から見て、現状のSAL_プリフィクス > 付きのマクロによるAPI規定層を一段噛ませた方が開発・保守コストが > 低くなると考えています。 あれ? Interface は MAKE_* + accessors + INIT() [ + FIN()?] + MARK/UNMARK ぐらいでほぼ固定だと思ったんですが。それに変更を加えること になったとしても、機械的なチェックが活躍する…その、まあ、機会、…がど ういうものか思いつきません。例えばある user が storage-a にある非公開 API の FOO() を使ってたとして、FOO() を実装してない storage-b に config option で変更したとしましょう。SAL_ が噛ませてあろうがなかろう が、cpp は文句を言います。逆に、SAL_ がある事によって FOO() の使用を阻 止することもできません。BAR() が SAL_BAR() と定義されてても BAR() と定 義されてても FOO() は外から見えますし。 冗長な prefixing について言ったのはこのためです。FOO() が MTAG_FOO()、 ましてや OTHERS_CAR_FOO() だったら明らかに scheme level の概念ではない ものが混じってるので、公開でないことはわかりそうなものです。 一方 SAL_ があると試行錯誤の自由が縛られます (こっちは OK ですよね?)。 SAL_ を設けることが文書での API 定義をサボる理由になるわけでもないし、 新しい設計を書くにしてもどうせ文書を基本に書くことになるので、特に SAL_ をつけとく merit が見えんのです。 > しかしfinalizationの分離は嬉しいですか? 現状のfree_cell()を見る > 限り、GC視点で集約してある方がコンパクトで読みやすいように思うし、 > ほとんど追加される機会のない新オブジェクトタイプのコードの書きや > すさより、GC全体の切口での保守しやすさの方が重要と思います。 私も aesthetically は別に嬉しかないです。でも面倒事がありまして。 Compile が通るまで修正していくのが嫌なので確認取ってませんが、accessor assert を有効にして今の storage-compact.h で GC を走らせると assertion faiure が出ませんか? Sweep 時には ptag のついてない pointer しかないの で、assert を諦めるか別の accessor を使うことになります。それの為だけ に ad-hoc な accessor をバラバラと置くよりは目的がわかりやすい fin() にまとめた方がいいかと判断したんです。その結果 BY_PTR のような気持ち悪 い層ができあがってしまってるわけですが。 ;; 「失敗」箇所の一つ。何か良い方法無いすかね。 > 個々の操作ではピンとこない名前もありましたが、デザインの根幹では > ないので当面は井上さんが分かりやすければそれでいいと思います。 どのへんでしょうか。とりあえず今のところわかってもらう気が薄いものは _BY_PTR() と CELL_ の関係ぐらいなんですが。あ、↓STRIP_TAG() とかの事 かな。 > 私からの希望としては、[Anthy-dev 2532]とstorage-compact.hの > SCM_INT_MSB付近のコメントに書いたように、元の実装ではstringや > vectorのlengthがintegerより無駄に広かったり符号ビットが未使用だっ > たりすところを最適化して欲しいです。 えーっと、MSB を mutable flag にするという話ですか。(Integer より広い というのはよくわかりませんが…。Integer は 32-4 bits, string / vector-length も mutable flag を考えると 32-4 bits でピッタリ合います。) MSB を mut(ry flag にすると mutability test は速くなりますが、長さを取 得する度に unmask が入るので、LEN() に 0x7FFF... の load が追加されま す。 それに対して下の方に置いておくと、mut(ry test した後 >> 1 で長さが取得 できます。長さだけを取るときの penalty は 0 です。Mut(ry は test する けど長さは取得しない場面というのをちょっと思いつかないので、下の方に置 いた方が得かなーと思いました。 > - 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()とか? > -#define SCM_IMMP(o) SCM_PTAG((o), SCM_PTAG_IMM) > +#define SCM_IMMP(o) SCM_PTAG_EQ((o), SCM_PTAG_IMM) いずれもその通り。直しときました。 > - #if SCM_GCBIT_UNMARKED /* Marked words are never dereferenced. */ > * 名前と論理が逆のように見える > * コメント無しでも理解できるぐらい自明な名前が欲しい。 > SCM_NO_MARKED_OBJ_DEREFERENCEとか? この comment は内容解説では無くて妥当性の説明です。Commit した方のを見 てください。 ;; あー、SCM_GCBIT_UNMARKED の位置がおかしいな。後で修正。
