Jump to content


Photo

Taking advantage of 64 bit OSes?


  • Please log in to reply
3 replies to this topic

#1 jamoram62

jamoram62

    Master Director

  • Members
  • 880 posts
  • Gender:Male
  • Location:3724'21.05"N 00559'14.69"W

Posted 18 March 2015 - 08:17 PM

Wandering through the www, I found a reference regarding a version of a Java JVM compiled with the LARGEADDRESSAWARE switch. I knew of this feature and have used in the past for some memory hungry applications (eg, Flight Simulator 2004). My knowledge about Java and their inner workings is rather scarce at best, but I was wondering if some advantage could be got in terms of available heap space for applications (ie, Moviestorm) if these are run on such a JVM.

 

By design, on 32-bit versions of Windows, the virtual address space (VAS) for any process is split between 2GB for the kernel and 2GB for the application itself. In those Windows systems, applications compiled and marked with this switch, in combination with the /3GB boot option, could be assigned a theoretical maximum 3GB for the application itself (there are some other considerations that decrease this value in practice). Again theoretically, such an 32-bit application running on a 64-bit Windows and WoW64 would be awarded 4GB of its VAS for the application itself.

 

Too bad, it seems such a JVMs are not as readily available (*). Worse, it's possible that some code component (ie, a third-party library) could misbehave if it hits the 2GB boundary. In addition, some reports state that the benefit in practice is lesser than expected in terms of address space and there is a significant impact in performance because of greater latencies in the garbage collection.

 

(*) The jRockit distribution available from Oracle (http://www.oracle.co...it-2192437.html)  has this option enabled and can handle a >2GB user mode address space.

 


ars longa vita brevis - Hippocrates (attributed)
 
If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ
 
Shared addons & stuff for Moviestorm: https://drive.google...aTNsSFBuN0sxZHM


#2 jamoram62

jamoram62

    Master Director

  • Members
  • 880 posts
  • Gender:Male
  • Location:3724'21.05"N 00559'14.69"W

Posted 20 March 2015 - 04:37 PM


 

(*) The jRockit distribution available from Oracle (http://www.oracle.co...it-2192437.html)  has this option enabled and can handle a >2GB user mode address space.

 

 

Tried to replace the JRE that comes bundled with Moviestorm with the one in the jRockit distribution. Both VMs were the same version (1.6), but Moviestorm dies immediately complaining about it couldn't start a JVM. Luckily got MS back to its original working status with no issues.


ars longa vita brevis - Hippocrates (attributed)
 
If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ
 
Shared addons & stuff for Moviestorm: https://drive.google...aTNsSFBuN0sxZHM


#3 EugeneE

EugeneE

    Master Director

  • Members
  • 458 posts

Posted 05 April 2015 - 11:18 PM

I'm not sure but I believe that Moviestorm might have to be re-written to support 64 bit OSes. I would love to see a 64 bit Moviestorm and others might to because it wouldn't have the memory restriction that 32 bit has.

 

IIRC, 32 Bit OS's are limited to 4 GB of ram, 64 bit's don't have this problem.



#4 jamoram62

jamoram62

    Master Director

  • Members
  • 880 posts
  • Gender:Male
  • Location:3724'21.05"N 00559'14.69"W

Posted 06 April 2015 - 06:31 AM

I'm not sure but I believe that Moviestorm might have to be re-written to support 64 bit OSes. I would love to see a 64 bit Moviestorm and others might to because it wouldn't have the memory restriction that 32 bit has.

 

IIRC, 32 Bit OS's are limited to 4 GB of ram, 64 bit's don't have this problem.

 

A 32-bit application would be limited to 4GB of Virtual Address Space (VAS) both on a 32-bit and a 64-bit Windows system. Always. The problem is that those 4GB are split between user address space (available for the application process itself) and the kernel address space (reserved for system structures and data used in the process context).

By default, both on 32 and 64-bit Windows systems, of those 4GB, only 2GB are available for the application itself. My proposition was to take advantage of a well-known feature that allows us to stretch this address space: on a 32-bit system that would render at most 3GB of the VAS (in practice, a lot less); but on a 64-bit OS, running on WoW64, the full 4GB of VAS would be available for the user address space. See: https://support2.mic...spx?scid=889654 and https://msdn.microso...y/aa366778.aspx

 

Virtual address space per 32-bit process: 

 - 32-bit OS: 2 GB, 3 GB if the system is booted with the /3GB switch (*)

 - 64-bit OS: 2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE switch

 

(*) Please note that the /LARGEADDRESSAWARE switch is required for the application taking advantage of this feature.

 

So on a 64-bit Windows OS we'd have 4GB available for the Moviestorm process, provided it's running on a JVM with the LARGEADDRESSAWARE feature enabled, instead of the current 2GB cap. Of course, this doesn't imply that those full 2GB extra would be available for the application itself: the JVM takes its share. In fact, of the 2GB currently available, only 512MB (or at most 800MB) are available for the data heap.  Provided we've got MS running happily on such a JVM, the next logical step is to take advantage of the extra address space and to increase the heap size. Now, this means that the JVM has more memory to track, manage and take care of, so it will need extra memory for its own data structures. Further, this also means that the garbage collector will have extra work to do, so a performance hit is to be expected, though its magnitude needs to be empirically assessed.

 

Indeed, a full and real 64-bit implementation of MS would be the real and ultimate cure for all our predicaments related to memory shortage: with a user address space of 8 TB, no more out of memory exceptions are to be expected. Too bad it seems quite improbable that we'll see it in the  future/ever.

 

IIRC the problem to get this accomplished has to do mostly with third-party libraries that are used and invoked from Moviestorm's own code. My knowledge about Java is shallow, so maybe I'm wrong, but porting MS itself to run on a 64-bit JVM shouldn't be very hard. Theoretically. There may be some class members and pieces of code that require further consideration to make it work reliably on a 64-bit platform.

 

Nevertheless, Ben is making his best and some performance and memory usage optimizations are to be expected soon: eg, not mapping meshes data files into the application address space unless an asset in the addon is actually used (http://www.moviestor...445#entry106539). For sure, that can make a difference.

 

 

 


ars longa vita brevis - Hippocrates (attributed)
 
If you want to tell jokes then use Muvizu; if you want to make 'Movies', use iClone; but if you want to tell stories, use Moviestorm - PrimaveraNZ
 
Shared addons & stuff for Moviestorm: https://drive.google...aTNsSFBuN0sxZHM



  • Please log in to reply


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users