What causes "Error parsing long: %s " in openjdk/jdk?

Open the replay file and locate the long value string shown in the message; check it is a plain decimal (optionally signed) 64-bit integer

openjdk/jdk · warning

Error parsing long: %s

Error message

Error parsing long: %s

What it means

While replaying a recorded compilation, ciReplay sets fields of an inline-type (value class) instance from the replay data (_vt->long_field_put). For a T_LONG field, sscanf(string_value, JLONG_FORMAT, &value) failed to parse the recorded textual value, so the message prints the offending string and the case breaks without setting the field — the field keeps its default value, making the replayed compilation potentially differ from the original.

Source

Thrown at src/hotspot/share/ci/ciReplay.cpp:1067

      case T_SHORT: {
        int value = atoi(string_value);
        _vt->short_field_put(fd->offset(), value);
        break;
      }
      case T_CHAR: {
        int value = atoi(string_value);
        _vt->char_field_put(fd->offset(), value);
        break;
      }
      case T_INT: {
        int value = atoi(string_value);
        _vt->int_field_put(fd->offset(), value);
        break;
      }
      case T_LONG: {
        jlong value;
        if (sscanf(string_value, JLONG_FORMAT, &value) != 1) {
          fprintf(stderr, "Error parsing long: %s\n", string_value);
          break;
        }
        _vt->long_field_put(fd->offset(), value);
        break;
      }
      case T_FLOAT: {
        float value = atof(string_value);
        _vt->float_field_put(fd->offset(), value);
        break;
      }
      case T_DOUBLE: {
        double value = atof(string_value);
        _vt->double_field_put(fd->offset(), value);
        break;
      }
      case T_ARRAY:
      case T_OBJECT:
        if (fd->is_null_free_inline_type() && fd->is_flat()) {

View on GitHub (pinned to 88dfb74bbe)

Solutions

Open the replay file and locate the long value string shown in the message; check it is a plain decimal (optionally signed) 64-bit integer
Fix the value by hand to decimal form, or regenerate the replay file from the original reproducing JVM
Ensure the replay file was produced and consumed by the same JDK build (JLONG_FORMAT differs between platforms/versions)
Re-run replay with -XX:+ReplayCompiles -XX:ReplayDataFile=<fixed file>

Example fix

# before (replay file line)
field com/foo/Point J 0x7fffffffffffffff

# after
field com/foo/Point J 9223372036854775807

Defensive patterns

Strategy: validation

Validate before calling

# Sanity-check all long field records in a replay file before running it:
grep -nE '^(field|staticfield).* J ' replay.log | grep -vE ' J -?[0-9]+$' \
  && echo 'malformed long values found' || echo 'long fields OK'

Prevention

Never hand-edit numeric fields into hex/float notation; keep signed decimal
Regenerate replay files on the same JDK build being used for replay
Treat any stderr noise during replay as a sign the replay diverges from the recorded compilation

When it happens

Trigger: A replay data file whose 'field ... J <value>' line for an inline-type long field contains something that does not match JLONG_FORMAT (%lld for 64-bit) — e.g. a hand-edited file, a value like '0x1234' with no hex support, 'null', an empty string, or a file truncated/corrupted mid-line.

Common situations: Manually editing replay files to bisect a compiler bug; replay files written by a JVM of a different version/architecture (32-bit %ld vs 64-bit formats); locale or whitespace damage to the file; transferring the file through a tool that mangles long lines.

Related errors

AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14). Data as JSON: /api/errors/9724074442e2031e. Report an issue: GitHub.