On 9/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Thanks to Egor and Gregory's responses to the JET write barrier patch. Those help. I was away from JIT development for a while. :-) Since the patch is small, if needed, please feel free to modify it as a JIRA update, or a committer to merge it then we submit new patch later. Basically the write barrier should be as small (quick) as possible and involves no additional VM runtime operations. A view to write barrier can be that, it is only an extended bytecode of the orignal reference store one. That means, we can implement it in anyway appropriate as long as the semantics of the reference store is kept, either in JIT IR, in LIL,
Please no LiL. We need to replace LiL code with either Java/vmmagic, jit intrinsic or emitter based asm code. Even JIT IR would be preferable to LiL. in asm or as a function call. Performance
and flexibility are the main goals. The performance is easy to understand, the flexibility refers to that a GC developer probably can conveniently change the write barrier implementation. As I know, a volunteer (Mikhail Fursov?) is writing helper inlining for DRLVM. Hopefully that will be the ultimate solution for write barrier implementation. Before that is ready, an intermediate solution would be acceptable. Thanks, xiaofeng > On 27 Sep 2006 17:20:36 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > I am curious about the switch > VM_Global_State::loader_env->use_lil_stubs. Does everything work in > both true and false? What do we need this switch for? Doesn't it > induce unnecessary complication/duplication? --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
