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 Wed, 25 Jun 2008 13:14:29 GMT
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.
We are trying to get IBM VM to run on unmodified classlib code, right?
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?

>> 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 :)

> 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

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.


View raw message