microsoft/gctoolkit
Publicmirrored from https://github.com/microsoft/gctoolkitAvailable
.github/copilot-instructions.md
100lines · modeblame
2cd6f661Derek Keeler7 months ago | 1 | # GitHub Copilot Instructions for GCToolKit |
| 2 | | |
| 3 | ## Project Overview | |
| 4 | GCToolKit is a Java-based toolkit for analyzing Garbage Collection logs from various JVM implementations. The project uses Maven as its build system and is structured as a multi-module project. | |
| 5 | | |
| 6 | ## Architecture & Design Patterns | |
| 7 | - **Multi-module Maven project** with clear separation of concerns | |
| 8 | - **Event-driven architecture** using Vert.x for message passing | |
| 9 | - **Parser framework** for processing various GC log formats | |
| 10 | - **Channel-based communication** between parsers and event consumers | |
| 11 | - **Verticle pattern** for asynchronous processing with Vert.x | |
| 12 | | |
| 13 | ## Module Structure | |
| 14 | - `api/` - Core API definitions, interfaces, and base classes | |
| 15 | - `parser/` - GC log parsing implementations for different JVM types | |
| 16 | - `vertx/` - Vert.x-based messaging and event handling infrastructure | |
| 17 | - `sample/` - Example usage and sample applications | |
| 18 | - `IT/` - Integration tests | |
| 19 | - `gclogs/` - Test data and sample GC logs | |
| 20 | | |
| 21 | ## Key Technologies | |
| 22 | - **Java 21+** with module system (module-info.java files) | |
| 23 | - **Vert.x 5.0.2** for reactive programming and event bus | |
| 24 | - **JUnit 5** for testing | |
| 25 | - **Maven** for build management | |
| 26 | - **Spotbugs, PMD, Checkstyle** for code quality | |
| 27 | | |
| 28 | ## Code Style & Conventions | |
| 29 | - Follow standard Java naming conventions | |
| 30 | - Use proper JavaDoc for public APIs | |
| 31 | - Implement equals/hashCode when appropriate | |
| 32 | - Use logging with java.util.logging | |
| 33 | - Handle exceptions appropriately with try-catch blocks | |
| 34 | - Use Promise/Future patterns for asynchronous operations with Vert.x | |
| 35 | | |
| 36 | ## Common Patterns in This Codebase | |
| 37 | | |
| 38 | ### Event Processing | |
| 39 | ```java | |
| 40 | public void start(Promise<Void> promise) { | |
| 41 | vertx.eventBus().<EventType>consumer(inbox, message -> { | |
| 42 | processor.receive(message.body()); | |
| 43 | }).completion() | |
| 44 | .onComplete(ar -> promise.complete()); | |
| 45 | } | |
| 46 | ``` | |
| 47 | | |
| 48 | ### Channel Implementation | |
| 49 | - Extend appropriate base channel classes | |
| 50 | - Implement proper lifecycle management (open/close) | |
| 51 | - Use Vert.x deployVerticle for async operations | |
| 52 | - Handle deployment IDs for proper cleanup | |
| 53 | | |
| 54 | ### Error Handling | |
| 55 | - Use java.util.logging.Logger for logging | |
| 56 | - Log warnings/errors with proper context | |
| 57 | - Handle Future completion with onComplete callbacks | |
| 58 | | |
| 59 | ## Vert.x Specific Guidelines | |
| 60 | - Use Verticles for isolated processing units | |
| 61 | - Deploy verticles asynchronously with completion handlers | |
| 62 | - Use the event bus for inter-verticle communication | |
| 63 | - Properly manage deployment IDs to avoid double-undeploy issues | |
| 64 | - Handle Promise<Void> completion in start() methods | |
| 65 | | |
| 66 | ## Testing Conventions | |
| 67 | - Integration tests go in the `IT/` module | |
| 68 | - Unit tests use JUnit 5 | |
| 69 | - Test GC log files are stored in `gclogs/` with organized subdirectories | |
| 70 | - Mock external dependencies appropriately | |
| 71 | | |
| 72 | ## Build & Dependencies | |
| 73 | - Maven 3.9.11+ required | |
| 74 | - Use the Maven Wrapper (i.e., `mvnw`) | |
| 75 | - Keep dependencies up to date, unless you see a comment saying why not to | |
| 76 | - Use dependencyManagement in parent POM for version consistency | |
| 77 | - Include proper test scopes for test dependencies | |
| 78 | | |
| 79 | ## When Suggesting Code Changes | |
| 80 | 1. Consider the event-driven nature of the architecture | |
| 81 | 2. Ensure proper async handling with Vert.x patterns | |
| 82 | 3. Maintain compatibility with existing interfaces | |
| 83 | 4. Add appropriate logging and error handling | |
| 84 | 5. Follow the established module boundaries | |
| 85 | 6. Consider performance implications for GC log processing | |
| 86 | 7. Ensure proper resource cleanup (channels, verticles, etc.) | |
| 87 | | |
| 88 | ## Common Issues to Avoid | |
| 89 | - Double-undeployment of Vert.x verticles | |
| 90 | - Blocking operations in Vert.x event loops | |
| 91 | - Memory leaks from unclosed channels or resources | |
| 92 | - Incorrect Promise/Future completion handling | |
| 93 | - Missing error handling in async operations | |
| 94 | | |
| 95 | ## File Naming Patterns | |
| 96 | - Verticles: `*Verticle.java` | |
| 97 | - Channels: `*Channel.java` | |
| 98 | - Events: `*Event.java` | |
| 99 | - Tests: `*Test.java` | |
| 100 | - Integration tests: `*IT.java` or in IT module |