> 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.
Ian, that's fascinating! BTW, have you noticed a reference to the related work on Java for scripting made by Sergey in the previous thread [1]? [1] http://markmail.org/message/5qoto52kzh534woa On Mon, Jun 30, 2008 at 4:33 AM, Ian Rogers <[EMAIL PROTECTED]> wrote: > 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 > > -- With best regards, Alexei
