cannot find native jdk.internal.misc.CDS.isDumpingClassList0 #450
Comments
|
Hi @cyrille-artho , |
|
When JPF looks for a given class, it usually uses the class from the application or library. However, library classes often call native methods (such as in this example), which are then not supported in JPF. When you encounter a case where a native method is not supported, a choice often arises about which class in the stack trace that leads to the problem to replace with a model class (perhaps augmented by a native peer). If you replace a class further down in the stack trace, that may be a use case that is covered by other code as well, so the implementation often has to be rather comprehensive. Classes higher up in the stack trace (closer to the failure) may be smaller and thus replaceable with less effort, but they may also integrate more closely with JVM-specific native code. So there is no easy way to tell which class to replace: If there is no obvious candidate after this, it may be best to fix a different test failure first and return to this one later. Perhaps other tests show overlap with this problem. |
|
Talking particularly about the error and Here we can see that class CDS is the most closest common ground. Is CDS best candidate to intercept the native method ? |
|
This is a good point, we've seen |
|
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.spring.io/spring-framework/reference/integration/cds.html above resources might help us to understand the CDS ? |
|
Thanks, these are good starting points for an overview of CDS. In our case, we also need to get information on the internal implementation. Luckily, we do not have to implement CDS itself, as long as we ensure that we achieve the same program state by loading an initializing classes as usual even when CDS is enabled. |
|
I have made a try to understand the I have noticed something while reading articles[links of those articles are mentioned in previous comment] with the method |
|
Your were right, we should create an empty stub. And far as for |
|
@cyrille-artho |
|
Try creating an empty stub for the missing native methods in |
|
Few doubts :
|
|
|
Please take a look 
As we only have to create stub so we have avoided mangling of names, because we do not have to interact with MJI. But running |
|
Try building from the command line with Gradle; if that fails, please copy the (text of) build failure message. |
|
After building from command line And one of the failed report (file:///Users/ekla/GSOC/JPFjava17/jpf-core/build/reports/tests/test/index.html) |
|
If the static initializer is not found, this means the class is not in the right place. I can't really see from your screenshot where you placed the file |
|
|
Thanks. I see that method |
We are using above error as an example to see the problem. What is happening behind the scenes :
Screenshot in context of our example error.
otherwise `isDumpingClassList0` is not being called. (`isDumpingClassList0` is a native method which is used to get the indication value from JVM at runtime).
So from here we can go with on stub of ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Approach to add stub for |
|
Ah, I see now what you mean. I agree that the model class is not loaded/used, but I can't see why. Let's take a look at this when we have our meeting. |
|
It also helps a lot if you make a branch with your work in progress (in your forked repository) and share it with us. This way, we can inspect various things ourselves, which can help us confirm or rule out possible causes. |
|
https://github.com/eklaDFF/jpf-core/tree/CDSstub What I did : |
|
Thanks, I was able to run the tests on this branch. I get 16 test failures. Which one are you referring to above? The few that I looked at have |
|
Do not know why but still it showing 38 failures on CDSstub branch. 
What is the reason ? /////////////////////////////////////////////////////////////////////////////////////////////// Standard output stack trace of |
|
PR #451 |
|
Thanks. As the next part, |
|
Here is the implementation for But we still have 16 failed cases. But this time different reason. Attaching below as one of the example from 16 failed tests Class gov.nasa.jpf.test.java.concurrent.ConcurrentSkipListMapTest
1tests1failures0ignored0.376sduration | 1tests | 1failures | 0ignored | 0.376sduration | 0%successful
-- | -- | -- | -- | -- | --
1tests | 1failures | 0ignored | 0.376sduration
running jpf with args: JavaPathfinder core system v8.0 (rev 629fbba1ca49064391347ba1e831825985d5d871) - (C) 2005-2014 United States Government. All rights reserved. all > gov.nasa.jpf.test.java.concurrent > ConcurrentSkipListMapTest 1 tests 1 0 0.376s 0% Failed tests ====================================================== system under test ====================================================== search started: 19/05/24, 1:07 am ====================================================== error 1 ====================================================== snapshot #1 ====================================================== results ====================================================== search finished: 19/05/24, 1:07 am |
|
The above particular problem can be solved if implement the Trace : at 
( |
|
Implementing I recommend looking at other issues first. |
|
One of the other failed tests were due to So before committing it, should I create PR for |
|
Yes, please create a PR for the work on |
|
PR #452 |
|
|
|
FYI, on my local machine, I get one unit test failure less. Not sure why.
The CI build on GitHub is what really matters, though.
…On Fri, May 24, 2024 at 1:37 PM Rahul Kumar ***@***.***> wrote:
String.repeat() PR #453
<#453>
—
Reply to this email directly, view it on GitHub
<#450 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXV4R4IURE5P2X4N4NBSOTZD4Q7NAVCNFSM6AAAAABHF5W5X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRZGMYTENBYGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Regards,
Cyrille Artho
|
|
Next error we got was then we got new error and that is :
As our JPF intercepts the native methods, how will we will have to implement these ? ////////////////////////////////////////////////////////////////////// |
|
JPF loads its own copy of the classes and has its own view of information on whether a method is primitive, where a field is an array, etc. For this, you will interface with JPF internals, but not with the equivalent functions of the host JVM. This is because JPF already has data structures in its own VM where all the metadata of the code is accessible. |
|
For the fix in |
|
#454 PR for |
|
Now, please let me know about the next step as it is now more complex to me. You said earlier that JPF deals its own way for information about primitive, non primitive or interface. |
|
Please look at |
|
For our I have just implemented the 
IMPORTANT : //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// All the errors related to descriptorString() method have been solved. |
|
Looks good! Please make a PR so I can take a look at the code. |
|
PR #455 |
Hi @cyrille-artho ,
While running ./gradle test, we have 38/1002 failed cases.
Below is one of the major error.
The text was updated successfully, but these errors were encountered: