harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
Date Wed, 14 Jun 2006 14:25:05 GMT
Ming,

 > The above is just a consideration for infrastructure. I have already
 > implemented the write barrier code in jet for some GC developed in C.
 > It has already been tested and attached file is the patch.
Cool ! Thanks for the patch !

I'm not too familiar with GC stuff, but seems you are right and your
patch fits all.  In case of AASTORE for .jet, as it generates a helper
call anyway, the VM can do the job. The statics are all known for GC
so they can be easily scanned. (Can GC guys comment on this ?)


-- 
Thanks,
   Alex

> hi, guys
> 
> The way to use gen_invoke to call a Java write barrier should work, and
> the better way may be inlining the barrier code. Maybe jet can not do
> inlining, but jitrino.opt should do it.
> 
> Alex's idea is not so bad. It is right that the cost will be high if
> we'll have a JNI call on every PUFIELD/PUTSTATIC/AASTORE, but I think
> the performance for jet is not very critical, becasue it is not an
> optimized jit. If we realy care about some methods' performance, we
> should recompile it using some more powerful jit such as jitrino.opt.
> 
> In fact, Alex's idea can be implemented as something like a root GC
> which can dynamically manage the different GC with the same interface.
> The idea of root GC will actually incur many overhead of indirect
> calling. I think, if we only care about the static situation with
> certain information about what gc we use, whether we have write
> barriers .etc, the direct solution is sure to be the best. But when we
> consider some dynamic situations, it is not the case. For example, when
> we change a gc without needs for write barrier to another gc with the
> needs during runtime, if we do not have help of root GC, we should
> recompile the method using jet, and if we have root GC, we do not have
> to recompile it, the changing to a new write barrier function can be
> finished by root GC interface during the process of loading of the new
> gc. Of course, recompiling for more powerful optimization is necessary,
> but it should only be done on some hot methods, and we may not need to
> recompile all the methods using jet.
> 
> The above is just a consideration for infrastructure. I have already
> implemented the write barrier code in jet for some GC developed in C.
> It has already been tested and attached file is the patch.
> 
> thanks
> -ming
> 
> 
> ------------------------------------------------------------------------
> 
> diff -BburN vm/jitrino/src/jet/cg_ia32.cpp vm-write-barriers/jitrino/src/jet/cg_ia32.cpp
> --- vm/jitrino/src/jet/cg_ia32.cpp	2006-03-28 22:33:21.000000000 +0800
> +++ vm-write-barriers/jitrino/src/jet/cg_ia32.cpp	2006-06-04 11:16:21.000000000 +0800
> @@ -2080,6 +2080,12 @@
>              voper(typeInfo[jt].mov, phi, vstack(1));
>          }
>          //
> +      	if (jt == jobj) {
> +        	void *helper = vm_get_rt_support_addr(VM_RT_WRITE_BARRIER_FASTCALL);
> +        	gen_mem(MEM_STACK|MEM_VARS|MEM_TO_MEM|MEM_UPDATE);
> +        	voper(Mnemonic_MOV, RegName_ECX, rref);
> +        	vcall(helper);
> +      	}
>          vpop(jt);
>          vpop(jobj);
>      }
> diff -BburN vm/vmcore/src/jit/jit_runtime_support.cpp vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp
> --- vm/vmcore/src/jit/jit_runtime_support.cpp	2006-03-28 22:53:28.000000000 +0800
> +++ vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp	2006-06-04 11:17:36.000000000
+0800
> @@ -1657,6 +1657,8 @@
>  #endif
>  
>      switch(f) {
> +		case VM_RT_WRITE_BARRIER_FASTCALL:
> +            return NULL;
>          // Object creation
>      case VM_RT_NEW_RESOLVED_USING_VTABLE_AND_SIZE:
>              return NULL;
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> 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



---------------------------------------------------------------------
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


Mime
View raw message