New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tools like jstack not working with OpenJDK 8-OpenJ9 #1621

Open
DanHeidinga opened this Issue Apr 5, 2018 · 17 comments

Comments

Projects
None yet
7 participants
@DanHeidinga
Contributor

DanHeidinga commented Apr 5, 2018

Issue was raised at Adopt: AdoptOpenJDK/openjdk-build#292

Should we support the OpenJDK J* diagnostic tools?

@DanHeidinga

This comment has been minimized.

Contributor

DanHeidinga commented Apr 5, 2018

FYI @Param-S - I've raised the question here at OpenJ9 for further discussion.

@Param-S

This comment has been minimized.

Contributor

Param-S commented Apr 6, 2018

apache/incubator-openwhisk#3504 Project is interested to use AdoptOpenJDK OpenJ9. But, there is some resistance due to the community is more familiar with J* diagnostics tools.

@ashu-mehra

This comment has been minimized.

Contributor

ashu-mehra commented Apr 6, 2018

There was some discussion last year here #350

@DanHeidinga

This comment has been minimized.

Contributor

DanHeidinga commented Apr 6, 2018

@Param-S which J* tools are they using? Are some essential for their workflows?

@DanHeidinga

This comment has been minimized.

Contributor

DanHeidinga commented Apr 11, 2018

Two pieces of data we need:

  • The top used / most important j* tools - allowing us to prioritize the implementation plan
  • Any data on tool lifecycles - are the any of the tools deprecated / removed in later OpenJDK releases?

We don't want to implement tools that will be removed shortly.

@DanHeidinga

This comment has been minimized.

Contributor

DanHeidinga commented Apr 13, 2018

https://docs.oracle.com/javase/9/docs/api/jdk.jcmd-summary.html

Describes the jdk.jcmd module which includes:
jcmd, jinfo, jmap, jps, jstack, jstat

All of the tools are listed as experimental and unsupported... but they've been listed that way for years so I don't think that tells us anything yet.

@Param-S

This comment has been minimized.

Contributor

Param-S commented Apr 13, 2018

If the jcmd is the future and replaces all other command lines tools then we may need to start from it. But the questions is, Does these existing J* tools fall under any specific JEP like http://openjdk.java.net/jeps/137. If the tools doesn't follow any defined spec then whether our effort to make it to work against another JVM implementation is sustainable.

@pdbain-ibm

This comment has been minimized.

Contributor

pdbain-ibm commented Apr 13, 2018

I am under the impression that jcmd uses late attach (i.e. attach API), while the other tools do not. Is that correct?

@ashu-mehra

This comment has been minimized.

Contributor

ashu-mehra commented Apr 14, 2018

Another tool in this space is JDK Mission Control which will likely be open-sourced soon as per http://mail.openjdk.java.net/pipermail/discuss/2018-March/004715.html.

@DanHeidinga

This comment has been minimized.

Contributor

DanHeidinga commented Apr 16, 2018

@ashu-mehra Mission Control is really cool. The historical alternative has been HealthCenter.

I'd like to keep this particular issue focused on which commandline tools to support with OpenJ9 so we don't try to boil the ocean in one go.

@sxa555

This comment has been minimized.

Contributor

sxa555 commented May 29, 2018

Tagging in @cwsolee as she raised AdoptOpenJDK/openjdk-build#345 which I've now closed

@pshipton

This comment has been minimized.

Contributor

pshipton commented Jun 7, 2018

#2112 asked about jstat and jinfo.

@anikser

This comment has been minimized.

Contributor

anikser commented Jun 15, 2018

I briefly looked into each of these commands and how they are implemented in the openjdk extensions:

jps:
jps reads files in hsperf_${username} folder (temp files generated by hotspot, folder is found in /tmp on linux) to get lvmid and other general VM information. This is strictly specific to HotSpot’s implementation. I wasn't sure of the copyright/legal concerns regarding this so I didn't dig too deep in looking into these files' format and contents.

jstack:
jstack uses implementation specific HotSpotVirtualMachine.remoteDataDump. The VM is cast as a HotSpotVirtualMachine before this is called, so even if an equivalent/similar stack dump method by this name is implemented in OpenJ9, some minimal changes would have to be made to the openjdk extensions.

jcmd:
Similar to jstack - vm is cast as HotSpotVirtualMachine before calling implementation specific method HotSpotVirtualMachine.executeJCmd with a parameter that depends on the command option passed to jcmd.

jinfo:
Shortcut for a subset of jcmd commands through an implementation specific VirtualMachine.executeCommand method.

jmap:
Half of the options are shortcuts for jcmd (almost identical to jinfo). Other half are other data dumps that are internally implemented in HotSpot.

jstat
Same as jps (reads from HotSpot temp files)

@pshipton

This comment has been minimized.

Contributor

pshipton commented Jun 27, 2018

Although the default implementation of jps is specific to Hotspot, I don't think it would be hard to create an OpenJ9 implementation. It seems just a matter of calling AttachProvider.listVirtualMachines() and formatting the result.

@anikser

This comment has been minimized.

Contributor

anikser commented Jun 27, 2018

Sorry, I should have been more clear - what I trying to get across was that since the temp files are read in the extensions, it is the extensions that must be changed, and simply implementing an API in OpenJ9 isn't enough (unless we want to implement the hsperf files).

Good to know that this API exists.

@pshipton

This comment has been minimized.

Contributor

pshipton commented Jun 27, 2018

Understood. My point was that in order to provide a jps implementation for OpenJ9 we don't need to run the existing extensions code. We can create a jps implementation that runs different code and has a OpenJ9 specific implementation.

@pdbain-ibm

This comment has been minimized.

Contributor

pdbain-ibm commented Jul 9, 2018

You don't even need OpenJ9 specific code. This code (which I threw together ~10 years ago :-) ) does what you want, I believe (modulo the class name and the verbosity):

import java.util.List;

import com.sun.tools.attach.VirtualMachineDescriptor;
import com.sun.tools.attach.spi.AttachProvider;

public class listvms {

	public static final String LIST_VMS_EXIT = "listVms:exit";


	public static void main(String[] args) {
			listVms();
	}

	
	private static void listVms() {
		List<AttachProvider> providers = AttachProvider.providers();
		AttachProvider ap = providers.get(0);
		if (null == ap) {
			System.err.println("no attach providers available");
		}
		List <VirtualMachineDescriptor> vmds = ap.listVirtualMachines();
		System.out.println("looking for attach targets");
		for (VirtualMachineDescriptor vmd: vmds) {
			System.out.println("id: "+vmd.id()+" name: "+vmd.displayName());
		}
		System.out.println(LIST_VMS_EXIT);
	}

}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment