Re: [PATCH V2] oprofile-tests Add test to exercise libjvmti_oprofile.so

On 2019-11-07 14:53, William Cohen wrote:
> On 10/15/19 2:21 PM, will schmidt wrote:
>> Hi,
>> 
>> For V2 of this patch, I have updated the logic that looks for
>> libjvmti_oprofile.so to also search /usr/lib64/ and /usr/lib/
>> for the library, stopping when the library is found.  I have
>> tested a few additional variations locally.
>> 
>> (V1:)
>> Assorted changes to exercise the use of oprofiles JVMTI hook.
>> (libjvmti_oprofile.so  - Java Virtual Machine Tools Interface).
>> 
>> This has been tested this on assorted ppc64* systems with a mixture
>> of having the libjvmti_oprofile present and not.
>> 
>>     testsuite/lib/op_util.exp:
>>     * Update compile_workload() procedure to allow building of .java 
>> files.
>>     * Add procedure op_resolve_java_dependencies() to ensure that 
>> dependencies
>>       for building and running the java test can be found. This 
>> includes java,
>>       javac, and libjvmti_oprofile.so. Since the libjvmti_oprofile.so 
>> object
>>       can't be readily found via 'which', logic is in place that 
>> assumes it can
>>       be found in a path relative to where the operf binary is found.
>> 
>>     testsuite/lib/op_workloads.exp:
>>     * Add an op_java_workload_table containing the new test.
>> 
>>     testsuite/lib/operf_util.exp:
>>     * Add procedure (check_java_samples_exist) to see that samples can 
>> be
>>       found that are associated with the generated .jo object.
>>     * Add procedure (check_java_object_file_exists) to ensure that at
>>       least one "*.jo" file was created during the run.
>>     * Add procedure (do_java_test) to do the actual test.
>> 
>>     testsuite/workloads/java/Fibonacci.java:
>>     * Add the java test itself.
>> 
>> --
>> 
>> Thanks,
>> -Will (Schmidt)
>> 
>> 
>> diff --git a/testsuite/lib/op_util.exp b/testsuite/lib/op_util.exp
>> index 7f0473d..863d46f 100644
>> --- a/testsuite/lib/op_util.exp
>> +++ b/testsuite/lib/op_util.exp
>> @@ -179,15 +179,15 @@ proc check_user {} {
>>  proc compile_workload {workload_src compile_options } {
>> 
>>      # Ideally the TCL command target_compile should be used.  
>> However,
>>      # target_compile is ignoring the compiler options argument.
>> 
>> -    set compiler "cc"
>>      set extension [lindex [split $workload_src "."] 1]
>> -    set workload_exc [ lindex [split $workload_src "."] 0]_bin
>> 
>>      if { [string compare $extension "c"] == 0 } {
>> +	set workload_exc [ lindex [split $workload_src "."] 0]_bin
>> +	set compiler "cc"
>>  	# workload is a C program, see if it needs to be compiled.
>>  	set test [local_exec "ls $workload_exc" "" "" 10]
>> 
>>  	if { [lindex $test 0] == 1 } {
>>  	    # workload has not been compiled
>> @@ -198,10 +198,28 @@ proc compile_workload {workload_src 
>> compile_options } {
>>  	    }
>>  	}
>>  	return [ lindex [split $workload_src "."] 0]_bin
>>      }
>> 
>> +    if { [string compare $extension "java"] == 0 } {
>> +	set compiler "javac"
>> +	set workload_exc [ lindex [split $workload_src "."] 0].class
>> +	# workload is a java program, see if it needs to be compiled.
>> +	set test [local_exec "ls $workload_exc" "" "" 10]
>> +	if { [lindex $test 0] == 1 } {
>> +	    # workload has not been compiled
>> +	    set result [local_exec "$compiler $workload_src 
>> $compile_options" "" "" 10 ]
>> +	    if { [lindex $result 0] == 1 } {
>> +		print "\nERROR compiling workload: $workload_src"
>> +		print "Compiler error message: $result\n"
>> +	    }
>> +	}
>> +	set path_and_basename [lindex [split $workload_src "."] 0]
>> +	set classonly [ lindex [ split $path_and_basename "/"] 2]
>> +	return $classonly
>> +    }
>> +
>>      # Assume the workload is a script, set the executable
>>      # name to the same as the source name.
>>      return $workload_src
>>  }
>> 
>> @@ -243,5 +261,67 @@ proc op_check_dependencies {} {
>>          set op_deps_ok 0
>>      } else {
>>          set op_deps_ok 1
>>      }
>>  }
>> +
>> +proc op_resolve_java_dependencies {} {
>> +    global java_deps_ok
>> +    global path_to_libjvmti
>> +    set libjvmti_oprofile_present 0
>> +    set java_present 0
>> +    set javac_present 0
>> +    set operf_present 0
>> +
>> +    set path_to_operf [ local_exec "which operf" "" "" 100 ]
>> +    if {[regexp "operf" $path_to_operf operf_present] == 1} {
>> +	verbose "Found operf ($operf_present) at $path_to_operf ."
>> +    } else {
>> +	send "Didn't find operf.\n"
>> +    }
>> +
>> +    set path_to_javac [ local_exec "which javac" "" "" 100 ]
>> +    if {[regexp "javac" $path_to_javac javac_present] == 1} {
>> +	verbose "Found javac ($javac_present) at $path_to_javac ."
>> +    } else {
>> +	send "javac is require to build the java testcase.  I didn't find 
>> javac via 'which'.\n"
>> +    }
>> +
>> +    set path_to_java [ local_exec "which java" "" "" 100 ]
>> +    if {[regexp "java" $path_to_java java_present] == 1} {
>> +	verbose "Found java ($java_present) at $path_to_java ."
>> +    } else {
>> +	send "java is require to run the java testcase.  I didn't find java 
>> via 'which'.\n"
>> +    }
>> +
>> +    # Finding libjvmti_oprofile.so.
>> +    # In the case of a userspace build, the oprofile install location 
>> has
>> +    # sibling /bin/ and /lib/ directories, so as long as we have 
>> found the
>> +    # operf binary, we should be able to infer the location of 
>> libjvmti_oprofile.so.
>> +    set path_to_libjvmti [string map {bin/operf 
>> lib/oprofile/libjvmti_oprofile.so} $path_to_operf ]
>> +    set path_to_libjvmti [string trimleft $path_to_libjvmti "0\ \{"]
>> +    set path_to_libjvmti [string trim $path_to_libjvmti "\ \n\r\}"]
>> +    set libjvmti_oprofile_present [file exists $path_to_libjvmti ]
>> +    if {$libjvmti_oprofile_present == 1 } {
>> +	send "found libjvmti_oprofile ($libjvmti_oprofile_present) at 
>> $path_to_libjvmti . \n"
>> +    } else {
>> +	send "did not find libjvmti_oprofile in $path_to_libjvmti ) .\n"
>> +	# search a few other common spots for the library.
>> +	foreach path_to_libjvmti  { /usr/lib64/libjvmti_oprofile.so 
>> /usr/lib/libjvmti_oprofile.so } {
> 
> Hi,
> 
> There are some other places that libjvmti_oprofile.so might end up.  
> For rhel7:
> 
> /usr/lib64/oprofile/libjvmti_oprofile.so
> 
> For Red Hat developer tool 9 and 8:
> 
> /opt/rh/devtoolset-9/root/usr/lib64/libjvmti_oprofile.so
> /opt/rh/devtoolset-8/root/usr/lib64/libjvmti_oprofile.so
> 
> For locally built oprofile default installs ended up with:
> 
> /usr/local/lib/oprofile/lib/libjvmti_oprofile.so
> 
> It might be better to determine which operf is being used and use the
> beginning of its path to find the associated jvmti.so

Right.. earlier versions of this found some false positives in the 
environments I have, which is why the first spot I check was/is relative 
to wherever i found 'operf'.    Looks like I only look for a 'lib' 
sibling, so adding a lib64 sibling will probably resolve the others you 
have listed. .. as long as the operf binary is in a relative path to the 
libs.

> /usr/lib64/oprofile/libjvmti_oprofile.so

So, operf for this one is at .. /usr/bin/operf ?

> /opt/rh/devtoolset-9/root/usr/lib64/libjvmti_oprofile.so
> /opt/rh/devtoolset-8/root/usr/lib64/libjvmti_oprofile.so

operf for these in /opt/rh/devtoolset-{7,8}/root/usr/bin/operf ?

> /usr/local/lib/oprofile/lib/libjvmti_oprofile.so

with operf at /usr/local/lib/oprofile/bin/operf  ?


Thanks
-Will (Schmidt)

> 
> -Will Cohen