Andrey Chernyshev wrote: > I'm not sure it is just a name clash problem - drlvm won't give the > hythread library if the class lib hadn't requested it.
The classlib builds it's own copy of the hythread library, so there is no need for a compatible VM to rebuild it or provide it. VMs are free to use the thread library for their own implementation, or use another thread library (but they shouldn't replace classlib's). > The problem is > that, the classlib will not work with it's original hythread library > if the classlib is run with drlvm. > This happens because, for example, monitor_enter() implementation of > the hythread requires each thread be attached to the hythread library > first (it requires > a pointer to HyThread structure be stored in the TLS), but this can > only be done by VM during thread creation. > To solve this, VM either has to always register every new Java thread > with the classlib's hythread library, or provide it's own > implementation of the hythread. Registering the thread creation is the preferred option. > It seems that classlib's hythread implementation assumes that the > hythread is shared between VM and classlib and VM is building it's > threading subsystem on top of the hythread. No that's not the case. For example the IBM VME and JCHEVM do not share the classlib thread library, there is no need for DRLVM to do so if it chooses. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
