analyze-connectorFinds and analyses JVM recordings that live on the connector (the recording volume on an Azure file share, or in a local directory) rather than in a file the user has — the JFR recordings, heap dumps, application logs, GC logs and crash files a deployed application produced. Use whenever the user as
analyze-exceptionsAnalyses the exceptions an application threw in a Jeffrey profile and traces each one to the code in the current repository that caused it — separates the application's throws (libraries included, so timeouts and connection resets stay) from the JVM's own class-loading and linking noise, finds where
analyze-heapAnalyses a heap dump held by a running Jeffrey Microscope — what is holding the memory, what is leaking, which class loader survived a redeploy, where the waste is — starting from the catalogue or from a .hprof file Jeffrey has not seen yet. Use whenever the user asks what is holding memory, why the
analyze-jfrAnalyses a JVM profile held by a running Jeffrey Microscope — CPU, wall-clock, allocation, lock contention, trace latency, and the machine underneath: garbage collection, safepoints, JIT compilation, threads, native memory, the container and the JVM's configuration. Starts from the catalogue or from
code-insightAnswers questions about the code in the current repository from a Jeffrey profile, asked by the names in the source - whether a method or class is hot, who calls it at runtime, which of its lines the time goes to, what it calls into, which exceptions are thrown under it, which requests run it, which
compare-jfrCompares two JVM profiles held by a running Jeffrey Microscope — a before and an after — using differential flamegraphs, to answer whether a change made the application slower, faster, or allocate more. Use whenever the user asks if a change regressed performance, what got slower or faster between t
heap-sqlLoad before the first heap_executeQuery call, whichever skill is driving the analysis: the schema of a Jeffrey heap-dump index (class, instance, outbound_ref, class_instance_field, string_content, gc_root, dominator, retained_size) and the traps that return a wrong answer without an error — the stri
helpExplains what a running Jeffrey Microscope can investigate and how to get there — the areas a JFR recording or a heap dump can answer (CPU, wall-clock, allocation, locks, requests and outbound calls, the database, I/O, exceptions, GC and pauses, JIT, threads, native memory, the container, leaks, and
jfr-sqlLoad before the first jfr_executeQuery or jfr_queryEvents call, whichever skill is driving the analysis: the schema of a Jeffrey profile's JFR database (events, event_types, threads, stacktraces, frames), the field names per event type, and the traps that return a wrong answer without an error — eve
optimize-codeTurns a Jeffrey profile into concrete code changes in the current repository — maps the hottest CPU, wall-clock, allocation and blocking frames, the slowest traces, the waiting on locks and I/O, the database and HTTP work, and a heap dump's leak suspects to real source, recommends minimal behaviour-
profile-runRuns this project under a profiler and analyses what comes out — a benchmark, a test, a load script or the application itself, recorded with JFR or async-profiler, imported into a running Jeffrey Microscope and handed to analyze-jfr. Use whenever the user wants to profile something that is not recor
regression-checkDecides whether a change made this project slower, by profiling two revisions the same way and weighing them against each other — build and record each, import both into a running Jeffrey Microscope, then report what moved and by how much. Use when the user asks whether a commit, branch or pull requ
reportThe shape and the evidence rules for any performance finding drawn from a Jeffrey Microscope profile — what a finding must carry before it is worth writing down, how a figure is quoted and against what denominator, what caps a claim at medium confidence, and how the questions a recording cannot answ