without VPC running -
P:\java6\bin\java.exe -mx800m -jar ..\lib\smartsynchronize.jar
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
which is what I expect with current VIRTUALADDRESSLIMIT=1536 setting But do never crash. Works nicely with -mx750m.

On single core Thinkpad never crashes even with VPC running. Starting with -Xmx450m only java app start hangs which can be killed with CTRL-C. No crash.

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).

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.

Please give us more information about your system: which OS/2 version, which kernel, etc.

Note that OS/2 is known to be unstable when VIRTUALADDRESSLIMIT is set to a value higher than 1024. See ​this part of README.OS2 for one example. So, you may be hitting a similar issue with one of your device drivers, for instance. Therefore I suggest you to test it with no VIRTUALADDRESSLIMIT set in config.sys to see if it makes any difference.

Also, please tell us what version of VPC you use and where to get it. Also, describe the minimal set of steps in order to reproduce the problem. And try something very simple like 'java -version' instead of starting a real Java application.

Seems with VIRTUALADDRESSLIMIT=1024 VPC, at least this W2k guest with which I've made all my test till now, is not able to start anymore. WPS do not respond with xcenter showing 99.9% for one CPU. It takes a little time with all these reboots and chkdsks (eCS and W2k guest) to get reproducable results. Even with no java running VPC do not start anymore.

Have to test even more. I sent the above only cause I wanted to have it saved before the next trap... So let me test again tomorrow to give more input. Sorry no time left today.

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

With Virtualaddresslimit=1280:
Java heap max. is now 542MB (-Xmx542m).

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

Problem seems to occur only when VPC uses much memory (512MB) and java uses much memory too. This is only possible with Virtualaddresslimit>1024. As VPC is odin based too, maybe there's a problem with more than one odin based application which uses lot of memory. I'm currently testing with multiple java apps to check this but till now with no traps. But java apps seem to allocate the memory only when the really need it unlike VPC which immediately allocate all memory. So it's not that easy to came to comparable results memory wise. Still not sure if this is only a VPC problem.

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. -Xmx510m traps)

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). This is without VPC started.

All in all this needs even more testing. But maybe we should ask Knut if he has a clue about this as he probably knows more about VPC and Odin as most of us.

Related to this I once got a popuplog.os2 entry when running smartsynchronize with java6 -Xmx512m and the hanging smartsvn with java6 -Xmx512m and additionally trying a 'java -Xmx542m -version' which gives a return code 5 and popuplog.os2 -

If you read README.OS2 carefully, there is a detailed explanation of the dependency between the maximum Java heap size and the VIRTUALADDRESSLIMIT setting. This more or less relates to any application using high memory, not only Java (you may try e.g. Open Office etc).

Yes, Java only reserves memory at startup. It commits it as needed. I don't know about VPC. What is the amount of real physical memory on your machine? Are you sure it is enough for both Java and VPC, given what you request for them?

Anyway, it looks like a kernel bug related to managing high memory to me. The absence of traps in case of VIRTUALADDRESSLIMIT=1024 only proves that. I don't think we can do a lot here, but if you give me a link to a complete VPC package that I need to reproduce the problem (including any VHD/VM configurations this may require), I will try to reproduce it locally at least.

No promise of the quick fix for that. So far, try to either not use both VPC and Java together or live with VIRTUALADDRESSLIMIT=1024.

Thx for looking into this. Now as I know the problem and how to circumvent I can live with it. But still not sure, if it's only a problem in conjunction with VPC or if it may appear with other odin/java apps too.

I've 4GB installed and eCS sees about 3.4GB. And yes, I've checked multiple times with memtest86. So there should be no problem with real available memory. Though I can not remember any time seeing eCS using more than 1.5GB (regarding to xcenter mem display).

No traps with VIRTUALADDRESSLIMIT=1024 can mean that

the kernel/OdinMemoryManagement/OdinExceptionHandler/....? traps only when using more then 1GB or beyond 1GB

or two concurrently running Odin/Java? apps do have problems only with more than 512MB per app (which is only possible with Virtualaddresslimit>1024)

or ???

If we feel certain this is only a VPC problem, I wouldn't spent any more minute on this. But I've the bad feeling this problem will hit eCS sooner or later again...

VPC/VHDs - have to try with stripped down images before. Cause I really don't want to upload >8GBs somewhere. It would take days with my upload bandwidth ;-) Have to test with the 14.105 kernel before too. Does it make sense to test with Pashas hacked kernels?

The POPUPLOG.OS2 entry just tells us it crashed in the fatal error report printing code in JVM (see #97) which is totally unrelated to your problem.

In order to find out if it's a VPC only problem, you could try to run Java in parallel with another greedy application that uses high memory such as OOo.

Java does nothing but allocates high memory with DosAllocMem?(OBJ_ANY), so Java is not the cause of the trap on its own. The same for Odin. So I can't see how this can be fixed on the application side except by removing OBJ_ANY usage (which will make it impossible to allocate more than 512M and therefore become equivalent to using -Xmx values < 500 => pointless).

If you want to test I've uploaded to my server at -​ftp://buchinger.selfip.net/vpc/
Login as user guest with your email address as password. Unfortunately my connection is not very stable especially with wet weather. But I think Peter Moylans ftp servers supports reget. The server should be online the next days.

The *_VHD is a eCS guest which resides on R:\ on my machine but can be anywhere of course. VIRTUALPC.zip is an installed VPC on P:\. Not sure if it works at another place. But have it transferred to another machines to P:\ successfully in the past without reinstall. When you configure a guest set the path for the first harddisk to the unzipped *.vhd and memory to 512MB.

I use this rexx script to step through various java memory settings but it should immediately trap with -Xmx500m. No matter if VPC runs before or is started afterwards.

For network connection from within the guest OS I use 'Virtuelle Umschaltung'. For this the VPC switch driver is necessary which can be installed with vpcsetup.exe. Be aware, mpts can not process protocol.ini afterwards. You need to deinstall switch.os2 with vpcsetup before. But most probably you do not need switch.os2 anyway.

Another reproducible crash scenario without VPC but OpenOffice3.2 and java6

fresh reboot (Virtualaddresslimit=1280)

start OO3.2 writer and load .bmp image with 240MB

open another writer instance and load another .bmp with 60MB (I can not load a second time a 240MB .bmp without silent OO termination)

again open another writer instance and load again a .bmp with 60MB

'java -version' --> trap 000e

Sometimes with other image loading scenarios I get hard crashes without trap screen but full hangs (no mouse movement, no <CTRL> <ALT> <DEL>)

I've tested with a simple test application and different DosAllocMem? calls up to 3GB memory utilization (different processes with up to 600MB each) and OO but had no crashes.

With java -Xmx* and simple DosAllocMem? application I can not produce traps too. It needs a more complex app like OO or VPC AND java to crash the machine. Maybe OO frees memory blocks at the time java tries to allocate?

I've pointed Steven to this ticket. Maybe he has ideas how to narrow down this trap000e (?) problems.

In theory yes, practically I never worked with KDB or ICAT. Com port and other eCS Systems are available. Not sure if I have a network card which works with ICAT but think it works with COM port too. Should search the Internet for a 'Setup of ICAT for dummies' before.

Do you think this are really page faults trap 000e) and what does it mean. I mean, if the page is not in memory (which I doubt cause I can reproduce it with more than 2GB free memory) than why the hell does the kernel not load it from the swap file? Obviously lack a basic understanding ...