Re: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups

It's a winner! On Mon, Dec 14, 2015 at 1:53 PM, Stuart Marks wrote: > > > On 12/11/15 12:23 PM, Martin Buchholz wrote: >> >> I added Iterator and Comparator to "my" list of tests. Thanks! >> >> The key difference is that we don't try to separate concurrent and >>

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain > in depth > in the context of an example. A more conservative approach is to show using > a static nested class. A lambda

Re: Need help to understand TLS behavior

On Mon, Dec 14, 2015 at 12:52 PM, Bernd Eckenfels wrote: > Maybe it can benefit from the new "No Inherit TLS" Thread constructor? If the process has TLS, then one has to assume there's a good reason, and it will be necessary.

Need help to understand TLS behavior

Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java ThreadFactory threadFactory = grimReaper

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

I remain happy with the webrev Stephen On 14 December 2015 at 08:14, Ramanand Patil wrote: > Hi Roger and all, > > Please review the updated Webrev: > http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066982

Need help to understand TLS behavior

Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code /jdk8u-cpu /jdk /src

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

> On 13 Dec 2015, at 22:38, Chris Hegarty wrote: > > Thanks for looking at this Sergey. > >> On 13 Dec 2015, at 11:16, Sergey Bylokhov wrote: >> >> Hi, Chris. >> What is the reason to use assertion? If the problem is not theoretical, >

Re: Need help to understand TLS behavior

David: What the spec says and what glibc does are two different things: https://sourceware.org/bugzilla/show_bug.cgi?id=11787 We have an internal Google patch to compensate for this. Nasty stuff. Jeremy On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: > On

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better off managing the RandomAccessFile via try-with-resources. That would clean up your exception handling. Regards, Sean. On 12/12/2015 18:43, Xueming Shen wrote: Hi, The changeset for JDK-8142508 had

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

Hi Sherman, thanks for providing the detailed history to this issue. At least for testing purpose it could be definitely nice to set sun.jnu.encoding. It may be also useful on platforms where setlocale() returns bogus values. But I won't insist in changing this until we don't have a real problem

RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi Roger,   The added import in DateTimeFormatter.java  is because of the javadocs entry - {@link ChronoLocalDateTime#atZone(ZoneId)}     Regards, Ramanand.   From: Roger Riggs Sent: Monday, December 14, 2015 8:36 PM To: Ramanand Patil; core-libs-dev@openjdk.java.net Cc:

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi Ramanand, Thanks for the cleanup of the test. On 12/14/2015 3:14 AM, Ramanand Patil wrote: RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition Hi Rogerand all, Please review the updated

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Goetz, On 14/12/2015 16:11, Lindenmaier, Goetz wrote: Hi Frederic, thanks for your fast reply. From reading the code I guessed about what you explained, now I understood more details, thanks! I will not fiddle with handling the zones. My change is only about handling larger pages, i.e. the

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: > > Hello > > Please review the new version on the patch. > > New webrev: > Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > Webrev jdk:

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, On 15/12/2015 8:38 AM, Roger Riggs wrote: Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine

Re: Need help to understand TLS behavior

On 15/12/2015 6:53 AM, Martin Buchholz wrote: Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing about that in "ELF Handling for Thread Local Storage".

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 15/12/2015 10:48 AM, Mandy Chung wrote: On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a

Re: Need help to understand TLS behavior

On 15/12/2015 4:32 PM, Jeremy Manson wrote: David: What the spec says and what glibc does are two different things: https://sourceware.org/bugzilla/show_bug.cgi?id=11787 We have an internal Google patch to compensate for this. Nasty stuff. Nasty isn't even the right word - this is just

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

PS. create(): can also throw SecurityException if not allowed to create/start threads. David On 10/12/2015 4:40 AM, Roger Riggs wrote: Hi, The example is revised to caution about inner classes and lambdas. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Re: Need help to understand TLS behavior

On 15/12/2015 6:52 AM, Bernd Eckenfels wrote: Am Mon, 14 Dec 2015 09:15:55 -0500 schrieb Roger Riggs : Hi, The reaper thread that waits for process exit has minimal stack requirements, and if possible should not consume all of the memory for a full stack. The 32k

Re: RFR(XXS): 8145212: ISO-8859-1 isn't properly handled as 'fastEncoding' in jni_util.c

Forwarded to core-libs-dev upon request. As I already got two reviews (thanks Roger and Martin) and as the fix for "8145015: jni_GetStringCritical asserts for empty strings" [1] has just been pushed to jdk9/hs-rt/hotspot I plan to push this one to jdk9/hs-rt/jdk as well. Regards, Volker [1]

Re: Need help to understand TLS behavior

Hi David, TLS is thread local storage. In test program it is defined using #define TLS_SIZE 32 int __thread XYZ[TLS_SIZE * 1024]; Regards, Cheleswer On 12/14/2015 6:29 PM, David Holmes wrote: What is TLS in this context? Thanks, David On 14/12/2015 10:34 PM, cheleswer sahu wrote: Hi, I am

Re: Need help to understand TLS behavior

Hi, The reaper thread that waits for process exit has minimal stack requirements, and if possible should not consume all of the memory for a full stack. The 32k number is a guess at a small stack. It has worked so far except in cases where the VM configuration or parameters increase the size

Re: Need help to understand TLS behavior

What is TLS in this context? Thanks, David On 14/12/2015 10:34 PM, cheleswer sahu wrote: Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Karen, Thank you for your review. Fred On 23/11/2015 20:10, Karen Kinnear wrote: Frederic, Looks good. Many thanks. Karen On Nov 23, 2015, at 12:44 PM, Frederic Parain > wrote: Karen, Thank you for your review, my answers

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Goetz, The reserved zone is sometime considered as a subpart of the yellow zone, and sometime as an independent entity. Technically the reserved zone is placed just before the yellow zone, but the way it is managed depends on the context. In most cases, there's no specially annotated methods on

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

Ah - of course. That comment would been lack of coffee syndrome on my behalf earlier this morning then ;) Regards, Sean. On 14/12/15 16:36, Xueming Shen wrote: On 12/14/15 1:13 AM, Seán Coffey wrote: Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better

