Re: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl

2016-05-10 Thread Mandy Chung 

> On May 10, 2016, at 1:03 PM, Alexandre (Shura) Iline 
>  wrote:
> 
> OK, I will do that, Mandy.
> 
> Should I create a separate bug (subtask) for this test fixes?


Create a new bug is good.  Send me a committed changeset and I can push it for 
you.

Mandy

Re: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl

2016-05-10 Thread Alexandre (Shura) Iline 
OK, I will do that, Mandy.

Should I create a separate bug (subtask) for this test fixes?

Shura

> On May 10, 2016, at 12:49 PM, Mandy Chung  wrote:
> 
> 
>> On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline 
>>  wrote:
>> 
>> Hi.
>> 
>> Please review the fix:
>> http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/
>> 
>> In the failing tests I have replaced java.management with jdk.management in 
>> @modules.
>> 
>> Besides the failed tests I have scanned all the tests which call 
>> ManagementFactory.getPlatformMBeanServer(…). Those which were not failing 
>> were already declaring dependency on jdk.management, sometimes together with 
>> java.management. Declaring java.management in such case is not needed, 
>> because java.management is a dependency of jdk.management.
> 
> In fact JDK-8155993 reveals a potential bug in the VM support for 
> java.lang.management when jdk.management module is not present.
> 
> I have no objection to change these tests to run with jdk.management and this 
> patch looks fine.  But we should keep JDK-8155993  open and provide a small 
> test to reproduce NCDFE when running with an image with only java.management 
> but no jdk.management module.
> 
> Mandy
>

Re: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl

2016-05-10 Thread Mandy Chung 

> On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline 
>  wrote:
> 
> Hi.
> 
> Please review the fix:
> http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/
> 
> In the failing tests I have replaced java.management with jdk.management in 
> @modules.
> 
> Besides the failed tests I have scanned all the tests which call 
> ManagementFactory.getPlatformMBeanServer(…). Those which were not failing 
> were already declaring dependency on jdk.management, sometimes together with 
> java.management. Declaring java.management in such case is not needed, 
> because java.management is a dependency of jdk.management.

In fact JDK-8155993 reveals a potential bug in the VM support for 
java.lang.management when jdk.management module is not present.

I have no objection to change these tests to run with jdk.management and this 
patch looks fine.  But we should keep JDK-8155993  open and provide a small 
test to reproduce NCDFE when running with an image with only java.management 
but no jdk.management module.

Mandy

RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl

2016-05-10 Thread Alexandre (Shura) Iline 
Hi.

Please review the fix:
http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/

In the failing tests I have replaced java.management with jdk.management in 
@modules.

Besides the failed tests I have scanned all the tests which call 
ManagementFactory.getPlatformMBeanServer(…). Those which were not failing were 
already declaring dependency on jdk.management, sometimes together with 
java.management. Declaring java.management in such case is not needed, because 
java.management is a dependency of jdk.management.

Shura

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

2016-05-10 Thread Alan Bateman 

On 09/05/2016 18:41, Jim Laskey (Oracle) wrote:

Modifies the jlink sort-plugin to accept a classlist to order files in the 
jimage.

http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8155237

I also see improvements with cold start so I think this is good and we 
should update the jlink usage in /make/Images.gmk to specify 
--order-resources.


One thing about this is that the argument to the plugin is ambiguous, it 
would be better if there were some way to make it clear whether the 
value is a file or class names/pattern. I just wonder if the file name 
should use @file instead. Related is that value of 
order-resources.description should probably be updated to document the 
file name approach too.


Style wise then you've mixed old and new I/O which seems unnecessary. 
There are a few other cleanups that could be done in this plugin but 
maybe for a cleanup round at some point.


-Alan

Re: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input

2016-05-10 Thread Claes Redestad 

Hi,

this looks good.

Testing cold[1] startup on my machine I see an improvement ranging from 
around 30-40ms on a minimal test to around 60-80ms on a larger app. Warm 
startup and footprint measures seem largely unaffected, as would be 
expected.


I also did an experiment with allowing secondary ordering in the plugin 
so that java.base could be ordered directly after the classlist-ordered 
resources but impact got lost in the noise, so it doesn't seem 
worthwhile to complicate things further.


Thanks!

/Claes

[1] simulated by calling echo 3 > /proc/sys/vm/drop_caches between runs

On 2016-05-09 19:41, Jim Laskey (Oracle) wrote:

Modifies the jlink sort-plugin to accept a classlist to order files in the 
jimage.

http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8155237

Re: RFR [9] 8153737: Unsupported Module

2016-05-10 Thread Chris Hegarty 

On 9 May 2016, at 20:43, Richard Opalka  wrote:

> Fixed in JBoss Marshalling upstream.

Thanks for fixing this, and getting back to us on the list.

I assume then that, at least, this part of JBoss is working on JDK 9 b115, 
right?

-Chris.

> Thanks,
> 
> Rio
> 
> On 04/27/2016 11:54 PM, Chris Hegarty wrote:
>> Hi Rio,
>> 
>> 
>>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction 
>>> inner class
>>> 
>>> in jdk.unsupported module:
>>> 
>>> java.lang.NoClassDefFoundError: 
>>> sun/reflect/ReflectionFactory$GetReflectionFactoryAction
>>>at 
>>> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-internal/BuiltinClassLoader.java:366)
>>>at 
>>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-internal/ClassLoaders.java:184)
>>>at 
>>> java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
>>>at 
>>> org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47)
>> GetReflectionFactoryAction is a convenience class for acquiring
>> the capability to instantiate reflective objects.
>> 
>> As part of JEP 260, we retained the single getReflectionFactory
>> accessor. You can replace your usage with the following:
>> 
>>  PrivilegedAction pa = new 
>> PrivilegedAction() {
>>@Override
>>public ReflectionFactory run() {
>>return ReflectionFactory.getReflectionFactory();
>>}
>>};
>> 
>> -Chris.
>> 
>