Finally ;)
On 9/19/17 5:56 AM, Jaroslav Tulach wrote:
On pátek 15. září 2017 10:53:45 CEST mandy chung wrote:
> http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html
Looks good.
Great. Unless there are further comments, then we can plan integration of my
changes. Vladimir, are y
On pátek 15. září 2017 10:53:45 CEST mandy chung wrote:
> > http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html
>
> Looks good.
Great. Unless there are further comments, then we can plan integration of my
changes. Vladimir, are you "sponsor" of my change? Will you integrate it
som
On 9/15/17 5:47 AM, Doug Simon wrote:
I don't think I can. There is no way to get to HotspotGraalRuntime except
asking the HotSpotGraalCompiler. The HotspotGraalRuntime isn't JVMCIRuntime...
At least I think so
That is correct - you have to obtain a HotspotGraalRuntime from a
HotSpotGraalComp
> On 15 Sep 2017, at 14:32, Jaroslav Tulach wrote:
>
> Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10
> repository is available, I have updated my webrev to its structure. In
> addition to that I addressed your comments:
>
> On úterý 12. září 2017 11:19:45 CEST mandy ch
Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10
repository is available, I have updated my webrev to its structure. In
addition to that I addressed your comments:
On úterý 12. září 2017 11:19:45 CEST mandy chung wrote:
> ./make/common/Modules.gmk
> Nit: can you move jd
On 9/13/17 2:28 AM, Daniel Fuchs wrote:
Hi Jaroslav,
GraalMBeans.java:
77 @Override
78 public Set mbeanInterfaceNames() {
79 return Collections.singleton(name);
80 }
Good catch, Daniel. This should return empty set as mbeanInterfaces()
returns.
Hi Jaroslav,
GraalMBeans.java:
77 @Override
78 public Set mbeanInterfaceNames() {
79 return Collections.singleton(name);
80 }
This is not correct. The return set should be a set of
MXBean interface names, as in Class.getName(), not a set
of MXBean Obj
On 9/12/17 10:44 AM, Jaroslav Tulach wrote:
Dear reviewers,
after several reconsiderations I have webrev #4 ready for your review. Can you
please take a look at
http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/
and let me know if it is in a reasonable shape? Thanks a lot.
-jt
Yes defin
Dear reviewers,
after several reconsiderations I have webrev #4 ready for your review. Can you
please take a look at
http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/
and let me know if it is in a reasonable shape? Thanks a lot.
-jt
On 8/22/17 6:19 AM, Jaroslav Tulach wrote:
Thanks for your comments, Mandy.
On pondělí 21. srpna 2017 12:42:09 CEST mandy chung wrote:
cc'ing serviceability-dev which is the right mailing list for platform
management discussion.
JVMCI is currently named as `jdk.internal.vm.ci` (a JDK interna
Thanks for your comments, Mandy.
On pondělí 21. srpna 2017 12:42:09 CEST mandy chung wrote:
> cc'ing serviceability-dev which is the right mailing list for platform
> management discussion.
>
> JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal
> module). I suppose this new module
cc'ing serviceability-dev which is the right mailing list for platform
management discussion.
JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal
module). I suppose this new module is intended to be kept as an
internal module?
30 * @since 9
should be @since 10.
JVMCIMBean
> On 21 Aug 2017, at 10:48, Jaroslav Tulach wrote:
>
> Hello Doug & co.,
> I think your comments are about the old webrev. I hope most of them have been
> (by a chance) addressed in the newest webrev 01:
Indeed they are. Sorry again for missing the latest link when do the review ;-)
-Doug
Hello Doug & co.,
I think your comments are about the old webrev. I hope most of them have been
(by a chance) addressed in the newest webrev 01:
http://cr.openjdk.java.net/~kvn/8182701/webrev.01/
On pátek 18. srpna 2017 21:11:28 CEST Doug Simon wrote:
> I don't think JVMCIMXBeans should be in th
Hi Jaroslav,
In general, thanks for pushing through with this change.
I don't think JVMCIMXBeans should be in the hotspot-agnostic
jdk.vm.ci.services.internal package since it has a direct reference to
HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot.
In HotSpotJVMCRuntime.j
Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/
On 8/18/17 7:12 AM, Jaroslav Tulach wrote:
Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if
we want the Graal compiler to expose its MBean in a lazy way. I am offering
new webrev for rev
Hi Jaroslav,
What we should do with 8182701? Do you still need JVMCI changes?
Note, your changes to Graal [GR-5435] were integrated recently into JDK
(jdk10/hs):
https://bugs.openjdk.java.net/browse/JDK-8186158
Thanks,
Vladimir
On 8/14/17 10:06 AM, Jaroslav Tulach wrote:
On čtvrtek 3. srpna
On čtvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote:
> On čtvrtek 27. července 2017 15:01:17 CEST Alan Bateman wrote:
> > On 27/07/2017 10:07, Jaroslav Tulach wrote:
> > > Yes, it seems like a desirable goal to let Graal compiler work with just
> > > java.base. Is there a description how t
On čtvrtek 27. července 2017 15:01:17 CEST Alan Bateman wrote:
> On 27/07/2017 10:07, Jaroslav Tulach wrote:
> > Yes, it seems like a desirable goal to let Graal compiler work with just
> > java.base. Is there a description how to build JDK9/10 with just java.base
> > that I could follow and test a
> On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach
> wrote:
>
>> This is Graal-specific MBean. It doesn’t seem that it must be registered as
>> “platform mbean” which has to implement PlatformManagedObject.
>>
>> Graal can register the MBean at runtime when java.management is present by
>> calling
> This is Graal-specific MBean. It doesn’t seem that it must be registered as
> “platform mbean” which has to implement PlatformManagedObject.
>
> Graal can register the MBean at runtime when java.management is present by
> calling ManagementFactory.getPlatformMBeanServer().registerMBean method.
> On Jul 27, 2017, at 2:07 AM, Jaroslav Tulach
> wrote:
>
>> One consideration might be to separate the JVMCI MBean provider in its own
>> module so that it’s registered only when such module is resolved in the
>> module graph. This way JVMCI can work even if java.management is not
>> present.
On 27/07/2017 10:07, Jaroslav Tulach wrote:
:
Yes, it seems like a desirable goal to let Graal compiler work with just
java.base. Is there a description how to build JDK9/10 with just java.base
that I could follow and test against?
You can use jlink to create a run-time image that only contains
Thanks for your review Mandy.
>> Mandy Chung : 25.07.17 @ 11:39 <<
> > On Jul 25, 2017, at 1:33 AM, Doug Simon wrote:
> >> On 25 Jul 2017, at 01:37, Mandy Chung wrote:
> >>
> >> Vladimir,
> >>
> >> I believe you don’t want to add the dependency from JVMCI to
> >> java.management. Otherwise,
> On Jul 25, 2017, at 1:33 AM, Doug Simon wrote:
>
>
>> On 25 Jul 2017, at 01:37, Mandy Chung wrote:
>>
>> Vladimir,
>>
>> I believe you don’t want to add the dependency from JVMCI to
>> java.management. Otherwise, JVMCI can’t run with only java.base.
>
> The dependency is unfortunate. Ca
> On 25 Jul 2017, at 01:37, Mandy Chung wrote:
>
> Vladimir,
>
> I believe you don’t want to add the dependency from JVMCI to java.management.
> Otherwise, JVMCI can’t run with only java.base.
The dependency is unfortunate. Can you suggest how JVMCI platform beans could
participate in platf
Vladimir,
I believe you don’t want to add the dependency from JVMCI to java.management.
Otherwise, JVMCI can’t run with only java.base. Is the MBean in
jdk.internal.vm.compiler or in Lab’s Graal compiler?
src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/services/internal/
On 12/07/2017 22:20, Vladimir Kozlov wrote:
https://bugs.openjdk.java.net/browse/JDK-8182701
webrev:
http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
Contributed by Jaroslav Tulach.
JDK itself contains quite a lot of platform MBeans which ge
https://bugs.openjdk.java.net/browse/JDK-8182701
webrev:
http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
Contributed by Jaroslav Tulach.
JDK itself contains quite a lot of platform MBeans which get registered "on demand". Graal compiler (jdk
29 matches
Mail list logo
