Community
Participate
Working Groups
Right now there is no way for an eclipse plugin to detect whether the jvm being used to launch a java app is a 32 bit or 64 bit jvm. This is especially troublesome for plugins which add say a native jvmtiagent to the launching application, eg profiler plugins, since the native dll will be different for 64 bit and 32 bit jvms. Also a launcher plugin may be able to set the -Xmx value higher if it needs to and detects that the jvm being launched is a 64 bit one (instead of 32 bit)
Not 100% sure but the vm system properties might tell you that.
the vm system properties will tell you about the vm in which *eclipse* is running. they wont tell you about the vm which eclipse is about to use to launch a new application.
How/when would your plug-in use that information? Probably when the code is invoked and hence it could also use the system property.
No. Consider the following situation. My plugin adds a native jvmtiagent to the launch arguments of a program. The jvmtiagent uses a different dll based on whether the program is being launched in a 32 bit or 64 bit vm. This needs to be decided *before* the program is invoked otherwise the jvm will crash if the wrong dll type is passed as the argument, eg 32 bit dll is used for the 64 bit jvm. If I use the system properties to detect the vm type, it only tells me the vm type of *Eclipse*. I want to know the vm type of the program being launched before it is launched and any code executed so that I can pass in the correct jvmti agent. It is because of lack of this api that plugins like Yourkit, etc which use a native jvmtiagent need to be manually specified for every launch config whether the jvm being run on is 32 bit or 64 bit. Addition of the api could also mean that eclipse can detect when the user has mistakenly set -Xmx to a value > 2gb but selected a 32 bit jvm for launch, thus warning the user of the incorrect param.
(In reply to comment #3) > Probably when the code is > invoked and hence it could also use the system property. OK, so you answered that with "no". But what about my first question: "How/when would your plug-in use that information?"? Would you write your own launcher?
> "How/when would your plug-in use that information?"? Would you write your own > launcher? Currently we extend the JavaLaunchDelegate and delegates for other launchers,eg JUnit, to add our own arguments. If we had this api, our delegate would know exactly which dll to add as the argument.
(In reply to comment #6) > > "How/when would your plug-in use that information?"? Would you write your own > > launcher? > > Currently we extend the JavaLaunchDelegate and delegates for other launchers,eg > JUnit, to add our own arguments. > > If we had this api, our delegate would know exactly which dll to add as the > argument. Makes sense. Note, that as a workaround you might simply execute the vm with "-showversion" and grab the information from that output.
> Makes sense. Note, that as a workaround you might simply execute the vm with > "-showversion" and grab the information from that output. Do you mean that during the launch we first do a standalone launch of the vm first with -showversion and then do the actual launch? We have though about this about put this could very negatively impact the speed of launches.
(In reply to comment #8) > > Makes sense. Note, that as a workaround you might simply execute the vm with > > "-showversion" and grab the information from that output. > > Do you mean that during the launch we first do a standalone launch of the vm > first with -showversion and then do the actual launch? Yes, but you could also cache the result by VM. We also have to use that approach to detect e.g. the correct Java version of the VM (and then cache it).
> Yes, but you could also cache the result by VM. We also have to use that > approach to detect e.g. the correct Java version of the VM (and then cache it). Well I guess we both agree that in any case this api should be present and would prove useful. Also I would suggest that instead of running the jvm with -showversion and parsing the output, which can change across jvm versions and vendors, one should actually run a tiny program which actually queries the system property inside the launchee jvm to print exactly whether it is 64 bit or 32 bit.
> Well I guess we both agree that in any case this api should be present and > would prove useful. Right, but it won't be at the top of our list, hence the suggested workaround.
(In reply to comment #11) > > Well I guess we both agree that in any case this api should be present and > > would prove useful. > Right, but it won't be at the top of our list, hence the suggested workaround. Another option could be to fetch the IVMInstall from the launch configuration and execute the IVMInstall3#evaluateSystemProperties(String[], IProgressMonitor) method, which will return a Map of the evaluated system properties AND handle the caching for you. The other benefit is that progress is reported, so any lag in the launch could be reported to the user. I agree new API to determine the 32 / 64 bit status of the VM would be useful. I would envision an IVMInstall4 with getVMArchitecture() (or similar).
(In reply to comment #12) > I would envision an IVMInstall4 with getVMArchitecture() (or similar). Note that AbstractVMInstall has #getAttribute(...) which might be able to be used for this (rather than adding new API).
