More reliable compressed-oops patch for JOL and some simple improvements [Patch Linked]

Serkan ÖZAL serkanozal86 at hotmail.com
Wed Sep 10 07:41:32 UTC 2014


Yes, we need to attach to the process. 

As far as I know and seen from the code there is no way.
Because these offsets are not defined as public member and they are getting from JVM process by reading symbols on dynamically loaded jvm library (dll, so, etc …)

I had many previous attempts to get them without attaching but I couldn’t find a way :(.
But I will look it again to find if there is another way without attaching.

For current Hotspot SA solution, on my application, I create a new process with same classpath of current process and attach this process to caller process as Hotspot SA agent. Then I get compressed-oops informations and then back to caller process via pipeline between processes.

https://github.com/serkan-ozal/jillegal/blob/master/src/main/java/tr/com/serkanozal/jillegal/util/HotspotJvmInfoUtil.java

By the way, when a Hotspot SA agent attaches to JVM process, attached application is suspended. So instead of attaching to itself, I create another process for attaching to current process.

Currently I have no other solution idea and all your suggestions are welcome.

—

Serkan ÖZAL


On 10 Sep 2014, at 10:28, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 09/10/2014 11:18 AM, serkan özal wrote:
>> As I seen, there are two problems/disadvantages with Hotspot SA:
>> * Process attach problem on MacOSX
> 
> Do we really need to attach? Can we just poke the named constant from SA
> jar? Asking seriously since I haven't looked what's in there.
> 
>> * "sa-jdi.jar" version must be same with current JVM version. For
>> example, if the program is run on Java 7, "sa-jdi.jar" for Java 7
>> must be used. "sa-jdi.jar" of Java 6 is not work on Java 7. But to be
>> sure, I will check it again.
> 
> Well, that is the whole point of SA, right? We pack the internal VM
> information in a separate JAR, which we can then reference from Java.
> 
>> However there are three advantages of Hotspot SA:
>> * We can always be sure that we get right compressed-oops values since they are directly taken by JVM
>> * For future works, Hotspot SA gives us more opportunities to play on JVM :)
>> * Less complex code 
> 
> Yes.
> 
> -Aleksey.
> 
> 



More information about the jol-dev mailing list