harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: My first submission! java.lang.ThreadLocal
Date Thu, 26 Jun 2008 08:22:08 GMT
Ok, Tim. It seems like we are wasting our time on discussing this :)
Let's back to this topic later.
For now, let's commit this change to DRLVM specific classes, but place
the TODO: comment in Classib's java.lang.Thread/ThreadLocal about
things state.

Thanks,
Aleksey.

On Thu, Jun 26, 2008 at 11:01 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Aleksey Shipilev wrote:
>>
>> On Wed, Jun 25, 2008 at 5:00 PM, Tim Ellison <t.p.ellison@gmail.com>
>> wrote:
>>>
>>> Aleksey Shipilev wrote:
>>>>
>>>> Can't IBM VM extend its j.l.Thread correspondingly?
>>>> Can't IBM VM copy current ThreadLocal implementation to _its_ kernel
>>>> classes?
>>>
>>> Yes, but I'm guessing that you don't want to wait for the next release of
>>> the IBM VME before accepting this patch.
>>
>> I'm afraid that the change would be lost if we adopt such
>> "DRLVM-specific" solution.
>
> I disagree, there are already DRLVM-specific classes, and nothing is 'lost'
> they are all in the same repository for everyone to see.
>
> VMs are always permitted to have their own specific implementation of a
> class.
>
>> We are trying to get IBM VM to run on unmodified classlib code, right?
>
> No, we are trying to ensure that the DRLVM and IBM VM and other VMs continue
> to work.  If we are going to change the contract between the class library
> and VMs then it should be a migration rather than 'break the world' change.
>
>> But if IBM VM is not flexible to afford the quick changes in core
>> libraries, would it be better to wrap the not-yet-compatible code in
>> classlib with some "porting glue" for legacy IBM VM version, but keep
>> the code visible for other quick-to-change VMs?
>
> I'm open to concrete suggestions.
>
>>>> The thing is, I presume we have an example of backporting the good
>>>> change from Android (?) back to Harmony.
>>>
>>> I'm not sure what you mean here.
>>
>> I'm a little speculating here. Judging on Bob's website I see that he
>> is the developer of core libraries of Android, so I presume this
>> change is already in Android code. Then if Android adopted and
>> improved LUNI in classlib, we should backport the change back to LUNI
>> in classlib :)
>
> I still don't see why this is relevant to the discussion.  Anyone is welcome
> to take the code and use it (under the license etc).
>
>>> Yes, it will get into the common classlib code.  In the meantime there is
>>> nothing to stop people getting the code from the DRLVM directory, like
>>> they
>>> do for Thread and all the other kernel classes.
>>
>> I'm afraid that no one VM developer would look in DRLVM's kernel
>> classes while working on porting of Harmony classlib to its own VM.
>> Leaving the things under the hood for IBM VM you also get the other
>> VMs into the same situation: eventually moving ThreadLocal
>> implementation to classlib will break their own VMs. I don't think
>> that "other VM" developers should take this extra caution while
>> porting.
>
> To turn it around, there are already VM implementers who have ported the
> class library code to their VMs, and making this change will break them.
>  I'm suggesting a simple transition period ending up exactly as you suggest.
>
>> Summarizing all above: if the problem is IBM VM's inability to quickly
>> react for changes - then the problem should be solved in IBM VM's
>> specific way, not the DRLVM's one.
>
> It's not just the IBM VM, it's the VM interface.  Let's keep things working
> for everyone.
>
> Regards,
> Tim
>
>

Mime
View raw message