From chenyt at cs.sjtu.edu.cn  Fri Jan  1 12:22:41 2016
From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=)
Date: Fri, 1 Jan 2016 20:22:41 +0800
Subject: A class is accessable from another?
Message-ID: <95D2590FC461438995FF4205BD8D801F@sjtu.edu.cn>

Hello, everyone. I created a class M1450648087 using soot, while the class 
is
executable on some JVMs but not on HotSpot releases:
(1) When the class is tested on IBM's J9 or GIJ, it is executable (i.e., 
"Executed!"
is printed out);
(2) When the class is tested using OpenJDK for Java7/8, it says
"java.lang.IllegalAccessError: tried to access class 
java.lang.AbstractStringBuilder
from class M1450648087"  (the run() method throws 
java.lang.AbstractStringBuilder );
(3) When the class is tested using OpenJDK for Java9, it says 
"java.lang.VerifyError:
Bad type on operand stack ...Type 
'sun/java2d/loops/GraphicsPrimitive$TraceReporter'
(current frame, stack[1]) is not assignable to 'java/lang/Thread' ".
(caused by run()...17: invokevirtual #10                 // Method 
java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V)

My problem is:
(1) Where can I find any reference about whether one class is accessable
from another? Why is the class java.lang.AbstractStringBuilder accessable 
from
M1450648087 when running on J9 but not accessable
when on HotSpot releases?

(2) When can one class be assignable to another? I cannot find any
materials about this. I guess HotSpot for Java9 rejects the assignment
by taking some new rules. Where can I find these rules?

Yuting
*************************************************************************************************************
The decompiled code is given as follows.

javap -verbose M1450648087.class
class M1450648087
  minor version: 0
  major version: 51
  flags: ACC_SUPER
Constant pool:
   #1 = Utf8               Executed!
   #2 = Utf8               ()V
   #3 = Utf8               main
   #4 = String             #1             // Executed!
   #5 = Utf8               java/lang/Object
   #6 = Utf8               java/lang/AbstractStringBuilder
   #7 = Class              #5             // java/lang/Object
   #8 = Methodref          #24.#35        // 
java/io/PrintStream.println:(Ljava/lang/String;)V
   #9 = Utf8               ()Ljava/lang/Runtime;
  #10 = Methodref          #45.#11        // 
java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V
  #11 = NameAndType        #47:#26        // 
addShutdownHook:(Ljava/lang/Thread;)V
  #12 = Utf8               java/lang/System
  #13 = Class              #6             // java/lang/AbstractStringBuilder
  #14 = Class              #12            // java/lang/System
  #15 = Utf8               ()Ljava/lang/Object;
  #16 = Utf8               M1450648087
  #17 = Utf8               sun/java2d/loops/GraphicsPrimitive$TraceReporter
  #18 = Methodref          #41.#29        // 
sun/java2d/loops/GraphicsPrimitive$TraceReporter.setContextClassLoader:(Ljava/lang/ClassLoader;)V
  #19 = Utf8               run
  #20 = Methodref          #41.#23        // 
sun/java2d/loops/GraphicsPrimitive$TraceReporter."<init>":()V
  #21 = Utf8               ([Ljava/lang/String;)V
  #22 = Class              #16            // M1450648087
  #23 = NameAndType        #30:#2         // "<init>":()V
  #24 = Class              #44            // java/io/PrintStream
  #25 = Utf8               Exceptions
  #26 = Utf8               (Ljava/lang/Thread;)V
  #27 = Utf8               SourceFile
  #28 = Utf8               println
  #29 = NameAndType        #48:#49        // 
setContextClassLoader:(Ljava/lang/ClassLoader;)V
  #30 = Utf8               <init>
  #31 = NameAndType        #32:#46        // out:Ljava/io/PrintStream;
  #32 = Utf8               out
  #33 = NameAndType        #38:#9         // 
getRuntime:()Ljava/lang/Runtime;
  #34 = Methodref          #7.#23         // java/lang/Object."<init>":()V
  #35 = NameAndType        #28:#42        // println:(Ljava/lang/String;)V
  #36 = Methodref          #45.#33        // 
java/lang/Runtime.getRuntime:()Ljava/lang/Runtime;
  #37 = Utf8               Jasmin
  #38 = Utf8               getRuntime
  #39 = Utf8               java/lang/Runtime
  #40 = Fieldref           #14.#31        // 
java/lang/System.out:Ljava/io/PrintStream;
  #41 = Class              #17            // 
sun/java2d/loops/GraphicsPrimitive$TraceReporter
  #42 = Utf8               (Ljava/lang/String;)V
  #43 = Utf8               Code
  #44 = Utf8               java/io/PrintStream
  #45 = Class              #39            // java/lang/Runtime
  #46 = Utf8               Ljava/io/PrintStream;
  #47 = Utf8               addShutdownHook
  #48 = Utf8               setContextClassLoader
  #49 = Utf8               (Ljava/lang/ClassLoader;)V
{
  M1450648087();
    descriptor: ()V
    flags:
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #34                 // Method 
java/lang/Object."<init>":()V
         4: return

  public java.lang.Object run() throws java.lang.AbstractStringBuilder;
    descriptor: ()Ljava/lang/Object;
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: new           #41                 // class 
sun/java2d/loops/GraphicsPrimitive$TraceReporter
         3: dup
         4: invokespecial #20                 // Method 
sun/java2d/loops/GraphicsPrimitive$TraceReporter."<init>":()V
         7: astore_0
         8: aload_0
         9: aconst_null
        10: invokevirtual #18                 // Method 
sun/java2d/loops/GraphicsPrimitive$TraceReporter.setContextClassLoader:(Ljava/lang/ClassLoader;)V
        13: invokestatic  #36                 // Method 
java/lang/Runtime.getRuntime:()Ljava/lang/Runtime;
        16: aload_0
        17: invokevirtual #10                 // Method 
java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V
        20: aconst_null
        21: areturn
    Exceptions:
      throws java.lang.AbstractStringBuilder

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #40                 // Field 
java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #4                  // String Executed!
         5: invokevirtual #8                  // Method 
java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
} 


From diamonds4shelz at gmail.com  Sat Jan  2 22:52:12 2016
From: diamonds4shelz at gmail.com (Shelly Taylor)
Date: Sat, 2 Jan 2016 17:52:12 -0500
Subject: Hot spot list 
Message-ID: <4E2F613E-3EBE-459E-A31D-37BB810FE5A2@gmail.com>

Thank you 

Sent from my iPhone

From ioi.lam at oracle.com  Sun Jan  3 08:11:27 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 03 Jan 2016 00:11:27 -0800
Subject: A class is accessable from another?
In-Reply-To: <95D2590FC461438995FF4205BD8D801F@sjtu.edu.cn>
References: <95D2590FC461438995FF4205BD8D801F@sjtu.edu.cn>
Message-ID: <5688D7AF.6060309@oracle.com>

The two exceptions that you see here are related to the internal 
implementation of the OpenJDK:

Case 1: For JDK 7/8, the exception happened here:

Exception in thread "main" java.lang.IllegalAccessError: tried to access 
class java.lang.AbstractStringBuilder from class M1450648087
     at java.lang.Class.getDeclaredMethods0(Native Method)
     at java.lang.Class.privateGetDeclaredMethods(Class.java:2688)
     at java.lang.Class.getMethod0(Class.java:2937)
     at java.lang.Class.getMethod(Class.java:1771)
     at 
sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
     at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

Note that java.lang.AbstractStringBuilder is an internal, non-public 
class and it's inaccessible by class M1450648087.

This exception happens only when the Java launcher looks up the "main" 
method. If you put the "throws AbstractStringBuilder" in any other 
methods, the JVM will not complain (see 
https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf, 4.7.5 The 
Exceptions Attribute). So it's quite plausible that the J9 launcher does 
something different than the sun.launcher and avoids the exception.

Case 2: In JDK8, the internal class GraphicsPrimitive$TraceReporter was 
a subclass of Thread. In JDK9, this class has been changed to "implement 
Runnable". Hence it's no longer assignable to Thread. You can read more 
about the Verifier in the JVM Spec link posted above.


In both cases, your code is accessing an internal JDK class, so the 
behavior may change in different JDK releases, even if there are no spec 
changes.


Thanks
- Ioi


On 1/1/16 4:22 AM, ??? wrote:
> Hello, everyone. I created a class M1450648087 using soot, while the 
> class is
> executable on some JVMs but not on HotSpot releases:
> (1) When the class is tested on IBM's J9 or GIJ, it is executable 
> (i.e., "Executed!"
> is printed out);
> (2) When the class is tested using OpenJDK for Java7/8, it says
> "java.lang.IllegalAccessError: tried to access class 
> java.lang.AbstractStringBuilder
> from class M1450648087"  (the run() method throws 
> java.lang.AbstractStringBuilder );
> (3) When the class is tested using OpenJDK for Java9, it says 
> "java.lang.VerifyError:
> Bad type on operand stack ...Type 
> 'sun/java2d/loops/GraphicsPrimitive$TraceReporter'
> (current frame, stack[1]) is not assignable to 'java/lang/Thread' ".
> (caused by run()...17: invokevirtual #10 // Method 
> java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V)
>
> My problem is:
> (1) Where can I find any reference about whether one class is accessable
> from another? Why is the class java.lang.AbstractStringBuilder 
> accessable from
> M1450648087 when running on J9 but not accessable
> when on HotSpot releases?
>
> (2) When can one class be assignable to another? I cannot find any
> materials about this. I guess HotSpot for Java9 rejects the assignment
> by taking some new rules. Where can I find these rules?
>
> Yuting
> ************************************************************************************************************* 
>
> The decompiled code is given as follows.
>
> javap -verbose M1450648087.class
> class M1450648087
>  minor version: 0
>  major version: 51
>  flags: ACC_SUPER
> Constant pool:
>   #1 = Utf8               Executed!
>   #2 = Utf8               ()V
>   #3 = Utf8               main
>   #4 = String             #1             // Executed!
>   #5 = Utf8               java/lang/Object
>   #6 = Utf8               java/lang/AbstractStringBuilder
>   #7 = Class              #5             // java/lang/Object
>   #8 = Methodref          #24.#35        // 
> java/io/PrintStream.println:(Ljava/lang/String;)V
>   #9 = Utf8               ()Ljava/lang/Runtime;
>  #10 = Methodref          #45.#11        // 
> java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V
>  #11 = NameAndType        #47:#26        // 
> addShutdownHook:(Ljava/lang/Thread;)V
>  #12 = Utf8               java/lang/System
>  #13 = Class              #6             // 
> java/lang/AbstractStringBuilder
>  #14 = Class              #12            // java/lang/System
>  #15 = Utf8               ()Ljava/lang/Object;
>  #16 = Utf8               M1450648087
>  #17 = Utf8 sun/java2d/loops/GraphicsPrimitive$TraceReporter
>  #18 = Methodref          #41.#29        // 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter.setContextClassLoader:(Ljava/lang/ClassLoader;)V
>  #19 = Utf8               run
>  #20 = Methodref          #41.#23        // 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter."<init>":()V
>  #21 = Utf8               ([Ljava/lang/String;)V
>  #22 = Class              #16            // M1450648087
>  #23 = NameAndType        #30:#2         // "<init>":()V
>  #24 = Class              #44            // java/io/PrintStream
>  #25 = Utf8               Exceptions
>  #26 = Utf8               (Ljava/lang/Thread;)V
>  #27 = Utf8               SourceFile
>  #28 = Utf8               println
>  #29 = NameAndType        #48:#49        // 
> setContextClassLoader:(Ljava/lang/ClassLoader;)V
>  #30 = Utf8               <init>
>  #31 = NameAndType        #32:#46        // out:Ljava/io/PrintStream;
>  #32 = Utf8               out
>  #33 = NameAndType        #38:#9         // 
> getRuntime:()Ljava/lang/Runtime;
>  #34 = Methodref          #7.#23         // java/lang/Object."<init>":()V
>  #35 = NameAndType        #28:#42        // println:(Ljava/lang/String;)V
>  #36 = Methodref          #45.#33        // 
> java/lang/Runtime.getRuntime:()Ljava/lang/Runtime;
>  #37 = Utf8               Jasmin
>  #38 = Utf8               getRuntime
>  #39 = Utf8               java/lang/Runtime
>  #40 = Fieldref           #14.#31        // 
> java/lang/System.out:Ljava/io/PrintStream;
>  #41 = Class              #17            // 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter
>  #42 = Utf8               (Ljava/lang/String;)V
>  #43 = Utf8               Code
>  #44 = Utf8               java/io/PrintStream
>  #45 = Class              #39            // java/lang/Runtime
>  #46 = Utf8               Ljava/io/PrintStream;
>  #47 = Utf8               addShutdownHook
>  #48 = Utf8               setContextClassLoader
>  #49 = Utf8               (Ljava/lang/ClassLoader;)V
> {
>  M1450648087();
>    descriptor: ()V
>    flags:
>    Code:
>      stack=1, locals=1, args_size=1
>         0: aload_0
>         1: invokespecial #34                 // Method 
> java/lang/Object."<init>":()V
>         4: return
>
>  public java.lang.Object run() throws java.lang.AbstractStringBuilder;
>    descriptor: ()Ljava/lang/Object;
>    flags: ACC_PUBLIC
>    Code:
>      stack=2, locals=1, args_size=1
>         0: new           #41                 // class 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter
>         3: dup
>         4: invokespecial #20                 // Method 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter."<init>":()V
>         7: astore_0
>         8: aload_0
>         9: aconst_null
>        10: invokevirtual #18                 // Method 
> sun/java2d/loops/GraphicsPrimitive$TraceReporter.setContextClassLoader:(Ljava/lang/ClassLoader;)V
>        13: invokestatic  #36                 // Method 
> java/lang/Runtime.getRuntime:()Ljava/lang/Runtime;
>        16: aload_0
>        17: invokevirtual #10                 // Method 
> java/lang/Runtime.addShutdownHook:(Ljava/lang/Thread;)V
>        20: aconst_null
>        21: areturn
>    Exceptions:
>      throws java.lang.AbstractStringBuilder
>
>  public static void main(java.lang.String[]);
>    descriptor: ([Ljava/lang/String;)V
>    flags: ACC_PUBLIC, ACC_STATIC
>    Code:
>      stack=2, locals=1, args_size=1
>         0: getstatic     #40                 // Field 
> java/lang/System.out:Ljava/io/PrintStream;
>         3: ldc           #4                  // String Executed!
>         5: invokevirtual #8                  // Method 
> java/io/PrintStream.println:(Ljava/lang/String;)V
>         8: return
> }


From chenyt at cs.sjtu.edu.cn  Sun Jan  3 08:20:14 2016
From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=)
Date: Sun, 3 Jan 2016 16:20:14 +0800
Subject: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
Message-ID: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>

Dear all,

I used soot to create the class M1450550406 (see next).
HotSpot for Java7 says that M1450550406 cannot access
the superinterface sun.nio.ch.SelChImpl, while HotSpot
for Java8/9 and J9 for Java8 can access. Could anyone tell
me the reason? I checked the package and believed
that  the interface is in the JRE libraries.

Yuting
**************************************************************
public class M1450550406 extends java.lang.Object implements 
sun.nio.ch.SelChImpl
{

    public static void main(java.lang.String[])
    {
        java.lang.String[] r0;
        java.io.PrintStream $r1;

        r0 := @parameter0: java.lang.String[];
        $r1 = <java.lang.System: java.io.PrintStream out>;
        virtualinvoke $r1.<java.io.PrintStream: void 
println(java.lang.String)>("Executed!");
        return;
    }
}



From chenyt at cs.sjtu.edu.cn  Sun Jan  3 08:28:55 2016
From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=)
Date: Sun, 3 Jan 2016 16:28:55 +0800
Subject: A class is accessable from another?
Message-ID: <F8EB6355C3A7481EA6DFD6819CFC5DAF@sjtu.edu.cn>

Dear all,
The next shows the Jimple file I created. The two lines that
make troubles are:
(1) public java.lang.Object run() throws java.lang.AbstractStringBuilder
(2) virtualinvoke $r3.<java.lang.Runtime: void 
addShutdownHook(java.lang.Thread)>(r2);

Yuting

class M1450648087 extends java.lang.Object
{
    public java.lang.Object run() throws java.lang.AbstractStringBuilder
    {
        sun.java2d.loops.GraphicsPrimitive$TraceReporter$1 r0;
        sun.java2d.loops.GraphicsPrimitive$TraceReporter $r1, r2;
        java.lang.Runtime $r3;

        r0 := @this: sun.java2d.loops.GraphicsPrimitive$TraceReporter$1;
        $r1 = new sun.java2d.loops.GraphicsPrimitive$TraceReporter;
        specialinvoke $r1.<sun.java2d.loops.GraphicsPrimitive$TraceReporter: 
void <init>()>();
        r2 = $r1;
        virtualinvoke r2.<sun.java2d.loops.GraphicsPrimitive$TraceReporter: 
void setContextClassLoader(java.lang.ClassLoader)>(null);
        $r3 = staticinvoke <java.lang.Runtime: java.lang.Runtime 
getRuntime()>();
        virtualinvoke $r3.<java.lang.Runtime: void 
addShutdownHook(java.lang.Thread)>(r2);
        return null;
    }

    public static void main(java.lang.String[])
    {
        java.lang.String[] r0;
        java.io.PrintStream $r1;

        r0 := @parameter0: java.lang.String[];
        $r1 = <java.lang.System: java.io.PrintStream out>;
        virtualinvoke $r1.<java.io.PrintStream: void 
println(java.lang.String)>("Executed!");
        return;
    }
} 


From Alan.Bateman at oracle.com  Sun Jan  3 08:30:36 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 3 Jan 2016 08:30:36 +0000
Subject: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
In-Reply-To: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>
References: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>
Message-ID: <5688DC2C.8040104@oracle.com>

On 03/01/2016 08:20, ??? wrote:
> Dear all,
>
> I used soot to create the class M1450550406 (see next).
> HotSpot for Java7 says that M1450550406 cannot access
> the superinterface sun.nio.ch.SelChImpl, while HotSpot
> for Java8/9 and J9 for Java8 can access. Could anyone tell
> me the reason? I checked the package and believed
> that  the interface is in the JRE libraries.
>
sun.nio.ch.SelChImpl is a JDK-internal class, it was package-private in 
JDK 7 but was changed to public in JDK 8.

-Alan

From chenyt at cs.sjtu.edu.cn  Sun Jan  3 08:43:31 2016
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Sun, 3 Jan 2016 16:43:31 +0800
Subject: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
In-Reply-To: <5688DC2C.8040104@oracle.com>
References: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>
	<5688DC2C.8040104@oracle.com>
Message-ID: <EAF99C6363A04209AA19CE1AEF050804@sjtu.edu.cn>

Thank you, Alan. I went through the source and got it.

Yuting

-----Original Message----- 
From: Alan Bateman
Sent: Sunday, January 03, 2016 4:30 PM
To: ??? ; hotspot-runtime-dev at openjdk.java.net
Subject: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for 
Java7?

On 03/01/2016 08:20, ??? wrote:
> Dear all,
>
> I used soot to create the class M1450550406 (see next).
> HotSpot for Java7 says that M1450550406 cannot access
> the superinterface sun.nio.ch.SelChImpl, while HotSpot
> for Java8/9 and J9 for Java8 can access. Could anyone tell
> me the reason? I checked the package and believed
> that  the interface is in the JRE libraries.
>
sun.nio.ch.SelChImpl is a JDK-internal class, it was package-private in
JDK 7 but was changed to public in JDK 8.

-Alan 


From forax at univ-mlv.fr  Sun Jan  3 10:33:12 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 3 Jan 2016 11:33:12 +0100 (CET)
Subject: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
In-Reply-To: <EAF99C6363A04209AA19CE1AEF050804@sjtu.edu.cn>
References: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>
	<5688DC2C.8040104@oracle.com>
	<EAF99C6363A04209AA19CE1AEF050804@sjtu.edu.cn>
Message-ID: <62105939.473338.1451817192470.JavaMail.zimbra@u-pem.fr>

And obviously because the class starts with sun.*,
this class is not accessible anymore in JDK 9 (with modules).

R?mi 

----- Mail original -----
> De: "???" <chenyt at cs.sjtu.edu.cn>
> ?: hotspot-runtime-dev at openjdk.java.net, "Alan Bateman" <Alan.Bateman at oracle.com>
> Envoy?: Dimanche 3 Janvier 2016 09:43:31
> Objet: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
> 
> Thank you, Alan. I went through the source and got it.
> 
> Yuting
> 
> -----Original Message-----
> From: Alan Bateman
> Sent: Sunday, January 03, 2016 4:30 PM
> To: ??? ; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for
> Java7?
> 
> On 03/01/2016 08:20, ??? wrote:
> > Dear all,
> >
> > I used soot to create the class M1450550406 (see next).
> > HotSpot for Java7 says that M1450550406 cannot access
> > the superinterface sun.nio.ch.SelChImpl, while HotSpot
> > for Java8/9 and J9 for Java8 can access. Could anyone tell
> > me the reason? I checked the package and believed
> > that  the interface is in the JRE libraries.
> >
> sun.nio.ch.SelChImpl is a JDK-internal class, it was package-private in
> JDK 7 but was changed to public in JDK 8.
> 
> -Alan
> 
> 

From chenyt at cs.sjtu.edu.cn  Sun Jan  3 12:21:36 2016
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Sun, 3 Jan 2016 20:21:36 +0800
Subject: A class is accessable from another?
Message-ID: <42446DA10DF44B519D7B041E1BF62F25@sjtu.edu.cn>

Thank you, Ioi.

(1) I rechecked the code. HotSpot complains when I put
java.lang.AbstractStringBuilder to any method (e.g., run()), while
J9 complains only when I put java.lang.AbstractStringBuilder to
the "main" method. Indeed, they take different strategies, although
they should be some compatible to each other.

So, should HotSpot complain if the class AbstractStringBuilder is not
accessable at runtime? I guess AbstractStringBuilder is still usable
(and it also has no effects to the main method) because in JVM 
specification,
"5.4.3.1 Class and Interface Resolution",

To resolve an unresolved symbolic reference from D to a class or interface C 
denoted
by N, the following steps are performed:
1. The defining class loader of D is used to create a class or interface 
denoted by
N. This class or interface is C. The details of the process are given in 
?5.3.
Any exception that can be thrown as a result of failure of class or 
interface
creation can thus be thrown as a result of failure of class and interface
resolution.
2. If C is an array class and its element type is a reference type, ...
3. Finally, access permissions to C are checked.
? If C is not accessible (?5.4.4) to D, class or interface resolution 
throws an
IllegalAccessError.
...
If steps 1 and 2 succeed but step 3 fails, C is still valid and usable.

(2) Thank you for your answer. GraphicsPrimitive$TraceReporter
has been changed to "implement Runnable".

Yuting 


From chenyt at cs.sjtu.edu.cn  Sun Jan  3 12:41:36 2016
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Sun, 3 Jan 2016 20:41:36 +0800
Subject: A class is accessable from another?
Message-ID: <6B74C93C08BC45A0A1B14CFADB9EE9CF@sjtu.edu.cn>

Hi, Ioi,

In fact I raised the similar question two months ago:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016082.html

But at that time a private inner class
sun/java2d/pisces/PiscesRenderingEngine$2 (corresponding to
private static enum NormMode {OFF, ON_NO_AA, ON_WITH_AA}) is put in
the "main" method. Still, JDK complains, but IBM's SDK
does not. It seems that some JVMs may omit these
inaccessable classes even if they are in the main method.

Regards,
Yuting

-----Original Message----- 
From: ???
Sent: Sunday, January 03, 2016 8:21 PM
To: hotspot-runtime-dev at openjdk.java.net ; ioi.lam at oracle.com
Subject: Re: A class is accessable from another?

Thank you, Ioi.

(1) I rechecked the code. HotSpot complains when I put
java.lang.AbstractStringBuilder to any method (e.g., run()), while
J9 complains only when I put java.lang.AbstractStringBuilder to
the "main" method. Indeed, they take different strategies, although
they should be some compatible to each other.

So, should HotSpot complain if the class AbstractStringBuilder is not
accessable at runtime? I guess AbstractStringBuilder is still usable
(and it also has no effects to the main method) because in JVM
specification,
"5.4.3.1 Class and Interface Resolution",

To resolve an unresolved symbolic reference from D to a class or interface C
denoted
by N, the following steps are performed:
1. The defining class loader of D is used to create a class or interface
denoted by
N. This class or interface is C. The details of the process are given in
?5.3.
Any exception that can be thrown as a result of failure of class or
interface
creation can thus be thrown as a result of failure of class and interface
resolution.
2. If C is an array class and its element type is a reference type, ...
3. Finally, access permissions to C are checked.
? If C is not accessible (?5.4.4) to D, class or interface resolution
throws an
IllegalAccessError.
...
If steps 1 and 2 succeed but step 3 fails, C is still valid and usable.

(2) Thank you for your answer. GraphicsPrimitive$TraceReporter
has been changed to "implement Runnable".

Yuting 


From forax at univ-mlv.fr  Sun Jan  3 13:37:17 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 3 Jan 2016 14:37:17 +0100 (CET)
Subject: A class is accessable from another?
In-Reply-To: <6B74C93C08BC45A0A1B14CFADB9EE9CF@sjtu.edu.cn>
References: <6B74C93C08BC45A0A1B14CFADB9EE9CF@sjtu.edu.cn>
Message-ID: <2043865038.540644.1451828237510.JavaMail.zimbra@u-pem.fr>

Hi Yuting,
the way IBM VM (J9) and OpenJDK VM (Hotspot) verify classes is different.
J9 is more lazy, by example, it only verifies a method the first time you execute it and not upfront when you load the class containing the method, as Hotspot does.

Note that both semantics are valid because the Java spec only requires something to be verified before being executed.

cheers,
R?mi

----- Mail original -----
> De: "???" <chenyt at cs.sjtu.edu.cn>
> ?: hotspot-runtime-dev at openjdk.java.net, "ioi lam" <ioi.lam at oracle.com>
> Envoy?: Dimanche 3 Janvier 2016 13:41:36
> Objet: Re: A class is accessable from another?
> 
> Hi, Ioi,
> 
> In fact I raised the similar question two months ago:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016082.html
> 
> But at that time a private inner class
> sun/java2d/pisces/PiscesRenderingEngine$2 (corresponding to
> private static enum NormMode {OFF, ON_NO_AA, ON_WITH_AA}) is put in
> the "main" method. Still, JDK complains, but IBM's SDK
> does not. It seems that some JVMs may omit these
> inaccessable classes even if they are in the main method.
> 
> Regards,
> Yuting
> 
> -----Original Message-----
> From: ???
> Sent: Sunday, January 03, 2016 8:21 PM
> To: hotspot-runtime-dev at openjdk.java.net ; ioi.lam at oracle.com
> Subject: Re: A class is accessable from another?
> 
> Thank you, Ioi.
> 
> (1) I rechecked the code. HotSpot complains when I put
> java.lang.AbstractStringBuilder to any method (e.g., run()), while
> J9 complains only when I put java.lang.AbstractStringBuilder to
> the "main" method. Indeed, they take different strategies, although
> they should be some compatible to each other.
> 
> So, should HotSpot complain if the class AbstractStringBuilder is not
> accessable at runtime? I guess AbstractStringBuilder is still usable
> (and it also has no effects to the main method) because in JVM
> specification,
> "5.4.3.1 Class and Interface Resolution",
> 
> To resolve an unresolved symbolic reference from D to a class or interface C
> denoted
> by N, the following steps are performed:
> 1. The defining class loader of D is used to create a class or interface
> denoted by
> N. This class or interface is C. The details of the process are given in
> ?5.3.
> Any exception that can be thrown as a result of failure of class or
> interface
> creation can thus be thrown as a result of failure of class and interface
> resolution.
> 2. If C is an array class and its element type is a reference type, ...
> 3. Finally, access permissions to C are checked.
> ? If C is not accessible (?5.4.4) to D, class or interface resolution
> throws an
> IllegalAccessError.
> ...
> If steps 1 and 2 succeed but step 3 fails, C is still valid and usable.
> 
> (2) Thank you for your answer. GraphicsPrimitive$TraceReporter
> has been changed to "implement Runnable".
> 
> Yuting
> 
> 

From goetz.lindenmaier at sap.com  Mon Jan  4 15:44:27 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 4 Jan 2016 15:44:27 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
Message-ID: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>

Hi,

Several recent changes cleaned up includes of oop.inline.hpp in real .hpp header file.
Unfortunately, the 'inline' qualifier is added to the function implementations
in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
compiler can not detect failing inlines properly.

This change moves the inline directive from oop.inline.hpp to oop.hpp. Also
it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.

Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.

I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
very small .hpp file and no .cpp file exists.  So I think this is acceptable.

Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
bigger changes to this file in the rt repo, because jvmci is subject to
freqent changes recently.

The following methods were moved to .cpp files:

ProtectionDomainCacheTable::compute_hash()
ProtectionDomainCacheTable::index_for()
typeArrayOopDesc::object_size()
This is called only once outside .cpp file:
CallSiteDepChange::CallSiteDepChange()
This is only called in .cpp file
ConstantPool::string_at_put()

If someone considers not inlining these harmful to performance,
I will add a new .inline.hpp file for them.

Please review this change.  I please need a sponsor.
There are no functional edits, so it should be simple to review.
http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/

Best regards,
  Goetz.

From yumin.qi at oracle.com  Tue Jan  5 02:38:51 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 4 Jan 2016 18:38:51 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris SPARC
	in runtime/SharedArchiveFile/SharedBaseAddress.java
Message-ID: <568B2CBB.3040803@oracle.com>

Please review:

Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/

Summary: Remove skip test bug 8044600, which is an one time failure and 
never got reproduced on the only failed platform, Solaris-sparc.

Tests: JPRT

Thanks
Yumin

From ioi.lam at oracle.com  Tue Jan  5 02:49:47 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 04 Jan 2016 18:49:47 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568B2CBB.3040803@oracle.com>
References: <568B2CBB.3040803@oracle.com>
Message-ID: <568B2F4B.7030707@oracle.com>

Hi Yumin,

Looks good to me.

Thanks
- Ioi

On 1/4/16 6:38 PM, Yumin Qi wrote:
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>
> Summary: Remove skip test bug 8044600, which is an one time failure 
> and never got reproduced on the only failed platform, Solaris-sparc.
>
> Tests: JPRT
>
> Thanks
> Yumin


From yumin.qi at oracle.com  Tue Jan  5 03:04:35 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 4 Jan 2016 19:04:35 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568B2F4B.7030707@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568B2F4B.7030707@oracle.com>
Message-ID: <568B32C3.2020207@oracle.com>

Thanks for the review!

Yumin

On 1/4/2016 6:49 PM, Ioi Lam wrote:
> Hi Yumin,
>
> Looks good to me.
>
> Thanks
> - Ioi
>
> On 1/4/16 6:38 PM, Yumin Qi wrote:
>> Please review:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>
>> Summary: Remove skip test bug 8044600, which is an one time failure 
>> and never got reproduced on the only failed platform, Solaris-sparc.
>>
>> Tests: JPRT
>>
>> Thanks
>> Yumin
>


From gerald.thornbrugh at oracle.com  Tue Jan  5 14:30:04 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 05 Jan 2016 07:30:04 -0700
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568B2CBB.3040803@oracle.com>
References: <568B2CBB.3040803@oracle.com>
Message-ID: <568BD36C.2090200@oracle.com>

Hi Yumin,

Your change looks good.

One question, should you update the copyright year with this change?

Thanks,

Jerry
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>
> Summary: Remove skip test bug 8044600, which is an one time failure 
> and never got reproduced on the only failed platform, Solaris-sparc.
>
> Tests: JPRT
>
> Thanks
> Yumin


From yumin.qi at oracle.com  Tue Jan  5 15:51:33 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 5 Jan 2016 07:51:33 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568BD36C.2090200@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
Message-ID: <568BE685.8090508@oracle.com>

Thanks George,

   Changed to current year.
   Do I need a "R"eviewer for test only changes? If so I still need a 
"R"eviewer gives a yes for push.

Yumin

On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
> Hi Yumin,
>
> Your change looks good.
>
> One question, should you update the copyright year with this change?
>
> Thanks,
>
> Jerry
>> Please review:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>
>> Summary: Remove skip test bug 8044600, which is an one time failure 
>> and never got reproduced on the only failed platform, Solaris-sparc.
>>
>> Tests: JPRT
>>
>> Thanks
>> Yumin
>


From harold.seigel at oracle.com  Tue Jan  5 15:56:28 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 5 Jan 2016 10:56:28 -0500
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568BE685.8090508@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com>
Message-ID: <568BE7AC.3010001@oracle.com>

Hi Yumin,

Your change looks good.

Thanks, Harold

On 1/5/2016 10:51 AM, Yumin Qi wrote:
> Thanks George,
>
>   Changed to current year.
>   Do I need a "R"eviewer for test only changes? If so I still need a 
> "R"eviewer gives a yes for push.
>
> Yumin
>
> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>> Hi Yumin,
>>
>> Your change looks good.
>>
>> One question, should you update the copyright year with this change?
>>
>> Thanks,
>>
>> Jerry
>>> Please review:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>
>>> Summary: Remove skip test bug 8044600, which is an one time failure 
>>> and never got reproduced on the only failed platform, Solaris-sparc.
>>>
>>> Tests: JPRT
>>>
>>> Thanks
>>> Yumin
>>
>


From yumin.qi at oracle.com  Tue Jan  5 15:58:07 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 5 Jan 2016 07:58:07 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568BE7AC.3010001@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
Message-ID: <568BE80F.7020600@oracle.com>

Thanks Harold for quick review!

On 1/5/2016 7:56 AM, harold seigel wrote:
> Hi Yumin,
>
> Your change looks good.
>
> Thanks, Harold
>
> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>> Thanks George,
>>
>>   Changed to current year.
>>   Do I need a "R"eviewer for test only changes? If so I still need a 
>> "R"eviewer gives a yes for push.
>>
>> Yumin
>>
>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>> Hi Yumin,
>>>
>>> Your change looks good.
>>>
>>> One question, should you update the copyright year with this change?
>>>
>>> Thanks,
>>>
>>> Jerry
>>>> Please review:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>
>>>> Summary: Remove skip test bug 8044600, which is an one time failure 
>>>> and never got reproduced on the only failed platform, Solaris-sparc.
>>>>
>>>> Tests: JPRT
>>>>
>>>> Thanks
>>>> Yumin
>>>
>>
>


From daniel.daugherty at oracle.com  Tue Jan  5 17:33:52 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 5 Jan 2016 10:33:52 -0700
Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...
In-Reply-To: <567A9183.1000900@oracle.com>
References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com>
	<567000F9.2070603@oracle.com> <56700279.4000408@oracle.com>
	<56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com>
	<567270F6.7030206@oracle.com> <567390D4.10307@oracle.com>
	<56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com>
	<567A9183.1000900@oracle.com>
Message-ID: <568BFE80.9040000@oracle.com>

Happy New Year!


 > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/

src/os/windows/vm/os_windows.cpp
     L3923:         Atomic::cmpxchg((jint)GetCurrentThreadId(), 
&process_exiting, 0);
         What's the return size of GetCurrentThreadId()? Are we
         down casting a larger size into a 'jint'? If so, that
         might allow more than one thread into this code when we
         only want one...

         Also please consider adding a comment above this line.
         Perhaps something like:

         // Atomically set process_exiting before the critical section
         // to increase the visibility between racing threads.

     L3998:             if (portion_count > MAXIMUM_WAIT_OBJECTS) {
     L3999:                 portion_count = MAXIMUM_WAIT_OBJECTS;
         Wrong indent; should be two spaces relative to L3998.

     L4013:               portion_count = handle_count - i;
         Please consider adding a comment for this error case.
         Perhaps something like:
         // Reset portion_count so we close the remaining
         // handles due to this error.

     L4030:     if (OrderAccess::load_acquire(&process_exiting) != 0 &&
     L4031:         process_exiting != (jint)GetCurrentThreadId()) {
     L4032:       while (true) {
     L4033:         // Some other thread is about to call exit(), so we
     L4034:         // don't let the current thread proceed to exit() or 
_endthreadex()
         The comment on L4033-4 is slightly misplaced now. It
         should be between L4031 and L4032.


Thumbs up modulo the GetCurrentThreadId() return size question
above. If that size is OK and you choose to make the comment
changes, I don't need to see another webrev.

Dan


On 12/23/15 5:20 AM, Ivan Gerasimov wrote:
> Thank you David for review!
>
> Sincerely yours,
> Ivan
>
> On 23.12.2015 7:41, David Holmes wrote:
>> Looks okay.
>>
>> Second review needed though.
>>
>> Thanks,
>> David
>>
>> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote:
>>>
>>>
>>>>> We will suspend the current thread if two conditions are satisfied:
>>>>> process_exiting != 0 and process_exiting != current thread id.
>>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting
>>>>> directly.
>>>>>
>>>>> Here's the updated webrev:
>>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/
>>>>
>>>> I still see pr_ex ??
>>>>
>>>
>>> Oops.
>>> Forgot to 'hg qrefresh' before generating the webrev.
>>> The webrev has just been updated in place.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>
>


From rachel.protacio at oracle.com  Tue Jan  5 18:04:21 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 5 Jan 2016 13:04:21 -0500
Subject: RFR (XXS): 8146481: Disable runtime/logging/DefaultMethodsTest.java
Message-ID: <568C05A5.50601@oracle.com>

Hi,

Please review this change, @ignore'ing the DefaultMethodsTest jtreg test 
until such a time as it can be properly fixed. (May be broken due to a 
deeper logging framework or windows issue since the test had been 
running fine for the past month.)

Open webrev: http://cr.openjdk.java.net/~rprotacio/8146481/
Bug: https://bugs.openjdk.java.net/browse/JDK-8146481

Thanks!
Rachel

From harold.seigel at oracle.com  Tue Jan  5 18:06:02 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 5 Jan 2016 13:06:02 -0500
Subject: RFR (XXS): 8146481: Disable
	runtime/logging/DefaultMethodsTest.java
In-Reply-To: <568C05A5.50601@oracle.com>
References: <568C05A5.50601@oracle.com>
Message-ID: <568C060A.2040004@oracle.com>

Hi Rachel,

The change looks good.

Harold

On 1/5/2016 1:04 PM, Rachel Protacio wrote:
> Hi,
>
> Please review this change, @ignore'ing the DefaultMethodsTest jtreg 
> test until such a time as it can be properly fixed. (May be broken due 
> to a deeper logging framework or windows issue since the test had been 
> running fine for the past month.)
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146481/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146481
>
> Thanks!
> Rachel


From george.triantafillou at oracle.com  Tue Jan  5 18:09:45 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 5 Jan 2016 13:09:45 -0500
Subject: RFR (XXS): 8146481: Disable
	runtime/logging/DefaultMethodsTest.java
In-Reply-To: <568C05A5.50601@oracle.com>
References: <568C05A5.50601@oracle.com>
Message-ID: <568C06E9.3010200@oracle.com>

Hi Rachel,

Looks good.

-George

On 1/5/2016 1:04 PM, Rachel Protacio wrote:
> Hi,
>
> Please review this change, @ignore'ing the DefaultMethodsTest jtreg 
> test until such a time as it can be properly fixed. (May be broken due 
> to a deeper logging framework or windows issue since the test had been 
> running fine for the past month.)
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146481/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146481
>
> Thanks!
> Rachel


From coleen.phillimore at oracle.com  Tue Jan  5 18:10:13 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 5 Jan 2016 13:10:13 -0500
Subject: RFR (XXS): 8146481: Disable
	runtime/logging/DefaultMethodsTest.java
In-Reply-To: <568C05A5.50601@oracle.com>
References: <568C05A5.50601@oracle.com>
Message-ID: <568C0705.7030008@oracle.com>


Looks good!  That was fast.
Coleen


On 1/5/16 1:04 PM, Rachel Protacio wrote:
> Hi,
>
> Please review this change, @ignore'ing the DefaultMethodsTest jtreg 
> test until such a time as it can be properly fixed. (May be broken due 
> to a deeper logging framework or windows issue since the test had been 
> running fine for the past month.)
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146481/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146481
>
> Thanks!
> Rachel


From rachel.protacio at oracle.com  Tue Jan  5 18:13:58 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 5 Jan 2016 13:13:58 -0500
Subject: RFR (XXS): 8146481: Disable
	runtime/logging/DefaultMethodsTest.java
In-Reply-To: <568C0705.7030008@oracle.com>
References: <568C05A5.50601@oracle.com> <568C0705.7030008@oracle.com>
Message-ID: <568C07E6.9070802@oracle.com>

Great! Thank you, Harold, George, and Coleen!
Rachel

On 1/5/2016 1:10 PM, Coleen Phillimore wrote:
>
> Looks good!  That was fast.
> Coleen
>
>
> On 1/5/16 1:04 PM, Rachel Protacio wrote:
>> Hi,
>>
>> Please review this change, @ignore'ing the DefaultMethodsTest jtreg 
>> test until such a time as it can be properly fixed. (May be broken 
>> due to a deeper logging framework or windows issue since the test had 
>> been running fine for the past month.)
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146481/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146481
>>
>> Thanks!
>> Rachel
>


From coleen.phillimore at oracle.com  Tue Jan  5 19:24:04 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 5 Jan 2016 14:24:04 -0500
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
Message-ID: <568C1854.8060806@oracle.com>


http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/code/dependencies.cpp.udiff.html

Can you fix the preexisting weird indentation of

+ assert(_call_site() ->is_a(SystemDictionary::CallSite_klass()), "must 
be");


Not sure what that was supposed to line up with originally.

http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/jvmci/jvmciJavaClasses.hpp.udiff.html

Don't have an opinion about including the .inline.hpp files in these.  
The compiler team should probably clean this up.

http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html

Why isn't inline in the declaration for obj_at_put ?

http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/oop.hpp.udiff.html

Why is inline commented out for some?

+ inline bool is_instance() const;
+ /*inline*/ bool is_array() const;


http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/oop.inline.hpp.udiff.html

I'm not really happy with the re-sorting because it may make backporting 
difficult, but it's not that many that were moved and the order of these 
functions has always seeemed random to me.  So I guess it's ok.

Can you line up the '\' in the OOP_ITERATE macros at the end?

http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/typeArrayOop.cpp.udiff.html

This non-inline function could affect performance.   It may be called 
from GC.  We might need a typeArrayOop.inline.hpp for it.

I can sponsor this, pending further review.

Coleen


On 1/4/16 10:44 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp header file.
> Unfortunately, the 'inline' qualifier is added to the function implementations
> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
> compiler can not detect failing inlines properly.
>
> This change moves the inline directive from oop.inline.hpp to oop.hpp. Also
> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>
> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
>
> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>
> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> bigger changes to this file in the rt repo, because jvmci is subject to
> freqent changes recently.
>
> The following methods were moved to .cpp files:
>
> ProtectionDomainCacheTable::compute_hash()
> ProtectionDomainCacheTable::index_for()
> typeArrayOopDesc::object_size()
> This is called only once outside .cpp file:
> CallSiteDepChange::CallSiteDepChange()
> This is only called in .cpp file
> ConstantPool::string_at_put()
>
> If someone considers not inlining these harmful to performance,
> I will add a new .inline.hpp file for them.
>
> Please review this change.  I please need a sponsor.
> There are no functional edits, so it should be simple to review.
> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
>
> Best regards,
>    Goetz.


From max.ockner at oracle.com  Tue Jan  5 19:25:35 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 05 Jan 2016 14:25:35 -0500
Subject: RFR: 8146485: Add test for Unified Logging classresolve tag.
Message-ID: <568C18AF.5000908@oracle.com>

Hello,
Please review this fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8146485
Webrev: http://cr.openjdk.java.net/~mockner/classresolvetest/

Summary: I patched my original webrev into a clean repo before 
submitting to jprt and I forgot to 'hg add' the test.  This fix contains 
the test.

Tested with: This test which is being added. No change was made to the 
source code, only a test was added.

Thanks,
Max

From george.triantafillou at oracle.com  Tue Jan  5 19:36:12 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 5 Jan 2016 14:36:12 -0500
Subject: RFR: 8146485: Add test for Unified Logging classresolve tag.
In-Reply-To: <568C18AF.5000908@oracle.com>
References: <568C18AF.5000908@oracle.com>
Message-ID: <568C1B2C.5090400@oracle.com>

Hi Max,

Looks good!

-George

On 1/5/2016 2:25 PM, Max Ockner wrote:
> Hello,
> Please review this fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146485
> Webrev: http://cr.openjdk.java.net/~mockner/classresolvetest/
>
> Summary: I patched my original webrev into a clean repo before 
> submitting to jprt and I forgot to 'hg add' the test.  This fix 
> contains the test.
>
> Tested with: This test which is being added. No change was made to the 
> source code, only a test was added.
>
> Thanks,
> Max


From coleen.phillimore at oracle.com  Tue Jan  5 19:44:56 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 5 Jan 2016 14:44:56 -0500
Subject: RFR: 8146485: Add test for Unified Logging classresolve tag.
In-Reply-To: <568C18AF.5000908@oracle.com>
References: <568C18AF.5000908@oracle.com>
Message-ID: <568C1D38.9070305@oracle.com>


Looks good!
Coleen

On 1/5/16 2:25 PM, Max Ockner wrote:
> Hello,
> Please review this fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146485
> Webrev: http://cr.openjdk.java.net/~mockner/classresolvetest/
>
> Summary: I patched my original webrev into a clean repo before 
> submitting to jprt and I forgot to 'hg add' the test.  This fix 
> contains the test.
>
> Tested with: This test which is being added. No change was made to the 
> source code, only a test was added.
>
> Thanks,
> Max


From max.ockner at oracle.com  Tue Jan  5 20:14:04 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 05 Jan 2016 15:14:04 -0500
Subject: RFR: 8146485: Add test for Unified Logging classresolve tag.
In-Reply-To: <568C1D38.9070305@oracle.com>
References: <568C18AF.5000908@oracle.com> <568C1D38.9070305@oracle.com>
Message-ID: <568C240C.70605@oracle.com>

Thanks, Coleen and George, for the quick responses. I'll wait an hour 
and then submit if nobody else has complaints.

On 1/5/2016 2:44 PM, Coleen Phillimore wrote:
>
> Looks good!
> Coleen
>
> On 1/5/16 2:25 PM, Max Ockner wrote:
>> Hello,
>> Please review this fix.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146485
>> Webrev: http://cr.openjdk.java.net/~mockner/classresolvetest/
>>
>> Summary: I patched my original webrev into a clean repo before 
>> submitting to jprt and I forgot to 'hg add' the test.  This fix 
>> contains the test.
>>
>> Tested with: This test which is being added. No change was made to 
>> the source code, only a test was added.
>>
>> Thanks,
>> Max
>


From jiangli.zhou at Oracle.COM  Tue Jan  5 22:30:36 2016
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Tue, 5 Jan 2016 14:30:36 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
Message-ID: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>

Hi,

Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:

  http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/

The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().

Tested with test/runtime/NMT.

Thanks,
Jiangli




From daniel.daugherty at oracle.com  Tue Jan  5 23:28:53 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 5 Jan 2016 16:28:53 -0700
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56784A53.5090203@oracle.com>
References: <56784A53.5090203@oracle.com>
Message-ID: <568C51B5.5030300@oracle.com>

On 12/21/15 11:52 AM, Yumin Qi wrote:
> Please review:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>
> This is REDO for bug 8087223, which was backed out due to failed on 
> 8143317 and 8143320.
> The defmeth encoutered new failures after the fix, which now has 
> correct constant tags. The test bugs will be addressed in 8143320, 
> which based on vm/runtime/defmeth and 8143317, which in jdk/test.
>
> One difference from the attached for this webrev is that in 
> MethodHandle resolution, I relax the check for one specific case: 
> Using MethodHandle to invoke static default interface method. In this 
> case, we must use invokestatic (JVM_REF_invokeStatic), which in 
> defmeth it will generate method tag for interface which violates 
> JVMS-5.4.3.3 (it should create interface method tag!). ASM currently 
> has no API to generate invokeinterface for a interface static default 
> method through MethodHandle invocation.
>
> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
> Note the fix still fails 8143320 and 8143317 which are not fixed at 
> the momment.

Are the failing tests quarantined? When this fix is pushed,
neither the "new" or "known" failures counts should increase.

Dan


>
>
> Thanks
> Yumin
>
>
> Original post:
> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>
> Please review:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>
> According to JVMS-8:
>
> JVMS-5.4.3.3 Method Resolution:
>  " If C is an interface, method resolution throws an 
> IncompatibleClassChangeError."
> JVMS-5.4.3.4 Interface Method Resolution:
>  "If C is not an interface, interface method resolution throws an 
> IncompatibleClassChangeError"
>
> When invoke a method with resolved to an interface method, or invoke a 
> interface method with resolved to an instance method, ICCE should be 
> thrown. The case usually happens when using tools like asmtools or 
> jdk.internal.org.objectweb.asm to generate java bytecode.
>
> The fix is carrying the constantTag for the method at call and check 
> if tag is consistent with the method called. Doing this by adding a 
> member of constantTag, _tag,  to LinkInfo, and check tag in resolve 
> functions to see if tag matched with the correct method.
>
> The fix solved the problem when call is from interpreter and compiler, 
> bug for MethodHandle invoke, which should be addressed in another 
> bug,  since the MethodHandle does not come with a byte stream and 
> getting the constant pool index at the invoke is not possible.  It 
> will be addressed in another bug.
>
> Tests: test case (added, minor modified from bug), JPRT, rutime quick 
> test list(in progress).
> manually tested:  1) -Xint
>                                2) -Xcomp
>                                3) -Xcomp -XX:-TieredCompiltion
>                                4) -Xcomp -XX:+TieredCompilation
>
> Thanks to Coleen for helping fixed constant pool index and cleaned 
> LinkInfo.
> ---------------------------------------------------------------------------------------------------------------------------------- 
>
>
> Second revision attached.
>
>
>
>
> Thanks
> Yumin


From yumin.qi at oracle.com  Tue Jan  5 23:37:59 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 5 Jan 2016 15:37:59 -0800
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <568C51B5.5030300@oracle.com>
References: <56784A53.5090203@oracle.com> <568C51B5.5030300@oracle.com>
Message-ID: <568C53D7.6030106@oracle.com>



On 1/5/2016 3:28 PM, Daniel D. Daugherty wrote:
> On 12/21/15 11:52 AM, Yumin Qi wrote:
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>
>> This is REDO for bug 8087223, which was backed out due to failed on 
>> 8143317 and 8143320.
>> The defmeth encoutered new failures after the fix, which now has 
>> correct constant tags. The test bugs will be addressed in 8143320, 
>> which based on vm/runtime/defmeth and 8143317, which in jdk/test.
>>
>> One difference from the attached for this webrev is that in 
>> MethodHandle resolution, I relax the check for one specific case: 
>> Using MethodHandle to invoke static default interface method. In this 
>> case, we must use invokestatic (JVM_REF_invokeStatic), which in 
>> defmeth it will generate method tag for interface which violates 
>> JVMS-5.4.3.3 (it should create interface method tag!). ASM currently 
>> has no API to generate invokeinterface for a interface static default 
>> method through MethodHandle invocation.
>>
>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>> Note the fix still fails 8143320 and 8143317 which are not fixed at 
>> the momment.
>
> Are the failing tests quarantined? When this fix is pushed,
> neither the "new" or "known" failures counts should increase.
>
Do you mean 'RULE' out in bugs? No.
So after the fix pushed, it still fails on the tests --- but will pass 
after 8143320 pushed to vm repo. It is not clear for me:

after 8145148(this) pushed to hs-rt, the tests will fail as before.
after 8143320 pushed to vm (sqe), hs-rt will pass, but hs-comp will fail 
since I changed defmeth!

As for 8143317, so far not assigned --- in jdk group.

Thanks
Yumin

> Dan
>
>
>>
>>
>> Thanks
>> Yumin
>>
>>
>> Original post:
>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>
>> According to JVMS-8:
>>
>> JVMS-5.4.3.3 Method Resolution:
>>  " If C is an interface, method resolution throws an 
>> IncompatibleClassChangeError."
>> JVMS-5.4.3.4 Interface Method Resolution:
>>  "If C is not an interface, interface method resolution throws an 
>> IncompatibleClassChangeError"
>>
>> When invoke a method with resolved to an interface method, or invoke 
>> a interface method with resolved to an instance method, ICCE should 
>> be thrown. The case usually happens when using tools like asmtools or 
>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>
>> The fix is carrying the constantTag for the method at call and check 
>> if tag is consistent with the method called. Doing this by adding a 
>> member of constantTag, _tag,  to LinkInfo, and check tag in resolve 
>> functions to see if tag matched with the correct method.
>>
>> The fix solved the problem when call is from interpreter and 
>> compiler, bug for MethodHandle invoke, which should be addressed in 
>> another bug,  since the MethodHandle does not come with a byte stream 
>> and getting the constant pool index at the invoke is not possible.  
>> It will be addressed in another bug.
>>
>> Tests: test case (added, minor modified from bug), JPRT, rutime quick 
>> test list(in progress).
>> manually tested:  1) -Xint
>>                                2) -Xcomp
>>                                3) -Xcomp -XX:-TieredCompiltion
>>                                4) -Xcomp -XX:+TieredCompilation
>>
>> Thanks to Coleen for helping fixed constant pool index and cleaned 
>> LinkInfo.
>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>> Second revision attached.
>>
>>
>>
>>
>> Thanks
>> Yumin
>


From david.holmes at oracle.com  Wed Jan  6 04:25:34 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Jan 2016 14:25:34 +1000
Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...
In-Reply-To: <568BFE80.9040000@oracle.com>
References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com>
	<567000F9.2070603@oracle.com> <56700279.4000408@oracle.com>
	<56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com>
	<567270F6.7030206@oracle.com> <567390D4.10307@oracle.com>
	<56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com>
	<567A9183.1000900@oracle.com> <568BFE80.9040000@oracle.com>
Message-ID: <568C973E.6030404@oracle.com>

On 6/01/2016 3:33 AM, Daniel D. Daugherty wrote:
> Happy New Year!

And to you :)

>
>  > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/
>
> src/os/windows/vm/os_windows.cpp
>      L3923:         Atomic::cmpxchg((jint)GetCurrentThreadId(),
> &process_exiting, 0);
>          What's the return size of GetCurrentThreadId()? Are we

It is a DWORD so 32-bit.

Cheers,
David
-----

>          down casting a larger size into a 'jint'? If so, that
>          might allow more than one thread into this code when we
>          only want one...
>
>          Also please consider adding a comment above this line.
>          Perhaps something like:
>
>          // Atomically set process_exiting before the critical section
>          // to increase the visibility between racing threads.
>
>      L3998:             if (portion_count > MAXIMUM_WAIT_OBJECTS) {
>      L3999:                 portion_count = MAXIMUM_WAIT_OBJECTS;
>          Wrong indent; should be two spaces relative to L3998.
>
>      L4013:               portion_count = handle_count - i;
>          Please consider adding a comment for this error case.
>          Perhaps something like:
>          // Reset portion_count so we close the remaining
>          // handles due to this error.
>
>      L4030:     if (OrderAccess::load_acquire(&process_exiting) != 0 &&
>      L4031:         process_exiting != (jint)GetCurrentThreadId()) {
>      L4032:       while (true) {
>      L4033:         // Some other thread is about to call exit(), so we
>      L4034:         // don't let the current thread proceed to exit() or
> _endthreadex()
>          The comment on L4033-4 is slightly misplaced now. It
>          should be between L4031 and L4032.
>
>
> Thumbs up modulo the GetCurrentThreadId() return size question
> above. If that size is OK and you choose to make the comment
> changes, I don't need to see another webrev.
>
> Dan
>
>
> On 12/23/15 5:20 AM, Ivan Gerasimov wrote:
>> Thank you David for review!
>>
>> Sincerely yours,
>> Ivan
>>
>> On 23.12.2015 7:41, David Holmes wrote:
>>> Looks okay.
>>>
>>> Second review needed though.
>>>
>>> Thanks,
>>> David
>>>
>>> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote:
>>>>
>>>>
>>>>>> We will suspend the current thread if two conditions are satisfied:
>>>>>> process_exiting != 0 and process_exiting != current thread id.
>>>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting
>>>>>> directly.
>>>>>>
>>>>>> Here's the updated webrev:
>>>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/
>>>>>
>>>>> I still see pr_ex ??
>>>>>
>>>>
>>>> Oops.
>>>> Forgot to 'hg qrefresh' before generating the webrev.
>>>> The webrev has just been updated in place.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>
>>
>

From david.holmes at oracle.com  Wed Jan  6 04:58:36 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Jan 2016 14:58:36 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
Message-ID: <568C9EFC.8050304@oracle.com>

Hi Goetz,

On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp header file.
> Unfortunately, the 'inline' qualifier is added to the function implementations
> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
> compiler can not detect failing inlines properly.
>
> This change moves the inline directive from oop.inline.hpp to oop.hpp. Also

This seems contrary to the C++ FAQ:

https://isocpp.org/wiki/faq/inline-functions

The declaration in the .hpp should not have inline, only the definition, 
which in our case is in the .inline.hpp file.

Any code that includes the .inline.hpp will have seen the definition of 
the inline function prior to its use - as long as the includes are correct.

David
-----


> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>
> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
>
> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>
> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> bigger changes to this file in the rt repo, because jvmci is subject to
> freqent changes recently.
>
> The following methods were moved to .cpp files:
>
> ProtectionDomainCacheTable::compute_hash()
> ProtectionDomainCacheTable::index_for()
> typeArrayOopDesc::object_size()
> This is called only once outside .cpp file:
> CallSiteDepChange::CallSiteDepChange()
> This is only called in .cpp file
> ConstantPool::string_at_put()
>
> If someone considers not inlining these harmful to performance,
> I will add a new .inline.hpp file for them.
>
> Please review this change.  I please need a sponsor.
> There are no functional edits, so it should be simple to review.
> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
>
> Best regards,
>    Goetz.
>

From david.holmes at oracle.com  Wed Jan  6 05:19:10 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Jan 2016 15:19:10 +1000
Subject: RFR(XS): 8146092: gcc 4.3: -fno-var-tracking-assignments not
	available
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EF317B@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EF317B@DEWDFEMB12A.global.corp.sap>
Message-ID: <568CA3CE.6020504@oracle.com>

Hi Goetz,

Is this still outstanding?

On 23/12/2015 11:37 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> gcc 4.3 does not grok -fno-var-tracking-assignments.
> I was told gcc 4.5 would known the flag, but I can not test that.
> So I now check for >= 4.8.

Don't we trust the gcc manual ??

> It's only a note, so it should not matter to "warnings are errors".
> I also remove a ia64 special case that's not necessary.

Mixing unrelated changes is not a good idea. Who is building ia64 with 
gcc? Are the other ia64 code fragments still needed?

Thanks,
David

> Please review. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8146092-gcc4.3/webrev.00/
>
> This is not urgent as fixes for gcc 4.1.2, as we don't use 4.3 in our
> test builds or internal VM.
>
> Best regards,
>    Goetz.
>

From david.holmes at oracle.com  Wed Jan  6 06:33:21 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Jan 2016 16:33:21 +1000
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
Message-ID: <568CB531.5080608@oracle.com>

Hi Jiangli,

On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
> Hi,
>
> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>
>    http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>
> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().

I find this very confusing. Is there some document that describes the 
relationship between mapping, reserving and committing virtual memory 
and the related NMT functionality? It is not at all clear to me why 
reserve_and_commit pairs with uncommit (unless committed memory must 
first be reserved, and uncommit both uncommits and "unreserves" ??)

Thanks,
David
-----

> Tested with test/runtime/NMT.
>
> Thanks,
> Jiangli
>
>
>

From cheleswer.sahu at oracle.com  Wed Jan  6 11:37:31 2016
From: cheleswer.sahu at oracle.com (cheleswer sahu)
Date: Wed, 6 Jan 2016 17:07:31 +0530
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each GC
	log rotation
Message-ID: <568CFC7B.1010801@oracle.com>

Hi,

Please review the code changes for 
"https://bugs.openjdk.java.net/browse/JDK-8144483".

webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483

Bug brief:
A long pause is observed after each gc log rotation in Solaris.

Problem Identified:
In each GC log rotation "print_memory_info()" is getting called through 
dump_loggc_header().
"print_memory_info()" of solaris version calls check_addr0(st);

File: 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp

void os::print_memory_info(outputStream* st) {
   st->print("Memory:");

   st->print(" %dk page", os::vm_page_size()>>10);

   st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);

   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);

   st->cr();
  (void) check_addr0(st);
}

Now check_addr0(st) function do a lot of read call to read the data from 
/proc/self/map.
and check if virtual address is mapped to 0x0. These read calls take lot 
of time which results in GC rotation pause.
Here calling check_addr0() seems unnecessary for every log rotation. It 
will be more logical if this function gets called only
when an error is reported.

Solution proposed:
Before GC log rotation print_memory_info() is ever getting called from 
Vm_error.cpp during error reporting. And in case of error reporting
checking for address mapping to 0x0 looks fine. So the proposed solution 
is to do an extra check inside print_memory_info().

-  (void) check_addr0(st);
+  if (VMError::fatal_error_in_progress()){
+     (void) check_addr0(st);
+  }
  }

  This check doesn't fit well inside printing function, but at this 
point I don't see the need to create a new os:: method and change all 
the OS classes just for that check.

Regards,
Cheleswer

From yumin.qi at oracle.com  Wed Jan  6 16:18:18 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 6 Jan 2016 08:18:18 -0800
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568CFC7B.1010801@oracle.com>
References: <568CFC7B.1010801@oracle.com>
Message-ID: <568D3E4A.7070308@oracle.com>

Cheleswer,

   If the call to check_addr0() is unnecessary, remove it is a better 
choice I think. In fatal error, means VM will exit, the error handler 
will print memory info, so it is redundant here. I don't know why it is 
added to log rotation code in the first place.

   Thanks
   Yumin

On 1/6/2016 3:37 AM, cheleswer sahu wrote:
> Hi,
>
> Please review the code changes for 
> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>
> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>
> Bug brief:
> A long pause is observed after each gc log rotation in Solaris.
>
> Problem Identified:
> In each GC log rotation "print_memory_info()" is getting called 
> through dump_loggc_header().
> "print_memory_info()" of solaris version calls check_addr0(st);
>
> File: 
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>
> void os::print_memory_info(outputStream* st) {
>   st->print("Memory:");
>
>   st->print(" %dk page", os::vm_page_size()>>10);
>
>   st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);
>
>   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>
>   st->cr();
>  (void) check_addr0(st);
> }
>
> Now check_addr0(st) function do a lot of read call to read the data 
> from /proc/self/map.
> and check if virtual address is mapped to 0x0. These read calls take 
> lot of time which results in GC rotation pause.
> Here calling check_addr0() seems unnecessary for every log rotation. 
> It will be more logical if this function gets called only
> when an error is reported.
>
> Solution proposed:
> Before GC log rotation print_memory_info() is ever getting called from 
> Vm_error.cpp during error reporting. And in case of error reporting
> checking for address mapping to 0x0 looks fine. So the proposed 
> solution is to do an extra check inside print_memory_info().
>
> -  (void) check_addr0(st);
> +  if (VMError::fatal_error_in_progress()){
> +     (void) check_addr0(st);
> +  }
>  }
>
>  This check doesn't fit well inside printing function, but at this 
> point I don't see the need to create a new os:: method and change all 
> the OS classes just for that check.
>
> Regards,
> Cheleswer


From john.r.rose at oracle.com  Wed Jan  6 17:32:54 2016
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 6 Jan 2016 09:32:54 -0800
Subject: RFR(XS): 8144852: Corrupted oop in nmethod
In-Reply-To: <5671F5F6.9060605@oracle.com>
References: <566A44AA.1040101@oracle.com> <566AB84C.1000603@oracle.com>
	<566B216B.1020204@oracle.com> <5671CC94.2080205@oracle.com>
	<5671F5F6.9060605@oracle.com>
Message-ID: <457FC936-D24F-4486-8D99-E4D8B55528CC@oracle.com>

On Dec 16, 2015, at 3:38 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Adding non_oop_word to oopDesc::print_*_on would imply that it's OK to assign this value in a more general context, which is not true.

So put in a comment.  The print_on stuff is for us to use in debuggers and tracing code, not for end users who might be confused.

> So I would suggest keeping knowledge of non_oop_word inside nmethod for now, and we can revisit this if other places start to use non_oop_word.

Either way is OK with me.  But I like my print functions to be as forgiving as possible; don't you?

? John

From rachel.protacio at oracle.com  Wed Jan  6 21:31:54 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 6 Jan 2016 16:31:54 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
Message-ID: <568D87CA.6000704@oracle.com>

Hi,

When I tried to commit this change, the ItablesTest was failing on 
windows, so I've been trying to get to the bottom of that failure. As 
other logging tests have recently proved themselves flaky on windows as 
well, it seems to be a deeper issue. As such, I have added the problem 
to https://bugs.openjdk.java.net/browse/JDK-8146435 for more thorough 
investigation and ignored the ItablesTest for the time being.

Here's my new webrev http://cr.openjdk.java.net/~rprotacio/8141564.03/ 
which only differs from the previously approved code via the @ignore 
line. The code passes JPRT.

Thank you!
Rachel

On 12/8/2015 12:28 PM, Karen Kinnear wrote:
> Rachel,
>
> Thank you for the updates.
> Can you please sanity check one thing for me - the log_tables boolean ?overrides? appears to
> be set correctly in the callers, to mean ?yes, this overrides?.
> In log_vtables, is it possible the choice of what to print is reversed?
>
> And perhaps add a check to your tests for example that ?NOT overriding? catches the right case?
>
> And yes please on the assertion (I have seen null method bugs in development and this code is an early
> opportunity to catch that problem).
>
> I don?t need to see an updated web rev and you don?t need to rerun all the tests to fix
> the printed string.
>
> thanks,
> Karen
>
>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>>
>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>> Hi, Karen,
>>>
>>> Thanks for the review. Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>
>>> Since I never listed the tests I ran even the first time, here are all of them:
>>>
>>> * jtreg
>>> * JPRT
>>> * jck vm, lang, & api/java_lang
>>> * rbt quick and non-colo (which now includes defmeth)
>>> * invoke*
>>>
>>> Replies inline.
>>>
>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>> Rachel,
>>>>
>>>> Thank you so much for doing (and redoing) this.
>>>>
>>>> Couple of questions/comments.
>>>>
>>>> 1. thank you so much for the transitive overriding test - not easy to figure out how to generate one!
>>>>
>>> Lois walked me through doing that one :)
>>>> 2. I missed the list of what you have tested for the first web rev and the other tests for this one
>>>> I will assume in parallel with the code review you are running (without tracing)
>>>> vm quick & nocolo, jck vm & lang
>>>> defmeth, invoke*
>>> Yeah, I totally forgot to email what tests I had run. Sorry about that! And just learned how to run the jck tests.
>>>> There might be value in running your new tests with old tracing vs. new and eyeballing the files - to see if they
>>>> get essentially the same information.
>>>>
>>> Yup!
>>>> 3. klassVtable.cpp lines 154-156 ?
>>>> Would it make any sense to do if !klass()->is_array_klass() and then just use the log_develop_debug and
>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>
>>> That makes sense. Changed as suggested.
>>>> 4. thank you so much for extracting the print_linkage_flags - I should have done that earlier - the information
>>>> just grew incrementally.
>>>>
>>>> 5. klassVtable.cpp line 1047 -
>>>>    I think you want an if (m != NULL) here  before dereferencing to print_linkage_flags.
>>>>    I see we miss that check for other dereferences -feel free to add small checks.
>>>>    Don?t completely skip logic paragraphs except for printing ones.
>>> Well, when I was making my change, we saw that it wouldn't be possible for m to be null at that point in the code. There are multiple places above it where it is dereferenced already, not to mention the fact that it is theoretically initialized to be a valid method. Would you like to me to add an assert after the declaration
>>>     assert(m != NULL, "methods can never be null");
>>> just to be safe?
>> In the code here:
>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html>
>>
>> Yes, Method* m = method->at(i); can never return NULL or else the whole VM would crash everywhere.  I suspect the logging code here was copied from other instances where 'm' could be null.   This line would crash first:
>>
>> if (interface_method_needs_itable_index(m)) {
>>
>>
>> Can you clean up this line also to not check for NULL:
>>
>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() : "<NULL>";
>>
>>
>> And add the assert if Karen agrees if it's needed.
>>
>> The rest of the changes look good.   I don't need to see another revision.
>>
>> Thanks,
>> Coleen
>>>>     Thank you for leaving the null check in fill_in_miranda and print_method_at.
>>>>
>>>> 6. log_vtables
>>>> The logic in update_inherited_vtables is quite complex.
>>>> So the value of allocate_new is not really the right conditional to pass in to determine if there
>>>> was an override.
>>>>    The first paragraph applies both for allocate_new=true and allocate_new=false (see !target_method()->is_package_private())
>>>>    so they would have allocate_new = true AND be overriding.
>>>>
>>>> So, perhaps you could add a boolean that says ?overrides? or ?overriding? or whatever : default it to false, and set it to true right after the put_method_at line (that iswhere the override occurs) and set it to false in the ?else? clause?
>>>> And pass that argument in to log_vtables ? And remove the allocate_new comment from log_vtables as well?
>>>>
>>> Done, too.
>>>
>>> Thanks!!
>>> Rachel
>>>> And the comment in the ?else? is not accurate since I put the package_private fix in - so removing
>>>> it was a good idea.
>>>>
>>>> many thanks,
>>>> Karen
>>>>
>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com> <mailto:rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>
>>>>> Hi,
>>>>> Thanks for the comments! Updated webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/ <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and passes logging jtreg tests.)
>>>>>
>>>>> Replies inline.
>>>>>
>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>> Rachel, There are a lot of changes here.  I have several comments and more suggested cleanup that should be done with this work.
>>>>>>
>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>>
>>>>>>
>>>>>> I did the original refactoring for trace_method_resolution. What I think would be better is to make it an internal static function in linkResolver.cpp and not defined in the linkResolver.hpp.  Make the call unconditional and pass vtable index in the last parameter as a default parameter with default value -1 so the last line in the function is the tty->cr() that I had outside the function call (that was pretty icky). And put all the ResourceMark and logstream logic inside the trace_method_resolution function.  It would never print to tty so doesn't need an outputStream parameter for other callers.
>>>>>>
>>>>>> So there would be only the one line trace_method_resolution(params) in the regular code.
>>>>> Thanks for the advice! I still have to call the function from within the conditional because it's develop level only and because I need to specify in the call whether it's for itables or vtables. Otherwise, I've followed your suggestions.
>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>>
>>>>>>
>>>>>> Can you put these tags near each other?
>>>>>>
>>>>> I have them sorted alphabetically, which I think is more useful in the long run.
>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>>
>>>>>>
>>>>>> One of the things that Markus Gronlund's made me think that we should do with his cleanup is to stop declaring functions as members of classes if they don't need external linkage. From his RFR(L): 8140485: Class load and creation clean up:
>>>>>>
>>>>>> "Comment: In my opinion, we should attempt to break the pattern of having private functions declared in header files when the private function does not need to reach inside "this"."
>>>>>>
>>>>>> I think the function log_vtables should follow this and be declared as a static internal function in klassVtable.cpp above the function where it's used.
>>>>>>
>>>>>> It's true that you don't see this very much in the hotspot sources.
>>>>>>
>>>>>> The refactoring of log_vtables is good and very much appreciated.
>>>>>>
>>>>>> In each of the logging blocks of code, there are about 6 lines that are about the same, that print the access flags and whether it's a default or overpass method.  (Karen and Lois should give you a TOI about what that means!)  Can you add a method to method.hpp that's something like print_flags(outputStream* st) and move this printing there, and make those blocks call your new function?  That would shorten many of these logging blocks of code and would be nice.  You could call this from the linkResolver.cpp trace_method_resolution() function too.
>>>>> Done.
>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>>
>>>>>>
>>>>>> These classes have missing copyrights.
>>>>> Fixed.
>>>>> Thanks!
>>>>> Rachel
>>>>>> Thanks!
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review this changeset that converts -XX:+TraceItables and -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>
>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/ <http://cr.openjdk.java.net/~rprotacio/8141564/> <http://cr.openjdk.java.net/%7Erprotacio/8141564/ <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564 <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>
>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp around 462-498 are a refactoring of the duplicate code from a conditional to a function with a boolean argument.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Rachel


From daniel.daugherty at oracle.com  Wed Jan  6 22:04:33 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 15:04:33 -0700
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568BE80F.7020600@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
	<568BE80F.7020600@oracle.com>
Message-ID: <568D8F71.4050702@oracle.com>

Not sure this is being tracked under the right bug ID:

JDK-8140593 Add configure parameter for devkit for the build compiler
https://bugs.openjdk.java.net/browse/JDK-8140593

and the above bug was resolved back on 2015.10.29.

Dan


On 1/5/16 8:58 AM, Yumin Qi wrote:
> Thanks Harold for quick review!
>
> On 1/5/2016 7:56 AM, harold seigel wrote:
>> Hi Yumin,
>>
>> Your change looks good.
>>
>> Thanks, Harold
>>
>> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>>> Thanks George,
>>>
>>>   Changed to current year.
>>>   Do I need a "R"eviewer for test only changes? If so I still need a 
>>> "R"eviewer gives a yes for push.
>>>
>>> Yumin
>>>
>>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>>> Hi Yumin,
>>>>
>>>> Your change looks good.
>>>>
>>>> One question, should you update the copyright year with this change?
>>>>
>>>> Thanks,
>>>>
>>>> Jerry
>>>>> Please review:
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>>
>>>>> Summary: Remove skip test bug 8044600, which is an one time 
>>>>> failure and never got reproduced on the only failed platform, 
>>>>> Solaris-sparc.
>>>>>
>>>>> Tests: JPRT
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>
>>>
>>
>
>


From coleen.phillimore at oracle.com  Wed Jan  6 22:14:40 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 6 Jan 2016 17:14:40 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <568D87CA.6000704@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<568D87CA.6000704@oracle.com>
Message-ID: <568D91D0.4070200@oracle.com>


I remember this change!  This came out very nice.  I agree that 
@ignore'ing the test until we figure out what's wrong with these tests 
on Windows is a good thing to do.

Thanks,
Coleen

On 1/6/16 4:31 PM, Rachel Protacio wrote:
> Hi,
>
> When I tried to commit this change, the ItablesTest was failing on 
> windows, so I've been trying to get to the bottom of that failure. As 
> other logging tests have recently proved themselves flaky on windows 
> as well, it seems to be a deeper issue. As such, I have added the 
> problem to https://bugs.openjdk.java.net/browse/JDK-8146435 for more 
> thorough investigation and ignored the ItablesTest for the time being.
>
> Here's my new webrev http://cr.openjdk.java.net/~rprotacio/8141564.03/ 
> which only differs from the previously approved code via the @ignore 
> line. The code passes JPRT.
>
> Thank you!
> Rachel
>
> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>> Rachel,
>>
>> Thank you for the updates.
>> Can you please sanity check one thing for me - the log_tables boolean 
>> ?overrides? appears to
>> be set correctly in the callers, to mean ?yes, this overrides?.
>> In log_vtables, is it possible the choice of what to print is reversed?
>>
>> And perhaps add a check to your tests for example that ?NOT 
>> overriding? catches the right case?
>>
>> And yes please on the assertion (I have seen null method bugs in 
>> development and this code is an early
>> opportunity to catch that problem).
>>
>> I don?t need to see an updated web rev and you don?t need to rerun 
>> all the tests to fix
>> the printed string.
>>
>> thanks,
>> Karen
>>
>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>>
>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>> Hi, Karen,
>>>>
>>>> Thanks for the review. Updated webrev: 
>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>
>>>> Since I never listed the tests I ran even the first time, here are 
>>>> all of them:
>>>>
>>>> * jtreg
>>>> * JPRT
>>>> * jck vm, lang, & api/java_lang
>>>> * rbt quick and non-colo (which now includes defmeth)
>>>> * invoke*
>>>>
>>>> Replies inline.
>>>>
>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>> Rachel,
>>>>>
>>>>> Thank you so much for doing (and redoing) this.
>>>>>
>>>>> Couple of questions/comments.
>>>>>
>>>>> 1. thank you so much for the transitive overriding test - not easy 
>>>>> to figure out how to generate one!
>>>>>
>>>> Lois walked me through doing that one :)
>>>>> 2. I missed the list of what you have tested for the first web rev 
>>>>> and the other tests for this one
>>>>> I will assume in parallel with the code review you are running 
>>>>> (without tracing)
>>>>> vm quick & nocolo, jck vm & lang
>>>>> defmeth, invoke*
>>>> Yeah, I totally forgot to email what tests I had run. Sorry about 
>>>> that! And just learned how to run the jck tests.
>>>>> There might be value in running your new tests with old tracing 
>>>>> vs. new and eyeballing the files - to see if they
>>>>> get essentially the same information.
>>>>>
>>>> Yup!
>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>> Would it make any sense to do if !klass()->is_array_klass() and 
>>>>> then just use the log_develop_debug and
>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>
>>>> That makes sense. Changed as suggested.
>>>>> 4. thank you so much for extracting the print_linkage_flags - I 
>>>>> should have done that earlier - the information
>>>>> just grew incrementally.
>>>>>
>>>>> 5. klassVtable.cpp line 1047 -
>>>>>    I think you want an if (m != NULL) here  before dereferencing 
>>>>> to print_linkage_flags.
>>>>>    I see we miss that check for other dereferences -feel free to 
>>>>> add small checks.
>>>>>    Don?t completely skip logic paragraphs except for printing ones.
>>>> Well, when I was making my change, we saw that it wouldn't be 
>>>> possible for m to be null at that point in the code. There are 
>>>> multiple places above it where it is dereferenced already, not to 
>>>> mention the fact that it is theoretically initialized to be a valid 
>>>> method. Would you like to me to add an assert after the declaration
>>>>     assert(m != NULL, "methods can never be null");
>>>> just to be safe?
>>> In the code here:
>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html> 
>>>
>>>
>>> Yes, Method* m = method->at(i); can never return NULL or else the 
>>> whole VM would crash everywhere.  I suspect the logging code here 
>>> was copied from other instances where 'm' could be null.   This line 
>>> would crash first:
>>>
>>> if (interface_method_needs_itable_index(m)) {
>>>
>>>
>>> Can you clean up this line also to not check for NULL:
>>>
>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() : 
>>> "<NULL>";
>>>
>>>
>>> And add the assert if Karen agrees if it's needed.
>>>
>>> The rest of the changes look good.   I don't need to see another 
>>> revision.
>>>
>>> Thanks,
>>> Coleen
>>>>>     Thank you for leaving the null check in fill_in_miranda and 
>>>>> print_method_at.
>>>>>
>>>>> 6. log_vtables
>>>>> The logic in update_inherited_vtables is quite complex.
>>>>> So the value of allocate_new is not really the right conditional 
>>>>> to pass in to determine if there
>>>>> was an override.
>>>>>    The first paragraph applies both for allocate_new=true and 
>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>
>>>>> So, perhaps you could add a boolean that says ?overrides? or 
>>>>> ?overriding? or whatever : default it to false, and set it to true 
>>>>> right after the put_method_at line (that iswhere the override 
>>>>> occurs) and set it to false in the ?else? clause?
>>>>> And pass that argument in to log_vtables ? And remove the 
>>>>> allocate_new comment from log_vtables as well?
>>>>>
>>>> Done, too.
>>>>
>>>> Thanks!!
>>>> Rachel
>>>>> And the comment in the ?else? is not accurate since I put the 
>>>>> package_private fix in - so removing
>>>>> it was a good idea.
>>>>>
>>>>> many thanks,
>>>>> Karen
>>>>>
>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio 
>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com> 
>>>>>> <mailto:rachel.protacio at oracle.com 
>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> Thanks for the comments! Updated 
>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/ 
>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and 
>>>>>> passes logging jtreg tests.)
>>>>>>
>>>>>> Replies inline.
>>>>>>
>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>> Rachel, There are a lot of changes here.  I have several 
>>>>>>> comments and more suggested cleanup that should be done with 
>>>>>>> this work.
>>>>>>>
>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>> 
>>>>>>>
>>>>>>>
>>>>>>> I did the original refactoring for trace_method_resolution. What 
>>>>>>> I think would be better is to make it an internal static 
>>>>>>> function in linkResolver.cpp and not defined in the 
>>>>>>> linkResolver.hpp.  Make the call unconditional and pass vtable 
>>>>>>> index in the last parameter as a default parameter with default 
>>>>>>> value -1 so the last line in the function is the tty->cr() that 
>>>>>>> I had outside the function call (that was pretty icky). And put 
>>>>>>> all the ResourceMark and logstream logic inside the 
>>>>>>> trace_method_resolution function.  It would never print to tty 
>>>>>>> so doesn't need an outputStream parameter for other callers.
>>>>>>>
>>>>>>> So there would be only the one line 
>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>> Thanks for the advice! I still have to call the function from 
>>>>>> within the conditional because it's develop level only and 
>>>>>> because I need to specify in the call whether it's for itables or 
>>>>>> vtables. Otherwise, I've followed your suggestions.
>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>> 
>>>>>>>
>>>>>>>
>>>>>>> Can you put these tags near each other?
>>>>>>>
>>>>>> I have them sorted alphabetically, which I think is more useful 
>>>>>> in the long run.
>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>> 
>>>>>>>
>>>>>>>
>>>>>>> One of the things that Markus Gronlund's made me think that we 
>>>>>>> should do with his cleanup is to stop declaring functions as 
>>>>>>> members of classes if they don't need external linkage. From his 
>>>>>>> RFR(L): 8140485: Class load and creation clean up:
>>>>>>>
>>>>>>> "Comment: In my opinion, we should attempt to break the pattern 
>>>>>>> of having private functions declared in header files when the 
>>>>>>> private function does not need to reach inside "this"."
>>>>>>>
>>>>>>> I think the function log_vtables should follow this and be 
>>>>>>> declared as a static internal function in klassVtable.cpp above 
>>>>>>> the function where it's used.
>>>>>>>
>>>>>>> It's true that you don't see this very much in the hotspot sources.
>>>>>>>
>>>>>>> The refactoring of log_vtables is good and very much appreciated.
>>>>>>>
>>>>>>> In each of the logging blocks of code, there are about 6 lines 
>>>>>>> that are about the same, that print the access flags and whether 
>>>>>>> it's a default or overpass method. (Karen and Lois should give 
>>>>>>> you a TOI about what that means!)  Can you add a method to 
>>>>>>> method.hpp that's something like print_flags(outputStream* st) 
>>>>>>> and move this printing there, and make those blocks call your 
>>>>>>> new function?  That would shorten many of these logging blocks 
>>>>>>> of code and would be nice.  You could call this from the 
>>>>>>> linkResolver.cpp trace_method_resolution() function too.
>>>>>> Done.
>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>> 
>>>>>>>
>>>>>>>
>>>>>>> These classes have missing copyrights.
>>>>>> Fixed.
>>>>>> Thanks!
>>>>>> Rachel
>>>>>>> Thanks!
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review this changeset that converts -XX:+TraceItables 
>>>>>>>> and -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>
>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/ 
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/> 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>
>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp 
>>>>>>>> around 462-498 are a refactoring of the duplicate code from a 
>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Rachel
>


From daniel.daugherty at oracle.com  Wed Jan  6 22:18:19 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 15:18:19 -0700
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568D8F71.4050702@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
	<568BE80F.7020600@oracle.com> <568D8F71.4050702@oracle.com>
Message-ID: <568D92AB.8010509@oracle.com>

Looks like this is the right one:

JDK-8145093 [TESTBUG] Remove test skip code for Solaris SPARC in 
runtime/SharedArchiveFile/SharedBaseAddress.java
https://bugs.openjdk.java.net/browse/JDK-8145093

Dan


On 1/6/16 3:04 PM, Daniel D. Daugherty wrote:
> Not sure this is being tracked under the right bug ID:
>
> JDK-8140593 Add configure parameter for devkit for the build compiler
> https://bugs.openjdk.java.net/browse/JDK-8140593
>
> and the above bug was resolved back on 2015.10.29.
>
> Dan
>
>
> On 1/5/16 8:58 AM, Yumin Qi wrote:
>> Thanks Harold for quick review!
>>
>> On 1/5/2016 7:56 AM, harold seigel wrote:
>>> Hi Yumin,
>>>
>>> Your change looks good.
>>>
>>> Thanks, Harold
>>>
>>> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>>>> Thanks George,
>>>>
>>>>   Changed to current year.
>>>>   Do I need a "R"eviewer for test only changes? If so I still need 
>>>> a "R"eviewer gives a yes for push.
>>>>
>>>> Yumin
>>>>
>>>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> Your change looks good.
>>>>>
>>>>> One question, should you update the copyright year with this change?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jerry
>>>>>> Please review:
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>>>
>>>>>> Summary: Remove skip test bug 8044600, which is an one time 
>>>>>> failure and never got reproduced on the only failed platform, 
>>>>>> Solaris-sparc.
>>>>>>
>>>>>> Tests: JPRT
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>
>>>>
>>>
>>
>>
>


From daniel.daugherty at oracle.com  Wed Jan  6 23:05:36 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 16:05:36 -0700
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <568C53D7.6030106@oracle.com>
References: <56784A53.5090203@oracle.com> <568C51B5.5030300@oracle.com>
	<568C53D7.6030106@oracle.com>
Message-ID: <568D9DC0.4090503@oracle.com>

On 1/5/16 4:37 PM, Yumin Qi wrote:
> On 1/5/2016 3:28 PM, Daniel D. Daugherty wrote:
>> On 12/21/15 11:52 AM, Yumin Qi wrote:
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>
>>> This is REDO for bug 8087223, which was backed out due to failed on 
>>> 8143317 and 8143320.
>>> The defmeth encoutered new failures after the fix, which now has 
>>> correct constant tags. The test bugs will be addressed in 8143320, 
>>> which based on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>
>>> One difference from the attached for this webrev is that in 
>>> MethodHandle resolution, I relax the check for one specific case: 
>>> Using MethodHandle to invoke static default interface method. In 
>>> this case, we must use invokestatic (JVM_REF_invokeStatic), which in 
>>> defmeth it will generate method tag for interface which violates 
>>> JVMS-5.4.3.3 (it should create interface method tag!). ASM currently 
>>> has no API to generate invokeinterface for a interface static 
>>> default method through MethodHandle invocation.
>>>
>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>> Note the fix still fails 8143320 and 8143317 which are not fixed at 
>>> the momment.
>>
>> Are the failing tests quarantined? When this fix is pushed,
>> neither the "new" or "known" failures counts should increase.
>>
> Do you mean 'RULE' out in bugs? No.

No I do not mean 'RULE' entries. A 'RULE' entry will make a test
failure show up as "known" and that is not what should happen here.

You are changing product code in such a way that existing tests
will fail. Yes, the tests need to be fixed, but we should not
bother to run those tests until they are fixed. This is what
'quarantine' is all about.

For JavaTest/JTREG tests, tests are quarantined by adding an
"@ignore NNNNNNN" entry to the test. For Tonga tests, I believe
the test list has to updated to include the quarantine keyword,
but that could have changed.

Please coordinate with one of our SQE folks to make sure that
the affected tests are quarantined before you push this fix.

8143320 covers vm.defmeth tests so that's Tonga.
8143317 covers tests in the JDK repo so that's JavaTest/JTREG.

So it looks like you need to work with SQE to get both Tonga
and JavaTest/JTREG tests quarantined.

Dan


> So after the fix pushed, it still fails on the tests --- but will pass 
> after 8143320 pushed to vm repo. It is not clear for me:
>
> after 8145148(this) pushed to hs-rt, the tests will fail as before.
> after 8143320 pushed to vm (sqe), hs-rt will pass, but hs-comp will 
> fail since I changed defmeth!
>
> As for 8143317, so far not assigned --- in jdk group.
>
> Thanks
> Yumin
>
>> Dan
>>
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> Original post:
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>
>>> According to JVMS-8:
>>>
>>> JVMS-5.4.3.3 Method Resolution:
>>>  " If C is an interface, method resolution throws an 
>>> IncompatibleClassChangeError."
>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>  "If C is not an interface, interface method resolution throws an 
>>> IncompatibleClassChangeError"
>>>
>>> When invoke a method with resolved to an interface method, or invoke 
>>> a interface method with resolved to an instance method, ICCE should 
>>> be thrown. The case usually happens when using tools like asmtools 
>>> or jdk.internal.org.objectweb.asm to generate java bytecode.
>>>
>>> The fix is carrying the constantTag for the method at call and check 
>>> if tag is consistent with the method called. Doing this by adding a 
>>> member of constantTag, _tag,  to LinkInfo, and check tag in resolve 
>>> functions to see if tag matched with the correct method.
>>>
>>> The fix solved the problem when call is from interpreter and 
>>> compiler, bug for MethodHandle invoke, which should be addressed in 
>>> another bug,  since the MethodHandle does not come with a byte 
>>> stream and getting the constant pool index at the invoke is not 
>>> possible.  It will be addressed in another bug.
>>>
>>> Tests: test case (added, minor modified from bug), JPRT, rutime 
>>> quick test list(in progress).
>>> manually tested:  1) -Xint
>>>                                2) -Xcomp
>>>                                3) -Xcomp -XX:-TieredCompiltion
>>>                                4) -Xcomp -XX:+TieredCompilation
>>>
>>> Thanks to Coleen for helping fixed constant pool index and cleaned 
>>> LinkInfo.
>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>> Second revision attached.
>>>
>>>
>>>
>>>
>>> Thanks
>>> Yumin
>>
>


From coleen.phillimore at oracle.com  Wed Jan  6 23:08:25 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 6 Jan 2016 18:08:25 -0500
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <568D9DC0.4090503@oracle.com>
References: <56784A53.5090203@oracle.com> <568C51B5.5030300@oracle.com>
	<568C53D7.6030106@oracle.com> <568D9DC0.4090503@oracle.com>
Message-ID: <568D9E69.1080508@oracle.com>



On 1/6/16 6:05 PM, Daniel D. Daugherty wrote:
> On 1/5/16 4:37 PM, Yumin Qi wrote:
>> On 1/5/2016 3:28 PM, Daniel D. Daugherty wrote:
>>> On 12/21/15 11:52 AM, Yumin Qi wrote:
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>>
>>>> This is REDO for bug 8087223, which was backed out due to failed on 
>>>> 8143317 and 8143320.
>>>> The defmeth encoutered new failures after the fix, which now has 
>>>> correct constant tags. The test bugs will be addressed in 8143320, 
>>>> which based on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>>
>>>> One difference from the attached for this webrev is that in 
>>>> MethodHandle resolution, I relax the check for one specific case: 
>>>> Using MethodHandle to invoke static default interface method. In 
>>>> this case, we must use invokestatic (JVM_REF_invokeStatic), which 
>>>> in defmeth it will generate method tag for interface which violates 
>>>> JVMS-5.4.3.3 (it should create interface method tag!). ASM 
>>>> currently has no API to generate invokeinterface for a interface 
>>>> static default method through MethodHandle invocation.
>>>>
>>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>>> Note the fix still fails 8143320 and 8143317 which are not fixed at 
>>>> the momment.
>>>
>>> Are the failing tests quarantined? When this fix is pushed,
>>> neither the "new" or "known" failures counts should increase.
>>>
>> Do you mean 'RULE' out in bugs? No.
>
> No I do not mean 'RULE' entries. A 'RULE' entry will make a test
> failure show up as "known" and that is not what should happen here.
>
> You are changing product code in such a way that existing tests
> will fail. Yes, the tests need to be fixed, but we should not
> bother to run those tests until they are fixed. This is what
> 'quarantine' is all about.
>
> For JavaTest/JTREG tests, tests are quarantined by adding an
> "@ignore NNNNNNN" entry to the test. For Tonga tests, I believe
> the test list has to updated to include the quarantine keyword,
> but that could have changed.
>
> Please coordinate with one of our SQE folks to make sure that
> the affected tests are quarantined before you push this fix.
>
> 8143320 covers vm.defmeth tests so that's Tonga.
> 8143317 covers tests in the JDK repo so that's JavaTest/JTREG.
>
> So it looks like you need to work with SQE to get both Tonga
> and JavaTest/JTREG tests quarantined.

I thought Yumin had a fix for the tonga tests and was in the process of 
pushing it, and he should fix the JDK tests before pushing this.

Coleen

>
> Dan
>
>
>> So after the fix pushed, it still fails on the tests --- but will 
>> pass after 8143320 pushed to vm repo. It is not clear for me:
>>
>> after 8145148(this) pushed to hs-rt, the tests will fail as before.
>> after 8143320 pushed to vm (sqe), hs-rt will pass, but hs-comp will 
>> fail since I changed defmeth!
>>
>> As for 8143317, so far not assigned --- in jdk group.
>>
>> Thanks
>> Yumin
>>
>>> Dan
>>>
>>>
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> Original post:
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>>
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>>
>>>> According to JVMS-8:
>>>>
>>>> JVMS-5.4.3.3 Method Resolution:
>>>>  " If C is an interface, method resolution throws an 
>>>> IncompatibleClassChangeError."
>>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>>  "If C is not an interface, interface method resolution throws an 
>>>> IncompatibleClassChangeError"
>>>>
>>>> When invoke a method with resolved to an interface method, or 
>>>> invoke a interface method with resolved to an instance method, ICCE 
>>>> should be thrown. The case usually happens when using tools like 
>>>> asmtools or jdk.internal.org.objectweb.asm to generate java bytecode.
>>>>
>>>> The fix is carrying the constantTag for the method at call and 
>>>> check if tag is consistent with the method called. Doing this by 
>>>> adding a member of constantTag, _tag,  to LinkInfo, and check tag 
>>>> in resolve functions to see if tag matched with the correct method.
>>>>
>>>> The fix solved the problem when call is from interpreter and 
>>>> compiler, bug for MethodHandle invoke, which should be addressed in 
>>>> another bug,  since the MethodHandle does not come with a byte 
>>>> stream and getting the constant pool index at the invoke is not 
>>>> possible.  It will be addressed in another bug.
>>>>
>>>> Tests: test case (added, minor modified from bug), JPRT, rutime 
>>>> quick test list(in progress).
>>>> manually tested:  1) -Xint
>>>>                                2) -Xcomp
>>>>                                3) -Xcomp -XX:-TieredCompiltion
>>>>                                4) -Xcomp -XX:+TieredCompilation
>>>>
>>>> Thanks to Coleen for helping fixed constant pool index and cleaned 
>>>> LinkInfo.
>>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>>
>>>>
>>>> Second revision attached.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>
>>
>


From daniel.daugherty at oracle.com  Wed Jan  6 23:26:01 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 16:26:01 -0700
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <568D9E69.1080508@oracle.com>
References: <56784A53.5090203@oracle.com> <568C51B5.5030300@oracle.com>
	<568C53D7.6030106@oracle.com> <568D9DC0.4090503@oracle.com>
	<568D9E69.1080508@oracle.com>
Message-ID: <568DA289.2070506@oracle.com>

On 1/6/16 4:08 PM, Coleen Phillimore wrote:
>
>
> On 1/6/16 6:05 PM, Daniel D. Daugherty wrote:
>> On 1/5/16 4:37 PM, Yumin Qi wrote:
>>> On 1/5/2016 3:28 PM, Daniel D. Daugherty wrote:
>>>> On 12/21/15 11:52 AM, Yumin Qi wrote:
>>>>> Please review:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>>>
>>>>> This is REDO for bug 8087223, which was backed out due to failed 
>>>>> on 8143317 and 8143320.
>>>>> The defmeth encoutered new failures after the fix, which now has 
>>>>> correct constant tags. The test bugs will be addressed in 8143320, 
>>>>> which based on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>>>
>>>>> One difference from the attached for this webrev is that in 
>>>>> MethodHandle resolution, I relax the check for one specific case: 
>>>>> Using MethodHandle to invoke static default interface method. In 
>>>>> this case, we must use invokestatic (JVM_REF_invokeStatic), which 
>>>>> in defmeth it will generate method tag for interface which 
>>>>> violates JVMS-5.4.3.3 (it should create interface method tag!). 
>>>>> ASM currently has no API to generate invokeinterface for a 
>>>>> interface static default method through MethodHandle invocation.
>>>>>
>>>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>>>> Note the fix still fails 8143320 and 8143317 which are not fixed 
>>>>> at the momment.
>>>>
>>>> Are the failing tests quarantined? When this fix is pushed,
>>>> neither the "new" or "known" failures counts should increase.
>>>>
>>> Do you mean 'RULE' out in bugs? No.
>>
>> No I do not mean 'RULE' entries. A 'RULE' entry will make a test
>> failure show up as "known" and that is not what should happen here.
>>
>> You are changing product code in such a way that existing tests
>> will fail. Yes, the tests need to be fixed, but we should not
>> bother to run those tests until they are fixed. This is what
>> 'quarantine' is all about.
>>
>> For JavaTest/JTREG tests, tests are quarantined by adding an
>> "@ignore NNNNNNN" entry to the test. For Tonga tests, I believe
>> the test list has to updated to include the quarantine keyword,
>> but that could have changed.
>>
>> Please coordinate with one of our SQE folks to make sure that
>> the affected tests are quarantined before you push this fix.
>>
>> 8143320 covers vm.defmeth tests so that's Tonga.
>> 8143317 covers tests in the JDK repo so that's JavaTest/JTREG.
>>
>> So it looks like you need to work with SQE to get both Tonga
>> and JavaTest/JTREG tests quarantined.
>
> I thought Yumin had a fix for the tonga tests and was in the process 
> of pushing it, and he should fix the JDK tests before pushing this.

I don't think so... :-(

Dan


>
> Coleen
>
>>
>> Dan
>>
>>
>>> So after the fix pushed, it still fails on the tests --- but will 
>>> pass after 8143320 pushed to vm repo. It is not clear for me:
>>>
>>> after 8145148(this) pushed to hs-rt, the tests will fail as before.
>>> after 8143320 pushed to vm (sqe), hs-rt will pass, but hs-comp will 
>>> fail since I changed defmeth!
>>>
>>> As for 8143317, so far not assigned --- in jdk group.
>>>
>>> Thanks
>>> Yumin
>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>> Original post:
>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>>>
>>>>> Please review:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>>>
>>>>> According to JVMS-8:
>>>>>
>>>>> JVMS-5.4.3.3 Method Resolution:
>>>>>  " If C is an interface, method resolution throws an 
>>>>> IncompatibleClassChangeError."
>>>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>>>  "If C is not an interface, interface method resolution throws an 
>>>>> IncompatibleClassChangeError"
>>>>>
>>>>> When invoke a method with resolved to an interface method, or 
>>>>> invoke a interface method with resolved to an instance method, 
>>>>> ICCE should be thrown. The case usually happens when using tools 
>>>>> like asmtools or jdk.internal.org.objectweb.asm to generate java 
>>>>> bytecode.
>>>>>
>>>>> The fix is carrying the constantTag for the method at call and 
>>>>> check if tag is consistent with the method called. Doing this by 
>>>>> adding a member of constantTag, _tag,  to LinkInfo, and check tag 
>>>>> in resolve functions to see if tag matched with the correct method.
>>>>>
>>>>> The fix solved the problem when call is from interpreter and 
>>>>> compiler, bug for MethodHandle invoke, which should be addressed 
>>>>> in another bug,  since the MethodHandle does not come with a byte 
>>>>> stream and getting the constant pool index at the invoke is not 
>>>>> possible.  It will be addressed in another bug.
>>>>>
>>>>> Tests: test case (added, minor modified from bug), JPRT, rutime 
>>>>> quick test list(in progress).
>>>>> manually tested:  1) -Xint
>>>>>                                2) -Xcomp
>>>>>                                3) -Xcomp -XX:-TieredCompiltion
>>>>>                                4) -Xcomp -XX:+TieredCompilation
>>>>>
>>>>> Thanks to Coleen for helping fixed constant pool index and cleaned 
>>>>> LinkInfo.
>>>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> Second revision attached.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>
>>>
>>
>


From ron.durbin at oracle.com  Wed Jan  6 23:39:26 2016
From: ron.durbin at oracle.com (Ron Durbin)
Date: Wed, 6 Jan 2016 15:39:26 -0800 (PST)
Subject: RFR (S) round 0 for 8135198  Add -XX:VMOptionsFile support to
	JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
Message-ID: <ec063228-9fef-4beb-848e-d0a71055dc16@default>

This change adds -XX:VMOptionsFile support to the JAVA_TOOL_OPTIONS
and _JAVA_OPTIONS environment variables. With this change, the
-XX:VMOptionsFile option is supported in the following option
containers:

- the command line
- JAVA_TOOL_OPTIONS env var
- _JAVA_OPTIONS env var

Webrev:
   http://cr.openjdk.java.net/~rdurbin/8135198_OCR0_JDK9_webrev

Bug report:
   https://bugs.openjdk.java.net/browse/JDK-8135198

This bug fix has been tested on:
     OS:
       Solaris, MAC, Windows, Linux
     Tests:
       Manual unit tests
       JPRT with -testset hotspot(including the SQE current test coverage for this feature.)


From daniel.daugherty at oracle.com  Wed Jan  6 23:47:07 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 16:47:07 -0700
Subject: RFR (S) round 0 for 8135198 Add -XX:VMOptionsFile support to
	JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
In-Reply-To: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
References: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
Message-ID: <568DA77B.2060301@oracle.com>

On 1/6/16 4:39 PM, Ron Durbin wrote:
> This change adds -XX:VMOptionsFile support to the JAVA_TOOL_OPTIONS
> and _JAVA_OPTIONS environment variables. With this change, the
> -XX:VMOptionsFile option is supported in the following option
> containers:
>
> - the command line
> - JAVA_TOOL_OPTIONS env var
> - _JAVA_OPTIONS env var
>
> Webrev:
>     http://cr.openjdk.java.net/~rdurbin/8135198_OCR0_JDK9_webrev

src/share/vm/runtime/arguments.cpp
     No comments.

src/share/vm/runtime/arguments.hpp
     No comments.

test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
     No comments.

Thumbs up!

Compared this patch with the one from JDK-8135198_PCR4_JDK9_webrev
and they match modulo line numbers and time stamps.

Dan


>
> Bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8135198
>
> This bug fix has been tested on:
>       OS:
>         Solaris, MAC, Windows, Linux
>       Tests:
>         Manual unit tests
>         JPRT with -testset hotspot(including the SQE current test coverage for this feature.)
>


From yumin.qi at oracle.com  Thu Jan  7 00:06:34 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 06 Jan 2016 16:06:34 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568D92AB.8010509@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
	<568BE80F.7020600@oracle.com> <568D8F71.4050702@oracle.com>
	<568D92AB.8010509@oracle.com>
Message-ID: <568DAC0A.4060009@oracle.com>

Thanks Dan, a typo after new year with too much food(?). I used the 
right one for push.

# HG changeset patch
# User minqi
# Date 1452018994 28800
#      Tue Jan 05 10:36:34 2016 -0800
# Node ID f51772bf53829805f33f28c0603d18cf3d3dd8c5
# Parent  756bb5cfc5cb6763d481f5334fcdfa63ec95300d
8145093: [TESTBUG] Remove test skip code for Solaris SPARC in 
runtime/SharedArchiveFile/SharedBaseAddress.java
Summary: The test failed(see bug 8044600) once on sparc platform which 
never reproduced thereafter, remove the skip.
Reviewed-by: hseigel, iklam, gtriantafill

diff -r 756bb5cfc5cb -r f51772bf5382 
test/runtime/SharedArchiveFile/SharedBaseAddress.java
--- a/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
17:05:13 2016 -0800
+++ b/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
10:36:34 2016 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -43,10 +43,6 @@
      };

      public static void main(String[] args) throws Exception {
-        // Known issue on Solaris-Sparc
-        // @ignore JDK-8044600
-        if (Platform.isSolaris() && Platform.isSparc())
-            return;

          for (String testEntry : testTable) {
              String filename = "SharedBaseAddress" + testEntry + ".jsa";

I will rename the webrev.

Thanks
Yumin



On 1/6/2016 2:18 PM, Daniel D. Daugherty wrote:
> Looks like this is the right one:
>
> JDK-8145093 [TESTBUG] Remove test skip code for Solaris SPARC in 
> runtime/SharedArchiveFile/SharedBaseAddress.java
> https://bugs.openjdk.java.net/browse/JDK-8145093
>
> Dan
>
>
> On 1/6/16 3:04 PM, Daniel D. Daugherty wrote:
>> Not sure this is being tracked under the right bug ID:
>>
>> JDK-8140593 Add configure parameter for devkit for the build compiler
>> https://bugs.openjdk.java.net/browse/JDK-8140593
>>
>> and the above bug was resolved back on 2015.10.29.
>>
>> Dan
>>
>>
>> On 1/5/16 8:58 AM, Yumin Qi wrote:
>>> Thanks Harold for quick review!
>>>
>>> On 1/5/2016 7:56 AM, harold seigel wrote:
>>>> Hi Yumin,
>>>>
>>>> Your change looks good.
>>>>
>>>> Thanks, Harold
>>>>
>>>> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>>>>> Thanks George,
>>>>>
>>>>>   Changed to current year.
>>>>>   Do I need a "R"eviewer for test only changes? If so I still need 
>>>>> a "R"eviewer gives a yes for push.
>>>>>
>>>>> Yumin
>>>>>
>>>>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>>>>> Hi Yumin,
>>>>>>
>>>>>> Your change looks good.
>>>>>>
>>>>>> One question, should you update the copyright year with this change?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jerry
>>>>>>> Please review:
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>>>>
>>>>>>> Summary: Remove skip test bug 8044600, which is an one time 
>>>>>>> failure and never got reproduced on the only failed platform, 
>>>>>>> Solaris-sparc.
>>>>>>>
>>>>>>> Tests: JPRT
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


From yumin.qi at oracle.com  Thu Jan  7 00:11:41 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 06 Jan 2016 16:11:41 -0800
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568DAC0A.4060009@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
	<568BE80F.7020600@oracle.com> <568D8F71.4050702@oracle.com>
	<568D92AB.8010509@oracle.com> <568DAC0A.4060009@oracle.com>
Message-ID: <568DAD3D.3020206@oracle.com>

Sigh... subject typo only .

Thanks
Yumin

On 1/6/2016 4:06 PM, Yumin Qi wrote:
> Thanks Dan, a typo after new year with too much food(?). I used the 
> right one for push.
>
> # HG changeset patch
> # User minqi
> # Date 1452018994 28800
> #      Tue Jan 05 10:36:34 2016 -0800
> # Node ID f51772bf53829805f33f28c0603d18cf3d3dd8c5
> # Parent  756bb5cfc5cb6763d481f5334fcdfa63ec95300d
> 8145093: [TESTBUG] Remove test skip code for Solaris SPARC in 
> runtime/SharedArchiveFile/SharedBaseAddress.java
> Summary: The test failed(see bug 8044600) once on sparc platform which 
> never reproduced thereafter, remove the skip.
> Reviewed-by: hseigel, iklam, gtriantafill
>
> diff -r 756bb5cfc5cb -r f51772bf5382 
> test/runtime/SharedArchiveFile/SharedBaseAddress.java
> --- a/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
> 17:05:13 2016 -0800
> +++ b/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
> 10:36:34 2016 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -43,10 +43,6 @@
>      };
>
>      public static void main(String[] args) throws Exception {
> -        // Known issue on Solaris-Sparc
> -        // @ignore JDK-8044600
> -        if (Platform.isSolaris() && Platform.isSparc())
> -            return;
>
>          for (String testEntry : testTable) {
>              String filename = "SharedBaseAddress" + testEntry + ".jsa";
>
> I will rename the webrev.
>
> Thanks
> Yumin
>
>
>
> On 1/6/2016 2:18 PM, Daniel D. Daugherty wrote:
>> Looks like this is the right one:
>>
>> JDK-8145093 [TESTBUG] Remove test skip code for Solaris SPARC in 
>> runtime/SharedArchiveFile/SharedBaseAddress.java
>> https://bugs.openjdk.java.net/browse/JDK-8145093
>>
>> Dan
>>
>>
>> On 1/6/16 3:04 PM, Daniel D. Daugherty wrote:
>>> Not sure this is being tracked under the right bug ID:
>>>
>>> JDK-8140593 Add configure parameter for devkit for the build compiler
>>> https://bugs.openjdk.java.net/browse/JDK-8140593
>>>
>>> and the above bug was resolved back on 2015.10.29.
>>>
>>> Dan
>>>
>>>
>>> On 1/5/16 8:58 AM, Yumin Qi wrote:
>>>> Thanks Harold for quick review!
>>>>
>>>> On 1/5/2016 7:56 AM, harold seigel wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> Your change looks good.
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>>>>>> Thanks George,
>>>>>>
>>>>>>   Changed to current year.
>>>>>>   Do I need a "R"eviewer for test only changes? If so I still 
>>>>>> need a "R"eviewer gives a yes for push.
>>>>>>
>>>>>> Yumin
>>>>>>
>>>>>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>>>>>> Hi Yumin,
>>>>>>>
>>>>>>> Your change looks good.
>>>>>>>
>>>>>>> One question, should you update the copyright year with this 
>>>>>>> change?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jerry
>>>>>>>> Please review:
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>>>>>
>>>>>>>> Summary: Remove skip test bug 8044600, which is an one time 
>>>>>>>> failure and never got reproduced on the only failed platform, 
>>>>>>>> Solaris-sparc.
>>>>>>>>
>>>>>>>> Tests: JPRT
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>


From daniel.daugherty at oracle.com  Thu Jan  7 00:12:27 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 6 Jan 2016 17:12:27 -0700
Subject: RFR(XS): 8140593: [TESTBUG] Remove test skip code for Solaris
	SPARC in runtime/SharedArchiveFile/SharedBaseAddress.java
In-Reply-To: <568DAC0A.4060009@oracle.com>
References: <568B2CBB.3040803@oracle.com> <568BD36C.2090200@oracle.com>
	<568BE685.8090508@oracle.com> <568BE7AC.3010001@oracle.com>
	<568BE80F.7020600@oracle.com> <568D8F71.4050702@oracle.com>
	<568D92AB.8010509@oracle.com> <568DAC0A.4060009@oracle.com>
Message-ID: <568DAD6B.5070102@oracle.com>

Thanks for the clarification!

Dan


On 1/6/16 5:06 PM, Yumin Qi wrote:
> Thanks Dan, a typo after new year with too much food(?). I used the 
> right one for push.
>
> # HG changeset patch
> # User minqi
> # Date 1452018994 28800
> #      Tue Jan 05 10:36:34 2016 -0800
> # Node ID f51772bf53829805f33f28c0603d18cf3d3dd8c5
> # Parent  756bb5cfc5cb6763d481f5334fcdfa63ec95300d
> 8145093: [TESTBUG] Remove test skip code for Solaris SPARC in 
> runtime/SharedArchiveFile/SharedBaseAddress.java
> Summary: The test failed(see bug 8044600) once on sparc platform which 
> never reproduced thereafter, remove the skip.
> Reviewed-by: hseigel, iklam, gtriantafill
>
> diff -r 756bb5cfc5cb -r f51772bf5382 
> test/runtime/SharedArchiveFile/SharedBaseAddress.java
> --- a/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
> 17:05:13 2016 -0800
> +++ b/test/runtime/SharedArchiveFile/SharedBaseAddress.java Tue Jan 05 
> 10:36:34 2016 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -43,10 +43,6 @@
>      };
>
>      public static void main(String[] args) throws Exception {
> -        // Known issue on Solaris-Sparc
> -        // @ignore JDK-8044600
> -        if (Platform.isSolaris() && Platform.isSparc())
> -            return;
>
>          for (String testEntry : testTable) {
>              String filename = "SharedBaseAddress" + testEntry + ".jsa";
>
> I will rename the webrev.
>
> Thanks
> Yumin
>
>
>
> On 1/6/2016 2:18 PM, Daniel D. Daugherty wrote:
>> Looks like this is the right one:
>>
>> JDK-8145093 [TESTBUG] Remove test skip code for Solaris SPARC in 
>> runtime/SharedArchiveFile/SharedBaseAddress.java
>> https://bugs.openjdk.java.net/browse/JDK-8145093
>>
>> Dan
>>
>>
>> On 1/6/16 3:04 PM, Daniel D. Daugherty wrote:
>>> Not sure this is being tracked under the right bug ID:
>>>
>>> JDK-8140593 Add configure parameter for devkit for the build compiler
>>> https://bugs.openjdk.java.net/browse/JDK-8140593
>>>
>>> and the above bug was resolved back on 2015.10.29.
>>>
>>> Dan
>>>
>>>
>>> On 1/5/16 8:58 AM, Yumin Qi wrote:
>>>> Thanks Harold for quick review!
>>>>
>>>> On 1/5/2016 7:56 AM, harold seigel wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> Your change looks good.
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 1/5/2016 10:51 AM, Yumin Qi wrote:
>>>>>> Thanks George,
>>>>>>
>>>>>>   Changed to current year.
>>>>>>   Do I need a "R"eviewer for test only changes? If so I still 
>>>>>> need a "R"eviewer gives a yes for push.
>>>>>>
>>>>>> Yumin
>>>>>>
>>>>>> On 1/5/2016 6:30 AM, Gerald Thornbrugh wrote:
>>>>>>> Hi Yumin,
>>>>>>>
>>>>>>> Your change looks good.
>>>>>>>
>>>>>>> One question, should you update the copyright year with this 
>>>>>>> change?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jerry
>>>>>>>> Please review:
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145093
>>>>>>>> Webrev: http://cr.openjdk.java.net/~minqi/8145093/webrev-01/
>>>>>>>>
>>>>>>>> Summary: Remove skip test bug 8044600, which is an one time 
>>>>>>>> failure and never got reproduced on the only failed platform, 
>>>>>>>> Solaris-sparc.
>>>>>>>>
>>>>>>>> Tests: JPRT
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>


From jiangli.zhou at oracle.com  Thu Jan  7 00:54:02 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 6 Jan 2016 16:54:02 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568CB531.5080608@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
Message-ID: <4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>

Hi David,

> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Jiangli,
> 
> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>> Hi,
>> 
>> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>> 
>>   http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>> 
>> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().
> 
> I find this very confusing. Is there some document that describes the relationship between mapping, reserving and committing virtual memory and the related NMT functionality?

I agree. This is very confusing. I haven?t come across any document explaining the usage of the NMT APIs in different scenarios. My understand is based on reading the related code.

> It is not at all clear to me why reserve_and_commit pairs with uncommit (unless committed memory must first be reserved, and uncommit both uncommits and "unreserves" ??)

I dug deeper into it and found more issues. It appears MemTracker::record_virtual_memory_reserve_and_commit() should record the memory as both ?reserved? and ?committed?. However, that only happens if the memory region is not known by the VirtualMemoryTracker. If the memory overlaps with a known region in the VirtualMemoryTracker, MemTracker::record_virtual_memory_reserve_and_commit() could be a ?nop' in certain case. In the bug revealed by the specific test scenario, the memory region causing the issue is the CDS shared memory. Here are the call sequences related to the shared memory region:

1. ReservedSpace::ReservedSpace - reserve the memory for shared region. VirtualMemorySummary::record_reserved_memory is called and the memory is recored as ?reserved?.
2.os::map_memory - each shared space within the shared memory region is mapped. MemTracker::record_virtual_memory_reserve_and_commit is called, the memory is not recounted. So the shared memory region is only counted as ?reserved? in NMT by previous VirtualMemorySummary::record_reserved_memory call.
3.os::unmap_memory - record each shared space within the shared memory region with virtual_memory_release_tracker
4 ReservedSpace::release (calls os::release_memory) - the virtual_memory_release_tracker is used again for the shared memory region.

On linux and all other non-windows platform, os::unmap_memory only unmap the memory (by calling system munmap) without ?release? the memory. On windows, unmap_memory also does ?release?.

So, there are at lease two issues:

The shared memory region is not recorded as ?committed?.
The shared memory region is counted twice as ?released?.
Thanks,
Jiangli

> 
> Thanks,
> David
> -----
> 
>> Tested with test/runtime/NMT.
>> 
>> Thanks,
>> Jiangli
>> 
>> 
>> 


From coleen.phillimore at oracle.com  Thu Jan  7 02:04:36 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 6 Jan 2016 21:04:36 -0500
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
Message-ID: <568DC7B4.1020403@oracle.com>



On 1/6/16 7:54 PM, Jiangli Zhou wrote:
> Hi David,
>
>> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Jiangli,
>>
>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>
>>>    http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>
>>> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().
>> I find this very confusing. Is there some document that describes the relationship between mapping, reserving and committing virtual memory and the related NMT functionality?
> I agree. This is very confusing. I haven?t come across any document explaining the usage of the NMT APIs in different scenarios. My understand is based on reading the related code.
>
>> It is not at all clear to me why reserve_and_commit pairs with uncommit (unless committed memory must first be reserved, and uncommit both uncommits and "unreserves" ??)
> I dug deeper into it and found more issues. It appears MemTracker::record_virtual_memory_reserve_and_commit() should record the memory as both ?reserved? and ?committed?. However, that only happens if the memory region is not known by the VirtualMemoryTracker. If the memory overlaps with a known region in the VirtualMemoryTracker, MemTracker::record_virtual_memory_reserve_and_commit() could be a ?nop' in certain case. In the bug revealed by the specific test scenario, the memory region causing the issue is the CDS shared memory. Here are the call sequences related to the shared memory region:
>
> 1. ReservedSpace::ReservedSpace - reserve the memory for shared region. VirtualMemorySummary::record_reserved_memory is called and the memory is recored as ?reserved?.
> 2.os::map_memory - each shared space within the shared memory region is mapped. MemTracker::record_virtual_memory_reserve_and_commit is called, the memory is not recounted. So the shared memory region is only counted as ?reserved? in NMT by previous VirtualMemorySummary::record_reserved_memory call.
> 3.os::unmap_memory - record each shared space within the shared memory region with virtual_memory_release_tracker
> 4 ReservedSpace::release (calls os::release_memory) - the virtual_memory_release_tracker is used again for the shared memory region.
>
> On linux and all other non-windows platform, os::unmap_memory only unmap the memory (by calling system munmap) without ?release? the memory. On windows, unmap_memory also does ?release?.

Yes, this is the difference between windows and unix machines.  I think 
NMT was developed on windows.
>
> So, there are at lease two issues:
>
> The shared memory region is not recorded as ?committed?.

File a P4 bug on this because I don't think it causes any crashes. I 
think it may under count the amount of committed memory.   We can 
investigate.

> The shared memory region is counted twice as ?released?.

Your change conditionalized for Windows in os.cpp would be the best 
thing.  Making the NMT call at a lower level ie. pd_unmap_memory runs 
into the problem that there are duplicates for the xnix platforms.  
Also, there are multiple returns that would need NMT logic so it 
wouldn't look good.  Also, there is risk because some of the os 
platforms call pd_unmap_memory by os::pd_attempt_reserve_memory_at() 
which would get the tracking wrong (I think).

Coleen

> Thanks,
> Jiangli
>
>> Thanks,
>> David
>> -----
>>
>>> Tested with test/runtime/NMT.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>>
>>>


From rainer.jung at kippdata.de  Thu Jan  7 03:43:04 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Thu, 7 Jan 2016 04:43:04 +0100
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568D3E4A.7070308@oracle.com>
References: <568CFC7B.1010801@oracle.com> <568D3E4A.7070308@oracle.com>
Message-ID: <568DDEC8.5070209@kippdata.de>

Hi all,

I'm the original reporter of the problem.

Am 06.01.2016 um 17:18 schrieb Yumin Qi:
> Cheleswer,
>
>    If the call to check_addr0() is unnecessary, remove it is a better
> choice I think. In fatal error, means VM will exit, the error handler
> will print memory info, so it is redundant here. I don't know why it is
> added to log rotation code in the first place.

When I first investigated the problem, I noticed that the same function 
check_addr0() is also used in os::run_periodic_checks(). The whole code 
goes back to

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6478739

I also wondered why it was called during GC log rotation but didn't 
investigate further.

Note that in addition to the problem of the long safepoint pause during 
GC log file rotation, this bug has a second aspect, namely that reading 
the maps file is done in a very inefficient and slow way. So even after 
removing the call to check_addr0() during gc log file rotation - which 
would fix this bug here - whatever code remains to call check_addr0(), 
will still notice that the call takes a very long time (e.g. more than 
30 seconds if your process has lots of threads and open jar files).

This aspect was triggered by an older fix of the code which reads the 
map file. Before the fix, the file was closed after reading the first 
record from it. That was a bug but it terminated the read loop early and 
the call returned quickly. After the old fix, the close was moved behind 
the read loop and now the full read loop executed and took too long. As 
an example for the old fix see

http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/diff/e50eb3195734/src/os/solaris/vm/os_solaris.cpp

I think the correct (and fast) way of reading the maps file can be seen 
by looking at the code of the Solaris "pmap" command. It reads the file 
in one go using the pread() call instead of reading lots of structs one 
by one. Therefore pmap executes very fast, much faster than 
check_addr0() for the same maps file. I did check that on the same map 
file, that showed the slowness bug in check_addr0().

Since the pmap code isn't available in the open, I looked at the Illumos 
code based on older OpenSolaris. There one can see:

In 
https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/cmd/ptools/pmap/pmap.c

- calls Pmapping_iter_resolved() to iterate over the maps

In 
https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Psymtab.c

- Pmapping_iter_resolved() calls i_Pmapping_iter()
- i_Pmapping_iter() calls Prd_agent()
- Prd_agent() calls Pupdate_maps()
- Pupdate_maps() calls Preadmaps()
- Preadmaps() calls P->ops.pop_read_maps()

In 
https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Pcontrol.c

- P->ops.pop_read_maps is Pread_maps_live()
- Pread_maps_live() (starting at line 100) uses pread() to read the 
whole file in one go into a buffer, that was sized using the st_size 
field in the stat returned from fstat() called on the map file.

So I suggest you also fix the slowness in check_addr0() by adjusting the 
code that reads the map file in a similar way. If you think that's to 
dangerous for a huge file, then you might consider at least reading the 
file in big enough chunks (e.g. 100 structs at a time).

Regards,

Rainer

> On 1/6/2016 3:37 AM, cheleswer sahu wrote:
>> Hi,
>>
>> Please review the code changes for
>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>
>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>
>> Bug brief:
>> A long pause is observed after each gc log rotation in Solaris.
>>
>> Problem Identified:
>> In each GC log rotation "print_memory_info()" is getting called
>> through dump_loggc_header().
>> "print_memory_info()" of solaris version calls check_addr0(st);
>>
>> File:
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>>
>>
>> void os::print_memory_info(outputStream* st) {
>>   st->print("Memory:");
>>
>>   st->print(" %dk page", os::vm_page_size()>>10);
>>
>>   st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);
>>
>>   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>
>>   st->cr();
>>  (void) check_addr0(st);
>> }
>>
>> Now check_addr0(st) function do a lot of read call to read the data
>> from /proc/self/map.
>> and check if virtual address is mapped to 0x0. These read calls take
>> lot of time which results in GC rotation pause.
>> Here calling check_addr0() seems unnecessary for every log rotation.
>> It will be more logical if this function gets called only
>> when an error is reported.
>>
>> Solution proposed:
>> Before GC log rotation print_memory_info() is ever getting called from
>> Vm_error.cpp during error reporting. And in case of error reporting
>> checking for address mapping to 0x0 looks fine. So the proposed
>> solution is to do an extra check inside print_memory_info().
>>
>> -  (void) check_addr0(st);
>> +  if (VMError::fatal_error_in_progress()){
>> +     (void) check_addr0(st);
>> +  }
>>  }
>>
>>  This check doesn't fit well inside printing function, but at this
>> point I don't see the need to create a new os:: method and change all
>> the OS classes just for that check.
>>
>> Regards,
>> Cheleswer

From david.holmes at oracle.com  Thu Jan  7 04:51:12 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Jan 2016 14:51:12 +1000
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568CFC7B.1010801@oracle.com>
References: <568CFC7B.1010801@oracle.com>
Message-ID: <568DEEC0.6070303@oracle.com>

Hi Cheleswer,

This needs to be fixed in JDK 9 first and then flagged for backport if 
desired. The "Fix Version" in the bug should be set to 9.

Thanks,
David

On 6/01/2016 9:37 PM, cheleswer sahu wrote:
> Hi,
>
> Please review the code changes for
> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>
> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>
> Bug brief:
> A long pause is observed after each gc log rotation in Solaris.
>
> Problem Identified:
> In each GC log rotation "print_memory_info()" is getting called through
> dump_loggc_header().
> "print_memory_info()" of solaris version calls check_addr0(st);
>
> File:
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>
>
> void os::print_memory_info(outputStream* st) {
>    st->print("Memory:");
>
>    st->print(" %dk page", os::vm_page_size()>>10);
>
>    st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);
>
>    st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>
>    st->cr();
>   (void) check_addr0(st);
> }
>
> Now check_addr0(st) function do a lot of read call to read the data from
> /proc/self/map.
> and check if virtual address is mapped to 0x0. These read calls take lot
> of time which results in GC rotation pause.
> Here calling check_addr0() seems unnecessary for every log rotation. It
> will be more logical if this function gets called only
> when an error is reported.
>
> Solution proposed:
> Before GC log rotation print_memory_info() is ever getting called from
> Vm_error.cpp during error reporting. And in case of error reporting
> checking for address mapping to 0x0 looks fine. So the proposed solution
> is to do an extra check inside print_memory_info().
>
> -  (void) check_addr0(st);
> +  if (VMError::fatal_error_in_progress()){
> +     (void) check_addr0(st);
> +  }
>   }
>
>   This check doesn't fit well inside printing function, but at this
> point I don't see the need to create a new os:: method and change all
> the OS classes just for that check.
>
> Regards,
> Cheleswer

From cheleswer.sahu at oracle.com  Thu Jan  7 06:42:04 2016
From: cheleswer.sahu at oracle.com (cheleswer sahu)
Date: Thu, 7 Jan 2016 12:12:04 +0530
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568DEEC0.6070303@oracle.com>
References: <568CFC7B.1010801@oracle.com> <568DEEC0.6070303@oracle.com>
Message-ID: <568E08BC.30402@oracle.com>

Hi David,
JDK9 uses unified logging and unified logging does not use the 
problematic function call. I have run the test with unified logging 
enabled and didn't  find the issue. Therefore I had started review 
request only for JDK8.

Regards,
Cheleswer

On 1/7/2016 10:21 AM, David Holmes wrote:
> Hi Cheleswer,
>
> This needs to be fixed in JDK 9 first and then flagged for backport if 
> desired. The "Fix Version" in the bug should be set to 9.
>
> Thanks,
> David
>
> On 6/01/2016 9:37 PM, cheleswer sahu wrote:
>> Hi,
>>
>> Please review the code changes for
>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>
>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>
>> Bug brief:
>> A long pause is observed after each gc log rotation in Solaris.
>>
>> Problem Identified:
>> In each GC log rotation "print_memory_info()" is getting called through
>> dump_loggc_header().
>> "print_memory_info()" of solaris version calls check_addr0(st);
>>
>> File:
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp 
>>
>>
>>
>> void os::print_memory_info(outputStream* st) {
>>    st->print("Memory:");
>>
>>    st->print(" %dk page", os::vm_page_size()>>10);
>>
>>    st->print(", physical " UINT64_FORMAT "k", 
>> os::physical_memory()>>10);
>>
>>    st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>
>>    st->cr();
>>   (void) check_addr0(st);
>> }
>>
>> Now check_addr0(st) function do a lot of read call to read the data from
>> /proc/self/map.
>> and check if virtual address is mapped to 0x0. These read calls take lot
>> of time which results in GC rotation pause.
>> Here calling check_addr0() seems unnecessary for every log rotation. It
>> will be more logical if this function gets called only
>> when an error is reported.
>>
>> Solution proposed:
>> Before GC log rotation print_memory_info() is ever getting called from
>> Vm_error.cpp during error reporting. And in case of error reporting
>> checking for address mapping to 0x0 looks fine. So the proposed solution
>> is to do an extra check inside print_memory_info().
>>
>> -  (void) check_addr0(st);
>> +  if (VMError::fatal_error_in_progress()){
>> +     (void) check_addr0(st);
>> +  }
>>   }
>>
>>   This check doesn't fit well inside printing function, but at this
>> point I don't see the need to create a new os:: method and change all
>> the OS classes just for that check.
>>
>> Regards,
>> Cheleswer


From david.holmes at oracle.com  Thu Jan  7 08:23:43 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Jan 2016 18:23:43 +1000
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568E08BC.30402@oracle.com>
References: <568CFC7B.1010801@oracle.com> <568DEEC0.6070303@oracle.com>
	<568E08BC.30402@oracle.com>
Message-ID: <568E208F.9000800@oracle.com>

On 7/01/2016 4:42 PM, cheleswer sahu wrote:
> Hi David,
> JDK9 uses unified logging and unified logging does not use the
> problematic function call. I have run the test with unified logging
> enabled and didn't  find the issue. Therefore I had started review
> request only for JDK8.

Ah I see. Okay can you update the bug report to remove "9" from the 
"Affects Version", add a 9-na label, and a comment explaining why this 
is now 9-na.

Thanks,
David

> Regards,
> Cheleswer
>
> On 1/7/2016 10:21 AM, David Holmes wrote:
>> Hi Cheleswer,
>>
>> This needs to be fixed in JDK 9 first and then flagged for backport if
>> desired. The "Fix Version" in the bug should be set to 9.
>>
>> Thanks,
>> David
>>
>> On 6/01/2016 9:37 PM, cheleswer sahu wrote:
>>> Hi,
>>>
>>> Please review the code changes for
>>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>>
>>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>>
>>> Bug brief:
>>> A long pause is observed after each gc log rotation in Solaris.
>>>
>>> Problem Identified:
>>> In each GC log rotation "print_memory_info()" is getting called through
>>> dump_loggc_header().
>>> "print_memory_info()" of solaris version calls check_addr0(st);
>>>
>>> File:
>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>>>
>>>
>>>
>>> void os::print_memory_info(outputStream* st) {
>>>    st->print("Memory:");
>>>
>>>    st->print(" %dk page", os::vm_page_size()>>10);
>>>
>>>    st->print(", physical " UINT64_FORMAT "k",
>>> os::physical_memory()>>10);
>>>
>>>    st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>>
>>>    st->cr();
>>>   (void) check_addr0(st);
>>> }
>>>
>>> Now check_addr0(st) function do a lot of read call to read the data from
>>> /proc/self/map.
>>> and check if virtual address is mapped to 0x0. These read calls take lot
>>> of time which results in GC rotation pause.
>>> Here calling check_addr0() seems unnecessary for every log rotation. It
>>> will be more logical if this function gets called only
>>> when an error is reported.
>>>
>>> Solution proposed:
>>> Before GC log rotation print_memory_info() is ever getting called from
>>> Vm_error.cpp during error reporting. And in case of error reporting
>>> checking for address mapping to 0x0 looks fine. So the proposed solution
>>> is to do an extra check inside print_memory_info().
>>>
>>> -  (void) check_addr0(st);
>>> +  if (VMError::fatal_error_in_progress()){
>>> +     (void) check_addr0(st);
>>> +  }
>>>   }
>>>
>>>   This check doesn't fit well inside printing function, but at this
>>> point I don't see the need to create a new os:: method and change all
>>> the OS classes just for that check.
>>>
>>> Regards,
>>> Cheleswer
>

From mattis.castegren at oracle.com  Thu Jan  7 10:33:27 2016
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Thu, 7 Jan 2016 02:33:27 -0800 (PST)
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568CFC7B.1010801@oracle.com>
References: <568CFC7B.1010801@oracle.com>
Message-ID: <c1d9d4e4-7ba6-4d92-8adb-fa2eb8a5a0df@default>

Hi

This is for an escalated customer issue, so it would be great if someone could review this today or tomorrow. The customer is pushing for an interim patch for this, so we would want to push this fix as soon as possible.

Kind Regards
/Mattis

-----Original Message-----
From: cheleswer sahu 
Sent: den 6 januari 2016 12:38
To: hotspot-runtime-dev at openjdk.java.net
Cc: Mattis Castegren; Kevin Walls
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each GC log rotation

Hi,

Please review the code changes for
"https://bugs.openjdk.java.net/browse/JDK-8144483".

webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483

Bug brief:
A long pause is observed after each gc log rotation in Solaris.

Problem Identified:
In each GC log rotation "print_memory_info()" is getting called through dump_loggc_header().
"print_memory_info()" of solaris version calls check_addr0(st);

File: 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp

void os::print_memory_info(outputStream* st) {
   st->print("Memory:");

   st->print(" %dk page", os::vm_page_size()>>10);

   st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);

   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);

   st->cr();
  (void) check_addr0(st);
}

Now check_addr0(st) function do a lot of read call to read the data from /proc/self/map.
and check if virtual address is mapped to 0x0. These read calls take lot of time which results in GC rotation pause.
Here calling check_addr0() seems unnecessary for every log rotation. It will be more logical if this function gets called only when an error is reported.

Solution proposed:
Before GC log rotation print_memory_info() is ever getting called from Vm_error.cpp during error reporting. And in case of error reporting checking for address mapping to 0x0 looks fine. So the proposed solution is to do an extra check inside print_memory_info().

-  (void) check_addr0(st);
+  if (VMError::fatal_error_in_progress()){
+     (void) check_addr0(st);
+  }
  }

  This check doesn't fit well inside printing function, but at this point I don't see the need to create a new os:: method and change all the OS classes just for that check.

Regards,
Cheleswer

From david.holmes at oracle.com  Thu Jan  7 10:41:56 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Jan 2016 20:41:56 +1000
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568CFC7B.1010801@oracle.com>
References: <568CFC7B.1010801@oracle.com>
Message-ID: <568E40F4.4020808@oracle.com>

Hi Cheleswer,

This workaround seems fine to me.

Thanks,
David

On 6/01/2016 9:37 PM, cheleswer sahu wrote:
> Hi,
>
> Please review the code changes for
> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>
> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>
> Bug brief:
> A long pause is observed after each gc log rotation in Solaris.
>
> Problem Identified:
> In each GC log rotation "print_memory_info()" is getting called through
> dump_loggc_header().
> "print_memory_info()" of solaris version calls check_addr0(st);
>
> File:
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>
>
> void os::print_memory_info(outputStream* st) {
>    st->print("Memory:");
>
>    st->print(" %dk page", os::vm_page_size()>>10);
>
>    st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);
>
>    st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>
>    st->cr();
>   (void) check_addr0(st);
> }
>
> Now check_addr0(st) function do a lot of read call to read the data from
> /proc/self/map.
> and check if virtual address is mapped to 0x0. These read calls take lot
> of time which results in GC rotation pause.
> Here calling check_addr0() seems unnecessary for every log rotation. It
> will be more logical if this function gets called only
> when an error is reported.
>
> Solution proposed:
> Before GC log rotation print_memory_info() is ever getting called from
> Vm_error.cpp during error reporting. And in case of error reporting
> checking for address mapping to 0x0 looks fine. So the proposed solution
> is to do an extra check inside print_memory_info().
>
> -  (void) check_addr0(st);
> +  if (VMError::fatal_error_in_progress()){
> +     (void) check_addr0(st);
> +  }
>   }
>
>   This check doesn't fit well inside printing function, but at this
> point I don't see the need to create a new os:: method and change all
> the OS classes just for that check.
>
> Regards,
> Cheleswer

From bertrand.delsart at oracle.com  Thu Jan  7 13:36:47 2016
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Thu, 7 Jan 2016 14:36:47 +0100
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568E40F4.4020808@oracle.com>
References: <568CFC7B.1010801@oracle.com> <568E40F4.4020808@oracle.com>
Message-ID: <568E69EF.7080006@oracle.com>

And to me too of course :-)

Bertrand.

On 1/7/16 11:41 AM, David Holmes wrote:
> Hi Cheleswer,
>
> This workaround seems fine to me.
>
> Thanks,
> David
>
> On 6/01/2016 9:37 PM, cheleswer sahu wrote:
>> Hi,
>>
>> Please review the code changes for
>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>
>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>
>> Bug brief:
>> A long pause is observed after each gc log rotation in Solaris.
>>
>> Problem Identified:
>> In each GC log rotation "print_memory_info()" is getting called through
>> dump_loggc_header().
>> "print_memory_info()" of solaris version calls check_addr0(st);
>>
>> File:
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>>
>>
>>
>> void os::print_memory_info(outputStream* st) {
>>    st->print("Memory:");
>>
>>    st->print(" %dk page", os::vm_page_size()>>10);
>>
>>    st->print(", physical " UINT64_FORMAT "k", os::physical_memory()>>10);
>>
>>    st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>
>>    st->cr();
>>   (void) check_addr0(st);
>> }
>>
>> Now check_addr0(st) function do a lot of read call to read the data from
>> /proc/self/map.
>> and check if virtual address is mapped to 0x0. These read calls take lot
>> of time which results in GC rotation pause.
>> Here calling check_addr0() seems unnecessary for every log rotation. It
>> will be more logical if this function gets called only
>> when an error is reported.
>>
>> Solution proposed:
>> Before GC log rotation print_memory_info() is ever getting called from
>> Vm_error.cpp during error reporting. And in case of error reporting
>> checking for address mapping to 0x0 looks fine. So the proposed solution
>> is to do an extra check inside print_memory_info().
>>
>> -  (void) check_addr0(st);
>> +  if (VMError::fatal_error_in_progress()){
>> +     (void) check_addr0(st);
>> +  }
>>   }
>>
>>   This check doesn't fit well inside printing function, but at this
>> point I don't see the need to create a new os:: method and change all
>> the OS classes just for that check.
>>
>> Regards,
>> Cheleswer


-- 
Bertrand Delsart,                     bertrand.delsart at oracle.com
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38334 Saint Ismier,                                        FRANCE
Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From goetz.lindenmaier at sap.com  Thu Jan  7 15:01:17 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 7 Jan 2016 15:01:17 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <568C9EFC.8050304@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>

Hi David, 

the documentation you point to makes the point that whether to inline
is an implementation detail, and that that should not be annotated to 
the declaration.  Basically, this is a good point.

But the documentation does not cover the fact that 
we have the implementation in a different file than the declaration.
The .inline.hpp is not included always (as you pointed out). 

Therefore, if we compile with precompiled headers, we get more
inlines than if we do so without.
Further, many functions were moved to oop.linline.hpp during the
recent cleanups, and I think all the #includes I had to add were not
left out deliberately, but just happened because the compiler did 
not complain.
I think if somebody decides not to place a function implementation 
in a .cpp file, it should have the chance to be inlined at all it's calls.
Putting the 'inline' into the .hpp file assures this.

Best regards,
  Goetz.




> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Mittwoch, 6. Januar 2016 05:59
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> Hi Goetz,
> 
> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
> header file.
> > Unfortunately, the 'inline' qualifier is added to the function
> implementations
> > in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
> > compiler can not detect failing inlines properly.
> >
> > This change moves the inline directive from oop.inline.hpp to oop.hpp.
> Also
> 
> This seems contrary to the C++ FAQ:
> 
> https://isocpp.org/wiki/faq/inline-functions
> 
> The declaration in the .hpp should not have inline, only the definition,
> which in our case is in the .inline.hpp file.
> 
> Any code that includes the .inline.hpp will have seen the definition of
> the inline function prior to its use - as long as the includes are correct.
> 
> David
> -----
> 
> 
> > it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
> >
> > Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
> >
> > I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> > very small .hpp file and no .cpp file exists.  So I think this is acceptable.
> >
> > Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> > bigger changes to this file in the rt repo, because jvmci is subject to
> > freqent changes recently.
> >
> > The following methods were moved to .cpp files:
> >
> > ProtectionDomainCacheTable::compute_hash()
> > ProtectionDomainCacheTable::index_for()
> > typeArrayOopDesc::object_size()
> > This is called only once outside .cpp file:
> > CallSiteDepChange::CallSiteDepChange()
> > This is only called in .cpp file
> > ConstantPool::string_at_put()
> >
> > If someone considers not inlining these harmful to performance,
> > I will add a new .inline.hpp file for them.
> >
> > Please review this change.  I please need a sponsor.
> > There are no functional edits, so it should be simple to review.
> > http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
> >
> > Best regards,
> >    Goetz.
> >

From ron.durbin at oracle.com  Thu Jan  7 15:16:53 2016
From: ron.durbin at oracle.com (Ron Durbin)
Date: Thu, 7 Jan 2016 07:16:53 -0800 (PST)
Subject: RFR (S) round 0 for 8135198 Add -XX:VMOptionsFile support to
	JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
In-Reply-To: <568DA77B.2060301@oracle.com>
References: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
	<568DA77B.2060301@oracle.com>
Message-ID: <35fdeaab-48f8-464f-9b73-77c745a9dfdc@default>

Thx Dan

>-----Original Message-----
>From: Daniel D. Daugherty
>Sent: Wednesday, January 06, 2016 4:47 PM
>To: Ron Durbin; hotspot-runtime-dev at openjdk.java.net
>Subject: Re: RFR (S) round 0 for 8135198 Add -XX:VMOptionsFile support to JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
>
>On 1/6/16 4:39 PM, Ron Durbin wrote:
>> This change adds -XX:VMOptionsFile support to the JAVA_TOOL_OPTIONS
>> and _JAVA_OPTIONS environment variables. With this change, the
>> -XX:VMOptionsFile option is supported in the following option
>> containers:
>>
>> - the command line
>> - JAVA_TOOL_OPTIONS env var
>> - _JAVA_OPTIONS env var
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rdurbin/8135198_OCR0_JDK9_webrev
>
>src/share/vm/runtime/arguments.cpp
>     No comments.
>
>src/share/vm/runtime/arguments.hpp
>     No comments.
>
>test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java
>     No comments.
>
>Thumbs up!
>
>Compared this patch with the one from JDK-8135198_PCR4_JDK9_webrev
>and they match modulo line numbers and time stamps.
>
>Dan
>
>
>>
>> Bug report:
>>     https://bugs.openjdk.java.net/browse/JDK-8135198
>>
>> This bug fix has been tested on:
>>       OS:
>>         Solaris, MAC, Windows, Linux
>>       Tests:
>>         Manual unit tests
>>         JPRT with -testset hotspot(including the SQE current test coverage for this feature.)
>>
>

From goetz.lindenmaier at sap.com  Thu Jan  7 15:41:55 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 7 Jan 2016 15:41:55 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix	header files
In-Reply-To: <568C1854.8060806@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C1854.8060806@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F282@DEWDFEMB12A.global.corp.sap>

Hi Coleen, 

thanks for looking at this!

> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/code/dependencies.cpp.udiff.html
> 
> Can you fix the preexisting weird indentation of
> + assert(_call_site() ->is_a(SystemDictionary::CallSite_klass()), "must
> be");
Done.

> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/jvmci/jvmciJavaClasses.hpp.udiff.html
> 
> Don't have an opinion about including the .inline.hpp files in these.
> The compiler team should probably clean this up.
Yes, I think so too.  It should be done in the compiler repo to avoid
clashes.

> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> 
> Why isn't inline in the declaration for obj_at_put ? 
> Why is inline commented out for some?
I have a follow-up change with a lot of cleanups in gc coding.
In that change, I will fix the remaining inlines.  I wanted to 
make an extra change for gc to simplify reviewing.
 
> + inline bool is_instance() const;
> + /*inline*/ bool is_array() const;
> 
> 
> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/oops/oop.inline.hpp.udiff.html
> 
> I'm not really happy with the re-sorting because it may make backporting
> difficult, but it's not that many that were moved and the order of these
> functions has always seeemed random to me.  So I guess it's ok.
> 
> Can you line up the '\' in the OOP_ITERATE macros at the end?
> 
> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/oops/typeArrayOop.cpp.udiff.html
I think that's an artefact of udiff.  The patch and my files look fine.

> This non-inline function could affect performance.   It may be called
> from GC.  We might need a typeArrayOop.inline.hpp for it.
I'll make a new file to be on the safe side.

Why is there the empty typeArrayOop.cpp file?
 
> I can sponsor this, pending further review.
Thanks!

Best regards,
   Goetz.



> 
> Coleen
> 
> 
> On 1/4/16 10:44 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
> header file.
> > Unfortunately, the 'inline' qualifier is added to the function
> implementations
> > in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
> > compiler can not detect failing inlines properly.
> >
> > This change moves the inline directive from oop.inline.hpp to oop.hpp.
> Also
> > it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
> >
> > Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
> >
> > I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> > very small .hpp file and no .cpp file exists.  So I think this is acceptable.
> >
> > Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> > bigger changes to this file in the rt repo, because jvmci is subject to
> > freqent changes recently.
> >
> > The following methods were moved to .cpp files:
> >
> > ProtectionDomainCacheTable::compute_hash()
> > ProtectionDomainCacheTable::index_for()
> > typeArrayOopDesc::object_size()
> > This is called only once outside .cpp file:
> > CallSiteDepChange::CallSiteDepChange()
> > This is only called in .cpp file
> > ConstantPool::string_at_put()
> >
> > If someone considers not inlining these harmful to performance,
> > I will add a new .inline.hpp file for them.
> >
> > Please review this change.  I please need a sponsor.
> > There are no functional edits, so it should be simple to review.
> > http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
> >
> > Best regards,
> >    Goetz.


From rachel.protacio at oracle.com  Thu Jan  7 17:12:25 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Thu, 7 Jan 2016 12:12:25 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <568D91D0.4070200@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<568D87CA.6000704@oracle.com> <568D91D0.4070200@oracle.com>
Message-ID: <568E9C79.3050402@oracle.com>

Great, thanks, Coleen!
Rachel

On 1/6/2016 5:14 PM, Coleen Phillimore wrote:
>
> I remember this change!  This came out very nice.  I agree that 
> @ignore'ing the test until we figure out what's wrong with these tests 
> on Windows is a good thing to do.
>
> Thanks,
> Coleen
>
> On 1/6/16 4:31 PM, Rachel Protacio wrote:
>> Hi,
>>
>> When I tried to commit this change, the ItablesTest was failing on 
>> windows, so I've been trying to get to the bottom of that failure. As 
>> other logging tests have recently proved themselves flaky on windows 
>> as well, it seems to be a deeper issue. As such, I have added the 
>> problem to https://bugs.openjdk.java.net/browse/JDK-8146435 for more 
>> thorough investigation and ignored the ItablesTest for the time being.
>>
>> Here's my new webrev 
>> http://cr.openjdk.java.net/~rprotacio/8141564.03/ which only differs 
>> from the previously approved code via the @ignore line. The code 
>> passes JPRT.
>>
>> Thank you!
>> Rachel
>>
>> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>>> Rachel,
>>>
>>> Thank you for the updates.
>>> Can you please sanity check one thing for me - the log_tables 
>>> boolean ?overrides? appears to
>>> be set correctly in the callers, to mean ?yes, this overrides?.
>>> In log_vtables, is it possible the choice of what to print is reversed?
>>>
>>> And perhaps add a check to your tests for example that ?NOT 
>>> overriding? catches the right case?
>>>
>>> And yes please on the assertion (I have seen null method bugs in 
>>> development and this code is an early
>>> opportunity to catch that problem).
>>>
>>> I don?t need to see an updated web rev and you don?t need to rerun 
>>> all the tests to fix
>>> the printed string.
>>>
>>> thanks,
>>> Karen
>>>
>>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore 
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>>> Hi, Karen,
>>>>>
>>>>> Thanks for the review. Updated webrev: 
>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>>
>>>>> Since I never listed the tests I ran even the first time, here are 
>>>>> all of them:
>>>>>
>>>>> * jtreg
>>>>> * JPRT
>>>>> * jck vm, lang, & api/java_lang
>>>>> * rbt quick and non-colo (which now includes defmeth)
>>>>> * invoke*
>>>>>
>>>>> Replies inline.
>>>>>
>>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>>> Rachel,
>>>>>>
>>>>>> Thank you so much for doing (and redoing) this.
>>>>>>
>>>>>> Couple of questions/comments.
>>>>>>
>>>>>> 1. thank you so much for the transitive overriding test - not 
>>>>>> easy to figure out how to generate one!
>>>>>>
>>>>> Lois walked me through doing that one :)
>>>>>> 2. I missed the list of what you have tested for the first web 
>>>>>> rev and the other tests for this one
>>>>>> I will assume in parallel with the code review you are running 
>>>>>> (without tracing)
>>>>>> vm quick & nocolo, jck vm & lang
>>>>>> defmeth, invoke*
>>>>> Yeah, I totally forgot to email what tests I had run. Sorry about 
>>>>> that! And just learned how to run the jck tests.
>>>>>> There might be value in running your new tests with old tracing 
>>>>>> vs. new and eyeballing the files - to see if they
>>>>>> get essentially the same information.
>>>>>>
>>>>> Yup!
>>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>>> Would it make any sense to do if !klass()->is_array_klass() and 
>>>>>> then just use the log_develop_debug and
>>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>>
>>>>> That makes sense. Changed as suggested.
>>>>>> 4. thank you so much for extracting the print_linkage_flags - I 
>>>>>> should have done that earlier - the information
>>>>>> just grew incrementally.
>>>>>>
>>>>>> 5. klassVtable.cpp line 1047 -
>>>>>>    I think you want an if (m != NULL) here  before dereferencing 
>>>>>> to print_linkage_flags.
>>>>>>    I see we miss that check for other dereferences -feel free to 
>>>>>> add small checks.
>>>>>>    Don?t completely skip logic paragraphs except for printing ones.
>>>>> Well, when I was making my change, we saw that it wouldn't be 
>>>>> possible for m to be null at that point in the code. There are 
>>>>> multiple places above it where it is dereferenced already, not to 
>>>>> mention the fact that it is theoretically initialized to be a 
>>>>> valid method. Would you like to me to add an assert after the 
>>>>> declaration
>>>>>     assert(m != NULL, "methods can never be null");
>>>>> just to be safe?
>>>> In the code here:
>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html> 
>>>>
>>>>
>>>> Yes, Method* m = method->at(i); can never return NULL or else the 
>>>> whole VM would crash everywhere.  I suspect the logging code here 
>>>> was copied from other instances where 'm' could be null.   This 
>>>> line would crash first:
>>>>
>>>> if (interface_method_needs_itable_index(m)) {
>>>>
>>>>
>>>> Can you clean up this line also to not check for NULL:
>>>>
>>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() : 
>>>> "<NULL>";
>>>>
>>>>
>>>> And add the assert if Karen agrees if it's needed.
>>>>
>>>> The rest of the changes look good.   I don't need to see another 
>>>> revision.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>>>     Thank you for leaving the null check in fill_in_miranda and 
>>>>>> print_method_at.
>>>>>>
>>>>>> 6. log_vtables
>>>>>> The logic in update_inherited_vtables is quite complex.
>>>>>> So the value of allocate_new is not really the right conditional 
>>>>>> to pass in to determine if there
>>>>>> was an override.
>>>>>>    The first paragraph applies both for allocate_new=true and 
>>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>>
>>>>>> So, perhaps you could add a boolean that says ?overrides? or 
>>>>>> ?overriding? or whatever : default it to false, and set it to 
>>>>>> true right after the put_method_at line (that iswhere the 
>>>>>> override occurs) and set it to false in the ?else? clause?
>>>>>> And pass that argument in to log_vtables ? And remove the 
>>>>>> allocate_new comment from log_vtables as well?
>>>>>>
>>>>> Done, too.
>>>>>
>>>>> Thanks!!
>>>>> Rachel
>>>>>> And the comment in the ?else? is not accurate since I put the 
>>>>>> package_private fix in - so removing
>>>>>> it was a good idea.
>>>>>>
>>>>>> many thanks,
>>>>>> Karen
>>>>>>
>>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio 
>>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com> 
>>>>>>> <mailto:rachel.protacio at oracle.com 
>>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> Thanks for the comments! Updated 
>>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/ 
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ 
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds 
>>>>>>> and passes logging jtreg tests.)
>>>>>>>
>>>>>>> Replies inline.
>>>>>>>
>>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>>> Rachel, There are a lot of changes here.  I have several 
>>>>>>>> comments and more suggested cleanup that should be done with 
>>>>>>>> this work.
>>>>>>>>
>>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> I did the original refactoring for trace_method_resolution. 
>>>>>>>> What I think would be better is to make it an internal static 
>>>>>>>> function in linkResolver.cpp and not defined in the 
>>>>>>>> linkResolver.hpp.  Make the call unconditional and pass vtable 
>>>>>>>> index in the last parameter as a default parameter with default 
>>>>>>>> value -1 so the last line in the function is the tty->cr() that 
>>>>>>>> I had outside the function call (that was pretty icky). And put 
>>>>>>>> all the ResourceMark and logstream logic inside the 
>>>>>>>> trace_method_resolution function.  It would never print to tty 
>>>>>>>> so doesn't need an outputStream parameter for other callers.
>>>>>>>>
>>>>>>>> So there would be only the one line 
>>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>>> Thanks for the advice! I still have to call the function from 
>>>>>>> within the conditional because it's develop level only and 
>>>>>>> because I need to specify in the call whether it's for itables 
>>>>>>> or vtables. Otherwise, I've followed your suggestions.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you put these tags near each other?
>>>>>>>>
>>>>>>> I have them sorted alphabetically, which I think is more useful 
>>>>>>> in the long run.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> One of the things that Markus Gronlund's made me think that we 
>>>>>>>> should do with his cleanup is to stop declaring functions as 
>>>>>>>> members of classes if they don't need external linkage. From 
>>>>>>>> his RFR(L): 8140485: Class load and creation clean up:
>>>>>>>>
>>>>>>>> "Comment: In my opinion, we should attempt to break the pattern 
>>>>>>>> of having private functions declared in header files when the 
>>>>>>>> private function does not need to reach inside "this"."
>>>>>>>>
>>>>>>>> I think the function log_vtables should follow this and be 
>>>>>>>> declared as a static internal function in klassVtable.cpp above 
>>>>>>>> the function where it's used.
>>>>>>>>
>>>>>>>> It's true that you don't see this very much in the hotspot 
>>>>>>>> sources.
>>>>>>>>
>>>>>>>> The refactoring of log_vtables is good and very much appreciated.
>>>>>>>>
>>>>>>>> In each of the logging blocks of code, there are about 6 lines 
>>>>>>>> that are about the same, that print the access flags and 
>>>>>>>> whether it's a default or overpass method. (Karen and Lois 
>>>>>>>> should give you a TOI about what that means!)  Can you add a 
>>>>>>>> method to method.hpp that's something like 
>>>>>>>> print_flags(outputStream* st) and move this printing there, and 
>>>>>>>> make those blocks call your new function?  That would shorten 
>>>>>>>> many of these logging blocks of code and would be nice.  You 
>>>>>>>> could call this from the linkResolver.cpp 
>>>>>>>> trace_method_resolution() function too.
>>>>>>> Done.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>> These classes have missing copyrights.
>>>>>>> Fixed.
>>>>>>> Thanks!
>>>>>>> Rachel
>>>>>>>> Thanks!
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review this changeset that converts -XX:+TraceItables 
>>>>>>>>> and -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>>
>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/ 
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/> 
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564 
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>>
>>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp 
>>>>>>>>> around 462-498 are a refactoring of the duplicate code from a 
>>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Rachel
>>
>


From rachel.protacio at oracle.com  Thu Jan  7 17:15:04 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Thu, 7 Jan 2016 12:15:04 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <5667A875.6090208@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<56672598.2050905@oracle.com> <5667A875.6090208@oracle.com>
Message-ID: <568E9D18.7040501@oracle.com>

Hi, David,

Thanks for that. I've corrected the issue in interpreterRuntime.cpp as 
well as in klassVtable.cpp. Did you look at all the code - shall I count 
you as a reviewer?

Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141564.04/

Rachel

On 12/8/2015 11:05 PM, David Holmes wrote:
> Hi Rachel,
>
> src/share/vm/interpreter/interpreterRuntime.cpp
>
> The ResourceMark is now used outside of the actual logging code. If a 
> ResourceMark is needed then I think we need to use the "if 
> (log_is_enabled(...)" form.
>
> Thanks,
> David
>
>
>
> On 9/12/2015 4:46 AM, Rachel Protacio wrote:
>> Hi,
>>
>> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>>> Rachel,
>>>
>>> Thank you for the updates.
>>> Can you please sanity check one thing for me - the log_tables boolean
>>> ?overrides? appears to
>>> be set correctly in the callers, to mean ?yes, this overrides?.
>>> In log_vtables, is it possible the choice of what to print is reversed?
>>>
>>> And perhaps add a check to your tests for example that ?NOT
>>> overriding? catches the right case?
>> Oh, good catch. Thank you - this is fixed now.
>>>
>>> And yes please on the assertion (I have seen null method bugs in
>>> development and this code is an early
>>> opportunity to catch that problem).
>>>
>>> I don?t need to see an updated web rev and you don?t need to rerun all
>>> the tests to fix
>>> the printed string.
>> Great. Thanks again, Karen and Coleen! Will commit the change.
>> Rachel
>>> thanks,
>>> Karen
>>>
>>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>>> Hi, Karen,
>>>>>
>>>>> Thanks for the review. Updated webrev:
>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>>
>>>>> Since I never listed the tests I ran even the first time, here are
>>>>> all of them:
>>>>>
>>>>> * jtreg
>>>>> * JPRT
>>>>> * jck vm, lang, & api/java_lang
>>>>> * rbt quick and non-colo (which now includes defmeth)
>>>>> * invoke*
>>>>>
>>>>> Replies inline.
>>>>>
>>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>>> Rachel,
>>>>>>
>>>>>> Thank you so much for doing (and redoing) this.
>>>>>>
>>>>>> Couple of questions/comments.
>>>>>>
>>>>>> 1. thank you so much for the transitive overriding test - not easy
>>>>>> to figure out how to generate one!
>>>>>>
>>>>> Lois walked me through doing that one :)
>>>>>> 2. I missed the list of what you have tested for the first web rev
>>>>>> and the other tests for this one
>>>>>> I will assume in parallel with the code review you are running
>>>>>> (without tracing)
>>>>>> vm quick & nocolo, jck vm & lang
>>>>>> defmeth, invoke*
>>>>> Yeah, I totally forgot to email what tests I had run. Sorry about
>>>>> that! And just learned how to run the jck tests.
>>>>>> There might be value in running your new tests with old tracing vs.
>>>>>> new and eyeballing the files - to see if they
>>>>>> get essentially the same information.
>>>>>>
>>>>> Yup!
>>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>>> Would it make any sense to do if !klass()->is_array_klass() and
>>>>>> then just use the log_develop_debug and
>>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>>
>>>>> That makes sense. Changed as suggested.
>>>>>> 4. thank you so much for extracting the print_linkage_flags - I
>>>>>> should have done that earlier - the information
>>>>>> just grew incrementally.
>>>>>>
>>>>>> 5. klassVtable.cpp line 1047 -
>>>>>>    I think you want an if (m != NULL) here  before dereferencing to
>>>>>> print_linkage_flags.
>>>>>>    I see we miss that check for other dereferences -feel free to
>>>>>> add small checks.
>>>>>>    Don?t completely skip logic paragraphs except for printing ones.
>>>>> Well, when I was making my change, we saw that it wouldn't be
>>>>> possible for m to be null at that point in the code. There are
>>>>> multiple places above it where it is dereferenced already, not to
>>>>> mention the fact that it is theoretically initialized to be a valid
>>>>> method. Would you like to me to add an assert after the declaration
>>>>>     assert(m != NULL, "methods can never be null");
>>>>> just to be safe?
>>>> In the code here:
>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>
>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html> 
>>>>
>>>>
>>>>
>>>> Yes, Method* m = method->at(i); can never return NULL or else the
>>>> whole VM would crash everywhere.  I suspect the logging code here was
>>>> copied from other instances where 'm' could be null.   This line
>>>> would crash first:
>>>>
>>>> if (interface_method_needs_itable_index(m)) {
>>>>
>>>>
>>>> Can you clean up this line also to not check for NULL:
>>>>
>>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() :
>>>> "<NULL>";
>>>>
>>>>
>>>> And add the assert if Karen agrees if it's needed.
>>>>
>>>> The rest of the changes look good.   I don't need to see another
>>>> revision.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>>>     Thank you for leaving the null check in fill_in_miranda and
>>>>>> print_method_at.
>>>>>>
>>>>>> 6. log_vtables
>>>>>> The logic in update_inherited_vtables is quite complex.
>>>>>> So the value of allocate_new is not really the right conditional to
>>>>>> pass in to determine if there
>>>>>> was an override.
>>>>>>    The first paragraph applies both for allocate_new=true and
>>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>>
>>>>>> So, perhaps you could add a boolean that says ?overrides? or
>>>>>> ?overriding? or whatever : default it to false, and set it to true
>>>>>> right after the put_method_at line (that iswhere the override
>>>>>> occurs) and set it to false in the ?else? clause?
>>>>>> And pass that argument in to log_vtables ? And remove the
>>>>>> allocate_new comment from log_vtables as well?
>>>>>>
>>>>> Done, too.
>>>>>
>>>>> Thanks!!
>>>>> Rachel
>>>>>> And the comment in the ?else? is not accurate since I put the
>>>>>> package_private fix in - so removing
>>>>>> it was a good idea.
>>>>>>
>>>>>> many thanks,
>>>>>> Karen
>>>>>>
>>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio
>>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com>
>>>>>>> <mailto:rachel.protacio at oracle.com
>>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> Thanks for the comments! Updated
>>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ 
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and
>>>>>>> passes logging jtreg tests.)
>>>>>>>
>>>>>>> Replies inline.
>>>>>>>
>>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>>> Rachel, There are a lot of changes here.  I have several comments
>>>>>>>> and more suggested cleanup that should be done with this work.
>>>>>>>>
>>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>
>>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I did the original refactoring for trace_method_resolution. What
>>>>>>>> I think would be better is to make it an internal static function
>>>>>>>> in linkResolver.cpp and not defined in the linkResolver.hpp.
>>>>>>>> Make the call unconditional and pass vtable index in the last
>>>>>>>> parameter as a default parameter with default value -1 so the
>>>>>>>> last line in the function is the tty->cr() that I had outside the
>>>>>>>> function call (that was pretty icky). And put all the
>>>>>>>> ResourceMark and logstream logic inside the
>>>>>>>> trace_method_resolution function.  It would never print to tty so
>>>>>>>> doesn't need an outputStream parameter for other callers.
>>>>>>>>
>>>>>>>> So there would be only the one line
>>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>>> Thanks for the advice! I still have to call the function from
>>>>>>> within the conditional because it's develop level only and because
>>>>>>> I need to specify in the call whether it's for itables or vtables.
>>>>>>> Otherwise, I've followed your suggestions.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you put these tags near each other?
>>>>>>>>
>>>>>>> I have them sorted alphabetically, which I think is more useful in
>>>>>>> the long run.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> One of the things that Markus Gronlund's made me think that we
>>>>>>>> should do with his cleanup is to stop declaring functions as
>>>>>>>> members of classes if they don't need external linkage. From his
>>>>>>>> RFR(L): 8140485: Class load and creation clean up:
>>>>>>>>
>>>>>>>> "Comment: In my opinion, we should attempt to break the pattern
>>>>>>>> of having private functions declared in header files when the
>>>>>>>> private function does not need to reach inside "this"."
>>>>>>>>
>>>>>>>> I think the function log_vtables should follow this and be
>>>>>>>> declared as a static internal function in klassVtable.cpp above
>>>>>>>> the function where it's used.
>>>>>>>>
>>>>>>>> It's true that you don't see this very much in the hotspot 
>>>>>>>> sources.
>>>>>>>>
>>>>>>>> The refactoring of log_vtables is good and very much appreciated.
>>>>>>>>
>>>>>>>> In each of the logging blocks of code, there are about 6 lines
>>>>>>>> that are about the same, that print the access flags and whether
>>>>>>>> it's a default or overpass method.  (Karen and Lois should give
>>>>>>>> you a TOI about what that means!)  Can you add a method to
>>>>>>>> method.hpp that's something like print_flags(outputStream* st)
>>>>>>>> and move this printing there, and make those blocks call your new
>>>>>>>> function?  That would shorten many of these logging blocks of
>>>>>>>> code and would be nice.  You could call this from the
>>>>>>>> linkResolver.cpp trace_method_resolution() function too.
>>>>>>> Done.
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>> 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> These classes have missing copyrights.
>>>>>>> Fixed.
>>>>>>> Thanks!
>>>>>>> Rachel
>>>>>>>> Thanks!
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review this changeset that converts -XX:+TraceItables and
>>>>>>>>> -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>>
>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>>
>>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp
>>>>>>>>> around 462-498 are a refactoring of the duplicate code from a
>>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Rachel
>>


From coleen.phillimore at oracle.com  Thu Jan  7 18:36:56 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 7 Jan 2016 13:36:56 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <568E9D18.7040501@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<56672598.2050905@oracle.com> <5667A875.6090208@oracle.com>
	<568E9D18.7040501@oracle.com>
Message-ID: <568EB048.6030102@oracle.com>


This still looks good!  I think I interpreted David's comment to not 
require another round, so I think he's a reviewer.

Coleen

On 1/7/16 12:15 PM, Rachel Protacio wrote:
> Hi, David,
>
> Thanks for that. I've corrected the issue in interpreterRuntime.cpp as 
> well as in klassVtable.cpp. Did you look at all the code - shall I 
> count you as a reviewer?
>
> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141564.04/
>
> Rachel
>
> On 12/8/2015 11:05 PM, David Holmes wrote:
>> Hi Rachel,
>>
>> src/share/vm/interpreter/interpreterRuntime.cpp
>>
>> The ResourceMark is now used outside of the actual logging code. If a 
>> ResourceMark is needed then I think we need to use the "if 
>> (log_is_enabled(...)" form.
>>
>> Thanks,
>> David
>>
>>
>>
>> On 9/12/2015 4:46 AM, Rachel Protacio wrote:
>>> Hi,
>>>
>>> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>>>> Rachel,
>>>>
>>>> Thank you for the updates.
>>>> Can you please sanity check one thing for me - the log_tables boolean
>>>> ?overrides? appears to
>>>> be set correctly in the callers, to mean ?yes, this overrides?.
>>>> In log_vtables, is it possible the choice of what to print is 
>>>> reversed?
>>>>
>>>> And perhaps add a check to your tests for example that ?NOT
>>>> overriding? catches the right case?
>>> Oh, good catch. Thank you - this is fixed now.
>>>>
>>>> And yes please on the assertion (I have seen null method bugs in
>>>> development and this code is an early
>>>> opportunity to catch that problem).
>>>>
>>>> I don?t need to see an updated web rev and you don?t need to rerun all
>>>> the tests to fix
>>>> the printed string.
>>> Great. Thanks again, Karen and Coleen! Will commit the change.
>>> Rachel
>>>> thanks,
>>>> Karen
>>>>
>>>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>>>> Hi, Karen,
>>>>>>
>>>>>> Thanks for the review. Updated webrev:
>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>>>
>>>>>> Since I never listed the tests I ran even the first time, here are
>>>>>> all of them:
>>>>>>
>>>>>> * jtreg
>>>>>> * JPRT
>>>>>> * jck vm, lang, & api/java_lang
>>>>>> * rbt quick and non-colo (which now includes defmeth)
>>>>>> * invoke*
>>>>>>
>>>>>> Replies inline.
>>>>>>
>>>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>>>> Rachel,
>>>>>>>
>>>>>>> Thank you so much for doing (and redoing) this.
>>>>>>>
>>>>>>> Couple of questions/comments.
>>>>>>>
>>>>>>> 1. thank you so much for the transitive overriding test - not easy
>>>>>>> to figure out how to generate one!
>>>>>>>
>>>>>> Lois walked me through doing that one :)
>>>>>>> 2. I missed the list of what you have tested for the first web rev
>>>>>>> and the other tests for this one
>>>>>>> I will assume in parallel with the code review you are running
>>>>>>> (without tracing)
>>>>>>> vm quick & nocolo, jck vm & lang
>>>>>>> defmeth, invoke*
>>>>>> Yeah, I totally forgot to email what tests I had run. Sorry about
>>>>>> that! And just learned how to run the jck tests.
>>>>>>> There might be value in running your new tests with old tracing vs.
>>>>>>> new and eyeballing the files - to see if they
>>>>>>> get essentially the same information.
>>>>>>>
>>>>>> Yup!
>>>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>>>> Would it make any sense to do if !klass()->is_array_klass() and
>>>>>>> then just use the log_develop_debug and
>>>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>>>
>>>>>> That makes sense. Changed as suggested.
>>>>>>> 4. thank you so much for extracting the print_linkage_flags - I
>>>>>>> should have done that earlier - the information
>>>>>>> just grew incrementally.
>>>>>>>
>>>>>>> 5. klassVtable.cpp line 1047 -
>>>>>>>    I think you want an if (m != NULL) here  before dereferencing to
>>>>>>> print_linkage_flags.
>>>>>>>    I see we miss that check for other dereferences -feel free to
>>>>>>> add small checks.
>>>>>>>    Don?t completely skip logic paragraphs except for printing ones.
>>>>>> Well, when I was making my change, we saw that it wouldn't be
>>>>>> possible for m to be null at that point in the code. There are
>>>>>> multiple places above it where it is dereferenced already, not to
>>>>>> mention the fact that it is theoretically initialized to be a valid
>>>>>> method. Would you like to me to add an assert after the declaration
>>>>>>     assert(m != NULL, "methods can never be null");
>>>>>> just to be safe?
>>>>> In the code here:
>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>
>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html> 
>>>>>
>>>>>
>>>>>
>>>>> Yes, Method* m = method->at(i); can never return NULL or else the
>>>>> whole VM would crash everywhere.  I suspect the logging code here was
>>>>> copied from other instances where 'm' could be null. This line
>>>>> would crash first:
>>>>>
>>>>> if (interface_method_needs_itable_index(m)) {
>>>>>
>>>>>
>>>>> Can you clean up this line also to not check for NULL:
>>>>>
>>>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() :
>>>>> "<NULL>";
>>>>>
>>>>>
>>>>> And add the assert if Karen agrees if it's needed.
>>>>>
>>>>> The rest of the changes look good.   I don't need to see another
>>>>> revision.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>>>     Thank you for leaving the null check in fill_in_miranda and
>>>>>>> print_method_at.
>>>>>>>
>>>>>>> 6. log_vtables
>>>>>>> The logic in update_inherited_vtables is quite complex.
>>>>>>> So the value of allocate_new is not really the right conditional to
>>>>>>> pass in to determine if there
>>>>>>> was an override.
>>>>>>>    The first paragraph applies both for allocate_new=true and
>>>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>>>
>>>>>>> So, perhaps you could add a boolean that says ?overrides? or
>>>>>>> ?overriding? or whatever : default it to false, and set it to true
>>>>>>> right after the put_method_at line (that iswhere the override
>>>>>>> occurs) and set it to false in the ?else? clause?
>>>>>>> And pass that argument in to log_vtables ? And remove the
>>>>>>> allocate_new comment from log_vtables as well?
>>>>>>>
>>>>>> Done, too.
>>>>>>
>>>>>> Thanks!!
>>>>>> Rachel
>>>>>>> And the comment in the ?else? is not accurate since I put the
>>>>>>> package_private fix in - so removing
>>>>>>> it was a good idea.
>>>>>>>
>>>>>>> many thanks,
>>>>>>> Karen
>>>>>>>
>>>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio
>>>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com>
>>>>>>>> <mailto:rachel.protacio at oracle.com
>>>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> Thanks for the comments! Updated
>>>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/
>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and
>>>>>>>> passes logging jtreg tests.)
>>>>>>>>
>>>>>>>> Replies inline.
>>>>>>>>
>>>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>>>> Rachel, There are a lot of changes here.  I have several comments
>>>>>>>>> and more suggested cleanup that should be done with this work.
>>>>>>>>>
>>>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I did the original refactoring for trace_method_resolution. What
>>>>>>>>> I think would be better is to make it an internal static function
>>>>>>>>> in linkResolver.cpp and not defined in the linkResolver.hpp.
>>>>>>>>> Make the call unconditional and pass vtable index in the last
>>>>>>>>> parameter as a default parameter with default value -1 so the
>>>>>>>>> last line in the function is the tty->cr() that I had outside the
>>>>>>>>> function call (that was pretty icky). And put all the
>>>>>>>>> ResourceMark and logstream logic inside the
>>>>>>>>> trace_method_resolution function.  It would never print to tty so
>>>>>>>>> doesn't need an outputStream parameter for other callers.
>>>>>>>>>
>>>>>>>>> So there would be only the one line
>>>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>>>> Thanks for the advice! I still have to call the function from
>>>>>>>> within the conditional because it's develop level only and because
>>>>>>>> I need to specify in the call whether it's for itables or vtables.
>>>>>>>> Otherwise, I've followed your suggestions.
>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you put these tags near each other?
>>>>>>>>>
>>>>>>>> I have them sorted alphabetically, which I think is more useful in
>>>>>>>> the long run.
>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> One of the things that Markus Gronlund's made me think that we
>>>>>>>>> should do with his cleanup is to stop declaring functions as
>>>>>>>>> members of classes if they don't need external linkage. From his
>>>>>>>>> RFR(L): 8140485: Class load and creation clean up:
>>>>>>>>>
>>>>>>>>> "Comment: In my opinion, we should attempt to break the pattern
>>>>>>>>> of having private functions declared in header files when the
>>>>>>>>> private function does not need to reach inside "this"."
>>>>>>>>>
>>>>>>>>> I think the function log_vtables should follow this and be
>>>>>>>>> declared as a static internal function in klassVtable.cpp above
>>>>>>>>> the function where it's used.
>>>>>>>>>
>>>>>>>>> It's true that you don't see this very much in the hotspot 
>>>>>>>>> sources.
>>>>>>>>>
>>>>>>>>> The refactoring of log_vtables is good and very much appreciated.
>>>>>>>>>
>>>>>>>>> In each of the logging blocks of code, there are about 6 lines
>>>>>>>>> that are about the same, that print the access flags and whether
>>>>>>>>> it's a default or overpass method.  (Karen and Lois should give
>>>>>>>>> you a TOI about what that means!)  Can you add a method to
>>>>>>>>> method.hpp that's something like print_flags(outputStream* st)
>>>>>>>>> and move this printing there, and make those blocks call your new
>>>>>>>>> function?  That would shorten many of these logging blocks of
>>>>>>>>> code and would be nice.  You could call this from the
>>>>>>>>> linkResolver.cpp trace_method_resolution() function too.
>>>>>>>> Done.
>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These classes have missing copyrights.
>>>>>>>> Fixed.
>>>>>>>> Thanks!
>>>>>>>> Rachel
>>>>>>>>> Thanks!
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review this changeset that converts -XX:+TraceItables and
>>>>>>>>>> -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>>>
>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/
>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>>>
>>>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp
>>>>>>>>>> around 462-498 are a refactoring of the duplicate code from a
>>>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Rachel
>>>
>


From jiangli.zhou at Oracle.COM  Thu Jan  7 18:50:06 2016
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Thu, 7 Jan 2016 10:50:06 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568DC7B4.1020403@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
Message-ID: <FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>

Hi Coleen,

> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> 
> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>> Hi David,
>> 
>>> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Jiangli,
>>> 
>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>> Hi,
>>>> 
>>>> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>> 
>>>>   http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>> 
>>>> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().
>>> I find this very confusing. Is there some document that describes the relationship between mapping, reserving and committing virtual memory and the related NMT functionality?
>> I agree. This is very confusing. I haven?t come across any document explaining the usage of the NMT APIs in different scenarios. My understand is based on reading the related code.
>> 
>>> It is not at all clear to me why reserve_and_commit pairs with uncommit (unless committed memory must first be reserved, and uncommit both uncommits and "unreserves" ??)
>> I dug deeper into it and found more issues. It appears MemTracker::record_virtual_memory_reserve_and_commit() should record the memory as both ?reserved? and ?committed?. However, that only happens if the memory region is not known by the VirtualMemoryTracker. If the memory overlaps with a known region in the VirtualMemoryTracker, MemTracker::record_virtual_memory_reserve_and_commit() could be a ?nop' in certain case. In the bug revealed by the specific test scenario, the memory region causing the issue is the CDS shared memory. Here are the call sequences related to the shared memory region:
>> 
>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared region. VirtualMemorySummary::record_reserved_memory is called and the memory is recored as ?reserved?.
>> 2.os::map_memory - each shared space within the shared memory region is mapped. MemTracker::record_virtual_memory_reserve_and_commit is called, the memory is not recounted. So the shared memory region is only counted as ?reserved? in NMT by previous VirtualMemorySummary::record_reserved_memory call.
>> 3.os::unmap_memory - record each shared space within the shared memory region with virtual_memory_release_tracker
>> 4 ReservedSpace::release (calls os::release_memory) - the virtual_memory_release_tracker is used again for the shared memory region.
>> 
>> On linux and all other non-windows platform, os::unmap_memory only unmap the memory (by calling system munmap) without ?release? the memory. On windows, unmap_memory also does ?release?.
> 
> Yes, this is the difference between windows and unix machines.  I think NMT was developed on windows.
>> 
>> So, there are at lease two issues:
>> 
>> The shared memory region is not recorded as ?committed?.
> 
> File a P4 bug on this because I don't think it causes any crashes. I think it may under count the amount of committed memory.   We can investigate.

I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.

> 
>> The shared memory region is counted twice as ?released?.
> 
> Your change conditionalized for Windows in os.cpp would be the best thing.  Making the NMT call at a lower level ie. pd_unmap_memory runs into the problem that there are duplicates for the xnix platforms.  Also, there are multiple returns that would need NMT logic so it wouldn't look good.  Also, there is risk because some of the os platforms call pd_unmap_memory by os::pd_attempt_reserve_memory_at() which would get the tracking wrong (I think).

Thanks for the suggestion. Here is the updated webrev:

http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/

Thanks!

Jiangli

> 
> Coleen
> 
>> Thanks,
>> Jiangli
>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> Tested with test/runtime/NMT.
>>>> 
>>>> Thanks,
>>>> Jiangli


From rachel.protacio at oracle.com  Thu Jan  7 19:01:41 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Thu, 7 Jan 2016 14:01:41 -0500
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <568EB048.6030102@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<56672598.2050905@oracle.com> <5667A875.6090208@oracle.com>
	<568E9D18.7040501@oracle.com> <568EB048.6030102@oracle.com>
Message-ID: <568EB615.5070409@oracle.com>

Great, thanks! I'll commit.
R

On 1/7/2016 1:36 PM, Coleen Phillimore wrote:
>
> This still looks good!  I think I interpreted David's comment to not 
> require another round, so I think he's a reviewer.
>
> Coleen
>
> On 1/7/16 12:15 PM, Rachel Protacio wrote:
>> Hi, David,
>>
>> Thanks for that. I've corrected the issue in interpreterRuntime.cpp 
>> as well as in klassVtable.cpp. Did you look at all the code - shall I 
>> count you as a reviewer?
>>
>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141564.04/
>>
>> Rachel
>>
>> On 12/8/2015 11:05 PM, David Holmes wrote:
>>> Hi Rachel,
>>>
>>> src/share/vm/interpreter/interpreterRuntime.cpp
>>>
>>> The ResourceMark is now used outside of the actual logging code. If 
>>> a ResourceMark is needed then I think we need to use the "if 
>>> (log_is_enabled(...)" form.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>
>>> On 9/12/2015 4:46 AM, Rachel Protacio wrote:
>>>> Hi,
>>>>
>>>> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>>>>> Rachel,
>>>>>
>>>>> Thank you for the updates.
>>>>> Can you please sanity check one thing for me - the log_tables boolean
>>>>> ?overrides? appears to
>>>>> be set correctly in the callers, to mean ?yes, this overrides?.
>>>>> In log_vtables, is it possible the choice of what to print is 
>>>>> reversed?
>>>>>
>>>>> And perhaps add a check to your tests for example that ?NOT
>>>>> overriding? catches the right case?
>>>> Oh, good catch. Thank you - this is fixed now.
>>>>>
>>>>> And yes please on the assertion (I have seen null method bugs in
>>>>> development and this code is an early
>>>>> opportunity to catch that problem).
>>>>>
>>>>> I don?t need to see an updated web rev and you don?t need to rerun 
>>>>> all
>>>>> the tests to fix
>>>>> the printed string.
>>>> Great. Thanks again, Karen and Coleen! Will commit the change.
>>>> Rachel
>>>>> thanks,
>>>>> Karen
>>>>>
>>>>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>>>>> Hi, Karen,
>>>>>>>
>>>>>>> Thanks for the review. Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>>>>
>>>>>>> Since I never listed the tests I ran even the first time, here are
>>>>>>> all of them:
>>>>>>>
>>>>>>> * jtreg
>>>>>>> * JPRT
>>>>>>> * jck vm, lang, & api/java_lang
>>>>>>> * rbt quick and non-colo (which now includes defmeth)
>>>>>>> * invoke*
>>>>>>>
>>>>>>> Replies inline.
>>>>>>>
>>>>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>>>>> Rachel,
>>>>>>>>
>>>>>>>> Thank you so much for doing (and redoing) this.
>>>>>>>>
>>>>>>>> Couple of questions/comments.
>>>>>>>>
>>>>>>>> 1. thank you so much for the transitive overriding test - not easy
>>>>>>>> to figure out how to generate one!
>>>>>>>>
>>>>>>> Lois walked me through doing that one :)
>>>>>>>> 2. I missed the list of what you have tested for the first web rev
>>>>>>>> and the other tests for this one
>>>>>>>> I will assume in parallel with the code review you are running
>>>>>>>> (without tracing)
>>>>>>>> vm quick & nocolo, jck vm & lang
>>>>>>>> defmeth, invoke*
>>>>>>> Yeah, I totally forgot to email what tests I had run. Sorry about
>>>>>>> that! And just learned how to run the jck tests.
>>>>>>>> There might be value in running your new tests with old tracing 
>>>>>>>> vs.
>>>>>>>> new and eyeballing the files - to see if they
>>>>>>>> get essentially the same information.
>>>>>>>>
>>>>>>> Yup!
>>>>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>>>>> Would it make any sense to do if !klass()->is_array_klass() and
>>>>>>>> then just use the log_develop_debug and
>>>>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>>>>
>>>>>>> That makes sense. Changed as suggested.
>>>>>>>> 4. thank you so much for extracting the print_linkage_flags - I
>>>>>>>> should have done that earlier - the information
>>>>>>>> just grew incrementally.
>>>>>>>>
>>>>>>>> 5. klassVtable.cpp line 1047 -
>>>>>>>>    I think you want an if (m != NULL) here  before 
>>>>>>>> dereferencing to
>>>>>>>> print_linkage_flags.
>>>>>>>>    I see we miss that check for other dereferences -feel free to
>>>>>>>> add small checks.
>>>>>>>>    Don?t completely skip logic paragraphs except for printing 
>>>>>>>> ones.
>>>>>>> Well, when I was making my change, we saw that it wouldn't be
>>>>>>> possible for m to be null at that point in the code. There are
>>>>>>> multiple places above it where it is dereferenced already, not to
>>>>>>> mention the fact that it is theoretically initialized to be a valid
>>>>>>> method. Would you like to me to add an assert after the declaration
>>>>>>>     assert(m != NULL, "methods can never be null");
>>>>>>> just to be safe?
>>>>>> In the code here:
>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>
>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html> 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, Method* m = method->at(i); can never return NULL or else the
>>>>>> whole VM would crash everywhere.  I suspect the logging code here 
>>>>>> was
>>>>>> copied from other instances where 'm' could be null. This line
>>>>>> would crash first:
>>>>>>
>>>>>> if (interface_method_needs_itable_index(m)) {
>>>>>>
>>>>>>
>>>>>> Can you clean up this line also to not check for NULL:
>>>>>>
>>>>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() :
>>>>>> "<NULL>";
>>>>>>
>>>>>>
>>>>>> And add the assert if Karen agrees if it's needed.
>>>>>>
>>>>>> The rest of the changes look good.   I don't need to see another
>>>>>> revision.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>>>     Thank you for leaving the null check in fill_in_miranda and
>>>>>>>> print_method_at.
>>>>>>>>
>>>>>>>> 6. log_vtables
>>>>>>>> The logic in update_inherited_vtables is quite complex.
>>>>>>>> So the value of allocate_new is not really the right 
>>>>>>>> conditional to
>>>>>>>> pass in to determine if there
>>>>>>>> was an override.
>>>>>>>>    The first paragraph applies both for allocate_new=true and
>>>>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>>>>
>>>>>>>> So, perhaps you could add a boolean that says ?overrides? or
>>>>>>>> ?overriding? or whatever : default it to false, and set it to true
>>>>>>>> right after the put_method_at line (that iswhere the override
>>>>>>>> occurs) and set it to false in the ?else? clause?
>>>>>>>> And pass that argument in to log_vtables ? And remove the
>>>>>>>> allocate_new comment from log_vtables as well?
>>>>>>>>
>>>>>>> Done, too.
>>>>>>>
>>>>>>> Thanks!!
>>>>>>> Rachel
>>>>>>>> And the comment in the ?else? is not accurate since I put the
>>>>>>>> package_private fix in - so removing
>>>>>>>> it was a good idea.
>>>>>>>>
>>>>>>>> many thanks,
>>>>>>>> Karen
>>>>>>>>
>>>>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio
>>>>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com>
>>>>>>>>> <mailto:rachel.protacio at oracle.com
>>>>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Thanks for the comments! Updated
>>>>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/
>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/ 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and
>>>>>>>>> passes logging jtreg tests.)
>>>>>>>>>
>>>>>>>>> Replies inline.
>>>>>>>>>
>>>>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>>>>> Rachel, There are a lot of changes here.  I have several 
>>>>>>>>>> comments
>>>>>>>>>> and more suggested cleanup that should be done with this work.
>>>>>>>>>>
>>>>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I did the original refactoring for trace_method_resolution. What
>>>>>>>>>> I think would be better is to make it an internal static 
>>>>>>>>>> function
>>>>>>>>>> in linkResolver.cpp and not defined in the linkResolver.hpp.
>>>>>>>>>> Make the call unconditional and pass vtable index in the last
>>>>>>>>>> parameter as a default parameter with default value -1 so the
>>>>>>>>>> last line in the function is the tty->cr() that I had outside 
>>>>>>>>>> the
>>>>>>>>>> function call (that was pretty icky). And put all the
>>>>>>>>>> ResourceMark and logstream logic inside the
>>>>>>>>>> trace_method_resolution function.  It would never print to 
>>>>>>>>>> tty so
>>>>>>>>>> doesn't need an outputStream parameter for other callers.
>>>>>>>>>>
>>>>>>>>>> So there would be only the one line
>>>>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>>>>> Thanks for the advice! I still have to call the function from
>>>>>>>>> within the conditional because it's develop level only and 
>>>>>>>>> because
>>>>>>>>> I need to specify in the call whether it's for itables or 
>>>>>>>>> vtables.
>>>>>>>>> Otherwise, I've followed your suggestions.
>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can you put these tags near each other?
>>>>>>>>>>
>>>>>>>>> I have them sorted alphabetically, which I think is more 
>>>>>>>>> useful in
>>>>>>>>> the long run.
>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> One of the things that Markus Gronlund's made me think that we
>>>>>>>>>> should do with his cleanup is to stop declaring functions as
>>>>>>>>>> members of classes if they don't need external linkage. From his
>>>>>>>>>> RFR(L): 8140485: Class load and creation clean up:
>>>>>>>>>>
>>>>>>>>>> "Comment: In my opinion, we should attempt to break the pattern
>>>>>>>>>> of having private functions declared in header files when the
>>>>>>>>>> private function does not need to reach inside "this"."
>>>>>>>>>>
>>>>>>>>>> I think the function log_vtables should follow this and be
>>>>>>>>>> declared as a static internal function in klassVtable.cpp above
>>>>>>>>>> the function where it's used.
>>>>>>>>>>
>>>>>>>>>> It's true that you don't see this very much in the hotspot 
>>>>>>>>>> sources.
>>>>>>>>>>
>>>>>>>>>> The refactoring of log_vtables is good and very much 
>>>>>>>>>> appreciated.
>>>>>>>>>>
>>>>>>>>>> In each of the logging blocks of code, there are about 6 lines
>>>>>>>>>> that are about the same, that print the access flags and whether
>>>>>>>>>> it's a default or overpass method.  (Karen and Lois should give
>>>>>>>>>> you a TOI about what that means!)  Can you add a method to
>>>>>>>>>> method.hpp that's something like print_flags(outputStream* st)
>>>>>>>>>> and move this printing there, and make those blocks call your 
>>>>>>>>>> new
>>>>>>>>>> function?  That would shorten many of these logging blocks of
>>>>>>>>>> code and would be nice.  You could call this from the
>>>>>>>>>> linkResolver.cpp trace_method_resolution() function too.
>>>>>>>>> Done.
>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These classes have missing copyrights.
>>>>>>>>> Fixed.
>>>>>>>>> Thanks!
>>>>>>>>> Rachel
>>>>>>>>>> Thanks!
>>>>>>>>>> Coleen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please review this changeset that converts -XX:+TraceItables 
>>>>>>>>>>> and
>>>>>>>>>>> -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>>>>
>>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/
>>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/>
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564
>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>>>>
>>>>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp
>>>>>>>>>>> around 462-498 are a refactoring of the duplicate code from a
>>>>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Rachel
>>>>
>>
>


From coleen.phillimore at oracle.com  Thu Jan  7 19:13:22 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 7 Jan 2016 14:13:22 -0500
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
Message-ID: <568EB8D2.2050604@oracle.com>


The latest webrev looks good.  Thank you for filing a bug on the other 
issue.

Thanks,
Coleen

On 1/7/16 1:50 PM, Jiangli Zhou wrote:
> Hi Coleen,
>
>> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore 
>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> 
>> wrote:
>>
>>
>>
>> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>>> Hi David,
>>>
>>>> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com 
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> Hi Jiangli,
>>>>
>>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the small fix for JDK-8146523 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>>>
>>>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Ejiangli/8146523/webrev.00/>
>>>>>
>>>>> The os::map_memory() and os:unmapp_memory() functions use the 
>>>>> memory tracker asymmetrically. The os::map_memory() function calls 
>>>>> MemTracker::record_virtual_memory_reserve_and_commit() to track 
>>>>> the mapped memory, while os::unmap_memory() uses the 
>>>>> 'virtual_memory_release_tracker' to track the memory being 
>>>>> unmapped. In NMT, there are different types of tracker for 
>>>>> releasing and uncommitting memory. The 
>>>>> ?virtual_memory_uncommit_tracker' is for 'uncommit? and 
>>>>> ?virtual_memory_release_tracker? is for 'release'. The 
>>>>> os::unmap_memory() should use the 
>>>>> ?virtual_memory_uncommit_tracker' to be balanced with 
>>>>> os::map_memory().
>>>> I find this very confusing. Is there some document that describes 
>>>> the relationship between mapping, reserving and committing virtual 
>>>> memory and the related NMT functionality?
>>> I agree. This is very confusing. I haven?t come across any document 
>>> explaining the usage of the NMT APIs in different scenarios. My 
>>> understand is based on reading the related code.
>>>
>>>> It is not at all clear to me why reserve_and_commit pairs with 
>>>> uncommit (unless committed memory must first be reserved, and 
>>>> uncommit both uncommits and "unreserves" ??)
>>> I dug deeper into it and found more issues. It appears 
>>> MemTracker::record_virtual_memory_reserve_and_commit() should record 
>>> the memory as both ?reserved? and ?committed?. However, that only 
>>> happens if the memory region is not known by the 
>>> VirtualMemoryTracker. If the memory overlaps with a known region in 
>>> the VirtualMemoryTracker, 
>>> MemTracker::record_virtual_memory_reserve_and_commit() could be a 
>>> ?nop' in certain case. In the bug revealed by the specific test 
>>> scenario, the memory region causing the issue is the CDS shared 
>>> memory. Here are the call sequences related to the shared memory region:
>>>
>>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared 
>>> region. VirtualMemorySummary::record_reserved_memory is called and 
>>> the memory is recored as ?reserved?.
>>> 2.os::map_memory - each shared space within the shared memory region 
>>> is mapped. MemTracker::record_virtual_memory_reserve_and_commit is 
>>> called, the memory is not recounted. So the shared memory region is 
>>> only counted as ?reserved? in NMT by previous 
>>> VirtualMemorySummary::record_reserved_memory call.
>>> 3.os::unmap_memory - record each shared space within the shared 
>>> memory region with virtual_memory_release_tracker
>>> 4 ReservedSpace::release (calls os::release_memory) - the 
>>> virtual_memory_release_tracker is used again for the shared memory 
>>> region.
>>>
>>> On linux and all other non-windows platform, os::unmap_memory only 
>>> unmap the memory (by calling system munmap) without ?release? the 
>>> memory. On windows, unmap_memory also does ?release?.
>>
>> Yes, this is the difference between windows and unix machines.  I 
>> think NMT was developed on windows.
>>>
>>> So, there are at lease two issues:
>>>
>>> The shared memory region is not recorded as ?committed?.
>>
>> File a P4 bug on this because I don't think it causes any crashes. I 
>> think it may under count the amount of committed memory.   We can 
>> investigate.
>
> I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.
>
>>
>>> The shared memory region is counted twice as ?released?.
>>
>> Your change conditionalized for Windows in os.cpp would be the best 
>> thing.  Making the NMT call at a lower level ie. pd_unmap_memory runs 
>> into the problem that there are duplicates for the xnix platforms. 
>>  Also, there are multiple returns that would need NMT logic so it 
>> wouldn't look good.  Also, there is risk because some of the os 
>> platforms call pd_unmap_memory by os::pd_attempt_reserve_memory_at() 
>> which would get the tracking wrong (I think).
>
> Thanks for the suggestion. Here is the updated webrev:
>
> http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ejiangli/8146523/webrev.01/>
>
> Thanks!
>
> Jiangli
>
>>
>> Coleen
>>
>>> Thanks,
>>> Jiangli
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> Tested with test/runtime/NMT.
>>>>>
>>>>> Thanks,
>>>>> Jiangli
>


From ioi.lam at oracle.com  Thu Jan  7 19:34:22 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 07 Jan 2016 11:34:22 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>	<568CB531.5080608@oracle.com>	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
Message-ID: <568EBDBE.3010003@oracle.com>

Hi Jiangli,

I looked at the implementatiion of os::pd_unmap_memory on windows but I 
can't figure out how it would affect the memory tracker:

os.cpp:

       bool os::unmap_memory(char *addr, size_t bytes) {
         bool result;
         if (MemTracker::tracking_level() > NMT_minimal) {
    + #ifndef _WINDOWS
    +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
    + #else
    +     // Windows pd_unmap_memory also does memory release, so use
    +     // the virtual_memory_release_tracker for windows
           Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
    + #endif

os_windows.cpp:

    bool os::pd_unmap_memory(char* addr, size_t bytes) {
       MEMORY_BASIC_INFORMATION mem_info;
       if (VirtualQuery(addr, &mem_info, sizeof(mem_info)) == 0) {
         if (PrintMiscellaneous && Verbose) {
           DWORD err = GetLastError();
           tty->print_cr("VirtualQuery() failed: GetLastError->%ld.", err);
         }
         return false;
       }

       // Executable memory was not mapped using
    CreateFileMapping/MapViewOfFileEx.
       // Instead, executable region was allocated using VirtualAlloc(). See
       // pd_map_memory() above.
       //
       // The following flags should match the 'exec_access' flages used for
       // VirtualProtect() in pd_map_memory().
       if (mem_info.Protect == PAGE_EXECUTE_READ ||
           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
         return pd_release_memory(addr, bytes);
       }

       BOOL result = UnmapViewOfFile(addr);
       if (result == 0) {
         if (PrintMiscellaneous && Verbose) {
           DWORD err = GetLastError();
           tty->print_cr("UnmapViewOfFile() failed: GetLastError->%ld.",
    err);
         }
         return false;
       }
       return true;
    }

    bool os::pd_release_memory(char* addr, size_t bytes) {
       return VirtualFree(addr, 0, MEM_RELEASE) != 0;
    }

Note this code doesn't use MemTracker at all.

So I have the fear that this fix doesn't really address the problem, and 
potentially it could cause other issues for the non-windows platforms, 
since you're unconditionally switching the code to use a different tracker.

I noticed the different usage of MemTracker in the os_<xxx>.cpp files:

    hotspot/src/os$ grep MemTracker:: */*/os_*.cpp | sed -e
    's/[(][^(]*//g'  | sort | uniq

    ./bsd/vm/os_bsd.cpp:
    MemTracker::record_virtual_memory_reserve_and_commit
    ./bsd/vm/os_bsd.cpp:                  Tracker tkr =
    MemTracker::get_virtual_memory_release_tracker
    ./linux/vm/os_linux.cpp:
    MemTracker::record_virtual_memory_reserve_and_commit
    ./linux/vm/os_linux.cpp:              Tracker tkr =
    MemTracker::get_virtual_memory_release_tracker
    ./windows/vm/os_windows.cpp: MemTracker::record_virtual_memory_reserve
    ./windows/vm/os_windows.cpp:
    MemTracker::record_virtual_memory_reserve_and_commit

So ONLY windows calls MemTracker::record_virtual_memory_reserve (under 
allocate_pages_individually). Perhaps this is a better explanation why 
NMT behaves differently on Windows vs other platforms?

Without understand how NMT works under all conditions, I would hesitate 
to make the change you're proposing.

Thanks
- Ioi

On 1/7/16 10:50 AM, Jiangli Zhou wrote:
> Hi Coleen,
>
>> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>>
>> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>>> Hi David,
>>>
>>>> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Jiangli,
>>>>
>>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>>>
>>>>>    http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>>>
>>>>> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().
>>>> I find this very confusing. Is there some document that describes the relationship between mapping, reserving and committing virtual memory and the related NMT functionality?
>>> I agree. This is very confusing. I haven?t come across any document explaining the usage of the NMT APIs in different scenarios. My understand is based on reading the related code.
>>>
>>>> It is not at all clear to me why reserve_and_commit pairs with uncommit (unless committed memory must first be reserved, and uncommit both uncommits and "unreserves" ??)
>>> I dug deeper into it and found more issues. It appears MemTracker::record_virtual_memory_reserve_and_commit() should record the memory as both ?reserved? and ?committed?. However, that only happens if the memory region is not known by the VirtualMemoryTracker. If the memory overlaps with a known region in the VirtualMemoryTracker, MemTracker::record_virtual_memory_reserve_and_commit() could be a ?nop' in certain case. In the bug revealed by the specific test scenario, the memory region causing the issue is the CDS shared memory. Here are the call sequences related to the shared memory region:
>>>
>>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared region. VirtualMemorySummary::record_reserved_memory is called and the memory is recored as ?reserved?.
>>> 2.os::map_memory - each shared space within the shared memory region is mapped. MemTracker::record_virtual_memory_reserve_and_commit is called, the memory is not recounted. So the shared memory region is only counted as ?reserved? in NMT by previous VirtualMemorySummary::record_reserved_memory call.
>>> 3.os::unmap_memory - record each shared space within the shared memory region with virtual_memory_release_tracker
>>> 4 ReservedSpace::release (calls os::release_memory) - the virtual_memory_release_tracker is used again for the shared memory region.
>>>
>>> On linux and all other non-windows platform, os::unmap_memory only unmap the memory (by calling system munmap) without ?release? the memory. On windows, unmap_memory also does ?release?.
>> Yes, this is the difference between windows and unix machines.  I think NMT was developed on windows.
>>> So, there are at lease two issues:
>>>
>>> The shared memory region is not recorded as ?committed?.
>> File a P4 bug on this because I don't think it causes any crashes. I think it may under count the amount of committed memory.   We can investigate.
> I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.
>
>>> The shared memory region is counted twice as ?released?.
>> Your change conditionalized for Windows in os.cpp would be the best thing.  Making the NMT call at a lower level ie. pd_unmap_memory runs into the problem that there are duplicates for the xnix platforms.  Also, there are multiple returns that would need NMT logic so it wouldn't look good.  Also, there is risk because some of the os platforms call pd_unmap_memory by os::pd_attempt_reserve_memory_at() which would get the tracking wrong (I think).
> Thanks for the suggestion. Here is the updated webrev:
>
> http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/
>
> Thanks!
>
> Jiangli
>
>> Coleen
>>
>>> Thanks,
>>> Jiangli
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> Tested with test/runtime/NMT.
>>>>>
>>>>> Thanks,
>>>>> Jiangli


From coleen.phillimore at oracle.com  Thu Jan  7 19:51:41 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 7 Jan 2016 14:51:41 -0500
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EBDBE.3010003@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com>
Message-ID: <568EC1CD.1060109@oracle.com>



On 1/7/16 2:34 PM, Ioi Lam wrote:
> Hi Jiangli,
>
> I looked at the implementatiion of os::pd_unmap_memory on windows but 
> I can't figure out how it would affect the memory tracker:
>
> os.cpp:
>
>       bool os::unmap_memory(char *addr, size_t bytes) {
>         bool result;
>         if (MemTracker::tracking_level() > NMT_minimal) {
>    + #ifndef _WINDOWS
>    +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>    + #else
>    +     // Windows pd_unmap_memory also does memory release, so use
>    +     // the virtual_memory_release_tracker for windows
>           Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>    + #endif
>
> os_windows.cpp:
>
>    bool os::pd_unmap_memory(char* addr, size_t bytes) {
>       MEMORY_BASIC_INFORMATION mem_info;
>       if (VirtualQuery(addr, &mem_info, sizeof(mem_info)) == 0) {
>         if (PrintMiscellaneous && Verbose) {
>           DWORD err = GetLastError();
>           tty->print_cr("VirtualQuery() failed: GetLastError->%ld.", 
> err);
>         }
>         return false;
>       }
>
>       // Executable memory was not mapped using
>    CreateFileMapping/MapViewOfFileEx.
>       // Instead, executable region was allocated using 
> VirtualAlloc(). See
>       // pd_map_memory() above.
>       //
>       // The following flags should match the 'exec_access' flages 
> used for
>       // VirtualProtect() in pd_map_memory().
>       if (mem_info.Protect == PAGE_EXECUTE_READ ||
>           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>         return pd_release_memory(addr, bytes);
>       }
>
>       BOOL result = UnmapViewOfFile(addr);
>       if (result == 0) {
>         if (PrintMiscellaneous && Verbose) {
>           DWORD err = GetLastError();
>           tty->print_cr("UnmapViewOfFile() failed: GetLastError->%ld.",
>    err);
>         }
>         return false;
>       }
>       return true;
>    }
>
>    bool os::pd_release_memory(char* addr, size_t bytes) {
>       return VirtualFree(addr, 0, MEM_RELEASE) != 0;
>    }
>
> Note this code doesn't use MemTracker at all.

Right, because the MemTracker call is done at the higher level so 
pd_unmap_memory just does the unmapping.

>
> So I have the fear that this fix doesn't really address the problem, 
> and potentially it could cause other issues for the non-windows 
> platforms, since you're unconditionally switching the code to use a 
> different tracker.
>
> I noticed the different usage of MemTracker in the os_<xxx>.cpp files:
>
>    hotspot/src/os$ grep MemTracker:: */*/os_*.cpp | sed -e
>    's/[(][^(]*//g'  | sort | uniq
>
>    ./bsd/vm/os_bsd.cpp:
>    MemTracker::record_virtual_memory_reserve_and_commit
>    ./bsd/vm/os_bsd.cpp:                  Tracker tkr =
>    MemTracker::get_virtual_memory_release_tracker
>    ./linux/vm/os_linux.cpp:
>    MemTracker::record_virtual_memory_reserve_and_commit
>    ./linux/vm/os_linux.cpp:              Tracker tkr =
>    MemTracker::get_virtual_memory_release_tracker
>    ./windows/vm/os_windows.cpp: MemTracker::record_virtual_memory_reserve
>    ./windows/vm/os_windows.cpp:
>    MemTracker::record_virtual_memory_reserve_and_commit
>
> So ONLY windows calls MemTracker::record_virtual_memory_reserve (under 
> allocate_pages_individually). Perhaps this is a better explanation why 
> NMT behaves differently on Windows vs other platforms?

No, I think it's because on Linux, you call os::reserve_memory() 
allocation on the whole CDS archive and call os::map_memory() to map 
them to the archive file.   On windows, the os::reserve_memory() isn't done.

There are some workarounds (hacks) to MemTracker in the os specific 
files.  They are to handle large pages (the os::reserve_memory_special 
file is pushed to the platform specific files so needs to have NMT 
tracking there), and for windows, a special case because it has to 
reserve and unreserve memory.

ie.
   MemTracker::record_virtual_memory_reserve((address)p_buf, 
size_of_reserve, CALLER_PC);
   os::release_memory(p_buf, bytes + chunk_size);

os::release_memory() calls virtual_memory_release so we have to make 
sure NMT counts it as reserved first.  This should probably call 
pd_release_memory.

The function allocate_pages_individually looks like it's to handle 
NUMA/large pages also.  I think the else case in os::pd_reserve_memory() 
is odd, but I think this is unrelated to Jiangli's problem.
>
> Without understand how NMT works under all conditions, I would 
> hesitate to make the change you're proposing.
>

I think the change is perfectly safe.  It doesn't change existing 
behavior for windows and fixes a known crash for a reason we understand 
for Linux.

Coleen

> Thanks
> - Ioi
>
> On 1/7/16 10:50 AM, Jiangli Zhou wrote:
>> Hi Coleen,
>>
>>> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>>
>>> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>>>> Hi David,
>>>>
>>>>> On Jan 5, 2016, at 10:33 PM, David Holmes 
>>>>> <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the small fix for JDK-8146523 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>>>>
>>>>>> The os::map_memory() and os:unmapp_memory() functions use the 
>>>>>> memory tracker asymmetrically. The os::map_memory() function 
>>>>>> calls MemTracker::record_virtual_memory_reserve_and_commit() to 
>>>>>> track the mapped memory, while os::unmap_memory() uses the 
>>>>>> 'virtual_memory_release_tracker' to track the memory being 
>>>>>> unmapped. In NMT, there are different types of tracker for 
>>>>>> releasing and uncommitting memory. The 
>>>>>> ?virtual_memory_uncommit_tracker' is for 'uncommit? and 
>>>>>> ?virtual_memory_release_tracker? is for 'release'. The 
>>>>>> os::unmap_memory() should use the 
>>>>>> ?virtual_memory_uncommit_tracker' to be balanced with 
>>>>>> os::map_memory().
>>>>> I find this very confusing. Is there some document that describes 
>>>>> the relationship between mapping, reserving and committing virtual 
>>>>> memory and the related NMT functionality?
>>>> I agree. This is very confusing. I haven?t come across any document 
>>>> explaining the usage of the NMT APIs in different scenarios. My 
>>>> understand is based on reading the related code.
>>>>
>>>>> It is not at all clear to me why reserve_and_commit pairs with 
>>>>> uncommit (unless committed memory must first be reserved, and 
>>>>> uncommit both uncommits and "unreserves" ??)
>>>> I dug deeper into it and found more issues. It appears 
>>>> MemTracker::record_virtual_memory_reserve_and_commit() should 
>>>> record the memory as both ?reserved? and ?committed?. However, that 
>>>> only happens if the memory region is not known by the 
>>>> VirtualMemoryTracker. If the memory overlaps with a known region in 
>>>> the VirtualMemoryTracker, 
>>>> MemTracker::record_virtual_memory_reserve_and_commit() could be a 
>>>> ?nop' in certain case. In the bug revealed by the specific test 
>>>> scenario, the memory region causing the issue is the CDS shared 
>>>> memory. Here are the call sequences related to the shared memory 
>>>> region:
>>>>
>>>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared 
>>>> region. VirtualMemorySummary::record_reserved_memory is called and 
>>>> the memory is recored as ?reserved?.
>>>> 2.os::map_memory - each shared space within the shared memory 
>>>> region is mapped. 
>>>> MemTracker::record_virtual_memory_reserve_and_commit is called, the 
>>>> memory is not recounted. So the shared memory region is only 
>>>> counted as ?reserved? in NMT by previous 
>>>> VirtualMemorySummary::record_reserved_memory call.
>>>> 3.os::unmap_memory - record each shared space within the shared 
>>>> memory region with virtual_memory_release_tracker
>>>> 4 ReservedSpace::release (calls os::release_memory) - the 
>>>> virtual_memory_release_tracker is used again for the shared memory 
>>>> region.
>>>>
>>>> On linux and all other non-windows platform, os::unmap_memory only 
>>>> unmap the memory (by calling system munmap) without ?release? the 
>>>> memory. On windows, unmap_memory also does ?release?.
>>> Yes, this is the difference between windows and unix machines.  I 
>>> think NMT was developed on windows.
>>>> So, there are at lease two issues:
>>>>
>>>> The shared memory region is not recorded as ?committed?.
>>> File a P4 bug on this because I don't think it causes any crashes. I 
>>> think it may under count the amount of committed memory.   We can 
>>> investigate.
>> I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.
>>
>>>> The shared memory region is counted twice as ?released?.
>>> Your change conditionalized for Windows in os.cpp would be the best 
>>> thing.  Making the NMT call at a lower level ie. pd_unmap_memory 
>>> runs into the problem that there are duplicates for the xnix 
>>> platforms.  Also, there are multiple returns that would need NMT 
>>> logic so it wouldn't look good. Also, there is risk because some of 
>>> the os platforms call pd_unmap_memory by 
>>> os::pd_attempt_reserve_memory_at() which would get the tracking 
>>> wrong (I think).
>> Thanks for the suggestion. Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/
>>
>> Thanks!
>>
>> Jiangli
>>
>>> Coleen
>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>> Tested with test/runtime/NMT.
>>>>>>
>>>>>> Thanks,
>>>>>> Jiangli
>


From marcins at microsoft.com  Thu Jan  7 19:52:49 2016
From: marcins at microsoft.com (Martin Sawicki)
Date: Thu, 7 Jan 2016 19:52:49 +0000
Subject: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS
	is handled
Message-ID: <BLUPR03MB4401F0B59C525FCC21047D8A8F50@BLUPR03MB440.namprd03.prod.outlook.com>

Hi all
Any other news/feedback on this bug fix submission?
Best regards
Martin

-----Original Message-----
From: Martin Sawicki 
Sent: Monday, September 28, 2015 11:11 AM
To: 'Andrei Pangin' <andrei.pangin at gmail.com>; hotspot-runtime-dev at openjdk.java.net; Vladimir Shcherbakov <vlashch at microsoft.com>
Subject: RE: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

Hi all
Here is the updated webrev attempting to take into account the feedback we've received.

Issue:  
  https://bugs.openjdk.java.net/browse/JDK-6415680

Webrev:
  http://cr.openjdk.java.net/~kshoop/6415680/webrev.01/ 

(Vladimir Shcherbakov is working on this now from our side)

Looking forward to any other feedback
Thanks

-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrei Pangin
Sent: Wednesday, June 24, 2015 5:49 PM
To: Kirk Shoop (MS OPEN TECH) <Kirk.Shoop at microsoft.com>
Cc: Valery Kopylov (Akvelon) <v-valkop at microsoft.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

Hi Kirk,

Thanks for looking into this long-standing bug.
I personally hit this issue several times and also attempted to address it.
Your fix is good, but it does not work in some cases.
Current implementation of the signal handler sets thread's async exception and then simply returns control to the next instruction.
This works fine for Unsafe_getX/Unsafe_setX, but not for Unsafe_CopyMemory which repeats loads or stores in the loop.
Each iteration will repeatedly produce EXCEPTION_IN_PAGE_ERROR until the loop ends. This can take hours for a long loop, e.g. if the target array is hundred megabytes large. The process will look hanging utilizing 100% of one CPU core.

One of the possible solutions is to demarcate the boundaries of the copying loop so that handle_unsafe_access() could detect if the exception occured in the loop and bail out.

A similar problem could probably happen in Unsafe_SetMemory as well. So I suggest to include it in the fix, too.

Regards,
  Andrei

2015-06-24 19:37 GMT+03:00 Kirk Shoop (MS OPEN TECH) <
Kirk.Shoop at microsoft.com>:

> > -----Original Message-----
> > From: David Holmes [mailto:david.holmes at oracle.com]
> > Subject: Re: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just 
> > as SIGBUS is handled
> >
> > On 24/06/2015 4:30 PM, Alan Bateman wrote:
> > >
> > >
> > > Kirk - as this is changing code in HotSpot then it's best to bring 
> > > this to hotspot-runtime-dev for review + sponsor.
> >
> > Not only "best" but required :)
> >
> > Hi Kirk, it is great to see active participation from MS here! To 
> > push
> this to
> > hotspot it needs to be re-based against one of the team repos - and 
> > I
> think
> > runtime is the right fit here as it owns the OS specific code and 
> > the
> unsafe
> > interface:
> >
> > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot
>
> Okay, will do.
>
> >
> > Thanks,
> > David
> >
> > > -Alan
>
> Thank you,
> Kirk
>
> Developer
> Microsoft Open Technologies, Inc.
>

From coleen.phillimore at oracle.com  Thu Jan  7 20:02:41 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 7 Jan 2016 15:02:41 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
Message-ID: <568EC461.8030209@oracle.com>

Summary: Add clear() to the assignment operator and add copy constructor.

Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with 
PrintSymbolTableSizeHistogram statistics:

   Percent removed          1.35
   Reference counts          194583

clean:

   Percent removed          1.53
   Reference counts          194245

Without a reference counting copy constructor, we could remove a 
TempNewSymbol's Symbol if a GC happens.  Consider:

TempNewSymbol ts = SymbolTable::new_symbol("abc");
// Hit GC

The ref count for "abc" is 1 when created by new_symbol, and the 
destructor could run after the copy into ts, decrementing the reference 
count to 0 again.  GC could unlink that symbol from the symbol table.  
Fortunately, we haven't seen this bug.

open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
bug link https://bugs.openjdk.java.net/browse/JDK-8145940

Thanks,
Coleen

From ioi.lam at oracle.com  Thu Jan  7 20:23:24 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 07 Jan 2016 12:23:24 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EC1CD.1060109@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>	<568CB531.5080608@oracle.com>	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>	<568DC7B4.1020403@oracle.com>	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>	<568EBDBE.3010003@oracle.com>
	<568EC1CD.1060109@oracle.com>
Message-ID: <568EC93C.1020906@oracle.com>



On 1/7/16 11:51 AM, Coleen Phillimore wrote:
>
>
> On 1/7/16 2:34 PM, Ioi Lam wrote:
>> Hi Jiangli,
>>
>> I looked at the implementatiion of os::pd_unmap_memory on windows but 
>> I can't figure out how it would affect the memory tracker:
>>
>> os.cpp:
>>
>>       bool os::unmap_memory(char *addr, size_t bytes) {
>>         bool result;
>>         if (MemTracker::tracking_level() > NMT_minimal) {
>>    + #ifndef _WINDOWS
>>    +     Tracker tkr = 
>> MemTracker::get_virtual_memory_uncommit_tracker();
>>    + #else
>>    +     // Windows pd_unmap_memory also does memory release, so use
>>    +     // the virtual_memory_release_tracker for windows
>>           Tracker tkr = 
>> MemTracker::get_virtual_memory_release_tracker();
>>    + #endif
>>
>> os_windows.cpp:
>>
>>    bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>       MEMORY_BASIC_INFORMATION mem_info;
>>       if (VirtualQuery(addr, &mem_info, sizeof(mem_info)) == 0) {
>>         if (PrintMiscellaneous && Verbose) {
>>           DWORD err = GetLastError();
>>           tty->print_cr("VirtualQuery() failed: GetLastError->%ld.", 
>> err);
>>         }
>>         return false;
>>       }
>>
>>       // Executable memory was not mapped using
>>    CreateFileMapping/MapViewOfFileEx.
>>       // Instead, executable region was allocated using 
>> VirtualAlloc(). See
>>       // pd_map_memory() above.
>>       //
>>       // The following flags should match the 'exec_access' flages 
>> used for
>>       // VirtualProtect() in pd_map_memory().
>>       if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>         return pd_release_memory(addr, bytes);
>>       }
>>
>>       BOOL result = UnmapViewOfFile(addr);
>>       if (result == 0) {
>>         if (PrintMiscellaneous && Verbose) {
>>           DWORD err = GetLastError();
>>           tty->print_cr("UnmapViewOfFile() failed: GetLastError->%ld.",
>>    err);
>>         }
>>         return false;
>>       }
>>       return true;
>>    }
>>
>>    bool os::pd_release_memory(char* addr, size_t bytes) {
>>       return VirtualFree(addr, 0, MEM_RELEASE) != 0;
>>    }
>>
>> Note this code doesn't use MemTracker at all.
>
> Right, because the MemTracker call is done at the higher level so 
> pd_unmap_memory just does the unmapping.
>
>>
>> So I have the fear that this fix doesn't really address the problem, 
>> and potentially it could cause other issues for the non-windows 
>> platforms, since you're unconditionally switching the code to use a 
>> different tracker.
>>
>> I noticed the different usage of MemTracker in the os_<xxx>.cpp files:
>>
>>    hotspot/src/os$ grep MemTracker:: */*/os_*.cpp | sed -e
>>    's/[(][^(]*//g'  | sort | uniq
>>
>>    ./bsd/vm/os_bsd.cpp:
>>    MemTracker::record_virtual_memory_reserve_and_commit
>>    ./bsd/vm/os_bsd.cpp:                  Tracker tkr =
>>    MemTracker::get_virtual_memory_release_tracker
>>    ./linux/vm/os_linux.cpp:
>>    MemTracker::record_virtual_memory_reserve_and_commit
>>    ./linux/vm/os_linux.cpp:              Tracker tkr =
>>    MemTracker::get_virtual_memory_release_tracker
>>    ./windows/vm/os_windows.cpp: 
>> MemTracker::record_virtual_memory_reserve
>>    ./windows/vm/os_windows.cpp:
>>    MemTracker::record_virtual_memory_reserve_and_commit
>>
>> So ONLY windows calls MemTracker::record_virtual_memory_reserve 
>> (under allocate_pages_individually). Perhaps this is a better 
>> explanation why NMT behaves differently on Windows vs other platforms?
>
> No, I think it's because on Linux, you call os::reserve_memory() 
> allocation on the whole CDS archive and call os::map_memory() to map 
> them to the archive file.   On windows, the os::reserve_memory() isn't 
> done.
>
> There are some workarounds (hacks) to MemTracker in the os specific 
> files.  They are to handle large pages (the os::reserve_memory_special 
> file is pushed to the platform specific files so needs to have NMT 
> tracking there), and for windows, a special case because it has to 
> reserve and unreserve memory.
>
> ie.
>   MemTracker::record_virtual_memory_reserve((address)p_buf, 
> size_of_reserve, CALLER_PC);
>   os::release_memory(p_buf, bytes + chunk_size);
>
> os::release_memory() calls virtual_memory_release so we have to make 
> sure NMT counts it as reserved first.  This should probably call 
> pd_release_memory.
>
> The function allocate_pages_individually looks like it's to handle 
> NUMA/large pages also.  I think the else case in 
> os::pd_reserve_memory() is odd, but I think this is unrelated to 
> Jiangli's problem.
>>
>> Without understand how NMT works under all conditions, I would 
>> hesitate to make the change you're proposing.
>>
>
> I think the change is perfectly safe.  It doesn't change existing 
> behavior for windows and fixes a known crash for a reason we 
> understand for Linux.

OK, I trust you -- although I suspect nightly tests may find cases where 
we call os::unmap_memory() on a block that wasn't returned by 
os::map_memory, and NMT would complain that the block wasn't marked as 
committed. But that would be a bug of the caller of os::unmap_memory, 
but an NMT bug.

In any case, the comment needs to be fixed to explain why the #ifdef is 
needed. The current comment is wrong.

Thanks
- Ioi

> Coleen
>
>> Thanks
>> - Ioi
>>
>> On 1/7/16 10:50 AM, Jiangli Zhou wrote:
>>> Hi Coleen,
>>>
>>>> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore 
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>
>>>>
>>>> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>>>>> Hi David,
>>>>>
>>>>>> On Jan 5, 2016, at 10:33 PM, David Holmes 
>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the small fix for JDK-8146523 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>>>>>
>>>>>>> The os::map_memory() and os:unmapp_memory() functions use the 
>>>>>>> memory tracker asymmetrically. The os::map_memory() function 
>>>>>>> calls MemTracker::record_virtual_memory_reserve_and_commit() to 
>>>>>>> track the mapped memory, while os::unmap_memory() uses the 
>>>>>>> 'virtual_memory_release_tracker' to track the memory being 
>>>>>>> unmapped. In NMT, there are different types of tracker for 
>>>>>>> releasing and uncommitting memory. The 
>>>>>>> ?virtual_memory_uncommit_tracker' is for 'uncommit? and 
>>>>>>> ?virtual_memory_release_tracker? is for 'release'. The 
>>>>>>> os::unmap_memory() should use the 
>>>>>>> ?virtual_memory_uncommit_tracker' to be balanced with 
>>>>>>> os::map_memory().
>>>>>> I find this very confusing. Is there some document that describes 
>>>>>> the relationship between mapping, reserving and committing 
>>>>>> virtual memory and the related NMT functionality?
>>>>> I agree. This is very confusing. I haven?t come across any 
>>>>> document explaining the usage of the NMT APIs in different 
>>>>> scenarios. My understand is based on reading the related code.
>>>>>
>>>>>> It is not at all clear to me why reserve_and_commit pairs with 
>>>>>> uncommit (unless committed memory must first be reserved, and 
>>>>>> uncommit both uncommits and "unreserves" ??)
>>>>> I dug deeper into it and found more issues. It appears 
>>>>> MemTracker::record_virtual_memory_reserve_and_commit() should 
>>>>> record the memory as both ?reserved? and ?committed?. However, 
>>>>> that only happens if the memory region is not known by the 
>>>>> VirtualMemoryTracker. If the memory overlaps with a known region 
>>>>> in the VirtualMemoryTracker, 
>>>>> MemTracker::record_virtual_memory_reserve_and_commit() could be a 
>>>>> ?nop' in certain case. In the bug revealed by the specific test 
>>>>> scenario, the memory region causing the issue is the CDS shared 
>>>>> memory. Here are the call sequences related to the shared memory 
>>>>> region:
>>>>>
>>>>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared 
>>>>> region. VirtualMemorySummary::record_reserved_memory is called and 
>>>>> the memory is recored as ?reserved?.
>>>>> 2.os::map_memory - each shared space within the shared memory 
>>>>> region is mapped. 
>>>>> MemTracker::record_virtual_memory_reserve_and_commit is called, 
>>>>> the memory is not recounted. So the shared memory region is only 
>>>>> counted as ?reserved? in NMT by previous 
>>>>> VirtualMemorySummary::record_reserved_memory call.
>>>>> 3.os::unmap_memory - record each shared space within the shared 
>>>>> memory region with virtual_memory_release_tracker
>>>>> 4 ReservedSpace::release (calls os::release_memory) - the 
>>>>> virtual_memory_release_tracker is used again for the shared memory 
>>>>> region.
>>>>>
>>>>> On linux and all other non-windows platform, os::unmap_memory only 
>>>>> unmap the memory (by calling system munmap) without ?release? the 
>>>>> memory. On windows, unmap_memory also does ?release?.
>>>> Yes, this is the difference between windows and unix machines.  I 
>>>> think NMT was developed on windows.
>>>>> So, there are at lease two issues:
>>>>>
>>>>> The shared memory region is not recorded as ?committed?.
>>>> File a P4 bug on this because I don't think it causes any crashes. 
>>>> I think it may under count the amount of committed memory.   We can 
>>>> investigate.
>>> I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.
>>>
>>>>> The shared memory region is counted twice as ?released?.
>>>> Your change conditionalized for Windows in os.cpp would be the best 
>>>> thing.  Making the NMT call at a lower level ie. pd_unmap_memory 
>>>> runs into the problem that there are duplicates for the xnix 
>>>> platforms.  Also, there are multiple returns that would need NMT 
>>>> logic so it wouldn't look good. Also, there is risk because some of 
>>>> the os platforms call pd_unmap_memory by 
>>>> os::pd_attempt_reserve_memory_at() which would get the tracking 
>>>> wrong (I think).
>>> Thanks for the suggestion. Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/
>>>
>>> Thanks!
>>>
>>> Jiangli
>>>
>>>> Coleen
>>>>
>>>>> Thanks,
>>>>> Jiangli
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Tested with test/runtime/NMT.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jiangli
>>
>


From jiangli.zhou at oracle.com  Thu Jan  7 21:30:39 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 7 Jan 2016 13:30:39 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EC93C.1020906@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
Message-ID: <3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>

Thanks Coleen for filling in all the details!

> On Jan 7, 2016, at 12:23 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> 
> 
> On 1/7/16 11:51 AM, Coleen Phillimore wrote:
>> 
>> 
>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>> Hi Jiangli,
>>> 
>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>> 
>>> os.cpp:
>>> 
>>>      bool os::unmap_memory(char *addr, size_t bytes) {
>>>        bool result;
>>>        if (MemTracker::tracking_level() > NMT_minimal) {
>>>   + #ifndef _WINDOWS
>>>   +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>   + #else
>>>   +     // Windows pd_unmap_memory also does memory release, so use
>>>   +     // the virtual_memory_release_tracker for windows
>>>          Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>   + #endif
>>> 
>>> os_windows.cpp:
>>> 
>>>   bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>      MEMORY_BASIC_INFORMATION mem_info;
>>>      if (VirtualQuery(addr, &mem_info, sizeof(mem_info)) == 0) {
>>>        if (PrintMiscellaneous && Verbose) {
>>>          DWORD err = GetLastError();
>>>          tty->print_cr("VirtualQuery() failed: GetLastError->%ld.", err);
>>>        }
>>>        return false;
>>>      }
>>> 
>>>      // Executable memory was not mapped using
>>>   CreateFileMapping/MapViewOfFileEx.
>>>      // Instead, executable region was allocated using VirtualAlloc(). See
>>>      // pd_map_memory() above.
>>>      //
>>>      // The following flags should match the 'exec_access' flages used for
>>>      // VirtualProtect() in pd_map_memory().
>>>      if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>          mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>        return pd_release_memory(addr, bytes);
>>>      }
>>> 
>>>      BOOL result = UnmapViewOfFile(addr);
>>>      if (result == 0) {
>>>        if (PrintMiscellaneous && Verbose) {
>>>          DWORD err = GetLastError();
>>>          tty->print_cr("UnmapViewOfFile() failed: GetLastError->%ld.",
>>>   err);
>>>        }
>>>        return false;
>>>      }
>>>      return true;
>>>   }
>>> 
>>>   bool os::pd_release_memory(char* addr, size_t bytes) {
>>>      return VirtualFree(addr, 0, MEM_RELEASE) != 0;
>>>   }
>>> 
>>> Note this code doesn't use MemTracker at all.
>> 
>> Right, because the MemTracker call is done at the higher level so pd_unmap_memory just does the unmapping.
>> 
>>> 
>>> So I have the fear that this fix doesn't really address the problem, and potentially it could cause other issues for the non-windows platforms, since you're unconditionally switching the code to use a different tracker.
>>> 
>>> I noticed the different usage of MemTracker in the os_<xxx>.cpp files:
>>> 
>>>   hotspot/src/os$ grep MemTracker:: */*/os_*.cpp | sed -e
>>>   's/[(][^(]*//g'  | sort | uniq
>>> 
>>>   ./bsd/vm/os_bsd.cpp:
>>>   MemTracker::record_virtual_memory_reserve_and_commit
>>>   ./bsd/vm/os_bsd.cpp:                  Tracker tkr =
>>>   MemTracker::get_virtual_memory_release_tracker
>>>   ./linux/vm/os_linux.cpp:
>>>   MemTracker::record_virtual_memory_reserve_and_commit
>>>   ./linux/vm/os_linux.cpp:              Tracker tkr =
>>>   MemTracker::get_virtual_memory_release_tracker
>>>   ./windows/vm/os_windows.cpp: MemTracker::record_virtual_memory_reserve
>>>   ./windows/vm/os_windows.cpp:
>>>   MemTracker::record_virtual_memory_reserve_and_commit
>>> 
>>> So ONLY windows calls MemTracker::record_virtual_memory_reserve (under allocate_pages_individually). Perhaps this is a better explanation why NMT behaves differently on Windows vs other platforms?
>> 
>> No, I think it's because on Linux, you call os::reserve_memory() allocation on the whole CDS archive and call os::map_memory() to map them to the archive file.   On windows, the os::reserve_memory() isn't done.
>> 
>> There are some workarounds (hacks) to MemTracker in the os specific files.  They are to handle large pages (the os::reserve_memory_special file is pushed to the platform specific files so needs to have NMT tracking there), and for windows, a special case because it has to reserve and unreserve memory.
>> 
>> ie.
>>  MemTracker::record_virtual_memory_reserve((address)p_buf, size_of_reserve, CALLER_PC);
>>  os::release_memory(p_buf, bytes + chunk_size);
>> 
>> os::release_memory() calls virtual_memory_release so we have to make sure NMT counts it as reserved first.  This should probably call pd_release_memory.
>> 
>> The function allocate_pages_individually looks like it's to handle NUMA/large pages also.  I think the else case in os::pd_reserve_memory() is odd, but I think this is unrelated to Jiangli's problem.
>>> 
>>> Without understand how NMT works under all conditions, I would hesitate to make the change you're proposing.
>>> 
>> 
>> I think the change is perfectly safe.  It doesn't change existing behavior for windows and fixes a known crash for a reason we understand for Linux.
> 
> OK, I trust you -- although I suspect nightly tests may find cases where we call os::unmap_memory() on a block that wasn't returned by os::map_memory, and NMT would complain that the block wasn't marked as committed. But that would be a bug of the caller of os::unmap_memory, but an NMT bug.
> 
> In any case, the comment needs to be fixed to explain why the #ifdef is needed. The current comment is wrong.

Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform. On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping. So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.

Thanks,
Jiangli

> 
> Thanks
> - Ioi
> 
>> Coleen
>> 
>>> Thanks
>>> - Ioi
>>> 
>>> On 1/7/16 10:50 AM, Jiangli Zhou wrote:
>>>> Hi Coleen,
>>>> 
>>>>> On Jan 6, 2016, at 6:04 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 1/6/16 7:54 PM, Jiangli Zhou wrote:
>>>>>> Hi David,
>>>>>> 
>>>>>>> On Jan 5, 2016, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Jiangli,
>>>>>>> 
>>>>>>> On 6/01/2016 8:30 AM, Jiangli Zhou wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Please review the small fix for JDK-8146523 <https://bugs.openjdk.java.net/browse/JDK-8146523>:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.00/
>>>>>>>> 
>>>>>>>> The os::map_memory() and os:unmapp_memory() functions use the memory tracker asymmetrically. The os::map_memory() function calls MemTracker::record_virtual_memory_reserve_and_commit() to track the mapped memory, while os::unmap_memory() uses the 'virtual_memory_release_tracker' to track the memory being unmapped. In NMT, there are different types of tracker for releasing and uncommitting memory. The ?virtual_memory_uncommit_tracker' is for 'uncommit? and ?virtual_memory_release_tracker? is for 'release'. The os::unmap_memory() should use the ?virtual_memory_uncommit_tracker' to be balanced with os::map_memory().
>>>>>>> I find this very confusing. Is there some document that describes the relationship between mapping, reserving and committing virtual memory and the related NMT functionality?
>>>>>> I agree. This is very confusing. I haven?t come across any document explaining the usage of the NMT APIs in different scenarios. My understand is based on reading the related code.
>>>>>> 
>>>>>>> It is not at all clear to me why reserve_and_commit pairs with uncommit (unless committed memory must first be reserved, and uncommit both uncommits and "unreserves" ??)
>>>>>> I dug deeper into it and found more issues. It appears MemTracker::record_virtual_memory_reserve_and_commit() should record the memory as both ?reserved? and ?committed?. However, that only happens if the memory region is not known by the VirtualMemoryTracker. If the memory overlaps with a known region in the VirtualMemoryTracker, MemTracker::record_virtual_memory_reserve_and_commit() could be a ?nop' in certain case. In the bug revealed by the specific test scenario, the memory region causing the issue is the CDS shared memory. Here are the call sequences related to the shared memory region:
>>>>>> 
>>>>>> 1. ReservedSpace::ReservedSpace - reserve the memory for shared region. VirtualMemorySummary::record_reserved_memory is called and the memory is recored as ?reserved?.
>>>>>> 2.os::map_memory - each shared space within the shared memory region is mapped. MemTracker::record_virtual_memory_reserve_and_commit is called, the memory is not recounted. So the shared memory region is only counted as ?reserved? in NMT by previous VirtualMemorySummary::record_reserved_memory call.
>>>>>> 3.os::unmap_memory - record each shared space within the shared memory region with virtual_memory_release_tracker
>>>>>> 4 ReservedSpace::release (calls os::release_memory) - the virtual_memory_release_tracker is used again for the shared memory region.
>>>>>> 
>>>>>> On linux and all other non-windows platform, os::unmap_memory only unmap the memory (by calling system munmap) without ?release? the memory. On windows, unmap_memory also does ?release?.
>>>>> Yes, this is the difference between windows and unix machines.  I think NMT was developed on windows.
>>>>>> So, there are at lease two issues:
>>>>>> 
>>>>>> The shared memory region is not recorded as ?committed?.
>>>>> File a P4 bug on this because I don't think it causes any crashes. I think it may under count the amount of committed memory.   We can investigate.
>>>> I filed JDK-8146637 <https://bugs.openjdk.java.net/browse/JDK-8146637>.
>>>> 
>>>>>> The shared memory region is counted twice as ?released?.
>>>>> Your change conditionalized for Windows in os.cpp would be the best thing.  Making the NMT call at a lower level ie. pd_unmap_memory runs into the problem that there are duplicates for the xnix platforms.  Also, there are multiple returns that would need NMT logic so it wouldn't look good. Also, there is risk because some of the os platforms call pd_unmap_memory by os::pd_attempt_reserve_memory_at() which would get the tracking wrong (I think).
>>>> Thanks for the suggestion. Here is the updated webrev:
>>>> 
>>>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.01/
>>>> 
>>>> Thanks!
>>>> 
>>>> Jiangli
>>>> 
>>>>> Coleen
>>>>> 
>>>>>> Thanks,
>>>>>> Jiangli
>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> -----
>>>>>>> 
>>>>>>>> Tested with test/runtime/NMT.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Jiangli


From ioi.lam at oracle.com  Thu Jan  7 23:12:58 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 07 Jan 2016 15:12:58 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
Message-ID: <568EF0FA.4070807@oracle.com>

On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>
>>>
>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>> Hi Jiangli,
>>>>
>>>> I looked at the implementatiion of os::pd_unmap_memory on windows 
>>>> but I can't figure out how it would affect the memory tracker:
>>>>
>>>> os.cpp:
>>>>
>>>>      bool os::unmap_memory(char *addr, size_t bytes) {
>>>>        bool result;
>>>>        if (MemTracker::tracking_level() > NMT_minimal) {
>>>>   + #ifndef _WINDOWS
>>>>   +     Tracker tkr = 
>>>> MemTracker::get_virtual_memory_uncommit_tracker();
>>>>   + #else
>>>>   +     // Windows pd_unmap_memory also does memory release, so use
>>>>   +     // the virtual_memory_release_tracker for windows
>>>>          Tracker tkr = 
>>>> MemTracker::get_virtual_memory_release_tracker();
>>>>   + #endif
>>>>
> Could you please explain why the comment is wrong? On linux/unix 
> platforms, we have extra code to do explicit memory ?reserve? and 
> ?release?, which calls NMT to track the reserve and release of the 
> related memory region. Mapping and unmaping are performed on the 
> memory regions that are already ?reserved? on those platform.
> On windows, there are no explicit calls to do memory ?reserve? before 
> mapping and ?release? after unmapping.
This is not true. There's platform-independent code in virtualspace.cpp:

     ReservedSpace::initialize -> os::reserve_memory -> 
os::pd_reserve_memory.

There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is 
actually implemented in os_windows.cpp

What you said may be true for CDS:

    bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
    #ifndef _WINDOWS
       // Map in the shared memory and then map the regions on top of it.
       // On Windows, don't map the memory here because it will cause the
       // mappings of the regions to fail.
       ReservedSpace shared_rs = mapinfo->reserve_shared_memory();

but that's not true in general. There are plenty of ReservedSpace used 
in platform-independent GC code.
> So the memory mapping/unmapping APIs have the implicit 
> ?reserve?/?release? behaviors. That?s why for windows the 
> release_tracker is used to reflect the behavior of unmapping with 
> implicit ?release?, and the linux/unix only needs the uncommit_tracker.
Also the comment implies that pd_unmap_memory always calls 
pd_release_memory, but this is not true:

    bool os::pd_unmap_memory(char* addr, size_t bytes) {
       ...
       if (mem_info.Protect == PAGE_EXECUTE_READ ||
           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
         return pd_release_memory(addr, bytes);
       }
       ...
    }

Even on Windows, won't we eventually call os::release_memory(), which 
would properly record the removal using 
get_virtual_memory_release_tracker? Yes, CDS is an exception, but that 
should be dealt with in the CDS code, not in the generic os.cpp code. 
And, I am not particularly worried about the CDS case, since it happens 
only when mapping of some of the CDS regions has failed.

Are you sure we need the special case for Windows here? Have you tested 
NMT on Windows without the #ifdef?

The NMT code is quite messy. I don't want to make it worse by adding 
more #ifdefs with comments that are only partially true.

Thanks
- Ioi


From ioi.lam at oracle.com  Thu Jan  7 23:30:23 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 07 Jan 2016 15:30:23 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EF0FA.4070807@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>	<568CB531.5080608@oracle.com>	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>	<568DC7B4.1020403@oracle.com>	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>	<568EBDBE.3010003@oracle.com>
	<568EC1CD.1060109@oracle.com>	<568EC93C.1020906@oracle.com>	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com>
Message-ID: <568EF50F.9060005@oracle.com>

Oops, please ignore most of what I said here. I just realized that 
os::map_memory/unmap_memory is called only by CDS.

- Ioi


On 1/7/16 3:12 PM, Ioi Lam wrote:
> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>
>>>>
>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows 
>>>>> but I can't figure out how it would affect the memory tracker:
>>>>>
>>>>> os.cpp:
>>>>>
>>>>>      bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>        bool result;
>>>>>        if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>   + #ifndef _WINDOWS
>>>>>   +     Tracker tkr = 
>>>>> MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>   + #else
>>>>>   +     // Windows pd_unmap_memory also does memory release, so use
>>>>>   +     // the virtual_memory_release_tracker for windows
>>>>>          Tracker tkr = 
>>>>> MemTracker::get_virtual_memory_release_tracker();
>>>>>   + #endif
>>>>>
>> Could you please explain why the comment is wrong? On linux/unix 
>> platforms, we have extra code to do explicit memory ?reserve? and 
>> ?release?, which calls NMT to track the reserve and release of the 
>> related memory region. Mapping and unmaping are performed on the 
>> memory regions that are already ?reserved? on those platform.
>> On windows, there are no explicit calls to do memory ?reserve? before 
>> mapping and ?release? after unmapping.
> This is not true. There's platform-independent code in virtualspace.cpp:
>
>     ReservedSpace::initialize -> os::reserve_memory -> 
> os::pd_reserve_memory.
>
> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is 
> actually implemented in os_windows.cpp
>
> What you said may be true for CDS:
>
>    bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>    #ifndef _WINDOWS
>       // Map in the shared memory and then map the regions on top of it.
>       // On Windows, don't map the memory here because it will cause the
>       // mappings of the regions to fail.
>       ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>
> but that's not true in general. There are plenty of ReservedSpace used 
> in platform-independent GC code.
>> So the memory mapping/unmapping APIs have the implicit 
>> ?reserve?/?release? behaviors. That?s why for windows the 
>> release_tracker is used to reflect the behavior of unmapping with 
>> implicit ?release?, and the linux/unix only needs the uncommit_tracker.
> Also the comment implies that pd_unmap_memory always calls 
> pd_release_memory, but this is not true:
>
>    bool os::pd_unmap_memory(char* addr, size_t bytes) {
>       ...
>       if (mem_info.Protect == PAGE_EXECUTE_READ ||
>           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>         return pd_release_memory(addr, bytes);
>       }
>       ...
>    }
>
> Even on Windows, won't we eventually call os::release_memory(), which 
> would properly record the removal using 
> get_virtual_memory_release_tracker? Yes, CDS is an exception, but that 
> should be dealt with in the CDS code, not in the generic os.cpp code. 
> And, I am not particularly worried about the CDS case, since it 
> happens only when mapping of some of the CDS regions has failed.
>
> Are you sure we need the special case for Windows here? Have you 
> tested NMT on Windows without the #ifdef?
>
> The NMT code is quite messy. I don't want to make it worse by adding 
> more #ifdefs with comments that are only partially true.
>
> Thanks
> - Ioi
>


From ioi.lam at oracle.com  Thu Jan  7 23:39:57 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 07 Jan 2016 15:39:57 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EF50F.9060005@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>	<568CB531.5080608@oracle.com>	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>	<568DC7B4.1020403@oracle.com>	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>	<568EBDBE.3010003@oracle.com>	<568EC1CD.1060109@oracle.com>	<568EC93C.1020906@oracle.com>	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>	<568EF0FA.4070807@oracle.com>
	<568EF50F.9060005@oracle.com>
Message-ID: <568EF74D.9050308@oracle.com>

For clarity, I think we should change the comment to this:

   + #ifndef _WINDOWS
   +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
   + #else
   +     // os::unmap_memory is only used for CDS. On Windows:
   +     //   + pd_unmap_memory also releases the memory;
   +     //   + there's no corresponding os::release_memory call for addr
   +     //     (see MetaspaceShared::map_shared_spaces);
   +     // so we must use get_virtual_memory_release_tracker here.
          Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
   + #endif

Thanks
- Ioi


On 1/7/16 3:30 PM, Ioi Lam wrote:
> Oops, please ignore most of what I said here. I just realized that 
> os::map_memory/unmap_memory is called only by CDS.
>
> - Ioi
>
>
> On 1/7/16 3:12 PM, Ioi Lam wrote:
>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>
>>>>>
>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>> Hi Jiangli,
>>>>>>
>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows 
>>>>>> but I can't figure out how it would affect the memory tracker:
>>>>>>
>>>>>> os.cpp:
>>>>>>
>>>>>>      bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>        bool result;
>>>>>>        if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>   + #ifndef _WINDOWS
>>>>>>   +     Tracker tkr = 
>>>>>> MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>   + #else
>>>>>>   +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>   +     // the virtual_memory_release_tracker for windows
>>>>>>          Tracker tkr = 
>>>>>> MemTracker::get_virtual_memory_release_tracker();
>>>>>>   + #endif
>>>>>>
>>> Could you please explain why the comment is wrong? On linux/unix 
>>> platforms, we have extra code to do explicit memory ?reserve? and 
>>> ?release?, which calls NMT to track the reserve and release of the 
>>> related memory region. Mapping and unmaping are performed on the 
>>> memory regions that are already ?reserved? on those platform.
>>> On windows, there are no explicit calls to do memory ?reserve? 
>>> before mapping and ?release? after unmapping.
>> This is not true. There's platform-independent code in virtualspace.cpp:
>>
>>     ReservedSpace::initialize -> os::reserve_memory -> 
>> os::pd_reserve_memory.
>>
>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is 
>> actually implemented in os_windows.cpp
>>
>> What you said may be true for CDS:
>>
>>    bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>    #ifndef _WINDOWS
>>       // Map in the shared memory and then map the regions on top of it.
>>       // On Windows, don't map the memory here because it will cause the
>>       // mappings of the regions to fail.
>>       ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>
>> but that's not true in general. There are plenty of ReservedSpace 
>> used in platform-independent GC code.
>>> So the memory mapping/unmapping APIs have the implicit 
>>> ?reserve?/?release? behaviors. That?s why for windows the 
>>> release_tracker is used to reflect the behavior of unmapping with 
>>> implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>> Also the comment implies that pd_unmap_memory always calls 
>> pd_release_memory, but this is not true:
>>
>>    bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>       ...
>>       if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>         return pd_release_memory(addr, bytes);
>>       }
>>       ...
>>    }
>>
>> Even on Windows, won't we eventually call os::release_memory(), which 
>> would properly record the removal using 
>> get_virtual_memory_release_tracker? Yes, CDS is an exception, but 
>> that should be dealt with in the CDS code, not in the generic os.cpp 
>> code. And, I am not particularly worried about the CDS case, since it 
>> happens only when mapping of some of the CDS regions has failed.
>>
>> Are you sure we need the special case for Windows here? Have you 
>> tested NMT on Windows without the #ifdef?
>>
>> The NMT code is quite messy. I don't want to make it worse by adding 
>> more #ifdefs with comments that are only partially true.
>>
>> Thanks
>> - Ioi
>>
>


From jiangli.zhou at oracle.com  Thu Jan  7 23:42:17 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 7 Jan 2016 15:42:17 -0800
Subject: RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()
In-Reply-To: <568EF50F.9060005@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
Message-ID: <274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>

Hi Ioi,

Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.

Just for the benefit of general public, here are some more details:

The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.

Thanks!
Jiangli

> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
> 
> - Ioi
> 
> 
> On 1/7/16 3:12 PM, Ioi Lam wrote:
>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>> 
>>>>> 
>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>> 
>>>>>> os.cpp:
>>>>>> 
>>>>>>     bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>       bool result;
>>>>>>       if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>  + #ifndef _WINDOWS
>>>>>>  +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>  + #else
>>>>>>  +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>  +     // the virtual_memory_release_tracker for windows
>>>>>>         Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>  + #endif
>>>>>> 
>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>> This is not true. There's platform-independent code in virtualspace.cpp:
>> 
>>    ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>> 
>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>> 
>> What you said may be true for CDS:
>> 
>>   bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>   #ifndef _WINDOWS
>>      // Map in the shared memory and then map the regions on top of it.
>>      // On Windows, don't map the memory here because it will cause the
>>      // mappings of the regions to fail.
>>      ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>> 
>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>> 
>>   bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>      ...
>>      if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>          mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>        return pd_release_memory(addr, bytes);
>>      }
>>      ...
>>   }
>> 
>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>> 
>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>> 
>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>> 
>> Thanks
>> - Ioi
>> 
> 


From david.holmes at oracle.com  Fri Jan  8 04:01:05 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Jan 2016 14:01:05 +1000
Subject: (XS) RFR: 8146222: assert(_initialized) failed: TLS not initialized
	yet!
Message-ID: <568F3481.80106@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8146222

webrev: http://cr.openjdk.java.net/~dholmes/8146222/webrev/

JDK-8144947 showed an error path, on Windows, where we can call 
Thread::current_or_null before TLS has been initialized and so hit the 
assertion failure - see bug report for details.

Simple fix is to move the ThreadLocalStorage::init() prior to any 
argument parsing code. As it contains simple OS library calls it can be 
initialized very early. Even the asserts in it still work (somewhat 
surprisingly) after the move.

Failure mode of 
com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java before the fix:

Agent[1].stdout: ## nof_mallocs = 674, nof_frees = 38
Agent[1].stdout: ## memory stomp:
Agent[1].stdout: GuardedMemory(0x0000000000fbf690) 
base_addr=0x0000000000fbf3f0 tag=0x00000000000da360 user_size=16512112 
user_data=0x0000000000fbf410
Agent[1].stdout: Header guard @0x0000000000fbf3f0 is BROKEN
Agent[1].stdout: # To suppress the following error report, specify this 
argument
Agent[1].stdout: # after -XX: or in .hotspotrc: 
SuppressErrorAt=\threadLocalStorage_windows.cpp:52
Agent[1].stdout: #
Agent[1].stdout: # A fatal error has been detected by the Java Runtime 
Environment:
Agent[1].stdout: #
Agent[1].stdout: # Internal Error 
(C:\jprt\T\P1\020042.daholme\s\hotspot\src\os\windows\vm\threadLocalStorage_windows.cpp:52), 
pid=5076, tid=4348
Agent[1].stdout: # assert(_initialized) failed: TLS not initialized yet!

Failure mode after:

Agent[1].stdout: ## nof_mallocs = 601, nof_frees = 36
Agent[1].stdout: ## memory stomp:
Agent[1].stdout: GuardedMemory(0x00f1fc44) base_addr=0x00f1fb40 
tag=0x003a9bc0 user_size=1942466404 user_data=0x00f1fb58
Agent[1].stdout: Header guard @0x00f1fb40 is BROKEN
Agent[1].stdout: #
Agent[1].stdout: # A fatal error has been detected by the Java Runtime 
Environment:
Agent[1].stdout: #
Agent[1].stdout: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 
pc=0x73bb8ab6, pid=10328, tid=7672

Testing:
   - JPRT
   - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
   - testing that the asserts in the relocated init() method fire correctly

Thanks,
David

From david.holmes at oracle.com  Fri Jan  8 05:06:55 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Jan 2016 15:06:55 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
Message-ID: <568F43EF.5090908@oracle.com>

On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
> the documentation you point to makes the point that whether to inline
> is an implementation detail, and that that should not be annotated to
> the declaration.  Basically, this is a good point.
>
> But the documentation does not cover the fact that
> we have the implementation in a different file than the declaration.
> The .inline.hpp is not included always (as you pointed out).
>
> Therefore, if we compile with precompiled headers, we get more
> inlines than if we do so without.
> Further, many functions were moved to oop.linline.hpp during the
> recent cleanups, and I think all the #includes I had to add were not
> left out deliberately, but just happened because the compiler did
> not complain.
> I think if somebody decides not to place a function implementation
> in a .cpp file, it should have the chance to be inlined at all it's calls.
> Putting the 'inline' into the .hpp file assures this.

Sorry I don't follow that. If you include the .inline.hpp you don't need 
"inline" in the .hpp. If you don't include it then the compiler doesn't 
have access to the definition so that it can be inlined. Maybe 
precompiled headers messes with that somehow but it seems to me that if 
you want it inlined then you must include the .inline.hpp anywhere it is 
needed. Anything else seems a bad-aid.

Cheers,
David

> Best regards,
>    Goetz.
>
>
>
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 6. Januar 2016 05:59
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
>> header files
>>
>> Hi Goetz,
>>
>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
>> header file.
>>> Unfortunately, the 'inline' qualifier is added to the function
>> implementations
>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
>>> compiler can not detect failing inlines properly.
>>>
>>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
>> Also
>>
>> This seems contrary to the C++ FAQ:
>>
>> https://isocpp.org/wiki/faq/inline-functions
>>
>> The declaration in the .hpp should not have inline, only the definition,
>> which in our case is in the .inline.hpp file.
>>
>> Any code that includes the .inline.hpp will have seen the definition of
>> the inline function prior to its use - as long as the includes are correct.
>>
>> David
>> -----
>>
>>
>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>
>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
>>>
>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>>>
>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
>>> bigger changes to this file in the rt repo, because jvmci is subject to
>>> freqent changes recently.
>>>
>>> The following methods were moved to .cpp files:
>>>
>>> ProtectionDomainCacheTable::compute_hash()
>>> ProtectionDomainCacheTable::index_for()
>>> typeArrayOopDesc::object_size()
>>> This is called only once outside .cpp file:
>>> CallSiteDepChange::CallSiteDepChange()
>>> This is only called in .cpp file
>>> ConstantPool::string_at_put()
>>>
>>> If someone considers not inlining these harmful to performance,
>>> I will add a new .inline.hpp file for them.
>>>
>>> Please review this change.  I please need a sponsor.
>>> There are no functional edits, so it should be simple to review.
>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
>>>
>>> Best regards,
>>>     Goetz.
>>>

From david.holmes at oracle.com  Fri Jan  8 05:09:18 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Jan 2016 15:09:18 +1000
Subject: RFR: 8141564: Convert TraceItables and PrintVtables to Unified
	Logging
In-Reply-To: <568EB615.5070409@oracle.com>
References: <565E2605.4060302@oracle.com> <565F47C8.9020307@oracle.com>
	<566096B9.6060807@oracle.com>
	<3E2722E6-DD93-4892-8A62-79DDE2BAFC03@oracle.com>
	<56621B07.2060005@oracle.com> <5665D1DD.5070208@oracle.com>
	<16BC4748-610A-4167-8009-7CEE8DC62FAF@oracle.com>
	<56672598.2050905@oracle.com> <5667A875.6090208@oracle.com>
	<568E9D18.7040501@oracle.com> <568EB048.6030102@oracle.com>
	<568EB615.5070409@oracle.com>
Message-ID: <568F447E.80503@oracle.com>

Yep all fine from my perspective.

Thanks,
David

On 8/01/2016 5:01 AM, Rachel Protacio wrote:
> Great, thanks! I'll commit.
> R
>
> On 1/7/2016 1:36 PM, Coleen Phillimore wrote:
>>
>> This still looks good!  I think I interpreted David's comment to not
>> require another round, so I think he's a reviewer.
>>
>> Coleen
>>
>> On 1/7/16 12:15 PM, Rachel Protacio wrote:
>>> Hi, David,
>>>
>>> Thanks for that. I've corrected the issue in interpreterRuntime.cpp
>>> as well as in klassVtable.cpp. Did you look at all the code - shall I
>>> count you as a reviewer?
>>>
>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141564.04/
>>>
>>> Rachel
>>>
>>> On 12/8/2015 11:05 PM, David Holmes wrote:
>>>> Hi Rachel,
>>>>
>>>> src/share/vm/interpreter/interpreterRuntime.cpp
>>>>
>>>> The ResourceMark is now used outside of the actual logging code. If
>>>> a ResourceMark is needed then I think we need to use the "if
>>>> (log_is_enabled(...)" form.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>
>>>> On 9/12/2015 4:46 AM, Rachel Protacio wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/8/2015 12:28 PM, Karen Kinnear wrote:
>>>>>> Rachel,
>>>>>>
>>>>>> Thank you for the updates.
>>>>>> Can you please sanity check one thing for me - the log_tables boolean
>>>>>> ?overrides? appears to
>>>>>> be set correctly in the callers, to mean ?yes, this overrides?.
>>>>>> In log_vtables, is it possible the choice of what to print is
>>>>>> reversed?
>>>>>>
>>>>>> And perhaps add a check to your tests for example that ?NOT
>>>>>> overriding? catches the right case?
>>>>> Oh, good catch. Thank you - this is fixed now.
>>>>>>
>>>>>> And yes please on the assertion (I have seen null method bugs in
>>>>>> development and this code is an early
>>>>>> opportunity to catch that problem).
>>>>>>
>>>>>> I don?t need to see an updated web rev and you don?t need to rerun
>>>>>> all
>>>>>> the tests to fix
>>>>>> the printed string.
>>>>> Great. Thanks again, Karen and Coleen! Will commit the change.
>>>>> Rachel
>>>>>> thanks,
>>>>>> Karen
>>>>>>
>>>>>>> On Dec 7, 2015, at 1:37 PM, Coleen Phillimore
>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/4/15 6:00 PM, Rachel Protacio wrote:
>>>>>>>> Hi, Karen,
>>>>>>>>
>>>>>>>> Thanks for the review. Updated webrev:
>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/
>>>>>>>>
>>>>>>>> Since I never listed the tests I ran even the first time, here are
>>>>>>>> all of them:
>>>>>>>>
>>>>>>>> * jtreg
>>>>>>>> * JPRT
>>>>>>>> * jck vm, lang, & api/java_lang
>>>>>>>> * rbt quick and non-colo (which now includes defmeth)
>>>>>>>> * invoke*
>>>>>>>>
>>>>>>>> Replies inline.
>>>>>>>>
>>>>>>>> On 12/3/2015 4:56 PM, Karen Kinnear wrote:
>>>>>>>>> Rachel,
>>>>>>>>>
>>>>>>>>> Thank you so much for doing (and redoing) this.
>>>>>>>>>
>>>>>>>>> Couple of questions/comments.
>>>>>>>>>
>>>>>>>>> 1. thank you so much for the transitive overriding test - not easy
>>>>>>>>> to figure out how to generate one!
>>>>>>>>>
>>>>>>>> Lois walked me through doing that one :)
>>>>>>>>> 2. I missed the list of what you have tested for the first web rev
>>>>>>>>> and the other tests for this one
>>>>>>>>> I will assume in parallel with the code review you are running
>>>>>>>>> (without tracing)
>>>>>>>>> vm quick & nocolo, jck vm & lang
>>>>>>>>> defmeth, invoke*
>>>>>>>> Yeah, I totally forgot to email what tests I had run. Sorry about
>>>>>>>> that! And just learned how to run the jck tests.
>>>>>>>>> There might be value in running your new tests with old tracing
>>>>>>>>> vs.
>>>>>>>>> new and eyeballing the files - to see if they
>>>>>>>>> get essentially the same information.
>>>>>>>>>
>>>>>>>> Yup!
>>>>>>>>> 3. klassVtable.cpp lines 154-156 ?
>>>>>>>>> Would it make any sense to do if !klass()->is_array_klass() and
>>>>>>>>> then just use the log_develop_debug and
>>>>>>>>> not do the extra develop_log_is_enabled check? No big deal.
>>>>>>>>>
>>>>>>>> That makes sense. Changed as suggested.
>>>>>>>>> 4. thank you so much for extracting the print_linkage_flags - I
>>>>>>>>> should have done that earlier - the information
>>>>>>>>> just grew incrementally.
>>>>>>>>>
>>>>>>>>> 5. klassVtable.cpp line 1047 -
>>>>>>>>>    I think you want an if (m != NULL) here  before
>>>>>>>>> dereferencing to
>>>>>>>>> print_linkage_flags.
>>>>>>>>>    I see we miss that check for other dereferences -feel free to
>>>>>>>>> add small checks.
>>>>>>>>>    Don?t completely skip logic paragraphs except for printing
>>>>>>>>> ones.
>>>>>>>> Well, when I was making my change, we saw that it wouldn't be
>>>>>>>> possible for m to be null at that point in the code. There are
>>>>>>>> multiple places above it where it is dereferenced already, not to
>>>>>>>> mention the fact that it is theoretically initialized to be a valid
>>>>>>>> method. Would you like to me to add an assert after the declaration
>>>>>>>>     assert(m != NULL, "methods can never be null");
>>>>>>>> just to be safe?
>>>>>>> In the code here:
>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.02/src/share/vm/oops/klassVtable.cpp.udiff.html>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, Method* m = method->at(i); can never return NULL or else the
>>>>>>> whole VM would crash everywhere.  I suspect the logging code here
>>>>>>> was
>>>>>>> copied from other instances where 'm' could be null. This line
>>>>>>> would crash first:
>>>>>>>
>>>>>>> if (interface_method_needs_itable_index(m)) {
>>>>>>>
>>>>>>>
>>>>>>> Can you clean up this line also to not check for NULL:
>>>>>>>
>>>>>>> const char* sig = (m != NULL) ? m->name_and_sig_as_C_string() :
>>>>>>> "<NULL>";
>>>>>>>
>>>>>>>
>>>>>>> And add the assert if Karen agrees if it's needed.
>>>>>>>
>>>>>>> The rest of the changes look good.   I don't need to see another
>>>>>>> revision.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>>>     Thank you for leaving the null check in fill_in_miranda and
>>>>>>>>> print_method_at.
>>>>>>>>>
>>>>>>>>> 6. log_vtables
>>>>>>>>> The logic in update_inherited_vtables is quite complex.
>>>>>>>>> So the value of allocate_new is not really the right
>>>>>>>>> conditional to
>>>>>>>>> pass in to determine if there
>>>>>>>>> was an override.
>>>>>>>>>    The first paragraph applies both for allocate_new=true and
>>>>>>>>> allocate_new=false (see !target_method()->is_package_private())
>>>>>>>>>    so they would have allocate_new = true AND be overriding.
>>>>>>>>>
>>>>>>>>> So, perhaps you could add a boolean that says ?overrides? or
>>>>>>>>> ?overriding? or whatever : default it to false, and set it to true
>>>>>>>>> right after the put_method_at line (that iswhere the override
>>>>>>>>> occurs) and set it to false in the ?else? clause?
>>>>>>>>> And pass that argument in to log_vtables ? And remove the
>>>>>>>>> allocate_new comment from log_vtables as well?
>>>>>>>>>
>>>>>>>> Done, too.
>>>>>>>>
>>>>>>>> Thanks!!
>>>>>>>> Rachel
>>>>>>>>> And the comment in the ?else? is not accurate since I put the
>>>>>>>>> package_private fix in - so removing
>>>>>>>>> it was a good idea.
>>>>>>>>>
>>>>>>>>> many thanks,
>>>>>>>>> Karen
>>>>>>>>>
>>>>>>>>>> On Dec 3, 2015, at 2:23 PM, Rachel Protacio
>>>>>>>>>> <rachel.protacio at oracle.com <mailto:rachel.protacio at oracle.com>
>>>>>>>>>> <mailto:rachel.protacio at oracle.com
>>>>>>>>>> <mailto:rachel.protacio at oracle.com>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> Thanks for the comments! Updated
>>>>>>>>>> webrev:http://cr.openjdk.java.net/~rprotacio/8141564.01/
>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564.01/><http://cr.openjdk.java.net/%7Erprotacio/8141564.01/
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564.01/>>(Builds and
>>>>>>>>>> passes logging jtreg tests.)
>>>>>>>>>>
>>>>>>>>>> Replies inline.
>>>>>>>>>>
>>>>>>>>>> On 12/2/2015 2:34 PM, Coleen Phillimore wrote:
>>>>>>>>>>> Rachel, There are a lot of changes here.  I have several
>>>>>>>>>>> comments
>>>>>>>>>>> and more suggested cleanup that should be done with this work.
>>>>>>>>>>>
>>>>>>>>>>> Inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <inhttp://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/interpreter/linkResolver.cpp.udiff.html>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I did the original refactoring for trace_method_resolution. What
>>>>>>>>>>> I think would be better is to make it an internal static
>>>>>>>>>>> function
>>>>>>>>>>> in linkResolver.cpp and not defined in the linkResolver.hpp.
>>>>>>>>>>> Make the call unconditional and pass vtable index in the last
>>>>>>>>>>> parameter as a default parameter with default value -1 so the
>>>>>>>>>>> last line in the function is the tty->cr() that I had outside
>>>>>>>>>>> the
>>>>>>>>>>> function call (that was pretty icky). And put all the
>>>>>>>>>>> ResourceMark and logstream logic inside the
>>>>>>>>>>> trace_method_resolution function.  It would never print to
>>>>>>>>>>> tty so
>>>>>>>>>>> doesn't need an outputStream parameter for other callers.
>>>>>>>>>>>
>>>>>>>>>>> So there would be only the one line
>>>>>>>>>>> trace_method_resolution(params) in the regular code.
>>>>>>>>>> Thanks for the advice! I still have to call the function from
>>>>>>>>>> within the conditional because it's develop level only and
>>>>>>>>>> because
>>>>>>>>>> I need to specify in the call whether it's for itables or
>>>>>>>>>> vtables.
>>>>>>>>>> Otherwise, I've followed your suggestions.
>>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/logging/logTag.hpp.udiff.html>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Can you put these tags near each other?
>>>>>>>>>>>
>>>>>>>>>> I have them sorted alphabetically, which I think is more
>>>>>>>>>> useful in
>>>>>>>>>> the long run.
>>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/src/share/vm/oops/klassVtable.cpp.udiff.html>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> One of the things that Markus Gronlund's made me think that we
>>>>>>>>>>> should do with his cleanup is to stop declaring functions as
>>>>>>>>>>> members of classes if they don't need external linkage. From his
>>>>>>>>>>> RFR(L): 8140485: Class load and creation clean up:
>>>>>>>>>>>
>>>>>>>>>>> "Comment: In my opinion, we should attempt to break the pattern
>>>>>>>>>>> of having private functions declared in header files when the
>>>>>>>>>>> private function does not need to reach inside "this"."
>>>>>>>>>>>
>>>>>>>>>>> I think the function log_vtables should follow this and be
>>>>>>>>>>> declared as a static internal function in klassVtable.cpp above
>>>>>>>>>>> the function where it's used.
>>>>>>>>>>>
>>>>>>>>>>> It's true that you don't see this very much in the hotspot
>>>>>>>>>>> sources.
>>>>>>>>>>>
>>>>>>>>>>> The refactoring of log_vtables is good and very much
>>>>>>>>>>> appreciated.
>>>>>>>>>>>
>>>>>>>>>>> In each of the logging blocks of code, there are about 6 lines
>>>>>>>>>>> that are about the same, that print the access flags and whether
>>>>>>>>>>> it's a default or overpass method.  (Karen and Lois should give
>>>>>>>>>>> you a TOI about what that means!)  Can you add a method to
>>>>>>>>>>> method.hpp that's something like print_flags(outputStream* st)
>>>>>>>>>>> and move this printing there, and make those blocks call your
>>>>>>>>>>> new
>>>>>>>>>>> function?  That would shorten many of these logging blocks of
>>>>>>>>>>> code and would be nice.  You could call this from the
>>>>>>>>>>> linkResolver.cpp trace_method_resolution() function too.
>>>>>>>>>> Done.
>>>>>>>>>>> http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/test/runtime/logging/p1/A.java.html><http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html
>>>>>>>>>>>
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/test/runtime/logging/p1/A.java.html>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> These classes have missing copyrights.
>>>>>>>>>> Fixed.
>>>>>>>>>> Thanks!
>>>>>>>>>> Rachel
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Coleen
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12/1/15 5:58 PM, Rachel Protacio wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review this changeset that converts -XX:+TraceItables
>>>>>>>>>>>> and
>>>>>>>>>>>> -XX:+PrintVtables flags to -Xlog:itables and -Xlog:vtables.
>>>>>>>>>>>>
>>>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141564/
>>>>>>>>>>>> <http://cr.openjdk.java.net/~rprotacio/8141564/>
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Erprotacio/8141564/>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141564
>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8141564>
>>>>>>>>>>>>
>>>>>>>>>>>> In case it's not clear, the changes in oops/klassVtable.cpp
>>>>>>>>>>>> around 462-498 are a refactoring of the duplicate code from a
>>>>>>>>>>>> conditional to a function with a boolean argument.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Rachel
>>>>>
>>>
>>
>

From max.ockner at oracle.com  Fri Jan  8 07:10:28 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 08 Jan 2016 02:10:28 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
Message-ID: <568F60E4.50609@oracle.com>

Hello,
Please review this unified logging conversion for several related flags 
in the class loading system.

Bugs:
https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
classloaderdata)
https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)

Webrev: http://cr.openjdk.java.net/~mockner/classload.01/

Summary:

There are two separate issues here. Originally Ioi and I began working 
on these fixes in parallel, but eventually it became obvious that the 
classload and classunload tags needed to be implemented together. This 
change is a combination of Ioi's change for 8079408 and my change for 
8142506.

(1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
This flag is added to the alias table. More verbose logging exists at 
level debug (one level of verbosity up from info)

(2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
This flag is added to the alias table. More verbose logging exists at 
level trace (converted from uses of WizardMode)

(3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"

The changes to TraceClassLoading and TraceClassUnloading also effected 
the implementation of "-verbose:class"

Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
-Xlog:classunload=trace -Xlog:classloaderdata=trace".

If you have questions about the updates to the classloading log, Ioi can 
give a better answer than I can.

Thanks,
Max





From goetz.lindenmaier at sap.com  Fri Jan  8 07:28:43 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 8 Jan 2016 07:28:43 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <568F43EF.5090908@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>



> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 8. Januar 2016 06:07
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > the documentation you point to makes the point that whether to inline
> > is an implementation detail, and that that should not be annotated to
> > the declaration.  Basically, this is a good point.
> >
> > But the documentation does not cover the fact that
> > we have the implementation in a different file than the declaration.
> > The .inline.hpp is not included always (as you pointed out).
> >
> > Therefore, if we compile with precompiled headers, we get more
> > inlines than if we do so without.
> > Further, many functions were moved to oop.linline.hpp during the
> > recent cleanups, and I think all the #includes I had to add were not
> > left out deliberately, but just happened because the compiler did
> > not complain.
> > I think if somebody decides not to place a function implementation
> > in a .cpp file, it should have the chance to be inlined at all it's calls.
> > Putting the 'inline' into the .hpp file assures this.
> 
> Sorry I don't follow that. If you include the .inline.hpp you don't need
> "inline" in the .hpp. If you don't include it then the compiler doesn't
> have access to the definition so that it can be inlined. 
Yes.

> it seems to me that if
> you want it inlined then you must include the .inline.hpp anywhere it is
> needed. Anything else seems a bad-aid.
But I think not the caller should decide whether it's to be inlined, 
but the implementor of the method (and next the compiler).  
As you describe, the caller has to decide which header to include.
So the caller has to know implementation details of the callee, 
which is contrary to the encapsulation described in that documentation.

If you add the 'inline' keyword in the header, the compiler enforces 
that the includes are in a way that it can do what the implementor 
of the callee / of the method to be inlined intended.

> Maybe
> precompiled headers messes with that somehow
Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
is it dragged in by some other .inline.hpp header.
I would assume this is a remnant of the problems with this header.
But if it was listed there, it would make a difference.

To put it the other way round: do you think all the places I had to 
clean up are well founded decisions not to include the methods
from oop.inline.hpp?
Before my change, the caller of obj_at_put() from objArrayOop.hpp
had to include oop.inline.hpp to get it properly inlined.  Seems very
unintuitive to me.
http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
(I'll add the inline keyword in a follow-up change for gc files, in case
this change is accepted.)

Best regards,
  Goetz.

> 
> Cheers,
> David
> 
> > Best regards,
> >    Goetz.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Mittwoch, 6. Januar 2016 05:59
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
> fix
> >> header files
> >>
> >> Hi Goetz,
> >>
> >> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
> >> header file.
> >>> Unfortunately, the 'inline' qualifier is added to the function
> >> implementations
> >>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
> the
> >>> compiler can not detect failing inlines properly.
> >>>
> >>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
> >> Also
> >>
> >> This seems contrary to the C++ FAQ:
> >>
> >> https://isocpp.org/wiki/faq/inline-functions
> >>
> >> The declaration in the .hpp should not have inline, only the definition,
> >> which in our case is in the .inline.hpp file.
> >>
> >> Any code that includes the .inline.hpp will have seen the definition of
> >> the inline function prior to its use - as long as the includes are correct.
> >>
> >> David
> >> -----
> >>
> >>
> >>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
> >>>
> >>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
> >>>
> >>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> >>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
> >>>
> >>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> >>> bigger changes to this file in the rt repo, because jvmci is subject to
> >>> freqent changes recently.
> >>>
> >>> The following methods were moved to .cpp files:
> >>>
> >>> ProtectionDomainCacheTable::compute_hash()
> >>> ProtectionDomainCacheTable::index_for()
> >>> typeArrayOopDesc::object_size()
> >>> This is called only once outside .cpp file:
> >>> CallSiteDepChange::CallSiteDepChange()
> >>> This is only called in .cpp file
> >>> ConstantPool::string_at_put()
> >>>
> >>> If someone considers not inlining these harmful to performance,
> >>> I will add a new .inline.hpp file for them.
> >>>
> >>> Please review this change.  I please need a sponsor.
> >>> There are no functional edits, so it should be simple to review.
> >>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/
> >>>
> >>> Best regards,
> >>>     Goetz.
> >>>

From david.holmes at oracle.com  Fri Jan  8 07:53:53 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Jan 2016 17:53:53 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
Message-ID: <568F6B11.7020603@oracle.com>



On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 8. Januar 2016 06:07
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
>> header files
>>
>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> the documentation you point to makes the point that whether to inline
>>> is an implementation detail, and that that should not be annotated to
>>> the declaration.  Basically, this is a good point.
>>>
>>> But the documentation does not cover the fact that
>>> we have the implementation in a different file than the declaration.
>>> The .inline.hpp is not included always (as you pointed out).
>>>
>>> Therefore, if we compile with precompiled headers, we get more
>>> inlines than if we do so without.
>>> Further, many functions were moved to oop.linline.hpp during the
>>> recent cleanups, and I think all the #includes I had to add were not
>>> left out deliberately, but just happened because the compiler did
>>> not complain.
>>> I think if somebody decides not to place a function implementation
>>> in a .cpp file, it should have the chance to be inlined at all it's calls.
>>> Putting the 'inline' into the .hpp file assures this.
>>
>> Sorry I don't follow that. If you include the .inline.hpp you don't need
>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>> have access to the definition so that it can be inlined.
> Yes.
>
>> it seems to me that if
>> you want it inlined then you must include the .inline.hpp anywhere it is
>> needed. Anything else seems a bad-aid.
> But I think not the caller should decide whether it's to be inlined,
> but the implementor of the method (and next the compiler).
> As you describe, the caller has to decide which header to include.
> So the caller has to know implementation details of the callee,
> which is contrary to the encapsulation described in that documentation.

That's my understanding of the way things are expected to work. This is 
not a public library exporting its interface in a .hpp file, this an 
internal part of the bigger system. As I understand it we define the 
.inline.hpp file precisely so that clients can include it. And yes the 
clients have to know to do that.

> If you add the 'inline' keyword in the header, the compiler enforces
> that the includes are in a way that it can do what the implementor
> of the callee / of the method to be inlined intended.

I still don't see how adding inline to the declaration changes anything 
here. The compiler can't do the inlining unless the .inline.hpp file has 
been included. ???

Cheers,
David
-----


>> Maybe
>> precompiled headers messes with that somehow
> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
> is it dragged in by some other .inline.hpp header.
> I would assume this is a remnant of the problems with this header.
> But if it was listed there, it would make a difference.
>
> To put it the other way round: do you think all the places I had to
> clean up are well founded decisions not to include the methods
> from oop.inline.hpp?
> Before my change, the caller of obj_at_put() from objArrayOop.hpp
> had to include oop.inline.hpp to get it properly inlined.  Seems very
> unintuitive to me.
> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> (I'll add the inline keyword in a follow-up change for gc files, in case
> this change is accepted.)
>
> Best regards,
>    Goetz.
>
>>
>> Cheers,
>> David
>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>> fix
>>>> header files
>>>>
>>>> Hi Goetz,
>>>>
>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
>>>> header file.
>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>> implementations
>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
>> the
>>>>> compiler can not detect failing inlines properly.
>>>>>
>>>>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
>>>> Also
>>>>
>>>> This seems contrary to the C++ FAQ:
>>>>
>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>
>>>> The declaration in the .hpp should not have inline, only the definition,
>>>> which in our case is in the .inline.hpp file.
>>>>
>>>> Any code that includes the .inline.hpp will have seen the definition of
>>>> the inline function prior to its use - as long as the includes are correct.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>>>
>>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
>>>>>
>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
>>>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>>>>>
>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
>>>>> bigger changes to this file in the rt repo, because jvmci is subject to
>>>>> freqent changes recently.
>>>>>
>>>>> The following methods were moved to .cpp files:
>>>>>
>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>> ProtectionDomainCacheTable::index_for()
>>>>> typeArrayOopDesc::object_size()
>>>>> This is called only once outside .cpp file:
>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>> This is only called in .cpp file
>>>>> ConstantPool::string_at_put()
>>>>>
>>>>> If someone considers not inlining these harmful to performance,
>>>>> I will add a new .inline.hpp file for them.
>>>>>
>>>>> Please review this change.  I please need a sponsor.
>>>>> There are no functional edits, so it should be simple to review.
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>

From goetz.lindenmaier at sap.com  Fri Jan  8 09:31:44 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 8 Jan 2016 09:31:44 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <568F6B11.7020603@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>

Hi David,

> I still don't see how adding inline to the declaration changes anything
> here. The compiler can't do the inlining unless the .inline.hpp file has
> been included. ???
Yes, and therefore it issues an error if the keyword is in the .hpp header:

In file included from /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/utilities/hashtable.cpp:27:0:
/sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/classfile/javaClasses.hpp:113:30: error: inline function 'static typeArrayOopDesc* java_lang_String::value(oop)' used but never defined [-Werror]
   static inline typeArrayOop value(oop java_string);

So you can not miss including the inline.hpp header.

Best regards,
  Goetz.

> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 8. Januar 2016 08:54
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> 
> 
> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Freitag, 8. Januar 2016 06:07
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
> fix
> >> header files
> >>
> >> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> >>> Hi David,
> >>>
> >>> the documentation you point to makes the point that whether to inline
> >>> is an implementation detail, and that that should not be annotated to
> >>> the declaration.  Basically, this is a good point.
> >>>
> >>> But the documentation does not cover the fact that
> >>> we have the implementation in a different file than the declaration.
> >>> The .inline.hpp is not included always (as you pointed out).
> >>>
> >>> Therefore, if we compile with precompiled headers, we get more
> >>> inlines than if we do so without.
> >>> Further, many functions were moved to oop.linline.hpp during the
> >>> recent cleanups, and I think all the #includes I had to add were not
> >>> left out deliberately, but just happened because the compiler did
> >>> not complain.
> >>> I think if somebody decides not to place a function implementation
> >>> in a .cpp file, it should have the chance to be inlined at all it's calls.
> >>> Putting the 'inline' into the .hpp file assures this.
> >>
> >> Sorry I don't follow that. If you include the .inline.hpp you don't need
> >> "inline" in the .hpp. If you don't include it then the compiler doesn't
> >> have access to the definition so that it can be inlined.
> > Yes.
> >
> >> it seems to me that if
> >> you want it inlined then you must include the .inline.hpp anywhere it is
> >> needed. Anything else seems a bad-aid.
> > But I think not the caller should decide whether it's to be inlined,
> > but the implementor of the method (and next the compiler).
> > As you describe, the caller has to decide which header to include.
> > So the caller has to know implementation details of the callee,
> > which is contrary to the encapsulation described in that documentation.
> 
> That's my understanding of the way things are expected to work. This is
> not a public library exporting its interface in a .hpp file, this an
> internal part of the bigger system. As I understand it we define the
> .inline.hpp file precisely so that clients can include it. And yes the
> clients have to know to do that.
> 
> > If you add the 'inline' keyword in the header, the compiler enforces
> > that the includes are in a way that it can do what the implementor
> > of the callee / of the method to be inlined intended.
> 
> I still don't see how adding inline to the declaration changes anything
> here. The compiler can't do the inlining unless the .inline.hpp file has
> been included. ???
Yes, but it issues a warning and  will abort if it's wrong.


> 
> Cheers,
> David
> -----
> 
> 
> >> Maybe
> >> precompiled headers messes with that somehow
> > Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
> > is it dragged in by some other .inline.hpp header.
> > I would assume this is a remnant of the problems with this header.
> > But if it was listed there, it would make a difference.
> >
> > To put it the other way round: do you think all the places I had to
> > clean up are well founded decisions not to include the methods
> > from oop.inline.hpp?
> > Before my change, the caller of obj_at_put() from objArrayOop.hpp
> > had to include oop.inline.hpp to get it properly inlined.  Seems very
> > unintuitive to me.
> > http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> > (I'll add the inline keyword in a follow-up change for gc files, in case
> > this change is accepted.)
> >
> > Best regards,
> >    Goetz.
> >
> >>
> >> Cheers,
> >> David
> >>
> >>> Best regards,
> >>>     Goetz.
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>> Sent: Mittwoch, 6. Januar 2016 05:59
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> and
> >> fix
> >>>> header files
> >>>>
> >>>> Hi Goetz,
> >>>>
> >>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
> .hpp
> >>>> header file.
> >>>>> Unfortunately, the 'inline' qualifier is added to the function
> >>>> implementations
> >>>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
> >> the
> >>>>> compiler can not detect failing inlines properly.
> >>>>>
> >>>>> This change moves the inline directive from oop.inline.hpp to
> oop.hpp.
> >>>> Also
> >>>>
> >>>> This seems contrary to the C++ FAQ:
> >>>>
> >>>> https://isocpp.org/wiki/faq/inline-functions
> >>>>
> >>>> The declaration in the .hpp should not have inline, only the definition,
> >>>> which in our case is in the .inline.hpp file.
> >>>>
> >>>> Any code that includes the .inline.hpp will have seen the definition of
> >>>> the inline function prior to its use - as long as the includes are correct.
> >>>>
> >>>> David
> >>>> -----
> >>>>
> >>>>
> >>>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
> >>>>>
> >>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp
> files.
> >>>>>
> >>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> >>>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
> >>>>>
> >>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to
> do
> >>>>> bigger changes to this file in the rt repo, because jvmci is subject to
> >>>>> freqent changes recently.
> >>>>>
> >>>>> The following methods were moved to .cpp files:
> >>>>>
> >>>>> ProtectionDomainCacheTable::compute_hash()
> >>>>> ProtectionDomainCacheTable::index_for()
> >>>>> typeArrayOopDesc::object_size()
> >>>>> This is called only once outside .cpp file:
> >>>>> CallSiteDepChange::CallSiteDepChange()
> >>>>> This is only called in .cpp file
> >>>>> ConstantPool::string_at_put()
> >>>>>
> >>>>> If someone considers not inlining these harmful to performance,
> >>>>> I will add a new .inline.hpp file for them.
> >>>>>
> >>>>> Please review this change.  I please need a sponsor.
> >>>>> There are no functional edits, so it should be simple to review.
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/
> >>>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>

From kevin.walls at oracle.com  Fri Jan  8 12:25:45 2016
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 8 Jan 2016 12:25:45 +0000
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568DDEC8.5070209@kippdata.de>
References: <568CFC7B.1010801@oracle.com> <568D3E4A.7070308@oracle.com>
	<568DDEC8.5070209@kippdata.de>
Message-ID: <568FAAC9.90500@oracle.com>


Hello Rainer, thanks for getting in touch -

Cheleswer and I have been talking about how to do this - currently we 
plan to push the change below to 8u as it doesn't affect 9 and it solves 
the specific issue raised about log rotation.  However as you say, the 
read itself should be more efficient: we'd like to handle that in a 
separate CR, which we'll log, as it makes more sense from our point of 
view when what we want in 8 and 9 are different.

In 9, we don't have a problem at log rotation due to other changes. 
(Maybe when using -Xcheck:jni we can see the same pause, as 
run_periodic_checks() calls check_addr0().  I'm not sure offhand if slow 
-Xcheck:jni behaviour will block other work as the gc rotation pause did).

I created https://bugs.openjdk.java.net/browse/JDK-8146683 for 9, and 
we'll consider backporting.

Many thanks
Kevin


On 07/01/2016 03:43, Rainer Jung wrote:
> Hi all,
>
> I'm the original reporter of the problem.
>
> Am 06.01.2016 um 17:18 schrieb Yumin Qi:
>> Cheleswer,
>>
>>    If the call to check_addr0() is unnecessary, remove it is a better
>> choice I think. In fatal error, means VM will exit, the error handler
>> will print memory info, so it is redundant here. I don't know why it is
>> added to log rotation code in the first place.
>
> When I first investigated the problem, I noticed that the same 
> function check_addr0() is also used in os::run_periodic_checks(). The 
> whole code goes back to
>
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6478739
>
> I also wondered why it was called during GC log rotation but didn't 
> investigate further.
>
> Note that in addition to the problem of the long safepoint pause 
> during GC log file rotation, this bug has a second aspect, namely that 
> reading the maps file is done in a very inefficient and slow way. So 
> even after removing the call to check_addr0() during gc log file 
> rotation - which would fix this bug here - whatever code remains to 
> call check_addr0(), will still notice that the call takes a very long 
> time (e.g. more than 30 seconds if your process has lots of threads 
> and open jar files).
>
> This aspect was triggered by an older fix of the code which reads the 
> map file. Before the fix, the file was closed after reading the first 
> record from it. That was a bug but it terminated the read loop early 
> and the call returned quickly. After the old fix, the close was moved 
> behind the read loop and now the full read loop executed and took too 
> long. As an example for the old fix see
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/diff/e50eb3195734/src/os/solaris/vm/os_solaris.cpp 
>
>
> I think the correct (and fast) way of reading the maps file can be 
> seen by looking at the code of the Solaris "pmap" command. It reads 
> the file in one go using the pread() call instead of reading lots of 
> structs one by one. Therefore pmap executes very fast, much faster 
> than check_addr0() for the same maps file. I did check that on the 
> same map file, that showed the slowness bug in check_addr0().
>
> Since the pmap code isn't available in the open, I looked at the 
> Illumos code based on older OpenSolaris. There one can see:
>
> In 
> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/cmd/ptools/pmap/pmap.c
>
> - calls Pmapping_iter_resolved() to iterate over the maps
>
> In 
> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Psymtab.c
>
> - Pmapping_iter_resolved() calls i_Pmapping_iter()
> - i_Pmapping_iter() calls Prd_agent()
> - Prd_agent() calls Pupdate_maps()
> - Pupdate_maps() calls Preadmaps()
> - Preadmaps() calls P->ops.pop_read_maps()
>
> In 
> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Pcontrol.c
>
> - P->ops.pop_read_maps is Pread_maps_live()
> - Pread_maps_live() (starting at line 100) uses pread() to read the 
> whole file in one go into a buffer, that was sized using the st_size 
> field in the stat returned from fstat() called on the map file.
>
> So I suggest you also fix the slowness in check_addr0() by adjusting 
> the code that reads the map file in a similar way. If you think that's 
> to dangerous for a huge file, then you might consider at least reading 
> the file in big enough chunks (e.g. 100 structs at a time).
>
> Regards,
>
> Rainer
>
>> On 1/6/2016 3:37 AM, cheleswer sahu wrote:
>>> Hi,
>>>
>>> Please review the code changes for
>>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>>
>>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>>
>>> Bug brief:
>>> A long pause is observed after each gc log rotation in Solaris.
>>>
>>> Problem Identified:
>>> In each GC log rotation "print_memory_info()" is getting called
>>> through dump_loggc_header().
>>> "print_memory_info()" of solaris version calls check_addr0(st);
>>>
>>> File:
>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp 
>>>
>>>
>>>
>>> void os::print_memory_info(outputStream* st) {
>>>   st->print("Memory:");
>>>
>>>   st->print(" %dk page", os::vm_page_size()>>10);
>>>
>>>   st->print(", physical " UINT64_FORMAT "k", 
>>> os::physical_memory()>>10);
>>>
>>>   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>>
>>>   st->cr();
>>>  (void) check_addr0(st);
>>> }
>>>
>>> Now check_addr0(st) function do a lot of read call to read the data
>>> from /proc/self/map.
>>> and check if virtual address is mapped to 0x0. These read calls take
>>> lot of time which results in GC rotation pause.
>>> Here calling check_addr0() seems unnecessary for every log rotation.
>>> It will be more logical if this function gets called only
>>> when an error is reported.
>>>
>>> Solution proposed:
>>> Before GC log rotation print_memory_info() is ever getting called from
>>> Vm_error.cpp during error reporting. And in case of error reporting
>>> checking for address mapping to 0x0 looks fine. So the proposed
>>> solution is to do an extra check inside print_memory_info().
>>>
>>> -  (void) check_addr0(st);
>>> +  if (VMError::fatal_error_in_progress()){
>>> +     (void) check_addr0(st);
>>> +  }
>>>  }
>>>
>>>  This check doesn't fit well inside printing function, but at this
>>> point I don't see the need to create a new os:: method and change all
>>> the OS classes just for that check.
>>>
>>> Regards,
>>> Cheleswer


From rainer.jung at kippdata.de  Fri Jan  8 12:45:29 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Fri, 8 Jan 2016 13:45:29 +0100
Subject: [8u] RFR: 8144483: One long Safepoint pause directly after each
	GC log rotation
In-Reply-To: <568FAAC9.90500@oracle.com>
References: <568CFC7B.1010801@oracle.com> <568D3E4A.7070308@oracle.com>
	<568DDEC8.5070209@kippdata.de> <568FAAC9.90500@oracle.com>
Message-ID: <568FAF69.8040204@kippdata.de>

Hello Kevin,

Am 08.01.2016 um 13:25 schrieb Kevin Walls:
>
> Hello Rainer, thanks for getting in touch -
>
> Cheleswer and I have been talking about how to do this - currently we
> plan to push the change below to 8u as it doesn't affect 9 and it solves
> the specific issue raised about log rotation.  However as you say, the
> read itself should be more efficient: we'd like to handle that in a
> separate CR, which we'll log, as it makes more sense from our point of
> view when what we want in 8 and 9 are different.
>
> In 9, we don't have a problem at log rotation due to other changes.
> (Maybe when using -Xcheck:jni we can see the same pause, as
> run_periodic_checks() calls check_addr0().  I'm not sure offhand if slow
> -Xcheck:jni behaviour will block other work as the gc rotation pause did).
>
> I created https://bugs.openjdk.java.net/browse/JDK-8146683 for 9, and
> we'll consider backporting.

thanks a bunch for the feedback and for opening the separate CR. Sounds 
like a good plan!

Regards,

Rainer

> On 07/01/2016 03:43, Rainer Jung wrote:
>> Hi all,
>>
>> I'm the original reporter of the problem.
>>
>> Am 06.01.2016 um 17:18 schrieb Yumin Qi:
>>> Cheleswer,
>>>
>>>    If the call to check_addr0() is unnecessary, remove it is a better
>>> choice I think. In fatal error, means VM will exit, the error handler
>>> will print memory info, so it is redundant here. I don't know why it is
>>> added to log rotation code in the first place.
>>
>> When I first investigated the problem, I noticed that the same
>> function check_addr0() is also used in os::run_periodic_checks(). The
>> whole code goes back to
>>
>> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6478739
>>
>> I also wondered why it was called during GC log rotation but didn't
>> investigate further.
>>
>> Note that in addition to the problem of the long safepoint pause
>> during GC log file rotation, this bug has a second aspect, namely that
>> reading the maps file is done in a very inefficient and slow way. So
>> even after removing the call to check_addr0() during gc log file
>> rotation - which would fix this bug here - whatever code remains to
>> call check_addr0(), will still notice that the call takes a very long
>> time (e.g. more than 30 seconds if your process has lots of threads
>> and open jar files).
>>
>> This aspect was triggered by an older fix of the code which reads the
>> map file. Before the fix, the file was closed after reading the first
>> record from it. That was a bug but it terminated the read loop early
>> and the call returned quickly. After the old fix, the close was moved
>> behind the read loop and now the full read loop executed and took too
>> long. As an example for the old fix see
>>
>> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/diff/e50eb3195734/src/os/solaris/vm/os_solaris.cpp
>>
>>
>> I think the correct (and fast) way of reading the maps file can be
>> seen by looking at the code of the Solaris "pmap" command. It reads
>> the file in one go using the pread() call instead of reading lots of
>> structs one by one. Therefore pmap executes very fast, much faster
>> than check_addr0() for the same maps file. I did check that on the
>> same map file, that showed the slowness bug in check_addr0().
>>
>> Since the pmap code isn't available in the open, I looked at the
>> Illumos code based on older OpenSolaris. There one can see:
>>
>> In
>> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/cmd/ptools/pmap/pmap.c
>>
>>
>> - calls Pmapping_iter_resolved() to iterate over the maps
>>
>> In
>> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Psymtab.c
>>
>>
>> - Pmapping_iter_resolved() calls i_Pmapping_iter()
>> - i_Pmapping_iter() calls Prd_agent()
>> - Prd_agent() calls Pupdate_maps()
>> - Pupdate_maps() calls Preadmaps()
>> - Preadmaps() calls P->ops.pop_read_maps()
>>
>> In
>> https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/lib/libproc/common/Pcontrol.c
>>
>>
>> - P->ops.pop_read_maps is Pread_maps_live()
>> - Pread_maps_live() (starting at line 100) uses pread() to read the
>> whole file in one go into a buffer, that was sized using the st_size
>> field in the stat returned from fstat() called on the map file.
>>
>> So I suggest you also fix the slowness in check_addr0() by adjusting
>> the code that reads the map file in a similar way. If you think that's
>> to dangerous for a huge file, then you might consider at least reading
>> the file in big enough chunks (e.g. 100 structs at a time).
>>
>> Regards,
>>
>> Rainer
>>
>>> On 1/6/2016 3:37 AM, cheleswer sahu wrote:
>>>> Hi,
>>>>
>>>> Please review the code changes for
>>>> "https://bugs.openjdk.java.net/browse/JDK-8144483".
>>>>
>>>> webrev link: http://cr.openjdk.java.net/~kevinw/8144483/webrev.00/
>>>> JBS link: https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>
>>>> Bug brief:
>>>> A long pause is observed after each gc log rotation in Solaris.
>>>>
>>>> Problem Identified:
>>>> In each GC log rotation "print_memory_info()" is getting called
>>>> through dump_loggc_header().
>>>> "print_memory_info()" of solaris version calls check_addr0(st);
>>>>
>>>> File:
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/80959a760b85/src/os/solaris/vm/os_solaris.cpp
>>>>
>>>>
>>>>
>>>> void os::print_memory_info(outputStream* st) {
>>>>   st->print("Memory:");
>>>>
>>>>   st->print(" %dk page", os::vm_page_size()>>10);
>>>>
>>>>   st->print(", physical " UINT64_FORMAT "k",
>>>> os::physical_memory()>>10);
>>>>
>>>>   st->print("(" UINT64_FORMAT "k free)", os::available_memory() >> 10);
>>>>
>>>>   st->cr();
>>>>  (void) check_addr0(st);
>>>> }
>>>>
>>>> Now check_addr0(st) function do a lot of read call to read the data
>>>> from /proc/self/map.
>>>> and check if virtual address is mapped to 0x0. These read calls take
>>>> lot of time which results in GC rotation pause.
>>>> Here calling check_addr0() seems unnecessary for every log rotation.
>>>> It will be more logical if this function gets called only
>>>> when an error is reported.
>>>>
>>>> Solution proposed:
>>>> Before GC log rotation print_memory_info() is ever getting called from
>>>> Vm_error.cpp during error reporting. And in case of error reporting
>>>> checking for address mapping to 0x0 looks fine. So the proposed
>>>> solution is to do an extra check inside print_memory_info().
>>>>
>>>> -  (void) check_addr0(st);
>>>> +  if (VMError::fatal_error_in_progress()){
>>>> +     (void) check_addr0(st);
>>>> +  }
>>>>  }
>>>>
>>>>  This check doesn't fit well inside printing function, but at this
>>>> point I don't see the need to create a new os:: method and change all
>>>> the OS classes just for that check.
>>>>
>>>> Regards,
>>>> Cheleswer

From daniel.daugherty at oracle.com  Fri Jan  8 14:47:31 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 8 Jan 2016 07:47:31 -0700
Subject: (XS) RFR: 8146222: assert(_initialized) failed: TLS not
	initialized yet!
In-Reply-To: <568F3481.80106@oracle.com>
References: <568F3481.80106@oracle.com>
Message-ID: <568FCC03.5080207@oracle.com>

On 1/7/16 9:01 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146222
>
> webrev: http://cr.openjdk.java.net/~dholmes/8146222/webrev/

src/share/vm/runtime/thread.cpp
     No comments.

Thumbs up.

Dan


>
> JDK-8144947 showed an error path, on Windows, where we can call 
> Thread::current_or_null before TLS has been initialized and so hit the 
> assertion failure - see bug report for details.
>
> Simple fix is to move the ThreadLocalStorage::init() prior to any 
> argument parsing code. As it contains simple OS library calls it can 
> be initialized very early. Even the asserts in it still work (somewhat 
> surprisingly) after the move.
>
> Failure mode of 
> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java before the 
> fix:
>
> Agent[1].stdout: ## nof_mallocs = 674, nof_frees = 38
> Agent[1].stdout: ## memory stomp:
> Agent[1].stdout: GuardedMemory(0x0000000000fbf690) 
> base_addr=0x0000000000fbf3f0 tag=0x00000000000da360 user_size=16512112 
> user_data=0x0000000000fbf410
> Agent[1].stdout: Header guard @0x0000000000fbf3f0 is BROKEN
> Agent[1].stdout: # To suppress the following error report, specify 
> this argument
> Agent[1].stdout: # after -XX: or in .hotspotrc: 
> SuppressErrorAt=\threadLocalStorage_windows.cpp:52
> Agent[1].stdout: #
> Agent[1].stdout: # A fatal error has been detected by the Java Runtime 
> Environment:
> Agent[1].stdout: #
> Agent[1].stdout: # Internal Error 
> (C:\jprt\T\P1\020042.daholme\s\hotspot\src\os\windows\vm\threadLocalStorage_windows.cpp:52), 
> pid=5076, tid=4348
> Agent[1].stdout: # assert(_initialized) failed: TLS not initialized yet!
>
> Failure mode after:
>
> Agent[1].stdout: ## nof_mallocs = 601, nof_frees = 36
> Agent[1].stdout: ## memory stomp:
> Agent[1].stdout: GuardedMemory(0x00f1fc44) base_addr=0x00f1fb40 
> tag=0x003a9bc0 user_size=1942466404 user_data=0x00f1fb58
> Agent[1].stdout: Header guard @0x00f1fb40 is BROKEN
> Agent[1].stdout: #
> Agent[1].stdout: # A fatal error has been detected by the Java Runtime 
> Environment:
> Agent[1].stdout: #
> Agent[1].stdout: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 
> pc=0x73bb8ab6, pid=10328, tid=7672
>
> Testing:
>   - JPRT
>   - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
>   - testing that the asserts in the relocated init() method fire 
> correctly
>
> Thanks,
> David


From daniel.daugherty at oracle.com  Fri Jan  8 14:59:36 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 8 Jan 2016 07:59:36 -0700
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
Message-ID: <568FCED8.90808@oracle.com>

On 1/8/16 2:31 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> I still don't see how adding inline to the declaration changes anything
>> here. The compiler can't do the inlining unless the .inline.hpp file has
>> been included. ???
> Yes, and therefore it issues an error if the keyword is in the .hpp header:
>
> In file included from /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/utilities/hashtable.cpp:27:0:
> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/classfile/javaClasses.hpp:113:30: error: inline function 'static typeArrayOopDesc* java_lang_String::value(oop)' used but never defined [-Werror]
>     static inline typeArrayOop value(oop java_string);
>
> So you can not miss including the inline.hpp header.

OK so now I'm confused...

You declare a method in the oop.hpp file, but it is not defined
there nor is it defined in the oop.cpp file. It is defined as
"inline" in the oop.inline.hpp file...

If I try to use the method in code that does not include oop.inline.hpp,
then I would expect the compiler to flag that because it can't find
the method. I could swear that I've run into that "problem" before...
and the solution was to add the "oop.inline.hpp" file...

What am I missing?

Dan


>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 8. Januar 2016 08:54
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
>> header files
>>
>>
>>
>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Freitag, 8. Januar 2016 06:07
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>> fix
>>>> header files
>>>>
>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>> Hi David,
>>>>>
>>>>> the documentation you point to makes the point that whether to inline
>>>>> is an implementation detail, and that that should not be annotated to
>>>>> the declaration.  Basically, this is a good point.
>>>>>
>>>>> But the documentation does not cover the fact that
>>>>> we have the implementation in a different file than the declaration.
>>>>> The .inline.hpp is not included always (as you pointed out).
>>>>>
>>>>> Therefore, if we compile with precompiled headers, we get more
>>>>> inlines than if we do so without.
>>>>> Further, many functions were moved to oop.linline.hpp during the
>>>>> recent cleanups, and I think all the #includes I had to add were not
>>>>> left out deliberately, but just happened because the compiler did
>>>>> not complain.
>>>>> I think if somebody decides not to place a function implementation
>>>>> in a .cpp file, it should have the chance to be inlined at all it's calls.
>>>>> Putting the 'inline' into the .hpp file assures this.
>>>> Sorry I don't follow that. If you include the .inline.hpp you don't need
>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>>> have access to the definition so that it can be inlined.
>>> Yes.
>>>
>>>> it seems to me that if
>>>> you want it inlined then you must include the .inline.hpp anywhere it is
>>>> needed. Anything else seems a bad-aid.
>>> But I think not the caller should decide whether it's to be inlined,
>>> but the implementor of the method (and next the compiler).
>>> As you describe, the caller has to decide which header to include.
>>> So the caller has to know implementation details of the callee,
>>> which is contrary to the encapsulation described in that documentation.
>> That's my understanding of the way things are expected to work. This is
>> not a public library exporting its interface in a .hpp file, this an
>> internal part of the bigger system. As I understand it we define the
>> .inline.hpp file precisely so that clients can include it. And yes the
>> clients have to know to do that.
>>
>>> If you add the 'inline' keyword in the header, the compiler enforces
>>> that the includes are in a way that it can do what the implementor
>>> of the callee / of the method to be inlined intended.
>> I still don't see how adding inline to the declaration changes anything
>> here. The compiler can't do the inlining unless the .inline.hpp file has
>> been included. ???
> Yes, but it issues a warning and  will abort if it's wrong.
>
>
>> Cheers,
>> David
>> -----
>>
>>
>>>> Maybe
>>>> precompiled headers messes with that somehow
>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>>> is it dragged in by some other .inline.hpp header.
>>> I would assume this is a remnant of the problems with this header.
>>> But if it was listed there, it would make a difference.
>>>
>>> To put it the other way round: do you think all the places I had to
>>> clean up are well founded decisions not to include the methods
>>> from oop.inline.hpp?
>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>>> unintuitive to me.
>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>> (I'll add the inline keyword in a follow-up change for gc files, in case
>>> this change is accepted.)
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>> and
>>>> fix
>>>>>> header files
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
>> .hpp
>>>>>> header file.
>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>> implementations
>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
>>>> the
>>>>>>> compiler can not detect failing inlines properly.
>>>>>>>
>>>>>>> This change moves the inline directive from oop.inline.hpp to
>> oop.hpp.
>>>>>> Also
>>>>>>
>>>>>> This seems contrary to the C++ FAQ:
>>>>>>
>>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>>
>>>>>> The declaration in the .hpp should not have inline, only the definition,
>>>>>> which in our case is in the .inline.hpp file.
>>>>>>
>>>>>> Any code that includes the .inline.hpp will have seen the definition of
>>>>>> the inline function prior to its use - as long as the includes are correct.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>>>>>
>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp
>> files.
>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>>>>>>>
>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to
>> do
>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject to
>>>>>>> freqent changes recently.
>>>>>>>
>>>>>>> The following methods were moved to .cpp files:
>>>>>>>
>>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>>> typeArrayOopDesc::object_size()
>>>>>>> This is called only once outside .cpp file:
>>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>>> This is only called in .cpp file
>>>>>>> ConstantPool::string_at_put()
>>>>>>>
>>>>>>> If someone considers not inlining these harmful to performance,
>>>>>>> I will add a new .inline.hpp file for them.
>>>>>>>
>>>>>>> Please review this change.  I please need a sponsor.
>>>>>>> There are no functional edits, so it should be simple to review.
>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>> rt/webrev.01/
>>>>>>> Best regards,
>>>>>>>       Goetz.
>>>>>>>


From gerald.thornbrugh at oracle.com  Fri Jan  8 15:18:39 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Fri, 08 Jan 2016 08:18:39 -0700
Subject: RFR (S) round 0 for 8135198  Add -XX:VMOptionsFile support to
	JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
In-Reply-To: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
References: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
Message-ID: <568FD34F.3020903@oracle.com>

Hi Ron,

Your changes look good.

Jerry
> This change adds -XX:VMOptionsFile support to the JAVA_TOOL_OPTIONS
> and _JAVA_OPTIONS environment variables. With this change, the
> -XX:VMOptionsFile option is supported in the following option
> containers:
>
> - the command line
> - JAVA_TOOL_OPTIONS env var
> - _JAVA_OPTIONS env var
>
> Webrev:
>     http://cr.openjdk.java.net/~rdurbin/8135198_OCR0_JDK9_webrev
>
> Bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8135198
>
> This bug fix has been tested on:
>       OS:
>         Solaris, MAC, Windows, Linux
>       Tests:
>         Manual unit tests
>         JPRT with -testset hotspot(including the SQE current test coverage for this feature.)
>


From volker.simonis at gmail.com  Fri Jan  8 16:43:42 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 8 Jan 2016 17:43:42 +0100
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <568F6B11.7020603@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
Message-ID: <CA+3eh12sJEk7oAmZzZvos8q-9EZ+vD0PrRgKWVJY-cfNPMighA@mail.gmail.com>

On Fri, Jan 8, 2016 at 8:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>
>
> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Freitag, 8. Januar 2016 06:07
>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>>> fix
>>> header files
>>>
>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>
>>>> Hi David,
>>>>
>>>> the documentation you point to makes the point that whether to inline
>>>> is an implementation detail, and that that should not be annotated to
>>>> the declaration.  Basically, this is a good point.
>>>>
>>>> But the documentation does not cover the fact that
>>>> we have the implementation in a different file than the declaration.
>>>> The .inline.hpp is not included always (as you pointed out).
>>>>
>>>> Therefore, if we compile with precompiled headers, we get more
>>>> inlines than if we do so without.
>>>> Further, many functions were moved to oop.linline.hpp during the
>>>> recent cleanups, and I think all the #includes I had to add were not
>>>> left out deliberately, but just happened because the compiler did
>>>> not complain.
>>>> I think if somebody decides not to place a function implementation
>>>> in a .cpp file, it should have the chance to be inlined at all it's
>>>> calls.
>>>> Putting the 'inline' into the .hpp file assures this.
>>>
>>>
>>> Sorry I don't follow that. If you include the .inline.hpp you don't need
>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>> have access to the definition so that it can be inlined.
>>
>> Yes.
>>
>>> it seems to me that if
>>> you want it inlined then you must include the .inline.hpp anywhere it is
>>> needed. Anything else seems a bad-aid.
>>
>> But I think not the caller should decide whether it's to be inlined,
>> but the implementor of the method (and next the compiler).
>> As you describe, the caller has to decide which header to include.
>> So the caller has to know implementation details of the callee,
>> which is contrary to the encapsulation described in that documentation.
>
>
> That's my understanding of the way things are expected to work. This is not
> a public library exporting its interface in a .hpp file, this an internal
> part of the bigger system. As I understand it we define the .inline.hpp file
> precisely so that clients can include it. And yes the clients have to know
> to do that.
>
>> If you add the 'inline' keyword in the header, the compiler enforces
>> that the includes are in a way that it can do what the implementor
>> of the callee / of the method to be inlined intended.
>
>
> I still don't see how adding inline to the declaration changes anything
> here. The compiler can't do the inlining unless the .inline.hpp file has
> been included. ???
>

If you put a method definition into an .inline.hpp file your intention
as programmer is that this method should always be inlined by the
compiler.

But if you declare it without the "inline" keyword in the .hpp file,
users may by mistake include the .hpp file instead of the .inline.hpp
file and call your function without it being inlined by the compiler.

The .hpp file should only be included by users who don't call any of
the inline functions from the classes defined in that .hpp file. If
they want to call some inline functions, they have to include the
.inline.hpp file. Goetz's change ensures exactly this. It prevents
users from mistakenly including a .hpp file but calling inline
functions from the corresponding .inline.hpp file. (As a side note: we
had compilers which produced linking errors in such situations because
the compiler didn't create instances for the inline functions from the
.inline.hpp file).

Regards,
Volker


> Cheers,
> David
> -----
>
>
>
>>> Maybe
>>> precompiled headers messes with that somehow
>>
>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>> is it dragged in by some other .inline.hpp header.
>> I would assume this is a remnant of the problems with this header.
>> But if it was listed there, it would make a difference.
>>
>> To put it the other way round: do you think all the places I had to
>> clean up are well founded decisions not to include the methods
>> from oop.inline.hpp?
>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>> unintuitive to me.
>>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>> (I'll add the inline keyword in a follow-up change for gc files, in case
>> this change is accepted.)
>>
>> Best regards,
>>    Goetz.
>>
>>>
>>> Cheers,
>>> David
>>>
>>>> Best regards,
>>>>     Goetz.
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>>> dev at openjdk.java.net
>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>>> and
>>>
>>> fix
>>>>>
>>>>> header files
>>>>>
>>>>> Hi Goetz,
>>>>>
>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
>>>>>> .hpp
>>>>>
>>>>> header file.
>>>>>>
>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>
>>>>> implementations
>>>>>>
>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
>>>>>> Therefore,
>>>
>>> the
>>>>>>
>>>>>> compiler can not detect failing inlines properly.
>>>>>>
>>>>>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
>>>>>
>>>>> Also
>>>>>
>>>>> This seems contrary to the C++ FAQ:
>>>>>
>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>
>>>>> The declaration in the .hpp should not have inline, only the
>>>>> definition,
>>>>> which in our case is in the .inline.hpp file.
>>>>>
>>>>> Any code that includes the .inline.hpp will have seen the definition of
>>>>> the inline function prior to its use - as long as the includes are
>>>>> correct.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>>>>
>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp
>>>>>> files.
>>>>>>
>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
>>>>>> this is a
>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
>>>>>> acceptable.
>>>>>>
>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to
>>>>>> do
>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
>>>>>> to
>>>>>> freqent changes recently.
>>>>>>
>>>>>> The following methods were moved to .cpp files:
>>>>>>
>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>> typeArrayOopDesc::object_size()
>>>>>> This is called only once outside .cpp file:
>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>> This is only called in .cpp file
>>>>>> ConstantPool::string_at_put()
>>>>>>
>>>>>> If someone considers not inlining these harmful to performance,
>>>>>> I will add a new .inline.hpp file for them.
>>>>>>
>>>>>> Please review this change.  I please need a sponsor.
>>>>>> There are no functional edits, so it should be simple to review.
>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>
>>> rt/webrev.01/
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>      Goetz.
>>>>>>
>

From goetz.lindenmaier at sap.com  Fri Jan  8 17:13:40 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 8 Jan 2016 17:13:40 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <568FCED8.90808@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<568FCED8.90808@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F82A@DEWDFEMB12A.global.corp.sap>

Hi Daniel,

The problem is that the separation into .inline.hpp files is not 
(and was much less) consistent.
I think the issue you remember are calls from xxx.hpp files 
to methods with 'inline' keyword in another yyy.hpp file where 
the implementation is in the yyy.inline.hpp file.
The proper fix would be to move this method to xxx.inline.hpp
and include yyy.inline.hpp in xxx.inline.hpp.
The fixes often applied instead were 
 1.) include yyy.inline.hpp in xxx.hpp.  This leads to cycles, maybe in a 
       later change.
 2.) add yyy.inline.hpp to all .cpp files that somehow include xxx.hpp.
       This keeps breaking all the time.
This was further complicated as there was no build without precompiled
headers. Precompiled headers hide these problems if yyy.inline.hpp is in the precompiled 
header.  Now (thanks to David!) jprt has a build without precompiled headers.

Recent cleanups improved the situation wrt. this.

Also, I remember the problems Volker mentioned where the linker
step fails.

Best regards,
  Goetz.


> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Freitag, 8. Januar 2016 16:00
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> On 1/8/16 2:31 AM, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> >> I still don't see how adding inline to the declaration changes anything
> >> here. The compiler can't do the inlining unless the .inline.hpp file has
> >> been included. ???
> > Yes, and therefore it issues an error if the keyword is in the .hpp header:
> >
> > In file included from /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/utilities/hashtable.cpp:27:0:
> > /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/classfile/javaClasses.hpp:113:30: error: inline function 'static
> typeArrayOopDesc* java_lang_String::value(oop)' used but never defined [-
> Werror]
> >     static inline typeArrayOop value(oop java_string);
> >
> > So you can not miss including the inline.hpp header.
> 
> OK so now I'm confused...
> 
> You declare a method in the oop.hpp file, but it is not defined
> there nor is it defined in the oop.cpp file. It is defined as
> "inline" in the oop.inline.hpp file...
> 
> If I try to use the method in code that does not include oop.inline.hpp,
> then I would expect the compiler to flag that because it can't find
> the method. I could swear that I've run into that "problem" before...
> and the solution was to add the "oop.inline.hpp" file...
> 
> What am I missing?
> 
> Dan
> 
> 
> >
> > Best regards,
> >    Goetz.
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Freitag, 8. Januar 2016 08:54
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
> fix
> >> header files
> >>
> >>
> >>
> >> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>> Sent: Freitag, 8. Januar 2016 06:07
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> and
> >> fix
> >>>> header files
> >>>>
> >>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> the documentation you point to makes the point that whether to
> inline
> >>>>> is an implementation detail, and that that should not be annotated to
> >>>>> the declaration.  Basically, this is a good point.
> >>>>>
> >>>>> But the documentation does not cover the fact that
> >>>>> we have the implementation in a different file than the declaration.
> >>>>> The .inline.hpp is not included always (as you pointed out).
> >>>>>
> >>>>> Therefore, if we compile with precompiled headers, we get more
> >>>>> inlines than if we do so without.
> >>>>> Further, many functions were moved to oop.linline.hpp during the
> >>>>> recent cleanups, and I think all the #includes I had to add were not
> >>>>> left out deliberately, but just happened because the compiler did
> >>>>> not complain.
> >>>>> I think if somebody decides not to place a function implementation
> >>>>> in a .cpp file, it should have the chance to be inlined at all it's calls.
> >>>>> Putting the 'inline' into the .hpp file assures this.
> >>>> Sorry I don't follow that. If you include the .inline.hpp you don't need
> >>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
> >>>> have access to the definition so that it can be inlined.
> >>> Yes.
> >>>
> >>>> it seems to me that if
> >>>> you want it inlined then you must include the .inline.hpp anywhere it is
> >>>> needed. Anything else seems a bad-aid.
> >>> But I think not the caller should decide whether it's to be inlined,
> >>> but the implementor of the method (and next the compiler).
> >>> As you describe, the caller has to decide which header to include.
> >>> So the caller has to know implementation details of the callee,
> >>> which is contrary to the encapsulation described in that documentation.
> >> That's my understanding of the way things are expected to work. This is
> >> not a public library exporting its interface in a .hpp file, this an
> >> internal part of the bigger system. As I understand it we define the
> >> .inline.hpp file precisely so that clients can include it. And yes the
> >> clients have to know to do that.
> >>
> >>> If you add the 'inline' keyword in the header, the compiler enforces
> >>> that the includes are in a way that it can do what the implementor
> >>> of the callee / of the method to be inlined intended.
> >> I still don't see how adding inline to the declaration changes anything
> >> here. The compiler can't do the inlining unless the .inline.hpp file has
> >> been included. ???
> > Yes, but it issues a warning and  will abort if it's wrong.
> >
> >
> >> Cheers,
> >> David
> >> -----
> >>
> >>
> >>>> Maybe
> >>>> precompiled headers messes with that somehow
> >>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
> >>> is it dragged in by some other .inline.hpp header.
> >>> I would assume this is a remnant of the problems with this header.
> >>> But if it was listed there, it would make a difference.
> >>>
> >>> To put it the other way round: do you think all the places I had to
> >>> clean up are well founded decisions not to include the methods
> >>> from oop.inline.hpp?
> >>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
> >>> had to include oop.inline.hpp to get it properly inlined.  Seems very
> >>> unintuitive to me.
> >>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> >>> (I'll add the inline keyword in a follow-up change for gc files, in case
> >>> this change is accepted.)
> >>>
> >>> Best regards,
> >>>     Goetz.
> >>>
> >>>> Cheers,
> >>>> David
> >>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
> >>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> >> runtime-
> >>>>>> dev at openjdk.java.net
> >>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> >> and
> >>>> fix
> >>>>>> header files
> >>>>>>
> >>>>>> Hi Goetz,
> >>>>>>
> >>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in
> real
> >> .hpp
> >>>>>> header file.
> >>>>>>> Unfortunately, the 'inline' qualifier is added to the function
> >>>>>> implementations
> >>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
> Therefore,
> >>>> the
> >>>>>>> compiler can not detect failing inlines properly.
> >>>>>>>
> >>>>>>> This change moves the inline directive from oop.inline.hpp to
> >> oop.hpp.
> >>>>>> Also
> >>>>>>
> >>>>>> This seems contrary to the C++ FAQ:
> >>>>>>
> >>>>>> https://isocpp.org/wiki/faq/inline-functions
> >>>>>>
> >>>>>> The declaration in the .hpp should not have inline, only the
> definition,
> >>>>>> which in our case is in the .inline.hpp file.
> >>>>>>
> >>>>>> Any code that includes the .inline.hpp will have seen the definition
> of
> >>>>>> the inline function prior to its use - as long as the includes are
> correct.
> >>>>>>
> >>>>>> David
> >>>>>> -----
> >>>>>>
> >>>>>>
> >>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
> oop.hpp.
> >>>>>>>
> >>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp
> >> files.
> >>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this
> is a
> >>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
> acceptable.
> >>>>>>>
> >>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want
> to
> >> do
> >>>>>>> bigger changes to this file in the rt repo, because jvmci is subject to
> >>>>>>> freqent changes recently.
> >>>>>>>
> >>>>>>> The following methods were moved to .cpp files:
> >>>>>>>
> >>>>>>> ProtectionDomainCacheTable::compute_hash()
> >>>>>>> ProtectionDomainCacheTable::index_for()
> >>>>>>> typeArrayOopDesc::object_size()
> >>>>>>> This is called only once outside .cpp file:
> >>>>>>> CallSiteDepChange::CallSiteDepChange()
> >>>>>>> This is only called in .cpp file
> >>>>>>> ConstantPool::string_at_put()
> >>>>>>>
> >>>>>>> If someone considers not inlining these harmful to performance,
> >>>>>>> I will add a new .inline.hpp file for them.
> >>>>>>>
> >>>>>>> Please review this change.  I please need a sponsor.
> >>>>>>> There are no functional edits, so it should be simple to review.
> >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >>>> rt/webrev.01/
> >>>>>>> Best regards,
> >>>>>>>       Goetz.
> >>>>>>>


From ioi.lam at oracle.com  Fri Jan  8 19:40:08 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 08 Jan 2016 11:40:08 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <568F60E4.50609@oracle.com>
References: <568F60E4.50609@oracle.com>
Message-ID: <56901098.7010203@oracle.com>

Hi Max,

Just an overall comment first -- What we should do with -verbose:class?

Of all the logging options, I think -verbose:class is probably the most 
frequently used. I think many existing user scripts would  pass 
-verbose:class as a JVM argument would parse the output. So if we 
completely remove the old output of TraceClassLoading and replace them 
with -Xlog:classload, many existing user scripts would break.

We have 2 choices:

[1] Keep the old behavior of -verbose:class, and add -Xlog:classload as 
an independent/separate output. That was the approach I took with my 
original patch. This is more backwards compatible but also more messy to 
maintain.

[2] Replace TraceClassLoading completely with  -Xlog:classload. This is 
the approach of your new patch.

I am actually leaning towards #2. I think there will be a LOT of logging 
changes in JDK9 anyway (e.g., the GC logs). So the benefit of just 
keeping -verbose:class working the old way is a bit dubious.

Anyway, I just want to raise this point so we can have a discussion 
about it.

=======

I must have sent you an earlier version of the classload logging. I've 
made a few small changes. Please see 
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html

Please use the changes in these files
http://cr.openjdk.java.net/~iklam/8079408-improve-class-load-log.v2/src/share/vm/classfile/classLoaderData.cpp.sdiff.html
http://cr.openjdk.java.net/~iklam/8079408-improve-class-load-log.v2/src/share/vm/classfile/classLoaderData.hpp.sdiff.html


Feedback on other files:

*src/share/vm/classfile/classLoader.cpp*
"[Opened %s]"  -> "opened: %s"
"[Path %s]"  -> "path: %s"

In general, adding a ":" will make it easier to read (by a human)

Also, keep the old code for TraceClassPaths. This should be fixed later 
when we UL-ize this flag.
  580     if (TraceClassPaths) {
  581       tty->print_cr("[Opened %s]", path);
  582     }

*src/share/vm/code/nmethod.cpp:*
Remove "[]" and "Class unloading: Making nmethod" -> "making nmethod"

*src/share/vm/memory/filemap.cpp*
Instead of adding "if (log_is_enabled(Debug, classload))", just remove 
this condition from the code.

      || (TraceClassLoading && Verbose)

These logs are really a part of TraceClassPaths, and we can UL-ize it in 
a separate patch.

*src/share/vm/oops/klass.cpp*
Remove the [] brackets, and change "Unlinking" -> "unlinking", " %s" -> 
": %s"

*src/share/vm/prims/jvmtiEnv.cpp*
"[Opened %s]" -> "opened: %s"

*src/share/vm/services/classLoadingService.cpp**
*Remove [] brackets

Thanks
- Ioi

On 1/7/16 11:10 PM, Max Ockner wrote:
> Hello,
> Please review this unified logging conversion for several related 
> flags in the class loading system.
>
> Bugs:
> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
> classloaderdata)
> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>
> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>
> Summary:
>
> There are two separate issues here. Originally Ioi and I began working 
> on these fixes in parallel, but eventually it became obvious that the 
> classload and classunload tags needed to be implemented together. This 
> change is a combination of Ioi's change for 8079408 and my change for 
> 8142506.
>
> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
> This flag is added to the alias table. More verbose logging exists at 
> level debug (one level of verbosity up from info)
>
> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
> This flag is added to the alias table. More verbose logging exists at 
> level trace (converted from uses of WizardMode)
>
> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>
> The changes to TraceClassLoading and TraceClassUnloading also effected 
> the implementation of "-verbose:class"
>
> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>
> If you have questions about the updates to the classloading log, Ioi 
> can give a better answer than I can.
>
> Thanks,
> Max
>
>
>
>


From coleen.phillimore at oracle.com  Fri Jan  8 22:21:45 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 8 Jan 2016 17:21:45 -0500
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F282@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C1854.8060806@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F282@DEWDFEMB12A.global.corp.sap>
Message-ID: <56903679.6070604@oracle.com>


Goetz,
Thanks for the reply.

On 1/7/16 10:41 AM, Lindenmaier, Goetz wrote:
> Hi Coleen,
>
> thanks for looking at this!
>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/code/dependencies.cpp.udiff.html
>>
>> Can you fix the preexisting weird indentation of
>> + assert(_call_site() ->is_a(SystemDictionary::CallSite_klass()), "must
>> be");
> Done.
>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/jvmci/jvmciJavaClasses.hpp.udiff.html
>>
>> Don't have an opinion about including the .inline.hpp files in these.
>> The compiler team should probably clean this up.
> Yes, I think so too.  It should be done in the compiler repo to avoid
> clashes.
>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>
>> Why isn't inline in the declaration for obj_at_put ?
>> Why is inline commented out for some?
> I have a follow-up change with a lot of cleanups in gc coding.
> In that change, I will fix the remaining inlines.  I wanted to
> make an extra change for gc to simplify reviewing.

Ah, thank you for explaining this mystery.  I couldn't think of why this 
was.
>   
>> + inline bool is_instance() const;
>> + /*inline*/ bool is_array() const;
>>
>>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/oops/oop.inline.hpp.udiff.html
>>
>> I'm not really happy with the re-sorting because it may make backporting
>> difficult, but it's not that many that were moved and the order of these
>> functions has always seeemed random to me.  So I guess it's ok.
>>
>> Can you line up the '\' in the OOP_ITERATE macros at the end?
>>
>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/oops/typeArrayOop.cpp.udiff.html
> I think that's an artefact of udiff.  The patch and my files look fine.
>
>> This non-inline function could affect performance.   It may be called
>> from GC.  We might need a typeArrayOop.inline.hpp for it.
> I'll make a new file to be on the safe side.
>
> Why is there the empty typeArrayOop.cpp file?
>   

Oh, heaven knows why there was an empty file!   Maybe an artifact of 
includeDB_junk.    Thanks for making this change.

>> I can sponsor this, pending further review.
> Thanks!

You have replied to Dan and David.  I agree with you that this is a 
worthwhile change.  I think there are some platforms (windows maybe?) 
that will just call 0 and crash if the definition of a function is 
missing, which you can do with a missing .inline.hpp include.   More 
compile time diagnostics makes the code less difficult to work on and 
more robust.

Thanks,
Coleen

>
> Best regards,
>     Goetz.
>
>
>
>> Coleen
>>
>>
>> On 1/4/16 10:44 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
>> header file.
>>> Unfortunately, the 'inline' qualifier is added to the function
>> implementations
>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore, the
>>> compiler can not detect failing inlines properly.
>>>
>>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
>> Also
>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>
>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
>>>
>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>>>
>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
>>> bigger changes to this file in the rt repo, because jvmci is subject to
>>> freqent changes recently.
>>>
>>> The following methods were moved to .cpp files:
>>>
>>> ProtectionDomainCacheTable::compute_hash()
>>> ProtectionDomainCacheTable::index_for()
>>> typeArrayOopDesc::object_size()
>>> This is called only once outside .cpp file:
>>> CallSiteDepChange::CallSiteDepChange()
>>> This is only called in .cpp file
>>> ConstantPool::string_at_put()
>>>
>>> If someone considers not inlining these harmful to performance,
>>> I will add a new .inline.hpp file for them.
>>>
>>> Please review this change.  I please need a sponsor.
>>> There are no functional edits, so it should be simple to review.
>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.01/
>>>
>>> Best regards,
>>>     Goetz.


From coleen.phillimore at oracle.com  Fri Jan  8 23:21:38 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 8 Jan 2016 18:21:38 -0500
Subject: RFR (S) round 0 for 8135198 Add -XX:VMOptionsFile support to
	JAVA_TOOL_OPTIONS and _JAVA_OPTIONS
In-Reply-To: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
References: <ec063228-9fef-4beb-848e-d0a71055dc16@default>
Message-ID: <56904482.9080209@oracle.com>


This looks good to me.
Coleen

On 1/6/16 6:39 PM, Ron Durbin wrote:
> This change adds -XX:VMOptionsFile support to the JAVA_TOOL_OPTIONS
> and _JAVA_OPTIONS environment variables. With this change, the
> -XX:VMOptionsFile option is supported in the following option
> containers:
>
> - the command line
> - JAVA_TOOL_OPTIONS env var
> - _JAVA_OPTIONS env var
>
> Webrev:
>     http://cr.openjdk.java.net/~rdurbin/8135198_OCR0_JDK9_webrev
>
> Bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8135198
>
> This bug fix has been tested on:
>       OS:
>         Solaris, MAC, Windows, Linux
>       Tests:
>         Manual unit tests
>         JPRT with -testset hotspot(including the SQE current test coverage for this feature.)
>


From coleen.phillimore at oracle.com  Fri Jan  8 23:54:14 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 8 Jan 2016 18:54:14 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <568F60E4.50609@oracle.com>
References: <568F60E4.50609@oracle.com>
Message-ID: <56904C26.1010207@oracle.com>


Hi, I have a bunch of comments that Ioi may have to help answer because 
I had some questions about how the logging output comes out.

http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html

I think these can be UL-ized with less lines.  There's no need to check 
if log_is_enabled here.

*!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
*!tty->print_cr("is_anonymous: %s", 
class_loader()->klass()->internal_name());*
*!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != NULL) {*
*!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
*+ log->print_cr("is_anonymous: %s", 
class_loader()->klass()->internal_name());*
}

*!if (class_loader() != NULL) {*
*!tty->print_cr("is_anonymous: %s", 
class_loader()->klass()->internal_name());*
*+ log_trace(classloaderdata)("is_anonymous: %s", 
class_loader()->klass()->internal_name());*
}

What does this come out looking like?  It seems like it's going to have 
[classloaderdata] in front of every line printed.  I think this wants to 
be all one log line.

*+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
*+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
*+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
*)cld->class_loader()),*
*+ cld->loader_name());*
*+ *
*+ if (string.not_null()) {*
*+ log->print(": ");*
*+ java_lang_String::print(string(), log);*
*+ } *
[classloaderdata] create class loader data <address>
[classloaderdata]  for instance <addr> of some name
[classloaderdata] :
[classloaderdata] some string

???

http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html

You don't need to check log_is_enabled.  log_debug macro does that. 2 
instances in this file.

*+ if (log_is_enabled(Debug, classload)) {*
*+ log_debug(classload)("[Add main shared path (%s) %s]", 
(cpe->is_jar_file() ? "jar" : "dir"), name);*
*+ } *


http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html

Do you want this to come out with fewer lines?   Maybe the messages 
should be collected in a tempStream and printed out at the end? LIke in 
this file:
http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html

There's a bunch of tty->print's still in this function.

*+ Handle class_loader(loader_data->class_loader());*
*+ tty->print(" source: %s", class_loader->klass()->external_name()); *

This could be simplified avoiding the Handle, which is not needed.

*+ tty->print(" source: %s", 
loader_data->class_loader()->klass()->external_name());*

Is the loader_data argument to print_loading_log simply the 
instanceKLass::_class_loader_data field?  In which case you can remove 
the argument and have:

*+ tty->print(" source: %s", class_loader()->klass()->external_name());
*

Obviously not to tty.

http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html

This one can be condensed also

*!if (_log_is_enabled(Info, classload)_) {*
*!_outputStream* log = LogHandle(classload)::info_stream(_);*
*+ log->print_cr("[Opened %s]", zip_entry->name());*
}

to

*+ log_info(classload)("[Opened %s]", zip_entry->name());

* 
http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html

Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in his 
previous mail.

http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html

The return value 'ret' isn't used.  Either return an error if it returns 
and error (what errors does it return?) or don't have 'ret'.

http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html

Test looks great to me!

  150         checkFor("[classload]", "java.lang.Object", "source:");
  151         checkFor("[classunload]", "[Unloading class");

Can this be:

  150         checkFor("[classload]", "java.lang.Object", "source:", "[classunload]", "[Unloading class");

To not start a new process?

Thanks,
Coleen

On 1/8/16 2:10 AM, Max Ockner wrote:
> Hello,
> Please review this unified logging conversion for several related 
> flags in the class loading system.
>
> Bugs:
> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
> classloaderdata)
> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>
> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>
> Summary:
>
> There are two separate issues here. Originally Ioi and I began working 
> on these fixes in parallel, but eventually it became obvious that the 
> classload and classunload tags needed to be implemented together. This 
> change is a combination of Ioi's change for 8079408 and my change for 
> 8142506.
>
> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
> This flag is added to the alias table. More verbose logging exists at 
> level debug (one level of verbosity up from info)
>
> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
> This flag is added to the alias table. More verbose logging exists at 
> level trace (converted from uses of WizardMode)
>
> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>
> The changes to TraceClassLoading and TraceClassUnloading also effected 
> the implementation of "-verbose:class"
>
> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>
> If you have questions about the updates to the classloading log, Ioi 
> can give a better answer than I can.
>
> Thanks,
> Max
>
>
>
>


From ioi.lam at oracle.com  Sat Jan  9 01:57:01 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 08 Jan 2016 17:57:01 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56904C26.1010207@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
Message-ID: <569068ED.6070509@oracle.com>



On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>
> Hi, I have a bunch of comments that Ioi may have to help answer 
> because I had some questions about how the logging output comes out.
>
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>
>
> I think these can be UL-ized with less lines.  There's no need to 
> check if log_is_enabled here.
>
> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
> *!tty->print_cr("is_anonymous: %s", 
> class_loader()->klass()->internal_name());*
> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
> NULL) {*
> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
> *+ log->print_cr("is_anonymous: %s", 
> class_loader()->klass()->internal_name());*
> }
>
> *!if (class_loader() != NULL) {*
> *!tty->print_cr("is_anonymous: %s", 
> class_loader()->klass()->internal_name());*
> *+ log_trace(classloaderdata)("is_anonymous: %s", 
> class_loader()->klass()->internal_name());*
> }
>
> What does this come out looking like?  It seems like it's going to 
> have [classloaderdata] in front of every line printed.  I think this 
> wants to be all one log line.
>
> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
> *)cld->class_loader()),*
> *+ cld->loader_name());*
> *+ *
> *+ if (string.not_null()) {*
> *+ log->print(": ");*
> *+ java_lang_String::print(string(), log);*
> *+ } *
> [classloaderdata] create class loader data <address>
> [classloaderdata]  for instance <addr> of some name
> [classloaderdata] :
> [classloaderdata] some string
>
The UL JEP says this in http://openjdk.java.net/jeps/158
"Goals ... Print line-at-a-time (no interleaving within same line)"

log->print() is line-buffered. So all of these will be concatenated into 
the same buffer until the final log->cr() or log->print_cr(), at which 
point the whole line will be printed (with a single [classloaderdata] 
prefix).

Here's an example:

$ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
[0.780s][debug  ][classloaderdata] create class loader data 
0x00007f71704d6940 for instance 0x000000041103dea0 of 
sun/misc/Launcher$AppClassLoader: 
"sun.misc.Launcher$AppClassLoader at 722c41f4"

>
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>
>
> You don't need to check log_is_enabled.  log_debug macro does that. 2 
> instances in this file.
>
> *+ if (log_is_enabled(Debug, classload)) {*
> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
> (cpe->is_jar_file() ? "jar" : "dir"), name);*
> *+ } *
>
>
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>
>
> Do you want this to come out with fewer lines?   Maybe the messages 
> should be collected in a tempStream and printed out at the end? LIke 
> in this file:
> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>
>
There's no need to use the tempStream, since the UL log already handles 
buffering.

If my understanding of UL buffering is correct, I think the use of 
tempStream should be removed as a clean up.

> There's a bunch of tty->print's still in this function.
>
> *+ Handle class_loader(loader_data->class_loader());*
> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>
> This could be simplified avoiding the Handle, which is not needed.
>
> *+ tty->print(" source: %s", 
> loader_data->class_loader()->klass()->external_name());*
>
> Is the loader_data argument to print_loading_log simply the 
> instanceKLass::_class_loader_data field?  In which case you can remove 
> the argument and have:
>
> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
> *
>
The original code (from classFileParser.cpp) is this:

         tty->print("[Loaded %s from %s]\n", ik->external_name(),
_loader_data->class_loader()->klass()->external_name());

I suppose _loader_data->class_loader() in that context should be exactly 
the same as class_loader() inside the InstanceKlass::print_loading_log 
function, so your suggestion should work.

> Obviously not to tty.

You're right. The "tty->print" should be changed to log->print in 
InstanceKlass::print_loading_log. What I don't understand is why the 
output looks just fine.

I never noticed these during my testing because the lines that use 
tty->print are uncommon and did not show up. I'll try to come up with a 
test case (I think it has something to do with reflection proxies ...).


Thanks
- Ioi
>
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>
>
> This one can be condensed also
>
> *!if (_log_is_enabled(Info, classload)_) {*
> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
> *+ log->print_cr("[Opened %s]", zip_entry->name());*
> }
>
> to
>
> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>
> * 
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>
> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
> his previous mail.
>
> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>
>
> The return value 'ret' isn't used.  Either return an error if it 
> returns and error (what errors does it return?) or don't have 'ret'.
>
> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>
>
> Test looks great to me!
>
>  150         checkFor("[classload]", "java.lang.Object", "source:");
>  151         checkFor("[classunload]", "[Unloading class");
>
> Can this be:
>
>  150         checkFor("[classload]", "java.lang.Object", "source:", 
> "[classunload]", "[Unloading class");
>
> To not start a new process?
>
> Thanks,
> Coleen
>
> On 1/8/16 2:10 AM, Max Ockner wrote:
>> Hello,
>> Please review this unified logging conversion for several related 
>> flags in the class loading system.
>>
>> Bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>> classloaderdata)
>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>
>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>
>> Summary:
>>
>> There are two separate issues here. Originally Ioi and I began 
>> working on these fixes in parallel, but eventually it became obvious 
>> that the classload and classunload tags needed to be implemented 
>> together. This change is a combination of Ioi's change for 8079408 
>> and my change for 8142506.
>>
>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>> This flag is added to the alias table. More verbose logging exists at 
>> level debug (one level of verbosity up from info)
>>
>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>> This flag is added to the alias table. More verbose logging exists at 
>> level trace (converted from uses of WizardMode)
>>
>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>
>> The changes to TraceClassLoading and TraceClassUnloading also 
>> effected the implementation of "-verbose:class"
>>
>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>
>> If you have questions about the updates to the classloading log, Ioi 
>> can give a better answer than I can.
>>
>> Thanks,
>> Max
>>
>>
>>
>>
>


From markus.gronlund at oracle.com  Sat Jan  9 17:05:20 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Sat, 9 Jan 2016 09:05:20 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <568EC461.8030209@oracle.com>
References: <568EC461.8030209@oracle.com>
Message-ID: <478451fa-2aa5-4f8b-8a53-22b46e0e9781@default>

Hi Coleen,

Thanks for bringing this issue to attention, I actually stumbled into issues with this code in some contexts that I worked on last week.

I agree that it needs to be reworked, however I think my reasons differ a bit from the reason you put forth, which I believe is not a real problem.

If I understand correctly, you are worried about the context which you describe with:

"Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:

TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC

The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  
Fortunately, we haven't seen this bug."

Actually I think this is not really a problem - this is because this will not call the copy constructor. Instead, it will call the type conversion constructor:

TempNewSymbol(Symbol* s) : _temp(s) {}

Since this constructor does not increment or decrement the _refcount, you are ok from a GC perspective.


However, there are multiple other ways that TempNewSymbol can mess up the reference counting.

I have summarized my analysis of both existing behavior as well as the suggested fix here:

814594:

Problem description: http://cr.openjdk.java.net/~mgronlun/8145940/8145940_TempNewSymbol_analysis.txt 
Webrev suggesting new impl: http://cr.openjdk.java.net/~mgronlun/8145940/webrev01/ 
bug link https://bugs.openjdk.java.net/browse/JDK-8145940

Please let me know what you think.

Best regards
Markus


-----Original Message-----
From: Coleen Phillimore 
Sent: den 7 januari 2016 21:03
To: hotspot-runtime-dev; Kim Barrett
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

Summary: Add clear() to the assignment operator and add copy constructor.

Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with 
PrintSymbolTableSizeHistogram statistics:

   Percent removed          1.35
   Reference counts          194583

clean:

   Percent removed          1.53
   Reference counts          194245

Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:

TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC

The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  
Fortunately, we haven't seen this bug.

open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
bug link https://bugs.openjdk.java.net/browse/JDK-8145940

Thanks,
Coleen

From david.holmes at oracle.com  Mon Jan 11 01:01:30 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jan 2016 11:01:30 +1000
Subject: (XS) RFR: 8146222: assert(_initialized) failed: TLS not
	initialized yet!
In-Reply-To: <568FCC03.5080207@oracle.com>
References: <568F3481.80106@oracle.com> <568FCC03.5080207@oracle.com>
Message-ID: <5692FEEA.2000804@oracle.com>

Thanks Dan!

David

On 9/01/2016 12:47 AM, Daniel D. Daugherty wrote:
> On 1/7/16 9:01 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146222
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8146222/webrev/
>
> src/share/vm/runtime/thread.cpp
>      No comments.
>
> Thumbs up.
>
> Dan
>
>
>>
>> JDK-8144947 showed an error path, on Windows, where we can call
>> Thread::current_or_null before TLS has been initialized and so hit the
>> assertion failure - see bug report for details.
>>
>> Simple fix is to move the ThreadLocalStorage::init() prior to any
>> argument parsing code. As it contains simple OS library calls it can
>> be initialized very early. Even the asserts in it still work (somewhat
>> surprisingly) after the move.
>>
>> Failure mode of
>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java before the
>> fix:
>>
>> Agent[1].stdout: ## nof_mallocs = 674, nof_frees = 38
>> Agent[1].stdout: ## memory stomp:
>> Agent[1].stdout: GuardedMemory(0x0000000000fbf690)
>> base_addr=0x0000000000fbf3f0 tag=0x00000000000da360 user_size=16512112
>> user_data=0x0000000000fbf410
>> Agent[1].stdout: Header guard @0x0000000000fbf3f0 is BROKEN
>> Agent[1].stdout: # To suppress the following error report, specify
>> this argument
>> Agent[1].stdout: # after -XX: or in .hotspotrc:
>> SuppressErrorAt=\threadLocalStorage_windows.cpp:52
>> Agent[1].stdout: #
>> Agent[1].stdout: # A fatal error has been detected by the Java Runtime
>> Environment:
>> Agent[1].stdout: #
>> Agent[1].stdout: # Internal Error
>> (C:\jprt\T\P1\020042.daholme\s\hotspot\src\os\windows\vm\threadLocalStorage_windows.cpp:52),
>> pid=5076, tid=4348
>> Agent[1].stdout: # assert(_initialized) failed: TLS not initialized yet!
>>
>> Failure mode after:
>>
>> Agent[1].stdout: ## nof_mallocs = 601, nof_frees = 36
>> Agent[1].stdout: ## memory stomp:
>> Agent[1].stdout: GuardedMemory(0x00f1fc44) base_addr=0x00f1fb40
>> tag=0x003a9bc0 user_size=1942466404 user_data=0x00f1fb58
>> Agent[1].stdout: Header guard @0x00f1fb40 is BROKEN
>> Agent[1].stdout: #
>> Agent[1].stdout: # A fatal error has been detected by the Java Runtime
>> Environment:
>> Agent[1].stdout: #
>> Agent[1].stdout: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at
>> pc=0x73bb8ab6, pid=10328, tid=7672
>>
>> Testing:
>>   - JPRT
>>   - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
>>   - testing that the asserts in the relocated init() method fire
>> correctly
>>
>> Thanks,
>> David
>

From david.holmes at oracle.com  Mon Jan 11 01:46:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jan 2016 11:46:00 +1000
Subject: RFR [9] 8146736: Move sun.misc performance counters to
	jdk.internal.perf
In-Reply-To: <11DB3ED6-8CC6-41F3-82E3-670D62BE906C@oracle.com>
References: <11DB3ED6-8CC6-41F3-82E3-670D62BE906C@oracle.com>
Message-ID: <56930958.8040906@oracle.com>

Hi Chris,

On 10/01/2016 7:31 PM, Chris Hegarty wrote:
> In preparation for JEP 260, the performance counters can be moved out of
> sun.misc and located somewhere more appropriate, like jdk.internal.perf.
>
> http://cr.openjdk.java.net/~chegar/8146736/
>
> Mandy asked whether this change should go through jdk9/hs-rt or jdk9/dev,
> I see no strong reason why is should go through hs-rt, so propose to go through
> jdk9/dev, unless there are objections. The hotspot changes are minor.

The changes are minor and I see no reason to not go through the dev 
forest, given the related changes. I've cc'd hotspot-runtime so others 
are aware.

Thanks,
David

> Note: the use of cleaner in Perf will be replaced with the proposed CleanerFactory
> when it is added.
>
> -Chris.
>

From david.holmes at oracle.com  Mon Jan 11 02:00:19 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jan 2016 12:00:19 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
Message-ID: <56930CB3.5090906@oracle.com>

On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
>> I still don't see how adding inline to the declaration changes anything
>> here. The compiler can't do the inlining unless the .inline.hpp file has
>> been included. ???
> Yes, and therefore it issues an error if the keyword is in the .hpp header:
>
> In file included from /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/utilities/hashtable.cpp:27:0:
> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/classfile/javaClasses.hpp:113:30: error: inline function 'static typeArrayOopDesc* java_lang_String::value(oop)' used but never defined [-Werror]
>     static inline typeArrayOop value(oop java_string);
>
> So you can not miss including the inline.hpp header.

Won't you get a link time failure in any case ?

I'm just concerned we are relying on unspecified compiler behaviour 
which might change in the future. The docs say you don't put "inline" on 
the declaration. What's to stop the next version of the compiler from 
flagging that as a warning?

Thanks,
David

> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 8. Januar 2016 08:54
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
>> header files
>>
>>
>>
>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Freitag, 8. Januar 2016 06:07
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>> fix
>>>> header files
>>>>
>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>> Hi David,
>>>>>
>>>>> the documentation you point to makes the point that whether to inline
>>>>> is an implementation detail, and that that should not be annotated to
>>>>> the declaration.  Basically, this is a good point.
>>>>>
>>>>> But the documentation does not cover the fact that
>>>>> we have the implementation in a different file than the declaration.
>>>>> The .inline.hpp is not included always (as you pointed out).
>>>>>
>>>>> Therefore, if we compile with precompiled headers, we get more
>>>>> inlines than if we do so without.
>>>>> Further, many functions were moved to oop.linline.hpp during the
>>>>> recent cleanups, and I think all the #includes I had to add were not
>>>>> left out deliberately, but just happened because the compiler did
>>>>> not complain.
>>>>> I think if somebody decides not to place a function implementation
>>>>> in a .cpp file, it should have the chance to be inlined at all it's calls.
>>>>> Putting the 'inline' into the .hpp file assures this.
>>>>
>>>> Sorry I don't follow that. If you include the .inline.hpp you don't need
>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>>> have access to the definition so that it can be inlined.
>>> Yes.
>>>
>>>> it seems to me that if
>>>> you want it inlined then you must include the .inline.hpp anywhere it is
>>>> needed. Anything else seems a bad-aid.
>>> But I think not the caller should decide whether it's to be inlined,
>>> but the implementor of the method (and next the compiler).
>>> As you describe, the caller has to decide which header to include.
>>> So the caller has to know implementation details of the callee,
>>> which is contrary to the encapsulation described in that documentation.
>>
>> That's my understanding of the way things are expected to work. This is
>> not a public library exporting its interface in a .hpp file, this an
>> internal part of the bigger system. As I understand it we define the
>> .inline.hpp file precisely so that clients can include it. And yes the
>> clients have to know to do that.
>>
>>> If you add the 'inline' keyword in the header, the compiler enforces
>>> that the includes are in a way that it can do what the implementor
>>> of the callee / of the method to be inlined intended.
>>
>> I still don't see how adding inline to the declaration changes anything
>> here. The compiler can't do the inlining unless the .inline.hpp file has
>> been included. ???
> Yes, but it issues a warning and  will abort if it's wrong.
>
>
>>
>> Cheers,
>> David
>> -----
>>
>>
>>>> Maybe
>>>> precompiled headers messes with that somehow
>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>>> is it dragged in by some other .inline.hpp header.
>>> I would assume this is a remnant of the problems with this header.
>>> But if it was listed there, it would make a difference.
>>>
>>> To put it the other way round: do you think all the places I had to
>>> clean up are well founded decisions not to include the methods
>>> from oop.inline.hpp?
>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>>> unintuitive to me.
>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>> (I'll add the inline keyword in a follow-up change for gc files, in case
>>> this change is accepted.)
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>> and
>>>> fix
>>>>>> header files
>>>>>>
>>>>>> Hi Goetz,
>>>>>>
>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
>> .hpp
>>>>>> header file.
>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>> implementations
>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
>>>> the
>>>>>>> compiler can not detect failing inlines properly.
>>>>>>>
>>>>>>> This change moves the inline directive from oop.inline.hpp to
>> oop.hpp.
>>>>>> Also
>>>>>>
>>>>>> This seems contrary to the C++ FAQ:
>>>>>>
>>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>>
>>>>>> The declaration in the .hpp should not have inline, only the definition,
>>>>>> which in our case is in the .inline.hpp file.
>>>>>>
>>>>>> Any code that includes the .inline.hpp will have seen the definition of
>>>>>> the inline function prior to its use - as long as the includes are correct.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
>>>>>>>
>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp
>> files.
>>>>>>>
>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
>>>>>>>
>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to
>> do
>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject to
>>>>>>> freqent changes recently.
>>>>>>>
>>>>>>> The following methods were moved to .cpp files:
>>>>>>>
>>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>>> typeArrayOopDesc::object_size()
>>>>>>> This is called only once outside .cpp file:
>>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>>> This is only called in .cpp file
>>>>>>> ConstantPool::string_at_put()
>>>>>>>
>>>>>>> If someone considers not inlining these harmful to performance,
>>>>>>> I will add a new .inline.hpp file for them.
>>>>>>>
>>>>>>> Please review this change.  I please need a sponsor.
>>>>>>> There are no functional edits, so it should be simple to review.
>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>> rt/webrev.01/
>>>>>>>
>>>>>>> Best regards,
>>>>>>>       Goetz.
>>>>>>>

From chris.hegarty at oracle.com  Mon Jan 11 06:20:37 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 11 Jan 2016 06:20:37 +0000
Subject: RFR [9] 8146736: Move sun.misc performance counters to
	jdk.internal.perf
In-Reply-To: <56930958.8040906@oracle.com>
References: <11DB3ED6-8CC6-41F3-82E3-670D62BE906C@oracle.com>
	<56930958.8040906@oracle.com>
Message-ID: <21AF1592-9564-4722-B854-A8BC44E68FCE@oracle.com>

On 11 Jan 2016, at 01:46, David Holmes <david.holmes at oracle.com> wrote:

> Hi Chris,
> 
> On 10/01/2016 7:31 PM, Chris Hegarty wrote:
>> In preparation for JEP 260, the performance counters can be moved out of
>> sun.misc and located somewhere more appropriate, like jdk.internal.perf.
>> 
>> http://cr.openjdk.java.net/~chegar/8146736/
>> 
>> Mandy asked whether this change should go through jdk9/hs-rt or jdk9/dev,
>> I see no strong reason why is should go through hs-rt, so propose to go through
>> jdk9/dev, unless there are objections. The hotspot changes are minor.
> 
> The changes are minor and I see no reason to not go through the dev forest, given the related changes. I've cc'd hotspot-runtime so others are aware.

Thanks David.

-Chris.

> Thanks,
> David
> 
>> Note: the use of cleaner in Perf will be replaced with the proposed CleanerFactory
>> when it is added.
>> 
>> -Chris.
>> 


From volker.simonis at gmail.com  Mon Jan 11 07:56:53 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 11 Jan 2016 08:56:53 +0100
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <56930CB3.5090906@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<56930CB3.5090906@oracle.com>
Message-ID: <CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>

On Mon, Jan 11, 2016 at 3:00 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
>>
>> Hi David,
>>
>>> I still don't see how adding inline to the declaration changes anything
>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>> been included. ???
>>
>> Yes, and therefore it issues an error if the keyword is in the .hpp
>> header:
>>
>> In file included from
>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/utilities/hashtable.cpp:27:0:
>>
>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/classfile/javaClasses.hpp:113:30:
>> error: inline function 'static typeArrayOopDesc*
>> java_lang_String::value(oop)' used but never defined [-Werror]
>>     static inline typeArrayOop value(oop java_string);
>>
>> So you can not miss including the inline.hpp header.
>
>
> Won't you get a link time failure in any case ?
>

With some compilers. But if the method has external linkage the
compiler usually instantiates a version of the method even if it is
not called.

>
> I'm just concerned we are relying on unspecified compiler behaviour which
> might change in the future. The docs say you don't put "inline" on the
> declaration. What's to stop the next version of the compiler from flagging
> that as a warning?
>

Who did ever ever claime that putting the inline specifier on both,
definition AND declaration is unspecified compiler behaviour? That's
just plain wrong! Please simply read the C++ Standard [1]. It clearly
states in paragraph 2 of section 9.3: "...An inline member function
(whether static or non-static) may also be defined outside of its
class definition provided either its declaration in the class
definition or its definition outside of the class definition declares
the function as inline...".

What has been cited here so far (e.g. [2]) is simply an advice (and
not more!) which shouldn't be confused with the language
specification! The reason behind the advice to 'place the inline
specifier on the method definition rather than on its declaration' is
because the writer deems it an implementation detail. BUT you have to
take into account that in the HotSpot code base we already have the
subdivision of header files into "true" .hpp files and .inline.hpp
files anyway. We've done that because of performance reasons and thus
already put the burden of deciding which one is required on the user
anyway. So the argument raised in [2] that the "inlineness" of a
method is "an implementation detail" doesn't quite hold true for the
HotSpot code base.

And once again - Goetz's change helps in ensuring that methods which
are declared inline will be always visible at call sites and thus
valid inline candidates. If this is not the case we will now (with
Goetz's change) get a compiler warning where we just silently got a
plain function call before.

Regards,
Volker

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
[2] https://isocpp.org/wiki/faq/inline-functions#where-to-put-inline-keyword

> Thanks,
>
> David
>
>> Best regards,
>>    Goetz.
>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Freitag, 8. Januar 2016 08:54
>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>>> fix
>>> header files
>>>
>>>
>>>
>>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>> Sent: Freitag, 8. Januar 2016 06:07
>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>>> dev at openjdk.java.net
>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>>> and
>>>
>>> fix
>>>>>
>>>>> header files
>>>>>
>>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> the documentation you point to makes the point that whether to inline
>>>>>> is an implementation detail, and that that should not be annotated to
>>>>>> the declaration.  Basically, this is a good point.
>>>>>>
>>>>>> But the documentation does not cover the fact that
>>>>>> we have the implementation in a different file than the declaration.
>>>>>> The .inline.hpp is not included always (as you pointed out).
>>>>>>
>>>>>> Therefore, if we compile with precompiled headers, we get more
>>>>>> inlines than if we do so without.
>>>>>> Further, many functions were moved to oop.linline.hpp during the
>>>>>> recent cleanups, and I think all the #includes I had to add were not
>>>>>> left out deliberately, but just happened because the compiler did
>>>>>> not complain.
>>>>>> I think if somebody decides not to place a function implementation
>>>>>> in a .cpp file, it should have the chance to be inlined at all it's
>>>>>> calls.
>>>>>> Putting the 'inline' into the .hpp file assures this.
>>>>>
>>>>>
>>>>> Sorry I don't follow that. If you include the .inline.hpp you don't
>>>>> need
>>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>>>> have access to the definition so that it can be inlined.
>>>>
>>>> Yes.
>>>>
>>>>> it seems to me that if
>>>>> you want it inlined then you must include the .inline.hpp anywhere it
>>>>> is
>>>>> needed. Anything else seems a bad-aid.
>>>>
>>>> But I think not the caller should decide whether it's to be inlined,
>>>> but the implementor of the method (and next the compiler).
>>>> As you describe, the caller has to decide which header to include.
>>>> So the caller has to know implementation details of the callee,
>>>> which is contrary to the encapsulation described in that documentation.
>>>
>>>
>>> That's my understanding of the way things are expected to work. This is
>>> not a public library exporting its interface in a .hpp file, this an
>>> internal part of the bigger system. As I understand it we define the
>>> .inline.hpp file precisely so that clients can include it. And yes the
>>> clients have to know to do that.
>>>
>>>> If you add the 'inline' keyword in the header, the compiler enforces
>>>> that the includes are in a way that it can do what the implementor
>>>> of the callee / of the method to be inlined intended.
>>>
>>>
>>> I still don't see how adding inline to the declaration changes anything
>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>> been included. ???
>>
>> Yes, but it issues a warning and  will abort if it's wrong.
>>
>>
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>
>>>>> Maybe
>>>>> precompiled headers messes with that somehow
>>>>
>>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>>>> is it dragged in by some other .inline.hpp header.
>>>> I would assume this is a remnant of the problems with this header.
>>>> But if it was listed there, it would make a difference.
>>>>
>>>> To put it the other way round: do you think all the places I had to
>>>> clean up are well founded decisions not to include the methods
>>>> from oop.inline.hpp?
>>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>>>> unintuitive to me.
>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>
>>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>>>
>>>> (I'll add the inline keyword in a follow-up change for gc files, in case
>>>> this change is accepted.)
>>>>
>>>> Best regards,
>>>>     Goetz.
>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> Best regards,
>>>>>>      Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>>>
>>> runtime-
>>>>>>>
>>>>>>> dev at openjdk.java.net
>>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>
>>> and
>>>>>
>>>>> fix
>>>>>>>
>>>>>>> header files
>>>>>>>
>>>>>>> Hi Goetz,
>>>>>>>
>>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
>>>
>>> .hpp
>>>>>>>
>>>>>>> header file.
>>>>>>>>
>>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>>>
>>>>>>> implementations
>>>>>>>>
>>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
>>>>>>>> Therefore,
>>>>>
>>>>> the
>>>>>>>>
>>>>>>>> compiler can not detect failing inlines properly.
>>>>>>>>
>>>>>>>> This change moves the inline directive from oop.inline.hpp to
>>>
>>> oop.hpp.
>>>>>>>
>>>>>>> Also
>>>>>>>
>>>>>>> This seems contrary to the C++ FAQ:
>>>>>>>
>>>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>>>
>>>>>>> The declaration in the .hpp should not have inline, only the
>>>>>>> definition,
>>>>>>> which in our case is in the .inline.hpp file.
>>>>>>>
>>>>>>> Any code that includes the .inline.hpp will have seen the definition
>>>>>>> of
>>>>>>> the inline function prior to its use - as long as the includes are
>>>>>>> correct.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
>>>>>>>> oop.hpp.
>>>>>>>>
>>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or
>>>>>>>> .cpp
>>>
>>> files.
>>>>>>>>
>>>>>>>>
>>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
>>>>>>>> this is a
>>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
>>>>>>>> acceptable.
>>>>>>>>
>>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want
>>>>>>>> to
>>>
>>> do
>>>>>>>>
>>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
>>>>>>>> to
>>>>>>>> freqent changes recently.
>>>>>>>>
>>>>>>>> The following methods were moved to .cpp files:
>>>>>>>>
>>>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>>>> typeArrayOopDesc::object_size()
>>>>>>>> This is called only once outside .cpp file:
>>>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>>>> This is only called in .cpp file
>>>>>>>> ConstantPool::string_at_put()
>>>>>>>>
>>>>>>>> If someone considers not inlining these harmful to performance,
>>>>>>>> I will add a new .inline.hpp file for them.
>>>>>>>>
>>>>>>>> Please review this change.  I please need a sponsor.
>>>>>>>> There are no functional edits, so it should be simple to review.
>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>>>
>>>>> rt/webrev.01/
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>       Goetz.
>>>>>>>>
>

From goetz.lindenmaier at sap.com  Mon Jan 11 08:13:23 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 11 Jan 2016 08:13:23 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<56930CB3.5090906@oracle.com>
	<CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F111D0@DEWDFEMB12A.global.corp.sap>

Hi,

thanks Volker, I was just seacrching that reference in the C++ standard that
inline can go to the declaration.

Best regards,
  Goetz.

> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Monday, January 11, 2016 8:57 AM
> To: David Holmes <david.holmes at oracle.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> On Mon, Jan 11, 2016 at 3:00 AM, David Holmes <david.holmes at oracle.com>
> wrote:
> > On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
> >>
> >> Hi David,
> >>
> >>> I still don't see how adding inline to the declaration changes anything
> >>> here. The compiler can't do the inlining unless the .inline.hpp file has
> >>> been included. ???
> >>
> >> Yes, and therefore it issues an error if the keyword is in the .hpp
> >> header:
> >>
> >> In file included from
> >> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/utilities/hashtable.cpp:27:0:
> >>
> >> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/classfile/javaClasses.hpp:113:30:
> >> error: inline function 'static typeArrayOopDesc*
> >> java_lang_String::value(oop)' used but never defined [-Werror]
> >>     static inline typeArrayOop value(oop java_string);
> >>
> >> So you can not miss including the inline.hpp header.
> >
> >
> > Won't you get a link time failure in any case ?
> >
> 
> With some compilers. But if the method has external linkage the
> compiler usually instantiates a version of the method even if it is
> not called.
> 
> >
> > I'm just concerned we are relying on unspecified compiler behaviour which
> > might change in the future. The docs say you don't put "inline" on the
> > declaration. What's to stop the next version of the compiler from flagging
> > that as a warning?
> >
> 
> Who did ever ever claime that putting the inline specifier on both,
> definition AND declaration is unspecified compiler behaviour? That's
> just plain wrong! Please simply read the C++ Standard [1]. It clearly
> states in paragraph 2 of section 9.3: "...An inline member function
> (whether static or non-static) may also be defined outside of its
> class definition provided either its declaration in the class
> definition or its definition outside of the class definition declares
> the function as inline...".
> 
> What has been cited here so far (e.g. [2]) is simply an advice (and
> not more!) which shouldn't be confused with the language
> specification! The reason behind the advice to 'place the inline
> specifier on the method definition rather than on its declaration' is
> because the writer deems it an implementation detail. BUT you have to
> take into account that in the HotSpot code base we already have the
> subdivision of header files into "true" .hpp files and .inline.hpp
> files anyway. We've done that because of performance reasons and thus
> already put the burden of deciding which one is required on the user
> anyway. So the argument raised in [2] that the "inlineness" of a
> method is "an implementation detail" doesn't quite hold true for the
> HotSpot code base.
> 
> And once again - Goetz's change helps in ensuring that methods which
> are declared inline will be always visible at call sites and thus
> valid inline candidates. If this is not the case we will now (with
> Goetz's change) get a compiler warning where we just silently got a
> plain function call before.
> 
> Regards,
> Volker
> 
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> [2] https://isocpp.org/wiki/faq/inline-functions#where-to-put-inline-
> keyword
> 
> > Thanks,
> >
> > David
> >
> >> Best regards,
> >>    Goetz.
> >>
> >>> -----Original Message-----
> >>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>> Sent: Freitag, 8. Januar 2016 08:54
> >>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>> dev at openjdk.java.net
> >>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
> >>> fix
> >>> header files
> >>>
> >>>
> >>>
> >>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>> Sent: Freitag, 8. Januar 2016 06:07
> >>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>>>> dev at openjdk.java.net
> >>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> >>>>> and
> >>>
> >>> fix
> >>>>>
> >>>>> header files
> >>>>>
> >>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> >>>>>>
> >>>>>> Hi David,
> >>>>>>
> >>>>>> the documentation you point to makes the point that whether to
> inline
> >>>>>> is an implementation detail, and that that should not be annotated
> to
> >>>>>> the declaration.  Basically, this is a good point.
> >>>>>>
> >>>>>> But the documentation does not cover the fact that
> >>>>>> we have the implementation in a different file than the declaration.
> >>>>>> The .inline.hpp is not included always (as you pointed out).
> >>>>>>
> >>>>>> Therefore, if we compile with precompiled headers, we get more
> >>>>>> inlines than if we do so without.
> >>>>>> Further, many functions were moved to oop.linline.hpp during the
> >>>>>> recent cleanups, and I think all the #includes I had to add were not
> >>>>>> left out deliberately, but just happened because the compiler did
> >>>>>> not complain.
> >>>>>> I think if somebody decides not to place a function implementation
> >>>>>> in a .cpp file, it should have the chance to be inlined at all it's
> >>>>>> calls.
> >>>>>> Putting the 'inline' into the .hpp file assures this.
> >>>>>
> >>>>>
> >>>>> Sorry I don't follow that. If you include the .inline.hpp you don't
> >>>>> need
> >>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
> >>>>> have access to the definition so that it can be inlined.
> >>>>
> >>>> Yes.
> >>>>
> >>>>> it seems to me that if
> >>>>> you want it inlined then you must include the .inline.hpp anywhere it
> >>>>> is
> >>>>> needed. Anything else seems a bad-aid.
> >>>>
> >>>> But I think not the caller should decide whether it's to be inlined,
> >>>> but the implementor of the method (and next the compiler).
> >>>> As you describe, the caller has to decide which header to include.
> >>>> So the caller has to know implementation details of the callee,
> >>>> which is contrary to the encapsulation described in that documentation.
> >>>
> >>>
> >>> That's my understanding of the way things are expected to work. This is
> >>> not a public library exporting its interface in a .hpp file, this an
> >>> internal part of the bigger system. As I understand it we define the
> >>> .inline.hpp file precisely so that clients can include it. And yes the
> >>> clients have to know to do that.
> >>>
> >>>> If you add the 'inline' keyword in the header, the compiler enforces
> >>>> that the includes are in a way that it can do what the implementor
> >>>> of the callee / of the method to be inlined intended.
> >>>
> >>>
> >>> I still don't see how adding inline to the declaration changes anything
> >>> here. The compiler can't do the inlining unless the .inline.hpp file has
> >>> been included. ???
> >>
> >> Yes, but it issues a warning and  will abort if it's wrong.
> >>
> >>
> >>>
> >>> Cheers,
> >>> David
> >>> -----
> >>>
> >>>
> >>>>> Maybe
> >>>>> precompiled headers messes with that somehow
> >>>>
> >>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
> >>>> is it dragged in by some other .inline.hpp header.
> >>>> I would assume this is a remnant of the problems with this header.
> >>>> But if it was listed there, it would make a difference.
> >>>>
> >>>> To put it the other way round: do you think all the places I had to
> >>>> clean up are well founded decisions not to include the methods
> >>>> from oop.inline.hpp?
> >>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
> >>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
> >>>> unintuitive to me.
> >>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >>>
> >>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> >>>>
> >>>> (I'll add the inline keyword in a follow-up change for gc files, in case
> >>>> this change is accepted.)
> >>>>
> >>>> Best regards,
> >>>>     Goetz.
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>> David
> >>>>>
> >>>>>> Best regards,
> >>>>>>      Goetz.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
> >>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> >>>
> >>> runtime-
> >>>>>>>
> >>>>>>> dev at openjdk.java.net
> >>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline
> directives
> >>>
> >>> and
> >>>>>
> >>>>> fix
> >>>>>>>
> >>>>>>> header files
> >>>>>>>
> >>>>>>> Hi Goetz,
> >>>>>>>
> >>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in
> real
> >>>
> >>> .hpp
> >>>>>>>
> >>>>>>> header file.
> >>>>>>>>
> >>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
> >>>>>>>
> >>>>>>> implementations
> >>>>>>>>
> >>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
> >>>>>>>> Therefore,
> >>>>>
> >>>>> the
> >>>>>>>>
> >>>>>>>> compiler can not detect failing inlines properly.
> >>>>>>>>
> >>>>>>>> This change moves the inline directive from oop.inline.hpp to
> >>>
> >>> oop.hpp.
> >>>>>>>
> >>>>>>> Also
> >>>>>>>
> >>>>>>> This seems contrary to the C++ FAQ:
> >>>>>>>
> >>>>>>> https://isocpp.org/wiki/faq/inline-functions
> >>>>>>>
> >>>>>>> The declaration in the .hpp should not have inline, only the
> >>>>>>> definition,
> >>>>>>> which in our case is in the .inline.hpp file.
> >>>>>>>
> >>>>>>> Any code that includes the .inline.hpp will have seen the definition
> >>>>>>> of
> >>>>>>> the inline function prior to its use - as long as the includes are
> >>>>>>> correct.
> >>>>>>>
> >>>>>>> David
> >>>>>>> -----
> >>>>>>>
> >>>>>>>
> >>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
> >>>>>>>> oop.hpp.
> >>>>>>>>
> >>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or
> >>>>>>>> .cpp
> >>>
> >>> files.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
> >>>>>>>> this is a
> >>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
> >>>>>>>> acceptable.
> >>>>>>>>
> >>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want
> >>>>>>>> to
> >>>
> >>> do
> >>>>>>>>
> >>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
> >>>>>>>> to
> >>>>>>>> freqent changes recently.
> >>>>>>>>
> >>>>>>>> The following methods were moved to .cpp files:
> >>>>>>>>
> >>>>>>>> ProtectionDomainCacheTable::compute_hash()
> >>>>>>>> ProtectionDomainCacheTable::index_for()
> >>>>>>>> typeArrayOopDesc::object_size()
> >>>>>>>> This is called only once outside .cpp file:
> >>>>>>>> CallSiteDepChange::CallSiteDepChange()
> >>>>>>>> This is only called in .cpp file
> >>>>>>>> ConstantPool::string_at_put()
> >>>>>>>>
> >>>>>>>> If someone considers not inlining these harmful to performance,
> >>>>>>>> I will add a new .inline.hpp file for them.
> >>>>>>>>
> >>>>>>>> Please review this change.  I please need a sponsor.
> >>>>>>>> There are no functional edits, so it should be simple to review.
> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >>>>>
> >>>>> rt/webrev.01/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>       Goetz.
> >>>>>>>>
> >

From david.holmes at oracle.com  Mon Jan 11 08:38:11 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Jan 2016 18:38:11 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<56930CB3.5090906@oracle.com>
	<CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
Message-ID: <569369F3.2030900@oracle.com>

On 11/01/2016 5:56 PM, Volker Simonis wrote:
> On Mon, Jan 11, 2016 at 3:00 AM, David Holmes <david.holmes at oracle.com> wrote:
>> On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
>>>
>>> Hi David,
>>>
>>>> I still don't see how adding inline to the declaration changes anything
>>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>>> been included. ???
>>>
>>> Yes, and therefore it issues an error if the keyword is in the .hpp
>>> header:
>>>
>>> In file included from
>>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/utilities/hashtable.cpp:27:0:
>>>
>>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-rt/src/share/vm/classfile/javaClasses.hpp:113:30:
>>> error: inline function 'static typeArrayOopDesc*
>>> java_lang_String::value(oop)' used but never defined [-Werror]
>>>      static inline typeArrayOop value(oop java_string);
>>>
>>> So you can not miss including the inline.hpp header.
>>
>>
>> Won't you get a link time failure in any case ?
>>
>
> With some compilers. But if the method has external linkage the
> compiler usually instantiates a version of the method even if it is
> not called.
>
>>
>> I'm just concerned we are relying on unspecified compiler behaviour which
>> might change in the future. The docs say you don't put "inline" on the
>> declaration. What's to stop the next version of the compiler from flagging
>> that as a warning?
>>
>
> Who did ever ever claime that putting the inline specifier on both,
> definition AND declaration is unspecified compiler behaviour?

That isn't what I meant. The unspecified part is how the compiler 
responds to seeing an inline declaration but not the definition.

> just plain wrong! Please simply read the C++ Standard [1]. It clearly
> states in paragraph 2 of section 9.3: "...An inline member function
> (whether static or non-static) may also be defined outside of its
> class definition provided either its declaration in the class
> definition or its definition outside of the class definition declares
> the function as inline...".

Yes it does - though 7.1.2 also claims "inline" is only valid on a 
declaration. And 9.3 seems at odds with the FAQ referenced as well.

Okay - the main point is that making the declaration inline is legal, so 
no compiler should be rejecting it. Even if it also doesn't provide any 
additional diagnostics.

Thanks for clarifying.

David
-----

> What has been cited here so far (e.g. [2]) is simply an advice (and
> not more!) which shouldn't be confused with the language
> specification! The reason behind the advice to 'place the inline
> specifier on the method definition rather than on its declaration' is
> because the writer deems it an implementation detail. BUT you have to
> take into account that in the HotSpot code base we already have the
> subdivision of header files into "true" .hpp files and .inline.hpp
> files anyway. We've done that because of performance reasons and thus
> already put the burden of deciding which one is required on the user
> anyway. So the argument raised in [2] that the "inlineness" of a
> method is "an implementation detail" doesn't quite hold true for the
> HotSpot code base.
>
> And once again - Goetz's change helps in ensuring that methods which
> are declared inline will be always visible at call sites and thus
> valid inline candidates. If this is not the case we will now (with
> Goetz's change) get a compiler warning where we just silently got a
> plain function call before.
>
> Regards,
> Volker
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> [2] https://isocpp.org/wiki/faq/inline-functions#where-to-put-inline-keyword
>
>> Thanks,
>>
>> David
>>
>>> Best regards,
>>>     Goetz.
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Freitag, 8. Januar 2016 08:54
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
>>>> fix
>>>> header files
>>>>
>>>>
>>>>
>>>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Freitag, 8. Januar 2016 06:07
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>>>> and
>>>>
>>>> fix
>>>>>>
>>>>>> header files
>>>>>>
>>>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> the documentation you point to makes the point that whether to inline
>>>>>>> is an implementation detail, and that that should not be annotated to
>>>>>>> the declaration.  Basically, this is a good point.
>>>>>>>
>>>>>>> But the documentation does not cover the fact that
>>>>>>> we have the implementation in a different file than the declaration.
>>>>>>> The .inline.hpp is not included always (as you pointed out).
>>>>>>>
>>>>>>> Therefore, if we compile with precompiled headers, we get more
>>>>>>> inlines than if we do so without.
>>>>>>> Further, many functions were moved to oop.linline.hpp during the
>>>>>>> recent cleanups, and I think all the #includes I had to add were not
>>>>>>> left out deliberately, but just happened because the compiler did
>>>>>>> not complain.
>>>>>>> I think if somebody decides not to place a function implementation
>>>>>>> in a .cpp file, it should have the chance to be inlined at all it's
>>>>>>> calls.
>>>>>>> Putting the 'inline' into the .hpp file assures this.
>>>>>>
>>>>>>
>>>>>> Sorry I don't follow that. If you include the .inline.hpp you don't
>>>>>> need
>>>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>>>>> have access to the definition so that it can be inlined.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> it seems to me that if
>>>>>> you want it inlined then you must include the .inline.hpp anywhere it
>>>>>> is
>>>>>> needed. Anything else seems a bad-aid.
>>>>>
>>>>> But I think not the caller should decide whether it's to be inlined,
>>>>> but the implementor of the method (and next the compiler).
>>>>> As you describe, the caller has to decide which header to include.
>>>>> So the caller has to know implementation details of the callee,
>>>>> which is contrary to the encapsulation described in that documentation.
>>>>
>>>>
>>>> That's my understanding of the way things are expected to work. This is
>>>> not a public library exporting its interface in a .hpp file, this an
>>>> internal part of the bigger system. As I understand it we define the
>>>> .inline.hpp file precisely so that clients can include it. And yes the
>>>> clients have to know to do that.
>>>>
>>>>> If you add the 'inline' keyword in the header, the compiler enforces
>>>>> that the includes are in a way that it can do what the implementor
>>>>> of the callee / of the method to be inlined intended.
>>>>
>>>>
>>>> I still don't see how adding inline to the declaration changes anything
>>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>>> been included. ???
>>>
>>> Yes, but it issues a warning and  will abort if it's wrong.
>>>
>>>
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>
>>>>>> Maybe
>>>>>> precompiled headers messes with that somehow
>>>>>
>>>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>>>>> is it dragged in by some other .inline.hpp header.
>>>>> I would assume this is a remnant of the problems with this header.
>>>>> But if it was listed there, it would make a difference.
>>>>>
>>>>> To put it the other way round: do you think all the places I had to
>>>>> clean up are well founded decisions not to include the methods
>>>>> from oop.inline.hpp?
>>>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>>>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>>>>> unintuitive to me.
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>>
>>>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>>>>
>>>>> (I'll add the inline keyword in a follow-up change for gc files, in case
>>>>> this change is accepted.)
>>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>> Best regards,
>>>>>>>       Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>>>>
>>>> runtime-
>>>>>>>>
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>>
>>>> and
>>>>>>
>>>>>> fix
>>>>>>>>
>>>>>>>> header files
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in real
>>>>
>>>> .hpp
>>>>>>>>
>>>>>>>> header file.
>>>>>>>>>
>>>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>>>>
>>>>>>>> implementations
>>>>>>>>>
>>>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
>>>>>>>>> Therefore,
>>>>>>
>>>>>> the
>>>>>>>>>
>>>>>>>>> compiler can not detect failing inlines properly.
>>>>>>>>>
>>>>>>>>> This change moves the inline directive from oop.inline.hpp to
>>>>
>>>> oop.hpp.
>>>>>>>>
>>>>>>>> Also
>>>>>>>>
>>>>>>>> This seems contrary to the C++ FAQ:
>>>>>>>>
>>>>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>>>>
>>>>>>>> The declaration in the .hpp should not have inline, only the
>>>>>>>> definition,
>>>>>>>> which in our case is in the .inline.hpp file.
>>>>>>>>
>>>>>>>> Any code that includes the .inline.hpp will have seen the definition
>>>>>>>> of
>>>>>>>> the inline function prior to its use - as long as the includes are
>>>>>>>> correct.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>
>>>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
>>>>>>>>> oop.hpp.
>>>>>>>>>
>>>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or
>>>>>>>>> .cpp
>>>>
>>>> files.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
>>>>>>>>> this is a
>>>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
>>>>>>>>> acceptable.
>>>>>>>>>
>>>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want
>>>>>>>>> to
>>>>
>>>> do
>>>>>>>>>
>>>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
>>>>>>>>> to
>>>>>>>>> freqent changes recently.
>>>>>>>>>
>>>>>>>>> The following methods were moved to .cpp files:
>>>>>>>>>
>>>>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>>>>> typeArrayOopDesc::object_size()
>>>>>>>>> This is called only once outside .cpp file:
>>>>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>>>>> This is only called in .cpp file
>>>>>>>>> ConstantPool::string_at_put()
>>>>>>>>>
>>>>>>>>> If someone considers not inlining these harmful to performance,
>>>>>>>>> I will add a new .inline.hpp file for them.
>>>>>>>>>
>>>>>>>>> Please review this change.  I please need a sponsor.
>>>>>>>>> There are no functional edits, so it should be simple to review.
>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>>>>
>>>>>> rt/webrev.01/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>

From thomas.stuefe at gmail.com  Mon Jan 11 13:39:53 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 11 Jan 2016 14:39:53 +0100
Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack
	on AIX
In-Reply-To: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
References: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
Message-ID: <CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>

Hi all,

could I please have a review?

Thank you!

..Thomas

On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi all,
>
> please review this AIX-only patch.
>
> This ports a more sophisticated native callstack printer for AIX to the
> OpenJDK. It prints out more information and is more robust in cases the
> stack is corrupted.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145184
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/
>
> Note that also some of functions were moved and made more coding-conform
> to the OpenJDK: the old getFuncName() and getModuleName() functions are
> moved to AixSymbols::get_function_name() and AixSymbols::get_module_name().
>
> Thanks and Kind Regards, Thomas
>

From max.ockner at oracle.com  Mon Jan 11 17:02:02 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Mon, 11 Jan 2016 12:02:02 -0500
Subject: RFR: 8146800: Reorganize logging alias code.
Message-ID: <5693E00A.1090001@oracle.com>

Hello all,
Please review my fix which reorganizes the alias table for Unified Logging.

bug: https://bugs.openjdk.java.net/browse/JDK-8146800
webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/

Summary:
How logging aliases used to handled - At the beginning of 
parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would be 
looked up in the logging alias table to see if there was a match. If a 
match was found, then the entire argument would be replaced by a 
corresponding unified logging argument. This argument would then cascade 
through the giant case structure until it was caught and handled close 
to the bottom of parse_each_vm_init_arg (which happens hundreds of lines 
later).

There is a section of code that handles aliases and deprecation for -XX 
options already. After this fix, logging aliases will be handled here 
instead of substituting entire logging expressions at the beginning of 
parse_each_vm_init_arg.

Tested with jtreg runtime tests. This includes several logging tests for 
recently aliased flags.

Thanks,
Max


From coleen.phillimore at oracle.com  Mon Jan 11 18:40:24 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 11 Jan 2016 13:40:24 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <478451fa-2aa5-4f8b-8a53-22b46e0e9781@default>
References: <568EC461.8030209@oracle.com>
	<478451fa-2aa5-4f8b-8a53-22b46e0e9781@default>
Message-ID: <5693F718.7040906@oracle.com>



On 1/9/16 12:05 PM, Markus Gronlund wrote:
> Hi Coleen,
>
> Thanks for bringing this issue to attention, I actually stumbled into issues with this code in some contexts that I worked on last week.

Hi Markus,

Thank you for reading this and your extensive comments.

> I agree that it needs to be reworked, however I think my reasons differ a bit from the reason you put forth, which I believe is not a real problem.
>
> If I understand correctly, you are worried about the context which you describe with:
>
> "Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>
> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>
> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.
> Fortunately, we haven't seen this bug."
>
> Actually I think this is not really a problem - this is because this will not call the copy constructor. Instead, it will call the type conversion constructor:
>
> TempNewSymbol(Symbol* s) : _temp(s) {}
>
> Since this constructor does not increment or decrement the _refcount, you are ok from a GC perspective.

The right hand side of the equal sign will call the conversion operator 
to create a TempNewSymbol and then call the copy constructor to get to 
the left hand side.

Most (all?) compilers elide this copy constructor away, but they don't 
have to.  If you make the copy constructor private, the compilers will 
give you a compilation error.  So logically, it does call the copy 
constructor, but we don't have a bug because it doesn't in real life.

>
> However, there are multiple other ways that TempNewSymbol can mess up the reference counting.
>
> I have summarized my analysis of both existing behavior as well as the suggested fix here:
>
> 814594:
>
> Problem description:http://cr.openjdk.java.net/~mgronlun/8145940/8145940_TempNewSymbol_analysis.txt  
> Webrev suggesting new impl:http://cr.openjdk.java.net/~mgronlun/8145940/webrev01/  
> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
>
> Please let me know what you think.
I think your change is essentially the same except for the self 
assignment and the really good comments.

+ if (this != &rhs && _temp != rhs._temp) {

This seems like a good optimization.  The original intent with 
TempNewSymbol and the Symbol* change was to minimize refcounting as much 
as possible.

I had comments to your analysis but I'll summarize them:


 > Since refcounts are dropped in TempNewSymbol's destructor, this means 
_refcount will be
 > decremented twice, since the second destructor to run will bring 
refcount to -1 (fortunately we
 > have an existing Symbol* _refcount underflow assertion in place to 
guard for this).

Right, but we don't want to hit that assertion!


 > Only concern is why //clear();  //FIXME was not implemented in the 
first place? Maybe this was
 > done because it is unclear what side-effects this fix might be 
causing if existing logic depend on this
 > leaking behavior? However, the right thing to do is to find those 
sites and correct them.

Yes, this was added as a comment but we were unsure if there would be a 
problem without additional
testing.

 > In addition, the clear() member function does not need to NULL out 
the current reference, hence:

Agreed.

So I want you to check in your code instead (reversing the code review) 
but I want to add an ExecuteInternalVMTest for it.

Coleen
> Best regards
> Markus
>
>
> -----Original Message-----
> From: Coleen Phillimore
> Sent: den 7 januari 2016 21:03
> To: hotspot-runtime-dev; Kim Barrett
> Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
>
> Summary: Add clear() to the assignment operator and add copy constructor.
>
> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with
> PrintSymbolTableSizeHistogram statistics:
>
>     Percent removed          1.35
>     Reference counts          194583
>
> clean:
>
>     Percent removed          1.53
>     Reference counts          194245
>
> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>
> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>
> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.
> Fortunately, we haven't seen this bug.
>
> open webrev athttp://cr.openjdk.java.net/~coleenp/8145940/
> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
>
> Thanks,
> Coleen


From markus.gronlund at oracle.com  Mon Jan 11 21:18:10 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 11 Jan 2016 13:18:10 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5693F718.7040906@oracle.com>
References: <568EC461.8030209@oracle.com>
	<478451fa-2aa5-4f8b-8a53-22b46e0e9781@default>
	<5693F718.7040906@oracle.com>
Message-ID: <7f3d84ed-6816-4af0-b5d7-bbe8af4af97e@default>

Hi Coleen,

?

Thanks for the clarification. See comments inline.

?

Best

Markus

?

From: Coleen Phillimore 
Sent: den 11 januari 2016 19:40
To: Markus Gronlund
Cc: hotspot-runtime-dev; Kim Barrett
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

?

?

On 1/9/16 12:05 PM, Markus Gronlund wrote:

Hi Coleen,
?
Thanks for bringing this issue to attention, I actually stumbled into issues with this code in some contexts that I worked on last week.


Hi Markus,

Thank you for reading this and your extensive comments.




?
I agree that it needs to be reworked, however I think my reasons differ a bit from the reason you put forth, which I believe is not a real problem.
?
If I understand correctly, you are worried about the context which you describe with:
?
"Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.? Consider:
?
TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
?
The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.? GC could unlink that symbol from the symbol table.? 
Fortunately, we haven't seen this bug."
?
Actually I think this is not really a problem - this is because this will not call the copy constructor. Instead, it will call the type conversion constructor:
?
TempNewSymbol(Symbol* s) : _temp(s) {}
?
Since this constructor does not increment or decrement the _refcount, you are ok from a GC perspective.


The right hand side of the equal sign will call the conversion operator to create a TempNewSymbol and then call the copy constructor to get to the left hand side.


Most (all?) compilers elide this copy constructor away, but they don't have to.? If you make the copy constructor private, the compilers will give you a compilation error.? So logically, it does call the copy constructor, but we don't have a bug because it doesn't in real life.

?
[MG] Interesting. I?m biased towards the MSFT CL compiler, and it has no problem with me disabling the copy constructor as well.... I guess this is as you say an area where compilers can do what they want?
?
What compilers would not compile because of a missing copy constructor here, do you know? 
?
And those that do, can they run without a copy constructor if instead it is being handed:
?
TempNewSymbol sym(SymbolTable::newsymbol(?abc?) ? that is, it?s the ?equal? sign that directs towards the copy constructor?
?
?
However, there are multiple other ways that TempNewSymbol can mess up the reference counting.
?
I have summarized my analysis of both existing behavior as well as the suggested fix here:
?
814594:
?
Problem description: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8145940/8145940_TempNewSymbol_analysis.txt"http://cr.openjdk.java.net/~mgronlun/8145940/8145940_TempNewSymbol_analysis.txt 
Webrev suggesting new impl: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8145940/webrev01/"http://cr.openjdk.java.net/~mgronlun/8145940/webrev01/ 
bug link https://bugs.openjdk.java.net/browse/JDK-8145940
?
Please let me know what you think.

I think your change is essentially the same except for the self assignment and the really good comments.



[MG] Agree, the reason for the extensive stuff is that I gathered all this info last week when debugging another issue ? I also prepared a patch for this ? when I saw your RFR on the exact same issue I just thought I would send it your way J

?

+??? if (this != &rhs && _temp != rhs._temp) {

This seems like a good optimization.? The original intent with TempNewSymbol and the Symbol* change was to minimize refcounting as much as possible.

I had comments to your analysis but I'll summarize them:


> Since refcounts are dropped in TempNewSymbol's destructor, this means _refcount will be
> decremented twice, since the second destructor to run will bring refcount to -1 (fortunately we
> have an existing Symbol* _refcount underflow assertion in place to guard for this).

Right, but we don't want to hit that assertion!



Absolutely agree.

?



> Only concern is why //clear();? //FIXME was not implemented in the first place? Maybe this was
> done because it is unclear what side-effects this fix might be causing if existing logic depend on this
> leaking behavior? However, the right thing to do is to find those sites and correct them.

Yes, this was added as a comment but we were unsure if there would be a problem without additional
testing.

?

Understand now.



> In addition, the clear() member function does not need to NULL out the current reference, hence:

Agreed.

So I want you to check in your code instead (reversing the code review) but I want to add an ExecuteInternalVMTest for it.



I have no problem with you taking my suggestion and pushing it as well ? maybe you just want to add the ExecuteInternalVMTest and do the putback?

?

Many thanks Coleen

?


Coleen



?
Best regards
Markus
?
?
-----Original Message-----
From: Coleen Phillimore 
Sent: den 7 januari 2016 21:03
To: hotspot-runtime-dev; Kim Barrett
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
?
Summary: Add clear() to the assignment operator and add copy constructor.
?
Ran all jtreg, colocated and non-colocated tests.?? RunThese -jck with 
PrintSymbolTableSizeHistogram statistics:
?
?? Percent removed????????? 1.35
?? Reference counts????????? 194583
?
clean:
?
?? Percent removed????????? 1.53
?? Reference counts????????? 194245
?
Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.? Consider:
?
TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
?
The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.? GC could unlink that symbol from the symbol table.? 
Fortunately, we haven't seen this bug.
?
open webrev at HYPERLINK "http://cr.openjdk.java.net/%7Ecoleenp/8145940/"http://cr.openjdk.java.net/~coleenp/8145940/
bug link https://bugs.openjdk.java.net/browse/JDK-8145940
?
Thanks,
Coleen

?

From coleen.phillimore at oracle.com  Mon Jan 11 22:43:53 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 11 Jan 2016 17:43:53 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <7f3d84ed-6816-4af0-b5d7-bbe8af4af97e@default>
References: <568EC461.8030209@oracle.com>
	<478451fa-2aa5-4f8b-8a53-22b46e0e9781@default>
	<5693F718.7040906@oracle.com>
	<7f3d84ed-6816-4af0-b5d7-bbe8af4af97e@default>
Message-ID: <56943029.8080304@oracle.com>



On 1/11/16 4:18 PM, Markus Gronlund wrote:
>
> Hi Coleen,
>
> Thanks for the clarification. See comments inline.
>
> Best
>
> Markus
>
> *From:*Coleen Phillimore
> *Sent:* den 11 januari 2016 19:40
> *To:* Markus Gronlund
> *Cc:* hotspot-runtime-dev; Kim Barrett
> *Subject:* Re: RFR (xs) 8145940: TempNewSymbol should have correct 
> copy and assignment functions
>
> On 1/9/16 12:05 PM, Markus Gronlund wrote:
>
>     Hi Coleen,
>
>     Thanks for bringing this issue to attention, I actually stumbled into issues with this code in some contexts that I worked on last week.
>
>
> Hi Markus,
>
> Thank you for reading this and your extensive comments.
>
>
> I agree that it needs to be reworked, however I think my reasons differ a bit from the reason you put forth, which I believe is not a real problem.
> If I understand correctly, you are worried about the context which you describe with:
> "Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.
> Fortunately, we haven't seen this bug."
> Actually I think this is not really a problem - this is because this will not call the copy constructor. Instead, it will call the type conversion constructor:
> TempNewSymbol(Symbol* s) : _temp(s) {}
> Since this constructor does not increment or decrement the _refcount, you are ok from a GC perspective.
>
>
> The right hand side of the equal sign will call the conversion 
> operator to create a TempNewSymbol and then call the copy constructor 
> to get to the left hand side.
>
>
> Most (all?) compilers elide this copy constructor away, but they don't 
> have to.  If you make the copy constructor private, the compilers will 
> give you a compilation error. So logically, it does call the copy 
> constructor, but we don't have a bug because it doesn't in real life.
>
> [MG] Interesting. I?m biased towards the MSFT CL compiler, and it has 
> no problem with me disabling the copy constructor as well.... I guess 
> this is as you say an area where compilers can do what they want?
> What compilers would not compile because of a missing copy constructor 
> here, do you know?

Sorry, I meant if I made the copy constructor private, I got a 
compilation error.  It doesn't have to call it though.
> And those that do, can they run without a copy constructor if instead 
> it is being handed:
> TempNewSymbol sym(SymbolTable::newsymbol(?abc?) ? that is, it?s the 
> ?equal? sign that directs towards the copy constructor?

Yes.   This form does not call the copy constructor.    But since 
SymbolTable::new_symbol("abc", CHECK) takes a TRAPS argument, you can't 
specify it this way because of the CHECK expansion.

> However, there are multiple other ways that TempNewSymbol can mess up 
> the reference counting.
> I have summarized my analysis of both existing behavior as well as the suggested fix here:
> 814594:
> Problem description:http://cr.openjdk.java.net/~mgronlun/8145940/8145940_TempNewSymbol_analysis.txt 
> <http://cr.openjdk.java.net/%7Emgronlun/8145940/8145940_TempNewSymbol_analysis.txt>  
> Webrev suggesting new impl:http://cr.openjdk.java.net/~mgronlun/8145940/webrev01/ 
> <http://cr.openjdk.java.net/%7Emgronlun/8145940/webrev01/>  
> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
> Please let me know what you think.
>
> I think your change is essentially the same except for the self 
> assignment and the really good comments.
>
> [MG] Agree, the reason for the extensive stuff is that I gathered all 
> this info last week when debugging another issue ? I also prepared a 
> patch for this ? when I saw your RFR on the exact same issue I just 
> thought I would send it your way J
>
> +    if (this != &rhs && _temp != rhs._temp) {
>
> This seems like a good optimization.  The original intent with 
> TempNewSymbol and the Symbol* change was to minimize refcounting as 
> much as possible.
>
> I had comments to your analysis but I'll summarize them:
>
>
> > Since refcounts are dropped in TempNewSymbol's destructor, this 
> means _refcount will be
> > decremented twice, since the second destructor to run will bring 
> refcount to -1 (fortunately we
> > have an existing Symbol* _refcount underflow assertion in place to 
> guard for this).
>
> Right, but we don't want to hit that assertion!
>
> Absolutely agree.
>
>
>
> > Only concern is why //clear();  //FIXME was not implemented in the 
> first place? Maybe this was
> > done because it is unclear what side-effects this fix might be 
> causing if existing logic depend on this
> > leaking behavior? However, the right thing to do is to find those 
> sites and correct them.
>
> Yes, this was added as a comment but we were unsure if there would be 
> a problem without additional
> testing.
>
> Understand now.
>
>
>
> > In addition, the clear() member function does not need to NULL out 
> the current reference, hence:
>
> Agreed.
>
> So I want you to check in your code instead (reversing the code 
> review) but I want to add an ExecuteInternalVMTest for it.
>
> I have no problem with you taking my suggestion and pushing it as well 
> ? maybe you just want to add the ExecuteInternalVMTest and do the putback?
>

Okay, I'll patch in your change instead of mine and resend it with my 
ExecuteInternalVMTest.

Thanks!
Coleen
>
> Many thanks Coleen
>
>
> Coleen
>
> Best regards
> Markus
> -----Original Message-----
> From: Coleen Phillimore
> Sent: den 7 januari 2016 21:03
> To: hotspot-runtime-dev; Kim Barrett
> Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
> Summary: Add clear() to the assignment operator and add copy constructor.
> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with
> PrintSymbolTableSizeHistogram statistics:
>     Percent removed          1.35
>     Reference counts          194583
> clean:
>     Percent removed          1.53
>     Reference counts          194245
> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.
> Fortunately, we haven't seen this bug.
> open webrev athttp://cr.openjdk.java.net/~coleenp/8145940/ 
> <http://cr.openjdk.java.net/%7Ecoleenp/8145940/>
> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
> Thanks,
> Coleen
>


From kim.barrett at oracle.com  Mon Jan 11 23:45:59 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 11 Jan 2016 18:45:59 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <568EC461.8030209@oracle.com>
References: <568EC461.8030209@oracle.com>
Message-ID: <C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>

On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> Summary: Add clear() to the assignment operator and add copy constructor.
> 
> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
> 
>  Percent removed          1.35
>  Reference counts          194583
> 
> clean:
> 
>  Percent removed          1.53
>  Reference counts          194245
> 
> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
> 
> TempNewSymbol ts = SymbolTable::new_symbol("abc");
> // Hit GC
> 
> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
> 
> Thanks,
> Coleen

For the assignment operator, I think better is:

void operator=(TempNewSymbol s) {
  Symbol* tmp = s._temp;
  s._temp = _temp;
  _temp = tmp;
}

This is the well-known copy and swap idiom, with a by-hand "swap".

http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom

In the copy constructor, as a matter of style I would initialize _temp
in the initialer list, rather than by assignment in the body.

I think the updated description of TempNewSymbol isn't really right.
Because the conversion constructor doesn't increment the reference
count, it must *not* be used to capture some arbitrary reference to a
Symbol*. Only a new symbol or one obtained from one of the lookup
functions really should be managed by this class.

Regarding copy elision, there's a good discussion here:

http://en.cppreference.com/w/cpp/language/copy_elision


From lois.foltan at oracle.com  Tue Jan 12 00:51:30 2016
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 11 Jan 2016 19:51:30 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
Message-ID: <56944E12.4080906@oracle.com>


On 1/11/2016 6:45 PM, Kim Barrett wrote:
> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore<coleen.phillimore at oracle.com>  wrote:
>> Summary: Add clear() to the assignment operator and add copy constructor.
>>
>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>
>>   Percent removed          1.35
>>   Reference counts          194583
>>
>> clean:
>>
>>   Percent removed          1.53
>>   Reference counts          194245
>>
>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>
>> TempNewSymbol ts = SymbolTable::new_symbol("abc");
>> // Hit GC
>>
>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>
>> open webrev athttp://cr.openjdk.java.net/~coleenp/8145940/
>> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
>>
>> Thanks,
>> Coleen
> For the assignment operator, I think better is:
>
> void operator=(TempNewSymbol s) {
>    Symbol* tmp = s._temp;
>    s._temp = _temp;
>    _temp = tmp;
> }
>
> This is the well-known copy and swap idiom, with a by-hand "swap".

Kim,
I'm a bit confused, why would the assignment operator want to swap? I 
don't think s._temp should be assigned _temp's value.

> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom
>
> In the copy constructor, as a matter of style I would initialize _temp
> in the initialer list, rather than by assignment in the body.
>
> I think the updated description of TempNewSymbol isn't really right.
> Because the conversion constructor doesn't increment the reference
> count, it must *not* be used to capture some arbitrary reference to a
> Symbol*. Only a new symbol or one obtained from one of the lookup
> functions really should be managed by this class.

I agree with this point, can we improve the comment ahead of 
TempNewSymbol's class definition as part of this webrev?
Thanks,
Lois

> Regarding copy elision, there's a good discussion here:
>
> http://en.cppreference.com/w/cpp/language/copy_elision
>


From david.holmes at oracle.com  Tue Jan 12 00:52:16 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jan 2016 10:52:16 +1000
Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack
	on AIX
In-Reply-To: <CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
References: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
	<CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
Message-ID: <56944E40.1070606@oracle.com>

Hi Thomas,

On 11/01/2016 11:39 PM, Thomas St?fe wrote:
> Hi all,
>
> could I please have a review?

Are you waiting for another AIX person to review, or a runtime team 
member to rubber stamp?

David

> Thank you!
>
> ..Thomas
>
> On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi all,
>>
>> please review this AIX-only patch.
>>
>> This ports a more sophisticated native callstack printer for AIX to the
>> OpenJDK. It prints out more information and is more robust in cases the
>> stack is corrupted.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145184
>> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/
>>
>> Note that also some of functions were moved and made more coding-conform
>> to the OpenJDK: the old getFuncName() and getModuleName() functions are
>> moved to AixSymbols::get_function_name() and AixSymbols::get_module_name().
>>
>> Thanks and Kind Regards, Thomas
>>

From lois.foltan at oracle.com  Tue Jan 12 01:27:07 2016
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 11 Jan 2016 20:27:07 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <56944E12.4080906@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<56944E12.4080906@oracle.com>
Message-ID: <5694566B.7000409@oracle.com>


On 1/11/2016 7:51 PM, Lois Foltan wrote:
>
> On 1/11/2016 6:45 PM, Kim Barrett wrote:
>> On Jan 7, 2016, at 3:02 PM, Coleen 
>> Phillimore<coleen.phillimore at oracle.com>  wrote:
>>> Summary: Add clear() to the assignment operator and add copy 
>>> constructor.
>>>
>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck 
>>> with PrintSymbolTableSizeHistogram statistics:
>>>
>>>   Percent removed          1.35
>>>   Reference counts          194583
>>>
>>> clean:
>>>
>>>   Percent removed          1.53
>>>   Reference counts          194245
>>>
>>> Without a reference counting copy constructor, we could remove a 
>>> TempNewSymbol's Symbol if a GC happens.  Consider:
>>>
>>> TempNewSymbol ts = SymbolTable::new_symbol("abc");
>>> // Hit GC
>>>
>>> The ref count for "abc" is 1 when created by new_symbol, and the 
>>> destructor could run after the copy into ts, decrementing the 
>>> reference count to 0 again.  GC could unlink that symbol from the 
>>> symbol table.  Fortunately, we haven't seen this bug.
>>>
>>> open webrev athttp://cr.openjdk.java.net/~coleenp/8145940/
>>> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8145940
>>>
>>> Thanks,
>>> Coleen
>> For the assignment operator, I think better is:
>>
>> void operator=(TempNewSymbol s) {
>>    Symbol* tmp = s._temp;
>>    s._temp = _temp;
>>    _temp = tmp;
>> }
>>
>> This is the well-known copy and swap idiom, with a by-hand "swap".
>
> Kim,
> I'm a bit confused, why would the assignment operator want to swap? I 
> don't think s._temp should be assigned _temp's value.

After some more thought on this, I would like to add I think you are 
doing the assignment into s._temp of the former value of _temp to get 
the destructor to run on the temporary that is created for the pass by 
value parameter s.  And thus if the destructor is run, the refcount is 
decremented of _temp's former value.  I find this way too subtle, and 
would prefer to actually see the assignment operator do the clear().
Lois

>
>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom 
>>
>>
>> In the copy constructor, as a matter of style I would initialize _temp
>> in the initialer list, rather than by assignment in the body.
>>
>> I think the updated description of TempNewSymbol isn't really right.
>> Because the conversion constructor doesn't increment the reference
>> count, it must *not* be used to capture some arbitrary reference to a
>> Symbol*. Only a new symbol or one obtained from one of the lookup
>> functions really should be managed by this class.
>
> I agree with this point, can we improve the comment ahead of 
> TempNewSymbol's class definition as part of this webrev?
> Thanks,
> Lois
>
>> Regarding copy elision, there's a good discussion here:
>>
>> http://en.cppreference.com/w/cpp/language/copy_elision
>>
>


From coleen.phillimore at oracle.com  Tue Jan 12 01:34:18 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 11 Jan 2016 20:34:18 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
Message-ID: <5694581A.804@oracle.com>


Kim and Lois,

Thanks for looking at this.   This is my latest webrev with the 
ExecuteInternalVMTest in it:

http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html

See comments below.

On 1/11/16 6:45 PM, Kim Barrett wrote:
> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> Summary: Add clear() to the assignment operator and add copy constructor.
>>
>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>
>>   Percent removed          1.35
>>   Reference counts          194583
>>
>> clean:
>>
>>   Percent removed          1.53
>>   Reference counts          194245
>>
>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>
>> TempNewSymbol ts = SymbolTable::new_symbol("abc");
>> // Hit GC
>>
>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>
>> Thanks,
>> Coleen
> For the assignment operator, I think better is:
>
> void operator=(TempNewSymbol s) {
>    Symbol* tmp = s._temp;
>    s._temp = _temp;
>    _temp = tmp;
> }
>
> This is the well-known copy and swap idiom, with a by-hand "swap".
>
> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom

Very tricky.  Lois and I figured out the trick.  It doesn't elide any 
Atomic::* reference counting though, which is what is worrysome for 
performance, just hides it in the destructor of 's'.  I don't want to 
change this.
> In the copy constructor, as a matter of style I would initialize _temp
> in the initialer list, rather than by assignment in the body.

Fixed.

> I think the updated description of TempNewSymbol isn't really right.
> Because the conversion constructor doesn't increment the reference
> count, it must *not* be used to capture some arbitrary reference to a
> Symbol*. Only a new symbol or one obtained from one of the lookup
> functions really should be managed by this class.

Yes, this is a subtlety of the design and one that I can't really fix 
right now.  I thought of changing TempNewSymbol to convert from const 
char * but there are cases where we don't want to add a symbol.

There is a comment above TempNewSymbol.  I don't know what to add to 
it.   And Markus's comments are really good.

Thanks,
Coleen
> Regarding copy elision, there's a good discussion here:
>
> http://en.cppreference.com/w/cpp/language/copy_elision
>


From david.holmes at oracle.com  Tue Jan 12 03:16:52 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jan 2016 13:16:52 +1000
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
Message-ID: <56947024.3040002@oracle.com>

Bug is non-public:

https://bugs.openjdk.java.net/browse/JDK-8077648

In globalDefinitions_gcc.hpp we do

#ifdef ARM32
#ifdef SOLARIS
#define BREAKPOINT __asm__ volatile (".long 0xe1200070")
#else
#define BREAKPOINT __asm__ volatile (".long 0xe7f001f0")
#endif
#else

The SOLARIS part of this is puzzling to say the least and is being 
deleted. :)

Otherwise the value used in not correct if compiling for Thumb 
instruction set.

Solution is to just use:

#define BREAKPOINT __asm__ volatile ("bkpt")

webrev: http://cr.openjdk.java.net/~dholmes/8077648/webrev/

Thanks,
David

From kim.barrett at oracle.com  Tue Jan 12 04:22:22 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 11 Jan 2016 23:22:22 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5694581A.804@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
Message-ID: <A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>

On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Kim and Lois,
> 
> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
> 
> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
> 
> See comments below.
> 
> On 1/11/16 6:45 PM, Kim Barrett wrote:
>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>> 
>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>> 
>>>  Percent removed          1.35
>>>  Reference counts          194583
>>> 
>>> clean:
>>> 
>>>  Percent removed          1.53
>>>  Reference counts          194245
>>> 
>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>> 
>>> TempNewSymbol ts = SymbolTable::new_symbol("abc");
>>> // Hit GC
>>> 
>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>> 
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>> 
>>> Thanks,
>>> Coleen
>> For the assignment operator, I think better is:
>> 
>> void operator=(TempNewSymbol s) {
>>   Symbol* tmp = s._temp;
>>   s._temp = _temp;
>>   _temp = tmp;
>> }
>> 
>> This is the well-known copy and swap idiom, with a by-hand "swap".
>> 
>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom
> 
> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.

Copy-swap saves several refcount manipulations in some (common) cases,
by taking advantage of rvalue copy elision.

Coleen's:

void operator=(const TempNewSymbol& s) {
  clear();
  _temp = s._temp;
  if (_temp != NULL) _temp->increment_refcount();
}

Markus's:

const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
  if (this != &rhs && _temp != rhs._temp) {
    clear();
    _temp = rhs._temp;
    if (_temp != NULL) {
      _temp->increment_refcount();
    }
  }
  return *this;
}

Kim's:

void operator=(TempNewSymbol rhs) {
  Symbol* tmp = rhs._temp;
  rhs._temp = _temp;
  _temp = tmp;
}

[I'm ignoring differences in the return value in the discussion below.
I think it ought to be either "TempNewSymbol&" (not const) or void.]

Markus's is mostly the same as Coleen's, except it handles a couple of
special cases differently.

Markus's handles self-assignment, where Coleen's doesn't. For
correctness that's important; in actual practice self-assignment is
generally rare to non-existent, so always paying overhead for it is
unpleasant.

Markus's also specially handles re-assignment to the same symbol,
avoiding any refcount changes in that case.  I suggest this is another
rare case, and adding overhead in the normal case to get that rare
benefit is not the right tradeoff.

Assuming we're not in one of those special cases and neither Symbol*
is NULL, Coleen/Markus decrements the old and increments the new. And
in an important special case where rhs is an rvalue, there will be
another decrement as the temporary goes out of scope. So two refcount
changes when rhs is an lvalue, three when it's an rvalue.

In contrast, Kim's does an increment and a decrement when rhs is an
lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy
elision is performed by the compiler, which any decent optimizing
compiler will do.

The rhs is an rvalue in the following situation:

  TempNewSymbol tns = ... ;
  ...
  tns = expr_returning_Symbol* ;

The rhs gets implicitly converted to a temporary (rvalue)
TempNewSymbol referring to the symbol (no refcount change), that
temporary is directly bound to the assignment argument (copy elided),
swap the symbols, and the rvalue converted temp goes out of scope and
decrements the refcount of the old Symbol*.

The copy-swap version also handles the (rare) self-assignment and
re-assignment to the same symbol cases. In these cases Kim's still
does the same refcounting changes as otherwise.  But it's better to do
extra work in the rare cases and keep the normal cases fast.

This is why copy-swap has become the "usual idiom"for assignment
operators. There might be cases where it's not the best answer, but
usually it is. And this is why (to answer Lois's issue) one should use
it even though it's not obvious if one is not previously familiar with
the idiom; one should instead learn the idiom, and then one spends
time looking hard at implementations that do something else.

Of course, this may all be entirely in the noise; I hope that
TempNewSymbol assignment is not a high frequency operation.


>> I think the updated description of TempNewSymbol isn't really right.
>> Because the conversion constructor doesn't increment the reference
>> count, it must *not* be used to capture some arbitrary reference to a
>> Symbol*. Only a new symbol or one obtained from one of the lookup
>> functions really should be managed by this class.
> 
> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
> 
> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.

I was confused about which webrev I was looking at.  Coleen?s doesn?t seem to change those comments.
It was (parts of) Markus?s comments that worried me.  And the whole design is tricky and risky.


From dean.long at oracle.com  Tue Jan 12 05:31:37 2016
From: dean.long at oracle.com (Dean Long)
Date: Mon, 11 Jan 2016 21:31:37 -0800
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <56947024.3040002@oracle.com>
References: <56947024.3040002@oracle.com>
Message-ID: <56948FB9.3050807@oracle.com>

How about moving it to "globalDefinitions_arm.hpp"?  You would just need 
to do #undef BREAKPOINT first.

dl

On 1/11/2016 7:16 PM, David Holmes wrote:
> Bug is non-public:
>
> https://bugs.openjdk.java.net/browse/JDK-8077648
>
> In globalDefinitions_gcc.hpp we do
>
> #ifdef ARM32
> #ifdef SOLARIS
> #define BREAKPOINT __asm__ volatile (".long 0xe1200070")
> #else
> #define BREAKPOINT __asm__ volatile (".long 0xe7f001f0")
> #endif
> #else
>
> The SOLARIS part of this is puzzling to say the least and is being 
> deleted. :)
>
> Otherwise the value used in not correct if compiling for Thumb 
> instruction set.
>
> Solution is to just use:
>
> #define BREAKPOINT __asm__ volatile ("bkpt")
>
> webrev: http://cr.openjdk.java.net/~dholmes/8077648/webrev/
>
> Thanks,
> David


From david.holmes at oracle.com  Tue Jan 12 05:46:54 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jan 2016 15:46:54 +1000
Subject: (S) RFR: 8146855: Update hotspot sources to recognize Solaris Studio
	12u4 compiler
Message-ID: <5694934E.9030602@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8146855
webrev: http://cr.openjdk.java.net/~dholmes/8146855/webrev/

Need to update ENFORCE_CC_COMPILER_REV in sparcWorks.make

Need to update HOTSPOT_BUILD_COMPILER logic in vm_version.cpp

Thanks,
David
-----



From david.holmes at oracle.com  Tue Jan 12 05:56:34 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jan 2016 15:56:34 +1000
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <56948FB9.3050807@oracle.com>
References: <56947024.3040002@oracle.com> <56948FB9.3050807@oracle.com>
Message-ID: <56949592.6040107@oracle.com>

On 12/01/2016 3:31 PM, Dean Long wrote:
> How about moving it to "globalDefinitions_arm.hpp"?  You would just need
> to do #undef BREAKPOINT first.

It would also need, technically, to be conditional upon using gcc.

I also don't know if the aarch32 port would be using this. ??

Thanks,
David

> dl
>
> On 1/11/2016 7:16 PM, David Holmes wrote:
>> Bug is non-public:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8077648
>>
>> In globalDefinitions_gcc.hpp we do
>>
>> #ifdef ARM32
>> #ifdef SOLARIS
>> #define BREAKPOINT __asm__ volatile (".long 0xe1200070")
>> #else
>> #define BREAKPOINT __asm__ volatile (".long 0xe7f001f0")
>> #endif
>> #else
>>
>> The SOLARIS part of this is puzzling to say the least and is being
>> deleted. :)
>>
>> Otherwise the value used in not correct if compiling for Thumb
>> instruction set.
>>
>> Solution is to just use:
>>
>> #define BREAKPOINT __asm__ volatile ("bkpt")
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8077648/webrev/
>>
>> Thanks,
>> David
>

From david.holmes at oracle.com  Tue Jan 12 06:31:09 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 12 Jan 2016 16:31:09 +1000
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <5693E00A.1090001@oracle.com>
References: <5693E00A.1090001@oracle.com>
Message-ID: <56949DAD.5060606@oracle.com>

Hi Max,

On 12/01/2016 3:02 AM, Max Ockner wrote:
> Hello all,
> Please review my fix which reorganizes the alias table for Unified Logging.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/

Is this supposed to contain the VAR_LOG_TAGS changes?

Is the "deprecation" of the converted tracing flags still to be added?

Otherwise seems okay.

Thanks,
David

> Summary:
> How logging aliases used to handled - At the beginning of
> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would be
> looked up in the logging alias table to see if there was a match. If a
> match was found, then the entire argument would be replaced by a
> corresponding unified logging argument. This argument would then cascade
> through the giant case structure until it was caught and handled close
> to the bottom of parse_each_vm_init_arg (which happens hundreds of lines
> later).
>
> There is a section of code that handles aliases and deprecation for -XX
> options already. After this fix, logging aliases will be handled here
> instead of substituting entire logging expressions at the beginning of
> parse_each_vm_init_arg.
>
> Tested with jtreg runtime tests. This includes several logging tests for
> recently aliased flags.
>
> Thanks,
> Max
>

From thomas.stuefe at gmail.com  Tue Jan 12 06:48:27 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 12 Jan 2016 07:48:27 +0100
Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack
	on AIX
In-Reply-To: <56944E40.1070606@oracle.com>
References: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
	<CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
	<56944E40.1070606@oracle.com>
Message-ID: <CAA-vtUwJR6abp0VBDrDR7Y-9Nrq1CVb3DyVTj-hCUtRgg_2j_w@mail.gmail.com>

Hi David,

I would prefer a real review. I'll ask Goetz later, maybe he is in the
mood.

Thanks, Thomas
On Jan 12, 2016 01:53, "David Holmes" <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 11/01/2016 11:39 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> could I please have a review?
>>
>
> Are you waiting for another AIX person to review, or a runtime team member
> to rubber stamp?
>
> David
>
> Thank you!
>>
>> ..Thomas
>>
>> On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>
>> Hi all,
>>>
>>> please review this AIX-only patch.
>>>
>>> This ports a more sophisticated native callstack printer for AIX to the
>>> OpenJDK. It prints out more information and is more robust in cases the
>>> stack is corrupted.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145184
>>> webrev:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.00/webrev/
>>>
>>> Note that also some of functions were moved and made more coding-conform
>>> to the OpenJDK: the old getFuncName() and getModuleName() functions are
>>> moved to AixSymbols::get_function_name() and
>>> AixSymbols::get_module_name().
>>>
>>> Thanks and Kind Regards, Thomas
>>>
>>>

From ivan.gerasimov at oracle.com  Tue Jan 12 06:55:20 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 12 Jan 2016 09:55:20 +0300
Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...
In-Reply-To: <568C973E.6030404@oracle.com>
References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com>
	<567000F9.2070603@oracle.com> <56700279.4000408@oracle.com>
	<56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com>
	<567270F6.7030206@oracle.com> <567390D4.10307@oracle.com>
	<56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com>
	<567A9183.1000900@oracle.com> <568BFE80.9040000@oracle.com>
	<568C973E.6030404@oracle.com>
Message-ID: <5694A358.9020705@oracle.com>

Thanks David and Daniel!

Yes, as David wrote, a thread-id is 32-bit on Windows.

I'll do all the suggested changes and will push the fix later today.

Sincerely yours,
Ivan

On 06.01.2016 7:25, David Holmes wrote:
> On 6/01/2016 3:33 AM, Daniel D. Daugherty wrote:
>> Happy New Year!
>
> And to you :)
>
>>
>>  > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/
>>
>> src/os/windows/vm/os_windows.cpp
>>      L3923:         Atomic::cmpxchg((jint)GetCurrentThreadId(),
>> &process_exiting, 0);
>>          What's the return size of GetCurrentThreadId()? Are we
>
> It is a DWORD so 32-bit.
>
> Cheers,
> David
> -----
>
>>          down casting a larger size into a 'jint'? If so, that
>>          might allow more than one thread into this code when we
>>          only want one...
>>
>>          Also please consider adding a comment above this line.
>>          Perhaps something like:
>>
>>          // Atomically set process_exiting before the critical section
>>          // to increase the visibility between racing threads.
>>
>>      L3998:             if (portion_count > MAXIMUM_WAIT_OBJECTS) {
>>      L3999:                 portion_count = MAXIMUM_WAIT_OBJECTS;
>>          Wrong indent; should be two spaces relative to L3998.
>>
>>      L4013:               portion_count = handle_count - i;
>>          Please consider adding a comment for this error case.
>>          Perhaps something like:
>>          // Reset portion_count so we close the remaining
>>          // handles due to this error.
>>
>>      L4030:     if (OrderAccess::load_acquire(&process_exiting) != 0 &&
>>      L4031:         process_exiting != (jint)GetCurrentThreadId()) {
>>      L4032:       while (true) {
>>      L4033:         // Some other thread is about to call exit(), so we
>>      L4034:         // don't let the current thread proceed to exit() or
>> _endthreadex()
>>          The comment on L4033-4 is slightly misplaced now. It
>>          should be between L4031 and L4032.
>>
>>
>> Thumbs up modulo the GetCurrentThreadId() return size question
>> above. If that size is OK and you choose to make the comment
>> changes, I don't need to see another webrev.
>>
>> Dan
>>
>>
>> On 12/23/15 5:20 AM, Ivan Gerasimov wrote:
>>> Thank you David for review!
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 23.12.2015 7:41, David Holmes wrote:
>>>> Looks okay.
>>>>
>>>> Second review needed though.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 19/12/2015 10:28 PM, Ivan Gerasimov wrote:
>>>>>
>>>>>
>>>>>>> We will suspend the current thread if two conditions are satisfied:
>>>>>>> process_exiting != 0 and process_exiting != current thread id.
>>>>>>> But, yes, pr_ex isn't really needed, as we can use process_exiting
>>>>>>> directly.
>>>>>>>
>>>>>>> Here's the updated webrev:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/
>>>>>>
>>>>>> I still see pr_ex ??
>>>>>>
>>>>>
>>>>> Oops.
>>>>> Forgot to 'hg qrefresh' before generating the webrev.
>>>>> The webrev has just been updated in place.
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>
>>>
>>
>


From marcus.larsson at oracle.com  Tue Jan 12 09:43:06 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 12 Jan 2016 10:43:06 +0100
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <5693E00A.1090001@oracle.com>
References: <5693E00A.1090001@oracle.com>
Message-ID: <5694CAAA.5060807@oracle.com>

Hi Max,

On 01/11/2016 06:02 PM, Max Ockner wrote:
> Hello all,
> Please review my fix which reorganizes the alias table for Unified 
> Logging.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/
>

I just realized that instead of using additional macros you could call 
configure_stdout with a terminating __NO_TAG. For example:

LogConfiguration::configure_stdout(alf.level, alf.exactMatch, alf.tag, 
LogTag::__NO_TAG)

This works because configure_stdout looks at up to 5 (MaxTags) tags, but 
stops looking as soon as it finds a __NO_TAG.

Thanks,
Marcus

> Summary:
> How logging aliases used to handled - At the beginning of 
> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would 
> be looked up in the logging alias table to see if there was a match. 
> If a match was found, then the entire argument would be replaced by a 
> corresponding unified logging argument. This argument would then 
> cascade through the giant case structure until it was caught and 
> handled close to the bottom of parse_each_vm_init_arg (which happens 
> hundreds of lines later).
>
> There is a section of code that handles aliases and deprecation for 
> -XX options already. After this fix, logging aliases will be handled 
> here instead of substituting entire logging expressions at the 
> beginning of parse_each_vm_init_arg.
>
> Tested with jtreg runtime tests. This includes several logging tests 
> for recently aliased flags.
>
> Thanks,
> Max
>


From edward.nevill at gmail.com  Tue Jan 12 10:03:50 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Tue, 12 Jan 2016 10:03:50 +0000
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <56949592.6040107@oracle.com>
References: <56947024.3040002@oracle.com> <56948FB9.3050807@oracle.com>
	<56949592.6040107@oracle.com>
Message-ID: <1452593030.28862.11.camel@mylittlepony.linaroharston>

On Tue, 2016-01-12 at 15:56 +1000, David Holmes wrote:
> On 12/01/2016 3:31 PM, Dean Long wrote:
> > How about moving it to "globalDefinitions_arm.hpp"?  You would just need
> > to do #undef BREAKPOINT first.
> 
> It would also need, technically, to be conditional upon using gcc.
> 
> I also don't know if the aarch32 port would be using this. ??

cc: aarch32-port-dev

The aarch32 currently does not define 'ARM32' so this code is not being included in the current port.

The aarch32 port does define 'ARM' so any code that is #ifdef ARM is included in the aarch32 port.

So, moving this code to globalDefinitions_arm.hpp will have no impact on the aarch32 port.

All the best,
Ed.



From markus.gronlund at oracle.com  Tue Jan 12 12:34:42 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Tue, 12 Jan 2016 04:34:42 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
Message-ID: <2d5a4044-9851-454d-83c9-73cbb9b22552@default>

Hi Kim,

Thanks a lot for the (detailed) reminder about the copy-and-swap idiom. I agree with your reasoning.

About the return value from operator=, I would suggest retaining the void as-is as well.

Maybe we should investigate if it is possible to have the functions in SymbolTable that increment Symbol*'s return a TempNewSymbol( or some other "smartptr" concept) instead of a direct Symbol*?

In that case we could make the type conversion constructor private and make SymbolTable a friend of TempNewSymbol - this would avoid accidental wrapping of arbitrary Symbol*'s. I will look into the possibility of this.

Thanks again for your clarification
Markus

-----Original Message-----
From: Kim Barrett 
Sent: den 12 januari 2016 05:22
To: Coleen Phillimore
Cc: hotspot-runtime-dev
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Kim and Lois,
> 
> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
> 
> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
> 
> See comments below.
> 
> On 1/11/16 6:45 PM, Kim Barrett wrote:
>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>> 
>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>> 
>>>  Percent removed          1.35
>>>  Reference counts          194583
>>> 
>>> clean:
>>> 
>>>  Percent removed          1.53
>>>  Reference counts          194245
>>> 
>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>> 
>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>> 
>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>> 
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>> 
>>> Thanks,
>>> Coleen
>> For the assignment operator, I think better is:
>> 
>> void operator=(TempNewSymbol s) {
>>   Symbol* tmp = s._temp;
>>   s._temp = _temp;
>>   _temp = tmp;
>> }
>> 
>> This is the well-known copy and swap idiom, with a by-hand "swap".
>> 
>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-
>> idiom
> 
> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.

Copy-swap saves several refcount manipulations in some (common) cases, by taking advantage of rvalue copy elision.

Coleen's:

void operator=(const TempNewSymbol& s) {
  clear();
  _temp = s._temp;
  if (_temp != NULL) _temp->increment_refcount(); }

Markus's:

const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
  if (this != &rhs && _temp != rhs._temp) {
    clear();
    _temp = rhs._temp;
    if (_temp != NULL) {
      _temp->increment_refcount();
    }
  }
  return *this;
}

Kim's:

void operator=(TempNewSymbol rhs) {
  Symbol* tmp = rhs._temp;
  rhs._temp = _temp;
  _temp = tmp;
}

[I'm ignoring differences in the return value in the discussion below.
I think it ought to be either "TempNewSymbol&" (not const) or void.]

Markus's is mostly the same as Coleen's, except it handles a couple of special cases differently.

Markus's handles self-assignment, where Coleen's doesn't. For correctness that's important; in actual practice self-assignment is generally rare to non-existent, so always paying overhead for it is unpleasant.

Markus's also specially handles re-assignment to the same symbol, avoiding any refcount changes in that case.  I suggest this is another rare case, and adding overhead in the normal case to get that rare benefit is not the right tradeoff.

Assuming we're not in one of those special cases and neither Symbol* is NULL, Coleen/Markus decrements the old and increments the new. And in an important special case where rhs is an rvalue, there will be another decrement as the temporary goes out of scope. So two refcount changes when rhs is an lvalue, three when it's an rvalue.

In contrast, Kim's does an increment and a decrement when rhs is an lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy elision is performed by the compiler, which any decent optimizing compiler will do.

The rhs is an rvalue in the following situation:

  TempNewSymbol tns = ... ;
  ...
  tns = expr_returning_Symbol* ;

The rhs gets implicitly converted to a temporary (rvalue) TempNewSymbol referring to the symbol (no refcount change), that temporary is directly bound to the assignment argument (copy elided), swap the symbols, and the rvalue converted temp goes out of scope and decrements the refcount of the old Symbol*.

The copy-swap version also handles the (rare) self-assignment and re-assignment to the same symbol cases. In these cases Kim's still does the same refcounting changes as otherwise.  But it's better to do extra work in the rare cases and keep the normal cases fast.

This is why copy-swap has become the "usual idiom"for assignment operators. There might be cases where it's not the best answer, but usually it is. And this is why (to answer Lois's issue) one should use it even though it's not obvious if one is not previously familiar with the idiom; one should instead learn the idiom, and then one spends time looking hard at implementations that do something else.

Of course, this may all be entirely in the noise; I hope that TempNewSymbol assignment is not a high frequency operation.


>> I think the updated description of TempNewSymbol isn't really right.
>> Because the conversion constructor doesn't increment the reference 
>> count, it must *not* be used to capture some arbitrary reference to a 
>> Symbol*. Only a new symbol or one obtained from one of the lookup 
>> functions really should be managed by this class.
> 
> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
> 
> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.

I was confused about which webrev I was looking at.  Coleen's doesn't seem to change those comments.
It was (parts of) Markus's comments that worried me.  And the whole design is tricky and risky.


From daniel.daugherty at oracle.com  Tue Jan 12 13:49:26 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 12 Jan 2016 06:49:26 -0700
Subject: (S) RFR: 8146855: Update hotspot sources to recognize Solaris
	Studio 12u4 compiler
In-Reply-To: <5694934E.9030602@oracle.com>
References: <5694934E.9030602@oracle.com>
Message-ID: <56950466.7090209@oracle.com>

On 1/11/16 10:46 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146855
> webrev: http://cr.openjdk.java.net/~dholmes/8146855/webrev/

make/solaris/makefiles/sparcWorks.make
     No comments.

src/share/vm/runtime/vm_version.cpp
     No comments.

Thumbs up. Of course, I have to wonder why the SS12.4 compiler
update changeset didn't fix this... :-(

Dan


>
> Need to update ENFORCE_CC_COMPILER_REV in sparcWorks.make
>
> Need to update HOTSPOT_BUILD_COMPILER logic in vm_version.cpp
>
> Thanks,
> David
> -----
>
>


From rachel.protacio at oracle.com  Tue Jan 12 18:27:03 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 12 Jan 2016 13:27:03 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently on
	windows when executed by JPRT
Message-ID: <56954577.90306@oracle.com>

Hello!

Please review this fix which adds "-Xshare:off" to all UL tests' 
ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for 
debugging and finding the source of the problem.

Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
Bug: https://bugs.openjdk.java.net/browse/JDK-8146435

Tests sent to JPRT, pass on all platforms.

Thank you!
Rachel

From jiangli.zhou at Oracle.COM  Tue Jan 12 18:28:53 2016
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Tue, 12 Jan 2016 10:28:53 -0800
Subject: RFR: 8146523: VirtualMemoryTracker::remove_released_region double
	count unmapped CDS shared memory
In-Reply-To: <274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
	<274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
Message-ID: <6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>

After more discussion with Coleen and Ioi, I decided to take a different approach to address the issue. Since the double counting release memory only occurs to unmapped CDS shared memory, fixing the issue for CDS only case is a safer approach.

Here is a new webrev that skips the release tracking for the unmapped CDS regions in VirtualMemoryTracker::remove_released_region(). The CDS shared memory is only tracked once by NMT as released when the memory is released as a whole after unmapping individual shared spaces.

http://cr.openjdk.java.net/~jiangli/8146523/webrev.02/

Thanks,
Jiangli

> On Jan 7, 2016, at 3:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
> 
> Hi Ioi,
> 
> Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.
> 
> Just for the benefit of general public, here are some more details:
> 
> The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.
> 
> Thanks!
> Jiangli
> 
>> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>> 
>> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
>> 
>> - Ioi
>> 
>> 
>> On 1/7/16 3:12 PM, Ioi Lam wrote:
>>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>> 
>>>>>> 
>>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>>> Hi Jiangli,
>>>>>>> 
>>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>>> 
>>>>>>> os.cpp:
>>>>>>> 
>>>>>>>    bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>>      bool result;
>>>>>>>      if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>> + #ifndef _WINDOWS
>>>>>>> +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>> + #else
>>>>>>> +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>> +     // the virtual_memory_release_tracker for windows
>>>>>>>        Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>> + #endif
>>>>>>> 
>>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>>> This is not true. There's platform-independent code in virtualspace.cpp:
>>> 
>>>   ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>>> 
>>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>>> 
>>> What you said may be true for CDS:
>>> 
>>>  bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>>  #ifndef _WINDOWS
>>>     // Map in the shared memory and then map the regions on top of it.
>>>     // On Windows, don't map the memory here because it will cause the
>>>     // mappings of the regions to fail.
>>>     ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>> 
>>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>>> 
>>>  bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>     ...
>>>     if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>         mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>       return pd_release_memory(addr, bytes);
>>>     }
>>>     ...
>>>  }
>>> 
>>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>>> 
>>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>>> 
>>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>>> 
>>> Thanks
>>> - Ioi
>>> 
>> 
> 


From george.triantafillou at oracle.com  Tue Jan 12 18:36:53 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 12 Jan 2016 13:36:53 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56954577.90306@oracle.com>
References: <56954577.90306@oracle.com>
Message-ID: <569547C5.6040801@oracle.com>

Hi Rachel,

Looks good!

-George

On 1/12/2016 1:27 PM, Rachel Protacio wrote:
> Hello!
>
> Please review this fix which adds "-Xshare:off" to all UL tests' 
> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for 
> debugging and finding the source of the problem.
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>
> Tests sent to JPRT, pass on all platforms.
>
> Thank you!
> Rachel


From george.triantafillou at oracle.com  Tue Jan 12 18:37:45 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 12 Jan 2016 13:37:45 -0500
Subject: RFR: 8146523: VirtualMemoryTracker::remove_released_region double
	count unmapped CDS shared memory
In-Reply-To: <6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
	<274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
	<6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
Message-ID: <569547F9.4000507@oracle.com>

Hi Jiangli,

Looks good!

-George

On 1/12/2016 1:28 PM, Jiangli Zhou wrote:
> After more discussion with Coleen and Ioi, I decided to take a different approach to address the issue. Since the double counting release memory only occurs to unmapped CDS shared memory, fixing the issue for CDS only case is a safer approach.
>
> Here is a new webrev that skips the release tracking for the unmapped CDS regions in VirtualMemoryTracker::remove_released_region(). The CDS shared memory is only tracked once by NMT as released when the memory is released as a whole after unmapping individual shared spaces.
>
> http://cr.openjdk.java.net/~jiangli/8146523/webrev.02/
>
> Thanks,
> Jiangli
>
>> On Jan 7, 2016, at 3:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>
>> Hi Ioi,
>>
>> Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.
>>
>> Just for the benefit of general public, here are some more details:
>>
>> The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.
>>
>> Thanks!
>> Jiangli
>>
>>> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>>
>>> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
>>>
>>> - Ioi
>>>
>>>
>>> On 1/7/16 3:12 PM, Ioi Lam wrote:
>>>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>>
>>>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>>>>
>>>>>>>> os.cpp:
>>>>>>>>
>>>>>>>>     bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>>>       bool result;
>>>>>>>>       if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>>> + #ifndef _WINDOWS
>>>>>>>> +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>>> + #else
>>>>>>>> +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>>> +     // the virtual_memory_release_tracker for windows
>>>>>>>>         Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>>> + #endif
>>>>>>>>
>>>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>>>> This is not true. There's platform-independent code in virtualspace.cpp:
>>>>
>>>>    ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>>>>
>>>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>>>>
>>>> What you said may be true for CDS:
>>>>
>>>>   bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>>>   #ifndef _WINDOWS
>>>>      // Map in the shared memory and then map the regions on top of it.
>>>>      // On Windows, don't map the memory here because it will cause the
>>>>      // mappings of the regions to fail.
>>>>      ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>>>
>>>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>>>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>>>>
>>>>   bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>>      ...
>>>>      if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>>          mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>>        return pd_release_memory(addr, bytes);
>>>>      }
>>>>      ...
>>>>   }
>>>>
>>>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>>>>
>>>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>>>>
>>>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>


From rachel.protacio at oracle.com  Tue Jan 12 18:39:54 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 12 Jan 2016 13:39:54 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569547C5.6040801@oracle.com>
References: <56954577.90306@oracle.com> <569547C5.6040801@oracle.com>
Message-ID: <5695487A.5010100@oracle.com>

Thanks, George!
Rachel

On 1/12/2016 1:36 PM, George Triantafillou wrote:
> Hi Rachel,
>
> Looks good!
>
> -George
>
> On 1/12/2016 1:27 PM, Rachel Protacio wrote:
>> Hello!
>>
>> Please review this fix which adds "-Xshare:off" to all UL tests' 
>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi 
>> for debugging and finding the source of the problem.
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>
>> Tests sent to JPRT, pass on all platforms.
>>
>> Thank you!
>> Rachel
>


From jiangli.zhou at oracle.com  Tue Jan 12 18:42:09 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 12 Jan 2016 10:42:09 -0800
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56954577.90306@oracle.com>
References: <56954577.90306@oracle.com>
Message-ID: <92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>

Hi Rachel,

Looks good. It would be also good to add comments in the tests explaining why they should be run with -Xshare:off.

Thanks,
Jiangli

> On Jan 12, 2016, at 10:27 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
> 
> Hello!
> 
> Please review this fix which adds "-Xshare:off" to all UL tests' ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for debugging and finding the source of the problem.
> 
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
> 
> Tests sent to JPRT, pass on all platforms.
> 
> Thank you!
> Rachel


From rachel.protacio at oracle.com  Tue Jan 12 19:53:01 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 12 Jan 2016 14:53:01 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>
References: <56954577.90306@oracle.com>
	<92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>
Message-ID: <5695599D.6060607@oracle.com>

Hi,

Thanks! Is this http://cr.openjdk.java.net/~rprotacio/8146435.01/ what 
you had in mind?

Rachel

On 1/12/2016 1:42 PM, Jiangli Zhou wrote:
> Hi Rachel,
>
> Looks good. It would be also good to add comments in the tests explaining why they should be run with -Xshare:off.
>
> Thanks,
> Jiangli
>
>> On Jan 12, 2016, at 10:27 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
>>
>> Hello!
>>
>> Please review this fix which adds "-Xshare:off" to all UL tests' ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for debugging and finding the source of the problem.
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>
>> Tests sent to JPRT, pass on all platforms.
>>
>> Thank you!
>> Rachel


From max.ockner at oracle.com  Tue Jan 12 20:01:34 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 12 Jan 2016 15:01:34 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <5695487A.5010100@oracle.com>
References: <56954577.90306@oracle.com> <569547C5.6040801@oracle.com>
	<5695487A.5010100@oracle.com>
Message-ID: <56955B9E.5040001@oracle.com>

Looks fine to me, though I also noticed you changed a bunch of formatting.

Max

On 1/12/2016 1:39 PM, Rachel Protacio wrote:
> Thanks, George!
> Rachel
>
> On 1/12/2016 1:36 PM, George Triantafillou wrote:
>> Hi Rachel,
>>
>> Looks good!
>>
>> -George
>>
>> On 1/12/2016 1:27 PM, Rachel Protacio wrote:
>>> Hello!
>>>
>>> Please review this fix which adds "-Xshare:off" to all UL tests' 
>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi 
>>> for debugging and finding the source of the problem.
>>>
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>
>>> Tests sent to JPRT, pass on all platforms.
>>>
>>> Thank you!
>>> Rachel
>>
>


From rachel.protacio at oracle.com  Tue Jan 12 20:06:19 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 12 Jan 2016 15:06:19 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56955B9E.5040001@oracle.com>
References: <56954577.90306@oracle.com> <569547C5.6040801@oracle.com>
	<5695487A.5010100@oracle.com> <56955B9E.5040001@oracle.com>
Message-ID: <56955CBB.80103@oracle.com>

You mean the line breaks? I was trying to keep the lines to a reasonable 
length when possible. Do you disagree, or were you just commenting?
Rachel

On 1/12/2016 3:01 PM, Max Ockner wrote:
> Looks fine to me, though I also noticed you changed a bunch of 
> formatting.
>
> Max
>
> On 1/12/2016 1:39 PM, Rachel Protacio wrote:
>> Thanks, George!
>> Rachel
>>
>> On 1/12/2016 1:36 PM, George Triantafillou wrote:
>>> Hi Rachel,
>>>
>>> Looks good!
>>>
>>> -George
>>>
>>> On 1/12/2016 1:27 PM, Rachel Protacio wrote:
>>>> Hello!
>>>>
>>>> Please review this fix which adds "-Xshare:off" to all UL tests' 
>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi 
>>>> for debugging and finding the source of the problem.
>>>>
>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>
>>>> Tests sent to JPRT, pass on all platforms.
>>>>
>>>> Thank you!
>>>> Rachel
>>>
>>
>


From jiangli.zhou at oracle.com  Tue Jan 12 20:07:44 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 12 Jan 2016 12:07:44 -0800
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <5695599D.6060607@oracle.com>
References: <56954577.90306@oracle.com>
	<92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>
	<5695599D.6060607@oracle.com>
Message-ID: <2BB39ADE-575E-4465-83B6-EC229BD4AF10@oracle.com>


> On Jan 12, 2016, at 11:53 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
> 
> Hi,
> 
> Thanks! Is this http://cr.openjdk.java.net/~rprotacio/8146435.01/ what you had in mind?

Looks good.

Thanks!

Jiangli

> 
> Rachel
> 
> On 1/12/2016 1:42 PM, Jiangli Zhou wrote:
>> Hi Rachel,
>> 
>> Looks good. It would be also good to add comments in the tests explaining why they should be run with -Xshare:off.
>> 
>> Thanks,
>> Jiangli
>> 
>>> On Jan 12, 2016, at 10:27 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
>>> 
>>> Hello!
>>> 
>>> Please review this fix which adds "-Xshare:off" to all UL tests' ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for debugging and finding the source of the problem.
>>> 
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>> 
>>> Tests sent to JPRT, pass on all platforms.
>>> 
>>> Thank you!
>>> Rachel
> 


From jiangli.zhou at oracle.com  Tue Jan 12 20:08:18 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 12 Jan 2016 12:08:18 -0800
Subject: RFR: 8146523: VirtualMemoryTracker::remove_released_region double
	count unmapped CDS shared memory
In-Reply-To: <569547F9.4000507@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
	<274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
	<6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
	<569547F9.4000507@oracle.com>
Message-ID: <BC50689A-F64A-4274-AAB1-A22622F9C8F1@oracle.com>

Thank you, George!

Jiangli

> On Jan 12, 2016, at 10:37 AM, George Triantafillou <george.triantafillou at oracle.com> wrote:
> 
> Hi Jiangli,
> 
> Looks good!
> 
> -George
> 
> On 1/12/2016 1:28 PM, Jiangli Zhou wrote:
>> After more discussion with Coleen and Ioi, I decided to take a different approach to address the issue. Since the double counting release memory only occurs to unmapped CDS shared memory, fixing the issue for CDS only case is a safer approach.
>> 
>> Here is a new webrev that skips the release tracking for the unmapped CDS regions in VirtualMemoryTracker::remove_released_region(). The CDS shared memory is only tracked once by NMT as released when the memory is released as a whole after unmapping individual shared spaces.
>> 
>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.02/
>> 
>> Thanks,
>> Jiangli
>> 
>>> On Jan 7, 2016, at 3:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>> 
>>> Hi Ioi,
>>> 
>>> Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.
>>> 
>>> Just for the benefit of general public, here are some more details:
>>> 
>>> The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.
>>> 
>>> Thanks!
>>> Jiangli
>>> 
>>>> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>>> 
>>>> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
>>>> 
>>>> - Ioi
>>>> 
>>>> 
>>>> On 1/7/16 3:12 PM, Ioi Lam wrote:
>>>>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>>>>> Hi Jiangli,
>>>>>>>>> 
>>>>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>>>>> 
>>>>>>>>> os.cpp:
>>>>>>>>> 
>>>>>>>>>    bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>>>>      bool result;
>>>>>>>>>      if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>>>> + #ifndef _WINDOWS
>>>>>>>>> +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>>>> + #else
>>>>>>>>> +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>>>> +     // the virtual_memory_release_tracker for windows
>>>>>>>>>        Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>>>> + #endif
>>>>>>>>> 
>>>>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>>>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>>>>> This is not true. There's platform-independent code in virtualspace.cpp:
>>>>> 
>>>>>   ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>>>>> 
>>>>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>>>>> 
>>>>> What you said may be true for CDS:
>>>>> 
>>>>>  bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>>>>  #ifndef _WINDOWS
>>>>>     // Map in the shared memory and then map the regions on top of it.
>>>>>     // On Windows, don't map the memory here because it will cause the
>>>>>     // mappings of the regions to fail.
>>>>>     ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>>>> 
>>>>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>>>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>>>>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>>>>> 
>>>>>  bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>>>     ...
>>>>>     if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>>>         mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>>>       return pd_release_memory(addr, bytes);
>>>>>     }
>>>>>     ...
>>>>>  }
>>>>> 
>>>>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>>>>> 
>>>>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>>>>> 
>>>>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>>>>> 
>>>>> Thanks
>>>>> - Ioi
>>>>> 
> 


From rachel.protacio at oracle.com  Tue Jan 12 20:08:18 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 12 Jan 2016 15:08:18 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <2BB39ADE-575E-4465-83B6-EC229BD4AF10@oracle.com>
References: <56954577.90306@oracle.com>
	<92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>
	<5695599D.6060607@oracle.com>
	<2BB39ADE-575E-4465-83B6-EC229BD4AF10@oracle.com>
Message-ID: <56955D32.2090101@oracle.com>

Great, thanks for the review!
Rachel

On 1/12/2016 3:07 PM, Jiangli Zhou wrote:
>> On Jan 12, 2016, at 11:53 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
>>
>> Hi,
>>
>> Thanks! Is this http://cr.openjdk.java.net/~rprotacio/8146435.01/ what you had in mind?
> Looks good.
>
> Thanks!
>
> Jiangli
>
>> Rachel
>>
>> On 1/12/2016 1:42 PM, Jiangli Zhou wrote:
>>> Hi Rachel,
>>>
>>> Looks good. It would be also good to add comments in the tests explaining why they should be run with -Xshare:off.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>>> On Jan 12, 2016, at 10:27 AM, Rachel Protacio <rachel.protacio at oracle.com> wrote:
>>>>
>>>> Hello!
>>>>
>>>> Please review this fix which adds "-Xshare:off" to all UL tests' ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for debugging and finding the source of the problem.
>>>>
>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>
>>>> Tests sent to JPRT, pass on all platforms.
>>>>
>>>> Thank you!
>>>> Rachel


From coleen.phillimore at oracle.com  Tue Jan 12 20:17:33 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 12 Jan 2016 15:17:33 -0500
Subject: RFR: 8146523: VirtualMemoryTracker::remove_released_region double
	count unmapped CDS shared memory
In-Reply-To: <6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
	<274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
	<6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
Message-ID: <56955F5D.20701@oracle.com>


Yes, this looks safe.  There's precedent for special code in NMT for CDS.

Coleen


On 1/12/16 1:28 PM, Jiangli Zhou wrote:
> After more discussion with Coleen and Ioi, I decided to take a different approach to address the issue. Since the double counting release memory only occurs to unmapped CDS shared memory, fixing the issue for CDS only case is a safer approach.
>
> Here is a new webrev that skips the release tracking for the unmapped CDS regions in VirtualMemoryTracker::remove_released_region(). The CDS shared memory is only tracked once by NMT as released when the memory is released as a whole after unmapping individual shared spaces.
>
> http://cr.openjdk.java.net/~jiangli/8146523/webrev.02/
>
> Thanks,
> Jiangli
>
>> On Jan 7, 2016, at 3:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>
>> Hi Ioi,
>>
>> Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.
>>
>> Just for the benefit of general public, here are some more details:
>>
>> The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.
>>
>> Thanks!
>> Jiangli
>>
>>> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>>
>>> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
>>>
>>> - Ioi
>>>
>>>
>>> On 1/7/16 3:12 PM, Ioi Lam wrote:
>>>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>>>> Hi Jiangli,
>>>>>>>>
>>>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>>>>
>>>>>>>> os.cpp:
>>>>>>>>
>>>>>>>>     bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>>>       bool result;
>>>>>>>>       if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>>> + #ifndef _WINDOWS
>>>>>>>> +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>>> + #else
>>>>>>>> +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>>> +     // the virtual_memory_release_tracker for windows
>>>>>>>>         Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>>> + #endif
>>>>>>>>
>>>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>>>> This is not true. There's platform-independent code in virtualspace.cpp:
>>>>
>>>>    ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>>>>
>>>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>>>>
>>>> What you said may be true for CDS:
>>>>
>>>>   bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>>>   #ifndef _WINDOWS
>>>>      // Map in the shared memory and then map the regions on top of it.
>>>>      // On Windows, don't map the memory here because it will cause the
>>>>      // mappings of the regions to fail.
>>>>      ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>>>
>>>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>>>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>>>>
>>>>   bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>>      ...
>>>>      if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>>          mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>>        return pd_release_memory(addr, bytes);
>>>>      }
>>>>      ...
>>>>   }
>>>>
>>>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>>>>
>>>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>>>>
>>>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>


From kim.barrett at oracle.com  Tue Jan 12 20:27:10 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 12 Jan 2016 15:27:10 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <2d5a4044-9851-454d-83c9-73cbb9b22552@default>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
Message-ID: <6329984C-2465-4976-9804-5AED5EF9710B@oracle.com>

On Jan 12, 2016, at 7:34 AM, Markus Gronlund <markus.gronlund at oracle.com> wrote:
> 
> Hi Kim,
> 
> Thanks a lot for the (detailed) reminder about the copy-and-swap idiom. I agree with your reasoning.
> 
> About the return value from operator=, I would suggest retaining the void as-is as well.
> 
> Maybe we should investigate if it is possible to have the functions in SymbolTable that increment Symbol*'s return a TempNewSymbol( or some other "smartptr" concept) instead of a direct Symbol*?
> 
> In that case we could make the type conversion constructor private and make SymbolTable a friend of TempNewSymbol - this would avoid accidental wrapping of arbitrary Symbol*'s. I will look into the possibility of this.

I thought I suggested something like this to Coleen a while ago, but it didn?t work out for some reason?  But I might be misremembering.

In such a scheme the conversion constructor doesn?t need to be private with friend access for SymbolTable.  Instead, the conversion constructor can increment the refcount and the SymbolTable functions that return symbol references make use of that behavior.


From max.ockner at oracle.com  Tue Jan 12 20:29:00 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 12 Jan 2016 15:29:00 -0500
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <56949DAD.5060606@oracle.com>
References: <5693E00A.1090001@oracle.com> <56949DAD.5060606@oracle.com>
Message-ID: <5695620C.7080109@oracle.com>

David,
Originally, VAR_LOG_TAGS was included to help use the configure_stdout 
function. Marcus has suggested that I don't need it so I have removed it.
New webrev: http://cr.openjdk.java.net/~mockner/aliastable.04/
Thanks,
Max
On 1/12/2016 1:31 AM, David Holmes wrote:
> Hi Max,
>
> On 12/01/2016 3:02 AM, Max Ockner wrote:
>> Hello all,
>> Please review my fix which reorganizes the alias table for Unified 
>> Logging.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
>> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/
>
> Is this supposed to contain the VAR_LOG_TAGS changes?
>
> Is the "deprecation" of the converted tracing flags still to be added?
>
> Otherwise seems okay.
>
> Thanks,
> David
>
>> Summary:
>> How logging aliases used to handled - At the beginning of
>> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would be
>> looked up in the logging alias table to see if there was a match. If a
>> match was found, then the entire argument would be replaced by a
>> corresponding unified logging argument. This argument would then cascade
>> through the giant case structure until it was caught and handled close
>> to the bottom of parse_each_vm_init_arg (which happens hundreds of lines
>> later).
>>
>> There is a section of code that handles aliases and deprecation for -XX
>> options already. After this fix, logging aliases will be handled here
>> instead of substituting entire logging expressions at the beginning of
>> parse_each_vm_init_arg.
>>
>> Tested with jtreg runtime tests. This includes several logging tests for
>> recently aliased flags.
>>
>> Thanks,
>> Max
>>


From harold.seigel at oracle.com  Tue Jan 12 20:40:41 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Tue, 12 Jan 2016 15:40:41 -0500
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <5695620C.7080109@oracle.com>
References: <5693E00A.1090001@oracle.com> <56949DAD.5060606@oracle.com>
	<5695620C.7080109@oracle.com>
Message-ID: <569564C9.6040400@oracle.com>

Hi Max,

Other than the copyright dates and minor #include alphabetizing the 
changes look good.

Harold

On 1/12/2016 3:29 PM, Max Ockner wrote:
> David,
> Originally, VAR_LOG_TAGS was included to help use the configure_stdout 
> function. Marcus has suggested that I don't need it so I have removed it.
> New webrev: http://cr.openjdk.java.net/~mockner/aliastable.04/
> Thanks,
> Max
> On 1/12/2016 1:31 AM, David Holmes wrote:
>> Hi Max,
>>
>> On 12/01/2016 3:02 AM, Max Ockner wrote:
>>> Hello all,
>>> Please review my fix which reorganizes the alias table for Unified 
>>> Logging.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
>>> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/
>>
>> Is this supposed to contain the VAR_LOG_TAGS changes?
>>
>> Is the "deprecation" of the converted tracing flags still to be added?
>>
>> Otherwise seems okay.
>>
>> Thanks,
>> David
>>
>>> Summary:
>>> How logging aliases used to handled - At the beginning of
>>> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would be
>>> looked up in the logging alias table to see if there was a match. If a
>>> match was found, then the entire argument would be replaced by a
>>> corresponding unified logging argument. This argument would then 
>>> cascade
>>> through the giant case structure until it was caught and handled close
>>> to the bottom of parse_each_vm_init_arg (which happens hundreds of 
>>> lines
>>> later).
>>>
>>> There is a section of code that handles aliases and deprecation for -XX
>>> options already. After this fix, logging aliases will be handled here
>>> instead of substituting entire logging expressions at the beginning of
>>> parse_each_vm_init_arg.
>>>
>>> Tested with jtreg runtime tests. This includes several logging tests 
>>> for
>>> recently aliased flags.
>>>
>>> Thanks,
>>> Max
>>>
>


From coleen.phillimore at oracle.com  Tue Jan 12 21:38:28 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 12 Jan 2016 16:38:28 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
Message-ID: <56957254.8080405@oracle.com>


Kim, see below.

On 1/11/16 11:22 PM, Kim Barrett wrote:
> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>> Kim and Lois,
>>
>> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
>>
>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>
>> See comments below.
>>
>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>>>
>>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>>>
>>>>   Percent removed          1.35
>>>>   Reference counts          194583
>>>>
>>>> clean:
>>>>
>>>>   Percent removed          1.53
>>>>   Reference counts          194245
>>>>
>>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>>>
>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc");
>>>> // Hit GC
>>>>
>>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>
>>>> Thanks,
>>>> Coleen
>>> For the assignment operator, I think better is:
>>>
>>> void operator=(TempNewSymbol s) {
>>>    Symbol* tmp = s._temp;
>>>    s._temp = _temp;
>>>    _temp = tmp;
>>> }
>>>
>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>
>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom
>> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.
> Copy-swap saves several refcount manipulations in some (common) cases,
> by taking advantage of rvalue copy elision.
>
> Coleen's:
>
> void operator=(const TempNewSymbol& s) {
>    clear();
>    _temp = s._temp;
>    if (_temp != NULL) _temp->increment_refcount();
> }
>
> Markus's:
>
> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>    if (this != &rhs && _temp != rhs._temp) {
>      clear();
>      _temp = rhs._temp;
>      if (_temp != NULL) {
>        _temp->increment_refcount();
>      }
>    }
>    return *this;
> }
>
> Kim's:
>
> void operator=(TempNewSymbol rhs) {
>    Symbol* tmp = rhs._temp;
>    rhs._temp = _temp;
>    _temp = tmp;
> }
>
> [I'm ignoring differences in the return value in the discussion below.
> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>
> Markus's is mostly the same as Coleen's, except it handles a couple of
> special cases differently.

Yes, I adopted Markus's version in my last change.
> Markus's handles self-assignment, where Coleen's doesn't. For
> correctness that's important; in actual practice self-assignment is
> generally rare to non-existent, so always paying overhead for it is
> unpleasant.
>
> Markus's also specially handles re-assignment to the same symbol,
> avoiding any refcount changes in that case.  I suggest this is another
> rare case, and adding overhead in the normal case to get that rare
> benefit is not the right tradeoff.
>
> Assuming we're not in one of those special cases and neither Symbol*
> is NULL, Coleen/Markus decrements the old and increments the new. And
> in an important special case where rhs is an rvalue, there will be
> another decrement as the temporary goes out of scope. So two refcount
> changes when rhs is an lvalue, three when it's an rvalue.
>
> In contrast, Kim's does an increment and a decrement when rhs is an
> lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy
> elision is performed by the compiler, which any decent optimizing
> compiler will do.

In my small test case, copy constructor elision is not done for either 
clang++ or g++ -O3 (attached).  So the ref counting is still the same.  
Or I'm counting wrong.


>
> The rhs is an rvalue in the following situation:
>
>    TempNewSymbol tns = ... ;
>    ...
>    tns = expr_returning_Symbol* ;
>
> The rhs gets implicitly converted to a temporary (rvalue)
> TempNewSymbol referring to the symbol (no refcount change), that
> temporary is directly bound to the assignment argument (copy elided),
> swap the symbols, and the rvalue converted temp goes out of scope and
> decrements the refcount of the old Symbol*.
>
> The copy-swap version also handles the (rare) self-assignment and
> re-assignment to the same symbol cases. In these cases Kim's still
> does the same refcounting changes as otherwise.  But it's better to do
> extra work in the rare cases and keep the normal cases fast.
>
> This is why copy-swap has become the "usual idiom"for assignment
> operators. There might be cases where it's not the best answer, but
> usually it is. And this is why (to answer Lois's issue) one should use
> it even though it's not obvious if one is not previously familiar with
> the idiom; one should instead learn the idiom, and then one spends
> time looking hard at implementations that do something else.

I don't mind learning new C++ or using "usual idioms"   I'd have to 
comment it to prevent someone from wasting time puzzling over it. If 
C++11 further optimizes away the copy constructors, that would be great.

Coleen
>
> Of course, this may all be entirely in the noise; I hope that
> TempNewSymbol assignment is not a high frequency operation.
>
>
>>> I think the updated description of TempNewSymbol isn't really right.
>>> Because the conversion constructor doesn't increment the reference
>>> count, it must *not* be used to capture some arbitrary reference to a
>>> Symbol*. Only a new symbol or one obtained from one of the lookup
>>> functions really should be managed by this class.
>> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
>>
>> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.
> I was confused about which webrev I was looking at.  Coleen?s doesn?t seem to change those comments.
> It was (parts of) Markus?s comments that worried me.  And the whole design is tricky and risky.
>

-------------- next part --------------

extern "C" int printf(const char *,...);
class Symbol {
  const char* _value;
 public:
  Symbol(const char* v) : _value(v) {}
  const char* value() { return this != 0 ? _value : "null"; }
};

class TempNewSymbol {
 public:
  Symbol* _sym;
  TempNewSymbol() : _sym(0) { printf("default ctor called\n"); }
  TempNewSymbol(Symbol* s) : _sym(s) { printf("convert ctor called %s\n", _sym->value()); }
  ~TempNewSymbol() { printf("dtor called %s\n", _sym->value()); }
  TempNewSymbol(const TempNewSymbol& ts) {
    _sym = ts._sym;
    printf("copy constructor called %s\n", _sym->value());
  }
#if 0
  const TempNewSymbol& operator=(const TempNewSymbol& ts) {
    printf("assignment operator called %s\n", _sym->value());
    _sym = ts._sym;
  }
#endif
  void operator=(TempNewSymbol rhs) {
    printf("assignment operator called %s\n", _sym->value());
    Symbol* tmp = rhs._sym;
    rhs._sym = _sym;
    _sym = tmp;
  }
};

int main() {
  Symbol* s = new Symbol("abc");
  TempNewSymbol ss = s;

  TempNewSymbol s1 = new Symbol("efg");
  TempNewSymbol s2 = new Symbol("hij");
  printf("s2 is hij=%s\n", s2._sym->value());
  s1 = s2;
  printf("s1 is hij=%s\n", s1._sym->value());

  s1 = s1;

  TempNewSymbol s3;
  s3 = new Symbol("klm");
  printf("s3 is klm=%s\n", s3._sym->value());
}

From coleen.phillimore at oracle.com  Tue Jan 12 21:59:26 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 12 Jan 2016 16:59:26 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <2d5a4044-9851-454d-83c9-73cbb9b22552@default>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
Message-ID: <5695773E.5000504@oracle.com>



On 1/12/16 7:34 AM, Markus Gronlund wrote:
> Hi Kim,
>
> Thanks a lot for the (detailed) reminder about the copy-and-swap idiom. I agree with your reasoning.

Two for (strongly?) and two against (myself, not so strongly and we can 
always add a comment to save someone else's time).  I can change it 
(hoping my test still pass).  Did you look at the test?
>
> About the return value from operator=, I would suggest retaining the void as-is as well.

Ok
>
> Maybe we should investigate if it is possible to have the functions in SymbolTable that increment Symbol*'s return a TempNewSymbol( or some other "smartptr" concept) instead of a direct Symbol*?

When changing symbolOops symbolHandles, to Symbol* with refcounting I 
had an implementation using SymbolHandle as a smart pointer.  I think I 
had the assignment operator transfer ownership of the pointer, iirc.  I 
had added reference counting statistics at that time (which I have 
output in my RFR).   My memory was that the number of Atomic:: add and 
subtract operations were an order of magnitude larger.  I saved a lot of 
email on this except the numbers.  Symbols mostly come into the JVM 
through the constant pool, with these exceptions that use TempNewSymbol.

>
> In that case we could make the type conversion constructor private and make SymbolTable a friend of TempNewSymbol - this would avoid accidental wrapping of arbitrary Symbol*'s. I will look into the possibility of this.

This sounds like a good idea.

Thanks,
Coleen
>
> Thanks again for your clarification
> Markus
>
> -----Original Message-----
> From: Kim Barrett
> Sent: den 12 januari 2016 05:22
> To: Coleen Phillimore
> Cc: hotspot-runtime-dev
> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
>
> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>> Kim and Lois,
>>
>> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
>>
>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>
>> See comments below.
>>
>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>>>
>>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>>>
>>>>   Percent removed          1.35
>>>>   Reference counts          194583
>>>>
>>>> clean:
>>>>
>>>>   Percent removed          1.53
>>>>   Reference counts          194245
>>>>
>>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>>>
>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>
>>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>
>>>> Thanks,
>>>> Coleen
>>> For the assignment operator, I think better is:
>>>
>>> void operator=(TempNewSymbol s) {
>>>    Symbol* tmp = s._temp;
>>>    s._temp = _temp;
>>>    _temp = tmp;
>>> }
>>>
>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>
>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-
>>> idiom
>> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.
> Copy-swap saves several refcount manipulations in some (common) cases, by taking advantage of rvalue copy elision.
>
> Coleen's:
>
> void operator=(const TempNewSymbol& s) {
>    clear();
>    _temp = s._temp;
>    if (_temp != NULL) _temp->increment_refcount(); }
>
> Markus's:
>
> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>    if (this != &rhs && _temp != rhs._temp) {
>      clear();
>      _temp = rhs._temp;
>      if (_temp != NULL) {
>        _temp->increment_refcount();
>      }
>    }
>    return *this;
> }
>
> Kim's:
>
> void operator=(TempNewSymbol rhs) {
>    Symbol* tmp = rhs._temp;
>    rhs._temp = _temp;
>    _temp = tmp;
> }
>
> [I'm ignoring differences in the return value in the discussion below.
> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>
> Markus's is mostly the same as Coleen's, except it handles a couple of special cases differently.
>
> Markus's handles self-assignment, where Coleen's doesn't. For correctness that's important; in actual practice self-assignment is generally rare to non-existent, so always paying overhead for it is unpleasant.
>
> Markus's also specially handles re-assignment to the same symbol, avoiding any refcount changes in that case.  I suggest this is another rare case, and adding overhead in the normal case to get that rare benefit is not the right tradeoff.
>
> Assuming we're not in one of those special cases and neither Symbol* is NULL, Coleen/Markus decrements the old and increments the new. And in an important special case where rhs is an rvalue, there will be another decrement as the temporary goes out of scope. So two refcount changes when rhs is an lvalue, three when it's an rvalue.
>
> In contrast, Kim's does an increment and a decrement when rhs is an lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy elision is performed by the compiler, which any decent optimizing compiler will do.
>
> The rhs is an rvalue in the following situation:
>
>    TempNewSymbol tns = ... ;
>    ...
>    tns = expr_returning_Symbol* ;
>
> The rhs gets implicitly converted to a temporary (rvalue) TempNewSymbol referring to the symbol (no refcount change), that temporary is directly bound to the assignment argument (copy elided), swap the symbols, and the rvalue converted temp goes out of scope and decrements the refcount of the old Symbol*.
>
> The copy-swap version also handles the (rare) self-assignment and re-assignment to the same symbol cases. In these cases Kim's still does the same refcounting changes as otherwise.  But it's better to do extra work in the rare cases and keep the normal cases fast.
>
> This is why copy-swap has become the "usual idiom"for assignment operators. There might be cases where it's not the best answer, but usually it is. And this is why (to answer Lois's issue) one should use it even though it's not obvious if one is not previously familiar with the idiom; one should instead learn the idiom, and then one spends time looking hard at implementations that do something else.
>
> Of course, this may all be entirely in the noise; I hope that TempNewSymbol assignment is not a high frequency operation.
>
>
>>> I think the updated description of TempNewSymbol isn't really right.
>>> Because the conversion constructor doesn't increment the reference
>>> count, it must *not* be used to capture some arbitrary reference to a
>>> Symbol*. Only a new symbol or one obtained from one of the lookup
>>> functions really should be managed by this class.
>> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
>>
>> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.
> I was confused about which webrev I was looking at.  Coleen's doesn't seem to change those comments.
> It was (parts of) Markus's comments that worried me.  And the whole design is tricky and risky.
>


From serguei.spitsyn at oracle.com  Tue Jan 12 22:25:44 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 12 Jan 2016 14:25:44 -0800
Subject: (XS) RFR: 8146222: assert(_initialized) failed: TLS not
	initialized yet!
In-Reply-To: <568FCC03.5080207@oracle.com>
References: <568F3481.80106@oracle.com> <568FCC03.5080207@oracle.com>
Message-ID: <56957D68.7050904@oracle.com>

David,

It looks good.

Thanks,
Serguei


On 1/8/16 06:47, Daniel D. Daugherty wrote:
> On 1/7/16 9:01 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146222
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8146222/webrev/
>
> src/share/vm/runtime/thread.cpp
>     No comments.
>
> Thumbs up.
>
> Dan
>
>
>>
>> JDK-8144947 showed an error path, on Windows, where we can call 
>> Thread::current_or_null before TLS has been initialized and so hit 
>> the assertion failure - see bug report for details.
>>
>> Simple fix is to move the ThreadLocalStorage::init() prior to any 
>> argument parsing code. As it contains simple OS library calls it can 
>> be initialized very early. Even the asserts in it still work 
>> (somewhat surprisingly) after the move.
>>
>> Failure mode of 
>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java before 
>> the fix:
>>
>> Agent[1].stdout: ## nof_mallocs = 674, nof_frees = 38
>> Agent[1].stdout: ## memory stomp:
>> Agent[1].stdout: GuardedMemory(0x0000000000fbf690) 
>> base_addr=0x0000000000fbf3f0 tag=0x00000000000da360 
>> user_size=16512112 user_data=0x0000000000fbf410
>> Agent[1].stdout: Header guard @0x0000000000fbf3f0 is BROKEN
>> Agent[1].stdout: # To suppress the following error report, specify 
>> this argument
>> Agent[1].stdout: # after -XX: or in .hotspotrc: 
>> SuppressErrorAt=\threadLocalStorage_windows.cpp:52
>> Agent[1].stdout: #
>> Agent[1].stdout: # A fatal error has been detected by the Java 
>> Runtime Environment:
>> Agent[1].stdout: #
>> Agent[1].stdout: # Internal Error 
>> (C:\jprt\T\P1\020042.daholme\s\hotspot\src\os\windows\vm\threadLocalStorage_windows.cpp:52), 
>> pid=5076, tid=4348
>> Agent[1].stdout: # assert(_initialized) failed: TLS not initialized yet!
>>
>> Failure mode after:
>>
>> Agent[1].stdout: ## nof_mallocs = 601, nof_frees = 36
>> Agent[1].stdout: ## memory stomp:
>> Agent[1].stdout: GuardedMemory(0x00f1fc44) base_addr=0x00f1fb40 
>> tag=0x003a9bc0 user_size=1942466404 user_data=0x00f1fb58
>> Agent[1].stdout: Header guard @0x00f1fb40 is BROKEN
>> Agent[1].stdout: #
>> Agent[1].stdout: # A fatal error has been detected by the Java 
>> Runtime Environment:
>> Agent[1].stdout: #
>> Agent[1].stdout: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 
>> pc=0x73bb8ab6, pid=10328, tid=7672
>>
>> Testing:
>>   - JPRT
>>   - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
>>   - testing that the asserts in the relocated init() method fire 
>> correctly
>>
>> Thanks,
>> David
>


From jiangli.zhou at oracle.com  Tue Jan 12 22:38:58 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 12 Jan 2016 14:38:58 -0800
Subject: RFR: 8146523: VirtualMemoryTracker::remove_released_region double
	count unmapped CDS shared memory
In-Reply-To: <56955F5D.20701@oracle.com>
References: <8625641B-402A-42D5-9214-CC47F2C26857@oracle.com>
	<568CB531.5080608@oracle.com>
	<4FF606E6-D6DC-4B87-8557-E8C74D23B658@oracle.com>
	<568DC7B4.1020403@oracle.com>
	<FE6C9DD3-A92A-4256-97EF-DEEE2264CE0A@oracle.com>
	<568EBDBE.3010003@oracle.com> <568EC1CD.1060109@oracle.com>
	<568EC93C.1020906@oracle.com>
	<3DEF0E34-A25A-4686-81BC-4220F26132FC@oracle.com>
	<568EF0FA.4070807@oracle.com> <568EF50F.9060005@oracle.com>
	<274BBFBF-DC8B-4E17-9CC4-0980F924D612@oracle.com>
	<6EA338B7-A663-4EA0-98AA-2C0B4FE4F258@oracle.com>
	<56955F5D.20701@oracle.com>
Message-ID: <A31A0DC6-C10B-4453-A691-B2CDD46F5926@oracle.com>

Thanks, Coleen.

Jiangli

> On Jan 12, 2016, at 12:17 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Yes, this looks safe.  There's precedent for special code in NMT for CDS.
> 
> Coleen
> 
> 
> On 1/12/16 1:28 PM, Jiangli Zhou wrote:
>> After more discussion with Coleen and Ioi, I decided to take a different approach to address the issue. Since the double counting release memory only occurs to unmapped CDS shared memory, fixing the issue for CDS only case is a safer approach.
>> 
>> Here is a new webrev that skips the release tracking for the unmapped CDS regions in VirtualMemoryTracker::remove_released_region(). The CDS shared memory is only tracked once by NMT as released when the memory is released as a whole after unmapping individual shared spaces.
>> 
>> http://cr.openjdk.java.net/~jiangli/8146523/webrev.02/
>> 
>> Thanks,
>> Jiangli
>> 
>>> On Jan 7, 2016, at 3:42 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>>> 
>>> Hi Ioi,
>>> 
>>> Got your email while typing my reply. :) I saw your email regarding the comment change as well. Will reflect that in my fix before pushing.
>>> 
>>> Just for the benefit of general public, here are some more details:
>>> 
>>> The reserve/release memory operations do not have platform specific behavior from NMT point of view. The reserve-map/unmap-release operations are handled differently for windows and linux/unix. The usage of reserve-map/unmap-release is only in CDS code currently, which has conditional code that does reserve and release for shared memory on non-windows platform. The fix does not change the original NMT behavior for windows platform.
>>> 
>>> Thanks!
>>> Jiangli
>>> 
>>>> On Jan 7, 2016, at 3:30 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>>> 
>>>> Oops, please ignore most of what I said here. I just realized that os::map_memory/unmap_memory is called only by CDS.
>>>> 
>>>> - Ioi
>>>> 
>>>> 
>>>> On 1/7/16 3:12 PM, Ioi Lam wrote:
>>>>> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>>>>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>>>>>> Hi Jiangli,
>>>>>>>>> 
>>>>>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows but I can't figure out how it would affect the memory tracker:
>>>>>>>>> 
>>>>>>>>> os.cpp:
>>>>>>>>> 
>>>>>>>>>    bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>>>>>      bool result;
>>>>>>>>>      if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>>>>> + #ifndef _WINDOWS
>>>>>>>>> +     Tracker tkr = MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>>>>> + #else
>>>>>>>>> +     // Windows pd_unmap_memory also does memory release, so use
>>>>>>>>> +     // the virtual_memory_release_tracker for windows
>>>>>>>>>        Tracker tkr = MemTracker::get_virtual_memory_release_tracker();
>>>>>>>>> + #endif
>>>>>>>>> 
>>>>>> Could you please explain why the comment is wrong? On linux/unix platforms, we have extra code to do explicit memory ?reserve? and ?release?, which calls NMT to track the reserve and release of the related memory region. Mapping and unmaping are performed on the memory regions that are already ?reserved? on those platform.
>>>>>> On windows, there are no explicit calls to do memory ?reserve? before mapping and ?release? after unmapping.
>>>>> This is not true. There's platform-independent code in virtualspace.cpp:
>>>>> 
>>>>>   ReservedSpace::initialize -> os::reserve_memory -> os::pd_reserve_memory.
>>>>> 
>>>>> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is actually implemented in os_windows.cpp
>>>>> 
>>>>> What you said may be true for CDS:
>>>>> 
>>>>>  bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>>>>>  #ifndef _WINDOWS
>>>>>     // Map in the shared memory and then map the regions on top of it.
>>>>>     // On Windows, don't map the memory here because it will cause the
>>>>>     // mappings of the regions to fail.
>>>>>     ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>>>>> 
>>>>> but that's not true in general. There are plenty of ReservedSpace used in platform-independent GC code.
>>>>>> So the memory mapping/unmapping APIs have the implicit ?reserve?/?release? behaviors. That?s why for windows the release_tracker is used to reflect the behavior of unmapping with implicit ?release?, and the linux/unix only needs the uncommit_tracker.
>>>>> Also the comment implies that pd_unmap_memory always calls pd_release_memory, but this is not true:
>>>>> 
>>>>>  bool os::pd_unmap_memory(char* addr, size_t bytes) {
>>>>>     ...
>>>>>     if (mem_info.Protect == PAGE_EXECUTE_READ ||
>>>>>         mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>>>>>       return pd_release_memory(addr, bytes);
>>>>>     }
>>>>>     ...
>>>>>  }
>>>>> 
>>>>> Even on Windows, won't we eventually call os::release_memory(), which would properly record the removal using get_virtual_memory_release_tracker? Yes, CDS is an exception, but that should be dealt with in the CDS code, not in the generic os.cpp code. And, I am not particularly worried about the CDS case, since it happens only when mapping of some of the CDS regions has failed.
>>>>> 
>>>>> Are you sure we need the special case for Windows here? Have you tested NMT on Windows without the #ifdef?
>>>>> 
>>>>> The NMT code is quite messy. I don't want to make it worse by adding more #ifdefs with comments that are only partially true.
>>>>> 
>>>>> Thanks
>>>>> - Ioi
>>>>> 
> 


From coleen.phillimore at oracle.com  Wed Jan 13 00:12:57 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 12 Jan 2016 19:12:57 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56955D32.2090101@oracle.com>
References: <56954577.90306@oracle.com>
	<92E92A12-E086-4D8A-8C88-AEF4D3301F1E@oracle.com>
	<5695599D.6060607@oracle.com>
	<2BB39ADE-575E-4465-83B6-EC229BD4AF10@oracle.com>
	<56955D32.2090101@oracle.com>
Message-ID: <56959689.2020405@oracle.com>


This change looks good.
Coleen


On 1/12/16 3:08 PM, Rachel Protacio wrote:
> Great, thanks for the review!
> Rachel
>
> On 1/12/2016 3:07 PM, Jiangli Zhou wrote:
>>> On Jan 12, 2016, at 11:53 AM, Rachel Protacio 
>>> <rachel.protacio at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Thanks! Is this http://cr.openjdk.java.net/~rprotacio/8146435.01/ 
>>> what you had in mind?
>> Looks good.
>>
>> Thanks!
>>
>> Jiangli
>>
>>> Rachel
>>>
>>> On 1/12/2016 1:42 PM, Jiangli Zhou wrote:
>>>> Hi Rachel,
>>>>
>>>> Looks good. It would be also good to add comments in the tests 
>>>> explaining why they should be run with -Xshare:off.
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>>> On Jan 12, 2016, at 10:27 AM, Rachel Protacio 
>>>>> <rachel.protacio at oracle.com> wrote:
>>>>>
>>>>> Hello!
>>>>>
>>>>> Please review this fix which adds "-Xshare:off" to all UL tests' 
>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi 
>>>>> for debugging and finding the source of the problem.
>>>>>
>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>
>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>
>>>>> Thank you!
>>>>> Rachel
>


From david.holmes at oracle.com  Wed Jan 13 00:44:54 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 10:44:54 +1000
Subject: (S) RFR: 8146855: Update hotspot sources to recognize Solaris
	Studio 12u4 compiler
In-Reply-To: <56950466.7090209@oracle.com>
References: <5694934E.9030602@oracle.com> <56950466.7090209@oracle.com>
Message-ID: <56959E06.1090207@oracle.com>

On 12/01/2016 11:49 PM, Daniel D. Daugherty wrote:
> On 1/11/16 10:46 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146855
>> webrev: http://cr.openjdk.java.net/~dholmes/8146855/webrev/
>
> make/solaris/makefiles/sparcWorks.make
>      No comments.
>
> src/share/vm/runtime/vm_version.cpp
>      No comments.
>
> Thumbs up. Of course, I have to wonder why the SS12.4 compiler
> update changeset didn't fix this... :-(

Thanks Dan. I guess it just wasn't obvious that it needed doing. It 
looks like we did the same dance with the SS12.3 update. I only noticed 
because I just updated my devkit reference for Solaris builds.

David

> Dan
>
>
>>
>> Need to update ENFORCE_CC_COMPILER_REV in sparcWorks.make
>>
>> Need to update HOTSPOT_BUILD_COMPILER logic in vm_version.cpp
>>
>> Thanks,
>> David
>> -----
>>
>>
>

From gerald.thornbrugh at oracle.com  Wed Jan 13 01:05:36 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 12 Jan 2016 18:05:36 -0700
Subject: (S) RFR: 8146855: Update hotspot sources to recognize Solaris
	Studio 12u4 compiler
In-Reply-To: <5694934E.9030602@oracle.com>
References: <5694934E.9030602@oracle.com>
Message-ID: <5695A2E0.6060100@oracle.com>

Hi David,

Your changes look good.

Jerry
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146855
> webrev: http://cr.openjdk.java.net/~dholmes/8146855/webrev/
>
> Need to update ENFORCE_CC_COMPILER_REV in sparcWorks.make
>
> Need to update HOTSPOT_BUILD_COMPILER logic in vm_version.cpp
>
> Thanks,
> David
> -----
>
>


From ioi.lam at oracle.com  Wed Jan 13 01:50:10 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 12 Jan 2016 17:50:10 -0800
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56954577.90306@oracle.com>
References: <56954577.90306@oracle.com>
Message-ID: <5695AD52.803@oracle.com>

Rachel,

I don't think adding "-Xshare:off" is the correct fix. For example, 
ItablesTest.java just runs "java -version", and depends on the fact that 
at least one of the JDK classes that are implicitly loaded has an itable 
(or whatever contents that produces the "vtable index " output).

This behavior depends on internal JDK implementation and there's no 
guarantee that it will always be true. There's also no guarantee that 
the behavior will be the same across all the OS ports.

In the future, some changes of "java -version" may cause this test to 
fail only on a particular platform. I don't want someone to spend a day 
to track down some imaginative windows issues again just to find out 
that it's a test bug.

So, as I mentioned in the bug report, the tests should be written to 
load a class that *you have written* to ensure that the output will be 
there regardless of JDK implementation.

Here are other cases where the tests are dependent on unspecified behaviors:

      out.shouldContain("[Initialized").shouldContain("without side 
effects]");

      All of the output in DefaultMethodsTest.java

In fact, I think you should remove "-Xshare:off" from the tests. Adding 
-Xshare:off will also force the tests to be executed with CDS disabled, 
and would cover up problems that only show up when CDS is enabled.

Thanks
- Ioi

On 1/12/16 10:27 AM, Rachel Protacio wrote:
> Hello!
>
> Please review this fix which adds "-Xshare:off" to all UL tests' 
> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for 
> debugging and finding the source of the problem.
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>
> Tests sent to JPRT, pass on all platforms.
>
> Thank you!
> Rachel


From david.holmes at oracle.com  Wed Jan 13 02:14:35 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 12:14:35 +1000
Subject: (S) RFR: 8146855: Update hotspot sources to recognize Solaris
	Studio 12u4 compiler
In-Reply-To: <5695A2E0.6060100@oracle.com>
References: <5694934E.9030602@oracle.com> <5695A2E0.6060100@oracle.com>
Message-ID: <5695B30B.6060805@oracle.com>

Thanks Jerry!

David

On 13/01/2016 11:05 AM, Gerald Thornbrugh wrote:
> Hi David,
>
> Your changes look good.
>
> Jerry
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146855
>> webrev: http://cr.openjdk.java.net/~dholmes/8146855/webrev/
>>
>> Need to update ENFORCE_CC_COMPILER_REV in sparcWorks.make
>>
>> Need to update HOTSPOT_BUILD_COMPILER logic in vm_version.cpp
>>
>> Thanks,
>> David
>> -----
>>
>>
>

From david.holmes at oracle.com  Wed Jan 13 02:27:37 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 12:27:37 +1000
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <1452593030.28862.11.camel@mylittlepony.linaroharston>
References: <56947024.3040002@oracle.com> <56948FB9.3050807@oracle.com>
	<56949592.6040107@oracle.com>
	<1452593030.28862.11.camel@mylittlepony.linaroharston>
Message-ID: <5695B619.8060509@oracle.com>

On 12/01/2016 8:03 PM, Edward Nevill wrote:
> On Tue, 2016-01-12 at 15:56 +1000, David Holmes wrote:
>> On 12/01/2016 3:31 PM, Dean Long wrote:
>>> How about moving it to "globalDefinitions_arm.hpp"?  You would just need
>>> to do #undef BREAKPOINT first.
>>
>> It would also need, technically, to be conditional upon using gcc.
>>
>> I also don't know if the aarch32 port would be using this. ??
>
> cc: aarch32-port-dev
>
> The aarch32 currently does not define 'ARM32' so this code is not being included in the current port.
>
> The aarch32 port does define 'ARM' so any code that is #ifdef ARM is included in the aarch32 port.
>
> So, moving this code to globalDefinitions_arm.hpp will have no impact on the aarch32 port.

Thanks Ed. Okay updated webrev in place:

http://cr.openjdk.java.net/~dholmes/8077648/webrev/

All ARM related code removed.

Thanks,
David
-----

> All the best,
> Ed.
>
>

From david.holmes at oracle.com  Wed Jan 13 02:45:37 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 12:45:37 +1000
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <5695AD52.803@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
Message-ID: <5695BA51.6080408@oracle.com>

I agree with Ioi. This is similar to the monitor inflation/deflation 
logging test - we need to ensure we use something guaranteed to always 
generate the expected log output.

Thanks,
David

On 13/01/2016 11:50 AM, Ioi Lam wrote:
> Rachel,
>
> I don't think adding "-Xshare:off" is the correct fix. For example,
> ItablesTest.java just runs "java -version", and depends on the fact that
> at least one of the JDK classes that are implicitly loaded has an itable
> (or whatever contents that produces the "vtable index " output).
>
> This behavior depends on internal JDK implementation and there's no
> guarantee that it will always be true. There's also no guarantee that
> the behavior will be the same across all the OS ports.
>
> In the future, some changes of "java -version" may cause this test to
> fail only on a particular platform. I don't want someone to spend a day
> to track down some imaginative windows issues again just to find out
> that it's a test bug.
>
> So, as I mentioned in the bug report, the tests should be written to
> load a class that *you have written* to ensure that the output will be
> there regardless of JDK implementation.
>
> Here are other cases where the tests are dependent on unspecified
> behaviors:
>
>       out.shouldContain("[Initialized").shouldContain("without side
> effects]");
>
>       All of the output in DefaultMethodsTest.java
>
> In fact, I think you should remove "-Xshare:off" from the tests. Adding
> -Xshare:off will also force the tests to be executed with CDS disabled,
> and would cover up problems that only show up when CDS is enabled.
>
> Thanks
> - Ioi
>
> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>> Hello!
>>
>> Please review this fix which adds "-Xshare:off" to all UL tests'
>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for
>> debugging and finding the source of the problem.
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>
>> Tests sent to JPRT, pass on all platforms.
>>
>> Thank you!
>> Rachel
>

From david.holmes at oracle.com  Wed Jan 13 02:49:41 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 12:49:41 +1000
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <569564C9.6040400@oracle.com>
References: <5693E00A.1090001@oracle.com> <56949DAD.5060606@oracle.com>
	<5695620C.7080109@oracle.com> <569564C9.6040400@oracle.com>
Message-ID: <5695BB45.5000309@oracle.com>

Hi Max,

On 13/01/2016 6:40 AM, harold seigel wrote:
> Hi Max,
>
> Other than the copyright dates and minor #include alphabetizing the
> changes look good.

I agree with Harold.

Thanks,
David

> Harold
>
> On 1/12/2016 3:29 PM, Max Ockner wrote:
>> David,
>> Originally, VAR_LOG_TAGS was included to help use the configure_stdout
>> function. Marcus has suggested that I don't need it so I have removed it.
>> New webrev: http://cr.openjdk.java.net/~mockner/aliastable.04/
>> Thanks,
>> Max
>> On 1/12/2016 1:31 AM, David Holmes wrote:
>>> Hi Max,
>>>
>>> On 12/01/2016 3:02 AM, Max Ockner wrote:
>>>> Hello all,
>>>> Please review my fix which reorganizes the alias table for Unified
>>>> Logging.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
>>>> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/
>>>
>>> Is this supposed to contain the VAR_LOG_TAGS changes?
>>>
>>> Is the "deprecation" of the converted tracing flags still to be added?
>>>
>>> Otherwise seems okay.
>>>
>>> Thanks,
>>> David
>>>
>>>> Summary:
>>>> How logging aliases used to handled - At the beginning of
>>>> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument would be
>>>> looked up in the logging alias table to see if there was a match. If a
>>>> match was found, then the entire argument would be replaced by a
>>>> corresponding unified logging argument. This argument would then
>>>> cascade
>>>> through the giant case structure until it was caught and handled close
>>>> to the bottom of parse_each_vm_init_arg (which happens hundreds of
>>>> lines
>>>> later).
>>>>
>>>> There is a section of code that handles aliases and deprecation for -XX
>>>> options already. After this fix, logging aliases will be handled here
>>>> instead of substituting entire logging expressions at the beginning of
>>>> parse_each_vm_init_arg.
>>>>
>>>> Tested with jtreg runtime tests. This includes several logging tests
>>>> for
>>>> recently aliased flags.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>
>

From dean.long at oracle.com  Wed Jan 13 07:24:56 2016
From: dean.long at oracle.com (Dean Long)
Date: Tue, 12 Jan 2016 23:24:56 -0800
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <5695B619.8060509@oracle.com>
References: <56947024.3040002@oracle.com> <56948FB9.3050807@oracle.com>
	<56949592.6040107@oracle.com>
	<1452593030.28862.11.camel@mylittlepony.linaroharston>
	<5695B619.8060509@oracle.com>
Message-ID: <5695FBC8.3000605@oracle.com>

Looks good.

dl

On 1/12/2016 6:27 PM, David Holmes wrote:
> On 12/01/2016 8:03 PM, Edward Nevill wrote:
>> On Tue, 2016-01-12 at 15:56 +1000, David Holmes wrote:
>>> On 12/01/2016 3:31 PM, Dean Long wrote:
>>>> How about moving it to "globalDefinitions_arm.hpp"?  You would just 
>>>> need
>>>> to do #undef BREAKPOINT first.
>>>
>>> It would also need, technically, to be conditional upon using gcc.
>>>
>>> I also don't know if the aarch32 port would be using this. ??
>>
>> cc: aarch32-port-dev
>>
>> The aarch32 currently does not define 'ARM32' so this code is not 
>> being included in the current port.
>>
>> The aarch32 port does define 'ARM' so any code that is #ifdef ARM is 
>> included in the aarch32 port.
>>
>> So, moving this code to globalDefinitions_arm.hpp will have no impact 
>> on the aarch32 port.
>
> Thanks Ed. Okay updated webrev in place:
>
> http://cr.openjdk.java.net/~dholmes/8077648/webrev/
>
> All ARM related code removed.
>
> Thanks,
> David
> -----
>
>> All the best,
>> Ed.
>>
>>


From marcus.larsson at oracle.com  Wed Jan 13 08:06:04 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 13 Jan 2016 09:06:04 +0100
Subject: RFR: 8146800: Reorganize logging alias code.
In-Reply-To: <5695BB45.5000309@oracle.com>
References: <5693E00A.1090001@oracle.com> <56949DAD.5060606@oracle.com>
	<5695620C.7080109@oracle.com> <569564C9.6040400@oracle.com>
	<5695BB45.5000309@oracle.com>
Message-ID: <5696056C.6090700@oracle.com>

Hi,

On 01/13/2016 03:49 AM, David Holmes wrote:
> Hi Max,
>
> On 13/01/2016 6:40 AM, harold seigel wrote:
>> Hi Max,
>>
>> Other than the copyright dates and minor #include alphabetizing the
>> changes look good.
>
> I agree with Harold.

+1

Thanks,
Marcus

>
> Thanks,
> David
>
>> Harold
>>
>> On 1/12/2016 3:29 PM, Max Ockner wrote:
>>> David,
>>> Originally, VAR_LOG_TAGS was included to help use the configure_stdout
>>> function. Marcus has suggested that I don't need it so I have 
>>> removed it.
>>> New webrev: http://cr.openjdk.java.net/~mockner/aliastable.04/
>>> Thanks,
>>> Max
>>> On 1/12/2016 1:31 AM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 12/01/2016 3:02 AM, Max Ockner wrote:
>>>>> Hello all,
>>>>> Please review my fix which reorganizes the alias table for Unified
>>>>> Logging.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146800
>>>>> webrev: http://cr.openjdk.java.net/~mockner/aliastable.03/
>>>>
>>>> Is this supposed to contain the VAR_LOG_TAGS changes?
>>>>
>>>> Is the "deprecation" of the converted tracing flags still to be added?
>>>>
>>>> Otherwise seems okay.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Summary:
>>>>> How logging aliases used to handled - At the beginning of
>>>>> parse_each_vm_init_arg() in arguments.cpp, each "-XX" argument 
>>>>> would be
>>>>> looked up in the logging alias table to see if there was a match. 
>>>>> If a
>>>>> match was found, then the entire argument would be replaced by a
>>>>> corresponding unified logging argument. This argument would then
>>>>> cascade
>>>>> through the giant case structure until it was caught and handled 
>>>>> close
>>>>> to the bottom of parse_each_vm_init_arg (which happens hundreds of
>>>>> lines
>>>>> later).
>>>>>
>>>>> There is a section of code that handles aliases and deprecation 
>>>>> for -XX
>>>>> options already. After this fix, logging aliases will be handled here
>>>>> instead of substituting entire logging expressions at the 
>>>>> beginning of
>>>>> parse_each_vm_init_arg.
>>>>>
>>>>> Tested with jtreg runtime tests. This includes several logging tests
>>>>> for
>>>>> recently aliased flags.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>
>>


From david.holmes at oracle.com  Wed Jan 13 09:18:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 19:18:49 +1000
Subject: (S) RFR: 8077648: ARM: BREAKPOINT is wrong for thumb
In-Reply-To: <5695FBC8.3000605@oracle.com>
References: <56947024.3040002@oracle.com> <56948FB9.3050807@oracle.com>
	<56949592.6040107@oracle.com>
	<1452593030.28862.11.camel@mylittlepony.linaroharston>
	<5695B619.8060509@oracle.com> <5695FBC8.3000605@oracle.com>
Message-ID: <56961679.30900@oracle.com>

Thanks Dean!

David

On 13/01/2016 5:24 PM, Dean Long wrote:
> Looks good.
>
> dl
>
> On 1/12/2016 6:27 PM, David Holmes wrote:
>> On 12/01/2016 8:03 PM, Edward Nevill wrote:
>>> On Tue, 2016-01-12 at 15:56 +1000, David Holmes wrote:
>>>> On 12/01/2016 3:31 PM, Dean Long wrote:
>>>>> How about moving it to "globalDefinitions_arm.hpp"?  You would just
>>>>> need
>>>>> to do #undef BREAKPOINT first.
>>>>
>>>> It would also need, technically, to be conditional upon using gcc.
>>>>
>>>> I also don't know if the aarch32 port would be using this. ??
>>>
>>> cc: aarch32-port-dev
>>>
>>> The aarch32 currently does not define 'ARM32' so this code is not
>>> being included in the current port.
>>>
>>> The aarch32 port does define 'ARM' so any code that is #ifdef ARM is
>>> included in the aarch32 port.
>>>
>>> So, moving this code to globalDefinitions_arm.hpp will have no impact
>>> on the aarch32 port.
>>
>> Thanks Ed. Okay updated webrev in place:
>>
>> http://cr.openjdk.java.net/~dholmes/8077648/webrev/
>>
>> All ARM related code removed.
>>
>> Thanks,
>> David
>> -----
>>
>>> All the best,
>>> Ed.
>>>
>>>
>

From markus.gronlund at oracle.com  Wed Jan 13 10:35:39 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 13 Jan 2016 02:35:39 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5695773E.5000504@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
Message-ID: <6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>

Hi Coleen,

The Test_TempNewSymbol() look fine - thank you for adding it.

Maybe you could also complement with a simple self-assignment test as well?  
...

  s1 = s1; // self assignment
  assert(s1->refcount() == 2, "should still be two abc (s1 and ss)");

...

Thanks!
Markus


-----Original Message-----
From: Coleen Phillimore 
Sent: den 12 januari 2016 22:59
To: Markus Gronlund; Kim Barrett
Cc: hotspot-runtime-dev
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions



On 1/12/16 7:34 AM, Markus Gronlund wrote:
> Hi Kim,
>
> Thanks a lot for the (detailed) reminder about the copy-and-swap idiom. I agree with your reasoning.

Two for (strongly?) and two against (myself, not so strongly and we can always add a comment to save someone else's time).  I can change it (hoping my test still pass).  Did you look at the test?
>
> About the return value from operator=, I would suggest retaining the void as-is as well.

Ok
>
> Maybe we should investigate if it is possible to have the functions in SymbolTable that increment Symbol*'s return a TempNewSymbol( or some other "smartptr" concept) instead of a direct Symbol*?

When changing symbolOops symbolHandles, to Symbol* with refcounting I had an implementation using SymbolHandle as a smart pointer.  I think I had the assignment operator transfer ownership of the pointer, iirc.  I had added reference counting statistics at that time (which I have 
output in my RFR).   My memory was that the number of Atomic:: add and 
subtract operations were an order of magnitude larger.  I saved a lot of email on this except the numbers.  Symbols mostly come into the JVM through the constant pool, with these exceptions that use TempNewSymbol.

>
> In that case we could make the type conversion constructor private and make SymbolTable a friend of TempNewSymbol - this would avoid accidental wrapping of arbitrary Symbol*'s. I will look into the possibility of this.

This sounds like a good idea.

Thanks,
Coleen
>
> Thanks again for your clarification
> Markus
>
> -----Original Message-----
> From: Kim Barrett
> Sent: den 12 januari 2016 05:22
> To: Coleen Phillimore
> Cc: hotspot-runtime-dev
> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy 
> and assignment functions
>
> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>> Kim and Lois,
>>
>> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
>>
>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>
>> See comments below.
>>
>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>>>
>>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>>>
>>>>   Percent removed          1.35
>>>>   Reference counts          194583
>>>>
>>>> clean:
>>>>
>>>>   Percent removed          1.53
>>>>   Reference counts          194245
>>>>
>>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>>>
>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>
>>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>
>>>> Thanks,
>>>> Coleen
>>> For the assignment operator, I think better is:
>>>
>>> void operator=(TempNewSymbol s) {
>>>    Symbol* tmp = s._temp;
>>>    s._temp = _temp;
>>>    _temp = tmp;
>>> }
>>>
>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>
>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap
>>> -
>>> idiom
>> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.
> Copy-swap saves several refcount manipulations in some (common) cases, by taking advantage of rvalue copy elision.
>
> Coleen's:
>
> void operator=(const TempNewSymbol& s) {
>    clear();
>    _temp = s._temp;
>    if (_temp != NULL) _temp->increment_refcount(); }
>
> Markus's:
>
> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>    if (this != &rhs && _temp != rhs._temp) {
>      clear();
>      _temp = rhs._temp;
>      if (_temp != NULL) {
>        _temp->increment_refcount();
>      }
>    }
>    return *this;
> }
>
> Kim's:
>
> void operator=(TempNewSymbol rhs) {
>    Symbol* tmp = rhs._temp;
>    rhs._temp = _temp;
>    _temp = tmp;
> }
>
> [I'm ignoring differences in the return value in the discussion below.
> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>
> Markus's is mostly the same as Coleen's, except it handles a couple of special cases differently.
>
> Markus's handles self-assignment, where Coleen's doesn't. For correctness that's important; in actual practice self-assignment is generally rare to non-existent, so always paying overhead for it is unpleasant.
>
> Markus's also specially handles re-assignment to the same symbol, avoiding any refcount changes in that case.  I suggest this is another rare case, and adding overhead in the normal case to get that rare benefit is not the right tradeoff.
>
> Assuming we're not in one of those special cases and neither Symbol* is NULL, Coleen/Markus decrements the old and increments the new. And in an important special case where rhs is an rvalue, there will be another decrement as the temporary goes out of scope. So two refcount changes when rhs is an lvalue, three when it's an rvalue.
>
> In contrast, Kim's does an increment and a decrement when rhs is an lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy elision is performed by the compiler, which any decent optimizing compiler will do.
>
> The rhs is an rvalue in the following situation:
>
>    TempNewSymbol tns = ... ;
>    ...
>    tns = expr_returning_Symbol* ;
>
> The rhs gets implicitly converted to a temporary (rvalue) TempNewSymbol referring to the symbol (no refcount change), that temporary is directly bound to the assignment argument (copy elided), swap the symbols, and the rvalue converted temp goes out of scope and decrements the refcount of the old Symbol*.
>
> The copy-swap version also handles the (rare) self-assignment and re-assignment to the same symbol cases. In these cases Kim's still does the same refcounting changes as otherwise.  But it's better to do extra work in the rare cases and keep the normal cases fast.
>
> This is why copy-swap has become the "usual idiom"for assignment operators. There might be cases where it's not the best answer, but usually it is. And this is why (to answer Lois's issue) one should use it even though it's not obvious if one is not previously familiar with the idiom; one should instead learn the idiom, and then one spends time looking hard at implementations that do something else.
>
> Of course, this may all be entirely in the noise; I hope that TempNewSymbol assignment is not a high frequency operation.
>
>
>>> I think the updated description of TempNewSymbol isn't really right.
>>> Because the conversion constructor doesn't increment the reference 
>>> count, it must *not* be used to capture some arbitrary reference to 
>>> a Symbol*. Only a new symbol or one obtained from one of the lookup 
>>> functions really should be managed by this class.
>> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
>>
>> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.
> I was confused about which webrev I was looking at.  Coleen's doesn't seem to change those comments.
> It was (parts of) Markus's comments that worried me.  And the whole design is tricky and risky.
>


From goetz.lindenmaier at sap.com  Wed Jan 13 11:13:25 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 13 Jan 2016 11:13:25 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <569369F3.2030900@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<56930CB3.5090906@oracle.com>
	<CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
	<569369F3.2030900@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F13C99@DEWDFEMB12A.global.corp.sap>

Hi David, 

do I understand this correctly that you are fine with this change?

Thanks,
  Goetz.

> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Montag, 11. Januar 2016 09:38
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> On 11/01/2016 5:56 PM, Volker Simonis wrote:
> > On Mon, Jan 11, 2016 at 3:00 AM, David Holmes
> <david.holmes at oracle.com> wrote:
> >> On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
> >>>
> >>> Hi David,
> >>>
> >>>> I still don't see how adding inline to the declaration changes anything
> >>>> here. The compiler can't do the inlining unless the .inline.hpp file has
> >>>> been included. ???
> >>>
> >>> Yes, and therefore it issues an error if the keyword is in the .hpp
> >>> header:
> >>>
> >>> In file included from
> >>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/utilities/hashtable.cpp:27:0:
> >>>
> >>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
> rt/src/share/vm/classfile/javaClasses.hpp:113:30:
> >>> error: inline function 'static typeArrayOopDesc*
> >>> java_lang_String::value(oop)' used but never defined [-Werror]
> >>>      static inline typeArrayOop value(oop java_string);
> >>>
> >>> So you can not miss including the inline.hpp header.
> >>
> >>
> >> Won't you get a link time failure in any case ?
> >>
> >
> > With some compilers. But if the method has external linkage the
> > compiler usually instantiates a version of the method even if it is
> > not called.
> >
> >>
> >> I'm just concerned we are relying on unspecified compiler behaviour
> which
> >> might change in the future. The docs say you don't put "inline" on the
> >> declaration. What's to stop the next version of the compiler from flagging
> >> that as a warning?
> >>
> >
> > Who did ever ever claime that putting the inline specifier on both,
> > definition AND declaration is unspecified compiler behaviour?
> 
> That isn't what I meant. The unspecified part is how the compiler
> responds to seeing an inline declaration but not the definition.
> 
> > just plain wrong! Please simply read the C++ Standard [1]. It clearly
> > states in paragraph 2 of section 9.3: "...An inline member function
> > (whether static or non-static) may also be defined outside of its
> > class definition provided either its declaration in the class
> > definition or its definition outside of the class definition declares
> > the function as inline...".
> 
> Yes it does - though 7.1.2 also claims "inline" is only valid on a
> declaration. And 9.3 seems at odds with the FAQ referenced as well.
> 
> Okay - the main point is that making the declaration inline is legal, so
> no compiler should be rejecting it. Even if it also doesn't provide any
> additional diagnostics.
> 
> Thanks for clarifying.
> 
> David
> -----
> 
> > What has been cited here so far (e.g. [2]) is simply an advice (and
> > not more!) which shouldn't be confused with the language
> > specification! The reason behind the advice to 'place the inline
> > specifier on the method definition rather than on its declaration' is
> > because the writer deems it an implementation detail. BUT you have to
> > take into account that in the HotSpot code base we already have the
> > subdivision of header files into "true" .hpp files and .inline.hpp
> > files anyway. We've done that because of performance reasons and thus
> > already put the burden of deciding which one is required on the user
> > anyway. So the argument raised in [2] that the "inlineness" of a
> > method is "an implementation detail" doesn't quite hold true for the
> > HotSpot code base.
> >
> > And once again - Goetz's change helps in ensuring that methods which
> > are declared inline will be always visible at call sites and thus
> > valid inline candidates. If this is not the case we will now (with
> > Goetz's change) get a compiler warning where we just silently got a
> > plain function call before.
> >
> > Regards,
> > Volker
> >
> > [1] http://www.open-
> std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> > [2] https://isocpp.org/wiki/faq/inline-functions#where-to-put-inline-
> keyword
> >
> >> Thanks,
> >>
> >> David
> >>
> >>> Best regards,
> >>>     Goetz.
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>> Sent: Freitag, 8. Januar 2016 08:54
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>>> dev at openjdk.java.net
> >>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> and
> >>>> fix
> >>>> header files
> >>>>
> >>>>
> >>>>
> >>>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>> Sent: Freitag, 8. Januar 2016 06:07
> >>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> runtime-
> >>>>>> dev at openjdk.java.net
> >>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
> >>>>>> and
> >>>>
> >>>> fix
> >>>>>>
> >>>>>> header files
> >>>>>>
> >>>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
> >>>>>>>
> >>>>>>> Hi David,
> >>>>>>>
> >>>>>>> the documentation you point to makes the point that whether to
> inline
> >>>>>>> is an implementation detail, and that that should not be annotated
> to
> >>>>>>> the declaration.  Basically, this is a good point.
> >>>>>>>
> >>>>>>> But the documentation does not cover the fact that
> >>>>>>> we have the implementation in a different file than the declaration.
> >>>>>>> The .inline.hpp is not included always (as you pointed out).
> >>>>>>>
> >>>>>>> Therefore, if we compile with precompiled headers, we get more
> >>>>>>> inlines than if we do so without.
> >>>>>>> Further, many functions were moved to oop.linline.hpp during the
> >>>>>>> recent cleanups, and I think all the #includes I had to add were not
> >>>>>>> left out deliberately, but just happened because the compiler did
> >>>>>>> not complain.
> >>>>>>> I think if somebody decides not to place a function implementation
> >>>>>>> in a .cpp file, it should have the chance to be inlined at all it's
> >>>>>>> calls.
> >>>>>>> Putting the 'inline' into the .hpp file assures this.
> >>>>>>
> >>>>>>
> >>>>>> Sorry I don't follow that. If you include the .inline.hpp you don't
> >>>>>> need
> >>>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
> >>>>>> have access to the definition so that it can be inlined.
> >>>>>
> >>>>> Yes.
> >>>>>
> >>>>>> it seems to me that if
> >>>>>> you want it inlined then you must include the .inline.hpp anywhere it
> >>>>>> is
> >>>>>> needed. Anything else seems a bad-aid.
> >>>>>
> >>>>> But I think not the caller should decide whether it's to be inlined,
> >>>>> but the implementor of the method (and next the compiler).
> >>>>> As you describe, the caller has to decide which header to include.
> >>>>> So the caller has to know implementation details of the callee,
> >>>>> which is contrary to the encapsulation described in that
> documentation.
> >>>>
> >>>>
> >>>> That's my understanding of the way things are expected to work. This is
> >>>> not a public library exporting its interface in a .hpp file, this an
> >>>> internal part of the bigger system. As I understand it we define the
> >>>> .inline.hpp file precisely so that clients can include it. And yes the
> >>>> clients have to know to do that.
> >>>>
> >>>>> If you add the 'inline' keyword in the header, the compiler enforces
> >>>>> that the includes are in a way that it can do what the implementor
> >>>>> of the callee / of the method to be inlined intended.
> >>>>
> >>>>
> >>>> I still don't see how adding inline to the declaration changes anything
> >>>> here. The compiler can't do the inlining unless the .inline.hpp file has
> >>>> been included. ???
> >>>
> >>> Yes, but it issues a warning and  will abort if it's wrong.
> >>>
> >>>
> >>>>
> >>>> Cheers,
> >>>> David
> >>>> -----
> >>>>
> >>>>
> >>>>>> Maybe
> >>>>>> precompiled headers messes with that somehow
> >>>>>
> >>>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
> >>>>> is it dragged in by some other .inline.hpp header.
> >>>>> I would assume this is a remnant of the problems with this header.
> >>>>> But if it was listed there, it would make a difference.
> >>>>>
> >>>>> To put it the other way round: do you think all the places I had to
> >>>>> clean up are well founded decisions not to include the methods
> >>>>> from oop.inline.hpp?
> >>>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
> >>>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
> >>>>> unintuitive to me.
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >>>>
> >>>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> >>>>>
> >>>>> (I'll add the inline keyword in a follow-up change for gc files, in case
> >>>>> this change is accepted.)
> >>>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>> David
> >>>>>>
> >>>>>>> Best regards,
> >>>>>>>       Goetz.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
> >>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
> >>>>
> >>>> runtime-
> >>>>>>>>
> >>>>>>>> dev at openjdk.java.net
> >>>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline
> directives
> >>>>
> >>>> and
> >>>>>>
> >>>>>> fix
> >>>>>>>>
> >>>>>>>> header files
> >>>>>>>>
> >>>>>>>> Hi Goetz,
> >>>>>>>>
> >>>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in
> real
> >>>>
> >>>> .hpp
> >>>>>>>>
> >>>>>>>> header file.
> >>>>>>>>>
> >>>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
> >>>>>>>>
> >>>>>>>> implementations
> >>>>>>>>>
> >>>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
> >>>>>>>>> Therefore,
> >>>>>>
> >>>>>> the
> >>>>>>>>>
> >>>>>>>>> compiler can not detect failing inlines properly.
> >>>>>>>>>
> >>>>>>>>> This change moves the inline directive from oop.inline.hpp to
> >>>>
> >>>> oop.hpp.
> >>>>>>>>
> >>>>>>>> Also
> >>>>>>>>
> >>>>>>>> This seems contrary to the C++ FAQ:
> >>>>>>>>
> >>>>>>>> https://isocpp.org/wiki/faq/inline-functions
> >>>>>>>>
> >>>>>>>> The declaration in the .hpp should not have inline, only the
> >>>>>>>> definition,
> >>>>>>>> which in our case is in the .inline.hpp file.
> >>>>>>>>
> >>>>>>>> Any code that includes the .inline.hpp will have seen the
> definition
> >>>>>>>> of
> >>>>>>>> the inline function prior to its use - as long as the includes are
> >>>>>>>> correct.
> >>>>>>>>
> >>>>>>>> David
> >>>>>>>> -----
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
> >>>>>>>>> oop.hpp.
> >>>>>>>>>
> >>>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or
> >>>>>>>>> .cpp
> >>>>
> >>>> files.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
> >>>>>>>>> this is a
> >>>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
> >>>>>>>>> acceptable.
> >>>>>>>>>
> >>>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't
> want
> >>>>>>>>> to
> >>>>
> >>>> do
> >>>>>>>>>
> >>>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
> >>>>>>>>> to
> >>>>>>>>> freqent changes recently.
> >>>>>>>>>
> >>>>>>>>> The following methods were moved to .cpp files:
> >>>>>>>>>
> >>>>>>>>> ProtectionDomainCacheTable::compute_hash()
> >>>>>>>>> ProtectionDomainCacheTable::index_for()
> >>>>>>>>> typeArrayOopDesc::object_size()
> >>>>>>>>> This is called only once outside .cpp file:
> >>>>>>>>> CallSiteDepChange::CallSiteDepChange()
> >>>>>>>>> This is only called in .cpp file
> >>>>>>>>> ConstantPool::string_at_put()
> >>>>>>>>>
> >>>>>>>>> If someone considers not inlining these harmful to performance,
> >>>>>>>>> I will add a new .inline.hpp file for them.
> >>>>>>>>>
> >>>>>>>>> Please review this change.  I please need a sponsor.
> >>>>>>>>> There are no functional edits, so it should be simple to review.
> >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >>>>>>
> >>>>>> rt/webrev.01/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>>        Goetz.
> >>>>>>>>>
> >>

From goetz.lindenmaier at sap.com  Wed Jan 13 11:48:07 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 13 Jan 2016 11:48:07 +0000
Subject: RFR(m): 8145184: [aix] Implement
	os::platform_print_native_stack	on AIX
In-Reply-To: <CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
References: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
	<CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap>

Hi Thomas,

I had a look at your change. 

The construction with #ifndef PLATFORM_PRINT_NATIVE_STACK is quite 
unconventional ... but it was there before, so it's not an issue of your change.

It's good to have this now, I've experienced missing stack traces before. 

Is it necessary to use macro ERRBYE?  It doesn't really help reading the 
code, as the 'return' is hidden in it.  I would remove it with this change.

Don't you have to remove the '== 0' here?  You changed the return value from '0' to true.
-      if (getFuncName((codeptr_t) p, funcname, sizeof(funcname), &displacement,
-                      NULL, NULL, 0, false) == 0) {
+      if (AixSymbols::get_function_name(p, funcname, sizeof(funcname),
+                      &displacement, NULL, true) == 0) {

Get_module_name has wrong indentation of parameters.  Probably they fit into
one line.

Besides that looks good.

Best regards,
  Goetz.




> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Montag, 11. Januar 2016 14:40
> To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-
> dev at openjdk.java.net
> Subject: Re: RFR(m): 8145184: [aix] Implement
> os::platform_print_native_stack on AIX
> 
> Hi all,
> 
> could I please have a review?
> 
> Thank you!
> 
> ..Thomas
> 
> On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe
> <thomas.stuefe at gmail.com>
> wrote:
> 
> > Hi all,
> >
> > please review this AIX-only patch.
> >
> > This ports a more sophisticated native callstack printer for AIX to the
> > OpenJDK. It prints out more information and is more robust in cases the
> > stack is corrupted.
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8145184
> > webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-
> os_platform_print_native_stack/webrev.00/webrev/
> >
> > Note that also some of functions were moved and made more coding-
> conform
> > to the OpenJDK: the old getFuncName() and getModuleName() functions
> are
> > moved to AixSymbols::get_function_name() and
> AixSymbols::get_module_name().
> >
> > Thanks and Kind Regards, Thomas
> >

From david.holmes at oracle.com  Wed Jan 13 12:25:59 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Jan 2016 22:25:59 +1000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
	header files
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F13C99@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C9EFC.8050304@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F249@DEWDFEMB12A.global.corp.sap>
	<568F43EF.5090908@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F586@DEWDFEMB12A.global.corp.sap>
	<568F6B11.7020603@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F63C@DEWDFEMB12A.global.corp.sap>
	<56930CB3.5090906@oracle.com>
	<CA+3eh10tPQiX9=1_r9A65gzYA5A0TcS-tfsaisVpEyQ39D4WRg@mail.gmail.com>
	<569369F3.2030900@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F13C99@DEWDFEMB12A.global.corp.sap>
Message-ID: <56964257.4080300@oracle.com>

On 13/01/2016 9:13 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> do I understand this correctly that you are fine with this change?

Yes.

Thanks.
David

> Thanks,
>    Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Montag, 11. Januar 2016 09:38
>> To: Volker Simonis <volker.simonis at gmail.com>
>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
>> header files
>>
>> On 11/01/2016 5:56 PM, Volker Simonis wrote:
>>> On Mon, Jan 11, 2016 at 3:00 AM, David Holmes
>> <david.holmes at oracle.com> wrote:
>>>> On 8/01/2016 7:31 PM, Lindenmaier, Goetz wrote:
>>>>>
>>>>> Hi David,
>>>>>
>>>>>> I still don't see how adding inline to the declaration changes anything
>>>>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>>>>> been included. ???
>>>>>
>>>>> Yes, and therefore it issues an error if the keyword is in the .hpp
>>>>> header:
>>>>>
>>>>> In file included from
>>>>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
>> rt/src/share/vm/utilities/hashtable.cpp:27:0:
>>>>>
>>>>> /sapmnt/home/d045726/oJ/8146401-oopInline-rt-hs-
>> rt/src/share/vm/classfile/javaClasses.hpp:113:30:
>>>>> error: inline function 'static typeArrayOopDesc*
>>>>> java_lang_String::value(oop)' used but never defined [-Werror]
>>>>>       static inline typeArrayOop value(oop java_string);
>>>>>
>>>>> So you can not miss including the inline.hpp header.
>>>>
>>>>
>>>> Won't you get a link time failure in any case ?
>>>>
>>>
>>> With some compilers. But if the method has external linkage the
>>> compiler usually instantiates a version of the method even if it is
>>> not called.
>>>
>>>>
>>>> I'm just concerned we are relying on unspecified compiler behaviour
>> which
>>>> might change in the future. The docs say you don't put "inline" on the
>>>> declaration. What's to stop the next version of the compiler from flagging
>>>> that as a warning?
>>>>
>>>
>>> Who did ever ever claime that putting the inline specifier on both,
>>> definition AND declaration is unspecified compiler behaviour?
>>
>> That isn't what I meant. The unspecified part is how the compiler
>> responds to seeing an inline declaration but not the definition.
>>
>>> just plain wrong! Please simply read the C++ Standard [1]. It clearly
>>> states in paragraph 2 of section 9.3: "...An inline member function
>>> (whether static or non-static) may also be defined outside of its
>>> class definition provided either its declaration in the class
>>> definition or its definition outside of the class definition declares
>>> the function as inline...".
>>
>> Yes it does - though 7.1.2 also claims "inline" is only valid on a
>> declaration. And 9.3 seems at odds with the FAQ referenced as well.
>>
>> Okay - the main point is that making the declaration inline is legal, so
>> no compiler should be rejecting it. Even if it also doesn't provide any
>> additional diagnostics.
>>
>> Thanks for clarifying.
>>
>> David
>> -----
>>
>>> What has been cited here so far (e.g. [2]) is simply an advice (and
>>> not more!) which shouldn't be confused with the language
>>> specification! The reason behind the advice to 'place the inline
>>> specifier on the method definition rather than on its declaration' is
>>> because the writer deems it an implementation detail. BUT you have to
>>> take into account that in the HotSpot code base we already have the
>>> subdivision of header files into "true" .hpp files and .inline.hpp
>>> files anyway. We've done that because of performance reasons and thus
>>> already put the burden of deciding which one is required on the user
>>> anyway. So the argument raised in [2] that the "inlineness" of a
>>> method is "an implementation detail" doesn't quite hold true for the
>>> HotSpot code base.
>>>
>>> And once again - Goetz's change helps in ensuring that methods which
>>> are declared inline will be always visible at call sites and thus
>>> valid inline candidates. If this is not the case we will now (with
>>> Goetz's change) get a compiler warning where we just silently got a
>>> plain function call before.
>>>
>>> Regards,
>>> Volker
>>>
>>> [1] http://www.open-
>> std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
>>> [2] https://isocpp.org/wiki/faq/inline-functions#where-to-put-inline-
>> keyword
>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>>> Best regards,
>>>>>      Goetz.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Freitag, 8. Januar 2016 08:54
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>> and
>>>>>> fix
>>>>>> header files
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/01/2016 5:28 PM, Lindenmaier, Goetz wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Freitag, 8. Januar 2016 06:07
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> runtime-
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives
>>>>>>>> and
>>>>>>
>>>>>> fix
>>>>>>>>
>>>>>>>> header files
>>>>>>>>
>>>>>>>> On 8/01/2016 1:01 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> the documentation you point to makes the point that whether to
>> inline
>>>>>>>>> is an implementation detail, and that that should not be annotated
>> to
>>>>>>>>> the declaration.  Basically, this is a good point.
>>>>>>>>>
>>>>>>>>> But the documentation does not cover the fact that
>>>>>>>>> we have the implementation in a different file than the declaration.
>>>>>>>>> The .inline.hpp is not included always (as you pointed out).
>>>>>>>>>
>>>>>>>>> Therefore, if we compile with precompiled headers, we get more
>>>>>>>>> inlines than if we do so without.
>>>>>>>>> Further, many functions were moved to oop.linline.hpp during the
>>>>>>>>> recent cleanups, and I think all the #includes I had to add were not
>>>>>>>>> left out deliberately, but just happened because the compiler did
>>>>>>>>> not complain.
>>>>>>>>> I think if somebody decides not to place a function implementation
>>>>>>>>> in a .cpp file, it should have the chance to be inlined at all it's
>>>>>>>>> calls.
>>>>>>>>> Putting the 'inline' into the .hpp file assures this.
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry I don't follow that. If you include the .inline.hpp you don't
>>>>>>>> need
>>>>>>>> "inline" in the .hpp. If you don't include it then the compiler doesn't
>>>>>>>> have access to the definition so that it can be inlined.
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>> it seems to me that if
>>>>>>>> you want it inlined then you must include the .inline.hpp anywhere it
>>>>>>>> is
>>>>>>>> needed. Anything else seems a bad-aid.
>>>>>>>
>>>>>>> But I think not the caller should decide whether it's to be inlined,
>>>>>>> but the implementor of the method (and next the compiler).
>>>>>>> As you describe, the caller has to decide which header to include.
>>>>>>> So the caller has to know implementation details of the callee,
>>>>>>> which is contrary to the encapsulation described in that
>> documentation.
>>>>>>
>>>>>>
>>>>>> That's my understanding of the way things are expected to work. This is
>>>>>> not a public library exporting its interface in a .hpp file, this an
>>>>>> internal part of the bigger system. As I understand it we define the
>>>>>> .inline.hpp file precisely so that clients can include it. And yes the
>>>>>> clients have to know to do that.
>>>>>>
>>>>>>> If you add the 'inline' keyword in the header, the compiler enforces
>>>>>>> that the includes are in a way that it can do what the implementor
>>>>>>> of the callee / of the method to be inlined intended.
>>>>>>
>>>>>>
>>>>>> I still don't see how adding inline to the declaration changes anything
>>>>>> here. The compiler can't do the inlining unless the .inline.hpp file has
>>>>>> been included. ???
>>>>>
>>>>> Yes, but it issues a warning and  will abort if it's wrong.
>>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>>> Maybe
>>>>>>>> precompiled headers messes with that somehow
>>>>>>>
>>>>>>> Actually, you are right.  Oop.inline.hpp is not in precompiled.hpp, nor
>>>>>>> is it dragged in by some other .inline.hpp header.
>>>>>>> I would assume this is a remnant of the problems with this header.
>>>>>>> But if it was listed there, it would make a difference.
>>>>>>>
>>>>>>> To put it the other way round: do you think all the places I had to
>>>>>>> clean up are well founded decisions not to include the methods
>>>>>>> from oop.inline.hpp?
>>>>>>> Before my change, the caller of obj_at_put() from objArrayOop.hpp
>>>>>>> had to include oop.inline.hpp to get it properly inlined.  Seems very
>>>>>>> unintuitive to me.
>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>>>>
>>>>>> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
>>>>>>>
>>>>>>> (I'll add the inline keyword in a follow-up change for gc files, in case
>>>>>>> this change is accepted.)
>>>>>>>
>>>>>>> Best regards,
>>>>>>>       Goetz.
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>        Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 6. Januar 2016 05:59
>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>>>>>>
>>>>>> runtime-
>>>>>>>>>>
>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline
>> directives
>>>>>>
>>>>>> and
>>>>>>>>
>>>>>>>> fix
>>>>>>>>>>
>>>>>>>>>> header files
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 5/01/2016 1:44 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Several recent changes cleaned up includes of oop.inline.hpp in
>> real
>>>>>>
>>>>>> .hpp
>>>>>>>>>>
>>>>>>>>>> header file.
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately, the 'inline' qualifier is added to the function
>>>>>>>>>>
>>>>>>>>>> implementations
>>>>>>>>>>>
>>>>>>>>>>> in oop.inline.hpp instead of to the declarations in oop.hpp.
>>>>>>>>>>> Therefore,
>>>>>>>>
>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>> compiler can not detect failing inlines properly.
>>>>>>>>>>>
>>>>>>>>>>> This change moves the inline directive from oop.inline.hpp to
>>>>>>
>>>>>> oop.hpp.
>>>>>>>>>>
>>>>>>>>>> Also
>>>>>>>>>>
>>>>>>>>>> This seems contrary to the C++ FAQ:
>>>>>>>>>>
>>>>>>>>>> https://isocpp.org/wiki/faq/inline-functions
>>>>>>>>>>
>>>>>>>>>> The declaration in the .hpp should not have inline, only the
>>>>>>>>>> definition,
>>>>>>>>>> which in our case is in the .inline.hpp file.
>>>>>>>>>>
>>>>>>>>>> Any code that includes the .inline.hpp will have seen the
>> definition
>>>>>>>>>> of
>>>>>>>>>> the inline function prior to its use - as long as the includes are
>>>>>>>>>> correct.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> it sorts the methods in oop.inline.hpp as they are sorted in
>>>>>>>>>>> oop.hpp.
>>>>>>>>>>>
>>>>>>>>>>> Further, it moves a row of calls from hpp files to inline.hpp or
>>>>>>>>>>> .cpp
>>>>>>
>>>>>> files.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but
>>>>>>>>>>> this is a
>>>>>>>>>>> very small .hpp file and no .cpp file exists.  So I think this is
>>>>>>>>>>> acceptable.
>>>>>>>>>>>
>>>>>>>>>>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't
>> want
>>>>>>>>>>> to
>>>>>>
>>>>>> do
>>>>>>>>>>>
>>>>>>>>>>> bigger changes to this file in the rt repo, because jvmci is subject
>>>>>>>>>>> to
>>>>>>>>>>> freqent changes recently.
>>>>>>>>>>>
>>>>>>>>>>> The following methods were moved to .cpp files:
>>>>>>>>>>>
>>>>>>>>>>> ProtectionDomainCacheTable::compute_hash()
>>>>>>>>>>> ProtectionDomainCacheTable::index_for()
>>>>>>>>>>> typeArrayOopDesc::object_size()
>>>>>>>>>>> This is called only once outside .cpp file:
>>>>>>>>>>> CallSiteDepChange::CallSiteDepChange()
>>>>>>>>>>> This is only called in .cpp file
>>>>>>>>>>> ConstantPool::string_at_put()
>>>>>>>>>>>
>>>>>>>>>>> If someone considers not inlining these harmful to performance,
>>>>>>>>>>> I will add a new .inline.hpp file for them.
>>>>>>>>>>>
>>>>>>>>>>> Please review this change.  I please need a sponsor.
>>>>>>>>>>> There are no functional edits, so it should be simple to review.
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
>>>>>>>>
>>>>>>>> rt/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>         Goetz.
>>>>>>>>>>>
>>>>

From thomas.stuefe at gmail.com  Wed Jan 13 14:00:11 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 13 Jan 2016 15:00:11 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
Message-ID: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>

Dear all,

please take a look at this small cleanup of ostream.

bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/

Basically, it gets rid of the staticBufferStream class by moving its one
feature up to the parent outputStream class:

When printing the error log in vmError.cpp, we want to use as little stack
space as possible. outputStream class uses on-stack buffers to assemble
snprintf functions. So, staticBufferStream was introduced as a child of
outputStream which overwrites the print functions and makes them use a
caller provided buffer. It then delegates the real writing to a connected
stream object.

The problem with that approach is that this is not a good fit for a child
class.Not all operations possible with outputStream are cleanly delegated
to the connected stream class, so a staticBufferStream behaves sometimes
differently from all other streams (see e.g. JDK-8145410, which will be
automatically fixed with this change too).

Another problem is that this delegation model leads to some code
duplication, because all print() methods of outputStream are practically
duplicated in staticBufferStream.

Another cosmetic note is that all other child classes of outputStream
(bufferedStream, stringStream, fileStream...) are specializations in term
of log destination, not internal behaviour.

Note that I implemented this in a very simple way without using templates,
because I wanted to keep the changes as small as possible.

Kind Regards, Thomas

From goetz.lindenmaier at sap.com  Wed Jan 13 15:02:09 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 13 Jan 2016 15:02:09 +0000
Subject: RFR(L): 8146401: Clean up oop.hpp: add inline directives and
	fix header files
In-Reply-To: <56903679.6070604@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41EFAD77@DEWDFEMB12A.global.corp.sap>
	<568C1854.8060806@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41F0F282@DEWDFEMB12A.global.corp.sap>
	<56903679.6070604@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41F13F11@DEWDFEMB12A.global.corp.sap>

Hi Coleen, 

the following webrev includes the changes proposed by you:
http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-rt/webrev.02/
Also, I removed the empty file.

Thanks for sponsoring,
  Goetz.

> -----Original Message-----
> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> Sent: Freitag, 8. Januar 2016 23:22
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(L): 8146401: Clean up oop.hpp: add inline directives and fix
> header files
> 
> 
> Goetz,
> Thanks for the reply.
> 
> On 1/7/16 10:41 AM, Lindenmaier, Goetz wrote:
> > Hi Coleen,
> >
> > thanks for looking at this!
> >
> >> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/code/dependencies.cpp.udiff.html
> >>
> >> Can you fix the preexisting weird indentation of
> >> + assert(_call_site() ->is_a(SystemDictionary::CallSite_klass()), "must
> >> be");
> > Done.
> >
> >> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/jvmci/jvmciJavaClasses.hpp.udiff.html
> >>
> >> Don't have an opinion about including the .inline.hpp files in these.
> >> The compiler team should probably clean this up.
> > Yes, I think so too.  It should be done in the compiler repo to avoid
> > clashes.
> >
> >> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/oops/objArrayOop.hpp.udiff.html
> >>
> >> Why isn't inline in the declaration for obj_at_put ?
> >> Why is inline commented out for some?
> > I have a follow-up change with a lot of cleanups in gc coding.
> > In that change, I will fix the remaining inlines.  I wanted to
> > make an extra change for gc to simplify reviewing.
> 
> Ah, thank you for explaining this mystery.  I couldn't think of why this
> was.
> >
> >> + inline bool is_instance() const;
> >> + /*inline*/ bool is_array() const;
> >>
> >>
> >> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/oops/oop.inline.hpp.udiff.html
> >>
> >> I'm not really happy with the re-sorting because it may make backporting
> >> difficult, but it's not that many that were moved and the order of these
> >> functions has always seeemed random to me.  So I guess it's ok.
> >>
> >> Can you line up the '\' in the OOP_ITERATE macros at the end?
> >>
> >> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> >> rt/webrev.01/src/share/vm/oops/typeArrayOop.cpp.udiff.html
> > I think that's an artefact of udiff.  The patch and my files look fine.
> >
> >> This non-inline function could affect performance.   It may be called
> >> from GC.  We might need a typeArrayOop.inline.hpp for it.
> > I'll make a new file to be on the safe side.
> >
> > Why is there the empty typeArrayOop.cpp file?
> >
> 
> Oh, heaven knows why there was an empty file!   Maybe an artifact of
> includeDB_junk.    Thanks for making this change.
> 
> >> I can sponsor this, pending further review.
> > Thanks!
> 
> You have replied to Dan and David.  I agree with you that this is a
> worthwhile change.  I think there are some platforms (windows maybe?)
> that will just call 0 and crash if the definition of a function is
> missing, which you can do with a missing .inline.hpp include.   More
> compile time diagnostics makes the code less difficult to work on and
> more robust.
> 
> Thanks,
> Coleen
> 
> >
> > Best regards,
> >     Goetz.
> >
> >
> >
> >> Coleen
> >>
> >>
> >> On 1/4/16 10:44 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> Several recent changes cleaned up includes of oop.inline.hpp in real .hpp
> >> header file.
> >>> Unfortunately, the 'inline' qualifier is added to the function
> >> implementations
> >>> in oop.inline.hpp instead of to the declarations in oop.hpp. Therefore,
> the
> >>> compiler can not detect failing inlines properly.
> >>>
> >>> This change moves the inline directive from oop.inline.hpp to oop.hpp.
> >> Also
> >>> it sorts the methods in oop.inline.hpp as they are sorted in oop.hpp.
> >>>
> >>> Further, it moves a row of calls from hpp files to inline.hpp or .cpp files.
> >>>
> >>> I put oop.inline.hpp into serviceUtil.hpp.  This is not clean, but this is a
> >>> very small .hpp file and no .cpp file exists.  So I think this is acceptable.
> >>>
> >>> Also, I put oop.inline.hpp into jvmciJavaClasses.hpp.  I don't want to do
> >>> bigger changes to this file in the rt repo, because jvmci is subject to
> >>> freqent changes recently.
> >>>
> >>> The following methods were moved to .cpp files:
> >>>
> >>> ProtectionDomainCacheTable::compute_hash()
> >>> ProtectionDomainCacheTable::index_for()
> >>> typeArrayOopDesc::object_size()
> >>> This is called only once outside .cpp file:
> >>> CallSiteDepChange::CallSiteDepChange()
> >>> This is only called in .cpp file
> >>> ConstantPool::string_at_put()
> >>>
> >>> If someone considers not inlining these harmful to performance,
> >>> I will add a new .inline.hpp file for them.
> >>>
> >>> Please review this change.  I please need a sponsor.
> >>> There are no functional edits, so it should be simple to review.
> >>> http://cr.openjdk.java.net/~goetz/wr16/8146401-oopInline-
> rt/webrev.01/
> >>>
> >>> Best regards,
> >>>     Goetz.


From rachel.protacio at oracle.com  Wed Jan 13 15:32:33 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 13 Jan 2016 10:32:33 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <5695BA51.6080408@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com>
Message-ID: <56966E11.6030105@oracle.com>

Hi,

Yes, we have agreed not to use "-version" for triggering potentially 
changeable processes. Ioi, I think you may have misread my code as I did 
not use "java -version" for ItablesTest.java. I had left it in the 
DefaultMethodsTest.java and ClassInitializationTest.java tests because 
they are testing for output that seemed to be independent of -version 
implementation, in particular, java/lang/String default methods and any 
initialization that had no class initialization side effects (such as 
java.io.OutputStream), respectively. But I can make them more robust by 
running on a dummy class.

As for the CDS, I realize I misinterpreted your conclusion. I can get 
rid of "-Xshare:off" and remove the parts of the tests looking for lines 
that disappear when CDS is enabled.

Thanks,
Rachel

On 1/12/2016 9:45 PM, David Holmes wrote:
> I agree with Ioi. This is similar to the monitor inflation/deflation 
> logging test - we need to ensure we use something guaranteed to always 
> generate the expected log output.
>
> Thanks,
> David
>
> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>> Rachel,
>>
>> I don't think adding "-Xshare:off" is the correct fix. For example,
>> ItablesTest.java just runs "java -version", and depends on the fact that
>> at least one of the JDK classes that are implicitly loaded has an itable
>> (or whatever contents that produces the "vtable index " output).
>>
>> This behavior depends on internal JDK implementation and there's no
>> guarantee that it will always be true. There's also no guarantee that
>> the behavior will be the same across all the OS ports.
>>
>> In the future, some changes of "java -version" may cause this test to
>> fail only on a particular platform. I don't want someone to spend a day
>> to track down some imaginative windows issues again just to find out
>> that it's a test bug.
>>
>> So, as I mentioned in the bug report, the tests should be written to
>> load a class that *you have written* to ensure that the output will be
>> there regardless of JDK implementation.
>>
>> Here are other cases where the tests are dependent on unspecified
>> behaviors:
>>
>>       out.shouldContain("[Initialized").shouldContain("without side
>> effects]");
>>
>>       All of the output in DefaultMethodsTest.java
>>
>> In fact, I think you should remove "-Xshare:off" from the tests. Adding
>> -Xshare:off will also force the tests to be executed with CDS disabled,
>> and would cover up problems that only show up when CDS is enabled.
>>
>> Thanks
>> - Ioi
>>
>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>> Hello!
>>>
>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for
>>> debugging and finding the source of the problem.
>>>
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>
>>> Tests sent to JPRT, pass on all platforms.
>>>
>>> Thank you!
>>> Rachel
>>


From coleen.phillimore at oracle.com  Wed Jan 13 16:28:22 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 13 Jan 2016 11:28:22 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
Message-ID: <56967B26.2090307@oracle.com>


Hi, Thanks Kim, Markus and Lois.  This is the latest version that I've 
retested and added to the internal test:

open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/

Thanks,
Coleen

On 1/13/16 5:35 AM, Markus Gronlund wrote:
> Hi Coleen,
>
> The Test_TempNewSymbol() look fine - thank you for adding it.
>
> Maybe you could also complement with a simple self-assignment test as well?
> ...
>
>    s1 = s1; // self assignment
>    assert(s1->refcount() == 2, "should still be two abc (s1 and ss)");
>
> ...
>
> Thanks!
> Markus
>
>
> -----Original Message-----
> From: Coleen Phillimore
> Sent: den 12 januari 2016 22:59
> To: Markus Gronlund; Kim Barrett
> Cc: hotspot-runtime-dev
> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
>
>
>
> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>> Hi Kim,
>>
>> Thanks a lot for the (detailed) reminder about the copy-and-swap idiom. I agree with your reasoning.
> Two for (strongly?) and two against (myself, not so strongly and we can always add a comment to save someone else's time).  I can change it (hoping my test still pass).  Did you look at the test?
>> About the return value from operator=, I would suggest retaining the void as-is as well.
> Ok
>> Maybe we should investigate if it is possible to have the functions in SymbolTable that increment Symbol*'s return a TempNewSymbol( or some other "smartptr" concept) instead of a direct Symbol*?
> When changing symbolOops symbolHandles, to Symbol* with refcounting I had an implementation using SymbolHandle as a smart pointer.  I think I had the assignment operator transfer ownership of the pointer, iirc.  I had added reference counting statistics at that time (which I have
> output in my RFR).   My memory was that the number of Atomic:: add and
> subtract operations were an order of magnitude larger.  I saved a lot of email on this except the numbers.  Symbols mostly come into the JVM through the constant pool, with these exceptions that use TempNewSymbol.
>
>> In that case we could make the type conversion constructor private and make SymbolTable a friend of TempNewSymbol - this would avoid accidental wrapping of arbitrary Symbol*'s. I will look into the possibility of this.
> This sounds like a good idea.
>
> Thanks,
> Coleen
>> Thanks again for your clarification
>> Markus
>>
>> -----Original Message-----
>> From: Kim Barrett
>> Sent: den 12 januari 2016 05:22
>> To: Coleen Phillimore
>> Cc: hotspot-runtime-dev
>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy
>> and assignment functions
>>
>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> Kim and Lois,
>>>
>>> Thanks for looking at this.   This is my latest webrev with the ExecuteInternalVMTest in it:
>>>
>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>
>>> See comments below.
>>>
>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>>> Summary: Add clear() to the assignment operator and add copy constructor.
>>>>>
>>>>> Ran all jtreg, colocated and non-colocated tests.   RunThese -jck with PrintSymbolTableSizeHistogram statistics:
>>>>>
>>>>>    Percent removed          1.35
>>>>>    Reference counts          194583
>>>>>
>>>>> clean:
>>>>>
>>>>>    Percent removed          1.53
>>>>>    Reference counts          194245
>>>>>
>>>>> Without a reference counting copy constructor, we could remove a TempNewSymbol's Symbol if a GC happens.  Consider:
>>>>>
>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>
>>>>> The ref count for "abc" is 1 when created by new_symbol, and the destructor could run after the copy into ts, decrementing the reference count to 0 again.  GC could unlink that symbol from the symbol table.  Fortunately, we haven't seen this bug.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>> For the assignment operator, I think better is:
>>>>
>>>> void operator=(TempNewSymbol s) {
>>>>     Symbol* tmp = s._temp;
>>>>     s._temp = _temp;
>>>>     _temp = tmp;
>>>> }
>>>>
>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>
>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap
>>>> -
>>>> idiom
>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide any Atomic::* reference counting though, which is what is worrysome for performance, just hides it in the destructor of 's'.  I don't want to change this.
>> Copy-swap saves several refcount manipulations in some (common) cases, by taking advantage of rvalue copy elision.
>>
>> Coleen's:
>>
>> void operator=(const TempNewSymbol& s) {
>>     clear();
>>     _temp = s._temp;
>>     if (_temp != NULL) _temp->increment_refcount(); }
>>
>> Markus's:
>>
>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>     if (this != &rhs && _temp != rhs._temp) {
>>       clear();
>>       _temp = rhs._temp;
>>       if (_temp != NULL) {
>>         _temp->increment_refcount();
>>       }
>>     }
>>     return *this;
>> }
>>
>> Kim's:
>>
>> void operator=(TempNewSymbol rhs) {
>>     Symbol* tmp = rhs._temp;
>>     rhs._temp = _temp;
>>     _temp = tmp;
>> }
>>
>> [I'm ignoring differences in the return value in the discussion below.
>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>
>> Markus's is mostly the same as Coleen's, except it handles a couple of special cases differently.
>>
>> Markus's handles self-assignment, where Coleen's doesn't. For correctness that's important; in actual practice self-assignment is generally rare to non-existent, so always paying overhead for it is unpleasant.
>>
>> Markus's also specially handles re-assignment to the same symbol, avoiding any refcount changes in that case.  I suggest this is another rare case, and adding overhead in the normal case to get that rare benefit is not the right tradeoff.
>>
>> Assuming we're not in one of those special cases and neither Symbol* is NULL, Coleen/Markus decrements the old and increments the new. And in an important special case where rhs is an rvalue, there will be another decrement as the temporary goes out of scope. So two refcount changes when rhs is an lvalue, three when it's an rvalue.
>>
>> In contrast, Kim's does an increment and a decrement when rhs is an lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy elision is performed by the compiler, which any decent optimizing compiler will do.
>>
>> The rhs is an rvalue in the following situation:
>>
>>     TempNewSymbol tns = ... ;
>>     ...
>>     tns = expr_returning_Symbol* ;
>>
>> The rhs gets implicitly converted to a temporary (rvalue) TempNewSymbol referring to the symbol (no refcount change), that temporary is directly bound to the assignment argument (copy elided), swap the symbols, and the rvalue converted temp goes out of scope and decrements the refcount of the old Symbol*.
>>
>> The copy-swap version also handles the (rare) self-assignment and re-assignment to the same symbol cases. In these cases Kim's still does the same refcounting changes as otherwise.  But it's better to do extra work in the rare cases and keep the normal cases fast.
>>
>> This is why copy-swap has become the "usual idiom"for assignment operators. There might be cases where it's not the best answer, but usually it is. And this is why (to answer Lois's issue) one should use it even though it's not obvious if one is not previously familiar with the idiom; one should instead learn the idiom, and then one spends time looking hard at implementations that do something else.
>>
>> Of course, this may all be entirely in the noise; I hope that TempNewSymbol assignment is not a high frequency operation.
>>
>>
>>>> I think the updated description of TempNewSymbol isn't really right.
>>>> Because the conversion constructor doesn't increment the reference
>>>> count, it must *not* be used to capture some arbitrary reference to
>>>> a Symbol*. Only a new symbol or one obtained from one of the lookup
>>>> functions really should be managed by this class.
>>> Yes, this is a subtlety of the design and one that I can't really fix right now.  I thought of changing TempNewSymbol to convert from const char * but there are cases where we don't want to add a symbol.
>>>
>>> There is a comment above TempNewSymbol.  I don't know what to add to it.   And Markus's comments are really good.
>> I was confused about which webrev I was looking at.  Coleen's doesn't seem to change those comments.
>> It was (parts of) Markus's comments that worried me.  And the whole design is tricky and risky.
>>


From lois.foltan at oracle.com  Wed Jan 13 18:21:19 2016
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 13 Jan 2016 13:21:19 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <56967B26.2090307@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
Message-ID: <5696959F.7080300@oracle.com>


On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>
> Hi, Thanks Kim, Markus and Lois.  This is the latest version that I've 
> retested and added to the internal test:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/

I think this looks good.  A few minor comments:

- symbolTable.cpp - you could have the test case contain a 
Symbol*/TempNewSymbol* defined within an inner scope to ensure the 
correct ref counting happens within the inner scope and upon exit from 
the inner scope.

- symbolTable.hpp - Glad to see the comment ahead of the assignment 
operator.  I find the last sentence a bit confusing.  Can you rephrase 
to something like, "rhs is passed by value, within the scope of this 
method it is a copy.  At method exit it contains the former value of 
_temp, triggering the correct refcount decrement upon destruction."

I don't need to see another webrev.

Thanks,
Lois

>
> Thanks,
> Coleen
>
> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>> Hi Coleen,
>>
>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>
>> Maybe you could also complement with a simple self-assignment test as 
>> well?
>> ...
>>
>>    s1 = s1; // self assignment
>>    assert(s1->refcount() == 2, "should still be two abc (s1 and ss)");
>>
>> ...
>>
>> Thanks!
>> Markus
>>
>>
>> -----Original Message-----
>> From: Coleen Phillimore
>> Sent: den 12 januari 2016 22:59
>> To: Markus Gronlund; Kim Barrett
>> Cc: hotspot-runtime-dev
>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy 
>> and assignment functions
>>
>>
>>
>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>> Hi Kim,
>>>
>>> Thanks a lot for the (detailed) reminder about the copy-and-swap 
>>> idiom. I agree with your reasoning.
>> Two for (strongly?) and two against (myself, not so strongly and we 
>> can always add a comment to save someone else's time).  I can change 
>> it (hoping my test still pass).  Did you look at the test?
>>> About the return value from operator=, I would suggest retaining the 
>>> void as-is as well.
>> Ok
>>> Maybe we should investigate if it is possible to have the functions 
>>> in SymbolTable that increment Symbol*'s return a TempNewSymbol( or 
>>> some other "smartptr" concept) instead of a direct Symbol*?
>> When changing symbolOops symbolHandles, to Symbol* with refcounting I 
>> had an implementation using SymbolHandle as a smart pointer.  I think 
>> I had the assignment operator transfer ownership of the pointer, 
>> iirc.  I had added reference counting statistics at that time (which 
>> I have
>> output in my RFR).   My memory was that the number of Atomic:: add and
>> subtract operations were an order of magnitude larger.  I saved a lot 
>> of email on this except the numbers.  Symbols mostly come into the 
>> JVM through the constant pool, with these exceptions that use 
>> TempNewSymbol.
>>
>>> In that case we could make the type conversion constructor private 
>>> and make SymbolTable a friend of TempNewSymbol - this would avoid 
>>> accidental wrapping of arbitrary Symbol*'s. I will look into the 
>>> possibility of this.
>> This sounds like a good idea.
>>
>> Thanks,
>> Coleen
>>> Thanks again for your clarification
>>> Markus
>>>
>>> -----Original Message-----
>>> From: Kim Barrett
>>> Sent: den 12 januari 2016 05:22
>>> To: Coleen Phillimore
>>> Cc: hotspot-runtime-dev
>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy
>>> and assignment functions
>>>
>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>> Kim and Lois,
>>>>
>>>> Thanks for looking at this.   This is my latest webrev with the 
>>>> ExecuteInternalVMTest in it:
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>
>>>> See comments below.
>>>>
>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore 
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> Summary: Add clear() to the assignment operator and add copy 
>>>>>> constructor.
>>>>>>
>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck 
>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>
>>>>>>    Percent removed          1.35
>>>>>>    Reference counts          194583
>>>>>>
>>>>>> clean:
>>>>>>
>>>>>>    Percent removed          1.53
>>>>>>    Reference counts          194245
>>>>>>
>>>>>> Without a reference counting copy constructor, we could remove a 
>>>>>> TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>
>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>
>>>>>> The ref count for "abc" is 1 when created by new_symbol, and the 
>>>>>> destructor could run after the copy into ts, decrementing the 
>>>>>> reference count to 0 again.  GC could unlink that symbol from the 
>>>>>> symbol table.  Fortunately, we haven't seen this bug.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>> For the assignment operator, I think better is:
>>>>>
>>>>> void operator=(TempNewSymbol s) {
>>>>>     Symbol* tmp = s._temp;
>>>>>     s._temp = _temp;
>>>>>     _temp = tmp;
>>>>> }
>>>>>
>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>
>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap
>>>>> -
>>>>> idiom
>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide 
>>>> any Atomic::* reference counting though, which is what is worrysome 
>>>> for performance, just hides it in the destructor of 's'.  I don't 
>>>> want to change this.
>>> Copy-swap saves several refcount manipulations in some (common) 
>>> cases, by taking advantage of rvalue copy elision.
>>>
>>> Coleen's:
>>>
>>> void operator=(const TempNewSymbol& s) {
>>>     clear();
>>>     _temp = s._temp;
>>>     if (_temp != NULL) _temp->increment_refcount(); }
>>>
>>> Markus's:
>>>
>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>     if (this != &rhs && _temp != rhs._temp) {
>>>       clear();
>>>       _temp = rhs._temp;
>>>       if (_temp != NULL) {
>>>         _temp->increment_refcount();
>>>       }
>>>     }
>>>     return *this;
>>> }
>>>
>>> Kim's:
>>>
>>> void operator=(TempNewSymbol rhs) {
>>>     Symbol* tmp = rhs._temp;
>>>     rhs._temp = _temp;
>>>     _temp = tmp;
>>> }
>>>
>>> [I'm ignoring differences in the return value in the discussion below.
>>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>>
>>> Markus's is mostly the same as Coleen's, except it handles a couple 
>>> of special cases differently.
>>>
>>> Markus's handles self-assignment, where Coleen's doesn't. For 
>>> correctness that's important; in actual practice self-assignment is 
>>> generally rare to non-existent, so always paying overhead for it is 
>>> unpleasant.
>>>
>>> Markus's also specially handles re-assignment to the same symbol, 
>>> avoiding any refcount changes in that case.  I suggest this is 
>>> another rare case, and adding overhead in the normal case to get 
>>> that rare benefit is not the right tradeoff.
>>>
>>> Assuming we're not in one of those special cases and neither Symbol* 
>>> is NULL, Coleen/Markus decrements the old and increments the new. 
>>> And in an important special case where rhs is an rvalue, there will 
>>> be another decrement as the temporary goes out of scope. So two 
>>> refcount changes when rhs is an lvalue, three when it's an rvalue.
>>>
>>> In contrast, Kim's does an increment and a decrement when rhs is an 
>>> lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy 
>>> elision is performed by the compiler, which any decent optimizing 
>>> compiler will do.
>>>
>>> The rhs is an rvalue in the following situation:
>>>
>>>     TempNewSymbol tns = ... ;
>>>     ...
>>>     tns = expr_returning_Symbol* ;
>>>
>>> The rhs gets implicitly converted to a temporary (rvalue) 
>>> TempNewSymbol referring to the symbol (no refcount change), that 
>>> temporary is directly bound to the assignment argument (copy 
>>> elided), swap the symbols, and the rvalue converted temp goes out of 
>>> scope and decrements the refcount of the old Symbol*.
>>>
>>> The copy-swap version also handles the (rare) self-assignment and 
>>> re-assignment to the same symbol cases. In these cases Kim's still 
>>> does the same refcounting changes as otherwise. But it's better to 
>>> do extra work in the rare cases and keep the normal cases fast.
>>>
>>> This is why copy-swap has become the "usual idiom"for assignment 
>>> operators. There might be cases where it's not the best answer, but 
>>> usually it is. And this is why (to answer Lois's issue) one should 
>>> use it even though it's not obvious if one is not previously 
>>> familiar with the idiom; one should instead learn the idiom, and 
>>> then one spends time looking hard at implementations that do 
>>> something else.
>>>
>>> Of course, this may all be entirely in the noise; I hope that 
>>> TempNewSymbol assignment is not a high frequency operation.
>>>
>>>
>>>>> I think the updated description of TempNewSymbol isn't really right.
>>>>> Because the conversion constructor doesn't increment the reference
>>>>> count, it must *not* be used to capture some arbitrary reference to
>>>>> a Symbol*. Only a new symbol or one obtained from one of the lookup
>>>>> functions really should be managed by this class.
>>>> Yes, this is a subtlety of the design and one that I can't really 
>>>> fix right now.  I thought of changing TempNewSymbol to convert from 
>>>> const char * but there are cases where we don't want to add a symbol.
>>>>
>>>> There is a comment above TempNewSymbol.  I don't know what to add 
>>>> to it.   And Markus's comments are really good.
>>> I was confused about which webrev I was looking at.  Coleen's 
>>> doesn't seem to change those comments.
>>> It was (parts of) Markus's comments that worried me.  And the whole 
>>> design is tricky and risky.
>>>
>


From ioi.lam at oracle.com  Wed Jan 13 19:26:37 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 13 Jan 2016 11:26:37 -0800
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56966E11.6030105@oracle.com>
References: <56954577.90306@oracle.com>
	<5695AD52.803@oracle.com>	<5695BA51.6080408@oracle.com>
	<56966E11.6030105@oracle.com>
Message-ID: <5696A4ED.7010301@oracle.com>



On 1/13/16 7:32 AM, Rachel Protacio wrote:
> Hi,
>
> Yes, we have agreed not to use "-version" for triggering potentially 
> changeable processes. Ioi, I think you may have misread my code as I 
> did not use "java -version" for ItablesTest.java. 
Hi Rachel,

Thanks for the explanation. I looked at ItablesTest again. It uses 
ClassB, which is pretty simple and by itself won't generate the "vtable 
index" output. If it's not too much effort, instead of removing the that 
output from the test, I would suggest changing ClassB so that it would 
produce the desired output.

Thanks

- Ioi


> I had left it in the DefaultMethodsTest.java and 
> ClassInitializationTest.java tests because they are testing for output 
> that seemed to be independent of -version implementation, in 
> particular, java/lang/String default methods and any initialization 
> that had no class initialization side effects (such as 
> java.io.OutputStream), respectively. But I can make them more robust 
> by running on a dummy class.
>
> As for the CDS, I realize I misinterpreted your conclusion. I can get 
> rid of "-Xshare:off" and remove the parts of the tests looking for 
> lines that disappear when CDS is enabled.
>
> Thanks,
> Rachel
>
> On 1/12/2016 9:45 PM, David Holmes wrote:
>> I agree with Ioi. This is similar to the monitor inflation/deflation 
>> logging test - we need to ensure we use something guaranteed to 
>> always generate the expected log output.
>>
>> Thanks,
>> David
>>
>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>> Rachel,
>>>
>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>> ItablesTest.java just runs "java -version", and depends on the fact 
>>> that
>>> at least one of the JDK classes that are implicitly loaded has an 
>>> itable
>>> (or whatever contents that produces the "vtable index " output).
>>>
>>> This behavior depends on internal JDK implementation and there's no
>>> guarantee that it will always be true. There's also no guarantee that
>>> the behavior will be the same across all the OS ports.
>>>
>>> In the future, some changes of "java -version" may cause this test to
>>> fail only on a particular platform. I don't want someone to spend a day
>>> to track down some imaginative windows issues again just to find out
>>> that it's a test bug.
>>>
>>> So, as I mentioned in the bug report, the tests should be written to
>>> load a class that *you have written* to ensure that the output will be
>>> there regardless of JDK implementation.
>>>
>>> Here are other cases where the tests are dependent on unspecified
>>> behaviors:
>>>
>>>       out.shouldContain("[Initialized").shouldContain("without side
>>> effects]");
>>>
>>>       All of the output in DefaultMethodsTest.java
>>>
>>> In fact, I think you should remove "-Xshare:off" from the tests. Adding
>>> -Xshare:off will also force the tests to be executed with CDS disabled,
>>> and would cover up problems that only show up when CDS is enabled.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>> Hello!
>>>>
>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi for
>>>> debugging and finding the source of the problem.
>>>>
>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>
>>>> Tests sent to JPRT, pass on all platforms.
>>>>
>>>> Thank you!
>>>> Rachel
>>>
>


From markus.gronlund at oracle.com  Wed Jan 13 20:01:01 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 13 Jan 2016 12:01:01 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5696959F.7080300@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
Message-ID: <78aceb8f-e874-45b0-8b5d-fd189edda870@default>

I think it looks good.

I agree with adding in Lois's comment about the assignment operator.

No need for another webrev.

Thanks
Markus

-----Original Message-----
From: Lois Foltan 
Sent: den 13 januari 2016 19:21
To: Coleen Phillimore
Cc: Markus Gronlund; hotspot-runtime-dev
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions


On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>
> Hi, Thanks Kim, Markus and Lois.  This is the latest version that I've 
> retested and added to the internal test:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/

I think this looks good.  A few minor comments:

- symbolTable.cpp - you could have the test case contain a
Symbol*/TempNewSymbol* defined within an inner scope to ensure the correct ref counting happens within the inner scope and upon exit from the inner scope.

- symbolTable.hpp - Glad to see the comment ahead of the assignment operator.  I find the last sentence a bit confusing.  Can you rephrase to something like, "rhs is passed by value, within the scope of this method it is a copy.  At method exit it contains the former value of _temp, triggering the correct refcount decrement upon destruction."

I don't need to see another webrev.

Thanks,
Lois

>
> Thanks,
> Coleen
>
> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>> Hi Coleen,
>>
>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>
>> Maybe you could also complement with a simple self-assignment test as 
>> well?
>> ...
>>
>>    s1 = s1; // self assignment
>>    assert(s1->refcount() == 2, "should still be two abc (s1 and 
>> ss)");
>>
>> ...
>>
>> Thanks!
>> Markus
>>
>>
>> -----Original Message-----
>> From: Coleen Phillimore
>> Sent: den 12 januari 2016 22:59
>> To: Markus Gronlund; Kim Barrett
>> Cc: hotspot-runtime-dev
>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy 
>> and assignment functions
>>
>>
>>
>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>> Hi Kim,
>>>
>>> Thanks a lot for the (detailed) reminder about the copy-and-swap 
>>> idiom. I agree with your reasoning.
>> Two for (strongly?) and two against (myself, not so strongly and we 
>> can always add a comment to save someone else's time).  I can change 
>> it (hoping my test still pass).  Did you look at the test?
>>> About the return value from operator=, I would suggest retaining the 
>>> void as-is as well.
>> Ok
>>> Maybe we should investigate if it is possible to have the functions 
>>> in SymbolTable that increment Symbol*'s return a TempNewSymbol( or 
>>> some other "smartptr" concept) instead of a direct Symbol*?
>> When changing symbolOops symbolHandles, to Symbol* with refcounting I 
>> had an implementation using SymbolHandle as a smart pointer.  I think 
>> I had the assignment operator transfer ownership of the pointer, 
>> iirc.  I had added reference counting statistics at that time (which 
>> I have
>> output in my RFR).   My memory was that the number of Atomic:: add and
>> subtract operations were an order of magnitude larger.  I saved a lot 
>> of email on this except the numbers.  Symbols mostly come into the 
>> JVM through the constant pool, with these exceptions that use 
>> TempNewSymbol.
>>
>>> In that case we could make the type conversion constructor private 
>>> and make SymbolTable a friend of TempNewSymbol - this would avoid 
>>> accidental wrapping of arbitrary Symbol*'s. I will look into the 
>>> possibility of this.
>> This sounds like a good idea.
>>
>> Thanks,
>> Coleen
>>> Thanks again for your clarification
>>> Markus
>>>
>>> -----Original Message-----
>>> From: Kim Barrett
>>> Sent: den 12 januari 2016 05:22
>>> To: Coleen Phillimore
>>> Cc: hotspot-runtime-dev
>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct 
>>> copy and assignment functions
>>>
>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>> Kim and Lois,
>>>>
>>>> Thanks for looking at this.   This is my latest webrev with the 
>>>> ExecuteInternalVMTest in it:
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>
>>>> See comments below.
>>>>
>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore 
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> Summary: Add clear() to the assignment operator and add copy 
>>>>>> constructor.
>>>>>>
>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck 
>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>
>>>>>>    Percent removed          1.35
>>>>>>    Reference counts          194583
>>>>>>
>>>>>> clean:
>>>>>>
>>>>>>    Percent removed          1.53
>>>>>>    Reference counts          194245
>>>>>>
>>>>>> Without a reference counting copy constructor, we could remove a 
>>>>>> TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>
>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>
>>>>>> The ref count for "abc" is 1 when created by new_symbol, and the 
>>>>>> destructor could run after the copy into ts, decrementing the 
>>>>>> reference count to 0 again.  GC could unlink that symbol from the 
>>>>>> symbol table.  Fortunately, we haven't seen this bug.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>> For the assignment operator, I think better is:
>>>>>
>>>>> void operator=(TempNewSymbol s) {
>>>>>     Symbol* tmp = s._temp;
>>>>>     s._temp = _temp;
>>>>>     _temp = tmp;
>>>>> }
>>>>>
>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>
>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-sw
>>>>> ap
>>>>> -
>>>>> idiom
>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide 
>>>> any Atomic::* reference counting though, which is what is worrysome 
>>>> for performance, just hides it in the destructor of 's'.  I don't 
>>>> want to change this.
>>> Copy-swap saves several refcount manipulations in some (common) 
>>> cases, by taking advantage of rvalue copy elision.
>>>
>>> Coleen's:
>>>
>>> void operator=(const TempNewSymbol& s) {
>>>     clear();
>>>     _temp = s._temp;
>>>     if (_temp != NULL) _temp->increment_refcount(); }
>>>
>>> Markus's:
>>>
>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>     if (this != &rhs && _temp != rhs._temp) {
>>>       clear();
>>>       _temp = rhs._temp;
>>>       if (_temp != NULL) {
>>>         _temp->increment_refcount();
>>>       }
>>>     }
>>>     return *this;
>>> }
>>>
>>> Kim's:
>>>
>>> void operator=(TempNewSymbol rhs) {
>>>     Symbol* tmp = rhs._temp;
>>>     rhs._temp = _temp;
>>>     _temp = tmp;
>>> }
>>>
>>> [I'm ignoring differences in the return value in the discussion below.
>>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>>
>>> Markus's is mostly the same as Coleen's, except it handles a couple 
>>> of special cases differently.
>>>
>>> Markus's handles self-assignment, where Coleen's doesn't. For 
>>> correctness that's important; in actual practice self-assignment is 
>>> generally rare to non-existent, so always paying overhead for it is 
>>> unpleasant.
>>>
>>> Markus's also specially handles re-assignment to the same symbol, 
>>> avoiding any refcount changes in that case.  I suggest this is 
>>> another rare case, and adding overhead in the normal case to get 
>>> that rare benefit is not the right tradeoff.
>>>
>>> Assuming we're not in one of those special cases and neither Symbol* 
>>> is NULL, Coleen/Markus decrements the old and increments the new.
>>> And in an important special case where rhs is an rvalue, there will 
>>> be another decrement as the temporary goes out of scope. So two 
>>> refcount changes when rhs is an lvalue, three when it's an rvalue.
>>>
>>> In contrast, Kim's does an increment and a decrement when rhs is an 
>>> lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy 
>>> elision is performed by the compiler, which any decent optimizing 
>>> compiler will do.
>>>
>>> The rhs is an rvalue in the following situation:
>>>
>>>     TempNewSymbol tns = ... ;
>>>     ...
>>>     tns = expr_returning_Symbol* ;
>>>
>>> The rhs gets implicitly converted to a temporary (rvalue) 
>>> TempNewSymbol referring to the symbol (no refcount change), that 
>>> temporary is directly bound to the assignment argument (copy 
>>> elided), swap the symbols, and the rvalue converted temp goes out of 
>>> scope and decrements the refcount of the old Symbol*.
>>>
>>> The copy-swap version also handles the (rare) self-assignment and 
>>> re-assignment to the same symbol cases. In these cases Kim's still 
>>> does the same refcounting changes as otherwise. But it's better to 
>>> do extra work in the rare cases and keep the normal cases fast.
>>>
>>> This is why copy-swap has become the "usual idiom"for assignment 
>>> operators. There might be cases where it's not the best answer, but 
>>> usually it is. And this is why (to answer Lois's issue) one should 
>>> use it even though it's not obvious if one is not previously 
>>> familiar with the idiom; one should instead learn the idiom, and 
>>> then one spends time looking hard at implementations that do 
>>> something else.
>>>
>>> Of course, this may all be entirely in the noise; I hope that 
>>> TempNewSymbol assignment is not a high frequency operation.
>>>
>>>
>>>>> I think the updated description of TempNewSymbol isn't really right.
>>>>> Because the conversion constructor doesn't increment the reference 
>>>>> count, it must *not* be used to capture some arbitrary reference 
>>>>> to a Symbol*. Only a new symbol or one obtained from one of the 
>>>>> lookup functions really should be managed by this class.
>>>> Yes, this is a subtlety of the design and one that I can't really 
>>>> fix right now.  I thought of changing TempNewSymbol to convert from 
>>>> const char * but there are cases where we don't want to add a symbol.
>>>>
>>>> There is a comment above TempNewSymbol.  I don't know what to add 
>>>> to it.   And Markus's comments are really good.
>>> I was confused about which webrev I was looking at.  Coleen's 
>>> doesn't seem to change those comments.
>>> It was (parts of) Markus's comments that worried me.  And the whole 
>>> design is tricky and risky.
>>>
>


From coleen.phillimore at oracle.com  Wed Jan 13 20:11:00 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 13 Jan 2016 15:11:00 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <78aceb8f-e874-45b0-8b5d-fd189edda870@default>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
	<78aceb8f-e874-45b0-8b5d-fd189edda870@default>
Message-ID: <5696AF54.4090701@oracle.com>


Okay, thanks!  I'll reword as suggested.
Coleen

On 1/13/16 3:01 PM, Markus Gronlund wrote:
> I think it looks good.
>
> I agree with adding in Lois's comment about the assignment operator.
>
> No need for another webrev.
>
> Thanks
> Markus
>
> -----Original Message-----
> From: Lois Foltan
> Sent: den 13 januari 2016 19:21
> To: Coleen Phillimore
> Cc: Markus Gronlund; hotspot-runtime-dev
> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions
>
>
> On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>> Hi, Thanks Kim, Markus and Lois.  This is the latest version that I've
>> retested and added to the internal test:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/
> I think this looks good.  A few minor comments:
>
> - symbolTable.cpp - you could have the test case contain a
> Symbol*/TempNewSymbol* defined within an inner scope to ensure the correct ref counting happens within the inner scope and upon exit from the inner scope.
>
> - symbolTable.hpp - Glad to see the comment ahead of the assignment operator.  I find the last sentence a bit confusing.  Can you rephrase to something like, "rhs is passed by value, within the scope of this method it is a copy.  At method exit it contains the former value of _temp, triggering the correct refcount decrement upon destruction."
>
> I don't need to see another webrev.
>
> Thanks,
> Lois
>
>> Thanks,
>> Coleen
>>
>> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>>> Hi Coleen,
>>>
>>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>>
>>> Maybe you could also complement with a simple self-assignment test as
>>> well?
>>> ...
>>>
>>>     s1 = s1; // self assignment
>>>     assert(s1->refcount() == 2, "should still be two abc (s1 and
>>> ss)");
>>>
>>> ...
>>>
>>> Thanks!
>>> Markus
>>>
>>>
>>> -----Original Message-----
>>> From: Coleen Phillimore
>>> Sent: den 12 januari 2016 22:59
>>> To: Markus Gronlund; Kim Barrett
>>> Cc: hotspot-runtime-dev
>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy
>>> and assignment functions
>>>
>>>
>>>
>>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>>> Hi Kim,
>>>>
>>>> Thanks a lot for the (detailed) reminder about the copy-and-swap
>>>> idiom. I agree with your reasoning.
>>> Two for (strongly?) and two against (myself, not so strongly and we
>>> can always add a comment to save someone else's time).  I can change
>>> it (hoping my test still pass).  Did you look at the test?
>>>> About the return value from operator=, I would suggest retaining the
>>>> void as-is as well.
>>> Ok
>>>> Maybe we should investigate if it is possible to have the functions
>>>> in SymbolTable that increment Symbol*'s return a TempNewSymbol( or
>>>> some other "smartptr" concept) instead of a direct Symbol*?
>>> When changing symbolOops symbolHandles, to Symbol* with refcounting I
>>> had an implementation using SymbolHandle as a smart pointer.  I think
>>> I had the assignment operator transfer ownership of the pointer,
>>> iirc.  I had added reference counting statistics at that time (which
>>> I have
>>> output in my RFR).   My memory was that the number of Atomic:: add and
>>> subtract operations were an order of magnitude larger.  I saved a lot
>>> of email on this except the numbers.  Symbols mostly come into the
>>> JVM through the constant pool, with these exceptions that use
>>> TempNewSymbol.
>>>
>>>> In that case we could make the type conversion constructor private
>>>> and make SymbolTable a friend of TempNewSymbol - this would avoid
>>>> accidental wrapping of arbitrary Symbol*'s. I will look into the
>>>> possibility of this.
>>> This sounds like a good idea.
>>>
>>> Thanks,
>>> Coleen
>>>> Thanks again for your clarification
>>>> Markus
>>>>
>>>> -----Original Message-----
>>>> From: Kim Barrett
>>>> Sent: den 12 januari 2016 05:22
>>>> To: Coleen Phillimore
>>>> Cc: hotspot-runtime-dev
>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct
>>>> copy and assignment functions
>>>>
>>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>> Kim and Lois,
>>>>>
>>>>> Thanks for looking at this.   This is my latest webrev with the
>>>>> ExecuteInternalVMTest in it:
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>>
>>>>> See comments below.
>>>>>
>>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> Summary: Add clear() to the assignment operator and add copy
>>>>>>> constructor.
>>>>>>>
>>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck
>>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>>
>>>>>>>     Percent removed          1.35
>>>>>>>     Reference counts          194583
>>>>>>>
>>>>>>> clean:
>>>>>>>
>>>>>>>     Percent removed          1.53
>>>>>>>     Reference counts          194245
>>>>>>>
>>>>>>> Without a reference counting copy constructor, we could remove a
>>>>>>> TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>>
>>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>>
>>>>>>> The ref count for "abc" is 1 when created by new_symbol, and the
>>>>>>> destructor could run after the copy into ts, decrementing the
>>>>>>> reference count to 0 again.  GC could unlink that symbol from the
>>>>>>> symbol table.  Fortunately, we haven't seen this bug.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>> For the assignment operator, I think better is:
>>>>>>
>>>>>> void operator=(TempNewSymbol s) {
>>>>>>      Symbol* tmp = s._temp;
>>>>>>      s._temp = _temp;
>>>>>>      _temp = tmp;
>>>>>> }
>>>>>>
>>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>>
>>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-sw
>>>>>> ap
>>>>>> -
>>>>>> idiom
>>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide
>>>>> any Atomic::* reference counting though, which is what is worrysome
>>>>> for performance, just hides it in the destructor of 's'.  I don't
>>>>> want to change this.
>>>> Copy-swap saves several refcount manipulations in some (common)
>>>> cases, by taking advantage of rvalue copy elision.
>>>>
>>>> Coleen's:
>>>>
>>>> void operator=(const TempNewSymbol& s) {
>>>>      clear();
>>>>      _temp = s._temp;
>>>>      if (_temp != NULL) _temp->increment_refcount(); }
>>>>
>>>> Markus's:
>>>>
>>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>>      if (this != &rhs && _temp != rhs._temp) {
>>>>        clear();
>>>>        _temp = rhs._temp;
>>>>        if (_temp != NULL) {
>>>>          _temp->increment_refcount();
>>>>        }
>>>>      }
>>>>      return *this;
>>>> }
>>>>
>>>> Kim's:
>>>>
>>>> void operator=(TempNewSymbol rhs) {
>>>>      Symbol* tmp = rhs._temp;
>>>>      rhs._temp = _temp;
>>>>      _temp = tmp;
>>>> }
>>>>
>>>> [I'm ignoring differences in the return value in the discussion below.
>>>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>>>
>>>> Markus's is mostly the same as Coleen's, except it handles a couple
>>>> of special cases differently.
>>>>
>>>> Markus's handles self-assignment, where Coleen's doesn't. For
>>>> correctness that's important; in actual practice self-assignment is
>>>> generally rare to non-existent, so always paying overhead for it is
>>>> unpleasant.
>>>>
>>>> Markus's also specially handles re-assignment to the same symbol,
>>>> avoiding any refcount changes in that case.  I suggest this is
>>>> another rare case, and adding overhead in the normal case to get
>>>> that rare benefit is not the right tradeoff.
>>>>
>>>> Assuming we're not in one of those special cases and neither Symbol*
>>>> is NULL, Coleen/Markus decrements the old and increments the new.
>>>> And in an important special case where rhs is an rvalue, there will
>>>> be another decrement as the temporary goes out of scope. So two
>>>> refcount changes when rhs is an lvalue, three when it's an rvalue.
>>>>
>>>> In contrast, Kim's does an increment and a decrement when rhs is an
>>>> lvalue, and *only* a decrement when rhs is an rvalue and rvalue copy
>>>> elision is performed by the compiler, which any decent optimizing
>>>> compiler will do.
>>>>
>>>> The rhs is an rvalue in the following situation:
>>>>
>>>>      TempNewSymbol tns = ... ;
>>>>      ...
>>>>      tns = expr_returning_Symbol* ;
>>>>
>>>> The rhs gets implicitly converted to a temporary (rvalue)
>>>> TempNewSymbol referring to the symbol (no refcount change), that
>>>> temporary is directly bound to the assignment argument (copy
>>>> elided), swap the symbols, and the rvalue converted temp goes out of
>>>> scope and decrements the refcount of the old Symbol*.
>>>>
>>>> The copy-swap version also handles the (rare) self-assignment and
>>>> re-assignment to the same symbol cases. In these cases Kim's still
>>>> does the same refcounting changes as otherwise. But it's better to
>>>> do extra work in the rare cases and keep the normal cases fast.
>>>>
>>>> This is why copy-swap has become the "usual idiom"for assignment
>>>> operators. There might be cases where it's not the best answer, but
>>>> usually it is. And this is why (to answer Lois's issue) one should
>>>> use it even though it's not obvious if one is not previously
>>>> familiar with the idiom; one should instead learn the idiom, and
>>>> then one spends time looking hard at implementations that do
>>>> something else.
>>>>
>>>> Of course, this may all be entirely in the noise; I hope that
>>>> TempNewSymbol assignment is not a high frequency operation.
>>>>
>>>>
>>>>>> I think the updated description of TempNewSymbol isn't really right.
>>>>>> Because the conversion constructor doesn't increment the reference
>>>>>> count, it must *not* be used to capture some arbitrary reference
>>>>>> to a Symbol*. Only a new symbol or one obtained from one of the
>>>>>> lookup functions really should be managed by this class.
>>>>> Yes, this is a subtlety of the design and one that I can't really
>>>>> fix right now.  I thought of changing TempNewSymbol to convert from
>>>>> const char * but there are cases where we don't want to add a symbol.
>>>>>
>>>>> There is a comment above TempNewSymbol.  I don't know what to add
>>>>> to it.   And Markus's comments are really good.
>>>> I was confused about which webrev I was looking at.  Coleen's
>>>> doesn't seem to change those comments.
>>>> It was (parts of) Markus's comments that worried me.  And the whole
>>>> design is tricky and risky.
>>>>


From coleen.phillimore at oracle.com  Wed Jan 13 20:50:45 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 13 Jan 2016 15:50:45 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5696959F.7080300@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
Message-ID: <5696B8A5.8060406@oracle.com>


Hi, Unfortunately, you're all getting another webrev.  I decided that I 
should make the test more robust, in the case where java 
-XX:+ExecuteInternalVMTests -version loads a class with the symbol 
"abc", "efg", "hij", etc. in it.

open webrev at http://cr.openjdk.java.net/~coleenp/8145940.05/


Thanks,
Coleen


On 1/13/16 1:21 PM, Lois Foltan wrote:
>
> On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>>
>> Hi, Thanks Kim, Markus and Lois.  This is the latest version that 
>> I've retested and added to the internal test:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/
>
> I think this looks good.  A few minor comments:
>
> - symbolTable.cpp - you could have the test case contain a 
> Symbol*/TempNewSymbol* defined within an inner scope to ensure the 
> correct ref counting happens within the inner scope and upon exit from 
> the inner scope.
>
> - symbolTable.hpp - Glad to see the comment ahead of the assignment 
> operator.  I find the last sentence a bit confusing. Can you rephrase 
> to something like, "rhs is passed by value, within the scope of this 
> method it is a copy.  At method exit it contains the former value of 
> _temp, triggering the correct refcount decrement upon destruction."
>
> I don't need to see another webrev.
>
> Thanks,
> Lois
>
>>
>> Thanks,
>> Coleen
>>
>> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>>> Hi Coleen,
>>>
>>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>>
>>> Maybe you could also complement with a simple self-assignment test 
>>> as well?
>>> ...
>>>
>>>    s1 = s1; // self assignment
>>>    assert(s1->refcount() == 2, "should still be two abc (s1 and ss)");
>>>
>>> ...
>>>
>>> Thanks!
>>> Markus
>>>
>>>
>>> -----Original Message-----
>>> From: Coleen Phillimore
>>> Sent: den 12 januari 2016 22:59
>>> To: Markus Gronlund; Kim Barrett
>>> Cc: hotspot-runtime-dev
>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct 
>>> copy and assignment functions
>>>
>>>
>>>
>>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>>> Hi Kim,
>>>>
>>>> Thanks a lot for the (detailed) reminder about the copy-and-swap 
>>>> idiom. I agree with your reasoning.
>>> Two for (strongly?) and two against (myself, not so strongly and we 
>>> can always add a comment to save someone else's time). I can change 
>>> it (hoping my test still pass).  Did you look at the test?
>>>> About the return value from operator=, I would suggest retaining 
>>>> the void as-is as well.
>>> Ok
>>>> Maybe we should investigate if it is possible to have the functions 
>>>> in SymbolTable that increment Symbol*'s return a TempNewSymbol( or 
>>>> some other "smartptr" concept) instead of a direct Symbol*?
>>> When changing symbolOops symbolHandles, to Symbol* with refcounting 
>>> I had an implementation using SymbolHandle as a smart pointer.  I 
>>> think I had the assignment operator transfer ownership of the 
>>> pointer, iirc.  I had added reference counting statistics at that 
>>> time (which I have
>>> output in my RFR).   My memory was that the number of Atomic:: add and
>>> subtract operations were an order of magnitude larger.  I saved a 
>>> lot of email on this except the numbers.  Symbols mostly come into 
>>> the JVM through the constant pool, with these exceptions that use 
>>> TempNewSymbol.
>>>
>>>> In that case we could make the type conversion constructor private 
>>>> and make SymbolTable a friend of TempNewSymbol - this would avoid 
>>>> accidental wrapping of arbitrary Symbol*'s. I will look into the 
>>>> possibility of this.
>>> This sounds like a good idea.
>>>
>>> Thanks,
>>> Coleen
>>>> Thanks again for your clarification
>>>> Markus
>>>>
>>>> -----Original Message-----
>>>> From: Kim Barrett
>>>> Sent: den 12 januari 2016 05:22
>>>> To: Coleen Phillimore
>>>> Cc: hotspot-runtime-dev
>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy
>>>> and assignment functions
>>>>
>>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore 
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>> Kim and Lois,
>>>>>
>>>>> Thanks for looking at this.   This is my latest webrev with the 
>>>>> ExecuteInternalVMTest in it:
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>>
>>>>> See comments below.
>>>>>
>>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore 
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> Summary: Add clear() to the assignment operator and add copy 
>>>>>>> constructor.
>>>>>>>
>>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck 
>>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>>
>>>>>>>    Percent removed          1.35
>>>>>>>    Reference counts          194583
>>>>>>>
>>>>>>> clean:
>>>>>>>
>>>>>>>    Percent removed          1.53
>>>>>>>    Reference counts          194245
>>>>>>>
>>>>>>> Without a reference counting copy constructor, we could remove a 
>>>>>>> TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>>
>>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>>
>>>>>>> The ref count for "abc" is 1 when created by new_symbol, and the 
>>>>>>> destructor could run after the copy into ts, decrementing the 
>>>>>>> reference count to 0 again.  GC could unlink that symbol from 
>>>>>>> the symbol table.  Fortunately, we haven't seen this bug.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>> For the assignment operator, I think better is:
>>>>>>
>>>>>> void operator=(TempNewSymbol s) {
>>>>>>     Symbol* tmp = s._temp;
>>>>>>     s._temp = _temp;
>>>>>>     _temp = tmp;
>>>>>> }
>>>>>>
>>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>>
>>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap
>>>>>> -
>>>>>> idiom
>>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide 
>>>>> any Atomic::* reference counting though, which is what is 
>>>>> worrysome for performance, just hides it in the destructor of 
>>>>> 's'.  I don't want to change this.
>>>> Copy-swap saves several refcount manipulations in some (common) 
>>>> cases, by taking advantage of rvalue copy elision.
>>>>
>>>> Coleen's:
>>>>
>>>> void operator=(const TempNewSymbol& s) {
>>>>     clear();
>>>>     _temp = s._temp;
>>>>     if (_temp != NULL) _temp->increment_refcount(); }
>>>>
>>>> Markus's:
>>>>
>>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>>     if (this != &rhs && _temp != rhs._temp) {
>>>>       clear();
>>>>       _temp = rhs._temp;
>>>>       if (_temp != NULL) {
>>>>         _temp->increment_refcount();
>>>>       }
>>>>     }
>>>>     return *this;
>>>> }
>>>>
>>>> Kim's:
>>>>
>>>> void operator=(TempNewSymbol rhs) {
>>>>     Symbol* tmp = rhs._temp;
>>>>     rhs._temp = _temp;
>>>>     _temp = tmp;
>>>> }
>>>>
>>>> [I'm ignoring differences in the return value in the discussion below.
>>>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>>>
>>>> Markus's is mostly the same as Coleen's, except it handles a couple 
>>>> of special cases differently.
>>>>
>>>> Markus's handles self-assignment, where Coleen's doesn't. For 
>>>> correctness that's important; in actual practice self-assignment is 
>>>> generally rare to non-existent, so always paying overhead for it is 
>>>> unpleasant.
>>>>
>>>> Markus's also specially handles re-assignment to the same symbol, 
>>>> avoiding any refcount changes in that case.  I suggest this is 
>>>> another rare case, and adding overhead in the normal case to get 
>>>> that rare benefit is not the right tradeoff.
>>>>
>>>> Assuming we're not in one of those special cases and neither 
>>>> Symbol* is NULL, Coleen/Markus decrements the old and increments 
>>>> the new. And in an important special case where rhs is an rvalue, 
>>>> there will be another decrement as the temporary goes out of scope. 
>>>> So two refcount changes when rhs is an lvalue, three when it's an 
>>>> rvalue.
>>>>
>>>> In contrast, Kim's does an increment and a decrement when rhs is an 
>>>> lvalue, and *only* a decrement when rhs is an rvalue and rvalue 
>>>> copy elision is performed by the compiler, which any decent 
>>>> optimizing compiler will do.
>>>>
>>>> The rhs is an rvalue in the following situation:
>>>>
>>>>     TempNewSymbol tns = ... ;
>>>>     ...
>>>>     tns = expr_returning_Symbol* ;
>>>>
>>>> The rhs gets implicitly converted to a temporary (rvalue) 
>>>> TempNewSymbol referring to the symbol (no refcount change), that 
>>>> temporary is directly bound to the assignment argument (copy 
>>>> elided), swap the symbols, and the rvalue converted temp goes out 
>>>> of scope and decrements the refcount of the old Symbol*.
>>>>
>>>> The copy-swap version also handles the (rare) self-assignment and 
>>>> re-assignment to the same symbol cases. In these cases Kim's still 
>>>> does the same refcounting changes as otherwise. But it's better to 
>>>> do extra work in the rare cases and keep the normal cases fast.
>>>>
>>>> This is why copy-swap has become the "usual idiom"for assignment 
>>>> operators. There might be cases where it's not the best answer, but 
>>>> usually it is. And this is why (to answer Lois's issue) one should 
>>>> use it even though it's not obvious if one is not previously 
>>>> familiar with the idiom; one should instead learn the idiom, and 
>>>> then one spends time looking hard at implementations that do 
>>>> something else.
>>>>
>>>> Of course, this may all be entirely in the noise; I hope that 
>>>> TempNewSymbol assignment is not a high frequency operation.
>>>>
>>>>
>>>>>> I think the updated description of TempNewSymbol isn't really right.
>>>>>> Because the conversion constructor doesn't increment the reference
>>>>>> count, it must *not* be used to capture some arbitrary reference to
>>>>>> a Symbol*. Only a new symbol or one obtained from one of the lookup
>>>>>> functions really should be managed by this class.
>>>>> Yes, this is a subtlety of the design and one that I can't really 
>>>>> fix right now.  I thought of changing TempNewSymbol to convert 
>>>>> from const char * but there are cases where we don't want to add a 
>>>>> symbol.
>>>>>
>>>>> There is a comment above TempNewSymbol.  I don't know what to add 
>>>>> to it.   And Markus's comments are really good.
>>>> I was confused about which webrev I was looking at. Coleen's 
>>>> doesn't seem to change those comments.
>>>> It was (parts of) Markus's comments that worried me.  And the whole 
>>>> design is tricky and risky.
>>>>
>>
>


From lois.foltan at oracle.com  Wed Jan 13 21:14:08 2016
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 13 Jan 2016 16:14:08 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5696B8A5.8060406@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
	<5696B8A5.8060406@oracle.com>
Message-ID: <5696BE20.3000301@oracle.com>

Looks good!
Lois

On 1/13/2016 3:50 PM, Coleen Phillimore wrote:
>
> Hi, Unfortunately, you're all getting another webrev.  I decided that 
> I should make the test more robust, in the case where java 
> -XX:+ExecuteInternalVMTests -version loads a class with the symbol 
> "abc", "efg", "hij", etc. in it.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.05/
>
>
> Thanks,
> Coleen
>
>
> On 1/13/16 1:21 PM, Lois Foltan wrote:
>>
>> On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>>>
>>> Hi, Thanks Kim, Markus and Lois.  This is the latest version that 
>>> I've retested and added to the internal test:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/
>>
>> I think this looks good.  A few minor comments:
>>
>> - symbolTable.cpp - you could have the test case contain a 
>> Symbol*/TempNewSymbol* defined within an inner scope to ensure the 
>> correct ref counting happens within the inner scope and upon exit 
>> from the inner scope.
>>
>> - symbolTable.hpp - Glad to see the comment ahead of the assignment 
>> operator.  I find the last sentence a bit confusing. Can you rephrase 
>> to something like, "rhs is passed by value, within the scope of this 
>> method it is a copy.  At method exit it contains the former value of 
>> _temp, triggering the correct refcount decrement upon destruction."
>>
>> I don't need to see another webrev.
>>
>> Thanks,
>> Lois
>>
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>>>> Hi Coleen,
>>>>
>>>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>>>
>>>> Maybe you could also complement with a simple self-assignment test 
>>>> as well?
>>>> ...
>>>>
>>>>    s1 = s1; // self assignment
>>>>    assert(s1->refcount() == 2, "should still be two abc (s1 and ss)");
>>>>
>>>> ...
>>>>
>>>> Thanks!
>>>> Markus
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Coleen Phillimore
>>>> Sent: den 12 januari 2016 22:59
>>>> To: Markus Gronlund; Kim Barrett
>>>> Cc: hotspot-runtime-dev
>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct 
>>>> copy and assignment functions
>>>>
>>>>
>>>>
>>>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>>>> Hi Kim,
>>>>>
>>>>> Thanks a lot for the (detailed) reminder about the copy-and-swap 
>>>>> idiom. I agree with your reasoning.
>>>> Two for (strongly?) and two against (myself, not so strongly and we 
>>>> can always add a comment to save someone else's time). I can change 
>>>> it (hoping my test still pass).  Did you look at the test?
>>>>> About the return value from operator=, I would suggest retaining 
>>>>> the void as-is as well.
>>>> Ok
>>>>> Maybe we should investigate if it is possible to have the 
>>>>> functions in SymbolTable that increment Symbol*'s return a 
>>>>> TempNewSymbol( or some other "smartptr" concept) instead of a 
>>>>> direct Symbol*?
>>>> When changing symbolOops symbolHandles, to Symbol* with refcounting 
>>>> I had an implementation using SymbolHandle as a smart pointer.  I 
>>>> think I had the assignment operator transfer ownership of the 
>>>> pointer, iirc.  I had added reference counting statistics at that 
>>>> time (which I have
>>>> output in my RFR).   My memory was that the number of Atomic:: add and
>>>> subtract operations were an order of magnitude larger.  I saved a 
>>>> lot of email on this except the numbers.  Symbols mostly come into 
>>>> the JVM through the constant pool, with these exceptions that use 
>>>> TempNewSymbol.
>>>>
>>>>> In that case we could make the type conversion constructor private 
>>>>> and make SymbolTable a friend of TempNewSymbol - this would avoid 
>>>>> accidental wrapping of arbitrary Symbol*'s. I will look into the 
>>>>> possibility of this.
>>>> This sounds like a good idea.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>> Thanks again for your clarification
>>>>> Markus
>>>>>
>>>>> -----Original Message-----
>>>>> From: Kim Barrett
>>>>> Sent: den 12 januari 2016 05:22
>>>>> To: Coleen Phillimore
>>>>> Cc: hotspot-runtime-dev
>>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy
>>>>> and assignment functions
>>>>>
>>>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore 
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> Kim and Lois,
>>>>>>
>>>>>> Thanks for looking at this.   This is my latest webrev with the 
>>>>>> ExecuteInternalVMTest in it:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>>>
>>>>>> See comments below.
>>>>>>
>>>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore 
>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>> Summary: Add clear() to the assignment operator and add copy 
>>>>>>>> constructor.
>>>>>>>>
>>>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck 
>>>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>>>
>>>>>>>>    Percent removed          1.35
>>>>>>>>    Reference counts          194583
>>>>>>>>
>>>>>>>> clean:
>>>>>>>>
>>>>>>>>    Percent removed          1.53
>>>>>>>>    Reference counts          194245
>>>>>>>>
>>>>>>>> Without a reference counting copy constructor, we could remove 
>>>>>>>> a TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>>>
>>>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>>>
>>>>>>>> The ref count for "abc" is 1 when created by new_symbol, and 
>>>>>>>> the destructor could run after the copy into ts, decrementing 
>>>>>>>> the reference count to 0 again.  GC could unlink that symbol 
>>>>>>>> from the symbol table.  Fortunately, we haven't seen this bug.
>>>>>>>>
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>> For the assignment operator, I think better is:
>>>>>>>
>>>>>>> void operator=(TempNewSymbol s) {
>>>>>>>     Symbol* tmp = s._temp;
>>>>>>>     s._temp = _temp;
>>>>>>>     _temp = tmp;
>>>>>>> }
>>>>>>>
>>>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap 
>>>>>>>
>>>>>>> -
>>>>>>> idiom
>>>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide 
>>>>>> any Atomic::* reference counting though, which is what is 
>>>>>> worrysome for performance, just hides it in the destructor of 
>>>>>> 's'.  I don't want to change this.
>>>>> Copy-swap saves several refcount manipulations in some (common) 
>>>>> cases, by taking advantage of rvalue copy elision.
>>>>>
>>>>> Coleen's:
>>>>>
>>>>> void operator=(const TempNewSymbol& s) {
>>>>>     clear();
>>>>>     _temp = s._temp;
>>>>>     if (_temp != NULL) _temp->increment_refcount(); }
>>>>>
>>>>> Markus's:
>>>>>
>>>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>>>     if (this != &rhs && _temp != rhs._temp) {
>>>>>       clear();
>>>>>       _temp = rhs._temp;
>>>>>       if (_temp != NULL) {
>>>>>         _temp->increment_refcount();
>>>>>       }
>>>>>     }
>>>>>     return *this;
>>>>> }
>>>>>
>>>>> Kim's:
>>>>>
>>>>> void operator=(TempNewSymbol rhs) {
>>>>>     Symbol* tmp = rhs._temp;
>>>>>     rhs._temp = _temp;
>>>>>     _temp = tmp;
>>>>> }
>>>>>
>>>>> [I'm ignoring differences in the return value in the discussion 
>>>>> below.
>>>>> I think it ought to be either "TempNewSymbol&" (not const) or void.]
>>>>>
>>>>> Markus's is mostly the same as Coleen's, except it handles a 
>>>>> couple of special cases differently.
>>>>>
>>>>> Markus's handles self-assignment, where Coleen's doesn't. For 
>>>>> correctness that's important; in actual practice self-assignment 
>>>>> is generally rare to non-existent, so always paying overhead for 
>>>>> it is unpleasant.
>>>>>
>>>>> Markus's also specially handles re-assignment to the same symbol, 
>>>>> avoiding any refcount changes in that case.  I suggest this is 
>>>>> another rare case, and adding overhead in the normal case to get 
>>>>> that rare benefit is not the right tradeoff.
>>>>>
>>>>> Assuming we're not in one of those special cases and neither 
>>>>> Symbol* is NULL, Coleen/Markus decrements the old and increments 
>>>>> the new. And in an important special case where rhs is an rvalue, 
>>>>> there will be another decrement as the temporary goes out of 
>>>>> scope. So two refcount changes when rhs is an lvalue, three when 
>>>>> it's an rvalue.
>>>>>
>>>>> In contrast, Kim's does an increment and a decrement when rhs is 
>>>>> an lvalue, and *only* a decrement when rhs is an rvalue and rvalue 
>>>>> copy elision is performed by the compiler, which any decent 
>>>>> optimizing compiler will do.
>>>>>
>>>>> The rhs is an rvalue in the following situation:
>>>>>
>>>>>     TempNewSymbol tns = ... ;
>>>>>     ...
>>>>>     tns = expr_returning_Symbol* ;
>>>>>
>>>>> The rhs gets implicitly converted to a temporary (rvalue) 
>>>>> TempNewSymbol referring to the symbol (no refcount change), that 
>>>>> temporary is directly bound to the assignment argument (copy 
>>>>> elided), swap the symbols, and the rvalue converted temp goes out 
>>>>> of scope and decrements the refcount of the old Symbol*.
>>>>>
>>>>> The copy-swap version also handles the (rare) self-assignment and 
>>>>> re-assignment to the same symbol cases. In these cases Kim's still 
>>>>> does the same refcounting changes as otherwise. But it's better to 
>>>>> do extra work in the rare cases and keep the normal cases fast.
>>>>>
>>>>> This is why copy-swap has become the "usual idiom"for assignment 
>>>>> operators. There might be cases where it's not the best answer, 
>>>>> but usually it is. And this is why (to answer Lois's issue) one 
>>>>> should use it even though it's not obvious if one is not 
>>>>> previously familiar with the idiom; one should instead learn the 
>>>>> idiom, and then one spends time looking hard at implementations 
>>>>> that do something else.
>>>>>
>>>>> Of course, this may all be entirely in the noise; I hope that 
>>>>> TempNewSymbol assignment is not a high frequency operation.
>>>>>
>>>>>
>>>>>>> I think the updated description of TempNewSymbol isn't really 
>>>>>>> right.
>>>>>>> Because the conversion constructor doesn't increment the reference
>>>>>>> count, it must *not* be used to capture some arbitrary reference to
>>>>>>> a Symbol*. Only a new symbol or one obtained from one of the lookup
>>>>>>> functions really should be managed by this class.
>>>>>> Yes, this is a subtlety of the design and one that I can't really 
>>>>>> fix right now.  I thought of changing TempNewSymbol to convert 
>>>>>> from const char * but there are cases where we don't want to add 
>>>>>> a symbol.
>>>>>>
>>>>>> There is a comment above TempNewSymbol.  I don't know what to add 
>>>>>> to it.   And Markus's comments are really good.
>>>>> I was confused about which webrev I was looking at. Coleen's 
>>>>> doesn't seem to change those comments.
>>>>> It was (parts of) Markus's comments that worried me.  And the 
>>>>> whole design is tricky and risky.
>>>>>
>>>
>>
>


From markus.gronlund at oracle.com  Wed Jan 13 21:24:22 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 13 Jan 2016 13:24:22 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5696BE20.3000301@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
	<5696959F.7080300@oracle.com> <5696B8A5.8060406@oracle.com>
	<5696BE20.3000301@oracle.com>
Message-ID: <cd0814f8-d860-4d75-a109-df980dbd8d0c@default>

Looks good!

Markus

-----Original Message-----
From: Lois Foltan 
Sent: den 13 januari 2016 22:14
To: Coleen Phillimore
Cc: Markus Gronlund; hotspot-runtime-dev
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

Looks good!
Lois

On 1/13/2016 3:50 PM, Coleen Phillimore wrote:
>
> Hi, Unfortunately, you're all getting another webrev.  I decided that 
> I should make the test more robust, in the case where java 
> -XX:+ExecuteInternalVMTests -version loads a class with the symbol 
> "abc", "efg", "hij", etc. in it.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.05/
>
>
> Thanks,
> Coleen
>
>
> On 1/13/16 1:21 PM, Lois Foltan wrote:
>>
>> On 1/13/2016 11:28 AM, Coleen Phillimore wrote:
>>>
>>> Hi, Thanks Kim, Markus and Lois.  This is the latest version that 
>>> I've retested and added to the internal test:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.03/
>>
>> I think this looks good.  A few minor comments:
>>
>> - symbolTable.cpp - you could have the test case contain a
>> Symbol*/TempNewSymbol* defined within an inner scope to ensure the 
>> correct ref counting happens within the inner scope and upon exit 
>> from the inner scope.
>>
>> - symbolTable.hpp - Glad to see the comment ahead of the assignment 
>> operator.  I find the last sentence a bit confusing. Can you rephrase 
>> to something like, "rhs is passed by value, within the scope of this 
>> method it is a copy.  At method exit it contains the former value of 
>> _temp, triggering the correct refcount decrement upon destruction."
>>
>> I don't need to see another webrev.
>>
>> Thanks,
>> Lois
>>
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/13/16 5:35 AM, Markus Gronlund wrote:
>>>> Hi Coleen,
>>>>
>>>> The Test_TempNewSymbol() look fine - thank you for adding it.
>>>>
>>>> Maybe you could also complement with a simple self-assignment test 
>>>> as well?
>>>> ...
>>>>
>>>>    s1 = s1; // self assignment
>>>>    assert(s1->refcount() == 2, "should still be two abc (s1 and 
>>>> ss)");
>>>>
>>>> ...
>>>>
>>>> Thanks!
>>>> Markus
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Coleen Phillimore
>>>> Sent: den 12 januari 2016 22:59
>>>> To: Markus Gronlund; Kim Barrett
>>>> Cc: hotspot-runtime-dev
>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct 
>>>> copy and assignment functions
>>>>
>>>>
>>>>
>>>> On 1/12/16 7:34 AM, Markus Gronlund wrote:
>>>>> Hi Kim,
>>>>>
>>>>> Thanks a lot for the (detailed) reminder about the copy-and-swap 
>>>>> idiom. I agree with your reasoning.
>>>> Two for (strongly?) and two against (myself, not so strongly and we 
>>>> can always add a comment to save someone else's time). I can change 
>>>> it (hoping my test still pass).  Did you look at the test?
>>>>> About the return value from operator=, I would suggest retaining 
>>>>> the void as-is as well.
>>>> Ok
>>>>> Maybe we should investigate if it is possible to have the 
>>>>> functions in SymbolTable that increment Symbol*'s return a 
>>>>> TempNewSymbol( or some other "smartptr" concept) instead of a 
>>>>> direct Symbol*?
>>>> When changing symbolOops symbolHandles, to Symbol* with refcounting 
>>>> I had an implementation using SymbolHandle as a smart pointer.  I 
>>>> think I had the assignment operator transfer ownership of the 
>>>> pointer, iirc.  I had added reference counting statistics at that 
>>>> time (which I have
>>>> output in my RFR).   My memory was that the number of Atomic:: add and
>>>> subtract operations were an order of magnitude larger.  I saved a 
>>>> lot of email on this except the numbers.  Symbols mostly come into 
>>>> the JVM through the constant pool, with these exceptions that use 
>>>> TempNewSymbol.
>>>>
>>>>> In that case we could make the type conversion constructor private 
>>>>> and make SymbolTable a friend of TempNewSymbol - this would avoid 
>>>>> accidental wrapping of arbitrary Symbol*'s. I will look into the 
>>>>> possibility of this.
>>>> This sounds like a good idea.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>> Thanks again for your clarification Markus
>>>>>
>>>>> -----Original Message-----
>>>>> From: Kim Barrett
>>>>> Sent: den 12 januari 2016 05:22
>>>>> To: Coleen Phillimore
>>>>> Cc: hotspot-runtime-dev
>>>>> Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct 
>>>>> copy and assignment functions
>>>>>
>>>>> On Jan 11, 2016, at 8:34 PM, Coleen Phillimore 
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> Kim and Lois,
>>>>>>
>>>>>> Thanks for looking at this.   This is my latest webrev with the 
>>>>>> ExecuteInternalVMTest in it:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/8145940.02/webrev/index.html
>>>>>>
>>>>>> See comments below.
>>>>>>
>>>>>> On 1/11/16 6:45 PM, Kim Barrett wrote:
>>>>>>> On Jan 7, 2016, at 3:02 PM, Coleen Phillimore 
>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>> Summary: Add clear() to the assignment operator and add copy 
>>>>>>>> constructor.
>>>>>>>>
>>>>>>>> Ran all jtreg, colocated and non-colocated tests. RunThese -jck 
>>>>>>>> with PrintSymbolTableSizeHistogram statistics:
>>>>>>>>
>>>>>>>>    Percent removed          1.35
>>>>>>>>    Reference counts          194583
>>>>>>>>
>>>>>>>> clean:
>>>>>>>>
>>>>>>>>    Percent removed          1.53
>>>>>>>>    Reference counts          194245
>>>>>>>>
>>>>>>>> Without a reference counting copy constructor, we could remove 
>>>>>>>> a TempNewSymbol's Symbol if a GC happens. Consider:
>>>>>>>>
>>>>>>>> TempNewSymbol ts = SymbolTable::new_symbol("abc"); // Hit GC
>>>>>>>>
>>>>>>>> The ref count for "abc" is 1 when created by new_symbol, and 
>>>>>>>> the destructor could run after the copy into ts, decrementing 
>>>>>>>> the reference count to 0 again.  GC could unlink that symbol 
>>>>>>>> from the symbol table.  Fortunately, we haven't seen this bug.
>>>>>>>>
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940/
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145940
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>> For the assignment operator, I think better is:
>>>>>>>
>>>>>>> void operator=(TempNewSymbol s) {
>>>>>>>     Symbol* tmp = s._temp;
>>>>>>>     s._temp = _temp;
>>>>>>>     _temp = tmp;
>>>>>>> }
>>>>>>>
>>>>>>> This is the well-known copy and swap idiom, with a by-hand "swap".
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/3279543/what-is-the-copy-and-
>>>>>>> swap
>>>>>>>
>>>>>>> -
>>>>>>> idiom
>>>>>> Very tricky.  Lois and I figured out the trick.  It doesn't elide 
>>>>>> any Atomic::* reference counting though, which is what is 
>>>>>> worrysome for performance, just hides it in the destructor of 
>>>>>> 's'.  I don't want to change this.
>>>>> Copy-swap saves several refcount manipulations in some (common) 
>>>>> cases, by taking advantage of rvalue copy elision.
>>>>>
>>>>> Coleen's:
>>>>>
>>>>> void operator=(const TempNewSymbol& s) {
>>>>>     clear();
>>>>>     _temp = s._temp;
>>>>>     if (_temp != NULL) _temp->increment_refcount(); }
>>>>>
>>>>> Markus's:
>>>>>
>>>>> const TempNewSymbol& operator=(const TempNewSymbol& rhs) {
>>>>>     if (this != &rhs && _temp != rhs._temp) {
>>>>>       clear();
>>>>>       _temp = rhs._temp;
>>>>>       if (_temp != NULL) {
>>>>>         _temp->increment_refcount();
>>>>>       }
>>>>>     }
>>>>>     return *this;
>>>>> }
>>>>>
>>>>> Kim's:
>>>>>
>>>>> void operator=(TempNewSymbol rhs) {
>>>>>     Symbol* tmp = rhs._temp;
>>>>>     rhs._temp = _temp;
>>>>>     _temp = tmp;
>>>>> }
>>>>>
>>>>> [I'm ignoring differences in the return value in the discussion 
>>>>> below.
>>>>> I think it ought to be either "TempNewSymbol&" (not const) or 
>>>>> void.]
>>>>>
>>>>> Markus's is mostly the same as Coleen's, except it handles a 
>>>>> couple of special cases differently.
>>>>>
>>>>> Markus's handles self-assignment, where Coleen's doesn't. For 
>>>>> correctness that's important; in actual practice self-assignment 
>>>>> is generally rare to non-existent, so always paying overhead for 
>>>>> it is unpleasant.
>>>>>
>>>>> Markus's also specially handles re-assignment to the same symbol, 
>>>>> avoiding any refcount changes in that case.  I suggest this is 
>>>>> another rare case, and adding overhead in the normal case to get 
>>>>> that rare benefit is not the right tradeoff.
>>>>>
>>>>> Assuming we're not in one of those special cases and neither
>>>>> Symbol* is NULL, Coleen/Markus decrements the old and increments 
>>>>> the new. And in an important special case where rhs is an rvalue, 
>>>>> there will be another decrement as the temporary goes out of 
>>>>> scope. So two refcount changes when rhs is an lvalue, three when 
>>>>> it's an rvalue.
>>>>>
>>>>> In contrast, Kim's does an increment and a decrement when rhs is 
>>>>> an lvalue, and *only* a decrement when rhs is an rvalue and rvalue 
>>>>> copy elision is performed by the compiler, which any decent 
>>>>> optimizing compiler will do.
>>>>>
>>>>> The rhs is an rvalue in the following situation:
>>>>>
>>>>>     TempNewSymbol tns = ... ;
>>>>>     ...
>>>>>     tns = expr_returning_Symbol* ;
>>>>>
>>>>> The rhs gets implicitly converted to a temporary (rvalue) 
>>>>> TempNewSymbol referring to the symbol (no refcount change), that 
>>>>> temporary is directly bound to the assignment argument (copy 
>>>>> elided), swap the symbols, and the rvalue converted temp goes out 
>>>>> of scope and decrements the refcount of the old Symbol*.
>>>>>
>>>>> The copy-swap version also handles the (rare) self-assignment and 
>>>>> re-assignment to the same symbol cases. In these cases Kim's still 
>>>>> does the same refcounting changes as otherwise. But it's better to 
>>>>> do extra work in the rare cases and keep the normal cases fast.
>>>>>
>>>>> This is why copy-swap has become the "usual idiom"for assignment 
>>>>> operators. There might be cases where it's not the best answer, 
>>>>> but usually it is. And this is why (to answer Lois's issue) one 
>>>>> should use it even though it's not obvious if one is not 
>>>>> previously familiar with the idiom; one should instead learn the 
>>>>> idiom, and then one spends time looking hard at implementations 
>>>>> that do something else.
>>>>>
>>>>> Of course, this may all be entirely in the noise; I hope that 
>>>>> TempNewSymbol assignment is not a high frequency operation.
>>>>>
>>>>>
>>>>>>> I think the updated description of TempNewSymbol isn't really 
>>>>>>> right.
>>>>>>> Because the conversion constructor doesn't increment the 
>>>>>>> reference count, it must *not* be used to capture some arbitrary 
>>>>>>> reference to a Symbol*. Only a new symbol or one obtained from 
>>>>>>> one of the lookup functions really should be managed by this class.
>>>>>> Yes, this is a subtlety of the design and one that I can't really 
>>>>>> fix right now.  I thought of changing TempNewSymbol to convert 
>>>>>> from const char * but there are cases where we don't want to add 
>>>>>> a symbol.
>>>>>>
>>>>>> There is a comment above TempNewSymbol.  I don't know what to add 
>>>>>> to it.   And Markus's comments are really good.
>>>>> I was confused about which webrev I was looking at. Coleen's 
>>>>> doesn't seem to change those comments.
>>>>> It was (parts of) Markus's comments that worried me.  And the 
>>>>> whole design is tricky and risky.
>>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Wed Jan 13 21:25:33 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 13 Jan 2016 16:25:33 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <569068ED.6070509@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com>
Message-ID: <5696C0CD.2050704@oracle.com>



On 1/8/16 8:57 PM, Ioi Lam wrote:
>
>
> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>
>> Hi, I have a bunch of comments that Ioi may have to help answer 
>> because I had some questions about how the logging output comes out.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>
>>
>> I think these can be UL-ized with less lines.  There's no need to 
>> check if log_is_enabled here.
>>
>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>> *!tty->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>> NULL) {*
>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>> *+ log->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> }
>>
>> *!if (class_loader() != NULL) {*
>> *!tty->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> }
>>
>> What does this come out looking like?  It seems like it's going to 
>> have [classloaderdata] in front of every line printed.  I think this 
>> wants to be all one log line.
>>
>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>> *)cld->class_loader()),*
>> *+ cld->loader_name());*
>> *+ *
>> *+ if (string.not_null()) {*
>> *+ log->print(": ");*
>> *+ java_lang_String::print(string(), log);*
>> *+ } *
>> [classloaderdata] create class loader data <address>
>> [classloaderdata]  for instance <addr> of some name
>> [classloaderdata] :
>> [classloaderdata] some string
>>
> The UL JEP says this in http://openjdk.java.net/jeps/158
> "Goals ... Print line-at-a-time (no interleaving within same line)"
>
> log->print() is line-buffered. So all of these will be concatenated 
> into the same buffer until the final log->cr() or log->print_cr(), at 
> which point the whole line will be printed (with a single 
> [classloaderdata] prefix).
>
> Here's an example:
>
> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
> [0.780s][debug  ][classloaderdata] create class loader data 
> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
> sun/misc/Launcher$AppClassLoader: 
> "sun.misc.Launcher$AppClassLoader at 722c41f4"

Oh, good, thank you for verifying this.  I think I conflated this with 
some other problem.  This is okay then.
>
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>
>>
>> You don't need to check log_is_enabled.  log_debug macro does that. 2 
>> instances in this file.
>>
>> *+ if (log_is_enabled(Debug, classload)) {*
>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>> *+ } *
>>
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>
>>
>> Do you want this to come out with fewer lines?   Maybe the messages 
>> should be collected in a tempStream and printed out at the end? LIke 
>> in this file:
>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>
>>
> There's no need to use the tempStream, since the UL log already 
> handles buffering.
>
> If my understanding of UL buffering is correct, I think the use of 
> tempStream should be removed as a clean up.
>
tempStream here was used to keep exception messages from being 
interleaved between threads.   But possibly this isn't needed because 
logStream buffers locally.  We didn't think of that.

>> There's a bunch of tty->print's still in this function.
>>
>> *+ Handle class_loader(loader_data->class_loader());*
>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>
>> This could be simplified avoiding the Handle, which is not needed.
>>
>> *+ tty->print(" source: %s", 
>> loader_data->class_loader()->klass()->external_name());*
>>
>> Is the loader_data argument to print_loading_log simply the 
>> instanceKLass::_class_loader_data field?  In which case you can 
>> remove the argument and have:
>>
>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>> *
>>
> The original code (from classFileParser.cpp) is this:
>
>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
> _loader_data->class_loader()->klass()->external_name());
>
> I suppose _loader_data->class_loader() in that context should be 
> exactly the same as class_loader() inside the 
> InstanceKlass::print_loading_log function, so your suggestion should 
> work.
>

I mostly want the Handle line to be taken out since it's not needed to 
handlize the class_loader here.

>> Obviously not to tty.
>
> You're right. The "tty->print" should be changed to log->print in 
> InstanceKlass::print_loading_log. What I don't understand is why the 
> output looks just fine.
>
> I never noticed these during my testing because the lines that use 
> tty->print are uncommon and did not show up. I'll try to come up with 
> a test case (I think it has something to do with reflection proxies ...).
>

Good, I think the changes I suggested are minor then.

Thanks,
Coleen
>
> Thanks
> - Ioi
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>
>>
>> This one can be condensed also
>>
>> *!if (_log_is_enabled(Info, classload)_) {*
>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>> }
>>
>> to
>>
>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>
>> * 
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>
>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>> his previous mail.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>
>>
>> The return value 'ret' isn't used.  Either return an error if it 
>> returns and error (what errors does it return?) or don't have 'ret'.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>
>>
>> Test looks great to me!
>>
>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>  151         checkFor("[classunload]", "[Unloading class");
>>
>> Can this be:
>>
>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>> "[classunload]", "[Unloading class");
>>
>> To not start a new process?
>>
>> Thanks,
>> Coleen
>>
>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>> Hello,
>>> Please review this unified logging conversion for several related 
>>> flags in the class loading system.
>>>
>>> Bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>> classloaderdata)
>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>
>>> Summary:
>>>
>>> There are two separate issues here. Originally Ioi and I began 
>>> working on these fixes in parallel, but eventually it became obvious 
>>> that the classload and classunload tags needed to be implemented 
>>> together. This change is a combination of Ioi's change for 8079408 
>>> and my change for 8142506.
>>>
>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>> This flag is added to the alias table. More verbose logging exists 
>>> at level debug (one level of verbosity up from info)
>>>
>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>> This flag is added to the alias table. More verbose logging exists 
>>> at level trace (converted from uses of WizardMode)
>>>
>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>
>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>> effected the implementation of "-verbose:class"
>>>
>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>
>>> If you have questions about the updates to the classloading log, Ioi 
>>> can give a better answer than I can.
>>>
>>> Thanks,
>>> Max
>>>
>>>
>>>
>>>
>>
>


From kim.barrett at oracle.com  Wed Jan 13 22:35:15 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 13 Jan 2016 17:35:15 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5696B8A5.8060406@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
	<5696B8A5.8060406@oracle.com>
Message-ID: <D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>

On Jan 13, 2016, at 3:50 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Hi, Unfortunately, you're all getting another webrev.  I decided that I should make the test more robust, in the case where java -XX:+ExecuteInternalVMTests -version loads a class with the symbol "abc", "efg", "hij", etc. in it.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.05/

------------------------------------------------------------------------------  
share/vm/classfile/symbolTable.hpp
  85   // Decrement reference counter so it can go away if it's unique

"unique" seems like the wrong term to me here.  Maybe "unused" or
"unreferenced"?

------------------------------------------------------------------------------
src/share/vm/classfile/symbolTable.cpp
 679   assert(ss->refcount() == abc->refcount(), "should match TempNewSymbol");

I think a stronger check would be

  assert(ss == abc, "...");

since we have that operator==.

------------------------------------------------------------------------------   
src/share/vm/classfile/symbolTable.cpp
 678   assert(ss->refcount() == abccount, "only one abc");
...
 688   assert(s1->refcount() == efgcount, "one efg");
 689   assert(s2->refcount() == hijcount, "one hij");
&etc

the "one" and "two" and such in the messages are misleading. This is
to protect against some of these symbols already existing for other
reasons, but I think the error messages confuse things a bit.

Just a comment about the problem of pre-existing symbols, rather than
actually changing the messages, would be sufficient for me.

------------------------------------------------------------------------------   
src/share/vm/classfile/symbolTable.cpp
 704   s3 = SymbolTable::new_symbol("klm", CATCH);
 705   // can't really assert that it's one
 706   // assert(s3->refcount() == 1, "only one klm now");

Capture new_symbol result in a Symbol*, record refcount, assign symbol
to s3, and verify refcount unchanged.

------------------------------------------------------------------------------  

There are other aspects of the TempNewSymbol that I might question,
but that's for another day.

I also like Markus's suggestion of SymbolTable symbol access returning
TempNewSymbol (perhaps under a better name!), but that is likely a
bigger change; I think this is still an improvement.

Looks good, other than those minor things above.  Unless one of these
leads to a substantive change, I don't need another webrev.



From john.r.rose at oracle.com  Wed Jan 13 23:29:47 2016
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 13 Jan 2016 15:29:47 -0800
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
	<5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
Message-ID: <4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>

Count me in as one who is very glad to see TempNewSymbol
getting regularized.  You can also count me as a reviewer.

Like Kim and Markus, I dislike the fact that TempNewSymbol
can decrease a refcount that it did not increase in the first place,
because new_symbol or lookup pre-incremented the refcount.
(FWIW, this has always bothered me about TempNewSymbol.)
This is the sort of convention that works best when the type
system enforces it.  Quick question:  Exactly how many of
the Symbol::* API points which yield Symbol* values include
the pre-increment?  If the answer is not "all of them" or "none
of them", we have a manually-enforced distinction which may
turn out to be fragile.

Markus, is there a tracking bug yet for addressing this?
There should be.

The "copy and swap idiom" is nice, and a new C++ trick to me.
It is a clever way of cleanly encapsulating keeping the lifecycle
invariants in the ctor/dtor pairs.  (Except for the case of TNS(S*)
which Kim, Markus, and I are uncomfortable about.)

Here's a thought, FWIW, about an incremental way forward on
the pre-increment problem.  It might be useful to split the "magic"
functions:

  TempNewSymbol lookup(int index, const char* name, int len, unsigned int hash);
  TempNewSymbol new_symbol(const char* name, TRAPS) { ? }
  Symbol* lookup_increment_refcount(int index, const char* name, int len, unsigned int hash);
  Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { ? }

There would be an initial wave of renaming (adding _increment_refcount),
followed (perhaps) by gradual removal of the _increment_refcount versions
in favor of more consistent use of TempNewSymbol.  Arrays are tricky, alas,
so maybe the endpoint is still messy, but elsewhere we work with growable
arrays of type Handle, so maybe there is a way forward.

? John


On Jan 13, 2016, at 2:35 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> I also like Markus's suggestion of SymbolTable symbol access returning
> TempNewSymbol (perhaps under a better name!), but that is likely a
> bigger change; I think this is still an improvement.
> 
> Looks good, other than those minor things above.  Unless one of these
> leads to a substantive change, I don't need another webrev.


From cheleswer.sahu at oracle.com  Thu Jan 14 06:53:13 2016
From: cheleswer.sahu at oracle.com (cheleswer sahu)
Date: Thu, 14 Jan 2016 12:23:13 +0530
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <CA+kOe09bxV5gUbjrELqxJWpi06ZBwYEB0wp70iPukGE2RnW7BA@mail.gmail.com>
References: <56962632.7080404@oracle.com>
	<CA+kOe09bxV5gUbjrELqxJWpi06ZBwYEB0wp70iPukGE2RnW7BA@mail.gmail.com>
Message-ID: <569745D9.1090007@oracle.com>

Adding core-libs-dev and hotspot-runtime-dev team .

On 1/14/2016 12:24 AM, Martin Buchholz wrote:
> You should include core-libs-dev (and perhaps hotspot-runtime-dev) in
> this thread.  You're changing core library code.
>
> On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu
> <cheleswer.sahu at oracle.com> wrote:
>> Hi,
>>
>> Please review the code changes for
>> "https://bugs.openjdk.java.net/browse/JDK-8130425".
>>
>> Problem summary: When a large TLS (Thread Local Storage) size is set for
>> threads,  JVM is throwing StackOverflow exception.
>>
>> Problem Identified:
>> As per investigation and a discussion we came to the conclusion that issue
>> is not with the JVM but it lies in the way glibc has been implemented. When
>> a TLS is declared , it steals the space from threads stack size.
>> So if a thread is created with small stack size, and TLS is set to a large
>> value, then it will result in StackOverflow. This is the exact case in this
>> bug where reaper thread is allocated a very low stack size 32768.
>>
>> Discussion thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html
>>
>> Solution proposed:
>> Its expected to get fix in glibc sometime , but for now I propose a
>> workaround, a boolean system property "processReaperUseDefaultStackSize"
>> using which we can set the stack size for reaper thread to default
>> instead of fix 32768. This property can be set by the user using "-D" or
>> "System.setProperty()". I have tested this fix, it works well with TLS size
>> between 32k to 128k.
>>
>> Fix:
>> diff -r 5c4530bb9ae6
>> src/java.base/share/classes/java/lang/ProcessHandleImpl.jav
>> --- a/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Fri Jan
>> 08 13:06:29 2016 +0800
>> +++ b/src/java.base/share/classes/java/lang/ProcessHandleImpl.java Tue Jan
>> 12 15:55:50 2016 +0530
>> @@ -83,9 +83,13 @@
>>                   ThreadGroup systemThreadGroup = tg;
>>
>>                   ThreadFactory threadFactory = grimReaper -> {
>> -                    // Our thread stack requirement is quite modest.
>> -                    Thread t = new Thread(systemThreadGroup, grimReaper,
>> -                            "process reaper", 32768);
>> +                   Thread t = null;
>> +                   if
>> (Boolean.getBoolean("processReaperUseDefaultStackSize")) {
>> +                       t = new Thread(systemThreadGroup, grimReaper,
>> "process reaper");
>> +                    } else {
>> +                       // Our thread stack requirement is quite modest.
>> +                       t = new Thread(systemThreadGroup, grimReaper,
>> "process reaper", 32768);
>> +                    }
>>                       t.setDaemon(true);
>>                       // A small attempt (probably futile) to avoid priority
>> inversion
>>                       t.setPriority(Thread.MAX_PRIORITY);
>>
>>
>> Regards,
>> Cheleswer


From david.holmes at oracle.com  Thu Jan 14 07:06:43 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Jan 2016 17:06:43 +1000
Subject: RFR: 8143558 evaluate if thr_sigsetmask can be removed from
	hotspot (solaris) codebase
In-Reply-To: <567AA1C0.4010801@gmx.de>
References: <567AA1C0.4010801@gmx.de>
Message-ID: <56974903.3060903@oracle.com>

Hi Sebastien,

Sorry for the delay on this. I will take this and test it etc.

Thanks,
David

On 23/12/2015 11:29 PM, Sebastian Sickelmann wrote:
> Hi,
>
> as a side-effect of https://bugs.openjdk.java.net/browse/JDK-8136978 i
> created
> a Enhancement in JBS
>
> https://bugs.openjdk.java.net/browse/JDK-8143558
>
> As David commented in JBS it is possible to replace the usage of
> thr_sigsetmask with pthread-sigmask.
>
> Maybe the change is not worth anything on its own. I hope that we can
> find more duplicated code that can be removed easier.
>
> I have create patch that replaces all calls to thr_sigsetmask:
>
> http://cr.openjdk.java.net/~sebastian/8143558/webrev.02/
>
> Unfortunately (Lacking a solaris environment) I am not able to compile
> check / jtreg-test this change.
>
> --
> Sebastian
>

From markus.gronlund at oracle.com  Thu Jan 14 10:47:25 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 14 Jan 2016 02:47:25 -0800 (PST)
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
	<5696959F.7080300@oracle.com> <5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
	<4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
Message-ID: <97d7a0a7-9e50-4c95-bc09-4dd50d657686@default>

Hi John,

Thanks for the input.

"Markus, is there a tracking bug yet for addressing this?
There should be."

https://bugs.openjdk.java.net/browse/JDK-8147083

Thanks again
Markus

-----Original Message-----
From: John Rose 
Sent: den 14 januari 2016 00:30
To: Kim Barrett; Coleen Phillimore
Cc: hotspot-runtime-dev
Subject: Re: RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

Count me in as one who is very glad to see TempNewSymbol getting regularized.  You can also count me as a reviewer.

Like Kim and Markus, I dislike the fact that TempNewSymbol can decrease a refcount that it did not increase in the first place, because new_symbol or lookup pre-incremented the refcount.
(FWIW, this has always bothered me about TempNewSymbol.) This is the sort of convention that works best when the type system enforces it.  Quick question:  Exactly how many of the Symbol::* API points which yield Symbol* values include the pre-increment?  If the answer is not "all of them" or "none of them", we have a manually-enforced distinction which may turn out to be fragile.

Markus, is there a tracking bug yet for addressing this?
There should be.

The "copy and swap idiom" is nice, and a new C++ trick to me.
It is a clever way of cleanly encapsulating keeping the lifecycle invariants in the ctor/dtor pairs.  (Except for the case of TNS(S*) which Kim, Markus, and I are uncomfortable about.)

Here's a thought, FWIW, about an incremental way forward on the pre-increment problem.  It might be useful to split the "magic"
functions:

  TempNewSymbol lookup(int index, const char* name, int len, unsigned int hash);
  TempNewSymbol new_symbol(const char* name, TRAPS) { . }
  Symbol* lookup_increment_refcount(int index, const char* name, int len, unsigned int hash);
  Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { . }

There would be an initial wave of renaming (adding _increment_refcount), followed (perhaps) by gradual removal of the _increment_refcount versions in favor of more consistent use of TempNewSymbol.  Arrays are tricky, alas, so maybe the endpoint is still messy, but elsewhere we work with growable arrays of type Handle, so maybe there is a way forward.

- John


On Jan 13, 2016, at 2:35 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> I also like Markus's suggestion of SymbolTable symbol access returning 
> TempNewSymbol (perhaps under a better name!), but that is likely a 
> bigger change; I think this is still an improvement.
> 
> Looks good, other than those minor things above.  Unless one of these 
> leads to a substantive change, I don't need another webrev.


From vladimir.x.ivanov at oracle.com  Thu Jan 14 10:51:39 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 14 Jan 2016 13:51:39 +0300
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56784A53.5090203@oracle.com>
References: <56784A53.5090203@oracle.com>
Message-ID: <56977DBB.3070502@oracle.com>

Yumin,

Please, file a follow-up bug for the missing check (interface static 
method referenced by a MethodHandle). We shouldn't leave it half-fixed.

I'd prefer to keep the original VM fix and quarantine affected tests 
until ASM is fixed, but 2-phase fix is also fine with me.

Not sure how to handle ASM problem. Is the problem present in the latest 
ASM version?

The best way would be to get it fixed upstream first and then sync 
internal copy with upstream. defmeth tests use the library bundled with 
the JDK.

Best regards,
Vladimir Ivanov

On 12/21/15 9:52 PM, Yumin Qi wrote:
> Please review:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>
> This is REDO for bug 8087223, which was backed out due to failed on
> 8143317 and 8143320.
> The defmeth encoutered new failures after the fix, which now has correct
> constant tags. The test bugs will be addressed in 8143320, which based
> on vm/runtime/defmeth and 8143317, which in jdk/test.
>
> One difference from the attached for this webrev is that in MethodHandle
> resolution, I relax the check for one specific case: Using MethodHandle
> to invoke static default interface method. In this case, we must use
> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
> method tag for interface which violates JVMS-5.4.3.3 (it should create
> interface method tag!).  ASM currently has no API to generate
> invokeinterface for a interface static default method through
> MethodHandle invocation.
>
> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
> Note the fix still fails 8143320 and 8143317 which are not fixed at the
> momment.
>
>
> Thanks
> Yumin
>
>
> Original post:
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Please review:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>
> According to JVMS-8:
>
> JVMS-5.4.3.3 Method Resolution:
>   " If C is an interface, method resolution throws an
> IncompatibleClassChangeError."
> JVMS-5.4.3.4 Interface Method Resolution:
>   "If C is not an interface, interface method resolution throws an
> IncompatibleClassChangeError"
>
> When invoke a method with resolved to an interface method, or invoke a
> interface method with resolved to an instance method,  ICCE should be
> thrown. The case usually happens when using tools like asmtools or
> jdk.internal.org.objectweb.asm to generate java bytecode.
>
> The fix is carrying the constantTag for the method at call and check if
> tag is consistent with the method called. Doing this by adding a member
> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
> to see if tag matched with the correct method.
>
> The fix solved the problem when call is from interpreter and compiler,
> bug for MethodHandle invoke, which should be addressed in another bug,
> since the MethodHandle does not come with a byte stream and getting the
> constant pool index at the invoke is not possible.  It will be addressed
> in another bug.
>
> Tests: test case (added, minor modified from bug), JPRT, rutime quick
> test list(in progress).
> manually tested:  1) -Xint
>                                 2) -Xcomp
>                                 3) -Xcomp -XX:-TieredCompiltion
>                                 4) -Xcomp -XX:+TieredCompilation
>
> Thanks to Coleen for helping fixed constant pool index and cleaned
> LinkInfo.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>
> Second revision attached.
>
>
>
>
> Thanks
> Yumin

From shafi.s.ahmad at oracle.com  Thu Jan 14 11:58:40 2016
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Thu, 14 Jan 2016 03:58:40 -0800 (PST)
Subject: RFR: JDK-8143146 : SIGSEGV, Problematic frame: # V
	[libjvm.so+0xd0c0cc] void
	InstanceKlass::oop_oop_iterate_oop_maps_specialized<true, oopDesc*,
	MarkAndPushClosure>
In-Reply-To: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>
References: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>
Message-ID: <8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>

Hi,

 

Please review the backport of bug: "JDKJDK-8143146 : SIGSEGV, Problematic frame: # V [libjvm.so+0xd0c0cc] void InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,MarkAndPushClosure>" to jdk8u-dev

 

Please note that this is not a clean backport due to - 

A) Location of file "g1CollectedHeap.cpp" are different in jdk9 and jdk8:

   jdk8: src/share/vm/gc_implementation/g1/

   jdk9: src/share/vm/gc/g1/

 

B) Compilation failure:

Variable args assert "#define assert(p, ...) vmassert(p, __VA_ARGS__)" is defined in jdk9/hs-rt/hotspot/src/share/vm/utilities/debug.hpp where as it is not defined in jdk8 and hence changeset leads to compilation failure.

 

Used err_msg ["typedef FormatBuffer<> err_msg;]" which convert var args to single arg. It is used in many places even in jdk9/hs-rt/hotspot.

 

C) jdk8 does not have "/test/lib" used for "import sun.hotspot.WhiteBox;" so I have change the line
+ * @library /testlibrary /test/lib 
to
+ * @library /testlibrary /testlibrary/whitebox
 

 

Webrev: http://cr.openjdk.java.net/~rpatil/shafi/8139424/webrev.00/

jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8139424

Backport bug: https://bugs.openjdk.java.net/browse/JDK-8143146

Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/636e286dd5da

 

Test:  Run jprt and relevant jtreg test.

 

Regards,

Shafi

From stefan.johansson at oracle.com  Thu Jan 14 13:27:14 2016
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 14 Jan 2016 14:27:14 +0100
Subject: RFR: JDK-8143146 : SIGSEGV, Problematic frame: # V
	[libjvm.so+0xd0c0cc] void
	InstanceKlass::oop_oop_iterate_oop_maps_specialized<true, oopDesc*,
	MarkAndPushClosure>
In-Reply-To: <8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>
References: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>
	<8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>
Message-ID: <5697A232.3000606@oracle.com>

Hi Shafi,

Backport looks good, but I'm not a jdk8u-reviewer so you'll need a 
Reviewer to look at it as well.

Thanks,
Stefan

On 2016-01-14 12:58, Shafi Ahmad wrote:
>
> Hi,
>
> Please review the backport of bug: ?JDKJDK-8143146 : SIGSEGV, 
> Problematic frame: # V [libjvm.so+0xd0c0cc] void 
> InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,MarkAndPushClosure>? 
> to jdk8u-dev
>
> Please note that this is not a clean backport due to -
>
> A) Location of file "g1CollectedHeap.cpp" are different in jdk9 and jdk8:
>
>    jdk8: src/share/vm/gc_implementation/g1/
>
>    jdk9: src/share/vm/gc/g1/
>
> B) Compilation failure:
>
> Variable args assert "#define assert(p, ...) vmassert(p, __VA_ARGS__)" 
> is defined in jdk9/hs-rt/hotspot/src/share/vm/utilities/debug.hpp 
> where as it is not defined in jdk8 and hence changeset leads to 
> compilation failure.
>
> Used err_msg ["typedef FormatBuffer<> err_msg;]" which convert var 
> args to single arg. It is used in many places even in jdk9/hs-rt/hotspot.
>
> C) jdk8 does not have ?/test/lib? used for ?import 
> sun.hotspot.WhiteBox;? so I have change the line
> + * @library /testlibrary /test/lib
> to
> + * @library /testlibrary /testlibrary/whitebox
>
> Webrev: http://cr.openjdk.java.net/~rpatil/shafi/8139424/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erpatil/shafi/8139424/webrev.00/>
>
> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8139424
>
> Backport bug: https://bugs.openjdk.java.net/browse/JDK-8143146
>
> Original patch pushed to jdk9: 
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/636e286dd5da
>
> Test:  Run jprt and relevant jtreg test.
>
> Regards,
>
> Shafi
>


From thomas.schatzl at oracle.com  Thu Jan 14 14:40:02 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Jan 2016 15:40:02 +0100
Subject: RFR: JDK-8143146 : SIGSEGV, Problematic frame: # V
	[libjvm.so+0xd0c0cc] void
	InstanceKlass::oop_oop_iterate_oop_maps_specialized<true, oopDesc*,
	MarkAndPushClosure>
In-Reply-To: <8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>
References: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>
	<8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>
Message-ID: <1452782402.15942.3.camel@oracle.com>

Hi,

On Thu, 2016-01-14 at 03:58 -0800, Shafi Ahmad wrote:
> Hi,
> 
> Please review the backport of bug: "JDKJDK-8143146 : SIGSEGV,
> Problematic frame: # V [libjvm.so+0xd0c0cc] void
> InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,Mar
> kAndPushClosure>" to jdk8u-dev

Thanks for backporting this issue! This issue is exactly the one I
would have otherwise asked to have backported.
 
> Please note that this is not a clean backport due to - 
> 
> A) Location of file "g1CollectedHeap.cpp" are different in jdk9 and
> jdk8:
> 
>    jdk8: src/share/vm/gc_implementation/g1/
> 
>    jdk9: src/share/vm/gc/g1/
>  
> 
> B) Compilation failure:
> 
> Variable args assert "#define assert(p, ...) vmassert(p,
> __VA_ARGS__)" is defined in jdk9/hs
> -rt/hotspot/src/share/vm/utilities/debug.hpp where as it is not
> defined in jdk8 and hence changeset leads to compilation failure.
> 
> Used err_msg ["typedef FormatBuffer<> err_msg;]" which convert var
> args to single arg. It is used in many places even in jdk9/hs
> -rt/hotspot.

The indentation of the parameters in g1CollectedHeap.cpp, line 3772 is
wrong. It should align with the err_msg method, not the assert.
 
> 
> C) jdk8 does not have "/test/lib" used for "import
> sun.hotspot.WhiteBox;" so I have change the line
> + * @library /testlibrary /test/lib 
> to
> + * @library /testlibrary /testlibrary/whitebox

 looks good otherwise.

Thanks,
  Thomas


From thomas.schatzl at oracle.com  Thu Jan 14 14:42:21 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Jan 2016 15:42:21 +0100
Subject: RFR: JDK-8143146 : SIGSEGV, Problematic frame: # V
	[libjvm.so+0xd0c0cc] void
	InstanceKlass::oop_oop_iterate_oop_maps_specialized<true, oopDesc*,
	MarkAndPushClosure>
In-Reply-To: <1452782402.15942.3.camel@oracle.com>
References: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>
	<8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>
	<1452782402.15942.3.camel@oracle.com>
Message-ID: <1452782541.15942.5.camel@oracle.com>

Hi,

  I just noticed that I am only committer for 8u too, sorry :(

Thomas

On Thu, 2016-01-14 at 15:40 +0100, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2016-01-14 at 03:58 -0800, Shafi Ahmad wrote:
> > Hi,
> > 
> > Please review the backport of bug: "JDKJDK-8143146 : SIGSEGV,
> > Problematic frame: # V [libjvm.so+0xd0c0cc] void
> > InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,M
> > ar
> > kAndPushClosure>" to jdk8u-dev
> 
> Thanks for backporting this issue! This issue is exactly the one I
> would have otherwise asked to have backported.
>  
> > Please note that this is not a clean backport due to - 
> > 
> > A) Location of file "g1CollectedHeap.cpp" are different in jdk9 and
> > jdk8:
> > 
> >    jdk8: src/share/vm/gc_implementation/g1/
> > 
> >    jdk9: src/share/vm/gc/g1/
> >  
> > 
> > B) Compilation failure:
> > 
> > Variable args assert "#define assert(p, ...) vmassert(p,
> > __VA_ARGS__)" is defined in jdk9/hs
> > -rt/hotspot/src/share/vm/utilities/debug.hpp where as it is not
> > defined in jdk8 and hence changeset leads to compilation failure.
> > 
> > Used err_msg ["typedef FormatBuffer<> err_msg;]" which convert var
> > args to single arg. It is used in many places even in jdk9/hs
> > -rt/hotspot.
> 
> The indentation of the parameters in g1CollectedHeap.cpp, line 3772
> is
> wrong. It should align with the err_msg method, not the assert.
>  
> > 
> > C) jdk8 does not have "/test/lib" used for "import
> > sun.hotspot.WhiteBox;" so I have change the line
> > + * @library /testlibrary /test/lib 
> > to
> > + * @library /testlibrary /testlibrary/whitebox
> 
>  looks good otherwise.
> 
> Thanks,
>   Thomas
> 

From marcus.larsson at oracle.com  Thu Jan 14 15:00:02 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 14 Jan 2016 16:00:02 +0100
Subject: RFR: 8146879: Truncate new UL log files
Message-ID: <5697B7F2.50104@oracle.com>

Hi,

Please review the following patch to make sure UL truncates existing log 
files before writing to them. Since files are opened in append mode, 
truncation isn't done automatically, so instead the patch adds an 
attempt to remove the log file before opening it.

Webrev:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8146879

Testing:
Included test through JPRT

Thanks,
Marcus

From thomas.stuefe at gmail.com  Thu Jan 14 15:08:49 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 14 Jan 2016 16:08:49 +0100
Subject: RFR(m): 8145184: [aix] Implement os::platform_print_native_stack
	on AIX
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap>
References: <CAA-vtUyHvNZuVsyi+MSVkr671JWYhn5cwCkiVO6Pa7Hjqtu5+Q@mail.gmail.com>
	<CAA-vtUyuYAW++iQTg6mrBP8BUjoheTPtLDR9QvRy+OiZ6rXQ2g@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41F13CDE@DEWDFEMB12A.global.corp.sap>
Message-ID: <CAA-vtUzfjP8ovmQjG7AKMPD7HV5veUCnrsoVbEQRapXmyKpViA@mail.gmail.com>

Hi Goetz,

thanks a lot for reviewing!

See here the new webrev:

http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-os_platform_print_native_stack/webrev.01/webrev/

Comments inline.

On Wed, Jan 13, 2016 at 12:48 PM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi Thomas,
>
> I had a look at your change.
>
> The construction with #ifndef PLATFORM_PRINT_NATIVE_STACK is quite
> unconventional ... but it was there before, so it's not an issue of your
> change.
>
>
Yes.. :-/


> It's good to have this now, I've experienced missing stack traces before.
>
> Is it necessary to use macro ERRBYE?  It doesn't really help reading the
> code, as the 'return' is hidden in it.  I would remove it with this change.
>
>
You are right, I removed than macro.


> Don't you have to remove the '== 0' here?  You changed the return value
> from '0' to true.
> -      if (getFuncName((codeptr_t) p, funcname, sizeof(funcname),
> &displacement,
> -                      NULL, NULL, 0, false) == 0) {
> +      if (AixSymbols::get_function_name(p, funcname, sizeof(funcname),
> +                      &displacement, NULL, true) == 0) {
>
>
Good catch! Found two places where I did not revert the logic, fixe and
tested.


> Get_module_name has wrong indentation of parameters.  Probably they fit
> into
> one line.
>
Besides that looks good.


Thanks!

Kind Regards, Thomas


>
>
Best regards,
>   Goetz.
>
>
>
>
> > -----Original Message-----
> > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> > bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> > Sent: Montag, 11. Januar 2016 14:40
> > To: hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-
> > dev at openjdk.java.net
> > Subject: Re: RFR(m): 8145184: [aix] Implement
> > os::platform_print_native_stack on AIX
> >
> > Hi all,
> >
> > could I please have a review?
> >
> > Thank you!
> >
> > ..Thomas
> >
> > On Wed, Dec 16, 2015 at 3:18 PM, Thomas St?fe
> > <thomas.stuefe at gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > please review this AIX-only patch.
> > >
> > > This ports a more sophisticated native callstack printer for AIX to the
> > > OpenJDK. It prints out more information and is more robust in cases the
> > > stack is corrupted.
> > >
> > > bug: https://bugs.openjdk.java.net/browse/JDK-8145184
> > > webrev:
> > > http://cr.openjdk.java.net/~stuefe/webrevs/8145184-aix-implement-
> > os_platform_print_native_stack/webrev.00/webrev/
> > >
> > > Note that also some of functions were moved and made more coding-
> > conform
> > > to the OpenJDK: the old getFuncName() and getModuleName() functions
> > are
> > > moved to AixSymbols::get_function_name() and
> > AixSymbols::get_module_name().
> > >
> > > Thanks and Kind Regards, Thomas
> > >
>

From dmitry.samersoff at oracle.com  Thu Jan 14 15:28:50 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 14 Jan 2016 18:28:50 +0300
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5697B7F2.50104@oracle.com>
References: <5697B7F2.50104@oracle.com>
Message-ID: <5697BEB2.3040206@oracle.com>

Marcus,

fopen(name, "wa+") truncate file before open it in append mode.

-Dmitry

On 2016-01-14 18:00, Marcus Larsson wrote:
> Hi,
> 
> Please review the following patch to make sure UL truncates existing log
> files before writing to them. Since files are opened in append mode,
> truncation isn't done automatically, so instead the patch adds an
> attempt to remove the log file before opening it.
> 
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146879
> 
> Testing:
> Included test through JPRT
> 
> Thanks,
> Marcus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From martinrb at google.com  Thu Jan 14 18:59:26 2016
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 14 Jan 2016 10:59:26 -0800
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <569745D9.1090007@oracle.com>
References: <56962632.7080404@oracle.com>
	<CA+kOe09bxV5gUbjrELqxJWpi06ZBwYEB0wp70iPukGE2RnW7BA@mail.gmail.com>
	<569745D9.1090007@oracle.com>
Message-ID: <CA+kOe09ntiOcLGeNKMQCv4KCztsGWQjNdq30LBNc+eEn2=qmmQ@mail.gmail.com>

The process grim reaper ends up being the first point of failure since
it tries not to waste the user's memory and it's in a core library,
but in principle it's not special.  I think a more general workaround
would be to add a hotspot flag that would add a memory safety zone to
all threads.  If it's known that TLS is stealing 32k from every
thread's stack, then the flag should ensure that every thread stack is
32k larger.

More generally, I was hoping that hotspot would ensure that the -Xss
size was available for actual java stack frames and OS overhead was
added on automatically, but that is hard to implement, so the best
alternative workaround is for users to be able to specify that
additional stack size padding.  Maybe -XX:StackSizeOverhead=32768 ?

From coleen.phillimore at oracle.com  Thu Jan 14 19:18:57 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 14 Jan 2016 14:18:57 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
	<5696959F.7080300@oracle.com> <5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
Message-ID: <5697F4A1.5080504@oracle.com>



On 1/13/16 5:35 PM, Kim Barrett wrote:
> On Jan 13, 2016, at 3:50 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>> Hi, Unfortunately, you're all getting another webrev.  I decided that I should make the test more robust, in the case where java -XX:+ExecuteInternalVMTests -version loads a class with the symbol "abc", "efg", "hij", etc. in it.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8145940.05/
> ------------------------------------------------------------------------------
> share/vm/classfile/symbolTable.hpp
>    85   // Decrement reference counter so it can go away if it's unique
>
> "unique" seems like the wrong term to me here.  Maybe "unused" or
> "unreferenced"?

Fixed. I picked "unused".
>
> ------------------------------------------------------------------------------
> src/share/vm/classfile/symbolTable.cpp
>   679   assert(ss->refcount() == abc->refcount(), "should match TempNewSymbol");
>
> I think a stronger check would be
>
>    assert(ss == abc, "...");
>
> since we have that operator==.

I'm not sure why we have operator==.   I don't remember why it was added 
or if there's code that uses it. I'd rather use operator-> which I know 
is used.
>
> ------------------------------------------------------------------------------
> src/share/vm/classfile/symbolTable.cpp
>   678   assert(ss->refcount() == abccount, "only one abc");
> ...
>   688   assert(s1->refcount() == efgcount, "one efg");
>   689   assert(s2->refcount() == hijcount, "one hij");
> &etc
>
> the "one" and "two" and such in the messages are misleading. This is
> to protect against some of these symbols already existing for other
> reasons, but I think the error messages confuse things a bit.
>
> Just a comment about the problem of pre-existing symbols, rather than
> actually changing the messages, would be sufficient for me.

Ok, I'll add a comment.  If someone is debugging the value is likely 
what's in the assert message.
>
> ------------------------------------------------------------------------------
> src/share/vm/classfile/symbolTable.cpp
>   704   s3 = SymbolTable::new_symbol("klm", CATCH);
>   705   // can't really assert that it's one
>   706   // assert(s3->refcount() == 1, "only one klm now");
>
> Capture new_symbol result in a Symbol*, record refcount, assign symbol
> to s3, and verify refcount unchanged.

ok, for some reason I thought it would be a redundant test, but it's not.
>
> ------------------------------------------------------------------------------
>
> There are other aspects of the TempNewSymbol that I might question,
> but that's for another day.
>
> I also like Markus's suggestion of SymbolTable symbol access returning
> TempNewSymbol (perhaps under a better name!), but that is likely a
> bigger change; I think this is still an improvement.

Yes, further RFE.
>
> Looks good, other than those minor things above.  Unless one of these
> leads to a substantive change, I don't need another webrev.
>
Thanks, none of the changes were big.

Coleen


From coleen.phillimore at oracle.com  Thu Jan 14 19:26:11 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 14 Jan 2016 14:26:11 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
	<5696959F.7080300@oracle.com> <5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
	<4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
Message-ID: <5697F653.7020005@oracle.com>



On 1/13/16 6:29 PM, John Rose wrote:
> Count me in as one who is very glad to see TempNewSymbol
> getting regularized.  You can also count me as a reviewer.
>
> Like Kim and Markus, I dislike the fact that TempNewSymbol
> can decrease a refcount that it did not increase in the first place,
> because new_symbol or lookup pre-incremented the refcount.
> (FWIW, this has always bothered me about TempNewSymbol.)
> This is the sort of convention that works best when the type
> system enforces it.  Quick question:  Exactly how many of
> the Symbol::* API points which yield Symbol* values include
> the pre-increment?  If the answer is not "all of them" or "none
> of them", we have a manually-enforced distinction which may
> turn out to be fragile.

It's all but two.   Yes, it can be fragile.  So the reason for having 
TempNewSymbol in the first place was to track symbols coming into the 
JVM via char*, vs. via the constant pool.  At the time it was 90% the 
constant pool so we didn't want refcounting for every symbol operation, 
ala smart pointers.  It was a bigger not nice change at the time, and 
tons of refcounting.  We also really want to manipulate symbols as 
Symbol* rather than some other name but we've debated this lots of times.

>
> Markus, is there a tracking bug yet for addressing this?
> There should be.
>
> The "copy and swap idiom" is nice, and a new C++ trick to me.
> It is a clever way of cleanly encapsulating keeping the lifecycle
> invariants in the ctor/dtor pairs.  (Except for the case of TNS(S*)
> which Kim, Markus, and I are uncomfortable about.)
>
> Here's a thought, FWIW, about an incremental way forward on
> the pre-increment problem.  It might be useful to split the "magic"
> functions:
>
>   TempNewSymbol lookup(int index, const char* name, int len, unsigned 
> int hash);
>   TempNewSymbol new_symbol(const char* name, TRAPS) { ? }
>   Symbol* lookup_increment_refcount(int index, const char* name, int 
> len, unsigned int hash);
>   Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { ? }
>
> There would be an initial wave of renaming (adding _increment_refcount),
> followed (perhaps) by gradual removal of the _increment_refcount versions
> in favor of more consistent use of TempNewSymbol.  Arrays are tricky, 
> alas,
> so maybe the endpoint is still messy, but elsewhere we work with growable
> arrays of type Handle, so maybe there is a way forward.

Having a safer API for creating TempNewSymbol with char* would be nice 
to have.

Coleen
>
> ? John
>
>
> On Jan 13, 2016, at 2:35 PM, Kim Barrett <kim.barrett at oracle.com 
> <mailto:kim.barrett at oracle.com>> wrote:
>>
>> I also like Markus's suggestion of SymbolTable symbol access returning
>> TempNewSymbol (perhaps under a better name!), but that is likely a
>> bigger change; I think this is still an improvement.
>>
>> Looks good, other than those minor things above.  Unless one of these
>> leads to a substantive change, I don't need another webrev.
>


From coleen.phillimore at oracle.com  Thu Jan 14 19:27:06 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 14 Jan 2016 14:27:06 -0500
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com>
	<5696959F.7080300@oracle.com> <5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
	<4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
Message-ID: <5697F68A.1030200@oracle.com>



On 1/13/16 6:29 PM, John Rose wrote:
> Count me in as one who is very glad to see TempNewSymbol
> getting regularized.  You can also count me as a reviewer.

I forgot to say, thank you for the code review.  Also, thank you for 
pointing out the problem in the first place.
It was lost in my mailbox for a while.

Coleen

>
> Like Kim and Markus, I dislike the fact that TempNewSymbol
> can decrease a refcount that it did not increase in the first place,
> because new_symbol or lookup pre-incremented the refcount.
> (FWIW, this has always bothered me about TempNewSymbol.)
> This is the sort of convention that works best when the type
> system enforces it.  Quick question:  Exactly how many of
> the Symbol::* API points which yield Symbol* values include
> the pre-increment?  If the answer is not "all of them" or "none
> of them", we have a manually-enforced distinction which may
> turn out to be fragile.
>
> Markus, is there a tracking bug yet for addressing this?
> There should be.
>
> The "copy and swap idiom" is nice, and a new C++ trick to me.
> It is a clever way of cleanly encapsulating keeping the lifecycle
> invariants in the ctor/dtor pairs.  (Except for the case of TNS(S*)
> which Kim, Markus, and I are uncomfortable about.)
>
> Here's a thought, FWIW, about an incremental way forward on
> the pre-increment problem.  It might be useful to split the "magic"
> functions:
>
>   TempNewSymbol lookup(int index, const char* name, int len, unsigned 
> int hash);
>   TempNewSymbol new_symbol(const char* name, TRAPS) { ? }
>   Symbol* lookup_increment_refcount(int index, const char* name, int 
> len, unsigned int hash);
>   Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { ? }
>
> There would be an initial wave of renaming (adding _increment_refcount),
> followed (perhaps) by gradual removal of the _increment_refcount versions
> in favor of more consistent use of TempNewSymbol.  Arrays are tricky, 
> alas,
> so maybe the endpoint is still messy, but elsewhere we work with growable
> arrays of type Handle, so maybe there is a way forward.
>
> ? John
>
>
> On Jan 13, 2016, at 2:35 PM, Kim Barrett <kim.barrett at oracle.com 
> <mailto:kim.barrett at oracle.com>> wrote:
>>
>> I also like Markus's suggestion of SymbolTable symbol access returning
>> TempNewSymbol (perhaps under a better name!), but that is likely a
>> bigger change; I think this is still an improvement.
>>
>> Looks good, other than those minor things above.  Unless one of these
>> leads to a substantive change, I don't need another webrev.
>


From yumin.qi at oracle.com  Thu Jan 14 19:57:41 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 14 Jan 2016 11:57:41 -0800
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56977DBB.3070502@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
Message-ID: <5697FDB5.20505@oracle.com>

Hi, Vladimir

   I will integrate the current version, filed a new bug to follow the 
existing issue: asm should generate correct code for invoking an 
interface static method handle.
   https://bugs.openjdk.java.net/browse/JDK-8147419


   Latest ASM version is 5.0.4, I could not see the problem is addressed.
   http://asm.ow2.org/history.html

   The testcases in defmethod will be kept. When this problem solved in  
ASM, we can remove the relax in hotspot under the new bug 8147419.

   Coleen, how about this plan? Comment please.

   Thanks
   Yumin

On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
> Yumin,
>
> Please, file a follow-up bug for the missing check (interface static 
> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>
> I'd prefer to keep the original VM fix and quarantine affected tests 
> until ASM is fixed, but 2-phase fix is also fine with me.
>
> Not sure how to handle ASM problem. Is the problem present in the 
> latest ASM version?
>
> The best way would be to get it fixed upstream first and then sync 
> internal copy with upstream. defmeth tests use the library bundled 
> with the JDK.
>
> Best regards,
> Vladimir Ivanov
>
> On 12/21/15 9:52 PM, Yumin Qi wrote:
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>
>> This is REDO for bug 8087223, which was backed out due to failed on
>> 8143317 and 8143320.
>> The defmeth encoutered new failures after the fix, which now has correct
>> constant tags. The test bugs will be addressed in 8143320, which based
>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>
>> One difference from the attached for this webrev is that in MethodHandle
>> resolution, I relax the check for one specific case: Using MethodHandle
>> to invoke static default interface method. In this case, we must use
>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>> interface method tag!).  ASM currently has no API to generate
>> invokeinterface for a interface static default method through
>> MethodHandle invocation.
>>
>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>> Note the fix still fails 8143320 and 8143317 which are not fixed at the
>> momment.
>>
>>
>> Thanks
>> Yumin
>>
>>
>> Original post:
>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>
>> According to JVMS-8:
>>
>> JVMS-5.4.3.3 Method Resolution:
>>   " If C is an interface, method resolution throws an
>> IncompatibleClassChangeError."
>> JVMS-5.4.3.4 Interface Method Resolution:
>>   "If C is not an interface, interface method resolution throws an
>> IncompatibleClassChangeError"
>>
>> When invoke a method with resolved to an interface method, or invoke a
>> interface method with resolved to an instance method,  ICCE should be
>> thrown. The case usually happens when using tools like asmtools or
>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>
>> The fix is carrying the constantTag for the method at call and check if
>> tag is consistent with the method called. Doing this by adding a member
>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>> to see if tag matched with the correct method.
>>
>> The fix solved the problem when call is from interpreter and compiler,
>> bug for MethodHandle invoke, which should be addressed in another bug,
>> since the MethodHandle does not come with a byte stream and getting the
>> constant pool index at the invoke is not possible.  It will be addressed
>> in another bug.
>>
>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>> test list(in progress).
>> manually tested:  1) -Xint
>>                                 2) -Xcomp
>>                                 3) -Xcomp -XX:-TieredCompiltion
>>                                 4) -Xcomp -XX:+TieredCompilation
>>
>> Thanks to Coleen for helping fixed constant pool index and cleaned
>> LinkInfo.
>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>>
>> Second revision attached.
>>
>>
>>
>>
>> Thanks
>> Yumin


From john.r.rose at oracle.com  Thu Jan 14 20:08:50 2016
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 14 Jan 2016 12:08:50 -0800
Subject: RFR (xs) 8145940: TempNewSymbol should have correct copy and
	assignment functions
In-Reply-To: <5697F653.7020005@oracle.com>
References: <568EC461.8030209@oracle.com>
	<C18AD074-BB62-4F1D-B045-CE2FC5AB1443@oracle.com>
	<5694581A.804@oracle.com>
	<A115F1AB-D38C-4F08-B8B8-E15CFEAD0EB4@oracle.com>
	<2d5a4044-9851-454d-83c9-73cbb9b22552@default>
	<5695773E.5000504@oracle.com>
	<6369c1b4-ab5e-4b33-b34a-54869dbd3d2d@default>
	<56967B26.2090307@oracle.com> <5696959F.7080300@oracle.com>
	<5696B8A5.8060406@oracle.com>
	<D47A87BB-2816-472D-B749-3F7C834E8D41@oracle.com>
	<4ACB3255-C82C-4185-BFEB-DE2627925BCD@oracle.com>
	<5697F653.7020005@oracle.com>
Message-ID: <B68DA40A-96C6-4B91-9526-931EFD527A97@oracle.com>

On Jan 14, 2016, at 11:26 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
>>> If the answer is not "all of them" or "none
>>> of them", we have a manually-enforced distinction which may
>>> turn out to be fragile.
>> 
>> It's all but two.   Yes, it can be fragile.  So the reason for having TempNewSymbol in the first place was to track symbols coming into the JVM via char*, vs. via the constant pool.  At the time it was 90% the constant pool so we didn't want refcounting for every symbol operation, ala smart pointers.  It was a bigger not nice change at the time, and tons of refcounting.  We also really want to manipulate symbols as Symbol* rather than some other name but we've debated this lots of times.

This is totally reasonable, and can be incrementally fixed without polluting the bulk of the code with new refcounting.

I am not worried about Symbol* uses which are piggy-backing on an already-loaded klass.  (I.e., I'm happy to use Symbol* and Klass* pointers most places, as long as there is an associated *Handle somewhere keeping it all pinned down.)

So, simply have the two special API points (and any future API points that also have to be special, but no others) return a TempNewSymbol instead of a Symbol*.

Nearly all of our Symbol-using code stays that same; that's what I was trying to say with the code example:

>> Here's a thought, FWIW, about an incremental way forward on
>> the pre-increment problem.  It might be useful to split the "magic"
>> functions:
>> 
>>   TempNewSymbol lookup(int index, const char* name, int len, unsigned int hash);
>>   TempNewSymbol new_symbol(const char* name, TRAPS) { ? }
>>   Symbol* lookup_increment_refcount(int index, const char* name, int len, unsigned int hash);
>>   Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { ? }


? John

From ecki at zusammenkunft.net  Thu Jan 14 20:36:58 2016
From: ecki at zusammenkunft.net (ecki at zusammenkunft.net)
Date: Thu, 14 Jan 2016 21:36:58 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5697BEB2.3040206@oracle.com>
References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com>
Message-ID: <e4fcb99a-dba6-44fb-a428-95934c2efe6f.maildroid@localhost>

Hello,

Especially for the GC log it is bad if the file is lost after a restart. It is of course possible to include PID or timestamp into the logfile, and then the truncation is no option, however if you do that you have to do your own purging. If you just want a number of generations with a fixed filename the truncation is not very good, Generally speaking why would you want to tru cate anyway? (You always have the option to delete the files if you want to feel the start,) but in all automated scenarios I cant see a good reason for truncating existing logs.

So it should be at least an option to truncate. (And if you do that, I dont think using append mode is needed).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Dmitry Samersoff <dmitry.samersoff at oracle.com>
To: Marcus Larsson <marcus.larsson at oracle.com>, serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net
Sent: Do., 14 Jan. 2016 16:39
Subject: Re: RFR: 8146879: Truncate new UL log files

Marcus,

fopen(name, "wa+") truncate file before open it in append mode.

-Dmitry

On 2016-01-14 18:00, Marcus Larsson wrote:
> Hi,
> 
> Please review the following patch to make sure UL truncates existing log
> files before writing to them. Since files are opened in append mode,
> truncation isn't done automatically, so instead the patch adds an
> attempt to remove the log file before opening it.
> 
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146879
> 
> Testing:
> Included test through JPRT
> 
> Thanks,
> Marcus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From harold.seigel at oracle.com  Thu Jan 14 21:00:12 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 14 Jan 2016 16:00:12 -0500
Subject: RFR(S) 8137314: vm crash from test
	java/security/Policy/SignedJar/SignedJarTest.java
Message-ID: <56980C5C.1080207@oracle.com>

Hi,

Please review this small change to fix bug 8137314 
<https://bugs.openjdk.java.net/browse/JDK-8137314>

The bug is that the JVM verifier asserts when it is called recursively 
to verify a class that has already been linked.  There already exist 
checks in the verifier to prevent recursive verification of a class.  
This fix adds additional checks including one needed to prevent the JVM 
assert.

The additional checks were added wherever there was a constant pool 
reference following a call that could potentially load a class. Loading 
a class causes the JVM to call back to the JDK to do a protection domain 
check which can then cause classes to get linked and executed.  And, 
linking changes a class's constant pool.  There are many places in the 
verifier that could load a class because is_assignable_from() may load a 
class.  But, most of them encounter an existing recursive verification 
check before accessing the constant pool.  These checks already exist 
after every verify_method() call and after every bytecode is verified.

Although the problem occurred in the Jake repo, it's being fixed in 
JDK-9 because the problem is not Jigsaw specific.

Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/

JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314

The fix was tested with JCK Lang and VM tests, UTE quick and split 
verifier tests, and the hotspot, JDK vm, java/io, java/lang, and 
java/util JTreg tests, and the test case reported  in this RFR.

Thanks, Harold

From coleen.phillimore at oracle.com  Thu Jan 14 21:55:27 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 14 Jan 2016 16:55:27 -0500
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <5697FDB5.20505@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
	<5697FDB5.20505@oracle.com>
Message-ID: <5698194F.5040200@oracle.com>



On 1/14/16 2:57 PM, Yumin Qi wrote:
> Hi, Vladimir
>
>   I will integrate the current version, filed a new bug to follow the 
> existing issue: asm should generate correct code for invoking an 
> interface static method handle.
>   https://bugs.openjdk.java.net/browse/JDK-8147419
>
>
>   Latest ASM version is 5.0.4, I could not see the problem is addressed.
>   http://asm.ow2.org/history.html
>
>   The testcases in defmethod will be kept. When this problem solved 
> in  ASM, we can remove the relax in hotspot under the new bug 8147419.

I don't understand this.  Will these testcases in defmeth fail like they 
did in https://bugs.openjdk.java.net/browse/JDK-8143320 (ie. 100s of tests?)

Or was the failure because of the check that you relax for 8147419 .

Obviously you can't check it in if you get 100s of test failures.

Is https://bugs.openjdk.java.net/browse/JDK-8143317 fix reviewed and 
will be checked in before this change?

This change still looks good to me but the test issues should be 
resolved before you check it in.
>
>   Coleen, how about this plan? Comment please.

That's what I think.

Coleen

>
>   Thanks
>   Yumin
>
> On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
>> Yumin,
>>
>> Please, file a follow-up bug for the missing check (interface static 
>> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>>
>> I'd prefer to keep the original VM fix and quarantine affected tests 
>> until ASM is fixed, but 2-phase fix is also fine with me.
>>
>> Not sure how to handle ASM problem. Is the problem present in the 
>> latest ASM version?
>>
>> The best way would be to get it fixed upstream first and then sync 
>> internal copy with upstream. defmeth tests use the library bundled 
>> with the JDK.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 12/21/15 9:52 PM, Yumin Qi wrote:
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>
>>> This is REDO for bug 8087223, which was backed out due to failed on
>>> 8143317 and 8143320.
>>> The defmeth encoutered new failures after the fix, which now has 
>>> correct
>>> constant tags. The test bugs will be addressed in 8143320, which based
>>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>
>>> One difference from the attached for this webrev is that in 
>>> MethodHandle
>>> resolution, I relax the check for one specific case: Using MethodHandle
>>> to invoke static default interface method. In this case, we must use
>>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>>> interface method tag!).  ASM currently has no API to generate
>>> invokeinterface for a interface static default method through
>>> MethodHandle invocation.
>>>
>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>> Note the fix still fails 8143320 and 8143317 which are not fixed at the
>>> momment.
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> Original post:
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>
>>> According to JVMS-8:
>>>
>>> JVMS-5.4.3.3 Method Resolution:
>>>   " If C is an interface, method resolution throws an
>>> IncompatibleClassChangeError."
>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>   "If C is not an interface, interface method resolution throws an
>>> IncompatibleClassChangeError"
>>>
>>> When invoke a method with resolved to an interface method, or invoke a
>>> interface method with resolved to an instance method,  ICCE should be
>>> thrown. The case usually happens when using tools like asmtools or
>>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>>
>>> The fix is carrying the constantTag for the method at call and check if
>>> tag is consistent with the method called. Doing this by adding a member
>>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>>> to see if tag matched with the correct method.
>>>
>>> The fix solved the problem when call is from interpreter and compiler,
>>> bug for MethodHandle invoke, which should be addressed in another bug,
>>> since the MethodHandle does not come with a byte stream and getting the
>>> constant pool index at the invoke is not possible.  It will be 
>>> addressed
>>> in another bug.
>>>
>>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>>> test list(in progress).
>>> manually tested:  1) -Xint
>>>                                 2) -Xcomp
>>>                                 3) -Xcomp -XX:-TieredCompiltion
>>>                                 4) -Xcomp -XX:+TieredCompilation
>>>
>>> Thanks to Coleen for helping fixed constant pool index and cleaned
>>> LinkInfo.
>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>> Second revision attached.
>>>
>>>
>>>
>>>
>>> Thanks
>>> Yumin
>


From kim.barrett at oracle.com  Thu Jan 14 22:43:09 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 14 Jan 2016 17:43:09 -0500
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5697B7F2.50104@oracle.com>
References: <5697B7F2.50104@oracle.com>
Message-ID: <F6DC962A-662D-4315-976A-63BB240C23ED@oracle.com>

On Jan 14, 2016, at 10:00 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
> 
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146879
> 
> Testing:
> Included test through JPRT
> 
> Thanks,
> Marcus

Deleting possibly critical data seems like a good way to generate a mob of angry users.


From yumin.qi at oracle.com  Thu Jan 14 23:52:10 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 14 Jan 2016 15:52:10 -0800
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <5698194F.5040200@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
	<5697FDB5.20505@oracle.com> <5698194F.5040200@oracle.com>
Message-ID: <569834AA.6070801@oracle.com>

Coleen,

   8143317: jdk/test... this will be integrated first. Now it gets 
reviewed by Paul Sandoz, waiting for one more reviewer.
   8143320: this is the 100s failures(in fact not that many, it's 
testing against 4 versions, 49, 50, 51, 52. so about 25 kinds of 
failures). The test cases should be modified after 8145148 fix. This is 
not open issue, I will send you another email about it.

   After investigation of those failures, the result is
   1) some tests will be modified since after 8145148, the expected 
Error or Exception changed.
   2) some tests failed due to the reason in my last email:

    ASM could not generate a correct handle invoke to an interface 
static default method.
    In the new webrev of 8145148, I relax the check for invokestatic on 
an interface which should with an InterfaceMethodref tag, but now has to 
be with a Methodref. With this addressed in ASM, the relaxing check is 
no longer needed(8147419).

    So, with above steps, all the failures are about to be fixed.

Thanks
Yumin





On 1/14/2016 1:55 PM, Coleen Phillimore wrote:
>
>
> On 1/14/16 2:57 PM, Yumin Qi wrote:
>> Hi, Vladimir
>>
>>   I will integrate the current version, filed a new bug to follow the 
>> existing issue: asm should generate correct code for invoking an 
>> interface static method handle.
>>   https://bugs.openjdk.java.net/browse/JDK-8147419
>>
>>
>>   Latest ASM version is 5.0.4, I could not see the problem is addressed.
>>   http://asm.ow2.org/history.html
>>
>>   The testcases in defmethod will be kept. When this problem solved 
>> in  ASM, we can remove the relax in hotspot under the new bug 8147419.
>
> I don't understand this.  Will these testcases in defmeth fail like 
> they did in https://bugs.openjdk.java.net/browse/JDK-8143320 (ie. 100s 
> of tests?)
>
> Or was the failure because of the check that you relax for 8147419 .
>
> Obviously you can't check it in if you get 100s of test failures.
>
> Is https://bugs.openjdk.java.net/browse/JDK-8143317 fix reviewed and 
> will be checked in before this change?
>
> This change still looks good to me but the test issues should be 
> resolved before you check it in.
>>
>>   Coleen, how about this plan? Comment please.
>
> That's what I think.
>
> Coleen
>
>>
>>   Thanks
>>   Yumin
>>
>> On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
>>> Yumin,
>>>
>>> Please, file a follow-up bug for the missing check (interface static 
>>> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>>>
>>> I'd prefer to keep the original VM fix and quarantine affected tests 
>>> until ASM is fixed, but 2-phase fix is also fine with me.
>>>
>>> Not sure how to handle ASM problem. Is the problem present in the 
>>> latest ASM version?
>>>
>>> The best way would be to get it fixed upstream first and then sync 
>>> internal copy with upstream. defmeth tests use the library bundled 
>>> with the JDK.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 12/21/15 9:52 PM, Yumin Qi wrote:
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>>
>>>> This is REDO for bug 8087223, which was backed out due to failed on
>>>> 8143317 and 8143320.
>>>> The defmeth encoutered new failures after the fix, which now has 
>>>> correct
>>>> constant tags. The test bugs will be addressed in 8143320, which based
>>>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>>
>>>> One difference from the attached for this webrev is that in 
>>>> MethodHandle
>>>> resolution, I relax the check for one specific case: Using 
>>>> MethodHandle
>>>> to invoke static default interface method. In this case, we must use
>>>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>>>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>>>> interface method tag!).  ASM currently has no API to generate
>>>> invokeinterface for a interface static default method through
>>>> MethodHandle invocation.
>>>>
>>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>>> Note the fix still fails 8143320 and 8143317 which are not fixed at 
>>>> the
>>>> momment.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> Original post:
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>>
>>>>
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>>
>>>> According to JVMS-8:
>>>>
>>>> JVMS-5.4.3.3 Method Resolution:
>>>>   " If C is an interface, method resolution throws an
>>>> IncompatibleClassChangeError."
>>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>>   "If C is not an interface, interface method resolution throws an
>>>> IncompatibleClassChangeError"
>>>>
>>>> When invoke a method with resolved to an interface method, or invoke a
>>>> interface method with resolved to an instance method,  ICCE should be
>>>> thrown. The case usually happens when using tools like asmtools or
>>>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>>>
>>>> The fix is carrying the constantTag for the method at call and 
>>>> check if
>>>> tag is consistent with the method called. Doing this by adding a 
>>>> member
>>>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>>>> to see if tag matched with the correct method.
>>>>
>>>> The fix solved the problem when call is from interpreter and compiler,
>>>> bug for MethodHandle invoke, which should be addressed in another bug,
>>>> since the MethodHandle does not come with a byte stream and getting 
>>>> the
>>>> constant pool index at the invoke is not possible.  It will be 
>>>> addressed
>>>> in another bug.
>>>>
>>>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>>>> test list(in progress).
>>>> manually tested:  1) -Xint
>>>>                                 2) -Xcomp
>>>>                                 3) -Xcomp -XX:-TieredCompiltion
>>>>                                 4) -Xcomp -XX:+TieredCompilation
>>>>
>>>> Thanks to Coleen for helping fixed constant pool index and cleaned
>>>> LinkInfo.
>>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>>
>>>>
>>>>
>>>> Second revision attached.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>
>


From david.holmes at oracle.com  Fri Jan 15 02:32:22 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Jan 2016 12:32:22 +1000
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <CA+kOe09ntiOcLGeNKMQCv4KCztsGWQjNdq30LBNc+eEn2=qmmQ@mail.gmail.com>
References: <56962632.7080404@oracle.com>
	<CA+kOe09bxV5gUbjrELqxJWpi06ZBwYEB0wp70iPukGE2RnW7BA@mail.gmail.com>
	<569745D9.1090007@oracle.com>
	<CA+kOe09ntiOcLGeNKMQCv4KCztsGWQjNdq30LBNc+eEn2=qmmQ@mail.gmail.com>
Message-ID: <56985A36.7070905@oracle.com>

On 15/01/2016 4:59 AM, Martin Buchholz wrote:
> The process grim reaper ends up being the first point of failure since
> it tries not to waste the user's memory and it's in a core library,
> but in principle it's not special.  I think a more general workaround
> would be to add a hotspot flag that would add a memory safety zone to
> all threads.  If it's known that TLS is stealing 32k from every
> thread's stack, then the flag should ensure that every thread stack is
> 32k larger.

I think we need a point fix for the process reaper case in the immediate 
term. We can then consider how to better address the general case in the 
medium to long term.

> More generally, I was hoping that hotspot would ensure that the -Xss
> size was available for actual java stack frames and OS overhead was
> added on automatically, but that is hard to implement, so the best
> alternative workaround is for users to be able to specify that
> additional stack size padding.  Maybe -XX:StackSizeOverhead=32768 ?

Even this is still a band-aid - the user has to experience the problem, 
recognize it, and then figure out the right adjustment to add. Plus if 
any third-party library uses native TLS the requirement could change 
dynamically.

So I'd prefer a new RFE to look at this general issue.

Thanks,
David

From david.holmes at oracle.com  Fri Jan 15 04:25:56 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Jan 2016 14:25:56 +1000
Subject: RFR: 8143558 evaluate if thr_sigsetmask can be removed from
	hotspot (solaris) codebase
In-Reply-To: <56974903.3060903@oracle.com>
References: <567AA1C0.4010801@gmx.de> <56974903.3060903@oracle.com>
Message-ID: <569874D4.9030500@oracle.com>

On 14/01/2016 5:06 PM, David Holmes wrote:
> Hi Sebastien,
>
> Sorry for the delay on this. I will take this and test it etc.

Tested, Reviewed and currently being pushed.

Thanks,
David

> Thanks,
> David
>
> On 23/12/2015 11:29 PM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> as a side-effect of https://bugs.openjdk.java.net/browse/JDK-8136978 i
>> created
>> a Enhancement in JBS
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143558
>>
>> As David commented in JBS it is possible to replace the usage of
>> thr_sigsetmask with pthread-sigmask.
>>
>> Maybe the change is not worth anything on its own. I hope that we can
>> find more duplicated code that can be removed easier.
>>
>> I have create patch that replaces all calls to thr_sigsetmask:
>>
>> http://cr.openjdk.java.net/~sebastian/8143558/webrev.02/
>>
>> Unfortunately (Lacking a solaris environment) I am not able to compile
>> check / jtreg-test this change.
>>
>> --
>> Sebastian
>>

From marcus.larsson at oracle.com  Fri Jan 15 07:52:05 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 15 Jan 2016 08:52:05 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5697BEB2.3040206@oracle.com>
References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com>
Message-ID: <5698A525.7000209@oracle.com>


On 01/14/2016 04:28 PM, Dmitry Samersoff wrote:
> Marcus,
>
> fopen(name, "wa+") truncate file before open it in append mode.

Ah, didn't know you could do that. If it works that would be much 
better, I'll give it a shot.

Thanks,
Marcus

>
> -Dmitry
>
> On 2016-01-14 18:00, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to make sure UL truncates existing log
>> files before writing to them. Since files are opened in append mode,
>> truncation isn't done automatically, so instead the patch adds an
>> attempt to remove the log file before opening it.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>
>> Testing:
>> Included test through JPRT
>>
>> Thanks,
>> Marcus
>


From bengt.rutisson at oracle.com  Fri Jan 15 09:13:58 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 15 Jan 2016 10:13:58 +0100
Subject: RFR: JDK-8143146 : SIGSEGV,
	Problematic frame: # V [libjvm.so+0xd0c0cc]
	void InstanceKlass::oop_oop_iterate_oop_maps_specialized<true, oopDesc*,
	MarkAndPushClosure>
In-Reply-To: <1452782541.15942.5.camel@oracle.com>
References: <c283e7e5-41d7-4782-bf41-620b30ed955d@default>	<8eaf4a8e-5eb7-49ef-a95b-0bc71dc3b1ba@default>	<1452782402.15942.3.camel@oracle.com>
	<1452782541.15942.5.camel@oracle.com>
Message-ID: <5698B856.9040807@oracle.com>


Hi Shafi,

On 2016-01-14 15:42, Thomas Schatzl wrote:
> Hi,
>
>    I just noticed that I am only committer for 8u too, sorry :(

I'm a reviewer in 8u.

I had a look and the backport looks correct to me.

Reviewed.

Bengt

>
> Thomas
>
> On Thu, 2016-01-14 at 15:40 +0100, Thomas Schatzl wrote:
>> Hi,
>>
>> On Thu, 2016-01-14 at 03:58 -0800, Shafi Ahmad wrote:
>>> Hi,
>>>
>>> Please review the backport of bug: "JDKJDK-8143146 : SIGSEGV,
>>> Problematic frame: # V [libjvm.so+0xd0c0cc] void
>>> InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,M
>>> ar
>>> kAndPushClosure>" to jdk8u-dev
>> Thanks for backporting this issue! This issue is exactly the one I
>> would have otherwise asked to have backported.
>>   
>>> Please note that this is not a clean backport due to -
>>>
>>> A) Location of file "g1CollectedHeap.cpp" are different in jdk9 and
>>> jdk8:
>>>
>>>     jdk8: src/share/vm/gc_implementation/g1/
>>>
>>>     jdk9: src/share/vm/gc/g1/
>>>   
>>>
>>> B) Compilation failure:
>>>
>>> Variable args assert "#define assert(p, ...) vmassert(p,
>>> __VA_ARGS__)" is defined in jdk9/hs
>>> -rt/hotspot/src/share/vm/utilities/debug.hpp where as it is not
>>> defined in jdk8 and hence changeset leads to compilation failure.
>>>
>>> Used err_msg ["typedef FormatBuffer<> err_msg;]" which convert var
>>> args to single arg. It is used in many places even in jdk9/hs
>>> -rt/hotspot.
>> The indentation of the parameters in g1CollectedHeap.cpp, line 3772
>> is
>> wrong. It should align with the err_msg method, not the assert.
>>   
>>> C) jdk8 does not have "/test/lib" used for "import
>>> sun.hotspot.WhiteBox;" so I have change the line
>>> + * @library /testlibrary /test/lib
>>> to
>>> + * @library /testlibrary /testlibrary/whitebox
>>   looks good otherwise.
>>
>> Thanks,
>>    Thomas
>>


From bengt.rutisson at oracle.com  Fri Jan 15 09:27:44 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 15 Jan 2016 10:27:44 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <F6DC962A-662D-4315-976A-63BB240C23ED@oracle.com>
References: <5697B7F2.50104@oracle.com>
	<F6DC962A-662D-4315-976A-63BB240C23ED@oracle.com>
Message-ID: <5698BB90.7000904@oracle.com>



On 2016-01-14 23:43, Kim Barrett wrote:
> On Jan 14, 2016, at 10:00 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>> Hi,
>>
>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>
>> Testing:
>> Included test through JPRT
>>
>> Thanks,
>> Marcus
> Deleting possibly critical data seems like a good way to generate a mob of angry users.


The GC log has always been overwritten on a restart. The propsed change 
to the UL file handling makes the log files work similar to how they 
used to work. So, I think we will get less problems with users after 
this change than before it.

Bengt
>


From dmitry.samersoff at oracle.com  Fri Jan 15 09:58:06 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 15 Jan 2016 12:58:06 +0300
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5698BB90.7000904@oracle.com>
References: <5697B7F2.50104@oracle.com>
	<F6DC962A-662D-4315-976A-63BB240C23ED@oracle.com>
	<5698BB90.7000904@oracle.com>
Message-ID: <5698C2AE.5030107@oracle.com>

Marcus,

Generally speaking (out of scope of this changes)

1. Appending (i.e. seek before write) isn't free
2. I'm against of overwriting the log on restart.

So personally, I would prefer:

a) Have a /signal/DCMD/linecount threshold/ that cause VM to close
existing log file and start new one with a simple numbering (i.e. close
jvm.log.001 start jvm.log.002)

b) Print clear visible banner to a log on JVM start and continue writing
to the same file.

c) Implement syslog support.

Leave everything else to variety of log management tools that allows to
implement wide variety of security and rotation policies.

-Dmitry


On 2016-01-15 12:27, Bengt Rutisson wrote:
> 
> 
> On 2016-01-14 23:43, Kim Barrett wrote:
>> On Jan 14, 2016, at 10:00 AM, Marcus Larsson
>> <marcus.larsson at oracle.com> wrote:
>>> Hi,
>>>
>>> Please review the following patch to make sure UL truncates existing
>>> log files before writing to them. Since files are opened in append
>>> mode, truncation isn't done automatically, so instead the patch adds
>>> an attempt to remove the log file before opening it.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>
>>> Testing:
>>> Included test through JPRT
>>>
>>> Thanks,
>>> Marcus
>> Deleting possibly critical data seems like a good way to generate a
>> mob of angry users.
> 
> 
> The GC log has always been overwritten on a restart. The propsed change
> to the UL file handling makes the log files work similar to how they
> used to work. So, I think we will get less problems with users after
> this change than before it.
> 
> Bengt
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From marcus.larsson at oracle.com  Fri Jan 15 09:59:12 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 15 Jan 2016 10:59:12 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <e4fcb99a-dba6-44fb-a428-95934c2efe6f.maildroid@localhost>
References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com>
	<e4fcb99a-dba6-44fb-a428-95934c2efe6f.maildroid@localhost>
Message-ID: <5698C2F0.8010309@oracle.com>

Hi,

On 01/14/2016 09:36 PM, ecki at zusammenkunft.net wrote:
> Hello,
>
> Especially for the GC log it is bad if the file is lost after a restart. It is of course possible to include PID or timestamp into the logfile, and then the truncation is no option, however if you do that you have to do your own purging. If you just want a number of generations with a fixed filename the truncation is not very good, Generally speaking why would you want to tru cate anyway? (You always have the option to delete the files if you want to feel the start,) but in all automated scenarios I cant see a good reason for truncating existing logs.
>
> So it should be at least an option to truncate.

I can see some use cases for appending to the log files, but I think the 
expected behavior is that files should be truncated. I believe it's 
worth keeping optional though, so we could add an option for log files 
whether or not they should be truncated before used (with the default 
being truncating). This way we also keep the previous behavior of -Xloggc.

> (And if you do that, I dont think using append mode is needed).

External log rotation tools require us to use append mode to work 
correctly, and we should do so regardless of truncation settings.

Thanks,
Marcus

>
> Gruss
> Bernd
>


From marcus.larsson at oracle.com  Fri Jan 15 13:22:53 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 15 Jan 2016 14:22:53 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5698A525.7000209@oracle.com>
References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com>
	<5698A525.7000209@oracle.com>
Message-ID: <5698F2AD.7060503@oracle.com>

Hi Dmitry,

On 01/15/2016 08:52 AM, Marcus Larsson wrote:
>
> On 01/14/2016 04:28 PM, Dmitry Samersoff wrote:
>> Marcus,
>>
>> fopen(name, "wa+") truncate file before open it in append mode.
>
> Ah, didn't know you could do that. If it works that would be much 
> better, I'll give it a shot.

Unfortunately this doesn't work on all platforms. Windows fails to open 
files in this mode, so I'm guessing it's some GCC extension we can't use.

Thanks,
Marcus

>
> Thanks,
> Marcus
>
>>
>> -Dmitry
>>
>> On 2016-01-14 18:00, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to make sure UL truncates existing 
>>> log
>>> files before writing to them. Since files are opened in append mode,
>>> truncation isn't done automatically, so instead the patch adds an
>>> attempt to remove the log file before opening it.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>
>>> Testing:
>>> Included test through JPRT
>>>
>>> Thanks,
>>> Marcus
>>
>


From marcus.larsson at oracle.com  Fri Jan 15 13:35:57 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 15 Jan 2016 14:35:57 +0100
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5698F0E9.4080806@oracle.com>
References: <5697B7F2.50104@oracle.com>
	<F6DC962A-662D-4315-976A-63BB240C23ED@oracle.com>
	<5698BB90.7000904@oracle.com> <5698C2AE.5030107@oracle.com>
	<5698F0E9.4080806@oracle.com>
Message-ID: <5698F5BD.4020201@oracle.com>

Hi,

On 01/15/2016 02:15 PM, Stefan S?rne wrote:
>
> I will second what others have already said.
>
> I do not think the existing logs should be removed (even if this has 
> been the case before).
>
> A quite likely scenario is that when a critical application hangs, 
> crash or misbehaves, a quick restart is done. After the service is up 
> again, the detective work starts to understand why it happened and if 
> the jvm log is truncated, one good source of info would be lost.
>
> So I would expect default is to either append (or backup earlier log) 
> and to also log rotate.

Alright, I'm convinced. Defaulting to appending rather than overwriting 
seems like a slightly better default.

I'll update the patch to make this a configurable option where appending 
is the default.

Thanks,
Marcus

>
> Cheers,
> Stefan
>
>
>
> Den 2016-01-15 kl. 10:58, skrev Dmitry Samersoff:
>> Marcus,
>>
>> Generally speaking (out of scope of this changes)
>>
>> 1. Appending (i.e. seek before write) isn't free
>> 2. I'm against of overwriting the log on restart.
>>
>> So personally, I would prefer:
>>
>> a) Have a /signal/DCMD/linecount threshold/ that cause VM to close
>> existing log file and start new one with a simple numbering (i.e. close
>> jvm.log.001 start jvm.log.002)
>>
>> b) Print clear visible banner to a log on JVM start and continue writing
>> to the same file.
>>
>> c) Implement syslog support.
>>
>> Leave everything else to variety of log management tools that allows to
>> implement wide variety of security and rotation policies.
>>
>> -Dmitry
>>
>>
>> On 2016-01-15 12:27, Bengt Rutisson wrote:
>>>
>>> On 2016-01-14 23:43, Kim Barrett wrote:
>>>> On Jan 14, 2016, at 10:00 AM, Marcus Larsson
>>>> <marcus.larsson at oracle.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch to make sure UL truncates existing
>>>>> log files before writing to them. Since files are opened in append
>>>>> mode, truncation isn't done automatically, so instead the patch adds
>>>>> an attempt to remove the log file before opening it.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>
>>>>> Testing:
>>>>> Included test through JPRT
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>> Deleting possibly critical data seems like a good way to generate a
>>>> mob of angry users.
>>>
>>> The GC log has always been overwritten on a restart. The propsed change
>>> to the UL file handling makes the log files work similar to how they
>>> used to work. So, I think we will get less problems with users after
>>> this change than before it.
>>>
>>> Bengt
>>
>


From dmitry.samersoff at oracle.com  Fri Jan 15 14:11:46 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 15 Jan 2016 17:11:46 +0300
Subject: RFR: 8146879: Truncate new UL log files
In-Reply-To: <5698F2AD.7060503@oracle.com>
References: <5697B7F2.50104@oracle.com> <5697BEB2.3040206@oracle.com>
	<5698A525.7000209@oracle.com> <5698F2AD.7060503@oracle.com>
Message-ID: <5698FE22.1000408@oracle.com>

Marcus,

> Unfortunately this doesn't work on all platforms.
> Windows fails to open
> files in this mode, so I'm guessing
> it's some GCC extension we can't use.

If my memory is not bogus, the same effect under windows could be
achieved by:

int fd = _open("filename", _O_RDWR | _O_APPEND | _O_CREAT | _O_TRUNC );
FILE * stream = _fdopen(fd, "a+");

-Dmitry


On 2016-01-15 16:22, Marcus Larsson wrote:
> Hi Dmitry,
> 
> On 01/15/2016 08:52 AM, Marcus Larsson wrote:
>>
>> On 01/14/2016 04:28 PM, Dmitry Samersoff wrote:
>>> Marcus,
>>>
>>> fopen(name, "wa+") truncate file before open it in append mode.
>>
>> Ah, didn't know you could do that. If it works that would be much
>> better, I'll give it a shot.
> 
> Unfortunately this doesn't work on all platforms. Windows fails to open
> files in this mode, so I'm guessing it's some GCC extension we can't use.
> 
> Thanks,
> Marcus
> 
>>
>> Thanks,
>> Marcus
>>
>>>
>>> -Dmitry
>>>
>>> On 2016-01-14 18:00, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to make sure UL truncates existing
>>>> log
>>>> files before writing to them. Since files are opened in append mode,
>>>> truncation isn't done automatically, so instead the patch adds an
>>>> attempt to remove the log file before opening it.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>
>>>> Testing:
>>>> Included test through JPRT
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

From karen.kinnear at oracle.com  Fri Jan 15 14:41:56 2016
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 15 Jan 2016 09:41:56 -0500
Subject: RFR(S) 8137314: vm crash from test
	java/security/Policy/SignedJar/SignedJarTest.java
In-Reply-To: <56980C5C.1080207@oracle.com>
References: <56980C5C.1080207@oracle.com>
Message-ID: <C06429AD-30B5-46C8-91AA-CDD7EACBF01A@oracle.com>

Harold,

Change looks good. Thank you for doing this in jdk9 since it is a general issue.
And thank you both for the extensive testing and for listing it in the RFR :-)

thanks,
Karen

> On Jan 14, 2016, at 4:00 PM, harold seigel <harold.seigel at oracle.com> wrote:
> 
> Hi,
> 
> Please review this small change to fix bug 8137314 <https://bugs.openjdk.java.net/browse/JDK-8137314>
> 
> The bug is that the JVM verifier asserts when it is called recursively to verify a class that has already been linked.  There already exist checks in the verifier to prevent recursive verification of a class.  This fix adds additional checks including one needed to prevent the JVM assert.
> 
> The additional checks were added wherever there was a constant pool reference following a call that could potentially load a class. Loading a class causes the JVM to call back to the JDK to do a protection domain check which can then cause classes to get linked and executed.  And, linking changes a class's constant pool.  There are many places in the verifier that could load a class because is_assignable_from() may load a class.  But, most of them encounter an existing recursive verification check before accessing the constant pool.  These checks already exist after every verify_method() call and after every bytecode is verified.
> 
> Although the problem occurred in the Jake repo, it's being fixed in JDK-9 because the problem is not Jigsaw specific.
> 
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/
> 
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314
> 
> The fix was tested with JCK Lang and VM tests, UTE quick and split verifier tests, and the hotspot, JDK vm, java/io, java/lang, and java/util JTreg tests, and the test case reported  in this RFR.
> 
> Thanks, Harold


From harold.seigel at oracle.com  Fri Jan 15 14:53:47 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 15 Jan 2016 09:53:47 -0500
Subject: RFR(S) 8137314: vm crash from test
	java/security/Policy/SignedJar/SignedJarTest.java
In-Reply-To: <C06429AD-30B5-46C8-91AA-CDD7EACBF01A@oracle.com>
References: <56980C5C.1080207@oracle.com>
	<C06429AD-30B5-46C8-91AA-CDD7EACBF01A@oracle.com>
Message-ID: <569907FB.2080800@oracle.com>

Hi Karen,

Thanks for reviewing this so quickly.

Harold

On 1/15/2016 9:41 AM, Karen Kinnear wrote:
> Harold,
>
> Change looks good. Thank you for doing this in jdk9 since it is a general issue.
> And thank you both for the extensive testing and for listing it in the RFR :-)
>
> thanks,
> Karen
>
>> On Jan 14, 2016, at 4:00 PM, harold seigel <harold.seigel at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this small change to fix bug 8137314 <https://bugs.openjdk.java.net/browse/JDK-8137314>
>>
>> The bug is that the JVM verifier asserts when it is called recursively to verify a class that has already been linked.  There already exist checks in the verifier to prevent recursive verification of a class.  This fix adds additional checks including one needed to prevent the JVM assert.
>>
>> The additional checks were added wherever there was a constant pool reference following a call that could potentially load a class. Loading a class causes the JVM to call back to the JDK to do a protection domain check which can then cause classes to get linked and executed.  And, linking changes a class's constant pool.  There are many places in the verifier that could load a class because is_assignable_from() may load a class.  But, most of them encounter an existing recursive verification check before accessing the constant pool.  These checks already exist after every verify_method() call and after every bytecode is verified.
>>
>> Although the problem occurred in the Jake repo, it's being fixed in JDK-9 because the problem is not Jigsaw specific.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314
>>
>> The fix was tested with JCK Lang and VM tests, UTE quick and split verifier tests, and the hotspot, JDK vm, java/io, java/lang, and java/util JTreg tests, and the test case reported  in this RFR.
>>
>> Thanks, Harold


From george.triantafillou at oracle.com  Fri Jan 15 16:59:49 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Fri, 15 Jan 2016 11:59:49 -0500
Subject: RFR(S) 8137314: vm crash from test
	java/security/Policy/SignedJar/SignedJarTest.java
In-Reply-To: <56980C5C.1080207@oracle.com>
References: <56980C5C.1080207@oracle.com>
Message-ID: <56992585.3040408@oracle.com>

Hi Harold,

Your changes look good.  Thanks for fixing this.

-George

On 1/14/2016 4:00 PM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug 8137314 
> <https://bugs.openjdk.java.net/browse/JDK-8137314>
>
> The bug is that the JVM verifier asserts when it is called recursively 
> to verify a class that has already been linked.  There already exist 
> checks in the verifier to prevent recursive verification of a class.  
> This fix adds additional checks including one needed to prevent the 
> JVM assert.
>
> The additional checks were added wherever there was a constant pool 
> reference following a call that could potentially load a class. 
> Loading a class causes the JVM to call back to the JDK to do a 
> protection domain check which can then cause classes to get linked and 
> executed.  And, linking changes a class's constant pool.  There are 
> many places in the verifier that could load a class because 
> is_assignable_from() may load a class.  But, most of them encounter an 
> existing recursive verification check before accessing the constant 
> pool.  These checks already exist after every verify_method() call and 
> after every bytecode is verified.
>
> Although the problem occurred in the Jake repo, it's being fixed in 
> JDK-9 because the problem is not Jigsaw specific.
>
> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314
>
> The fix was tested with JCK Lang and VM tests, UTE quick and split 
> verifier tests, and the hotspot, JDK vm, java/io, java/lang, and 
> java/util JTreg tests, and the test case reported  in this RFR.
>
> Thanks, Harold


From harold.seigel at oracle.com  Fri Jan 15 18:12:52 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 15 Jan 2016 13:12:52 -0500
Subject: RFR(S) 8137314: vm crash from test
	java/security/Policy/SignedJar/SignedJarTest.java
In-Reply-To: <56992585.3040408@oracle.com>
References: <56980C5C.1080207@oracle.com> <56992585.3040408@oracle.com>
Message-ID: <569936A4.60205@oracle.com>

Thanks George, for the review!

Harold

On 1/15/2016 11:59 AM, George Triantafillou wrote:
> Hi Harold,
>
> Your changes look good.  Thanks for fixing this.
>
> -George
>
> On 1/14/2016 4:00 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix bug 8137314 
>> <https://bugs.openjdk.java.net/browse/JDK-8137314>
>>
>> The bug is that the JVM verifier asserts when it is called 
>> recursively to verify a class that has already been linked. There 
>> already exist checks in the verifier to prevent recursive 
>> verification of a class.  This fix adds additional checks including 
>> one needed to prevent the JVM assert.
>>
>> The additional checks were added wherever there was a constant pool 
>> reference following a call that could potentially load a class. 
>> Loading a class causes the JVM to call back to the JDK to do a 
>> protection domain check which can then cause classes to get linked 
>> and executed.  And, linking changes a class's constant pool.  There 
>> are many places in the verifier that could load a class because 
>> is_assignable_from() may load a class.  But, most of them encounter 
>> an existing recursive verification check before accessing the 
>> constant pool.  These checks already exist after every 
>> verify_method() call and after every bytecode is verified.
>>
>> Although the problem occurred in the Jake repo, it's being fixed in 
>> JDK-9 because the problem is not Jigsaw specific.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314
>>
>> The fix was tested with JCK Lang and VM tests, UTE quick and split 
>> verifier tests, and the hotspot, JDK vm, java/io, java/lang, and 
>> java/util JTreg tests, and the test case reported  in this RFR.
>>
>> Thanks, Harold
>


From coleen.phillimore at oracle.com  Fri Jan 15 22:12:18 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 15 Jan 2016 17:12:18 -0500
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <567861EA.6080109@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
Message-ID: <56996EC2.1020306@oracle.com>


Hi,

I've read this change and it looks correct to me.  The 32/64 bit natural 
alignment should be used for the vtable and itable embedded fields, and 
this change accomplishes this.


On 12/21/15 3:32 PM, Chris Plummer wrote:
> Hello,
>
> I'm doing a bit of a reset on this thread. I've updated the webrev. 
> The only change is fixing SA to also no longer do the aligning:
>
> https://bugs.openjdk.java.net/browse/JDK-8143608
> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/
>
> I've also filed the following CRs for pre-existing bugs instead of 
> addressing them with these changes:
>
> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the 
> incorrect size and has no test
> https://bugs.openjdk.java.net/browse/JDK-8145628
> hotspot metadata classes shouldn't use HeapWordSize or heap related 
> macros like align_object_size

I am currently working on this bug because it is wrong to use 
align_object_size() for metadata.  Metadata should be naturally aligned 
and I'll verify it's the case in metaspace allocation code.

Thanks to Mikael for the alert about SA code that copies this.  It seems 
that the SA shouldn't report metadata sizes if that's also reported with 
jcmd.  Maybe the jstat -classstats functionality that uses SA (which is 
wrong now) can be removed?  And why would someone use this on a core file?

>
> And just restating here why I think the removal of these 
> align_object_field references is safe:
>
> The argument to align_object_offset() is the offset in words, and it 
> returns the offset in words after aligning to a HeapWordsPerLong 
> boundary. Since the argument is in words, there is no concern with my 
> changes removing word alignment of something that is not already word 
> aligned. It must already be word aligned or the current implementation 
> would be broken.
>
> Since HeapWordsPerLong is 1 on 64-bit, the end result is that 
> align_object_offset() is a no-op, so the removal is having no impact 
> on 64-bit.

It (align_object_offset) is actually wrong, but since the size of the 
objects are naturally aligned, I think it's better to not have some 
explicit alignment call.
>
> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset 
> will remain 32-bit word aligned, and not be 64-bit aligned. This is in 
> fact the goal of this change, so what remains is to show that 64-bit 
> alignment of the fields is not needed on 32-bit. Since all of the 
> fields for which alignment has been removed are 32-bit types, it is 
> safe to keep them 32-bit word aligned instead of making them 64-bit 
> aligned.
>

Agree.  This looks good.

Thanks,
Coleen

> thanks,
>
> Chris
>
>
>
> On 12/4/15 2:02 PM, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143608
>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>
>> A bit of background would help. The InstanceKlass object has a number 
>> of variable length fields that are laid out after the declared 
>> fields. When an InstanceKlass object is allocated, extra memory is 
>> allocated for it to leave room for these fields. The first three of 
>> these fields are vtable, itable, and nonstatic_oopmap. They are all 
>> arrays of HeapWord sized values, which means void* size, which means 
>> they only need 32-bit alignment on 32-bit systems. However, they have 
>> always been 64-bit aligned. This webrev removes the forced 64-bit 
>> alignment on 32-bit systems, saving footprint.
>>
>> This change affects all 32-bit platforms. It should have no net 
>> impact on 64-bit platforms since the fields remain (naturally) 64-bit 
>> aligned (unless of course I've introduced a bug). The intent is to 
>> not change what is done for 64-bit platforms.
>>
>> BTW, there is a change to AARCH64, which may seem odd at first. It 
>> just removes an "if" block where the condition should always have 
>> evaluated to false, so it should have no net affect.
>>
>> Tested with JPRT "-testset hotspot". Please let me know if you think 
>> there are any additional tests that should be run.
>>
>> thanks,
>>
>> Chris
>>
>


From chris.plummer at oracle.com  Fri Jan 15 22:27:54 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 15 Jan 2016 14:27:54 -0800
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <56996EC2.1020306@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com>
Message-ID: <5699726A.6000403@oracle.com>

Hi Coleen,

On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>
> Hi,
>
> I've read this change and it looks correct to me.  The 32/64 bit 
> natural alignment should be used for the vtable and itable embedded 
> fields, and this change accomplishes this.
Thanks for looking at this. It's much appreciated.
>
>
> On 12/21/15 3:32 PM, Chris Plummer wrote:
>> Hello,
>>
>> I'm doing a bit of a reset on this thread. I've updated the webrev. 
>> The only change is fixing SA to also no longer do the aligning:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143608
>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/
>>
>> I've also filed the following CRs for pre-existing bugs instead of 
>> addressing them with these changes:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the 
>> incorrect size and has no test
>> https://bugs.openjdk.java.net/browse/JDK-8145628
>> hotspot metadata classes shouldn't use HeapWordSize or heap related 
>> macros like align_object_size
>
> I am currently working on this bug because it is wrong to use 
> align_object_size() for metadata.  Metadata should be naturally 
> aligned and I'll verify it's the case in metaspace allocation code.
>
> Thanks to Mikael for the alert about SA code that copies this.  It 
> seems that the SA shouldn't report metadata sizes if that's also 
> reported with jcmd.  Maybe the jstat -classstats functionality that 
> uses SA (which is wrong now) can be removed?  And why would someone 
> use this on a core file?
Well, that's a good question for the serviceability team.
>
>>
>> And just restating here why I think the removal of these 
>> align_object_field references is safe:
>>
>> The argument to align_object_offset() is the offset in words, and it 
>> returns the offset in words after aligning to a HeapWordsPerLong 
>> boundary. Since the argument is in words, there is no concern with my 
>> changes removing word alignment of something that is not already word 
>> aligned. It must already be word aligned or the current 
>> implementation would be broken.
>>
>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that 
>> align_object_offset() is a no-op, so the removal is having no impact 
>> on 64-bit.
>
> It (align_object_offset) is actually wrong, but since the size of the 
> objects are naturally aligned, I think it's better to not have some 
> explicit alignment call.
>>
>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset 
>> will remain 32-bit word aligned, and not be 64-bit aligned. This is 
>> in fact the goal of this change, so what remains is to show that 
>> 64-bit alignment of the fields is not needed on 32-bit. Since all of 
>> the fields for which alignment has been removed are 32-bit types, it 
>> is safe to keep them 32-bit word aligned instead of making them 
>> 64-bit aligned.
>>
>
> Agree.  This looks good.
Great. Thanks again.

Chris
>
> Thanks,
> Coleen
>
>> thanks,
>>
>> Chris
>>
>>
>>
>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>>
>>> A bit of background would help. The InstanceKlass object has a 
>>> number of variable length fields that are laid out after the 
>>> declared fields. When an InstanceKlass object is allocated, extra 
>>> memory is allocated for it to leave room for these fields. The first 
>>> three of these fields are vtable, itable, and nonstatic_oopmap. They 
>>> are all arrays of HeapWord sized values, which means void* size, 
>>> which means they only need 32-bit alignment on 32-bit systems. 
>>> However, they have always been 64-bit aligned. This webrev removes 
>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>
>>> This change affects all 32-bit platforms. It should have no net 
>>> impact on 64-bit platforms since the fields remain (naturally) 
>>> 64-bit aligned (unless of course I've introduced a bug). The intent 
>>> is to not change what is done for 64-bit platforms.
>>>
>>> BTW, there is a change to AARCH64, which may seem odd at first. It 
>>> just removes an "if" block where the condition should always have 
>>> evaluated to false, so it should have no net affect.
>>>
>>> Tested with JPRT "-testset hotspot". Please let me know if you think 
>>> there are any additional tests that should be run.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>
>


From jiangli.zhou at Oracle.COM  Sat Jan 16 00:05:59 2016
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Fri, 15 Jan 2016 16:05:59 -0800
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
Message-ID: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>

Please review the following improvements to HashtableTextDump::get_num() and HashtableTextDump::corrupted_if() described in JDK-8147500 <https://bugs.openjdk.java.net/browse/JDK-8147500>.

 - The HashtableTextDump::get_num() is use to parse an integer value from the input file. It should check for integer overflow and report error without continuing.
 - The HashtableTextDump::corrupted_if() should take an additional argument so caller can pass a meaningful error message.

Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/

Thanks,
Jiangli





From thomas.stuefe at gmail.com  Sat Jan 16 09:42:37 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 16 Jan 2016 10:42:37 +0100
Subject: RFR(xs): 8147510: [windows] no text locations shown for register info
	in hs-err file
Message-ID: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>

Hi,

could I please have reviews and a sponsor for this small fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/

When we print register to memory info in hs-err file, text addresses are
not resolved on windows like on other platforms:

"RCX=0x000000005efa0000 is an unknown value"

This fix changes this (the same way it is implemented on other platforms):

"RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll + 0"

Please note that this printout and the code behind it could be improved and
cleaned up a lot. For instance, I know that using an on-stack buffer in
os::find() is not the best implementation here. But I wanted a minimal
change. For the follow-up work, I opened a new bug:
https://bugs.openjdk.java.net/browse/JDK-8147512.

Thanks & Regards, Thomas

From david.holmes at oracle.com  Mon Jan 18 03:54:39 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Jan 2016 13:54:39 +1000
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <5699726A.6000403@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <5699726A.6000403@oracle.com>
Message-ID: <569C61FF.6010600@oracle.com>

Hi Chris,

I'm also okay with the changes, but as Karen asked the other day (TOI), 
are there any asserts checking that everything is actually aligned as 
expected?

Thanks,
David

On 16/01/2016 8:27 AM, Chris Plummer wrote:
> Hi Coleen,
>
> On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>>
>> Hi,
>>
>> I've read this change and it looks correct to me.  The 32/64 bit
>> natural alignment should be used for the vtable and itable embedded
>> fields, and this change accomplishes this.
> Thanks for looking at this. It's much appreciated.
>>
>>
>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>> The only change is fixing SA to also no longer do the aligning:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/
>>>
>>> I've also filed the following CRs for pre-existing bugs instead of
>>> addressing them with these changes:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>> incorrect size and has no test
>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>> macros like align_object_size
>>
>> I am currently working on this bug because it is wrong to use
>> align_object_size() for metadata.  Metadata should be naturally
>> aligned and I'll verify it's the case in metaspace allocation code.
>>
>> Thanks to Mikael for the alert about SA code that copies this.  It
>> seems that the SA shouldn't report metadata sizes if that's also
>> reported with jcmd.  Maybe the jstat -classstats functionality that
>> uses SA (which is wrong now) can be removed?  And why would someone
>> use this on a core file?
> Well, that's a good question for the serviceability team.
>>
>>>
>>> And just restating here why I think the removal of these
>>> align_object_field references is safe:
>>>
>>> The argument to align_object_offset() is the offset in words, and it
>>> returns the offset in words after aligning to a HeapWordsPerLong
>>> boundary. Since the argument is in words, there is no concern with my
>>> changes removing word alignment of something that is not already word
>>> aligned. It must already be word aligned or the current
>>> implementation would be broken.
>>>
>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>> align_object_offset() is a no-op, so the removal is having no impact
>>> on 64-bit.
>>
>> It (align_object_offset) is actually wrong, but since the size of the
>> objects are naturally aligned, I think it's better to not have some
>> explicit alignment call.
>>>
>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is
>>> in fact the goal of this change, so what remains is to show that
>>> 64-bit alignment of the fields is not needed on 32-bit. Since all of
>>> the fields for which alignment has been removed are 32-bit types, it
>>> is safe to keep them 32-bit word aligned instead of making them
>>> 64-bit aligned.
>>>
>>
>> Agree.  This looks good.
> Great. Thanks again.
>
> Chris
>>
>> Thanks,
>> Coleen
>>
>>> thanks,
>>>
>>> Chris
>>>
>>>
>>>
>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>>>
>>>> A bit of background would help. The InstanceKlass object has a
>>>> number of variable length fields that are laid out after the
>>>> declared fields. When an InstanceKlass object is allocated, extra
>>>> memory is allocated for it to leave room for these fields. The first
>>>> three of these fields are vtable, itable, and nonstatic_oopmap. They
>>>> are all arrays of HeapWord sized values, which means void* size,
>>>> which means they only need 32-bit alignment on 32-bit systems.
>>>> However, they have always been 64-bit aligned. This webrev removes
>>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>>
>>>> This change affects all 32-bit platforms. It should have no net
>>>> impact on 64-bit platforms since the fields remain (naturally)
>>>> 64-bit aligned (unless of course I've introduced a bug). The intent
>>>> is to not change what is done for 64-bit platforms.
>>>>
>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>> just removes an "if" block where the condition should always have
>>>> evaluated to false, so it should have no net affect.
>>>>
>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>> there are any additional tests that should be run.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>
>>
>

From mikael.gerdin at oracle.com  Mon Jan 18 09:41:03 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Jan 2016 10:41:03 +0100
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <56996EC2.1020306@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com>
Message-ID: <569CB32F.7030504@oracle.com>

Hi,

On 2016-01-15 23:12, Coleen Phillimore wrote:
>
> Hi,
>
> I've read this change and it looks correct to me.  The 32/64 bit natural
> alignment should be used for the vtable and itable embedded fields, and
> this change accomplishes this.
>
>
> On 12/21/15 3:32 PM, Chris Plummer wrote:
>> Hello,
>>
>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>> The only change is fixing SA to also no longer do the aligning:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8143608
>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/

In sharkTopLevelBlock.cpp there is a bit of code to perform the 
alignment which you have removed from the other platforms, search for 
"needs_aligning". I'm not sure if shark even builds but it might be 
courteous to at least attempt to update the sources.

It's interesting that PPC64 does not appear to need any change, but I 
don't see any code to align up after loading the vtable length in the 
PPC sources.

Otherwise the change looks good as far as my limited knowledge of this 
can tell.

/Mikael


>>
>> I've also filed the following CRs for pre-existing bugs instead of
>> addressing them with these changes:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>> incorrect size and has no test
>> https://bugs.openjdk.java.net/browse/JDK-8145628
>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>> macros like align_object_size
>
> I am currently working on this bug because it is wrong to use
> align_object_size() for metadata.  Metadata should be naturally aligned
> and I'll verify it's the case in metaspace allocation code.
>
> Thanks to Mikael for the alert about SA code that copies this.  It seems
> that the SA shouldn't report metadata sizes if that's also reported with
> jcmd.  Maybe the jstat -classstats functionality that uses SA (which is
> wrong now) can be removed?  And why would someone use this on a core file?
>
>>
>> And just restating here why I think the removal of these
>> align_object_field references is safe:
>>
>> The argument to align_object_offset() is the offset in words, and it
>> returns the offset in words after aligning to a HeapWordsPerLong
>> boundary. Since the argument is in words, there is no concern with my
>> changes removing word alignment of something that is not already word
>> aligned. It must already be word aligned or the current implementation
>> would be broken.
>>
>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>> align_object_offset() is a no-op, so the removal is having no impact
>> on 64-bit.
>
> It (align_object_offset) is actually wrong, but since the size of the
> objects are naturally aligned, I think it's better to not have some
> explicit alignment call.
>>
>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>> will remain 32-bit word aligned, and not be 64-bit aligned. This is in
>> fact the goal of this change, so what remains is to show that 64-bit
>> alignment of the fields is not needed on 32-bit. Since all of the
>> fields for which alignment has been removed are 32-bit types, it is
>> safe to keep them 32-bit word aligned instead of making them 64-bit
>> aligned.
>>
>
> Agree.  This looks good.
>
> Thanks,
> Coleen
>
>> thanks,
>>
>> Chris
>>
>>
>>
>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>>
>>> A bit of background would help. The InstanceKlass object has a number
>>> of variable length fields that are laid out after the declared
>>> fields. When an InstanceKlass object is allocated, extra memory is
>>> allocated for it to leave room for these fields. The first three of
>>> these fields are vtable, itable, and nonstatic_oopmap. They are all
>>> arrays of HeapWord sized values, which means void* size, which means
>>> they only need 32-bit alignment on 32-bit systems. However, they have
>>> always been 64-bit aligned. This webrev removes the forced 64-bit
>>> alignment on 32-bit systems, saving footprint.
>>>
>>> This change affects all 32-bit platforms. It should have no net
>>> impact on 64-bit platforms since the fields remain (naturally) 64-bit
>>> aligned (unless of course I've introduced a bug). The intent is to
>>> not change what is done for 64-bit platforms.
>>>
>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>> just removes an "if" block where the condition should always have
>>> evaluated to false, so it should have no net affect.
>>>
>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>> there are any additional tests that should be run.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>
>


From mikael.gerdin at oracle.com  Mon Jan 18 13:21:37 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 18 Jan 2016 14:21:37 +0100
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569CB32F.7030504@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <569CB32F.7030504@oracle.com>
Message-ID: <569CE6E1.1010105@oracle.com>

On 2016-01-18 10:41, Mikael Gerdin wrote:
> Hi,
>
> On 2016-01-15 23:12, Coleen Phillimore wrote:
>>
>> Hi,
>>
>> I've read this change and it looks correct to me.  The 32/64 bit natural
>> alignment should be used for the vtable and itable embedded fields, and
>> this change accomplishes this.
>>
>>
>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>> The only change is fixing SA to also no longer do the aligning:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/
>
> In sharkTopLevelBlock.cpp there is a bit of code to perform the
> alignment which you have removed from the other platforms, search for
> "needs_aligning". I'm not sure if shark even builds but it might be
> courteous to at least attempt to update the sources.
>
> It's interesting that PPC64 does not appear to need any change, but I
> don't see any code to align up after loading the vtable length in the
> PPC sources.

I've just realized that this fix only changes the behavior on 32 bit 
platforms, so PPC64 never needed it.

/Mikael

>
> Otherwise the change looks good as far as my limited knowledge of this
> can tell.
>
> /Mikael
>
>
>>>
>>> I've also filed the following CRs for pre-existing bugs instead of
>>> addressing them with these changes:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>> incorrect size and has no test
>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>> macros like align_object_size
>>
>> I am currently working on this bug because it is wrong to use
>> align_object_size() for metadata.  Metadata should be naturally aligned
>> and I'll verify it's the case in metaspace allocation code.
>>
>> Thanks to Mikael for the alert about SA code that copies this.  It seems
>> that the SA shouldn't report metadata sizes if that's also reported with
>> jcmd.  Maybe the jstat -classstats functionality that uses SA (which is
>> wrong now) can be removed?  And why would someone use this on a core
>> file?
>>
>>>
>>> And just restating here why I think the removal of these
>>> align_object_field references is safe:
>>>
>>> The argument to align_object_offset() is the offset in words, and it
>>> returns the offset in words after aligning to a HeapWordsPerLong
>>> boundary. Since the argument is in words, there is no concern with my
>>> changes removing word alignment of something that is not already word
>>> aligned. It must already be word aligned or the current implementation
>>> would be broken.
>>>
>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>> align_object_offset() is a no-op, so the removal is having no impact
>>> on 64-bit.
>>
>> It (align_object_offset) is actually wrong, but since the size of the
>> objects are naturally aligned, I think it's better to not have some
>> explicit alignment call.
>>>
>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is in
>>> fact the goal of this change, so what remains is to show that 64-bit
>>> alignment of the fields is not needed on 32-bit. Since all of the
>>> fields for which alignment has been removed are 32-bit types, it is
>>> safe to keep them 32-bit word aligned instead of making them 64-bit
>>> aligned.
>>>
>>
>> Agree.  This looks good.
>>
>> Thanks,
>> Coleen
>>
>>> thanks,
>>>
>>> Chris
>>>
>>>
>>>
>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>>>
>>>> A bit of background would help. The InstanceKlass object has a number
>>>> of variable length fields that are laid out after the declared
>>>> fields. When an InstanceKlass object is allocated, extra memory is
>>>> allocated for it to leave room for these fields. The first three of
>>>> these fields are vtable, itable, and nonstatic_oopmap. They are all
>>>> arrays of HeapWord sized values, which means void* size, which means
>>>> they only need 32-bit alignment on 32-bit systems. However, they have
>>>> always been 64-bit aligned. This webrev removes the forced 64-bit
>>>> alignment on 32-bit systems, saving footprint.
>>>>
>>>> This change affects all 32-bit platforms. It should have no net
>>>> impact on 64-bit platforms since the fields remain (naturally) 64-bit
>>>> aligned (unless of course I've introduced a bug). The intent is to
>>>> not change what is done for 64-bit platforms.
>>>>
>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>> just removes an "if" block where the condition should always have
>>>> evaluated to false, so it should have no net affect.
>>>>
>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>> there are any additional tests that should be run.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>
>>
>


From martinrb at google.com  Mon Jan 18 16:52:15 2016
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Jan 2016 08:52:15 -0800
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <56962632.7080404@oracle.com>
References: <56962632.7080404@oracle.com>
Message-ID: <CA+kOe08PsiXek3TR7P1v1=Q5pquRJGuTZ-NGZ=yMKLpDco4q3Q@mail.gmail.com>

Historical note - I never liked having a reaper thread for each
subprocess, but no other reliable implementation is known.  Given the
potential for many reaper threads, I at least wanted to keep the
memory waste low.

On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu
<cheleswer.sahu at oracle.com> wrote:

> +                   Thread t = null;
> +                   if
> (Boolean.getBoolean("processReaperUseDefaultStackSize")) {
> +                       t = new Thread(systemThreadGroup, grimReaper,
> "process reaper");
> +                    } else {
> +                       // Our thread stack requirement is quite modest.
> +                       t = new Thread(systemThreadGroup, grimReaper,
> "process reaper", 32768);
> +                    }

If we do end up using this strategy, cleaner would be to use
https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-java.lang.String-long-
stackSize - the desired stack size for the new thread, or zero to
indicate that this parameter is to be ignored.

From chris.plummer at oracle.com  Mon Jan 18 20:38:02 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 18 Jan 2016 12:38:02 -0800
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569C61FF.6010600@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <5699726A.6000403@oracle.com>
	<569C61FF.6010600@oracle.com>
Message-ID: <569D4D2A.8040205@oracle.com>

Ok, I'll add some asserts.

Chris

On 1/17/16 7:54 PM, David Holmes wrote:
> Hi Chris,
>
> I'm also okay with the changes, but as Karen asked the other day 
> (TOI), are there any asserts checking that everything is actually 
> aligned as expected?
>
> Thanks,
> David
>
> On 16/01/2016 8:27 AM, Chris Plummer wrote:
>> Hi Coleen,
>>
>> On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>>>
>>> Hi,
>>>
>>> I've read this change and it looks correct to me.  The 32/64 bit
>>> natural alignment should be used for the vtable and itable embedded
>>> fields, and this change accomplishes this.
>> Thanks for looking at this. It's much appreciated.
>>>
>>>
>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>> The only change is fixing SA to also no longer do the aligning:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/ 
>>>>
>>>>
>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>> addressing them with these changes:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>> incorrect size and has no test
>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>> macros like align_object_size
>>>
>>> I am currently working on this bug because it is wrong to use
>>> align_object_size() for metadata.  Metadata should be naturally
>>> aligned and I'll verify it's the case in metaspace allocation code.
>>>
>>> Thanks to Mikael for the alert about SA code that copies this.  It
>>> seems that the SA shouldn't report metadata sizes if that's also
>>> reported with jcmd.  Maybe the jstat -classstats functionality that
>>> uses SA (which is wrong now) can be removed?  And why would someone
>>> use this on a core file?
>> Well, that's a good question for the serviceability team.
>>>
>>>>
>>>> And just restating here why I think the removal of these
>>>> align_object_field references is safe:
>>>>
>>>> The argument to align_object_offset() is the offset in words, and it
>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>> boundary. Since the argument is in words, there is no concern with my
>>>> changes removing word alignment of something that is not already word
>>>> aligned. It must already be word aligned or the current
>>>> implementation would be broken.
>>>>
>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>> on 64-bit.
>>>
>>> It (align_object_offset) is actually wrong, but since the size of the
>>> objects are naturally aligned, I think it's better to not have some
>>> explicit alignment call.
>>>>
>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is
>>>> in fact the goal of this change, so what remains is to show that
>>>> 64-bit alignment of the fields is not needed on 32-bit. Since all of
>>>> the fields for which alignment has been removed are 32-bit types, it
>>>> is safe to keep them 32-bit word aligned instead of making them
>>>> 64-bit aligned.
>>>>
>>>
>>> Agree.  This looks good.
>> Great. Thanks again.
>>
>> Chris
>>>
>>> Thanks,
>>> Coleen
>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ 
>>>>>
>>>>>
>>>>> A bit of background would help. The InstanceKlass object has a
>>>>> number of variable length fields that are laid out after the
>>>>> declared fields. When an InstanceKlass object is allocated, extra
>>>>> memory is allocated for it to leave room for these fields. The first
>>>>> three of these fields are vtable, itable, and nonstatic_oopmap. They
>>>>> are all arrays of HeapWord sized values, which means void* size,
>>>>> which means they only need 32-bit alignment on 32-bit systems.
>>>>> However, they have always been 64-bit aligned. This webrev removes
>>>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>>>
>>>>> This change affects all 32-bit platforms. It should have no net
>>>>> impact on 64-bit platforms since the fields remain (naturally)
>>>>> 64-bit aligned (unless of course I've introduced a bug). The intent
>>>>> is to not change what is done for 64-bit platforms.
>>>>>
>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>> just removes an "if" block where the condition should always have
>>>>> evaluated to false, so it should have no net affect.
>>>>>
>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>> there are any additional tests that should be run.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>
>>


From ioi.lam at oracle.com  Tue Jan 19 04:42:51 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 18 Jan 2016 20:42:51 -0800
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
In-Reply-To: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
References: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
Message-ID: <569DBECB.9030602@oracle.com>

Hi Jiangli,

The changes look good to me. Thanks for fixing this.

- Ioi

On 1/15/16 4:05 PM, Jiangli Zhou wrote:
> Please review the following improvements to HashtableTextDump::get_num() and HashtableTextDump::corrupted_if() described in JDK-8147500 <https://bugs.openjdk.java.net/browse/JDK-8147500>.
>
>   - The HashtableTextDump::get_num() is use to parse an integer value from the input file. It should check for integer overflow and report error without continuing.
>   - The HashtableTextDump::corrupted_if() should take an additional argument so caller can pass a meaningful error message.
>
> Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/
>
> Thanks,
> Jiangli
>
>
>
>


From david.holmes at oracle.com  Tue Jan 19 06:34:42 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jan 2016 16:34:42 +1000
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569C61FF.6010600@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <5699726A.6000403@oracle.com>
	<569C61FF.6010600@oracle.com>
Message-ID: <569DD902.2070703@oracle.com>

On 18/01/2016 1:54 PM, David Holmes wrote:
> Hi Chris,
>
> I'm also okay with the changes, but as Karen asked the other day (TOI),
> are there any asserts checking that everything is actually aligned as
> expected?

Okay after offline discussion I'm okay with things as-is. We would be 
checking that a N-word offset from a word-aligned address was word-aligned.

Thanks,
David

> Thanks,
> David
>
> On 16/01/2016 8:27 AM, Chris Plummer wrote:
>> Hi Coleen,
>>
>> On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>>>
>>> Hi,
>>>
>>> I've read this change and it looks correct to me.  The 32/64 bit
>>> natural alignment should be used for the vtable and itable embedded
>>> fields, and this change accomplishes this.
>> Thanks for looking at this. It's much appreciated.
>>>
>>>
>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>> The only change is fixing SA to also no longer do the aligning:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/
>>>>
>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>> addressing them with these changes:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>> incorrect size and has no test
>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>> macros like align_object_size
>>>
>>> I am currently working on this bug because it is wrong to use
>>> align_object_size() for metadata.  Metadata should be naturally
>>> aligned and I'll verify it's the case in metaspace allocation code.
>>>
>>> Thanks to Mikael for the alert about SA code that copies this.  It
>>> seems that the SA shouldn't report metadata sizes if that's also
>>> reported with jcmd.  Maybe the jstat -classstats functionality that
>>> uses SA (which is wrong now) can be removed?  And why would someone
>>> use this on a core file?
>> Well, that's a good question for the serviceability team.
>>>
>>>>
>>>> And just restating here why I think the removal of these
>>>> align_object_field references is safe:
>>>>
>>>> The argument to align_object_offset() is the offset in words, and it
>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>> boundary. Since the argument is in words, there is no concern with my
>>>> changes removing word alignment of something that is not already word
>>>> aligned. It must already be word aligned or the current
>>>> implementation would be broken.
>>>>
>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>> on 64-bit.
>>>
>>> It (align_object_offset) is actually wrong, but since the size of the
>>> objects are naturally aligned, I think it's better to not have some
>>> explicit alignment call.
>>>>
>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is
>>>> in fact the goal of this change, so what remains is to show that
>>>> 64-bit alignment of the fields is not needed on 32-bit. Since all of
>>>> the fields for which alignment has been removed are 32-bit types, it
>>>> is safe to keep them 32-bit word aligned instead of making them
>>>> 64-bit aligned.
>>>>
>>>
>>> Agree.  This looks good.
>> Great. Thanks again.
>>
>> Chris
>>>
>>> Thanks,
>>> Coleen
>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>>>>>
>>>>>
>>>>> A bit of background would help. The InstanceKlass object has a
>>>>> number of variable length fields that are laid out after the
>>>>> declared fields. When an InstanceKlass object is allocated, extra
>>>>> memory is allocated for it to leave room for these fields. The first
>>>>> three of these fields are vtable, itable, and nonstatic_oopmap. They
>>>>> are all arrays of HeapWord sized values, which means void* size,
>>>>> which means they only need 32-bit alignment on 32-bit systems.
>>>>> However, they have always been 64-bit aligned. This webrev removes
>>>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>>>
>>>>> This change affects all 32-bit platforms. It should have no net
>>>>> impact on 64-bit platforms since the fields remain (naturally)
>>>>> 64-bit aligned (unless of course I've introduced a bug). The intent
>>>>> is to not change what is done for 64-bit platforms.
>>>>>
>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>> just removes an "if" block where the condition should always have
>>>>> evaluated to false, so it should have no net affect.
>>>>>
>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>> there are any additional tests that should be run.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>
>>

From frederic.parain at oracle.com  Tue Jan 19 09:26:17 2016
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 19 Jan 2016 10:26:17 +0100
Subject: RFR(XS): JDK-8146751: jdk/test/tools/launcher/TooSmallStackSize.java
	failed on Mac OS
Message-ID: <569E0139.6010408@oracle.com>

Please review this small fix:

CR:
https://bugs.openjdk.java.net/browse/JDK-8146751

Webrev:
http://cr.openjdk.java.net/~fparain/8146751/webrev.00/

The changeset for JDK-8139864 introduced a bug for the
BSD and the Solaris platforms: missing parentheses cause
the VM to compute a wrong minimal value for stack size.

Fix has been tested manually (see CR).

Thanks,

Fred

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From david.holmes at oracle.com  Tue Jan 19 09:37:47 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jan 2016 19:37:47 +1000
Subject: RFR(XS): JDK-8146751:
	jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS
In-Reply-To: <569E0139.6010408@oracle.com>
References: <569E0139.6010408@oracle.com>
Message-ID: <569E03EB.40004@oracle.com>

Looks good to me Fred! Well spotted.

Thanks,
David

On 19/01/2016 7:26 PM, Frederic Parain wrote:
> Please review this small fix:
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8146751
>
> Webrev:
> http://cr.openjdk.java.net/~fparain/8146751/webrev.00/
>
> The changeset for JDK-8139864 introduced a bug for the
> BSD and the Solaris platforms: missing parentheses cause
> the VM to compute a wrong minimal value for stack size.
>
> Fix has been tested manually (see CR).
>
> Thanks,
>
> Fred
>

From dmitry.dmitriev at oracle.com  Tue Jan 19 11:32:30 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 19 Jan 2016 14:32:30 +0300
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
Message-ID: <569E1ECE.1070302@oracle.com>

Hello,

Please review small fix for printing flags functionality. This fix 
return ability to print develop and not product flags in debug VM by 
-XX:+PrintFlags* options.
Few comments:
1) "if (printRanges) {" on line 407 in globals.cpp was deleted, because 
it located in else branch of "if (!printRanges) {" and therefore always 
true.
2) TestOptionsWithRanges.java was corrected to not pick develop and not 
product flags.

JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
Testing: JPRT, hotspot_all, vm.quick

Thanks,
Dmitry

From kevin.walls at oracle.com  Tue Jan 19 11:53:01 2016
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 19 Jan 2016 11:53:01 +0000
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <CA+kOe08PsiXek3TR7P1v1=Q5pquRJGuTZ-NGZ=yMKLpDco4q3Q@mail.gmail.com>
References: <56962632.7080404@oracle.com>
	<CA+kOe08PsiXek3TR7P1v1=Q5pquRJGuTZ-NGZ=yMKLpDco4q3Q@mail.gmail.com>
Message-ID: <569E239D.1020701@oracle.com>

|
Hi Cheleswer, I think Martin is suggesting something like:
|

// Use a modest stack size, unless requested otherwise:
long stackSize = Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 : 32768;
Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper", stackSize);

|||
If that tests OK for you, it may be the way we can go ahead with the 
point fix for this.

Regards
Kevin
|
On 18/01/2016 16:52, Martin Buchholz wrote:
> Historical note - I never liked having a reaper thread for each
> subprocess, but no other reliable implementation is known.  Given the
> potential for many reaper threads, I at least wanted to keep the
> memory waste low.
>
> On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu
> <cheleswer.sahu at oracle.com> wrote:
>
>> +                   Thread t = null;
>> +                   if
>> (Boolean.getBoolean("processReaperUseDefaultStackSize")) {
>> +                       t = new Thread(systemThreadGroup, grimReaper,
>> "process reaper");
>> +                    } else {
>> +                       // Our thread stack requirement is quite modest.
>> +                       t = new Thread(systemThreadGroup, grimReaper,
>> "process reaper", 32768);
>> +                    }
> If we do end up using this strategy, cleaner would be to use
> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-java.lang.String-long-
> stackSize - the desired stack size for the new thread, or zero to
> indicate that this parameter is to be ignored.


From david.holmes at oracle.com  Tue Jan 19 12:10:10 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Jan 2016 22:10:10 +1000
Subject: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in
	executables with 32k tbss/tdata
In-Reply-To: <569E239D.1020701@oracle.com>
References: <56962632.7080404@oracle.com>
	<CA+kOe08PsiXek3TR7P1v1=Q5pquRJGuTZ-NGZ=yMKLpDco4q3Q@mail.gmail.com>
	<569E239D.1020701@oracle.com>
Message-ID: <569E27A2.4070207@oracle.com>

On 19/01/2016 9:53 PM, Kevin Walls wrote:
> |
> Hi Cheleswer, I think Martin is suggesting something like:
> |
>
> // Use a modest stack size, unless requested otherwise:
> long stackSize = Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 : 32768;

Someone from core-libs needs to chime on what the appropriate namespace 
for such a property would be.

David
-----

> Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper", stackSize);
>
> |||
> If that tests OK for you, it may be the way we can go ahead with the
> point fix for this.
>
> Regards
> Kevin
> |
> On 18/01/2016 16:52, Martin Buchholz wrote:
>> Historical note - I never liked having a reaper thread for each
>> subprocess, but no other reliable implementation is known.  Given the
>> potential for many reaper threads, I at least wanted to keep the
>> memory waste low.
>>
>> On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu
>> <cheleswer.sahu at oracle.com>  wrote:
>>
>>> +                   Thread t = null;
>>> +                   if
>>> (Boolean.getBoolean("processReaperUseDefaultStackSize")) {
>>> +                       t = new Thread(systemThreadGroup, grimReaper,
>>> "process reaper");
>>> +                    } else {
>>> +                       // Our thread stack requirement is quite modest.
>>> +                       t = new Thread(systemThreadGroup, grimReaper,
>>> "process reaper", 32768);
>>> +                    }
>> If we do end up using this strategy, cleaner would be to use
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-java.lang.String-long-
>> stackSize - the desired stack size for the new thread, or zero to
>> indicate that this parameter is to be ignored.
>

From george.triantafillou at oracle.com  Tue Jan 19 13:09:24 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 19 Jan 2016 08:09:24 -0500
Subject: RFR(XS): JDK-8146751:
	jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS
In-Reply-To: <569E0139.6010408@oracle.com>
References: <569E0139.6010408@oracle.com>
Message-ID: <569E3584.20408@oracle.com>

Hi Fred,

Your changes look good.

-George

On 1/19/2016 4:26 AM, Frederic Parain wrote:
> Please review this small fix:
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8146751
>
> Webrev:
> http://cr.openjdk.java.net/~fparain/8146751/webrev.00/
>
> The changeset for JDK-8139864 introduced a bug for the
> BSD and the Solaris platforms: missing parentheses cause
> the VM to compute a wrong minimal value for stack size.
>
> Fix has been tested manually (see CR).
>
> Thanks,
>
> Fred
>


From frederic.parain at oracle.com  Tue Jan 19 13:38:53 2016
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 19 Jan 2016 14:38:53 +0100
Subject: RFR(XS): JDK-8146751:
	jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS
In-Reply-To: <569E03EB.40004@oracle.com>
References: <569E0139.6010408@oracle.com> <569E03EB.40004@oracle.com>
Message-ID: <569E3C6D.6070004@oracle.com>

David,

Thanks for the review.

Fred

On 19/01/2016 10:37, David Holmes wrote:
> Looks good to me Fred! Well spotted.
>
> Thanks,
> David
>
> On 19/01/2016 7:26 PM, Frederic Parain wrote:
>> Please review this small fix:
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8146751
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fparain/8146751/webrev.00/
>>
>> The changeset for JDK-8139864 introduced a bug for the
>> BSD and the Solaris platforms: missing parentheses cause
>> the VM to compute a wrong minimal value for stack size.
>>
>> Fix has been tested manually (see CR).
>>
>> Thanks,
>>
>> Fred
>>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From frederic.parain at oracle.com  Tue Jan 19 13:39:20 2016
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 19 Jan 2016 14:39:20 +0100
Subject: RFR(XS): JDK-8146751:
	jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS
In-Reply-To: <569E3584.20408@oracle.com>
References: <569E0139.6010408@oracle.com> <569E3584.20408@oracle.com>
Message-ID: <569E3C88.3080205@oracle.com>

George,

Thank you for the review.

Fred

On 19/01/2016 14:09, George Triantafillou wrote:
> Hi Fred,
>
> Your changes look good.
>
> -George
>
> On 1/19/2016 4:26 AM, Frederic Parain wrote:
>> Please review this small fix:
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8146751
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fparain/8146751/webrev.00/
>>
>> The changeset for JDK-8139864 introduced a bug for the
>> BSD and the Solaris platforms: missing parentheses cause
>> the VM to compute a wrong minimal value for stack size.
>>
>> Fix has been tested manually (see CR).
>>
>> Thanks,
>>
>> Fred
>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From marcus.larsson at oracle.com  Tue Jan 19 13:58:23 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 19 Jan 2016 14:58:23 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC logging
	mechanism
Message-ID: <569E40FF.9070003@oracle.com>

Hi,

Please review the following patch to fix an issue in UL causing the VM 
to crash during shutdown.

The problem is that the static LogStdoutOutput is deinitialized before 
the last use of it (G1 concurrent thread tries to log very late during 
VM shutdown). The solution is to make sure neither LogStdoutOutput nor 
LogStderrOutput are deinitialized during the full lifetime of the VM. To 
accomplish this I've changed the storage from static objects to static 
pointers to heap instances that are allocated & initialized on first use 
[0]. These instances are never deleted and can always be used. Also 
updated LogConfiguration::finalize to disable all file outputs before 
deleting & freeing them.

Webrev:
http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8146009

Testing:
- local runs of the reproducer (500+ iterations without crashing)
- JPRT

Thanks,
Marcus

[0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use

From coleen.phillimore at oracle.com  Tue Jan 19 15:45:57 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 19 Jan 2016 10:45:57 -0500
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569D4D2A.8040205@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <5699726A.6000403@oracle.com>
	<569C61FF.6010600@oracle.com> <569D4D2A.8040205@oracle.com>
Message-ID: <569E5A35.2030805@oracle.com>


I was thinking about this and wondering if you could write a WhiteBox or 
ExecuteInternalVMTest for this, ie to verify that the vtable alignment 
is not 64 bits for 32 bits when the itable doesn't end on a 64 bit 
boundary (ie no alignment gap) but I don't think there is a good way to 
write a good test for this.  I think it's noreg-hard.

Coleen

On 1/18/16 3:38 PM, Chris Plummer wrote:
> Ok, I'll add some asserts.
>
> Chris
>
> On 1/17/16 7:54 PM, David Holmes wrote:
>> Hi Chris,
>>
>> I'm also okay with the changes, but as Karen asked the other day 
>> (TOI), are there any asserts checking that everything is actually 
>> aligned as expected?
>>
>> Thanks,
>> David
>>
>> On 16/01/2016 8:27 AM, Chris Plummer wrote:
>>> Hi Coleen,
>>>
>>> On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've read this change and it looks correct to me.  The 32/64 bit
>>>> natural alignment should be used for the vtable and itable embedded
>>>> fields, and this change accomplishes this.
>>> Thanks for looking at this. It's much appreciated.
>>>>
>>>>
>>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>>> The only change is fixing SA to also no longer do the aligning:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/ 
>>>>>
>>>>>
>>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>>> addressing them with these changes:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>>> incorrect size and has no test
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>>> macros like align_object_size
>>>>
>>>> I am currently working on this bug because it is wrong to use
>>>> align_object_size() for metadata.  Metadata should be naturally
>>>> aligned and I'll verify it's the case in metaspace allocation code.
>>>>
>>>> Thanks to Mikael for the alert about SA code that copies this.  It
>>>> seems that the SA shouldn't report metadata sizes if that's also
>>>> reported with jcmd.  Maybe the jstat -classstats functionality that
>>>> uses SA (which is wrong now) can be removed?  And why would someone
>>>> use this on a core file?
>>> Well, that's a good question for the serviceability team.
>>>>
>>>>>
>>>>> And just restating here why I think the removal of these
>>>>> align_object_field references is safe:
>>>>>
>>>>> The argument to align_object_offset() is the offset in words, and it
>>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>>> boundary. Since the argument is in words, there is no concern with my
>>>>> changes removing word alignment of something that is not already word
>>>>> aligned. It must already be word aligned or the current
>>>>> implementation would be broken.
>>>>>
>>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>>> on 64-bit.
>>>>
>>>> It (align_object_offset) is actually wrong, but since the size of the
>>>> objects are naturally aligned, I think it's better to not have some
>>>> explicit alignment call.
>>>>>
>>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is
>>>>> in fact the goal of this change, so what remains is to show that
>>>>> 64-bit alignment of the fields is not needed on 32-bit. Since all of
>>>>> the fields for which alignment has been removed are 32-bit types, it
>>>>> is safe to keep them 32-bit word aligned instead of making them
>>>>> 64-bit aligned.
>>>>>
>>>>
>>>> Agree.  This looks good.
>>> Great. Thanks again.
>>>
>>> Chris
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ 
>>>>>>
>>>>>>
>>>>>> A bit of background would help. The InstanceKlass object has a
>>>>>> number of variable length fields that are laid out after the
>>>>>> declared fields. When an InstanceKlass object is allocated, extra
>>>>>> memory is allocated for it to leave room for these fields. The first
>>>>>> three of these fields are vtable, itable, and nonstatic_oopmap. They
>>>>>> are all arrays of HeapWord sized values, which means void* size,
>>>>>> which means they only need 32-bit alignment on 32-bit systems.
>>>>>> However, they have always been 64-bit aligned. This webrev removes
>>>>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>>>>
>>>>>> This change affects all 32-bit platforms. It should have no net
>>>>>> impact on 64-bit platforms since the fields remain (naturally)
>>>>>> 64-bit aligned (unless of course I've introduced a bug). The intent
>>>>>> is to not change what is done for 64-bit platforms.
>>>>>>
>>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>>> just removes an "if" block where the condition should always have
>>>>>> evaluated to false, so it should have no net affect.
>>>>>>
>>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>>> there are any additional tests that should be run.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>
>>>>
>>>
>


From tom.benson at oracle.com  Tue Jan 19 15:54:01 2016
From: tom.benson at oracle.com (Tom Benson)
Date: Tue, 19 Jan 2016 10:54:01 -0500
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <569E40FF.9070003@oracle.com>
References: <569E40FF.9070003@oracle.com>
Message-ID: <569E5C19.3010709@oracle.com>

Hi Marcus,
I think all the copyrights need to be updated.

Since I had been able to reproduce the problem on nearly every run, I 
tried your fix and the crash no longer occurs.  However, I now see that 
in about 1 in 5 runs, the final message that used to trigger the crash 
now gets printed twice.  EG:

Exception: java.lang.OutOfMemoryError thrown from the 
UncaughtExceptionHandler in thread "main"
[3.624s][info   ][gc] GC(28) Pause Initial Mark (G1 Evacuation Pause) 
39M->39M(40M) (3.621s, 3.624s) 3.173ms
[3.624s][info   ][gc] GC(29) Concurrent Mark (3.624s)
[3.627s][info   ][gc] GC(30) Pause Young (G1 Evacuation Pause) 
39M->39M(40M) (3.624s, 3.627s) 2.299ms
[3.948s][info   ][gc] GC(31) Pause Full (Allocation Failure) 
39M->39M(40M) (3.627s, 3.948s) 321.141ms
[4.270s][info   ][gc] GC(32) Pause Full (Allocation Failure) 
39M->39M(40M) (3.948s, 4.270s) 321.400ms
[4.271s][info   ][gc] GC(29) Concurrent Mark abort
[4.271s][info   ][gc] GC(29) Concurrent Mark abort

The change looks OK to me, but I can't explain the above.
Tom

On 1/19/2016 8:58 AM, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to fix an issue in UL causing the VM 
> to crash during shutdown.
>
> The problem is that the static LogStdoutOutput is deinitialized before 
> the last use of it (G1 concurrent thread tries to log very late during 
> VM shutdown). The solution is to make sure neither LogStdoutOutput nor 
> LogStderrOutput are deinitialized during the full lifetime of the VM. 
> To accomplish this I've changed the storage from static objects to 
> static pointers to heap instances that are allocated & initialized on 
> first use [0]. These instances are never deleted and can always be 
> used. Also updated LogConfiguration::finalize to disable all file 
> outputs before deleting & freeing them.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146009
>
> Testing:
> - local runs of the reproducer (500+ iterations without crashing)
> - JPRT
>
> Thanks,
> Marcus
>
> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use


From jiangli.zhou at oracle.com  Tue Jan 19 17:02:48 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 19 Jan 2016 09:02:48 -0800
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
In-Reply-To: <569DBECB.9030602@oracle.com>
References: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
	<569DBECB.9030602@oracle.com>
Message-ID: <2717BDD4-B93F-49A9-A151-F02341553E52@oracle.com>

Thank you, Ioi.

Jiangli

> On Jan 18, 2016, at 8:42 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Hi Jiangli,
> 
> The changes look good to me. Thanks for fixing this.
> 
> - Ioi
> 
> On 1/15/16 4:05 PM, Jiangli Zhou wrote:
>> Please review the following improvements to HashtableTextDump::get_num() and HashtableTextDump::corrupted_if() described in JDK-8147500 <https://bugs.openjdk.java.net/browse/JDK-8147500>.
>> 
>>  - The HashtableTextDump::get_num() is use to parse an integer value from the input file. It should check for integer overflow and report error without continuing.
>>  - The HashtableTextDump::corrupted_if() should take an additional argument so caller can pass a meaningful error message.
>> 
>> Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/
>> 
>> Thanks,
>> Jiangli
>> 
>> 
>> 
>> 
> 


From rachel.protacio at oracle.com  Tue Jan 19 17:51:46 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Tue, 19 Jan 2016 12:51:46 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <5696A4ED.7010301@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com>
Message-ID: <569E77B2.1050503@oracle.com>

Hello, again!

A call for brand new reviews; I've corrected the code as requested by 
Ioi, i.e. none of the tests use "java -version" at all and the 
ItablesTest forces the use of vtables, even when class sharing is 
enabled (as on windows). Thanks to Coleen for guiding me through the latter.

The fixes pass JPRT once and for all! Webrev at 
http://cr.openjdk.java.net/~rprotacio/8146435.02/

I changed the copyrights in ClassB.java and VtablesTest.java because I 
had erroneously written them as 2015 when they weren't actually checked 
in until 2016.

Thank you,
Rachel


On 1/13/2016 2:26 PM, Ioi Lam wrote:
>
>
> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>> Hi,
>>
>> Yes, we have agreed not to use "-version" for triggering potentially 
>> changeable processes. Ioi, I think you may have misread my code as I 
>> did not use "java -version" for ItablesTest.java. 
> Hi Rachel,
>
> Thanks for the explanation. I looked at ItablesTest again. It uses 
> ClassB, which is pretty simple and by itself won't generate the 
> "vtable index" output. If it's not too much effort, instead of 
> removing the that output from the test, I would suggest changing 
> ClassB so that it would produce the desired output.
>
> Thanks
>
> - Ioi
>
>
>> I had left it in the DefaultMethodsTest.java and 
>> ClassInitializationTest.java tests because they are testing for 
>> output that seemed to be independent of -version implementation, in 
>> particular, java/lang/String default methods and any initialization 
>> that had no class initialization side effects (such as 
>> java.io.OutputStream), respectively. But I can make them more robust 
>> by running on a dummy class.
>>
>> As for the CDS, I realize I misinterpreted your conclusion. I can get 
>> rid of "-Xshare:off" and remove the parts of the tests looking for 
>> lines that disappear when CDS is enabled.
>>
>> Thanks,
>> Rachel
>>
>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>> I agree with Ioi. This is similar to the monitor inflation/deflation 
>>> logging test - we need to ensure we use something guaranteed to 
>>> always generate the expected log output.
>>>
>>> Thanks,
>>> David
>>>
>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>> Rachel,
>>>>
>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>> ItablesTest.java just runs "java -version", and depends on the fact 
>>>> that
>>>> at least one of the JDK classes that are implicitly loaded has an 
>>>> itable
>>>> (or whatever contents that produces the "vtable index " output).
>>>>
>>>> This behavior depends on internal JDK implementation and there's no
>>>> guarantee that it will always be true. There's also no guarantee that
>>>> the behavior will be the same across all the OS ports.
>>>>
>>>> In the future, some changes of "java -version" may cause this test to
>>>> fail only on a particular platform. I don't want someone to spend a 
>>>> day
>>>> to track down some imaginative windows issues again just to find out
>>>> that it's a test bug.
>>>>
>>>> So, as I mentioned in the bug report, the tests should be written to
>>>> load a class that *you have written* to ensure that the output will be
>>>> there regardless of JDK implementation.
>>>>
>>>> Here are other cases where the tests are dependent on unspecified
>>>> behaviors:
>>>>
>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>> effects]");
>>>>
>>>>       All of the output in DefaultMethodsTest.java
>>>>
>>>> In fact, I think you should remove "-Xshare:off" from the tests. 
>>>> Adding
>>>> -Xshare:off will also force the tests to be executed with CDS 
>>>> disabled,
>>>> and would cover up problems that only show up when CDS is enabled.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>> Hello!
>>>>>
>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi 
>>>>> for
>>>>> debugging and finding the source of the problem.
>>>>>
>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>
>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>
>>>>> Thank you!
>>>>> Rachel
>>>>
>>
>


From kim.barrett at oracle.com  Tue Jan 19 19:25:52 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 19 Jan 2016 14:25:52 -0500
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <569E40FF.9070003@oracle.com>
References: <569E40FF.9070003@oracle.com>
Message-ID: <0E436D95-725A-4E1E-83A9-B920E9D6E2D5@oracle.com>

On Jan 19, 2016, at 8:58 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch to fix an issue in UL causing the VM to crash during shutdown.
> 
> The problem is that the static LogStdoutOutput is deinitialized before the last use of it (G1 concurrent thread tries to log very late during VM shutdown). The solution is to make sure neither LogStdoutOutput nor LogStderrOutput are deinitialized during the full lifetime of the VM. To accomplish this I've changed the storage from static objects to static pointers to heap instances that are allocated & initialized on first use [0]. These instances are never deleted and can always be used. Also updated LogConfiguration::finalize to disable all file outputs before deleting & freeing them.
> 
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146009
> 
> Testing:
> - local runs of the reproducer (500+ iterations without crashing)
> - JPRT
> 
> Thanks,
> Marcus
> 
> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use

------------------------------------------------------------------------------ 
src/share/vm/logging/logOutput.cpp
  32 LogOutput* LogOutput::stdout_output() {
  33   static LogOutput* instance = new LogStdoutOutput();
  34   return instance;
  35 }
  36 
  37 LogOutput* LogOutput::stderr_output() {
  38   static LogOutput* instance = new LogStderrOutput();
  39   return instance;
  40 }

Function scoped statics may not be thread-safe.

They are thread-safe by default for gcc4.x (there's a compiler option
to disable that).  I'm pretty sure they are not for older versions of
Visual Studio, though C++11 requires thread-safe initialization so
some relatively recent version of VS probably makes them so.  I don't
know about Solaris or other platforms.

------------------------------------------------------------------------------

The failure situation this change is attempting to address may still
technically invoke undefined behavior with the change.  I think that
referencing the function scoped static during exit processing may be
theoretically problematic because the variable may have been
destroyed.  It likely works despite that, since the destructor for a
pointer-typed value probably trivially does nothing.

This suggests that even thread-safe statics may not make the
stdxxx_output functions strictly correct.

------------------------------------------------------------------------------

Why do we still have gc (or any other) threads running during a
shutdown that does exit processing[1]?  That seems like the real bug
here.  Shouldn't we either have stopped all threads before exit
processing, or not be doing exit processing at all and instead be
aborting? 

[1] By exit processing I mean the distinction between exit(3) et al
and abort(3).

------------------------------------------------------------------------------


From ioi.lam at oracle.com  Tue Jan 19 23:12:34 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 19 Jan 2016 15:12:34 -0800
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569E77B2.1050503@oracle.com>
References: <56954577.90306@oracle.com>
	<5695AD52.803@oracle.com>	<5695BA51.6080408@oracle.com>
	<56966E11.6030105@oracle.com>	<5696A4ED.7010301@oracle.com>
	<569E77B2.1050503@oracle.com>
Message-ID: <569EC2E2.3050301@oracle.com>

Hi Rachel,

The new code looks good. Thanks for being patient with my requests :-)

- Ioi

On 1/19/16 9:51 AM, Rachel Protacio wrote:
> Hello, again!
>
> A call for brand new reviews; I've corrected the code as requested by 
> Ioi, i.e. none of the tests use "java -version" at all and the 
> ItablesTest forces the use of vtables, even when class sharing is 
> enabled (as on windows). Thanks to Coleen for guiding me through the 
> latter.
>
> The fixes pass JPRT once and for all! Webrev at 
> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>
> I changed the copyrights in ClassB.java and VtablesTest.java because I 
> had erroneously written them as 2015 when they weren't actually 
> checked in until 2016.
>
> Thank you,
> Rachel
>
>
> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>
>>
>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>> Hi,
>>>
>>> Yes, we have agreed not to use "-version" for triggering potentially 
>>> changeable processes. Ioi, I think you may have misread my code as I 
>>> did not use "java -version" for ItablesTest.java. 
>> Hi Rachel,
>>
>> Thanks for the explanation. I looked at ItablesTest again. It uses 
>> ClassB, which is pretty simple and by itself won't generate the 
>> "vtable index" output. If it's not too much effort, instead of 
>> removing the that output from the test, I would suggest changing 
>> ClassB so that it would produce the desired output.
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>> I had left it in the DefaultMethodsTest.java and 
>>> ClassInitializationTest.java tests because they are testing for 
>>> output that seemed to be independent of -version implementation, in 
>>> particular, java/lang/String default methods and any initialization 
>>> that had no class initialization side effects (such as 
>>> java.io.OutputStream), respectively. But I can make them more robust 
>>> by running on a dummy class.
>>>
>>> As for the CDS, I realize I misinterpreted your conclusion. I can 
>>> get rid of "-Xshare:off" and remove the parts of the tests looking 
>>> for lines that disappear when CDS is enabled.
>>>
>>> Thanks,
>>> Rachel
>>>
>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>> I agree with Ioi. This is similar to the monitor 
>>>> inflation/deflation logging test - we need to ensure we use 
>>>> something guaranteed to always generate the expected log output.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>> Rachel,
>>>>>
>>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>>> ItablesTest.java just runs "java -version", and depends on the 
>>>>> fact that
>>>>> at least one of the JDK classes that are implicitly loaded has an 
>>>>> itable
>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>
>>>>> This behavior depends on internal JDK implementation and there's no
>>>>> guarantee that it will always be true. There's also no guarantee that
>>>>> the behavior will be the same across all the OS ports.
>>>>>
>>>>> In the future, some changes of "java -version" may cause this test to
>>>>> fail only on a particular platform. I don't want someone to spend 
>>>>> a day
>>>>> to track down some imaginative windows issues again just to find out
>>>>> that it's a test bug.
>>>>>
>>>>> So, as I mentioned in the bug report, the tests should be written to
>>>>> load a class that *you have written* to ensure that the output 
>>>>> will be
>>>>> there regardless of JDK implementation.
>>>>>
>>>>> Here are other cases where the tests are dependent on unspecified
>>>>> behaviors:
>>>>>
>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>> effects]");
>>>>>
>>>>>       All of the output in DefaultMethodsTest.java
>>>>>
>>>>> In fact, I think you should remove "-Xshare:off" from the tests. 
>>>>> Adding
>>>>> -Xshare:off will also force the tests to be executed with CDS 
>>>>> disabled,
>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to 
>>>>>> Ioi for
>>>>>> debugging and finding the source of the problem.
>>>>>>
>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>
>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>
>>>>>> Thank you!
>>>>>> Rachel
>>>>>
>>>
>>
>


From david.holmes at oracle.com  Wed Jan 20 04:45:58 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Jan 2016 14:45:58 +1000
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569E77B2.1050503@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
Message-ID: <569F1106.5040209@oracle.com>

Hi Rachel,

On 20/01/2016 3:51 AM, Rachel Protacio wrote:
> Hello, again!
>
> A call for brand new reviews; I've corrected the code as requested by
> Ioi, i.e. none of the tests use "java -version" at all and the
> ItablesTest forces the use of vtables, even when class sharing is
> enabled (as on windows). Thanks to Coleen for guiding me through the
> latter.
>
> The fixes pass JPRT once and for all! Webrev at
> http://cr.openjdk.java.net/~rprotacio/8146435.02/

Functionally this all looks fine.

test/runtime/logging/ClassInitializationTest.java (and elsewhere)

Style Nit: The breakups of long processBuilder lines don't follow the 
Java style guide [1] for doing such changes. My preferred approach 
(Variant 3 of 'continuation lines') is to always keep the first argument 
to a call on the same line, then indent subsequent arguments to it on 
separate lines eg (I hope this formats correctly in email):

ProcessBuilder pb = 
ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info", 
"-Xverify:all", "-Xmx64m", "BadMap50");

becomes:

ProcessBuilder pb = 
ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
                                                           "-Xverify:all",
                                                           "-Xmx64m",
                                                           "BadMap50");

If that is still too long you can also break after the = and only indent 
the initial call line by 8 (Variant 1) then use variant 3 eg:

ProcessBuilder pb =
         ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
                                               "-Xverify:all",
                                               "-Xmx64m",
                                               "BadMap50");

[1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get 
published yet?)

Thanks,
David

> I changed the copyrights in ClassB.java and VtablesTest.java because I
> had erroneously written them as 2015 when they weren't actually checked
> in until 2016.
>
> Thank you,
> Rachel
>
>
> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>
>>
>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>> Hi,
>>>
>>> Yes, we have agreed not to use "-version" for triggering potentially
>>> changeable processes. Ioi, I think you may have misread my code as I
>>> did not use "java -version" for ItablesTest.java.
>> Hi Rachel,
>>
>> Thanks for the explanation. I looked at ItablesTest again. It uses
>> ClassB, which is pretty simple and by itself won't generate the
>> "vtable index" output. If it's not too much effort, instead of
>> removing the that output from the test, I would suggest changing
>> ClassB so that it would produce the desired output.
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>> I had left it in the DefaultMethodsTest.java and
>>> ClassInitializationTest.java tests because they are testing for
>>> output that seemed to be independent of -version implementation, in
>>> particular, java/lang/String default methods and any initialization
>>> that had no class initialization side effects (such as
>>> java.io.OutputStream), respectively. But I can make them more robust
>>> by running on a dummy class.
>>>
>>> As for the CDS, I realize I misinterpreted your conclusion. I can get
>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>> lines that disappear when CDS is enabled.
>>>
>>> Thanks,
>>> Rachel
>>>
>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>> I agree with Ioi. This is similar to the monitor inflation/deflation
>>>> logging test - we need to ensure we use something guaranteed to
>>>> always generate the expected log output.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>> Rachel,
>>>>>
>>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>>> ItablesTest.java just runs "java -version", and depends on the fact
>>>>> that
>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>> itable
>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>
>>>>> This behavior depends on internal JDK implementation and there's no
>>>>> guarantee that it will always be true. There's also no guarantee that
>>>>> the behavior will be the same across all the OS ports.
>>>>>
>>>>> In the future, some changes of "java -version" may cause this test to
>>>>> fail only on a particular platform. I don't want someone to spend a
>>>>> day
>>>>> to track down some imaginative windows issues again just to find out
>>>>> that it's a test bug.
>>>>>
>>>>> So, as I mentioned in the bug report, the tests should be written to
>>>>> load a class that *you have written* to ensure that the output will be
>>>>> there regardless of JDK implementation.
>>>>>
>>>>> Here are other cases where the tests are dependent on unspecified
>>>>> behaviors:
>>>>>
>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>> effects]");
>>>>>
>>>>>       All of the output in DefaultMethodsTest.java
>>>>>
>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>> Adding
>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>> disabled,
>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi
>>>>>> for
>>>>>> debugging and finding the source of the problem.
>>>>>>
>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>
>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>
>>>>>> Thank you!
>>>>>> Rachel
>>>>>
>>>
>>
>

From david.holmes at oracle.com  Wed Jan 20 04:20:34 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Jan 2016 14:20:34 +1000
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <569E40FF.9070003@oracle.com>
References: <569E40FF.9070003@oracle.com>
Message-ID: <569F0B12.9060308@oracle.com>

On 19/01/2016 11:58 PM, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to fix an issue in UL causing the VM
> to crash during shutdown.
>
> The problem is that the static LogStdoutOutput is deinitialized before
> the last use of it (G1 concurrent thread tries to log very late during
> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
> LogStderrOutput are deinitialized during the full lifetime of the VM. To

I agree with Kim here - this seems like the "wrong" solution. If the G1 
thread can log very late during VM shutdown then we could
- move the logging "deinitialize" to later in the shutdown process 
(assuming the G1 threads won't continue to run right up to process 
termination); or
- ensure the G1 threads have to terminate, or block, before the 
deinitialization

Generally termination coordination involves the use of locks unfortunately.

That said, pre-UL, would the "logging" in the G1 thread have hit any 
termination issues or was the logging target valid through the lifetime 
of the VM?

> accomplish this I've changed the storage from static objects to static
> pointers to heap instances that are allocated & initialized on first use

I'm not familiar with the initialization of function-scoped statics but 
as Kim noted the thread-safety aspects of this seem dubious at best.

That aside, I have concerns about non-trivial static initialization in 
the existing code, as it is unclear to me exactly when during VM 
initialization such instances will be constructed.

Thanks,
David
-----


> [0]. These instances are never deleted and can always be used. Also
> updated LogConfiguration::finalize to disable all file outputs before
> deleting & freeing them.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146009
>
> Testing:
> - local runs of the reproducer (500+ iterations without crashing)
> - JPRT
>
> Thanks,
> Marcus
>
> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use

From thomas.stuefe at gmail.com  Wed Jan 20 07:53:30 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jan 2016 08:53:30 +0100
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
Message-ID: <CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>

May I please have a review and a sponsor?

Thank you!

On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi,
>
> could I please have reviews and a sponsor for this small fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>
> When we print register to memory info in hs-err file, text addresses are
> not resolved on windows like on other platforms:
>
> "RCX=0x000000005efa0000 is an unknown value"
>
> This fix changes this (the same way it is implemented on other platforms):
>
> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
> 0"
>
> Please note that this printout and the code behind it could be improved
> and cleaned up a lot. For instance, I know that using an on-stack buffer in
> os::find() is not the best implementation here. But I wanted a minimal
> change. For the follow-up work, I opened a new bug:
> https://bugs.openjdk.java.net/browse/JDK-8147512.
>
> Thanks & Regards, Thomas
>
>
>
>

From thomas.stuefe at gmail.com  Wed Jan 20 07:54:16 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jan 2016 08:54:16 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
Message-ID: <CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>

May I please have a review for this? Thanks!

On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Dear all,
>
> please take a look at this small cleanup of ostream.
>
> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>
> Basically, it gets rid of the staticBufferStream class by moving its one
> feature up to the parent outputStream class:
>
> When printing the error log in vmError.cpp, we want to use as little stack
> space as possible. outputStream class uses on-stack buffers to assemble
> snprintf functions. So, staticBufferStream was introduced as a child of
> outputStream which overwrites the print functions and makes them use a
> caller provided buffer. It then delegates the real writing to a connected
> stream object.
>
> The problem with that approach is that this is not a good fit for a child
> class.Not all operations possible with outputStream are cleanly delegated
> to the connected stream class, so a staticBufferStream behaves sometimes
> differently from all other streams (see e.g. JDK-8145410, which will be
> automatically fixed with this change too).
>
> Another problem is that this delegation model leads to some code
> duplication, because all print() methods of outputStream are practically
> duplicated in staticBufferStream.
>
> Another cosmetic note is that all other child classes of outputStream
> (bufferedStream, stringStream, fileStream...) are specializations in term
> of log destination, not internal behaviour.
>
> Note that I implemented this in a very simple way without using templates,
> because I wanted to keep the changes as small as possible.
>
> Kind Regards, Thomas
>

From thomas.stuefe at gmail.com  Wed Jan 20 08:31:15 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jan 2016 09:31:15 +0100
Subject: Unused code in prims/methodComparator
Message-ID: <CAA-vtUxJoJy-L8ohR-xi=7wUiZtt1R59p0bG56VEM51B5yONjg@mail.gmail.com>

Hi all,

when investigating a warning about unchecked realloc() usage in
methodComparator.hpp, I found that the offending function
(BciMap::store_fragment_location) is not callable anymore.

BciMap::store_fragment_location is called
by MethodComparator::methods_switchable, which is not called anywhere.

Is there any reason we should keep this?

Regards, Thomas

From volker.simonis at gmail.com  Wed Jan 20 08:32:53 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 Jan 2016 09:32:53 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
Message-ID: <CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>

Hi Thomas,

thanks for doing this nice cleanup.

The change looks good. Can you please just adapt the comment at line
987 and remove the reference to staticBufferStream from there as well.

Regards,
Volker


On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> May I please have a review for this? Thanks!
>
> On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Dear all,
>>
>> please take a look at this small cleanup of ostream.
>>
>> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
>> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>>
>> Basically, it gets rid of the staticBufferStream class by moving its one
>> feature up to the parent outputStream class:
>>
>> When printing the error log in vmError.cpp, we want to use as little stack
>> space as possible. outputStream class uses on-stack buffers to assemble
>> snprintf functions. So, staticBufferStream was introduced as a child of
>> outputStream which overwrites the print functions and makes them use a
>> caller provided buffer. It then delegates the real writing to a connected
>> stream object.
>>
>> The problem with that approach is that this is not a good fit for a child
>> class.Not all operations possible with outputStream are cleanly delegated
>> to the connected stream class, so a staticBufferStream behaves sometimes
>> differently from all other streams (see e.g. JDK-8145410, which will be
>> automatically fixed with this change too).
>>
>> Another problem is that this delegation model leads to some code
>> duplication, because all print() methods of outputStream are practically
>> duplicated in staticBufferStream.
>>
>> Another cosmetic note is that all other child classes of outputStream
>> (bufferedStream, stringStream, fileStream...) are specializations in term
>> of log destination, not internal behaviour.
>>
>> Note that I implemented this in a very simple way without using templates,
>> because I wanted to keep the changes as small as possible.
>>
>> Kind Regards, Thomas
>>

From thomas.stuefe at gmail.com  Wed Jan 20 09:29:21 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 20 Jan 2016 10:29:21 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
	<CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
Message-ID: <CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>

Thank you Volker!

Still need a second reviewer, and once hs-rt is open again I'll need a
sponsor too.

Kind Regards, Thomas

On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> thanks for doing this nice cleanup.
>
> The change looks good. Can you please just adapt the comment at line
> 987 and remove the reference to staticBufferStream from there as well.
>
> Regards,
> Volker
>
>
> On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > May I please have a review for this? Thanks!
> >
> > On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> > wrote:
> >
> >> Dear all,
> >>
> >> please take a look at this small cleanup of ostream.
> >>
> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
> >> webrev:
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
> >>
> >> Basically, it gets rid of the staticBufferStream class by moving its one
> >> feature up to the parent outputStream class:
> >>
> >> When printing the error log in vmError.cpp, we want to use as little
> stack
> >> space as possible. outputStream class uses on-stack buffers to assemble
> >> snprintf functions. So, staticBufferStream was introduced as a child of
> >> outputStream which overwrites the print functions and makes them use a
> >> caller provided buffer. It then delegates the real writing to a
> connected
> >> stream object.
> >>
> >> The problem with that approach is that this is not a good fit for a
> child
> >> class.Not all operations possible with outputStream are cleanly
> delegated
> >> to the connected stream class, so a staticBufferStream behaves sometimes
> >> differently from all other streams (see e.g. JDK-8145410, which will be
> >> automatically fixed with this change too).
> >>
> >> Another problem is that this delegation model leads to some code
> >> duplication, because all print() methods of outputStream are practically
> >> duplicated in staticBufferStream.
> >>
> >> Another cosmetic note is that all other child classes of outputStream
> >> (bufferedStream, stringStream, fileStream...) are specializations in
> term
> >> of log destination, not internal behaviour.
> >>
> >> Note that I implemented this in a very simple way without using
> templates,
> >> because I wanted to keep the changes as small as possible.
> >>
> >> Kind Regards, Thomas
> >>
>

From chenyt at cs.sjtu.edu.cn  Wed Jan 20 10:13:16 2016
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Wed, 20 Jan 2016 18:13:16 +0800
Subject: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for Java7?
In-Reply-To: <62105939.473338.1451817192470.JavaMail.zimbra@u-pem.fr>
References: <3CE79DB984BF4183BF8A42CB9EA3628C@sjtu.edu.cn>
	<5688DC2C.8040104@oracle.com>
	<EAF99C6363A04209AA19CE1AEF050804@sjtu.edu.cn>
	<62105939.473338.1451817192470.JavaMail.zimbra@u-pem.fr>
Message-ID: <F83C33857B9B4C688AC2E54C92F34C00@sjtu.edu.cn>

Hello, I rechecked the JVM releases by creating some classes.

Today I created one class and ran it on Oracle's
VM (HotSpot for Java8/Java9) and IBM's VM (J9 for Java8). J9
complains that there is an Exception in thread "main"
java.lang.IllegalAccessError: sun.nio.cs.ext.DoubleByteDecoder.
HotSpot releases do not report any errors.
(It seems that the class starts with sun.* can still be accessible
in JDK9.)

I can understand that J9 is more lazy in format-checking
and verifying a class (I have many cases about this) than HotSpot.
However, this example is a little different. Why is
J9 not compatible to HotSpot in processing this case? Why is
sun.nio.cs.ext.DoubleByteDecoder accessed and checked by
J9 even if the method newDecoder() is not invoked?

Next show the Jimple's code and the decompiled code. The
statement causing the JVM difference is in
public java.nio.charset.CharsetDecoder newDecoder():
...
specialinvoke $r2.<sun.nio.cs.ext.JIS_X_0208$Decoder: void
<init>(java.nio.charset.Charset)>(r0);
...

Yuting

******************************************************
public class M1450718140 extends java.nio.charset.Charset
{

     public void <init>()
     {
         M1450718140 r0;
         java.lang.String[] $r1;

         r0 := @this: M1450718140;
         $r1 = staticinvoke <sun.nio.cs.ext.ExtendedCharsets:
java.lang.String[] aliasesFor(java.lang.String)>("x-JIS0208");
         specialinvoke r0.<java.nio.charset.Charset: void
<init>(java.lang.String,java.lang.String[])>("x-JIS0208", $r1);
         return;
     }

     public java.nio.charset.CharsetDecoder newDecoder()
     {
         M1450718140 r0;
         sun.nio.cs.ext.JIS_X_0208$Decoder $r2;

         r0 := @this: M1450718140;
         $r2 = new sun.nio.cs.ext.JIS_X_0208$Decoder;
         specialinvoke $r2.<sun.nio.cs.ext.JIS_X_0208$Decoder: void
<init>(java.nio.charset.Charset)>(r0);
         return $r2;
     }

     public static void main(java.lang.String[])
     {
         return;
     }
}

public class M1450718140 extends java.nio.charset.Charset
   minor version: 0
   major version: 51
   flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
    #1 = Class              #11            //
sun/nio/cs/ext/ExtendedCharsets
    #2 = Utf8               ([Ljava/lang/String;)V
    #3 = Utf8               <init>
    #4 = Methodref          #19.#26        //
java/nio/charset/Charset."<init>":(Ljava/lang/String;[Ljava/lang/String;)V
    #5 = Utf8               ()V
    #6 = Utf8               Code
    #7 = NameAndType        #24:#25        //
aliasesFor:(Ljava/lang/String;)[Ljava/lang/String;
    #8 = Utf8               main
    #9 = Utf8               newDecoder
   #10 = Utf8               SourceFile
   #11 = Utf8               sun/nio/cs/ext/ExtendedCharsets
   #12 = Utf8               ()Ljava/nio/charset/CharsetDecoder;
   #13 = Utf8               (Ljava/lang/String;[Ljava/lang/String;)V
   #14 = Utf8               Jasmin
   #15 = Utf8               sun/nio/cs/ext/JIS_X_0208$Decoder
   #16 = Class              #15            //
sun/nio/cs/ext/JIS_X_0208$Decoder
   #17 = NameAndType        #3:#20         //
"<init>":(Ljava/nio/charset/Charset;)V
   #18 = String             #21            // x-JIS0208
   #19 = Class              #29            // java/nio/charset/Charset
   #20 = Utf8               (Ljava/nio/charset/Charset;)V
   #21 = Utf8               x-JIS0208
   #22 = Methodref          #16.#17        //
sun/nio/cs/ext/JIS_X_0208$Decoder."<init>":(Ljava/nio/charset/Charset;)V
   #23 = Utf8               M1450718140
   #24 = Utf8               aliasesFor
   #25 = Utf8               (Ljava/lang/String;)[Ljava/lang/String;
   #26 = NameAndType        #3:#13         //
"<init>":(Ljava/lang/String;[Ljava/lang/String;)V
   #27 = Class              #23            // M1450718140
   #28 = Methodref          #1.#7          //
sun/nio/cs/ext/ExtendedCharsets.aliasesFor:(Ljava/lang/String;)[Ljava/lang/String;
   #29 = Utf8               java/nio/charset/Charset
{
   public M1450718140();
     descriptor: ()V
     flags: ACC_PUBLIC
     Code:
       stack=3, locals=1, args_size=1
          0: aload_0
          1: ldc           #18                 // String x-JIS0208
          3: ldc           #18                 // String x-JIS0208
          5: invokestatic  #28                 // Method
sun/nio/cs/ext/ExtendedCharsets.aliasesFor:(Ljava/lang/String;)[Ljava/lang/String;
          8: invokespecial #4                  // Method
java/nio/charset/Charset."<init>":(Ljava/lang/String;[Ljava/lang/String;)V
         11: return

   public java.nio.charset.CharsetDecoder newDecoder();
     descriptor: ()Ljava/nio/charset/CharsetDecoder;
     flags: ACC_PUBLIC
     Code:
       stack=3, locals=1, args_size=1
          0: new           #16                 // class
sun/nio/cs/ext/JIS_X_0208$Decoder
          3: dup
          4: aload_0
          5: invokespecial #22                 // Method
sun/nio/cs/ext/JIS_X_0208$Decoder."<init>":(Ljava/nio/charset/Charset;)V
          8: areturn

   public static void main(java.lang.String[]);
     descriptor: ([Ljava/lang/String;)V
     flags: ACC_PUBLIC, ACC_STATIC
     Code:
       stack=0, locals=1, args_size=1
          0: return
}

-----Original Message----- 
From: Remi Forax
Sent: Sunday, January 03, 2016 6:33 PM
To: ???
Cc: hotspot-runtime-dev at openjdk.java.net ; Alan Bateman
Subject: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for 
Java7?

And obviously because the class starts with sun.*,
this class is not accessible anymore in JDK 9 (with modules).

R?mi

----- Mail original -----
> De: "???" <chenyt at cs.sjtu.edu.cn>
> ?: hotspot-runtime-dev at openjdk.java.net, "Alan Bateman" 
> <Alan.Bateman at oracle.com>
> Envoy?: Dimanche 3 Janvier 2016 09:43:31
> Objet: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for 
> Java7?
>
> Thank you, Alan. I went through the source and got it.
>
> Yuting
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Sunday, January 03, 2016 4:30 PM
> To: ??? ; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: Why sun.nio.ch.SelChImpl is not accessable at HotSpot for
> Java7?
>
> On 03/01/2016 08:20, ??? wrote:
> > Dear all,
> >
> > I used soot to create the class M1450550406 (see next).
> > HotSpot for Java7 says that M1450550406 cannot access
> > the superinterface sun.nio.ch.SelChImpl, while HotSpot
> > for Java8/9 and J9 for Java8 can access. Could anyone tell
> > me the reason? I checked the package and believed
> > that  the interface is in the JRE libraries.
> >
> sun.nio.ch.SelChImpl is a JDK-internal class, it was package-private in
> JDK 7 but was changed to public in JDK 8.
>
> -Alan
>
> 


From kirk at kodewerk.com  Wed Jan 20 13:01:02 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Wed, 20 Jan 2016 14:01:02 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <569F0B12.9060308@oracle.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
Message-ID: <7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>


> On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 19/01/2016 11:58 PM, Marcus Larsson wrote:
>> Hi,
>> 
>> Please review the following patch to fix an issue in UL causing the VM
>> to crash during shutdown.
>> 
>> The problem is that the static LogStdoutOutput is deinitialized before
>> the last use of it (G1 concurrent thread tries to log very late during
>> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
>> LogStderrOutput are deinitialized during the full lifetime of the VM. To
> 
> I agree with Kim here - this seems like the "wrong" solution. If the G1 thread can log very late during VM shutdown then we could
> - move the logging "deinitialize" to later in the shutdown process (assuming the G1 threads won't continue to run right up to process termination); or
> - ensure the G1 threads have to terminate, or block, before the deinitialization

Can I ask a silly question? If the JVM is shutting down is there a need to de-initialize logging?

IME iit is highly unlikely that the loss of one or two GC log records would make a difference in my use cases.

Kind regards,
Kirk


From marcus.larsson at oracle.com  Wed Jan 20 13:07:56 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 20 Jan 2016 14:07:56 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <0E436D95-725A-4E1E-83A9-B920E9D6E2D5@oracle.com>
References: <569E40FF.9070003@oracle.com>
	<0E436D95-725A-4E1E-83A9-B920E9D6E2D5@oracle.com>
Message-ID: <569F86AC.4030008@oracle.com>

Hi Kim,

On 01/19/2016 08:25 PM, Kim Barrett wrote:
> On Jan 19, 2016, at 8:58 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>> Hi,
>>
>> Please review the following patch to fix an issue in UL causing the VM to crash during shutdown.
>>
>> The problem is that the static LogStdoutOutput is deinitialized before the last use of it (G1 concurrent thread tries to log very late during VM shutdown). The solution is to make sure neither LogStdoutOutput nor LogStderrOutput are deinitialized during the full lifetime of the VM. To accomplish this I've changed the storage from static objects to static pointers to heap instances that are allocated & initialized on first use [0]. These instances are never deleted and can always be used. Also updated LogConfiguration::finalize to disable all file outputs before deleting & freeing them.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146009
>>
>> Testing:
>> - local runs of the reproducer (500+ iterations without crashing)
>> - JPRT
>>
>> Thanks,
>> Marcus
>>
>> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
> ------------------------------------------------------------------------------
> src/share/vm/logging/logOutput.cpp
>    32 LogOutput* LogOutput::stdout_output() {
>    33   static LogOutput* instance = new LogStdoutOutput();
>    34   return instance;
>    35 }
>    36
>    37 LogOutput* LogOutput::stderr_output() {
>    38   static LogOutput* instance = new LogStderrOutput();
>    39   return instance;
>    40 }
>
> Function scoped statics may not be thread-safe.
>
> They are thread-safe by default for gcc4.x (there's a compiler option
> to disable that).  I'm pretty sure they are not for older versions of
> Visual Studio, though C++11 requires thread-safe initialization so
> some relatively recent version of VS probably makes them so.  I don't
> know about Solaris or other platforms.

I don't think this will be a problem in this specific case. Both 
functions will always be called during early init when there's only a 
single thread around (LogConfiguration::initialize and LogTagSet 
constructor). I was actually able to limit the usage of these functions 
to only these two cases. I'll post a new webrev soon.

>
> ------------------------------------------------------------------------------
>
> The failure situation this change is attempting to address may still
> technically invoke undefined behavior with the change.  I think that
> referencing the function scoped static during exit processing may be
> theoretically problematic because the variable may have been
> destroyed.  It likely works despite that, since the destructor for a
> pointer-typed value probably trivially does nothing.
>
> This suggests that even thread-safe statics may not make the
> stdxxx_output functions strictly correct.

The functions return copies of the pointers, so no one will really have 
a reference to those specific pointers. The memory the pointers point to 
is also never freed. With the changes I mentioned above, no one will 
call these functions or look at that static data once initialization is 
complete. The functions will just be a mean to get predictable static 
initialization for stdout and stderr outputs.

>
> ------------------------------------------------------------------------------
>
> Why do we still have gc (or any other) threads running during a
> shutdown that does exit processing[1]?  That seems like the real bug
> here.  Shouldn't we either have stopped all threads before exit
> processing, or not be doing exit processing at all and instead be
> aborting?
>
> [1] By exit processing I mean the distinction between exit(3) et al
> and abort(3).

That's a fair point, and it could indeed be a bug itself. The reason I 
chose to fix the logging side of this is that I think it would be good 
if the log framework is available at all times, even right before the VM 
dies.

Thanks,
Marcus

> ------------------------------------------------------------------------------
>


From rachel.protacio at oracle.com  Wed Jan 20 16:27:46 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 20 Jan 2016 11:27:46 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569F1106.5040209@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com>
Message-ID: <569FB582.3050100@oracle.com>

Thanks for the reviews, Ioi and David! I'll fix those style issues.
Rachel

On 1/19/2016 11:45 PM, David Holmes wrote:
> Hi Rachel,
>
> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>> Hello, again!
>>
>> A call for brand new reviews; I've corrected the code as requested by
>> Ioi, i.e. none of the tests use "java -version" at all and the
>> ItablesTest forces the use of vtables, even when class sharing is
>> enabled (as on windows). Thanks to Coleen for guiding me through the
>> latter.
>>
>> The fixes pass JPRT once and for all! Webrev at
>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>
> Functionally this all looks fine.
>
> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>
> Style Nit: The breakups of long processBuilder lines don't follow the 
> Java style guide [1] for doing such changes. My preferred approach 
> (Variant 3 of 'continuation lines') is to always keep the first 
> argument to a call on the same line, then indent subsequent arguments 
> to it on separate lines eg (I hope this formats correctly in email):
>
> ProcessBuilder pb = 
> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info", 
> "-Xverify:all", "-Xmx64m", "BadMap50");
>
> becomes:
>
> ProcessBuilder pb = 
> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
> "-Xverify:all",
> "-Xmx64m",
> "BadMap50");
>
> If that is still too long you can also break after the = and only 
> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>
> ProcessBuilder pb =
> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>                                               "-Xverify:all",
>                                               "-Xmx64m",
>                                               "BadMap50");
>
> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get 
> published yet?)
>
> Thanks,
> David
>
>> I changed the copyrights in ClassB.java and VtablesTest.java because I
>> had erroneously written them as 2015 when they weren't actually checked
>> in until 2016.
>>
>> Thank you,
>> Rachel
>>
>>
>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>
>>>
>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>> Hi,
>>>>
>>>> Yes, we have agreed not to use "-version" for triggering potentially
>>>> changeable processes. Ioi, I think you may have misread my code as I
>>>> did not use "java -version" for ItablesTest.java.
>>> Hi Rachel,
>>>
>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>> ClassB, which is pretty simple and by itself won't generate the
>>> "vtable index" output. If it's not too much effort, instead of
>>> removing the that output from the test, I would suggest changing
>>> ClassB so that it would produce the desired output.
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>>
>>>> I had left it in the DefaultMethodsTest.java and
>>>> ClassInitializationTest.java tests because they are testing for
>>>> output that seemed to be independent of -version implementation, in
>>>> particular, java/lang/String default methods and any initialization
>>>> that had no class initialization side effects (such as
>>>> java.io.OutputStream), respectively. But I can make them more robust
>>>> by running on a dummy class.
>>>>
>>>> As for the CDS, I realize I misinterpreted your conclusion. I can get
>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>> lines that disappear when CDS is enabled.
>>>>
>>>> Thanks,
>>>> Rachel
>>>>
>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>> I agree with Ioi. This is similar to the monitor inflation/deflation
>>>>> logging test - we need to ensure we use something guaranteed to
>>>>> always generate the expected log output.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>> Rachel,
>>>>>>
>>>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>>>> ItablesTest.java just runs "java -version", and depends on the fact
>>>>>> that
>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>> itable
>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>
>>>>>> This behavior depends on internal JDK implementation and there's no
>>>>>> guarantee that it will always be true. There's also no guarantee 
>>>>>> that
>>>>>> the behavior will be the same across all the OS ports.
>>>>>>
>>>>>> In the future, some changes of "java -version" may cause this 
>>>>>> test to
>>>>>> fail only on a particular platform. I don't want someone to spend a
>>>>>> day
>>>>>> to track down some imaginative windows issues again just to find out
>>>>>> that it's a test bug.
>>>>>>
>>>>>> So, as I mentioned in the bug report, the tests should be written to
>>>>>> load a class that *you have written* to ensure that the output 
>>>>>> will be
>>>>>> there regardless of JDK implementation.
>>>>>>
>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>> behaviors:
>>>>>>
>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>> effects]");
>>>>>>
>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>
>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>> Adding
>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>> disabled,
>>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>>
>>>>>> Thanks
>>>>>> - Ioi
>>>>>>
>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi
>>>>>>> for
>>>>>>> debugging and finding the source of the problem.
>>>>>>>
>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>
>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>
>>>>>>> Thank you!
>>>>>>> Rachel
>>>>>>
>>>>
>>>
>>


From rachel.protacio at oracle.com  Wed Jan 20 16:53:32 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 20 Jan 2016 11:53:32 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569FB582.3050100@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com> <569FB582.3050100@oracle.com>
Message-ID: <569FBB8C.3080103@oracle.com>

http://cr.openjdk.java.net/~rprotacio/8146435.03/

I went ahead and corrected the style in all the UL test files. If 
someone can review them to make sure I understood correctly, I'll go 
ahead and commit!

Thanks,
Rachel

On 1/20/2016 11:27 AM, Rachel Protacio wrote:
> Thanks for the reviews, Ioi and David! I'll fix those style issues.
> Rachel
>
> On 1/19/2016 11:45 PM, David Holmes wrote:
>> Hi Rachel,
>>
>> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>>> Hello, again!
>>>
>>> A call for brand new reviews; I've corrected the code as requested by
>>> Ioi, i.e. none of the tests use "java -version" at all and the
>>> ItablesTest forces the use of vtables, even when class sharing is
>>> enabled (as on windows). Thanks to Coleen for guiding me through the
>>> latter.
>>>
>>> The fixes pass JPRT once and for all! Webrev at
>>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>>
>> Functionally this all looks fine.
>>
>> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>>
>> Style Nit: The breakups of long processBuilder lines don't follow the 
>> Java style guide [1] for doing such changes. My preferred approach 
>> (Variant 3 of 'continuation lines') is to always keep the first 
>> argument to a call on the same line, then indent subsequent arguments 
>> to it on separate lines eg (I hope this formats correctly in email):
>>
>> ProcessBuilder pb = 
>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info", 
>> "-Xverify:all", "-Xmx64m", "BadMap50");
>>
>> becomes:
>>
>> ProcessBuilder pb = 
>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>> "-Xverify:all",
>> "-Xmx64m",
>> "BadMap50");
>>
>> If that is still too long you can also break after the = and only 
>> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>>
>> ProcessBuilder pb =
>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>                                               "-Xverify:all",
>>                                               "-Xmx64m",
>>                                               "BadMap50");
>>
>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get 
>> published yet?)
>>
>> Thanks,
>> David
>>
>>> I changed the copyrights in ClassB.java and VtablesTest.java because I
>>> had erroneously written them as 2015 when they weren't actually checked
>>> in until 2016.
>>>
>>> Thank you,
>>> Rachel
>>>
>>>
>>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>>
>>>>
>>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>>> Hi,
>>>>>
>>>>> Yes, we have agreed not to use "-version" for triggering potentially
>>>>> changeable processes. Ioi, I think you may have misread my code as I
>>>>> did not use "java -version" for ItablesTest.java.
>>>> Hi Rachel,
>>>>
>>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>>> ClassB, which is pretty simple and by itself won't generate the
>>>> "vtable index" output. If it's not too much effort, instead of
>>>> removing the that output from the test, I would suggest changing
>>>> ClassB so that it would produce the desired output.
>>>>
>>>> Thanks
>>>>
>>>> - Ioi
>>>>
>>>>
>>>>> I had left it in the DefaultMethodsTest.java and
>>>>> ClassInitializationTest.java tests because they are testing for
>>>>> output that seemed to be independent of -version implementation, in
>>>>> particular, java/lang/String default methods and any initialization
>>>>> that had no class initialization side effects (such as
>>>>> java.io.OutputStream), respectively. But I can make them more robust
>>>>> by running on a dummy class.
>>>>>
>>>>> As for the CDS, I realize I misinterpreted your conclusion. I can get
>>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>>> lines that disappear when CDS is enabled.
>>>>>
>>>>> Thanks,
>>>>> Rachel
>>>>>
>>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>>> I agree with Ioi. This is similar to the monitor inflation/deflation
>>>>>> logging test - we need to ensure we use something guaranteed to
>>>>>> always generate the expected log output.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>>> Rachel,
>>>>>>>
>>>>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>>>>> ItablesTest.java just runs "java -version", and depends on the fact
>>>>>>> that
>>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>>> itable
>>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>>
>>>>>>> This behavior depends on internal JDK implementation and there's no
>>>>>>> guarantee that it will always be true. There's also no guarantee 
>>>>>>> that
>>>>>>> the behavior will be the same across all the OS ports.
>>>>>>>
>>>>>>> In the future, some changes of "java -version" may cause this 
>>>>>>> test to
>>>>>>> fail only on a particular platform. I don't want someone to spend a
>>>>>>> day
>>>>>>> to track down some imaginative windows issues again just to find 
>>>>>>> out
>>>>>>> that it's a test bug.
>>>>>>>
>>>>>>> So, as I mentioned in the bug report, the tests should be 
>>>>>>> written to
>>>>>>> load a class that *you have written* to ensure that the output 
>>>>>>> will be
>>>>>>> there regardless of JDK implementation.
>>>>>>>
>>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>>> behaviors:
>>>>>>>
>>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>>> effects]");
>>>>>>>
>>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>>
>>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>>> Adding
>>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>>> disabled,
>>>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>>>
>>>>>>> Thanks
>>>>>>> - Ioi
>>>>>>>
>>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi
>>>>>>>> for
>>>>>>>> debugging and finding the source of the problem.
>>>>>>>>
>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>>
>>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>> Rachel
>>>>>>>
>>>>>
>>>>
>>>
>


From max.ockner at oracle.com  Wed Jan 20 17:29:35 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Wed, 20 Jan 2016 12:29:35 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569FBB8C.3080103@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com> <569FB582.3050100@oracle.com>
	<569FBB8C.3080103@oracle.com>
Message-ID: <569FC3FF.3070305@oracle.com>

Looks good to me.
Thanks,
Max
On 1/20/2016 11:53 AM, Rachel Protacio wrote:
> http://cr.openjdk.java.net/~rprotacio/8146435.03/
>
> I went ahead and corrected the style in all the UL test files. If 
> someone can review them to make sure I understood correctly, I'll go 
> ahead and commit!
>
> Thanks,
> Rachel
>
> On 1/20/2016 11:27 AM, Rachel Protacio wrote:
>> Thanks for the reviews, Ioi and David! I'll fix those style issues.
>> Rachel
>>
>> On 1/19/2016 11:45 PM, David Holmes wrote:
>>> Hi Rachel,
>>>
>>> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>>>> Hello, again!
>>>>
>>>> A call for brand new reviews; I've corrected the code as requested by
>>>> Ioi, i.e. none of the tests use "java -version" at all and the
>>>> ItablesTest forces the use of vtables, even when class sharing is
>>>> enabled (as on windows). Thanks to Coleen for guiding me through the
>>>> latter.
>>>>
>>>> The fixes pass JPRT once and for all! Webrev at
>>>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>>>
>>> Functionally this all looks fine.
>>>
>>> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>>>
>>> Style Nit: The breakups of long processBuilder lines don't follow 
>>> the Java style guide [1] for doing such changes. My preferred 
>>> approach (Variant 3 of 'continuation lines') is to always keep the 
>>> first argument to a call on the same line, then indent subsequent 
>>> arguments to it on separate lines eg (I hope this formats correctly 
>>> in email):
>>>
>>> ProcessBuilder pb = 
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info", 
>>> "-Xverify:all", "-Xmx64m", "BadMap50");
>>>
>>> becomes:
>>>
>>> ProcessBuilder pb = 
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>> "-Xverify:all",
>>> "-Xmx64m",
>>> "BadMap50");
>>>
>>> If that is still too long you can also break after the = and only 
>>> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>>>
>>> ProcessBuilder pb =
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>                                               "-Xverify:all",
>>>                                               "-Xmx64m",
>>>                                               "BadMap50");
>>>
>>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get 
>>> published yet?)
>>>
>>> Thanks,
>>> David
>>>
>>>> I changed the copyrights in ClassB.java and VtablesTest.java because I
>>>> had erroneously written them as 2015 when they weren't actually 
>>>> checked
>>>> in until 2016.
>>>>
>>>> Thank you,
>>>> Rachel
>>>>
>>>>
>>>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>>>
>>>>>
>>>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Yes, we have agreed not to use "-version" for triggering potentially
>>>>>> changeable processes. Ioi, I think you may have misread my code as I
>>>>>> did not use "java -version" for ItablesTest.java.
>>>>> Hi Rachel,
>>>>>
>>>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>>>> ClassB, which is pretty simple and by itself won't generate the
>>>>> "vtable index" output. If it's not too much effort, instead of
>>>>> removing the that output from the test, I would suggest changing
>>>>> ClassB so that it would produce the desired output.
>>>>>
>>>>> Thanks
>>>>>
>>>>> - Ioi
>>>>>
>>>>>
>>>>>> I had left it in the DefaultMethodsTest.java and
>>>>>> ClassInitializationTest.java tests because they are testing for
>>>>>> output that seemed to be independent of -version implementation, in
>>>>>> particular, java/lang/String default methods and any initialization
>>>>>> that had no class initialization side effects (such as
>>>>>> java.io.OutputStream), respectively. But I can make them more robust
>>>>>> by running on a dummy class.
>>>>>>
>>>>>> As for the CDS, I realize I misinterpreted your conclusion. I can 
>>>>>> get
>>>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>>>> lines that disappear when CDS is enabled.
>>>>>>
>>>>>> Thanks,
>>>>>> Rachel
>>>>>>
>>>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>>>> I agree with Ioi. This is similar to the monitor 
>>>>>>> inflation/deflation
>>>>>>> logging test - we need to ensure we use something guaranteed to
>>>>>>> always generate the expected log output.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>>>> Rachel,
>>>>>>>>
>>>>>>>> I don't think adding "-Xshare:off" is the correct fix. For 
>>>>>>>> example,
>>>>>>>> ItablesTest.java just runs "java -version", and depends on the 
>>>>>>>> fact
>>>>>>>> that
>>>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>>>> itable
>>>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>>>
>>>>>>>> This behavior depends on internal JDK implementation and 
>>>>>>>> there's no
>>>>>>>> guarantee that it will always be true. There's also no 
>>>>>>>> guarantee that
>>>>>>>> the behavior will be the same across all the OS ports.
>>>>>>>>
>>>>>>>> In the future, some changes of "java -version" may cause this 
>>>>>>>> test to
>>>>>>>> fail only on a particular platform. I don't want someone to 
>>>>>>>> spend a
>>>>>>>> day
>>>>>>>> to track down some imaginative windows issues again just to 
>>>>>>>> find out
>>>>>>>> that it's a test bug.
>>>>>>>>
>>>>>>>> So, as I mentioned in the bug report, the tests should be 
>>>>>>>> written to
>>>>>>>> load a class that *you have written* to ensure that the output 
>>>>>>>> will be
>>>>>>>> there regardless of JDK implementation.
>>>>>>>>
>>>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>>>> behaviors:
>>>>>>>>
>>>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>>>> effects]");
>>>>>>>>
>>>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>>>
>>>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>>>> Adding
>>>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>>>> disabled,
>>>>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> - Ioi
>>>>>>>>
>>>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to 
>>>>>>>>> Ioi
>>>>>>>>> for
>>>>>>>>> debugging and finding the source of the problem.
>>>>>>>>>
>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>>>
>>>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>>>
>>>>>>>>> Thank you!
>>>>>>>>> Rachel
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>


From rachel.protacio at oracle.com  Wed Jan 20 17:39:48 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 20 Jan 2016 12:39:48 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569FC3FF.3070305@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com> <569FB582.3050100@oracle.com>
	<569FBB8C.3080103@oracle.com> <569FC3FF.3070305@oracle.com>
Message-ID: <569FC664.9010807@oracle.com>

Thank you, Max!


On 1/20/2016 12:29 PM, Max Ockner wrote:
> Looks good to me.
> Thanks,
> Max
> On 1/20/2016 11:53 AM, Rachel Protacio wrote:
>> http://cr.openjdk.java.net/~rprotacio/8146435.03/
>>
>> I went ahead and corrected the style in all the UL test files. If 
>> someone can review them to make sure I understood correctly, I'll go 
>> ahead and commit!
>>
>> Thanks,
>> Rachel
>>
>> On 1/20/2016 11:27 AM, Rachel Protacio wrote:
>>> Thanks for the reviews, Ioi and David! I'll fix those style issues.
>>> Rachel
>>>
>>> On 1/19/2016 11:45 PM, David Holmes wrote:
>>>> Hi Rachel,
>>>>
>>>> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>>>>> Hello, again!
>>>>>
>>>>> A call for brand new reviews; I've corrected the code as requested by
>>>>> Ioi, i.e. none of the tests use "java -version" at all and the
>>>>> ItablesTest forces the use of vtables, even when class sharing is
>>>>> enabled (as on windows). Thanks to Coleen for guiding me through the
>>>>> latter.
>>>>>
>>>>> The fixes pass JPRT once and for all! Webrev at
>>>>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>>>>
>>>> Functionally this all looks fine.
>>>>
>>>> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>>>>
>>>> Style Nit: The breakups of long processBuilder lines don't follow 
>>>> the Java style guide [1] for doing such changes. My preferred 
>>>> approach (Variant 3 of 'continuation lines') is to always keep the 
>>>> first argument to a call on the same line, then indent subsequent 
>>>> arguments to it on separate lines eg (I hope this formats correctly 
>>>> in email):
>>>>
>>>> ProcessBuilder pb = 
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info", 
>>>> "-Xverify:all", "-Xmx64m", "BadMap50");
>>>>
>>>> becomes:
>>>>
>>>> ProcessBuilder pb = 
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>> "-Xverify:all",
>>>> "-Xmx64m",
>>>> "BadMap50");
>>>>
>>>> If that is still too long you can also break after the = and only 
>>>> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>>>>
>>>> ProcessBuilder pb =
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>> "-Xverify:all",
>>>>                                               "-Xmx64m",
>>>>                                               "BadMap50");
>>>>
>>>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get 
>>>> published yet?)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> I changed the copyrights in ClassB.java and VtablesTest.java 
>>>>> because I
>>>>> had erroneously written them as 2015 when they weren't actually 
>>>>> checked
>>>>> in until 2016.
>>>>>
>>>>> Thank you,
>>>>> Rachel
>>>>>
>>>>>
>>>>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>>>>
>>>>>>
>>>>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Yes, we have agreed not to use "-version" for triggering 
>>>>>>> potentially
>>>>>>> changeable processes. Ioi, I think you may have misread my code 
>>>>>>> as I
>>>>>>> did not use "java -version" for ItablesTest.java.
>>>>>> Hi Rachel,
>>>>>>
>>>>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>>>>> ClassB, which is pretty simple and by itself won't generate the
>>>>>> "vtable index" output. If it's not too much effort, instead of
>>>>>> removing the that output from the test, I would suggest changing
>>>>>> ClassB so that it would produce the desired output.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> - Ioi
>>>>>>
>>>>>>
>>>>>>> I had left it in the DefaultMethodsTest.java and
>>>>>>> ClassInitializationTest.java tests because they are testing for
>>>>>>> output that seemed to be independent of -version implementation, in
>>>>>>> particular, java/lang/String default methods and any initialization
>>>>>>> that had no class initialization side effects (such as
>>>>>>> java.io.OutputStream), respectively. But I can make them more 
>>>>>>> robust
>>>>>>> by running on a dummy class.
>>>>>>>
>>>>>>> As for the CDS, I realize I misinterpreted your conclusion. I 
>>>>>>> can get
>>>>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>>>>> lines that disappear when CDS is enabled.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rachel
>>>>>>>
>>>>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>>>>> I agree with Ioi. This is similar to the monitor 
>>>>>>>> inflation/deflation
>>>>>>>> logging test - we need to ensure we use something guaranteed to
>>>>>>>> always generate the expected log output.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>>>>> Rachel,
>>>>>>>>>
>>>>>>>>> I don't think adding "-Xshare:off" is the correct fix. For 
>>>>>>>>> example,
>>>>>>>>> ItablesTest.java just runs "java -version", and depends on the 
>>>>>>>>> fact
>>>>>>>>> that
>>>>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>>>>> itable
>>>>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>>>>
>>>>>>>>> This behavior depends on internal JDK implementation and 
>>>>>>>>> there's no
>>>>>>>>> guarantee that it will always be true. There's also no 
>>>>>>>>> guarantee that
>>>>>>>>> the behavior will be the same across all the OS ports.
>>>>>>>>>
>>>>>>>>> In the future, some changes of "java -version" may cause this 
>>>>>>>>> test to
>>>>>>>>> fail only on a particular platform. I don't want someone to 
>>>>>>>>> spend a
>>>>>>>>> day
>>>>>>>>> to track down some imaginative windows issues again just to 
>>>>>>>>> find out
>>>>>>>>> that it's a test bug.
>>>>>>>>>
>>>>>>>>> So, as I mentioned in the bug report, the tests should be 
>>>>>>>>> written to
>>>>>>>>> load a class that *you have written* to ensure that the output 
>>>>>>>>> will be
>>>>>>>>> there regardless of JDK implementation.
>>>>>>>>>
>>>>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>>>>> behaviors:
>>>>>>>>>
>>>>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>>>>> effects]");
>>>>>>>>>
>>>>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>>>>
>>>>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>>>>> Adding
>>>>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>>>>> disabled,
>>>>>>>>> and would cover up problems that only show up when CDS is 
>>>>>>>>> enabled.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> - Ioi
>>>>>>>>>
>>>>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks 
>>>>>>>>>> to Ioi
>>>>>>>>>> for
>>>>>>>>>> debugging and finding the source of the problem.
>>>>>>>>>>
>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>>>>
>>>>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>>>>
>>>>>>>>>> Thank you!
>>>>>>>>>> Rachel
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From yumin.qi at oracle.com  Wed Jan 20 18:54:39 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 20 Jan 2016 10:54:39 -0800
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56977DBB.3070502@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
Message-ID: <569FD7EF.2010007@oracle.com>

Hi, Vladimir

   I filed another bug 8147755 for ASM which now I have a fix for it: 
make asm create correct constant tag for a handle pointing to interface 
static method.
https://bugs.openjdk.java.net/browse/JDK-8147755

   I have a simple test case showed it works to generate a callsite for  
static I.m:

Constant pool:
....
   #16 = Utf8               Calling static I.m():
   #17 = String             #16            // Calling static I.m():
   #18 = Utf8               java/io/PrintStream
   #19 = Class              #18            // java/io/PrintStream
   #20 = Utf8               println
   #21 = Utf8               (Ljava/lang/String;)V
   #22 = NameAndType        #20:#21        // println:(Ljava/lang/String;)V
   #23 = Methodref          #19.#22        // 
java/io/PrintStream.println:(Ljava/lang/String;)V
   #24 = Utf8               I
   #25 = Class              #24            // I
   #26 = Utf8               m
   #27 = NameAndType        #26:#6         // m:()V
   #28 = InterfaceMethodref #25.#27        // I.m:()V
   #29 = MethodHandle       #6:#28         // invokestatic I.m:()V
   #30 = Utf8               java/lang/invoke/MethodHandle
....
{
   public static void staticCallIm();
     descriptor: ()V
     flags: ACC_PUBLIC, ACC_STATIC
     Code:
       stack=3, locals=1, args_size=0
          0: getstatic     #15                 // Field 
java/lang/System.out:Ljava/io/PrintStream;
          3: ldc           #17                 // String Calling static 
I.m():
          5: invokevirtual #23                 // Method 
java/io/PrintStream.println:(Ljava/lang/String;)V
          8: ldc           #29                 // MethodHandle 
invokestatic I.m:()V
         10: invokevirtual #34                 // Method 
java/lang/invoke/MethodHandle.invoke:()V
         13: return
}

    So now keep the original fix of 8087223 as 8145148 fix and  relax 
for the check in method handle method tag no longer needed with 8147755 
solved.

    Still, I need to test defmeth again to see the failed cases --- and 
the fix will be in defmeth use the new added Handle.

     Stas and Dmitry:
     8143320 fix may change if tests on new binary with 8145148/8147755 
shows defmeth needs changes too(I think so, since I add a new Handle 
constructor).

      The previous webrev now has conflict with the current repo so need 
make new webrev and send codereview again.

Thanks
Yumin

On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
> Yumin,
>
> Please, file a follow-up bug for the missing check (interface static 
> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>
> I'd prefer to keep the original VM fix and quarantine affected tests 
> until ASM is fixed, but 2-phase fix is also fine with me.
>
> Not sure how to handle ASM problem. Is the problem present in the 
> latest ASM version?
>
> The best way would be to get it fixed upstream first and then sync 
> internal copy with upstream. defmeth tests use the library bundled 
> with the JDK.
>
> Best regards,
> Vladimir Ivanov
>
> On 12/21/15 9:52 PM, Yumin Qi wrote:
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>
>> This is REDO for bug 8087223, which was backed out due to failed on
>> 8143317 and 8143320.
>> The defmeth encoutered new failures after the fix, which now has correct
>> constant tags. The test bugs will be addressed in 8143320, which based
>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>
>> One difference from the attached for this webrev is that in MethodHandle
>> resolution, I relax the check for one specific case: Using MethodHandle
>> to invoke static default interface method. In this case, we must use
>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>> interface method tag!).  ASM currently has no API to generate
>> invokeinterface for a interface static default method through
>> MethodHandle invocation.
>>
>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>> Note the fix still fails 8143320 and 8143317 which are not fixed at the
>> momment.
>>
>>
>> Thanks
>> Yumin
>>
>>
>> Original post:
>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>> Please review:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>
>> According to JVMS-8:
>>
>> JVMS-5.4.3.3 Method Resolution:
>>   " If C is an interface, method resolution throws an
>> IncompatibleClassChangeError."
>> JVMS-5.4.3.4 Interface Method Resolution:
>>   "If C is not an interface, interface method resolution throws an
>> IncompatibleClassChangeError"
>>
>> When invoke a method with resolved to an interface method, or invoke a
>> interface method with resolved to an instance method,  ICCE should be
>> thrown. The case usually happens when using tools like asmtools or
>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>
>> The fix is carrying the constantTag for the method at call and check if
>> tag is consistent with the method called. Doing this by adding a member
>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>> to see if tag matched with the correct method.
>>
>> The fix solved the problem when call is from interpreter and compiler,
>> bug for MethodHandle invoke, which should be addressed in another bug,
>> since the MethodHandle does not come with a byte stream and getting the
>> constant pool index at the invoke is not possible.  It will be addressed
>> in another bug.
>>
>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>> test list(in progress).
>> manually tested:  1) -Xint
>>                                 2) -Xcomp
>>                                 3) -Xcomp -XX:-TieredCompiltion
>>                                 4) -Xcomp -XX:+TieredCompilation
>>
>> Thanks to Coleen for helping fixed constant pool index and cleaned
>> LinkInfo.
>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>>
>> Second revision attached.
>>
>>
>>
>>
>> Thanks
>> Yumin


From chris.plummer at oracle.com  Thu Jan 21 01:27:15 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 20 Jan 2016 17:27:15 -0800
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569D4D2A.8040205@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <5699726A.6000403@oracle.com>
	<569C61FF.6010600@oracle.com> <569D4D2A.8040205@oracle.com>
Message-ID: <56A033F3.4010808@oracle.com>

After some discussion offline, it was decided that asserts are not 
needed since all the values for which alignment could be checked are 
already scaled to word size. Since we want word size alignment, there's 
no finer alignment that can be checked for.

Chris

On 1/18/16 12:38 PM, Chris Plummer wrote:
> Ok, I'll add some asserts.
>
> Chris
>
> On 1/17/16 7:54 PM, David Holmes wrote:
>> Hi Chris,
>>
>> I'm also okay with the changes, but as Karen asked the other day 
>> (TOI), are there any asserts checking that everything is actually 
>> aligned as expected?
>>
>> Thanks,
>> David
>>
>> On 16/01/2016 8:27 AM, Chris Plummer wrote:
>>> Hi Coleen,
>>>
>>> On 1/15/16 2:12 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've read this change and it looks correct to me.  The 32/64 bit
>>>> natural alignment should be used for the vtable and itable embedded
>>>> fields, and this change accomplishes this.
>>> Thanks for looking at this. It's much appreciated.
>>>>
>>>>
>>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>>> The only change is fixing SA to also no longer do the aligning:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/ 
>>>>>
>>>>>
>>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>>> addressing them with these changes:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>>> incorrect size and has no test
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>>> macros like align_object_size
>>>>
>>>> I am currently working on this bug because it is wrong to use
>>>> align_object_size() for metadata.  Metadata should be naturally
>>>> aligned and I'll verify it's the case in metaspace allocation code.
>>>>
>>>> Thanks to Mikael for the alert about SA code that copies this.  It
>>>> seems that the SA shouldn't report metadata sizes if that's also
>>>> reported with jcmd.  Maybe the jstat -classstats functionality that
>>>> uses SA (which is wrong now) can be removed?  And why would someone
>>>> use this on a core file?
>>> Well, that's a good question for the serviceability team.
>>>>
>>>>>
>>>>> And just restating here why I think the removal of these
>>>>> align_object_field references is safe:
>>>>>
>>>>> The argument to align_object_offset() is the offset in words, and it
>>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>>> boundary. Since the argument is in words, there is no concern with my
>>>>> changes removing word alignment of something that is not already word
>>>>> aligned. It must already be word aligned or the current
>>>>> implementation would be broken.
>>>>>
>>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>>> on 64-bit.
>>>>
>>>> It (align_object_offset) is actually wrong, but since the size of the
>>>> objects are naturally aligned, I think it's better to not have some
>>>> explicit alignment call.
>>>>>
>>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is
>>>>> in fact the goal of this change, so what remains is to show that
>>>>> 64-bit alignment of the fields is not needed on 32-bit. Since all of
>>>>> the fields for which alignment has been removed are 32-bit types, it
>>>>> is safe to keep them 32-bit word aligned instead of making them
>>>>> 64-bit aligned.
>>>>>
>>>>
>>>> Agree.  This looks good.
>>> Great. Thanks again.
>>>
>>> Chris
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ 
>>>>>>
>>>>>>
>>>>>> A bit of background would help. The InstanceKlass object has a
>>>>>> number of variable length fields that are laid out after the
>>>>>> declared fields. When an InstanceKlass object is allocated, extra
>>>>>> memory is allocated for it to leave room for these fields. The first
>>>>>> three of these fields are vtable, itable, and nonstatic_oopmap. They
>>>>>> are all arrays of HeapWord sized values, which means void* size,
>>>>>> which means they only need 32-bit alignment on 32-bit systems.
>>>>>> However, they have always been 64-bit aligned. This webrev removes
>>>>>> the forced 64-bit alignment on 32-bit systems, saving footprint.
>>>>>>
>>>>>> This change affects all 32-bit platforms. It should have no net
>>>>>> impact on 64-bit platforms since the fields remain (naturally)
>>>>>> 64-bit aligned (unless of course I've introduced a bug). The intent
>>>>>> is to not change what is done for 64-bit platforms.
>>>>>>
>>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>>> just removes an "if" block where the condition should always have
>>>>>> evaluated to false, so it should have no net affect.
>>>>>>
>>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>>> there are any additional tests that should be run.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>
>>>>
>>>
>


From david.holmes at oracle.com  Thu Jan 21 08:45:23 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 21 Jan 2016 18:45:23 +1000
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <569FBB8C.3080103@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com> <569FB582.3050100@oracle.com>
	<569FBB8C.3080103@oracle.com>
Message-ID: <56A09AA3.1030700@oracle.com>

On 21/01/2016 2:53 AM, Rachel Protacio wrote:
> http://cr.openjdk.java.net/~rprotacio/8146435.03/
>
> I went ahead and corrected the style in all the UL test files. If
> someone can review them to make sure I understood correctly, I'll go
> ahead and commit!

Looks good!

Thanks,
David

> Thanks,
> Rachel
>
> On 1/20/2016 11:27 AM, Rachel Protacio wrote:
>> Thanks for the reviews, Ioi and David! I'll fix those style issues.
>> Rachel
>>
>> On 1/19/2016 11:45 PM, David Holmes wrote:
>>> Hi Rachel,
>>>
>>> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>>>> Hello, again!
>>>>
>>>> A call for brand new reviews; I've corrected the code as requested by
>>>> Ioi, i.e. none of the tests use "java -version" at all and the
>>>> ItablesTest forces the use of vtables, even when class sharing is
>>>> enabled (as on windows). Thanks to Coleen for guiding me through the
>>>> latter.
>>>>
>>>> The fixes pass JPRT once and for all! Webrev at
>>>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>>>
>>> Functionally this all looks fine.
>>>
>>> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>>>
>>> Style Nit: The breakups of long processBuilder lines don't follow the
>>> Java style guide [1] for doing such changes. My preferred approach
>>> (Variant 3 of 'continuation lines') is to always keep the first
>>> argument to a call on the same line, then indent subsequent arguments
>>> to it on separate lines eg (I hope this formats correctly in email):
>>>
>>> ProcessBuilder pb =
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>> "-Xverify:all", "-Xmx64m", "BadMap50");
>>>
>>> becomes:
>>>
>>> ProcessBuilder pb =
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>> "-Xverify:all",
>>> "-Xmx64m",
>>> "BadMap50");
>>>
>>> If that is still too long you can also break after the = and only
>>> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>>>
>>> ProcessBuilder pb =
>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>                                               "-Xverify:all",
>>>                                               "-Xmx64m",
>>>                                               "BadMap50");
>>>
>>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get
>>> published yet?)
>>>
>>> Thanks,
>>> David
>>>
>>>> I changed the copyrights in ClassB.java and VtablesTest.java because I
>>>> had erroneously written them as 2015 when they weren't actually checked
>>>> in until 2016.
>>>>
>>>> Thank you,
>>>> Rachel
>>>>
>>>>
>>>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>>>
>>>>>
>>>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Yes, we have agreed not to use "-version" for triggering potentially
>>>>>> changeable processes. Ioi, I think you may have misread my code as I
>>>>>> did not use "java -version" for ItablesTest.java.
>>>>> Hi Rachel,
>>>>>
>>>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>>>> ClassB, which is pretty simple and by itself won't generate the
>>>>> "vtable index" output. If it's not too much effort, instead of
>>>>> removing the that output from the test, I would suggest changing
>>>>> ClassB so that it would produce the desired output.
>>>>>
>>>>> Thanks
>>>>>
>>>>> - Ioi
>>>>>
>>>>>
>>>>>> I had left it in the DefaultMethodsTest.java and
>>>>>> ClassInitializationTest.java tests because they are testing for
>>>>>> output that seemed to be independent of -version implementation, in
>>>>>> particular, java/lang/String default methods and any initialization
>>>>>> that had no class initialization side effects (such as
>>>>>> java.io.OutputStream), respectively. But I can make them more robust
>>>>>> by running on a dummy class.
>>>>>>
>>>>>> As for the CDS, I realize I misinterpreted your conclusion. I can get
>>>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>>>> lines that disappear when CDS is enabled.
>>>>>>
>>>>>> Thanks,
>>>>>> Rachel
>>>>>>
>>>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>>>> I agree with Ioi. This is similar to the monitor inflation/deflation
>>>>>>> logging test - we need to ensure we use something guaranteed to
>>>>>>> always generate the expected log output.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>>>> Rachel,
>>>>>>>>
>>>>>>>> I don't think adding "-Xshare:off" is the correct fix. For example,
>>>>>>>> ItablesTest.java just runs "java -version", and depends on the fact
>>>>>>>> that
>>>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>>>> itable
>>>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>>>
>>>>>>>> This behavior depends on internal JDK implementation and there's no
>>>>>>>> guarantee that it will always be true. There's also no guarantee
>>>>>>>> that
>>>>>>>> the behavior will be the same across all the OS ports.
>>>>>>>>
>>>>>>>> In the future, some changes of "java -version" may cause this
>>>>>>>> test to
>>>>>>>> fail only on a particular platform. I don't want someone to spend a
>>>>>>>> day
>>>>>>>> to track down some imaginative windows issues again just to find
>>>>>>>> out
>>>>>>>> that it's a test bug.
>>>>>>>>
>>>>>>>> So, as I mentioned in the bug report, the tests should be
>>>>>>>> written to
>>>>>>>> load a class that *you have written* to ensure that the output
>>>>>>>> will be
>>>>>>>> there regardless of JDK implementation.
>>>>>>>>
>>>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>>>> behaviors:
>>>>>>>>
>>>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>>>> effects]");
>>>>>>>>
>>>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>>>
>>>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>>>> Adding
>>>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>>>> disabled,
>>>>>>>> and would cover up problems that only show up when CDS is enabled.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> - Ioi
>>>>>>>>
>>>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks to Ioi
>>>>>>>>> for
>>>>>>>>> debugging and finding the source of the problem.
>>>>>>>>>
>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>>>
>>>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>>>
>>>>>>>>> Thank you!
>>>>>>>>> Rachel
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

From marcus.larsson at oracle.com  Thu Jan 21 12:30:23 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 21 Jan 2016 13:30:23 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <569E40FF.9070003@oracle.com>
References: <569E40FF.9070003@oracle.com>
Message-ID: <56A0CF5F.4050401@oracle.com>

Updated webrev:
http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/

Incremental:
http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/

Only LogConfiguration::initialize() and LogTagSet constructor now calls 
the stdout_output()/stderr_output() functions. Made the functions 
private to prevent usages from other places. Also removed the previous 
output instances from LogFileStream.{c,h}pp which I forgot to do in the 
first patch.

Thanks,
Marcus

On 01/19/2016 02:58 PM, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to fix an issue in UL causing the VM 
> to crash during shutdown.
>
> The problem is that the static LogStdoutOutput is deinitialized before 
> the last use of it (G1 concurrent thread tries to log very late during 
> VM shutdown). The solution is to make sure neither LogStdoutOutput nor 
> LogStderrOutput are deinitialized during the full lifetime of the VM. 
> To accomplish this I've changed the storage from static objects to 
> static pointers to heap instances that are allocated & initialized on 
> first use [0]. These instances are never deleted and can always be 
> used. Also updated LogConfiguration::finalize to disable all file 
> outputs before deleting & freeing them.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146009
>
> Testing:
> - local runs of the reproducer (500+ iterations without crashing)
> - JPRT
>
> Thanks,
> Marcus
>
> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use


From marcus.larsson at oracle.com  Thu Jan 21 12:31:48 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 21 Jan 2016 13:31:48 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <56A0CF5F.4050401@oracle.com>
References: <569E40FF.9070003@oracle.com> <56A0CF5F.4050401@oracle.com>
Message-ID: <56A0CFB4.2050601@oracle.com>

Sorry, wrong link to incremental webrev.

Look here instead:
http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00-01/


On 01/21/2016 01:30 PM, Marcus Larsson wrote:
> Updated webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/
>
> Only LogConfiguration::initialize() and LogTagSet constructor now 
> calls the stdout_output()/stderr_output() functions. Made the 
> functions private to prevent usages from other places. Also removed 
> the previous output instances from LogFileStream.{c,h}pp which I 
> forgot to do in the first patch.
>
> Thanks,
> Marcus
>
> On 01/19/2016 02:58 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to fix an issue in UL causing the 
>> VM to crash during shutdown.
>>
>> The problem is that the static LogStdoutOutput is deinitialized 
>> before the last use of it (G1 concurrent thread tries to log very 
>> late during VM shutdown). The solution is to make sure neither 
>> LogStdoutOutput nor LogStderrOutput are deinitialized during the full 
>> lifetime of the VM. To accomplish this I've changed the storage from 
>> static objects to static pointers to heap instances that are 
>> allocated & initialized on first use [0]. These instances are never 
>> deleted and can always be used. Also updated 
>> LogConfiguration::finalize to disable all file outputs before 
>> deleting & freeing them.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146009
>>
>> Testing:
>> - local runs of the reproducer (500+ iterations without crashing)
>> - JPRT
>>
>> Thanks,
>> Marcus
>>
>> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
>


From thomas.stuefe at gmail.com  Thu Jan 21 17:00:40 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 21 Jan 2016 18:00:40 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
Message-ID: <CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>

Hi,

On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com <kirk at kodewerk.com>
wrote:

>
> > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com>
> wrote:
> >
> > On 19/01/2016 11:58 PM, Marcus Larsson wrote:
> >> Hi,
> >>
> >> Please review the following patch to fix an issue in UL causing the VM
> >> to crash during shutdown.
> >>
> >> The problem is that the static LogStdoutOutput is deinitialized before
> >> the last use of it (G1 concurrent thread tries to log very late during
> >> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
> >> LogStderrOutput are deinitialized during the full lifetime of the VM. To
> >
> > I agree with Kim here - this seems like the "wrong" solution. If the G1
> thread can log very late during VM shutdown then we could
> > - move the logging "deinitialize" to later in the shutdown process
> (assuming the G1 threads won't continue to run right up to process
> termination); or
> > - ensure the G1 threads have to terminate, or block, before the
> deinitialization
>
> Can I ask a silly question? If the JVM is shutting down is there a need to
> de-initialize logging?
>
>
I wonder too. Why not let the logging live right to the end? Logging is
useful in all life phases of the VM; if logging is disabled before
initialization or after cleanup, if one does not see output one always
wonders if logging is disabled or if we just did not hit the logging call.

Instead of deleting or disabling the LogOutput objects, why not just flush
them (to ensure they write all accumulated output) but let them live on? As
far as I can see, all LogOutput childs are keeping file descriptors which
get closed automatically once the process stops.

Or am I missing something obvious?

Kind Regards, Thomas



> IME iit is highly unlikely that the loss of one or two GC log records
> would make a difference in my use cases.
>
> Kind regards,
> Kirk
>
>

From rachel.protacio at oracle.com  Thu Jan 21 17:07:25 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Thu, 21 Jan 2016 12:07:25 -0500
Subject: RFR: 8146435: [TESTBUG] Logging tests are failing intermittently
	on windows when executed by JPRT
In-Reply-To: <56A09AA3.1030700@oracle.com>
References: <56954577.90306@oracle.com> <5695AD52.803@oracle.com>
	<5695BA51.6080408@oracle.com> <56966E11.6030105@oracle.com>
	<5696A4ED.7010301@oracle.com> <569E77B2.1050503@oracle.com>
	<569F1106.5040209@oracle.com> <569FB582.3050100@oracle.com>
	<569FBB8C.3080103@oracle.com> <56A09AA3.1030700@oracle.com>
Message-ID: <56A1104D.7030801@oracle.com>

Thanks, David!
Rachel

On 1/21/2016 3:45 AM, David Holmes wrote:
> On 21/01/2016 2:53 AM, Rachel Protacio wrote:
>> http://cr.openjdk.java.net/~rprotacio/8146435.03/
>>
>> I went ahead and corrected the style in all the UL test files. If
>> someone can review them to make sure I understood correctly, I'll go
>> ahead and commit!
>
> Looks good!
>
> Thanks,
> David
>
>> Thanks,
>> Rachel
>>
>> On 1/20/2016 11:27 AM, Rachel Protacio wrote:
>>> Thanks for the reviews, Ioi and David! I'll fix those style issues.
>>> Rachel
>>>
>>> On 1/19/2016 11:45 PM, David Holmes wrote:
>>>> Hi Rachel,
>>>>
>>>> On 20/01/2016 3:51 AM, Rachel Protacio wrote:
>>>>> Hello, again!
>>>>>
>>>>> A call for brand new reviews; I've corrected the code as requested by
>>>>> Ioi, i.e. none of the tests use "java -version" at all and the
>>>>> ItablesTest forces the use of vtables, even when class sharing is
>>>>> enabled (as on windows). Thanks to Coleen for guiding me through the
>>>>> latter.
>>>>>
>>>>> The fixes pass JPRT once and for all! Webrev at
>>>>> http://cr.openjdk.java.net/~rprotacio/8146435.02/
>>>>
>>>> Functionally this all looks fine.
>>>>
>>>> test/runtime/logging/ClassInitializationTest.java (and elsewhere)
>>>>
>>>> Style Nit: The breakups of long processBuilder lines don't follow the
>>>> Java style guide [1] for doing such changes. My preferred approach
>>>> (Variant 3 of 'continuation lines') is to always keep the first
>>>> argument to a call on the same line, then indent subsequent arguments
>>>> to it on separate lines eg (I hope this formats correctly in email):
>>>>
>>>> ProcessBuilder pb =
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>> "-Xverify:all", "-Xmx64m", "BadMap50");
>>>>
>>>> becomes:
>>>>
>>>> ProcessBuilder pb =
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>> "-Xverify:all",
>>>> "-Xmx64m",
>>>> "BadMap50");
>>>>
>>>> If that is still too long you can also break after the = and only
>>>> indent the initial call line by 8 (Variant 1) then use variant 3 eg:
>>>>
>>>> ProcessBuilder pb =
>>>> ProcessTools.createJavaProcessBuilder("-Xlog:classinit=info",
>>>> "-Xverify:all",
>>>>                                               "-Xmx64m",
>>>>                                               "BadMap50");
>>>>
>>>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/ (did this get
>>>> published yet?)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> I changed the copyrights in ClassB.java and VtablesTest.java 
>>>>> because I
>>>>> had erroneously written them as 2015 when they weren't actually 
>>>>> checked
>>>>> in until 2016.
>>>>>
>>>>> Thank you,
>>>>> Rachel
>>>>>
>>>>>
>>>>> On 1/13/2016 2:26 PM, Ioi Lam wrote:
>>>>>>
>>>>>>
>>>>>> On 1/13/16 7:32 AM, Rachel Protacio wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Yes, we have agreed not to use "-version" for triggering 
>>>>>>> potentially
>>>>>>> changeable processes. Ioi, I think you may have misread my code 
>>>>>>> as I
>>>>>>> did not use "java -version" for ItablesTest.java.
>>>>>> Hi Rachel,
>>>>>>
>>>>>> Thanks for the explanation. I looked at ItablesTest again. It uses
>>>>>> ClassB, which is pretty simple and by itself won't generate the
>>>>>> "vtable index" output. If it's not too much effort, instead of
>>>>>> removing the that output from the test, I would suggest changing
>>>>>> ClassB so that it would produce the desired output.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> - Ioi
>>>>>>
>>>>>>
>>>>>>> I had left it in the DefaultMethodsTest.java and
>>>>>>> ClassInitializationTest.java tests because they are testing for
>>>>>>> output that seemed to be independent of -version implementation, in
>>>>>>> particular, java/lang/String default methods and any initialization
>>>>>>> that had no class initialization side effects (such as
>>>>>>> java.io.OutputStream), respectively. But I can make them more 
>>>>>>> robust
>>>>>>> by running on a dummy class.
>>>>>>>
>>>>>>> As for the CDS, I realize I misinterpreted your conclusion. I 
>>>>>>> can get
>>>>>>> rid of "-Xshare:off" and remove the parts of the tests looking for
>>>>>>> lines that disappear when CDS is enabled.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rachel
>>>>>>>
>>>>>>> On 1/12/2016 9:45 PM, David Holmes wrote:
>>>>>>>> I agree with Ioi. This is similar to the monitor 
>>>>>>>> inflation/deflation
>>>>>>>> logging test - we need to ensure we use something guaranteed to
>>>>>>>> always generate the expected log output.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 13/01/2016 11:50 AM, Ioi Lam wrote:
>>>>>>>>> Rachel,
>>>>>>>>>
>>>>>>>>> I don't think adding "-Xshare:off" is the correct fix. For 
>>>>>>>>> example,
>>>>>>>>> ItablesTest.java just runs "java -version", and depends on the 
>>>>>>>>> fact
>>>>>>>>> that
>>>>>>>>> at least one of the JDK classes that are implicitly loaded has an
>>>>>>>>> itable
>>>>>>>>> (or whatever contents that produces the "vtable index " output).
>>>>>>>>>
>>>>>>>>> This behavior depends on internal JDK implementation and 
>>>>>>>>> there's no
>>>>>>>>> guarantee that it will always be true. There's also no guarantee
>>>>>>>>> that
>>>>>>>>> the behavior will be the same across all the OS ports.
>>>>>>>>>
>>>>>>>>> In the future, some changes of "java -version" may cause this
>>>>>>>>> test to
>>>>>>>>> fail only on a particular platform. I don't want someone to 
>>>>>>>>> spend a
>>>>>>>>> day
>>>>>>>>> to track down some imaginative windows issues again just to find
>>>>>>>>> out
>>>>>>>>> that it's a test bug.
>>>>>>>>>
>>>>>>>>> So, as I mentioned in the bug report, the tests should be
>>>>>>>>> written to
>>>>>>>>> load a class that *you have written* to ensure that the output
>>>>>>>>> will be
>>>>>>>>> there regardless of JDK implementation.
>>>>>>>>>
>>>>>>>>> Here are other cases where the tests are dependent on unspecified
>>>>>>>>> behaviors:
>>>>>>>>>
>>>>>>>>> out.shouldContain("[Initialized").shouldContain("without side
>>>>>>>>> effects]");
>>>>>>>>>
>>>>>>>>>       All of the output in DefaultMethodsTest.java
>>>>>>>>>
>>>>>>>>> In fact, I think you should remove "-Xshare:off" from the tests.
>>>>>>>>> Adding
>>>>>>>>> -Xshare:off will also force the tests to be executed with CDS
>>>>>>>>> disabled,
>>>>>>>>> and would cover up problems that only show up when CDS is 
>>>>>>>>> enabled.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> - Ioi
>>>>>>>>>
>>>>>>>>> On 1/12/16 10:27 AM, Rachel Protacio wrote:
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> Please review this fix which adds "-Xshare:off" to all UL tests'
>>>>>>>>>> ProcessBuilders to prevent windows failures. Extreme thanks 
>>>>>>>>>> to Ioi
>>>>>>>>>> for
>>>>>>>>>> debugging and finding the source of the problem.
>>>>>>>>>>
>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146435/
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146435
>>>>>>>>>>
>>>>>>>>>> Tests sent to JPRT, pass on all platforms.
>>>>>>>>>>
>>>>>>>>>> Thank you!
>>>>>>>>>> Rachel
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>


From max.ockner at oracle.com  Fri Jan 22 00:22:22 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 21 Jan 2016 19:22:22 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <569068ED.6070509@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com>
Message-ID: <56A1763E.5030506@oracle.com>

Hello all,
This fix is now working again with the new changes incorporated.

New webrev: http://cr.openjdk.java.net/~mockner/classload.03/

I responded to all comments from Ioi and Coleen.
My answer to Ioi's first question is option #2.

Max

On 1/8/2016 8:57 PM, Ioi Lam wrote:
>
>
> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>
>> Hi, I have a bunch of comments that Ioi may have to help answer 
>> because I had some questions about how the logging output comes out.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>
>>
>> I think these can be UL-ized with less lines.  There's no need to 
>> check if log_is_enabled here.
>>
>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>> *!tty->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>> NULL) {*
>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>> *+ log->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> }
>>
>> *!if (class_loader() != NULL) {*
>> *!tty->print_cr("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>> class_loader()->klass()->internal_name());*
>> }
>>
>> What does this come out looking like?  It seems like it's going to 
>> have [classloaderdata] in front of every line printed.  I think this 
>> wants to be all one log line.
>>
>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>> *)cld->class_loader()),*
>> *+ cld->loader_name());*
>> *+ *
>> *+ if (string.not_null()) {*
>> *+ log->print(": ");*
>> *+ java_lang_String::print(string(), log);*
>> *+ } *
>> [classloaderdata] create class loader data <address>
>> [classloaderdata]  for instance <addr> of some name
>> [classloaderdata] :
>> [classloaderdata] some string
>>
> The UL JEP says this in http://openjdk.java.net/jeps/158
> "Goals ... Print line-at-a-time (no interleaving within same line)"
>
> log->print() is line-buffered. So all of these will be concatenated 
> into the same buffer until the final log->cr() or log->print_cr(), at 
> which point the whole line will be printed (with a single 
> [classloaderdata] prefix).
>
> Here's an example:
>
> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
> [0.780s][debug  ][classloaderdata] create class loader data 
> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
> sun/misc/Launcher$AppClassLoader: 
> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>
>>
>> You don't need to check log_is_enabled.  log_debug macro does that. 2 
>> instances in this file.
>>
>> *+ if (log_is_enabled(Debug, classload)) {*
>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>> *+ } *
>>
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>
>>
>> Do you want this to come out with fewer lines?   Maybe the messages 
>> should be collected in a tempStream and printed out at the end? LIke 
>> in this file:
>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>
>>
> There's no need to use the tempStream, since the UL log already 
> handles buffering.
>
> If my understanding of UL buffering is correct, I think the use of 
> tempStream should be removed as a clean up.
>
>> There's a bunch of tty->print's still in this function.
>>
>> *+ Handle class_loader(loader_data->class_loader());*
>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>
>> This could be simplified avoiding the Handle, which is not needed.
>>
>> *+ tty->print(" source: %s", 
>> loader_data->class_loader()->klass()->external_name());*
>>
>> Is the loader_data argument to print_loading_log simply the 
>> instanceKLass::_class_loader_data field?  In which case you can 
>> remove the argument and have:
>>
>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>> *
>>
> The original code (from classFileParser.cpp) is this:
>
>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
> _loader_data->class_loader()->klass()->external_name());
>
> I suppose _loader_data->class_loader() in that context should be 
> exactly the same as class_loader() inside the 
> InstanceKlass::print_loading_log function, so your suggestion should 
> work.
>
>> Obviously not to tty.
>
> You're right. The "tty->print" should be changed to log->print in 
> InstanceKlass::print_loading_log. What I don't understand is why the 
> output looks just fine.
>
> I never noticed these during my testing because the lines that use 
> tty->print are uncommon and did not show up. I'll try to come up with 
> a test case (I think it has something to do with reflection proxies ...).
>
>
> Thanks
> - Ioi
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>
>>
>> This one can be condensed also
>>
>> *!if (_log_is_enabled(Info, classload)_) {*
>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>> }
>>
>> to
>>
>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>
>> * 
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>
>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>> his previous mail.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>
>>
>> The return value 'ret' isn't used.  Either return an error if it 
>> returns and error (what errors does it return?) or don't have 'ret'.
>>
>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>
>>
>> Test looks great to me!
>>
>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>  151         checkFor("[classunload]", "[Unloading class");
>>
>> Can this be:
>>
>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>> "[classunload]", "[Unloading class");
>>
>> To not start a new process?
>>
>> Thanks,
>> Coleen
>>
>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>> Hello,
>>> Please review this unified logging conversion for several related 
>>> flags in the class loading system.
>>>
>>> Bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>> classloaderdata)
>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>
>>> Summary:
>>>
>>> There are two separate issues here. Originally Ioi and I began 
>>> working on these fixes in parallel, but eventually it became obvious 
>>> that the classload and classunload tags needed to be implemented 
>>> together. This change is a combination of Ioi's change for 8079408 
>>> and my change for 8142506.
>>>
>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>> This flag is added to the alias table. More verbose logging exists 
>>> at level debug (one level of verbosity up from info)
>>>
>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>> This flag is added to the alias table. More verbose logging exists 
>>> at level trace (converted from uses of WizardMode)
>>>
>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>
>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>> effected the implementation of "-verbose:class"
>>>
>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>
>>> If you have questions about the updates to the classloading log, Ioi 
>>> can give a better answer than I can.
>>>
>>> Thanks,
>>> Max
>>>
>>>
>>>
>>>
>>
>


From david.holmes at oracle.com  Fri Jan 22 04:37:09 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 14:37:09 +1000
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
In-Reply-To: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
References: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
Message-ID: <56A1B1F5.8070707@oracle.com>

Hi Jiangli,

> Please review the following improvements to HashtableTextDump::get_num() and HashtableTextDump::corrupted_if() described in JDK-8147500 <https://bugs.openjdk.java.net/browse/JDK-8147500>.
>
>  - The HashtableTextDump::get_num() is use to parse an integer value from the input file. It should check for integer overflow and report error without continuing.
>  - The HashtableTextDump::corrupted_if() should take an additional argument so caller can pass a meaningful error message.
>
> Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/

As improvements on the existing code this seems fine.

Thanks,
David

From david.holmes at oracle.com  Fri Jan 22 08:06:05 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 18:06:05 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
Message-ID: <56A1E2ED.1000109@oracle.com>

First a special thanks to Martin Buchholz for his input, feedback, 
critique and raising awareness of how non-simple this issue is.

bug: https://bugs.openjdk.java.net/browse/JDK-6515172
webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/

Basic problem:
   processors available for use <= processors online <= processors 
configured

but we always returned the number of online processors.

Solution is simple in its basic form: use sched_getaffinity to get the 
scheduling affinity mask and count the number of available processors.

Details are complicated by the desire to handle very large processor 
systems. See the bug report for lots of detailed discussions and references.

Testing:
  - new test that verifies behaviour when running under taskset
  - diagnostic hook injection (UseNewCodeN) to enable testing of all 
code paths (one hook is left in for non-product to allow easy testing of 
the dynamic path)
  - JPRT

Compatability issues:
- the system code we're using now is at least 5 years old so distro's 
older than that (which are not officially supported) may not work
- anyone already running under a processor constrained environment (like 
Docker) and using availableProcessor() to "size" things, will find that 
size has now changed. We do not expect this to be a problem - on the 
contrary we expect Docker users to want the new behaviour.

Thanks,
David

From thomas.stuefe at gmail.com  Fri Jan 22 09:21:31 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 22 Jan 2016 10:21:31 +0100
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A1E2ED.1000109@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
Message-ID: <CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>

Hi David,

I may be doing this wrong, but I do not get this to work for me (ubuntu
14.4).

I built hs-rt with your patch. I am running a simple loop with
Runtime.availableProcessors(). I change affinity with taskset and would
expect output to change, but nothing changes.

java command line: ../images/jdk/bin/java -Xlog:os=trace test
taskset command:  taskset -p 0x1 <pid>

Output:

proc: 8
[73,525s][trace  ][os] active_processor_count: using static path -
configured processors: 8
[73,525s][trace  ][os] active_processor_count: sched_getaffinity processor
count: 8
proc: 8
...

Kind Regards, Thomas




On Fri, Jan 22, 2016 at 9:06 AM, David Holmes <david.holmes at oracle.com>
wrote:

> First a special thanks to Martin Buchholz for his input, feedback,
> critique and raising awareness of how non-simple this issue is.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
> Basic problem:
>   processors available for use <= processors online <= processors
> configured
>
> but we always returned the number of online processors.
>
> Solution is simple in its basic form: use sched_getaffinity to get the
> scheduling affinity mask and count the number of available processors.
>
> Details are complicated by the desire to handle very large processor
> systems. See the bug report for lots of detailed discussions and references.
>
> Testing:
>  - new test that verifies behaviour when running under taskset
>  - diagnostic hook injection (UseNewCodeN) to enable testing of all code
> paths (one hook is left in for non-product to allow easy testing of the
> dynamic path)
>  - JPRT
>
> Compatability issues:
> - the system code we're using now is at least 5 years old so distro's
> older than that (which are not officially supported) may not work
> - anyone already running under a processor constrained environment (like
> Docker) and using availableProcessor() to "size" things, will find that
> size has now changed. We do not expect this to be a problem - on the
> contrary we expect Docker users to want the new behaviour.
>
> Thanks,
> David
>

From thomas.stuefe at gmail.com  Fri Jan 22 09:29:37 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 22 Jan 2016 10:29:37 +0100
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
Message-ID: <CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>

On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> I may be doing this wrong, but I do not get this to work for me (ubuntu
> 14.4).
>
> I built hs-rt with your patch. I am running a simple loop with
> Runtime.availableProcessors(). I change affinity with taskset and would
> expect output to change, but nothing changes.
>
> java command line: ../images/jdk/bin/java -Xlog:os=trace test
> taskset command:  taskset -p 0x1 <pid>
>
> Output:
>
> proc: 8
> [73,525s][trace  ][os] active_processor_count: using static path -
> configured processors: 8
> [73,525s][trace  ][os] active_processor_count: sched_getaffinity processor
> count: 8
> proc: 8
> ...
>
> Kind Regards, Thomas
>
>
>
I found that if I change:

 if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {

to

 if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {

it works.

Manpage on sched_getaffinity() states that "If pid is zero, then the mask
of the calling process is returned." but seems that does not work.

Kind Regards, Thomas

ps.  I am happy you introduced the "os" log tag, now I can use this for
AIX-specific logging without having to change shared files :-)




>
>
> On Fri, Jan 22, 2016 at 9:06 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> First a special thanks to Martin Buchholz for his input, feedback,
>> critique and raising awareness of how non-simple this issue is.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>> Basic problem:
>>   processors available for use <= processors online <= processors
>> configured
>>
>> but we always returned the number of online processors.
>>
>> Solution is simple in its basic form: use sched_getaffinity to get the
>> scheduling affinity mask and count the number of available processors.
>>
>> Details are complicated by the desire to handle very large processor
>> systems. See the bug report for lots of detailed discussions and references.
>>
>> Testing:
>>  - new test that verifies behaviour when running under taskset
>>  - diagnostic hook injection (UseNewCodeN) to enable testing of all code
>> paths (one hook is left in for non-product to allow easy testing of the
>> dynamic path)
>>  - JPRT
>>
>> Compatability issues:
>> - the system code we're using now is at least 5 years old so distro's
>> older than that (which are not officially supported) may not work
>> - anyone already running under a processor constrained environment (like
>> Docker) and using availableProcessor() to "size" things, will find that
>> size has now changed. We do not expect this to be a problem - on the
>> contrary we expect Docker users to want the new behaviour.
>>
>> Thanks,
>> David
>>
>
>

From david.holmes at oracle.com  Fri Jan 22 12:17:17 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 22:17:17 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
	<CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
Message-ID: <56A21DCD.90806@oracle.com>

Hi Thomas,

On 22/01/2016 7:29 PM, Thomas St?fe wrote:
>
> On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     I may be doing this wrong, but I do not get this to work for me
>     (ubuntu 14.4).
>
>     I built hs-rt with your patch. I am running a simple loop with
>     Runtime.availableProcessors(). I change affinity with taskset and
>     would expect output to change, but nothing changes.
>
>     java command line: ../images/jdk/bin/java -Xlog:os=trace test
>     taskset command:  taskset -p 0x1 <pid>
>
>     Output:
>
>     proc: 8
>     [73,525s][trace  ][os] active_processor_count: using static path -
>     configured processors: 8
>     [73,525s][trace  ][os] active_processor_count: sched_getaffinity
>     processor count: 8
>     proc: 8
>     ...
>
>     Kind Regards, Thomas
>
>
>
> I found that if I change:
>
>   if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {
>
> to
>
>   if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {
>
> it works.
>
> Manpage on sched_getaffinity() states that "If pid is zero, then the
> mask of the calling process is returned." but seems that does not work.

Later manpages changed that to be "zero means the current thread" - see
the online manpage

http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html

sched_getaffinity is really a thread-API that takes a pid_t - which is 
confusing to say the least. Regardless if you change the affinity of the 
process using taskset then it should affect all threads in the process, 
so this seems to be a glibc and/or kernel bug :(

I will see if I can get a C program that shows which threads in a 
process see the updated mask. This is yet another complexity to 
something that should be very simple, that I could really do without!

Many thanks for the report.

David
-----

> Kind Regards, Thomas
>
> ps.  I am happy you introduced the "os" log tag, now I can use this for
> AIX-specific logging without having to change shared files :-)
>
>
>
>
>     On Fri, Jan 22, 2016 at 9:06 AM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         First a special thanks to Martin Buchholz for his input,
>         feedback, critique and raising awareness of how non-simple this
>         issue is.
>
>         bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>         webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
>         Basic problem:
>            processors available for use <= processors online <=
>         processors configured
>
>         but we always returned the number of online processors.
>
>         Solution is simple in its basic form: use sched_getaffinity to
>         get the scheduling affinity mask and count the number of
>         available processors.
>
>         Details are complicated by the desire to handle very large
>         processor systems. See the bug report for lots of detailed
>         discussions and references.
>
>         Testing:
>           - new test that verifies behaviour when running under taskset
>           - diagnostic hook injection (UseNewCodeN) to enable testing of
>         all code paths (one hook is left in for non-product to allow
>         easy testing of the dynamic path)
>           - JPRT
>
>         Compatability issues:
>         - the system code we're using now is at least 5 years old so
>         distro's older than that (which are not officially supported)
>         may not work
>         - anyone already running under a processor constrained
>         environment (like Docker) and using availableProcessor() to
>         "size" things, will find that size has now changed. We do not
>         expect this to be a problem - on the contrary we expect Docker
>         users to want the new behaviour.
>
>         Thanks,
>         David
>
>
>

From david.holmes at oracle.com  Fri Jan 22 12:21:48 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 22:21:48 +1000
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
	<CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
Message-ID: <56A21EDC.5050506@oracle.com>

On 22/01/2016 3:00 AM, Thomas St?fe wrote:
> Hi,
>
> On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com
> <mailto:kirk at kodewerk.com> <kirk at kodewerk.com
> <mailto:kirk at kodewerk.com>> wrote:
>
>
>     > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>     >
>     > On 19/01/2016 11:58 PM, Marcus Larsson wrote:
>     >> Hi,
>     >>
>     >> Please review the following patch to fix an issue in UL causing the VM
>     >> to crash during shutdown.
>     >>
>     >> The problem is that the static LogStdoutOutput is deinitialized before
>     >> the last use of it (G1 concurrent thread tries to log very late during
>     >> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
>     >> LogStderrOutput are deinitialized during the full lifetime of the VM. To
>     >
>     > I agree with Kim here - this seems like the "wrong" solution. If the G1 thread can log very late during VM shutdown then we could
>     > - move the logging "deinitialize" to later in the shutdown process (assuming the G1 threads won't continue to run right up to process termination); or
>     > - ensure the G1 threads have to terminate, or block, before the deinitialization
>
>     Can I ask a silly question? If the JVM is shutting down is there a
>     need to de-initialize logging?
>
>
> I wonder too. Why not let the logging live right to the end? Logging is
> useful in all life phases of the VM; if logging is disabled before
> initialization or after cleanup, if one does not see output one always
> wonders if logging is disabled or if we just did not hit the logging call.
>
> Instead of deleting or disabling the LogOutput objects, why not just
> flush them (to ensure they write all accumulated output) but let them
> live on? As far as I can see, all LogOutput childs are keeping file
> descriptors which get closed automatically once the process stops.
>
> Or am I missing something obvious?

There is an ideal (which we seem to get further and further from) that 
the JVM should be unloadable within a process. In that model everything 
we initialize we should "de-initialize" before termination. And when 
logging itself can depend on facilities that are themselves "torn down" 
during termination we can have problems in trying to log too late, just 
as we can trying to log too early.

David
------

> Kind Regards, Thomas
>
>     IME iit is highly unlikely that the loss of one or two GC log
>     records would make a difference in my use cases.
>
>     Kind regards,
>     Kirk
>
>

From david.holmes at oracle.com  Fri Jan 22 12:22:24 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 22:22:24 +1000
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
In-Reply-To: <56A1B1F5.8070707@oracle.com>
References: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
	<56A1B1F5.8070707@oracle.com>
Message-ID: <56A21F00.4000900@oracle.com>

PS. Don't forget copyright updates :)

On 22/01/2016 2:37 PM, David Holmes wrote:
> Hi Jiangli,
>
>> Please review the following improvements to
>> HashtableTextDump::get_num() and HashtableTextDump::corrupted_if()
>> described in JDK-8147500
>> <https://bugs.openjdk.java.net/browse/JDK-8147500>.
>>
>>  - The HashtableTextDump::get_num() is use to parse an integer value
>> from the input file. It should check for integer overflow and report
>> error without continuing.
>>  - The HashtableTextDump::corrupted_if() should take an additional
>> argument so caller can pass a meaningful error message.
>>
>> Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/
>
> As improvements on the existing code this seems fine.
>
> Thanks,
> David

From staffan.larsen at oracle.com  Fri Jan 22 12:25:35 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 22 Jan 2016 13:25:35 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <56A21EDC.5050506@oracle.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
	<CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
	<56A21EDC.5050506@oracle.com>
Message-ID: <22F22FB4-E722-49D9-BDEC-BD5C8FF0F7B9@oracle.com>


> On 22 jan. 2016, at 13:21, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 22/01/2016 3:00 AM, Thomas St?fe wrote:
>> Hi,
>> 
>> On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com> <kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com>> wrote:
>> 
>> 
>>    > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>    >
>>    > On 19/01/2016 11:58 PM, Marcus Larsson wrote:
>>    >> Hi,
>>    >>
>>    >> Please review the following patch to fix an issue in UL causing the VM
>>    >> to crash during shutdown.
>>    >>
>>    >> The problem is that the static LogStdoutOutput is deinitialized before
>>    >> the last use of it (G1 concurrent thread tries to log very late during
>>    >> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
>>    >> LogStderrOutput are deinitialized during the full lifetime of the VM. To
>>    >
>>    > I agree with Kim here - this seems like the "wrong" solution. If the G1 thread can log very late during VM shutdown then we could
>>    > - move the logging "deinitialize" to later in the shutdown process (assuming the G1 threads won't continue to run right up to process termination); or
>>    > - ensure the G1 threads have to terminate, or block, before the deinitialization
>> 
>>    Can I ask a silly question? If the JVM is shutting down is there a
>>    need to de-initialize logging?
>> 
>> 
>> I wonder too. Why not let the logging live right to the end? Logging is
>> useful in all life phases of the VM; if logging is disabled before
>> initialization or after cleanup, if one does not see output one always
>> wonders if logging is disabled or if we just did not hit the logging call.
>> 
>> Instead of deleting or disabling the LogOutput objects, why not just
>> flush them (to ensure they write all accumulated output) but let them
>> live on? As far as I can see, all LogOutput childs are keeping file
>> descriptors which get closed automatically once the process stops.
>> 
>> Or am I missing something obvious?
> 
> There is an ideal (which we seem to get further and further from) that the JVM should be unloadable within a process. In that model everything we initialize we should "de-initialize" before termination. And when logging itself can depend on facilities that are themselves "torn down" during termination we can have problems in trying to log too late, just as we can trying to log too early.

Cleaning up like this is important if the JVM is being run many time inside the same host process (think applets within a browser), but this is becoming much less common. I wonder if it works at all at this point.


> 
> David
> ------
> 
>> Kind Regards, Thomas
>> 
>>    IME iit is highly unlikely that the loss of one or two GC log
>>    records would make a difference in my use cases.
>> 
>>    Kind regards,
>>    Kirk
>> 
>> 


From vitalyd at gmail.com  Fri Jan 22 12:38:25 2016
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 22 Jan 2016 07:38:25 -0500
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A21DCD.90806@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
	<CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
	<56A21DCD.90806@oracle.com>
Message-ID: <CAHjP37FntfisGcoYAN+zGN+=Um4a0vpu0TZdRbTLP7AHdiYTFA@mail.gmail.com>

I don't think current thread represents current process, it represents the
current kernel thread :).  You can launch Java with taskset and then change
one of the thread's affinity masks at any time via sched_setaffinity,
including increasing number of usable CPUs (if nothing else constrains it).
If you want process mask you need to pass it the pid, but that may be
meaningless if other threads were later affinitized differently.

Also are we sure it's a good idea to change this API behavior?

On Friday, January 22, 2016, David Holmes <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 22/01/2016 7:29 PM, Thomas St?fe wrote:
>
>>
>> On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe <thomas.stuefe at gmail.com
>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>     Hi David,
>>
>>     I may be doing this wrong, but I do not get this to work for me
>>     (ubuntu 14.4).
>>
>>     I built hs-rt with your patch. I am running a simple loop with
>>     Runtime.availableProcessors(). I change affinity with taskset and
>>     would expect output to change, but nothing changes.
>>
>>     java command line: ../images/jdk/bin/java -Xlog:os=trace test
>>     taskset command:  taskset -p 0x1 <pid>
>>
>>     Output:
>>
>>     proc: 8
>>     [73,525s][trace  ][os] active_processor_count: using static path -
>>     configured processors: 8
>>     [73,525s][trace  ][os] active_processor_count: sched_getaffinity
>>     processor count: 8
>>     proc: 8
>>     ...
>>
>>     Kind Regards, Thomas
>>
>>
>>
>> I found that if I change:
>>
>>   if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {
>>
>> to
>>
>>   if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {
>>
>> it works.
>>
>> Manpage on sched_getaffinity() states that "If pid is zero, then the
>> mask of the calling process is returned." but seems that does not work.
>>
>
> Later manpages changed that to be "zero means the current thread" - see
> the online manpage
>
> http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html
>
> sched_getaffinity is really a thread-API that takes a pid_t - which is
> confusing to say the least. Regardless if you change the affinity of the
> process using taskset then it should affect all threads in the process, so
> this seems to be a glibc and/or kernel bug :(
>
> I will see if I can get a C program that shows which threads in a process
> see the updated mask. This is yet another complexity to something that
> should be very simple, that I could really do without!
>
> Many thanks for the report.
>
> David
> -----
>
> Kind Regards, Thomas
>>
>> ps.  I am happy you introduced the "os" log tag, now I can use this for
>> AIX-specific logging without having to change shared files :-)
>>
>>
>>
>>
>>     On Fri, Jan 22, 2016 at 9:06 AM, David Holmes
>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>>         First a special thanks to Martin Buchholz for his input,
>>         feedback, critique and raising awareness of how non-simple this
>>         issue is.
>>
>>         bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>         webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>>         Basic problem:
>>            processors available for use <= processors online <=
>>         processors configured
>>
>>         but we always returned the number of online processors.
>>
>>         Solution is simple in its basic form: use sched_getaffinity to
>>         get the scheduling affinity mask and count the number of
>>         available processors.
>>
>>         Details are complicated by the desire to handle very large
>>         processor systems. See the bug report for lots of detailed
>>         discussions and references.
>>
>>         Testing:
>>           - new test that verifies behaviour when running under taskset
>>           - diagnostic hook injection (UseNewCodeN) to enable testing of
>>         all code paths (one hook is left in for non-product to allow
>>         easy testing of the dynamic path)
>>           - JPRT
>>
>>         Compatability issues:
>>         - the system code we're using now is at least 5 years old so
>>         distro's older than that (which are not officially supported)
>>         may not work
>>         - anyone already running under a processor constrained
>>         environment (like Docker) and using availableProcessor() to
>>         "size" things, will find that size has now changed. We do not
>>         expect this to be a problem - on the contrary we expect Docker
>>         users to want the new behaviour.
>>
>>         Thanks,
>>         David
>>
>>
>>
>>

-- 
Sent from my phone

From david.holmes at oracle.com  Fri Jan 22 12:47:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Jan 2016 22:47:29 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <CAHjP37FntfisGcoYAN+zGN+=Um4a0vpu0TZdRbTLP7AHdiYTFA@mail.gmail.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
	<CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
	<56A21DCD.90806@oracle.com>
	<CAHjP37FntfisGcoYAN+zGN+=Um4a0vpu0TZdRbTLP7AHdiYTFA@mail.gmail.com>
Message-ID: <56A224E1.8070100@oracle.com>

On 22/01/2016 10:38 PM, Vitaly Davidovich wrote:
> I don't think current thread represents current process, it represents
> the current kernel thread :).  You can launch Java with taskset and then
> change one of the thread's affinity masks at any time via
> sched_setaffinity, including increasing number of usable CPUs (if
> nothing else constrains it).  If you want process mask you need to pass
> it the pid, but that may be meaningless if other threads were later
> affinitized differently.

I'm not trying to account for separate threads being individually 
modified via sched_setaffinity. If you use native code to do that then 
you are on your own. There is no way for an API like 
Runtime.availableProcesors to behave sensibly in that scenario.

If you taskset a running process then it is supposed to constrain all 
threads of the process.

But I'm not even trying to address the situation where dynamic changes 
occur (though I did expect it to work). The main use case to address is 
starting the JVM within a taskset/cgroup and have it report the correct 
number of available processors.

> Also are we sure it's a good idea to change this API behavior?

Most people expect it to return the actual number of processors 
available to the JVM - which in normal execution it does. But once 
tasksets/cgroups come into play it fails to do that. The Solaris version 
was changed years ago to address the same issue with processor sets - 
linux wasn't modified then because the mechanism and APIs on linux 
hadn't stabilized and no-one was asking for it.

Thanks,
David

> On Friday, January 22, 2016, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 22/01/2016 7:29 PM, Thomas St?fe wrote:
>
>
>         On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe
>         <thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>> wrote:
>
>              Hi David,
>
>              I may be doing this wrong, but I do not get this to work for me
>              (ubuntu 14.4).
>
>              I built hs-rt with your patch. I am running a simple loop with
>              Runtime.availableProcessors(). I change affinity with
>         taskset and
>              would expect output to change, but nothing changes.
>
>              java command line: ../images/jdk/bin/java -Xlog:os=trace test
>              taskset command:  taskset -p 0x1 <pid>
>
>              Output:
>
>              proc: 8
>              [73,525s][trace  ][os] active_processor_count: using static
>         path -
>              configured processors: 8
>              [73,525s][trace  ][os] active_processor_count:
>         sched_getaffinity
>              processor count: 8
>              proc: 8
>              ...
>
>              Kind Regards, Thomas
>
>
>
>         I found that if I change:
>
>            if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {
>
>         to
>
>            if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {
>
>         it works.
>
>         Manpage on sched_getaffinity() states that "If pid is zero, then the
>         mask of the calling process is returned." but seems that does
>         not work.
>
>
>     Later manpages changed that to be "zero means the current thread" - see
>     the online manpage
>
>     http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html
>
>     sched_getaffinity is really a thread-API that takes a pid_t - which
>     is confusing to say the least. Regardless if you change the affinity
>     of the process using taskset then it should affect all threads in
>     the process, so this seems to be a glibc and/or kernel bug :(
>
>     I will see if I can get a C program that shows which threads in a
>     process see the updated mask. This is yet another complexity to
>     something that should be very simple, that I could really do without!
>
>     Many thanks for the report.
>
>     David
>     -----
>
>         Kind Regards, Thomas
>
>         ps.  I am happy you introduced the "os" log tag, now I can use
>         this for
>         AIX-specific logging without having to change shared files :-)
>
>
>
>
>              On Fri, Jan 22, 2016 at 9:06 AM, David Holmes
>              <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>         wrote:
>
>                  First a special thanks to Martin Buchholz for his input,
>                  feedback, critique and raising awareness of how
>         non-simple this
>                  issue is.
>
>                  bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>                  webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
>                  Basic problem:
>                     processors available for use <= processors online <=
>                  processors configured
>
>                  but we always returned the number of online processors.
>
>                  Solution is simple in its basic form: use
>         sched_getaffinity to
>                  get the scheduling affinity mask and count the number of
>                  available processors.
>
>                  Details are complicated by the desire to handle very large
>                  processor systems. See the bug report for lots of detailed
>                  discussions and references.
>
>                  Testing:
>                    - new test that verifies behaviour when running under
>         taskset
>                    - diagnostic hook injection (UseNewCodeN) to enable
>         testing of
>                  all code paths (one hook is left in for non-product to
>         allow
>                  easy testing of the dynamic path)
>                    - JPRT
>
>                  Compatability issues:
>                  - the system code we're using now is at least 5 years
>         old so
>                  distro's older than that (which are not officially
>         supported)
>                  may not work
>                  - anyone already running under a processor constrained
>                  environment (like Docker) and using availableProcessor() to
>                  "size" things, will find that size has now changed. We
>         do not
>                  expect this to be a problem - on the contrary we expect
>         Docker
>                  users to want the new behaviour.
>
>                  Thanks,
>                  David
>
>
>
>
>
> --
> Sent from my phone

From vitalyd at gmail.com  Fri Jan 22 12:58:15 2016
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 22 Jan 2016 07:58:15 -0500
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A224E1.8070100@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
	<CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
	<56A21DCD.90806@oracle.com>
	<CAHjP37FntfisGcoYAN+zGN+=Um4a0vpu0TZdRbTLP7AHdiYTFA@mail.gmail.com>
	<56A224E1.8070100@oracle.com>
Message-ID: <CAHjP37Enr_oViU-Nwfj7ohxwtwL5QgUtQ=RPvzQYhhzRmeNbiA@mail.gmail.com>

On Friday, January 22, 2016, David Holmes <david.holmes at oracle.com> wrote:

> On 22/01/2016 10:38 PM, Vitaly Davidovich wrote:
>
>> I don't think current thread represents current process, it represents
>> the current kernel thread :).  You can launch Java with taskset and then
>> change one of the thread's affinity masks at any time via
>> sched_setaffinity, including increasing number of usable CPUs (if
>> nothing else constrains it).  If you want process mask you need to pass
>> it the pid, but that may be meaningless if other threads were later
>> affinitized differently.
>>
>
> I'm not trying to account for separate threads being individually modified
> via sched_setaffinity. If you use native code to do that then you are on
> your own. There is no way for an API like Runtime.availableProcesors to
> behave sensibly in that scenario.


Right, agreed.

>
> If you taskset a running process then it is supposed to constrain all
> threads of the process.
>
> But I'm not even trying to address the situation where dynamic changes
> occur (though I did expect it to work). The main use case to address is
> starting the JVM within a taskset/cgroup and have it report the correct
> number of available processors.


Ok.  I agree that 0 vs pid shouldn't matter there as all threads will
inherit the mask.  But, I don't see the harm in passing getpid() to be more
explicit; extra syscall but this shouldn't be a hot function in normal
applications.

>
> Also are we sure it's a good idea to change this API behavior?
>>
>
> Most people expect it to return the actual number of processors available
> to the JVM - which in normal execution it does. But once tasksets/cgroups
> come into play it fails to do that. The Solaris version was changed years
> ago to address the same issue with processor sets - linux wasn't modified
> then because the mechanism and APIs on linux hadn't stabilized and no-one
> was asking for it.


Yes but I think people using this API already know this limitation and may
be relying on it returning number of online CPUs.  I didn't know Solaris
takes processor sets into account.  At any rate, I think your proposal
makes sense but I'd worry it may break someone.  New method would be safer
and then you can actually query both bits of info using JDK code, # of
online CPUs and proc affinity mask.

$.02

>
> Thanks,
> David
>
> On Friday, January 22, 2016, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     On 22/01/2016 7:29 PM, Thomas St?fe wrote:
>>
>>
>>         On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe
>>         <thomas.stuefe at gmail.com
>>         <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>              Hi David,
>>
>>              I may be doing this wrong, but I do not get this to work for
>> me
>>              (ubuntu 14.4).
>>
>>              I built hs-rt with your patch. I am running a simple loop
>> with
>>              Runtime.availableProcessors(). I change affinity with
>>         taskset and
>>              would expect output to change, but nothing changes.
>>
>>              java command line: ../images/jdk/bin/java -Xlog:os=trace test
>>              taskset command:  taskset -p 0x1 <pid>
>>
>>              Output:
>>
>>              proc: 8
>>              [73,525s][trace  ][os] active_processor_count: using static
>>         path -
>>              configured processors: 8
>>              [73,525s][trace  ][os] active_processor_count:
>>         sched_getaffinity
>>              processor count: 8
>>              proc: 8
>>              ...
>>
>>              Kind Regards, Thomas
>>
>>
>>
>>         I found that if I change:
>>
>>            if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {
>>
>>         to
>>
>>            if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {
>>
>>         it works.
>>
>>         Manpage on sched_getaffinity() states that "If pid is zero, then
>> the
>>         mask of the calling process is returned." but seems that does
>>         not work.
>>
>>
>>     Later manpages changed that to be "zero means the current thread" -
>> see
>>     the online manpage
>>
>>     http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html
>>
>>     sched_getaffinity is really a thread-API that takes a pid_t - which
>>     is confusing to say the least. Regardless if you change the affinity
>>     of the process using taskset then it should affect all threads in
>>     the process, so this seems to be a glibc and/or kernel bug :(
>>
>>     I will see if I can get a C program that shows which threads in a
>>     process see the updated mask. This is yet another complexity to
>>     something that should be very simple, that I could really do without!
>>
>>     Many thanks for the report.
>>
>>     David
>>     -----
>>
>>         Kind Regards, Thomas
>>
>>         ps.  I am happy you introduced the "os" log tag, now I can use
>>         this for
>>         AIX-specific logging without having to change shared files :-)
>>
>>
>>
>>
>>              On Fri, Jan 22, 2016 at 9:06 AM, David Holmes
>>              <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>>         wrote:
>>
>>                  First a special thanks to Martin Buchholz for his input,
>>                  feedback, critique and raising awareness of how
>>         non-simple this
>>                  issue is.
>>
>>                  bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>                  webrev:
>> http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>>                  Basic problem:
>>                     processors available for use <= processors online <=
>>                  processors configured
>>
>>                  but we always returned the number of online processors.
>>
>>                  Solution is simple in its basic form: use
>>         sched_getaffinity to
>>                  get the scheduling affinity mask and count the number of
>>                  available processors.
>>
>>                  Details are complicated by the desire to handle very
>> large
>>                  processor systems. See the bug report for lots of
>> detailed
>>                  discussions and references.
>>
>>                  Testing:
>>                    - new test that verifies behaviour when running under
>>         taskset
>>                    - diagnostic hook injection (UseNewCodeN) to enable
>>         testing of
>>                  all code paths (one hook is left in for non-product to
>>         allow
>>                  easy testing of the dynamic path)
>>                    - JPRT
>>
>>                  Compatability issues:
>>                  - the system code we're using now is at least 5 years
>>         old so
>>                  distro's older than that (which are not officially
>>         supported)
>>                  may not work
>>                  - anyone already running under a processor constrained
>>                  environment (like Docker) and using availableProcessor()
>> to
>>                  "size" things, will find that size has now changed. We
>>         do not
>>                  expect this to be a problem - on the contrary we expect
>>         Docker
>>                  users to want the new behaviour.
>>
>>                  Thanks,
>>                  David
>>
>>
>>
>>
>>
>> --
>> Sent from my phone
>>
>

-- 
Sent from my phone

From rvansa at redhat.com  Fri Jan 22 12:59:09 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 22 Jan 2016 13:59:09 +0100
Subject: OptimizeStringConcat does not preallocate StringBuilder
Message-ID: <56A2279D.7030709@redhat.com>

Hi,

I have been analyzing memory allocations in an app and I've noticed that 
non-trivial amount of allocations come from StringBuilder growing its 
buffer. These came from simple toString() implementations that looked 
like string1 + "-" + string2 + "-" string3. In this case, the bytecode 
contains arg-less StringBuilder ctor which allocates 16-char array, 
which was insufficient here. On the appends, this buffer had to be 
expanded, causing allocations and copying. In the end, common 
StringBuilder.toString() was used, therefore triggering another 
allocation and copy to the immutable String.

I've observed this through JFR as TLAB allocations, so I assume that 
this is really happening - for some reason the allocations are not 
eliminated.

I was wondering whether in these simple cases (without a loop) there is 
any reason why the strings1-3 could not be retrieved before constructing 
the StringBuilder with proper sum of lengths of used strings.
Even better, in the end the code could call (currently non-existent) 
invalidateToString() that would check that the contents length equals 
the buffer length, and in this case call the copy-less String(value, 
true) constructor, resetting the SB's buffer in the end (so this would 
not endanger the immutability of String).

Is this just not-implemented-yet, or are there any reasons against this?

Thanks

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From aleksey.shipilev at oracle.com  Fri Jan 22 13:29:56 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 22 Jan 2016 16:29:56 +0300
Subject: OptimizeStringConcat does not preallocate StringBuilder
In-Reply-To: <56A2279D.7030709@redhat.com>
References: <56A2279D.7030709@redhat.com>
Message-ID: <56A22ED4.7060701@oracle.com>

On 01/22/2016 03:59 PM, Radim Vansa wrote:
> I was wondering whether in these simple cases (without a loop) there 
> is any reason why the strings1-3 could not be retrieved before 
> constructing the StringBuilder with proper sum of lengths of used 
> strings.

Actually, OptimizeStringConcat is supposed to do effectively that for
all-String concat, like string1 + "-" + string2 + "-" string3: pull the
argument lengths, figure out the final storage size, allocate it, copy
strings into it, and then invoke a copy-less String constructor,
materializing the String. This bypasses StringBuilder, so there is no
need for "preallocating" it.


> I've observed this through JFR as TLAB allocations, so I assume
> that? this is really happening - for some reason the allocations are
> not eliminated.

Note that you still have to allocate the backing storage for a final
String, which will manifest in (TLAB) allocations. I am not sure if
those allocations would be attributed to StringBuilder after
OptimizeStringConcat transformed the code. Also note that
OptimizeStringConcat is a C2 optimization, so if you happen to run the
code in C1, you will see the good ol' StringBuilder.


> Is this just not-implemented-yet, or are there any reasons against this?

OptimizeStringConcat implementation is quite complicated and fragile. It
might very well be that you've stepped on some issue in there. If you
really did, contact hotspot-compiler-dev with your test case!

N.B.: A carte-blanche way to deal with OptimizeStringConcat is to allow
runtime to select the appropriate code for String concatenation, rather
than pushing C2 to decipher and rewrite what javac had lowered the
concatenation into. JEP 280 "Indify String Concatenation" covers this,
and many other tricky corner cases:
  http://openjdk.java.net/jeps/280

Cheers,
-Aleksey


From rvansa at redhat.com  Fri Jan 22 15:39:47 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 22 Jan 2016 16:39:47 +0100
Subject: OptimizeStringConcat does not preallocate StringBuilder
In-Reply-To: <56A22ED4.7060701@oracle.com>
References: <56A2279D.7030709@redhat.com> <56A22ED4.7060701@oracle.com>
Message-ID: <56A24D43.3090302@redhat.com>

So I've probably used wrong term for the operation. I was thinking about 
the part in javac which generates the bytecode in the first place, and 
from what you describe, OptimizeStringConcat is at C2 level reverting 
this work. I should probably move my question to compiler-dev, although 
JEP 280 probably obsoletes it.

Thanks!

Radim

On 01/22/2016 02:29 PM, Aleksey Shipilev wrote:
> On 01/22/2016 03:59 PM, Radim Vansa wrote:
>> I was wondering whether in these simple cases (without a loop) there
>> is any reason why the strings1-3 could not be retrieved before
>> constructing the StringBuilder with proper sum of lengths of used
>> strings.
> Actually, OptimizeStringConcat is supposed to do effectively that for
> all-String concat, like string1 + "-" + string2 + "-" string3: pull the
> argument lengths, figure out the final storage size, allocate it, copy
> strings into it, and then invoke a copy-less String constructor,
> materializing the String. This bypasses StringBuilder, so there is no
> need for "preallocating" it.
>
>
>> I've observed this through JFR as TLAB allocations, so I assume
>> that? this is really happening - for some reason the allocations are
>> not eliminated.
> Note that you still have to allocate the backing storage for a final
> String, which will manifest in (TLAB) allocations. I am not sure if
> those allocations would be attributed to StringBuilder after
> OptimizeStringConcat transformed the code. Also note that
> OptimizeStringConcat is a C2 optimization, so if you happen to run the
> code in C1, you will see the good ol' StringBuilder.
>
>
>> Is this just not-implemented-yet, or are there any reasons against this?
> OptimizeStringConcat implementation is quite complicated and fragile. It
> might very well be that you've stepped on some issue in there. If you
> really did, contact hotspot-compiler-dev with your test case!
>
> N.B.: A carte-blanche way to deal with OptimizeStringConcat is to allow
> runtime to select the appropriate code for String concatenation, rather
> than pushing C2 to decipher and rewrite what javac had lowered the
> concatenation into. JEP 280 "Indify String Concatenation" covers this,
> and many other tricky corner cases:
>    http://openjdk.java.net/jeps/280
>
> Cheers,
> -Aleksey
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From chris.plummer at oracle.com  Fri Jan 22 16:08:21 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 22 Jan 2016 08:08:21 -0800
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <569CE6E1.1010105@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <569CB32F.7030504@oracle.com>
	<569CE6E1.1010105@oracle.com>
Message-ID: <56A253F5.2000700@oracle.com>

On 1/18/16 5:21 AM, Mikael Gerdin wrote:
> On 2016-01-18 10:41, Mikael Gerdin wrote:
>> Hi,
>>
>> On 2016-01-15 23:12, Coleen Phillimore wrote:
>>>
>>> Hi,
>>>
>>> I've read this change and it looks correct to me.  The 32/64 bit 
>>> natural
>>> alignment should be used for the vtable and itable embedded fields, and
>>> this change accomplishes this.
>>>
>>>
>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>> The only change is fixing SA to also no longer do the aligning:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/ 
>>>>
>>
>> In sharkTopLevelBlock.cpp there is a bit of code to perform the
>> alignment which you have removed from the other platforms, search for
>> "needs_aligning". I'm not sure if shark even builds but it might be
>> courteous to at least attempt to update the sources.
>>
>> It's interesting that PPC64 does not appear to need any change, but I
>> don't see any code to align up after loading the vtable length in the
>> PPC sources.
>
> I've just realized that this fix only changes the behavior on 32 bit 
> platforms, so PPC64 never needed it.
>
Hi Mikael,

Sorry, I missed your responses since I thought I was always getting cc'd.

You are correct that on 64-bit there is effectively no change. 
align_object_size() is a nop for 64-bit. My changes do include a diff 
for AARCH64, but it is to remove what is effectively dead code. The code 
is doing 64-bit alignment when the word size is 32-bit, but of course 
this never happens for AARCH64. I believe it was copied from the x86 
port to handle the 64-bit alignment on 32-bit archs.

thanks,

Chris
> /Mikael
>
>>
>> Otherwise the change looks good as far as my limited knowledge of this
>> can tell.
>>
>> /Mikael
>>
>>
>>>>
>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>> addressing them with these changes:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>> incorrect size and has no test
>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>> macros like align_object_size
>>>
>>> I am currently working on this bug because it is wrong to use
>>> align_object_size() for metadata.  Metadata should be naturally aligned
>>> and I'll verify it's the case in metaspace allocation code.
>>>
>>> Thanks to Mikael for the alert about SA code that copies this.  It 
>>> seems
>>> that the SA shouldn't report metadata sizes if that's also reported 
>>> with
>>> jcmd.  Maybe the jstat -classstats functionality that uses SA (which is
>>> wrong now) can be removed?  And why would someone use this on a core
>>> file?
>>>
>>>>
>>>> And just restating here why I think the removal of these
>>>> align_object_field references is safe:
>>>>
>>>> The argument to align_object_offset() is the offset in words, and it
>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>> boundary. Since the argument is in words, there is no concern with my
>>>> changes removing word alignment of something that is not already word
>>>> aligned. It must already be word aligned or the current implementation
>>>> would be broken.
>>>>
>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>> on 64-bit.
>>>
>>> It (align_object_offset) is actually wrong, but since the size of the
>>> objects are naturally aligned, I think it's better to not have some
>>> explicit alignment call.
>>>>
>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This is in
>>>> fact the goal of this change, so what remains is to show that 64-bit
>>>> alignment of the fields is not needed on 32-bit. Since all of the
>>>> fields for which alignment has been removed are 32-bit types, it is
>>>> safe to keep them 32-bit word aligned instead of making them 64-bit
>>>> aligned.
>>>>
>>>
>>> Agree.  This looks good.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ 
>>>>>
>>>>>
>>>>> A bit of background would help. The InstanceKlass object has a number
>>>>> of variable length fields that are laid out after the declared
>>>>> fields. When an InstanceKlass object is allocated, extra memory is
>>>>> allocated for it to leave room for these fields. The first three of
>>>>> these fields are vtable, itable, and nonstatic_oopmap. They are all
>>>>> arrays of HeapWord sized values, which means void* size, which means
>>>>> they only need 32-bit alignment on 32-bit systems. However, they have
>>>>> always been 64-bit aligned. This webrev removes the forced 64-bit
>>>>> alignment on 32-bit systems, saving footprint.
>>>>>
>>>>> This change affects all 32-bit platforms. It should have no net
>>>>> impact on 64-bit platforms since the fields remain (naturally) 64-bit
>>>>> aligned (unless of course I've introduced a bug). The intent is to
>>>>> not change what is done for 64-bit platforms.
>>>>>
>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>> just removes an "if" block where the condition should always have
>>>>> evaluated to false, so it should have no net affect.
>>>>>
>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>> there are any additional tests that should be run.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>
>>
>


From jiangli.zhou at oracle.com  Fri Jan 22 16:39:53 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 22 Jan 2016 08:39:53 -0800
Subject: RFR: 8147500: The HashtableTextDump::get_num() should check for
	integer overflow
In-Reply-To: <56A21F00.4000900@oracle.com>
References: <82FF1ADE-D51C-41AB-9089-17F7B4DB6903@oracle.com>
	<56A1B1F5.8070707@oracle.com> <56A21F00.4000900@oracle.com>
Message-ID: <2018C1BB-6DFD-4660-A796-9115CF649624@oracle.com>

Thank you, David!

> On Jan 22, 2016, at 4:22 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> PS. Don't forget copyright updates :)

Will update copyright before pushing.

Thanks!
Jiangli

> 
> On 22/01/2016 2:37 PM, David Holmes wrote:
>> Hi Jiangli,
>> 
>>> Please review the following improvements to
>>> HashtableTextDump::get_num() and HashtableTextDump::corrupted_if()
>>> described in JDK-8147500
>>> <https://bugs.openjdk.java.net/browse/JDK-8147500>.
>>> 
>>> - The HashtableTextDump::get_num() is use to parse an integer value
>>> from the input file. It should check for integer overflow and report
>>> error without continuing.
>>> - The HashtableTextDump::corrupted_if() should take an additional
>>> argument so caller can pass a meaningful error message.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jiangli/8147500/webrev.00/
>> 
>> As improvements on the existing code this seems fine.
>> 
>> Thanks,
>> David


From coleen.phillimore at oracle.com  Fri Jan 22 16:49:18 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 22 Jan 2016 11:49:18 -0500
Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass
	vtable, itable, and nonstatic_oopmap on 32-bit systems
In-Reply-To: <56A253F5.2000700@oracle.com>
References: <56620D85.8090204@oracle.com> <567861EA.6080109@oracle.com>
	<56996EC2.1020306@oracle.com> <569CB32F.7030504@oracle.com>
	<569CE6E1.1010105@oracle.com> <56A253F5.2000700@oracle.com>
Message-ID: <56A25D8E.9080608@oracle.com>



On 1/22/16 11:08 AM, Chris Plummer wrote:
> On 1/18/16 5:21 AM, Mikael Gerdin wrote:
>> On 2016-01-18 10:41, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> On 2016-01-15 23:12, Coleen Phillimore wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've read this change and it looks correct to me.  The 32/64 bit 
>>>> natural
>>>> alignment should be used for the vtable and itable embedded fields, 
>>>> and
>>>> this change accomplishes this.
>>>>
>>>>
>>>> On 12/21/15 3:32 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> I'm doing a bit of a reset on this thread. I've updated the webrev.
>>>>> The only change is fixing SA to also no longer do the aligning:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.03/webrev.hotspot/ 
>>>>>
>>>
>>> In sharkTopLevelBlock.cpp there is a bit of code to perform the
>>> alignment which you have removed from the other platforms, search for
>>> "needs_aligning". I'm not sure if shark even builds but it might be
>>> courteous to at least attempt to update the sources.
>>>
>>> It's interesting that PPC64 does not appear to need any change, but I
>>> don't see any code to align up after loading the vtable length in the
>>> PPC sources.
>>
>> I've just realized that this fix only changes the behavior on 32 bit 
>> platforms, so PPC64 never needed it.
>>
> Hi Mikael,
>
> Sorry, I missed your responses since I thought I was always getting cc'd.
>
> You are correct that on 64-bit there is effectively no change. 
> align_object_size() is a nop for 64-bit. My changes do include a diff 
> for AARCH64, but it is to remove what is effectively dead code. The 
> code is doing 64-bit alignment when the word size is 32-bit, but of 
> course this never happens for AARCH64. I believe it was copied from 
> the x86 port to handle the 64-bit alignment on 32-bit archs.

align_object_offset is 64 bits and a nop on 64 bit platforms. 
align_object_size uses ObjectAlignmentInBytes - I will have an RFR to 
fix this based on Chris's change once the repositories are not frozen.

Coleen

>
> thanks,
>
> Chris
>> /Mikael
>>
>>>
>>> Otherwise the change looks good as far as my limited knowledge of this
>>> can tell.
>>>
>>> /Mikael
>>>
>>>
>>>>>
>>>>> I've also filed the following CRs for pre-existing bugs instead of
>>>>> addressing them with these changes:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145627 -
>>>>>     sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the
>>>>> incorrect size and has no test
>>>>> https://bugs.openjdk.java.net/browse/JDK-8145628
>>>>> hotspot metadata classes shouldn't use HeapWordSize or heap related
>>>>> macros like align_object_size
>>>>
>>>> I am currently working on this bug because it is wrong to use
>>>> align_object_size() for metadata.  Metadata should be naturally 
>>>> aligned
>>>> and I'll verify it's the case in metaspace allocation code.
>>>>
>>>> Thanks to Mikael for the alert about SA code that copies this.  It 
>>>> seems
>>>> that the SA shouldn't report metadata sizes if that's also reported 
>>>> with
>>>> jcmd.  Maybe the jstat -classstats functionality that uses SA 
>>>> (which is
>>>> wrong now) can be removed?  And why would someone use this on a core
>>>> file?
>>>>
>>>>>
>>>>> And just restating here why I think the removal of these
>>>>> align_object_field references is safe:
>>>>>
>>>>> The argument to align_object_offset() is the offset in words, and it
>>>>> returns the offset in words after aligning to a HeapWordsPerLong
>>>>> boundary. Since the argument is in words, there is no concern with my
>>>>> changes removing word alignment of something that is not already word
>>>>> aligned. It must already be word aligned or the current 
>>>>> implementation
>>>>> would be broken.
>>>>>
>>>>> Since HeapWordsPerLong is 1 on 64-bit, the end result is that
>>>>> align_object_offset() is a no-op, so the removal is having no impact
>>>>> on 64-bit.
>>>>
>>>> It (align_object_offset) is actually wrong, but since the size of the
>>>> objects are naturally aligned, I think it's better to not have some
>>>> explicit alignment call.
>>>>>
>>>>> On 32-bit HeapWordsPerLong is 2, so the end result is that the offset
>>>>> will remain 32-bit word aligned, and not be 64-bit aligned. This 
>>>>> is in
>>>>> fact the goal of this change, so what remains is to show that 64-bit
>>>>> alignment of the fields is not needed on 32-bit. Since all of the
>>>>> fields for which alignment has been removed are 32-bit types, it is
>>>>> safe to keep them 32-bit word aligned instead of making them 64-bit
>>>>> aligned.
>>>>>
>>>>
>>>> Agree.  This looks good.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> On 12/4/15 2:02 PM, Chris Plummer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608
>>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ 
>>>>>>
>>>>>>
>>>>>> A bit of background would help. The InstanceKlass object has a 
>>>>>> number
>>>>>> of variable length fields that are laid out after the declared
>>>>>> fields. When an InstanceKlass object is allocated, extra memory is
>>>>>> allocated for it to leave room for these fields. The first three of
>>>>>> these fields are vtable, itable, and nonstatic_oopmap. They are all
>>>>>> arrays of HeapWord sized values, which means void* size, which means
>>>>>> they only need 32-bit alignment on 32-bit systems. However, they 
>>>>>> have
>>>>>> always been 64-bit aligned. This webrev removes the forced 64-bit
>>>>>> alignment on 32-bit systems, saving footprint.
>>>>>>
>>>>>> This change affects all 32-bit platforms. It should have no net
>>>>>> impact on 64-bit platforms since the fields remain (naturally) 
>>>>>> 64-bit
>>>>>> aligned (unless of course I've introduced a bug). The intent is to
>>>>>> not change what is done for 64-bit platforms.
>>>>>>
>>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It
>>>>>> just removes an "if" block where the condition should always have
>>>>>> evaluated to false, so it should have no net affect.
>>>>>>
>>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think
>>>>>> there are any additional tests that should be run.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>
>>>>
>>>
>>
>


From thomas.stuefe at gmail.com  Sat Jan 23 09:14:26 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 23 Jan 2016 10:14:26 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <22F22FB4-E722-49D9-BDEC-BD5C8FF0F7B9@oracle.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
	<CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
	<56A21EDC.5050506@oracle.com>
	<22F22FB4-E722-49D9-BDEC-BD5C8FF0F7B9@oracle.com>
Message-ID: <CAA-vtUy94FVyzauuxBgAwPuSW8Txbroz0tw-mLUdSoHRyHvHeA@mail.gmail.com>

Hi Staffan,

On Fri, Jan 22, 2016 at 1:25 PM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:

>
>
>
> Cleaning up like this is important if the JVM is being run many time
> inside the same host process (think applets within a browser), but this is
> becoming much less common. I wonder if it works at all at this point.
>
>
>
I did not know that was even a thing. I would have thought that there are
many process global resources which are monopolised by the VM - though
right off the bat I only can think of signal handling, and Windows as the
main desktop platform has stack-based exception handling which could
coexist with other VMs.

But I would think this could never work on Unix-like platforms, or?

Kind Regards, Thomas

From thomas.stuefe at gmail.com  Sat Jan 23 09:18:21 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 23 Jan 2016 10:18:21 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <56A21EDC.5050506@oracle.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
	<CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
	<56A21EDC.5050506@oracle.com>
Message-ID: <CAA-vtUysNBf1fpGVZpG_o4AN+C3CadkxwgJ_ym1-PdDtNNT67Q@mail.gmail.com>

David,

On Fri, Jan 22, 2016 at 1:21 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 22/01/2016 3:00 AM, Thomas St?fe wrote:
>
>> Hi,
>>
>> On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com> <kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com>> wrote:
>>
>>
>>     > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>     >
>>     > On 19/01/2016 11:58 PM, Marcus Larsson wrote:
>>     >> Hi,
>>     >>
>>     >> Please review the following patch to fix an issue in UL causing
>> the VM
>>     >> to crash during shutdown.
>>     >>
>>     >> The problem is that the static LogStdoutOutput is deinitialized
>> before
>>     >> the last use of it (G1 concurrent thread tries to log very late
>> during
>>     >> VM shutdown). The solution is to make sure neither LogStdoutOutput
>> nor
>>     >> LogStderrOutput are deinitialized during the full lifetime of the
>> VM. To
>>     >
>>     > I agree with Kim here - this seems like the "wrong" solution. If
>> the G1 thread can log very late during VM shutdown then we could
>>     > - move the logging "deinitialize" to later in the shutdown process
>> (assuming the G1 threads won't continue to run right up to process
>> termination); or
>>     > - ensure the G1 threads have to terminate, or block, before the
>> deinitialization
>>
>>     Can I ask a silly question? If the JVM is shutting down is there a
>>     need to de-initialize logging?
>>
>>
>> I wonder too. Why not let the logging live right to the end? Logging is
>> useful in all life phases of the VM; if logging is disabled before
>> initialization or after cleanup, if one does not see output one always
>> wonders if logging is disabled or if we just did not hit the logging call.
>>
>> Instead of deleting or disabling the LogOutput objects, why not just
>> flush them (to ensure they write all accumulated output) but let them
>> live on? As far as I can see, all LogOutput childs are keeping file
>> descriptors which get closed automatically once the process stops.
>>
>> Or am I missing something obvious?
>>
>
> There is an ideal (which we seem to get further and further from) that the
> JVM should be unloadable within a process. In that model everything we
> initialize we should "de-initialize" before termination. And when logging
> itself can depend on facilities that are themselves "torn down" during
> termination we can have problems in trying to log too late, just as we can
> trying to log too early.
>
>
Ok, I agree with you. Both on the long term goal of being unloadable and
that the logging system needs other subsystems (e.g thread locals) which
need to be life too.

Thomas

David
> ------
>
>
> Kind Regards, Thomas
>>
>>     IME iit is highly unlikely that the loss of one or two GC log
>>     records would make a difference in my use cases.
>>
>>     Kind regards,
>>     Kirk
>>
>>
>>

From kirk.pepperdine at gmail.com  Sat Jan 23 10:42:19 2016
From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com)
Date: Sat, 23 Jan 2016 11:42:19 +0100
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <CAA-vtUysNBf1fpGVZpG_o4AN+C3CadkxwgJ_ym1-PdDtNNT67Q@mail.gmail.com>
References: <569E40FF.9070003@oracle.com> <569F0B12.9060308@oracle.com>
	<7B4D9B72-6AB4-4749-A1A7-4C410CB05B40@kodewerk.com>
	<CAA-vtUx8_9X=pEXkvZ4Fmfp6sXq6cq58vhBpTz3RygbT0D5WHQ@mail.gmail.com>
	<56A21EDC.5050506@oracle.com>
	<CAA-vtUysNBf1fpGVZpG_o4AN+C3CadkxwgJ_ym1-PdDtNNT67Q@mail.gmail.com>
Message-ID: <3EDA8CB5-7BDA-4BDD-9D17-7EEF3911A999@gmail.com>

>>> 
>>> Or am I missing something obvious?
>>> 
>> 
>> There is an ideal (which we seem to get further and further from) that the
>> JVM should be unloadable within a process. In that model everything we
>> initialize we should "de-initialize" before termination. And when logging
>> itself can depend on facilities that are themselves "torn down" during
>> termination we can have problems in trying to log too late, just as we can
>> trying to log too early.

Interesting? Thanks for the explanation.
>> 
>> 
> Ok, I agree with you. Both on the long term goal of being unloadable and
> that the logging system needs other subsystems (e.g thread locals) which
> need to be life too.

I have generally found that at a certain depth you cannot avoid circular dependencies. If everything depends on logging and logging depends on anything?.

Regards,
Kirk


From david.holmes at oracle.com  Sun Jan 24 21:16:27 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Jan 2016 07:16:27 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A224E1.8070100@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
	<CAA-vtUwNQAGfvZ+t438qn+Gc=0QvME5iJXz4i42dghQ=4VrA=w@mail.gmail.com>
	<CAA-vtUxWvb8khDgk-mMH12b75XfF1CP1sZ1m4JHmjMWhnKYQdQ@mail.gmail.com>
	<56A21DCD.90806@oracle.com>
	<CAHjP37FntfisGcoYAN+zGN+=Um4a0vpu0TZdRbTLP7AHdiYTFA@mail.gmail.com>
	<56A224E1.8070100@oracle.com>
Message-ID: <56A53F2B.20608@oracle.com>

On 22/01/2016 10:47 PM, David Holmes wrote:
> On 22/01/2016 10:38 PM, Vitaly Davidovich wrote:
>> I don't think current thread represents current process, it represents
>> the current kernel thread :).  You can launch Java with taskset and then
>> change one of the thread's affinity masks at any time via
>> sched_setaffinity, including increasing number of usable CPUs (if
>> nothing else constrains it).  If you want process mask you need to pass
>> it the pid, but that may be meaningless if other threads were later
>> affinitized differently.
>
> I'm not trying to account for separate threads being individually
> modified via sched_setaffinity. If you use native code to do that then
> you are on your own. There is no way for an API like
> Runtime.availableProcesors to behave sensibly in that scenario.
>
> If you taskset a running process then it is supposed to constrain all
> threads of the process.

Actually - against all reasonable expectations IMHO - it doesn't. If you 
want taskset to change the affinity for all threads in a running process 
then you need the -a/--all option. Otherwise I presume it will only 
change the affinity of the main process thread - which is not used to 
launch the JVM - which is why changing the code to pass the pid from 
getpid() to sched_getaffinity "fixes" things.

So no need to change anything - the VM code is working as intended/expected.

Thanks,
David
-----


> But I'm not even trying to address the situation where dynamic changes
> occur (though I did expect it to work). The main use case to address is
> starting the JVM within a taskset/cgroup and have it report the correct
> number of available processors.
>
>> Also are we sure it's a good idea to change this API behavior?
>
> Most people expect it to return the actual number of processors
> available to the JVM - which in normal execution it does. But once
> tasksets/cgroups come into play it fails to do that. The Solaris version
> was changed years ago to address the same issue with processor sets -
> linux wasn't modified then because the mechanism and APIs on linux
> hadn't stabilized and no-one was asking for it.
>
> Thanks,
> David
>
>> On Friday, January 22, 2016, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     On 22/01/2016 7:29 PM, Thomas St?fe wrote:
>>
>>
>>         On Fri, Jan 22, 2016 at 10:21 AM, Thomas St?fe
>>         <thomas.stuefe at gmail.com
>>         <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>              Hi David,
>>
>>              I may be doing this wrong, but I do not get this to work
>> for me
>>              (ubuntu 14.4).
>>
>>              I built hs-rt with your patch. I am running a simple loop
>> with
>>              Runtime.availableProcessors(). I change affinity with
>>         taskset and
>>              would expect output to change, but nothing changes.
>>
>>              java command line: ../images/jdk/bin/java -Xlog:os=trace
>> test
>>              taskset command:  taskset -p 0x1 <pid>
>>
>>              Output:
>>
>>              proc: 8
>>              [73,525s][trace  ][os] active_processor_count: using static
>>         path -
>>              configured processors: 8
>>              [73,525s][trace  ][os] active_processor_count:
>>         sched_getaffinity
>>              processor count: 8
>>              proc: 8
>>              ...
>>
>>              Kind Regards, Thomas
>>
>>
>>
>>         I found that if I change:
>>
>>            if (sched_getaffinity(0, cpus_size, cpus_p) == 0) {
>>
>>         to
>>
>>            if (sched_getaffinity(getpid(), cpus_size, cpus_p) == 0) {
>>
>>         it works.
>>
>>         Manpage on sched_getaffinity() states that "If pid is zero,
>> then the
>>         mask of the calling process is returned." but seems that does
>>         not work.
>>
>>
>>     Later manpages changed that to be "zero means the current thread"
>> - see
>>     the online manpage
>>
>>     http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html
>>
>>     sched_getaffinity is really a thread-API that takes a pid_t - which
>>     is confusing to say the least. Regardless if you change the affinity
>>     of the process using taskset then it should affect all threads in
>>     the process, so this seems to be a glibc and/or kernel bug :(
>>
>>     I will see if I can get a C program that shows which threads in a
>>     process see the updated mask. This is yet another complexity to
>>     something that should be very simple, that I could really do without!
>>
>>     Many thanks for the report.
>>
>>     David
>>     -----
>>
>>         Kind Regards, Thomas
>>
>>         ps.  I am happy you introduced the "os" log tag, now I can use
>>         this for
>>         AIX-specific logging without having to change shared files :-)
>>
>>
>>
>>
>>              On Fri, Jan 22, 2016 at 9:06 AM, David Holmes
>>              <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>>         wrote:
>>
>>                  First a special thanks to Martin Buchholz for his input,
>>                  feedback, critique and raising awareness of how
>>         non-simple this
>>                  issue is.
>>
>>                  bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>                  webrev:
>> http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>>                  Basic problem:
>>                     processors available for use <= processors online <=
>>                  processors configured
>>
>>                  but we always returned the number of online processors.
>>
>>                  Solution is simple in its basic form: use
>>         sched_getaffinity to
>>                  get the scheduling affinity mask and count the number of
>>                  available processors.
>>
>>                  Details are complicated by the desire to handle very
>> large
>>                  processor systems. See the bug report for lots of
>> detailed
>>                  discussions and references.
>>
>>                  Testing:
>>                    - new test that verifies behaviour when running under
>>         taskset
>>                    - diagnostic hook injection (UseNewCodeN) to enable
>>         testing of
>>                  all code paths (one hook is left in for non-product to
>>         allow
>>                  easy testing of the dynamic path)
>>                    - JPRT
>>
>>                  Compatability issues:
>>                  - the system code we're using now is at least 5 years
>>         old so
>>                  distro's older than that (which are not officially
>>         supported)
>>                  may not work
>>                  - anyone already running under a processor constrained
>>                  environment (like Docker) and using
>> availableProcessor() to
>>                  "size" things, will find that size has now changed. We
>>         do not
>>                  expect this to be a problem - on the contrary we expect
>>         Docker
>>                  users to want the new behaviour.
>>
>>                  Thanks,
>>                  David
>>
>>
>>
>>
>>
>> --
>> Sent from my phone

From david.holmes at oracle.com  Mon Jan 25 02:04:50 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Jan 2016 12:04:50 +1000
Subject: RFR: 8146009: "pure virtual method called" with using new GC
	logging mechanism
In-Reply-To: <56A0CF5F.4050401@oracle.com>
References: <569E40FF.9070003@oracle.com> <56A0CF5F.4050401@oracle.com>
Message-ID: <56A582C2.4090409@oracle.com>

On 21/01/2016 10:30 PM, Marcus Larsson wrote:
> Updated webrev:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.01/
>
> Only LogConfiguration::initialize() and LogTagSet constructor now calls
> the stdout_output()/stderr_output() functions. Made the functions

When can the LogTagSet constructor be called before 
LogConfiguration::initialize()? And what impact does that have on the 
dependencies that the stdout_output()/stderr_output() functions have?

I still object to defining objects that never get cleaned up. It 
indicates we really don't know when the last logging can happen during 
VM shutdown, and so we don't know if it will work or fail, depending on 
other VM facilities used that may have already been shutdown.

Thanks,
David
-----


> private to prevent usages from other places. Also removed the previous
> output instances from LogFileStream.{c,h}pp which I forgot to do in the
> first patch.
>
> Thanks,
> Marcus
>
> On 01/19/2016 02:58 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to fix an issue in UL causing the VM
>> to crash during shutdown.
>>
>> The problem is that the static LogStdoutOutput is deinitialized before
>> the last use of it (G1 concurrent thread tries to log very late during
>> VM shutdown). The solution is to make sure neither LogStdoutOutput nor
>> LogStderrOutput are deinitialized during the full lifetime of the VM.
>> To accomplish this I've changed the storage from static objects to
>> static pointers to heap instances that are allocated & initialized on
>> first use [0]. These instances are never deleted and can always be
>> used. Also updated LogConfiguration::finalize to disable all file
>> outputs before deleting & freeing them.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146009
>>
>> Testing:
>> - local runs of the reproducer (500+ iterations without crashing)
>> - JPRT
>>
>> Thanks,
>> Marcus
>>
>> [0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
>

From ioi.lam at oracle.com  Mon Jan 25 03:49:00 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 24 Jan 2016 19:49:00 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A1763E.5030506@oracle.com>
References: <568F60E4.50609@oracle.com>
	<56904C26.1010207@oracle.com>	<569068ED.6070509@oracle.com>
	<56A1763E.5030506@oracle.com>
Message-ID: <56A59B2C.4010107@oracle.com>

Hi Max:

Looks good overall. Just some minor nits in the code, and a suggestion 
for the test.

classFileParser.cpp:

    copyright date


classLoaderData.cpp:

    wrong copyright date

    This comment is superfluous and can be removed.

    617   // It's OK to do safe points now (and we need to do that in JavaCalls::call_virtual)

systemDictionary.cpp:

    copyright date

    Remove the "else" here. These should be two independent "if" blocks
    (see ClassLoadingService::notify_class_loaded).
    1308     else if (log_is_enabled(Debug, classload)) {


nmethod.cpp:

    Remove "]":
    1317                   " unloadable], Method*(" INTPTR_FORMAT

klass.cpp:

    Remove [] and de-capitalize
    407         log_trace(classunload)("[Unlinking class (sibling) %s]",
    sibling->external_name());

globals.hpp:

    copyright date

ClassLoadUnloadTest.java:

    Testing for class unloading is tricky, so instead of rolling your
    own code to force class unloading, it's better to use the
    ClassUnloadCommon library.

    You have

       39     private static class ClassUnloadTestMain {
       40
       41         static String klass = "public class Empty {"
       42                   + " public void bigLoop(){}"
       43                   + " public String toString() { return
    \"nothing\"; } }";
       44
       45         public static volatile WeakReference<ByteCodeLoader>
    clweak;
       46         public static byte[] garbage;
       47
       48         public static void main(String... args) throws Exception {
       49             ByteCodeLoader cl = new ByteCodeLoader("Empty",
    InMemoryJavaCompiler.compile("Empty", klass));
       50             Class<?> c = cl.loadClass("Empty");
       51             Object o = c.newInstance();
       52             Method m = c.getMethod("bigLoop");
       53
       54             for ( int i=0; i<10001; i++){
       55                 m.invoke(o);
       56             }
       57
       58             clweak = new WeakReference<>(cl);
       59             cl = null; c = null; o = null; m = null;
       60             while(clweak.get() != null) {
       61                   garbage = new byte[8192];
       62                   System.gc();
       63             }
       64         }
       65     }

    Example of using ClassUnloadCommon can be found in
    hotspot/test/runtime/ClassUnload/UnloadTest.java

    public class UnloadTest {
         private static String className = "test.Empty";

         public static void main(String... args) throws Exception {
            run();
         }

         private static void run() throws Exception {
             final WhiteBox wb = WhiteBox.getWhiteBox();

    ClassUnloadCommon.failIf(wb.isClassAlive(className), "is not
    expected to be alive yet");

             ClassLoader cl = ClassUnloadCommon.newClassLoader();
             Class<?> c = cl.loadClass(className);
             Object o = c.newInstance();

    ClassUnloadCommon.failIf(!wb.isClassAlive(className), "should be
    live here");

             cl = null; c = null; o = null;
             ClassUnloadCommon.triggerUnloading();
    ClassUnloadCommon.failIf(wb.isClassAlive(className), "should have
    been unloaded");
         }
    }

    In your case, you can even remove the whitebox calls, and just use:

         private static void run() throws Exception {
             ClassLoader cl = ClassUnloadCommon.newClassLoader();
             Class<?> c = cl.loadClass(className);
             cl = null; c = null;

             ClassUnloadCommon.triggerUnloading();
         }

Thanks
- Ioi



On 1/21/16 4:22 PM, Max Ockner wrote:
> Hello all,
> This fix is now working again with the new changes incorporated.
>
> New webrev: http://cr.openjdk.java.net/~mockner/classload.03/
>
> I responded to all comments from Ioi and Coleen.
> My answer to Ioi's first question is option #2.
>
> Max
>
> On 1/8/2016 8:57 PM, Ioi Lam wrote:
>>
>>
>> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>>
>>> Hi, I have a bunch of comments that Ioi may have to help answer 
>>> because I had some questions about how the logging output comes out.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>>
>>>
>>> I think these can be UL-ized with less lines.  There's no need to 
>>> check if log_is_enabled here.
>>>
>>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>>> NULL) {*
>>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>>> *+ log->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> *!if (class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> What does this come out looking like?  It seems like it's going to 
>>> have [classloaderdata] in front of every line printed.  I think this 
>>> wants to be all one log line.
>>>
>>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>>> *)cld->class_loader()),*
>>> *+ cld->loader_name());*
>>> *+ *
>>> *+ if (string.not_null()) {*
>>> *+ log->print(": ");*
>>> *+ java_lang_String::print(string(), log);*
>>> *+ } *
>>> [classloaderdata] create class loader data <address>
>>> [classloaderdata]  for instance <addr> of some name
>>> [classloaderdata] :
>>> [classloaderdata] some string
>>>
>> The UL JEP says this in http://openjdk.java.net/jeps/158
>> "Goals ... Print line-at-a-time (no interleaving within same line)"
>>
>> log->print() is line-buffered. So all of these will be concatenated 
>> into the same buffer until the final log->cr() or log->print_cr(), at 
>> which point the whole line will be printed (with a single 
>> [classloaderdata] prefix).
>>
>> Here's an example:
>>
>> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
>> [0.780s][debug  ][classloaderdata] create class loader data 
>> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
>> sun/misc/Launcher$AppClassLoader: 
>> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>>
>>>
>>> You don't need to check log_is_enabled.  log_debug macro does that. 
>>> 2 instances in this file.
>>>
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>>> *+ } *
>>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>>
>>>
>>> Do you want this to come out with fewer lines?   Maybe the messages 
>>> should be collected in a tempStream and printed out at the end? LIke 
>>> in this file:
>>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>>
>>>
>> There's no need to use the tempStream, since the UL log already 
>> handles buffering.
>>
>> If my understanding of UL buffering is correct, I think the use of 
>> tempStream should be removed as a clean up.
>>
>>> There's a bunch of tty->print's still in this function.
>>>
>>> *+ Handle class_loader(loader_data->class_loader());*
>>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>>
>>> This could be simplified avoiding the Handle, which is not needed.
>>>
>>> *+ tty->print(" source: %s", 
>>> loader_data->class_loader()->klass()->external_name());*
>>>
>>> Is the loader_data argument to print_loading_log simply the 
>>> instanceKLass::_class_loader_data field?  In which case you can 
>>> remove the argument and have:
>>>
>>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>>> *
>>>
>> The original code (from classFileParser.cpp) is this:
>>
>>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
>> _loader_data->class_loader()->klass()->external_name());
>>
>> I suppose _loader_data->class_loader() in that context should be 
>> exactly the same as class_loader() inside the 
>> InstanceKlass::print_loading_log function, so your suggestion should 
>> work.
>>
>>> Obviously not to tty.
>>
>> You're right. The "tty->print" should be changed to log->print in 
>> InstanceKlass::print_loading_log. What I don't understand is why the 
>> output looks just fine.
>>
>> I never noticed these during my testing because the lines that use 
>> tty->print are uncommon and did not show up. I'll try to come up with 
>> a test case (I think it has something to do with reflection proxies 
>> ...).
>>
>>
>> Thanks
>> - Ioi
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>>
>>>
>>> This one can be condensed also
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>>> }
>>>
>>> to
>>>
>>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>>
>>> * 
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>>
>>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>>> his previous mail.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>>
>>>
>>> The return value 'ret' isn't used.  Either return an error if it 
>>> returns and error (what errors does it return?) or don't have 'ret'.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>>
>>>
>>> Test looks great to me!
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>>  151         checkFor("[classunload]", "[Unloading class");
>>>
>>> Can this be:
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>>> "[classunload]", "[Unloading class");
>>>
>>> To not start a new process?
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>>> Hello,
>>>> Please review this unified logging conversion for several related 
>>>> flags in the class loading system.
>>>>
>>>> Bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>>> classloaderdata)
>>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>>
>>>> Summary:
>>>>
>>>> There are two separate issues here. Originally Ioi and I began 
>>>> working on these fixes in parallel, but eventually it became 
>>>> obvious that the classload and classunload tags needed to be 
>>>> implemented together. This change is a combination of Ioi's change 
>>>> for 8079408 and my change for 8142506.
>>>>
>>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level debug (one level of verbosity up from info)
>>>>
>>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level trace (converted from uses of WizardMode)
>>>>
>>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>>
>>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>>> effected the implementation of "-verbose:class"
>>>>
>>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>>
>>>> If you have questions about the updates to the classloading log, 
>>>> Ioi can give a better answer than I can.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>
>>
>


From thomas.stuefe at gmail.com  Mon Jan 25 09:18:34 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Jan 2016 10:18:34 +0100
Subject: (ping) RFR(xs): 8147510: [windows] no text locations shown for
	register info in hs-err file
Message-ID: <CAA-vtUwGyxjxHQQDhRP=eT-Tc-g+Y=vYMY-2oXcXdNsA9Y37qA@mail.gmail.com>

Hi all,

could I please have a review and a sponsor? This is a small fix.

Thanks and Kind Regards, Thomas

On Wed, Jan 20, 2016 at 8:53 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> May I please have a review and a sponsor?
>
> Thank you!
>
> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi,
>>
>> could I please have reviews and a sponsor for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>
>> When we print register to memory info in hs-err file, text addresses are
>> not resolved on windows like on other platforms:
>>
>> "RCX=0x000000005efa0000 is an unknown value"
>>
>> This fix changes this (the same way it is implemented on other platforms):
>>
>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>> 0"
>>
>> Please note that this printout and the code behind it could be improved
>> and cleaned up a lot. For instance, I know that using an on-stack buffer in
>> os::find() is not the best implementation here. But I wanted a minimal
>> change. For the follow-up work, I opened a new bug:
>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>
>> Thanks & Regards, Thomas
>>
>>
>>
>>
>

From thomas.stuefe at gmail.com  Mon Jan 25 09:30:50 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Jan 2016 10:30:50 +0100
Subject: (ping) RFR(xs): 8146905 - cleanup ostream, staticBufferStream
Message-ID: <CAA-vtUx1gO9rVMW8hFpYC1wXmur2V4s_cUmUQ1HUyv_Uzcn7mA@mail.gmail.com>

Hi all,

I would still like a second review and a sponsor on this one.

This is both a cleanup (Bug https://bugs.openjdk.java.net/browse/JDK-8146905)
and a fix for (https://bugs.openjdk.java.net/browse/JDK-8146905): it only
affects the stream used for hs_err files, so its effect on the rest of the
VM is limited.

Current webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.01/webrev/

Thanks and Regards, Thomas



On Wed, Jan 20, 2016 at 10:29 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Thank you Volker!
>
> Still need a second reviewer, and once hs-rt is open again I'll need a
> sponsor too.
>
> Kind Regards, Thomas
>
> On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Thomas,
>>
>> thanks for doing this nice cleanup.
>>
>> The change looks good. Can you please just adapt the comment at line
>> 987 and remove the reference to staticBufferStream from there as well.
>>
>> Regards,
>> Volker
>>
>>
>> On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>> > May I please have a review for this? Thanks!
>> >
>> > On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>> > wrote:
>> >
>> >> Dear all,
>> >>
>> >> please take a look at this small cleanup of ostream.
>> >>
>> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
>> >> webrev:
>> >>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>> >>
>> >> Basically, it gets rid of the staticBufferStream class by moving its
>> one
>> >> feature up to the parent outputStream class:
>> >>
>> >> When printing the error log in vmError.cpp, we want to use as little
>> stack
>> >> space as possible. outputStream class uses on-stack buffers to assemble
>> >> snprintf functions. So, staticBufferStream was introduced as a child of
>> >> outputStream which overwrites the print functions and makes them use a
>> >> caller provided buffer. It then delegates the real writing to a
>> connected
>> >> stream object.
>> >>
>> >> The problem with that approach is that this is not a good fit for a
>> child
>> >> class.Not all operations possible with outputStream are cleanly
>> delegated
>> >> to the connected stream class, so a staticBufferStream behaves
>> sometimes
>> >> differently from all other streams (see e.g. JDK-8145410, which will be
>> >> automatically fixed with this change too).
>> >>
>> >> Another problem is that this delegation model leads to some code
>> >> duplication, because all print() methods of outputStream are
>> practically
>> >> duplicated in staticBufferStream.
>> >>
>> >> Another cosmetic note is that all other child classes of outputStream
>> >> (bufferedStream, stringStream, fileStream...) are specializations in
>> term
>> >> of log destination, not internal behaviour.
>> >>
>> >> Note that I implemented this in a very simple way without using
>> templates,
>> >> because I wanted to keep the changes as small as possible.
>> >>
>> >> Kind Regards, Thomas
>> >>
>>
>
>

From coleen.phillimore at oracle.com  Mon Jan 25 19:58:22 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 25 Jan 2016 14:58:22 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A1763E.5030506@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
Message-ID: <56A67E5E.3030208@oracle.com>


Hi Max,

This looks pretty good.  It's a large change!  A couple of comments:

http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html

As Harold pointed out earlier this change should check for 'else'.

*!if (_log_is_enabled(Info, classload)_) {*
*!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
}  else
*+ if (log_is_enabled(Debug, classload)) {*
*+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
}

http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/memory/filemap.cpp.udiff.html

Doesn't this need to have a log_trace(classload)("...") in the three 
places you removed the conditional TraceClassLoading && Verbose?

Or did you and Ioi decide to not output anything for -Xlog:classload ?

http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/runtime/arguments.cpp.udiff.html

Doesn't the copyright go the wrong way?  Looks like it's updated to 2015 
from 2016?

It would be nice if the alias table lines up wrt to the semicolons.

http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/services/classLoadingService.cpp.udiff.html

This is inconsistent.  I think in 
ClassLoadingService::reset_trace_class_unloading, don't have the return 
code 'ret' that you don't use for anything.

That's all,  These are pretty minor but I think I'd like to see the 
final change.

Thanks!
Coleen

On 1/21/16 7:22 PM, Max Ockner wrote:
> Hello all,
> This fix is now working again with the new changes incorporated.
>
> New webrev: http://cr.openjdk.java.net/~mockner/classload.03/
>
> I responded to all comments from Ioi and Coleen.
> My answer to Ioi's first question is option #2.
>
> Max
>
> On 1/8/2016 8:57 PM, Ioi Lam wrote:
>>
>>
>> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>>
>>> Hi, I have a bunch of comments that Ioi may have to help answer 
>>> because I had some questions about how the logging output comes out.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>>
>>>
>>> I think these can be UL-ized with less lines.  There's no need to 
>>> check if log_is_enabled here.
>>>
>>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>>> NULL) {*
>>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>>> *+ log->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> *!if (class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> What does this come out looking like?  It seems like it's going to 
>>> have [classloaderdata] in front of every line printed.  I think this 
>>> wants to be all one log line.
>>>
>>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>>> *)cld->class_loader()),*
>>> *+ cld->loader_name());*
>>> *+ *
>>> *+ if (string.not_null()) {*
>>> *+ log->print(": ");*
>>> *+ java_lang_String::print(string(), log);*
>>> *+ } *
>>> [classloaderdata] create class loader data <address>
>>> [classloaderdata]  for instance <addr> of some name
>>> [classloaderdata] :
>>> [classloaderdata] some string
>>>
>> The UL JEP says this in http://openjdk.java.net/jeps/158
>> "Goals ... Print line-at-a-time (no interleaving within same line)"
>>
>> log->print() is line-buffered. So all of these will be concatenated 
>> into the same buffer until the final log->cr() or log->print_cr(), at 
>> which point the whole line will be printed (with a single 
>> [classloaderdata] prefix).
>>
>> Here's an example:
>>
>> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
>> [0.780s][debug  ][classloaderdata] create class loader data 
>> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
>> sun/misc/Launcher$AppClassLoader: 
>> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>>
>>>
>>> You don't need to check log_is_enabled.  log_debug macro does that. 
>>> 2 instances in this file.
>>>
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>>> *+ } *
>>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>>
>>>
>>> Do you want this to come out with fewer lines?   Maybe the messages 
>>> should be collected in a tempStream and printed out at the end? LIke 
>>> in this file:
>>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>>
>>>
>> There's no need to use the tempStream, since the UL log already 
>> handles buffering.
>>
>> If my understanding of UL buffering is correct, I think the use of 
>> tempStream should be removed as a clean up.
>>
>>> There's a bunch of tty->print's still in this function.
>>>
>>> *+ Handle class_loader(loader_data->class_loader());*
>>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>>
>>> This could be simplified avoiding the Handle, which is not needed.
>>>
>>> *+ tty->print(" source: %s", 
>>> loader_data->class_loader()->klass()->external_name());*
>>>
>>> Is the loader_data argument to print_loading_log simply the 
>>> instanceKLass::_class_loader_data field?  In which case you can 
>>> remove the argument and have:
>>>
>>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>>> *
>>>
>> The original code (from classFileParser.cpp) is this:
>>
>>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
>> _loader_data->class_loader()->klass()->external_name());
>>
>> I suppose _loader_data->class_loader() in that context should be 
>> exactly the same as class_loader() inside the 
>> InstanceKlass::print_loading_log function, so your suggestion should 
>> work.
>>
>>> Obviously not to tty.
>>
>> You're right. The "tty->print" should be changed to log->print in 
>> InstanceKlass::print_loading_log. What I don't understand is why the 
>> output looks just fine.
>>
>> I never noticed these during my testing because the lines that use 
>> tty->print are uncommon and did not show up. I'll try to come up with 
>> a test case (I think it has something to do with reflection proxies 
>> ...).
>>
>>
>> Thanks
>> - Ioi
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>>
>>>
>>> This one can be condensed also
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>>> }
>>>
>>> to
>>>
>>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>>
>>> * 
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>>
>>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>>> his previous mail.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>>
>>>
>>> The return value 'ret' isn't used.  Either return an error if it 
>>> returns and error (what errors does it return?) or don't have 'ret'.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>>
>>>
>>> Test looks great to me!
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>>  151         checkFor("[classunload]", "[Unloading class");
>>>
>>> Can this be:
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>>> "[classunload]", "[Unloading class");
>>>
>>> To not start a new process?
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>>> Hello,
>>>> Please review this unified logging conversion for several related 
>>>> flags in the class loading system.
>>>>
>>>> Bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>>> classloaderdata)
>>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>>
>>>> Summary:
>>>>
>>>> There are two separate issues here. Originally Ioi and I began 
>>>> working on these fixes in parallel, but eventually it became 
>>>> obvious that the classload and classunload tags needed to be 
>>>> implemented together. This change is a combination of Ioi's change 
>>>> for 8079408 and my change for 8142506.
>>>>
>>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level debug (one level of verbosity up from info)
>>>>
>>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level trace (converted from uses of WizardMode)
>>>>
>>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>>
>>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>>> effected the implementation of "-verbose:class"
>>>>
>>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>>
>>>> If you have questions about the updates to the classloading log, 
>>>> Ioi can give a better answer than I can.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>
>>
>


From rachel.protacio at oracle.com  Mon Jan 25 21:26:34 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Mon, 25 Jan 2016 16:26:34 -0500
Subject: RFR: 8146137: runtime/logging/ExceptionsTest.java fails on embedded
	and ARM test
In-Reply-To: <56A68073.7040905@oracle.com>
References: <56A68073.7040905@oracle.com>
Message-ID: <56A6930A.7010008@oracle.com>

Hi,

Please review this fix for bug 8146137, where 
logging/ExceptionsTest.java was failing because of an optimized-away 
exception not being printed in embedded/arm, which does not use Tiered 
Compilation. Rather than fight with the platform, I've deleted the 
portion of the test looking for that compiled function's exception message.

To save time, I'll note that David Holmes and Coleen both reviewed the 
code offline already.

Open webrev: http://cr.openjdk.java.net/~rprotacio/8146137/
Bug: https://bugs.openjdk.java.net/browse/JDK-8146137 (apologies for 
it's being confidential)
Passes JPRT testing.

Thank you,
Rachel


From david.holmes at oracle.com  Mon Jan 25 21:29:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Jan 2016 07:29:29 +1000
Subject: RFR: 8146137: runtime/logging/ExceptionsTest.java fails on
	embedded and ARM test
In-Reply-To: <56A6930A.7010008@oracle.com>
References: <56A68073.7040905@oracle.com> <56A6930A.7010008@oracle.com>
Message-ID: <56A693B9.7000901@oracle.com>

For the public record - Reviewed!.

Thanks,
David

On 26/01/2016 7:26 AM, Rachel Protacio wrote:
> Hi,
>
> Please review this fix for bug 8146137, where
> logging/ExceptionsTest.java was failing because of an optimized-away
> exception not being printed in embedded/arm, which does not use Tiered
> Compilation. Rather than fight with the platform, I've deleted the
> portion of the test looking for that compiled function's exception message.
>
> To save time, I'll note that David Holmes and Coleen both reviewed the
> code offline already.
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146137/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146137 (apologies for
> it's being confidential)
> Passes JPRT testing.
>
> Thank you,
> Rachel
>

From coleen.phillimore at oracle.com  Mon Jan 25 21:30:26 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 25 Jan 2016 16:30:26 -0500
Subject: RFR: 8146137: runtime/logging/ExceptionsTest.java fails on
	embedded and ARM test
In-Reply-To: <56A6930A.7010008@oracle.com>
References: <56A68073.7040905@oracle.com> <56A6930A.7010008@oracle.com>
Message-ID: <56A693F2.7050606@oracle.com>

Looks good!
Coleen

On 1/25/16 4:26 PM, Rachel Protacio wrote:
> Hi,
>
> Please review this fix for bug 8146137, where 
> logging/ExceptionsTest.java was failing because of an optimized-away 
> exception not being printed in embedded/arm, which does not use Tiered 
> Compilation. Rather than fight with the platform, I've deleted the 
> portion of the test looking for that compiled function's exception 
> message.
>
> To save time, I'll note that David Holmes and Coleen both reviewed the 
> code offline already.
>
> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146137/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146137 (apologies for 
> it's being confidential)
> Passes JPRT testing.
>
> Thank you,
> Rachel
>


From rachel.protacio at oracle.com  Mon Jan 25 21:30:55 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Mon, 25 Jan 2016 16:30:55 -0500
Subject: RFR: 8146137: runtime/logging/ExceptionsTest.java fails on
	embedded and ARM test
In-Reply-To: <56A693B9.7000901@oracle.com>
References: <56A68073.7040905@oracle.com> <56A6930A.7010008@oracle.com>
	<56A693B9.7000901@oracle.com>
Message-ID: <56A6940F.4080703@oracle.com>

Thank you, David!
Rachel

On 1/25/2016 4:29 PM, David Holmes wrote:
> For the public record - Reviewed!.
>
> Thanks,
> David
>
> On 26/01/2016 7:26 AM, Rachel Protacio wrote:
>> Hi,
>>
>> Please review this fix for bug 8146137, where
>> logging/ExceptionsTest.java was failing because of an optimized-away
>> exception not being printed in embedded/arm, which does not use Tiered
>> Compilation. Rather than fight with the platform, I've deleted the
>> portion of the test looking for that compiled function's exception 
>> message.
>>
>> To save time, I'll note that David Holmes and Coleen both reviewed the
>> code offline already.
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146137/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146137 (apologies for
>> it's being confidential)
>> Passes JPRT testing.
>>
>> Thank you,
>> Rachel
>>


From rachel.protacio at oracle.com  Mon Jan 25 22:04:39 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Mon, 25 Jan 2016 17:04:39 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A1763E.5030506@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
Message-ID: <56A69BF7.9030409@oracle.com>

Looks good (excepting the changed mentioned by Ioi/Coleen)! The jtreg 
test needs to be normalized a bit, though. Namely, you can look at the 
header for ClassResolutionTest.java:

    /*
      * @test ClassResolutionTest
      * @bug 8144874
      * @library /testlibrary
      * @build jdk.test.lib.OutputAnalyzer jdk.test.lib.ProcessTools
      * @run driver ClassResolutionTest
      */

    import jdk.test.lib.OutputAnalyzer;
    import jdk.test.lib.ProcessTools;
    import java.lang.ref.WeakReference;
    import java.lang.reflect.Method;

Where you should import the specific OutputAnalyzer and ProcessTools and 
@build them.

Also I think the ProcessBuilder function calls in your code were based 
on my incorrect tests before, so they should be formatted with one 
argument per line.

Thanks!
Rachel

On 1/21/2016 7:22 PM, Max Ockner wrote:
> Hello all,
> This fix is now working again with the new changes incorporated.
>
> New webrev: http://cr.openjdk.java.net/~mockner/classload.03/
>
> I responded to all comments from Ioi and Coleen.
> My answer to Ioi's first question is option #2.
>
> Max
>
> On 1/8/2016 8:57 PM, Ioi Lam wrote:
>>
>>
>> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>>
>>> Hi, I have a bunch of comments that Ioi may have to help answer 
>>> because I had some questions about how the logging output comes out.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>>
>>>
>>> I think these can be UL-ized with less lines.  There's no need to 
>>> check if log_is_enabled here.
>>>
>>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>>> NULL) {*
>>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>>> *+ log->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> *!if (class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> What does this come out looking like?  It seems like it's going to 
>>> have [classloaderdata] in front of every line printed.  I think this 
>>> wants to be all one log line.
>>>
>>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>>> *)cld->class_loader()),*
>>> *+ cld->loader_name());*
>>> *+ *
>>> *+ if (string.not_null()) {*
>>> *+ log->print(": ");*
>>> *+ java_lang_String::print(string(), log);*
>>> *+ } *
>>> [classloaderdata] create class loader data <address>
>>> [classloaderdata]  for instance <addr> of some name
>>> [classloaderdata] :
>>> [classloaderdata] some string
>>>
>> The UL JEP says this in http://openjdk.java.net/jeps/158
>> "Goals ... Print line-at-a-time (no interleaving within same line)"
>>
>> log->print() is line-buffered. So all of these will be concatenated 
>> into the same buffer until the final log->cr() or log->print_cr(), at 
>> which point the whole line will be printed (with a single 
>> [classloaderdata] prefix).
>>
>> Here's an example:
>>
>> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
>> [0.780s][debug  ][classloaderdata] create class loader data 
>> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
>> sun/misc/Launcher$AppClassLoader: 
>> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>>
>>>
>>> You don't need to check log_is_enabled.  log_debug macro does that. 
>>> 2 instances in this file.
>>>
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>>> *+ } *
>>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>>
>>>
>>> Do you want this to come out with fewer lines?   Maybe the messages 
>>> should be collected in a tempStream and printed out at the end? LIke 
>>> in this file:
>>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>>
>>>
>> There's no need to use the tempStream, since the UL log already 
>> handles buffering.
>>
>> If my understanding of UL buffering is correct, I think the use of 
>> tempStream should be removed as a clean up.
>>
>>> There's a bunch of tty->print's still in this function.
>>>
>>> *+ Handle class_loader(loader_data->class_loader());*
>>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>>
>>> This could be simplified avoiding the Handle, which is not needed.
>>>
>>> *+ tty->print(" source: %s", 
>>> loader_data->class_loader()->klass()->external_name());*
>>>
>>> Is the loader_data argument to print_loading_log simply the 
>>> instanceKLass::_class_loader_data field?  In which case you can 
>>> remove the argument and have:
>>>
>>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>>> *
>>>
>> The original code (from classFileParser.cpp) is this:
>>
>>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
>> _loader_data->class_loader()->klass()->external_name());
>>
>> I suppose _loader_data->class_loader() in that context should be 
>> exactly the same as class_loader() inside the 
>> InstanceKlass::print_loading_log function, so your suggestion should 
>> work.
>>
>>> Obviously not to tty.
>>
>> You're right. The "tty->print" should be changed to log->print in 
>> InstanceKlass::print_loading_log. What I don't understand is why the 
>> output looks just fine.
>>
>> I never noticed these during my testing because the lines that use 
>> tty->print are uncommon and did not show up. I'll try to come up with 
>> a test case (I think it has something to do with reflection proxies 
>> ...).
>>
>>
>> Thanks
>> - Ioi
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>>
>>>
>>> This one can be condensed also
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>>> }
>>>
>>> to
>>>
>>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>>
>>> * 
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>>
>>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>>> his previous mail.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>>
>>>
>>> The return value 'ret' isn't used.  Either return an error if it 
>>> returns and error (what errors does it return?) or don't have 'ret'.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>>
>>>
>>> Test looks great to me!
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>>  151         checkFor("[classunload]", "[Unloading class");
>>>
>>> Can this be:
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>>> "[classunload]", "[Unloading class");
>>>
>>> To not start a new process?
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>>> Hello,
>>>> Please review this unified logging conversion for several related 
>>>> flags in the class loading system.
>>>>
>>>> Bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>>> classloaderdata)
>>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>>
>>>> Summary:
>>>>
>>>> There are two separate issues here. Originally Ioi and I began 
>>>> working on these fixes in parallel, but eventually it became 
>>>> obvious that the classload and classunload tags needed to be 
>>>> implemented together. This change is a combination of Ioi's change 
>>>> for 8079408 and my change for 8142506.
>>>>
>>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level debug (one level of verbosity up from info)
>>>>
>>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level trace (converted from uses of WizardMode)
>>>>
>>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>>
>>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>>> effected the implementation of "-verbose:class"
>>>>
>>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>>
>>>> If you have questions about the updates to the classloading log, 
>>>> Ioi can give a better answer than I can.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>
>>
>


From rachel.protacio at oracle.com  Mon Jan 25 22:11:33 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Mon, 25 Jan 2016 17:11:33 -0500
Subject: RFR: 8146137: runtime/logging/ExceptionsTest.java fails on
	embedded and ARM test
In-Reply-To: <56A693F2.7050606@oracle.com>
References: <56A68073.7040905@oracle.com> <56A6930A.7010008@oracle.com>
	<56A693F2.7050606@oracle.com>
Message-ID: <56A69D95.8090406@oracle.com>

Thanks, Coleen!
Rachel

On 1/25/2016 4:30 PM, Coleen Phillimore wrote:
> Looks good!
> Coleen
>
> On 1/25/16 4:26 PM, Rachel Protacio wrote:
>> Hi,
>>
>> Please review this fix for bug 8146137, where 
>> logging/ExceptionsTest.java was failing because of an optimized-away 
>> exception not being printed in embedded/arm, which does not use 
>> Tiered Compilation. Rather than fight with the platform, I've deleted 
>> the portion of the test looking for that compiled function's 
>> exception message.
>>
>> To save time, I'll note that David Holmes and Coleen both reviewed 
>> the code offline already.
>>
>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146137/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146137 (apologies for 
>> it's being confidential)
>> Passes JPRT testing.
>>
>> Thank you,
>> Rachel
>>
>


From ioi.lam at oracle.com  Tue Jan 26 05:31:31 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 25 Jan 2016 21:31:31 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A67E5E.3030208@oracle.com>
References: <568F60E4.50609@oracle.com>
	<56904C26.1010207@oracle.com>	<569068ED.6070509@oracle.com>
	<56A1763E.5030506@oracle.com> <56A67E5E.3030208@oracle.com>
Message-ID: <56A704B3.80100@oracle.com>

On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>
> Hi Max,
>
> This looks pretty good.  It's a large change!  A couple of comments:
>
> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>
>
> As Harold pointed out earlier this change should check for 'else'.
>
> *!if (_log_is_enabled(Info, classload)_) {*
> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
> }  else
> *+ if (log_is_enabled(Debug, classload)) {*
> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
> }
>

Hi Coleen,

The case for the 'else' has been discussed before. Please refer to

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html

To recap: the reason for NOT having the 'else' is for:

java -cp ~/tmp -Xlog:classload=info:file=info.log 
-Xlog:classload=debug:file=debug.log Foo

If you add the 'else' there,  the debug-level output intended for 
debug.log will be missing.

OK, you may say, let's switch the order of the Info and Debug checks. 
But if you do that, the info.log file will have no content.

The 'info' level looks like this

   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage

The 'debug' level looks like this (in a single line):

   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
   klass: 0x00000007c0000fb0 super: 0x0000000000000000
   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3

Because UL buffers at the line level, I cannot split the output into two 
parts like this:

   [info ][classload] java.lang.Object source: ...
   [debug][classload] klass: 0x00000007c0000fb0 super: ...

Otherwise some unrelated output may be interleaved between the two 
lines, making the output impossible to parse. The ability to parse the 
output is very important to tools that analyze the class loading 
behavior (e.g., tools related to CDS).

Due to this limitation of UL, I think our only choice is to repeat the 
class name and 'source' in both info and debug levels, hence NO 'else' 
in the code you quoted:

   [info ][classload] java.lang.Object source: ..
   [debug][classload] java.lang.Object source: .. klass: .. super: ..

Thanks
- Ioi




From daniel.daugherty at oracle.com  Tue Jan 26 15:45:48 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 26 Jan 2016 08:45:48 -0700
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A1763E.5030506@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
Message-ID: <56A794AC.2050800@oracle.com>

On 1/21/16 5:22 PM, Max Ockner wrote:
> Hello all,
> This fix is now working again with the new changes incorporated.
>
> New webrev: http://cr.openjdk.java.net/~mockner/classload.03/
>
> I responded to all comments from Ioi and Coleen.
> My answer to Ioi's first question is option #2.

Max,

A search of existing tests for use of TraceClassLoading revealed
some hits in both the jdk/test and hotspot/test dirs:

$ rgrep TraceClassLoading jdk/test hotspot/test
jdk/test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh: 
-verbose:class -XX:+TraceClassLoading -cp . \
jdk/test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh: 
-verbose:class -XX:+TraceClassLoading -cp . \
hotspot/test/closed/runtime/AppCDS/JvmtiAddPath.java: 
run(check_appcds_enabled, appJar, "-XX:+TraceClassLoading", "JvmtiApp", 
"noadd"); // appcds should be enabled
hotspot/test/closed/runtime/AppCDS/JvmtiAddPath.java: 
run(check_appcds_disabled, appJar, "-XX:+TraceClassLoading", "JvmtiApp", 
"bootonly", addbootJar); // appcds should be disabled


A search of existing tests for use of TraceClassUnloading revealed
some hits in both the jdk/test and hotspot/test dirs:

$ rgrep TraceClassUnloading jdk/test hotspot/test
jdk/test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh: 
$JAVA ${TESTVMOPTS} -Xverify:none -XX:+TraceClassUnloading \
jdk/test/closed/com/oracle/jfr/runtime/TestClassUnloadEvent.java: * @run 
main/othervm -XX:+UnlockCommercialFeatures -XX:+FlightRecorder 
-XX:+TraceClassUnloading -Xlog:gc -Xmx16m TestClassUnloadEvent
hotspot/test/compiler/jsr292/CallSiteDepContextTest.java: * @run 
main/bootclasspath -Xbatch -XX:+IgnoreUnrecognizedVMOptions 
-XX:+TraceClassUnloading


A search of existing tests for use of TraceClassLoaderData
revealed no hits in either the jdk/test or hotspot/test dirs.


For the tests that use either TraceClassLoading or TraceClassUnloading,
you'll want to update the tests to use your new style options and, more
importantly, you'll need to check the tests to see if they depend on
any of the output formats that may have changed.

Dan


>
> Max
>
> On 1/8/2016 8:57 PM, Ioi Lam wrote:
>>
>>
>> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>>
>>> Hi, I have a bunch of comments that Ioi may have to help answer 
>>> because I had some questions about how the logging output comes out.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>>
>>>
>>> I think these can be UL-ized with less lines.  There's no need to 
>>> check if log_is_enabled here.
>>>
>>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>>> NULL) {*
>>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>>> *+ log->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> *!if (class_loader() != NULL) {*
>>> *!tty->print_cr("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>>> class_loader()->klass()->internal_name());*
>>> }
>>>
>>> What does this come out looking like?  It seems like it's going to 
>>> have [classloaderdata] in front of every line printed.  I think this 
>>> wants to be all one log line.
>>>
>>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>>> *)cld->class_loader()),*
>>> *+ cld->loader_name());*
>>> *+ *
>>> *+ if (string.not_null()) {*
>>> *+ log->print(": ");*
>>> *+ java_lang_String::print(string(), log);*
>>> *+ } *
>>> [classloaderdata] create class loader data <address>
>>> [classloaderdata]  for instance <addr> of some name
>>> [classloaderdata] :
>>> [classloaderdata] some string
>>>
>> The UL JEP says this in http://openjdk.java.net/jeps/158
>> "Goals ... Print line-at-a-time (no interleaving within same line)"
>>
>> log->print() is line-buffered. So all of these will be concatenated 
>> into the same buffer until the final log->cr() or log->print_cr(), at 
>> which point the whole line will be printed (with a single 
>> [classloaderdata] prefix).
>>
>> Here's an example:
>>
>> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
>> [0.780s][debug  ][classloaderdata] create class loader data 
>> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
>> sun/misc/Launcher$AppClassLoader: 
>> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>>
>>>
>>> You don't need to check log_is_enabled.  log_debug macro does that. 
>>> 2 instances in this file.
>>>
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>>> *+ } *
>>>
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>>
>>>
>>> Do you want this to come out with fewer lines?   Maybe the messages 
>>> should be collected in a tempStream and printed out at the end? LIke 
>>> in this file:
>>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>>
>>>
>> There's no need to use the tempStream, since the UL log already 
>> handles buffering.
>>
>> If my understanding of UL buffering is correct, I think the use of 
>> tempStream should be removed as a clean up.
>>
>>> There's a bunch of tty->print's still in this function.
>>>
>>> *+ Handle class_loader(loader_data->class_loader());*
>>> *+ tty->print(" source: %s", class_loader->klass()->external_name()); *
>>>
>>> This could be simplified avoiding the Handle, which is not needed.
>>>
>>> *+ tty->print(" source: %s", 
>>> loader_data->class_loader()->klass()->external_name());*
>>>
>>> Is the loader_data argument to print_loading_log simply the 
>>> instanceKLass::_class_loader_data field?  In which case you can 
>>> remove the argument and have:
>>>
>>> *+ tty->print(" source: %s", class_loader()->klass()->external_name());
>>> *
>>>
>> The original code (from classFileParser.cpp) is this:
>>
>>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
>> _loader_data->class_loader()->klass()->external_name());
>>
>> I suppose _loader_data->class_loader() in that context should be 
>> exactly the same as class_loader() inside the 
>> InstanceKlass::print_loading_log function, so your suggestion should 
>> work.
>>
>>> Obviously not to tty.
>>
>> You're right. The "tty->print" should be changed to log->print in 
>> InstanceKlass::print_loading_log. What I don't understand is why the 
>> output looks just fine.
>>
>> I never noticed these during my testing because the lines that use 
>> tty->print are uncommon and did not show up. I'll try to come up with 
>> a test case (I think it has something to do with reflection proxies 
>> ...).
>>
>>
>> Thanks
>> - Ioi
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>>
>>>
>>> This one can be condensed also
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>>> }
>>>
>>> to
>>>
>>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>>
>>> * 
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>>
>>> Yes, I think -verbose:class should be converted to UL.  Ioi's #2 in 
>>> his previous mail.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>>
>>>
>>> The return value 'ret' isn't used.  Either return an error if it 
>>> returns and error (what errors does it return?) or don't have 'ret'.
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>>
>>>
>>> Test looks great to me!
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>>  151         checkFor("[classunload]", "[Unloading class");
>>>
>>> Can this be:
>>>
>>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>>> "[classunload]", "[Unloading class");
>>>
>>> To not start a new process?
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>>> Hello,
>>>> Please review this unified logging conversion for several related 
>>>> flags in the class loading system.
>>>>
>>>> Bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>>> classloaderdata)
>>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>>
>>>> Summary:
>>>>
>>>> There are two separate issues here. Originally Ioi and I began 
>>>> working on these fixes in parallel, but eventually it became 
>>>> obvious that the classload and classunload tags needed to be 
>>>> implemented together. This change is a combination of Ioi's change 
>>>> for 8079408 and my change for 8142506.
>>>>
>>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level debug (one level of verbosity up from info)
>>>>
>>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>>> This flag is added to the alias table. More verbose logging exists 
>>>> at level trace (converted from uses of WizardMode)
>>>>
>>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>>
>>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>>> effected the implementation of "-verbose:class"
>>>>
>>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>>
>>>> If you have questions about the updates to the classloading log, 
>>>> Ioi can give a better answer than I can.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>


From ioi.lam at oracle.com  Tue Jan 26 17:14:05 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 26 Jan 2016 09:14:05 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A794AC.2050800@oracle.com>
References: <568F60E4.50609@oracle.com>
	<56904C26.1010207@oracle.com>	<569068ED.6070509@oracle.com>
	<56A1763E.5030506@oracle.com> <56A794AC.2050800@oracle.com>
Message-ID: <56A7A95D.700@oracle.com>



On 1/26/16 7:45 AM, Daniel D. Daugherty wrote:
> On 1/21/16 5:22 PM, Max Ockner wrote:
>> Hello all,
>> This fix is now working again with the new changes incorporated.
>>
>> New webrev: http://cr.openjdk.java.net/~mockner/classload.03/
>>
>> I responded to all comments from Ioi and Coleen.
>> My answer to Ioi's first question is option #2.
>
> Max,
>
> A search of existing tests for use of TraceClassLoading revealed
> some hits in both the jdk/test and hotspot/test dirs:
>
> $ rgrep TraceClassLoading jdk/test hotspot/test
> jdk/test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh: 
> -verbose:class -XX:+TraceClassLoading -cp . \
> jdk/test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh: 
> -verbose:class -XX:+TraceClassLoading -cp . \
> hotspot/test/closed/runtime/AppCDS/JvmtiAddPath.java: 
> run(check_appcds_enabled, appJar, "-XX:+TraceClassLoading", 
> "JvmtiApp", "noadd"); // appcds should be enabled
> hotspot/test/closed/runtime/AppCDS/JvmtiAddPath.java: 
> run(check_appcds_disabled, appJar, "-XX:+TraceClassLoading", 
> "JvmtiApp", "bootonly", addbootJar); // appcds should be disabled
>
>
> A search of existing tests for use of TraceClassUnloading revealed
> some hits in both the jdk/test and hotspot/test dirs:
>
> $ rgrep TraceClassUnloading jdk/test hotspot/test
> jdk/test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh: 
> $JAVA ${TESTVMOPTS} -Xverify:none -XX:+TraceClassUnloading \
> jdk/test/closed/com/oracle/jfr/runtime/TestClassUnloadEvent.java: * 
> @run main/othervm -XX:+UnlockCommercialFeatures -XX:+FlightRecorder 
> -XX:+TraceClassUnloading -Xlog:gc -Xmx16m TestClassUnloadEvent
> hotspot/test/compiler/jsr292/CallSiteDepContextTest.java: * @run 
> main/bootclasspath -Xbatch -XX:+IgnoreUnrecognizedVMOptions 
> -XX:+TraceClassUnloading
>
>
> A search of existing tests for use of TraceClassLoaderData
> revealed no hits in either the jdk/test or hotspot/test dirs.
>
>
> For the tests that use either TraceClassLoading or TraceClassUnloading,
> you'll want to update the tests to use your new style options and, more
> importantly, you'll need to check the tests to see if they depend on
> any of the output formats that may have changed.
Note that TraceClassLoading is implicitly enabled when -verbose or 
-verbose:class are specified in the command line (see arguments.cpp), so 
there could be other tests that depend on the output of TraceClassLoading

I think for tests that use only -verbose/verbose:class, but do not 
explicitly specify TraceClassLoading, we can leave their command-lines 
alone, but need to fix the test bodies if they depend on the specific 
output format.

To run all the hotspot tests on the supported platforms, the easiest is 
to use RBT with

     --test hotspot/test/:hotspot_all

Thanks
- Ioi

>
> Dan
>
>
>>
>> Max
>>
>> On 1/8/2016 8:57 PM, Ioi Lam wrote:
>>>
>>>
>>> On 1/8/16 3:54 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi, I have a bunch of comments that Ioi may have to help answer 
>>>> because I had some questions about how the logging output comes out.
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/classfile/classLoaderData.cpp.udiff.html 
>>>>
>>>>
>>>> I think these can be UL-ized with less lines.  There's no need to 
>>>> check if log_is_enabled here.
>>>>
>>>> *!if (TraceClassLoaderData && Verbose&& class_loader() != NULL) {*
>>>> *!tty->print_cr("is_anonymous: %s", 
>>>> class_loader()->klass()->internal_name());*
>>>> *!if (_log_is_enabled(Trace, classloaderdata)_&& class_loader() != 
>>>> NULL) {*
>>>> *!_outputStream* log = LogHandle(classloaderdata)::trace_stream(_);*
>>>> *+ log->print_cr("is_anonymous: %s", 
>>>> class_loader()->klass()->internal_name());*
>>>> }
>>>>
>>>> *!if (class_loader() != NULL) {*
>>>> *!tty->print_cr("is_anonymous: %s", 
>>>> class_loader()->klass()->internal_name());*
>>>> *+ log_trace(classloaderdata)("is_anonymous: %s", 
>>>> class_loader()->klass()->internal_name());*
>>>> }
>>>>
>>>> What does this come out looking like?  It seems like it's going to 
>>>> have [classloaderdata] in front of every line printed.  I think 
>>>> this wants to be all one log line.
>>>>
>>>> *+ outputStream* log = LogHandle(classloaderdata)::debug_stream();*
>>>> *+ log->print("create class loader data " INTPTR_FORMAT, p2i(cld));*
>>>> *+ log->print(" for instance " INTPTR_FORMAT " of %s", p2i((void 
>>>> *)cld->class_loader()),*
>>>> *+ cld->loader_name());*
>>>> *+ *
>>>> *+ if (string.not_null()) {*
>>>> *+ log->print(": ");*
>>>> *+ java_lang_String::print(string(), log);*
>>>> *+ } *
>>>> [classloaderdata] create class loader data <address>
>>>> [classloaderdata]  for instance <addr> of some name
>>>> [classloaderdata] :
>>>> [classloaderdata] some string
>>>>
>>> The UL JEP says this in http://openjdk.java.net/jeps/158
>>> "Goals ... Print line-at-a-time (no interleaving within same line)"
>>>
>>> log->print() is line-buffered. So all of these will be concatenated 
>>> into the same buffer until the final log->cr() or log->print_cr(), 
>>> at which point the whole line will be printed (with a single 
>>> [classloaderdata] prefix).
>>>
>>> Here's an example:
>>>
>>> $ java -Xlog:classloaderdata=debug -cp ~/tmp Foo
>>> [0.780s][debug  ][classloaderdata] create class loader data 
>>> 0x00007f71704d6940 for instance 0x000000041103dea0 of 
>>> sun/misc/Launcher$AppClassLoader: 
>>> "sun.misc.Launcher$AppClassLoader at 722c41f4"
>>>
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/memory/filemap.cpp.udiff.html 
>>>>
>>>>
>>>> You don't need to check log_is_enabled.  log_debug macro does that. 
>>>> 2 instances in this file.
>>>>
>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>> *+ log_debug(classload)("[Add main shared path (%s) %s]", 
>>>> (cpe->is_jar_file() ? "jar" : "dir"), name);*
>>>> *+ } *
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/oops/instanceKlass.cpp.udiff.html 
>>>>
>>>>
>>>> Do you want this to come out with fewer lines?   Maybe the messages 
>>>> should be collected in a tempStream and printed out at the end? 
>>>> LIke in this file:
>>>> http://cr.openjdk.java.net/~rprotacio/8144953/src/share/vm/c1/c1_Runtime1.cpp.udiff.html 
>>>>
>>>>
>>> There's no need to use the tempStream, since the UL log already 
>>> handles buffering.
>>>
>>> If my understanding of UL buffering is correct, I think the use of 
>>> tempStream should be removed as a clean up.
>>>
>>>> There's a bunch of tty->print's still in this function.
>>>>
>>>> *+ Handle class_loader(loader_data->class_loader());*
>>>> *+ tty->print(" source: %s", 
>>>> class_loader->klass()->external_name()); *
>>>>
>>>> This could be simplified avoiding the Handle, which is not needed.
>>>>
>>>> *+ tty->print(" source: %s", 
>>>> loader_data->class_loader()->klass()->external_name());*
>>>>
>>>> Is the loader_data argument to print_loading_log simply the 
>>>> instanceKLass::_class_loader_data field?  In which case you can 
>>>> remove the argument and have:
>>>>
>>>> *+ tty->print(" source: %s", 
>>>> class_loader()->klass()->external_name());
>>>> *
>>>>
>>> The original code (from classFileParser.cpp) is this:
>>>
>>>         tty->print("[Loaded %s from %s]\n", ik->external_name(),
>>> _loader_data->class_loader()->klass()->external_name());
>>>
>>> I suppose _loader_data->class_loader() in that context should be 
>>> exactly the same as class_loader() inside the 
>>> InstanceKlass::print_loading_log function, so your suggestion should 
>>> work.
>>>
>>>> Obviously not to tty.
>>>
>>> You're right. The "tty->print" should be changed to log->print in 
>>> InstanceKlass::print_loading_log. What I don't understand is why the 
>>> output looks just fine.
>>>
>>> I never noticed these during my testing because the lines that use 
>>> tty->print are uncommon and did not show up. I'll try to come up 
>>> with a test case (I think it has something to do with reflection 
>>> proxies ...).
>>>
>>>
>>> Thanks
>>> - Ioi
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/prims/jvmtiEnv.cpp.udiff.html 
>>>>
>>>>
>>>> This one can be condensed also
>>>>
>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>> *!_outputStream* log = LogHandle(classload)::info_stream(_);*
>>>> *+ log->print_cr("[Opened %s]", zip_entry->name());*
>>>> }
>>>>
>>>> to
>>>>
>>>> *+ log_info(classload)("[Opened %s]", zip_entry->name());
>>>>
>>>> * 
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/runtime/arguments.cpp.udiff.html
>>>>
>>>> Yes, I think -verbose:class should be converted to UL. Ioi's #2 in 
>>>> his previous mail.
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>>>
>>>>
>>>> The return value 'ret' isn't used.  Either return an error if it 
>>>> returns and error (what errors does it return?) or don't have 'ret'.
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.01/test/runtime/logging/ClassLoadUnload.java.html 
>>>>
>>>>
>>>> Test looks great to me!
>>>>
>>>>  150         checkFor("[classload]", "java.lang.Object", "source:");
>>>>  151         checkFor("[classunload]", "[Unloading class");
>>>>
>>>> Can this be:
>>>>
>>>>  150         checkFor("[classload]", "java.lang.Object", "source:", 
>>>> "[classunload]", "[Unloading class");
>>>>
>>>> To not start a new process?
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 1/8/16 2:10 AM, Max Ockner wrote:
>>>>> Hello,
>>>>> Please review this unified logging conversion for several related 
>>>>> flags in the class loading system.
>>>>>
>>>>> Bugs:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8079408 (classload, 
>>>>> classloaderdata)
>>>>> https://bugs.openjdk.java.net/browse/JDK-8142506 (classunload)
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.01/
>>>>>
>>>>> Summary:
>>>>>
>>>>> There are two separate issues here. Originally Ioi and I began 
>>>>> working on these fixes in parallel, but eventually it became 
>>>>> obvious that the classload and classunload tags needed to be 
>>>>> implemented together. This change is a combination of Ioi's change 
>>>>> for 8079408 and my change for 8142506.
>>>>>
>>>>> (1) "-XX:+TraceClassLoading" ==> "-Xlog:classload=info"
>>>>> This flag is added to the alias table. More verbose logging exists 
>>>>> at level debug (one level of verbosity up from info)
>>>>>
>>>>> (2) "-XX:+TraceClassUnLoading" ==> "-Xlog:classunload=info"
>>>>> This flag is added to the alias table. More verbose logging exists 
>>>>> at level trace (converted from uses of WizardMode)
>>>>>
>>>>> (3) "-XX:+TraceClassLoaderData" ==> "-Xlog:classloaderdata=debug"
>>>>>
>>>>> The changes to TraceClassLoading and TraceClassUnloading also 
>>>>> effected the implementation of "-verbose:class"
>>>>>
>>>>> Tested with: jtreg runtime, runThese with "-Xlog:classload=trace 
>>>>> -Xlog:classunload=trace -Xlog:classloaderdata=trace".
>>>>>
>>>>> If you have questions about the updates to the classloading log, 
>>>>> Ioi can give a better answer than I can.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>


From coleen.phillimore at oracle.com  Tue Jan 26 19:23:04 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 26 Jan 2016 14:23:04 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A704B3.80100@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
Message-ID: <56A7C798.2040102@oracle.com>


Thanks for recapping the decision.  I didn't remember it from all our 
discussions, etc.

As the one who looks at these logs and is parsing these for CDS, thank 
you for confirming that this is intentional.  Do you really have two 
different output files for info and debug info?

Max/Ioi can you add a comment to the code.  This looks easily like 
someone would "fix" because it looks funny.

Thanks,
Coleen

On 1/26/16 12:31 AM, Ioi Lam wrote:
> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>
>> Hi Max,
>>
>> This looks pretty good.  It's a large change!  A couple of comments:
>>
>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>
>>
>> As Harold pointed out earlier this change should check for 'else'.
>>
>> *!if (_log_is_enabled(Info, classload)_) {*
>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>> }  else
>> *+ if (log_is_enabled(Debug, classload)) {*
>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>> }
>>
>
> Hi Coleen,
>
> The case for the 'else' has been discussed before. Please refer to
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>
>
> To recap: the reason for NOT having the 'else' is for:
>
> java -cp ~/tmp -Xlog:classload=info:file=info.log 
> -Xlog:classload=debug:file=debug.log Foo
>
> If you add the 'else' there,  the debug-level output intended for 
> debug.log will be missing.
>
> OK, you may say, let's switch the order of the Info and Debug checks. 
> But if you do that, the info.log file will have no content.
>
> The 'info' level looks like this
>
>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>
> The 'debug' level looks like this (in a single line):
>
>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>
> Because UL buffers at the line level, I cannot split the output into 
> two parts like this:
>
>   [info ][classload] java.lang.Object source: ...
>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>
> Otherwise some unrelated output may be interleaved between the two 
> lines, making the output impossible to parse. The ability to parse the 
> output is very important to tools that analyze the class loading 
> behavior (e.g., tools related to CDS).
>
> Due to this limitation of UL, I think our only choice is to repeat the 
> class name and 'source' in both info and debug levels, hence NO 'else' 
> in the code you quoted:
>
>   [info ][classload] java.lang.Object source: ..
>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>
> Thanks
> - Ioi
>
>
>


From max.ockner at oracle.com  Tue Jan 26 20:25:55 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 26 Jan 2016 15:25:55 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7C798.2040102@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com>
Message-ID: <56A7D653.7010504@oracle.com>

I am working on changing the affected tests to look for the proper output.
-Max

On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>
> Thanks for recapping the decision.  I didn't remember it from all our 
> discussions, etc.
>
> As the one who looks at these logs and is parsing these for CDS, thank 
> you for confirming that this is intentional.  Do you really have two 
> different output files for info and debug info?
>
> Max/Ioi can you add a comment to the code.  This looks easily like 
> someone would "fix" because it looks funny.
>
> Thanks,
> Coleen
>
> On 1/26/16 12:31 AM, Ioi Lam wrote:
>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>
>>> Hi Max,
>>>
>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>>
>>>
>>> As Harold pointed out earlier this change should check for 'else'.
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>> }  else
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>> }
>>>
>>
>> Hi Coleen,
>>
>> The case for the 'else' has been discussed before. Please refer to
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>>
>>
>> To recap: the reason for NOT having the 'else' is for:
>>
>> java -cp ~/tmp -Xlog:classload=info:file=info.log 
>> -Xlog:classload=debug:file=debug.log Foo
>>
>> If you add the 'else' there,  the debug-level output intended for 
>> debug.log will be missing.
>>
>> OK, you may say, let's switch the order of the Info and Debug checks. 
>> But if you do that, the info.log file will have no content.
>>
>> The 'info' level looks like this
>>
>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>
>> The 'debug' level looks like this (in a single line):
>>
>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>
>> Because UL buffers at the line level, I cannot split the output into 
>> two parts like this:
>>
>>   [info ][classload] java.lang.Object source: ...
>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>
>> Otherwise some unrelated output may be interleaved between the two 
>> lines, making the output impossible to parse. The ability to parse 
>> the output is very important to tools that analyze the class loading 
>> behavior (e.g., tools related to CDS).
>>
>> Due to this limitation of UL, I think our only choice is to repeat 
>> the class name and 'source' in both info and debug levels, hence NO 
>> 'else' in the code you quoted:
>>
>>   [info ][classload] java.lang.Object source: ..
>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>
>> Thanks
>> - Ioi
>>
>>
>>
>


From david.holmes at oracle.com  Tue Jan 26 20:33:25 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 06:33:25 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7D653.7010504@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7D653.7010504@oracle.com>
Message-ID: <56A7D815.3000205@oracle.com>

On 27/01/2016 6:25 AM, Max Ockner wrote:
> I am working on changing the affected tests to look for the proper output.

Late to the party but should we not be trying to maintain the existing 
basic format of the log messages so that anyone who already regularly 
uses -verbose:class and has scripts etc that check this, will still see 
basic things like:

[Loaded xxx from yyyy]

?

David

  -Max
>
> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>
>> Thanks for recapping the decision.  I didn't remember it from all our
>> discussions, etc.
>>
>> As the one who looks at these logs and is parsing these for CDS, thank
>> you for confirming that this is intentional.  Do you really have two
>> different output files for info and debug info?
>>
>> Max/Ioi can you add a comment to the code.  This looks easily like
>> someone would "fix" because it looks funny.
>>
>> Thanks,
>> Coleen
>>
>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>
>>>>
>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>
>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>> }  else
>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>> }
>>>>
>>>
>>> Hi Coleen,
>>>
>>> The case for the 'else' has been discussed before. Please refer to
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>
>>>
>>> To recap: the reason for NOT having the 'else' is for:
>>>
>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>> -Xlog:classload=debug:file=debug.log Foo
>>>
>>> If you add the 'else' there,  the debug-level output intended for
>>> debug.log will be missing.
>>>
>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>> But if you do that, the info.log file will have no content.
>>>
>>> The 'info' level looks like this
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>
>>> The 'debug' level looks like this (in a single line):
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>
>>> Because UL buffers at the line level, I cannot split the output into
>>> two parts like this:
>>>
>>>   [info ][classload] java.lang.Object source: ...
>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>
>>> Otherwise some unrelated output may be interleaved between the two
>>> lines, making the output impossible to parse. The ability to parse
>>> the output is very important to tools that analyze the class loading
>>> behavior (e.g., tools related to CDS).
>>>
>>> Due to this limitation of UL, I think our only choice is to repeat
>>> the class name and 'source' in both info and debug levels, hence NO
>>> 'else' in the code you quoted:
>>>
>>>   [info ][classload] java.lang.Object source: ..
>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>
>

From max.ockner at oracle.com  Tue Jan 26 20:44:20 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 26 Jan 2016 15:44:20 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7D815.3000205@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7D653.7010504@oracle.com>
	<56A7D815.3000205@oracle.com>
Message-ID: <56A7DAA4.9050800@oracle.com>

David,
In general, we want to keep logging messages the same as before. This 
fix contains changes to the logging output as well.
Max
On 1/26/2016 3:33 PM, David Holmes wrote:
> On 27/01/2016 6:25 AM, Max Ockner wrote:
>> I am working on changing the affected tests to look for the proper 
>> output.
>
> Late to the party but should we not be trying to maintain the existing 
> basic format of the log messages so that anyone who already regularly 
> uses -verbose:class and has scripts etc that check this, will still 
> see basic things like:
>
> [Loaded xxx from yyyy]
>
> ?
>
> David
>
>  -Max
>>
>> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>>
>>> Thanks for recapping the decision.  I didn't remember it from all our
>>> discussions, etc.
>>>
>>> As the one who looks at these logs and is parsing these for CDS, thank
>>> you for confirming that this is intentional.  Do you really have two
>>> different output files for info and debug info?
>>>
>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>> someone would "fix" because it looks funny.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>>
>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>>>>
>>>>>
>>>>>
>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>
>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>> }  else
>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>> }
>>>>>
>>>>
>>>> Hi Coleen,
>>>>
>>>> The case for the 'else' has been discussed before. Please refer to
>>>>
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>>>>
>>>>
>>>>
>>>> To recap: the reason for NOT having the 'else' is for:
>>>>
>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>
>>>> If you add the 'else' there,  the debug-level output intended for
>>>> debug.log will be missing.
>>>>
>>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>>> But if you do that, the info.log file will have no content.
>>>>
>>>> The 'info' level looks like this
>>>>
>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>
>>>> The 'debug' level looks like this (in a single line):
>>>>
>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>
>>>> Because UL buffers at the line level, I cannot split the output into
>>>> two parts like this:
>>>>
>>>>   [info ][classload] java.lang.Object source: ...
>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>
>>>> Otherwise some unrelated output may be interleaved between the two
>>>> lines, making the output impossible to parse. The ability to parse
>>>> the output is very important to tools that analyze the class loading
>>>> behavior (e.g., tools related to CDS).
>>>>
>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>> the class name and 'source' in both info and debug levels, hence NO
>>>> 'else' in the code you quoted:
>>>>
>>>>   [info ][classload] java.lang.Object source: ..
>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>>
>>>>
>>>
>>


From david.holmes at oracle.com  Tue Jan 26 20:48:30 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 06:48:30 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7DAA4.9050800@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7D653.7010504@oracle.com>
	<56A7D815.3000205@oracle.com> <56A7DAA4.9050800@oracle.com>
Message-ID: <56A7DB9E.6050201@oracle.com>

On 27/01/2016 6:44 AM, Max Ockner wrote:
> David,
> In general, we want to keep logging messages the same as before. This
> fix contains changes to the logging output as well.

Why are we changing the logging output? And why mix the two changes?

Thanks,
David

> Max
> On 1/26/2016 3:33 PM, David Holmes wrote:
>> On 27/01/2016 6:25 AM, Max Ockner wrote:
>>> I am working on changing the affected tests to look for the proper
>>> output.
>>
>> Late to the party but should we not be trying to maintain the existing
>> basic format of the log messages so that anyone who already regularly
>> uses -verbose:class and has scripts etc that check this, will still
>> see basic things like:
>>
>> [Loaded xxx from yyyy]
>>
>> ?
>>
>> David
>>
>>  -Max
>>>
>>> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>>>
>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>> discussions, etc.
>>>>
>>>> As the one who looks at these logs and is parsing these for CDS, thank
>>>> you for confirming that this is intentional.  Do you really have two
>>>> different output files for info and debug info?
>>>>
>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>> someone would "fix" because it looks funny.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>
>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>> }  else
>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>> }
>>>>>>
>>>>>
>>>>> Hi Coleen,
>>>>>
>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>>>
>>>>>
>>>>>
>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>
>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>
>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>> debug.log will be missing.
>>>>>
>>>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>>>> But if you do that, the info.log file will have no content.
>>>>>
>>>>> The 'info' level looks like this
>>>>>
>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>
>>>>> The 'debug' level looks like this (in a single line):
>>>>>
>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>
>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>> two parts like this:
>>>>>
>>>>>   [info ][classload] java.lang.Object source: ...
>>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>
>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>> lines, making the output impossible to parse. The ability to parse
>>>>> the output is very important to tools that analyze the class loading
>>>>> behavior (e.g., tools related to CDS).
>>>>>
>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>> 'else' in the code you quoted:
>>>>>
>>>>>   [info ][classload] java.lang.Object source: ..
>>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>>
>>>>>
>>>>
>>>
>

From max.ockner at oracle.com  Tue Jan 26 21:04:43 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Tue, 26 Jan 2016 16:04:43 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7DB9E.6050201@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7D653.7010504@oracle.com>
	<56A7D815.3000205@oracle.com> <56A7DAA4.9050800@oracle.com>
	<56A7DB9E.6050201@oracle.com>
Message-ID: <56A7DF6B.5010001@oracle.com>

This changeset is a combination of two smaller changes:
1) Ioi's classload/classloaderdata changeset
2)My classunload changeset.

Ioi's changeset includes changes to the classload output. I have taken 
his advice during the review process and some output has been changed 
for classunload as well.

These changes are mixed because logging for class loading and class 
unloading can be triggered together by -verbose:class, and it was much 
easier to convert both at the same time than it would have been to come 
up with a temporary fix for -verbose:class.

I think Ioi can explain why the logs are changing better than I can, so 
hopefully he can offer his perspective on this.

-Max

On 1/26/2016 3:48 PM, David Holmes wrote:
> On 27/01/2016 6:44 AM, Max Ockner wrote:
>> David,
>> In general, we want to keep logging messages the same as before. This
>> fix contains changes to the logging output as well.
>
> Why are we changing the logging output? And why mix the two changes?
>
> Thanks,
> David
>
>> Max
>> On 1/26/2016 3:33 PM, David Holmes wrote:
>>> On 27/01/2016 6:25 AM, Max Ockner wrote:
>>>> I am working on changing the affected tests to look for the proper
>>>> output.
>>>
>>> Late to the party but should we not be trying to maintain the existing
>>> basic format of the log messages so that anyone who already regularly
>>> uses -verbose:class and has scripts etc that check this, will still
>>> see basic things like:
>>>
>>> [Loaded xxx from yyyy]
>>>
>>> ?
>>>
>>> David
>>>
>>>  -Max
>>>>
>>>> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>>> discussions, etc.
>>>>>
>>>>> As the one who looks at these logs and is parsing these for CDS, 
>>>>> thank
>>>>> you for confirming that this is intentional.  Do you really have two
>>>>> different output files for info and debug info?
>>>>>
>>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>>> someone would "fix" because it looks funny.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> This looks pretty good.  It's a large change!  A couple of 
>>>>>>> comments:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>>
>>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>>> }  else
>>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Hi Coleen,
>>>>>>
>>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>>
>>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>>
>>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>>> debug.log will be missing.
>>>>>>
>>>>>> OK, you may say, let's switch the order of the Info and Debug 
>>>>>> checks.
>>>>>> But if you do that, the info.log file will have no content.
>>>>>>
>>>>>> The 'info' level looks like this
>>>>>>
>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>
>>>>>> The 'debug' level looks like this (in a single line):
>>>>>>
>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>>
>>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>>> two parts like this:
>>>>>>
>>>>>>   [info ][classload] java.lang.Object source: ...
>>>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>>
>>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>>> lines, making the output impossible to parse. The ability to parse
>>>>>> the output is very important to tools that analyze the class loading
>>>>>> behavior (e.g., tools related to CDS).
>>>>>>
>>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>>> 'else' in the code you quoted:
>>>>>>
>>>>>>   [info ][classload] java.lang.Object source: ..
>>>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>>
>>>>>> Thanks
>>>>>> - Ioi
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>


From gerald.thornbrugh at oracle.com  Tue Jan 26 21:09:56 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 26 Jan 2016 14:09:56 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A1E2ED.1000109@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
Message-ID: <56A7E0A4.6070500@oracle.com>

Hi David,

Your code looks good. I do have a question about the test. If I 
understand the test correctly
the test will be run with no parameters and will use the "taskset" 
command to determine the
number of processors.

Under what circumstances will the test be run with arguments?

Was this something you added to allow the verification of the 
"availbleProcessors" method to
be done manually?

Jerry
> First a special thanks to Martin Buchholz for his input, feedback, 
> critique and raising awareness of how non-simple this issue is.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
> Basic problem:
>   processors available for use <= processors online <= processors 
> configured
>
> but we always returned the number of online processors.
>
> Solution is simple in its basic form: use sched_getaffinity to get the 
> scheduling affinity mask and count the number of available processors.
>
> Details are complicated by the desire to handle very large processor 
> systems. See the bug report for lots of detailed discussions and 
> references.
>
> Testing:
>  - new test that verifies behaviour when running under taskset
>  - diagnostic hook injection (UseNewCodeN) to enable testing of all 
> code paths (one hook is left in for non-product to allow easy testing 
> of the dynamic path)
>  - JPRT
>
> Compatability issues:
> - the system code we're using now is at least 5 years old so distro's 
> older than that (which are not officially supported) may not work
> - anyone already running under a processor constrained environment 
> (like Docker) and using availableProcessor() to "size" things, will 
> find that size has now changed. We do not expect this to be a problem 
> - on the contrary we expect Docker users to want the new behaviour.
>
> Thanks,
> David


From david.holmes at oracle.com  Tue Jan 26 21:12:24 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 07:12:24 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A1E2ED.1000109@oracle.com>
References: <56A1E2ED.1000109@oracle.com>
Message-ID: <56A7E138.8000301@oracle.com>

Update ...

On 22/01/2016 6:06 PM, David Holmes wrote:
> First a special thanks to Martin Buchholz for his input, feedback,
> critique and raising awareness of how non-simple this issue is.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
> Basic problem:
>    processors available for use <= processors online <= processors
> configured
>
> but we always returned the number of online processors.
>
> Solution is simple in its basic form: use sched_getaffinity to get the
> scheduling affinity mask and count the number of available processors.
>
> Details are complicated by the desire to handle very large processor
> systems. See the bug report for lots of detailed discussions and
> references.
>
> Testing:
>   - new test that verifies behaviour when running under taskset
>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
> code paths (one hook is left in for non-product to allow easy testing of
> the dynamic path)

I have been told that using the development flag UseNewCode in released 
code is a bad idea because it is used internally during development (as 
per its defined purpose).

I would like to be able to test the dynamic path easily, but I didn't 
want to pay the price of adding a new VM option to do it. So choices are:

a) don't do anything (remove the UseNewCode check)
b) add a new diagnostic flag
c) add a new experimental flag

Thoughts?

Thanks,
David


>   - JPRT
>
> Compatability issues:
> - the system code we're using now is at least 5 years old so distro's
> older than that (which are not officially supported) may not work
> - anyone already running under a processor constrained environment (like
> Docker) and using availableProcessor() to "size" things, will find that
> size has now changed. We do not expect this to be a problem - on the
> contrary we expect Docker users to want the new behaviour.
>
> Thanks,
> David

From ioi.lam at oracle.com  Tue Jan 26 21:39:43 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 26 Jan 2016 13:39:43 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7DB9E.6050201@oracle.com>
References: <568F60E4.50609@oracle.com>
	<56904C26.1010207@oracle.com>	<569068ED.6070509@oracle.com>
	<56A1763E.5030506@oracle.com>	<56A67E5E.3030208@oracle.com>
	<56A704B3.80100@oracle.com>	<56A7C798.2040102@oracle.com>
	<56A7D653.7010504@oracle.com>	<56A7D815.3000205@oracle.com>
	<56A7DAA4.9050800@oracle.com> <56A7DB9E.6050201@oracle.com>
Message-ID: <56A7E79F.1040806@oracle.com>



On 1/26/16 12:48 PM, David Holmes wrote:
> On 27/01/2016 6:44 AM, Max Ockner wrote:
>> David,
>> In general, we want to keep logging messages the same as before. This
>> fix contains changes to the logging output as well.
>
> Why are we changing the logging output? And why mix the two changes?
>

David,

OLD:

[Loaded xxx from yyyy]

NEW:

[info ][classload] xxx source: yyyy

Keeping the "Loaded" there seems superfluous. It would look like

[info ][classload] Loaded xxx source: yyyy

The point of UL is to remove the need for ad-hoc tags such as "Loaded".

Also, the original [] brackets are inconsistent with the UL style, so 
they are removed.

I think it's better to change over to the new UL style rather than 
keeping the older odd style. Even if we don't, the addition of the 
[info][classload] characters would break some scripts anyway (e.g., my 
old scripts would grep for "*^\\[Loaded*" , so we can't get 100% 
backwards compatibility.

The GC UL changes would also break existing scripts (such as those 
analyzing pause times, etc), so we are not the only one here.

- Ioi

> Thanks,
> David
>
>> Max
>> On 1/26/2016 3:33 PM, David Holmes wrote:
>>> On 27/01/2016 6:25 AM, Max Ockner wrote:
>>>> I am working on changing the affected tests to look for the proper
>>>> output.
>>>
>>> Late to the party but should we not be trying to maintain the existing
>>> basic format of the log messages so that anyone who already regularly
>>> uses -verbose:class and has scripts etc that check this, will still
>>> see basic things like:
>>>
>>> [Loaded xxx from yyyy]
>>>
>>> ?
>>>
>>> David
>>>
>>>  -Max
>>>>
>>>> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>>> discussions, etc.
>>>>>
>>>>> As the one who looks at these logs and is parsing these for CDS, 
>>>>> thank
>>>>> you for confirming that this is intentional.  Do you really have two
>>>>> different output files for info and debug info?
>>>>>
>>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>>> someone would "fix" because it looks funny.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> This looks pretty good.  It's a large change!  A couple of 
>>>>>>> comments:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>>
>>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>>> }  else
>>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Hi Coleen,
>>>>>>
>>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>>
>>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>>
>>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>>> debug.log will be missing.
>>>>>>
>>>>>> OK, you may say, let's switch the order of the Info and Debug 
>>>>>> checks.
>>>>>> But if you do that, the info.log file will have no content.
>>>>>>
>>>>>> The 'info' level looks like this
>>>>>>
>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>
>>>>>> The 'debug' level looks like this (in a single line):
>>>>>>
>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>>
>>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>>> two parts like this:
>>>>>>
>>>>>>   [info ][classload] java.lang.Object source: ...
>>>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>>
>>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>>> lines, making the output impossible to parse. The ability to parse
>>>>>> the output is very important to tools that analyze the class loading
>>>>>> behavior (e.g., tools related to CDS).
>>>>>>
>>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>>> 'else' in the code you quoted:
>>>>>>
>>>>>>   [info ][classload] java.lang.Object source: ..
>>>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>>
>>>>>> Thanks
>>>>>> - Ioi
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>


From daniel.daugherty at oracle.com  Tue Jan 26 21:47:12 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 26 Jan 2016 14:47:12 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7E138.8000301@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
Message-ID: <56A7E960.7070004@oracle.com>

On 1/26/16 2:12 PM, David Holmes wrote:
> Update ...
>
> On 22/01/2016 6:06 PM, David Holmes wrote:
>> First a special thanks to Martin Buchholz for his input, feedback,
>> critique and raising awareness of how non-simple this issue is.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>> Basic problem:
>>    processors available for use <= processors online <= processors
>> configured
>>
>> but we always returned the number of online processors.
>>
>> Solution is simple in its basic form: use sched_getaffinity to get the
>> scheduling affinity mask and count the number of available processors.
>>
>> Details are complicated by the desire to handle very large processor
>> systems. See the bug report for lots of detailed discussions and
>> references.
>>
>> Testing:
>>   - new test that verifies behaviour when running under taskset
>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>> code paths (one hook is left in for non-product to allow easy testing of
>> the dynamic path)
>
> I have been told that using the development flag UseNewCode in 
> released code is a bad idea because it is used internally during 
> development (as per its defined purpose).
>
> I would like to be able to test the dynamic path easily, but I didn't 
> want to pay the price of adding a new VM option to do it. So choices are:
>
> a) don't do anything (remove the UseNewCode check)
> b) add a new diagnostic flag
> c) add a new experimental flag

My vote:

-XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath

With a plan (and a bug) to remove that option down the road.

And a code review.

src/os/linux/vm/os_linux.cpp
     No comments.

src/share/vm/logging/logTag.hpp
     No comments.

test/runtime/os/AvailableProcessors.java
     Nice test. I like that the default (no args) runs a set of tests
     and if you (manually) run the test with a specific arg it will
     check just that one value.

Thumbs up! (Assuming you change UseNewCode to something else or
delete its use all together.

Dan


>
> Thoughts?
>
> Thanks,
> David
>
>
>>   - JPRT
>>
>> Compatability issues:
>> - the system code we're using now is at least 5 years old so distro's
>> older than that (which are not officially supported) may not work
>> - anyone already running under a processor constrained environment (like
>> Docker) and using availableProcessor() to "size" things, will find that
>> size has now changed. We do not expect this to be a problem - on the
>> contrary we expect Docker users to want the new behaviour.
>>
>> Thanks,
>> David


From david.holmes at oracle.com  Tue Jan 26 22:26:23 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 08:26:23 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7E0A4.6070500@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E0A4.6070500@oracle.com>
Message-ID: <56A7F28F.3030708@oracle.com>

Hi Jerry,

On 27/01/2016 7:09 AM, Gerald Thornbrugh wrote:
> Hi David,
>
> Your code looks good. I do have a question about the test. If I
> understand the test correctly
> the test will be run with no parameters and will use the "taskset"
> command to determine the
> number of processors.
>
> Under what circumstances will the test be run with arguments?

The taskset command runs the test with arguments (the argument being the 
expected number of processors). Notice that I prepend the taskset part 
of the command to the original Java command, then append the expected 
number of processors.

> Was this something you added to allow the verification of the
> "availbleProcessors" method to be done manually?

Yes this allows checking availableProcessors with different numbers of 
processors being available.

Thanks,
David

>
> Jerry
>> First a special thanks to Martin Buchholz for his input, feedback,
>> critique and raising awareness of how non-simple this issue is.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>
>> Basic problem:
>>   processors available for use <= processors online <= processors
>> configured
>>
>> but we always returned the number of online processors.
>>
>> Solution is simple in its basic form: use sched_getaffinity to get the
>> scheduling affinity mask and count the number of available processors.
>>
>> Details are complicated by the desire to handle very large processor
>> systems. See the bug report for lots of detailed discussions and
>> references.
>>
>> Testing:
>>  - new test that verifies behaviour when running under taskset
>>  - diagnostic hook injection (UseNewCodeN) to enable testing of all
>> code paths (one hook is left in for non-product to allow easy testing
>> of the dynamic path)
>>  - JPRT
>>
>> Compatability issues:
>> - the system code we're using now is at least 5 years old so distro's
>> older than that (which are not officially supported) may not work
>> - anyone already running under a processor constrained environment
>> (like Docker) and using availableProcessor() to "size" things, will
>> find that size has now changed. We do not expect this to be a problem
>> - on the contrary we expect Docker users to want the new behaviour.
>>
>> Thanks,
>> David
>

From gerald.thornbrugh at oracle.com  Tue Jan 26 22:27:58 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 26 Jan 2016 15:27:58 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7F28F.3030708@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E0A4.6070500@oracle.com>
	<56A7F28F.3030708@oracle.com>
Message-ID: <56A7F2EE.50800@oracle.com>

Hi David,

Thanks for the information, your code looks good.

Jerry
> Hi Jerry,
>
> On 27/01/2016 7:09 AM, Gerald Thornbrugh wrote:
>> Hi David,
>>
>> Your code looks good. I do have a question about the test. If I
>> understand the test correctly
>> the test will be run with no parameters and will use the "taskset"
>> command to determine the
>> number of processors.
>>
>> Under what circumstances will the test be run with arguments?
>
> The taskset command runs the test with arguments (the argument being 
> the expected number of processors). Notice that I prepend the taskset 
> part of the command to the original Java command, then append the 
> expected number of processors.
>
>> Was this something you added to allow the verification of the
>> "availbleProcessors" method to be done manually?
>
> Yes this allows checking availableProcessors with different numbers of 
> processors being available.
>
> Thanks,
> David
>
>>
>> Jerry
>>> First a special thanks to Martin Buchholz for his input, feedback,
>>> critique and raising awareness of how non-simple this issue is.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>
>>> Basic problem:
>>>   processors available for use <= processors online <= processors
>>> configured
>>>
>>> but we always returned the number of online processors.
>>>
>>> Solution is simple in its basic form: use sched_getaffinity to get the
>>> scheduling affinity mask and count the number of available processors.
>>>
>>> Details are complicated by the desire to handle very large processor
>>> systems. See the bug report for lots of detailed discussions and
>>> references.
>>>
>>> Testing:
>>>  - new test that verifies behaviour when running under taskset
>>>  - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>> code paths (one hook is left in for non-product to allow easy testing
>>> of the dynamic path)
>>>  - JPRT
>>>
>>> Compatability issues:
>>> - the system code we're using now is at least 5 years old so distro's
>>> older than that (which are not officially supported) may not work
>>> - anyone already running under a processor constrained environment
>>> (like Docker) and using availableProcessor() to "size" things, will
>>> find that size has now changed. We do not expect this to be a problem
>>> - on the contrary we expect Docker users to want the new behaviour.
>>>
>>> Thanks,
>>> David
>>


From david.holmes at oracle.com  Tue Jan 26 22:29:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 08:29:29 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7E960.7070004@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com>
Message-ID: <56A7F349.2040200@oracle.com>

Thanks for the Review and vote Dan!

I'll wait to see if there are other opinions, but I'm leaning to adding 
an experimental flag. Not sure about planning for its removal though - 
that will be after 1000+ processor systems are common place :)

Cheers,
David

On 27/01/2016 7:47 AM, Daniel D. Daugherty wrote:
> On 1/26/16 2:12 PM, David Holmes wrote:
>> Update ...
>>
>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>> First a special thanks to Martin Buchholz for his input, feedback,
>>> critique and raising awareness of how non-simple this issue is.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>
>>> Basic problem:
>>>    processors available for use <= processors online <= processors
>>> configured
>>>
>>> but we always returned the number of online processors.
>>>
>>> Solution is simple in its basic form: use sched_getaffinity to get the
>>> scheduling affinity mask and count the number of available processors.
>>>
>>> Details are complicated by the desire to handle very large processor
>>> systems. See the bug report for lots of detailed discussions and
>>> references.
>>>
>>> Testing:
>>>   - new test that verifies behaviour when running under taskset
>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>> code paths (one hook is left in for non-product to allow easy testing of
>>> the dynamic path)
>>
>> I have been told that using the development flag UseNewCode in
>> released code is a bad idea because it is used internally during
>> development (as per its defined purpose).
>>
>> I would like to be able to test the dynamic path easily, but I didn't
>> want to pay the price of adding a new VM option to do it. So choices are:
>>
>> a) don't do anything (remove the UseNewCode check)
>> b) add a new diagnostic flag
>> c) add a new experimental flag
>
> My vote:
>
> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>
> With a plan (and a bug) to remove that option down the road.
>
> And a code review.
>
> src/os/linux/vm/os_linux.cpp
>      No comments.
>
> src/share/vm/logging/logTag.hpp
>      No comments.
>
> test/runtime/os/AvailableProcessors.java
>      Nice test. I like that the default (no args) runs a set of tests
>      and if you (manually) run the test with a specific arg it will
>      check just that one value.
>
> Thumbs up! (Assuming you change UseNewCode to something else or
> delete its use all together.
>
> Dan
>
>
>>
>> Thoughts?
>>
>> Thanks,
>> David
>>
>>
>>>   - JPRT
>>>
>>> Compatability issues:
>>> - the system code we're using now is at least 5 years old so distro's
>>> older than that (which are not officially supported) may not work
>>> - anyone already running under a processor constrained environment (like
>>> Docker) and using availableProcessor() to "size" things, will find that
>>> size has now changed. We do not expect this to be a problem - on the
>>> contrary we expect Docker users to want the new behaviour.
>>>
>>> Thanks,
>>> David
>

From ioi.lam at oracle.com  Tue Jan 26 22:58:46 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 26 Jan 2016 14:58:46 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7C798.2040102@oracle.com>
References: <568F60E4.50609@oracle.com>
	<56904C26.1010207@oracle.com>	<569068ED.6070509@oracle.com>
	<56A1763E.5030506@oracle.com>	<56A67E5E.3030208@oracle.com>
	<56A704B3.80100@oracle.com> <56A7C798.2040102@oracle.com>
Message-ID: <56A7FA26.1010306@oracle.com>



On 1/26/16 11:23 AM, Coleen Phillimore wrote:
>
> Thanks for recapping the decision.  I didn't remember it from all our 
> discussions, etc.
>
> As the one who looks at these logs and is parsing these for CDS, thank 
> you for confirming that this is intentional.  Do you really have two 
> different output files for info and debug info?

Here's an example:

$ *java -Xlog:gc=trace:file=trace.log -Xlog:gc=info:file=info.log -version*
java version "9-internal"
Java(TM) SE Runtime Environment (build 
9-internal+0-2016-01-20-150959.iklam.jdk9rt)
Java HotSpot(TM) 64-Bit Server VM (build 
9-internal+0-2016-01-20-150959.iklam.jdk9rt, mixed mode)

$*cat trace.log*
[0.002s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
[0.002s][trace  ][gc] ConcGCThreads: 0
[0.122s][info   ][gc] Using G1
[0.001s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
[0.001s][trace  ][gc] ConcGCThreads: 0
[0.102s][info   ][gc] Using G1

$ *cat info.log*
[0.102s][info   ][gc] Using G1

(There's a bug that trace.log has duplicated entries but I think that 
might be already fixed).

>
> Max/Ioi can you add a comment to the code.  This looks easily like 
> someone would "fix" because it looks funny.
>

Since we have 2 blocks of these two statements in two separate files,

if (log_is_enabled(Info, classload)) {
   ik->print_loading_log(LogLevel::Info, _loader_data, _stream);
}
if (log_is_enabled(Debug, classload)) {
   ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);
}

I think it's better to consolidate them into a function inside 
instanceKlass.cpp, like:

InstanceKlass::print_loading_log(loader, stream) {
   if (log_is_enabled(Info, classload)) {
     print_loading_log(LogLevel::Info, loader_data, stream);
   }
   // Do NOT put an 'else' here, so that the following command would
   // work as expected.
   //
   // java -Xlog:classload=info:file=info.log \
   //      -Xlog:classload=debug:file=debug.log MainClass
   if (log_is_enabled(Debug, classload)) {
     print_loading_log(LogLevel::Debug, loader_data, stream);
   }
}

Thanks
- Ioi

> Thanks,
> Coleen
>
> On 1/26/16 12:31 AM, Ioi Lam wrote:
>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>
>>> Hi Max,
>>>
>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>
>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html 
>>>
>>>
>>> As Harold pointed out earlier this change should check for 'else'.
>>>
>>> *!if (_log_is_enabled(Info, classload)_) {*
>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>> }  else
>>> *+ if (log_is_enabled(Debug, classload)) {*
>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>> }
>>>
>>
>> Hi Coleen,
>>
>> The case for the 'else' has been discussed before. Please refer to
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html 
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html 
>>
>>
>> To recap: the reason for NOT having the 'else' is for:
>>
>> java -cp ~/tmp -Xlog:classload=info:file=info.log 
>> -Xlog:classload=debug:file=debug.log Foo
>>
>> If you add the 'else' there,  the debug-level output intended for 
>> debug.log will be missing.
>>
>> OK, you may say, let's switch the order of the Info and Debug checks. 
>> But if you do that, the info.log file will have no content.
>>
>> The 'info' level looks like this
>>
>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>
>> The 'debug' level looks like this (in a single line):
>>
>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>
>> Because UL buffers at the line level, I cannot split the output into 
>> two parts like this:
>>
>>   [info ][classload] java.lang.Object source: ...
>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>
>> Otherwise some unrelated output may be interleaved between the two 
>> lines, making the output impossible to parse. The ability to parse 
>> the output is very important to tools that analyze the class loading 
>> behavior (e.g., tools related to CDS).
>>
>> Due to this limitation of UL, I think our only choice is to repeat 
>> the class name and 'source' in both info and debug levels, hence NO 
>> 'else' in the code you quoted:
>>
>>   [info ][classload] java.lang.Object source: ..
>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>
>> Thanks
>> - Ioi
>>
>>
>>
>


From gerald.thornbrugh at oracle.com  Tue Jan 26 23:20:24 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 26 Jan 2016 16:20:24 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7E960.7070004@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com>
Message-ID: <56A7FF38.4030501@oracle.com>

Hi David,

I also like the idea of using an "-XX" option, that seems like the best 
way to go.

I am ok with leaving the code in.  If there are any issues with the code 
we can always
create a bug and remove it.

Jerry
> On 1/26/16 2:12 PM, David Holmes wrote:
>> Update ...
>>
>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>> First a special thanks to Martin Buchholz for his input, feedback,
>>> critique and raising awareness of how non-simple this issue is.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>
>>> Basic problem:
>>>    processors available for use <= processors online <= processors
>>> configured
>>>
>>> but we always returned the number of online processors.
>>>
>>> Solution is simple in its basic form: use sched_getaffinity to get the
>>> scheduling affinity mask and count the number of available processors.
>>>
>>> Details are complicated by the desire to handle very large processor
>>> systems. See the bug report for lots of detailed discussions and
>>> references.
>>>
>>> Testing:
>>>   - new test that verifies behaviour when running under taskset
>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>> code paths (one hook is left in for non-product to allow easy 
>>> testing of
>>> the dynamic path)
>>
>> I have been told that using the development flag UseNewCode in 
>> released code is a bad idea because it is used internally during 
>> development (as per its defined purpose).
>>
>> I would like to be able to test the dynamic path easily, but I didn't 
>> want to pay the price of adding a new VM option to do it. So choices 
>> are:
>>
>> a) don't do anything (remove the UseNewCode check)
>> b) add a new diagnostic flag
>> c) add a new experimental flag
>
> My vote:
>
> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>
> With a plan (and a bug) to remove that option down the road.
>
> And a code review.
>
> src/os/linux/vm/os_linux.cpp
>     No comments.
>
> src/share/vm/logging/logTag.hpp
>     No comments.
>
> test/runtime/os/AvailableProcessors.java
>     Nice test. I like that the default (no args) runs a set of tests
>     and if you (manually) run the test with a specific arg it will
>     check just that one value.
>
> Thumbs up! (Assuming you change UseNewCode to something else or
> delete its use all together.
>
> Dan
>
>
>>
>> Thoughts?
>>
>> Thanks,
>> David
>>
>>
>>>   - JPRT
>>>
>>> Compatability issues:
>>> - the system code we're using now is at least 5 years old so distro's
>>> older than that (which are not officially supported) may not work
>>> - anyone already running under a processor constrained environment 
>>> (like
>>> Docker) and using availableProcessor() to "size" things, will find that
>>> size has now changed. We do not expect this to be a problem - on the
>>> contrary we expect Docker users to want the new behaviour.
>>>
>>> Thanks,
>>> David
>


From david.holmes at oracle.com  Tue Jan 26 23:53:04 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 09:53:04 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7FA26.1010306@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7FA26.1010306@oracle.com>
Message-ID: <56A806E0.8030105@oracle.com>

On 27/01/2016 8:58 AM, Ioi Lam wrote:
>
>
> On 1/26/16 11:23 AM, Coleen Phillimore wrote:
>>
>> Thanks for recapping the decision.  I didn't remember it from all our
>> discussions, etc.
>>
>> As the one who looks at these logs and is parsing these for CDS, thank
>> you for confirming that this is intentional.  Do you really have two
>> different output files for info and debug info?
>
> Here's an example:
>
> $ *java -Xlog:gc=trace:file=trace.log -Xlog:gc=info:file=info.log -version*
> java version "9-internal"
> Java(TM) SE Runtime Environment (build
> 9-internal+0-2016-01-20-150959.iklam.jdk9rt)
> Java HotSpot(TM) 64-Bit Server VM (build
> 9-internal+0-2016-01-20-150959.iklam.jdk9rt, mixed mode)
>
> $*cat trace.log*
> [0.002s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
> [0.002s][trace  ][gc] ConcGCThreads: 0
> [0.122s][info   ][gc] Using G1
> [0.001s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
> [0.001s][trace  ][gc] ConcGCThreads: 0
> [0.102s][info   ][gc] Using G1
>
> $ *cat info.log*
> [0.102s][info   ][gc] Using G1
>
> (There's a bug that trace.log has duplicated entries but I think that
> might be already fixed).
>
>>
>> Max/Ioi can you add a comment to the code.  This looks easily like
>> someone would "fix" because it looks funny.
>>
>
> Since we have 2 blocks of these two statements in two separate files,
>
> if (log_is_enabled(Info, classload)) {
>    ik->print_loading_log(LogLevel::Info, _loader_data, _stream);
> }
> if (log_is_enabled(Debug, classload)) {
>    ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);
> }
>
> I think it's better to consolidate them into a function inside
> instanceKlass.cpp, like:
>
> InstanceKlass::print_loading_log(loader, stream) {
>    if (log_is_enabled(Info, classload)) {
>      print_loading_log(LogLevel::Info, loader_data, stream);
>    }
>    // Do NOT put an 'else' here, so that the following command would
>    // work as expected.
>    //
>    // java -Xlog:classload=info:file=info.log \
>    //      -Xlog:classload=debug:file=debug.log MainClass
>    if (log_is_enabled(Debug, classload)) {
>      print_loading_log(LogLevel::Debug, loader_data, stream);
>    }

I don't think we need to be so explanatory here, a simple:

   // Not 'else' here as logging levels are not mutually exclusive

should suffice.

David

> }
>
> Thanks
> - Ioi
>
>> Thanks,
>> Coleen
>>
>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>
>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>
>>>>
>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>
>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>> }  else
>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>> }
>>>>
>>>
>>> Hi Coleen,
>>>
>>> The case for the 'else' has been discussed before. Please refer to
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>
>>>
>>> To recap: the reason for NOT having the 'else' is for:
>>>
>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>> -Xlog:classload=debug:file=debug.log Foo
>>>
>>> If you add the 'else' there,  the debug-level output intended for
>>> debug.log will be missing.
>>>
>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>> But if you do that, the info.log file will have no content.
>>>
>>> The 'info' level looks like this
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>
>>> The 'debug' level looks like this (in a single line):
>>>
>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>
>>> Because UL buffers at the line level, I cannot split the output into
>>> two parts like this:
>>>
>>>   [info ][classload] java.lang.Object source: ...
>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>
>>> Otherwise some unrelated output may be interleaved between the two
>>> lines, making the output impossible to parse. The ability to parse
>>> the output is very important to tools that analyze the class loading
>>> behavior (e.g., tools related to CDS).
>>>
>>> Due to this limitation of UL, I think our only choice is to repeat
>>> the class name and 'source' in both info and debug levels, hence NO
>>> 'else' in the code you quoted:
>>>
>>>   [info ][classload] java.lang.Object source: ..
>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>
>

From david.holmes at oracle.com  Tue Jan 26 23:56:31 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 09:56:31 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A7E79F.1040806@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7D653.7010504@oracle.com>
	<56A7D815.3000205@oracle.com> <56A7DAA4.9050800@oracle.com>
	<56A7DB9E.6050201@oracle.com> <56A7E79F.1040806@oracle.com>
Message-ID: <56A807AF.40403@oracle.com>

On 27/01/2016 7:39 AM, Ioi Lam wrote:
>
>
> On 1/26/16 12:48 PM, David Holmes wrote:
>> On 27/01/2016 6:44 AM, Max Ockner wrote:
>>> David,
>>> In general, we want to keep logging messages the same as before. This
>>> fix contains changes to the logging output as well.
>>
>> Why are we changing the logging output? And why mix the two changes?
>>
>
> David,
>
> OLD:
>
> [Loaded xxx from yyyy]
>
> NEW:
>
> [info ][classload] xxx source: yyyy
>
> Keeping the "Loaded" there seems superfluous. It would look like
>
> [info ][classload] Loaded xxx source: yyyy
>
> The point of UL is to remove the need for ad-hoc tags such as "Loaded".
>
> Also, the original [] brackets are inconsistent with the UL style, so
> they are removed.
>
> I think it's better to change over to the new UL style rather than
> keeping the older odd style. Even if we don't, the addition of the
> [info][classload] characters would break some scripts anyway (e.g., my
> old scripts would grep for "*^\\[Loaded*" , so we can't get 100%
> backwards compatibility.
>
> The GC UL changes would also break existing scripts (such as those
> analyzing pause times, etc), so we are not the only one here.

Well I hope there will be a lot of documentation/release-note entries 
about the impact of UL.

Thanks,
David
-----

> - Ioi
>
>> Thanks,
>> David
>>
>>> Max
>>> On 1/26/2016 3:33 PM, David Holmes wrote:
>>>> On 27/01/2016 6:25 AM, Max Ockner wrote:
>>>>> I am working on changing the affected tests to look for the proper
>>>>> output.
>>>>
>>>> Late to the party but should we not be trying to maintain the existing
>>>> basic format of the log messages so that anyone who already regularly
>>>> uses -verbose:class and has scripts etc that check this, will still
>>>> see basic things like:
>>>>
>>>> [Loaded xxx from yyyy]
>>>>
>>>> ?
>>>>
>>>> David
>>>>
>>>>  -Max
>>>>>
>>>>> On 1/26/2016 2:23 PM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>>>> discussions, etc.
>>>>>>
>>>>>> As the one who looks at these logs and is parsing these for CDS,
>>>>>> thank
>>>>>> you for confirming that this is intentional.  Do you really have two
>>>>>> different output files for info and debug info?
>>>>>>
>>>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>>>> someone would "fix" because it looks funny.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>>>
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> This looks pretty good.  It's a large change!  A couple of
>>>>>>>> comments:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>>>
>>>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>>>> }  else
>>>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> Hi Coleen,
>>>>>>>
>>>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>>>
>>>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>>>
>>>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>>>> debug.log will be missing.
>>>>>>>
>>>>>>> OK, you may say, let's switch the order of the Info and Debug
>>>>>>> checks.
>>>>>>> But if you do that, the info.log file will have no content.
>>>>>>>
>>>>>>> The 'info' level looks like this
>>>>>>>
>>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>>
>>>>>>> The 'debug' level looks like this (in a single line):
>>>>>>>
>>>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>>>
>>>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>>>> two parts like this:
>>>>>>>
>>>>>>>   [info ][classload] java.lang.Object source: ...
>>>>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>>>
>>>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>>>> lines, making the output impossible to parse. The ability to parse
>>>>>>> the output is very important to tools that analyze the class loading
>>>>>>> behavior (e.g., tools related to CDS).
>>>>>>>
>>>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>>>> 'else' in the code you quoted:
>>>>>>>
>>>>>>>   [info ][classload] java.lang.Object source: ..
>>>>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>>>
>>>>>>> Thanks
>>>>>>> - Ioi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

From ioi.lam at oracle.com  Wed Jan 27 00:20:06 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 26 Jan 2016 16:20:06 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A806E0.8030105@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7FA26.1010306@oracle.com>
	<56A806E0.8030105@oracle.com>
Message-ID: <D00CF697-C4EA-46FC-8535-013D4FF22060@oracle.com>



> On Jan 26, 2016, at 3:53 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 27/01/2016 8:58 AM, Ioi Lam wrote:
>> 
>> 
>>> On 1/26/16 11:23 AM, Coleen Phillimore wrote:
>>> 
>>> Thanks for recapping the decision.  I didn't remember it from all our
>>> discussions, etc.
>>> 
>>> As the one who looks at these logs and is parsing these for CDS, thank
>>> you for confirming that this is intentional.  Do you really have two
>>> different output files for info and debug info?
>> 
>> Here's an example:
>> 
>> $ *java -Xlog:gc=trace:file=trace.log -Xlog:gc=info:file=info.log -version*
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (build
>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt)
>> Java HotSpot(TM) 64-Bit Server VM (build
>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt, mixed mode)
>> 
>> $*cat trace.log*
>> [0.002s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>> [0.002s][trace  ][gc] ConcGCThreads: 0
>> [0.122s][info   ][gc] Using G1
>> [0.001s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>> [0.001s][trace  ][gc] ConcGCThreads: 0
>> [0.102s][info   ][gc] Using G1
>> 
>> $ *cat info.log*
>> [0.102s][info   ][gc] Using G1
>> 
>> (There's a bug that trace.log has duplicated entries but I think that
>> might be already fixed).
>> 
>>> 
>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>> someone would "fix" because it looks funny.
>> 
>> Since we have 2 blocks of these two statements in two separate files,
>> 
>> if (log_is_enabled(Info, classload)) {
>>   ik->print_loading_log(LogLevel::Info, _loader_data, _stream);
>> }
>> if (log_is_enabled(Debug, classload)) {
>>   ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);
>> }
>> 
>> I think it's better to consolidate them into a function inside
>> instanceKlass.cpp, like:
>> 
>> InstanceKlass::print_loading_log(loader, stream) {
>>   if (log_is_enabled(Info, classload)) {
>>     print_loading_log(LogLevel::Info, loader_data, stream);
>>   }
>>   // Do NOT put an 'else' here, so that the following command would
>>   // work as expected.
>>   //
>>   // java -Xlog:classload=info:file=info.log \
>>   //      -Xlog:classload=debug:file=debug.log MainClass
>>   if (log_is_enabled(Debug, classload)) {
>>     print_loading_log(LogLevel::Debug, loader_data, stream);
>>   }
> 
> I don't think we need to be so explanatory here, a simple:
> 
>  // Not 'else' here as logging levels are not mutually exclusive
> 
> should suffice.
> 

Conciseness would be good, but I am not sure if the above is clear or correct. -Xlog:classload=debug implies outputs from the info level as well, so they are not mutually exclusive.

UL is nice in many ways, but it's just not as easy to explain as: here's a Boolean variable :-(



> David
> 
>> }
>> 
>> Thanks
>> - Ioi
>> 
>>> Thanks,
>>> Coleen
>>> 
>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>> 
>>>>> Hi Max,
>>>>> 
>>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>> 
>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>> 
>>>>> 
>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>> 
>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>> }  else
>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>> }
>>>> 
>>>> Hi Coleen,
>>>> 
>>>> The case for the 'else' has been discussed before. Please refer to
>>>> 
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>> 
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>> 
>>>> 
>>>> To recap: the reason for NOT having the 'else' is for:
>>>> 
>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>> -Xlog:classload=debug:file=debug.log Foo
>>>> 
>>>> If you add the 'else' there,  the debug-level output intended for
>>>> debug.log will be missing.
>>>> 
>>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>>> But if you do that, the info.log file will have no content.
>>>> 
>>>> The 'info' level looks like this
>>>> 
>>>>  java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>> 
>>>> The 'debug' level looks like this (in a single line):
>>>> 
>>>>  java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>  klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>  loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>> 
>>>> Because UL buffers at the line level, I cannot split the output into
>>>> two parts like this:
>>>> 
>>>>  [info ][classload] java.lang.Object source: ...
>>>>  [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>> 
>>>> Otherwise some unrelated output may be interleaved between the two
>>>> lines, making the output impossible to parse. The ability to parse
>>>> the output is very important to tools that analyze the class loading
>>>> behavior (e.g., tools related to CDS).
>>>> 
>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>> the class name and 'source' in both info and debug levels, hence NO
>>>> 'else' in the code you quoted:
>>>> 
>>>>  [info ][classload] java.lang.Object source: ..
>>>>  [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>> 
>>>> Thanks
>>>> - Ioi
>> 

From david.holmes at oracle.com  Wed Jan 27 00:26:09 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 10:26:09 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <D00CF697-C4EA-46FC-8535-013D4FF22060@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7FA26.1010306@oracle.com>
	<56A806E0.8030105@oracle.com>
	<D00CF697-C4EA-46FC-8535-013D4FF22060@oracle.com>
Message-ID: <56A80EA1.5060308@oracle.com>

On 27/01/2016 10:20 AM, Ioi Lam wrote:
>
>
>> On Jan 26, 2016, at 3:53 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 27/01/2016 8:58 AM, Ioi Lam wrote:
>>>
>>>
>>>> On 1/26/16 11:23 AM, Coleen Phillimore wrote:
>>>>
>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>> discussions, etc.
>>>>
>>>> As the one who looks at these logs and is parsing these for CDS, thank
>>>> you for confirming that this is intentional.  Do you really have two
>>>> different output files for info and debug info?
>>>
>>> Here's an example:
>>>
>>> $ *java -Xlog:gc=trace:file=trace.log -Xlog:gc=info:file=info.log -version*
>>> java version "9-internal"
>>> Java(TM) SE Runtime Environment (build
>>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt)
>>> Java HotSpot(TM) 64-Bit Server VM (build
>>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt, mixed mode)
>>>
>>> $*cat trace.log*
>>> [0.002s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>>> [0.002s][trace  ][gc] ConcGCThreads: 0
>>> [0.122s][info   ][gc] Using G1
>>> [0.001s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>>> [0.001s][trace  ][gc] ConcGCThreads: 0
>>> [0.102s][info   ][gc] Using G1
>>>
>>> $ *cat info.log*
>>> [0.102s][info   ][gc] Using G1
>>>
>>> (There's a bug that trace.log has duplicated entries but I think that
>>> might be already fixed).
>>>
>>>>
>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>> someone would "fix" because it looks funny.
>>>
>>> Since we have 2 blocks of these two statements in two separate files,
>>>
>>> if (log_is_enabled(Info, classload)) {
>>>    ik->print_loading_log(LogLevel::Info, _loader_data, _stream);
>>> }
>>> if (log_is_enabled(Debug, classload)) {
>>>    ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);
>>> }
>>>
>>> I think it's better to consolidate them into a function inside
>>> instanceKlass.cpp, like:
>>>
>>> InstanceKlass::print_loading_log(loader, stream) {
>>>    if (log_is_enabled(Info, classload)) {
>>>      print_loading_log(LogLevel::Info, loader_data, stream);
>>>    }
>>>    // Do NOT put an 'else' here, so that the following command would
>>>    // work as expected.
>>>    //
>>>    // java -Xlog:classload=info:file=info.log \
>>>    //      -Xlog:classload=debug:file=debug.log MainClass
>>>    if (log_is_enabled(Debug, classload)) {
>>>      print_loading_log(LogLevel::Debug, loader_data, stream);
>>>    }
>>
>> I don't think we need to be so explanatory here, a simple:
>>
>>   // Not 'else' here as logging levels are not mutually exclusive
>>
>> should suffice.
>>
>
> Conciseness would be good, but I am not sure if the above is clear or correct. -Xlog:classload=debug implies outputs from the info level as well, so they are not mutually exclusive.

Yes that is what I said "logging levels are not mutually exclusive". 
Hence it isn't either/or, and so not if/else.

David

> UL is nice in many ways, but it's just not as easy to explain as: here's a Boolean variable :-(
>
>
>
>> David
>>
>>> }
>>>
>>> Thanks
>>> - Ioi
>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>>>
>>>>>>
>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>
>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>> }  else
>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>> }
>>>>>
>>>>> Hi Coleen,
>>>>>
>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>>>
>>>>>
>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>
>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>
>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>> debug.log will be missing.
>>>>>
>>>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>>>> But if you do that, the info.log file will have no content.
>>>>>
>>>>> The 'info' level looks like this
>>>>>
>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>
>>>>> The 'debug' level looks like this (in a single line):
>>>>>
>>>>>   java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>   klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>   loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>
>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>> two parts like this:
>>>>>
>>>>>   [info ][classload] java.lang.Object source: ...
>>>>>   [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>
>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>> lines, making the output impossible to parse. The ability to parse
>>>>> the output is very important to tools that analyze the class loading
>>>>> behavior (e.g., tools related to CDS).
>>>>>
>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>> 'else' in the code you quoted:
>>>>>
>>>>>   [info ][classload] java.lang.Object source: ..
>>>>>   [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>

From ioi.lam at oracle.com  Wed Jan 27 00:42:44 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 26 Jan 2016 16:42:44 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A80EA1.5060308@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A67E5E.3030208@oracle.com> <56A704B3.80100@oracle.com>
	<56A7C798.2040102@oracle.com> <56A7FA26.1010306@oracle.com>
	<56A806E0.8030105@oracle.com>
	<D00CF697-C4EA-46FC-8535-013D4FF22060@oracle.com>
	<56A80EA1.5060308@oracle.com>
Message-ID: <7B5E3D20-5007-4DCE-A304-314D71751E27@oracle.com>



> On Jan 26, 2016, at 4:26 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 27/01/2016 10:20 AM, Ioi Lam wrote:
>> 
>> 
>>>> On Jan 26, 2016, at 3:53 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> On 27/01/2016 8:58 AM, Ioi Lam wrote:
>>>> 
>>>> 
>>>>> On 1/26/16 11:23 AM, Coleen Phillimore wrote:
>>>>> 
>>>>> Thanks for recapping the decision.  I didn't remember it from all our
>>>>> discussions, etc.
>>>>> 
>>>>> As the one who looks at these logs and is parsing these for CDS, thank
>>>>> you for confirming that this is intentional.  Do you really have two
>>>>> different output files for info and debug info?
>>>> 
>>>> Here's an example:
>>>> 
>>>> $ *java -Xlog:gc=trace:file=trace.log -Xlog:gc=info:file=info.log -version*
>>>> java version "9-internal"
>>>> Java(TM) SE Runtime Environment (build
>>>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt)
>>>> Java HotSpot(TM) 64-Bit Server VM (build
>>>> 9-internal+0-2016-01-20-150959.iklam.jdk9rt, mixed mode)
>>>> 
>>>> $*cat trace.log*
>>>> [0.002s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>>>> [0.002s][trace  ][gc] ConcGCThreads: 0
>>>> [0.122s][info   ][gc] Using G1
>>>> [0.001s][trace  ][gc] MarkStackSize: 4096k  MarkStackSizeMax: 16384k
>>>> [0.001s][trace  ][gc] ConcGCThreads: 0
>>>> [0.102s][info   ][gc] Using G1
>>>> 
>>>> $ *cat info.log*
>>>> [0.102s][info   ][gc] Using G1
>>>> 
>>>> (There's a bug that trace.log has duplicated entries but I think that
>>>> might be already fixed).
>>>> 
>>>>> 
>>>>> Max/Ioi can you add a comment to the code.  This looks easily like
>>>>> someone would "fix" because it looks funny.
>>>> 
>>>> Since we have 2 blocks of these two statements in two separate files,
>>>> 
>>>> if (log_is_enabled(Info, classload)) {
>>>>   ik->print_loading_log(LogLevel::Info, _loader_data, _stream);
>>>> }
>>>> if (log_is_enabled(Debug, classload)) {
>>>>   ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);
>>>> }
>>>> 
>>>> I think it's better to consolidate them into a function inside
>>>> instanceKlass.cpp, like:
>>>> 
>>>> InstanceKlass::print_loading_log(loader, stream) {
>>>>   if (log_is_enabled(Info, classload)) {
>>>>     print_loading_log(LogLevel::Info, loader_data, stream);
>>>>   }
>>>>   // Do NOT put an 'else' here, so that the following command would
>>>>   // work as expected.
>>>>   //
>>>>   // java -Xlog:classload=info:file=info.log \
>>>>   //      -Xlog:classload=debug:file=debug.log MainClass
>>>>   if (log_is_enabled(Debug, classload)) {
>>>>     print_loading_log(LogLevel::Debug, loader_data, stream);
>>>>   }
>>> 
>>> I don't think we need to be so explanatory here, a simple:
>>> 
>>>  // Not 'else' here as logging levels are not mutually exclusive
>>> 
>>> should suffice.
>> 
>> Conciseness would be good, but I am not sure if the above is clear or correct. -Xlog:classload=debug implies outputs from the info level as well, so they are not mutually exclusive.
> 
> Yes that is what I said "logging levels are not mutually exclusive". Hence it isn't either/or, and so not if/else.
> 

Oh I missed the 'not'. Need a bigger iPhone!


> David
> 
>> UL is nice in many ways, but it's just not as easy to explain as: here's a Boolean variable :-(
>> 
>> 
>> 
>>> David
>>> 
>>>> }
>>>> 
>>>> Thanks
>>>> - Ioi
>>>> 
>>>>> Thanks,
>>>>> Coleen
>>>>> 
>>>>>>> On 1/26/16 12:31 AM, Ioi Lam wrote:
>>>>>>> On 1/25/16 11:58 AM, Coleen Phillimore wrote:
>>>>>>> 
>>>>>>> Hi Max,
>>>>>>> 
>>>>>>> This looks pretty good.  It's a large change!  A couple of comments:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~mockner/classload.03/src/share/vm/classfile/classFileParser.cpp.udiff.html
>>>>>>> 
>>>>>>> 
>>>>>>> As Harold pointed out earlier this change should check for 'else'.
>>>>>>> 
>>>>>>> *!if (_log_is_enabled(Info, classload)_) {*
>>>>>>> *!_ik->print_loading_log(LogLevel::Info, _loader_data, _stream)_;*
>>>>>>> }  else
>>>>>>> *+ if (log_is_enabled(Debug, classload)) {*
>>>>>>> *+ ik->print_loading_log(LogLevel::Debug, _loader_data, _stream);*
>>>>>>> }
>>>>>> 
>>>>>> Hi Coleen,
>>>>>> 
>>>>>> The case for the 'else' has been discussed before. Please refer to
>>>>>> 
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016460.html
>>>>>> 
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016904.html
>>>>>> 
>>>>>> 
>>>>>> To recap: the reason for NOT having the 'else' is for:
>>>>>> 
>>>>>> java -cp ~/tmp -Xlog:classload=info:file=info.log
>>>>>> -Xlog:classload=debug:file=debug.log Foo
>>>>>> 
>>>>>> If you add the 'else' there,  the debug-level output intended for
>>>>>> debug.log will be missing.
>>>>>> 
>>>>>> OK, you may say, let's switch the order of the Info and Debug checks.
>>>>>> But if you do that, the info.log file will have no content.
>>>>>> 
>>>>>> The 'info' level looks like this
>>>>>> 
>>>>>>  java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>> 
>>>>>> The 'debug' level looks like this (in a single line):
>>>>>> 
>>>>>>  java.lang.Object source: /jdk/lib/modules/bootmodules.jimage
>>>>>>  klass: 0x00000007c0000fb0 super: 0x0000000000000000
>>>>>>  loader: [NULL class_loader] bytes: 1640 checksum: ddb8a6f3
>>>>>> 
>>>>>> Because UL buffers at the line level, I cannot split the output into
>>>>>> two parts like this:
>>>>>> 
>>>>>>  [info ][classload] java.lang.Object source: ...
>>>>>>  [debug][classload] klass: 0x00000007c0000fb0 super: ...
>>>>>> 
>>>>>> Otherwise some unrelated output may be interleaved between the two
>>>>>> lines, making the output impossible to parse. The ability to parse
>>>>>> the output is very important to tools that analyze the class loading
>>>>>> behavior (e.g., tools related to CDS).
>>>>>> 
>>>>>> Due to this limitation of UL, I think our only choice is to repeat
>>>>>> the class name and 'source' in both info and debug levels, hence NO
>>>>>> 'else' in the code you quoted:
>>>>>> 
>>>>>>  [info ][classload] java.lang.Object source: ..
>>>>>>  [debug][classload] java.lang.Object source: .. klass: .. super: ..
>>>>>> 
>>>>>> Thanks
>>>>>> - Ioi
>>>> 

From david.holmes at oracle.com  Wed Jan 27 05:27:02 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 15:27:02 +1000
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
	<CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
	<CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>
Message-ID: <56A85526.1050107@oracle.com>

Hi Thomas,

On 20/01/2016 7:29 PM, Thomas St?fe wrote:
> Thank you Volker!
>
> Still need a second reviewer, and once hs-rt is open again I'll need a
> sponsor too.

Sorry for the delay ... I can sponsor this for you.

Overall looks okay - took me a little while to wrap my head around it.

src/share/vm/utilities/ostream.hpp

Typo:  // Caller may specify an own scratch buffer

an -> their

---

Please update copyright years.

---

What testing have you done for this? Is it sufficient to generate some 
crash logs and validate the content is the same before and after this fix?

Thanks,
David
----


> Kind Regards, Thomas
>
> On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Thomas,
>>
>> thanks for doing this nice cleanup.
>>
>> The change looks good. Can you please just adapt the comment at line
>> 987 and remove the reference to staticBufferStream from there as well.
>>
>> Regards,
>> Volker
>>
>>
>> On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>> May I please have a review for this? Thanks!
>>>
>>> On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> please take a look at this small cleanup of ostream.
>>>>
>>>> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
>>>> webrev:
>>>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>>>>
>>>> Basically, it gets rid of the staticBufferStream class by moving its one
>>>> feature up to the parent outputStream class:
>>>>
>>>> When printing the error log in vmError.cpp, we want to use as little
>> stack
>>>> space as possible. outputStream class uses on-stack buffers to assemble
>>>> snprintf functions. So, staticBufferStream was introduced as a child of
>>>> outputStream which overwrites the print functions and makes them use a
>>>> caller provided buffer. It then delegates the real writing to a
>> connected
>>>> stream object.
>>>>
>>>> The problem with that approach is that this is not a good fit for a
>> child
>>>> class.Not all operations possible with outputStream are cleanly
>> delegated
>>>> to the connected stream class, so a staticBufferStream behaves sometimes
>>>> differently from all other streams (see e.g. JDK-8145410, which will be
>>>> automatically fixed with this change too).
>>>>
>>>> Another problem is that this delegation model leads to some code
>>>> duplication, because all print() methods of outputStream are practically
>>>> duplicated in staticBufferStream.
>>>>
>>>> Another cosmetic note is that all other child classes of outputStream
>>>> (bufferedStream, stringStream, fileStream...) are specializations in
>> term
>>>> of log destination, not internal behaviour.
>>>>
>>>> Note that I implemented this in a very simple way without using
>> templates,
>>>> because I wanted to keep the changes as small as possible.
>>>>
>>>> Kind Regards, Thomas
>>>>
>>

From david.holmes at oracle.com  Wed Jan 27 05:44:35 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 15:44:35 +1000
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
Message-ID: <56A85943.5050505@oracle.com>

Hi Thomas,

On 20/01/2016 5:53 PM, Thomas St?fe wrote:
> May I please have a review and a sponsor?
>
> Thank you!
>
> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi,
>>
>> could I please have reviews and a sponsor for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>
>> When we print register to memory info in hs-err file, text addresses are
>> not resolved on windows like on other platforms:
>>
>> "RCX=0x000000005efa0000 is an unknown value"
>>
>> This fix changes this (the same way it is implemented on other platforms):

In the sense that something is better than nothing this seems okay, but 
I have to wonder why the other OS do what they do in os::find and don't 
call os::dll_address_to_library_name? I'm not an expert on dll querying 
on any platform.

Thanks,
David
-----

>>
>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>> 0"
>>
>> Please note that this printout and the code behind it could be improved
>> and cleaned up a lot. For instance, I know that using an on-stack buffer in
>> os::find() is not the best implementation here. But I wanted a minimal
>> change. For the follow-up work, I opened a new bug:
>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>
>> Thanks & Regards, Thomas
>>
>>
>>
>>

From david.holmes at oracle.com  Wed Jan 27 07:16:28 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2016 17:16:28 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A7FF38.4030501@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
Message-ID: <56A86ECC.5060002@oracle.com>

Okay here is v2:

http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/

- UseNewCode is replaced by a new experimental flag UseCpuAllocPath
- the logging statement shows whether the path was forced to be taken
- this is now enabled in product builds

Sorry I don't know how to generate an incremental webrev when working 
with uncommitted changes. :(

Thanks,
David

On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
> Hi David,
>
> I also like the idea of using an "-XX" option, that seems like the best
> way to go.
>
> I am ok with leaving the code in.  If there are any issues with the code
> we can always
> create a bug and remove it.
>
> Jerry
>> On 1/26/16 2:12 PM, David Holmes wrote:
>>> Update ...
>>>
>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>> critique and raising awareness of how non-simple this issue is.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>
>>>> Basic problem:
>>>>    processors available for use <= processors online <= processors
>>>> configured
>>>>
>>>> but we always returned the number of online processors.
>>>>
>>>> Solution is simple in its basic form: use sched_getaffinity to get the
>>>> scheduling affinity mask and count the number of available processors.
>>>>
>>>> Details are complicated by the desire to handle very large processor
>>>> systems. See the bug report for lots of detailed discussions and
>>>> references.
>>>>
>>>> Testing:
>>>>   - new test that verifies behaviour when running under taskset
>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>>> code paths (one hook is left in for non-product to allow easy
>>>> testing of
>>>> the dynamic path)
>>>
>>> I have been told that using the development flag UseNewCode in
>>> released code is a bad idea because it is used internally during
>>> development (as per its defined purpose).
>>>
>>> I would like to be able to test the dynamic path easily, but I didn't
>>> want to pay the price of adding a new VM option to do it. So choices
>>> are:
>>>
>>> a) don't do anything (remove the UseNewCode check)
>>> b) add a new diagnostic flag
>>> c) add a new experimental flag
>>
>> My vote:
>>
>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>
>> With a plan (and a bug) to remove that option down the road.
>>
>> And a code review.
>>
>> src/os/linux/vm/os_linux.cpp
>>     No comments.
>>
>> src/share/vm/logging/logTag.hpp
>>     No comments.
>>
>> test/runtime/os/AvailableProcessors.java
>>     Nice test. I like that the default (no args) runs a set of tests
>>     and if you (manually) run the test with a specific arg it will
>>     check just that one value.
>>
>> Thumbs up! (Assuming you change UseNewCode to something else or
>> delete its use all together.
>>
>> Dan
>>
>>
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>>   - JPRT
>>>>
>>>> Compatability issues:
>>>> - the system code we're using now is at least 5 years old so distro's
>>>> older than that (which are not officially supported) may not work
>>>> - anyone already running under a processor constrained environment
>>>> (like
>>>> Docker) and using availableProcessor() to "size" things, will find that
>>>> size has now changed. We do not expect this to be a problem - on the
>>>> contrary we expect Docker users to want the new behaviour.
>>>>
>>>> Thanks,
>>>> David
>>
>

From thomas.stuefe at gmail.com  Wed Jan 27 08:11:14 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 Jan 2016 09:11:14 +0100
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <56A85943.5050505@oracle.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
	<56A85943.5050505@oracle.com>
Message-ID: <CAA-vtUwgDb0rSoNXww5ROkZuJ6k-X4fr7SMha5iTBYgFwWu8Jw@mail.gmail.com>

Hi David,

thank you for the review! Answer inline.

On Wed, Jan 27, 2016 at 6:44 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 20/01/2016 5:53 PM, Thomas St?fe wrote:
>
>> May I please have a review and a sponsor?
>>
>> Thank you!
>>
>> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> could I please have reviews and a sponsor for this small fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>>
>>> When we print register to memory info in hs-err file, text addresses are
>>> not resolved on windows like on other platforms:
>>>
>>> "RCX=0x000000005efa0000 is an unknown value"
>>>
>>> This fix changes this (the same way it is implemented on other
>>> platforms):
>>>
>>
> In the sense that something is better than nothing this seems okay, but I
> have to wonder why the other OS do what they do in os::find and don't call
> os::dll_address_to_library_name? I'm not an expert on dll querying on any
> platform.
>

You are totally right. There is a lot of code duplication. My guess is that
os::find was originally used as a debugging aid (called from within the
debugger, if that is supported).

I wanted to have a basic fix first and then do a real cleanup later,
therefore I opened https://bugs.openjdk.java.net/browse/JDK-8147512. I
thought that way it is easier to get reviews.

Thanks, Thomas


>
> Thanks,
> David
> -----
>
>
>
>>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>>> 0"
>>>
>>> Please note that this printout and the code behind it could be improved
>>> and cleaned up a lot. For instance, I know that using an on-stack buffer
>>> in
>>> os::find() is not the best implementation here. But I wanted a minimal
>>> change. For the follow-up work, I opened a new bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>>
>>> Thanks & Regards, Thomas
>>>
>>>
>>>
>>>
>>>

From thomas.stuefe at gmail.com  Wed Jan 27 11:05:58 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 Jan 2016 12:05:58 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <56A85526.1050107@oracle.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
	<CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
	<CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>
	<56A85526.1050107@oracle.com>
Message-ID: <CAA-vtUzfMQhRMMAdJn77A0C7dqPuCWMs_TFLua--4uTLcgVR9g@mail.gmail.com>

Hi David,

See here the new webrev.

http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.02/webrev

I changed the comment for set_scratch_buffer() and the copyright years, as
per your request, and left the rest unchanged.

On Wed, Jan 27, 2016 at 6:27 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 20/01/2016 7:29 PM, Thomas St?fe wrote:
>
>> Thank you Volker!
>>
>> Still need a second reviewer, and once hs-rt is open again I'll need a
>> sponsor too.
>>
>
> Sorry for the delay ... I can sponsor this for you.
>
> Overall looks okay - took me a little while to wrap my head around it.
>
> src/share/vm/utilities/ostream.hpp
>
> Typo:  // Caller may specify an own scratch buffer
>
> an -> their
>
> ---
>
> Please update copyright years.
>
> ---
>
> What testing have you done for this? Is it sufficient to generate some
> crash logs and validate the content is the same before and after this fix?
>

For Linux x64, windows and aix I tested manually. hs-err files look ok,
finally on AIX too. On Linux I also diffed an old with the new hs-err file,
to see if there is anything different, but could not spot anything apart
the expected differences for two different runs of the error handler.

I also ran jtreg test for hotspot/test/runtime/ErrorHandling on Windows,
Linux, AIx.

Kind Regards, Thomas


>
> Thanks,
> David
> ----
>
>
>
> Kind Regards, Thomas
>>
>> On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis <volker.simonis at gmail.com
>> >
>> wrote:
>>
>> Hi Thomas,
>>>
>>> thanks for doing this nice cleanup.
>>>
>>> The change looks good. Can you please just adapt the comment at line
>>> 987 and remove the reference to staticBufferStream from there as well.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>
>>>> May I please have a review for this? Thanks!
>>>>
>>>> On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>>>> wrote:
>>>>
>>>> Dear all,
>>>>>
>>>>> please take a look at this small cleanup of ostream.
>>>>>
>>>>> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
>>>>> webrev:
>>>>>
>>>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>>>
>>>>
>>>>> Basically, it gets rid of the staticBufferStream class by moving its
>>>>> one
>>>>> feature up to the parent outputStream class:
>>>>>
>>>>> When printing the error log in vmError.cpp, we want to use as little
>>>>>
>>>> stack
>>>
>>>> space as possible. outputStream class uses on-stack buffers to assemble
>>>>> snprintf functions. So, staticBufferStream was introduced as a child of
>>>>> outputStream which overwrites the print functions and makes them use a
>>>>> caller provided buffer. It then delegates the real writing to a
>>>>>
>>>> connected
>>>
>>>> stream object.
>>>>>
>>>>> The problem with that approach is that this is not a good fit for a
>>>>>
>>>> child
>>>
>>>> class.Not all operations possible with outputStream are cleanly
>>>>>
>>>> delegated
>>>
>>>> to the connected stream class, so a staticBufferStream behaves sometimes
>>>>> differently from all other streams (see e.g. JDK-8145410, which will be
>>>>> automatically fixed with this change too).
>>>>>
>>>>> Another problem is that this delegation model leads to some code
>>>>> duplication, because all print() methods of outputStream are
>>>>> practically
>>>>> duplicated in staticBufferStream.
>>>>>
>>>>> Another cosmetic note is that all other child classes of outputStream
>>>>> (bufferedStream, stringStream, fileStream...) are specializations in
>>>>>
>>>> term
>>>
>>>> of log destination, not internal behaviour.
>>>>>
>>>>> Note that I implemented this in a very simple way without using
>>>>>
>>>> templates,
>>>
>>>> because I wanted to keep the changes as small as possible.
>>>>>
>>>>> Kind Regards, Thomas
>>>>>
>>>>>
>>>

From felix.yang at linaro.org  Wed Jan 27 11:47:35 2016
From: felix.yang at linaro.org (Felix Yang)
Date: Wed, 27 Jan 2016 19:47:35 +0800
Subject: RFR: 8148328: aarch64: avoid unnecessary lsr instructions in stub code
Message-ID: <CACc5Y6QexvHbWQeg+bS+Xy92nD92QNcMF112n298eHk+TeoUiA@mail.gmail.com>

Hi,

Please review the following webrev:
http://cr.openjdk.java.net/~fyang/8148328/webrev.00/

Jira issue: https://bugs.openjdk.java.net/browse/JDK-8148328

This trivial patch eliminates unnecessary lsr instructions in
jbyte_arraycopy and jbyte_disjoint_arraycopy stub.

Tested with jtreg hotspot & langtools.  Is it OK?

Thanks,
Felix.

From thomas.stuefe at gmail.com  Wed Jan 27 13:48:04 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 Jan 2016 14:48:04 +0100
Subject: How do I control UL via jcmd VM.log?
Message-ID: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>

Hi all,

sorry if this is a stupid question. I have trouble figuring out the syntax
to enable Logging dynamically using jcmd for a life process.

Whatever argument I hand down to the VM.log command, I
get java.lang.IllegalArgumentException.

Examples:

./images/jdk/bin/jcmd 12680 VM.log  all
./images/jdk/bin/jcmd 12680 VM.log  all=trace
./images/jdk/bin/jcmd 12680 'VM.log  all=trace'
...
nothing works.


I also looked through https://bugs.openjdk.java.net/browse/JDK-8046148 but
did not find a clear answer beside "Everything that can be specified on the
command line can also be specified dynamically with Diagnostic Commands."
which did not help much.

What am I doing wrong?

Thanks and Kind Regards, Thomas

From magnus.ihse.bursie at oracle.com  Wed Jan 27 14:03:14 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2016 15:03:14 +0100
Subject: RFR: 8148361: Need to disable the thread local storage compiler
	option for ios
In-Reply-To: <56A8BB25.7040405@oracle.com>
References: <56A8BB25.7040405@oracle.com>
Message-ID: <56A8CE22.2050803@oracle.com>

On 2016-01-27 13:42, Gary Adams wrote:
> When the sync with jdk9 b102 was pulled into mobile/dev repos a new
> feature for thread local storage was over looked. Most modern compilers
> include support for thread local declaration, but this feature is 
> intentionally
> not supported by Apple's clang compiler.
>
> This change declares USE_LIBRARY_BASED_TLS_ONLY along with other
> TARGET_OS_IPHONE declarations in the hotspot globalDefinitions_gcc.hpp 
> file.
>
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8148361
>   Webrev: http://cr.openjdk.java.net/~gadams/8148361/webrev.00/

 From my perspective it looks good, but since you're actually modifying 
the hotspot source code and not make files, someone from the Hotspot 
team should look at this as well.

/Magnus

From staffan.larsen at oracle.com  Wed Jan 27 14:18:07 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 27 Jan 2016 15:18:07 +0100
Subject: How do I control UL via jcmd VM.log?
In-Reply-To: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>
References: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>
Message-ID: <95B5D81B-9657-4FB8-A2BC-FAC4B7C97D20@oracle.com>

The documentation clearly needs som work. But ?jcmd <pid> help VM.log? gives you some hints.

I think this does what you want (although I?m not completely sure):

$ jcmd <pid> VM.log what=all=trace


> On 27 jan. 2016, at 14:48, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi all,
> 
> sorry if this is a stupid question. I have trouble figuring out the syntax
> to enable Logging dynamically using jcmd for a life process.
> 
> Whatever argument I hand down to the VM.log command, I
> get java.lang.IllegalArgumentException.
> 
> Examples:
> 
> ./images/jdk/bin/jcmd 12680 VM.log  all
> ./images/jdk/bin/jcmd 12680 VM.log  all=trace
> ./images/jdk/bin/jcmd 12680 'VM.log  all=trace'
> ...
> nothing works.
> 
> 
> I also looked through https://bugs.openjdk.java.net/browse/JDK-8046148 but
> did not find a clear answer beside "Everything that can be specified on the
> command line can also be specified dynamically with Diagnostic Commands."
> which did not help much.
> 
> What am I doing wrong?
> 
> Thanks and Kind Regards, Thomas


From stefan.karlsson at oracle.com  Wed Jan 27 14:23:06 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 27 Jan 2016 15:23:06 +0100
Subject: How do I control UL via jcmd VM.log?
In-Reply-To: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>
References: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>
Message-ID: <56A8D2CA.7070109@oracle.com>

Hi Thomas,

On 2016-01-27 14:48, Thomas St?fe wrote:
> Hi all,
>
> sorry if this is a stupid question. I have trouble figuring out the syntax
> to enable Logging dynamically using jcmd for a life process.
>
> Whatever argument I hand down to the VM.log command, I
> get java.lang.IllegalArgumentException.
>
> Examples:
>
> ./images/jdk/bin/jcmd 12680 VM.log  all
> ./images/jdk/bin/jcmd 12680 VM.log  all=trace
> ./images/jdk/bin/jcmd 12680 'VM.log  all=trace'
> ...
> nothing works.

Try the following to get more help:

./images/jdk/bin/jcmd 12680 VM.log help
---
VM.log
Lists, enables, disables or changes a log output configuration.

Impact: Low: No impact

Permission: java.lang.management.ManagementPermission(control)

Syntax : VM.log [options]

Options: (options must be specified using the <key> or <key>=<value> syntax)
	output : [optional] The name or index (#<index>) of output to configure. (STRING, no default value)
	output_options : [optional] Options for the output. (STRING, no default value)
	what : [optional] Configures what tags to log. (STRING, no default value)
	decorators : [optional] Configures which decorators to use. Use 'none' or an empty value to remove all. (STRING, no default value)
	disable : [optional] Turns off all logging and clears the log configuration. (BOOLEAN, no default value)
	list : [optional] Lists current log configuration. (BOOLEAN, no default value)
---

and also:

./images/jdk/bin/jcmd 12680 VM.log list

to see what's currently used.


and then:

./images/jdk/bin/jcmd 12680 VM.log what=all=trace


to change the settings.

StefanK

>
>
> I also looked through https://bugs.openjdk.java.net/browse/JDK-8046148 but
> did not find a clear answer beside "Everything that can be specified on the
> command line can also be specified dynamically with Diagnostic Commands."
> which did not help much.
>
> What am I doing wrong?
>
> Thanks and Kind Regards, Thomas


From thomas.stuefe at gmail.com  Wed Jan 27 14:28:41 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 Jan 2016 15:28:41 +0100
Subject: How do I control UL via jcmd VM.log?
In-Reply-To: <56A8D2CA.7070109@oracle.com>
References: <CAA-vtUxYXfdybf2_giPvgwSFLnwQGERdUDeLhR7AxNnsVxLTZA@mail.gmail.com>
	<56A8D2CA.7070109@oracle.com>
Message-ID: <CAA-vtUxYpmEtjxhdXvqUC1OHJuHf9MzF4p1TH9BVnmRarDQ-gg@mail.gmail.com>

Staffan, Steffan,

thanks a lot! Now I see my output as expected.

Kind Regards, Thomas


On Wed, Jan 27, 2016 at 3:23 PM, Stefan Karlsson <stefan.karlsson at oracle.com
> wrote:

> Hi Thomas,
>
> On 2016-01-27 14:48, Thomas St?fe wrote:
>
>> Hi all,
>>
>> sorry if this is a stupid question. I have trouble figuring out the syntax
>> to enable Logging dynamically using jcmd for a life process.
>>
>> Whatever argument I hand down to the VM.log command, I
>> get java.lang.IllegalArgumentException.
>>
>> Examples:
>>
>> ./images/jdk/bin/jcmd 12680 VM.log  all
>> ./images/jdk/bin/jcmd 12680 VM.log  all=trace
>> ./images/jdk/bin/jcmd 12680 'VM.log  all=trace'
>> ...
>> nothing works.
>>
>
> Try the following to get more help:
>
> ./images/jdk/bin/jcmd 12680 VM.log help
> ---
> VM.log
> Lists, enables, disables or changes a log output configuration.
>
> Impact: Low: No impact
>
> Permission: java.lang.management.ManagementPermission(control)
>
> Syntax : VM.log [options]
>
> Options: (options must be specified using the <key> or <key>=<value>
> syntax)
>         output : [optional] The name or index (#<index>) of output to
> configure. (STRING, no default value)
>         output_options : [optional] Options for the output. (STRING, no
> default value)
>         what : [optional] Configures what tags to log. (STRING, no default
> value)
>         decorators : [optional] Configures which decorators to use. Use
> 'none' or an empty value to remove all. (STRING, no default value)
>         disable : [optional] Turns off all logging and clears the log
> configuration. (BOOLEAN, no default value)
>         list : [optional] Lists current log configuration. (BOOLEAN, no
> default value)
> ---
>
> and also:
>
> ./images/jdk/bin/jcmd 12680 VM.log list
>
> to see what's currently used.
>
>
> and then:
>
> ./images/jdk/bin/jcmd 12680 VM.log what=all=trace
>
>
> to change the settings.
>
> StefanK
>
>
>
>>
>> I also looked through https://bugs.openjdk.java.net/browse/JDK-8046148
>> but
>> did not find a clear answer beside "Everything that can be specified on
>> the
>> command line can also be specified dynamically with Diagnostic Commands."
>> which did not help much.
>>
>> What am I doing wrong?
>>
>> Thanks and Kind Regards, Thomas
>>
>
>

From gerald.thornbrugh at oracle.com  Wed Jan 27 17:03:19 2016
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Wed, 27 Jan 2016 10:03:19 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A86ECC.5060002@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
	<56A86ECC.5060002@oracle.com>
Message-ID: <56A8F857.3010407@oracle.com>

Hi David,

Your changes look good to me.

Jerry
> Okay here is v2:
>
> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/
>
> - UseNewCode is replaced by a new experimental flag UseCpuAllocPath
> - the logging statement shows whether the path was forced to be taken
> - this is now enabled in product builds
>
> Sorry I don't know how to generate an incremental webrev when working 
> with uncommitted changes. :(
>
> Thanks,
> David
>
> On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
>> Hi David,
>>
>> I also like the idea of using an "-XX" option, that seems like the best
>> way to go.
>>
>> I am ok with leaving the code in.  If there are any issues with the code
>> we can always
>> create a bug and remove it.
>>
>> Jerry
>>> On 1/26/16 2:12 PM, David Holmes wrote:
>>>> Update ...
>>>>
>>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>>> critique and raising awareness of how non-simple this issue is.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>>
>>>>> Basic problem:
>>>>>    processors available for use <= processors online <= processors
>>>>> configured
>>>>>
>>>>> but we always returned the number of online processors.
>>>>>
>>>>> Solution is simple in its basic form: use sched_getaffinity to get 
>>>>> the
>>>>> scheduling affinity mask and count the number of available 
>>>>> processors.
>>>>>
>>>>> Details are complicated by the desire to handle very large processor
>>>>> systems. See the bug report for lots of detailed discussions and
>>>>> references.
>>>>>
>>>>> Testing:
>>>>>   - new test that verifies behaviour when running under taskset
>>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>>>> code paths (one hook is left in for non-product to allow easy
>>>>> testing of
>>>>> the dynamic path)
>>>>
>>>> I have been told that using the development flag UseNewCode in
>>>> released code is a bad idea because it is used internally during
>>>> development (as per its defined purpose).
>>>>
>>>> I would like to be able to test the dynamic path easily, but I didn't
>>>> want to pay the price of adding a new VM option to do it. So choices
>>>> are:
>>>>
>>>> a) don't do anything (remove the UseNewCode check)
>>>> b) add a new diagnostic flag
>>>> c) add a new experimental flag
>>>
>>> My vote:
>>>
>>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>>
>>> With a plan (and a bug) to remove that option down the road.
>>>
>>> And a code review.
>>>
>>> src/os/linux/vm/os_linux.cpp
>>>     No comments.
>>>
>>> src/share/vm/logging/logTag.hpp
>>>     No comments.
>>>
>>> test/runtime/os/AvailableProcessors.java
>>>     Nice test. I like that the default (no args) runs a set of tests
>>>     and if you (manually) run the test with a specific arg it will
>>>     check just that one value.
>>>
>>> Thumbs up! (Assuming you change UseNewCode to something else or
>>> delete its use all together.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>>   - JPRT
>>>>>
>>>>> Compatability issues:
>>>>> - the system code we're using now is at least 5 years old so distro's
>>>>> older than that (which are not officially supported) may not work
>>>>> - anyone already running under a processor constrained environment
>>>>> (like
>>>>> Docker) and using availableProcessor() to "size" things, will find 
>>>>> that
>>>>> size has now changed. We do not expect this to be a problem - on the
>>>>> contrary we expect Docker users to want the new behaviour.
>>>>>
>>>>> Thanks,
>>>>> David
>>>
>>


From daniel.daugherty at oracle.com  Wed Jan 27 17:40:24 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 27 Jan 2016 10:40:24 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A86ECC.5060002@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
	<56A86ECC.5060002@oracle.com>
Message-ID: <56A90108.4000705@oracle.com>

On 1/27/16 12:16 AM, David Holmes wrote:
> Okay here is v2:
>
> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/

Reviewed by comparing the two patch files. Looks good modulo
one question: should the change to src/share/vm/runtime/globals.hpp
be in src/os/linux/vm/globals_linux.hpp instead?

Dan


>
> - UseNewCode is replaced by a new experimental flag UseCpuAllocPath
> - the logging statement shows whether the path was forced to be taken
> - this is now enabled in product builds
>
> Sorry I don't know how to generate an incremental webrev when working 
> with uncommitted changes. :(
>
> Thanks,
> David
>
> On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
>> Hi David,
>>
>> I also like the idea of using an "-XX" option, that seems like the best
>> way to go.
>>
>> I am ok with leaving the code in.  If there are any issues with the code
>> we can always
>> create a bug and remove it.
>>
>> Jerry
>>> On 1/26/16 2:12 PM, David Holmes wrote:
>>>> Update ...
>>>>
>>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>>> critique and raising awareness of how non-simple this issue is.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>>
>>>>> Basic problem:
>>>>>    processors available for use <= processors online <= processors
>>>>> configured
>>>>>
>>>>> but we always returned the number of online processors.
>>>>>
>>>>> Solution is simple in its basic form: use sched_getaffinity to get 
>>>>> the
>>>>> scheduling affinity mask and count the number of available 
>>>>> processors.
>>>>>
>>>>> Details are complicated by the desire to handle very large processor
>>>>> systems. See the bug report for lots of detailed discussions and
>>>>> references.
>>>>>
>>>>> Testing:
>>>>>   - new test that verifies behaviour when running under taskset
>>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>>>> code paths (one hook is left in for non-product to allow easy
>>>>> testing of
>>>>> the dynamic path)
>>>>
>>>> I have been told that using the development flag UseNewCode in
>>>> released code is a bad idea because it is used internally during
>>>> development (as per its defined purpose).
>>>>
>>>> I would like to be able to test the dynamic path easily, but I didn't
>>>> want to pay the price of adding a new VM option to do it. So choices
>>>> are:
>>>>
>>>> a) don't do anything (remove the UseNewCode check)
>>>> b) add a new diagnostic flag
>>>> c) add a new experimental flag
>>>
>>> My vote:
>>>
>>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>>
>>> With a plan (and a bug) to remove that option down the road.
>>>
>>> And a code review.
>>>
>>> src/os/linux/vm/os_linux.cpp
>>>     No comments.
>>>
>>> src/share/vm/logging/logTag.hpp
>>>     No comments.
>>>
>>> test/runtime/os/AvailableProcessors.java
>>>     Nice test. I like that the default (no args) runs a set of tests
>>>     and if you (manually) run the test with a specific arg it will
>>>     check just that one value.
>>>
>>> Thumbs up! (Assuming you change UseNewCode to something else or
>>> delete its use all together.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>>   - JPRT
>>>>>
>>>>> Compatability issues:
>>>>> - the system code we're using now is at least 5 years old so distro's
>>>>> older than that (which are not officially supported) may not work
>>>>> - anyone already running under a processor constrained environment
>>>>> (like
>>>>> Docker) and using availableProcessor() to "size" things, will find 
>>>>> that
>>>>> size has now changed. We do not expect this to be a problem - on the
>>>>> contrary we expect Docker users to want the new behaviour.
>>>>>
>>>>> Thanks,
>>>>> David
>>>
>>


From max.ockner at oracle.com  Wed Jan 27 20:51:09 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Wed, 27 Jan 2016 15:51:09 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A895FE.7060507@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A794AC.2050800@oracle.com> <56A79880.1000702@oracle.com>
	<56A7A73D.5040206@oracle.com> <56A7AB69.7090507@oracle.com>
	<56A7AEF0.7070206@oracle.com> <56A7B0F2.8080509@oracle.com>
	<56A895FE.7060507@oracle.com>
Message-ID: <56A92DBD.6050901@oracle.com>

Hello again,
I have responded to the last round of feedback.

Some of the tests affected by the new logging output have been changed 
to look for the appropriate messages.
Webrevs:
[hotspot] http://cr.openjdk.java.net/~mockner/classload.06
[jdk] http://cr.openjdk.java.net/~mockner/8079408.jdk/

I have made all of the recommended changes to the source, and I have 
fixed all affected tests from Dan's list. I have also fixed any test 
which uses "-verbose:class" and looks for the old output from 
TraceClassLoading or TraceClassUnloading.

Though Ioi suggested I change my new test, I have not done that. I was 
recommended to copy from runtime/ClassUnload/UnloadTest.java instead of 
rolling my own test for class unloading. I mentioned that it was tricky 
to make the new test work, but it was tricky because I was trying to 
copy from UnloadTest.java. This test refers to a class "test.Empty" from 
a "classes" library, but the new test has a processBuilder which I think 
does not play nicely with the class path for  "test.Empty". In the end 
it was much easier to hardcode the entire test into one place than to 
follow UnloadTest.java and refer to extra libraries.

Thanks,
Max

From rachel.protacio at oracle.com  Wed Jan 27 23:02:36 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Wed, 27 Jan 2016 18:02:36 -0500
Subject: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return
	JNI_VERSION_9
Message-ID: <56A94C8C.9050306@oracle.com>

Hello!

Small but important change for review: updating the JNI_VERSION and in 
so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y 
(see code/bug for details).

Bug: https://bugs.openjdk.java.net/browse/JDK-8145098

hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_hotspot/
jdk repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_jdk/

I grep'ed through the code to find references to the current JNI version 
and believe I have caught all the ones that needed changing, plus the 
fact that all these tests pass:

  * local hotspot jtreg tests
  * my own sample JNI test to print and visually inspect the version
    (essentially what is performed by the updated
    hotspot/test/native_sanity/JniVersion.java test)
  * jck vm tests
  * local rbt colcated and noncolocated tests, especially for the
    purpose of hitting tonga/src/nsk/share/jvmti tests where
    JNI_GetVersion() is used

Thank you,
Rachel

From coleen.phillimore at oracle.com  Thu Jan 28 02:08:11 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 27 Jan 2016 21:08:11 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A92DBD.6050901@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A794AC.2050800@oracle.com> <56A79880.1000702@oracle.com>
	<56A7A73D.5040206@oracle.com> <56A7AB69.7090507@oracle.com>
	<56A7AEF0.7070206@oracle.com> <56A7B0F2.8080509@oracle.com>
	<56A895FE.7060507@oracle.com> <56A92DBD.6050901@oracle.com>
Message-ID: <56A9780B.4040103@oracle.com>

Hi Max,

Overall looks good.

http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/classfile/classLoader.cpp.udiff.html

Looks like you changed the copyright date from 2016 to 2015.

http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/memory/filemap.cpp.udiff.html

What was the answer to this?  Why is there no logging for classload here?

http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/services/classLoadingService.cpp.udiff.html

You still have bool ret; declared, should be removed.

I don't need to see another webrev if you fix, answer and fix these 
minor issues.

thanks,
Coleen

On 1/27/16 3:51 PM, Max Ockner wrote:
> Hello again,
> I have responded to the last round of feedback.
>
> Some of the tests affected by the new logging output have been changed 
> to look for the appropriate messages.
> Webrevs:
> [hotspot] http://cr.openjdk.java.net/~mockner/classload.06
> [jdk] http://cr.openjdk.java.net/~mockner/8079408.jdk/
>
> I have made all of the recommended changes to the source, and I have 
> fixed all affected tests from Dan's list. I have also fixed any test 
> which uses "-verbose:class" and looks for the old output from 
> TraceClassLoading or TraceClassUnloading.
>
> Though Ioi suggested I change my new test, I have not done that. I was 
> recommended to copy from runtime/ClassUnload/UnloadTest.java instead 
> of rolling my own test for class unloading. I mentioned that it was 
> tricky to make the new test work, but it was tricky because I was 
> trying to copy from UnloadTest.java. This test refers to a class 
> "test.Empty" from a "classes" library, but the new test has a 
> processBuilder which I think does not play nicely with the class path 
> for  "test.Empty". In the end it was much easier to hardcode the 
> entire test into one place than to follow UnloadTest.java and refer to 
> extra libraries.
>
> Thanks,
> Max


From david.holmes at oracle.com  Thu Jan 28 03:05:09 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Jan 2016 13:05:09 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A90108.4000705@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
	<56A86ECC.5060002@oracle.com> <56A90108.4000705@oracle.com>
Message-ID: <56A98565.5090305@oracle.com>

On 28/01/2016 3:40 AM, Daniel D. Daugherty wrote:
> On 1/27/16 12:16 AM, David Holmes wrote:
>> Okay here is v2:
>>
>> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/
>
> Reviewed by comparing the two patch files. Looks good modulo
> one question: should the change to src/share/vm/runtime/globals.hpp
> be in src/os/linux/vm/globals_linux.hpp instead?

Thanks Dan!

http://cr.openjdk.java.net/~dholmes/6515172/webrev.v3/

I hadn't realized I could do that! There are a few flags in globals.hpp 
that should be elsewhere.

One glitch is that the per-os flag definitions are not set up to handle 
"experimental". I did not want to have to change all of the platform 
files to deal with that, so I switched back to a diagnostic option. I 
hope that is okay? (Comment was updated in os_linux.cpp)

I also want to note that Thomas Stuefe raised an issue with the use of 
strerror() - it may not be thread-safe. We already use it quite a lot in 
the VM code so I think there needs to be a general solution so I will 
file a separate CR. I also note that it will make the logging use of 
strerror very awkward if we need to define a local buffer, and not have 
any impact when logging is disabled. :(

Thanks,
David

> Dan
>
>
>>
>> - UseNewCode is replaced by a new experimental flag UseCpuAllocPath
>> - the logging statement shows whether the path was forced to be taken
>> - this is now enabled in product builds
>>
>> Sorry I don't know how to generate an incremental webrev when working
>> with uncommitted changes. :(
>>
>> Thanks,
>> David
>>
>> On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
>>> Hi David,
>>>
>>> I also like the idea of using an "-XX" option, that seems like the best
>>> way to go.
>>>
>>> I am ok with leaving the code in.  If there are any issues with the code
>>> we can always
>>> create a bug and remove it.
>>>
>>> Jerry
>>>> On 1/26/16 2:12 PM, David Holmes wrote:
>>>>> Update ...
>>>>>
>>>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>>>> critique and raising awareness of how non-simple this issue is.
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>>>
>>>>>> Basic problem:
>>>>>>    processors available for use <= processors online <= processors
>>>>>> configured
>>>>>>
>>>>>> but we always returned the number of online processors.
>>>>>>
>>>>>> Solution is simple in its basic form: use sched_getaffinity to get
>>>>>> the
>>>>>> scheduling affinity mask and count the number of available
>>>>>> processors.
>>>>>>
>>>>>> Details are complicated by the desire to handle very large processor
>>>>>> systems. See the bug report for lots of detailed discussions and
>>>>>> references.
>>>>>>
>>>>>> Testing:
>>>>>>   - new test that verifies behaviour when running under taskset
>>>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of all
>>>>>> code paths (one hook is left in for non-product to allow easy
>>>>>> testing of
>>>>>> the dynamic path)
>>>>>
>>>>> I have been told that using the development flag UseNewCode in
>>>>> released code is a bad idea because it is used internally during
>>>>> development (as per its defined purpose).
>>>>>
>>>>> I would like to be able to test the dynamic path easily, but I didn't
>>>>> want to pay the price of adding a new VM option to do it. So choices
>>>>> are:
>>>>>
>>>>> a) don't do anything (remove the UseNewCode check)
>>>>> b) add a new diagnostic flag
>>>>> c) add a new experimental flag
>>>>
>>>> My vote:
>>>>
>>>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>>>
>>>> With a plan (and a bug) to remove that option down the road.
>>>>
>>>> And a code review.
>>>>
>>>> src/os/linux/vm/os_linux.cpp
>>>>     No comments.
>>>>
>>>> src/share/vm/logging/logTag.hpp
>>>>     No comments.
>>>>
>>>> test/runtime/os/AvailableProcessors.java
>>>>     Nice test. I like that the default (no args) runs a set of tests
>>>>     and if you (manually) run the test with a specific arg it will
>>>>     check just that one value.
>>>>
>>>> Thumbs up! (Assuming you change UseNewCode to something else or
>>>> delete its use all together.
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>>   - JPRT
>>>>>>
>>>>>> Compatability issues:
>>>>>> - the system code we're using now is at least 5 years old so distro's
>>>>>> older than that (which are not officially supported) may not work
>>>>>> - anyone already running under a processor constrained environment
>>>>>> (like
>>>>>> Docker) and using availableProcessor() to "size" things, will find
>>>>>> that
>>>>>> size has now changed. We do not expect this to be a problem - on the
>>>>>> contrary we expect Docker users to want the new behaviour.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>
>>>
>

From david.holmes at oracle.com  Thu Jan 28 04:19:17 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Jan 2016 14:19:17 +1000
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUwgDb0rSoNXww5ROkZuJ6k-X4fr7SMha5iTBYgFwWu8Jw@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
	<56A85943.5050505@oracle.com>
	<CAA-vtUwgDb0rSoNXww5ROkZuJ6k-X4fr7SMha5iTBYgFwWu8Jw@mail.gmail.com>
Message-ID: <56A996C5.9030403@oracle.com>

Hi Thomas,

On 27/01/2016 6:11 PM, Thomas St?fe wrote:
> Hi David,
>
> thank you for the review! Answer inline.
>
> On Wed, Jan 27, 2016 at 6:44 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 20/01/2016 5:53 PM, Thomas St?fe wrote:
>
>         May I please have a review and a sponsor?
>
>         Thank you!
>
>         On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe
>         <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>         wrote:
>
>             Hi,
>
>             could I please have reviews and a sponsor for this small fix:
>
>             Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>             Webrev:
>             http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>
>             When we print register to memory info in hs-err file, text
>             addresses are
>             not resolved on windows like on other platforms:
>
>             "RCX=0x000000005efa0000 is an unknown value"
>
>             This fix changes this (the same way it is implemented on
>             other platforms):
>
>
>     In the sense that something is better than nothing this seems okay,
>     but I have to wonder why the other OS do what they do in os::find
>     and don't call os::dll_address_to_library_name? I'm not an expert on
>     dll querying on any platform.
>
>
> You are totally right. There is a lot of code duplication. My guess is
> that os::find was originally used as a debugging aid (called from within
> the debugger, if that is supported).
>
> I wanted to have a basic fix first and then do a real cleanup later,
> therefore I opened https://bugs.openjdk.java.net/browse/JDK-8147512. I
> thought that way it is easier to get reviews.

Okay. We will need a second review for this, but I'm happy to sponsor it 
for you.

Thanks,
David

> Thanks, Thomas
>
>
>     Thanks,
>     David
>     -----
>
>
>
>             "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll
>             +
>             0"
>
>             Please note that this printout and the code behind it could
>             be improved
>             and cleaned up a lot. For instance, I know that using an
>             on-stack buffer in
>             os::find() is not the best implementation here. But I wanted
>             a minimal
>             change. For the follow-up work, I opened a new bug:
>             https://bugs.openjdk.java.net/browse/JDK-8147512.
>
>             Thanks & Regards, Thomas
>
>
>
>
>

From david.holmes at oracle.com  Thu Jan 28 04:26:37 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 28 Jan 2016 14:26:37 +1000
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <CAA-vtUzfMQhRMMAdJn77A0C7dqPuCWMs_TFLua--4uTLcgVR9g@mail.gmail.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
	<CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
	<CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>
	<56A85526.1050107@oracle.com>
	<CAA-vtUzfMQhRMMAdJn77A0C7dqPuCWMs_TFLua--4uTLcgVR9g@mail.gmail.com>
Message-ID: <56A9987D.7040303@oracle.com>

Thanks Thomas - push under way.

Please note the changeset comment must have form:

<bug number>: <description>

Cheers,
David

On 27/01/2016 9:05 PM, Thomas St?fe wrote:
> Hi David,
>
> See here the new webrev.
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.02/webrev
>
> I changed the comment for set_scratch_buffer() and the copyright years,
> as per your request, and left the rest unchanged.
>
> On Wed, Jan 27, 2016 at 6:27 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 20/01/2016 7:29 PM, Thomas St?fe wrote:
>
>         Thank you Volker!
>
>         Still need a second reviewer, and once hs-rt is open again I'll
>         need a
>         sponsor too.
>
>
>     Sorry for the delay ... I can sponsor this for you.
>
>     Overall looks okay - took me a little while to wrap my head around it.
>
>     src/share/vm/utilities/ostream.hpp
>
>     Typo:  // Caller may specify an own scratch buffer
>
>     an -> their
>
>     ---
>
>     Please update copyright years.
>
>     ---
>
>     What testing have you done for this? Is it sufficient to generate
>     some crash logs and validate the content is the same before and
>     after this fix?
>
>
> For Linux x64, windows and aix I tested manually. hs-err files look ok,
> finally on AIX too. On Linux I also diffed an old with the new hs-err
> file, to see if there is anything different, but could not spot anything
> apart the expected differences for two different runs of the error handler.
>
> I also ran jtreg test for hotspot/test/runtime/ErrorHandling on Windows,
> Linux, AIx.
>
> Kind Regards, Thomas
>
>
>     Thanks,
>     David
>     ----
>
>
>
>         Kind Regards, Thomas
>
>         On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis
>         <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>         wrote:
>
>             Hi Thomas,
>
>             thanks for doing this nice cleanup.
>
>             The change looks good. Can you please just adapt the comment
>             at line
>             987 and remove the reference to staticBufferStream from
>             there as well.
>
>             Regards,
>             Volker
>
>
>             On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe
>             <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>             wrote:
>
>                 May I please have a review for this? Thanks!
>
>                 On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe
>                 <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>                 wrote:
>
>                     Dear all,
>
>                     please take a look at this small cleanup of ostream.
>
>                     bug report:
>                     https://bugs.openjdk.java.net/browse/JDK-8146905
>                     webrev:
>
>             http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>
>
>                     Basically, it gets rid of the staticBufferStream
>                     class by moving its one
>                     feature up to the parent outputStream class:
>
>                     When printing the error log in vmError.cpp, we want
>                     to use as little
>
>             stack
>
>                     space as possible. outputStream class uses on-stack
>                     buffers to assemble
>                     snprintf functions. So, staticBufferStream was
>                     introduced as a child of
>                     outputStream which overwrites the print functions
>                     and makes them use a
>                     caller provided buffer. It then delegates the real
>                     writing to a
>
>             connected
>
>                     stream object.
>
>                     The problem with that approach is that this is not a
>                     good fit for a
>
>             child
>
>                     class.Not all operations possible with outputStream
>                     are cleanly
>
>             delegated
>
>                     to the connected stream class, so a
>                     staticBufferStream behaves sometimes
>                     differently from all other streams (see e.g.
>                     JDK-8145410, which will be
>                     automatically fixed with this change too).
>
>                     Another problem is that this delegation model leads
>                     to some code
>                     duplication, because all print() methods of
>                     outputStream are practically
>                     duplicated in staticBufferStream.
>
>                     Another cosmetic note is that all other child
>                     classes of outputStream
>                     (bufferedStream, stringStream, fileStream...) are
>                     specializations in
>
>             term
>
>                     of log destination, not internal behaviour.
>
>                     Note that I implemented this in a very simple way
>                     without using
>
>             templates,
>
>                     because I wanted to keep the changes as small as
>                     possible.
>
>                     Kind Regards, Thomas
>
>
>

From ioi.lam at oracle.com  Thu Jan 28 06:42:02 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 27 Jan 2016 22:42:02 -0800
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
Message-ID: <56A9B83A.6040808@oracle.com>

Hi Thomas,

5269 bool os::find(address addr, outputStream* st) {
5270   int offset = -1;
5271   char buf[255];
5272   if (os::dll_address_to_library_name(addr, buf, sizeof(buf), &offset)) {
5273     st->print_cr("%s + %x", buf, offset);
5274     return true;
5275   }
5276   return false;
5277 }


Have you tried calling os::dll_address_to_function_name as well so you 
can get the function name?

I noticed that the Linux version of os::find contains code for printing 
out the function name, but couldn't find an hs_err file where that code 
is actually used:

bool os::find(address addr, outputStream* st) {
     ...
     if (dlinfo.dli_fname != NULL) {
       st->print(" in %s", dlinfo.dli_fname);
     }


Thanks
- Ioi

On 1/19/16 11:53 PM, Thomas St?fe wrote:
> May I please have a review and a sponsor?
>
> Thank you!
>
> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi,
>>
>> could I please have reviews and a sponsor for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>
>> When we print register to memory info in hs-err file, text addresses are
>> not resolved on windows like on other platforms:
>>
>> "RCX=0x000000005efa0000 is an unknown value"
>>
>> This fix changes this (the same way it is implemented on other platforms):
>>
>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>> 0"
>>
>> Please note that this printout and the code behind it could be improved
>> and cleaned up a lot. For instance, I know that using an on-stack buffer in
>> os::find() is not the best implementation here. But I wanted a minimal
>> change. For the follow-up work, I opened a new bug:
>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>
>> Thanks & Regards, Thomas
>>
>>
>>
>>


From Alan.Bateman at oracle.com  Thu Jan 28 09:05:22 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 Jan 2016 09:05:22 +0000
Subject: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return
	JNI_VERSION_9
In-Reply-To: <56A94C8C.9050306@oracle.com>
References: <56A94C8C.9050306@oracle.com>
Message-ID: <56A9D9D2.2030208@oracle.com>

On 27/01/2016 23:02, Rachel Protacio wrote:
> Hello!
>
> Small but important change for review: updating the JNI_VERSION and in 
> so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y 
> (see code/bug for details).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145098
>
> hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_hotspot/
> jdk repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_jdk/

It would be good if Iris or someone on JEP 223 would comment on this.

In JEP 223 then the version number doesn't have trailing zeros and I'm 
wondering if this should be JNI_VERSION_9 rather than JNI_VERSION_9_0. I 
brought up the issue of the native interfaces on verona-dev recently [1] 
and I think Iris was open to having the JEP document this so that there 
is one document of truth on the version changes.

Also just to mention that we have draft updates to the JVM TI spec in 
the jake forest. As part of that work then we've optimistically rev'ed 
the JVM TI version so that jvmti.h defines JVMTI_VERSION_9. We should at 
least be consistent so that both native interfaces are _9 or _9_0.

-Alan.

[1] 
http://mail.openjdk.java.net/pipermail/verona-dev/2015-December/000324.html

From dmitry.dmitriev at oracle.com  Thu Jan 28 11:05:03 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 28 Jan 2016 14:05:03 +0300
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing
	for the jdk9/hs snapshot control job
Message-ID: <56A9F5DF.8000502@oracle.com>

Hello,

Please review added regression test cases to the 
test/runtime/logging/ExceptionsTest.java test. The underlying problem 
was fixed in JDK-8145153 by removing using of locally allocated array, 
thus this patch only adds regression test cases for that. In this test 
cases I specify TraceExceptions option in locations different from the 
command line(environment variables, VM Options files) and verify that 
aliasing code works.

JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>
Testing: JPRT, RBT

Thanks,
Dmitry

From dmitry.dmitriev at oracle.com  Thu Jan 28 11:07:19 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 28 Jan 2016 14:07:19 +0300
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
In-Reply-To: <569E1ECE.1070302@oracle.com>
References: <569E1ECE.1070302@oracle.com>
Message-ID: <56A9F667.5050805@oracle.com>

Hello,

Can I get review for that small patch please?

Thanks,
Dmitry

On 19.01.2016 14:32, Dmitry Dmitriev wrote:
> Hello,
>
> Please review small fix for printing flags functionality. This fix 
> return ability to print develop and not product flags in debug VM by 
> -XX:+PrintFlags* options.
> Few comments:
> 1) "if (printRanges) {" on line 407 in globals.cpp was deleted, 
> because it located in else branch of "if (!printRanges) {" and 
> therefore always true.
> 2) TestOptionsWithRanges.java was corrected to not pick develop and 
> not product flags.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
> Testing: JPRT, hotspot_all, vm.quick
>
> Thanks,
> Dmitry


From thomas.stuefe at gmail.com  Thu Jan 28 11:29:39 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 28 Jan 2016 12:29:39 +0100
Subject: RFR(xs): 8146905 - cleanup ostream, staticBufferStream
In-Reply-To: <56A9987D.7040303@oracle.com>
References: <CAA-vtUzhcg1SYRE-ZUrrNYR=-bOA8oEs=etU+dii66jM8N1fZg@mail.gmail.com>
	<CAA-vtUzgsbg8GHp0Uvd+X4DgDpYdmjrmab62sdA2xTT79OXWgQ@mail.gmail.com>
	<CA+3eh12h59DVfEWkQRPL93JB3zCE3RvY4vjZyLskRvx39_eZ2w@mail.gmail.com>
	<CAA-vtUwwBfB7EUaa=2T=nRJHKknTMhVETeVtkBFM7ap8aT-V1A@mail.gmail.com>
	<56A85526.1050107@oracle.com>
	<CAA-vtUzfMQhRMMAdJn77A0C7dqPuCWMs_TFLua--4uTLcgVR9g@mail.gmail.com>
	<56A9987D.7040303@oracle.com>
Message-ID: <CAA-vtUy5U0CFk_SM6g8-tr+Mi9v0+jZ-i6RwCi68-YWqmMXvjg@mail.gmail.com>

Thank you, David!



On Thu, Jan 28, 2016 at 5:26 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Thanks Thomas - push under way.
>
> Please note the changeset comment must have form:
>
> <bug number>: <description>
>
> Cheers,
> David
>
> On 27/01/2016 9:05 PM, Thomas St?fe wrote:
>
>> Hi David,
>>
>> See here the new webrev.
>>
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.02/webrev
>>
>> I changed the comment for set_scratch_buffer() and the copyright years,
>> as per your request, and left the rest unchanged.
>>
>> On Wed, Jan 27, 2016 at 6:27 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     On 20/01/2016 7:29 PM, Thomas St?fe wrote:
>>
>>         Thank you Volker!
>>
>>         Still need a second reviewer, and once hs-rt is open again I'll
>>         need a
>>         sponsor too.
>>
>>
>>     Sorry for the delay ... I can sponsor this for you.
>>
>>     Overall looks okay - took me a little while to wrap my head around it.
>>
>>     src/share/vm/utilities/ostream.hpp
>>
>>     Typo:  // Caller may specify an own scratch buffer
>>
>>     an -> their
>>
>>     ---
>>
>>     Please update copyright years.
>>
>>     ---
>>
>>     What testing have you done for this? Is it sufficient to generate
>>     some crash logs and validate the content is the same before and
>>     after this fix?
>>
>>
>> For Linux x64, windows and aix I tested manually. hs-err files look ok,
>> finally on AIX too. On Linux I also diffed an old with the new hs-err
>> file, to see if there is anything different, but could not spot anything
>> apart the expected differences for two different runs of the error
>> handler.
>>
>> I also ran jtreg test for hotspot/test/runtime/ErrorHandling on Windows,
>> Linux, AIx.
>>
>> Kind Regards, Thomas
>>
>>
>>     Thanks,
>>     David
>>     ----
>>
>>
>>
>>         Kind Regards, Thomas
>>
>>         On Wed, Jan 20, 2016 at 9:32 AM, Volker Simonis
>>         <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>>         wrote:
>>
>>             Hi Thomas,
>>
>>             thanks for doing this nice cleanup.
>>
>>             The change looks good. Can you please just adapt the comment
>>             at line
>>             987 and remove the reference to staticBufferStream from
>>             there as well.
>>
>>             Regards,
>>             Volker
>>
>>
>>             On Wed, Jan 20, 2016 at 8:54 AM, Thomas St?fe
>>             <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>>             wrote:
>>
>>                 May I please have a review for this? Thanks!
>>
>>                 On Wed, Jan 13, 2016 at 3:00 PM, Thomas St?fe
>>                 <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com
>> >>
>>
>>                 wrote:
>>
>>                     Dear all,
>>
>>                     please take a look at this small cleanup of ostream.
>>
>>                     bug report:
>>                     https://bugs.openjdk.java.net/browse/JDK-8146905
>>                     webrev:
>>
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>>
>>
>>                     Basically, it gets rid of the staticBufferStream
>>                     class by moving its one
>>                     feature up to the parent outputStream class:
>>
>>                     When printing the error log in vmError.cpp, we want
>>                     to use as little
>>
>>             stack
>>
>>                     space as possible. outputStream class uses on-stack
>>                     buffers to assemble
>>                     snprintf functions. So, staticBufferStream was
>>                     introduced as a child of
>>                     outputStream which overwrites the print functions
>>                     and makes them use a
>>                     caller provided buffer. It then delegates the real
>>                     writing to a
>>
>>             connected
>>
>>                     stream object.
>>
>>                     The problem with that approach is that this is not a
>>                     good fit for a
>>
>>             child
>>
>>                     class.Not all operations possible with outputStream
>>                     are cleanly
>>
>>             delegated
>>
>>                     to the connected stream class, so a
>>                     staticBufferStream behaves sometimes
>>                     differently from all other streams (see e.g.
>>                     JDK-8145410, which will be
>>                     automatically fixed with this change too).
>>
>>                     Another problem is that this delegation model leads
>>                     to some code
>>                     duplication, because all print() methods of
>>                     outputStream are practically
>>                     duplicated in staticBufferStream.
>>
>>                     Another cosmetic note is that all other child
>>                     classes of outputStream
>>                     (bufferedStream, stringStream, fileStream...) are
>>                     specializations in
>>
>>             term
>>
>>                     of log destination, not internal behaviour.
>>
>>                     Note that I implemented this in a very simple way
>>                     without using
>>
>>             templates,
>>
>>                     because I wanted to keep the changes as small as
>>                     possible.
>>
>>                     Kind Regards, Thomas
>>
>>
>>
>>

From thomas.stuefe at gmail.com  Thu Jan 28 13:01:16 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 28 Jan 2016 14:01:16 +0100
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <56A9B83A.6040808@oracle.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
	<56A9B83A.6040808@oracle.com>
Message-ID: <CAA-vtUx5EgxsJOKNzgtaC_bsZU3HstKf+92yuTJRi9ndWeN0ng@mail.gmail.com>

Hi Ioi,

thanks a lot for the review!

You are right, displaying the function name is more useful. I wanted to
postpone this until I could start
https://bugs.openjdk.java.net/browse/JDK-8147512, but now I took your
suggestion and implemented this anyway.

See here new webrev:

http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev

Notes:
-I decided to cut off the path for libraries to make the printout easier to
the eye; also, in the DLL-section we print out all DLLs including paths.
-There is no clean way to handle truncation of long library paths, so I
decided to at least detect truncation and if it happens to not print the
library at all. I want to avoid large on-stack buffers, therefore I keep
the result buffer relativly small (256 bytes). A better approach would be
to - if os::find is used from error handling - hand down the error handling
scratch buffer like we do in many other cases. But this is beyond the scope
for this small fix.

New printout looks like this:

 35 Register to memory mapping:
 36
 37 RIP=0x000000006ddd6a43 jvm.dll::crash_with_segfault + 0x13
 38 RAX=0xabc0000000000abc is an unknown value

Kind Regards, Thomas



On Thu, Jan 28, 2016 at 7:42 AM, Ioi Lam <ioi.lam at oracle.com> wrote:

> Hi Thomas,
>
> 5269 bool os::find(address addr, outputStream* st) {
> 5270   int offset = -1;
> 5271   char buf[255];
> 5272   if (os::dll_address_to_library_name(addr, buf, sizeof(buf),
> &offset)) {
> 5273     st->print_cr("%s + %x", buf, offset);
> 5274     return true;
> 5275   }
> 5276   return false;
> 5277 }
>
>
> Have you tried calling os::dll_address_to_function_name as well so you can
> get the function name?
>
> I noticed that the Linux version of os::find contains code for printing
> out the function name, but couldn't find an hs_err file where that code is
> actually used:
>
> bool os::find(address addr, outputStream* st) {
>     ...
>     if (dlinfo.dli_fname != NULL) {
>       st->print(" in %s", dlinfo.dli_fname);
>     }
>
>
> Thanks
> - Ioi
>
>
> On 1/19/16 11:53 PM, Thomas St?fe wrote:
>
>> May I please have a review and a sponsor?
>>
>> Thank you!
>>
>> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> could I please have reviews and a sponsor for this small fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>>
>>> When we print register to memory info in hs-err file, text addresses are
>>> not resolved on windows like on other platforms:
>>>
>>> "RCX=0x000000005efa0000 is an unknown value"
>>>
>>> This fix changes this (the same way it is implemented on other
>>> platforms):
>>>
>>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll +
>>> 0"
>>>
>>> Please note that this printout and the code behind it could be improved
>>> and cleaned up a lot. For instance, I know that using an on-stack buffer
>>> in
>>> os::find() is not the best implementation here. But I wanted a minimal
>>> change. For the follow-up work, I opened a new bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>>
>>> Thanks & Regards, Thomas
>>>
>>>
>>>
>>>
>>>
>

From goetz.lindenmaier at sap.com  Thu Jan 28 14:23:12 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 28 Jan 2016 14:23:12 +0000
Subject: RFR(XS): 8148470: Metadata print routines should not print to tty
Message-ID: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>

Hi,

Please review this small and obvious fix.  I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr16/8148470-tty/webrev.01/

I ran into this when calling format() in C2 compiler and setting Verbose.

Thanks and best regards,
  Goetz.

From george.triantafillou at oracle.com  Thu Jan 28 14:55:50 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Thu, 28 Jan 2016 09:55:50 -0500
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
In-Reply-To: <56A9F667.5050805@oracle.com>
References: <569E1ECE.1070302@oracle.com> <56A9F667.5050805@oracle.com>
Message-ID: <56AA2BF6.5080307@oracle.com>

Hi Dmitry,

Your changes look good.

-George

On 1/28/2016 6:07 AM, Dmitry Dmitriev wrote:
> Hello,
>
> Can I get review for that small patch please?
>
> Thanks,
> Dmitry
>
> On 19.01.2016 14:32, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review small fix for printing flags functionality. This fix 
>> return ability to print develop and not product flags in debug VM by 
>> -XX:+PrintFlags* options.
>> Few comments:
>> 1) "if (printRanges) {" on line 407 in globals.cpp was deleted, 
>> because it located in else branch of "if (!printRanges) {" and 
>> therefore always true.
>> 2) TestOptionsWithRanges.java was corrected to not pick develop and 
>> not product flags.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
>> Testing: JPRT, hotspot_all, vm.quick
>>
>> Thanks,
>> Dmitry
>


From mikael.gerdin at oracle.com  Thu Jan 28 15:00:25 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 28 Jan 2016 16:00:25 +0100
Subject: RFR(XS): 8148470: Metadata print routines should not print to tty
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
Message-ID: <56AA2D09.7000704@oracle.com>

Hi Goetz,

On 2016-01-28 15:23, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review this small and obvious fix.  I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr16/8148470-tty/webrev.01/

Fix looks good.
/Mikael

>
> I ran into this when calling format() in C2 compiler and setting Verbose.
>
> Thanks and best regards,
>    Goetz.
>


From dmitry.dmitriev at oracle.com  Thu Jan 28 15:02:34 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 28 Jan 2016 18:02:34 +0300
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
In-Reply-To: <56AA2BF6.5080307@oracle.com>
References: <569E1ECE.1070302@oracle.com> <56A9F667.5050805@oracle.com>
	<56AA2BF6.5080307@oracle.com>
Message-ID: <56AA2D8A.6090409@oracle.com>

Hi George,

Thank you for the review!

Dmitry

On 28.01.2016 17:55, George Triantafillou wrote:
> Hi Dmitry,
>
> Your changes look good.
>
> -George
>
> On 1/28/2016 6:07 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Can I get review for that small patch please?
>>
>> Thanks,
>> Dmitry
>>
>> On 19.01.2016 14:32, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review small fix for printing flags functionality. This fix 
>>> return ability to print develop and not product flags in debug VM by 
>>> -XX:+PrintFlags* options.
>>> Few comments:
>>> 1) "if (printRanges) {" on line 407 in globals.cpp was deleted, 
>>> because it located in else branch of "if (!printRanges) {" and 
>>> therefore always true.
>>> 2) TestOptionsWithRanges.java was corrected to not pick develop and 
>>> not product flags.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
>>> Testing: JPRT, hotspot_all, vm.quick
>>>
>>> Thanks,
>>> Dmitry
>>
>


From gerard.ziemski at oracle.com  Thu Jan 28 15:19:56 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 28 Jan 2016 09:19:56 -0600
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is
	failing for the jdk9/hs snapshot control job
In-Reply-To: <56A9F5DF.8000502@oracle.com>
References: <56A9F5DF.8000502@oracle.com>
Message-ID: <C0BE40A0-35BB-4151-8C3D-3D725A864BEE@oracle.com>

hi Dmitry,


----
src/share/vm/runtime/globals.cpp

No comments except that this was easy ;-)

---
test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

So we are not going to test the debug (non-product) flags at all, even on the debug build? (requires too much time?)



cheers

> On Jan 28, 2016, at 5:05 AM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com> wrote:
> 
> Hello,
> 
> Please review added regression test cases to the test/runtime/logging/ExceptionsTest.java test. The underlying problem was fixed in JDK-8145153 by removing using of locally allocated array, thus this patch only adds regression test cases for that. In this test cases I specify TraceExceptions option in locations different from the command line(environment variables, VM Options files) and verify that aliasing code works.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ <http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>
> Testing: JPRT, RBT
> 
> Thanks,
> Dmitry


From george.triantafillou at oracle.com  Thu Jan 28 15:14:55 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Thu, 28 Jan 2016 10:14:55 -0500
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing
	for the jdk9/hs snapshot control job
In-Reply-To: <56A9F5DF.8000502@oracle.com>
References: <56A9F5DF.8000502@oracle.com>
Message-ID: <56AA306F.9060804@oracle.com>

Hi Dmitry,

Changes look good!

-George

On 1/28/2016 6:05 AM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review added regression test cases to the 
> test/runtime/logging/ExceptionsTest.java test. The underlying problem 
> was fixed in JDK-8145153 by removing using of locally allocated array, 
> thus this patch only adds regression test cases for that. In this test 
> cases I specify TraceExceptions option in locations different from the 
> command line(environment variables, VM Options files) and verify that 
> aliasing code works.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>
> Testing: JPRT, RBT
>
> Thanks,
> Dmitry


From max.ockner at oracle.com  Thu Jan 28 17:23:31 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 28 Jan 2016 12:23:31 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56A9780B.4040103@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A794AC.2050800@oracle.com> <56A79880.1000702@oracle.com>
	<56A7A73D.5040206@oracle.com> <56A7AB69.7090507@oracle.com>
	<56A7AEF0.7070206@oracle.com> <56A7B0F2.8080509@oracle.com>
	<56A895FE.7060507@oracle.com> <56A92DBD.6050901@oracle.com>
	<56A9780B.4040103@oracle.com>
Message-ID: <56AA4E93.3050502@oracle.com>


On 1/27/2016 9:08 PM, Coleen Phillimore wrote:
> Hi Max,
>
> Overall looks good.
>
> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/classfile/classLoader.cpp.udiff.html 
>
>
> Looks like you changed the copyright date from 2016 to 2015.
>
All copyright dates (in all patches) have been fixed.
> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/memory/filemap.cpp.udiff.html 
>
>
> What was the answer to this?  Why is there no logging for classload here?
This logging is part of TraceClassPaths, and not really part of 
TraceClassLoading. Sorry I missed this.
>
> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/services/classLoadingService.cpp.udiff.html 
>
>
> You still have bool ret; declared, should be removed.
>
This is gone now.
> I don't need to see another webrev if you fix, answer and fix these 
> minor issues.
>
> thanks,
> Coleen
>
> On 1/27/16 3:51 PM, Max Ockner wrote:
>> Hello again,
>> I have responded to the last round of feedback.
>>
>> Some of the tests affected by the new logging output have been 
>> changed to look for the appropriate messages.
>> Webrevs:
>> [hotspot] http://cr.openjdk.java.net/~mockner/classload.06
>> [jdk] http://cr.openjdk.java.net/~mockner/8079408.jdk/
>>
>> I have made all of the recommended changes to the source, and I have 
>> fixed all affected tests from Dan's list. I have also fixed any test 
>> which uses "-verbose:class" and looks for the old output from 
>> TraceClassLoading or TraceClassUnloading.
>>
>> Though Ioi suggested I change my new test, I have not done that. I 
>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>> instead of rolling my own test for class unloading. I mentioned that 
>> it was tricky to make the new test work, but it was tricky because I 
>> was trying to copy from UnloadTest.java. This test refers to a class 
>> "test.Empty" from a "classes" library, but the new test has a 
>> processBuilder which I think does not play nicely with the class path 
>> for  "test.Empty". In the end it was much easier to hardcode the 
>> entire test into one place than to follow UnloadTest.java and refer 
>> to extra libraries.
>>
>> Thanks,
>> Max
>


From gerard.ziemski at oracle.com  Thu Jan 28 17:49:51 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 28 Jan 2016 11:49:51 -0600
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
In-Reply-To: <56A9F667.5050805@oracle.com>
References: <569E1ECE.1070302@oracle.com> <56A9F667.5050805@oracle.com>
Message-ID: <F547B025-FC18-4A8F-A150-879D27C228D8@oracle.com>

Resending referencing the correct issue:

hi Dmitry,


----
src/share/vm/runtime/globals.cpp

No comments except that this was easy ;-) And thank you for getting rid of extraneous ?printRanges? check. 

---
test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java

So we are not going to test the debug (non-product) flags at all, even on the debug build? (requires too much time?)


> On Jan 28, 2016, at 5:07 AM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com> wrote:
> 
> Hello,
> 
> Can I get review for that small patch please?
> 
> Thanks,
> Dmitry
> 
> On 19.01.2016 14:32, Dmitry Dmitriev wrote:
>> Hello,
>> 
>> Please review small fix for printing flags functionality. This fix return ability to print develop and not product flags in debug VM by -XX:+PrintFlags* options.
>> Few comments:
>> 1) "if (printRanges) {" on line 407 in globals.cpp was deleted, because it located in else branch of "if (!printRanges) {" and therefore always true.
>> 2) TestOptionsWithRanges.java was corrected to not pick develop and not product flags.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ <http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
>> Testing: JPRT, hotspot_all, vm.quick
>> 
>> Thanks,
>> Dmitry
> 


From gerard.ziemski at oracle.com  Thu Jan 28 17:50:43 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 28 Jan 2016 11:50:43 -0600
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is
	failing for the jdk9/hs snapshot control job
In-Reply-To: <56A9F5DF.8000502@oracle.com>
References: <56A9F5DF.8000502@oracle.com>
Message-ID: <F6DC60A9-1117-4B73-876B-016E122B451C@oracle.com>

Thank you for fixing this!

Please consider it (r)eviewed


cheers

> On Jan 28, 2016, at 5:05 AM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com> wrote:
> 
> Hello,
> 
> Please review added regression test cases to the test/runtime/logging/ExceptionsTest.java test. The underlying problem was fixed in JDK-8145153 by removing using of locally allocated array, thus this patch only adds regression test cases for that. In this test cases I specify TraceExceptions option in locations different from the command line(environment variables, VM Options files) and verify that aliasing code works.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ <http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>
> Testing: JPRT, RBT
> 
> Thanks,
> Dmitry


From daniel.daugherty at oracle.com  Thu Jan 28 17:52:37 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Jan 2016 10:52:37 -0700
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56A98565.5090305@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
	<56A86ECC.5060002@oracle.com> <56A90108.4000705@oracle.com>
	<56A98565.5090305@oracle.com>
Message-ID: <56AA5565.9000705@oracle.com>

On 1/27/16 8:05 PM, David Holmes wrote:
> On 28/01/2016 3:40 AM, Daniel D. Daugherty wrote:
>> On 1/27/16 12:16 AM, David Holmes wrote:
>>> Okay here is v2:
>>>
>>> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/
>>
>> Reviewed by comparing the two patch files. Looks good modulo
>> one question: should the change to src/share/vm/runtime/globals.hpp
>> be in src/os/linux/vm/globals_linux.hpp instead?
>
> Thanks Dan!
>
> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v3/

src/os/linux/vm/globals_linux.hpp
     No comments.

src/os/linux/vm/os_linux.cpp
     No comments.

src/share/vm/logging/logTag.hpp
     No comments.

test/runtime/os/AvailableProcessors.java
     No comments.

Thumbs up.

> I hadn't realized I could do that! There are a few flags in 
> globals.hpp that should be elsewhere.

Yet Another Cleanup Bug (YACB) :-)


> One glitch is that the per-os flag definitions are not set up to 
> handle "experimental". I did not want to have to change all of the 
> platform files to deal with that, so I switched back to a diagnostic 
> option. I hope that is okay? (Comment was updated in os_linux.cpp)

That is fine with me. Hmmmm... I remember running into that
limitation recently, but I don't remember the context. It was
probably when I was downgrading various Java Monitor options
from product flags to diagnostic/experimental.


> I also want to note that Thomas Stuefe raised an issue with the use of 
> strerror() - it may not be thread-safe. We already use it quite a lot 
> in the VM code so I think there needs to be a general solution so I 
> will file a separate CR. I also note that it will make the logging use 
> of strerror very awkward if we need to define a local buffer, and not 
> have any impact when logging is disabled. :(

I saw the new bug. That one is depressing.

Dan


>
> Thanks,
> David
>
>> Dan
>>
>>
>>>
>>> - UseNewCode is replaced by a new experimental flag UseCpuAllocPath
>>> - the logging statement shows whether the path was forced to be taken
>>> - this is now enabled in product builds
>>>
>>> Sorry I don't know how to generate an incremental webrev when working
>>> with uncommitted changes. :(
>>>
>>> Thanks,
>>> David
>>>
>>> On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
>>>> Hi David,
>>>>
>>>> I also like the idea of using an "-XX" option, that seems like the 
>>>> best
>>>> way to go.
>>>>
>>>> I am ok with leaving the code in.  If there are any issues with the 
>>>> code
>>>> we can always
>>>> create a bug and remove it.
>>>>
>>>> Jerry
>>>>> On 1/26/16 2:12 PM, David Holmes wrote:
>>>>>> Update ...
>>>>>>
>>>>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>>>>> critique and raising awareness of how non-simple this issue is.
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>>>>
>>>>>>> Basic problem:
>>>>>>>    processors available for use <= processors online <= processors
>>>>>>> configured
>>>>>>>
>>>>>>> but we always returned the number of online processors.
>>>>>>>
>>>>>>> Solution is simple in its basic form: use sched_getaffinity to get
>>>>>>> the
>>>>>>> scheduling affinity mask and count the number of available
>>>>>>> processors.
>>>>>>>
>>>>>>> Details are complicated by the desire to handle very large 
>>>>>>> processor
>>>>>>> systems. See the bug report for lots of detailed discussions and
>>>>>>> references.
>>>>>>>
>>>>>>> Testing:
>>>>>>>   - new test that verifies behaviour when running under taskset
>>>>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of 
>>>>>>> all
>>>>>>> code paths (one hook is left in for non-product to allow easy
>>>>>>> testing of
>>>>>>> the dynamic path)
>>>>>>
>>>>>> I have been told that using the development flag UseNewCode in
>>>>>> released code is a bad idea because it is used internally during
>>>>>> development (as per its defined purpose).
>>>>>>
>>>>>> I would like to be able to test the dynamic path easily, but I 
>>>>>> didn't
>>>>>> want to pay the price of adding a new VM option to do it. So choices
>>>>>> are:
>>>>>>
>>>>>> a) don't do anything (remove the UseNewCode check)
>>>>>> b) add a new diagnostic flag
>>>>>> c) add a new experimental flag
>>>>>
>>>>> My vote:
>>>>>
>>>>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>>>>
>>>>> With a plan (and a bug) to remove that option down the road.
>>>>>
>>>>> And a code review.
>>>>>
>>>>> src/os/linux/vm/os_linux.cpp
>>>>>     No comments.
>>>>>
>>>>> src/share/vm/logging/logTag.hpp
>>>>>     No comments.
>>>>>
>>>>> test/runtime/os/AvailableProcessors.java
>>>>>     Nice test. I like that the default (no args) runs a set of tests
>>>>>     and if you (manually) run the test with a specific arg it will
>>>>>     check just that one value.
>>>>>
>>>>> Thumbs up! (Assuming you change UseNewCode to something else or
>>>>> delete its use all together.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>>   - JPRT
>>>>>>>
>>>>>>> Compatability issues:
>>>>>>> - the system code we're using now is at least 5 years old so 
>>>>>>> distro's
>>>>>>> older than that (which are not officially supported) may not work
>>>>>>> - anyone already running under a processor constrained environment
>>>>>>> (like
>>>>>>> Docker) and using availableProcessor() to "size" things, will find
>>>>>>> that
>>>>>>> size has now changed. We do not expect this to be a problem - on 
>>>>>>> the
>>>>>>> contrary we expect Docker users to want the new behaviour.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>
>>>>
>>


From daniel.daugherty at oracle.com  Thu Jan 28 18:18:05 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Jan 2016 11:18:05 -0700
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing
	for the jdk9/hs snapshot control job
In-Reply-To: <56A9F5DF.8000502@oracle.com>
References: <56A9F5DF.8000502@oracle.com>
Message-ID: <56AA5B5D.5070206@oracle.com>

On 1/28/16 4:05 AM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review added regression test cases to the 
> test/runtime/logging/ExceptionsTest.java test. The underlying problem 
> was fixed in JDK-8145153 by removing using of locally allocated array, 
> thus this patch only adds regression test cases for that. In this test 
> cases I specify TraceExceptions option in locations different from the 
> command line(environment variables, VM Options files) and verify that 
> aliasing code works.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>

test/runtime/logging/ExceptionsTest.java
     No comments.

test/runtime/logging/ExceptionsTest_options_file
     No comments.

Thumbs up!

Thanks for adding coverage for the use of the alias table.

Dan


> Testing: JPRT, RBT
>
> Thanks,
> Dmitry


From coleen.phillimore at oracle.com  Thu Jan 28 18:18:25 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 28 Jan 2016 13:18:25 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA4E93.3050502@oracle.com>
References: <568F60E4.50609@oracle.com> <56904C26.1010207@oracle.com>
	<569068ED.6070509@oracle.com> <56A1763E.5030506@oracle.com>
	<56A794AC.2050800@oracle.com> <56A79880.1000702@oracle.com>
	<56A7A73D.5040206@oracle.com> <56A7AB69.7090507@oracle.com>
	<56A7AEF0.7070206@oracle.com> <56A7B0F2.8080509@oracle.com>
	<56A895FE.7060507@oracle.com> <56A92DBD.6050901@oracle.com>
	<56A9780B.4040103@oracle.com> <56AA4E93.3050502@oracle.com>
Message-ID: <56AA5B71.50002@oracle.com>


Okay, thanks!

On 1/28/16 12:23 PM, Max Ockner wrote:
>
> On 1/27/2016 9:08 PM, Coleen Phillimore wrote:
>> Hi Max,
>>
>> Overall looks good.
>>
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/classfile/classLoader.cpp.udiff.html 
>>
>>
>> Looks like you changed the copyright date from 2016 to 2015.
>>
> All copyright dates (in all patches) have been fixed.
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/memory/filemap.cpp.udiff.html 
>>
>>
>> What was the answer to this?  Why is there no logging for classload 
>> here?
> This logging is part of TraceClassPaths, and not really part of 
> TraceClassLoading. Sorry I missed this.

Okay, that's fine.

thanks,
Coleen
>>
>> http://cr.openjdk.java.net/~mockner/classload.06/src/share/vm/services/classLoadingService.cpp.udiff.html 
>>
>>
>> You still have bool ret; declared, should be removed.
>>
> This is gone now.
>> I don't need to see another webrev if you fix, answer and fix these 
>> minor issues.
>>
>> thanks,
>> Coleen
>>
>> On 1/27/16 3:51 PM, Max Ockner wrote:
>>> Hello again,
>>> I have responded to the last round of feedback.
>>>
>>> Some of the tests affected by the new logging output have been 
>>> changed to look for the appropriate messages.
>>> Webrevs:
>>> [hotspot] http://cr.openjdk.java.net/~mockner/classload.06
>>> [jdk] http://cr.openjdk.java.net/~mockner/8079408.jdk/
>>>
>>> I have made all of the recommended changes to the source, and I have 
>>> fixed all affected tests from Dan's list. I have also fixed any test 
>>> which uses "-verbose:class" and looks for the old output from 
>>> TraceClassLoading or TraceClassUnloading.
>>>
>>> Though Ioi suggested I change my new test, I have not done that. I 
>>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>>> instead of rolling my own test for class unloading. I mentioned that 
>>> it was tricky to make the new test work, but it was tricky because I 
>>> was trying to copy from UnloadTest.java. This test refers to a class 
>>> "test.Empty" from a "classes" library, but the new test has a 
>>> processBuilder which I think does not play nicely with the class 
>>> path for  "test.Empty". In the end it was much easier to hardcode 
>>> the entire test into one place than to follow UnloadTest.java and 
>>> refer to extra libraries.
>>>
>>> Thanks,
>>> Max
>>
>


From coleen.phillimore at oracle.com  Thu Jan 28 18:20:53 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 28 Jan 2016 13:20:53 -0500
Subject: RFR(XS): 8147477:
	com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing
	for the jdk9/hs snapshot control job
In-Reply-To: <56AA5B5D.5070206@oracle.com>
References: <56A9F5DF.8000502@oracle.com> <56AA5B5D.5070206@oracle.com>
Message-ID: <56AA5C05.2040601@oracle.com>


Hi Dmitry,
This test looks really nice!
Thanks,
Coleen

On 1/28/16 1:18 PM, Daniel D. Daugherty wrote:
> On 1/28/16 4:05 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review added regression test cases to the 
>> test/runtime/logging/ExceptionsTest.java test. The underlying problem 
>> was fixed in JDK-8145153 by removing using of locally allocated 
>> array, thus this patch only adds regression test cases for that. In 
>> this test cases I specify TraceExceptions option in locations 
>> different from the command line(environment variables, VM Options 
>> files) and verify that aliasing code works.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147477
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8147477/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eddmitriev/8147477/webrev.00/>
>
> test/runtime/logging/ExceptionsTest.java
>     No comments.
>
> test/runtime/logging/ExceptionsTest_options_file
>     No comments.
>
> Thumbs up!
>
> Thanks for adding coverage for the use of the alias table.
>
> Dan
>
>
>> Testing: JPRT, RBT
>>
>> Thanks,
>> Dmitry
>


From daniel.daugherty at oracle.com  Thu Jan 28 18:37:10 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 28 Jan 2016 11:37:10 -0700
Subject: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return
	JNI_VERSION_9
In-Reply-To: <56A94C8C.9050306@oracle.com>
References: <56A94C8C.9050306@oracle.com>
Message-ID: <56AA5FD6.4020400@oracle.com>

On 1/27/16 4:02 PM, Rachel Protacio wrote:
> Hello!
>
> Small but important change for review: updating the JNI_VERSION and in 
> so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y 
> (see code/bug for details).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145098
>
> hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_hotspot/

src/share/vm/prims/jni.cpp
     No comments.

src/share/vm/prims/jni.h
     No comments.

src/share/vm/runtime/thread.cpp
     No comments.

test/native_sanity/JniVersion.java
     No comments.


> jdk repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_jdk/

src/java.base/share/native/include/jni.h
     No comments.

     Meta-comment not specific to this bug. It sure would be nice if
     finally had "one source of truth" for "jni.h" (and friends).
     Perhaps in the top-level repo... :-)


Thumbs up!

On Alan's comments about JNI_VERSION_9_0 versus JNI_VERSION_9, my
personal preference is for trailing zero version. There was recently
a comment on hotspot-dev at o.j.n and verona-dev at o.j.n about the missing
trailing zeros. Subject line is: Version special case '9'

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021525.html

Dan


>
> I grep'ed through the code to find references to the current JNI 
> version and believe I have caught all the ones that needed changing, 
> plus the fact that all these tests pass:
>
>  * local hotspot jtreg tests
>  * my own sample JNI test to print and visually inspect the version
>    (essentially what is performed by the updated
>    hotspot/test/native_sanity/JniVersion.java test)
>  * jck vm tests
>  * local rbt colcated and noncolocated tests, especially for the
>    purpose of hitting tonga/src/nsk/share/jvmti tests where
>    JNI_GetVersion() is used
>
> Thank you,
> Rachel


From ioi.lam at oracle.com  Thu Jan 28 19:15:29 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 28 Jan 2016 11:15:29 -0800
Subject: RFR(XS): 8148470: Metadata print routines should not print to tty
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
Message-ID: <56AA68D1.2000403@oracle.com>

Hi Goetz,

This looks good to me. I'll sponsor it.

Thanks
- Ioi

On 1/28/16 6:23 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review this small and obvious fix.  I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr16/8148470-tty/webrev.01/
>
> I ran into this when calling format() in C2 compiler and setting Verbose.
>
> Thanks and best regards,
>    Goetz.


From max.ockner at oracle.com  Thu Jan 28 19:29:02 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 28 Jan 2016 14:29:02 -0500
Subject: Fwd: Re: RFR: 8079408: Reimplement TraceClassLoading,
	TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA648B.5060706@oracle.com>
References: <56AA648B.5060706@oracle.com>
Message-ID: <56AA6BFE.7090505@oracle.com>

Forwarded private discussion with Ioi about changing the test to use 
ClassUnloadCommon.

Hopefully nearing the end:

Webrev: http://cr.openjdk.java.net/~mockner/classload.08/

-------- Original Message --------
Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, 
TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
Date: 	Thu, 28 Jan 2016 10:57:15 -0800
From: 	Ioi Lam <ioi.lam at oracle.com>
To: 	Max Ockner <max.ockner at oracle.com>



Hi Max,

Thanks for doing this. Also, I sent the e-mail to you personally, so you 
may want to post the new version in the open list for record purpose.

Thanks
- Ioi

On 1/28/16 8:11 AM, Max Ockner wrote:
> Ioi,
> I have replaced my test with this test that you have given me (thank 
> you!)
> I also have removed the commented out section which used to test for 
> "making nmethod ...", and I have added the comment that you suggested 
> at the top of ClassUnloadCommon.java
> Thanks,
> Max
> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>
>>
>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>> Though Ioi suggested I change my new test, I have not done that. I 
>>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>>> instead of rolling my own test for class unloading. I mentioned that 
>>> it was tricky to make the new test work, but it was tricky because I 
>>> was trying to copy from UnloadTest.java. This test refers to a class 
>>> "test.Empty" from a "classes" library, but the new test has a 
>>> processBuilder which I think does not play nicely with the class 
>>> path for  "test.Empty". In the end it was much easier to hardcode 
>>> the entire test into one place than to follow UnloadTest.java and 
>>> refer to extra libraries.
>>>
>>
>> Hi Max,
>>
>> I've written a version of ClassLoadUnloadTest.java using 
>> ClassUnloadCommon. The main trick is here:
>>
>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>> System.getProperty("test.classes","."));
>>
>> That's because of this line in ClassUnloadCommon:
>>
>>             return new URLClassLoader(new URL[] {
>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar 
>> + "classes").toUri().toURL(),
>>             }, null);
>>
>> When Jtreg launches a sub-process, it strips off all the Java system 
>> properties, so you need to add the "-D" in the command-line.
>>
>> I also disabled the test related to "making nmethod ... unloadable". 
>> As Rachel found out in JDK-8146137, the compiler is unpredictable. 
>> Even if you invoke a method 10001 times, there's no guaranteed that 
>> it will always be compiled. Since this is not an 'easy-to-test' 
>> feature, we should just skip it.
>>
>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>
>> /*
>>  * To use ClassUnloadCommon from a sub-process, see 
>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>  * for an example.
>>  */
>>
>> What do you think?
>> - Ioi
>




From coleen.phillimore at oracle.com  Thu Jan 28 20:15:01 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 28 Jan 2016 15:15:01 -0500
Subject: Fwd: Re: RFR: 8079408: Reimplement TraceClassLoading,
	TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA6BFE.7090505@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
Message-ID: <56AA76C5.9070207@oracle.com>


Yes, this test looks really good.  Thanks Ioi for figuring out the 
vagaries of jtreg.

Coleen

On 1/28/16 2:29 PM, Max Ockner wrote:
> Forwarded private discussion with Ioi about changing the test to use 
> ClassUnloadCommon.
>
> Hopefully nearing the end:
>
> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>
> -------- Original Message --------
> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading, 
> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
> Date:     Thu, 28 Jan 2016 10:57:15 -0800
> From:     Ioi Lam <ioi.lam at oracle.com>
> To:     Max Ockner <max.ockner at oracle.com>
>
>
>
> Hi Max,
>
> Thanks for doing this. Also, I sent the e-mail to you personally, so 
> you may want to post the new version in the open list for record purpose.
>
> Thanks
> - Ioi
>
> On 1/28/16 8:11 AM, Max Ockner wrote:
>> Ioi,
>> I have replaced my test with this test that you have given me (thank 
>> you!)
>> I also have removed the commented out section which used to test for 
>> "making nmethod ...", and I have added the comment that you suggested 
>> at the top of ClassUnloadCommon.java
>> Thanks,
>> Max
>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>
>>>
>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>> Though Ioi suggested I change my new test, I have not done that. I 
>>>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>>>> instead of rolling my own test for class unloading. I mentioned 
>>>> that it was tricky to make the new test work, but it was tricky 
>>>> because I was trying to copy from UnloadTest.java. This test refers 
>>>> to a class "test.Empty" from a "classes" library, but the new test 
>>>> has a processBuilder which I think does not play nicely with the 
>>>> class path for  "test.Empty". In the end it was much easier to 
>>>> hardcode the entire test into one place than to follow 
>>>> UnloadTest.java and refer to extra libraries.
>>>>
>>>
>>> Hi Max,
>>>
>>> I've written a version of ClassLoadUnloadTest.java using 
>>> ClassUnloadCommon. The main trick is here:
>>>
>>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>>> System.getProperty("test.classes","."));
>>>
>>> That's because of this line in ClassUnloadCommon:
>>>
>>>             return new URLClassLoader(new URL[] {
>>> Paths.get(System.getProperty("test.classes",".") + 
>>> File.separatorChar + "classes").toUri().toURL(),
>>>             }, null);
>>>
>>> When Jtreg launches a sub-process, it strips off all the Java system 
>>> properties, so you need to add the "-D" in the command-line.
>>>
>>> I also disabled the test related to "making nmethod ... unloadable". 
>>> As Rachel found out in JDK-8146137, the compiler is unpredictable. 
>>> Even if you invoke a method 10001 times, there's no guaranteed that 
>>> it will always be compiled. Since this is not an 'easy-to-test' 
>>> feature, we should just skip it.
>>>
>>> I would also suggest adding this to the header of 
>>> ClassUnloadCommon.java
>>>
>>> /*
>>>  * To use ClassUnloadCommon from a sub-process, see 
>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>  * for an example.
>>>  */
>>>
>>> What do you think?
>>> - Ioi
>>
>
>
>


From gnu.andrew at redhat.com  Thu Jan 28 21:07:39 2016
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 28 Jan 2016 16:07:39 -0500 (EST)
Subject: [aarch64-port-dev ] VAR_CPU_ARCH for ARM platforms
In-Reply-To: <CADV+1JrRC8VV4vb08t5=Y3ptZbFBQk9HFmqKGd2Hz8F9hanvGg@mail.gmail.com>
References: <C1C54234-9AC2-4649-B9BD-738049F6E541@oracle.com>
	<567AD21C.5040907@redhat.com>
	<CADV+1JrRC8VV4vb08t5=Y3ptZbFBQk9HFmqKGd2Hz8F9hanvGg@mail.gmail.com>
Message-ID: <489951915.13804855.1454015259244.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Hi guys,
> 
> And indeed, please don't forget about AArch32 port. It's like ARM but it's
> quite different, you know. And it is currently using aarch32 value as
> VAR_CPU and VAR_CPU_ARCH
> 
> Thanks,
> Andrey
> 
> On Wed, Dec 23, 2015 at 7:56 PM Andrew Haley <aph at redhat.com> wrote:
> 
> > On 23/12/15 14:55, Bob Vandette wrote:
> >
> > > In my push to the mobile/dev forest, I changed VAR_CPU_ARCH on arm
> > > platforms to always use arm for both 32 and 64 bit arm builds to be
> > > consistent with the setting for x86/x86_64.
> >
> > This isn't a similar situation, IMO.
> >
> > > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ <
> > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/>
> > >
> > > My assumption which is confirmed by most of the usage in the
> > > makefiles is that VAR_CPU_ARCH should be set to the generic ARCH
> > > family (x86, arm) for both 32 and 64 bit builds.
> > >
> > > My motivation for doing this was initially for the selection of the
> > > Socket and UnixConstant template files used in cross compilation
> > > since these files contain the same content for arm and aarch64.
> >
> > I'm not convinced this makes any sense.  The only thing the ARM
> > architectures have in common is that they come from the same company.
> > This is not true of x86_64, which is a rather elaborate 64-bit
> > extension of x86.  For examples of how the ARM/AArch64 split is
> > handled elsewhere, note that the Linux kernel, GCC, and GNU binutils
> > arches are all separate.
> >
> > > There are a lot of hacks in both open and closed makefiles to set
> > > various variable based on ARCH in order to end up with the correct
> > > variables.
> > >
> > > In hotspot/make/defs.make, we undo the VAR_CPU_ARCH setting of x86
> > > for x86_64 builds by checking for LP64!  This is not done for arm.
> >
> > It really should not need to be.  AArch64 is not ARM.
> >
> > Andrew.
> >
> 

I just came across this mail when looking through AArch32 mails, and I
hope the change has now been reversed. It seems quite odd to be making
such a change in the mobile/dev forest rather than proposing it to the
AArch64 & AArch32 projects.

As Andrew points out, the history of arm/AArch64 is quite different to that
of x86/x86_64. Historically, x86_64 was introduced as a way to provide a
64-bit variant of x86, while maintaining compatibility with decades of
existing 32-bit binaries. It was introduced by AMD and is done in such a
way that a x86_64 chip is essentially an x86 chip when not operating in
LONG mode. Intel had already tried to do 64-bit with a complete redesign
in the form of the Itanium and one of its failings was the slow emulation
of 32-bit code. x86 has a long legacy of 32-bit binaries, many of which
are proprietary and simply can't be ported to 64-bit.

This scenario makes it fairly unique and other architectures handle the
32/64-bit split differently. For example, I believe 64-bit has always
been part of the design for PowerPC and SPARC, and its use doesn't share
the performance advantages of x86 over x86_64, because it doesn't use
the switch to 64-bit to add a bunch of other features, such as doubling
register provision, that were missing from the original architecture. It
is really just a case of working with a larger bit-size.

Anyway, the reason for me entering into this conversation is to point out
that we've already been burnt by a similar attempt at cleanup. When ppc64le
was merged, it was decided that it could just be referred to as 'ppc64'.
In actual use, this turned out to be a problem because tools running on the
platform couldn't work out whether they were on ppc64[be] or ppc64le and use
appropriate native binaries. I, along with others working on the PPC port,
have spent a lot of time diagnosing and fixing this over the past year.
I'd prefer that we didn't make the same mistake with arm and AArch64.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222



From ioi.lam at oracle.com  Thu Jan 28 23:07:00 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 28 Jan 2016 15:07:00 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA76C5.9070207@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<56AA76C5.9070207@oracle.com>
Message-ID: <56AA9F14.5000507@oracle.com>

Hi Max,

It looks really good now. Just a minor nit for classFileParser.cpp and 
systemDictionary.cpp, add the comment suggested by David:

1305     if (log_is_enabled(Info, classload)) {
1306       ik()->print_loading_log(LogLevel::Info, loader_data, NULL);
1307     }
          // No 'else' here as logging levels are not mutually exclusive
1308     if (log_is_enabled(Debug, classload)) {
1309       ik()->print_loading_log(LogLevel::Debug, loader_data, NULL);
1310     }

If there are no other changes, you don't need to post new webrev.

Thanks
- Ioi



On 1/28/16 12:15 PM, Coleen Phillimore wrote:
>
> Yes, this test looks really good.  Thanks Ioi for figuring out the 
> vagaries of jtreg.
>
> Coleen
>
> On 1/28/16 2:29 PM, Max Ockner wrote:
>> Forwarded private discussion with Ioi about changing the test to use 
>> ClassUnloadCommon.
>>
>> Hopefully nearing the end:
>>
>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>
>> -------- Original Message --------
>> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading, 
>> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>> Date:     Thu, 28 Jan 2016 10:57:15 -0800
>> From:     Ioi Lam <ioi.lam at oracle.com>
>> To:     Max Ockner <max.ockner at oracle.com>
>>
>>
>>
>> Hi Max,
>>
>> Thanks for doing this. Also, I sent the e-mail to you personally, so 
>> you may want to post the new version in the open list for record 
>> purpose.
>>
>> Thanks
>> - Ioi
>>
>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>> Ioi,
>>> I have replaced my test with this test that you have given me (thank 
>>> you!)
>>> I also have removed the commented out section which used to test for 
>>> "making nmethod ...", and I have added the comment that you 
>>> suggested at the top of ClassUnloadCommon.java
>>> Thanks,
>>> Max
>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>
>>>>
>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>> Though Ioi suggested I change my new test, I have not done that. I 
>>>>> was recommended to copy from runtime/ClassUnload/UnloadTest.java 
>>>>> instead of rolling my own test for class unloading. I mentioned 
>>>>> that it was tricky to make the new test work, but it was tricky 
>>>>> because I was trying to copy from UnloadTest.java. This test 
>>>>> refers to a class "test.Empty" from a "classes" library, but the 
>>>>> new test has a processBuilder which I think does not play nicely 
>>>>> with the class path for "test.Empty". In the end it was much 
>>>>> easier to hardcode the entire test into one place than to follow 
>>>>> UnloadTest.java and refer to extra libraries.
>>>>>
>>>>
>>>> Hi Max,
>>>>
>>>> I've written a version of ClassLoadUnloadTest.java using 
>>>> ClassUnloadCommon. The main trick is here:
>>>>
>>>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>>>> System.getProperty("test.classes","."));
>>>>
>>>> That's because of this line in ClassUnloadCommon:
>>>>
>>>>             return new URLClassLoader(new URL[] {
>>>> Paths.get(System.getProperty("test.classes",".") + 
>>>> File.separatorChar + "classes").toUri().toURL(),
>>>>             }, null);
>>>>
>>>> When Jtreg launches a sub-process, it strips off all the Java 
>>>> system properties, so you need to add the "-D" in the command-line.
>>>>
>>>> I also disabled the test related to "making nmethod ... 
>>>> unloadable". As Rachel found out in JDK-8146137, the compiler is 
>>>> unpredictable. Even if you invoke a method 10001 times, there's no 
>>>> guaranteed that it will always be compiled. Since this is not an 
>>>> 'easy-to-test' feature, we should just skip it.
>>>>
>>>> I would also suggest adding this to the header of 
>>>> ClassUnloadCommon.java
>>>>
>>>> /*
>>>>  * To use ClassUnloadCommon from a sub-process, see 
>>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>  * for an example.
>>>>  */
>>>>
>>>> What do you think?
>>>> - Ioi
>>>
>>
>>
>>
>


From ioi.lam at oracle.com  Thu Jan 28 23:32:56 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 28 Jan 2016 15:32:56 -0800
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUx5EgxsJOKNzgtaC_bsZU3HstKf+92yuTJRi9ndWeN0ng@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>	<56A9B83A.6040808@oracle.com>
	<CAA-vtUx5EgxsJOKNzgtaC_bsZU3HstKf+92yuTJRi9ndWeN0ng@mail.gmail.com>
Message-ID: <56AAA528.70409@oracle.com>

Hi Thomas,

Thanks for taking my suggestion :-)

To make the intention of the truncation check clearer, how about 
reorganizing the code to:

   if (os::dll_address_to_library_name(addr, buf, sizeof(buf), &offset)) {
     st->print(PTR_FORMAT " ", addr);
     if (strlen(buf) < sizeof(buf)-1) {
       char* p = strrchr(buf, '\\');
       if (p) {
         st->print("%s", p + 1);
       } else {
         st->print("%s", buf);
       }else {
         // The library name is probably truncated. Let's omit the 
library name.
         // See also JDK-8147512.
       }
}

I'd say 'probably' because the name could be exactly 255 characters long ...

Thanks
- Ioi


On 1/28/16 5:01 AM, Thomas St?fe wrote:
> Hi Ioi,
>
> thanks a lot for the review!
>
> You are right, displaying the function name is more useful. I wanted 
> to postpone this until I could start 
> https://bugs.openjdk.java.net/browse/JDK-8147512, but now I took your 
> suggestion and implemented this anyway.
>
> See here new webrev:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev>
>
> Notes:
> -I decided to cut off the path for libraries to make the printout 
> easier to the eye; also, in the DLL-section we print out all DLLs 
> including paths.
> -There is no clean way to handle truncation of long library paths, so 
> I decided to at least detect truncation and if it happens to not print 
> the library at all. I want to avoid large on-stack buffers, therefore 
> I keep the result buffer relativly small (256 bytes). A better 
> approach would be to - if os::find is used from error handling - hand 
> down the error handling scratch buffer like we do in many other cases. 
> But this is beyond the scope for this small fix.
>
> New printout looks like this:
>
>  35 Register to memory mapping:
>  36
>  37 RIP=0x000000006ddd6a43 jvm.dll::crash_with_segfault + 0x13
>  38 RAX=0xabc0000000000abc is an unknown value
>
> Kind Regards, Thomas
>
>
>
> On Thu, Jan 28, 2016 at 7:42 AM, Ioi Lam <ioi.lam at oracle.com 
> <mailto:ioi.lam at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     5269 bool os::find(address addr, outputStream* st) {
>     5270   int offset = -1;
>     5271   char buf[255];
>     5272   if (os::dll_address_to_library_name(addr, buf, sizeof(buf),
>     &offset)) {
>     5273     st->print_cr("%s + %x", buf, offset);
>     5274     return true;
>     5275   }
>     5276   return false;
>     5277 }
>
>
>     Have you tried calling os::dll_address_to_function_name as well so
>     you can get the function name?
>
>     I noticed that the Linux version of os::find contains code for
>     printing out the function name, but couldn't find an hs_err file
>     where that code is actually used:
>
>     bool os::find(address addr, outputStream* st) {
>         ...
>         if (dlinfo.dli_fname != NULL) {
>           st->print(" in %s", dlinfo.dli_fname);
>         }
>
>
>     Thanks
>     - Ioi
>
>
>     On 1/19/16 11:53 PM, Thomas St?fe wrote:
>
>         May I please have a review and a sponsor?
>
>         Thank you!
>
>         On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe
>         <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>         wrote:
>
>             Hi,
>
>             could I please have reviews and a sponsor for this small fix:
>
>             Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>             Webrev:
>             http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>             <http://cr.openjdk.java.net/%7Estuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/>
>
>             When we print register to memory info in hs-err file, text
>             addresses are
>             not resolved on windows like on other platforms:
>
>             "RCX=0x000000005efa0000 is an unknown value"
>
>             This fix changes this (the same way it is implemented on
>             other platforms):
>
>             "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll
>             +
>             0"
>
>             Please note that this printout and the code behind it
>             could be improved
>             and cleaned up a lot. For instance, I know that using an
>             on-stack buffer in
>             os::find() is not the best implementation here. But I
>             wanted a minimal
>             change. For the follow-up work, I opened a new bug:
>             https://bugs.openjdk.java.net/browse/JDK-8147512.
>
>             Thanks & Regards, Thomas
>
>
>
>
>
>


From david.holmes at oracle.com  Fri Jan 29 00:40:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jan 2016 10:40:00 +1000
Subject: RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset
	command
In-Reply-To: <56AA5565.9000705@oracle.com>
References: <56A1E2ED.1000109@oracle.com> <56A7E138.8000301@oracle.com>
	<56A7E960.7070004@oracle.com> <56A7FF38.4030501@oracle.com>
	<56A86ECC.5060002@oracle.com> <56A90108.4000705@oracle.com>
	<56A98565.5090305@oracle.com> <56AA5565.9000705@oracle.com>
Message-ID: <56AAB4E0.2080305@oracle.com>

Thanks Dan!

Also thanks Jerry and Thomas.

I will push the changes.

David
-----

On 29/01/2016 3:52 AM, Daniel D. Daugherty wrote:
> On 1/27/16 8:05 PM, David Holmes wrote:
>> On 28/01/2016 3:40 AM, Daniel D. Daugherty wrote:
>>> On 1/27/16 12:16 AM, David Holmes wrote:
>>>> Okay here is v2:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v2/
>>>
>>> Reviewed by comparing the two patch files. Looks good modulo
>>> one question: should the change to src/share/vm/runtime/globals.hpp
>>> be in src/os/linux/vm/globals_linux.hpp instead?
>>
>> Thanks Dan!
>>
>> http://cr.openjdk.java.net/~dholmes/6515172/webrev.v3/
>
> src/os/linux/vm/globals_linux.hpp
>      No comments.
>
> src/os/linux/vm/os_linux.cpp
>      No comments.
>
> src/share/vm/logging/logTag.hpp
>      No comments.
>
> test/runtime/os/AvailableProcessors.java
>      No comments.
>
> Thumbs up.
>
>> I hadn't realized I could do that! There are a few flags in
>> globals.hpp that should be elsewhere.
>
> Yet Another Cleanup Bug (YACB) :-)
>
>
>> One glitch is that the per-os flag definitions are not set up to
>> handle "experimental". I did not want to have to change all of the
>> platform files to deal with that, so I switched back to a diagnostic
>> option. I hope that is okay? (Comment was updated in os_linux.cpp)
>
> That is fine with me. Hmmmm... I remember running into that
> limitation recently, but I don't remember the context. It was
> probably when I was downgrading various Java Monitor options
> from product flags to diagnostic/experimental.
>
>
>> I also want to note that Thomas Stuefe raised an issue with the use of
>> strerror() - it may not be thread-safe. We already use it quite a lot
>> in the VM code so I think there needs to be a general solution so I
>> will file a separate CR. I also note that it will make the logging use
>> of strerror very awkward if we need to define a local buffer, and not
>> have any impact when logging is disabled. :(
>
> I saw the new bug. That one is depressing.
>
> Dan
>
>
>>
>> Thanks,
>> David
>>
>>> Dan
>>>
>>>
>>>>
>>>> - UseNewCode is replaced by a new experimental flag UseCpuAllocPath
>>>> - the logging statement shows whether the path was forced to be taken
>>>> - this is now enabled in product builds
>>>>
>>>> Sorry I don't know how to generate an incremental webrev when working
>>>> with uncommitted changes. :(
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 27/01/2016 9:20 AM, Gerald Thornbrugh wrote:
>>>>> Hi David,
>>>>>
>>>>> I also like the idea of using an "-XX" option, that seems like the
>>>>> best
>>>>> way to go.
>>>>>
>>>>> I am ok with leaving the code in.  If there are any issues with the
>>>>> code
>>>>> we can always
>>>>> create a bug and remove it.
>>>>>
>>>>> Jerry
>>>>>> On 1/26/16 2:12 PM, David Holmes wrote:
>>>>>>> Update ...
>>>>>>>
>>>>>>> On 22/01/2016 6:06 PM, David Holmes wrote:
>>>>>>>> First a special thanks to Martin Buchholz for his input, feedback,
>>>>>>>> critique and raising awareness of how non-simple this issue is.
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>>>>>>>>
>>>>>>>> Basic problem:
>>>>>>>>    processors available for use <= processors online <= processors
>>>>>>>> configured
>>>>>>>>
>>>>>>>> but we always returned the number of online processors.
>>>>>>>>
>>>>>>>> Solution is simple in its basic form: use sched_getaffinity to get
>>>>>>>> the
>>>>>>>> scheduling affinity mask and count the number of available
>>>>>>>> processors.
>>>>>>>>
>>>>>>>> Details are complicated by the desire to handle very large
>>>>>>>> processor
>>>>>>>> systems. See the bug report for lots of detailed discussions and
>>>>>>>> references.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>>   - new test that verifies behaviour when running under taskset
>>>>>>>>   - diagnostic hook injection (UseNewCodeN) to enable testing of
>>>>>>>> all
>>>>>>>> code paths (one hook is left in for non-product to allow easy
>>>>>>>> testing of
>>>>>>>> the dynamic path)
>>>>>>>
>>>>>>> I have been told that using the development flag UseNewCode in
>>>>>>> released code is a bad idea because it is used internally during
>>>>>>> development (as per its defined purpose).
>>>>>>>
>>>>>>> I would like to be able to test the dynamic path easily, but I
>>>>>>> didn't
>>>>>>> want to pay the price of adding a new VM option to do it. So choices
>>>>>>> are:
>>>>>>>
>>>>>>> a) don't do anything (remove the UseNewCode check)
>>>>>>> b) add a new diagnostic flag
>>>>>>> c) add a new experimental flag
>>>>>>
>>>>>> My vote:
>>>>>>
>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
>>>>>>
>>>>>> With a plan (and a bug) to remove that option down the road.
>>>>>>
>>>>>> And a code review.
>>>>>>
>>>>>> src/os/linux/vm/os_linux.cpp
>>>>>>     No comments.
>>>>>>
>>>>>> src/share/vm/logging/logTag.hpp
>>>>>>     No comments.
>>>>>>
>>>>>> test/runtime/os/AvailableProcessors.java
>>>>>>     Nice test. I like that the default (no args) runs a set of tests
>>>>>>     and if you (manually) run the test with a specific arg it will
>>>>>>     check just that one value.
>>>>>>
>>>>>> Thumbs up! (Assuming you change UseNewCode to something else or
>>>>>> delete its use all together.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>>   - JPRT
>>>>>>>>
>>>>>>>> Compatability issues:
>>>>>>>> - the system code we're using now is at least 5 years old so
>>>>>>>> distro's
>>>>>>>> older than that (which are not officially supported) may not work
>>>>>>>> - anyone already running under a processor constrained environment
>>>>>>>> (like
>>>>>>>> Docker) and using availableProcessor() to "size" things, will find
>>>>>>>> that
>>>>>>>> size has now changed. We do not expect this to be a problem - on
>>>>>>>> the
>>>>>>>> contrary we expect Docker users to want the new behaviour.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>
>>>>>
>>>
>

From jiangli.zhou at Oracle.COM  Fri Jan 29 00:50:45 2016
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Thu, 28 Jan 2016 16:50:45 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA6BFE.7090505@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
Message-ID: <B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>

Hi Max,

The changes look very good. I have just few minor comments and questions below.

- klass.cpp
I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.

- filemap.cpp
?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?

The same question for other changes in filemap.cpp.

- instanceKlass.cpp
Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.

- arguments.cpp
LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).

Thanks,
Jiangli


> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
> 
> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
> 
> Hopefully nearing the end:
> 
> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
> 
> -------- Original Message --------
> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
> From: 	Ioi Lam <ioi.lam at oracle.com>
> To: 	Max Ockner <max.ockner at oracle.com>
> 
> 
> 
> Hi Max,
> 
> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
> 
> Thanks
> - Ioi
> 
> On 1/28/16 8:11 AM, Max Ockner wrote:
>> Ioi,
>> I have replaced my test with this test that you have given me (thank you!)
>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>> Thanks,
>> Max
>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>> 
>>> 
>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>> 
>>> 
>>> Hi Max,
>>> 
>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>> 
>>>        Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>> 
>>> That's because of this line in ClassUnloadCommon:
>>> 
>>>            return new URLClassLoader(new URL[] {
>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>            }, null);
>>> 
>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>> 
>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>> 
>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>> 
>>> /*
>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>> * for an example.
>>> */
>>> 
>>> What do you think?
>>> - Ioi
>> 
> 
> 
> 


From david.holmes at oracle.com  Fri Jan 29 01:01:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jan 2016 11:01:00 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
Message-ID: <56AAB9CC.5040307@oracle.com>

On 29/01/2016 10:50 AM, Jiangli Zhou wrote:
> Hi Max,
>
> The changes look very good. I have just few minor comments and questions below.
>
> - klass.cpp
> I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.

Good catch - we need the "if (log_is_enabled())" check to ensure the 
ResourceMark is only defined when logging is enabled, but then the 
actual log statement should be the direct form, not the log_xxx() macro 
form. E.g as used here for exceptions logging:

       if (log_is_enabled(Info, exceptions)) {
         ResourceMark rm;
         outputStream* logstream = LogHandle(exceptions)::info_stream();
         logstream->print("Async. exception installed at runtime exit (" 
INTPTR_FORMAT ")", p2i(this));


David

> - filemap.cpp
> ?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?
>
> The same question for other changes in filemap.cpp.
>
> - instanceKlass.cpp
> Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.
>
> - arguments.cpp
> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).
>
> Thanks,
> Jiangli
>
>
>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>
>> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
>>
>> Hopefully nearing the end:
>>
>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>
>> -------- Original Message --------
>> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
>> From: 	Ioi Lam <ioi.lam at oracle.com>
>> To: 	Max Ockner <max.ockner at oracle.com>
>>
>>
>>
>> Hi Max,
>>
>> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
>>
>> Thanks
>> - Ioi
>>
>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>> Ioi,
>>> I have replaced my test with this test that you have given me (thank you!)
>>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>>> Thanks,
>>> Max
>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>
>>>>
>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>>>
>>>>
>>>> Hi Max,
>>>>
>>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>>>
>>>>         Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>>>
>>>> That's because of this line in ClassUnloadCommon:
>>>>
>>>>             return new URLClassLoader(new URL[] {
>>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>>             }, null);
>>>>
>>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>>>
>>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>>>
>>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>>>
>>>> /*
>>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>> * for an example.
>>>> */
>>>>
>>>> What do you think?
>>>> - Ioi
>>>
>>
>>
>>
>

From coleen.phillimore at oracle.com  Fri Jan 29 02:39:14 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 28 Jan 2016 21:39:14 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AAB9CC.5040307@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AAB9CC.5040307@oracle.com>
Message-ID: <56AAD0D2.8040103@oracle.com>



On 1/28/16 8:01 PM, David Holmes wrote:
> On 29/01/2016 10:50 AM, Jiangli Zhou wrote:
>> Hi Max,
>>
>> The changes look very good. I have just few minor comments and 
>> questions below.
>>
>> - klass.cpp
>> I?m new to the logging code, so I might be wrong. It seems the ?if 
>> (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are 
>> not needed since log_trace() also checks if the trace flag is enabled.
>
> Good catch - we need the "if (log_is_enabled())" check to ensure the 
> ResourceMark is only defined when logging is enabled, but then the 
> actual log statement should be the direct form, not the log_xxx() 
> macro form. E.g as used here for exceptions logging:
>
>       if (log_is_enabled(Info, exceptions)) {
>         ResourceMark rm;
>         outputStream* logstream = LogHandle(exceptions)::info_stream();
>         logstream->print("Async. exception installed at runtime exit 
> (" INTPTR_FORMAT ")", p2i(this));
>

I think I had him change it to be the more compact looking form of 
log_info(classload)("message") .  I don't think the implementation 
details need to be exposed just to avoid testing the logging tag twice.  
It would be nice to have a log macro that also had a resource_mark 
enclosed.  We have a lot of these.

log_info_rm(classload)("message %s", foo->external_name());

Coleen

>
> David
>
>> - filemap.cpp
>> ?TraceClassLoading && Verbose? is removed at line 211. Should a 
>> ?log_info(classload)? call be added? Or maybe the skipping of 
>> classloading trace for shared path is intentional?
>>
>> The same question for other changes in filemap.cpp.
>>
>> - instanceKlass.cpp
>> Please break line 2908 into two lines so it?s not too long. There are 
>> a few other long lines in print_loading_log() should be broken into two.
>>
>> - arguments.cpp
>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading 
>> in aliased_logging_flags[]. Should there be one for LogLevel::Debug 
>> for the classloading tracing? Maybe there is no old styled option for 
>> debug level class loading trace, so it's not defined in 
>> aliased_logging_flags(?).
>>
>> Thanks,
>> Jiangli
>>
>>
>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>>
>>> Forwarded private discussion with Ioi about changing the test to use 
>>> ClassUnloadCommon.
>>>
>>> Hopefully nearing the end:
>>>
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>
>>> -------- Original Message --------
>>> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading, 
>>> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>> Date:     Thu, 28 Jan 2016 10:57:15 -0800
>>> From:     Ioi Lam <ioi.lam at oracle.com>
>>> To:     Max Ockner <max.ockner at oracle.com>
>>>
>>>
>>>
>>> Hi Max,
>>>
>>> Thanks for doing this. Also, I sent the e-mail to you personally, so 
>>> you may want to post the new version in the open list for record 
>>> purpose.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>> Ioi,
>>>> I have replaced my test with this test that you have given me 
>>>> (thank you!)
>>>> I also have removed the commented out section which used to test 
>>>> for "making nmethod ...", and I have added the comment that you 
>>>> suggested at the top of ClassUnloadCommon.java
>>>> Thanks,
>>>> Max
>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>
>>>>>
>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>> Though Ioi suggested I change my new test, I have not done that. 
>>>>>> I was recommended to copy from 
>>>>>> runtime/ClassUnload/UnloadTest.java instead of rolling my own 
>>>>>> test for class unloading. I mentioned that it was tricky to make 
>>>>>> the new test work, but it was tricky because I was trying to copy 
>>>>>> from UnloadTest.java. This test refers to a class "test.Empty" 
>>>>>> from a "classes" library, but the new test has a processBuilder 
>>>>>> which I think does not play nicely with the class path for  
>>>>>> "test.Empty". In the end it was much easier to hardcode the 
>>>>>> entire test into one place than to follow UnloadTest.java and 
>>>>>> refer to extra libraries.
>>>>>>
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> I've written a version of ClassLoadUnloadTest.java using 
>>>>> ClassUnloadCommon. The main trick is here:
>>>>>
>>>>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>>>>> System.getProperty("test.classes","."));
>>>>>
>>>>> That's because of this line in ClassUnloadCommon:
>>>>>
>>>>>             return new URLClassLoader(new URL[] {
>>>>> Paths.get(System.getProperty("test.classes",".") + 
>>>>> File.separatorChar + "classes").toUri().toURL(),
>>>>>             }, null);
>>>>>
>>>>> When Jtreg launches a sub-process, it strips off all the Java 
>>>>> system properties, so you need to add the "-D" in the command-line.
>>>>>
>>>>> I also disabled the test related to "making nmethod ... 
>>>>> unloadable". As Rachel found out in JDK-8146137, the compiler is 
>>>>> unpredictable. Even if you invoke a method 10001 times, there's no 
>>>>> guaranteed that it will always be compiled. Since this is not an 
>>>>> 'easy-to-test' feature, we should just skip it.
>>>>>
>>>>> I would also suggest adding this to the header of 
>>>>> ClassUnloadCommon.java
>>>>>
>>>>> /*
>>>>> * To use ClassUnloadCommon from a sub-process, see 
>>>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>> * for an example.
>>>>> */
>>>>>
>>>>> What do you think?
>>>>> - Ioi
>>>>
>>>
>>>
>>>
>>


From david.holmes at oracle.com  Fri Jan 29 02:46:06 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jan 2016 12:46:06 +1000
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AAD0D2.8040103@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AAB9CC.5040307@oracle.com> <56AAD0D2.8040103@oracle.com>
Message-ID: <56AAD26E.4020505@oracle.com>

On 29/01/2016 12:39 PM, Coleen Phillimore wrote:
> On 1/28/16 8:01 PM, David Holmes wrote:
>> On 29/01/2016 10:50 AM, Jiangli Zhou wrote:
>>> Hi Max,
>>>
>>> The changes look very good. I have just few minor comments and
>>> questions below.
>>>
>>> - klass.cpp
>>> I?m new to the logging code, so I might be wrong. It seems the ?if
>>> (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are
>>> not needed since log_trace() also checks if the trace flag is enabled.
>>
>> Good catch - we need the "if (log_is_enabled())" check to ensure the
>> ResourceMark is only defined when logging is enabled, but then the
>> actual log statement should be the direct form, not the log_xxx()
>> macro form. E.g as used here for exceptions logging:
>>
>>       if (log_is_enabled(Info, exceptions)) {
>>         ResourceMark rm;
>>         outputStream* logstream = LogHandle(exceptions)::info_stream();
>>         logstream->print("Async. exception installed at runtime exit
>> (" INTPTR_FORMAT ")", p2i(this));
>>
>
> I think I had him change it to be the more compact looking form of
> log_info(classload)("message") .  I don't think the implementation
> details need to be exposed just to avoid testing the logging tag twice.
> It would be nice to have a log macro that also had a resource_mark
> enclosed.  We have a lot of these.
>
> log_info_rm(classload)("message %s", foo->external_name());

Perhaps. And/Or we could have simplified macro forms that don't 
double-up on the is-enabled check. The current doubling-up of the check 
seems to be prevalent in the GC logging code too.

David

> Coleen
>
>>
>> David
>>
>>> - filemap.cpp
>>> ?TraceClassLoading && Verbose? is removed at line 211. Should a
>>> ?log_info(classload)? call be added? Or maybe the skipping of
>>> classloading trace for shared path is intentional?
>>>
>>> The same question for other changes in filemap.cpp.
>>>
>>> - instanceKlass.cpp
>>> Please break line 2908 into two lines so it?s not too long. There are
>>> a few other long lines in print_loading_log() should be broken into two.
>>>
>>> - arguments.cpp
>>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading
>>> in aliased_logging_flags[]. Should there be one for LogLevel::Debug
>>> for the classloading tracing? Maybe there is no old styled option for
>>> debug level class loading trace, so it's not defined in
>>> aliased_logging_flags(?).
>>>
>>> Thanks,
>>> Jiangli
>>>
>>>
>>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>>>
>>>> Forwarded private discussion with Ioi about changing the test to use
>>>> ClassUnloadCommon.
>>>>
>>>> Hopefully nearing the end:
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>>
>>>> -------- Original Message --------
>>>> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading,
>>>> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>>> Date:     Thu, 28 Jan 2016 10:57:15 -0800
>>>> From:     Ioi Lam <ioi.lam at oracle.com>
>>>> To:     Max Ockner <max.ockner at oracle.com>
>>>>
>>>>
>>>>
>>>> Hi Max,
>>>>
>>>> Thanks for doing this. Also, I sent the e-mail to you personally, so
>>>> you may want to post the new version in the open list for record
>>>> purpose.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>>> Ioi,
>>>>> I have replaced my test with this test that you have given me
>>>>> (thank you!)
>>>>> I also have removed the commented out section which used to test
>>>>> for "making nmethod ...", and I have added the comment that you
>>>>> suggested at the top of ClassUnloadCommon.java
>>>>> Thanks,
>>>>> Max
>>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>>
>>>>>>
>>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>>> Though Ioi suggested I change my new test, I have not done that.
>>>>>>> I was recommended to copy from
>>>>>>> runtime/ClassUnload/UnloadTest.java instead of rolling my own
>>>>>>> test for class unloading. I mentioned that it was tricky to make
>>>>>>> the new test work, but it was tricky because I was trying to copy
>>>>>>> from UnloadTest.java. This test refers to a class "test.Empty"
>>>>>>> from a "classes" library, but the new test has a processBuilder
>>>>>>> which I think does not play nicely with the class path for
>>>>>>> "test.Empty". In the end it was much easier to hardcode the
>>>>>>> entire test into one place than to follow UnloadTest.java and
>>>>>>> refer to extra libraries.
>>>>>>>
>>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> I've written a version of ClassLoadUnloadTest.java using
>>>>>> ClassUnloadCommon. The main trick is here:
>>>>>>
>>>>>>         Collections.addAll(argsList, "-Dtest.classes=" +
>>>>>> System.getProperty("test.classes","."));
>>>>>>
>>>>>> That's because of this line in ClassUnloadCommon:
>>>>>>
>>>>>>             return new URLClassLoader(new URL[] {
>>>>>> Paths.get(System.getProperty("test.classes",".") +
>>>>>> File.separatorChar + "classes").toUri().toURL(),
>>>>>>             }, null);
>>>>>>
>>>>>> When Jtreg launches a sub-process, it strips off all the Java
>>>>>> system properties, so you need to add the "-D" in the command-line.
>>>>>>
>>>>>> I also disabled the test related to "making nmethod ...
>>>>>> unloadable". As Rachel found out in JDK-8146137, the compiler is
>>>>>> unpredictable. Even if you invoke a method 10001 times, there's no
>>>>>> guaranteed that it will always be compiled. Since this is not an
>>>>>> 'easy-to-test' feature, we should just skip it.
>>>>>>
>>>>>> I would also suggest adding this to the header of
>>>>>> ClassUnloadCommon.java
>>>>>>
>>>>>> /*
>>>>>> * To use ClassUnloadCommon from a sub-process, see
>>>>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>>> * for an example.
>>>>>> */
>>>>>>
>>>>>> What do you think?
>>>>>> - Ioi
>>>>>
>>>>
>>>>
>>>>
>>>
>

From yumin.qi at oracle.com  Fri Jan 29 04:35:15 2016
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 28 Jan 2016 20:35:15 -0800
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <569FD7EF.2010007@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
	<569FD7EF.2010007@oracle.com>
Message-ID: <56AAEC03.6070209@oracle.com>

Vladimir and Coleen,

   Based on fix of 8143320 (which passed synced jdk from future ASM5.1), 
I think the relax can be removed now.
   New webrev (based on current hs-rt repo) remove relax check on 
MethodHandle resolution and some copyright year to 2016.

http://cr.openjdk.java.net/~minqi/8145148/webrev-02/

    Testing on defmeth (fix 8143320) with jdk (contains new version of 
Handle from ASM5.1). Now the only issue is waiting for vm test 
co-location project so it can be built with current jdk.

on testlist/vm.defmeth.testlist:

TOTAL TESTS IN RUN: 696
TEST PASS: 696; 100% rate
TEST FAIL: 0; 0% rate
TEST UNDEFINED: 0; 0% rate
TEST INCOMPLETE: 0; 0% rate
TESTS NOT RUN: 0

TOTAL TEST IN TESTLIST: 696



   Thanks
   Yumin

On 1/20/2016 10:54 AM, Yumin Qi wrote:
> Hi, Vladimir
>
>   I filed another bug 8147755 for ASM which now I have a fix for it: 
> make asm create correct constant tag for a handle pointing to 
> interface static method.
> https://bugs.openjdk.java.net/browse/JDK-8147755
>
>   I have a simple test case showed it works to generate a callsite 
> for  static I.m:
>
> Constant pool:
> ....
>   #16 = Utf8               Calling static I.m():
>   #17 = String             #16            // Calling static I.m():
>   #18 = Utf8               java/io/PrintStream
>   #19 = Class              #18            // java/io/PrintStream
>   #20 = Utf8               println
>   #21 = Utf8               (Ljava/lang/String;)V
>   #22 = NameAndType        #20:#21        // 
> println:(Ljava/lang/String;)V
>   #23 = Methodref          #19.#22        // 
> java/io/PrintStream.println:(Ljava/lang/String;)V
>   #24 = Utf8               I
>   #25 = Class              #24            // I
>   #26 = Utf8               m
>   #27 = NameAndType        #26:#6         // m:()V
>   #28 = InterfaceMethodref #25.#27        // I.m:()V
>   #29 = MethodHandle       #6:#28         // invokestatic I.m:()V
>   #30 = Utf8               java/lang/invoke/MethodHandle
> ....
> {
>   public static void staticCallIm();
>     descriptor: ()V
>     flags: ACC_PUBLIC, ACC_STATIC
>     Code:
>       stack=3, locals=1, args_size=0
>          0: getstatic     #15                 // Field 
> java/lang/System.out:Ljava/io/PrintStream;
>          3: ldc           #17                 // String Calling static 
> I.m():
>          5: invokevirtual #23                 // Method 
> java/io/PrintStream.println:(Ljava/lang/String;)V
>          8: ldc           #29                 // MethodHandle 
> invokestatic I.m:()V
>         10: invokevirtual #34                 // Method 
> java/lang/invoke/MethodHandle.invoke:()V
>         13: return
> }
>
>    So now keep the original fix of 8087223 as 8145148 fix and relax 
> for the check in method handle method tag no longer needed with 
> 8147755 solved.
>
>    Still, I need to test defmeth again to see the failed cases --- and 
> the fix will be in defmeth use the new added Handle.
>
>     Stas and Dmitry:
>     8143320 fix may change if tests on new binary with 8145148/8147755 
> shows defmeth needs changes too(I think so, since I add a new Handle 
> constructor).
>
>      The previous webrev now has conflict with the current repo so 
> need make new webrev and send codereview again.
>
> Thanks
> Yumin
>
> On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
>> Yumin,
>>
>> Please, file a follow-up bug for the missing check (interface static 
>> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>>
>> I'd prefer to keep the original VM fix and quarantine affected tests 
>> until ASM is fixed, but 2-phase fix is also fine with me.
>>
>> Not sure how to handle ASM problem. Is the problem present in the 
>> latest ASM version?
>>
>> The best way would be to get it fixed upstream first and then sync 
>> internal copy with upstream. defmeth tests use the library bundled 
>> with the JDK.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 12/21/15 9:52 PM, Yumin Qi wrote:
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>
>>> This is REDO for bug 8087223, which was backed out due to failed on
>>> 8143317 and 8143320.
>>> The defmeth encoutered new failures after the fix, which now has 
>>> correct
>>> constant tags. The test bugs will be addressed in 8143320, which based
>>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>
>>> One difference from the attached for this webrev is that in 
>>> MethodHandle
>>> resolution, I relax the check for one specific case: Using MethodHandle
>>> to invoke static default interface method. In this case, we must use
>>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>>> interface method tag!).  ASM currently has no API to generate
>>> invokeinterface for a interface static default method through
>>> MethodHandle invocation.
>>>
>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>> Note the fix still fails 8143320 and 8143317 which are not fixed at the
>>> momment.
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> Original post:
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>
>>> According to JVMS-8:
>>>
>>> JVMS-5.4.3.3 Method Resolution:
>>>   " If C is an interface, method resolution throws an
>>> IncompatibleClassChangeError."
>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>   "If C is not an interface, interface method resolution throws an
>>> IncompatibleClassChangeError"
>>>
>>> When invoke a method with resolved to an interface method, or invoke a
>>> interface method with resolved to an instance method,  ICCE should be
>>> thrown. The case usually happens when using tools like asmtools or
>>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>>
>>> The fix is carrying the constantTag for the method at call and check if
>>> tag is consistent with the method called. Doing this by adding a member
>>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>>> to see if tag matched with the correct method.
>>>
>>> The fix solved the problem when call is from interpreter and compiler,
>>> bug for MethodHandle invoke, which should be addressed in another bug,
>>> since the MethodHandle does not come with a byte stream and getting the
>>> constant pool index at the invoke is not possible.  It will be 
>>> addressed
>>> in another bug.
>>>
>>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>>> test list(in progress).
>>> manually tested:  1) -Xint
>>>                                 2) -Xcomp
>>>                                 3) -Xcomp -XX:-TieredCompiltion
>>>                                 4) -Xcomp -XX:+TieredCompilation
>>>
>>> Thanks to Coleen for helping fixed constant pool index and cleaned
>>> LinkInfo.
>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>> Second revision attached.
>>>
>>>
>>>
>>>
>>> Thanks
>>> Yumin
>


From thomas.stuefe at gmail.com  Fri Jan 29 08:53:52 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 29 Jan 2016 09:53:52 +0100
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <56AAA528.70409@oracle.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>
	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>
	<56A9B83A.6040808@oracle.com>
	<CAA-vtUx5EgxsJOKNzgtaC_bsZU3HstKf+92yuTJRi9ndWeN0ng@mail.gmail.com>
	<56AAA528.70409@oracle.com>
Message-ID: <CAA-vtUzgwsx80TjsAdNi28Be4eeXyRt-J9_AiOjkr1=U080nuw@mail.gmail.com>

Hi Ioi,

Your suggestion makes sense, I changed the fix accordingly.

New webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.02/webrev/

Kind Regards, Thomas


On Fri, Jan 29, 2016 at 12:32 AM, Ioi Lam <ioi.lam at oracle.com> wrote:

> Hi Thomas,
>
> Thanks for taking my suggestion :-)
>
> To make the intention of the truncation check clearer, how about
> reorganizing the code to:
>
>   if (os::dll_address_to_library_name(addr, buf, sizeof(buf), &offset)) {
>     st->print(PTR_FORMAT " ", addr);
>     if (strlen(buf) < sizeof(buf)-1) {
>       char* p = strrchr(buf, '\\');
>       if (p) {
>         st->print("%s", p + 1);
>       } else {
>         st->print("%s", buf);
>       } else {
>         // The library name is probably truncated. Let's omit the library
> name.
>         // See also JDK-8147512.
>       }
>     }
>
> I'd say 'probably' because the name could be exactly 255 characters long
> ...
>
> Thanks
> - Ioi
>
>
>
> On 1/28/16 5:01 AM, Thomas St?fe wrote:
>
> Hi Ioi,
>
> thanks a lot for the review!
>
> You are right, displaying the function name is more useful. I wanted to
> postpone this until I could start
> https://bugs.openjdk.java.net/browse/JDK-8147512, but now I took your
> suggestion and implemented this anyway.
>
> See here new webrev:
>
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev
>
> Notes:
> -I decided to cut off the path for libraries to make the printout easier
> to the eye; also, in the DLL-section we print out all DLLs including paths.
> -There is no clean way to handle truncation of long library paths, so I
> decided to at least detect truncation and if it happens to not print the
> library at all. I want to avoid large on-stack buffers, therefore I keep
> the result buffer relativly small (256 bytes). A better approach would be
> to - if os::find is used from error handling - hand down the error handling
> scratch buffer like we do in many other cases. But this is beyond the scope
> for this small fix.
>
> New printout looks like this:
>
>  35 Register to memory mapping:
>  36
>  37 RIP=0x000000006ddd6a43 jvm.dll::crash_with_segfault + 0x13
>  38 RAX=0xabc0000000000abc is an unknown value
>
> Kind Regards, Thomas
>
>
>
> On Thu, Jan 28, 2016 at 7:42 AM, Ioi Lam <ioi.lam at oracle.com> wrote:
>
>> Hi Thomas,
>>
>> 5269 bool os::find(address addr, outputStream* st) {
>> 5270   int offset = -1;
>> 5271   char buf[255];
>> 5272   if (os::dll_address_to_library_name(addr, buf, sizeof(buf),
>> &offset)) {
>> 5273     st->print_cr("%s + %x", buf, offset);
>> 5274     return true;
>> 5275   }
>> 5276   return false;
>> 5277 }
>>
>>
>> Have you tried calling os::dll_address_to_function_name as well so you
>> can get the function name?
>>
>> I noticed that the Linux version of os::find contains code for printing
>> out the function name, but couldn't find an hs_err file where that code is
>> actually used:
>>
>> bool os::find(address addr, outputStream* st) {
>>     ...
>>     if (dlinfo.dli_fname != NULL) {
>>       st->print(" in %s", dlinfo.dli_fname);
>>     }
>>
>>
>> Thanks
>> - Ioi
>>
>>
>> On 1/19/16 11:53 PM, Thomas St?fe wrote:
>>
>>> May I please have a review and a sponsor?
>>>
>>> Thank you!
>>>
>>> On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> could I please have reviews and a sponsor for this small fix:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>>>
>>>> When we print register to memory info in hs-err file, text addresses are
>>>> not resolved on windows like on other platforms:
>>>>
>>>> "RCX=0x000000005efa0000 is an unknown value"
>>>>
>>>> This fix changes this (the same way it is implemented on other
>>>> platforms):
>>>>
>>>> "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll
>>>> +
>>>> 0"
>>>>
>>>> Please note that this printout and the code behind it could be improved
>>>> and cleaned up a lot. For instance, I know that using an on-stack
>>>> buffer in
>>>> os::find() is not the best implementation here. But I wanted a minimal
>>>> change. For the follow-up work, I opened a new bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8147512.
>>>>
>>>> Thanks & Regards, Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
>

From vladimir.x.ivanov at oracle.com  Fri Jan 29 09:44:09 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 29 Jan 2016 12:44:09 +0300
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56AAEC03.6070209@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
	<569FD7EF.2010007@oracle.com> <56AAEC03.6070209@oracle.com>
Message-ID: <56AB3469.40109@oracle.com>

That's awesome! My congratulations with success in this multi-project 
effort! :-)

Best regards,
Vladimir Ivanov

On 1/29/16 7:35 AM, Yumin Qi wrote:
> Vladimir and Coleen,
>
>    Based on fix of 8143320 (which passed synced jdk from future ASM5.1),
> I think the relax can be removed now.
>    New webrev (based on current hs-rt repo) remove relax check on
> MethodHandle resolution and some copyright year to 2016.
>
> http://cr.openjdk.java.net/~minqi/8145148/webrev-02/
>
>     Testing on defmeth (fix 8143320) with jdk (contains new version of
> Handle from ASM5.1). Now the only issue is waiting for vm test
> co-location project so it can be built with current jdk.
>
> on testlist/vm.defmeth.testlist:
>
> TOTAL TESTS IN RUN: 696
> TEST PASS: 696; 100% rate
> TEST FAIL: 0; 0% rate
> TEST UNDEFINED: 0; 0% rate
> TEST INCOMPLETE: 0; 0% rate
> TESTS NOT RUN: 0
>
> TOTAL TEST IN TESTLIST: 696
>
>
>
>    Thanks
>    Yumin
>
> On 1/20/2016 10:54 AM, Yumin Qi wrote:
>> Hi, Vladimir
>>
>>   I filed another bug 8147755 for ASM which now I have a fix for it:
>> make asm create correct constant tag for a handle pointing to
>> interface static method.
>> https://bugs.openjdk.java.net/browse/JDK-8147755
>>
>>   I have a simple test case showed it works to generate a callsite
>> for  static I.m:
>>
>> Constant pool:
>> ....
>>   #16 = Utf8               Calling static I.m():
>>   #17 = String             #16            // Calling static I.m():
>>   #18 = Utf8               java/io/PrintStream
>>   #19 = Class              #18            // java/io/PrintStream
>>   #20 = Utf8               println
>>   #21 = Utf8               (Ljava/lang/String;)V
>>   #22 = NameAndType        #20:#21        //
>> println:(Ljava/lang/String;)V
>>   #23 = Methodref          #19.#22        //
>> java/io/PrintStream.println:(Ljava/lang/String;)V
>>   #24 = Utf8               I
>>   #25 = Class              #24            // I
>>   #26 = Utf8               m
>>   #27 = NameAndType        #26:#6         // m:()V
>>   #28 = InterfaceMethodref #25.#27        // I.m:()V
>>   #29 = MethodHandle       #6:#28         // invokestatic I.m:()V
>>   #30 = Utf8               java/lang/invoke/MethodHandle
>> ....
>> {
>>   public static void staticCallIm();
>>     descriptor: ()V
>>     flags: ACC_PUBLIC, ACC_STATIC
>>     Code:
>>       stack=3, locals=1, args_size=0
>>          0: getstatic     #15                 // Field
>> java/lang/System.out:Ljava/io/PrintStream;
>>          3: ldc           #17                 // String Calling static
>> I.m():
>>          5: invokevirtual #23                 // Method
>> java/io/PrintStream.println:(Ljava/lang/String;)V
>>          8: ldc           #29                 // MethodHandle
>> invokestatic I.m:()V
>>         10: invokevirtual #34                 // Method
>> java/lang/invoke/MethodHandle.invoke:()V
>>         13: return
>> }
>>
>>    So now keep the original fix of 8087223 as 8145148 fix and relax
>> for the check in method handle method tag no longer needed with
>> 8147755 solved.
>>
>>    Still, I need to test defmeth again to see the failed cases --- and
>> the fix will be in defmeth use the new added Handle.
>>
>>     Stas and Dmitry:
>>     8143320 fix may change if tests on new binary with 8145148/8147755
>> shows defmeth needs changes too(I think so, since I add a new Handle
>> constructor).
>>
>>      The previous webrev now has conflict with the current repo so
>> need make new webrev and send codereview again.
>>
>> Thanks
>> Yumin
>>
>> On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
>>> Yumin,
>>>
>>> Please, file a follow-up bug for the missing check (interface static
>>> method referenced by a MethodHandle). We shouldn't leave it half-fixed.
>>>
>>> I'd prefer to keep the original VM fix and quarantine affected tests
>>> until ASM is fixed, but 2-phase fix is also fine with me.
>>>
>>> Not sure how to handle ASM problem. Is the problem present in the
>>> latest ASM version?
>>>
>>> The best way would be to get it fixed upstream first and then sync
>>> internal copy with upstream. defmeth tests use the library bundled
>>> with the JDK.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 12/21/15 9:52 PM, Yumin Qi wrote:
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>>
>>>> This is REDO for bug 8087223, which was backed out due to failed on
>>>> 8143317 and 8143320.
>>>> The defmeth encoutered new failures after the fix, which now has
>>>> correct
>>>> constant tags. The test bugs will be addressed in 8143320, which based
>>>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>>
>>>> One difference from the attached for this webrev is that in
>>>> MethodHandle
>>>> resolution, I relax the check for one specific case: Using MethodHandle
>>>> to invoke static default interface method. In this case, we must use
>>>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will generate
>>>> method tag for interface which violates JVMS-5.4.3.3 (it should create
>>>> interface method tag!).  ASM currently has no API to generate
>>>> invokeinterface for a interface static default method through
>>>> MethodHandle invocation.
>>>>
>>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>>> Note the fix still fails 8143320 and 8143317 which are not fixed at the
>>>> momment.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> Original post:
>>>> -----------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>>
>>>> According to JVMS-8:
>>>>
>>>> JVMS-5.4.3.3 Method Resolution:
>>>>   " If C is an interface, method resolution throws an
>>>> IncompatibleClassChangeError."
>>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>>   "If C is not an interface, interface method resolution throws an
>>>> IncompatibleClassChangeError"
>>>>
>>>> When invoke a method with resolved to an interface method, or invoke a
>>>> interface method with resolved to an instance method,  ICCE should be
>>>> thrown. The case usually happens when using tools like asmtools or
>>>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>>>
>>>> The fix is carrying the constantTag for the method at call and check if
>>>> tag is consistent with the method called. Doing this by adding a member
>>>> of constantTag, _tag,  to LinkInfo, and check tag in resolve functions
>>>> to see if tag matched with the correct method.
>>>>
>>>> The fix solved the problem when call is from interpreter and compiler,
>>>> bug for MethodHandle invoke, which should be addressed in another bug,
>>>> since the MethodHandle does not come with a byte stream and getting the
>>>> constant pool index at the invoke is not possible.  It will be
>>>> addressed
>>>> in another bug.
>>>>
>>>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>>>> test list(in progress).
>>>> manually tested:  1) -Xint
>>>>                                 2) -Xcomp
>>>>                                 3) -Xcomp -XX:-TieredCompiltion
>>>>                                 4) -Xcomp -XX:+TieredCompilation
>>>>
>>>> Thanks to Coleen for helping fixed constant pool index and cleaned
>>>> LinkInfo.
>>>> ----------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Second revision attached.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>
>

From dmitry.dmitriev at oracle.com  Fri Jan 29 14:47:21 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 29 Jan 2016 17:47:21 +0300
Subject: RFR(XS): 8146187: Print develop and nonproduct flags by
	-XX:+PrintFlags* options in debug build
In-Reply-To: <F547B025-FC18-4A8F-A150-879D27C228D8@oracle.com>
References: <569E1ECE.1070302@oracle.com> <56A9F667.5050805@oracle.com>
	<F547B025-FC18-4A8F-A150-879D27C228D8@oracle.com>
Message-ID: <56AB7B79.5030103@oracle.com>

Hi Gerard,

Thank you for looking into that. Please see my comments inline.

Dmitry

On 28.01.2016 20:49, Gerard Ziemski wrote:
> Resending referencing the correct issue:
>
> hi Dmitry,
>
>
> ----
> src/share/vm/runtime/globals.cpp
>
> No comments except that this was easy ;-) And thank you for getting rid of extraneous ?printRanges? check.
You are welcome :)
>
> ---
> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
>
> So we are not going to test the debug (non-product) flags at all, even on the debug build? (requires too much time?)
Yes, from my point of view this is not needed. These flags are used for 
development and are constant in product build. I think that these flags 
can increase testing time due it's development nature.

Dmitry
>
>
>> On Jan 28, 2016, at 5:07 AM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com> wrote:
>>
>> Hello,
>>
>> Can I get review for that small patch please?
>>
>> Thanks,
>> Dmitry
>>
>> On 19.01.2016 14:32, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review small fix for printing flags functionality. This fix return ability to print develop and not product flags in debug VM by -XX:+PrintFlags* options.
>>> Few comments:
>>> 1) "if (printRanges) {" on line 407 in globals.cpp was deleted, because it located in else branch of "if (!printRanges) {" and therefore always true.
>>> 2) TestOptionsWithRanges.java was corrected to not pick develop and not product flags.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8146187
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8146187/webrev.00/ <http://cr.openjdk.java.net/%7Eddmitriev/8146187/webrev.00/>
>>> Testing: JPRT, hotspot_all, vm.quick
>>>
>>> Thanks,
>>> Dmitry


From coleen.phillimore at oracle.com  Fri Jan 29 14:51:07 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 29 Jan 2016 09:51:07 -0500
Subject: RFR: 8145148: InterfaceMethod CP entry pointing to a class should
	cause ICCE
In-Reply-To: <56AB3469.40109@oracle.com>
References: <56784A53.5090203@oracle.com> <56977DBB.3070502@oracle.com>
	<569FD7EF.2010007@oracle.com> <56AAEC03.6070209@oracle.com>
	<56AB3469.40109@oracle.com>
Message-ID: <56AB7C5B.6070906@oracle.com>


I agree.  This is great news!  The code still looks good.  I tried to 
update the links and believe it's blocked on 8143320 and 8147755.

Coleen

On 1/29/16 4:44 AM, Vladimir Ivanov wrote:
> That's awesome! My congratulations with success in this multi-project 
> effort! :-)
>
> Best regards,
> Vladimir Ivanov
>
> On 1/29/16 7:35 AM, Yumin Qi wrote:
>> Vladimir and Coleen,
>>
>>    Based on fix of 8143320 (which passed synced jdk from future ASM5.1),
>> I think the relax can be removed now.
>>    New webrev (based on current hs-rt repo) remove relax check on
>> MethodHandle resolution and some copyright year to 2016.
>>
>> http://cr.openjdk.java.net/~minqi/8145148/webrev-02/
>>
>>     Testing on defmeth (fix 8143320) with jdk (contains new version of
>> Handle from ASM5.1). Now the only issue is waiting for vm test
>> co-location project so it can be built with current jdk.
>>
>> on testlist/vm.defmeth.testlist:
>>
>> TOTAL TESTS IN RUN: 696
>> TEST PASS: 696; 100% rate
>> TEST FAIL: 0; 0% rate
>> TEST UNDEFINED: 0; 0% rate
>> TEST INCOMPLETE: 0; 0% rate
>> TESTS NOT RUN: 0
>>
>> TOTAL TEST IN TESTLIST: 696
>>
>>
>>
>>    Thanks
>>    Yumin
>>
>> On 1/20/2016 10:54 AM, Yumin Qi wrote:
>>> Hi, Vladimir
>>>
>>>   I filed another bug 8147755 for ASM which now I have a fix for it:
>>> make asm create correct constant tag for a handle pointing to
>>> interface static method.
>>> https://bugs.openjdk.java.net/browse/JDK-8147755
>>>
>>>   I have a simple test case showed it works to generate a callsite
>>> for  static I.m:
>>>
>>> Constant pool:
>>> ....
>>>   #16 = Utf8               Calling static I.m():
>>>   #17 = String             #16            // Calling static I.m():
>>>   #18 = Utf8               java/io/PrintStream
>>>   #19 = Class              #18            // java/io/PrintStream
>>>   #20 = Utf8               println
>>>   #21 = Utf8               (Ljava/lang/String;)V
>>>   #22 = NameAndType        #20:#21        //
>>> println:(Ljava/lang/String;)V
>>>   #23 = Methodref          #19.#22        //
>>> java/io/PrintStream.println:(Ljava/lang/String;)V
>>>   #24 = Utf8               I
>>>   #25 = Class              #24            // I
>>>   #26 = Utf8               m
>>>   #27 = NameAndType        #26:#6         // m:()V
>>>   #28 = InterfaceMethodref #25.#27        // I.m:()V
>>>   #29 = MethodHandle       #6:#28         // invokestatic I.m:()V
>>>   #30 = Utf8               java/lang/invoke/MethodHandle
>>> ....
>>> {
>>>   public static void staticCallIm();
>>>     descriptor: ()V
>>>     flags: ACC_PUBLIC, ACC_STATIC
>>>     Code:
>>>       stack=3, locals=1, args_size=0
>>>          0: getstatic     #15                 // Field
>>> java/lang/System.out:Ljava/io/PrintStream;
>>>          3: ldc           #17                 // String Calling static
>>> I.m():
>>>          5: invokevirtual #23                 // Method
>>> java/io/PrintStream.println:(Ljava/lang/String;)V
>>>          8: ldc           #29                 // MethodHandle
>>> invokestatic I.m:()V
>>>         10: invokevirtual #34                 // Method
>>> java/lang/invoke/MethodHandle.invoke:()V
>>>         13: return
>>> }
>>>
>>>    So now keep the original fix of 8087223 as 8145148 fix and relax
>>> for the check in method handle method tag no longer needed with
>>> 8147755 solved.
>>>
>>>    Still, I need to test defmeth again to see the failed cases --- and
>>> the fix will be in defmeth use the new added Handle.
>>>
>>>     Stas and Dmitry:
>>>     8143320 fix may change if tests on new binary with 8145148/8147755
>>> shows defmeth needs changes too(I think so, since I add a new Handle
>>> constructor).
>>>
>>>      The previous webrev now has conflict with the current repo so
>>> need make new webrev and send codereview again.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 1/14/2016 2:51 AM, Vladimir Ivanov wrote:
>>>> Yumin,
>>>>
>>>> Please, file a follow-up bug for the missing check (interface static
>>>> method referenced by a MethodHandle). We shouldn't leave it 
>>>> half-fixed.
>>>>
>>>> I'd prefer to keep the original VM fix and quarantine affected tests
>>>> until ASM is fixed, but 2-phase fix is also fine with me.
>>>>
>>>> Not sure how to handle ASM problem. Is the problem present in the
>>>> latest ASM version?
>>>>
>>>> The best way would be to get it fixed upstream first and then sync
>>>> internal copy with upstream. defmeth tests use the library bundled
>>>> with the JDK.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 12/21/15 9:52 PM, Yumin Qi wrote:
>>>>> Please review:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145148
>>>>> webrev:http://cr.openjdk.java.net/~minqi/8145148/webrev-01/
>>>>>
>>>>> This is REDO for bug 8087223, which was backed out due to failed on
>>>>> 8143317 and 8143320.
>>>>> The defmeth encoutered new failures after the fix, which now has
>>>>> correct
>>>>> constant tags. The test bugs will be addressed in 8143320, which 
>>>>> based
>>>>> on vm/runtime/defmeth and 8143317, which in jdk/test.
>>>>>
>>>>> One difference from the attached for this webrev is that in
>>>>> MethodHandle
>>>>> resolution, I relax the check for one specific case: Using 
>>>>> MethodHandle
>>>>> to invoke static default interface method. In this case, we must use
>>>>> invokestatic (JVM_REF_invokeStatic), which in defmeth it will 
>>>>> generate
>>>>> method tag for interface which violates JVMS-5.4.3.3 (it should 
>>>>> create
>>>>> interface method tag!).  ASM currently has no API to generate
>>>>> invokeinterface for a interface static default method through
>>>>> MethodHandle invocation.
>>>>>
>>>>> Tests: JPRT, runtime quick test list (the fixed version for 8143320).
>>>>> Note the fix still fails 8143320 and 8143317 which are not fixed 
>>>>> at the
>>>>> momment.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>> Original post:
>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>> Please review:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8087223
>>>>> webrev: http://cr.openjdk.java.net/~minqi/8087223/webrev-02/
>>>>>
>>>>> According to JVMS-8:
>>>>>
>>>>> JVMS-5.4.3.3 Method Resolution:
>>>>>   " If C is an interface, method resolution throws an
>>>>> IncompatibleClassChangeError."
>>>>> JVMS-5.4.3.4 Interface Method Resolution:
>>>>>   "If C is not an interface, interface method resolution throws an
>>>>> IncompatibleClassChangeError"
>>>>>
>>>>> When invoke a method with resolved to an interface method, or 
>>>>> invoke a
>>>>> interface method with resolved to an instance method, ICCE should be
>>>>> thrown. The case usually happens when using tools like asmtools or
>>>>> jdk.internal.org.objectweb.asm to generate java bytecode.
>>>>>
>>>>> The fix is carrying the constantTag for the method at call and 
>>>>> check if
>>>>> tag is consistent with the method called. Doing this by adding a 
>>>>> member
>>>>> of constantTag, _tag,  to LinkInfo, and check tag in resolve 
>>>>> functions
>>>>> to see if tag matched with the correct method.
>>>>>
>>>>> The fix solved the problem when call is from interpreter and 
>>>>> compiler,
>>>>> bug for MethodHandle invoke, which should be addressed in another 
>>>>> bug,
>>>>> since the MethodHandle does not come with a byte stream and 
>>>>> getting the
>>>>> constant pool index at the invoke is not possible.  It will be
>>>>> addressed
>>>>> in another bug.
>>>>>
>>>>> Tests: test case (added, minor modified from bug), JPRT, rutime quick
>>>>> test list(in progress).
>>>>> manually tested:  1) -Xint
>>>>>                                 2) -Xcomp
>>>>>                                 3) -Xcomp -XX:-TieredCompiltion
>>>>>                                 4) -Xcomp -XX:+TieredCompilation
>>>>>
>>>>> Thanks to Coleen for helping fixed constant pool index and cleaned
>>>>> LinkInfo.
>>>>> ---------------------------------------------------------------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Second revision attached.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>
>>


From max.ockner at oracle.com  Fri Jan 29 16:05:09 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 29 Jan 2016 11:05:09 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AA9F14.5000507@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<56AA76C5.9070207@oracle.com> <56AA9F14.5000507@oracle.com>
Message-ID: <56AB8DB5.3020305@oracle.com>

I have fixed this. I am still responding to other suggestions.
Thanks,
Max
On 1/28/2016 6:07 PM, Ioi Lam wrote:
> Hi Max,
>
> It looks really good now. Just a minor nit for classFileParser.cpp and 
> systemDictionary.cpp, add the comment suggested by David:
>
> 1305     if (log_is_enabled(Info, classload)) {
> 1306       ik()->print_loading_log(LogLevel::Info, loader_data, NULL);
> 1307     }
>          // No 'else' here as logging levels are not mutually exclusive
> 1308     if (log_is_enabled(Debug, classload)) {
> 1309       ik()->print_loading_log(LogLevel::Debug, loader_data, NULL);
> 1310     }
>
> If there are no other changes, you don't need to post new webrev.
>
> Thanks
> - Ioi
>
>
>
> On 1/28/16 12:15 PM, Coleen Phillimore wrote:
>>
>> Yes, this test looks really good.  Thanks Ioi for figuring out the 
>> vagaries of jtreg.
>>
>> Coleen
>>
>> On 1/28/16 2:29 PM, Max Ockner wrote:
>>> Forwarded private discussion with Ioi about changing the test to use 
>>> ClassUnloadCommon.
>>>
>>> Hopefully nearing the end:
>>>
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>
>>> -------- Original Message --------
>>> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading, 
>>> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>> Date:     Thu, 28 Jan 2016 10:57:15 -0800
>>> From:     Ioi Lam <ioi.lam at oracle.com>
>>> To:     Max Ockner <max.ockner at oracle.com>
>>>
>>>
>>>
>>> Hi Max,
>>>
>>> Thanks for doing this. Also, I sent the e-mail to you personally, so 
>>> you may want to post the new version in the open list for record 
>>> purpose.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>> Ioi,
>>>> I have replaced my test with this test that you have given me 
>>>> (thank you!)
>>>> I also have removed the commented out section which used to test 
>>>> for "making nmethod ...", and I have added the comment that you 
>>>> suggested at the top of ClassUnloadCommon.java
>>>> Thanks,
>>>> Max
>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>
>>>>>
>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>> Though Ioi suggested I change my new test, I have not done that. 
>>>>>> I was recommended to copy from 
>>>>>> runtime/ClassUnload/UnloadTest.java instead of rolling my own 
>>>>>> test for class unloading. I mentioned that it was tricky to make 
>>>>>> the new test work, but it was tricky because I was trying to copy 
>>>>>> from UnloadTest.java. This test refers to a class "test.Empty" 
>>>>>> from a "classes" library, but the new test has a processBuilder 
>>>>>> which I think does not play nicely with the class path for 
>>>>>> "test.Empty". In the end it was much easier to hardcode the 
>>>>>> entire test into one place than to follow UnloadTest.java and 
>>>>>> refer to extra libraries.
>>>>>>
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> I've written a version of ClassLoadUnloadTest.java using 
>>>>> ClassUnloadCommon. The main trick is here:
>>>>>
>>>>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>>>>> System.getProperty("test.classes","."));
>>>>>
>>>>> That's because of this line in ClassUnloadCommon:
>>>>>
>>>>>             return new URLClassLoader(new URL[] {
>>>>> Paths.get(System.getProperty("test.classes",".") + 
>>>>> File.separatorChar + "classes").toUri().toURL(),
>>>>>             }, null);
>>>>>
>>>>> When Jtreg launches a sub-process, it strips off all the Java 
>>>>> system properties, so you need to add the "-D" in the command-line.
>>>>>
>>>>> I also disabled the test related to "making nmethod ... 
>>>>> unloadable". As Rachel found out in JDK-8146137, the compiler is 
>>>>> unpredictable. Even if you invoke a method 10001 times, there's no 
>>>>> guaranteed that it will always be compiled. Since this is not an 
>>>>> 'easy-to-test' feature, we should just skip it.
>>>>>
>>>>> I would also suggest adding this to the header of 
>>>>> ClassUnloadCommon.java
>>>>>
>>>>> /*
>>>>>  * To use ClassUnloadCommon from a sub-process, see 
>>>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>>  * for an example.
>>>>>  */
>>>>>
>>>>> What do you think?
>>>>> - Ioi
>>>>
>>>
>>>
>>>
>>
>


From rachel.protacio at oracle.com  Fri Jan 29 16:12:48 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Fri, 29 Jan 2016 11:12:48 -0500
Subject: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return
	JNI_VERSION_9
In-Reply-To: <56AA5FD6.4020400@oracle.com>
References: <56A94C8C.9050306@oracle.com> <56AA5FD6.4020400@oracle.com>
Message-ID: <56AB8F80.3020402@oracle.com>

Thanks for the review, Dan. We'll see how the 9 v. 9_0 discussion plays out.

Rachel

On 1/28/2016 1:37 PM, Daniel D. Daugherty wrote:
> On 1/27/16 4:02 PM, Rachel Protacio wrote:
>> Hello!
>>
>> Small but important change for review: updating the JNI_VERSION and 
>> in so doing, changing the format from JNI_VERSION_1_x to 
>> JNI_VERSION_x_y (see code/bug for details).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145098
>>
>> hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_hotspot/
>
> src/share/vm/prims/jni.cpp
>     No comments.
>
> src/share/vm/prims/jni.h
>     No comments.
>
> src/share/vm/runtime/thread.cpp
>     No comments.
>
> test/native_sanity/JniVersion.java
>     No comments.
>
>
>> jdk repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_jdk/
>
> src/java.base/share/native/include/jni.h
>     No comments.
>
>     Meta-comment not specific to this bug. It sure would be nice if
>     finally had "one source of truth" for "jni.h" (and friends).
>     Perhaps in the top-level repo... :-)
>
>
> Thumbs up!
>
> On Alan's comments about JNI_VERSION_9_0 versus JNI_VERSION_9, my
> personal preference is for trailing zero version. There was recently
> a comment on hotspot-dev at o.j.n and verona-dev at o.j.n about the missing
> trailing zeros. Subject line is: Version special case '9'
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021525.html 
>
>
> Dan
>
>
>>
>> I grep'ed through the code to find references to the current JNI 
>> version and believe I have caught all the ones that needed changing, 
>> plus the fact that all these tests pass:
>>
>>  * local hotspot jtreg tests
>>  * my own sample JNI test to print and visually inspect the version
>>    (essentially what is performed by the updated
>>    hotspot/test/native_sanity/JniVersion.java test)
>>  * jck vm tests
>>  * local rbt colcated and noncolocated tests, especially for the
>>    purpose of hitting tonga/src/nsk/share/jvmti tests where
>>    JNI_GetVersion() is used
>>
>> Thank you,
>> Rachel
>


From max.ockner at oracle.com  Fri Jan 29 16:32:07 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 29 Jan 2016 11:32:07 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AAB9CC.5040307@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AAB9CC.5040307@oracle.com>
Message-ID: <56AB9407.2060608@oracle.com>

David,
Thanks for explaining why it is necessary to check log_is_enabled(). 
However I think it clouds up the code to define a logstream and print to 
it when we could use log_trace, and provides minimal benefit in the process.
Thanks,
Max

On 1/28/2016 8:01 PM, David Holmes wrote:
> On 29/01/2016 10:50 AM, Jiangli Zhou wrote:
>> Hi Max,
>>
>> The changes look very good. I have just few minor comments and 
>> questions below.
>>
>> - klass.cpp
>> I?m new to the logging code, so I might be wrong. It seems the ?if 
>> (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are 
>> not needed since log_trace() also checks if the trace flag is enabled.
>
> Good catch - we need the "if (log_is_enabled())" check to ensure the 
> ResourceMark is only defined when logging is enabled, but then the 
> actual log statement should be the direct form, not the log_xxx() 
> macro form. E.g as used here for exceptions logging:
>
>       if (log_is_enabled(Info, exceptions)) {
>         ResourceMark rm;
>         outputStream* logstream = LogHandle(exceptions)::info_stream();
>         logstream->print("Async. exception installed at runtime exit 
> (" INTPTR_FORMAT ")", p2i(this));
>
>
> David
>
>> - filemap.cpp
>> ?TraceClassLoading && Verbose? is removed at line 211. Should a 
>> ?log_info(classload)? call be added? Or maybe the skipping of 
>> classloading trace for shared path is intentional?
>>
>> The same question for other changes in filemap.cpp.
>>
>> - instanceKlass.cpp
>> Please break line 2908 into two lines so it?s not too long. There are 
>> a few other long lines in print_loading_log() should be broken into two.
>>
>> - arguments.cpp
>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading 
>> in aliased_logging_flags[]. Should there be one for LogLevel::Debug 
>> for the classloading tracing? Maybe there is no old styled option for 
>> debug level class loading trace, so it's not defined in 
>> aliased_logging_flags(?).
>>
>> Thanks,
>> Jiangli
>>
>>
>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>>
>>> Forwarded private discussion with Ioi about changing the test to use 
>>> ClassUnloadCommon.
>>>
>>> Hopefully nearing the end:
>>>
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>
>>> -------- Original Message --------
>>> Subject:     Re: RFR: 8079408: Reimplement TraceClassLoading, 
>>> TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>> Date:     Thu, 28 Jan 2016 10:57:15 -0800
>>> From:     Ioi Lam <ioi.lam at oracle.com>
>>> To:     Max Ockner <max.ockner at oracle.com>
>>>
>>>
>>>
>>> Hi Max,
>>>
>>> Thanks for doing this. Also, I sent the e-mail to you personally, so 
>>> you may want to post the new version in the open list for record 
>>> purpose.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>> Ioi,
>>>> I have replaced my test with this test that you have given me 
>>>> (thank you!)
>>>> I also have removed the commented out section which used to test 
>>>> for "making nmethod ...", and I have added the comment that you 
>>>> suggested at the top of ClassUnloadCommon.java
>>>> Thanks,
>>>> Max
>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>
>>>>>
>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>> Though Ioi suggested I change my new test, I have not done that. 
>>>>>> I was recommended to copy from 
>>>>>> runtime/ClassUnload/UnloadTest.java instead of rolling my own 
>>>>>> test for class unloading. I mentioned that it was tricky to make 
>>>>>> the new test work, but it was tricky because I was trying to copy 
>>>>>> from UnloadTest.java. This test refers to a class "test.Empty" 
>>>>>> from a "classes" library, but the new test has a processBuilder 
>>>>>> which I think does not play nicely with the class path for  
>>>>>> "test.Empty". In the end it was much easier to hardcode the 
>>>>>> entire test into one place than to follow UnloadTest.java and 
>>>>>> refer to extra libraries.
>>>>>>
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> I've written a version of ClassLoadUnloadTest.java using 
>>>>> ClassUnloadCommon. The main trick is here:
>>>>>
>>>>>         Collections.addAll(argsList, "-Dtest.classes=" + 
>>>>> System.getProperty("test.classes","."));
>>>>>
>>>>> That's because of this line in ClassUnloadCommon:
>>>>>
>>>>>             return new URLClassLoader(new URL[] {
>>>>> Paths.get(System.getProperty("test.classes",".") + 
>>>>> File.separatorChar + "classes").toUri().toURL(),
>>>>>             }, null);
>>>>>
>>>>> When Jtreg launches a sub-process, it strips off all the Java 
>>>>> system properties, so you need to add the "-D" in the command-line.
>>>>>
>>>>> I also disabled the test related to "making nmethod ... 
>>>>> unloadable". As Rachel found out in JDK-8146137, the compiler is 
>>>>> unpredictable. Even if you invoke a method 10001 times, there's no 
>>>>> guaranteed that it will always be compiled. Since this is not an 
>>>>> 'easy-to-test' feature, we should just skip it.
>>>>>
>>>>> I would also suggest adding this to the header of 
>>>>> ClassUnloadCommon.java
>>>>>
>>>>> /*
>>>>> * To use ClassUnloadCommon from a sub-process, see 
>>>>> hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>> * for an example.
>>>>> */
>>>>>
>>>>> What do you think?
>>>>> - Ioi
>>>>
>>>
>>>
>>>
>>


From max.ockner at oracle.com  Fri Jan 29 16:59:40 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 29 Jan 2016 11:59:40 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
Message-ID: <56AB9A7C.90005@oracle.com>

Thanks for reviewing.
Comments below:

On 1/28/2016 7:50 PM, Jiangli Zhou wrote:
> Hi Max,
>
> The changes look very good. I have just few minor comments and questions below.
>
> - klass.cpp
> I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.

David gave a good answer for this question. We need to check 
log_is_enabled() before defining the resource mark. Once inside this 
scope, we could choose to define a log stream and then print to it, or 
we could use the macro log_trace, which also happens to check 
log_is_enabled again. I vote for keeping log_trace because it is cleaner 
than the alternative.

> - filemap.cpp
> ?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?
>
> The same question for other changes in filemap.cpp.

I spoke with Ioi about this. The logs in filemap.cpp are really part of 
TraceClassPaths and not part of TraceClassLoading.

> - instanceKlass.cpp
> Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.

I found two other lines that needed to be broken up. I split up any line 
I found that was longer than 80 chars.

>
> - arguments.cpp
> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).

Correct. "-Xlog:classload=info" should print the same thing as 
"-XX:+TraceClassLoading".  If you also set the Verbose flag with 
TraceClassLoading or TraceClassUnloading, you can see additional output. 
This output can be accessed with "-Xlog:classload=debug". However, the 
Verbose flag is only available in non-product builds. The logging alias 
table is meant to preserve the product functionality of 
TraceClassLoading and TraceClassUnloading, so there is nothing that gets 
aliased to the debug level for classload or classunload.
>
> Thanks,
> Jiangli
>
>
>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>
>> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
>>
>> Hopefully nearing the end:
>>
>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>
>> -------- Original Message --------
>> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
>> From: 	Ioi Lam <ioi.lam at oracle.com>
>> To: 	Max Ockner <max.ockner at oracle.com>
>>
>>
>>
>> Hi Max,
>>
>> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
>>
>> Thanks
>> - Ioi
>>
>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>> Ioi,
>>> I have replaced my test with this test that you have given me (thank you!)
>>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>>> Thanks,
>>> Max
>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>
>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>>>
>>>> Hi Max,
>>>>
>>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>>>
>>>>         Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>>>
>>>> That's because of this line in ClassUnloadCommon:
>>>>
>>>>             return new URLClassLoader(new URL[] {
>>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>>             }, null);
>>>>
>>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>>>
>>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>>>
>>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>>>
>>>> /*
>>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>> * for an example.
>>>> */
>>>>
>>>> What do you think?
>>>> - Ioi
>>
>>


From rachel.protacio at oracle.com  Fri Jan 29 18:13:14 2016
From: rachel.protacio at oracle.com (Rachel Protacio)
Date: Fri, 29 Jan 2016 13:13:14 -0500
Subject: latest repo not building?
Message-ID: <56ABABBA.7030703@oracle.com>

Hi,

I just updated a blank repo and tried to build it, but got this error:

    /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4821:48:
    error: 'CPU_COUNT_S' was not declared in this scope
            cpu_count = CPU_COUNT_S(cpus_size, cpus_p);
                                                     ^
    /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4824:35:
    error: 'CPU_COUNT' was not declared in this scope
            cpu_count = CPU_COUNT(cpus_p);
                                        ^
    /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4835:20:
    error: 'CPU_FREE' was not declared in this scope
          CPU_FREE(cpus_p);
                         ^

It looks from the history that David edited this file today, but maybe 
it's just my problem? Is anyone else running into this?

Thanks,
RAchel


From ioi.lam at oracle.com  Fri Jan 29 18:45:26 2016
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 29 Jan 2016 10:45:26 -0800
Subject: RFR(xs): 8147510: [windows] no text locations shown for register
	info in hs-err file
In-Reply-To: <CAA-vtUzgwsx80TjsAdNi28Be4eeXyRt-J9_AiOjkr1=U080nuw@mail.gmail.com>
References: <CAA-vtUzGknAy+e2cRdBJmWv185wSJ5rTbGyh=Y3CR2j24rgw1g@mail.gmail.com>	<CAA-vtUwnKXgyGENb70pkNerNS9EPsvYXSkzeMMOd+serfs9DEw@mail.gmail.com>	<56A9B83A.6040808@oracle.com>	<CAA-vtUx5EgxsJOKNzgtaC_bsZU3HstKf+92yuTJRi9ndWeN0ng@mail.gmail.com>	<56AAA528.70409@oracle.com>
	<CAA-vtUzgwsx80TjsAdNi28Be4eeXyRt-J9_AiOjkr1=U080nuw@mail.gmail.com>
Message-ID: <56ABB346.8020906@oracle.com>

Thanks Thomas, looks good!

- Ioi

On 1/29/16 12:53 AM, Thomas St?fe wrote:
> Hi Ioi,
>
> Your suggestion makes sense, I changed the fix accordingly.
>
> New webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.02/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8147510-windows-register-info-print-location/webrev.02/webrev/>
>
> Kind Regards, Thomas
>
>
> On Fri, Jan 29, 2016 at 12:32 AM, Ioi Lam <ioi.lam at oracle.com 
> <mailto:ioi.lam at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     Thanks for taking my suggestion :-)
>
>     To make the intention of the truncation check clearer, how about
>     reorganizing the code to:
>
>       if (os::dll_address_to_library_name(addr, buf, sizeof(buf),
>     &offset)) {
>         st->print(PTR_FORMAT " ", addr);
>         if (strlen(buf) < sizeof(buf)-1) {
>           char* p = strrchr(buf, '\\');
>           if (p) {
>             st->print("%s", p + 1);
>           } else {
>             st->print("%s", buf);
>           }else {
>             // The library name is probably truncated. Let's omit the
>     library name.
>             // See also JDK-8147512.
>           }
>     }
>
>     I'd say 'probably' because the name could be exactly 255
>     characters long ...
>
>     Thanks
>     - Ioi
>
>
>
>     On 1/28/16 5:01 AM, Thomas St?fe wrote:
>>     Hi Ioi,
>>
>>     thanks a lot for the review!
>>
>>     You are right, displaying the function name is more useful. I
>>     wanted to postpone this until I could start
>>     https://bugs.openjdk.java.net/browse/JDK-8147512, but now I took
>>     your suggestion and implemented this anyway.
>>
>>     See here new webrev:
>>
>>     http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev
>>     <http://cr.openjdk.java.net/%7Estuefe/webrevs/8147510-windows-register-info-print-location/webrev.01/webrev>
>>
>>     Notes:
>>     -I decided to cut off the path for libraries to make the printout
>>     easier to the eye; also, in the DLL-section we print out all DLLs
>>     including paths.
>>     -There is no clean way to handle truncation of long library
>>     paths, so I decided to at least detect truncation and if it
>>     happens to not print the library at all. I want to avoid large
>>     on-stack buffers, therefore I keep the result buffer relativly
>>     small (256 bytes). A better approach would be to - if os::find is
>>     used from error handling - hand down the error handling scratch
>>     buffer like we do in many other cases. But this is beyond the
>>     scope for this small fix.
>>
>>     New printout looks like this:
>>
>>      35 Register to memory mapping:
>>      36
>>      37 RIP=0x000000006ddd6a43 jvm.dll::crash_with_segfault + 0x13
>>      38 RAX=0xabc0000000000abc is an unknown value
>>
>>     Kind Regards, Thomas
>>
>>
>>
>>     On Thu, Jan 28, 2016 at 7:42 AM, Ioi Lam <ioi.lam at oracle.com
>>     <mailto:ioi.lam at oracle.com>> wrote:
>>
>>         Hi Thomas,
>>
>>         5269 bool os::find(address addr, outputStream* st) {
>>         5270   int offset = -1;
>>         5271   char buf[255];
>>         5272   if (os::dll_address_to_library_name(addr, buf,
>>         sizeof(buf), &offset)) {
>>         5273     st->print_cr("%s + %x", buf, offset);
>>         5274     return true;
>>         5275   }
>>         5276   return false;
>>         5277 }
>>
>>
>>         Have you tried calling os::dll_address_to_function_name as
>>         well so you can get the function name?
>>
>>         I noticed that the Linux version of os::find contains code
>>         for printing out the function name, but couldn't find an
>>         hs_err file where that code is actually used:
>>
>>         bool os::find(address addr, outputStream* st) {
>>             ...
>>             if (dlinfo.dli_fname != NULL) {
>>               st->print(" in %s", dlinfo.dli_fname);
>>             }
>>
>>
>>         Thanks
>>         - Ioi
>>
>>
>>         On 1/19/16 11:53 PM, Thomas St?fe wrote:
>>
>>             May I please have a review and a sponsor?
>>
>>             Thank you!
>>
>>             On Sat, Jan 16, 2016 at 10:42 AM, Thomas St?fe
>>             <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>>
>>             wrote:
>>
>>                 Hi,
>>
>>                 could I please have reviews and a sponsor for this
>>                 small fix:
>>
>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8147510
>>                 Webrev:
>>                 http://cr.openjdk.java.net/~stuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/
>>                 <http://cr.openjdk.java.net/%7Estuefe/webrevs/8147510-windows-register-info-print-location/webrev.00/>
>>
>>                 When we print register to memory info in hs-err file,
>>                 text addresses are
>>                 not resolved on windows like on other platforms:
>>
>>                 "RCX=0x000000005efa0000 is an unknown value"
>>
>>                 This fix changes this (the same way it is implemented
>>                 on other platforms):
>>
>>                 "RCX=C:\d031900\openjdk\jdk9-hs-rt\output\images\jdk\bin\server\jvm.dll
>>                 +
>>                 0"
>>
>>                 Please note that this printout and the code behind it
>>                 could be improved
>>                 and cleaned up a lot. For instance, I know that using
>>                 an on-stack buffer in
>>                 os::find() is not the best implementation here. But I
>>                 wanted a minimal
>>                 change. For the follow-up work, I opened a new bug:
>>                 https://bugs.openjdk.java.net/browse/JDK-8147512.
>>
>>                 Thanks & Regards, Thomas
>>
>>
>>
>>
>>
>>
>
>


From jiangli.zhou at oracle.com  Fri Jan 29 20:33:02 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 29 Jan 2016 12:33:02 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56AB9A7C.90005@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AB9A7C.90005@oracle.com>
Message-ID: <052D599E-5D62-49D8-BD0A-FB127E63DE30@oracle.com>

Hi Max,

> On Jan 29, 2016, at 8:59 AM, Max Ockner <max.ockner at oracle.com> wrote:
> 
> Thanks for reviewing.
> Comments below:
> 
> On 1/28/2016 7:50 PM, Jiangli Zhou wrote:
>> Hi Max,
>> 
>> The changes look very good. I have just few minor comments and questions below.
>> 
>> - klass.cpp
>> I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.
> 
> David gave a good answer for this question. We need to check log_is_enabled() before defining the resource mark. Once inside this scope, we could choose to define a log stream and then print to it, or we could use the macro log_trace, which also happens to check log_is_enabled again. I vote for keeping log_trace because it is cleaner than the alternative.

That's fine, although a more consistent usage of the log_trace & log_is_enabled is preferred. To prevent confusion for anyone trying to add logs in the future, maybe you can add a simple comment stating the log_is_enabled is not need for log_trace but for defining the resource mark when classunload tracing is enabled.

> 
>> - filemap.cpp
>> ?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?
>> 
>> The same question for other changes in filemap.cpp.
> 
> I spoke with Ioi about this. The logs in filemap.cpp are really part of TraceClassPaths and not part of TraceClassLoading.

Ok. Thanks for the confirmation.

> 
>> - instanceKlass.cpp
>> Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.
> 
> I found two other lines that needed to be broken up. I split up any line I found that was longer than 80 chars.

Thanks.

> 
>> 
>> - arguments.cpp
>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).
> 
> Correct. "-Xlog:classload=info" should print the same thing as "-XX:+TraceClassLoading".  If you also set the Verbose flag with TraceClassLoading or TraceClassUnloading, you can see additional output. This output can be accessed with "-Xlog:classload=debug". However, the Verbose flag is only available in non-product builds. The logging alias table is meant to preserve the product functionality of TraceClassLoading and TraceClassUnloading, so there is nothing that gets aliased to the debug level for classload or class unload.

Ok.

Thanks,
Jiangli

>> 
>> Thanks,
>> Jiangli
>> 
>> 
>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>> 
>>> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
>>> 
>>> Hopefully nearing the end:
>>> 
>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>> 
>>> -------- Original Message --------
>>> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
>>> From: 	Ioi Lam <ioi.lam at oracle.com>
>>> To: 	Max Ockner <max.ockner at oracle.com>
>>> 
>>> 
>>> 
>>> Hi Max,
>>> 
>>> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
>>> 
>>> Thanks
>>> - Ioi
>>> 
>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>> Ioi,
>>>> I have replaced my test with this test that you have given me (thank you!)
>>>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>>>> Thanks,
>>>> Max
>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>> 
>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>>>> 
>>>>> Hi Max,
>>>>> 
>>>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>>>> 
>>>>>        Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>>>> 
>>>>> That's because of this line in ClassUnloadCommon:
>>>>> 
>>>>>            return new URLClassLoader(new URL[] {
>>>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>>>            }, null);
>>>>> 
>>>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>>>> 
>>>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>>>> 
>>>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>>>> 
>>>>> /*
>>>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>> * for an example.
>>>>> */
>>>>> 
>>>>> What do you think?
>>>>> - Ioi
>>> 
>>> 
> 


From max.ockner at oracle.com  Fri Jan 29 22:25:32 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 29 Jan 2016 17:25:32 -0500
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, 
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <052D599E-5D62-49D8-BD0A-FB127E63DE30@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AB9A7C.90005@oracle.com>
	<052D599E-5D62-49D8-BD0A-FB127E63DE30@oracle.com>
Message-ID: <56ABE6DC.8050202@oracle.com>

I added a commend in klass.cpp. If there aren't further comments at this 
point, I will submit.
Thanks,
Max
On 1/29/2016 3:33 PM, Jiangli Zhou wrote:
> Hi Max,
>
>> On Jan 29, 2016, at 8:59 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>
>> Thanks for reviewing.
>> Comments below:
>>
>> On 1/28/2016 7:50 PM, Jiangli Zhou wrote:
>>> Hi Max,
>>>
>>> The changes look very good. I have just few minor comments and questions below.
>>>
>>> - klass.cpp
>>> I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.
>> David gave a good answer for this question. We need to check log_is_enabled() before defining the resource mark. Once inside this scope, we could choose to define a log stream and then print to it, or we could use the macro log_trace, which also happens to check log_is_enabled again. I vote for keeping log_trace because it is cleaner than the alternative.
> That's fine, although a more consistent usage of the log_trace & log_is_enabled is preferred. To prevent confusion for anyone trying to add logs in the future, maybe you can add a simple comment stating the log_is_enabled is not need for log_trace but for defining the resource mark when classunload tracing is enabled.
>
>>> - filemap.cpp
>>> ?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?
>>>
>>> The same question for other changes in filemap.cpp.
>> I spoke with Ioi about this. The logs in filemap.cpp are really part of TraceClassPaths and not part of TraceClassLoading.
> Ok. Thanks for the confirmation.
>
>>> - instanceKlass.cpp
>>> Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.
>> I found two other lines that needed to be broken up. I split up any line I found that was longer than 80 chars.
> Thanks.
>
>>> - arguments.cpp
>>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).
>> Correct. "-Xlog:classload=info" should print the same thing as "-XX:+TraceClassLoading".  If you also set the Verbose flag with TraceClassLoading or TraceClassUnloading, you can see additional output. This output can be accessed with "-Xlog:classload=debug". However, the Verbose flag is only available in non-product builds. The logging alias table is meant to preserve the product functionality of TraceClassLoading and TraceClassUnloading, so there is nothing that gets aliased to the debug level for classload or class unload.
> Ok.
>
> Thanks,
> Jiangli
>
>>> Thanks,
>>> Jiangli
>>>
>>>
>>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>>>
>>>> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
>>>>
>>>> Hopefully nearing the end:
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>>
>>>> -------- Original Message --------
>>>> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>>> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
>>>> From: 	Ioi Lam <ioi.lam at oracle.com>
>>>> To: 	Max Ockner <max.ockner at oracle.com>
>>>>
>>>>
>>>>
>>>> Hi Max,
>>>>
>>>> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>>> Ioi,
>>>>> I have replaced my test with this test that you have given me (thank you!)
>>>>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>>>>> Thanks,
>>>>> Max
>>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>>>>>
>>>>>>         Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>>>>>
>>>>>> That's because of this line in ClassUnloadCommon:
>>>>>>
>>>>>>             return new URLClassLoader(new URL[] {
>>>>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>>>>             }, null);
>>>>>>
>>>>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>>>>>
>>>>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>>>>>
>>>>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>>>>>
>>>>>> /*
>>>>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>>> * for an example.
>>>>>> */
>>>>>>
>>>>>> What do you think?
>>>>>> - Ioi
>>>>


From david.holmes at oracle.com  Fri Jan 29 22:43:59 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 30 Jan 2016 08:43:59 +1000
Subject: latest repo not building?
In-Reply-To: <56ABABBA.7030703@oracle.com>
References: <56ABABBA.7030703@oracle.com>
Message-ID: <56ABEB2F.6030606@oracle.com>

Sorry Rachel, the latest changes I pushed for sched_getaffinity do rely 
on using at least our official gcc version for building - which is 
4.9.2. I was under the (perhaps mistaken) impression that there was 
already something that prevented us using the older 4.8.x version.

David

On 30/01/2016 4:13 AM, Rachel Protacio wrote:
> Hi,
>
> I just updated a blank repo and tried to build it, but got this error:
>
>     /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4821:48:
>     error: 'CPU_COUNT_S' was not declared in this scope
>             cpu_count = CPU_COUNT_S(cpus_size, cpus_p);
>                                                      ^
>     /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4824:35:
>     error: 'CPU_COUNT' was not declared in this scope
>             cpu_count = CPU_COUNT(cpus_p);
>                                         ^
>     /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4835:20:
>     error: 'CPU_FREE' was not declared in this scope
>           CPU_FREE(cpus_p);
>                          ^
>
> It looks from the history that David edited this file today, but maybe
> it's just my problem? Is anyone else running into this?
>
> Thanks,
> RAchel
>

From david.holmes at oracle.com  Fri Jan 29 23:06:45 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 30 Jan 2016 09:06:45 +1000
Subject: latest repo not building?
In-Reply-To: <56ABEB2F.6030606@oracle.com>
References: <56ABABBA.7030703@oracle.com> <56ABEB2F.6030606@oracle.com>
Message-ID: <56ABF085.6060905@oracle.com>

On 30/01/2016 8:43 AM, David Holmes wrote:
> Sorry Rachel, the latest changes I pushed for sched_getaffinity do rely
> on using at least our official gcc version for building - which is
> 4.9.2. I was under the (perhaps mistaken) impression that there was
> already something that prevented us using the older 4.8.x version.

Sorry this is incorrect information. Internally we use devkits which 
combine a specific gcc version with a specific OS version. Our current 
devkit is using gcc 4.9.2, but the sched_getaffinity code depends on the 
OS header files to support dynamic cpu sets (man CPU_SET). I can't say 
exactly which OS versions support this but Linux distributions post 2010 
should be fine.

So older gcc may be fine, but you need the later OS.

David

> David
>
> On 30/01/2016 4:13 AM, Rachel Protacio wrote:
>> Hi,
>>
>> I just updated a blank repo and tried to build it, but got this error:
>>
>>
>> /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4821:48:
>>
>>     error: 'CPU_COUNT_S' was not declared in this scope
>>             cpu_count = CPU_COUNT_S(cpus_size, cpus_p);
>>                                                      ^
>>
>> /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4824:35:
>>
>>     error: 'CPU_COUNT' was not declared in this scope
>>             cpu_count = CPU_COUNT(cpus_p);
>>                                         ^
>>
>> /scratch/rprotaci/repos/startuptime/hotspot/src/os/linux/vm/os_linux.cpp:4835:20:
>>
>>     error: 'CPU_FREE' was not declared in this scope
>>           CPU_FREE(cpus_p);
>>                          ^
>>
>> It looks from the history that David edited this file today, but maybe
>> it's just my problem? Is anyone else running into this?
>>
>> Thanks,
>> RAchel
>>

From jiangli.zhou at oracle.com  Fri Jan 29 23:32:35 2016
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 29 Jan 2016 15:32:35 -0800
Subject: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading,
	and TraceClassLoaderData with Unified Logging.
In-Reply-To: <56ABE6DC.8050202@oracle.com>
References: <56AA648B.5060706@oracle.com> <56AA6BFE.7090505@oracle.com>
	<B4C95B86-D05C-4CD8-8C98-968D1F0599F4@oracle.com>
	<56AB9A7C.90005@oracle.com>
	<052D599E-5D62-49D8-BD0A-FB127E63DE30@oracle.com>
	<56ABE6DC.8050202@oracle.com>
Message-ID: <728A9208-E76A-4276-8844-BA02F56402D8@oracle.com>

Thank you. No further comments from me.

Thanks,
Jiangli

> On Jan 29, 2016, at 2:25 PM, Max Ockner <max.ockner at oracle.com> wrote:
> 
> I added a commend in klass.cpp. If there aren't further comments at this point, I will submit.
> Thanks,
> Max
> On 1/29/2016 3:33 PM, Jiangli Zhou wrote:
>> Hi Max,
>> 
>>> On Jan 29, 2016, at 8:59 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>> 
>>> Thanks for reviewing.
>>> Comments below:
>>> 
>>> On 1/28/2016 7:50 PM, Jiangli Zhou wrote:
>>>> Hi Max,
>>>> 
>>>> The changes look very good. I have just few minor comments and questions below.
>>>> 
>>>> - klass.cpp
>>>> I?m new to the logging code, so I might be wrong. It seems the ?if (log_is_enabled(Trace, classunload))? checks at line 390 & 405 are not needed since log_trace() also checks if the trace flag is enabled.
>>> David gave a good answer for this question. We need to check log_is_enabled() before defining the resource mark. Once inside this scope, we could choose to define a log stream and then print to it, or we could use the macro log_trace, which also happens to check log_is_enabled again. I vote for keeping log_trace because it is cleaner than the alternative.
>> That's fine, although a more consistent usage of the log_trace & log_is_enabled is preferred. To prevent confusion for anyone trying to add logs in the future, maybe you can add a simple comment stating the log_is_enabled is not need for log_trace but for defining the resource mark when classunload tracing is enabled.
>> 
>>>> - filemap.cpp
>>>> ?TraceClassLoading && Verbose? is removed at line 211. Should a ?log_info(classload)? call be added? Or maybe the skipping of classloading trace for shared path is intentional?
>>>> 
>>>> The same question for other changes in filemap.cpp.
>>> I spoke with Ioi about this. The logs in filemap.cpp are really part of TraceClassPaths and not part of TraceClassLoading.
>> Ok. Thanks for the confirmation.
>> 
>>>> - instanceKlass.cpp
>>>> Please break line 2908 into two lines so it?s not too long. There are a few other long lines in print_loading_log() should be broken into two.
>>> I found two other lines that needed to be broken up. I split up any line I found that was longer than 80 chars.
>> Thanks.
>> 
>>>> - arguments.cpp
>>>> LogLevel:Info is added for TraceClassLoading and TraceClassUnloading in aliased_logging_flags[]. Should there be one for LogLevel::Debug for the classloading tracing? Maybe there is no old styled option for debug level class loading trace, so it's not defined in aliased_logging_flags(?).
>>> Correct. "-Xlog:classload=info" should print the same thing as "-XX:+TraceClassLoading".  If you also set the Verbose flag with TraceClassLoading or TraceClassUnloading, you can see additional output. This output can be accessed with "-Xlog:classload=debug". However, the Verbose flag is only available in non-product builds. The logging alias table is meant to preserve the product functionality of TraceClassLoading and TraceClassUnloading, so there is nothing that gets aliased to the debug level for classload or class unload.
>> Ok.
>> 
>> Thanks,
>> Jiangli
>> 
>>>> Thanks,
>>>> Jiangli
>>>> 
>>>> 
>>>>> On Jan 28, 2016, at 11:29 AM, Max Ockner <max.ockner at oracle.com> wrote:
>>>>> 
>>>>> Forwarded private discussion with Ioi about changing the test to use ClassUnloadCommon.
>>>>> 
>>>>> Hopefully nearing the end:
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~mockner/classload.08/
>>>>> 
>>>>> -------- Original Message --------
>>>>> Subject: 	Re: RFR: 8079408: Reimplement TraceClassLoading, TraceClassUnloading, and TraceClassLoaderData with Unified Logging.
>>>>> Date: 	Thu, 28 Jan 2016 10:57:15 -0800
>>>>> From: 	Ioi Lam <ioi.lam at oracle.com>
>>>>> To: 	Max Ockner <max.ockner at oracle.com>
>>>>> 
>>>>> 
>>>>> 
>>>>> Hi Max,
>>>>> 
>>>>> Thanks for doing this. Also, I sent the e-mail to you personally, so you may want to post the new version in the open list for record purpose.
>>>>> 
>>>>> Thanks
>>>>> - Ioi
>>>>> 
>>>>> On 1/28/16 8:11 AM, Max Ockner wrote:
>>>>>> Ioi,
>>>>>> I have replaced my test with this test that you have given me (thank you!)
>>>>>> I also have removed the commented out section which used to test for "making nmethod ...", and I have added the comment that you suggested at the top of ClassUnloadCommon.java
>>>>>> Thanks,
>>>>>> Max
>>>>>> On 1/27/2016 7:13 PM, Ioi Lam wrote:
>>>>>>> On 1/27/16 12:51 PM, Max Ockner wrote:
>>>>>>>> Though Ioi suggested I change my new test, I have not done that. I was recommended to copy from runtime/ClassUnload/UnloadTest.java instead of rolling my own test for class unloading. I mentioned that it was tricky to make the new test work, but it was tricky because I was trying to copy from UnloadTest.java. This test refers to a class "test.Empty" from a "classes" library, but the new test has a processBuilder which I think does not play nicely with the class path for  "test.Empty". In the end it was much easier to hardcode the entire test into one place than to follow UnloadTest.java and refer to extra libraries.
>>>>>>>> 
>>>>>>> Hi Max,
>>>>>>> 
>>>>>>> I've written a version of ClassLoadUnloadTest.java using ClassUnloadCommon. The main trick is here:
>>>>>>> 
>>>>>>>        Collections.addAll(argsList, "-Dtest.classes=" + System.getProperty("test.classes","."));
>>>>>>> 
>>>>>>> That's because of this line in ClassUnloadCommon:
>>>>>>> 
>>>>>>>            return new URLClassLoader(new URL[] {
>>>>>>> Paths.get(System.getProperty("test.classes",".") + File.separatorChar + "classes").toUri().toURL(),
>>>>>>>            }, null);
>>>>>>> 
>>>>>>> When Jtreg launches a sub-process, it strips off all the Java system properties, so you need to add the "-D" in the command-line.
>>>>>>> 
>>>>>>> I also disabled the test related to "making nmethod ... unloadable". As Rachel found out in JDK-8146137, the compiler is unpredictable. Even if you invoke a method 10001 times, there's no guaranteed that it will always be compiled. Since this is not an 'easy-to-test' feature, we should just skip it.
>>>>>>> 
>>>>>>> I would also suggest adding this to the header of ClassUnloadCommon.java
>>>>>>> 
>>>>>>> /*
>>>>>>> * To use ClassUnloadCommon from a sub-process, see hotspot/test/runtime/logging/ClassLoadUnloadTest.java
>>>>>>> * for an example.
>>>>>>> */
>>>>>>> 
>>>>>>> What do you think?
>>>>>>> - Ioi
>>>>> 
> 


From goetz.lindenmaier at sap.com  Sat Jan 30 11:58:15 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 30 Jan 2016 11:58:15 +0000
Subject: RFR(XS): 8148470: Metadata print routines should not print to tty
In-Reply-To: <56AA68D1.2000403@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
	<56AA68D1.2000403@oracle.com>
Message-ID: <fa986ee602ad438891509b1342bd2a8b@DEWDFE13DE09.global.corp.sap>

Hi Ioi, 

thanks for reviewing and sponsoring. This was fast!

Best regards,
  Goetz

> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of Ioi Lam
> Sent: Thursday, January 28, 2016 8:15 PM
> To: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8148470: Metadata print routines should not print to tty
> 
> Hi Goetz,
> 
> This looks good to me. I'll sponsor it.
> 
> Thanks
> - Ioi
> 
> On 1/28/16 6:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Please review this small and obvious fix.  I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr16/8148470-tty/webrev.01/
> >
> > I ran into this when calling format() in C2 compiler and setting Verbose.
> >
> > Thanks and best regards,
> >    Goetz.


From goetz.lindenmaier at sap.com  Sat Jan 30 12:00:50 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 30 Jan 2016 12:00:50 +0000
Subject: RFR(XS): 8148470: Metadata print routines should not print to tty
In-Reply-To: <56AA2D09.7000704@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC41F219CE@DEWDFEMB12A.global.corp.sap>
	<56AA2D09.7000704@oracle.com>
Message-ID: <b0b179b1d88949c69d505eef5e416ec0@DEWDFE13DE09.global.corp.sap>

Thanks Mikael!

Best regards,
  Goetz

> -----Original Message-----
> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com]
> Sent: Thursday, January 28, 2016 4:00 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(XS): 8148470: Metadata print routines should not print to tty
> 
> Hi Goetz,
> 
> On 2016-01-28 15:23, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Please review this small and obvious fix.  I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr16/8148470-tty/webrev.01/
> 
> Fix looks good.
> /Mikael
> 
> >
> > I ran into this when calling format() in C2 compiler and setting Verbose.
> >
> > Thanks and best regards,
> >    Goetz.
> >