Accepting jdwp connection early enough to debug Graal startup with -Xcomp

Gary Frost frost.gary at gmail.com
Wed Aug 28 13:50:41 UTC 2019


Thanks Doug.

Very intresting.


On Wed, Aug 28, 2019 at 2:48 PM Doug Simon <doug.simon at oracle.com> wrote:

>
>
> On 28 Aug 2019, at 15:37, Gary Frost <frost.gary at gmail.com> wrote:
>
> Thanks Alan and Doug for the feedback
>
> Sounds like libgraal is intended to be a precompiled (AOT?) binary library
> formed by  'closing' over the Graal module?
>
>
> Yes, that’s exactly what libgraal is. You can find more detail in this
> article:
>
>
> https://medium.com/graalvm/libgraal-graalvm-compiler-as-a-precompiled-graalvm-native-image-26e354bee5c
>
> If so will it still allow Java plugins to be dynamically loaded?
>
>
> The plugins will have to be part of the environment (i.e. class path) when
> building a libgraal image. Otherwise, Graal plugins will only work in
> jargraal mode.
>
>  In my case I can work around (removing -Xcomp helps a lot)
>
> Just trying to get my head around the debug story for people writing
> plugins.
>
>
> I hope the above info helps.
>
> -Doug
>
>
> Gary
>
>
>
>
>
> On Wed, Aug 28, 2019 at 2:08 PM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 28/08/2019 13:35, Doug Simon wrote:
>> > Alan,
>> >
>> > Thanks a lot for the input.
>> >
>> > My only further comment is that with libgraal, the whole JDWP question
>> is irrelevant as Graal will not be running as Java code (from HotSpot’s
>> perspective).
>> >
>> Sure but my point is that it might be possible to queue compilations
>> earlier in the startup when the compiler is precompiled. That is, I
>> thought Gary's mail was about debugging the compiler which I assume will
>> need a solution when compiled to libgraal.
>>
>> -Alan
>>
>
>


More information about the graal-dev mailing list