From lists at fniephaus.com  Thu Aug  8 16:35:46 2019
From: lists at fniephaus.com (Fabio Niephaus)
Date: Thu, 8 Aug 2019 18:35:46 +0200
Subject: Call for Papers, The Programming Journal, Volume 4, Issue 3
Message-ID: <CADfnKi5w=nM0+9fzS_AEsFs9sFr41hAnDzanCtSwTiFY=hbC_w@mail.gmail.com>

========================================================================
                        The Programming Journal

          The Art, Science, and Engineering of Programming


                 Call for Papers for Volume 4, Issue 3

                 http://programming-journal.org/cfp/
                Follow us on Twitter: @programmingconf
========================================================================

The Art, Science, and Engineering of Programming was created with the
goal of placing the wonderful art of programming on the map of scholarly
works. Many academic journals and conferences exist that publish research
related to programming, starting with programming languages, software
engineering, and expanding to the whole Computer Science field. Yet, many
of us feel that, as the field of Computer Science expanded, programming,
in itself, has been neglected to a secondary role not worthy of scholarly
attention. That is a serious gap, as much of the progress in Computer
Science lies on the basis of computer programs, the people who write them,
and the concepts and tools available to them to express computational tasks.

The Art, Science, and Engineering of Programming aims at closing this
gap by focusing primarily on programming: the art itself (programming
styles, pearls, models, languages), the emerging science of understanding
what works and what doesn?t work in general and in specific contexts,
as well as more established engineering and mathematical perspectives.


We solicit papers describing work from one of the following perspectives:

  Art: knowledge and technical skills acquired through practice and
       personal experiences. Examples include libraries, frameworks,
       languages, APIs, programming models and styles, programming
       pearls, and essays about programming.

  Science (Theoretical): knowledge and technical skills acquired
       through mathematical formalisms. Examples include formal
       programming models and proofs.

  Science (Empirical): knowledge and technical skills acquired
       through experiments and systematic observations. Examples
       include user studies and programming-related data mining.

  Engineering: knowledge and technical skills acquired through
       designing and building large systems and through calculated
       application of principles in building those systems.
       Examples include measurements of artifacts? properties,
       development processes and tools, and quality assurance methods.

Independent of the type of work, the journal accepts submissions covering
several areas of expertise, including but not limited to:

 - General-purpose programming
 - Data mining and machine learning programming, and for programming
 - Database programming
 - Distributed systems programming
 - Graphics and GPU programming
 - Interpreters, virtual machines, and compilers
 - Metaprogramming and reflection
 - Model-based development
 - Modularity and separation of concerns
 - Parallel and multi-core programming
 - Program verification
 - Programming education
 - Programming environments
 - Security programming
 - Social coding
 - Testing and debugging
 - User interface programming
 - Visual and live programming

All details, including the selection process are described on
  http://programming-journal.org/cfp/

Details on the submission processed are available at
  http://programming-journal.org/submission/

Authors of accepted papers will be invited to present at the
<Programming>?20 conference in Porto, Portugal from March 23-26:
  https://2020.programming-conference.org/


## Upcoming Deadlines

We solicit submissions for the following upcoming deadlines:

Submission:           October 1
First notification:   December 1
Revised submission:   January 1
Final notification:   January 7
Camera-ready:         January 15

## Standing Review Committee Volume 4

Christophe Scholliers, Ghent University
Coen De Roover, Vrije Universiteit Brussel
Craig Anslow, Victoria University of Wellington, New Zealand
Didier Verna, EPITA / LRDE, France
Diego Garbervetsky, University of Buenos Aires
Edd Barrett, King's College London
Erik Ernst, Google
Felienne Hermans,  Leiden University
Francisco Sant'Anna, Rio de Janeiro State University
Friedrich Steimann, University of Hagen
Gordana Rakic, University of Novi Sad
Guido Salvaneschi, TU Darmstadt
Hidehiko Masuhara, Tokyo Institute of Technology
Jeremy Gibbons, University of Oxford
Jonathan Edwards, US
Jun Kato, AIST, Japan
Luke Church, University of Cambridge
Matthew Flatt, University of Utah
Michael L. Van De Vanter, Cal Poly San Luis Obispo
Nicol?s Cardozo, Universidad de los Andes, Colombia
Stephen Kell, University of Kent

