harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <rogers.em...@gmail.com>
Subject Re: My first submission! java.lang.ThreadLocal
Date Mon, 30 Jun 2008 00:33:31 GMT
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 

Ian Rogers

[1] Common Public License, a variant of the Eclipse Public License where 
IBM rather than the Eclipse Foundation are the steward
[3] http://www.fosdem.org/2008/schedule/devroom/freejava
[4] http://openjdk.java.net/challenge/
[5] http://jira.codehaus.org/browse/RVM-517

View raw message