Cache JNI call results in SysUtils on native side.

Cache JNI call results in SysUtils on native side.

BUG=323727
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=238228

[Yaron, 2013-11-27 18:40:19]

I'm not sure any of the usages listed on the bug are hot code paths. Do you have
evidence that this is costly? I mean between ContentViewCore and some other
JNI-intensive classes, it seems like this wouldn't register. If you have
evidence to the contrary, then this seems reasonable.

More importantly: I'd love to see any tooling/methodology on how you're
identifying this and other sources for expensive JNI calls

[ostap, 2013-11-28 02:28:59]

On 2013/11/27 18:40:19, Yaron wrote:
> I'm not sure any of the usages listed on the bug are hot code paths. Do you
have
> evidence that this is costly? I mean between ContentViewCore and some other
> JNI-intensive classes, it seems like this wouldn't register. If you have
> evidence to the contrary, then this seems reasonable.
> 
> More importantly: I'd love to see any tooling/methodology on how you're
> identifying this and other sources for expensive JNI calls

I didn't measure it this time. I was looking through low end device related
commits and found this when I looked into SysUtils class.
There are some places where it called quite often, like
WebKitPlatformSupportImpl::maxDecodedImageBytes() or
GLContextEGL::GetTotalGpuMemory() and also there is a great chance that it will
be called from some hot spot where it will make bigger difference, especially on
low end devices.
Also, it is pretty easy to fix by caching the value in static bool. I don't
think that device could change high end/low end status or amount of physical RAM
during chromium runtime.

[Yaron, 2013-12-02 19:00:17]

On 2013/11/28 02:28:59, ostap wrote:
> On 2013/11/27 18:40:19, Yaron wrote:
> > I'm not sure any of the usages listed on the bug are hot code paths. Do you
> have
> > evidence that this is costly? I mean between ContentViewCore and some other
> > JNI-intensive classes, it seems like this wouldn't register. If you have
> > evidence to the contrary, then this seems reasonable.
> > 
> > More importantly: I'd love to see any tooling/methodology on how you're
> > identifying this and other sources for expensive JNI calls
> 
> I didn't measure it this time. I was looking through low end device related
> commits and found this when I looked into SysUtils class.
> There are some places where it called quite often, like
> WebKitPlatformSupportImpl::maxDecodedImageBytes() or
> GLContextEGL::GetTotalGpuMemory() and also there is a great chance that it
will
> be called from some hot spot where it will make bigger difference, especially
on
> low end devices.
> Also, it is pretty easy to fix by caching the value in static bool. I don't
> think that device could change high end/low end status or amount of physical
RAM
> during chromium runtime.

lgtm

I don't think it changing is a concern either, I just was curious whether this
really helps. I'm still not entirely convinced but if it is called a lot from
deep within c++ gpu code it may help. Perhaps you can do more rigorous analysis,
and instrument the JNI generator to look for other cases such as the one in
https://codereview.chromium.org/26129009/ ?

[ostap, 2013-12-02 20:08:15]

On 2013/12/02 19:00:17, Yaron wrote:
> Perhaps you can do more rigorous analysis,
> and instrument the JNI generator to look for other cases 

I think it is great idea. Created bug for this:
http://code.google.com/p/chromium/issues/detail?id=324902

[commit-bot: I haz the power, 2013-12-02 20:10:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sl.ostapenko@samsung.com/89773002/1

[commit-bot: I haz the power, 2013-12-02 23:27:05]

Change committed as 238228