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 wrote:
>> Aleksey Shipilev wrote:
>>> On Wed, Jun 25, 2008 at 5:00 PM, Tim Ellison
>>> 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
>>
>>
>