<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 16, 2015 at 8:23 AM Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
we recently discussed about the problem of modelling locks as Java<br>
locks, and blocking our actual threads - or have to delegate to<br>
internal large threadpools - to model the "parking" of a thread which<br>
is visiting the interceptor chain, when all we want is to model a lock<br>
as a boolean with possibly some metadata like owners and timestamps.<br>
<br>
We all agreed that it needs to change, and we proposed some high-level<br>
basic ideas about how to store the "on stack" state in some container<br>
object. We know what we want to achieve, but I haven't seen yet much<br>
progress on details about how exactly get there.<br></blockquote><div><br></div><div>Dan has started with a handful of JIRAs [1]. It looks like this issue in particular is the one to explore that information. I am guessing he will have a design thought out for that in a bit, is that what you are looking for?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One basic first step we discussed is to split the internal contract of<br>
the visitor chain between separate methods "up" and "down" (very much<br>
in JGroups style). That would force us to highlight local variables,<br>
which need to be moved within an appropriate container.<br>
We then briefly discussed how such a container should model a stack,<br>
to allow for different visitors to avoid name clashing, and do it<br>
efficiently: we wouldn't like to allocate a vector for the stack, nor<br>
use a dictionary for the names-object variables, but at every least a<br>
custom payload object would need to be coded for each visitor, and<br>
appended to the chain.. that would have the allocation costs of a<br>
linked list and a container object to allow field access pointers be<br>
allocated for each visitor in the chain.<br>
Pooling is also an option.. but really it's all just looking horrible :-)<br>
<br>
I was now reading about Quasar and Fibers (credit to Mark Little and<br>
Tim Fox for the pointer) :<br>
- <a href="http://docs.paralleluniverse.co/quasar/" rel="noreferrer" target="_blank">http://docs.paralleluniverse.co/quasar/</a><br>
<br>
It seems very interesting, and relevant to our Infinispan discussion.<br>
Although it does much more than what we need and the prospect of<br>
supporting production systems which extensively rely on ASM and modify<br>
definitions like threads and lock owners scares me a bit, so I'm not<br>
advocating we use Fibers directly but it would be very nice to:<br>
- be able to experiment with it<br>
- see if something similar could be done without needing the bytecode<br>
manipulation<br>
- maybe use it?<br></blockquote><div><br></div><div>Yeah I actually brought up Fibers a few times at the F2F last year, but no one else seemed interested. And to be honest the more I looked at it I don't know if I like the idea of having ASM etc as well especially modifying basic Java constructs like thread information. Doing this scares me especially since I have no idea how this would work common tools like jstack or debuggers etc.</div><div><br></div><div>And actually Fibers does exactly what you were mentioning in the prior paragraph regarding the stack object to store between invocations. It just does it for the entire thread details.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The overall impression I get, is that it's a very complex task for us<br>
to split the visitor chain at this point, and it's equally expensive<br>
to make any such experiment viable, so embarking in an experiment to<br>
evaluate something like Fiber gets the "Epic" JIRA level.. but there<br>
might be better ways!<br></blockquote><div><br></div><div>Yeah I came to just assume it would be too much for most likely little overall benefit, but maybe not :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you look at our RPC Commands, a lot of code is very repetitive,<br>
following established patterns and conventions. The component of the<br>
Visitor chain are a bit less repetitive, but still there are some<br>
patterns.<br>
<br>
So, what if we had some basic templates for all this repeating code,<br>
and used a custom DSL to define what a Command or a Visitor is<br>
supposed to do?<br>
I'm not suggesting we invent yet another general purpose programming<br>
language, but something very ad-hoc which takes the input we need and<br>
generates Java sources which we all understand, so issues in the code<br>
generation should be easy to spot (better so than ASM!).<br></blockquote><div><br></div><div>With all of the different edge cases based on the multitude of configuration options, I wonder how much code this would actually save us though. It seems we need to break it down into up and down methods either way to be able to have something to reuse like this, which would put us close to the interceptor rewrite anyways.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we had such a tool, it would be sustainable to make cross-the-board<br>
changes to the threading model, experiment with things like Fibers,<br>
generate the visitor code and the correct stack handling w/o getting<br>
dirty with very boring code which we don't even know how it will work<br>
out.<br>
<br>
In addition such a tool could optionally be enhanced to generate<br>
metadata for tooling, like correctness evaluations, model checkers,<br>
inject correct trace logging w/o polluting our design, output to<br>
visualizers or other debugging helpers.<br>
More importantly, it would significantly reduce the manpower needed to<br>
experiment with model changes which would otherwise affect a too large<br>
code base. For example, for some configurations one might not need the<br>
InvocationContext at all, and to push the performance level to the<br>
extreme it would be better handled by generating an alternative set of<br>
visitors (or use bytecode manipulation).<br></blockquote><div><br></div><div>I hope whether or not a context is required is something Dan has in mind possibly for his design :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Sanne<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote><div><br></div><div>- Will</div><div><br></div><div>[1] <a href="https://issues.jboss.org/browse/ISPN-5467">https://issues.jboss.org/browse/ISPN-5467</a> </div></div></div>