From letsche at gmail.com  Fri Nov  3 20:25:17 2017
From: letsche at gmail.com (Todd Letsche)
Date: Fri, 3 Nov 2017 15:25:17 -0500
Subject: Python
Message-ID: <CAPfPP9D54=7Ht5SHBc42W4MxUspK-snSoZbVs_w+mfqLcB2u=w@mail.gmail.com>

Hi,

Perhaps this is the wrong place to ask, but maybe you can point me to
the right place.

The Python interpreter in the graalvm 0.28.2 distribution appears to
be a modified version of ZipPy.  Is the source code available, by
chance?  If not, are there plans to make it available somewhere?

Thanks,

Todd

From christian.humer at gmail.com  Fri Nov  3 20:47:22 2017
From: christian.humer at gmail.com (Christian Humer)
Date: Fri, 03 Nov 2017 20:47:22 +0000
Subject: Python
In-Reply-To: <CAPfPP9D54=7Ht5SHBc42W4MxUspK-snSoZbVs_w+mfqLcB2u=w@mail.gmail.com>
References: <CAPfPP9D54=7Ht5SHBc42W4MxUspK-snSoZbVs_w+mfqLcB2u=w@mail.gmail.com>
Message-ID: <emc69fa7e2-74b9-4c74-b42e-9fbd5b59ba12@grashalm-work>

Hi Todd,

Thank you for your interest.
The Graal Python version included in GraalVM 0.28.2 is currently under 
heavy development.
The source code is not available publicly atm, but it is likely that it 
will be open sourced as soon as the implementation is more mature.
We will announce on the graal-dev list if and when the source will 
become available.

In the meantime we will keep updating Graal Python in our monthly 
GraalVM binary releases.

Stay tuned,

Cheers,
Christian


On 03.11.2017 21:25:17, "Todd Letsche" <letsche at gmail.com> wrote:

>Hi,
>
>Perhaps this is the wrong place to ask, but maybe you can point me to
>the right place.
>
>The Python interpreter in the graalvm 0.28.2 distribution appears to
>be a modified version of ZipPy.  Is the source code available, by
>chance?  If not, are there plans to make it available somewhere?
>
>Thanks,
>
>Todd


From letsche at gmail.com  Fri Nov  3 20:55:14 2017
From: letsche at gmail.com (Todd Letsche)
Date: Fri, 3 Nov 2017 15:55:14 -0500
Subject: Python
In-Reply-To: <emc69fa7e2-74b9-4c74-b42e-9fbd5b59ba12@grashalm-work>
References: <CAPfPP9D54=7Ht5SHBc42W4MxUspK-snSoZbVs_w+mfqLcB2u=w@mail.gmail.com>
 <emc69fa7e2-74b9-4c74-b42e-9fbd5b59ba12@grashalm-work>
Message-ID: <CAPfPP9AVjemcpM1EBtCCe2Z3B-EQ8SAnK3rO_qNdcthL99MJqw@mail.gmail.com>

OK.  Thanks!


Todd

On Fri, Nov 3, 2017 at 3:47 PM, Christian Humer
<christian.humer at gmail.com> wrote:
> Hi Todd,
>
> Thank you for your interest.
> The Graal Python version included in GraalVM 0.28.2 is currently under heavy
> development.
> The source code is not available publicly atm, but it is likely that it will
> be open sourced as soon as the implementation is more mature.
> We will announce on the graal-dev list if and when the source will become
> available.
>
> In the meantime we will keep updating Graal Python in our monthly GraalVM
> binary releases.
>
> Stay tuned,
>
> Cheers,
> Christian
>
>
>
> On 03.11.2017 21:25:17, "Todd Letsche" <letsche at gmail.com> wrote:
>
>> Hi,
>>
>> Perhaps this is the wrong place to ask, but maybe you can point me to
>> the right place.
>>
>> The Python interpreter in the graalvm 0.28.2 distribution appears to
>> be a modified version of ZipPy.  Is the source code available, by
>> chance?  If not, are there plans to make it available somewhere?
>>
>> Thanks,
>>
>> Todd
>
>

From jackson at jcdav.is  Fri Nov 10 10:57:46 2017
From: jackson at jcdav.is (Jackson Davis)
Date: Fri, 10 Nov 2017 02:57:46 -0800
Subject: An introduction and some questions
In-Reply-To: <74643684-E1AA-4DA5-9E7E-1E23D390BA02@oracle.com>
References: <CAHeMEgKYynBr5SL5qgH9tmmc_fW+-0+0MEbuaOkwKimUERXi5w@mail.gmail.com>
 <74643684-E1AA-4DA5-9E7E-1E23D390BA02@oracle.com>
Message-ID: <CAHeMEg+RvZvWdwJESXcWBV9qg1onfkWFSKah__9oyrHe5p_u=A@mail.gmail.com>

