Bugzilla – Full Text Bug Listing
| Summary: | [launcher] Invalid JVM options are silently ignored | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Daniel Serodio <eclipse.dserodio> |
| Component: | Launcher | Assignee: | Project Inbox <equinox.launcher-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, jevon, Jim.Adams, mober.at+eclipse, psolanki, Silenio_Quarti, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Daniel Serodio
If we had known invalid arguments got ignored when jni launching then we could have just added the -XX:MaxPermSize=256m and done away with the --launcher.XXMaxPermSize option for the Sun VM. When using the -vm option in the eclipse.ini to point to the java exe the invalid arguments do prevent the launch. I assume something about launching the vm with jni in process is allowing the invalid arguments to be ignored. The Sun and IBM VMs both seem to ignore invalid options when launched this way. When creating the vm we set JavaVMInitArgs.ignoreUnrecognized = true. We do this mostly because it seemed like a good idea at the time. It is trivial to change if we want to. I could be wrong, but I am not 100% confident that this is respected by all vms on all platforms. If we were confident of this, --launcher.XXMaxPermSize could mean set -XX:MaxPermSize when launching via JNI or when we know it is Sun. (Though this is moot if we decide to set ignoreUnrecognized=false). We can't just specify the -XX:MaxPermSize and have it ignored because we don't know that we are always launching via jni. Some platforms (linux.ppc, aix) still have problems with JNI launching and default to using the exe. Sometimes we can just fail to find the jvm shared library and fall back on the exe. Or the user could just specify the exe with -vm. ignoreUnrecognized was set to false in I20071016-1215. This is working fine on all platforms tested except for the Mac. On Mac the vm is failing to start so ignoreUnrecognized has be reset back to true for the Mac and this bug remains open until we can figure out what the problem is on the mac. Don't you just love "write once, run anywhere" ? :-) bug 206614 comment #4 implies the problem on the mac is the -Xdock:icon argument. This together with changes made in bug 173764 suggests to me that -Xdock:icon (and -Xdock:name) is not an actual vm argument, but rather an argument that is processed and removed by the mac java launcher. Which means that the eclipse launcher should consume the -Xdock:icon when it sets the corresponding APP_ICON_%d environment variable. Silenio, can you comment on this? I believe you are right. You need to handle -Xdock:name as well. I think we should reconsider if we really want to do this. We are heading down the path where every argument consumed by any supported java vm's launcher now needs to be consumed by the eclipse launcher. I can see more bugs like bug 208671 coming up and needing changes. This is a catch 22. On one hand we would like to know when there is an argument the java launcher is consuming because we would like to mimic the behavior if possible. On the other hand it will force use to know about and possibly support all arguments consumed by any supported java vm's launcher. Is there an option to ignore loudly? ;) Meaning allow the vm to load but print (ideally log) an error message? I have reverted this for now and we are once again ignoring unrecognized options. I will investigate logging or printing a message if the vm will tell us it didn't recognize the argument. Otherwise, I think a option to turn this on or off is in order. To me, it seems that knowing about unrecognized VM options is something that's relevant to product builders, commandline users or power users. As an end user, I don't necessarily want to know whether my VM just silently swallowed an option. Perhaps a --launcher.noJNI option as suggested in bug 188616, along with appropriate documentation that this is good during development / testing but not for deployment, might be an acceptable mitigation in the short term. Since that would force using the java.exe and thus also enable messages about unrecognized vmargs. Or, an explicit switch for enabling/disabling messages about unrecognized vmargs. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |