Thank you, Alan
Vladimir
On 12/13/17 8:58 AM, Alan Bateman wrote:
On 13/12/2017 16:47, mandy chung wrote:
On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
After several rounds of testing (which found different types of
failures with Graal as JIT compiler) I decided to limit these changes
On 13/12/2017 16:47, mandy chung wrote:
On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
After several rounds of testing (which found different types of
failures with Graal as JIT compiler) I decided to limit these changes
for cases when --limit-modules is used:
Thank you, Mandy
Vladimir
On 12/13/17 8:47 AM, mandy chung wrote:
On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
After several rounds of testing (which found different types of
failures with Graal as JIT compiler) I decided to limit these changes
for cases when --limit-modules is used:
On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
After several rounds of testing (which found different types of
failures with Graal as JIT compiler) I decided to limit these changes
for cases when --limit-modules is used:
http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
Looks okay.
Since
After several rounds of testing (which found different types of failures
with Graal as JIT compiler) I decided to limit these changes for cases
when --limit-modules is used:
http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8191788
Thanks,
Vladimir
Yes, it was my limited understanding what --limit-modules is. We should not add modules "under
cover" when --limit-modules is used. User should known all required modules *explicitly* to create
correct image with jlink based on result of runs with --limit-modules flag.
Since it is limited set
Vladimir and I discussed this offline. java --limit-modules should have
the same set of observable modules as running on an image that is
created with jlink. When running with -XX:+UseJVMCICompiler on a
runtime image with just java.base, it will fail in the same way as
running with java
> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov
> wrote:
>
> On 11/29/17 4:37 AM, Alan Bateman wrote:
>> On 29/11/2017 11:26, David Holmes wrote:
>>>
>>> The current approach basically prevents anyone using JVMCI from shooting
>>> themselves in the foot by setting
> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov
> wrote:
>
> On 11/29/17 4:37 AM, Alan Bateman wrote:
>> On 29/11/2017 11:26, David Holmes wrote:
>>>
>>> The current approach basically prevents anyone using JVMCI from shooting
>>> themselves in the foot by setting
On 11/29/17 4:37 AM, Alan Bateman wrote:
On 29/11/2017 11:26, David Holmes wrote:
The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting
--limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure
Hi Alan,
On 11/29/17 1:05 AM, Alan Bateman wrote:
On 28/11/2017 23:51, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have
On 11/29/17 4:37 AM, Alan Bateman wrote:
On 29/11/2017 11:26, David Holmes wrote:
The current approach basically prevents anyone using JVMCI from
shooting themselves in the foot by setting --limit-modules in a way
that excludes the jdk.internal.vm.compiler module. In essence we want
to
On 29/11/2017 11:26, David Holmes wrote:
The current approach basically prevents anyone using JVMCI from
shooting themselves in the foot by setting --limit-modules in a way
that excludes the jdk.internal.vm.compiler module. In essence we want
to ensure that if using JVMCI then all the
On 29/11/2017 7:05 PM, Alan Bateman wrote:
On 28/11/2017 23:51, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added
jdk.internal.vm.compiler to tests which have
> On 29 Nov 2017, at 10:05, Alan Bateman wrote:
>
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added
On 28/11/2017 23:51, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added
jdk.internal.vm.compiler to tests which have --limit-modules option.
Unfortunately tests start
Thank you, Calvin
On 11/28/17 10:15 PM, Calvin Cheung wrote:
Hi Vladimir,
Fix looks good to me.
Could you break up lines #3386 (104 chars) and #3391 (146 chars)?
I will do that.
Vladimir
No need to send another webrev for the above change.
thanks,
Calvin
On 11/28/17, 3:51 PM, Vladimir
Thank you, David
On 11/28/17 8:57 PM, David Holmes wrote:
Hi Vladimir,
On 29/11/2017 9:51 AM, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to
Hi Vladimir,
Fix looks good to me.
Could you break up lines #3386 (104 chars) and #3391 (146 chars)?
No need to send another webrev for the above change.
thanks,
Calvin
On 11/28/17, 3:51 PM, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
Hi Vladimir,
On 29/11/2017 9:51 AM, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler
to tests which have --limit-modules option. Unfortunately
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788
This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have
--limit-modules option. Unfortunately tests start failing on SPARC where Graal
21 matches
Mail list logo