cobalt/metrics: Add interfaces and stubs for granular memory tracking.

[Awallky]

This commit introduces the DetailedMetricsDelegate interface and necessary
stubs in OSMetrics to support custom memory categorization in Cobalt.
It also includes a Starboard wrapper for prctl to support VMA naming.

• Add DetailedMetricsDelegate interface.
• Add stubs in OSMetrics for delegate interaction.
• Add Starboard wrapper for prctl (VMA naming).

Bug: 494004530

[github-actions]

🤖 Gemini Suggested Commit Message

---

cobalt: Add interfaces for granular memory tracking

This change introduces the DetailedMetricsDelegate interface and
associated infrastructure within the memory instrumentation service.
It enables project-specific collection and categorization of detailed
memory metrics, particularly by processing /proc/self/smaps data.

The goal is to provide a mechanism for Cobalt to implement granular
memory tracking for its components, facilitating deeper insights into
memory usage for optimization and debugging.

Bug: 494004530

---

💡 Pro Tips for a Better Commit Message:

1. Influence the Result: Want to change the output? You can write custom prompts or instructions directly in the Pull Request description. The model uses that text to generate the message.
2. Re-run the Generator: Post a comment with: /generate-commit-message

[gemini-code-assist]

Code Review

This pull request introduces the DetailedMetricsDelegate interface and DetailedMetrics structure to enable project-specific memory metrics collection. It updates MemoryInstrumentation and OSMetrics to integrate this delegate and adds conditional Mojo fields for detailed stats. Key feedback includes providing definitions for the DetailedMetrics lifecycle methods to prevent linker errors, removing redundant global state in OSMetrics in favor of explicit parameter passing, and addressing thread-safety concerns regarding raw pointer access to the delegate.

[gemini-code-assist]

The DetailedMetrics struct declares a constructor, destructor, and move operations but does not provide definitions. Since this is a new header and no corresponding .cc file is included in the PR, this will result in linker errors. If these are intended to be default implementations, they should be defined as = default in the header. Additionally, per Chromium style, move operations should be marked noexcept to allow for optimizations when used in containers.

  DetailedMetrics() = default;
  ~DetailedMetrics() = default;
  DetailedMetrics(DetailedMetrics&&) noexcept = default;
  DetailedMetrics& operator=(DetailedMetrics&&) noexcept = default;

References

1. Adhere to established upstream Chromium style guides for C++ code, including the use of = default and noexcept for move operations. ^(link)

[gemini-code-assist]

The addition of a static SetDetailedMetricsDelegate method introduces global state into the OSMetrics utility class. Since FillOSMemoryDump has been updated to accept a DetailedMetricsDelegate* as a parameter (line 57), this static setter is redundant and creates ambiguity regarding which delegate is used. It is better to pass the delegate explicitly through the call chain to keep OSMetrics stateless and easier to test, consistent with Chromium's preference for avoiding global state in utility classes.

References

1. Follow Chromium best practices by avoiding global state in utility classes and preferring explicit dependency injection via parameters. ^(link)

[gemini-code-assist]

Returning a raw pointer to the delegate from GetDetailedMetricsDelegate() is potentially unsafe, even with the use of detailed_metrics_delegate_lock_. Once the lock is released, the caller holds a pointer that could be nullified or the underlying object destroyed by another thread (e.g., via a call to SetDetailedMetricsDelegate). Consider a safer access pattern, such as passing the delegate directly to the methods that require it, or using a callback/observer pattern if the lifetime cannot be strictly guaranteed.