harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "鸣伍" <wuming.sp...@gmail.com>
Subject Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
Date Fri, 09 Jun 2006 07:13:40 GMT
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.


View raw message