On Wed, Jun 25, 2008 at 5:00 PM, Tim Ellison <[EMAIL PROTECTED]> 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 porting. 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. Thanks, Aleksey.
