Graal and Hotspot

Gilles Duboscq gilwooden at gmail.com
Wed Feb 13 12:45:53 PST 2013


Hi Gulfem,

You can pass arguments in a similar fashion in Graal.
For example:
"mx vm -G:GraphCacheSize=2000 -XX:CompileCommand=print,Object::toString"

Boolean options are specified using "-G:+EnabledOption" and
"-G:-DisabledOption"

Graal defines a number of "-G:" options, you can see them
in com.oracle.graal.phases.GraalOptions.
The Graal VM also adds a few options to HotSpot (see graalGlobals.hpp).
These are "-XX:" flags. For example -XX:-BootstrapGraal

Every argument you pass after "mx vm" is directly forwarded to the vm.
A useful option of the mx script is -v, in verbose more, mx will print the
command line it uses to start the vm.
For example:
›mx -v vm -version
/home/gd/Development/Graal/graalvm/jdk1.7.0_11/product/bin/java -graal -d64
-version
...

- Gilles



On Wed, Feb 13, 2013 at 9:33 PM, Gulfem Savrun Yeniceri <
gulfemsavrun at gmail.com> wrote:

> Hi Gilles,
>
> Since you are giving some info about how to use mx script, I was wondering
> how can we specify GraalOptions thorough the mx script.
> For ex, we specify options in Maxine as "mx vm -C1X:+PrintAssembly class".
> How can we do this in Graal?
>
> Gulfem
>
> On Feb 13, 2013, at 9:32 AM, Gilles Duboscq <gilwooden at gmail.com> wrote:
>
> > -server0 is a copy of the original JDK's vm and it doesn't work because
> the
> > mx script currently refuses this value (mx --vm server0 vm will
> complain) i
> > will fix that.
> > -server in the server vm built from our source tree. Whether is contains
> > the Graal compiler (configuration 2) or not (configuration 3) depends on
> > whether you didn't or did (respectively) define OMIT_GRAAL while
> building.
> > -graal is the Graal VM (configuration 1)
> >
> > please not that "mx vm" already appends the vm argument, nothing good
> will
> > come out of "mx vm -graal" or "mx vm -server" etc.
> > Use "mx vm" (this is equivalant to "mx --vm graal vm") "mx --vm server
> vm"
> > or "mx --vm server0 vm"
> >
> >
> > On Wed, Feb 13, 2013 at 5:55 PM, Venkatachalam, Vasanth <
> > Vasanth.Venkatachalam at amd.com> wrote:
> >
> >> Thanks for the clarification. I had a follow-up question.****
> >>
> >> ** **
> >>
> >> When I do an mx vm –help (after doing mx build) I get the below
> options.**
> >> **
> >>
> >> ** **
> >>
> >> I’m trying to understand the difference between the –server0, -server
> and
> >> –graal options. ****
> >>
> >> Do these map to the three configurations mentioned below in Doug’s
> >> response?****
> >>
> >> ** **
> >>
> >> Usage: java [-options] class [args...]
> >>           (to execute a class)
> >> where options include:
> >>    -server0      to select the "server0" VM
> >>    -server      to select the "server" VM
> >>    -graal      to select the "graal" VM
> >>                  The default VM is server0,
> >>                  because you are running on a server-class machine.****
> >>
> >> ** **
> >>
> >> ** **
> >>
> >> *From:* Gilles Duboscq [mailto:gilwooden at gmail.com]
> >> *Sent:* Wednesday, February 13, 2013 3:39 AM
> >> *To:* Doug Simon @ Oracle
> >> *Cc:* Venkatachalam, Vasanth; graal-dev at openjdk.java.net
> >> *Subject:* Re: Graal and Hotspot****
> >>
> >> ** **
> >>
> >> Where configuration 1 defines both GRAAL and GRAALVM, configuration 2 to
> >> defines only GRAAL and configuration 3 defines none.****
> >>
> >> ** **
> >>
> >> On Wed, Feb 13, 2013 at 12:57 AM, Doug Simon @ Oracle <
> >> doug.simon at oracle.com> wrote:****
> >>
> >>
> >>
> >> The VM can be built in a number configurations:
> >>
> >> 1. To exclusively use Graal for servicing compilation requests (e.g.,
> upon
> >> counter overflow for hot methods in the interpreter). In this
> >> configuration, c1 and c2 are completely omitted from the VM binary. This
> >> configuration is built with the 'mx build' command and is run with the
> 'mx
> >> vm <VM options> class <args>' command.
> >> 2. To have the Graal extension points in the binary available so that
> >> Graal can be used for explicit compilation and code installation.  In
> this
> >> configuration, c1 and c2 are present and are used for VM requested
> >> compilations. That is, the VM is almost like a stock HotSpot build
> except
> >> that the Graal compiler can be used from Java code. For example, look at
> >> com.oracle.graal.compiler.test.CompiledMethodTest. This configuration is
> >> built with the 'mx --vm server build' command and is run with the 'mx
> --vm
> >> server vm <VM options> class <args>' command.
> >> 3. A stock HotSpot build with none of the Graal code included. This
> >> configuration is built with the 'env OMIT_GRAAL= mx --vm server build'
> >> command and is run with the 'mx --server vm <VM options> class <args>'
> >> command. This cannot coexist with config 2 and so you need to issue a
> 'mx
> >> clean --no-java' command when switching between config 2 and 3.
> >>
> >> For the most part, we have guarded all Graal modifications to the VM
> with
> >> '#ifdef GRAAL' or '#ifdef GRAALVM'.
> >>
> >> -Doug****
> >>
> >>
> >> On Feb 13, 2013, at 7:49 AM, "Venkatachalam, Vasanth" <
> >> Vasanth.Venkatachalam at amd.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> The Graal webpage says that the Graal VM is a modified version of
> >> Hotspot that uses Graal as the compiler instead of C1 or C2.
> >>>
> >>> Can someone explain at a high-level which components of Hotspot are
> >> intact and which ones have been modified?
> >>> I see a number of API routines relating to hotspot
> >> (com.oracle.graal.hotspot.server).
> >>>
> >>> Vasanth
> >>>
> >>>
> >>>
> >>> ****
> >>
> >> ** **
> >>
>
>


More information about the graal-dev mailing list