System Software

9月30日更新

このページでは最新のシステムソフトウェアに関する話題を扱っていきます。

ホームページに戻る


System 7.5.5の話題

System 7.5.5での改善点

  1. Virttual Memoryの性能改善
  2. Type11エラーの減少
  3. DOSコンパチビリティーカードを挿したときのフロッピーディスクの信頼性向上(Windowsが起動している時にFDを挿入すると問題が発生していた)
  4. PCI PowerMac、PowerPC PowerBookでハードディスクにアクセスした際起きることがあったフリーズの解消。
  5. 仮想記憶の利用中にEthernetで大きなファイルを送る際にエラーが発生していたことの解消。
  6. Apple TV TunerまたはMacintoshTVで、リモコンを使ってチャンネル・ボリュームを素早く操作すると機能しなくなることの解消。
  7. LocalTalkの性能向上
  8. バックグラウンドオンリーのプログラムが2つ以上走っているときの安定性向上
  9. ネットワークで共有されているプリンタへのアクセス時の安定性向上
  10. 180MHz以上のクロックのマシンでの起動・FD初期化の信頼性向上
  11. Performa5400, 6400でEthernet Cardを使用した際の信頼性向上
  12. サウンド機能を多用するプログラムを、PowerPCカードを載せたQuadra, Centris上で走らせた際の信頼性向上


System 7.5.5の改善点を技術レベルから見ると

Code Fragment Manager

仮想記憶がオフのとき、Shared Libraryの"private copy"をロードする際に、テンポラリメモリ・システムヒープに空きがない場合はこれをアプリケーションヒープ中の空き領域にロードする。このアクションでもsizeリソースで指定したminimumメモリパーティションサイズとactualメモリパーティションサイズの差以上にメモリを使うことはない。

この機能によって、今までであれば起動できなかった条件でアプリケーションを起動できるようになった。

コードフラグメントをメモリにロードするときはFile Systemのキャッシュをバイパスしている。またBlockMoveDataルーチンを多用することも行っている。これらによってアプリケーションの起動が速くなっている。

Modern Memory Manager

内部のローカル変数をsigned longからunsigned longに変更した。このため、アプリケーションが負の数でメモリをアロケートしようとするとModern Memory ManagerはType11エラーを出すようになった。

Background-only Application (Process Manager)

以前のシステムでは2つ以上のバックグラウンドオンリーアプリケーションが共にMaxApplZoneルーチンを呼ぶとProcess Managerはこれらのプロセスの状態を正しくセーブできず、システムがハングしてしまっていた。

このバグはバックグラウンドオンリーアプリケーションの概念が導入されてからこの方ずっと存在していたが、System 7.5.5でようやく除去された。

Floppy Drive & Async I/O

PowerMac 6100/7100/8100のROMにはフロッピーディスクが入った状態で非同期ファイル動作があるとマシンがハングするバグがあった。これはこのROMがFile Systemについての実験中にFinalizeされたため、内部にいくつかの不適切なルーチンがあったのが原因である。

System 7.5.5ではROMの当該ルーチンにパッチを当てることでこの問題を回避している。

180MHz越のマシンでのフロッピー初期化

以前「System 7.5.3の問題点」としてこの問題にふれた際、PCI Bridgeチップの初期化不良が原因と書いたが、実際は別の原因であった。

Macintoshがフロッピーを初期化する際にはフロッピー初期化ルーチンによって作業を行っているが、180MHz超マシンではこのコードが速く実行されすぎるために、フロッピーの表面から裏面へ移る時の待ち時間が足りず、裏面がフォーマットされないまま終了してしまっていた。

System 7.5.5では、この待ち時間タイミングを調整することでフロッピー初期化の不具合を解消している。

PCI PowerMac, PB5300, PB2300の68Kエミュレータ

存在しない領域のメモリをフラッシュしようとしていた。この状態になると、エミュレータは無限ループに陥ってしまった。

System 7.5.5ではレンジチェックを行い、不当な領域をフラッシュしようとした際には動作をキャンセルし、呼び出し元へ抜けられるようにした。

PCI PowerMac, PB5300, PB2300でのFile Managerの動作

File Managerでも存在しないメモリ領域のフラッシュを試みていた。このため前項と同様にエミュレータが無限ループに陥っていた。

Ethernet on Performa 5400/6400

内部で特定のパケットに高すぎるプライオリティを与えていたため、プライオリティの低いパケットのパケット落ちが発生し、低速な通信しかできなかった。

System 7.5.5ではこの問題を解決している。

180MHz超のマシンでの起動時ハング

