Don't register JNI methods for the android_webview.

Don't register JNI methods for the android_webview.

Rather than registering all jni bindings at startup, only get references
to the class object for those files which require bindings. All others
are satisfied by exporting symbols which can be found automatically by
the VM.

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

[mkosiba (inactive), 2014-08-08 16:24:14]

This is a reland of https://codereview.chromium.org/147533004/.

The original change got reverted since it broke the crazy linker. I'm going to
try and re-land it for the webview only.

[mkosiba (inactive), 2014-08-08 16:26:44]

-mcilroy, +rmcilroy for the jni generator (typo, sorry)

[mkosiba (inactive), 2014-08-08 16:27:36]

+rmcilroy for real this time.

[rmcilroy, 2014-08-11 10:16:17]

lgtm, thanks.

Out of interest, what was the reason that this broke the crazy linker?  Could we
fix this and enable it for Chrome too eventually too?

[Torne, 2014-08-11 10:24:01]

On 2014/08/11 10:16:17, rmcilroy wrote:
> lgtm, thanks.
> 
> Out of interest, what was the reason that this broke the crazy linker?  Could
we
> fix this and enable it for Chrome too eventually too?

dlsym() will not find symbols in libraries loaded by the crazy linker, so the
VM's lazy lookups all fail.

[rmcilroy, 2014-08-11 10:29:30]

On 2014/08/11 10:24:01, Torne wrote:
> On 2014/08/11 10:16:17, rmcilroy wrote:
> > lgtm, thanks.
> > 
> > Out of interest, what was the reason that this broke the crazy linker? 
Could
> we
> > fix this and enable it for Chrome too eventually too?
> 
> dlsym() will not find symbols in libraries loaded by the crazy linker, so the
> VM's lazy lookups all fail.

Yeah, makes sense. Thanks Torne.

[Torne, 2014-08-11 10:36:55]

lgtm

[mkosiba (inactive), 2014-08-11 10:42:18]

The CQ bit was checked by mkosiba@chromium.org

[commit-bot: I haz the power, 2014-08-11 10:43:28]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mkosiba@chromium.org/454923002/1

[commit-bot: I haz the power, 2014-08-11 11:27:25]

Change committed as 288685

[Yaron, 2014-08-11 17:12:28]

On 2014/08/11 11:27:25, I haz the power (commit-bot) wrote:
> Change committed as 288685

Glad to see this approach being put to use even though we can't use it for
Chrome browser

[Torne, 2014-08-11 17:23:21]

Well, Chrome may be able to use it at some point if the linker works out how to
allow it. :)

[ostap, 2014-08-11 19:21:48]

On 2014/08/11 17:23:21, Torne wrote:
> Well, Chrome may be able to use it at some point if the linker works out how
to
> allow it. :)

Is it possible to integrate crazy linker into android libc and fix resolving of
the shared library symbols? If chromium browser has an improvement from crazy
linker, may be other apps loading also would be improved?

There is long open sourceware bug about loading dlopen of in-memory objects,
which I think could be helpful in this case:
https://sourceware.org/bugzilla/show_bug.cgi?id=11767
Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym calls and
do symbol lookups before libc. Unfortunately it doesn't exist in android libc. 
Otherwise there is no way to access libc symbol tables to add symbols resolved
by crazy linker.

[chromium-reviews, 2014-08-12 09:15:23]

+simonb (see question below)


On 11 August 2014 20:21, <sl.ostapenko@samsung.com> wrote:

> On 2014/08/11 17:23:21, Torne wrote:
>
>> Well, Chrome may be able to use it at some point if the linker works out
>> how
>>
> to
>
>> allow it. :)
>>
>
> Is it possible to integrate crazy linker into android libc and fix
> resolving of
> the shared library symbols? If chromium browser has an improvement from
> crazy
> linker, may be other apps loading also would be improved?
>
> There is long open sourceware bug about loading dlopen of in-memory
> objects,
> which I think could be helpful in this case:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym
> calls and
> do symbol lookups before libc. Unfortunately it doesn't exist in android
> libc.
> Otherwise there is no way to access libc symbol tables to add symbols
> resolved
> by crazy linker.
>
> https://codereview.chromium.org/454923002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[mkosiba (inactive), 2014-08-12 09:47:46]

