[12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present
Liu Xin
navy.xliu at gmail.com
Fri Aug 10 18:35:31 UTC 2018
thank you. I got it.
I will take a closer look at project Metropolis and substratevm
<https://github.com/oracle/graal/tree/master/substratevm>.
thanks,
--lx
On Fri, Aug 10, 2018 at 10:58 AM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:
> Yes, you can do that to avoid missing C1 issue with Graal. But it is "too
> complicated" for end user ;)
> User have to generate these libraries himself. On other hand we are
> planning to ship libgraal.so with JDK.
>
> And with this you solve only startup problem. Even that is questionable
> based on our experiments. If AOT library is big
> (like when you compile whole module), its load time and symbols resolution
> offsets benefit of pre-compilation.
>
> Also produced like that AOT code is just extension from existing code in
> CodeCache. It still shares Java heap with
> application during compilation and have other side effects. It could be
> deoptimized as you noticed and go into
> Interpreter polluting profiling again. It happens because we make very
> conservative assumptions during AOT compilation.
>
> Yes, there are different ways to solve GRaal's issues and we decided to go
> with libgraal.so as we think it will solve
> most of these issues.
>
> Regards,
> Vladimir
>
> On 8/10/18 9:22 AM, Liu Xin wrote:
> > Vladimir,
> >
> > I am quite new area. Why Graal needs its own GC and small runtime?
> Theoretically, jaotc compiles some Java classes. It doesn’t need to know
> that those classes are themselves.
> > My original thought is straight-forward. Compile Graal classes using
> JOT, load them to avoid from warming-up.
> >
> > I compiled both modules:
> > ./jdk/bin/jaotc --module jdk.internal.vm.ci --output
> libHotspotCI.dylib
> > ./jdk/bin/jaotc --module jdk.internal.vm.compiler --output
> libHotspotCompiler.dylib
> >
> > And I loaded them to run.
> > ./jdk/bin/java -XX:+PrintCompilation \
> > -XX:+UnlockExperimentalVMOptions \
> > -XX:+EnableJVMCI \
> > -XX:+UseJVMCICompiler
> -XX:AOTLibrary=./libHotspotCI.dylib:./libHotSpotCompiler.dylib -cp . Demo
> |& tee jvmci_with_aot_graal.output
> >
> > Does it work? I took a look the output of PrintCompilation.
> > I found many methods are marked 'made not entrant’. It means that
> hotspot deoptimize them right?
> >
> >
> >> On Aug 9, 2018, at 11:26 AM, Vladimir Kozlov <
> vladimir.kozlov at oracle.com> wrote:
> >>
> >>
> >> My main motivation is that it is not supported configuration for us.
> And if you don't use Graal you waste space with Graal module.
> >
>
More information about the hotspot-dev
mailing list