On Jul 24, 2016, at 3:41 PM, Mark Roos <mr...@roos.com> wrote: > > A few questions on implementation. > > My old prototype looks like: > private RtObject[] _mDicts = new RtObject[8]; // array of > method dicts > private MethodHandle[] _methods = new MethodHandle[8]; // the > code MH > MethodHandle lookupSelf(RtObject rcvr, RtCallSite site) > RtObject methodDict = rcvr.classField(); > if(_mDicts[0] == methodDict) return _methods[0]; > if(_mDicts[1] == methodDict) return _methods[1];.... > > If I fill the arrays I treat them as a circular buffer and overwrite the > existing contents. > > You mention the need for the last element in the arrays to be null. Why?
It doesn't; I was thinking of a doubtful loop shape improvement. In you code, there's no loop at all. > If the arrays are declared 'Stable' does this mean that when I fill them I > cannot reuse them? Would > I just replace the arrays with new ones? The documentation for Stable (which is not a standard feature yet, and may not become one) says you are only allowed to set a stable array (any level of structure, from root to leaf) exactly once. The JIT avoids constant folding the stable array structure until it sees a non-default value. If you then change a non-default value to another value, you've broken the rules. Perhaps the real rule is that you have to be willing to live with any of the (non-default) values that the JIT chooses to constant-fold. In any case, that's operationally what the JIT provides for you if you use Stable values. The above set of rules or non-rules is only half-baked. That's why Stable is not a feature. It's merely an internal optimization. > You also mention a concern if the test items are Objects vs MethodHandles. > My test MH does the same > object reference compare and I was trying to avoid executing the > rcvr.classField() for each test. Would > I be better off if I used a test MH instead? If you have a clean token you can use with comparisons, that is fine. The advantage of MH's is simple: They get inlined vigorously. – John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