I've cleaned this up and turned this into a PR, was wondering if someone
could take a look?

https://github.com/graalvm/graal/pull/263

This only considers add/sub for constants > 1, for which using lea is
always at least as short, if not shorter.

Thanks,
-Jackson


On Mon, Oct 30, 2017 at 12:53 PM, Doug Simon <doug.simon at oracle.com> wrote:

> Welcome Jackson!
>
> > On 30 Oct 2017, at 18:27, Jackson Davis <jackson at jcdav.is> wrote:
> >
> > Hello,
> >
> > I've been trying to finally introduce myself to graal over the last few
> > days, with a hope I can maybe sneak in a few changes when I have time -
> its
> > an interesting project :)
> >
> > On the non-technical side: Whats with the [GR-XXXX] in commit messages,
> is
> > this a private issue tracker? I don't see anything on the graal project
> on
> > openjdk jira, or anywhere else for that matter.
>
> These are indeed related to an internal jira instance Graal shares with a
> number of other projects at Oracle Labs, some of which are not open source.
>
> We also respond to issues and pull requests at https://github.com/graalvm/
> graal.
>
> > On the technical side: I've been looking into optimizing the code
> > generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are
> > different, reg2 = add reg1, C generates
> > mov %reg1, %reg2
> > add C, %reg2
> >
> > This can be folded into a single lea C(%reg1), %reg2 (if there is no
> > resulting operation dependent on flags being set). We can do the same for
> > sub, and for shl if C=1/2/3. I have a very basic attempt of this
> > working-ish here:
> > https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263c
> a0cde3dcf1
> > . This currently always uses leaq, which is at best 1 byte longer than it
> > needs to be for 32 bit operands (since the REX prefix isn't necessary),
> and
> > at worst possibly wrong because over/underflow will set the high order 32
> > bits (which might be ok? But unsure). It also misses add/sub by 1 (since
> > those are lowered to MOp, not ConstOp), and also doesn't consider %reg3 =
> > %reg1 + %reg2 (which can also be represented as an lea)
> >
> > Where I am a little lost is how to clean this up properly. I was
> thinking a
> > new emit function that also takes a source register x could be added,
> which
> > be default would still call the same move + emit, and then, individual
> > opcodes could override that behavior as necessary?
>
> I would suggest implementing and testing your suggestion then submitting a
> PR on github to allow someone more familiar than I am with this part of the
> compiler to offer feedback.
>
> -Doug

From gilles.m.duboscq at oracle.com  Fri Nov 10 11:06:51 2017
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Fri, 10 Nov 2017 12:06:51 +0100
Subject: An introduction and some questions
In-Reply-To: <CAHeMEg+RvZvWdwJESXcWBV9qg1onfkWFSKah__9oyrHe5p_u=A@mail.gmail.com>
References: <CAHeMEgKYynBr5SL5qgH9tmmc_fW+-0+0MEbuaOkwKimUERXi5w@mail.gmail.com>
 <74643684-E1AA-4DA5-9E7E-1E23D390BA02@oracle.com>
 <CAHeMEg+RvZvWdwJESXcWBV9qg1onfkWFSKah__9oyrHe5p_u=A@mail.gmail.com>
Message-ID: <1e6609e2-7aa3-d7b5-156a-5e95a5e705a5@oracle.com>

Hi Jackson,

You'll need to sign the Oracle Contributor Agreement. The procedure is described there:
http://www.oracle.com/technetwork/community/oca-486395.html

Please let us know when that's done.

 Gilles

On 10/11/17 11:57, Jackson Davis wrote:
> I've cleaned this up and turned this into a PR, was wondering if someone
> could take a look?
> 
> https://github.com/graalvm/graal/pull/263
> 
> This only considers add/sub for constants > 1, for which using lea is
> always at least as short, if not shorter.
> 
> Thanks,
> -Jackson
> 
> 
> On Mon, Oct 30, 2017 at 12:53 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> Welcome Jackson!
>>
>>> On 30 Oct 2017, at 18:27, Jackson Davis <jackson at jcdav.is> wrote:
>>>
>>> Hello,
>>>
>>> I've been trying to finally introduce myself to graal over the last few
>>> days, with a hope I can maybe sneak in a few changes when I have time -
>> its
>>> an interesting project :)
>>>
>>> On the non-technical side: Whats with the [GR-XXXX] in commit messages,
>> is
>>> this a private issue tracker? I don't see anything on the graal project
>> on
>>> openjdk jira, or anywhere else for that matter.
>>
>> These are indeed related to an internal jira instance Graal shares with a
>> number of other projects at Oracle Labs, some of which are not open source.
>>
>> We also respond to issues and pull requests at https://github.com/graalvm/
>> graal.
>>
>>> On the technical side: I've been looking into optimizing the code
>>> generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are
>>> different, reg2 = add reg1, C generates
>>> mov %reg1, %reg2
>>> add C, %reg2
>>>
>>> This can be folded into a single lea C(%reg1), %reg2 (if there is no
>>> resulting operation dependent on flags being set). We can do the same for
>>> sub, and for shl if C=1/2/3. I have a very basic attempt of this
>>> working-ish here:
>>> https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263c
>> a0cde3dcf1
>>> . This currently always uses leaq, which is at best 1 byte longer than it
>>> needs to be for 32 bit operands (since the REX prefix isn't necessary),
>> and
>>> at worst possibly wrong because over/underflow will set the high order 32
>>> bits (which might be ok? But unsure). It also misses add/sub by 1 (since
>>> those are lowered to MOp, not ConstOp), and also doesn't consider %reg3 =
>>> %reg1 + %reg2 (which can also be represented as an lea)
>>>
>>> Where I am a little lost is how to clean this up properly. I was
>> thinking a
>>> new emit function that also takes a source register x could be added,
>> which
>>> be default would still call the same move + emit, and then, individual
>>> opcodes could override that behavior as necessary?
>>
>> I would suggest implementing and testing your suggestion then submitting a
>> PR on github to allow someone more familiar than I am with this part of the
>> compiler to offer feedback.
>>
>> -Doug

From java at stefan-marr.de  Tue Nov 14 16:28:30 2017
From: java at stefan-marr.de (Stefan Marr)
Date: Tue, 14 Nov 2017 16:28:30 +0000
Subject: Truffle Splitting Heuristics cause compilation to never stabilize
In-Reply-To: <4AA691F7-AD9D-4325-B95A-4225C979EA04@oracle.com>
References: <1C7C33DE-FBE3-49E1-8DC5-F4730A5F264B@stefan-marr.de>
 <4AA691F7-AD9D-4325-B95A-4225C979EA04@oracle.com>
Message-ID: <98406FC1-7052-4EFC-A78E-348FD3F4B21F@stefan-marr.de>

Hi:

Any updates on this issue?
It seems to come back biting us. Now it seems the culprit in some fork/join workloads.

Thanks
Stefan

> On 26 Jul 2017, at 21:49, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
> Thanks Stefan. This is a great catch! We need to fix the splitting heuristics to cover indirect recursion. - thomas
> 
>> On 26 Jul 2017, at 17:57, Stefan Marr <java at stefan-marr.de> wrote:
>> 
>> Hi:
>> 
>> I have been running into a stabilizing issue with a small benchmark from the Newspeak benchmark suite.
>> 
>> The issue exists however also in other languages.
>> Let?s take Ruby as example, which might be more legible:
>> 
>> def fib(x)
>> -> n {
>>   if n < 2
>>     1
>>   else
>>     fib(n-1) + fib(n-2)
>>   end
>> }.call(x)
>> end
>> 
>> loop { fib(25) }
>> 
>> The main problem here is that we have an indirectly recursive function, which itself has only a single call.
>> 
>> This means, DefaultTruffleSplittingStrategy will see fib and say hey isMaxSingleCall==true, let?s split it.
>> In the block itself, fib is then split again and again, because it is not directly recursive, but one indirection removed. So, the recursion heuristic doesn?t trigger.
>> 
>> In my Newspeak (SOMns), the problem is further exaggerated because when a method gets split, I also split its embedded blocks to allow type specialization of local variables. This isn?t the case in TruffleRuby however.
>> 
>> Is there anything that could be done to make DefaultTruffleSplittingStrategy a little smarter about this?

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/



From christian.humer at gmail.com  Tue Nov 14 17:05:09 2017
From: christian.humer at gmail.com (Christian Humer)
Date: Tue, 14 Nov 2017 17:05:09 +0000
Subject: Truffle Splitting Heuristics cause compilation to never stabilize
In-Reply-To: <98406FC1-7052-4EFC-A78E-348FD3F4B21F@stefan-marr.de>
References: <1C7C33DE-FBE3-49E1-8DC5-F4730A5F264B@stefan-marr.de>
 <4AA691F7-AD9D-4325-B95A-4225C979EA04@oracle.com>
 <98406FC1-7052-4EFC-A78E-348FD3F4B21F@stefan-marr.de>
Message-ID: <em1d390f62-1fd4-43f7-b4c9-ce1eccb827be@grashalm-work>

Hi Stefan,

No not yet. We are working on a general overhaul of the splitting 
heuristic.
But this should probably be fixed independently of that. We will work on 
a fix for this ASAP.
We will reply here as soon as its done.

Thanks,

Christian


On 14.11.2017 17:28:30, "Stefan Marr" <java at stefan-marr.de> wrote:

>Hi:
>
>Any updates on this issue?
>It seems to come back biting us. Now it seems the culprit in some 
>fork/join workloads.
>
>Thanks
>Stefan
>
>>On 26 Jul 2017, at 21:49, Thomas Wuerthinger 
>><thomas.wuerthinger at oracle.com> wrote:
>>
>>Thanks Stefan. This is a great catch! We need to fix the splitting 
>>heuristics to cover indirect recursion. - thomas
>>
>>>On 26 Jul 2017, at 17:57, Stefan Marr <java at stefan-marr.de> wrote:
>>>
>>>Hi:
>>>
>>>I have been running into a stabilizing issue with a small benchmark 
>>>from the Newspeak benchmark suite.
>>>
>>>The issue exists however also in other languages.
>>>Let?s take Ruby as example, which might be more legible:
>>>
>>>def fib(x)
>>>-> n {
>>>   if n < 2
>>>     1
>>>   else
>>>     fib(n-1) + fib(n-2)
>>>   end
>>>}.call(x)
>>>end
>>>
>>>loop { fib(25) }
>>>
>>>The main problem here is that we have an indirectly recursive 
>>>function, which itself has only a single call.
>>>
>>>This means, DefaultTruffleSplittingStrategy will see fib and say hey 
>>>isMaxSingleCall==true, let?s split it.
>>>In the block itself, fib is then split again and again, because it is 
>>>not directly recursive, but one indirection removed. So, the 
>>>recursion heuristic doesn?t trigger.
>>>
>>>In my Newspeak (SOMns), the problem is further exaggerated because 
>>>when a method gets split, I also split its embedded blocks to allow 
>>>type specialization of local variables. This isn?t the case in 
>>>TruffleRuby however.
>>>
>>>Is there anything that could be done to make 
>>>DefaultTruffleSplittingStrategy a little smarter about this?
>
>--
>Stefan Marr
>School of Computing, University of Kent
>http://stefan-marr.de/research/
>
>


From jackson at jcdav.is  Wed Nov 15 19:49:29 2017
From: jackson at jcdav.is (Jackson Davis)
Date: Wed, 15 Nov 2017 11:49:29 -0800
Subject: An introduction and some questions
In-Reply-To: <1e6609e2-7aa3-d7b5-156a-5e95a5e705a5@oracle.com>
References: <CAHeMEgKYynBr5SL5qgH9tmmc_fW+-0+0MEbuaOkwKimUERXi5w@mail.gmail.com>
 <74643684-E1AA-4DA5-9E7E-1E23D390BA02@oracle.com>
 <CAHeMEg+RvZvWdwJESXcWBV9qg1onfkWFSKah__9oyrHe5p_u=A@mail.gmail.com>
 <1e6609e2-7aa3-d7b5-156a-5e95a5e705a5@oracle.com>
Message-ID: <CAHeMEg+GXLzw2kG-ZwSKzPdhV+2FzCRjnjYczSf7n51PW_+ALw@mail.gmail.com>

Hi Gilles,

OCA is signed: http://www.oracle.com/technetwork/community/oca-486395.html#d

Thanks
-Jackson


On Fri, Nov 10, 2017 at 3:06 AM, Gilles Duboscq <gilles.m.duboscq at oracle.com
> wrote:

> Hi Jackson,
>
> You'll need to sign the Oracle Contributor Agreement. The procedure is
> described there:
> http://www.oracle.com/technetwork/community/oca-486395.html
>
> Please let us know when that's done.
>
>  Gilles
>
> On 10/11/17 11:57, Jackson Davis wrote:
> > I've cleaned this up and turned this into a PR, was wondering if someone
> > could take a look?
> >
> > https://github.com/graalvm/graal/pull/263
> >
> > This only considers add/sub for constants > 1, for which using lea is
> > always at least as short, if not shorter.
> >
> > Thanks,
> > -Jackson
> >
> >
> > On Mon, Oct 30, 2017 at 12:53 PM, Doug Simon <doug.simon at oracle.com>
> wrote:
> >
> >> Welcome Jackson!
> >>
> >>> On 30 Oct 2017, at 18:27, Jackson Davis <jackson at jcdav.is> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I've been trying to finally introduce myself to graal over the last few
> >>> days, with a hope I can maybe sneak in a few changes when I have time -
> >> its
> >>> an interesting project :)
> >>>
> >>> On the non-technical side: Whats with the [GR-XXXX] in commit messages,
> >> is
> >>> this a private issue tracker? I don't see anything on the graal project
> >> on
> >>> openjdk jira, or anywhere else for that matter.
> >>
> >> These are indeed related to an internal jira instance Graal shares with
> a
> >> number of other projects at Oracle Labs, some of which are not open
> source.
> >>
> >> We also respond to issues and pull requests at
> https://github.com/graalvm/
> >> graal.
> >>
> >>> On the technical side: I've been looking into optimizing the code
> >>> generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are
> >>> different, reg2 = add reg1, C generates
> >>> mov %reg1, %reg2
> >>> add C, %reg2
> >>>
> >>> This can be folded into a single lea C(%reg1), %reg2 (if there is no
> >>> resulting operation dependent on flags being set). We can do the same
> for
> >>> sub, and for shl if C=1/2/3. I have a very basic attempt of this
> >>> working-ish here:
> >>> https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263c
> >> a0cde3dcf1
> >>> . This currently always uses leaq, which is at best 1 byte longer than
> it
> >>> needs to be for 32 bit operands (since the REX prefix isn't necessary),
> >> and
> >>> at worst possibly wrong because over/underflow will set the high order
> 32
> >>> bits (which might be ok? But unsure). It also misses add/sub by 1
> (since
> >>> those are lowered to MOp, not ConstOp), and also doesn't consider
> %reg3 =
> >>> %reg1 + %reg2 (which can also be represented as an lea)
> >>>
> >>> Where I am a little lost is how to clean this up properly. I was
> >> thinking a
> >>> new emit function that also takes a source register x could be added,
> >> which
> >>> be default would still call the same move + emit, and then, individual
> >>> opcodes could override that behavior as necessary?
> >>
> >> I would suggest implementing and testing your suggestion then
> submitting a
> >> PR on github to allow someone more familiar than I am with this part of
> the
> >> compiler to offer feedback.
> >>
> >> -Doug
>

From thomas.wuerthinger at oracle.com  Thu Nov 16 13:55:45 2017
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Thu, 16 Nov 2017 14:55:45 +0100
Subject: Detecting when compilations occur
In-Reply-To: <80c62bfa-9eb1-6da4-476f-a1f1b09a5eff@cs.utexas.edu>
References: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu>
 <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz>
 <80c62bfa-9eb1-6da4-476f-a1f1b09a5eff@cs.utexas.edu>
Message-ID: <F57586F0-D215-46C8-94E9-88BCF416ADFB@oracle.com>

No, it does not include Truffle compile times. - thomas

> On 13 Oct 2017, at 18:11, Arthur Peters <amp at cs.utexas.edu> wrote:
> 
> Thanks!
> 
> I had not thought of CompilationMXBean for some reason. Does
> CompilationMXBean.getTotalCompilationTime() include Truffle compile
> time? Looking at the numbers it seems like it might not, but it's hard
> to tell.
> 
> -Arthur
> 
> 
> On 10/13/2017 01:17 AM, Petr T?ma wrote:
>> Hi Arthur,
>> 
>> some options, depending on what exactly you want:
>> 
>> - you could catch the JVMTI CompiledMethodLoad event callback, this
>> needs a C agent but otherwise should work quite well
>> 
>> - you could query the CompilationMXBean in java.lang.management, this
>> gives you the aggregate compilation time in milliseconds (this will
>> jump forward on compilation end but sub millisecond compilation events
>> will not be visible)
>> 
>> - you can monitor the execution time of the compiler threads
>> 
>> - you can enable the JVM compilation log (-XX:+PrintCompilation), this
>> includes time relative to JVM start so can be correlated with
>> benchmark iterations if they are long enough
>> 
>> Some of these are implemented in
>> https://github.com/D-iii-S/java-ubench-agent, you can take a look for
>> inspiration.
>> 
>> Hope this helps, Petr
>> 
>> 
>> On 13/10/17 02:47, Arthur Peters wrote:
>>> Is there any way to detect when Truffle/Graal compilations happen? (for
>>> instance by getting a callback or even just accessing a count of how
>>> many compilations have happened so I can check if it has changed.)
>>> 
>>> I would like to have this information for my benchmarking so I can
>>> easily tag repetitions of the benchmark that have a compilation. This
>>> would be useful for analyzing how fast the code generated by the
>>> compiler is independent of the compiler itself and visa versa.
>>> 
>>> -Arthur
>>> 
>>> PS: I'm not going to just remove all the repetitions with compilations.
>>> That would not really represent the performance of the language. But it
>>> would be nice to be able to do subgroup analysis.
>>> 
> 
> 


From pangalz at gmail.com  Sat Nov 18 21:00:40 2017
From: pangalz at gmail.com (Leonardo Loch Zanivan)
Date: Sat, 18 Nov 2017 21:00:40 +0000
Subject: Native image compilation error
Message-ID: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>

Hi

I didn't found this mailing list before, so I created an issue in github.

Basically, I'm trying to compile to native image a very simple Java
application that serializes a objeto into JSON using Jackson, but it fails.

https://github.com/graalvm/graal/issues/264

From java at stefan-marr.de  Sat Nov 18 21:07:31 2017
From: java at stefan-marr.de (Stefan Marr)
Date: Sat, 18 Nov 2017 21:07:31 +0000
Subject: Native image compilation error
In-Reply-To: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
Message-ID: <3854E5EE-F355-4C59-BCA1-BB5DA751997B@stefan-marr.de>

Hi Leonardo:

> On 18 Nov 2017, at 21:00, Leonardo Loch Zanivan <pangalz at gmail.com> wrote:
> 
> Basically, I'm trying to compile to native image a very simple Java
> application that serializes a objeto into JSON using Jackson, but it fails.
> 
> https://github.com/graalvm/graal/issues/264

If I read the stack trace correctly, it is trying to use reflection?
As far as I know, SVM/native images currently don?t support reflection at run time.

Best regards
Stefan

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/



From pangalz at gmail.com  Sat Nov 18 21:10:52 2017
From: pangalz at gmail.com (Leonardo Loch Zanivan)
Date: Sat, 18 Nov 2017 21:10:52 +0000
Subject: Native image compilation error
In-Reply-To: <3854E5EE-F355-4C59-BCA1-BB5DA751997B@stefan-marr.de>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
 <3854E5EE-F355-4C59-BCA1-BB5DA751997B@stefan-marr.de>
Message-ID: <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>

Hi Setan,

Yes, it does. I wasn't aware of that limitation.

I only read some mentions about Classloading limitations.

All the JSON serializers I know uses Reflection APIs, so I suppose this is
something to be supported in future releases.

Regards,
Leonardo

On Sat, Nov 18, 2017 at 7:07 PM Stefan Marr <java at stefan-marr.de> wrote:

> Hi Leonardo:
>
> > On 18 Nov 2017, at 21:00, Leonardo Loch Zanivan <pangalz at gmail.com>
> wrote:
> >
> > Basically, I'm trying to compile to native image a very simple Java
> > application that serializes a objeto into JSON using Jackson, but it
> fails.
> >
> > https://github.com/graalvm/graal/issues/264
>
> If I read the stack trace correctly, it is trying to use reflection?
> As far as I know, SVM/native images currently don?t support reflection at
> run time.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>
>

From java at stefan-marr.de  Sat Nov 18 21:18:37 2017
From: java at stefan-marr.de (Stefan Marr)
Date: Sat, 18 Nov 2017 21:18:37 +0000
Subject: Native image compilation error
In-Reply-To: <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
 <3854E5EE-F355-4C59-BCA1-BB5DA751997B@stefan-marr.de>
 <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
Message-ID: <324AD597-E302-435D-97D4-C7EFB2BD7C09@stefan-marr.de>

Hi Leonardo:

> On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan <pangalz at gmail.com> wrote:
> 
> I only read some mentions about Classloading limitations.
> 
> All the JSON serializers I know uses Reflection APIs, so I suppose this is something to be supported in future releases.

I don?t know. But, you really need the closed world assumption to make AOT compilation in the way it is supposed to work for Truffle languages.
So, I wouldn?t expect that this is going to be addressed any time soon?

Best regards
Stefan

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/



From codrut.stancu at oracle.com  Sat Nov 18 22:04:30 2017
From: codrut.stancu at oracle.com (Codrut Stancu)
Date: Sat, 18 Nov 2017 14:04:30 -0800
Subject: Native image compilation error
Message-ID: <201711182204.vAIM4Ye4011551@aserv0121.oracle.com>

We actually do support reflection in SVM, but you have to specify the reflexively accessed elements using some descriptor files. That's a limitation of the closed world assumption. The only feature that's not supported is dynamic class loading. We haven't experimented with Jackson yet. I'll get back later with more details (on my phone right now).

Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr <java at stefan-marr.de> wrote:
>
> Hi Leonardo: 
>
> > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan <pangalz at gmail.com> wrote: 
> > 
> > I only read some mentions about Classloading limitations. 
> > 
> > All the JSON serializers I know uses Reflection APIs, so I suppose this is something to be supported in future releases. 
>
> I don?t know. But, you really need the closed world assumption to make AOT compilation in the way it is supposed to work for Truffle languages. 
> So, I wouldn?t expect that this is going to be addressed any time soon? 
>
> Best regards 
> Stefan 
>
> -- 
> Stefan Marr 
> School of Computing, University of Kent 
> http://stefan-marr.de/research/ 
>
>

From pangalz at gmail.com  Sun Nov 19 13:41:40 2017
From: pangalz at gmail.com (Leonardo Loch Zanivan)
Date: Sun, 19 Nov 2017 13:41:40 +0000
Subject: Native image compilation error
In-Reply-To: <201711182204.vAIM4Ye4011551@aserv0121.oracle.com>
References: <201711182204.vAIM4Ye4011551@aserv0121.oracle.com>
Message-ID: <CA+sftsCNjnrDSJrYo_xOaKxoAeB6YqjVV2HpUVzoX7t0a-oAig@mail.gmail.com>

Ok, thanks for the clarification.
I tried "java.lang.invoke.MethodHandle" without success too.

"We actually do support reflection in SVM, but you have to specify the
reflexively accessed elements using some descriptor files."

Do you have any documentation or sample that I can use?

On Sat, Nov 18, 2017 at 8:04 PM Codrut Stancu <codrut.stancu at oracle.com>
wrote:

> We actually do support reflection in SVM, but you have to specify the
> reflexively accessed elements using some descriptor files. That's a
> limitation of the closed world assumption. The only feature that's not
> supported is dynamic class loading. We haven't experimented with Jackson
> yet. I'll get back later with more details (on my phone right now).
>
> Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr <java at stefan-marr.de>
> wrote:
> >
> > Hi Leonardo:
> >
> > > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan <pangalz at gmail.com>
> wrote:
> > >
> > > I only read some mentions about Classloading limitations.
> > >
> > > All the JSON serializers I know uses Reflection APIs, so I suppose
> this is something to be supported in future releases.
> >
> > I don?t know. But, you really need the closed world assumption to make
> AOT compilation in the way it is supposed to work for Truffle languages.
> > So, I wouldn?t expect that this is going to be addressed any time soon?
> >
> > Best regards
> > Stefan
> >
> > --
> > Stefan Marr
> > School of Computing, University of Kent
> > http://stefan-marr.de/research/
> >
> >
>

From jaroslav.tulach at oracle.com  Mon Nov 20 05:49:06 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Mon, 20 Nov 2017 06:49:06 +0100
Subject: JSON without reflection was: Native image compilation error
In-Reply-To: <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
 <3854E5EE-F355-4C59-BCA1-BB5DA751997B@stefan-marr.de>
 <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
Message-ID: <4395289.Qd3gviHYAj@logoutik>

>> Leonardo Loch Zanivan <pangalz at gmail.com>: 18.11.17 @ 21:10 <<
> All the JSON serializers I know uses Reflection APIs, so I suppose this is
> something to be supported in future releases.

Hi. I wrote [Apache HTML/Java API](https://github.com/apache/incubator-netbeans-html4j) and it can be [used for parsing/serializing JSON](https://
dukescript.com/update/2015/01/27/ParsingJSON.html) without any need of 
reflection. As such one can use this method in native-image without any issues.

Good luck.
-jt


From jaroslav.tulach at oracle.com  Mon Nov 20 12:15:49 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Mon, 20 Nov 2017 13:15:49 +0100
Subject: JSON without reflection was: Native image compilation error
In-Reply-To: <4395289.Qd3gviHYAj@logoutik>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
 <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
 <4395289.Qd3gviHYAj@logoutik>
Message-ID: <7447922.08io0b0PGS@logoutik>

Hello Leonardo.

>> Jaroslav Tulach <jaroslav.tulach at oracle.com>: 20.11.17 @ 6:49 <<
> >> Leonardo Loch Zanivan <pangalz at gmail.com>: 18.11.17 @ 21:10 <<
> > 
> > All the JSON serializers I know uses Reflection APIs, so I suppose this is
> > something to be supported in future releases.
> 
> Hi. I wrote [Apache HTML/Java
> API](https://github.com/apache/incubator-netbeans-html4j) and it can be
> [used for parsing/serializing JSON](https://
> dukescript.com/update/2015/01/27/ParsingJSON.html) without any need of
> reflection. As such one can use this method in native-image without any
> issues.
> 
> Good luck.

I have given it a try and here is a Maven example showing how to use the 
@Model based JSON parser with SubstrateVM:

https://github.com/JaroslavTulach/incubator-netbeans-html4j/blob/examples/
examples/jsonparse/README.md

I hope you find it useful.
-jt


From leonardo.zanivan at gmail.com  Mon Nov 20 15:13:27 2017
From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan)
Date: Mon, 20 Nov 2017 15:13:27 +0000
Subject: JSON without reflection was: Native image compilation error
In-Reply-To: <7447922.08io0b0PGS@logoutik>
References: <CA+sftsDMuhyvDBgKzTGo8QXi4J9+qkue+AzD+R9nEq19NUtQGA@mail.gmail.com>
 <CA+sftsB579BbJ5i2NnCvZa9R_75BGNT81UrwipShjWGaym3YHw@mail.gmail.com>
 <4395289.Qd3gviHYAj@logoutik> <7447922.08io0b0PGS@logoutik>
Message-ID: <CA+sftsA-znjtqZFK6YuB1TuJDaSjKtuydVpuoSE3iW1TSS0zYQ@mail.gmail.com>

Hi Jaroslav,

Thanks! I was not aware of this netbeans-html4j feature :)

