villastorm.blogg.se - Smartsynchronize

This is without VPC started.Īll in all this needs even more testing. One indication for a java memory problem is, I can not start smartsynchronize with -Xmx512m and let them do real work and at the same time start smartsvn with -Xmx512m (smartsvn starts but hang at the logo screen). Weird problem is only with some combination of memory settings (VPC 512m and Java -Xmx540m gives no trap but '.Could not reserve.' as stated above while f.i. Still not sure if this is only a VPC problem. So it's not that easy to came to comparable results memory wise. But java apps seem to allocate the memory only when the really need it unlike VPC which immediately allocate all memory. I'm currently testing with multiple java apps to check this but till now with no traps. As VPC is odin based too, maybe there's a problem with more than one odin based application which uses lot of memory. This is only possible with Virtualaddresslimit>1024. Problem seems to occur only when VPC uses much memory (512MB) and java uses much memory too.

but '.Could not reserve enough space for object heap.' with VPC guest memory setting 512MB and starting 'java -Xmx540m' or -Xmx530m or -Xmx520m.

trap000e with VPC guest memory setting 512MB and starting 'java -Xmx510m.' or -Xmx500m.

immediate reboot with VPC guest memory setting 512MB and starting 'java -Xmx440m -version'.

no problem with VPC guest memory setting 96MB/128MB/256MB (java max.

no problem as long as VPC is not running.

Higher values gives '.Could not reserve enough space for object heap.' But maybe this is cause in this case max. With Virtualaddresslimit=1024 I can not produce traps. To give guest a memory of 800MB (which I have used for years) needs Virtualaddresslimit setting of more than 1024 (I had 1536). I had no traps with guests with 256MB or less memory. Traps can be reproduced with VPC guests memory setting of 512MB or more. OpenJDK Client VM (build 19.0-b09, mixed mode)

OpenJDK Runtime Environment (build 1.6.0-ga-b22) And try something very simple like 'java -version' instead of starting a real Java application.Īll in all, we need more information and a good way to reproduce.Īll test from now are made with GA version. Also, describe the minimal set of steps in order to reproduce the problem. Therefore I suggest you to test it with no VIRTUALADDRESSLIMIT set in config.sys to see if it makes any difference.Īlso, please tell us what version of VPC you use and where to get it. So, you may be hitting a similar issue with one of your device drivers, for instance. See this part of README.OS2 for one example. Note that OS/2 is known to be unstable when VIRTUALADDRESSLIMIT is set to a value higher than 1024. Please give us more information about your system: which OS/2 version, which kernel, etc. So my wild guess is that attempts to allocate a block of size close to or above the limit screw up the SMP kernel on your system.

The only thing the -Xmx option does is setting the size of the Java heap - a contiguous block of linear memory in the private arena reserved at JVM startup (eventually, just a single DosAllocMem?() call, so there is no place for multi-threaded race conditions).