I want to mmap to a file or a block device.
So, I modified HotSpot code, function named commit_memory_impl() to be without MAP_ANONYMOUS.
However, JVM failed with SIGSEGV.
If I append the MAP_ANONYMOUS, it works.
Should I use mmap with MAP_ANON? in JVM?
If you want to mmap a file I would use the built in libraries to do this.
Note: This is limited to less than 2 GB at a time however if you use reflection like Chronicle-Bytes does, you can map 63-bit regions.
This doesn't require you to modify the JVM.
Related
when use the heap dump of visualVm, there is an option to see all the instances of a specific class, but when the instances is to much, i got this error:
out of memory in heap walker：
To avoid this error，increase the -Xmx value in the etc/netbeans.conf file in NetBeans IDE installation directory.
But the error should have nothing to do with the netbeans.conf, it should be something like a visualVM.conf file. And I also did not find the configuration file in my jdk. So how can i solve this error?
There are two solutions for this :
1.using command line to start the JvisualVM, e.g: jvisualvm -J-Xms1024m -J-Xmx2048m
2.update the properties in %JDK_HOME%\lib\visualvm\etc\visualvm.conf
Option 1 is more convenient and recommended
Is there a free JVM implementation that allow to see the content of the different parts of the Java Virtual Machine (e.g., callstack, heap) and execute a program step by step?
Once the JIT compiles the bytecode to native code, the VM registers and stack have little meaning.
I would use your debugger to see what the Java program is doing line by line. The bytecode is for a virtual machine, not an actual one and the JVM doesn't have to follow the VM literally, only what the program does.
The JIT can
use the many registers your CPU has rather than use a pure stack.
inline code rather than perform method calls.
remove code which it determines isn't used.
place objects on the stack.
not synchronize objects which are only used in a local method.
A good tool to see how the code is translated from byte code to machine code is JITWatch
I am hacking OpenJDK7 to implement an algorithm. In the process of doing this, I need to output debug information to the stdout. As I can see in the code base, all printings are done by using outputStream*->print_cr(). I wonder why printf() was not used at all?
Part of the reasons why I'm asking this because I in fact used a lot of printf() calls. And I have been seeing weird bugs such as random memory corruption and random JVM crashing. Is there any chance that my printf() is the root cause? (Assume that the logic of my code is bug-free of course)
why printf() was not used at all?
Instead of using stdio directly, HotSpot utilizes its own printing and logging framework. This extra abstraction layer provides the following benefits:
Allows printing not only to stdout but to an arbitrary stream. Different JVM parts may log to separate streams (e.g. a dedicated stream for GC logs).
Has its own implementation of formatting and buffering that does not allocate memory or use global locks.
Gives control over all output emitted by JVM. For example, all output can be easily supplemented with timestamps.
Facilitates porting to different platforms and environments.
The framework is further improved in JDK 9 to support JEP 158: Unified JVM Logging.
Is there any chance that my printf() is the root cause?
No, unless printf is misused: e.g. arguments do not match format specifiers, or printf is called inside a signal handler. Otherwise it is safe to use printf for debugging. I did so many times when worked on HotSpot.
I have 2 processes, and I would like one of the processes to talk to the other one with a high data throughput. I have tried IPC(boost::iterprocess specifically) and sockets but their performance/throughput is too slow to use.
My fallback option is to launch the 2nd process as an attached child of the first(load its dll, create the 'tool', etc), which has the best performance, as they are technically the same process at that point, and passing data is just calling the interface functions with the DLL.
I'm looking for ways to avoid doing it like this but still have that degree of performance. Is it possible to set up a DLL that 2 processes can load and somehow share memory space between? Are IPC and sockets the only options here?
On windows, you can use named pipes. They were once considered more efficient than sockets when used locally. They've gone out of vogue however. You can learn more here microsoft docs on named pipes
What is "IPC" in your question? Sockets, pipes, shared memory are all ways to do IPC. And yes, you can use shared memory on Windows, Linux and other general-purpose systems. In C++ you can just declare a memory block as shared (at least on Windows) or you can call Memory Mapped File (MMF) functions. On Linux and BSD you use Memory Mapped File functions as well.
MMFs are the fastest possible way besides transforming a second process into the DLL. Named pipes and anything else is slower.
For local processes you can use a shared file. If you memory map the file it would be much faster.
My application is experiencing cashes in production.
The crash dump indicates a SIGSEGV has occurred in GCTaskThread
It uses JNI, so there might be some source for memory corruption, although I can't be sure.
How can I debug this problem - I though of doing -XX:OnError... but i am not sure what will help me debug this.
Also, can some of you give a concrete example on how JNI code can crash GC with SIGSEGV
EDIT:
OS:SUSE Linux Enterprise Server 10 (x86_64)
vm_info: Java HotSpot(TM) 64-Bit Server VM (11.0-b15) for linux-amd64 JRE (1.6.0_10-b33), built on Sep 26 2008 01:10:29 by "java_re" with gcc 3.2.2 (SuSE Linux)
EDIT:
The issue stop occurring after we disable the hyper threading, any thoughts?
Errors in JNI code can occur in several ways:
The program crashes during execution of a native method (most common).
The program crashes some time after returning from the native method, often during GC (not so common).
Bad JNI code causes deadlocks shortly after returning from a native method (occasional).
If you think that you have a problem with the interaction between user-written native code and the JVM (that is, a JNI problem), you can run diagnostics that help you check the JNI transitions. to invoke these diagnostics; specify the -Xcheck:jni option when you start up the JVM.
The -Xcheck:jni option activates a set of wrapper functions around the JNI functions. The wrapper functions perform checks on the incoming parameters. These checks include:
Whether the call and the call that initialized JNI are on the same thread.
Whether the object parameters are valid objects.
Whether local or global references refer to valid objects.
Whether the type of a field matches the Get<Type>Field or Set<Type>Field call.
Whether static and nonstatic field IDs are valid.
Whether strings are valid and non-null.
Whether array elements are non-null.
The types on array elements.
Pls read the following links
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/html/jni_debug.html
http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmtq
Use valgrind. This sounds like a memory corruption. The output will be verbose but try to isolate the report to the JNI library if its possible.
Since the faulty thread seems to be GCTaskThread, did you try enabling verbose:gc and analyzing the output (preferably using a graphical tool like samurai, etc.)? Are you able to isolate a specific lib after examining the hs_err file?
Also, can you please provide more information on what causes the issue and if it is easily reproducible?