I have a few scenarios that I may use it, but I also need compile existing
code that uses reflection (Jackson/Gson) to be working.

On Mon, Nov 20, 2017 at 10:16 AM Jaroslav Tulach <jaroslav.tulach at oracle.com>
wrote:

> Hello Leonardo.
>
> >> Jaroslav Tulach <jaroslav.tulach at oracle.com>: 20.11.17 @ 6:49 <<
> > >> Leonardo Loch Zanivan <pangalz at gmail.com>: 18.11.17 @ 21:10 <<
> > >
> > > All the JSON serializers I know uses Reflection APIs, so I suppose
> this is
> > > something to be supported in future releases.
> >
> > Hi. I wrote [Apache HTML/Java
> > API](https://github.com/apache/incubator-netbeans-html4j) and it can be
> > [used for parsing/serializing JSON](https://
> > dukescript.com/update/2015/01/27/ParsingJSON.html) without any need of
> > reflection. As such one can use this method in native-image without any
> > issues.
> >
> > Good luck.
>
> I have given it a try and here is a Maven example showing how to use the
> @Model based JSON parser with SubstrateVM:
>
> https://github.com/JaroslavTulach/incubator-netbeans-html4j/blob/examples/
> examples/jsonparse/README.md
> <https://github.com/JaroslavTulach/incubator-netbeans-html4j/blob/examples/examples/jsonparse/README.md>
>
> I hope you find it useful.
> -jt
>
>

From codrut.stancu at oracle.com  Mon Nov 20 23:54:19 2017
From: codrut.stancu at oracle.com (Codrut Stancu)
Date: Mon, 20 Nov 2017 15:54:19 -0800
Subject: Native image compilation error
In-Reply-To: <6pt2bsus0rocefn9ja456be2.1511042679532@email.android.com>
References: <6pt2bsus0rocefn9ja456be2.1511042679532@email.android.com>
Message-ID: <1511222059.16129.3.camel@oracle.com>

Hi Leonardo,

Reflection is not supported in the current native-image released
binary. It should be supported in the next release. The release will
also include a small example to get you started.

Codrut Stancu

On Sat, 2017-11-18 at 14:04 -0800, Codrut Stancu wrote:
> We actually do support reflection in SVM, but you have to specify the
> reflexively accessed elements using some descriptor files. That's a
> limitation of the closed world assumption. The only feature that's
> not supported is dynamic class loading. We haven't experimented with
> Jackson yet. I'll get back later with more details (on my phone right
> now).
> 
> Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr <java at stefan-marr.d
> e> wrote:
> > 
> > 
> > Hi Leonardo:?
> > 
> > > 
> > > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan <pangalz at gmail.co
> > > m> wrote:?
> > > 
> > > I only read some mentions about Classloading limitations.?
> > > 
> > > All the JSON serializers I know uses Reflection APIs, so I
> > > suppose this is something to be supported in future releases.?
> > I don?t know. But, you really need the closed world assumption to
> > make AOT compilation in the way it is supposed to work for Truffle
> > languages.?
> > So, I wouldn?t expect that this is going to be addressed any time
> > soon??
> > 
> > Best regards?
> > Stefan?
> > 

