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

[Bengt Rutisson]

Hi all,

I know I'm a bit late in the game here, 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.

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.

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
>>>>>>
>>>
>>
>