Weblogic out of space in CodeCache for adapters causes downtime and weblogiccodecache

Weblogic out of space in CodeCache for adapters causes downtime and weblogiccodecache

Weblogic goes down inexplicably. The downtime log is different from the previous one:

Caused By: java. lang. VirtualMachineError: out of space in CodeCache for adapters

At org. codehaus. groovy. runtime. callsite. AbstractCallSite. callCurrent (AbstractCallSite. java: 141)
At net. sf. jasperreports. engine. fill. JREvaluator. init (JREvaluator. java: 88)
At net. sf. jasperreports. engine. fill. JRCalculator. init (JRCalculator. java: 111)
At net. sf. jasperreports. engine. fill. JRFillDataset. initCalculator (JRFillDataset. java: 469)
At net. sf. jasperreports. engine. fill. JRBaseFiller. <init> (JRBaseFiller. java: 529)
At net. sf. jasperreports. engine. fill. JRVerticalFiller. <init> (JRVerticalFiller. java: 88)
At net. sf. jasperreports. engine. fill. JRVerticalFiller. <init> (JRVerticalFiller. java: 103)
At net. sf. jasperreports. engine. fill. JRVerticalFiller. <init> (JRVerticalFiller. java: 61)
At net. sf. jasperreports. engine. fill. JRFiller. createFiller (JRFiller. java: 153)
At net. sf. jasperreports. engine. fill. JRFiller. fill (JRFiller. java: 55)
At net. sf. jasperreports. engine. JasperFillManager. fill (JasperFillManager. java: 446)
At net. sf. jasperreports. engine. JasperFillManager. fillReport (JasperFillManager. java: 849)
At com. gg. datareport. reportform. appservice. impl. JRService. getJasperPrint (JRService. java: 1017)

At com. gg. datareport. reportform. appservice. impl. JRService. reportHTMLByTemplToResp (JRService. java: 1123)

The Code cache is full because the third-party report tool uses groovy to dynamically generate many classes, which are explained on the network as follows:

The full use of Code Cache may be due to insufficient space, and the Code Cache will not be recycled, so it will accumulate more and more (in fact, it won't be too much if we don't use the dynamic update/load class like groovy), so the solution one can increase the size of the code cache, you can add-XX: ReservedCodeCacheSize = 256 m to the startup parameter (we recommend that you increase the code cache size for the Oracle JVM Team), and enable the code cache recycle mechanism, you can add "-XX: + UseCodeCacheFlushing" to the startup parameter to enable it.

1. Change the weblogic startup parameter to-XX: ReservedCodeCacheSize = 1024 m. The downtime frequency decreases, but the downtime still exists.

Adjust 2: add the parameter-XX: + UseCodeCacheFlushing, which is very stable so far.

Summary:However, to solve the root problem, you should check the code to check where there is no memory leakage. This third-party report tool is a new component, and new things will bring new problems, so the problem diagnosis should keep pace with the times.