Review Board 2.0.15


gem5ops: Implement Java JNI for gem5Ops

Review Request #831 - Created Aug. 19, 2011 and submitted

Information
Ali Saidi
gem5
Reviewers
Default
ali, gblack, nate, stever 
gem5ops: Implement Java JNI for gem5Ops

These ops allow gem5 ops to be called from within java programs like the following:
import jni.gem5Op;

public  class HelloWorld {

    public static void main(String[] args) {
        gem5Op gem5 = new gem5Op();
        System.out.println("Rpns0:" + gem5.rpns());
        System.out.println("Rpns1:" + gem5.rpns());
    }

    static {
        System.loadLibrary("gem5OpJni");
    }
}

When building you need to make sure classpath include gem5OpJni.jar:
javac -classpath $CLASSPATH:/path/to/gem5OpJni.jar HelloWorld.java

and when running you need to make sure both the java and library path are set:
java -classpath $CLASSPATH:/path/to/gem5OpJni.jar -Djava.library.path=/path/to/libgem5OpJni.so HelloWorld


   

  


 


 

  

  









  
 


  

 


















 

  


 


  



   

   
Gabe Black

   
Posted  (Aug. 19, 2011, 11:27 a.m.)


  


  


  

   
It looks like it, but if I don't want to (or can't) build the java parts, that's not pulled in automatically, right? If somebody needs the C parts but doesn't have java set up, we want the C parts to still work. I think you have this covered, but it seemed like a good idea to double check.



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    yea, no problems if you make it without JDK_PATH set and don't try to make gem5OpJni.jar or libgem5OpJni.so (which aren't made by default)
    
    
    
   
    2. 

   


  





  

 


  

 

















 



 

  


 


  



   

   
Steve Reinhardt

   
Posted  (Sept. 12, 2011, 2:19 a.m.)


  


  


  

   
I assume these are ISA-independent, right?  If so, it would be nice to have Makefile support not isolated to ARM.  Ideally it would be nice to have a common makefile structure with only the parts that differ factored out, in which case this request would be trivial.

I don't mean to snowball this simple change into a requirement to rearchitect the whole makefile structure here, just pointing out that it's the Right Thing To Do.  If you want to commit this as it, I won't protest, I'll just be disappointed ;-)



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I also should mention that the nice little example you have in the commit message really belongs as a comment in the code, not in the commit message... we need to keep in mind that users are not going to search the hg log for documentation (nor should they be expected to)
    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    I moved the example into the wiki.

As for the Makefile, I think Gabe had some changes to use scons to build them. 
    
    
    
   
    3. 


   
  3. 
    
    
     
    
      
     
    
     
    Nope, although I could do that if that's useful. I think you're thinking of statetrace.
    
    
    
   
    4. 


   
  4. 
    
    
     
    
      
     
    
     
    I'll take a look at the makefile differences
    
    
    
   
    5.