Alternate vendors on more non-mainstream architectures probably won't be very likely with the currently template based interpreter ( assembly language templates ) which requires a bit more people hours to bring up a vm without hotspot. Although keep that as 'unlikely', not impossible. This keeps a vendor list smaller...
I also don't really see show stopping VM bugs very common at all. Probably what I am trying to say is, possibly one vendor might have more problems than the norm; due to unknown reasons, due to closed source from that specific vendor.
scott
Jan Hlavaty wrote:
Samuel Andrew McIntyre wrote:
After thinking about this some more, I think the try/catch route may be
the best way to go after all. I think it is in our best interest, as
stated elsewhere, to remain as vendor-neutral as possible. I don't think
that we want to get into the business of endorsing any particular
vendor's JVMs.
I agree endorsing JVMs is a bad thing, but disagree on that try/catch idea. See below.
So, I don't think enabling or disabling a feature based
on a list of vendors to include/exclude is really the best way to fix
the problem, and doing so would set a bad precedent. slippery slope, and
all that.
Include and exclude are very different concepts. Include list is a bad idea, and has the endorsing effect, in addition to the burden of having to add new JVM versions to the list. But exclude list is much better and does not have that effect.
While the try/catch route may not seem like the cleaning solution to the
problem, at least it could fix the issue where it is known to cause a
problem without introducing unnecessary prejudice. So, if in the future
the particular problem is fixed, the feature would be automatically
enabled again, and we're still covered on any system where the JVM/OS
combination still has the problem.
I don't think you can catch all JVM bugs like that. And code becomes cluttered with extraneous tests for the bugs presence, in addition to the necessary workarounds.
You can do much better with exclusion list, which has exact buggy JVM version. With buggy JVM version i mean exact build version of the JVM, as identified by combination of system properties "java.vm.vendor", "java.vm.name" and "java.vm.version". Unknown JVMs should be expected to not have a particular bug. Maybe we could add os.name/os.arch/os.verion, but it is not guaranteed to reflect fixes to OS bugs - so we cannot reliably detect if the OS has a particular bug when the JVM bug is in fact caused by OS bug. That would need an override mechanism, where user could specify that he does not want to have particular workaround enabled.
I imagine a special class (VMVersion?) that would have a static boolean variable or accessor method for each known bug/workaround. In class initializer, it would read a resource with database of known bugs and their respective JVMs, and set corresponding variable to true when a bug is believed to be present on the currently running JVM. There would also be a user configuration file that would allow user override the status of any particular workaround.
When a specific workaround for a bug would be implemented, you would add an entry for workaround in the VMVersion class, and add known buggy VM versions to the buggy vm database resource. Tehn in code you would check the value of the workarounds variable and select the normal/workaround code based on that.
To eliminate any negative effects of workarounds on the performance, a mechanism for selecting different implementation class could be realized, similar to the way Derby handles different JDK versions. In fact, these mechanisms could be one mechanism as different JDK versions can be handled by the very same mechanism as JVM bugs - they both pick implementations based on what JVM they run on - only the properties differ (java.specification.version instead of java.vm.*).
Jan
