MappedByteBuffer
in [Java Help]
|
Prev: swing html parser
Next: Class Constants - pros and cons
From: Alan Gutierrez on 23 Jul 2010 20:53 Peter Duniho wrote: > Arne Vajhøj wrote: >> [...] >>> But out of the box, 32-bit Java is restricted to 2GB whether running on >>> 32-bit Windows or 64-bit Windows. >> >> The IMAGE_FILE_LARGE_ADDRESS_AWARE is not the real problem. > > On 64-bit Windows, I think it is. > >> SUN Java requires contiguous heap space. And even with /3GB there >> are something around the 2 GB marker. > > The /3GB switch (that is, the flag set for Windows itself…this works > alongside 32-bit apps with the "large address aware" flag set) applies > only to 32-bit Windows. > > On 64-bit Windows (where the /3GB switch is moot), I'm not aware of any > address space boundaries that would cause a problem. > > Even on 32-bit Windows with /3GB in the boot.ini file, one may get more > memory for their Java process if they hack the Java .exe to have the > "large address aware" flag, because less of the first 2GB of virtual > address space is taken up by overhead (i.e. a lot of it can go in the > third GB of address space). > > But you're right that on 32-bit Windows, a 32-bit process isn't going to > get a Java heap larger than 2GB (and likely not even as large as). What I'm understanding from this is: I can create a great many large MappedByteBuffers (~250MB) on 64 bit OS X, SPARC and Linux, but this strategy is not going to work on 64 bit Windows. I'm also eager to hear someone destroy the idea entirely, to tell me, "no you're not supposed to use `MappedByteBuffer` that way," or better still, to say I'm on the right track if I'm willing to accept the deployment limitations. A yeah or nay would suffice. Essentially, I always see `MappedByteBuffer` hinted at for this sort of problem, but no one has blogged or otherwise recorded their experiences with anything other than reading a single file. (Maybe that is because 64 bits has only become prevalent more recently?) -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Lew on 23 Jul 2010 21:05 Alan Gutierrez wrote: > What I'm understanding from this is: > > I can create a great many large MappedByteBuffers (~250MB) on 64 bit OS > X, SPARC and Linux, but this strategy is not going to work on 64 bit > Windows. I don't think that's a problem if you use a 64-bit JVM. The restrictions people have discussed here apply only to 32-bit JVMs. -- Lew
From: Peter Duniho on 23 Jul 2010 22:30 Alan Gutierrez wrote: > What I'm understanding from this is: > > I can create a great many large MappedByteBuffers (~250MB) on 64 bit OS > X, SPARC and Linux, but this strategy is not going to work on 64 bit > Windows. [...] It should work fine on 64-bit Windows. You just need to run the correct JVM (the 64-bit one).
From: Kevin McMurtrie on 24 Jul 2010 04:39 In article <i2c2pn$e64$2(a)news.albasani.net>, Lew <noone(a)lewscanon.com> wrote: > Kevin McMurtrie wrote: > > Java 1.5 is more commonly a 32 bit process while Java 1.6 is more > > commonly a 64 bit process. > > How do you figure that? Just an observation of which is more likely to launch by default when there's no selector provided. It may depend on the Java bundle used too. I count 5 primary bundles on Oracle's page. Java DB documents also reference "Server SDK" and "GlassFish Server" bundles. > > > You're running out of memory addresses in 32 bit mode. > > > > Adding '-d64' as the first JVM option will force the 64 bit version or > > fail with a message that it's not installed. -- I won't see Google Groups replies because I must filter them as spam
From: Lew on 24 Jul 2010 10:32
Kevin McMurtrie wrote: >>> Java 1.5 is more commonly a 32 bit process while Java 1.6 is more >>> commonly a 64 bit process. Lew wrote: >> How do you figure that? Kevin McMurtrie wrote: > Just an observation of which is more likely to launch by default when > there's no selector provided. It may depend on the Java bundle used > too. I count 5 primary bundles on Oracle's page. Java DB documents > also reference "Server SDK" and "GlassFish Server" bundles. Whichever one launches by default depends on the one installed. You must have observed 32-bit Java 5 installations and 64-bit Java 6 installations, but it's always dangerous to infer universality from a small non-random sample. It would be just as dangerous for me to conclude that Java 5 64-bit is more common than Java 5 32-bit just because the large government projects that have hired me over the last few years happen to use big iron. -- Lew |