3

I've got a Windows server with a third-party application on it that runs as a Windows service. The service/application is actually a java virtual machine however it displays in task manager as an exe (let's call it foo.exe).

I know that the program is designed to pick up JVM heap size allocation preferences from the registry and I know where in the registry it's looking for that information. That being said, I'm not sure if an admin edited the registry before (or after) starting the service.

Since this is a production system, I'm reluctant to restart the service (especially if it's already using the heap allocation values I'm seeing in the registry now). Is there any other way I can tell WITHOUT restarting the service? I suppose I could look at the currently use memory in task manager but that wouldn't provide the exact values.

Mike B
  • 11,570
  • 42
  • 106
  • 165

3 Answers3

2

Show the command line column in task manager, which should have the settings assuming they were passed on the command line:

task manager

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Thank you for the excellent suggestion however it doesn't appear to be passed in the command line as it reads `"C:\Program Files (x86)\Foo Vender\Foo.exe"` in the command line column. :-( – Mike B Dec 05 '14 at 01:16
2

Note that the below answer might require JMX to be enabled - I believe it's disabled by default in public JRE, and requires a restart of the JVM to change it, which would be rather useless in your case. Still, worth a shot?

Whether they work or not will also depend on the specific native wrapping method used by this application.

You should be able to copy these tools along with jli.dll from a JDK with a matching minor version and architecture to the JRE you're running. You could also run the tools remotely, though that's less likely to work without some initial set up due to the security requirements for remote connections.


The jps tool, available in the JDK, should be able to provide this information with the command jps -v. If you have multiple Java processes running, you can identify them by the PID in the first column.

Example output on Netbeans (PID 9056) (which uses a native wrapper similar to your application):

9056  -Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade -Dnetbeans.accept_
license_class=org.netbeans.license.AcceptLicense -client -Xss2m -Xms32m -XX:Perm
Size=32m -Dapple.laf.useScreenMenuBar=true -Dapple.awt.graphics.UseQuartz=true -
Dsun.java2d.noddraw=true -Dsun.java2d.dpiaware=true -Dsun.zip.disableMemoryMappi
ng=true -Xmx1024m <snip>

Notice the -Xss, -Xms and -Xmx arguments.


Another thing you can try is jinfo, which allows you to target a specific PID, e.g. jinfo 9056.

NOTE - This utility is unsupported and may or may not be available in future versions of the JDK.


You could also try jconsole and jvisualvm, though they seem to have trouble attaching to wrapped JVMs and listing VM arguments, from my testing.

Bob
  • 1,536
  • 12
  • 17
1

Look under the "C:\Program Files (x86)\Foo Vender" for any text file that contains the strings -Xms and -Xmx - it could be pulling the values from an INI file. If there aren't any, it's probably getting them from the registry somewhere, as you surmised. One of my clients uses a web proxy that runs as a Windows service and gets it startup parameters from a reg key that it installed.

If you want to confirm exactly what files or registry keys are being read during startup of the EXE, use ProcMon from Sysinternals while you start the service.

mfinni
  • 35,711
  • 3
  • 50
  • 86
  • Thanks. I know for a fact that it's being read from the registry and have found the section in the registry where that's at. I'm wondering how I can confirm from an OS standpoint that the program is actually honoring/using the values in the registry. I'll try to rephrase my question to be more clear. Thanks for the prompt response. – Mike B Dec 05 '14 at 01:35
  • I updated the question to hopefully make my question more clear. Thanks again for the prompt response. – Mike B Dec 05 '14 at 01:44