Re: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member
On 7/26/19 11:51 PM, Alan Bateman wrote: On 26/07/2019 22:12, Mandy Chung wrote: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup on a different lookup class. A quick fix for this bug is to pass Object.class for resolution for a Lookup object with UNCONDITIONAL mode as previously. The lookup class and allowed modes are used to check if the resolved member is accessible to this Lookup object. We should re-examine this area in particular publicLookup (see JDK-8173977). Looks okay as a quick fix, surprised it is only caught with tier5 or 6 testing. It was a surprise that this was not caught in our tier1-3 testing. We shall revisit and expand tier1-3 to execute certain tests such as jdk_lang group in fastdebug mode. I assume JDK-8173977 will need a priority boost. It may be time to revisit this together with loader constraints (although they are orthogonal). Mandy
Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent
On 26/07/2019 20:01, Brian Burkhalter wrote: So updated: http://cr.openjdk.java.net/~bpb/8078891/webrev.02/ This version is a lot cleaner and looks okay to me. -Alan
Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent
On 26/07/2019 20:37, Pavel Rappo wrote: For the record. If we change this as you suggested, the code will behave differently in the case of a single `null` element found in the midst of iteration (broken enumeration?). The stream won't be able to close after running into it. But this most likely is a programming error anyway. The changes in webrev.01 probably have the same issue because nextStream will throw NPE when nextElement returns null and this will terminate the close without closing the streams that follow the null. Yeah, it's a usage/programming error. peekNextStream could include an exception message to help with such cases but it hardly seems worth trying to do more. -Alan
Re: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member
On 26/07/2019 22:12, Mandy Chung wrote: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup on a different lookup class. A quick fix for this bug is to pass Object.class for resolution for a Lookup object with UNCONDITIONAL mode as previously. The lookup class and allowed modes are used to check if the resolved member is accessible to this Lookup object. We should re-examine this area in particular publicLookup (see JDK-8173977). Looks okay as a quick fix, surprised it is only caught with tier5 or 6 testing. I assume JDK-8173977 will need a priority boost. -Alan
