Re: [rvm-research] online turning on/off write barriers
Eliot Moss <[email protected]> Wed, 9 Jan 2019 10:51:45 -0500
| Newsgroups | gmane.comp.java.jikes.rvm.devel |
|---|---|
| Message-ID | <[email protected]> |
On 1/9/2019 9:48 AM, Shoaib Akram wrote: > As part of my research, I want to build a JVM prototype, which enables executing certain phases of the program using write barriers (both primitive and references), and other phases without write barriers. The write barrier will do some accounting, for example, set a special bit the object header. Generally, you can build the JVM with write barriers enabled or disabled. My idea is to use the benefit of the write barrier to online monitor certain activities, whereas not pay the penalty of having the barriers turned on during the entire program execution. Note that dividing the barrier into a fast path (check a flag and leave the barrier), and a slow path (check a flag and do the accounting) is not very helpful since the cost of the extra method call(s) when barriers are enabled is prohibitive. The cost of accounting (setting bit in header) is a fraction of the total cost of enabling the write barriers. > One way to accomplish this is to recompile all methods while informing the compiler(s) to insert or leave the write barrier code. Has anyone tried doing such a thing in the past? Any thoughts on alternative ways or challenges involved are welcome! Unless turning the barriers on/off is a very rare event, the recompilation cost may well be an issue in itself. Fast path/slow path is not an either/or kind of thing. You can move more code into the fast path, for example. So if your accounting is simple, you just inline it there. You still need your check as to whether barriers are on/off. That can be a check of a memory location, or, if you can dedicate one bit in a register somewhere, you can make the test faster (though more complex to turn on/off). I suppose another option is to retain *both* versions of methods, and swap them in and out. You would need to do on-stack replacement of currently running methods in that case -- something that has been done, but is somewhat complex (unless you can just use it more or less as is). You might also check into the lterature about turning various instrumentation on and off by recompiling methods dynamically, to sample only sometimes. Do you need this accounting barrier turned on/off for all objects at once? Or are you just trying to sample such that turning it on/off for different methods at different time would be ok? Etc. Btw, we usually find that we can be more helpful on this list if you tell us more about what you're really trying to accomplish :-) ... Regards - Eliot Moss