Is there a feature like Finding which methods allocated large objects for Sun JAVA?
-Xdump:stack:events=allocation,filter=#1k
or
-Xdump:stack:events=allocation,filter=#2m..4m
I'm not sure there is a way to do this with just command lines to the JVM, but you should be able to use hprof to dump the heap, and then analyze the dump using jhat to find the large objects and where they were allocated (assuming they are still in the heap when hprof dumps it).
You can use hprof to dump the heap like so:
java -agentlib:hprof=heap=dump
This will give you a file .hprof, then you can run jhat:
jhat <pid>.hprof
jhat will run a webserver at:
http://localhost:7000.
So point your browser there and take al ook.
Also a native way to do this exists via Java agent: code.google.com/p/java-allocation-instrumenter – Martin Jun 6 '13 at 3:26 see also How to find all referrers of an object in Java?
Related
I am working on an old internal project. I am working on windows. The puredata I am using is on 32bit.
There are some objects like [mtx_*~] [mtx_:] [mtx_.^] [mtx_circular_harmonics] have "couldn't create" error.
I have iemmatrix installed through "find external".
I tried older versions of Puredata extended or several versions of vanilla. I can't create mtx_, either.
From pd/externals/iemmatrix, I can find a file called "mtx_0x2a0x7e.dll", which I think is "mtx_~" after decoding.
There is not much information on the internet about it anymore.
The "official" version (not the one with the 'extended' suffix) is compiled as a multi-object library. So you have to load the library first, either with a command line flag '-lib iemmatrix' or with a [declare -lib iemmatrix] object in your patch (The latter is much preferred as it makes your patch more portable). When loaded, iemmatrix prints a greeter to the Pd console window:
iemmatrix 0.3.2
objects for manipulating 2d-matrices
(c) 2001-2015 iem
IOhannes m zmölnig
Thomas Musil
Franz Zotter
compiled Sep 6 2019 : 12:07:54
After that you can create objects like [mtx_*~]
The version 'v0.0-extended' was added to facilitate the migration away from now retired Pd-extended. Since it is compiled as a one-object-per-file library and many of the those objects have names that cannot easily be used in filenames, Pd-extended used a trick with an additional hexloader library that translates hex encoded filenames to the actual name of the objects. For being able to load objects from the extended version, you would have to install and load 'hexloader' first.
Having said that, it is highly recommended to use the official version which is actively maintained while the extended version is not and is there for historical reasons.
I would like to get the NIC driver 64bit statistics in userspace, in the simplest way possible.
The man page of API function getifaddrs(), suggests a simple example program that does it using 32bit "struct rtnl_link_stats" (possible to see it here for example: http://man7.org/linux/man-pages/man3/getifaddrs.3.html).
The problem with this struct is obvious: the 32bit variables wrap-around (exceed 2^32) quickly (e.g. "rx_bytes").
In the same header file (linux/if_link.h) that contains struct rtnl_link_stats, there is a similar struct with 64bit variables: struct rtnl_link_stats64.
I was sure that I'm very close to have the same statistics on 64bit variables, but unfortunately, I failed doing so.
There are functions like dev_get_stats(), but they are all written for kernel-space.
Programs like "ethtool -S" show these statistics in 64bit values, but I think they do some manipulation and not fill up struct rtnl_link_stats64 in a simple way.
Reading directly from /sys/class/net/ethX/statistics/rx_bytes (using fopen, fscanf...) is ok, but it doesn't perform as good as reading using API.
Is there a simple way in userspace to have struct rtnl_link_stats64 filled with the relevant statistics, that I miss?
Apparently, the best (performance wise) way I found is using netlink APIs from library libnl.
Here is a link to a simple example program that I found, that implements it:
https://gist.github.com/beejeebus/cc4fb07472cf5a0afd41
I have a running Scala process and want to get the contents of a List in that process. I know the PID of the process and I know the name of the List[String], and I have taken a heap dump with VisualVM. Is there a way for me to find the actual contents of that specific list and save it somewhere?
If the List[String] instance is referenced by a class (for example via a val) than you can look for the class that holds it.
You can download Eclipse Memory Analyzer (MAT) and open your heap dump.
You can then click the 'Dominator tree' and in the top of the table you can type the name of the class that holds your list.
If you have found the class right-click it and select 'List objects -> With Incoming References`, that should give you the instances of the class that all could potentially hold the list.
Right click one of the instances and select 'List objects -> With Outgoing References', that should give you a tree structure where you would find your list
Note that once you find your list, you can check out the panel on the left (the inspector panel), that contains readable information.
Note: the above steps are from the top of my head, so they might not be completely accurate. This should however give you a good sense of direction.
Good luck!
I'm sure in principle it is possible, but surely there's nothing simple or straightforward and off-the-shelf to allow you to do so.
I'd probably go with using the Java Platform Debugger Architecture (JPDA) and its Java Debugging Wire Protocol (JDWP) to get at the raw information you'd need. From there you can use Java and / or Scala reflection to discover what to query in the target JVM.
I don't know how much of this is applicable to heap dumps. In the old days, the C / Unix debugging tools could operate on either core dumps or active processes.
I have an OpenCL kernel that runs well but I want to look at the intermediate code. I use getprograminfo to pull out the binary and save it to a text file. I've tried this with nVidia, AMD, an i7 and a Xeon.
In all of these cases the binary is unreadable.
I understand that on OS X the chunk of data returned is actually a binary plist. I've found instructions for using plutil to convert it to xml, and they work.
It's still unreadable ... though I've seen instructions online that this is where you find the PTX code (in the case of my AMD 5870). There's the expected clBinaryData key but the data under that key is still one big chunk of stuff, not readable IL instructions in text form.
I'd really like to examine the intermediate language to assess inefficiencies in my use of the gpu. Is this simply not possible under Xcode? Or, what am I doing wrong?
Thanks for any information!...
If you run your program with following environmental variable set you should see .IL and .ISA files in your directory.
$ GPU_DUMP_DEVICE_KERNEL=3 ./my-program
Another way is to use AMD APP Kernel Analyzer (which comes along with AMD APP SDK) to look at the Intermediate file i.e IL and ISA.
(I am not sure whether AMD APP SDK available for MAC or not).
One more option according to APP SDK documentation, put the below in your host code.
putenv("GPU_DUMP_DEVICE_KERNEL=3");
References
AMD OpenCL Programming Guide
AMD Devgurus forum
(Making this a top-level answer so I can do some formatting.)
ocluser's answer was very helpful, in that it was enlightening and caused great learning, though it did not, alas, solve the problem.
I've verified that the environment variable described is being set, and is available to my application when run from within xcode. However, it does not have (under OSX) the highly desirable effect it has under Linux.
But, I now know how to set environment variables in 7 of 8 different ways. I also set "tracer" envars to tell me which methods are effective within the scope of my application. From the below, you can see that both the method of "edit scheme" to add arguments works, as does the "putenv" suggested by ocluser. What didn't set it in that scope: ~/.MACOS/environment.plist, app-specific plist, .profile, and adding a build phase to run a custom script (I found at least one other way within xcode to set one but forgot what I called the tracer and can't find it now; maybe it's on another machine....)
GPU_DUMP_DEVICE_KERNEL is 3
GPU_DUMP_TRK_ENVPLIST is (null)
GPU_DUMP_TRK_APPPLIST is (null)
GPU_DUMP_TRK_DOTPROFILE is (null)
GPU_DUMP_TRK_RUNSCRIPT is (null)
GPU_DUMP_TRK_SCHARGS is 1
GPU_DUMP_TRK_PUTENV is 1
... so, no this doesn't really answer the question, but expands on it a bit. Sorry if poor form. Thanks!
Have not given up and shall provide an actual problem-solver if I find one.
I'm trying to run an algorithm that requires a few hundred megabytes of memory within eclipse, and I've specified VM arguments -Xmx512m, but I can't get past some arbitrary memory limit which seems to decrease as I continually try to run my programs. Physical memory is fine...what could be the issue?
Eclipse takes VM arguments, but those are for the Eclipse platform itself, you need to modify the applications Launch Configuration to ensure it has enough memory.
When you run a program within Eclipse it creates a new Launch Configuration with default parameters. You can modify those parameters by selecting Run->Run Configurations.. (or Debug->Debug Configurations...), then select the relevant configuration. If it is a Java main app, the configuration will be under Java Application, probably with the name of the class or project you selected when you first ran it.
Select the launch configuration, then the Arguments tab, then enter the relevant JVM arguments (i.e -Xmx512m) in the VM arguments pane. You can also enter Program arguments to pass to the main method if you wish.
(source: modumind.com)
Update: another parameter to try passing is -XX:MaxPermSize=128m, if your algorithm is creating lots of method and/or class objects (which sounds like it is the case).
Look at the arguments -Xms too. Be sure that the argument is specify to your Run mode ( Run / debug).
If you still have some problem, you can use a profiler to see what happen in memory, or just logging the Runtime.getRuntime().freeMemory() can help.
You should ensure that you are specifying the arguments for your test application in the Run Dialog, and not in arguments to Eclipse itself.