Is it an issue if "loa" is consisting 100%? There free memory in other areas. If it is an in issue what is the proper solution? gc type="scavenge"
<mem type="loa" free="*******" total="*******" percent="100" />
<gc-end id="xxxx" type="scavenge" contextid="xxxx" durationms="34.230"
<mem-info id="xxx" free="" total="" percent="72">
<mem type="nursery" free="" total="" percent="98" />
<mem type="tenure" free="" total="" percent="64">
<mem type="soa" free="" total="" percent="63" />
JVM details
java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxp6460_26sr8fp4ifix-20150514_01(SR8 FP4+IX90162+IV73188))
IBM J9 VM (build 2.6, JRE 1.6.0 Linux ppc64-64 Compressed References 20150512_248381 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR8_20150512_1623_B248381
JIT - tr.r11_20150401_88894
GC - R26_Java626_SR8_20150512_1623_B248381_CMPRSS
J9CL - 20150512_248381)
JCL - 20150413_01
LOA is the Large Object Area memory type used to satisfy the large object allocation requests, which could not be satisfied in Small Object Area of tenure heap space. If the application does not allocate large objects, the LOA will continue to show 100% free in verbose gc log for few GC cycles. This is not a problem as such because GC algorithm takes care of monitoring LOA usage every gc cycle and shrinks it after few number of GC cycles in case if it is not used consistently.
For more details on command-line options to configure LOA size, please refer:
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.0.0/com.ibm.java.lnx.70.doc/diag/understanding/mm_allocation_loa.html
Related
I would like to use ProcDump's ability to create minidumps with a custom MINIDUMP_TYPE via the -mc command-line switch to include memory contents beyond MiniDumpNormal.
Unfortunately neither MiniDumpWithFullMemory, MiniDumpWithIndirectlyReferencedMemory, nor MiniDumpWithPrivateReadWriteMemory | MiniDumpWithPrivateWriteCopyMemory seem to have any effect: A nonempty minidump is created without an error being displayed, but a lot smaller than expected and querying the minidump via WinDbg's .dumpdebug functionality does not list any of the aforementioned flags even if explicitly included in the minidump type. It seems as if none of the flags mentioned above have an impact on ProcDump's behavior.
The process in question is a 32-bit process running under 64-bit Windows 10, build 2004. I have tried both procdump.exe and procdump64.exe version 9.0, albeit without the -64 command-line switch since I do not want to include SysWOW64 overhead. I have also tried copying 32-bit and 64-bit versions of dbghelp.dll provided by the most recent Debugging Tools for Windows SDK into the corresponding folders in which procdump.exe and procdump64.exe are located. Finally, I have made sure to pass the minidump type as hexadecimal numbers and any other flags that I have tried seem to be recognized without an issue and are being listed when inspecting the minidump in WinDbg afterwards.
As an example, the invocation procdump.exe -mc 51B25 <process> should create a dump with
0x51B25 = 334629 = (MiniDumpWithDataSegs
| MiniDumpWithProcessThreadData
| MiniDumpWithHandleData
| MiniDumpWithPrivateReadWriteMemory
| MiniDumpWithUnloadedModules
| MiniDumpWithFullMemoryInfo
| MiniDumpWithThreadInfo
| MiniDumpWithTokenInformation
| MiniDumpWithPrivateWriteCopyMemory)
When inspecting the dump in WinDbg, neither MiniDumpWithPrivateReadWriteMemory nor MiniDumpWithPrivateWriteCopyMemory show up in the .dumpdebug information with corresponding memory regions being unavailable. Note that when I create the dump from within the application using MiniDumpWriteDump for demonstration purposes, the flags do show up when using .dumpdebug and the resulting minidump will be significantly larger (under otherwise comparable conditions).
Can someone confirm that ProcDump is indeed ignoring memory-related flags or explain to me what I am doing wrong?
(Writing a MiniPlus dump using the -mp switch does work but does not necessarily include the memory regions of interest.)
I'm running a couple of Java programs in BlueJ. I want to be able to know how much memory the program uses for a given input value. Is there any way I can do this?
1) to get the maximum amount of memory that your Java application can use Runtime:
Runtime runtime = Runtime.getRuntime();
System.out.println("max memory: " + runtime.maxMemory() / 1024);
2)to get how much memory that JVM has allocated for your application :
Runtime runtime = Runtime.getRuntime();
System.out.println("allocated memory: " + runtime.totalMemory() / 1024);
3)to get how much memory is being used by your application:
Runtime runtime = Runtime.getRuntime();
System.out.println("free memory: " + runtime.freeMemory() / 1024);
It could be operating system specific; notably the JVM manages Java allocated memory, but you might call external functions in C++ using JNI which are allocating memory too (e.g. your Java program calling OpenCV functions), and you could be interested in the virtual address space of your current process. On Linux you might use proc(5) and read and parse /proc/self/statm or /proc/self/stat or /proc/self/status. If your process has pid 1234, you could also try cat /proc/1234/maps ijn an other terminal, or use pmap(1). On other operating systems, you'll need to dive into their appropriate documenation.
If you only care about the memory directly used by the JVM, use the Runtime class as answered by Hans.
BTW, your JVM has a garbage collector, and so defining what exactly is the amount of memory used is not trivial.
With respect to "setDomainEnv.cmd" file for weblogic server (10.3.6), what is the difference between the memory argument set by "set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx1024m" and the argument provided by "set EXTRA_JAVA_PROPERTIES=-Xms512m -Xmx512m".
I don't have that EXTRA_JAVA_OPTIONS being set anywhere in my setDomainEnv.cmd. That said, generally the last memory argument is what gets used if it's set twice:
Duplicated Java runtime options : what is the order of preference?
Are you sure there's not an if/else somehow wrapping both of those values? When you start your server Weblogic will check for 32-bit vs 64-bit and a Sun jvm vs. an Oracle jvm to determine what the memory arguments should be.
I have 24 GB of RAM on my PC, but sometimes when Netbeans compiles my projects, it says not enough memory to compile it, I looked at the memory useage, it shows : 586/590 M.
So how to tell Netbeans, there are plenty of RAM, use as much as you need ?
In the etc directory under your Netbeans-Home, edit the file netbeans.conf file.
-Xms and -Xmx should be increased to the values that allow your program to compile.
Here are the instructions in netbeans.conf:
# Note that default -Xmx and -XX:MaxPermSize are selected for you automatically.
# You can find these values in var/log/messages.log file in your userdir.
# The automatically selected value can be overridden by specifying -J-Xmx or
# -J-XX:MaxPermSize= here or on the command line.
Put the values in the netbeans_default_options string. Here is mine (remove linebreaks, added for readability):
netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m
-J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true
-J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true
-J-Dsun.zip.disableMemoryMapping=true -J-Dsun.awt.disableMixing=true
-J-Dswing.aatext=true -J-Dawt.useSystemAAFontSettings=lcd --laf Nimbus"
EDIT: -J-Xms sets the minimum Java heap size, -J-Xmx sets the maximum Java heap size.
I am getting out of memory errors when doing compile time weaving. As you can see, I have already set the Xmx (via maxmem) to 1024m. This could be due to the jar I am trying to weave is ~70MB.
How do I set the Garbage Collector? I tried using the X param but when I connect to the process with JConsole the ConcMarkSweep is not set.
<echo message="Weaving..."/>
<aspectj:iajc classpathref="compile.libs" aspectpath="${src.dir}" outJar="${output.jar}" fork="true" maxmem="1024m" X="+UseConcMarkSweepGC">
<inpath>
<pathelement path="${classes.dir}"/>
</inpath>
</aspectj:iajc>
The error is:
Bugs for exceptions thrown have titles File:line from the top stack,
e.g., "SomeFile.java:243"
If you don't find the exception below in a bug, please add a new bug
at http://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
To make the bug a priority, please include a test program
that can reproduce this exception.
GC overhead limit exceeded
when weaving classes
when weaving
when batch building BuildConfig[null] #Files=0 AopXmls=#0
GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
at org.aspectj.apache.bcel.classfile.ConstantPool.copy(ConstantPool.java:69)
at org.aspectj.apache.bcel.generic.ClassGen.<init>(ClassGen.java:161)
at org.aspectj.weaver.bcel.LazyClassGen.<init>(LazyClassGen.java:255)
at org.aspectj.weaver.bcel.BcelObjectType.getLazyClassGen(BcelObjectType.java:523)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1742)
at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1710)
at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1472)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1286)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435)
at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterCompiling(AjPipeliningCompilerAdapter.java:304)
at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspectj_ajdt_internal_compiler_CompilerAdapter$2$f9cc9ca0(CompilerAdapter.aj:73)
at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:430)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1003)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:267)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:181)
at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:112)
at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
at org.aspectj.tools.ajc.Main.run(Main.java:355)
at org.aspectj.tools.ajc.Main.runMain(Main.java:234)
at org.aspectj.tools.ajc.Main.main(Main.java:84)
23-Sep-2013 23:58:12 org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to D:\Projects\Delete\AspectjTest\.\ajcore.20130923.234357.932.txt
1 fail|abort
a workaround would be to use the <java> ant command, and list the main weaver class as the thing that runs. org.aspectj.tools.ajc.Main, you would also have to set all the args manually that this ant task does automatically.
I got it using it via ANTs exec task calling the aspectj1.7/bin/ajc.bat (1.7.3) with args.
Just editing ajc.bat and replacing -Xmx64g by -Xmx3g helped me trying to apply it e.g. on the guava-18.0.jar.
Similarly it was also mentioned here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36234#c3
if you wan't to use the aspectj:iajc task nevertheless you should run your ant.bat (or sh) with the appropriate JVM args as above.
Within Eclipse (it happens normally within the Eclipse VM and in case it is not appropriately configured and you don't wanna make the JVM arg changes in the eclipse.ini file) you would need to adjust the implicitely created External Tools Configuration for your ANT target and set JRE => Runtime JRE: [x] Separate JRE: ... and adjust its VM arguments: -Xmx3g e.g..