Software engineers must make decisions that trade off competing goals (faster vs. cheaper, secure vs. usable, accurate vs. interpretable, etc.). Despite MSR’s proven techniques for exploring such goals, researchers still struggle with these trade-offs. Similarly, industrial practitioners deliver sub-optimal products since they lack the tools needed to explore these trade-offs. To address this, MOOT (http://tiny.cc/moot) is a repository of many SE multi-objective optimization tasks. MOOT’s 120+ tasks cover software configuration, cloud tuning, project health, process modeling, hyperparameter optimization, and more. Sample scripts for reading MOOT and generating baseline results are available– just clone the repository and run the sample rqx.sh files (from tiny.cc/moot0). To the best of our knowledge, MOOT is the largest and most varied collection of real multi-objective optimization tasks in SE. We note that MOOT’s novelty is infrastructural, not algorithmic—we contribute curated data and research enablement, not new optimization methods. MOOT enables harder and more credible research. MOOT lets us replace studies on toy problems (or just half a dozen hand-picked examples) with case studies on 120+ examples. Such studies could focus on stability, sample efficiency, failure modes, cross-domain generality, or many other questions (see list in this document).

Context: Exhaustive fuzzing of modern JavaScript engines is infeasible due to the vast number of program states and execution paths. Coverage-guided fuzzers rely on coverage as a proxy for progress, but many vulnerability-triggering inputs that do not increase coverage are discarded. Since fuzzing is expensive and crashes are rare in mature engines, relying on brute-force exploration wastes substantial effort. Existing heuristics proposed to mitigate this require expert effort, are brittle, and hard to adapt. Objective: We propose a data-centric, LLM-boosted alternative that learns from historical vulnerabilities to automatically identify minimal static (code) and dynamic (runtime) features for detecting high-risk inputs. Method: Guided by historical V8 bugs, iterative prompting generated 115 static and 49 dynamic features, with the latter requiring only five trace flags, minimizing instrumentation cost. After feature selection, 41 features remained to train an XGBoost model to predict high-risk inputs during fuzzing. Results: Combining static and dynamic features yields over 85% precision and under 1% false alarm. Only 25% of these features are needed for comparable performance, showing that most of the search space is irrelevant. Conclusion: Rather than proposing a new fuzzer, this work contributes a guidance model that learns from historical vulnerabilities to identify high-risk inputs, shifting the question from ”is this path new?” to ”does this code look dangerous?” By retaining semantically dangerous inputs that coverage-based corpus management would otherwise discard, our method supports more targeted and reproducible vulnerability discovery. To support open science, all scripts and data are available at https://github.com/KKGanguly/DataCentricFuzzJS .

This dataset contains 246 bugs, their fixes and corresponding buggy projects from historical bug fixes dataset (https://github.com/xuanbachle/data-bugfixes) that fulfill the following criteria:\n\n\n\tUnique\n\tSatisfy redundancy assumption at file level\n\tFixed by applying replacement mutation\n\tRequire fixing at expression level\n\tHaving available project and dependency files\n\n\nFor details, please view https://www.scitepress.org/Link.aspx?doi=10.5220/0009411301700180

Patch prioritization means sorting candidate patches based on probability of correctness. It helps to minimize the bug fixing time and maximize the precision of an automated program repairing technique. Approaches in the literature use either syntactic or semantic similarity between faulty code and fixing element to prioritize patches. Unlike others, this paper aims at analyzing the impact of combining syntactic and semantic similarities on patch prioritization. As a pilot study, it uses genealogical and variable similarity to measure semantic similarity, and normalized longest common subsequence to capture syntactic similarity. For evaluating the approach, 22 replacement mutation bugs from IntroClassJava benchmark were used. The approach repairs all the 22 bugs and achieves a precision of 100%.