Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Failed creating a JVM, result code -4 ... why?

When I make this call: ISpaceProxy proxy = SpaceProxyProviderFactory.Instance.FindSpace(spaceUrl);

I get this exception:

An exception of type 'GigaSpaces.NetToJava.NetToJavaException' occurred in MyGridApplication.dll and wasn't handled before a managed/native boundary

Additional information: Failed creating a JVM, result code -4 Make sure you're not asking for too much heap size and that you have not inserted unrecognized custom options (Use JvmCustomOptions IgnoreUnrecognized="true" to ignore unrecognized options)

Why is this happening? How can I debug this kind of exception? I tried to add an app.config with this 'ignore' set to true but the error still pops up.

When I trace, I get the following trace:

GigaSpaces.Core Information: 1003 : Trace Source is not defined in configuration - using default settings (LoggingLevel: Information). GigaSpaces.XAP.ProcessingUnit Information: 1003 : Trace Source is not defined in configuration - using default settings (LoggingLevel: Information). GigaSpaces.XAP.Events Information: 1003 : Trace Source is not defined in configuration - using default settings (LoggingLevel: Information). GigaSpaces.NetToJava: Checking for existing Jvm GigaSpaces.NetToJava: Checking if Jvm module is loaded (module named jvm) GigaSpaces.NetToJava: No Jvm module found in process GigaSpaces.Core Information: 1007 : Jvm initialization options:

-Dcom.gs.home=D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime -Xbootclasspath/p:;.;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\xml;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\xml\serializer.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\xml\xalan.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\xml\xercesImpl.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\xml\xml-apis.jar -Djava.class.path=;.;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\common\backport-util-concurrent.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\JSpaces.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\jini\jsk-platform.jar;D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\lib\ext -Xms16m -Xmx256m -Djava.security.policy=D:\Program Files\GigaSpaces\XAP.NET 6.6.1\Runtime\policy\policy.all

GigaSpaces.NetToJava: Initializing Jvm roamer.exe Error: 0 : GigaSpaces.NetToJava: Failed creating a JVM, result code -4 Make sure you're not asking for too much heap size and that you have not inserted unrecognized custom options (Use JvmCustomOptions IgnoreUnrecognized="true" to ignore unrecognized options) A first chance exception of type 'GigaSpaces.NetToJava.NetToJavaException' occurred in GigaSpaces.NetToJava.dll

It seems that the failure is in the following code (from reflection):

int num5 = JNI_CreateJavaVM_func(&avm_Ptr, &v_Ptr, &args); int num3 = 0; if (0 < *(((int) (&args + 4)))) { do { uint num4 = ((uint) ((num3 * 8) + optionPtr)); if (num4 != 0) { delete((void) num4); } num3++; } while (num3 < *(((int) (&args + 4)))); } delete((void*) optionPtr); if (num5 == 0) { threadLocalJVMContext = new JVMThreadContext(); threadLocalJVMContext.Env = v_Ptr; globalJVM = avm_Ptr; } else { TraceAndThrowNetToJavaException(("Failed creating a JVM, result code " + num5) + Environment.NewLine + "Make sure you're

not asking for too much heap size and that you have not inserted unrecognized custom options (Use JvmCustomOptions

IgnoreUnrecognized=\"true\" to ignore unrecognized options)"); } }

I checked around Java and if JNI_CreateJavaVM_func returns -4 it is an JNI_ENOMEM code, meaning out of memory. But the machine is really not out of memory....Commit charge is 1.1 GB and Limit is 2.9 MB with 2GB RAM.

Edited by: theo w on Nov 21, 2008 3:37 AM (added details) h4. Attachments


{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2728]{quote}

asked 2008-11-21 01:59:42 -0500

theo gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

This error occurs when the Jvm creation fails because the operation system denied the request for the specified chunk of memory.

In order to isolate the problem try to change the default maximum heap size, see:

And set the MaximumHeapSizeInMB and InitialHepaSizeInMB in your app config to be really low.
If that solves the problem you should investigate why the memory request is denied, are you running inside an excel process perhaps?
We've encountered this problem when running inside Visual studio for example or inside an excel process.


P.S are you starting an embedded space in that process or connecting to a remote one, the default memory allocation is 256 MB but it can easily be decreased when connecting to a remote space.

answered 2008-11-21 04:19:02 -0500

eitany gravatar image
edit flag offensive delete link more


Thank you for the answer and it works to reduce the size. I used this file snippet: <jvmsettings> <jvmmemory initialheapsizeinmb="2" maximumheapsizeinmb="2"/> <jvmdll mode="Client"/> </jvmsettings>

The set-up of this process is a bit tricky. I have a native application (C++) calling my C# assembly, which is exposed as COM component to the native application. The C# assembly then starts GS. The problem occurs regardless of whether I am using debugger or not. Interestingly, the problem does not occur when I use the samples that come with GS. All of these samples that work have one thing in common: they are EXEs and not DLLs. Thus, it appears that these memory settings are not global heaps but just process-specific heaps. Does this make sense?

However, as I am changing the configuration in this way, it seems I may be voiding stability, performance, robustness or any other guarantees. Especially since the GS code internally sets up the JVM only based on settings in the configuration files without taking any consideration of the actual process memory allocation, memory situation in the O/S and/or actual GigaSpaces JVM memory needs. Would you mind to clarify the following:

(1) If GS JVM can run with 2/2 MB, then why isn't this more resource-conservative setting the default? (2) How can I measure which of the GS JVM parameters InitialHeapSizeInMB or MaximumHeapSizeInMB that causes the problem? (2) Which factors determine the GS JVM minimum memory requirement? (3) How can I reliably predict the GS JVM minimum memory requirement in advance? (Except for trial-and-error) (4) Which factors determine the GS JVM maximum memory requirement? (5) How can I reliably predict the GS JVM maximum memory requirement in advance? (Except for trial-and-error) (6) Even if the GS JVM starts up reliably, what kind of errors may happen later if the memory is not enough? (7) Following question (6), how to catch these errors? What GS exceptions to look for, and under what circumstances?

Sorry for asking so many questions but changing default settings in this way feels a bit to casual. It seems that it would be really nice to have a property that can report the available heap size for the JVM and another property that reports the minimum needed memory for safe operation, so I could compare these before trying to start the GS JVM.

Edited by: theo w on Nov 21, 2008 8:05 PM

theo gravatar imagetheo ( 2008-11-21 20:04:34 -0500 )edit

It might be related to the fact that the assembly is exposed through COM which might enforce different memory allocation boundaries, though I can't say for sure, it's only an assumption.

Regarding the rest of your questions:
1) The default settings are addressed to solve most scenarios without the need for user intervention, while 2MB might be enough for a remote proxy, if the user starts an embedded space or a local cache/view, 2MB will limit the capacitity of the space to contain at most 2MB - Overhead objects. Which in most scenarios will not be enough.
2) It will usally, if not always, be the maximum heap size since the minimum heap size is less or equal than the maximum heap size, I've always encountered the -4 error code when it happen and it was solved by reducing the maximum heap size.
3+4) The minimum requirement can be really low, 16-32mb should suffice. The reason for using the initial heap size is when you have a knowledge or an estimation of how much memory your application will require( this is most relevant for embedded spaces, local cache/view) if you have a remote proxy then you can't really estimate it since your objects will not be saved in the same process. Anyhow, the minimum heap size is only an optimization to reduce the reallocation of memory on demand and garbage collection if you can predict how much memory will be needed, in worst case scenario the application will always need more than the initial heap size, and it will reallocate memory (until it reaches the maximum heap size). hence, the important parameter is the maximum heap size.
5) The same parameters as above determine the maximum heap size while taking in consideration how much memory your are "willing" to allocate to this process in your environment. If your process is a remote proxy you don't need too much memory, I would try the trial and error to see how much you can allocate to start a Jvm successfully and go from there.
6+7) When the Jvm is about to run out of memory, GS will start throwing MemoryShortageException to indicate it, which usually tells the user that he can't put more objects into the space until he frees some memory by removing other objects. when this exception it is determined if the Jvm had reached the low water mark or high water mark memory consumption, at some point it will stop putting objects into the space until enough memory is released. Keep in mind that this is not relevant for a remote proxy since the objects are put in a different process. Therefore, if the Jvm started successfully you should not encounter problems. (That said, 2MB Maximum heap size is really low and should not be used, too much garbage collection and the proxy might still need some memory).
(see:http://www.gigaspaces.com/wiki/display/XAP66/Memory ...


eitany gravatar imageeitany ( 2008-11-22 02:04:03 -0500 )edit

Thank you for the detailed explanation, very appreciated.

Using managed code is the preferred choice for productivity although C++ could be helpful to avoid excessive native-managed transition overhead on the CCW. It's great that you have a C++ API anyway, will check it.

Since this scenario operates with several inter-process technologies (C++ to COM, COM to Com Callable Wrapper to .NET, .NET to .NET, .NET to P/Invoke JNI, JNI to Java JVM, JVM to x) it is admittedly hard to pinpoint the problem! An experimental approach appears more suitable in the short term. But I am not convinced of your hypothesis that the problem has to do with COM. COM is just a standardized binary interface for components and the memory allocation and management should be each application's own responsibility. COM is both a ubiquitous and mature technology and if COM had a generic problem with memory allocations, then the whole Windows operating system should be broken by now. After all, the problem here is a native exception which is thrown from inside GS. If GS claims .NET support, it should be able to work in .NET COM scenarios as well as CLR hosting scenarios. Since none of the supplied GS samples cover these scenarios (I can find console applications and WinForms applications and PUs only), one cannot say for sure whether it is supported or not. Therefore I would like to suggest your team to create internal tests for these scenarios to replicate the problem. Since you mention that this problem happened even inside Visual Studio or inside Excel, something is not quite right here - and it doesn't look good to blame COM, Visual Studio and Excel at the same time. Besides, there are many interesting scenarios for using GS from Office applications, such as in Excel for financial applications.

theo gravatar imagetheo ( 2008-11-23 20:37:10 -0500 )edit

Don't get me wrong, I didn't say GS doesn't work from visual studio or Excel, I just said that we encountered some memory limitations on some machines that were solved by reducing the heap size.
We even have a few excel examples (stocks demo) and a space viewer which allows you to connect to a space from excel and view the objects inside.

I Agree that currently the reason for this error is not completely known, however, before we implemented our own bridge between .NET and Java, we were using a third party product to do so (Codemesh) and it had exactly the same problem when creating the Jvm in some in process scenarios (exactly the same error was thrown using either one of the bridges). The problem occurs before even the first CLR to Jvm invocation is called, as you noticed your self, the exception is thrown on the JNI_CreateJvm function which is a native JNI method that starts the Jvm. We should investigate why this method get denied for memory allocation in some scenarios as described above.

Thanks for your feedback.

eitany gravatar imageeitany ( 2008-11-24 00:20:09 -0500 )edit

From your description it seems that the most reasonable hypothesis is that this is an issue of the initialization of JVM from JNI. As I understand you convert the <JvmMemory InitialHeapSizeInMB="2" MaximumHeapSizeInMB="16"/> tag to the -Xms2m and -Xmx16m parameters. I suppose all third-party libraries ultimately have to use JNI to achieve the functionality and ultimately they also need to pass these parameters, which would explain why Codemesh couldn't do it properly either.

theo gravatar imagetheo ( 2008-11-24 01:00:05 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2008-11-21 01:59:42 -0500

Seen: 434 times

Last updated: Aug 08 '13