## Editors

Stefan Marr (Editor Volume 4), University of Kent
Cristina V. Lopes (Editor-in-Chief), University of California, Irvine

From mohamed.ez.zarghili at oracle.com  Wed Aug 21 08:51:38 2019
From: mohamed.ez.zarghili at oracle.com (Mohamed EZZARGHILI)
Date: Wed, 21 Aug 2019 09:51:38 +0100
Subject: JVMCI Release 19.3-b01
Message-ID: <9534172B-F4CA-4FFB-A59E-19590C3B5B17@oracle.com>

Hi

The 19.3-b01 release includes:

[GR-17641] Report JVMCI root objects as jni roots in heap dump.
[GR-17480] Improve InstalledCode.invalidate for large code caches.
[GR-17552] Do not use os:read in Arguments::finalize_vm_init_args.
[GR-17293] Add ZapTLAB option to detect overwriting past top in product mode.
[GR-17342] Improve parallel scavenge verify logic.

The binaries are available at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.3-b01 <https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.3-b01>

- Mohamed

From Xiaohong.Gong at arm.com  Tue Aug 27 07:14:11 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Tue, 27 Aug 2019 07:14:11 +0000
Subject: RFR: 8230129:  Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
Message-ID: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>

Hi,

  Please help to review this small patch:
  Webrew: http://cr.openjdk.java.net/~pli/rfr/8230129/webrev.00/
  JBS: https://bugs.openjdk.java.net/browse/JDK-8230129

  Jtreg test "serviceability/sa/ClhsdbInspect.java" fails when running with Graal. It fails when inspecting an address to check whether it's pointing to an expected oop
or method, which is printed by running "jstack -v" firstly.
  When running with graal, it needs more java heap for the JVMCI initialization and the compiler working. So it's inevitable to make GC happen during the application
running. If GC happens after runnning "jstack", the actual address of the oops and methods may be different when running "inpsect". And the address inspected may
point to other object or nothing.
  A simple fix is to add this test to the graal problem list.

Thanks,
Xiaohong Gong

From Xiaohong.Gong at arm.com  Wed Aug 28 01:52:49 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Wed, 28 Aug 2019 01:52:49 +0000
Subject: RFR: 8229797: [JVMCI] Clean up no longer used
 JVMCI::dependencies_invalid value.
Message-ID: <VI1PR08MB3421E4822599E75D997C7F37F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>

Hi,

  Please help to review this jvmci patch:
  Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/
  JBS: https://bugs.openjdk.java.net/browse/JDK-8229797

  This patch fix issue: https://github.com/oracle/graal/issues/1587.
  The loading of new classes can cause dependencies to become false, which requires the dependent
nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the
result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException.
  The invalid dependencies happen at the time of installation without any intervening modification of
the system dictionary. So as the system dictionary modification optimization has been removed, the
compiler can not know whether the failed dependencies are triggered by class reloading or not. It's
better to use dependencies_failed to mark the result.

Thanks,
Xiaohong Gong

From Xiaohong.Gong at arm.com  Wed Aug 28 01:54:05 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Wed, 28 Aug 2019 01:54:05 +0000
Subject: RFR: 8229797: [JVMCI] Clean up no longer used
 JVMCI::dependencies_invalid value.
In-Reply-To: <VI1PR08MB3421E4822599E75D997C7F37F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
References: <VI1PR08MB3421E4822599E75D997C7F37F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
Message-ID: <VI1PR08MB3421F8AD4ADEC4D1F13A5800F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>

Hi,

  Please help to review this jvmci patch:
  Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/
  JBS: https://bugs.openjdk.java.net/browse/JDK-8229797

  This patch fix issue: https://github.com/oracle/graal/issues/1587.
  The loading of new classes can cause dependencies to become false, which requires the dependent
nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the
result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException.
  The invalid dependencies happen at the time of installation without any intervening modification of
the system dictionary. So as the system dictionary modification optimization has been removed, the
compiler can not know whether the failed dependencies are triggered by class reloading or not. It's
better to use dependencies_failed to mark the result.

Thanks,
Xiaohong Gong

