harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: My first submission! java.lang.ThreadLocal
Date Thu, 26 Jun 2008 09:53:11 GMT

Changes committed in r671836:

and there is a new JIRA task:
"HARMONY-5883 [vmi] Document and progress pending changes to the VM 

Comments welcome.


Tim Ellison wrote:
> Aleksey Shipilev wrote:
>> Ok, Tim. It seems like we are wasting our time on discussing this :)
> I'd like to proceed and commit the patch, but the topic is not a waste 
> of time.  I just wanted to be clear that I see the commit as a 
> 'tactical' fix to keep all VMs working, but I agree with the overall 
> goal of updating the VMI.
> This is not the only place where we have made this decision, including a 
> number of build time flags in the native code to keep things working.
>> 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.
> Yes, good idea -- and I'll raise a JIRA to ensure the issue is captured.
> Regards,
> Tim
>> 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

View raw message