JAVAとBREWのソース互換性について003

とりあえず今までの流れを整理しましょう。
　
JAVAとまったく同じ記述が可能なStringクラスは作りました。
しかし、newを頻繁に行なうため「BREWではnewに失敗した場合はエラー画面に移行しなければならない」がネックです。
　
そこで私が考えたのは「newに失敗したフレームだけ耐えられれば良い」→「1フレーム耐えられるだけのメモリーをあらかじめ確保しておく」というものでした。
　
とりあえずこの考え方自体は、それほどびっくりするものではありませんが、new失敗の呪縛からは一応解放されました。
ですがあらかじめ用意しておいたメモリーを超えてしまう可能性も無くはありません。
そこで次にメモリーコンパクションを考えてみましょう。
　
本当に凝ったものを作り始めると、いくら作っても足りません。
もう一度言いますが1フレームもちゃいいのです。
というわけでコンパクションは諦めます。えー!?
ですがdeleteされた部分の再利用くらいはしたいものです。
　
そこでnewする際に確保する量を、2の乗数に固定します。
おそらく2や4もいらないので。
8, 16, 32, 64, 128, 256, 512, 1024
くらいがあればいいでしょう。
例えば6バイトのnewが行なわれた場合、8バイト確保するようにします。
　
次に、各サイズについてdeleteが行なわれるたびにその履歴を保存します。
16履歴くらい保存できればいいでしょう。
つまり、128バイト領域のdeleteがあった場合、その位置を「128バイトdeleteアドレス履歴」に保存します。
その履歴に1つ以上履歴がある場合、次の128バイト領域のnewが起こった場合そちらを割り振るのです。
　
これでメモリーの再利用ができました。
一番心配だったStringの確保/解放の連続にも、これがあれば耐えられます。

str = "こんにちは";
str += "ぼくどらえもん";
str += "です";
　
なども、本来ならオブジェクトが何度も生成されてメモリーがもったいないお化けでしたが、上のシステムならメモリを使いまわしまくってくれるでしょう。
　
また、2の乗数に揃えてメモリー確保を行なうという設計は、副産物としてメモリー確保量を2の何乗かというBYTEで管理することができます。やっほー!!unsigned shortでとるより1バイトも減ったよ！
　
とりあえずこれでBREWのnew対策は一通りおしまいとします。
あとは実践します(`・ω・´)
　
＜ここから＞
実践後。
(((((((( ;゜Д゜)))))))
超馬鹿ぶっこいた。
JAVAでメソッド先にString渡すと、参照渡しじゃなくてコピーが生成されるのね。
ぅぉぉぉぉぉ……orz
Stringとプリミティブ型だけ、参照じゃなくてコピーが生成されるらしい。
もっと早く言えよ！ここの日記見てるJAVAプログラマーな友達よぉ！！
(´・ω・`)まぁnewとかはこのままで、String型だけ挙動変えるよママン。Object型を継承しなきゃいいのね。シクシクシク…。
　
素朴な疑問。なんでString型だけObjectを継承しているのに、わざわざコピーが生成されるの？
　
[追記]
修正完了ヽ(`Д´)ノむしろこっちのほうが機能追加時に書きやすくてトテモ(・∀・)イインチョ!!
負け惜しみm9(^Д^)プギャー
＜ここまで＞
[追記]
↑ここから〜ここまで　を無視してください。私の勘違いでした。