From kanth909 at gmail.com Wed Jan 10 13:58:25 2018 From: kanth909 at gmail.com (kant kodali) Date: Wed, 10 Jan 2018 05:58:25 -0800 Subject: How does Project Loom Fibers/Green threads help in Anyway ? Message-ID: Hi All, I came across the links below and I wondering how Fibers can really help ? when compared to using a thread pool (which is a pool of kernel threads)? Sure having both options is great but I am trying to understand what difference can it make in terms of performance ? Here is what I know 1) Kernel threads are expensive and the default stack size is in MB's whereas Fibers can have a small stack size somewhere in KB's so one can create as many of them. so what? eventually they all have to map to Kernel threads and thread pool exists so user don't create as many as say Fibers. isn't it? 2) Fibers have no idea about kernal threads and vice-versa. so if a Fiber makes a blocking system call it has not idea that the kernel thread is blocked and there is no upcall mechanism by any major OS. 3) One can argue Fibers are great when a program is making lot of async calls but I wonder how this is any better in terms of performance when compared to having small thread pool that makes async calls? If this is all about expressing something gets easier in Fibers than using thread pool but there is no performance difference then I must say this is just subjective so everyone can have their own opinion. At this time, I am not seeing how Fibers can be better performant than having a pool of Kernel threads? if they are in some cases can someone please provide any examples so I can enlightened? http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html https://hn.svelte.technology/item/15599854 From david.holmes at oracle.com Sat Jan 13 10:05:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Jan 2018 20:05:42 +1000 Subject: How does Project Loom Fibers/Green threads help in Anyway ? In-Reply-To: References: Message-ID: <691b20ca-8b54-c7ba-4130-e62815bee3aa@oracle.com> Project Loom is still being set up and should have a project page and mailing list soon. David On 10/01/2018 11:58 PM, kant kodali wrote: > Hi All, > > I came across the links below and I wondering how Fibers can really help ? > when compared to using a thread pool (which is a pool of kernel threads)? > Sure having both options is great but I am trying to understand what > difference can it make in terms of performance ? > > Here is what I know > > 1) Kernel threads are expensive and the default stack size is in MB's > whereas Fibers can have a small stack size somewhere in KB's so one can > create as many of them. so what? eventually they all have to map to Kernel > threads and thread pool exists so user don't create as many as say Fibers. > isn't it? > > 2) Fibers have no idea about kernal threads and vice-versa. so if a Fiber > makes a blocking system call it has not idea that the kernel thread is > blocked and there is no upcall mechanism by any major OS. > > 3) One can argue Fibers are great when a program is making lot of async > calls but I wonder how this is any better in terms of performance when > compared to having small thread pool that makes async calls? > > If this is all about expressing something gets easier in Fibers than using > thread pool but there is no performance difference then I must say this is > just subjective so everyone can have their own opinion. > > At this time, I am not seeing how Fibers can be better performant than > having a pool of Kernel threads? if they are in some cases can someone > please provide any examples so I can enlightened? > > > > http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html > https://hn.svelte.technology/item/15599854 > From david.holmes at oracle.com Wed Jan 17 10:22:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jan 2018 20:22:03 +1000 Subject: How does Project Loom Fibers/Green threads help in Anyway ? In-Reply-To: <691b20ca-8b54-c7ba-4130-e62815bee3aa@oracle.com> References: <691b20ca-8b54-c7ba-4130-e62815bee3aa@oracle.com> Message-ID: http://mail.openjdk.java.net/mailman/listinfo/loom-dev David On 13/01/2018 8:05 PM, David Holmes wrote: > Project Loom is still being set up and should have a project page and > mailing list soon. > > David > > On 10/01/2018 11:58 PM, kant kodali wrote: >> Hi All, >> >> I came across the links below and I wondering how Fibers can really >> help ? >> when compared to using a thread pool (which is a pool of kernel threads)? >> Sure having both options is great but I am trying to understand what >> difference can it make in terms of performance ? >> >> Here is what I know >> >> 1) Kernel threads are expensive and the default stack size is in MB's >> whereas Fibers can have a small stack size somewhere in KB's so one can >> create as many of them. so what? eventually they all have to map to >> Kernel >> threads and thread pool exists so user don't create as many as say >> Fibers. >> isn't it? >> >> 2) Fibers have no idea about kernal threads and vice-versa. so if a Fiber >> makes a blocking system call it has not idea that the kernel thread is >> blocked and there is no upcall mechanism by any major OS. >> >> 3) One can argue Fibers are great when a program is making lot of async >> calls but I wonder how this is any better in terms of performance when >> compared to having small thread pool that makes async calls? >> >> If this is all about expressing something gets easier in Fibers than >> using >> thread pool but there is no performance difference then I must say >> this is >> just subjective so everyone can have their own opinion. >> >> At this time, I am not seeing how Fibers can be better performant than >> having a pool of Kernel threads? if they are in some cases can someone >> please provide any examples so I can enlightened? >> >> >> >> http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html >> https://hn.svelte.technology/item/15599854 >> From kanth909 at gmail.com Wed Jan 17 10:27:57 2018 From: kanth909 at gmail.com (kant kodali) Date: Wed, 17 Jan 2018 02:27:57 -0800 Subject: How does Project Loom Fibers/Green threads help in Anyway ? In-Reply-To: References: <691b20ca-8b54-c7ba-4130-e62815bee3aa@oracle.com> Message-ID: Thanks a lot! On Wed, Jan 17, 2018 at 2:22 AM, David Holmes wrote: > http://mail.openjdk.java.net/mailman/listinfo/loom-dev > > David > > > On 13/01/2018 8:05 PM, David Holmes wrote: > >> Project Loom is still being set up and should have a project page and >> mailing list soon. >> >> David >> >> On 10/01/2018 11:58 PM, kant kodali wrote: >> >>> Hi All, >>> >>> I came across the links below and I wondering how Fibers can really help >>> ? >>> when compared to using a thread pool (which is a pool of kernel threads)? >>> Sure having both options is great but I am trying to understand what >>> difference can it make in terms of performance ? >>> >>> Here is what I know >>> >>> 1) Kernel threads are expensive and the default stack size is in MB's >>> whereas Fibers can have a small stack size somewhere in KB's so one can >>> create as many of them. so what? eventually they all have to map to >>> Kernel >>> threads and thread pool exists so user don't create as many as say >>> Fibers. >>> isn't it? >>> >>> 2) Fibers have no idea about kernal threads and vice-versa. so if a Fiber >>> makes a blocking system call it has not idea that the kernel thread is >>> blocked and there is no upcall mechanism by any major OS. >>> >>> 3) One can argue Fibers are great when a program is making lot of async >>> calls but I wonder how this is any better in terms of performance when >>> compared to having small thread pool that makes async calls? >>> >>> If this is all about expressing something gets easier in Fibers than >>> using >>> thread pool but there is no performance difference then I must say this >>> is >>> just subjective so everyone can have their own opinion. >>> >>> At this time, I am not seeing how Fibers can be better performant than >>> having a pool of Kernel threads? if they are in some cases can someone >>> please provide any examples so I can enlightened? >>> >>> >>> >>> http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html >>> https://hn.svelte.technology/item/15599854 >>> >>> From aph at redhat.com Mon Jan 22 13:46:32 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 13:46:32 +0000 Subject: RFR: 8194739: JDK9u: Zero port of 8174962: Better interface invocations Message-ID: Fixes the breakage to Zero caused by 8174962: Better interface invocations. http://cr.openjdk.java.net/~aph/8194739/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tianxiao.gu at gmail.com Sun Jan 21 01:34:59 2018 From: tianxiao.gu at gmail.com (Tianxiao Gu) Date: Sat, 20 Jan 2018 17:34:59 -0800 Subject: jaotc fails to build the object file for the given class. Message-ID: Hi All, I have created a simple random Java class file generator and try to use it to find bugs of JVM or dex compiler. jaotc (jaotc 9.0.4+11) fails to build the object file for a generated class with non-deterministic error messages. I am not sure whether this is a bug or not since the generated class is executable (ending with StackOverflowError) and also can be compiled by the dex compiler for Android (dx). Can anybody help me to resolve this issue? OS (`uname -a`): Linux xtiger 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Reproduce: ./jdk-9.0.4/bin/jaotc --output C0.so C0.class C0.class is attached. One example of messages: t@~/Projects/JVMTesting/bugs/t *>>> *../../jdk-9.0.4/bin/jaotc --output > C0.so C0.class > Error: Failed compilation: > C0.M1([SLjava/lang/Double;[Ljava/lang/Short;[SLjava/lang/Integer;F[B[B[Ljava/lang/Float;Ljava/lang/Integer;[JLjava/lang/Double;IISS[JBLjava/lang/Object;[SLjava/lang/Character;Ljava/lang/Character;Ljava/lang/Short;[Ljava/lang/Character;[Z[Ljava/lang/Number;[Ljava/lang/Byte;FJ[I[CIIJLjava/lang/Float;[Ljava/lang/Byte;I[C[Ljava/lang/Integer;BB[Ljava/lang/Integer;[CLjava/lang/Double;[F[Ljava/lang/Double;Ljava/lang/Character;)B: > java.lang.StackOverflowError > Error: Failed compilation: > C0.M3(FLjava/lang/Object;SB[Ljava/lang/Float;[Ljava/lang/CharSequence;[IJ[BLC0;CLjava/lang/Object;Ljava/lang/CharSequence;[ZLjava/lang/Number;ZCF[JLjava/lang/Character;[ZZ[Ljava/io/Serializable;LC0;[Ljava/lang/Integer;[Ljava/lang/String;FZFJZC[Ljava/lang/CharSequence;JI[LC0;CS[Ljava/io/Serializable;[BLjava/lang/Long;Ljava/lang/Short;[S[F[Ljava/lang/Float;[ILjava/lang/Integer;Ljava/lang/Long;[Ljava/lang/String;[IJ[Ljava/lang/Long;LC0;[BB[Ljava/lang/String;[Ljava/lang/String;[B[Ljava/lang/Double;Ljava/lang/Float;BFZLjava/lang/Short;[B[B[CLjava/lang/Number;Z[ZJ[I[LC0;B[ZFLjava/lang/String;I[Ljava/lang/String;[IF[BLjava/lang/CharSequence;C)I: > java.lang.OutOfMemoryError: Java heap space > Error: Failed compilation: > C0.M8(Ljava/lang/Integer;[LC0;[Ljava/lang/Double;[ILjava/lang/Float;[Ljava/lang/Byte;[Ljava/lang/Character;BLjava/lang/Byte;Ljava/lang/Comparable;F[Ljava/lang/Object;[BLjava/lang/Character;C[I[Ljava/lang/String;ZLjava/lang/Long;JLjava/lang/Object;[Ljava/lang/CharSequence;FLjava/lang/Object;[Ljava/lang/Short;[I[Ljava/lang/Character;[BLjava/lang/Character;[Ljava/lang/Number;[Ljava/lang/Number;[ZLjava/lang/String;Ljava/lang/Short;)F: > java.lang.OutOfMemoryError: Java heap space > Error: Failed compilation: > C0.M5(Z[S[Z[BLjava/lang/Double;[Ljava/lang/Integer;Ljava/lang/Short;[Ljava/lang/Integer;[F[I[F[Ljava/lang/Number;FLjava/lang/Float;)C: > java.lang.OutOfMemoryError: Java heap space > Error: Failed compilation: C0.main([Ljava/lang/String;)V: java.lang.OutOfMemoryError: > Java heap space > Error: Failed compilation: > C0.M2([Ljava/lang/Number;CJLjava/lang/Character;Ljava/lang/Float;J[ISLjava/lang/Short;)F: > java.lang.OutOfMemoryError: Java heap space From sgehwolf at redhat.com Mon Jan 22 17:30:40 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 22 Jan 2018 18:30:40 +0100 Subject: RFR: 8194739: JDK9u: Zero port of 8174962: Better interface invocations In-Reply-To: References: Message-ID: <1516642240.4142.26.camel@redhat.com> On Mon, 2018-01-22 at 13:46 +0000, Andrew Haley wrote: > Fixes the breakage to Zero caused by 8174962: Better interface > invocations. > > http://cr.openjdk.java.net/~aph/8194739/ Zero version 9.0.4 (build 11) + patch builds fine for me in all variants (release/fastdebug/slowdebug). It was broken pre-patch, so +1 from me. Thanks, Severin From aph at redhat.com Mon Jan 22 17:53:17 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 17:53:17 +0000 Subject: jaotc fails to build the object file for the given class. In-Reply-To: References: Message-ID: <1a1bf8f0-39ba-67ef-9414-eb3db9fec25d@redhat.com> On 21/01/18 01:34, Tianxiao Gu wrote: > Can anybody help me to resolve this issue? It looks like all of these are StackOverflowErrors or OutOfMemoryErrors. Does it work if you allocate large stack and heap? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From benjamin.john.evans at gmail.com Mon Jan 22 18:00:20 2018 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 22 Jan 2018 19:00:20 +0100 Subject: jaotc fails to build the object file for the given class. In-Reply-To: References: Message-ID: Hi Tianxiao, The jdk9-dev list strips attachments - so you will need to host the class elsewhere. It's probably easiest to set up a Github or other simple OSS project and put your random class generator, and any examples of classes that fail AOTC there, and then just give the link in your mail. Thanks, Ben On Sun, Jan 21, 2018 at 2:34 AM, Tianxiao Gu wrote: > Hi All, > > I have created a simple random Java class file generator and try to use it > to find bugs of JVM or dex compiler. > > jaotc (jaotc 9.0.4+11) fails to build the object file for a generated class > with non-deterministic error messages. > > I am not sure whether this is a bug or not since the generated class is > executable (ending with StackOverflowError) and also can be compiled by the > dex compiler for Android (dx). > > Can anybody help me to resolve this issue? > > > > OS (`uname -a`): > > Linux xtiger 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 >> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > > Reproduce: > > ./jdk-9.0.4/bin/jaotc --output C0.so C0.class > > > C0.class is attached. > > One example of messages: > > t@~/Projects/JVMTesting/bugs/t *>>> *../../jdk-9.0.4/bin/jaotc --output >> C0.so C0.class >> Error: Failed compilation: >> C0.M1([SLjava/lang/Double;[Ljava/lang/Short;[SLjava/lang/Integer;F[B[B[Ljava/lang/Float;Ljava/lang/Integer;[JLjava/lang/Double;IISS[JBLjava/lang/Object;[SLjava/lang/Character;Ljava/lang/Character;Ljava/lang/Short;[Ljava/lang/Character;[Z[Ljava/lang/Number;[Ljava/lang/Byte;FJ[I[CIIJLjava/lang/Float;[Ljava/lang/Byte;I[C[Ljava/lang/Integer;BB[Ljava/lang/Integer;[CLjava/lang/Double;[F[Ljava/lang/Double;Ljava/lang/Character;)B: >> java.lang.StackOverflowError >> Error: Failed compilation: >> C0.M3(FLjava/lang/Object;SB[Ljava/lang/Float;[Ljava/lang/CharSequence;[IJ[BLC0;CLjava/lang/Object;Ljava/lang/CharSequence;[ZLjava/lang/Number;ZCF[JLjava/lang/Character;[ZZ[Ljava/io/Serializable;LC0;[Ljava/lang/Integer;[Ljava/lang/String;FZFJZC[Ljava/lang/CharSequence;JI[LC0;CS[Ljava/io/Serializable;[BLjava/lang/Long;Ljava/lang/Short;[S[F[Ljava/lang/Float;[ILjava/lang/Integer;Ljava/lang/Long;[Ljava/lang/String;[IJ[Ljava/lang/Long;LC0;[BB[Ljava/lang/String;[Ljava/lang/String;[B[Ljava/lang/Double;Ljava/lang/Float;BFZLjava/lang/Short;[B[B[CLjava/lang/Number;Z[ZJ[I[LC0;B[ZFLjava/lang/String;I[Ljava/lang/String;[IF[BLjava/lang/CharSequence;C)I: >> java.lang.OutOfMemoryError: Java heap space >> Error: Failed compilation: >> C0.M8(Ljava/lang/Integer;[LC0;[Ljava/lang/Double;[ILjava/lang/Float;[Ljava/lang/Byte;[Ljava/lang/Character;BLjava/lang/Byte;Ljava/lang/Comparable;F[Ljava/lang/Object;[BLjava/lang/Character;C[I[Ljava/lang/String;ZLjava/lang/Long;JLjava/lang/Object;[Ljava/lang/CharSequence;FLjava/lang/Object;[Ljava/lang/Short;[I[Ljava/lang/Character;[BLjava/lang/Character;[Ljava/lang/Number;[Ljava/lang/Number;[ZLjava/lang/String;Ljava/lang/Short;)F: >> java.lang.OutOfMemoryError: Java heap space >> Error: Failed compilation: >> C0.M5(Z[S[Z[BLjava/lang/Double;[Ljava/lang/Integer;Ljava/lang/Short;[Ljava/lang/Integer;[F[I[F[Ljava/lang/Number;FLjava/lang/Float;)C: >> java.lang.OutOfMemoryError: Java heap space >> Error: Failed compilation: C0.main([Ljava/lang/String;)V: java.lang.OutOfMemoryError: >> Java heap space >> Error: Failed compilation: >> C0.M2([Ljava/lang/Number;CJLjava/lang/Character;Ljava/lang/Float;J[ISLjava/lang/Short;)F: >> java.lang.OutOfMemoryError: Java heap space From mark.reinhold at oracle.com Mon Jan 22 18:11:57 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 22 Jan 2018 10:11:57 -0800 Subject: jaotc fails to build the object file for the given class. In-Reply-To: References: Message-ID: <20180122101157.330224994@eggemoggin.niobe.net> 2018/1/22 10:00:20 -0800, benjamin.john.evans at gmail.com: > The jdk9-dev list strips attachments - so you will need to host the > class elsewhere. The jdk9-dev list, like most OpenJDK mailing lists, retains attachments of the following content types: multipart/mixed multipart/alternative text/plain text/x-diff text/x-patch message/rfc822 multipart/signed So if you want to attach a `.java` source file, just attach it as text/plain. > It's probably easiest to set up a Github or other simple OSS project > and put your random class generator, and any examples of classes that > fail AOTC there, and then just give the link in your mail. For IP clarity, many OpenJDK contributors will never follow such a link. Material contributions (bug reports, patches, documentation, etc.) must come in via OpenJDK infrastructure. - Mark From tianxiao.gu at gmail.com Mon Jan 22 18:19:36 2018 From: tianxiao.gu at gmail.com (Tianxiao Gu) Date: Mon, 22 Jan 2018 10:19:36 -0800 Subject: jaotc fails to build the object file for the given class. In-Reply-To: <20180122101157.330224994@eggemoggin.niobe.net> References: <20180122101157.330224994@eggemoggin.niobe.net> Message-ID: @Ben and Andrew and Mark, Thanks very much for your reply and help! Next time I will update the class file to github. Actually, all these StackOverFlow and OutOfMemory issues have been fixed in the latest JDK 10. So they are not issues anymore. I am sorry for asking for help without checking that. Besides, I also found something like org.graalvm.compiler.graph.GraalGraphError: org.graalvm.compiler.debug.GraalError: NormalizeCompareNode connected to org.graalvm.compiler.nodes. calc.IntegerBelowNode$BelowOp at 6de2ac50 (int[16777215|0xffffff] 17|NormalizeCompare false) But all these error messages seem to be caused by invalid bytecode sequences. I wil try to dig it out first. On Mon, Jan 22, 2018 at 10:11 AM, wrote: > 2018/1/22 10:00:20 -0800, benjamin.john.evans at gmail.com: > > The jdk9-dev list strips attachments - so you will need to host the > > class elsewhere. > > The jdk9-dev list, like most OpenJDK mailing lists, retains attachments > of the following content types: > > multipart/mixed > multipart/alternative > text/plain > text/x-diff > text/x-patch > message/rfc822 > multipart/signed > > So if you want to attach a `.java` source file, just attach it as > text/plain. > > > It's probably easiest to set up a Github or other simple OSS project > > and put your random class generator, and any examples of classes that > > fail AOTC there, and then just give the link in your mail. > > For IP clarity, many OpenJDK contributors will never follow such a link. > Material contributions (bug reports, patches, documentation, etc.) must > come in via OpenJDK infrastructure. > > - Mark > From kanth909 at gmail.com Tue Jan 30 06:04:00 2018 From: kanth909 at gmail.com (kant kodali) Date: Mon, 29 Jan 2018 22:04:00 -0800 Subject: is there any tool that can show the execution path of the classloader? Message-ID: Hi All, I posted a question on SO https://stackoverflow.com/questions/48514796/is-there-any-tool-that-can-show-the-execution-path-of-the-classloaders I am wondering if anyone has any suggestions? Thanks, kant From david.holmes at oracle.com Tue Jan 30 06:22:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jan 2018 16:22:40 +1000 Subject: is there any tool that can show the execution path of the classloader? In-Reply-To: References: Message-ID: <72ce6355-158f-8fe3-612b-3e095ce438f5@oracle.com> Hi Kant, This mailing list is effectively dormant now that Java 9 has shipped. On 30/01/2018 4:04 PM, kant kodali wrote: > Hi All, > > I posted a question on SO > https://stackoverflow.com/questions/48514796/is-there-any-tool-that-can-show-the-execution-path-of-the-classloaders > > I am wondering if anyone has any suggestions? java -Xlog:class+load=trace David ----- > Thanks, > kant >