アカウント名:
パスワード:
とりあえず、現在最もよく用いられているelfの場合。
elfの場合、shared objectにはversion numberという概念はありません(確かa.outではld.soの動作に意味を持つversion numberが存在した)。その代りに、major version number(executable作成時とruntimeで一致していなければならない)をheaderに埋め込むことによってversion controlを実現しています。
major version numberは、dynamic sectionのSONAMEに保存されます。gnu binutilsの場合、objdump(1)で確認できます。
silver% objdump -x /usr/lib/libc.so.5 | head -n 20 (snip) Dynamic Sec
最近はprocessを使うのもずいぶん楽になりました。risc-based workstationを使い慣れていない人は全く知らないと思いますが(私もついこの前初めて知った)、実はaddress spaceの切り換えというのはprocessorの工夫によってある程度安く済むようになっています。典型はSPARC V9上のSolaris 2で、kernel address spaceにprocess address spaceを全くmapしません。もともとはkernel address spaceを増やす事が目的でしたが、system callのた
今となっては、processを使うことをためらわせるぐらいaddress spaceの切り替えが高くつくのはIntelぐらいでしょうねぇ...
virtual address spaceが使えるprocessorには、virtual address spaceの各pageをphysical memoryのpageに変換する(対応するphysical pageが存在しないこともある)表を持っています。この表は通常memory上にあるのですが、実際にはそれをaddress参照の度に読んでいるとprocessorの実行がmemory busの帯域にboundしてしまいます。そこで、通常は表の一部をcacheに持っておきます。これがTLB(Translation Lookaside Buffer)です。
Intelのprocessorでは、一度に1つの変換表しか使うことができません。また、TLBはvirtual address spaceを切り換えた時に全て無効化されてしまいます。これはTLB miss(注目しているvirtual addressがTLBに見つからない場合のcache miss)を増加させる原因になります。UltraSPARC IおよびIIではaddress space identifier(実体は8bitの数値)によってaddress spaceに名前をつけ、address space全体を切り換えることなく複数のaddress spaceを使い分けることが可能です。TLBがそのまま使えるので、kernel address spaceからuser process address spaceへのデータ転送などで不必要なTLB missを防ぐことができます。
Intelだとaddress変換表のcacheがムダになってしまうことが多いが、SPARCはその心配がないというぐらいの意味です。実際、TLBに入っている情報というのは変換表の一部をコピーしたものなので。
補足ですが、TLBは変換表のコピーに過ぎないので、TLB missが生じたらtrapを発生してOSにTLBの補充を行わせるという考え方もあります。MIPSやUltraSPARCのようにriscの血を引き継いでいるprocessorではどちらかというとこの発想が普通です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
ライブラリの更新時にもメリット? (スコア:3, 参考になる)
普通は
鵜呑みにしてみる?
Re:ライブラリの更新時にもメリット? (スコア:1)
多くのソフトウェアで使われているライブラリに障害が見つかった場合、
稼働中のシステムでは全部 make し直すというのは
かなり厳しい作業でしょうから、そういった意味でも
dynamic link になるのはいいことですよね。
ただ、今度はライブラリの下位互換性の問題が生まれるのでしょうが……
.NET Framework では、共有アセンブリのバージョン管理に工夫をしているようで
サイドバイサイド実行 [microsoft.com]なんていうものもできるそうなのですが、
Unix の .so はどうなっているのでしょう。
よく、
/usr/local/lib/libVFlib2.so -> li
elf shared objectの場合 (スコア:3, 参考になる)
とりあえず、現在最もよく用いられているelfの場合。
elfの場合、shared objectにはversion numberという概念はありません(確かa.outではld.soの動作に意味を持つversion numberが存在した)。その代りに、major version number(executable作成時とruntimeで一致していなければならない)をheaderに埋め込むことによってversion controlを実現しています。
major version numberは、dynamic sectionのSONAMEに保存されます。gnu binutilsの場合、objdump(1)で確認できます。
silver% objdump -x /usr/lib/libc.so.5 | head -n 20
(snip)
Dynamic Sec
Re:elf shared objectの場合 (スコア:1)
.NETも、unixみたいに、「processを」たて続けに起動する
なんて使い方をするんだろうか?とか、一瞬思って
Re:elf shared objectの場合 (スコア:0, 余計なもの)
最近はprocessを使うのもずいぶん楽になりました。risc-based workstationを使い慣れていない人は全く知らないと思いますが(私もついこの前初めて知った)、実はaddress spaceの切り換えというのはprocessorの工夫によってある程度安く済むようになっています。典型はSPARC V9上のSolaris 2で、kernel address spaceにprocess address spaceを全くmapしません。もともとはkernel address spaceを増やす事が目的でしたが、system callのた
Re:elf shared objectの場合 (スコア:0)
IntelとUltraSPARCのaddress space (スコア:2, 参考になる)
virtual address spaceが使えるprocessorには、virtual address spaceの各pageをphysical memoryのpageに変換する(対応するphysical pageが存在しないこともある)表を持っています。この表は通常memory上にあるのですが、実際にはそれをaddress参照の度に読んでいるとprocessorの実行がmemory busの帯域にboundしてしまいます。そこで、通常は表の一部をcacheに持っておきます。これがTLB(Translation Lookaside Buffer)です。
Intelのprocessorでは、一度に1つの変換表しか使うことができません。また、TLBはvirtual address spaceを切り換えた時に全て無効化されてしまいます。これはTLB miss(注目しているvirtual addressがTLBに見つからない場合のcache miss)を増加させる原因になります。UltraSPARC IおよびIIではaddress space identifier(実体は8bitの数値)によってaddress spaceに名前をつけ、address space全体を切り換えることなく複数のaddress spaceを使い分けることが可能です。TLBがそのまま使えるので、kernel address spaceからuser process address spaceへのデータ転送などで不必要なTLB missを防ぐことができます。
Re:IntelとUltraSPARCのaddress space (スコア:0)
要は CS 等が切り替わったときに読み込まれる descripter table
の情報が i386 系統ではあんまりキャッシュされないけど
Sparc ならキャッシュされる、ということですか?
それともその descripter table が指し示す先のリニアアドレスの
page directory がキャッシュされない、ってことですか?
Re:IntelとUltraSPARCのaddress space (スコア:1)
Intelだとaddress変換表のcacheがムダになってしまうことが多いが、SPARCはその心配がないというぐらいの意味です。実際、TLBに入っている情報というのは変換表の一部をコピーしたものなので。
補足ですが、TLBは変換表のコピーに過ぎないので、TLB missが生じたらtrapを発生してOSにTLBの補充を行わせるという考え方もあります。MIPSやUltraSPARCのようにriscの血を引き継いでいるprocessorではどちらかというとこの発想が普通です。