Apologies for keeping this thread going but I had a few
points/experiences I thought were worth mentioning. I'm currently
involved in porting Harmony to a VM licensed under the CPL [1] and I've
also been involved in developing a ThreadLocal implementation -
optimization of which was important due to Jython performance. Our
previous weak hash map thread local performed an allocation per get, we
came to a custom weak hash map implementation (via an array that could
reclaim soft references) and, when copyright assignment is in place, the
code should be pushed into GNU Classpath. The primary reason for pushing
the code to GNU Classpath is that this has been historically the class
library we have used, rather than strong convictions on open source
licenses and who the copyright should be assigned to. The reason to push
the code back is to ease maintenance and to benefit the community. The
reason for the implementation was to overcome the allocation problem and
I should probably investigate the performance of an array vs crazy bob's
vs an identity hash map vs weak identity hash map vs weak identity hash
map less any allocations.
On working on the port to Harmony I have found a number of times I need
to work from the DRLVM classes rather than the Harmony ones,
ReferenceQueues being just one example. A problem with the DRLVM classes
is they are poorly documented, so often I've created a hybrid class
combining the implementation from DRLVM with the comments of the main
class library - an exercise is to push these back up to Harmony's class
library [2]. I've been surprised with Harmony how much of the core API
is left for the VM implementor to figure out and fill-in. At FOSDEM
2008's free Java developers meeting [3] we had a discussion about
porting class libraries to VMs, the fruit of which has been an OpenJDK
innovator challenge [4] to at least document what the virtual machine
interface for OpenJDK is. As I understand porting class libraries:
- GNU Classpath has package private helper classes and reference
implementations for the JVM implementor to pick-up and some times
fill-in. A problem with this is moving the interface forward when its
not optimal [5] - ie you may want to fix everyones VM at the same time
as you change the reference implementation.
- Harmony provides stubs of kernel classes to be replaced by the VM
implementor. In some cases, like reference queues, we've preferred the
DRLVM implementation over that which is in the class library.
- OpenJDK requires a large set of native methods that are implemented,
in the Cacao VM, in a file known as jvm.cpp. Native methods are
problematic for metacircular, java-in-java VMs and a work around is to
rewrite the bytecode and provide non-native implementations.
Anyway, this has just been a long winded way to say that I agree with
Bob's statement:
Putting a perfectly generic class in the DRLVM library just creates more
work in the long term given that we're eventually going to move it into the
core lib anyway.
and that perhaps there's scope for something like a virtual machine
interface JSR that Harmony could participate in. This idea appeared to
get broad support from the VM implementors, free Java people and Sun at
FOSDEM.
Thanks,
Ian Rogers
[1] Common Public License, a variant of the Eclipse Public License where
IBM rather than the Eclipse Foundation are the steward
[2]
http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/libraryInterface/Harmony/
[3] http://www.fosdem.org/2008/schedule/devroom/freejava
[4] http://openjdk.java.net/challenge/
[5] http://jira.codehaus.org/browse/RVM-517
--
http://www.cs.man.ac.uk/~irogers
http://icooolps.loria.fr/icooolps2008/index.php
