Community
Participate
Working Groups
Currently, Eclipse processes annotations by loading the user's annotation processor into its own VM. This enhancement requests that annotations be processed in a separate VM. Problems with the same-VM approach: 1. On linux, the VM will crash if a memory-mapped jar or class file goes away. Since build artifacts are usually temporary files and may be stored on unreliable network storage. This can cause Eclipse to segfault seemingly randomly when working with an annotation-heavy code base. 2. Some annotation processors leak memory. This is not a big problem for javac, which is a short-running operation and is only used for one build, but Eclipse is a long-running tool which will be used for many builds so leaks have a long time to build up. Eclipse is the very tool our users should be using to fix a leaky annotation processor, so supporting leaky annotation processors should be a supported use-case. 3. Some annotation processors are unstable and can crash. Much like with 2, this should be a supported use-case in the sense that Eclipse should assist with fixing said crashes rather than crashing itself. 4. Annotation processors can load a lot of classes that aren't otherwise needed by the rest of Eclipse. When running in the same VM, these classes have a permanent memory cost. Running a second VM instance would allow this memory to be reclaimed immediately after the build. Extracted from bug 469537
