> On 12/7/06, Robin Garner <[EMAIL PROTECTED]> wrote: >> Xiao-Feng Li wrote: >> > On 12/7/06, Robin Garner <[EMAIL PROTECTED]> wrote: >> >> Xiao-Feng Li wrote: >> >> >> >> >> 2) I have to use 3 params for fast path helper because slow >> helper >> >> >> (gc_heap_slot_write_ref) requires 3 params. >> >> > >> >> > Mikhail, we need a simpler helper. The current helper is used for a >> >> > full barrier including both the fast-path and slow-path. It's >> >> > undesirable. >> >> >> >> Excuse me if I'm missing some details here, but surely the number of >> >> parameters to the write barrier helper is unimportant (well, within >> >> limits) ? Since the helper (by definition) is inlined, there is no >> real >> >> parameter passing going on, and unused parameters will simply be >> >> optimized away. >> > >> > Robin, thanks. Yes, for the Java helper, it doesn't matter to have >> > more parameters. >> > >> > But the parameters here are those for the native function invocation >> > that does the real remembering. It is not inlined, so the parameter >> > count might have impact on performance, but we don't know without real >> > experiment. >> >> But by definition, the slow-path helper is slow. I would be very >> surprised if extra parameters had any significant impact on speed, >> particularly with the simple boundary-crossing barrier. >> >> > >> > The other reason for a new native write barrier interface is, the >> > original one is called by VM even with non-generational GC. It's >> > undesirable to have a check in the native function body about whether >> > it's generational GC or not. We can change either the VM body or only >> > the GC side. So my suggestion is to change the GC side. >> >> Again, I would have thought this was by far the least common case - the >> mutator modifies pointers far more than the VM. >> >> I would think that rather than implement the whole thing and measure, if >> you added some simple counters of: >> - fast path invocation >> - slow path invocation >> - VM invocation > > Robin, I guess we have some miscommunication. > > The problem here is not about Java helper parameters. This native VM > helper function is not a real write barrier. It is only a function to > do the real remembering. It doesn't make sense for it to take some > useless parameters. This function can be invoked by other write > barrier functions (native or Java). For example, > gc_heap_slot_write_ref can call it when the GC is generational.
So in standard GC terminology, this is the API for adding a reference to the remembered set ? I guess I'm having difficulty understanding why anything except the write barrier would want to add an entry to the remset. > We are not talking about a generic write barrier API, because this > function is not a write barrier itself. I know the ratio of slow path > is much lower than the fast path, but that's not the reason to put > something useless in the VM helper. > > If we want other Java write barrier functionality that the current > design doesn't support, we can modify the Java helper code later on. > But that's another thing, different from the VM native helper. OK, I think the term "helper" is being overloaded here ? > Finally, the Java helper code is specific to the GC implementation, > hence put into the specific GC directory. It doesn't impact other GC > to have other Java helper code. Now what Mikhail is building is an > inlining infrastructure that will easily adapt to different helpers. Sure, the Java helper code is GC-specific, but the interface should be common across all GCs. We're on the same page here, aren't we ? > Thanks, > xiaofeng > cheers, Robin
