Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Roger, On 12/04/2017 03:09 PM, Peter Levart wrote: On 12/04/2017 02:25 PM, Peter Levart wrote: Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

On 12/04/2017 02:25 PM, Peter Levart wrote: Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

AltFinalizer after this.finalize() returns. I don't know what impact does such order have on the compatibility. Probably not big. Regards, Peter On 12/04/2017 02:25 PM, Peter Levart wrote: Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Condit

Fwd: Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Sending previous message to the list also (forgot to mention it in CC)... Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder if it is the right thing to use AltFina

Re: RFR 8080225 FileInput/OutputStream/FileChannel cleanup should be improved

Hi Rogger, On 12/04/2017 02:17 PM, Peter Levart wrote: Hi Rogger, Interesting approach. Conditional finalization. You use finalization to support cases where user overrides finalize() and/or close() and Cleaner when he doesn't. I wonder if it is the right thing to use AltFinalizer

RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

la je 21. 11. 2017 ob 10:14 napisal: Thanks Peter for sponsoring this patch. Is there anything else that needs to be done from my end for this patch to be integrated? Please let me know. -Venkat On 14/11/17 8:46 PM, Peter Levart wrote: Hi Venkat, I created the following issue: https://bugs.ope

Re: Collections.emptyList().sort() does nothing

Hi, On 11/15/2017 12:18 PM, Vitaly Davidovich wrote: On Wed, Nov 15, 2017 at 5:21 AM Andrej Golovnin wrote: On 15/11/17 10:03, Andrej Golovnin wrote: I think we would need to write ugly code in any case as Java 9 has now two empty list implementations: Collections.emptyList() and List.of().

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi David, On 11/14/2017 10:28 PM, David Holmes wrote: Hi Peter, On 15/11/2017 1:02 AM, Peter Levart wrote: Hi David, On 11/11/2017 07:51 AM, David Holmes wrote: AFAICS SimpleTimeZone is simply not thread-safe. It has state that can be modified concurrently without synchronization and with

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Patrick, On 11/10/2017 09:49 AM, Patrick Reinhart wrote: Hi Stuart, After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would see

Re: Incorrect validation of DST in java.util.SimpleTimeZone

R Chintala wrote: Thanks David, Peter for your review and comments. As I am new to the community, can you please help me to open a bug and integrate the changes into code base? -Venkat On 12/11/17 2:19 AM, Peter Levart wrote: Hi David, Venkat, On 11/11/17 21:15, Peter Levart wrote: For

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi David, On 11/11/2017 07:51 AM, David Holmes wrote: AFAICS SimpleTimeZone is simply not thread-safe. It has state that can be modified concurrently without synchronization and with fields not even declared volatile. Only the "cache" makes an attempt to use synchronization. So clone() is neve

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi David, Venkat, On 11/11/17 21:15, Peter Levart wrote: For example, take the following method: String defaultTZID() {     return TimeZone.getDefault().getID(); } When JIT compiles it and inlines invocations to other methods within it, it can prove that cloned TimeZone instance never

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi David, On 11/11/17 13:37, David Holmes wrote: Hi Peter, On 11/11/2017 8:06 PM, Peter Levart wrote: Hi Venkateswara R Chintala, I would like to remind that TimeZone.clone() is also in the code path of java.time.ZoneId.systemDefault() where it was relied on to be optimized by JIT to never

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi Venkat, On 11/10/17 13:07, Venkateswara R Chintala wrote: Hi, In a multi-threaded environment, when java.util.SimpleTimeZone object is used to create a default timezone, there can be a race condition between the methods java.util.Timezone.getDefault() and java.util.Timezone.getDefaultRef(

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi Venkateswara R Chintala, I would like to remind that TimeZone.clone() is also in the code path of java.time.ZoneId.systemDefault() where it was relied on to be optimized by JIT to never actually allocate the cloned TimeZone object by employing escape analysis. It would be nice to verify if

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 11/03/17 09:48, Peter Levart wrote: Hi Sherman, I think this looks good now. Thanks. Regards, Peter Just one more thing. Re-reading the code once more after a few days made me re-think about why in my last version I did what I did with CleanableResource.inflaters field. In

Re: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

Hi, On 11/03/2017 02:17 PM, Alan Bateman wrote: On 03/11/2017 08:11, Christoph Dreis wrote: Hi John, this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this? The footprint is probably about the same.  Small List.of values do not contain

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

582/webrev/ thanks, sherman On 11/1/17, 5:04 AM, Peter Levart wrote: Hi Sherman, On 11/01/17 00:25, Xueming Shen wrote: Hi Peter, After tried couple implementations it seems the most reasonable approach is to use the coding pattern you suggested to move all pieces into ZSStream Ref. Given we

Re: ThreadPoolExecutor and finalization

limited view over any ExecutorService and there may be multiple views over same instance. Regards, Peter From: core-libs-dev on behalf of Peter Levart Sent: Thursday, November 2, 2017 10:23 AM To: David Holmes; Roger Riggs Cc: core-libs-dev Subject: Re

Re: ThreadPoolExecutor and finalization

Hi, On 11/02/2017 01:47 PM, David Holmes wrote: public class CleanableExecutorService implements ExecutorService { private final ThreadPoolExecutor tpe; public CleanableExecutorService(ThreadPoolExecutor tpe) { CleanerFactory.cleaner().register(this, tpe::shutdown);

Re: ThreadPoolExecutor and finalization

On 11/02/2017 01:47 PM, David Holmes wrote: On 2/11/2017 7:26 PM, Peter Levart wrote: On 11/02/2017 03:34 AM, David Holmes wrote: On 2/11/2017 3:46 AM, Peter Levart wrote: On 11/01/17 13:34, David Holmes wrote: On 1/11/2017 10:20 PM, Peter Levart wrote: On 11/01/17 10:04, David Holmes

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi, On 11/02/2017 12:51 AM, Stuart Marks wrote: On 11/1/17 10:45 AM, Tagir Valeev wrote: Set.of: +    if (coll instanceof ImmutableCollections.AbstractImmutableSet) { +    return (Set)coll; +    } else { +    return (Set)Set.of(coll.stream().distinct().toArray()); I

Re: ThreadPoolExecutor and finalization

On 11/02/2017 03:34 AM, David Holmes wrote: On 2/11/2017 3:46 AM, Peter Levart wrote: On 11/01/17 13:34, David Holmes wrote: On 1/11/2017 10:20 PM, Peter Levart wrote: On 11/01/17 10:04, David Holmes wrote: On 1/11/2017 6:16 PM, Peter Levart wrote: On 11/01/17 02:49, David Holmes

Re: ThreadPoolExecutor and finalization

On 11/01/17 13:34, David Holmes wrote: On 1/11/2017 10:20 PM, Peter Levart wrote: On 11/01/17 10:04, David Holmes wrote: On 1/11/2017 6:16 PM, Peter Levart wrote: On 11/01/17 02:49, David Holmes wrote: Hi Roger, On 31/10/2017 11:58 PM, Roger Riggs wrote: Hi Peter, Only native resources

Re: ThreadPoolExecutor and finalization

On 11/01/17 10:04, David Holmes wrote: On 1/11/2017 6:16 PM, Peter Levart wrote: On 11/01/17 02:49, David Holmes wrote: Hi Roger, On 31/10/2017 11:58 PM, Roger Riggs wrote: Hi Peter, Only native resources that do not map to the heap allocation/gc cycle need any kind of cleanup.  I would

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 11/01/17 00:25, Xueming Shen wrote: Hi Peter, After tried couple implementations it seems the most reasonable approach is to use the coding pattern you suggested to move all pieces into ZSStream Ref. Given we are already using the internal API CleanerFactory it is attractive t

Re: ThreadPoolExecutor and finalization

Regards, Peter David - For TPE, since Threads do not become unreferenced, the part of the spec related to finalize being called by the finalizer thread is moot. $.02, Roger On 10/31/2017 5:24 AM, Peter Levart wrote: Hi, Here are some of my thoughts... On 10/31/17 05:37, David Ho

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Mandy, Sherman, Roger, On 10/31/17 00:25, mandy chung wrote: On 10/30/17 1:49 PM, Peter Levart wrote: ...above example lends itself as a use case for the following equivalent alternative using internal low-level API where ZStreamRef becomes the Cleanable itself: class ZStreamRef

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 10/31/17 00:32, Xueming Shen wrote: On 10/30/2017 01:34 PM, Peter Levart wrote: The Inflater and Deflater now look fine (except you don't have to check for cleanable != null any more in Inflater.end()). But what shall we do with ZipFile? Peter, The fundamental issue

Re: ThreadPoolExecutor and finalization

Hi, Here are some of my thoughts... On 10/31/17 05:37, David Holmes wrote: Hi Roger, On 31/10/2017 12:43 AM, Roger Riggs wrote: Hi David, On 10/30/2017 3:31 AM, David Holmes wrote: Hi Andrej, On 30/10/2017 5:02 PM, Andrej Golovnin wrote: Hi David, On 30. Oct 2017, at 01:40, David Holmes

Re: ThreadPoolExecutor and finalization

Hi David, On 10/31/17 08:45, David Holmes wrote: The docs for TPE cover this in detail: [1] Finalization     A pool that is no longer referenced in a program AND has no remaining threads will be shutdown automatically. If you would like to ensure that unreferenced pools are reclaimed even if

Re: ThreadPoolExecutor and finalization

Hi, On 10/31/17 05:12, David Holmes wrote: On 31/10/2017 1:02 AM, David Lloyd wrote: On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs wrote: ThreadPoolExecutor has a responsibility to cleanup any native resources it has allocated (threads) and it should be free to use whatever mechanism is appro

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi again, On 10/30/17 21:34, Peter Levart wrote: To mimic the finalization registration, it might be a good to encourage the following coding pattern (using Inflater/ZStreamRef just as an example, not suggesting to do that here unless you like it): class ZStreamRef implements Runnable

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 10/30/17 19:45, Xueming Shen wrote: Peter, Given we have to put in those "make it more robust" code in ZipFile to make cleaner work correctly with the zipfile/inflater in those vm error circumstances I would assume it is a wrong design decision to have the short-cut Inflater c

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 10/28/2017 09:01 PM, Xueming Shen wrote: On 10/28/17, 10:47 AM, Peter Levart wrote: Hi Florian, On 10/28/17 16:16, Florian Weimer wrote: * Xueming Shen: https://bugs.openjdk.java.net/browse/JDK-8187485 http://cr.openjdk.java.net/~sherman/8185582/webrev In ZipFile: 387

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Florian, On 10/28/17 16:16, Florian Weimer wrote: * Xueming Shen: https://bugs.openjdk.java.net/browse/JDK-8187485 http://cr.openjdk.java.net/~sherman/8185582/webrev In ZipFile: 387 Inflater inf = getInflater(); 388 InputStream is = new ZipFileInflaterInput

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

me up with a nice short explanation that is understandable to anyone. I'll try to come up with something tomorrow. Regards, Peter Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.04/ Regards, Ogata From: David Holmes To: Peter Levart , Kazunori Ogata Cc:

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

l value. Does this make sense? Regards, Peter On 10/23/17 22:47, Peter Levart wrote: Hi Ogata, Sorry for late reply. You are absolutely right. Good catch! I missed this scenario. The criteria for placing the mark (current Thread) on a cachedLoader must include the check that validates previ

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

.java.net/~horii/8188858/webrev.03/ I also made minor changes to reduce the number of invocation of the JNI method Thread.currentThread(). Regards, Ogata From: Peter Levart To: Kazunori Ogata , Alan Bateman Cc: core-libs-dev@openjdk.java.net Date: 2017/10/16 19:5

Re: RFR: 8189266: (ann) Optimize AnnotationInvocationHandler.invoke

Hi Claes, This looks good. And can even be backported if desired. If/When Christoph's proposal to add Executable.getParameterType(index) gets accepted, all getParameterTypes() usages will be fixed at once, including this one... Regards, Peter On 10/20/2017 04:10 PM, Claes Redestad wrote: H

Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0

Did not cause the mincore output buffer to be unnecessarily large. Thanks for catching this. As for your other concern: On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart mailto:peter.lev...@gmail.com>> wrote: -- In Java_java_nio_MappedByteBuffer_isLoaded0,

Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0

Hi Thomas, Just one more concern... On 10/18/2017 09:44 AM, Thomas Stüfe wrote: Hi all, I am wrapping up fixes which did not make it into the repo before the consolidation. Alan already reviewed the last webrev, but I need a second reviewer. Issue: https://bugs.openjdk.java.net/browse/JDK

Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0

On 10/18/2017 10:14 AM, Peter Levart wrote: Hi Thomas, Shouldn't the following line:   47 return len2 + pagesize - 1 / pagesize; ..be written as:            return (len2 + pagesize - 1) / pagesize; ...or better yet, as:            return numPages; (you already calcula

Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0

Hi Thomas, Shouldn't the following line:   47 return len2 + pagesize - 1 / pagesize; ..be written as:            return (len2 + pagesize - 1) / pagesize; Regards, Peter On 10/18/2017 09:44 AM, Thomas Stüfe wrote: Hi all, I am wrapping up fixes which did not make it into the repo befor

Re: AssertionError in WildcardTypeImpl.getUpperBoundASTs

1011) at org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1000) On Tue, Oct 17, 2017 at 12:13 PM, Peter Levart wrote: Hi Dawid, The [2] mentions a thread which resulted in a patch by Martin Bucholtz for JDK 9: https://bugs.openjdk.java.net/browse/JDK-8065172 ...

Re: AssertionError in WildcardTypeImpl.getUpperBoundASTs

Hi Dawid, The [2] mentions a thread which resulted in a patch by Martin Bucholtz for JDK 9: https://bugs.openjdk.java.net/browse/JDK-8065172 ...but it seems this has not been backported to 8u (yet). The question is, will there be any more 8u releases? Would you like this to be backported to

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

Hi Ogata, I found a problem in my last suggestion. See below... On 10/16/2017 11:36 AM, Peter Levart wrote: On 10/16/2017 11:02 AM, Peter Levart wrote: For example: - let public readObject() / readUnshared() entry and exit points just clear the cached loader (set it to null). An

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

On 10/16/2017 11:02 AM, Peter Levart wrote: For example: - let public readObject() / readUnshared() entry and exit points just clear the cached loader (set it to null). An alternative would be for entry point to save and clear the cached loader while exit point would restore / clear it if

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

Hi Ogata, I think that webrev.02 is safe as you describe. But there's one case which now has some overhead. It's a common practice to subclass ObjectInputStream and override resloveClass() method and implement custom resolving (without calling super.resolveClass()). In such case, the cached l

Re: RFR 8080225: FileInputStream cleanup should be improved

On 10/14/17 10:51, Peter Levart wrote: Hi Roger, I know I'm late for the comments on this one, but anyway... I'm looking at JNI part of FileDescriptor. There are now two native "close" methods for each FileDescriptor variant (unix/windows). One is instance method (clos

Re: RFR 8080225: FileInputStream cleanup should be improved

Hi Roger, I know I'm late for the comments on this one, but anyway... I'm looking at JNI part of FileDescriptor. There are now two native "close" methods for each FileDescriptor variant (unix/windows). One is instance method (close0) and the other is static (cleanupClose0), which takes an int

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

On 10/13/2017 08:55 AM, Christoph Dreis wrote: Hi Peter, Thanks for your feedback! Method.getName() returns an interned String and String literals are interned strings. Reference comparison is therefore possible Good point. The pair (declaringClass, methodName) uniquely identifies the me

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

erman This looks good to me. Regards, Peter On 9/30/17, 12:41 AM, Peter Levart wrote: Right, the Inflater is captured by the cleaning function for the ZipFileInflaterInputStream and is kept strongly reachable until the function fires, which may happen automatically or manually. At tha

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

meterCount == 1 && member.equals("equals") && +method.getParameterTypes()[0] == Object.class) return equalsImpl(proxy, args[0]); -if (paramTypes.length != 0) +if (parameterCount != 0) throw new AssertionError("Too m

Re: Review Request JDK-8164512: Replace ClassLoader use of finalizer with phantom reference to unload native library

Hi Mandy, On 10/10/17 17:00, mandy chung wrote: Now that (system)nativeLibraries is a Map, is it still necessary to iterate it and call lib.findEntry(name) on each NativeLibrary until the one that returns a non-zero entry or would it be semantically equivalent to 1st look-up the Map by the 'na

Re: Review Request JDK-8164512: Replace ClassLoader use of finalizer with phantom reference to unload native library

On 10/09/2017 10:17 PM, mandy chung wrote: David, Peter, Alan The VM has a fast path to search the symbol from libjava.so first for bootstrap loader.  That was the case I mostly concern about performance and it's not impacted by this change.   Also I consulted with Claes on the performance i

Re: Review Request JDK-8164512: Replace ClassLoader use of finalizer with phantom reference to unload native library

On 10/09/2017 10:20 AM, Alan Bateman wrote: On 06/10/2017 20:37, mandy chung wrote: : The native libraries map is now created lazily with synchronization.    I keep the lazy initialization that will save to create a CHM as many custom class loaders don't have native code.  I think it's a g

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 09/30/17 02:02, Xueming Shen wrote: On 9/29/17, 1:18 PM, Peter Levart wrote: Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 23:23, Remi Forax wrote: - Mail original - De: "Peter Levart" À: "Roger Riggs" , "core-libs-dev" Envoyé: Vendredi 29 Septembre 2017 23:14:33 Objet: Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers On 09/29/17

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 23:11, Peter Levart wrote: Hi Roger, On 09/29/17 22:55, Roger Riggs wrote: fyi, The proposed[1]  changes to FileInputStream and FileOutputStream remove the finalize method exposing Object.finalize (throws Throwable) to subclasses.  We may need retain the finalize methods (with

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

compatibility. The problem is that empty finalize() method that throws anything other than Throwable will not compile. Regards, Peter Roger [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049351.html On 9/29/2017 4:49 PM, Xueming Shen wrote: On 9/29/17, 1:18 PM, Peter

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Remi, On 09/29/17 22:49, Remi Forax wrote: - Mail original - De: "mandy chung" À: "Peter Levart" , "Xueming Shen" , "core-libs-dev" Envoyé: Vendredi 29 Septembre 2017 22:34:52 Objet: Re: RFR JDK-8185582, Update Zip implementation to use Cle

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 22:34, mandy chung wrote: On 9/27/17 2:31 AM, Peter Levart wrote: Up to a point where 'this' is dereferenced to obtain the 'zsRef' value (line 261), the Deflater instance is reachable. But after that, even ensureOpen() may be inlined and 'this'

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported exception Throwable; must be caught or declared to be thrown super.finalize();

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

:31 PM, Peter Levart wrote: Hi Sherman, At first I checked the Deflater/Inflater changes. I'll come back with ZipFile later. I think the code is mostly correct, but I have a concern. If clean() is invoked via Deflater.end(), then the Deflater instance is still alive and synchronizati

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, At first I checked the Deflater/Inflater changes. I'll come back with ZipFile later. I think the code is mostly correct, but I have a concern. If clean() is invoked via Deflater.end(), then the Deflater instance is still alive and synchronization is necessary as other threads mig

Re: Scanning multi version jars?

On 09/19/2017 09:34 AM, Alan Bateman wrote: On 19/09/2017 05:37, Greg Wilkins wrote: : Which raises an interesting point   with the multi versioned jar I have used as an example, which contains:     - org/example/Foo.class     - org/example/Foo$Bar.class     - META-INF/versions/9/org/e

Re: Review Request JDK-8186050: StackFrame should provide the method signature

Hi Mandy, On 09/21/2017 05:15 PM, mandy chung wrote: Hi Peter, Updated webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186050/webrev.03/ On 9/3/17 7:02 AM, Peter Levart wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8186050/webrev.02/ That's what

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi Ogata, Thanks, I'll try with a Java equivalent of below structure. I can change it later if needed. Stay tuned... Regards, Peter On 09/21/2017 11:39 AM, Kazunori Ogata wrote: Hi Peter, If you could extract from the benchmark just the approximate shape of the data structure and typical

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

On 09/20/2017 12:12 PM, Kazunori Ogata wrote: By the way, I'm running the benchmark on POWER8 machine. Removing volatile won't change the performance on x86. I would like to compare different variants of optimization using final fields. I won't compare it with current code that uses volatil

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi Ogata, On 09/20/2017 12:12 PM, Kazunori Ogata wrote: Hi Peter, The benchmark is GradientBoostingTree of Intel HiBench [1]. HiBench is a suite of programs using Hadoop or Spark, and GradientBoostingTree is a Spark program. The source code (in Scala) is [2]. To build the code, you need Apac

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

From: Hans Boehm To: Kazunori Ogata Cc: Peter Levart , core-libs-dev Date: 2017/09/19 05:47 Subject:Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout() On Mon, Sep 18, 2017 at 10:52 AM, Kazunori Ogata wrote: Hi Peter, Peter Levart wrote on

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

od' value which is always recomputed in ObjectInputStream.readSerialData if your benchmark shows this is a promising direction... Regards, Peter Regards, Ogata Peter Levart wrote on 2017/09/18 05:51:07: From: Peter Levart To: Hans Boehm Cc: Kazunori Ogata , core-libs-dev Date: 2017/09/18 0

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi, On 09/15/17 19:54, Hans Boehm wrote: The problem occurs if this is transformed (by hardware or compiler) to 1196     ClassDataSlot[] getClassDataLayout() throws InvalidClassException { 1197         // REMIND: synchronize instead of relying on fullFence()?                   1198         Cl

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi, On 09/15/2017 07:12 AM, Kazunori Ogata wrote: Hi Hans, Thank you for your comment Hans Boehm wrote on 2017/09/15 09:44:56: Just to be clear, the semi-plausible failure scenario here is that a reader will see a non-null slots value, but then read an uninitialized value from the ClassData

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi, Maybe a more knowledgeable soul could shed some light into an internal @Stable annotation... It was meant to be used internally in the java.lang.invoke package, but in JDK 9 it was made public, not exported, so it can be used in the entire java.base module. There are already some usages

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Ops, pressed SEND to quickly... On 09/04/2017 10:45 AM, Peter Levart wrote: ClassDataSlot[] getClassDataLayout() throws InvalidClassException { ClassDataSlot[] slots = dataLayout; if (slots == null) { ClassDataSlot[] slots = getClassDataLayout0

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi Ogata, On 09/04/2017 10:23 AM, Kazunori Ogata wrote: Hi Peter, Thank you for your comment. I thought the compiler must insert memory fence at the end of object initializer, but I agree relying on it is not correct w.r.t. JMM. Then I'll take 1) 1) Put VarHandle.fullFence() between initializ

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

Hi Ogata, On 09/04/2017 07:20 AM, Kazunori Ogata wrote: 4) Put reference to ClassDataSlot[] into a final field of an object, read the final field immediately after the object creation, and store it to non-volatile dataLayout. I think this is also correct based on the semantics of final fields a

Re: Review Request JDK-8186050: StackFrame should provide the method signature

Hi Mandy, On 09/03/2017 04:52 AM, mandy chung wrote: On 9/2/17 2:57 AM, Peter Levart wrote: Hi Mandy, The API looks fine to me. Note that there is an opportunity for a follow-up optimization of the StackFrameInfo::getDescriptor() case. When MemberName's 'type' field is f

Re: Review Request JDK-8186050: StackFrame should provide the method signature

Hi Mandy, The API looks fine to me. Note that there is an opportunity for a follow-up optimization of the StackFrameInfo::getDescriptor() case. When MemberName's 'type' field is filled by native expandFromVM() it is usually filled with the descriptor string. MemberName::getMethodType() then p

Re: Manifest Add-Exports vs. command line --add-exports

Hi, On 08/23/2017 11:24 PM, Tom Hood wrote: The CLI options to export or open packages can be specified in JNLP file, you shouldn't need to ask user to add them via the control panel. You can predicate on the Java SE version too, i.e. The issue is the limit on the *number* of args we can

Re: RFR [10]: 8185362: Replace use of AtomicReferenceFieldUpdater from BufferedInputStream with Unsafe

Hi Claes, On 08/21/2017 01:15 PM, Claes Redestad wrote: On 08/21/2017 12:29 PM, Aleksey Shipilev wrote: On 08/21/2017 12:20 PM, Claes Redestad wrote: Webrev: http://cr.openjdk.java.net/~redestad/8185362/jdk.00/ *) Should be static *final*, otherwise you miss constant folding for Unsafe access

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

Hi Martin, On 08/21/2017 05:05 AM, Martin Buchholz wrote: On Sat, Aug 19, 2017 at 1:53 PM, Martin Buchholz wrote: Now I see that the code snippet in TimeUnit.timedWait is also in need of fixing. H public synchronized Object poll(long timeout, TimeUnit unit) throws Interrupt

Re: RFR: jsr166 jdk10 integration wave 2

On 08/08/2017 02:21 PM, Peter Levart wrote: Hi Martin, Just a purely theoretical question... On 08/08/2017 02:06 AM, Martin Buchholz wrote: Need to fix 1. JDK-8185830 <https://bugs.openjdk.java.net/browse/JDK-8185830> ConcurrentSkipListSet.clone() fail

Re: RFR: jsr166 jdk10 integration wave 2

Hi Martin, Just a purely theoretical question... On 08/08/2017 02:06 AM, Martin Buchholz wrote: Need to fix 1. JDK-8185830 ConcurrentSkipListSet.clone() fails with UnsupportedOperationException http://cr.openjdk.java.net/~martin/webrevs/

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Hi Ivan, On 07/29/2017 07:22 PM, Peter Levart wrote: I tried an approach where sub-sequences are CharSequence objects by delegation and use sub-comparators that don't convert CharSequence(s) to String(s). Here's what this looks like: http://cr.openjdk.java.net/~pl

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Hi Ivan, On 07/28/2017 06:25 PM, Ivan Gerasimov wrote: Hi Peter! Thank a lot for looking into this! On 7/28/17 7:32 AM, Peter Levart wrote: Hi Ivan, In the light of what Stuart Marks wrote, then what do you think about a parameterized comparator (would be sub-optimal, I know) where one

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

would need a comparator comparing the reversed sequence lexicographically, but for Ax sub-sequences, one could choose from a plethora of case-(in)sensitive comparator(s) and collators already available on the platform. Regards, peter On 07/28/2017 04:12 PM, Peter Levart wrote: Hi Ivan

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Hi Ivan, Would I be wrong if I described the logic of these two comparators as the following: The comparator compares two character sequences as though each of them would be 1st transformed into a tuple of the form: (A0, N0, A1, N1, ..., An-1, Nn-1, An) where: A0 and An are (possibly empt

Re: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

Hi Claes, On 07/17/2017 02:16 PM, Claes Redestad wrote: Hi Peter! On 2017-07-15 14:08, Peter Levart wrote: It seems that interning signature(s) is important for correctness (for example, in ObjectOutputStream.writeTypeString(str) the 'str' is used to lookup a handle so that h

Re: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

Hi, On 07/14/2017 04:22 PM, Aleksey Shipilev wrote: On 07/14/2017 04:12 PM, Claes Redestad wrote: Thing is, "volatile" is not as strong as "final" for racy initializations: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals If that is not a concern -- e

Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Ogata, The change looks good. But I think this needs to go through CSR. The CSR FAQ page at: https://wiki.openjdk.java.net/display/csr/CSR+FAQs writes... Q: What sort of changes require CSR review? A: Any change to a JDK interface meant to be used outside of the JDK itself requires CSR re

Re: RFR(M) : 8182154 : merge jdk.testlibrary.Platform and jdk.test.lib.Platform

Hi Igor, On 06/27/2017 03:17 AM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8182154/webrev.01/ 281 lines changed: 18 ins; 223 del; 40 mod; Hi all, could you please review this changeset which removes Platform from jdk testlibrary and updates tests to use jdk.test.lib.Platform

Re: JDK 10 RFR of 8182710: File.listRoots() always returns the root of CD drive

Hi Brian, On 06/23/2017 11:56 PM, Brian Burkhalter wrote: Please review at your convenience. https://bugs.openjdk.java.net/browse/JDK-8182710 http://cr.openjdk.java.net/~bpb/8182710/webrev.00/ The listRoots() method invokes the GetLogicalDrives() Windows function [1] which may set the bit for

Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

? Regards, Peter On 05/20/2017 11:38 PM, joe darcy wrote: Hi Peter, On 5/20/2017 11:00 AM, Peter Levart wrote: Hi Joe, So enum classes, anonymous classes and local classes don't have a standard way of passing synthetic/implicit constructor parameters? Right; there is no standardized or man

Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

On 05/20/2017 11:30 PM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk9-dev/8074977_ConstructorParameterAnnotations/webrev.01/ If there was a reliable way to determine whether a local or anonymous class is from static context or not, then this could work for javac generated

Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

r anonymous class is from static context or not, then this could work for javac generated code at least. Regards, Peter - Mail original - De: "Peter Levart" À: "joe darcy" , "core-libs-dev" Envoyé: Samedi 20 Mai 2017 20:00:25 Objet: Re: JDK 9 RFR of J

Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

I see that local classes in static context don't have STATIC modifier. The same for anonymous classes. So there's no reliable information in the class file whether some local class is from the static context or not? Regards, Peter On 05/20/2017 08:00 PM, Peter Levart wrote: Hi Joe

Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

Hi Joe, So enum classes, anonymous classes and local classes don't have a standard way of passing synthetic/implicit constructor parameters? Do various compilers do it differently than javac? It's unfortunate but if # of parameter annotations arrays is less than the # of parameters, Paramete

<    2   3   4   5   6   7   8   9   10   11   >