harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [classlib] HashMap optimization (again)
Date Thu, 10 Jan 2008 21:14:56 GMT
Hi, Tim!

On Jan 10, 2008 11:53 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Aleksey Shipilev wrote:
> > a little update here. I have managed to split problematic method into
> > two chunks, I will attach new patch to JIRA in few minutes. So far the
> > picture is following:
> So this is an attempt to make the method small enough (measured in
> what?) to be inlined by the JIT, right?  Is there a way to annotate the
> JIT to always in-line it, say by name, rather than juggling the size?
AFAIU, to ensure modularity, it would require implementing annotation
in classlib that should be recognized by any JIT. AFAIK, Jitrino has
@Inline pragma, but it's defined in DRLVM classes. Anyway, IMO the
thing I done should be done automatically by JIT, because that's the
specialization of method which should eliminate unneeded branches and
then make code capable for inlining.

That's also the point why your patch is really interesting: it can
help to understand whether such specialization worth it. If it's true,
then we might consider implementing some JIT-side optimization or even
implement similar "manual unboxing" of other primitive types.

> > Windows x86_64:
> >  100% Harmony-clean
> >  97.7% Harmony-clean + H5374 (old)
> >  99.6% Harmony-clean + H5374 (new)
> >
> > Windows x86:
> >  100% Harmony-clean
> >  97.9% Harmony-clean + H5374 (old)
> >  99.6% Harmony-clean + H5374 (new)
>
> What benchmark are you using?  I saw this specialization technique give
> a reasonable boost on SPECjbb2005, with IBM VME not DRLVM, and was
> hoping it would be applicable here too.
Yep, it is SPECjbb2005, I thought it was intended, sorry. I don't
really know IBM VME so much, but I believe the boost on J9 and no
boost on DRLVM caused by  Scalar Replacement technique implemented in
Jitrino, which unboxes such primitive types (here, Integer -> int)
during the compilation, do it neglects effect of your "manual
unboxing".

> Avoiding the value dereference enhances data locality and thereby fewer CPU cache misses.
> I think we should only apply the patch if it produces a benefit to Harmony.
Yep, that's true. So I was suprised why your patch gives a
degradation, while it should give a boost - that was the firestarter
of my investigation - and I haven't complete clue even now, though we
reduced degradation significantly. I'm looking for some another not so
obvious problem there...

Thanks,
Aleksey,
ESSD, Intel.

Mime
View raw message