harmony-dev mailing list archives

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