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