On 7/3/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
On 3 July 2006 at 15:14, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote: > > I didn't find the exact reason why this happens, looks like a drlvm > > ant scripts work differently. > > It could be a side effect of the recent adoption of DRLVM build > for classlib binaries. The trick is that drlvm should put it's own > hythread library into the deploy JRE. Before that change drlvm wasn't > building the original hythread library at all, but now libhythr.so is > copied from the class libraries into the deploy directory along with > all other native class libraries. > > There could be two ways to resolve it: > > (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a > filter which will will exclude hythr from copying; > > (b) More graceful fix - split the "process.components" target in > build.xml into compilation of the components and their copying > into deploy directory, and then update the dependencies order for > the "build" target to make sure that class libraries are always > copied first and then the compiled drlvm binaries are copied second, > overwriting the classlib binaries if needed. c) Call the drlvm thread library something else to avoid the name clash with the existing library? (As IBM VME does with it's thread library.)
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 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. 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. Thanks, Andrey.
> I would prefer to do (a) for now since these kind of dependencies > between classlib and drlvm are supposed to be handled by the top level > build anyways. I don't think we should expect the top-level build to fix any problems like this. The top-level build should be completely dumb. My preference for the top-level build to just do a recursive copy of the drlvm/deploy tree and the classlib/deploy tree to a top-level deploy tree - which means it has to know nothing about the structure of the deploy directories. (And I don't think we should rely on the order in which the recursive copies happen - i.e. the set of files under deploy/drlvm and deploy/ classlib trees should not intersect.) Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrey Chernyshev Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
