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.java:
558 public String mbeanName() {
568 public Object mbean() {
Any reason these methods don't follow the conventions of other getter methods
in this class (i.e. getMBeanName() and getMBean())?
95 /** Name of the {@link MBeanInfo MBean} representing the internals
This should be:
/**
* Gets the name of the ...
Same comment for mbean() method. Also {@code null} is used in JVMCI instead of
<code>null</code>.
-Doug
> On 18 Aug 2017, at 20:49, Vladimir Kozlov <vladimir.koz...@oracle.com> wrote:
>
> 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 review. It contains following changes:
>
> Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge
> between
> JVMCI and jdk.management. Adding new module was a bit tricky, but with great
> help of Jan
> Lahoda I even managed to register it as a boot module.
>
> I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I fixed
> the non-standard location of JVMCIMXBean class.
>
> I changed the interface to use Map, so the compiler is able to expose more
> than a single bean.
>
> That's it. I am looking forward to your review comments.
> -jt
>
> Here are original changes for reference:
>
> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
>
> On 8/17/17 11:54 AM, Vladimir Kozlov wrote:
>> 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 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 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
>>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base
>>>>> --output smalljre).
>>>>
>>>> Status update: I've just tried to run Graal compiler against JDK9 with only
>>>> java.base and jdk.internal.vm.ci modules, and there are some problems. I
>>>> need to resolve them first before I provide updated version of my patch.
>>>
>>> FYI: As of
>>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0
>>> the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci
>>> only
>>> modules. But it wasn't easy, especially the
>>> http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of
>>> work.
>>>
>>> -jt
>>>
>>>
