Re: Projects

["Jonathan P. Olson" <olson at mmsi dot com>]

On Thu, 27 Apr 2000, Anthony Green wrote:
I put write barriers into g++ and gcj over a year ago and have been using
it on our embedded products that use Super-H, StrongARM, and AMD 29k
processors.  Sure is nice to have a multi-threaded, garbage collected
C++/Java environment.

Note that write barriers allow the garbage collector to run at low priority
and not affect other time critical tasks.  The way I implemented them, they
do not allow the implementation of a precise collector, since the write barrier
traps only occur during garbage collection.  Because write barriers traps only
occur during collection, they have a very small overhead.

This implementation maintains a global write-barrier threshold register in
a location easily accessible to the run-time environment.  Whenever
gcc writes to a pointer, it generates code that generates a trap if the
pointer is higher than this write-barrier threshold.  During normal operation,
the write barrier is set to FFFFFFFF, so no traps occur. During collection,
the garbage collector lowers the write barrier to the start of heap. This
causes all pointer writes to trap to a handler which records the new
pointer being written in the system collector gray list.

This implementation adds a new named RTL pattern, "write_barrier" to the
compiler back-end.   Here are the write barrier patterns for the three
processors we use:

AMD 29K:  This one's really cool because it only requires one assert
instruction!  The assert is a nop if the collector isn't collecting.

(define_insn "write_barrier"
  [(parallel [
	(set (match_operand:SI 0 "memory_operand"   "=m")
	     (match_operand:SI 1 "register_operand" "r"))
	(unspec_volatile [(match_dup 1)] 16)])]
  ""
  "store 0,0,%1,%0\;asleu V_write_barrier,%1,gr95")

StrongARM.  This one also only adds one instruction, but it's
a call (branch/link) to a statically linked function, which checks
the given register against the write barrier.  The function executes
three instructions to perform the check.  Yeah, it stalls the pipeline
because it's a branch but in embedded applications I'd rather 
save the code space.

(define_insn "write_barrier"
  [(parallel [
	(set (match_operand:SI 0 "memory_operand"   "=m")
	     (match_operand:SI 1 "register_operand" "r"))
	(unspec_volatile [(match_dup 1)] 16)
	(clobber (reg:SI 12))
	(clobber (reg:SI 14))])]
  ""
  "str%?\\t%1,%0\;bl%?\\t___write_barrier_%1"
[(set_attr "conds" "clob")
 (set_attr "length" "8")])

Super-H.  The Super-H has a limited branch range but short instructions.
Hence I inlined this one.  Note that the barrier itself requires four 16-bit
instructions.

(define_insn "write_barrier"
  [(parallel [
	(set (match_operand:SI 0 "general_movdst_operand" "=m")
	     (match_operand:SI 1 "register_operand" "r"))
	(unspec_volatile [(match_dup 1)] 16)
	(clobber (reg:SI 0))
	(clobber (reg:SI 22))])]
  ""
  "*
{
  operands[2] = gen_label_rtx ();
  return
      \"mov.l	%1,%0
	mov.l	@(14*4,gbr),r0
	cmp/hi	r0,%1
	bf	%l2
	trapa	#V_write_barrier
%l2:\";
}"
[(set_attr "in_delay_slot" "no")
 (set_attr "length" "10")])

As you can see, the target specific code for the write barriers is really
pretty simple.  It executes an extra 1-4 instructions per pointer write
when collection is not running.  When the collector is running, it traps
to actually record the pointer in the collector's allocation table.
Instrumenting the embedded collector shows that the number of these
write barrier traps taken is relatively small since they're only taken during
the 20-50 milliseconds required for the conservative scan.

BTW, I also throw in some peepholes to collapse multiple writes of the
same register to multiple in-memory pointers.  This helps optimize things like:

	p->last = p->next = q;

>Tom Tromey and I recently put together a preliminary list of projects
>that we believe are useful and interesting.  The idea is that they
>might be of interest to people wanting to help out on GCJ, but not
>quite sure where to start.
>
>http://sourceware.cygnus.com/java/projects.html
>
>There's a link to it off of the "Contributing" page.
>
>It's kind of short right now, but we can easily add items to this
>list.
>
>AG
>

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790