From frost.gary at gmail.com  Wed Aug 28 09:52:56 2019
From: frost.gary at gmail.com (Gary Frost)
Date: Wed, 28 Aug 2019 10:52:56 +0100
Subject: Accepting jdwp connection early enough to debug Graal startup with
 -Xcomp
Message-ID: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>

Have been away from Graal since 'Sumatra' days so forgive the 'n00b'
question.

I have been patching Graal's startup (to mutate some nodes) and noticed
that when I run with a standard jdwp connector configured thusly..

-agentlib:jdwp=transport=dt_socket,server=y,address=8000

By the time my debug connection has attached I have 'missed' all the Graal
setup 'goodness' :)

Admittedly I am running with -Xcomp  (oh and this is OpenJDK 11)

Re-reading the jdwp specs, I note that the contract is only that the VM
will halt and wait for connections prior to entering my applications'
main(). So no bug here, I just wish I could halt earlier ;)

How (if there is a way) do you guys get to debug startup with -Xcomp?

Is there a trick? that I am missing to halt as early as possible (I
understand there is an implied race)

Gary

From doug.simon at oracle.com  Wed Aug 28 09:58:02 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 28 Aug 2019 11:58:02 +0200
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
Message-ID: <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>

Hi Gary,

I?ve noticed the same thing myself and have not yet found a good solution. It would be nice to know what the definitive point is in VM startup after which JDWP debugging is ?on?. I?ve cc?ed Alan Bateman who may be able to offer some insight (or redirect to someone who can).

-Doug

> On 28 Aug 2019, at 11:52, Gary Frost <frost.gary at gmail.com> wrote:
> 
> Have been away from Graal since 'Sumatra' days so forgive the 'n00b'
> question.
> 
> I have been patching Graal's startup (to mutate some nodes) and noticed
> that when I run with a standard jdwp connector configured thusly..
> 
> -agentlib:jdwp=transport=dt_socket,server=y,address=8000
> 
> By the time my debug connection has attached I have 'missed' all the Graal
> setup 'goodness' :)
> 
> Admittedly I am running with -Xcomp  (oh and this is OpenJDK 11)
> 
> Re-reading the jdwp specs, I note that the contract is only that the VM
> will halt and wait for connections prior to entering my applications'
> main(). So no bug here, I just wish I could halt earlier ;)
> 
> How (if there is a way) do you guys get to debug startup with -Xcomp?
> 
> Is there a trick? that I am missing to halt as early as possible (I
> understand there is an implied race)
> 
> Gary


From doug.simon at oracle.com  Wed Aug 28 12:11:24 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 28 Aug 2019 14:11:24 +0200
Subject: RFR: 8229797: [JVMCI] Clean up no longer used
 JVMCI::dependencies_invalid value.
In-Reply-To: <VI1PR08MB3421F8AD4ADEC4D1F13A5800F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
References: <VI1PR08MB3421E4822599E75D997C7F37F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
 <VI1PR08MB3421F8AD4ADEC4D1F13A5800F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
Message-ID: <7C924A1F-1869-41B1-9FF0-8007A579F945@oracle.com>

Hi Xiaohong,

Thanks for making this change.

For future reference, you only need to send the RFR email for a JVMCI change in OpenJDK to hotspot-compiler-dev at openjdk.java.net (which I see you?ve done as well).

-Doug

> On 28 Aug 2019, at 03:54, Xiaohong Gong (Arm Technology China) <Xiaohong.Gong at arm.com> wrote:
> 
> Hi,
>  
>   Please help to review this jvmci patch:
>   Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/ <http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/>
>   JBS: https://bugs.openjdk.java.net/browse/JDK-8229797 <https://bugs.openjdk.java.net/browse/JDK-8229797>
>  
>   This patch fix issue: https://github.com/oracle/graal/issues/1587 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_issues_1587&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=HAIG1kZmXe7rRLHnK-WpdTHsQYhGOrQAZ6JHosxFLfs&s=emh-SS67iRljJ66ByQ9i_9LhSMM5kwcvc3P2YcjymyI&e=>.
>   The loading of new classes can cause dependencies to become false, which requires the dependent
> nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the
> result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException.
>   The invalid dependencies happen at the time of installation without any intervening modification of
> the system dictionary. So as the system dictionary modification optimization has been removed, the
> compiler can not know whether the failed dependencies are triggered by class reloading or not. It's
> better to use dependencies_failed to mark the result.
>  
> Thanks,
> Xiaohong Gong


