Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Aug 2001 18:12:49 -0700
From:      Arun Sharma <arun@sharmas.dhs.org>
To:        Fuyuhiko Maruyama <fuyuhik8@is.titech.ac.jp>
Cc:        java@FreeBSD.ORG
Subject:   Re: JVM and native threads
Message-ID:  <20010827181249.A16093@sharmas.dhs.org>
In-Reply-To: <55itf9cmln.wl@tripper.private>; from fuyuhik8@is.titech.ac.jp on Tue, Aug 28, 2001 at 04:46:28AM %2B0900
References:  <20010824233304.A32099@sharmas.dhs.org> <55vgjcqv87.wl@tripper.private> <20010825095746.A1015@sharmas.dhs.org> <55heuv0xtl.wl@tripper.private> <20010826171010.A6742@gnuppy> <20010827143244.A12305@misty.eyesbeyond.com> <55k7zqnd1x.wl@tripper.private> <20010827095624.B14875@sharmas.dhs.org> <55itf9cmln.wl@tripper.private>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 28, 2001 at 04:46:28AM +0900, Fuyuhiko Maruyama wrote:
> Thanks, it is interesting.
> 
> In fact, it seems quite curious for me because you say nothing about
> thread's context.  So I dig the orp-20010727 sources and found that
> current ORP doesn't well support Linux platform.  Current ORP may
> cause disaster when GC is happen on Linux, possible senarios are:
> 1. GC system collects live object refered only by register.
> 2. GC system moves live objects refered by register and it doesn't
>    treat pointers on register to catch up moving of objects.
> 3. GC system cannot ensure all threads are suspended at GC safepoint.
> 
> Do I misunderstand?
> 

Since they claim to run SpecJVM on Linux and it doesn't crash and burn,
they must be doing something right :)

See:

1. http://www.acm.org/pubs/citations/proceedings/pldi/301618/p118-stichnoth/
2. Comments from arch/ia32/base/root_set_enum_ia32.cpp

    // Not at a GC-safe point.  We will let the thread run, but before
    // we do it,
    // we will:
    //  1. gc_status = moving_to_gc_safepoint
    //  2. Hijack the return eip.
    //  3. Set the breakpoints
    // There are only three ways to escape from a Java frame:
    //  A. Return.  This is handled by (1) above.
    //  B. Call to another method.  Handled by (2).
    //  C. Exception which is not handled in the current method.  This
    //  is handled
    //     by the exception throwing code which checks the state of the
    //     thread

	-Arun

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010827181249.A16093>