Closed Bug 1616622 Opened 5 months ago Closed 4 months ago

Java sampling is limited to 10 seconds due to a hardcoded limit


(Core :: Gecko Profiler, defect, P2)




Tracking Status
firefox75 --- fixed


(Reporter: mstange, Assigned: canova)


(Blocks 1 open bug)



(3 files)


It would be nice to capture more than 10 seconds of Java sampling. At the moment, there's an artificial limit to 1000 samples:

The Java profiling code hasn't seen much love and is basically unchanged from its state in 2013.

Since Fenix makes heavy use of Java/Kotlin, I think Java profiling is more important than it once was.

Nazim, is this something you can help with?

Flags: needinfo?(canaltinova)
Priority: -- → P2
Depends on: 1616887
Blocks: 1616887
No longer depends on: 1616887

Sorry about not writing here before, I saw that and looking into it. Keeping the needinfo.

Assignee: nobody → canaltinova

Currently we only profile the Java Main Thread, and don't profile anything
else. This is not ideal, but this is how it works right now. And inside the
code index 0 was hardcoded on the most parts of the code. We can rollback
this patch once we want to implement profiling more than one thread, or we can
think about something more clever.

This class is not technically the thread itself, it's the runnable that the
sampling thread uses. This name is more accurate and clear for it.

Depends on D64752

The previous samples buffer had a limited size and it was only keeping the
samples for 10 seconds. We wanted to increase the amount of samples we want to
keep but we also wanted to make sure that we are not allocating a lot of memory
at the start. So we created a segmented buffer instead(LinkedList<Sample[]>)
With this buffer, we don't create the whole buffer at the start but we create
small portions of the buffer on the go. Since we use LinkedList, we do not copy
all the memory while allocating more memory, so it's more performant compared
to its alternative.
We also had to keep the circular nature of the buffer and make sure that we are
not breaking java side when we are out of the whole segmented buffer.
Disclaimer: This circular buffer is extremely naive and doesn't look like the
circular buffer in the profiler cpp side. But I wanted to keep it like this
because 1) it was like this in it's previous implementation. 2) I wanted to
land this work as soon as possible so people can start profiling java thread
more than 10 seconds sooner. But I intend to work on this after this work and
make it more performant.

Depends on D64753

Clearing the needinfo after the patches.

Flags: needinfo?(canaltinova)
Attachment #9129768 - Attachment description: Bug 1616622 - Implement a segmented circular buffer and increase the buffer limit r?gerald,julienw → Bug 1616622 - Increase the buffer limit and refactor the java code r?gerald,julienw
Pushed by
Remove the SparseArray from the samples array since we only profile the main thread. r=julienw
Rename SamplingThread class to SamplingRunnable instead. r=julienw
Increase the buffer limit and refactor the java code r=gerald,julienw
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
You need to log in before you can comment on or make changes to this bug.