From Alan.Bateman at oracle.com  Wed Aug 28 12:11:39 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2019 13:11:39 +0100
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
Message-ID: <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>

On 28/08/2019 10:58, Doug Simon wrote:
> Hi Gary,
>
> I?ve noticed the same thing myself and have not yet found a good solution. It would be nice to know what the definitive point is in VM startup after which JDWP debugging is ?on?. I?ve cc?ed Alan Bateman who may be able to offer some insight (or redirect to someone who can).
>
The debugger agent can accept or establish a connection to the debugger 
once the VM is initialized. In Thread::create_vm look for 
JvmtiExport::post_vm_initialized. So yes, some code will execute in 
initPhase1, initPhase2, and initPhase3 prior to this. Are you expecting 
JVMCI to be initialized and the Graal compiler to be invoked to compile 
this code? The VM can't load classes outside of java.base until module 
system is initialized in initPhase2 so I don't think a Graal compiler in 
Java can be used until after that. Maybe things change with libgraal. To 
support debugging of Java code that is executed before the live phase 
would require surgery in the JDWP agent and maybe additional support in 
JVM TI as many of the functions and events are only defined for the live 
phase.

-Alan



From doug.simon at oracle.com  Wed Aug 28 12:35:18 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 28 Aug 2019 14:35:18 +0200
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
Message-ID: <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>

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).

-Doug

> On 28 Aug 2019, at 14:11, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 28/08/2019 10:58, Doug Simon wrote:
>> Hi Gary,
>> 
>> I?ve noticed the same thing myself and have not yet found a good solution. It would be nice to know what the definitive point is in VM startup after which JDWP debugging is ?on?. I?ve cc?ed Alan Bateman who may be able to offer some insight (or redirect to someone who can).
>> 
> The debugger agent can accept or establish a connection to the debugger once the VM is initialized. In Thread::create_vm look for JvmtiExport::post_vm_initialized. So yes, some code will execute in initPhase1, initPhase2, and initPhase3 prior to this. Are you expecting JVMCI to be initialized and the Graal compiler to be invoked to compile this code? The VM can't load classes outside of java.base until module system is initialized in initPhase2 so I don't think a Graal compiler in Java can be used until after that. Maybe things change with libgraal. To support debugging of Java code that is executed before the live phase would require surgery in the JDWP agent and maybe additional support in JVM TI as many of the functions and events are only defined for the live phase.
> 
> -Alan
> 
> 


From Alan.Bateman at oracle.com  Wed Aug 28 13:08:33 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Aug 2019 14:08:33 +0100
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
 <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
Message-ID: <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>

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

From doug.simon at oracle.com  Wed Aug 28 13:33:43 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 28 Aug 2019 15:33:43 +0200
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
 <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
 <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
Message-ID: <F7A69F09-84ED-423C-B1BE-D77C613A2239@oracle.com>



> On 28 Aug 2019, at 15:08, 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.

The only solution available then is to use a native debugger (native-image compiled code does not support JVMTI).

In terms of developing/debugging Graal, the working assumption is that compiler errors should mostly be debuggable in jargraal mode. There?s also an effort underway to add compilation replay support to Graal to improve debugging support where compiler errors are only occurring in libgraal mode.

-Doug

From frost.gary at gmail.com  Wed Aug 28 13:37:42 2019
From: frost.gary at gmail.com (Gary Frost)
Date: Wed, 28 Aug 2019 14:37:42 +0100
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
 <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
 <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
Message-ID: <CA+VKHzbUWp7TfuO37TbT0FeiPUu-yzp0P9pDMJKh6OgbuSjg3w@mail.gmail.com>

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?

If so will it still allow Java plugins to be dynamically loaded?

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.

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
>

From doug.simon at oracle.com  Wed Aug 28 13:48:50 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 28 Aug 2019 15:48:50 +0200
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <CA+VKHzbUWp7TfuO37TbT0FeiPUu-yzp0P9pDMJKh6OgbuSjg3w@mail.gmail.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
 <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
 <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
 <CA+VKHzbUWp7TfuO37TbT0FeiPUu-yzp0P9pDMJKh6OgbuSjg3w@mail.gmail.com>
