"record" feature in jpf-core/java-17 #484
Comments
|
BTW, when we wrap the All the above |
|
Please look into the compiled bytecode to see what may have caused this behavior in JPF. It is possible that JPF completely misinterprets new bytecode attributes that were introduced in Java 17, as its class loader has been written for older versions of Java. |
|
"Please look into the compiled bytecode to see what may have caused this behavior in JPF. It is possible that JPF completely misinterprets new bytecode attributes that were introduced in Java 17, as its class loader has been written for older versions of Java." -----> I created a regular class equivalent to record functionality and tested them. Everything was fine as all Tests passed. Got this idea from different source (like ChatGPT) to try, things will be more clear. "Also, share your WIP on a branch so Pavel and I can take a look." -----> https://github.com/eklaDFF/jpf-core/tree/NewFeatureRecordRoughBranch |
|
Use |
I need to compile them first. But do not know how in this case. |
|
You indicate the fully qualified class name, not the file name. Use |
|
Thankyou @cyrille-artho This one worked : Here is the output for above command (I will take some time to study about Byte Codes. This is a great opportunity to learn about Byte Codes.) : |
|
In the stack trace above, which is the method that cannot be loaded? What method is the one causing the index out of bounds at |
|
Also, please look at class |
|
Tried to understand the execution flow : Start of Test Is this right direction to explore ? |
|
I don't think the problem is in the state space exploration. I think it's the fact that JPF encounters an unfamiliar data element in the constant pool, which it does not parse correctly. Look at the stack trace in your earlier comment: #484 (comment) |
|
Well, now where should I look. May be when we are instantiating Point Object creation, causes this error ? |
|
Look at the stack trace and how the class file gets parsed. There is an element in the constant pool that does not get parsed correctly, which results in an array index that makes no sense (> 64). |
|
The constant pool of |
|
Flow of Code : Here is the method And this method has been used in When we run at this level, the output is like below : This strange output (from our printing statement) show that our issue is routed from Am I in right direction ? |
|
And also please see the similarity between |
|
The method to parse the binary content is correct, but the index (54) is wrong. |
Output :
|
|
Yes, and if you can find out where the function call was made, that will likely give us clues on the correct value. You can try the use the |
|
Above method is called from this (below) method. Both are actually overloaded methods in And then above method is called from Here is the output : index 54 is generated from |
|
Please try to set up the |
Where do I have to write the listener ? Not working in command. |
|
The option is passed to the |
|
But the new output is very large. How can I show the result to you ? Around 40 MB. |
They are to cluttered to understand. How do they mean something valuable ? |
|
Only the last part is important. We see that the problem is triggered by Now, you can look into the bytecode of that test method to see what the instructions are, and which part of the record class is used. Then, we can deduce where the wrong index comes from. |
|
I only executed We can see the and constant pool |
|
From Bytecode, it seems like it's been treated like a regular class ? (Should I delete some comments to make this issue short) |
|
We need the |
|
As mentioned in our last meeting, index (in this case 54) is correct. Then we have look how 14081 (in this case) is produced. So here is last state from where we can move ...
From above, 14081 is returned from It seems like we should check what content One more thing, I printed some value which helped me a bit... Outputs below result (here is relevant part) : |
|
The method |
|
I when we create a simple java program like below The bytecode for above program differs from the one written in our JPF Bytecode for above simple program ByteCode for JPF record My Question is, both the programs is compiled under same compiler ? If yes, how can be different bytecode for same record class(subclass) ? |
|
Should I send you more detailed explanation of the above comment . (Please check email regarding today's meeting?) |
|
Probably you are using a slightly different version of the compiler than what gradle uses. Your own Java environment does two things: 1. It runs Gradle. 2. It runs JPF when you run |
|
So, now I should go for debugging the bootstrap method along with a proper diagram comfortably? |
|
Yes, please do that; use the bytecode that Gradle produces (i.e., when you build JPF and run the tests normally). |
|
In the diagram you suggested, it is difficult to show the behaviour of the methods like manipulation of the parameters within the method. Because sometimes it is more important to show the behaviour proceeding the flow of calls. How do you do ? |
|
You want to focus on one aspect in the diagram, and I recommend you focus on the data dependencies. The control flow is simpler, and, from what we can see, JPF handles the instructions themselves correctly, but not the data. |
|
For an example, Here is the diagram, Do this adding some value ? |
|
more clear diagram for
and at the moment of error, |
|
Thanks, so it is in the bootstrap method data where the index is off by one (if I read your diagram correctly). |
The result is: In decimal, 0x3701 equals:
|
|
Here is flow of code, might help you to understand the above diagram> in in Here in Later 14081 is returned back to 14081 is greater than |
|
Thanks. The issue is in The entire mechanism of using the bootstrap information is completely different for records, as there is a specialized method to handle the data for As a first step, let's avoid walking into using Change
|
|
We can also refactor the code inside the outer |
You were right, the OutOfBoundError solved. Here is update after just above change only. all the above 5 failed tests fails with output
In the |
|
Here is how the method looks, Should I send the output of above code ? |
|
Good start. For the first "if" part, I would try to retain the check of the array size with After that, I would extract the bodies of the "if/then" part and the "else" part into a helper method ("extract method" refactoring) so that code is separate and |
|
In the refactoring, you will create three new private methods that are called from inside the different code blocks. The signature of these three new methods can be adapted from is copied into (if there are additional paramters that are needed after all, add them back) and finally You may have to add additional parameters to some of these helper methods, or you can perhaps remove some in some cases but not others. The goal is: You want to keep the exact same functionality (so you do not modify the body of the code, other than adding declarations of local variables or (in cases other than this one) |
|
Your assertion also shows that the first |
|
New modification in the
And here is how it looks like : After above modification, output is :
Here is an important part of After the modification(described at the top of this comment), going to refactor the code as per your guide (your prev comment). |
|
Great! You can now remove the debug print statements and make a pull request. |
|
Thanks, I have merged it. This results in a few failing tests, but the failing tests are all new tests (for the record features). |
|
Here refactored code for |
|
|
|
Was this output present before? |
|
Yes the behaviour is still the same because the refactoring code produces the same result. |
|
#500 Please Look into |
|
I suggest that you try implementing the method |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@cyrille-artho
@pparizek
This issue is to track the
recordfeature ofjava-17onJPF.Here is the
Testto testrecord:All of the above
Testspasses (currently on OpenJDK-17).Question 1 : How can we access the 'private
field?Question 2 : These
Testspassed on underlying JVM. DoverifyNoPropertyViolationwill make it run onJPF?The text was updated successfully, but these errors were encountered: