好的，所以我编写了一个 C# 驱动程序（驱动程序在虚拟程序中调用存根而不是设备驱动程序）程序，该程序调用 C 包装器 DLL，C 包装器 DLL 通过 JNI 调用 java jar 文件，该文件实际上完成了大部分工作。所有 3 个程序都是 32 位的。这样做是为了与另一个供应商集成，该供应商应该执行 C# 以及调用我们的 C DLL 的 C 程序。
我的示例测试 C# 到 C到 Java 程序工作正常，但问题是，当供应商的实际 C# 程序调用我们的程序时，Hotspot JVM 要么完全初始化失败，要么如果它正确初始化，在调用我们的函数期间，它会抛出 OutOfMemory 错误。当我尝试使用不需要连续堆空间的JRockit JVM时，JVM会导致程序彻底崩溃。
开发平台是Windows 7 64位操作系统。酷睿i7,8GB内存实际程序必须是 32 位，以便向后兼容旧硬件/操作系统。
据我了解，一个 32 位进程通常最多有 2 GB 的地址空间可供使用。我的驱动程序占用的任务管理器的峰值总大小为 256MB。供应商的 C# 程序加载了相当多的其他库，但我非常怀疑它们会占用超过 700MB。
这里可能有什么问题？是地址空间不连续吗？但是，如果是这样的话，为什么JRockit会直接崩溃，因为它可以处理不连续的地址空间？
这里可能出错的事情太多了，无法推测可能是哪一个。
一些建议：
-
试图通过独立于实际证据开发理论来调试问题是一个坏主意。 你有一个理论，认为这与不连续的地址空间有关，（显然）没有任何真正的证据。 先获取一些证据...
-
随机更改变量（例如尝试不同的 JVM）是一种糟糕的方法，除非您有一些证据表明这是问题所在......在你的情况下。
-
如果您正在构建要在 32 位平台和旧版操作系统上运行的内容，则需要一个 32 位 + 旧版操作系统测试环境来进行日常开发测试。 （你的问题的措辞表明你没有。
-
您需要重现客户端看到的实际问题。 获取他们的程序以及他们的硬件和操作系统等的详细信息，并尝试设置克隆。 如果无法做到这一点，请安排一次现场访问，在那里您可以直接访问他们的工具包。
最后。 试图在同一过程中拼凑C，C#和Java的系统设计在技术上风险达到疯狂的程度。 无论谁决定这是一个好主意，都需要接受再教育。