Free Support Forum - aspose.com

Code cache leak with Aspose Cells java

Hi team,

Recently we found our JVM non-heap memory always becomes full when we use aspose cells to populate multiple excel reports. And we add our JVM parameters of “code cache”, we found we always have codeCache warning when operate excel file with aspose-cells library. Can you please investigate?

And it seems we are not the only one who encounter such issue:
http://www.aspose.com/community/forums/thread/537210/customer-reporting-crash-with-aspose.slides-for-java.aspx

Add two sample logs:
The first one:

[2015-07-17
13:19:59,278] DEBUG AsposeCommonReportServerRenderer reportnumber 4328748800
msg AsposeCommonReportServerRenderer.applyFormating() end<o:p></o:p>

[2015-07-17 13:19:59,278] DEBUG AsposeCommonReportServerRenderer reportnumber 4328748800 msg AsposeCommonReportServerRenderer.convertTextToNumber() start

[2015-07-17 13:19:59,278] DEBUG AsposeCommonReportServerRenderer reportnumber 4328748800 msg AsposeCommonReportServerRenderer.convertTextToNumber() compRange==Sheet3!$F$22:$DG$1804

[2015-07-17 13:19:59,278] DEBUG AsposeUtil convertToNumber =Sheet3!$F$22:$DG$1804

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.

Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

[2015-07-17 13:19:59,824] DEBUG AsposeCommonReportServerRenderer reportnumber 4328748800 msg AsposeCommonReportServerRenderer.convertTextToNumber() end

The second one:

[2015-07-19 17:44:16,955] DEBUG AsposeCommonReportServerRenderer reportnumber 28554827781 msg replace Range: ='Stores Not Scanning'!$B$441:$J$460

[2015-07-19 17:44:16,955] DEBUG AsposeCommonReportServerRenderer rangeReplace get called for replacing by-

[2015-07-19 17:44:16,955] DEBUG AsposeCommonReportServerRenderer reportnumber 28554827781 msg replace Range: ='Stores Not Scanning'!$B$461:$J$480

Java HotSpot(TM) 64-Bit Server VM warning: [2015-07-19 17:44:16,955] DEBUG AsposeCommonReportServerRenderer rangeReplace get called for replacing by-

CodeCache is full. Compiler has been disabled.

Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

[2015-07-19 17:44:16,955] DEBUG AsposeCommonReportServerRenderer reportnumber 28554827781 msg replace Range: ='Stores Not Scanning'!$B$481:$J$500

Hi Sissi,


Thank you for contacting Aspose support.

Please note. although it is merely a warning, “Compiler has been disabled” sounds ominous. Fortunately this warning does not affect the compilation process because the resulting bytecode is exactly the same if produced without this warning. However, you can address this situation in a number of ways, such as follow.

  1. You can disable code cache flushing totally by passing the JVM option XX:-UseCodeCacheFlushing.
  2. Instead of disabling it, you can also increase the code cache size with -XX:ReservedCodeCacheSize=128M. Please note, default value is 48M, which is sufficient for most of the times.

Anyway, if you are not satisfied with above solutions then please first try the scenario with Aspose.Cells for Java 8.5.1. In case you still see similar behavior, please provide us an executable standalone sample application along with supporting spreadsheets for further investigation. We will also require your environment settings such as follow to simulate the settings on our side.

  • Operating system version
  • Operating system architecture
  • JDK vendor
  • JDK version
  • List of JVM arguments that you are currently setting for the application/process
  • Tool(s) used for monitoring. I believe you are using JConsole, correct?

Ok, I will try the version 8.5.1.


But I have one question: why the JVM non-heap not released automatically after excel close.
We have tried to increase it from 50M to 200M before sending this ticket. Please see the attached monitor we did. When there are Excel operations with Aspose library, it will increased. Even after Excel close, it won’t release.

After the warning message, JVM performance becomes painfully slow, so it is a showstopper issue for us, because we then need to restart JBoss. We increased CodeCache size to 200M, but it keeps growing and not recycled, so we will hit the limit again.

Please help to investigate this and appreciate if any fix can resolve the issue.

Hi Sissi,