Message-ID: <3CD1D15E-B149-43B6-B497-992344FAC932@oracle.com>



> 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 <mailto: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


From frost.gary at gmail.com  Wed Aug 28 13:50:41 2019
From: frost.gary at gmail.com (Gary Frost)
Date: Wed, 28 Aug 2019 14:50:41 +0100
Subject: Accepting jdwp connection early enough to debug Graal startup
 with -Xcomp
In-Reply-To: <3CD1D15E-B149-43B6-B497-992344FAC932@oracle.com>
References: <CA+VKHzadqKDwBAAE5xr7dW4+OX68OqOdS8zzdnZg7fZ4yQjJ6A@mail.gmail.com>
 <D087E2FD-1A66-4A2A-B80F-24D329F07F25@oracle.com>
 <9d283a77-0aa5-4f36-209d-15b20fe54f39@oracle.com>
 <5D6E10DB-FC90-470A-ADC7-47582E11A64F@oracle.com>
 <5bb9f4a9-8935-4aa3-83da-0479b14d81ad@oracle.com>
 <CA+VKHzbUWp7TfuO37TbT0FeiPUu-yzp0P9pDMJKh6OgbuSjg3w@mail.gmail.com>
 <3CD1D15E-B149-43B6-B497-992344FAC932@oracle.com>
Message-ID: <CA+VKHzZi_xcn=6JH3jF3wC0ih1=bXV766mX5d+kOjfi-bdRrZw@mail.gmail.com>

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
>>
>
>

From dean.long at oracle.com  Wed Aug 28 16:51:21 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 28 Aug 2019 09:51:21 -0700
Subject: RFR: 8229797: [JVMCI] Clean up no longer used
 JVMCI::dependencies_invalid value.
In-Reply-To: <VI1PR08MB3421322B4C9C9544EB2F7291F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
References: <VI1PR08MB3421322B4C9C9544EB2F7291F5A30@VI1PR08MB3421.eurprd08.prod.outlook.com>
Message-ID: <a6e0b2bc-1160-f3d9-39bb-961f6aebc723@oracle.com>

Looks good.

dl

On 8/27/19 7:25 PM, Xiaohong Gong (Arm Technology China) wrote:
> Hi,
>
>    Please help to review this jvmci patch:
>    Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8229797
>
>    This patch fix issue: https://github.com/oracle/graal/issues/1587.
>    The loading of new classes can cause dependencies to become false, which requires the dependent
> nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the
> result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException.
>    The invalid dependencies happen at the time of installation without any intervening modification of
> the system dictionary. So as the system dictionary modification optimization has been removed, the
> compiler can not know whether the failed dependencies are triggered by class reloading or not. It's
> better to use dependencies_failed to mark the result.
>
> Thanks,
> Xiaohong Gong


From dean.long at oracle.com  Thu Aug 29 23:40:24 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 29 Aug 2019 16:40:24 -0700
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
Message-ID: <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>

Isn't it the correct process that there should be a master bug for 
fixing the test or underlying issue, then use that bug number for the 
problem list entry, and push it using a SubTask.? For example, see the 
relationship between JDK-8229447 and JDK-8229446 as an example.

dl

On 8/27/19 12:14 AM, Xiaohong Gong (Arm Technology China) wrote:
> Hi,
>
>    Please help to review this small patch:
>    Webrew: http://cr.openjdk.java.net/~pli/rfr/8230129/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8230129
>
>    Jtreg test "serviceability/sa/ClhsdbInspect.java" fails when running with Graal. It fails when inspecting an address to check whether it's pointing to an expected oop
> or method, which is printed by running "jstack -v" firstly.
>    When running with graal, it needs more java heap for the JVMCI initialization and the compiler working. So it's inevitable to make GC happen during the application
> running. If GC happens after runnning "jstack", the actual address of the oops and methods may be different when running "inpsect". And the address inspected may
> point to other object or nothing.
>    A simple fix is to add this test to the graal problem list.
>
> Thanks,
> Xiaohong Gong