On the 0x436 day of Apache Harmony Alexey Varlamov wrote:
> 29 Apr 2008 14:47:20 +0400, Egor Pasko <[EMAIL PROTECTED]>:
> > On the 0x431 day of Apache Harmony Aleksey Shipilev wrote:
> > > Hi,
> > >
> > > I had returned to idea to have @Inline and @NoBoundCheck annotation
> > > support in classlib and Jitrino.
> >
> > I am not sure how much work it is to do, but I always wanted to have
> > ways to access annotations in JIT. There are multiple applications for
> > that always appearing here and there.
>
> In fact such mechanism is already there and is used for a long, e.g.
> look for Inliner::processInlinePragmas() in Jitrino.OPT. I thought
> you're aware of it...
I did not know :( Thanks for the pointer!
> AFAIU Aleksey just suggests to extend support with richer set of
> annotations and propagate tuning markup to vm-agnostic source codes of
> classlib.
I see. This is good.
P.S.: probably @Inline should not guarantee inlining. Recursive calls
are an example. Do we throw OutOfMemory from inliner correctly?
> > so, I am +1 for such mechanism. We can restrict it to just system
> > classes for the start.
> >
> > > I will try to summarize the rationale for both these annotations:
> > >
> > > 1. @Inline. There are places where we're creating small methods to
> > > get more consistent code, while we expect JIT should inline them to
> > > reduce call penalty. Unfortunately, this is not always the case and
> > > any JIT can miss the opportunities for inline. As classlib developers
> > > we can dope our code with the hints saying "this method is really
> > > should be inlined, as we know it would be the penalty leaving it not
> > > inlined, just do it even when inline budget is exhausted". Jitrino
> > > really have @Inline already as the part of vmmagic package, but I want
> > > to see these annotations visible from the classlib part.
> > >
> > > That's the case of new HashMap [1] for example:
> > >
> > > /*
> > > * Contract-related functionality
> > > */
> > > static int computeHashCode(Object key) {
> > > return key.hashCode();
> > > }
> > >
> > > static boolean areEqualKeys(Object key1, Object key2) {
> > > return key1.equals(key2);
> > > }
> > >
> > > static boolean areEqualValues(Object value1, Object value2) {
> > > return value1.equals(value2);
> > > }
> > >
> > >
> > > 2. @NoBoundCheck. There are also cases in which we definitely know
> > > that no bound check need to be performed. This is the case of HashMap
> > > again:
> > >
> > > ...
> > > int hash = computeHashCode(key);
> > > index = hash & (elementData.length - 1);
> > > entry = elementData[index];
> > > ...
> > >
> > > Of course, good JIT compiler should also resolve such patterns and
> > > eliminate bounds check here, but we can again hint the compiler they
> > > are not necessary. There's a complication though that such pragma
> > > could violate security if used in user code, but we could restrict its
> > > usage to bootstrap classes only. ABCD gurus (Egor?) could shed more
> > > light whether it's possible to implement on JIT side.
> >
> > As for this specific example the reason JIT is not eating the expr
> > properly is that it looked like a very rare pattern in
> > practice. Straightforward solution is: "if a[i] check is proven
> > redundant then a[i&anything] is redundant". Does it suit you, Alexey?
> > Any other enhancement ideas?
> >
> > > What do you think? I can elaborate with proof-of-concept patches to
> > > see what advantage it would bring.
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > [1] https://issues.apache.org/jira/browse/HARMONY-5791
> > >
> >
> > --
> > Egor Pasko
> >
> >
>
--
Egor Pasko
