Don't return service in list of profilable JVM processes

[Byte-Lab]

Currently when you query a service for a list of JCozVMDescriptors, it also sends itself as an available process. We should not include the service in this list.

[Byte-Lab]

Hey @RichardH92 , I'm working on getting the build system working in #17 so we can easily build and run JCoz. Once that's done, this might be a good starter bug for you

[Byte-Lab]

The basic idea here is that when the RMI service uses the VirtualMachine API to find a list of processes (see https://github.com/Decave/JCoz/blob/master/src/java/src/main/java/com/vernetperronllc/jcoz/service/JCozServiceImpl.java#L68), it should not return itself in that list. We are also going to need a way to determine which of those services is running with the JCoz native agent and only return those rather than any other JVM process.

[Byte-Lab]

Note that #24 is slightly different from this bug because we should not be returning the same RMI service even if for some reason it is being profiled by JCoz.

[RichardH92]

So, I have been researching. I think to accomplish this and the other related issue #24, we will need to use System.setProperty("process.unique.id", uniqueId); to assign the processes a unique PID.

Then, when calling VirtualMachine.list() we will know which process is which.

https://gist.github.com/deckerego/7826661

[Byte-Lab]

Nice, that should work. You'll have to figure out how to call it (or something equivalent) from the native JVMTI layer. Something along the lines of http://www.hildstrom.com/projects/jni/index.html should work. You don't have to create the JNI environment - you can just call it from here: https://github.com/Decave/JCoz/blob/master/src/native/entry.cc#L229. Hopefully the SecurityManager won't get in your way.

Also, let's name the property something unique to JCoz, like System.setProperty("process.jcoz.enabled", JNI_TRUE); just to keep namespaces separate.