1455006 - Java thread not collecting any samples on (some?) phones

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect, P1)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

This worked at one point, but seems to be broken currently.

Comment 1

[Markus Stange [:mstange]]

see also bug 1449983

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Marking the dependency, but I expect this will likely be just a dupe.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

The fix from bug 1449983 doesn't seem to be enough: https://perfht.ml/2vZ0LCI
I don't see any Java-related frames and the Java Main Thread is empty.

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

> The fix from bug 1449983 doesn't seem to be enough: https://perfht.ml/2vZ0LCI
> I don't see any Java-related frames and the Java Main Thread is empty.

Comment 5

[Makoto Kato [:m_kato]]

(In reply to Panos Astithas [:past] (please ni?) from comment #3)
> The fix from bug 1449983 doesn't seem to be enough: https://perfht.ml/2vZ0LCI
> I don't see any Java-related frames and the Java Main Thread is empty.

I cannot reproduce it on my Nexus 5X device (Android 8.1) using Nightly 2018-04-30.  What device and OS version?

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

I'm using a Moto G5 Plus with Android 7.0 using the latest nightly. I'm recording the profile using WebIDE to connect and then use the new performance panel (devtools.performance.new-panel-enabled=true) to profile using the features Native Stacks, JavaScript and Java. Could you share a profile and how you recorded it? I'm curious to see how it's different from mine.

Comment 7

[Makoto Kato [:m_kato]]

My profile is https://perfht.ml/2HLEABe

Comment 8

[Makoto Kato [:m_kato]]

I get this by new performance panel via WebIDE + USB connect.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

Weird. I can see that in my system I get this path for libxul.so:

/data/app/org.mozilla.fennec_aurora-2/base.apk!/assets/armeabi-v7a/libxul.so

while you appear to be getting:

/data/app/org.mozilla.fennec_aurora-59qLqSLnwyw51t7COdYwPA==/base.apk!/assets/armeabi-v7a/libxul.so

Not sure if this is related or not.

Could you share a screenshot of the settings pane from the performance panel to compare? Also, what is it that you are profiling? I have a tab open that I scroll around and then open a new tab. Is this interaction supposed to add Java stacks in the profile?

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

I saw another profile from mstange that had java stacks, so it's not just working for you. Unsure if it is only broken for me though.

Comment 12

[Makoto Kato [:m_kato]]

Panos, could you test https://queue.taskcluster.net/v1/task/TgDCS3SsQF622Bv9ThTB4A/runs/0/artifacts/public/build/target.apk ?

And I would like adb logcat log when start profiling.

Comment 13

[Makoto Kato [:m_kato]]

Maybe, logcat shows "Main thread not found" when starting profile...

Comment 14

[Julien Wajsberg [:julienw]]

Couldn't it be just bug 1460973 ?

Comment 15

[:Harald Kirschner :digitarald]

So far we got Java stacks on

OnePlus 5 (Android 8): https://perfht.ml/2J14BR4
Nexus 5 (Android 5): https://perfht.ml/2klqlci

But even when it works, the stacks are erratic. Nothing is reported for the most part (bug 1460973) and when it has stacks, the sampling rate is much lower (around 10ms) than the rest of the profile (1ms).

Didn't work on so far for:

Moto G5 (Android 7)

The Android team confirmed that this is not on the critical path for GeckoView's performance (all GeckoView integration APIs are async, so Java is less likely to impact content performance); so we will not block remote debugging m1 on this but want to have this working in the medium term.

Comment 16

[Panos Astithas (he/him) [:past] (please ni?)]

With the build from comment 12 I am getting Java stacks: https://perfht.ml/2scTUAn

I will attach the logs from that session.

Comment 17

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Logcat

Comment 18

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: WebIDE console log

This is from WebIDE's console.

Comment 19

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to :Harald Kirschner :digitarald from comment #15)
> But even when it works, the stacks are erratic. Nothing is reported for the
> most part (bug 1460973) and when it has stacks, the sampling rate is much
> lower (around 10ms) than the rest of the profile (1ms).

Sampling is capped to 10 ms here:

https://searchfox.org/mozilla-central/rev/bf4def01bf8f6ff0d18f02f2d7e9efc73e12c63f/mobile/android/base/java/org/mozilla/gecko/GeckoJavaSampler.java#69-70

This is BenWa's comment from 2013:

https://bugzilla.mozilla.org/show_bug.cgi?id=788022#c13

Maybe this works well enough now without capping in our reference hardware?

Comment 20

[Makoto Kato [:m_kato]]

(In reply to Panos Astithas [:past] (please ni?) from comment #19)
> (In reply to :Harald Kirschner :digitarald from comment #15)
> > But even when it works, the stacks are erratic. Nothing is reported for the
> > most part (bug 1460973) and when it has stacks, the sampling rate is much
> > lower (around 10ms) than the rest of the profile (1ms).
> 
> Sampling is capped to 10 ms here:
> 
> https://searchfox.org/mozilla-central/rev/
> bf4def01bf8f6ff0d18f02f2d7e9efc73e12c63f/mobile/android/base/java/org/
> mozilla/gecko/GeckoJavaSampler.java#69-70

https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/tools/profiler/core/platform.cpp#2913 has another check.

> 
> This is BenWa's comment from 2013:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=788022#c13
> 
> Maybe this works well enough now without capping in our reference hardware?

I will file a new bug for changing new interval.

Comment 21

[Makoto Kato [:m_kato]]

(In reply to Panos Astithas [:past] (please ni?) from comment #16)
> With the build from comment 12 I am getting Java stacks:
> https://perfht.ml/2scTUAn

Thanks.  OK, I will request review to gv team.

Comment 22

[Makoto Kato [:m_kato]]

Attachment: Bug 1455006 - Use Looper to get main thread instead of main thread name.

Actually, Gecko uses thread name "main" to find main thread.  But Android
has Looper object to get main loop.  So we should use it instead.

Review commit: https://reviewboard.mozilla.org/r/247208/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/247208/

Comment 23

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8981100 [details]
Bug 1455006 - Use Looper to get main thread instead of main thread name.

https://reviewboard.mozilla.org/r/247208/#review253726

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/347ccb93cb08
Use Looper to get main thread instead of main thread name. r=jchen

Comment 25

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/347ccb93cb08