Metaspace OOME



how can I investigate an OOME?


XX:MaxMetaspaceSize=[size] we can set the Metaspace upper bounds.

However, in case the MetaspaceSize extrapolates an OutOfMemory error.

GC only removes objects that are no longer in use. The GC process is triggered when the max size is reached. Metaspace by default auto increases and keeps meta-information about loaded classes. Instances of the class Class are in the regular heap.

Investigating Metaspace OOME

How to investigate:
~Do a heap dump and analyze it with Eclipse MAT. Look at the classes you have loaded. Check if there's something unexpected, especially duplicate classes. It also has a classloader explorer.


Issues on Metaspace ~ OOME
The main cause for the java.lang.OutOfMemoryError: Metaspace are one of the following:

~ too many classes:
   For dynamic languages, this might happen.

~too big classes being loaded to the Metaspace:
    A classloader leak happens when an application is redeployed, but there are lingering instances of the previous deployment’s classes left.

You can use MAT for investing those kinds of issue, and acquiring a heap dump to analyze. But on this case, the heap should be dumped after at least one ClassLoader instance has leaked. You can then analyze it with Eclipse Memory Analyzer ~ MAT.
There is a through explanation on details [1].



Classloader leaks I – How to find classloader leaks with Eclipse Memory Analyser (MAT)

Audit log ~ EAP


Quick note for JBoss ~ enabling Audit log

The audit log can be used ~ as the name says ~ to Audit information as who and when are logging. The original reference is here.

Audit log xml:

The following XML can be used as a model:

                <json-formatter name="json-formatter"/>
                <file-handler name="file" formatter="json-formatter" relative-to="" path="audit-log.log"/>
            <logger log-boot="true" log-read-only="false" enabled="true"> 
                    <handler name="file"/>


The output will be on the file:


Logger configuration ~ three configurations

JBoss Audit log has three configuration modes – that basically will filter the amount/type of data that will be recorded, as below:

Attribute Description
enabled true to enable logging of the management operations
log-boot true to log the management operations when booting the server, false otherwise
log-read-only If true all operations will be audit logged, if false only operations that change the model will be logged


Btw: log-read-only when is used, increase the overhead considerably, since there are many operations that happen every 15s/20s in EAP.


CLI command for the configuration attributes above:

cli-command#  /core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

cli-command#  /core-service=management/access=audit/logger=audit-log:write-attribute(name=log-boot,value=true)

cli-command#  /core-service=management/access=audit/logger=audit-log:write-attribute(name=log-read-only,value=true)


I work at Red Hat with EAP.

TCP Dump Linux



Understanding bugs on Java/Python is quite interesting, but sometimes we have issues with the network. On those cases, we have the tcpdumps to help:

TCP Dump

tcpdump basically is a common packet analyzer that runs under the command line, as in:


        #sudo tcpdump -D

Btw, reading is much more difficult than actually capturing the data.

For only IPV6 traffic you can use:

#tcpdump ip6

For HTTPS get/post dump, the command is here:

 sudo tcpdump -s 0 -v -n -l | egrep -i "POST /|GET /|Host:"

Some examples can be found here






Oracle Release notes

The compiler in the server VM now provides correct stack backtraces for all “cold” built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled.

After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: 




Well, there is a JVM optimization (OmitStackTraceInFastThrow, which is on by default) which optimizes “built-in” exceptions that are thrown frequently enough to be cached and have to stack trace. So somebody at one point thought that was a worthwhile optimization and allocated engineering resources to it.



Interesting English words


anomaly: unexpected

equivocal: not easily understood or explained

lucid: unambiguous

assuage: less intense


laudable: admirable

pedant: excessive display of learning, show off

vacillate: fluctuate

capricious: temperamental

engender: generate, provoke

loquacious: talkative

apathy: lack of enthusiasm

corroborate: confirm, verify, authenticate

ephemeral: transitory, momentary

laconic: use a few words












Oracle JDK usagetracker



On Oracle JDK you have this usage tracker that can record information about the JDK usage. It’s quite interesting and useful for debugging and profiling Java applications.

Usage Tracker

It’s a usage tracker – i.e a file with several details about usage. The values are in ” ” and separated by commas (default, you can change this configuring additional options)


Usage Tracker Output

An example of the output is below:

"javaws application",
"Mon Feb 01 14:52:58 PST 2016",
"Oracle Corporation",
"Oracle Corporation",
"Windows 7",

The example above is output and shows several details about the usage, including the architecture, x86, the JDK, the JRE version/location, the OS, in one file.

To enable Usage Tracker

  1. First option: create – as follows:
# UsageTracker template properties file.
# Copy to <JRE directory>/conf/management/
# (or <JRE directory>/lib/management/ for
# JRE releases prior to 9) and edit, uncommenting required settings, to enable.
# Settings for logging to a file:
# Use forward slashes (/) because backslash is an escape character in a
# properties file.
# = ${user.home}/.java_usagetracker

# Settings for logging to a UDP socket:
# = hostname.domain:32139
# (Optional) Specify a file size limit in bytes:
# = 10000000
# If the record should include additional Java properties,
# this can be a comma-separated list:
# = 
# Additional options:
# = true = , = " = '


  1. Second option: apply directly on <file in the central file system location>
java MyApplication


Additional options

The options below, are for the file output itself.

# Additional options:
# = true = , = " = '


Up to my knowledge, at this moment, the OpenJDK version is not ready yet. Ofc, I might be wrong. The is the Jira bug.