From pangalz at gmail.com  Tue Nov 21 00:07:33 2017
From: pangalz at gmail.com (Leonardo Loch Zanivan)
Date: Tue, 21 Nov 2017 00:07:33 +0000
Subject: Native image compilation error
In-Reply-To: <1511222059.16129.3.camel@oracle.com>
References: <6pt2bsus0rocefn9ja456be2.1511042679532@email.android.com>
 <1511222059.16129.3.camel@oracle.com>
Message-ID: <CA+sftsDt8XYQvCRW5Wvj+Tc9khMoKkb2TWpH70W-gd5Gg6MbTA@mail.gmail.com>

Awesome! Thank you for letting me know. I'm looking forward to use it soon.

Cheers

On Mon, Nov 20, 2017 at 9:54 PM Codrut Stancu <codrut.stancu at oracle.com>
wrote:

> Hi Leonardo,
>
> Reflection is not supported in the current native-image released
> binary. It should be supported in the next release. The release will
> also include a small example to get you started.
>
> Codrut Stancu
>
> On Sat, 2017-11-18 at 14:04 -0800, Codrut Stancu wrote:
> > We actually do support reflection in SVM, but you have to specify the
> > reflexively accessed elements using some descriptor files. That's a
> > limitation of the closed world assumption. The only feature that's
> > not supported is dynamic class loading. We haven't experimented with
> > Jackson yet. I'll get back later with more details (on my phone right
> > now).
> >
> > Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr <java at stefan-marr.d
> > e> wrote:
> > >
> > >
> > > Hi Leonardo:
> > >
> > > >
> > > > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan <pangalz at gmail.co
> > > > m> wrote:
> > > >
> > > > I only read some mentions about Classloading limitations.
> > > >
> > > > All the JSON serializers I know uses Reflection APIs, so I
> > > > suppose this is something to be supported in future releases.
> > > I don?t know. But, you really need the closed world assumption to
> > > make AOT compilation in the way it is supposed to work for Truffle
> > > languages.
> > > So, I wouldn?t expect that this is going to be addressed any time
> > > soon?
> > >
> > > Best regards
> > > Stefan
> > >
>