db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Hlavaty <hla...@code.cz>
Subject JVM bug workarounds - Was: release status as of 9/12/2004
Date Thu, 14 Oct 2004 09:20:33 GMT
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.*).


View raw message