Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of weldonwjw@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=W5c0oH1MxmTKnw7h5eVd5cp+ip+4NC+u1Vu64vwpzmdxtKqhTGsfCqtcWv3qUmcJbaRwXOftGdJcyboAjXvCdGXDPyCaGF6Cojg69uGPSTDhBs+q32ZVU8VUR5RHOZ8BI9BXq/qefYTKCDnIs+G5dDFBLciEmDtSJEEdW36M0N4=
Message-ID: <4dd1f3f00606020600i215c9612pee5272bb58f54993@mail.gmail.com>
Date: Fri, 2 Jun 2006 06:00:59 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM] adding write barriers to Jitrino.JET
In-Reply-To: <12385bbd0606020425t5f7f7f22h5919cabaf8155e0a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4dd1f3f00605301512l21cf4070uf26be9d18b83c934@mail.gmail.com>
	 <51d555c70605311410t74f0149by339b5b409018be2c@mail.gmail.com>
	 <12385bbd0605311516u1d7f9e0ap65367702116ee341@mail.gmail.com>
	 <4dd1f3f00605312100g1a056f5cx5e02c358a91e9ac8@mail.gmail.com>
	 <12385bbd0606010420i535b63d0x1e5b9b9e03367b69@mail.gmail.com>
	 <4dd1f3f00606010747h3524b708we5a09737cab63243@mail.gmail.com>
	 <12385bbd0606010916p26359163l3b0301c0b2ff3d91@mail.gmail.com>
	 <51d555c70606011839k2426eba0xcfa4d16d3a4db06a@mail.gmail.com>
	 <4dd1f3f00606012133v1b5cc052pe398188e79d104ec@mail.gmail.com>
	 <12385bbd0606020425t5f7f7f22h5919cabaf8155e0a@mail.gmail.com>

On 6/2/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> I didn't look at the MMTk source, but IMHO the special translation of
> bytecodes is not nessasary in first stage. If the functionality
> implemented as methods which are handled specially in jikes, in
> interpreter they can be implemented as native methods. Anyway, I do
> not insist on the use of interpreter, just wanted to clarify this
> case.

Good observation.  It might be possible to do the following.  Write a
special version of the java files sitting in vmmagic that call new,
matching native methods that do the pointer manipulation.  No GC can
be allowed in these native methods.  Why?  Because these routines do
stuff like convert an int containing a raw pointer to an
ObjectReference containing a valid ref ptr.  It should be fairly
simple to hold off GC during execution of these natives.

AFIK, all the vmmagic classes implement the Uninterruptible interface.
 The interpreter would be modified to poll for GC between intrepreting
each bytecode.  If the current method implements the Uninterruptible
interface, polling for GC would be skipped.  Admittedly the above
would run slow.  Maybe too slow for even development purposes since
every pointer manipulation becomes a native method call.  Its tough to
call this one.

>
> As for the patch, you will at least find the places in VM code where
> missing write barriers should be added.
>
> Regards,
> --
> Ivan
>
> 2006/6/2, Weldon Washburn <weldonwjw@gmail.com>:
>
> > > 4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
> > > corresponding VM and support for WB. In this patch, the interpreter also
> > > supports write barriers. So in theory, one should be able to bring up MMTk
> > > in interpreter mode even before modifying .Jet?
> >
> > After a closer look, I can give a definite "maybe" on this one.  In
> > practice it might end up being just as much or more work as bringing
> > up Jitrino.JET because a bunch of MMTK pointer manipulating classes
> > must somehow be translated via javac into bytecode patterns that
> > trigger the interpreter to bend the type safety rules and do stuff
> > like move an int into a ref ptr field.  Other approaches would be to
> > modify javac to generate unsafe code (yuk!)   We could also use  some
> > sort of automated bytecode editor to hack the bytecode stream -- maybe
> > use sed/awk/ruby/perl/forth.   The classes in question are located in
> > org.vmmagic.unboxed (I think).  Note that once you bring up the
> > interpreter, you still have to bring up the compilers.  While still to
> > early to call, using an interpreter approach is not promising.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org