An official website of the United States government
This is the artifact abstract for the ICSE 2024 paper, *Semantic Analysis of Macro Usage for Portability*. This artifact provides the source code of Maki, the tool described in the paper, and instructions on how to run Maki to replicate the results originally reported in the paper. The paper's original results are also included so that one may cross-reference them against the results they obtain while attempting to replicate them. We claim the **available** and **reusable** badges. We believe this artifact deserves the available badge because it is publicly available on Zenodo at https://doi.org/10.5281/zenodo.7783131 (DOI 10.5281/zenodo.7783131). We believe this artifact deserves the reusable badge because it includes instructions for reproducing all the paper's major results, along with a dataset one may verify them against. This artifact also utilizes Docker to facilitate reuse, as recommended in the ICSE 2024 Call for Artifact Submissions. A reviewer who wishes to evaluate this artifact must be familiar with Docker and the Linux command line. Clang and Python experience is advised, but not essential. A reviewer will need Docker to run the artifact, and should have a device with at least 8 threads and 8GB of RAM. "Kicking the tires" and replicating a portion of the paper's original results should take about 20 minutes of time and 2GB of storage memory. Replicating the paper's full results would require over two weeks of time and 620GB of storage memory. The artifact does not require any specific operating system or environment to run.
more »
« less
Artifact for Jmvx: Fast Multi-threaded Multi-Version eXecution and Record-Replay for Managed Languages
Introduction Java Multi-Version Execution (JMVX) is a tool for performing Multi-Version Execution (MVX) and Record Replay (RR) in Java. Most tools for MVX and RR observe the behavior of a program at a low level, e.g., by looking at system calls. Unfortunately, this approach fails for high level language virtual machines due to benign divergences (differences in behavior that accomplish that same result) introduced by the virtual machine -- particularly by garbage collection and just-in-time compilation. In other words, the management of the virtual machines creates differing sequences of system calls that lead existing tools to believe a program has diverged, when in practice, the application running on top of the VM has not. JMVX takes a different approach, opting instead to add MVX and RR logic into the bytecode of compiled programs running in the VM to avoid benign divergences related to VM management. This artifact is a docker image that will create a container holding our source code, compiled system, and experiments with JMVX. The image allows you to run the experiments we used to address the research questions from the paper (from Section 4). This artifact is desiged to show: [Supported] JMVX performs MVX for Java [Supported] JMVX performs RR for Java [Supported] JMVX is performant In the "Step by Step" section, we will point out how to run experiments to generate data supporting these claims. The 3rd claim is supported, however, it may not be easily reproducible. For the paper we measured performance on bare metal rather than in a docker container. When testing the containerized artifact on a Macbook (Sonoma v14.5), JMVX ran slower than expected. Similarly, see the section on "Differences From Experiment" to see properties of the artifact that were altered (and could affect runtime results). Thanks for taking the time to explore our artifact. Hardware Requirements x86 machine running Linux, preferably Ubuntu 22.04 (Jammy) 120 Gb of storage About 10 Gb of RAM to spare 2+ cores Getting Started Guide Section is broken into 2 parts, setting up the docker container and running a quick experiment to test if everything is working. Container Setup Download the container image (DOI 10.5281/zenodo.12637140). If using docker desktop, increase the size of the virtual disk to 120 gb. In the GUI goto Settings > Resources > Virtual Disk (should be a slider). From the terminal, modify `diskSizeMiB` field in docker's `settings.json` and restart docker. Linux location: ~/.docker/desktop/settings.json. Mac location : ~/Library/Group Containers/group.com.docker/settings.json. Install with docker load -i java-mvx-image.tar.gz This process takes can take 30 minutes to 1 hour. Start the container via: docker run --name jmvx -it --shm-size="10g" java-mvx The `--shm-size` parameter is important as JMVX will crash the JVM if not enough space is available (detected via a SIGBUS error). Quick Start The container starts you off in an environment with JMVX already prepared, e.g., JMVX has been built and the instrumentation is done. The script test-quick.sh will test all of JMVX's features for DaCapo's avrora benchmark. The script has comments explaining each command. It should take about 10 minutes to run. The script starts by running our system call tracer tool. This phase of the script will create the directory /java-mvx/artifact/trace, which will contain: natives-avrora.log -- (serialized) map of methods, that resulted in system calls, to the stack trace that generated the call. /java-mvx/artifact/scripts/tracer/analyze2.sh is used to analyze this log and generate other files in this directory. table.txt - a table showing how many unique stack traces led to the invocation of a native method that called a system call. recommended.txt - A list of methods JMVX recommends to instrument for the benchmark. dump.txt - A textual dump of the last 8 methods from every stack trace logged. This allows us to reduce the number of methods we need to instrument by choosing a wrapper that can handle multiple system calls. `FileSystemProvider.checkAccess` is an example of this. JMVX will recommend functions to instrument, these are included in recommended.txt. If you inspect the file, you'll see some simple candidates for instrumentation, e.g., available, open, and read, from FileInputStream. The instrumentation code for FileInputInputStream can be found in /java-mvx/src/main/java/edu/uic/cs/jmvx/bytecode/FileInputStreamClassVisitor.java. The recommendations work in many cases, but for some, e.g. FileDescriptor.closeAll, we chose a different method (e.g., FileInputStream.close) by manually inspecting dump.txt. After tracing, runtime data is gathered, starting with measuring the overhead caused by instrumentation. Next it will move onto getting data on MVX, and finally RR. The raw output of the benchmark runs for these phases is saved in /java-mvx/artifact/data/quick. Tables showing the benchmark's runtime performance will be placed in /java-mvx/artifact/tables/quick. That directory will contain: instr.txt -- Measures the overhead of instrumentation. mvx.txt -- Performance for multi-version execution mode. rec.txt -- Performance for recording. rep.txt -- Performance for replaying. This script captures data for research claims 1-3 albeit for a single benchmark and with a single iteration. Note, data is captured for the benchmark's memory usage, but the txt tables only display runtime data. For more, see readme.pdf or readme.md.
more »
« less
- Award ID(s):
- 2227183
- PAR ID:
- 10600851
- Publisher / Repository:
- Zenodo
- Date Published:
- Format(s):
- Medium: X
- Right(s):
- Publicly accessible
- Sponsoring Org:
- National Science Foundation
More Like this
-
-
This artifact contains resources for reproducing and extending the work "The Effects of Computational Resources on Flaky Tests" Contents: Analysis and Processed Test Results.tgz: An archive that contains information about the projects analyzed, summarized test results per-throttling configuration per-run, and a Jupyter notebook that detects RAFT (generating all tables and figures in the article). A README in this archive provides further guidance on its contents js-results.tar, java-results.tar, python-results.tar: The raw results produced by the test runner when executing each JavaScript, Java and Python project 300 times in each of the throttling configurations. See also: We have published docker containers that include each project that we studied, along with all of the dependenices for running the tests. These containers can be used to reproduce our results, or to extend our work by running additional tests. The containers are available at https://hub.docker.com/r/jonbell/raft/tagsmore » « less
-
{"Abstract":["This data set contains all classifications that the Gravity Spy Machine Learning model for LIGO glitches from the first three observing runs (O1, O2 and O3, where O3 is split into O3a and O3b). Gravity Spy classified all noise events identified by the Omicron trigger pipeline in which Omicron identified that the signal-to-noise ratio was above 7.5 and the peak frequency of the noise event was between 10 Hz and 2048 Hz. To classify noise events, Gravity Spy made Omega scans of every glitch consisting of 4 different durations, which helps capture the morphology of noise events that are both short and long in duration.<\/p>\n\nThere are 22 classes used for O1 and O2 data (including No_Glitch and None_of_the_Above), while there are two additional classes used to classify O3 data.<\/p>\n\nFor O1 and O2, the glitch classes were: 1080Lines, 1400Ripples, Air_Compressor, Blip, Chirp, Extremely_Loud, Helix, Koi_Fish, Light_Modulation, Low_Frequency_Burst, Low_Frequency_Lines, No_Glitch, None_of_the_Above, Paired_Doves, Power_Line, Repeating_Blips, Scattered_Light, Scratchy, Tomte, Violin_Mode, Wandering_Line, Whistle<\/p>\n\nFor O3, the glitch classes were: 1080Lines, 1400Ripples, Air_Compressor, Blip, Blip_Low_Frequency<\/strong>, Chirp, Extremely_Loud, Fast_Scattering<\/strong>, Helix, Koi_Fish, Light_Modulation, Low_Frequency_Burst, Low_Frequency_Lines, No_Glitch, None_of_the_Above, Paired_Doves, Power_Line, Repeating_Blips, Scattered_Light, Scratchy, Tomte, Violin_Mode, Wandering_Line, Whistle<\/p>\n\nIf you would like to download the Omega scans associated with each glitch, then you can use the gravitational-wave data-analysis tool GWpy. If you would like to use this tool, please install anaconda if you have not already and create a virtual environment using the following command<\/p>\n\n```conda create --name gravityspy-py38 -c conda-forge python=3.8 gwpy pandas psycopg2 sqlalchemy```<\/p>\n\nAfter downloading one of the CSV files for a specific era and interferometer, please run the following Python script if you would like to download the data associated with the metadata in the CSV file. We recommend not trying to download too many images at one time. For example, the script below will read data on Hanford glitches from O2 that were classified by Gravity Spy and filter for only glitches that were labelled as Blips with 90% confidence or higher, and then download the first 4 rows of the filtered table.<\/p>\n\n```<\/p>\n\nfrom gwpy.table import GravitySpyTable<\/p>\n\nH1_O2 = GravitySpyTable.read('H1_O2.csv')<\/p>\n\nH1_O2[(H1_O2["ml_label"] == "Blip") & (H1_O2["ml_confidence"] > 0.9)]<\/p>\n\nH1_O2[0:4].download(nproc=1)<\/p>\n\n```<\/p>\n\nEach of the columns in the CSV files are taken from various different inputs: <\/p>\n\n[\u2018event_time\u2019, \u2018ifo\u2019, \u2018peak_time\u2019, \u2018peak_time_ns\u2019, \u2018start_time\u2019, \u2018start_time_ns\u2019, \u2018duration\u2019, \u2018peak_frequency\u2019, \u2018central_freq\u2019, \u2018bandwidth\u2019, \u2018channel\u2019, \u2018amplitude\u2019, \u2018snr\u2019, \u2018q_value\u2019] contain metadata about the signal from the Omicron pipeline. <\/p>\n\n[\u2018gravityspy_id\u2019] is the unique identifier for each glitch in the dataset. <\/p>\n\n[\u20181400Ripples\u2019, \u20181080Lines\u2019, \u2018Air_Compressor\u2019, \u2018Blip\u2019, \u2018Chirp\u2019, \u2018Extremely_Loud\u2019, \u2018Helix\u2019, \u2018Koi_Fish\u2019, \u2018Light_Modulation\u2019, \u2018Low_Frequency_Burst\u2019, \u2018Low_Frequency_Lines\u2019, \u2018No_Glitch\u2019, \u2018None_of_the_Above\u2019, \u2018Paired_Doves\u2019, \u2018Power_Line\u2019, \u2018Repeating_Blips\u2019, \u2018Scattered_Light\u2019, \u2018Scratchy\u2019, \u2018Tomte\u2019, \u2018Violin_Mode\u2019, \u2018Wandering_Line\u2019, \u2018Whistle\u2019] contain the machine learning confidence for a glitch being in a particular Gravity Spy class (the confidence in all these columns should sum to unity). <\/p>\n\n[\u2018ml_label\u2019, \u2018ml_confidence\u2019] provide the machine-learning predicted label for each glitch, and the machine learning confidence in its classification. <\/p>\n\n[\u2018url1\u2019, \u2018url2\u2019, \u2018url3\u2019, \u2018url4\u2019] are the links to the publicly-available Omega scans for each glitch. \u2018url1\u2019 shows the glitch for a duration of 0.5 seconds, \u2018url2\u2019 for 1 seconds, \u2018url3\u2019 for 2 seconds, and \u2018url4\u2019 for 4 seconds.<\/p>\n\n```<\/p>\n\nFor the most recently uploaded training set used in Gravity Spy machine learning algorithms, please see Gravity Spy Training Set on Zenodo.<\/p>\n\nFor detailed information on the training set used for the original Gravity Spy machine learning paper, please see Machine learning for Gravity Spy: Glitch classification and dataset on Zenodo. <\/p>"]}more » « less
-
The following repository contains the data used for the manuscript: "Searching for Low-Mass Exoplanets Amid Stellar Variability with a Fixed Effects Linear Model of Line-by-Line Shape Changes". Within line_property_files.zip there is file "line_property_files_README.md" that contains a description of each column of completeLines.csv. The important columns of this csv are date: time of observation line_order: unique identifier of a line, a combination of that line's central wavelength and order ID rv_template_0.5: the RV measure for a given line on a given day fit_gauss_a,fit_gauss_b,fit_gauss_depth,fit_gauss_sigmasq,proj_hg_coeff_0,proj_hg_coeff_2,proj_hg_coeff_3,proj_hg_coeff_4,proj_hg_coeff_5,proj_hg_coeff_6,proj_hg_coeff_7,proj_hg_coeff_8,proj_hg_coeff_9,proj_hg_coeff_10: the shape-change covariates that we use to control for stellar activity Below is a description of each of the data files completeLines.csv: this csv file contains the time series of every line's shape measurements and RVs, it is used throughout the analysis. line_property_files.zip: this directory contains .h5 files that contain all line-shape information and contaminated RVs for each line used in our analysis. The script clean_data.Rmd uses these as input and combines them all into a single csv file called completeLines.csv. project_template_deriv_onto_gh.h5: this contains the projection vector described in the paper to produce the orthogonal HG coefficients. The script clean_data.Rmd uses this as input and combines them all into a single csv file called completeLines.csv. models.zip: this directory contains the results from each model that was fit for our paper.more » « less
-
{"Abstract":["Data used for the two-hour photoelasticity lesson on September 29, 2022 at the 2022 ALERT Doctoral School in Aussois, France. <\/p>\n\nIn the Data directory, you will find the PEGS-master, PhotoelasticDisks, and Results subdirectories. You will also find the Jupyter notebook ALERTPhotoelasticity_220929_v1.ipynb.<\/p>\n\nPhotoelasticity data is in the PhotoelasticDisks subdirectory. N_Image and P_Image contain a sequence of images of 511 bidisperse birefringent disks in simple shear as viewed with unpolarized light and polarized light, respectively. The Positions subdirectory contains the position and radii of the disks in disks in each image. The G2images and radii_highlighted subdirectories contain, respectively: (1) images of each particle colored by G^2 as computed from the photoelasticity images via methods described in (Daniels, et al., Review of Scientific Instruments, 88, 051808 (2017)); (2) images of deformation of the particle with the outlines of each particle highlighted. Computations are performed in the accompanying ALERTPhotoelasticity_220929_v1.ipynb Jupyter notebook, which may be opened on any computer supporting jupyter notebooks or through Google Colab.<\/p>\n\nWithin PEGS-master, you can open PeGSDiskSolve.m to solve for inter-particle forces using methods described in Sec. V of (Daniels, et al., Review of Scientific Instruments, 88, 051808 (2017)) and in the thesis of James Puckett (thesis titled "State Variables in Granular Materials: an Investigation of Volume and Stress Fluctuations" and completed at North Carolina State University in 2012). You can also find a script titled "PlotExpVsSynth.m" that compares results from G^2 calculations; results are put into the Results subdirectory.<\/p>\n\nPaths may need to be changed in all scripts.<\/p>\n\nRelated content from the doctoral school can be found here: https://github.com/alert-geomaterials/2022-doctoral-school. <\/p>"]}more » « less
