Re: My first submission! java.lang.ThreadLocal

[Tim Ellison]

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 <[EMAIL PROTECTED]> wrote:
Aleksey Shipilev wrote:
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.
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