Windows 7 and all my Java stuff.
in [Java Programming]
|
From: Lew on 23 Nov 2009 20:42 Roedy Green wrote: > In my own code, Strings and arrays of pointers to Strings would be the > most common ram hog. Your code would probably benefit greatly from the '-XX:+UseCompressedOops' option in a 64-bit environment, then. -- Lew
From: Nigel Wade on 24 Nov 2009 04:12 On Mon, 23 Nov 2009 10:14:32 -0800, Roedy Green wrote: > On 23 Nov 2009 13:54:01 GMT, Thomas Pornin <pornin(a)bolet.org> wrote, > quoted or indirectly quoted someone who said : > >>most of the memory used in a >>typical application is for non-pointer data, e.g. byte[] or char[], > > In my own code, Strings and arrays of pointers to Strings would be the > most common ram hog. > > I wonder if someone could cook up a simple tool to predict the effect of > going to 64 bit on any given app. Given that going 64bit lifts you out of the 3GB straight-jacket, I predict the effect of going 64bit would be to free you from worries about the amount of RAM your application requires and concentrate on other, more important issues. -- Nigel Wade
From: Arved Sandstrom on 24 Nov 2009 05:17 Nigel Wade wrote: > On Mon, 23 Nov 2009 10:14:32 -0800, Roedy Green wrote: > >> On 23 Nov 2009 13:54:01 GMT, Thomas Pornin <pornin(a)bolet.org> wrote, >> quoted or indirectly quoted someone who said : >> >>> most of the memory used in a >>> typical application is for non-pointer data, e.g. byte[] or char[], >> In my own code, Strings and arrays of pointers to Strings would be the >> most common ram hog. >> >> I wonder if someone could cook up a simple tool to predict the effect of >> going to 64 bit on any given app. > > Given that going 64bit lifts you out of the 3GB straight-jacket, I > predict the effect of going 64bit would be to free you from worries about > the amount of RAM your application requires and concentrate on other, > more important issues. > Leaving aside the specific numbers, how many times over the past thirty years (rough timeframe for the Age of PCs [1]) have we said the same thing? :-) AHS [1] defining that "Age" by at least reasonably large use.
From: Thomas Pornin on 24 Nov 2009 06:58 According to David Lamb <dalamb(a)cs.queensu.ca>: > Do you have any studies that show this (ie. that most memory use is > large arrays of this sort)? Only my own experience -- which includes fitting a Java-based server into my own JVM for an embedded system, where I wrote the GC and saw first-hand what RAM was used for. Although there were fairly complex data structures in there (including complete validation of X.509 certificates), most of the memory used turned out to be I/O buffers (a compliant SSL server requires a 18437-byte input buffer per connection, and that's quite a lot actually). On anything vaguely graphical, I would expect bitmap pictures to eat up quite a lot of RAM as well. --Thomas Pornin
From: DuncanIdaho on 24 Nov 2009 09:31
Thomas Pornin wrote: > According to DuncanIdaho <Duncan.Idaho2008(a)googlemail.com>: >> The question is, will all my Java stuff (Tomcat 6, Eclipse/My Eclipse >> 5.1/ Java 1.6)that I currently have installed on my remaining XP SP2 >> machine still work or do I need to get everything in new, spanky 64 bit >> versions. > .... > And anyway, you will have > to go 64-bit at some time, so better do it now. Well most of my time is spent developing business systems that usually run as webapps on Tomcat. Consequently I need to be aware of which versions of the servlet engine I am working with (or rather which versions the clients are using) and I certainly can't 'go 64 bit' on a whim. I can see that the address size might be a slight issue memory wise but there is more to 64 bit that bigger addresses isn't there. Do 64 bit registers mean a 64 bit memory bus ... do we really need to fetch 64 bits for a short (oops, sorry Short) ... so many years since university so much forgotten. Anyway, many thanks for the very complete answers to my question -- Idaho |