Ahem, ahem... :) This is the most funny idea i've heard from a long time ago, it reminds me that when I was at age 12 I tought tat I cah compress sompressed file and then compress it again and again until I fit all my games on a single flopy disk :)
The compression is achieved because low information content (or highly correlated signal if you prefer) the loseless JPEG compresses photographic images (which are highly corelated data) at 10% in the best case. Apart from solving the problem how would you split the code in 8x8 pixels (as prescribed in the JPEG standard) the transformed signal will have approximately the same size. BTW both the fractal and JPEG compressions are used in their lossy variants which makes them inappropriate for code. The memory compresion is done mostly with loseles statistical algorithms like the good old Huffman. It gives you maximum ratio of 5. if you have 512MB dedicated for IDEA (in fact if you had it you wouldn't have the trouble) it means 1.5G "waiting buffer". Assuming that on my 256MB heap the garbage collections occur at least every hour, it would mean that the 1.5GB would sufice for approx 6 hours... so you have to go to the beach really often :) regards, dimiter =QUOTED============================================= Ahem... If you look at the source of Runtime.gc() (line 488) you'll see that it can be overridden. So, all that needs doing is to implement JPeg or Fractal decompression on the memory stack. In javart.dll (or its Linux equivalent - I think its called javalnx.so) the octal dump is : 017 AF02 00001100100100010001 018 AD02 0000100100701000!111 : which is the generic machine code for BITSET RAMPUSH So as long as memory is stored compressed (because it is just zeroes and one's remember) I see no problem deferring garbage collection until at least Tuesday. =END=QUOTED============================================= _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features
