RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk

Rickard Bäckman rickard.backman at oracle.com
Wed Feb 8 06:29:52 PST 2012


On 02/08/2012 03:21 PM, Christian Thalinger wrote:
>
> On Feb 8, 2012, at 3:15 PM, Rickard Bäckman wrote:
>
>> Christian,
>>
>> is the duplication of lines 452-453 on 455-456 intendend? (make/Makefile)
>>
>> 450     ifeq ($(ARCH_DATA_MODEL), 32)
>> 451       ifneq ($(ZERO_BUILD), true)
>> 452         $(JDK_IMAGE_DIR)/bin/java -d32 -client -Xinternalversion
>> 453         $(JDK_IMAGE_DIR)/bin/java -d32 -client -version
>> 454       endif
>> 455         $(JDK_IMAGE_DIR)/bin/java -d32 -server -Xinternalversion
>> 456         $(JDK_IMAGE_DIR)/bin/java -d32 -server -version
>> 457     endif
>>
>> Seems like the commands will run twice on non-zero builds?
>
> If you look closely it's testing client and server on 32-bit.  Zero never had a client VM.
>

Right! Looks good to me.

/R

> -- Chris
>
>>
>> /R
>>
>> On 02/08/2012 02:50 PM, Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/7143766/
>>>
>>> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk
>>> Reviewed-by:
>>>
>>> I'd like to add the possibility to specify JDK_IMAGE_DIR via
>>> ALT_JDK_IMAGE_DIR.  This is very helpful during development since it's
>>> possible to copy a JDK into a specified directory and export different
>>> VM builds to the same JDK.  Doing this you don't have to change any
>>> paths (or command line arguments) but use the same java command, e.g.:
>>>
>>> $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk
>>> $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk
>>>
>>> And after all your bugs are fixed do a product build, export that and
>>> use the same java command:
>>>
>>> $ make product export_product ALT_EXPORT_DIR=/foo/jdk
>>>
>>> The changes for test_jdk make sure that the right VM is tested.  This
>>> might not be the case when you are doing 64-bit builds on Solaris,
>>> export the VM and do a test_jdk:
>>>
>>> $ make test_jdk LP64=1
>>> INFO: no objcopy cmd found so cannot create .debuginfo files.
>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version
>>> java version "1.8.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24)
>>> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode)
>>>
>>> What you actually want is to run the just-built 64-bit VM, like:
>>>
>>> $ make test_jdk LP64=1
>>> INFO: no objcopy cmd found so cannot create .debuginfo files.
>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion
>>> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb  8 2012 04:26:02 by "ct232829" with Sun Studio 12u1
>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version
>>> java version "1.8.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24)
>>> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode)
>>>
>>> I also added printing -Xinternalversion to test_jdk.  This makes it
>>> easier to verify the installed VM is the one you just built (and want
>>> to test).
>>>
>>> make/Makefile
>>> make/bsd/makefiles/defs.make
>>> make/defs.make
>>>
>>
>



More information about the hotspot-dev mailing list