On 2014/08/11 19:21:48, ostap wrote:
> On 2014/08/11 17:23:21, Torne wrote:
> > Well, Chrome may be able to use it at some point if the linker works out how
> to
> > allow it. :)
> 
> Is it possible to integrate crazy linker into android libc and fix resolving
of
> the shared library symbols? If chromium browser has an improvement from crazy
> linker, may be other apps loading also would be improved?
> 
> There is long open sourceware bug about loading dlopen of in-memory objects,
> which I think could be helpful in this case:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym calls
and
> do symbol lookups before libc. Unfortunately it doesn't exist in android libc.

> Otherwise there is no way to access libc symbol tables to add symbols resolved
> by crazy linker.

Are we doing this for perf reasons?

torne@ did some very basic measurements of the time it takes to run the jni
and it looked like the majority of the overhead is coming from loading the class
(that is the 'GetClass' call) and not from the method registrations, so this
change might make things worse, since we'd be trading off the very cheap eager
method registrations for (potentially) more costly lazy lookups.

Did you measure the perf impact of your changes?

[mkosiba (inactive), 2014-08-12 09:47:49]

On 2014/08/11 19:21:48, ostap wrote:
> On 2014/08/11 17:23:21, Torne wrote:
> > Well, Chrome may be able to use it at some point if the linker works out how
> to
> > allow it. :)
> 
> Is it possible to integrate crazy linker into android libc and fix resolving
of
> the shared library symbols? If chromium browser has an improvement from crazy
> linker, may be other apps loading also would be improved?
> 
> There is long open sourceware bug about loading dlopen of in-memory objects,
> which I think could be helpful in this case:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym calls
and
> do symbol lookups before libc. Unfortunately it doesn't exist in android libc.

> Otherwise there is no way to access libc symbol tables to add symbols resolved
> by crazy linker.

Are we doing this for perf reasons?

torne@ did some very basic measurements of the time it takes to run the jni
and it looked like the majority of the overhead is coming from loading the class
(that is the 'GetClass' call) and not from the method registrations, so this
change might make things worse, since we'd be trading off the very cheap eager
method registrations for (potentially) more costly lazy lookups.

Did you measure the perf impact of your changes?

[Torne, 2014-08-12 09:48:18]

On 2014/08/11 19:21:48, ostap wrote:
> On 2014/08/11 17:23:21, Torne wrote:
> > Well, Chrome may be able to use it at some point if the linker works out how
> to
> > allow it. :)
> 
> Is it possible to integrate crazy linker into android libc and fix resolving
of
> the shared library symbols? If chromium browser has an improvement from crazy
> linker, may be other apps loading also would be improved?

I implemented the relro sharing part of the crazy linker into the android C
library already, but this doesn't solve the problem for Chrome since this change
is only available in the upcoming Android L release, and Chrome supports all the
way back to ICS using the same binary.

> There is long open sourceware bug about loading dlopen of in-memory objects,
> which I think could be helpful in this case:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym calls
and
> do symbol lookups before libc. Unfortunately it doesn't exist in android libc.

> Otherwise there is no way to access libc symbol tables to add symbols resolved
> by crazy linker.

Unfortunately for the same reason we also can't rely on adding hooks to the
system linker since they won't exist on older OS versions.

[dehao, 2014-09-09 23:00:41]

Hi,

This patch will break FDO instrumentation build because compiler generated
global symbol will not be emitted in the libwebviewchromium.so

Dehao

On 2014/08/12 09:48:18, Torne wrote:
> On 2014/08/11 19:21:48, ostap wrote:
> > On 2014/08/11 17:23:21, Torne wrote:
> > > Well, Chrome may be able to use it at some point if the linker works out
how
> > to
> > > allow it. :)
> > 
> > Is it possible to integrate crazy linker into android libc and fix resolving
> of
> > the shared library symbols? If chromium browser has an improvement from
crazy
> > linker, may be other apps loading also would be improved?
> 
> I implemented the relro sharing part of the crazy linker into the android C
> library already, but this doesn't solve the problem for Chrome since this
change
> is only available in the upcoming Android L release, and Chrome supports all
the
> way back to ICS using the same binary.
> 
> > There is long open sourceware bug about loading dlopen of in-memory objects,
> > which I think could be helpful in this case:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> > Glibc 2.19 has _dlfcn_hook which can be used to intercept dlopen/dlsym calls
> and
> > do symbol lookups before libc. Unfortunately it doesn't exist in android
libc.
> 
> > Otherwise there is no way to access libc symbol tables to add symbols
resolved
> > by crazy linker.
> 
> Unfortunately for the same reason we also can't rely on adding hooks to the
> system linker since they won't exist on older OS versions.