クロックが180MHzを越えるPCI PowerMacで起動時にPCI Bridge Chipの初期化に失敗することがあった。この状態になるとPCIバスは起動中からアクセス不能になり、最終的にはマシン全体がハングする結果になった。

System7.5.5では起動時のPCI Bridge Chipの初期化方法を一層信頼性のある方法に変更したため、この問題は解消した。



System 7.5.5で入れ替わったファイル

筆者の環境(PowerMac 9500)では次のファイルが更新された。
System
System 7.5.2updateファイルがなくなり、全てのリソースがSystemファイルに統合された。
Mouseコントロールパネル
PowerBook系のマシンでのトラックパッドでの不具合の修正に関連したものと思われる。
Energy Saver Extension, Eneger Saverコントロールパネル
新しい2.0.2コントロールパネルからは"Energy Star"ロゴが外された。
Startup Tuner
System内で起動時の問題を解消する対策がとられているようで、このファイルは消滅した。
Serial(Built-in)
Ver1.2に変更になった。



Finderのメモリ不足について

コントロールパネルなどを開くときにFinderがメモリ不足に陥ることがある。これはPowerMac 7500/8500/9500の機種でサードパーティ製のコントロールパネルを開くときによく起こる問題である。コントロールパネルのコンパイル時にMathLibをリンクしているとこの問題が発生する。

コントロールパネル(以下cdevと呼称)はFinderのアプリケーションヒープ内にロードされる。MathLibをリンクしたcdevがロードされると、Finderのヒープにはcdev本体の他にMathLibによって生成されたMathLib globals (22Kバイト)もロードされる。FinderヒープにはROM内のMathLibによって生成されたMathLib globalが既に置かれているが、以前のマシンであれば、こちらのMathLib globalsは2Kと小さかったので、全てを合計してもFinderのパージ可能なヒープ領域サイズに収まっていた。

ところがPowerMac 7500/8500/9500ではROM内MathLibによってアロケートされるMathLib globsも22Kバイトの大きさを持っているので、cdevによってもたらされたMathLib globsと合わさるとFinderのヒープをほとんど全て使い切ってしまう。このような状況に陥ると、Finderは度々メモリ不足の警告を表示することになる。

解決策は、Finderのsizeリソースに手を加えて、Finderの使用メモリを増やすことである。



なぜSystem7.5.5ではアプリケーションに23Kバイト余計にメモリが必要なのか

これはSystem7.5.5で新しいMathLibが使われるようになったからである。おそらくPCIマックで導入されたMathLibの発展したものがシステムに標準で含まれるようになったのであろう。(23KというサイズからMath globalの件に容易に想像が及ぶ。)

新しいMathLibでは若干数学関数のパフォーマンスが向上しているという。



インストール中に"optimizing system for speed"というメッセージを表示して裏で何をやっているのか?(笑)

Syste 7.5.5 updateによってSysteファイルにインストールされたリソースの中には、圧縮されたものがあり、このメッセージが表示されている間にそのようなリソースを解凍しているのである。「スピードに最適化」というのは、実行時に圧縮されたリソースを解凍しながら実行したのではパフォーマンスが落ちるから、という意味なのであろう。




OpenTransport1.1.1b7

改善点・変更点


現在明らかになっている問題点


OpenTransport TCP/IPの動作

TCP/IPアプリケーションが起動すると、アプリケーションに続いてOpenTransportの内部モジュール「TCP/IPスタック」がアプリケーションヒープにロードされる。TCP/IPアプリケーションが稼働中はこのモジュールがメモリ内に留まり、TCP/IPプロトコルでのデータ入出力を受け持つ。

全てのTCP/IPアプリケーションがQuitすると、TCP/IPスタックは2分間TCP/IPストリームを監視し、その間TCP/IPストリームがなければこのモジュールはメモリ上からUnloadされる。

古いバージョンのOpenTransportでは、このときモジュール全体が完全にUnloadされず、メモリリークを発生していた。これは1.1.1b6以降ある程度改善されている。

TCP/IPコントロールパネルでユーザーモードを"Advanced"以上に設定すると、コントロールパネルウィンドウに"Options..."というボタンが現れるが、ここで"Load only when needed"というチェックボックスをアンチェックしておくと、TCP/IPスタックは起動時にアプリケーションヒープに読み込まれ、TCP/IPアプリケーションの起動とは無関係にメモリ内に常駐する。この方法にしておくと何度もTCP/IPスタックが異なったアドレスにロードされることがないので、メモリリークの被害を局所的な領域に封じ込めることができる。完全にメモリリークの問題が解決するまでこの設定を用いることをお薦めする。


System 7.5.3 の不具合


ホームページに戻る