We need to thoroughly investigate the presented scenario on our side to establish it as a bug on the part of Aspose.Cells for Java API, and we need the requested information/artifacts for investigation. Thank you for your understanding.

By the way, have you tried the scenario with latest release?

I am testing with latest release version, but maybe no changes for the JVM memory issue.


Provide below infos to you, please investigate.
  • Operating system version: Windows Server 2008 R2 Service pack 1, 64 bit.
  • JDK: java version
    “1.6.0_33”

    Java(TM) SE Runtime Environment (build 1.6.0_33-b03)

    Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)

  • JVM ops: Xrs -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=6002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xms4G -Xmx16G -XX:MaxPermSize=2G -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:ReservedCodeCacheSize=200M
  • Tool(s) used for monitoring: Jconsole

Hi Sissi,


Thank you for providing more information.

We have logged an investigative ticket (CELLSJAVA-41418) based on the information shared so far, however, it will be nearly impossible to recreate the circumstances to trigger the said behavior without the original code & sample spreadsheets. Moreover, upon discussion with the product team, we think the probable cause for the said behavior is the JDK version being used on your side therefore it is suggested to try the scenario against the more recent releases of JDK such as 1.8 and share the log files here for review.

The issue happened on any spreadsheets, just create an Excel and write some code based on your library, populate data, replace range, apply format… and add a loop to run it, wait some time each loop, you will see the memory will keep increasing and never cycled.

Not sure why it impossible to recreate the circumstances.

Please try it…

Hi Sissi,


First of all, we are already working to replicate the problem on our side. We have so far tried on Windows 7 Home Premium x64 against JDK 1.8.0_20 with simple spreadsheet manipulation without observing any issue. Now you have shared your environment details so our first priority is to simulate the environment to give the scenario another try and we are currently working on it.

Please note, source code & sample documents are the most important items to start investigation in such scenarios. Moreover, Aspose.Cells APIs are quite complex where most of the features have alternatives. For instance, there are more than 6 ways to import/populate the data in worksheets using Aspose.Cells for Java. Also there are several switches to influence the range replace/copy operation and to format the data cell, row and/or column wise. So recreating the exact circumstances without the original source code is nearly impossible because we cannot know how you are achieving all aforesaid in your main application that is showing the presented problem. One way could be that we come back to you again n again to get more information or to get verification on how we are currently testing the scenario. More, appropriate way is to share the requested artifacts, that are; a demo application & input spreadsheet(s). I am not sure why are you reluctant to share these items. If you are concerned regarding the privacy of your data then please ask your legal team to review the EULA for NDA (clause 8). We are bound not to expose any user shared data unless the thread is Public. Please note, the Public threads are indexed by search engines and are publicly accessible to everyone. On the other hand, Private threads are not indexed by search engines and only accessible to the thread owner and the Aspose team members.

Regarding the test results against the latest version of Aspose.Cells for Java 8.5.1, we need to be sure that the latest version of the API also exhibits similar behavior before we log a valid investigation. In this case, we have logged the investigation without confirming the behavior on our end due to the urgency of the matter. However, the ticket is currently pending for analysis and is in the queue with other priority tasks. As soon as you share the missing information, we will attach it to the ticket and request the product team to schedule the analysis at earliest possible.

Thank you for your understanding & cooperation.

Hi again,


This is to inform you that we have executed some tests to get the non-heap memory spike as shown in the snapshot (code cache monitor.jpg). However, we were not able to replicate the error “CodeCache is full” on our side. Please note that the non-heap memory space stores the per-class structures such as run-time constant pool, field and method data, and the code for methods and constructors as well as the internal Strings whereas the Code Cache is part of the non-heap memory used for the compilation and storage of native code. It is completely managed by the JVM and not by the Aspose.Cells component. We think the increase in the non-heap memory is because of the fact that more and more java class structures (classes, methods etc.) are required when executing your particular application. What we are sure of is that all the objects created by Aspose.Cells are plain java objects, and they all should be in heap instead of the non-heap memory space.

For your question “why the JVM non-heap not released automatically after excel close”, it is certainly because the Workbook and other related objects are all in heap, and not in non-heap memory space.