Review request 6981484: Update development launcher

Fri Sep 24 12:27:55 PDT 2010

Thanks for the pointers. For the development launcher, things are much simpler since there is only one JVM it can and will launch (the one in the same directory as the launcher). This removes all need for execv(). 

To set up the correct LD_LIBRARY_PATH, I use a script in front of the well-known gamma launcher. This script sets up LD_LIBRARY_PATH, as well as launching the process in a debugger if requested. When launching in a debugger the script sets a breakpoint in a well-known method in the launcher after libraries have been loaded. Thus when you get to the prompt in the debugger libraries are loaded and you can set breakpoints as you'd like. This also makes it easy to set all command line options before launching the debugger. To launch in gdb would look something like:

> fusion -gdb -cp my/path/here -XX:+SomeFlagHere MyProgram

It also turns out that we can't use the jdk7 launcher since it has been rewritten and cannot launch jdk6 anymore. 

Regards,
/Staffan

On 24 sep 2010, at 18.47, Volker Simonis wrote:

> .. and I forgot to attach the following maybe usefull links to Joe
> Darcy's blogs about the problems and recent reengineering of the
> default Java launcher:
> 
> What is the launcher? at http://blogs.sun.com/darcy/entry/what_is_the_launcher
> Purging LD_LIBRARY_PATH at
> http://blogs.sun.com/darcy/entry/purging_ld_library_path
> 
> Regards,
> Volker
> 
> On Thu, Sep 23, 2010 at 5:13 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>> 
>> I think the main problem is not that we have two (in fact four)
>> launchers, but that they are located in two workspaces.
>> 
>> The main reason why I use 'gamma' is because I usually only build the
>> 'hotspot' project and not 'jdk' which contains the standard 'java'
>> launcher.
>> 
>> Another reason for using 'gamma' is that it doesn't do a 'execv()'
>> system call to run with a new LD_LIBRARY_PATH like this is done by
>> 'java' launcher. This  'execv()' usually confuses debuggers. In order
>> to avoid it, one has to set the right LD_LIBRARY_PATH (i.e. the one
>> that would be build by the launcher anyway) before calling 'java'.
>> This all is kind of "how to debug the HotSpot" wizard knowledge spread
>> over various blogs and email threads.
>> 
>> I don't really see a problem in the fact that libjvm.so doesn't get
>> loaded when the launcher is started. Just do a first run with:
>> 
>> (gdb) run -version
>> 
>> which loads all the necessary dynamic objects. Then it's easily
>> possible to set breakpoints wherever you want. (And double checking
>> that you debug the right version of libjvm.so is never a fault:)
>> 
>> To cut a long story short:
>> - I don't think that its possible to keep two launchers in sync if
>> they are in different workspaces ('hotspot' and 'jdk') nor do I think
>> that it's possible to factor out some common code between the two
>> workspaces.
>> - We should have a launcher in Hotspot which is as simple as possible
>> and not dependant on the one from 'jdk' anymore. Therefore it doesn't
>> really matter where we start from (taking the one from jdk7 would be a
>> natural choice though)
>> - as much as possible common code of the new HotSpot launcher ('gamma'
>> or 'fusion' or whatever..)should be factored out into the shared code
>> space (/share/vm/tools/..).
>> - the main design goal of the new launcher should be easy
>> 'debuggability' (i.e. no execv()) and an easy possibility to chose a
>> runtime JDK to run with (from command line or from the environment).
>> 
>> Regards,
>> Volker
>> 
>> On Wed, Sep 22, 2010 at 9:46 PM, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I think we should use the jdk7 version that you have in the windows build
>>> for all platforms.  Many/most of the launcher jdk7 changes seem to be
>>> introducing the JLI layer and fixing some bugs.    The platform dependent
>>> java_md.{ch} can be in os/<os>/launcher, and the java.c (which is the most
>>> code) in share/vm/tools/launcher - there isn't really risk to changing the
>>> solaris and linux versions since most people don't use them except for
>>> debugging.  The only change that people would notice is if the libjvm.so is
>>> no longer statically linked in, because this is the primary benefit:
>>> 
>>> dbx gamma
>>> stop in <some vm function>  # no complaints from the debugger because
>>> libjvm.so is loaded already
>>> run
>>> <stop at break>    # except this doesn't seem to work on linux now anyway
>>> 
>>> I can forsee using the launcher for development testing so having the latest
>>> jdk7 version makes a lot of sense, and having them consistent by platforms
>>> would be good going forward.   I hope this isn't a ton of work to do though.
>>> 
>>> thanks,
>>> Coleen
>>> 
>>> On 09/22/10 14:59, Staffan Larsen wrote:
>>> 
>>> Thanks for the review, Coleen.
>>> 
>>> Yes, the files are almost identical and we should really have just one set.
>>> There were two main reasons why I duplicated the code, and neither of them
>>> is very good:
>>> 
>>> 1) The code in /os/(linux|solaris)/launcher/* is based on the launcher in
>>> 1.6.0-b28 (at least the comment in java.c says so). I couldn't easily find
>>> that source code to grab the windows files from, so I got them from some
>>> other build (6.0u22-b01). There was enough difference between these to make
>>> the platform independent and platform dependent files incompatible.
>>> 2) I didn't want to make more changes than I had to, so I didn't want to
>>> touch the linux or solaris launchers.
>>> 
>>> Perhaps there is even a third reason: There was already a precedent of
>>> having the linux and solaris code duplicated, so I just did the same thing
>>> for windows. Seems we would really benefit from a "posix" branch with common
>>> linux and solaris code in - in fact, the platform dependent parts of the
>>> launcher are the same for linux and solaris.
>>> 
>>> In retrospect, none of these reasons are good enough, and we should use the
>>> same code as much as possible. Any thoughts on what version on the launcher
>>> I should use as baseline? The latest one from jdk7? A stable one from jdk6?
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>> On 22 sep 2010, at 16.20, Coleen Phillimore wrote:
>>> 
>>> 
>>> 
>>> Hi Staffan,
>>> Is this file src/os/windows/launcher/java.c
>>> the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c
>>> In fact, the sources in os/linux/launcher are almost exactly the same as
>>> os/solaris/launcher.
>>> Can we have just one set?  Perhaps put it in directory
>>> src/share/tools/launcher and make the makefiles use these sources instead?
>>> Sorry to make more work but having the same 2000 lines of code somewhere
>>> else, guarantees one copy will always be wrong.
>>> 
>>> Thanks,
>>> Coleen
>>> 
>>> On 09/22/10 08:38, Staffan Larsen wrote:
>>> 
>>> 
>>> Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/
>>> 
>>> 
>>> Eventually, I'll get there...
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger
>>> Sent: den 22 september 2010 2:38
>>> To: Staffan Larsen
>>> Cc:
>>> hotspot-dev at openjdk.java.net
>>> 
>>> Subject: RE: Review request 6981484: Update development launcher
>>> 
>>> On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote:
>>> 
>>> 
>>> 
>>> 
>>> Thanks Christian - I obviously have some things to learn as a new
>>> committer - didn't think about the copyrights :-)
>>> 
>>> 
>>> 
>>> 
>>> Sure.  I was going the same route :-)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> http://cr.openjdk.java.net/~sla/6981484/webrev.02/
>>> 
>>> 
>>> Now with updated copyrights.
>>> 
>>> 
>>> 
>>> 
>>> As David already said.
>>> 
>>> -- Christian
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 