訳注:この翻訳物は、TRGの許可無く私が勝手に日本語訳したものです。本内容に関してTRGなどに問い合わせることなどはご遠慮下さい。本内容の著作権等は当然TRGにあると考えられますので、引用などはお避け下さい。翻訳に際しては細心の注意を払っていますが、翻訳物の運用結果に責任を持つものではありません。翻訳に関するご質問・ご指摘などは、kterada@yokohama.kanagawa.toまでお願いします。

原文は、TRGのサイトにあります。本翻訳文は、98/3/12時点の原文を元に作成されています。

DeFragger FAQ (良くある質問)

目次

  1. DeFraggerの恩恵を受けられるのは誰ですか?
  2. メモリの断片化(fragmentation)とは何ですか?
  3. いつ、どのくらいの頻度でDeFraggerを実行すべきですか?
  4. yMFragとDeFraggerの違いは何ですか?
  5. なぜyMFragとDeFraggerは異なるヒープ値を示すのですか?
  6. 断片化解消の処理中に安全にそれを中断することはできますか?
  7. 断片化解消はせずに、単にメモリの状態を見るためだけにDeFraggerを使うことは出来ますか?
  8. 移動できないメモリチャンクとは?
  9. 移動不可またはロックされたメモリチャンクのために、DeFraggerをかけた後でもメモリが断片化しているということはありますか?
  10. DeFraggerをかけた後、詰め込まれたヒープの殆どは約1024 byte空きになっています。これはなぜ?
  11. DeFraggerをかけた後、多くのヒープは、"1024 空き、1018 最大チャンクサイズ"となります。これはなぜ?
  12. ロード可能なデータベースの数の上限はありますか?
  13. DeFraggerをかけた後で性能の向上は見られますか?

DeFraggerの恩恵を受けられるのは誰ですか?

全てのpilot/PalmPilotユーザはDeFraggerの恩恵にあずかることが出来ます。断片化は大容量メモリの際に起きやすい問題ですが、小さいメモリでも起きえます。


メモリの断片化(fragmentation)とは何ですか?

Doug DeVriesの文書を参照してください。


いつ、どのくらいの頻度でDeFraggerを実行すべきですか?

DeFraggerがメモリの断片化を解決したとしても、データベースを追加・削除するたびに、OSは残りのメモリを断片化するでしょう。ですから、時々DeFraggerを再実行することになるでしょう。特に、まだメモリがふんだんに余っているにも関わらず、OSやHotSyncがメモリ不足を表示した場合にです。メモリボードを完全にいっぱいにしてしまうためには、DeFraggerを4,5回走らせる必要があります。HotSyncが、メモリ不足によって毎回中断してしまう場合には、DeFraggerしてからHotSyncを動かしてみると良いです。


yMFragとDeFraggerの違いは何ですか?

yMFragは単に一つのヒープの中のメモリを詰め込み直すだけです。これは、メモリ断片化の部分的な解決でしかありません。一つのヒープ中の断片化は解決しますが、64Kのヒープ境界に起因する断片化は解決されません。一方、DeFraggerはヒープ間でメモリチャンクを移動し、ヒープ全体を割り当て可能にします。


なぜyMFragとDeFraggerは異なるヒープ値を示すのですか?

yMFragはRAMとROMの両方のヒープを表示しますが、両者を区別していません。yMFragは始めにRAMを、それからROMのヒープを表示します。DeFraggerはRAMのヒープのみを表示します。


断片化解消の処理中に安全にそれを中断することはできますか?

できます。DeFraggerを止めるためのボタンを叩くことで、プログラムはその時点で停止し、そしてpilotをリセットするためのボタンを叩くように要請してきます。ヒープはまだ部分的にいっぱいかもしれませんが、しかしそれ以外の問題は起きないでしょう。


移動できないメモリチャンクとは?

移動不可とマークされたり、またはOSによってロックされたメモリチャンクは、DeFraggerによって移動できません。また、HackMaster自身や、あなたがpilotにロードしたhackの類は、移動できません。これは、hackが有効になっていてもそうでなくても同じことです。


断片化解消はせずに、単にメモリの状態を見るためだけにDeFraggerを使うことは出来ますか?

できます。DeFraggerの初期画面は、すべてのRAMヒープに関するスクロール可能なリストになっています。


移動不可またはロックされたメモリチャンクのために、DeFraggerをかけた後でもメモリが断片化しているということはありますか?

OS自身が移動不可のメモリチャンクを必要とした場合は、断片化を最小にするために、有効なヒープのうち最上位のメモリが割り当てられます。けれども、Hackがヒープの真ん中に固定されていて、断片化の原因になることもありえます。このことが問題になるのは、hackが最後のヒープの真ん中をロックしていて、かつ他のすべてのヒープが完全にいっぱいである場合でしょう。そうだとしても、DeFraggerはすくなくとも他の一つのヒープを使用可能にしようとします。

メモリを完全に満タンに近づけようとすると、ロックされたチャンクによる隙間にできるごく小さいメモリチャンクばかりに制約されるようになります。


DeFraggerをかけた後、詰め込まれたヒープの殆どは約1024byte空きになっています。これはなぜ?

DeFraggerの初期の版は、ヒープを完全に詰め込んでいました。けれども、最初のいくつかのヒープが完全にいっぱいになっていると、OSが問題(バグ?特徴?異常?)を起こすのです。SuperPilotメモリボード上に2MB以上の空きがあるにも関わらず、680バイトのPRCファイルをロードできなかったのです。HotSyncのログファイルは、メモリ不足が起きたことが記録されていました。

OSは残してある1024バイトを使うでしょうから、しばらく後には、ヒープのいくつかが1024より少なくなっていることをDeFraggerで見ることができるのです。


DeFraggerをかけた後、多くのヒープは、"1024 空き、1018 最大チャンクサイズ"となります。これはなぜ?

メモリ上に割り当てられたチャンク(一つのレコードが一つのチャンクになります)はそれぞれ、6バイトのオーバヘッドを持っています。これは、OSがチャンクを管理することができるようにです。このオーバヘッドは、チャンクのサイズとか、そのチャンクが開放されたときにロックされていたり移動不可能かどうか、といった情報を含んでいます。


ロード可能なデータベースの数の上限はありますか?

このメモリシステムについて詳しくなってみると、そのような制限があるとは信じられません。データベースとメモリ管理とを結合してあるこのデータ構造は、データベースの数や、データベース中のレコードの数に関する制約を持っていません。起きうる問題として、断片化の問題があります。TRGにおいて、この問題を再現することは今までにできていません。300以上のデータベースをSuperPilotメモリボードに作成してみましたが、問題はありませんでした。


DeFraggerをかけた後で性能の向上は見られますか?

そのようなことはありません。沢山のデータベースをロードできることで、Pilotがかえって遅くなることはあるかもしれませんが。


Mike Walter
Copyright (C) TRG. All rights reserved.
Revised: March 12, 1998.

Copyright (C) 1998 Technology Resource Group

Last Updated: Mar. 12, 1998
mail to:TERADA, Koichi <kterada@yokohama.kanagawa.to>