How to profile into Java serialization in JProfiler - jprofiler

Using JProfiler 7.1 (also tried 7.0) I cannot profile into Java serialization.
I have removed all filters, using dynamic, estimate CPU, profiling.
It seems like it does not profile into any JDK methods?
Not attaching to an existing JVM, JProfiler is launching the test.
Windows, 64bit, jdk 1.6

Related

JProfiler doesn't detect running AdoptOpenJDK 11 openJ9

I'm trying to profile a Java app running with AdoptOpenJDK 11 version OpenJ9.
My problem is that, when I try to attach JProfiler on my app, it doesn't detect the running instance.
I'm using the last version of JProfiler (11.1.4).
Is it compatible with this JRE?
Is there something to do/configure to make it working?
Best regards
As of JProfiler 11.0, attach mode is not supported for OpenJ9 JVMs. Also, attach mode is not enabled by default for OpenJ9.
When passing the -agentpath VM parameter as given by the integration wizards, profiling OpenJ9 JVMs is fully supported.

Mule ESB JDK 1.8 memory tweaks

We are planning on using JDK 1.8 for Mule 3.7 CE.
In the past we edited wrapper.conf to tweak the memory JDK 1.6/1.7 uses. We did this by editing:
wrapper.java.initmemory=256m
wrapper.java.maxmemory=512
wrapper.java.additional.7=-XX:PermSize=256m
wrapper.java.additional.8=-XX:MaxPermSize=512m
Looking into the processes that are running in linux we see that Mule still uses xmx settings. If not mistaken, this no longer works in java 1.8 because it has been removed. Instead JDK 1.8 uses metaspace.
Now my question is, how/where to we make memory tweaks for Mule 3.7 using JDK 1.8? Or does Mule 3.7 CE not support this yet?
Do we simply add to wrapper.conf the following settings?:
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
And remove:
wrapper.java.initmemory=1024
wrapper.java.maxmemory=1024
Or we do still use the following settings?
wrapper.java.initmemory
wrapper.java.maxmemory?
Thanks!
You can keep using the initmemory and maxmemory.
Changing to Java 1.8 doesn't impact this.
We use Java 1.8 with Mule 3.7 in Linux and we are able to successfully control the heap allocation with the current setting of initmemory and maxmemory.
You might want to use Metaspace configuration only to replace PermGen settings.
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
Go through the following link for more understanding.
http://www.infoq.com/articles/Java-PERMGEN-Removed
Hope this helps.

Error while running Jprofile8

I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.

JRE Architecture Dependencies (Running on MIPS)

OpenJDK currently does not have support for a JRE on MIPS processors (there's a port in progress, but who knows how long that will take).
I'm trying to understand how the JRE works, and what is standing in the way of using OpenJDK on our embedded system running Linux on a MIPS processor. If I have a custom JVM that is capable of running on MIPS designed to work with OpenJDK (in this case, I'm referring to JamVM 2.0), is there anything else preventing the JRE from running on the MIPS board? Are any other parts of the JRE platform-dependent?
My understanding is that the JRE is (mostly) composed of two units: the virtual machine, which abstracts the hardware and which is platform-dependent, and the collection of Java libraries which run on the virtual machine and which are not platform-dependent.
To be clear, my questions is: aside from the JVM, is any part of the Java Runtime Environment platform-dependent?
"aside from the JVM, is any part of the Java Runtime Environment platform-dependent?"
That depends on where you place the boundary where the VM ends and the JRE begins. I would consider memory management and code execution as 'the VM', everything more specific part of the JRE.
Thats means every binding to the operating system, be it I/O, Graphics etc. is part of the JRE. Thus the JRE has many platform dependent parts; you usually just don't notice them because your code uses their abstractions (e.g. File, Socket, Window).
So when you say "a port to MIPS" it doesn't mean anything without specifying an OS (ok, your link says Linux); a VM ported to a processor architecture by itself does not make a working java environment. It also requires a port of the native parts of the JRE that allow the java program to actually communicate with things outside the VM; thats where the OS platform comes in.
Since Linux is already supported for x64, the MIPS port should be able to reuse most of the JRE to platform bindings from that.

Forcing 64 bit jvm to 32 bit jvm?

Would anyone please give me ideas about forcing 64 bit jvm to run as 32-bit jvm?
I need to write a jse desktop application for bluetooth connection. For that i need to implement Bluecove jar . It has 32-bit files only. So i included -D32 under VM arguments in eclipse pulsar. But still i am getting the same error that displayed before adding the argument: bluecove_x64.dll missing. I tried with -d32, and it showed me "unrecognized option: d32".
And it seems like i should install a 32-bit jvm that would run on 64-bit os. So, can anyone please tell me what exactly should i install? Java SDK in 32-bit or Eclipse software?
Thanks in advance!
Switching modes is only possible on Solaris. A JVM is either 64bit or 32bit, except on Solaris where both run modes are available in a single JVM.
But anyway, if you don't need more than 4Gig Ram, install the 32bit JVM also on 64bit Systems, because it is 10-15% faster and needs less memory.
First, install a 32-bit JVM. (I suppose this is under Windows).
Then in Eclipse, open the Preferences panel, and go to Java -> Installed JRE's.
Click Search, tell it to search your harddisk.
Wait.
You should now see both your original 64-bit JVM and your new 32-bit JVM in the list. Put the checkmark on the 32-bit JVM instead of the 64-bit JVM. Click OK.
You should now use a 32-bit JVM in Eclipse, which should be compatible with the library you have.