In message <[EMAIL PROTECTED]>, "Nathan Beyer" writes: > > On Tue, Apr 29, 2008 at 10:12 PM, Alexey Varlamov > <[EMAIL PROTECTED]> wrote: > > > 2008/4/30, Nathan Beyer <[EMAIL PROTECTED]>: > > > > > > On Tue, Apr 29, 2008 at 12:35 AM, Alexey Varlamov > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I recall we chewed this theme few months ago but nothing > > > > has changed since then. > > > > As long as you do full build of classlib, hythread native > > > > library is rebuilt (even if you did not touch relevant sources) > > > > and replaces drlvm's one (in deploy/jdk/jre/bin) thus drlvm > > > > fails. Alexei does only partial build and it works unless > > > > includes hythread. But I wonder why classlib natives are > > > > rebuilt each time. > > > > > > > > > Did this change in the past 6-12 months? I use to do this all the > > > time with the IBM VME and it always worked. > > > > Nope, this problem exists from the very beginning. This works with > > J9 as it names its threading lib differently (j9thr). > > So how do we fix this, permanently? The whole point of the HDK/JDK > folder layout was to achieve this drop-n-go; at least that's what > I thought. I know we want some level of abstraction, but it seems > awkward not to facilitate the the most obvious development practice -- > drlvm + classlib.
As I said in an earlier message in this thread, the correct fix is to drop the classlib hythr implementation and let the VME to supply it's own implementation with a well-defined API. The work for classlib is actually done and is activated with -Dhy.no.thr=true ant option. It just needs to be implemented in DRLVM and the IBM VME. No doubt the API will need to be refined a little if/when the VME portion of the work is attempted. -Mark.
