RFR (S): 8006965: test_gamma should run with import JDK

Tue Feb 26 05:07:37 PST 2013

This thread is getting really long.   Associated with this change, can 
someone update a wiki page somewhere with all this information.  IE.   
How to run a test at the end of building so we don't install a broken 
libjvm.so into a jdk and how to set breakpoints in the platforms that we 
debug?    I think these are the two main requirements here.

Thanks!
Coleen

On 2/26/2013 2:34 AM, Bengt Rutisson wrote:
> On 2/25/13 7:53 PM, Christian Thalinger wrote:
>> On Feb 25, 2013, at 1:07 AM, Bengt Rutisson 
>> <bengt.rutisson at oracle.com> wrote:
>>
>>> Hi all,
>>>
>>> I know I'm a bit late in the game here
>> Not too late; we're just getting started :-)
>
> Great! :)
>
>
>>> , but I get a bit worried about removing the gamma launcher. I admit 
>>> that I don't know much about the launchers or how they are built. 
>>> But if removing the gamma launcher means that I will have to start 
>>> copying libjvms around I don't think this is acceptable.
>>>
>>> Please correct me if I am miss understanding something here. I am 
>>> always using the hotspot script to execute my newly built hotspots. 
>>> It is very convenient, and I don't want to have a situation where I 
>>> have to copy the libjvm every time I want to run my builds. And I 
>>> certainly don't want to build the whole JDK every time I build.
>> The hotspot script doesn't go away; I know that a lot of people use 
>> it.  Mikael and I found a way to run the newly built libjvm without 
>> copying somewhere and without using gamma.  You shouldn't notice any 
>> difference.
>
> That's good enough for me. Thanks!
>
>
>>> Also, have you looked in to how the Visual Studio projects are 
>>> affected by this? Again I don't know the details, but debugging 
>>> support on Windows is excellent and I don't want that to get more 
>>> difficult if we remove the gamma launcher. Not sure if it is used by 
>>> the Visual Studio projects though.
>> Honestly, I never did a manual build on Windows.  If, as you say, 
>> debugging support is excellent on Windows than it certainly should be 
>> able to handle a shared libjvm library (that's what most people are 
>> concerned about: statically linked gamma vs. java launcher dlopen'ing 
>> libjvm).
>
> You are probably correct. If you want to I can try it out. Do you have 
> a patch that removes gamma? In that case I can create a VS project and 
> try some debugging. If that works and the hotspot script will keep 
> working I'm fine with removing gamma.
>
> Thanks,
> Bengt
>
>>
>> -- Chris
>>
>>> Bengt
>>>
>>> On 2/24/13 11:18 PM, Coleen Phillimore wrote:
>>>> On 2/22/2013 8:40 PM, BILL PITTORE wrote:
>>>>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote:
>>>>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote:
>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen 
>>>>>>> <staffan.larsen at oracle.com> wrote:
>>>>>>>
>>>>>>>> I'm not sure what the correct solution is, but when you do find 
>>>>>>>> out, the jdkpath.sh target should also be updated.
>>>>>>> How many are actually using the hotspot script?  Would people be 
>>>>>>> very sentimental if we would remove the gamma launcher altogether?
>>>>>>>
>>>>>>> Taking to people here it seems that most are copying their 
>>>>>>> libjvm into a JDK and use java anyway.
>>>>>> I use the hotspot script on linux to debug with -gdb, ie:
>>>>>>
>>>>>> hotspot -gdb <command line arguments>
>>>>>>
>>>>>> It works really well!  So the gamma launcher is really good for 
>>>>>> debugging without having to do odd things like ^C or 
>>>>>> PauseVMAtStartup to set breakpoints after libjvm.so is loaded. 
>>>>>> How else can you debug this?
>>>>> With recent versions of gdb I have no problem debugging using gdb 
>>>>> on the java executable
>>>>> gdb --args ./bin/java -cp . HelloWorld
>>>>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
>>>>> ...
>>>>> (gdb) break ClassVerifier::verify_method
>>>>> Make breakpoint pending on future shared library load? (y or [n]) y
>>>>>
>>>>> Breakpoint 1 (ClassVerifier::verify_method) pending.
>>>>> (gdb) run
>>>>> ...
>>>>>
>>>>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, 
>>>>> m=0xf732ab08,
>>>>>     __the_thread__=0xf7108000)
>>>>>     at 
>>>>> /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575
>>>>> 575      HandleMark hm(THREAD);
>>>>> (gdb)
>>>>>
>>>> This works on the linux 32 and 64 bit machine we're using. But it 
>>>> only works on 32 bit if DEBUG_BINARIES=true is set while building 
>>>> (this creates binaries with dwarf2 rather than stabs, apparently 
>>>> dwarf takes more disk space so the build by default creates 
>>>> binaries with stabs).
>>>>
>>>> I don't think this works on solaris and I don't know about 
>>>> windows.   Someone who debugs on windows should tell us how they 
>>>> debug without gamma.
>>>>
>>>> Coleen
>>>>
>>>>> bill
>>>>>> For testing, I copy the jvm into a jdk binary.
>>>>>>
>>>>>> Coleen
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> /Staffan
>>>>>>>>
>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger 
>>>>>>>> <christian.thalinger at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965
>>>>>>>>>
>>>>>>>>> 8006965: test_gamma should run with import JDK
>>>>>>>>> Reviewed-by:
>>>>>>>>>
>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 
>>>>>>>>> (where
>>>>>>>>> JDK n is the version we are actually compiling for). This 
>>>>>>>>> setup is
>>>>>>>>> unsupported and thus should not be done during HotSpot builds.
>>>>>>>>>
>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME 
>>>>>>>>> when
>>>>>>>>> running test_gamma.
>>>>>>>>>
>>>>>>>>> make/bsd/makefiles/buildtree.make
>>>>>>>>> make/defs.make
>>>>>>>>> make/linux/makefiles/buildtree.make
>>>>>>>>> make/solaris/makefiles/buildtree.make
>>>>>>>>>
>