Alex, It looks like the JIT needs to support write barriers written in both C as well as Java. Its probably best to think of the C write barrier as a conventional vm helper call. For a garbage collector written in Java like MMTk, the write barrier is actually Java code. Injecting a vm helper call and crossing the JNI boundary twice per each MMTk write barrier will be a nightmare to debug. Most likely performance would be unacceptable even for debug.
On 6/14/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
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 ?)
For a general purpose GC/VM interface, it is best not to assume the GC algorithm will always scan all the static variables containing reference pointers. The write barrier needs to also be applied to putstatic.
-- Thanks, Alex
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
