<cough> From: "Dimiter" <[EMAIL PROTECTED]>
> 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 :) Ah those were the days! You belittle yourself to right off these childhood imaginings! Perhaps if a floppy disk had fallen on your head while you were taking a bath, you would have had the appropriate epiphany. Of course you are constrained in your example by singularity of media (only floppy disks), but a plethora of options abound in our case. See below... > 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. I use JPeg and fractal compression merely as stepping stones to provoke a more lateral approach. Consider the elements that we are storing in memory (at the simplest level we have code and data segments) We simply identify the data elements as having either lossy or lossless storage requirements, and handle them appropriately. In either case depending on the frequency of access requirements, data segment elements could sometimes be stored to disk rather than memory. (Why waste memory on what are predominately static entities anyway?) As far as compressing code using lossy methods goes, consider using CRC back checking to derive the original code from the lossy decompressed version. In other words use lossy compresion on the code and include well-engineered CRCs (or similar code cracking devices) to act as hints for resolving the losses encountered during decompression. i.e. the combination of lossy code with CRC hints are applied to an algorithm that iteratively adjusts the code until the original CRC is attained, and voila!, lossless code. > 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". As stated before alg(lossy(code) + hints + crc) = lossless(code) This approach, I expect, goes beyond the scope of this list, but does serve to illustrate how we seem to spend a lot of time trying to squeeze the contents of a pear shaped swimming pool into a leaky red bucket, simply because we don't have a tropical beach at our disposal. > 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 :) This is not a bad thing, and waterproof laptops that can be mounted on bodyboards will no doubt soon be more popular than portable mp4 palm players and their ilk. They screwed up the material for my mantle. Its looks more like sackcloth than anything I've seen at the royal drapiers. And for some reason they have shaven my head. Oh these Spanish and there inauguration rituals! WPE Madrid Februias 33.3 LP MONO PS. What with all our noses being on the moon, is it any wonder nobody wants to wake up and smell the coffee. > > =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
