harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: My first submission! java.lang.ThreadLocal
Date Tue, 01 Jul 2008 14:43:56 GMT
> 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 <rogers.email@gmail.com> 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

Mime
View raw message