Hi Jochen!

On Wed, Oct 5, 2016 at 7:37 AM, Jochen Theodorou <blackd...@gmx.org> wrote:
> If the meta class for A is changed, all handles operating on instances of
> A may have to reselect. the handles for B and Object need not to be
> affected. If the meta class for Object changes, I need to invalidate all
> the handles for A, B and Object.

This is exactly how JRuby's type-modification guards work. We've used this
technique since our first implementation of indy call sites.

> Doing this with switchpoints means probably one switchpoint per metaclass
> and a small number of meta classes per class (in total 3 in my example).
> This would mean my MethodHandle would have to get through a bunch of
> switchpoints, before it can do the actual method invocation. And while
> switchpoints might be fast it does not sound good to me.

>From what I've seen, it's fine as far as hot performance. Adding complexity
to your handle chains likely impacts cold perf, of course.

Can you elaborate on the structure? JRuby has 6-deep (configurable)
polymorphic caching, with each entry being a GWT (to check type) and a SP
(to check modification) before hitting the plumbing for the method itself.

I will say that using SwitchPoints is FAR better than our alternative
mechanism: pinging the (meta)class each time and checking a serial number.

> Or I can do one switchpoint for all methodhandles in the system, which
> makes me wonder if after a meta class change the callsite ever gets Jitted
> again. The later performance penalty is actually also not very attractive
> to me.

We have fought to keep the JIT from giving up on us, and I believe that as
of today you can invalidate call sites forever and the JIT will still
recompile them (within memory, code cache, and other limits of course).

However, you'll be invalidating every call site for every modification. If
the system eventually settles, that's fine. If it doesn't, you're going to
be stuck with cold call site performance most of the time.

> So what is the way to go here? Or is there an even better way?

I strongly recommend the switchpoint-per-class granularity (or finer, like
switchpoint-per-class-and-method-name, which I am playing with now).

- Charlie
mlvm-dev mailing list

Reply via email to