JVM bug workarounds - Was: release status as of 9/12/2004

[Jan Hlavaty <hl...@code.cz>]

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

Re: JVM bug workarounds - Was: release status as of 9/12/2004

[scott hutinger <s-...@wiu.edu>]

Just for information:  OOo (OpenOffice) and the OS X version using 
alternate UI's has had problems with java specific problems.

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
>  
>