Re: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]

On 12/14/15 1:13 AM, Seán Coffey wrote: Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better off managing the RandomAccessFile via try-with-resources. That would clean up your exception handling. Hi Sean, The "zfile" does not need to close if "new

Re: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups

On 12/11/15 12:23 PM, Martin Buchholz wrote: I added Iterator and Comparator to "my" list of tests. Thanks! The key difference is that we don't try to separate concurrent and non-concurrent collections, so my "collections test set" includes all of /java/util/concurrent even though it's

RE: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Hi Frederic, I'm now again working on my change "8139864: Improve handling of stack protection zones." Coleen had asked me to wait until this change of yours is submitted. You changed the stack_yellow_zone accessor functions in thread.hpp to handle both zones, yellow and reserved. Therefore,

ExceptionTable addition?

Greetings, From a byte code analysis--toolsy point of view, it would be nice if you could deterministically find the end of a catch/finally block. Unfortunately, the ExceptionTable attribute only lists the starts of trys/catches/finallys. Now obviously, there are times when you can

RE: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Hi Frederic, thanks for your fast reply. From reading the code I guessed about what you explained, now I understood more details, thanks! I will not fiddle with handling the zones. My change is only about handling larger pages, i.e. the sizes of the zones, so there is no danger I will break

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Hi Joel, Revised ccc request finalized for current version of the spec; should be approved in a day or two. Once that is approved, I think the current version can be pushed, enabling the refactorings you've alluded to to occur later. Thanks, -Joe On 12/13/2015 12:26 PM, Joel

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

The added text and tests represent a spec clarification. The behaviour in this area was not precisely defined before. The bug itself was clear due to the expected round-trip behaviour of toString() and parse(). While this is a slightly more tricky backport than some, it is really quite broken in

Re: Reference.reachabilityFence

> On 11 Dec 2015, at 16:52, Vitaly Davidovich wrote: > > Hi Paul, > > No objections, but just wanted to summarize a couple of possible key > performance issues that were raised on the concurrency-interest thread. You > may have picked them up already, so pardon the

RE: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi Roger and all, Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066982 Roger, please see my comments about new tests: - All my test methods were earlier generic with main method and hence had

Re: Producing streams in java.time?

Hi Tagir, What are the use cases? Does it need to be more convenient? It seems relatively easy to do in application code. Could there be a more general form that would be as useful but add fewer methods? Roger On 12/10/2015 11:31 AM, Tagir F. Valeev wrote: Hello! Currently it seems

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and others should stick

Re: Need help to understand TLS behavior

On 14/12/2015 11:06 PM, cheleswer sahu wrote: Hi David, TLS is thread local storage. In test program it is defined using #define TLS_SIZE 32 int __thread XYZ[TLS_SIZE * 1024]; Thanks for clarifying. What test is that? I'm guessing this may be a linux only test? Which platform do you see the

Re: Need help to understand TLS behavior

Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. IOW, the java thread stack size should actually be available for stack frames. Hotspot should be fixed, but it's not easy. On Mon, Dec 14, 2015 at 12:47 PM, David Holmes

Re: Need help to understand TLS behavior

Am Mon, 14 Dec 2015 09:15:55 -0500 schrieb Roger Riggs : > Hi, > > The reaper thread that waits for process exit has minimal stack > requirements, > and if possible should not consume all of the memory for a full stack. > The 32k number is a guess at a small stack. It

Re: RFR 8144675: Add a filtering collector

> On 10 Dec 2015, at 15:29, ShinyaYoshida wrote: > > Hi Stuart, > Thank you for your review and comment. > The doc comment is wonderful! > I like it, it must be helpful to users when they understand this method and > how the filtering collector works! > > I've updated the

Re: RFR 8143404: Remove apple script engine code in jdk repository

On 07/12/2015 19:38, Mike Dever Google wrote: Is there a work around? That really limits, actually kills a lot of functionality. The JDK 7 and JDK 8 builds don't declare AppleScript in the services configuration file (META-INF/services/javax.script.ScriptEngineFactory). This means that if

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Hi Igor I have filed an RFE you asked about https://bugs.openjdk.java.net/browse/JDK-8145297. -Konstantin On 12/12/2015 05:10 AM, Igor Ignatyev wrote: Hi Konstantin, the fix and tests look good to me, but I think you have to wait for OK from Coleen. One minor thing —it looks like there

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 14, 2015, at 5:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain > in depth > in the context of an example. A more conservative approach is to show using > a static nested > class. A lambda