call site generation for string concat

[Mahmoud-Khawaja]

I recently added support for string concatenation in #546 , however there are some edge cases that still need to be handled. Below is a high-level overview of my implementation.

---

Overview: String Concatenation in JPF

When JPF encounters string concatenation (like "Hello " + name + "!"), here's the simplified execution flow:

1. Java Compilation (Background)

// Java source: "Hello " + name + "!"
// Compiles to: invokedynamic #4 makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
// With recipe: "Hello \u0001!"  (\u0001 = placeholder for variable)

the work flow when we encounter a string concat call site will start from here in the invokedyanmic

2. INVOKEDYNAMIC Instruction Execution

@Override
public Instruction execute(ThreadInfo ti) {
    // 1. Get bootstrap method info from class
    BootstrapMethodInfo bmi = enclosingClass.getBootstrapMethodInfo(bootstrapMethodIndex);
    
    // 2. Create or retrieve cached CallSite
    CallSite callSite = getOrCreateCallSite(callSiteKey, ti, enclosingClass, bmi);
    
    // 3. Execute the CallSite
    return executeCallSite(ti, callSite, bmi);
}

private CallSite createStringConcatCallSite(MethodHandles.Lookup lookup, String name, MethodType methodType) {
    // 1. Extract recipe: "Hello \u0001!" 
    // 2. Extract constants: []
    // 3. Get actual parameter types: [String.class]
    // 4. Create MethodHandle that calls JPFStringConcatHelper.concatenate()
    // 5. Return ConstantCallSite with the handle
}

3. String Concatenation Execution

// In INVOKEDYNAMIC.java
private Instruction executeStringConcatenation(ThreadInfo ti, MethodHandle target, MethodType type, BootstrapMethodInfo bmi) {
    // 1. Pop arguments from JPF operand stack: ["World"]
    // 2. Convert JPF ElementInfo objects to Java objects
    // 3. Call MethodHandle: target.invokeWithArguments(args)
    // 4. Get result: "Hello World!"
    // 5. Push result back to JPF stack as new String ElementInfo
}

4. Actual Concatenation Logic

// In JPFStringConcatHelper.java
public static String concatenate(String recipe, Class<?>[] argTypes, Object[] constants, Object... args) {
    // 1. Parse recipe: "Hello \u0001!"
    // 2. For each character:
    //    - Regular char: append to result
    //    - \u0001: append next argument from args[]
    //    - \u0002: append constant from constants[]
    // 3. Return: "Hello World!"
}

This implementation allows JPF to correctly model Java 9+ string concatenation without breaking compatibility with JPF's internal object representation system.

[Mahmoud-Khawaja]

the implementaion is mostly correct but we have some failing tests in JSONTest.java

The SAM descriptor was being incorrectly parsed as
(FFF)Ljava/lang/String; (3 floats)
when the actual method signature should have been
(DDD)V (3 doubles) for assertEquals(double, double, double) calls.

and those are the dubuggin statements:

[DEBUG] Parsing SAM descriptor: (FFF)Ljava/lang/String;
[DEBUG] CallSite target type: (float,float,float)String

which is totally what we dont want
of course this will cause Stack Corruption from Incorrect Slot Management
and i think this is why we actaully getting those faling tests

[Mahmoud-Khawaja]

my guess is that i maybe doing something wrong with the signature cause we actaully has a type signature mismatch when we try to run thoses tests. but i will investigate and will fix this patch

[Mahmoud-Khawaja]

for now lets say that we have this test

  @Test
  public void testFailure() {
    if (verifyNoPropertyViolation()) {
      double expected = 1.0;
      double actual = 2.0;
      double delta = 0.1;
      assertEquals(expected, actual, delta);
    }
  }

im getting in the log wrong method handle creation

[DEBUG] Created method type: (float,float,float)String // should be double
[DEBUG] CallSite target type: (float,float,float)String

we should have 6 slots in the stack however that will incorrectly handle it as a 3 "cause its assuming its float not double"
when we try to pop from the stack it will pop 3 slots not 6. thats one problem.

the other one we're getting corrupted values
we should have 1.0, 2.0, 0.1 but we get

[DEBUG] Arg 0: 0.0 (float)          
[DEBUG] Arg 1: 1.4499999 (float)     
[DEBUG] Arg 2: -1.5881868E-23 (float) 

the string concat succeeds with the wrong values but it will crach at the end thowing out of bounds exception

[Mahmoud-Khawaja]

i think i now understand the issue with my implementation
the SAM descriptor was incorrectly parsed as (FFF) instead of (DDD)

also we need to have element info conversion cause we were passign the ElementInfo directly to the method handle.
i guess we should have something like this in invokedynamic

private Object convert(ElementInfo e){
    String className = ei.getClassInfo().getName();
    switch (className){
         case "java.lang.Byte":    return ei.getByteField("value");
        // etc
    }
}

this way will work instead of passing the internal element info objects as we are extracting the actual primitive values from the value field that method handles expect

[Mahmoud-Khawaja]

i will try to fix the last patch and finalize the pr and i think it should be working this way. what do you think about it @cyrille-artho ?

[cyrille-artho]

I see; having the wrong argument types explains the strange values, as the sizes of the exponent and mantissa differ between the two representations, so the values of two numbers representing the same bit string differ hugely.