WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> Hi Mikael,
> On 30/11/2011 2:04 AM, Mikael Gerdin wrote:
>> I've been working on a white box testing API for HotSpot in order to
>> allow for improved precision in vm testing.
>> The basic idea is to open up the possibility for tests written in Java
>> to call native methods which query or poke the vm in some way.
>> The API is accessible by using the class sun/hotspot/WhiteBox which is
>> not intended to be available in public builds.
> Where "public" means non-developer builds - right?
> But what if someone simply puts wb.jar in their classpath?
It won't work. They need to put it in the boot class path in order to
get it to work. Additinally they'll need to add
"-XX:+UnlockDiagnosticVMOptions -XX:+EnableWhiteboxAPI" to their command
But yes, it is not impossible to use from a "non-developer" build.
>> In order to allow the WhiteBox class access to the VM the
>> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. That
>> function then links all the implementation functions using normal JNI
>> The API is not meant to be used by end users for any intent or purpose
>> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions
>> -XX:+EnableWhiteboxAPI" and the fact that the class files will not be
>> present in an end user build of a JDK.
> I'm a little confused as to where wb.jar ends up when I build hotspot. I
> see this in a makefile:
There are a couple of issues in these make files.
> 26 WB = wb
> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src
> 30 WB_JAR = $(GENERATED)/$(WB).jar
> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR)
> Why JAVA_HOME? That's normally a binary installation of a JDK used for
> building, not somewhere I expect my build to try and put something. Plus
> the above will expand to:
For example, look in jsig.make. It has a target that copies libjsig to
JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to
JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior
with the "install"-targets in the make files.
> which doesn't seem right either.
Agreed, that's incorrect.
> And if I build a full JDK, where does wb.jar end up then?
Because of security requirements and implementation details the Whitebox
class must be available on the boot class path.
Putting the wb.jar file in the endorsed directory is a quick and easy
way to achieve that.
Does this clarify your concerns?
>> If the VM crashes after this API has been accessed a note will be
>> written in the hs_err file to signal that the API has been used.
>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >> (thanks to stefank for hosting my webrev :)
>> I'll file a CR tomorrow.
>> Change comments:
>> Add a test target to make sure that the API is available on all
>> supported platforms
>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a
>> JAR file and copy it to the jre/lib/endorsed directory in the export
>> The BSD makefile changes are not tested since I don't have access to any
>> BSD/OSX machine to test them on.
>> Special-case the method sun/hotspot/WhiteBox/registerNatives and link it
>> to JVM_RegisterWhiteBoxMethods
>> The implementation of the white box API. The actual API functions are
>> only examples of what we want to be able to do using the API.
>> Add the command line flag
>> Print a message in hs_err files when white box API has been used.
>> Add a makefile test target for the white box API test
>> JTreg test to ensure that the API works.
>> /Mikael Gerdin