Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Hi Maurizio, I'm checking out the thread-confinement in the parallel stream case. I see the Spliterator.trySplit() is calling AbstractMemorySegmentImpl's:  102 private AbstractMemorySegmentImpl asSliceNoCheck(long offset, long newSize) {  103 return dup(offset, newSize, mask, own

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

r. So for short-circuiting streams it might be important to have a MemoryScope that is scalable. Here's one such attempt using a pair of scalable counters (just one pair per root memory scope): import java.util.concurrent.atomic.LongAdder; /**  * @author Peter Levart  */ public abstr

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

On 4/28/20 10:49 PM, Maurizio Cimadamore wrote: On 28/04/2020 17:12, Peter Levart wrote: Hi Maurizio, I'm checking out the thread-confinement in the parallel stream case. I see the Spliterator.trySplit() is calling AbstractMemorySegmentImpl's:  102 private AbstractMemoryS

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

On 4/29/20 2:41 AM, Maurizio Cimadamore wrote: On 28/04/2020 21:27, Peter Levart wrote: Hi, The problem with current implementation of MemoryScope is that if a child scope is frequently acquired and closed (which increments and then decrements the parent scope counter atomically using

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Hi Maurizio, On 4/29/20 2:41 AM, Maurizio Cimadamore wrote: The current implementation has performances that are on par with the previous acquire-based implementation, and also on par with what can be achieved with Unsafe. We do have a micro benchmark in the patch (see ParallelSum (**)) which

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

On 4/29/20 11:16 PM, Maurizio Cimadamore wrote: On 29/04/2020 21:40, Maurizio Cimadamore wrote: On 29/04/2020 08:10, Peter Levart wrote: Right, as you saw in a private Email, I did exactly that in a revised version (posted below). The spurious ISE may happen but only when close is called

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

ty of time until 15 ships... Regards, Peter Cheers Maurizio On 29/04/2020 20:19, Peter Levart wrote: Hi Maurizio, On 4/29/20 2:41 AM, Maurizio Cimadamore wrote: The current implementation has performances that are on par with the previous acquire-based implementation, and also on par with w

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: On 30/04/2020 01:06, Peter Levart wrote: Think differently: what if the client succeeded in closing the segment, just because it did it in a time window when no thread in the thread pool held an open scope (this is entirely possible with

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Hi Maurizio, On 5/1/20 3:00 PM, Peter Levart wrote: Luckily, I think I have fixed this shortcoming in the alternative MemoryScope: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java I added support for dup() (modified above file in-place) and also

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

the adder concurrently with the call to sum() in the close thread. But you just showed above that acquires.increment() (by acquiring thread) happens before acquires.sum() (by closing thread) - they don't execute concurrently, so closing thread can not possibly see the sum of 'a

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

On 5/1/20 4:36 PM, Maurizio Cimadamore wrote: Now there's dup(). I think implementing dup() on a root scope is not too hard - for the child you probably need some trick, but probably not too bad - in the sense that in a Child scope, the cleanup action is really the increment of the root exi

Re: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters

Hi Naoto, On 4/30/20 12:18 AM, naoto.s...@oracle.com wrote: Hello, Please review this small fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8244152 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ The hash map used there didn't

Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

Hi Maurizio, On 5/5/20 4:12 PM, Maurizio Cimadamore wrote: On 02/05/2020 09:45, Peter Levart wrote: Thread 1 does: a) increments 'acquires' b) reads OPEN from 'state' Thread 2 does: c) writes CLOSING to 'state' d) sums 'acquires' 'a&#

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

> Hi Peter, > > You are correct. Thanks. I'll remove that initial value of 16. > > Naoto > > On 5/5/20 9:37 AM, Peter Levart wrote: >> Hi Naoto, >> >> On 4/30/20 12:18 AM, naoto.s...@oracle.com <mailto:naoto

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

that is less than alternative formula's value and too small to adequately pre-size the HashMap table. Voila, we have some bugs to fix or I am doing something wrong here. Regards, Peter On Tue, May 5, 2020 at 12:12 PM Peter Levart <mailto:peter.lev...@gmail.com>> wrote:

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

a/JDK does in floating point before conversion to int. If I put Naoto's formula into my test program, no undercalculations are detected. So while Naoto's formula is sub-optimal for expectedSizes that are multiples of 3, the Guava/JDK also has a bug. Regards, Peter On 5/5/20 10

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

@oracle.com wrote: Hi Peter, You are correct. Thanks. I'll remove that initial value of 16. Naoto On 5/5/20 9:37 AM, Peter Levart wrote: Hi Naoto, On 4/30/20 12:18 AM, naoto.s...@oracle.com wrote: Hello, Please review this small fix to the following issue: https://bugs.openjdk.java.

Re: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor

Hi Claes, One step further would be to eliminate access to FileDescriptor.fd/handle from native hot paths altogether and pass the fd/handle to native methods from java: http://cr.openjdk.java.net/~plevart/jdk-dev/8244936_dont_access_FileDescriptor/webrev.01/ This has similar incremental e

Re: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor

On 5/18/20 10:52 AM, Alan Bateman wrote: On 18/05/2020 09:48, Peter Levart wrote: Hi Claes, One step further would be to eliminate access to FileDescriptor.fd/handle from native hot paths altogether and pass the fd/handle to native methods from java: I was chatting with Claes about this

Re: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor

On 5/18/20 11:11 AM, Alan Bateman wrote: On 18/05/2020 09:59, Peter Levart wrote: : Please elaborate. Do you have an example of such use case? Are there any existing races possible? Everywhere that closes a file descriptor needs to coordinate the closing with threads that may be accessing

RFR: 8247532: Records deserialization is slow

Hi, I noticed that deserializing records (new preview Java feature in JDK14 and JDK15) is slow compared to equivalent classical classes. I created a JMH benchmark [1] to se how it compares (ran it on JDK14): Benchmark Mode

Re: Optimize StringConcatHelper::simpleConcat for empty strings

Hi Tagir, I think that there might be cases where one of the arguments of concatenation is constant empty String. I found myself sometimes doing "" + someNonStringValue (instead of more readable String.valueOf(someNonStringValue)) simply because of laziness. So does this optimization help in

Re: RFR: 8247532: Records deserialization is slow

On 6/14/20 7:03 PM, Johannes Kuhn wrote: Small suggestion: RecordSupport.defaultValueExtractorFor could be written as:     return MethodHandles.empty(MethodType.methodType(pClass, byte[].class, Object[].class)); It could then be inlined. - Johannes Thanks, Johannes. There is also a Me

Re: RFR: 8247532: Records deserialization is slow

So, here's new webrev incorporating Johannes' suggestion: http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.02/ Peter On 6/14/20 11:17 PM, Peter Levart wrote: On 6/14/20 7:03 PM, Johannes Kuhn wrote: Small suggestion: RecordSupport.defaultValueExtractorFo

Re: RFR: 8247532: Records deserialization is slow

dk.java.net/jeps/3#Late-Enhancement-Request-Process On 14 Jun 2020, at 22:34, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: So, here's new webrev incorporating Johannes' suggestion: http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.02/

Re: RFR: 8247532: Records deserialization is slow

Hi Chris, On 6/16/20 5:15 PM, Chris Hegarty wrote: Hi Peter, On 14 Jun 2020, at 17:28, Peter Levart wrote: ... [2] http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.01/ I think that this is very good. It’s clever to build a chain of method handles that can be

Re: RFR: 8247532: Records deserialization is slow

suggested by Johanes Kuhn as here: http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.02/ Regards, Peter On Jun 16, 2020, at 8:15 AM, Chris Hegarty wrote: Hi Peter, On 14 Jun 2020, at 17:28, Peter Levart wrote: ... [2] http://cr.openjdk.java.net/~plevart/jdk-dev

Re: RFR: 8247532: Records deserialization is slow

al - De: "Chris Hegarty" À: "Peter Levart" Cc: "core-libs-dev" Envoyé: Mardi 16 Juin 2020 17:15:03 Objet: Re: RFR: 8247532: Records deserialization is slow Hi Peter, On 14 Jun 2020, at 17:28, Peter Levart wrote: ... [2] http://cr.openjdk.java.net/~plevart/jdk-

Re: RFR: 8247532: Records deserialization is slow

Hi Chris, On 6/17/20 12:31 AM, Peter Levart wrote: I did however notice that there is just a single test, DefaultValuesTest, that exercises different stream shapes for the same class in the stream. Would be good to expand coverage in this area, but of course some lower-level test-specific

Re: RFR: 8247532: Records deserialization is slow

On 6/16/20 5:15 PM, Chris Hegarty wrote: The caching is on a per-stream-field shape basis, which should be consistent in the common case, but of course is not always guaranteed to be the case, hence the need for the cache. I think that this should be fine, since the ObjectStreamClass ( that

Re: RFR: 8247532: Records deserialization is slow

On 6/17/20 8:08 AM, Peter Levart wrote: On 6/16/20 5:15 PM, Chris Hegarty wrote: The caching is on a per-stream-field shape basis, which should be consistent in the common case, but of course is not always guaranteed to be the case, hence the need for the cache. I think that this should be

Re: [PATCH] remove redundant initialization of volatile fields with default values

Hi Remi, On 6/19/20 10:03 AM, Remi Forax wrote: Hi Sergei, the problem is that you are changing the semantics if there are several fields. By example with the code below, you have the guarantee that the code will print 4 (if it prints something), if you remove the assignment field = false, the

Re: [PATCH] remove redundant initialization of volatile fields with default values

Hi, Sergey, On 6/19/20 11:33 AM, Сергей Цыпанов wrote: Hello Remi, thanks for pointing this out, I didn't take this into account. As I understand, the volatile semantics here covers all the fields of an object, no matter whether they are declared before or after volatile field (probably actua

Re: RFR: 8247532: Records deserialization is slow

On 6/17/20 4:47 PM, fo...@univ-mlv.fr wrote: - Mail original - De: "Peter Levart" ... TLDR; So for each record type (Class) there can be several distinct ObjectStreamClasses deserialized in the same VM that were produced by serializing different versions of record types in

Re: RFR: 8247532: Records deserialization is slow

cause ClassCastException is thrown from invokeExact, which is then wrapped with InvalidObjectException and I think is more correct: http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.04/ So this patch actually fixes a little bug too. Regards, Peter 6/17/20 4:13 PM, Ch

Re: RFR: 8247532: Records deserialization is slow

Hi Chris, Here's a small optimization over webrev.04 in the caching logic.We don't need a doubly-linked list to implement a FIFO. Just single 'next' link in each key is sufficient. I also changed initialCapacity of ConcurrentHashMap to 2 (which should be typical number of cached shapes per r

Re: RFR: 8247532: Records deserialization is slow

Hi, When re-running the benchmark [1] with different lengths of serialized arrays of records, I found that, compared to classical classes, lookup into the cache of adapted method handles starts to show when the length of array is larger (# of instances of same record type deserialized in sin

Re: (15) RFR: JDK-8247444: Trust final fields in records

Hi Aleksey, On 6/18/20 7:10 PM, Aleksey Shipilev wrote: On 6/18/20 3:09 PM, Chris Hegarty wrote: On 18 Jun 2020, at 13:43, Aleksey Shipilev wrote: Again, JDK-8247532 is the writing on the wall: we don't need 3rd party developers to tell if Record serialization works fast in 15 -- we already k

Re: RFR: 8247532: Records deserialization is slow

be interesting to explore how poor performance would become if we'd hit the (artificial) 11 layouts limit, e.g, by cycling through 10, 11, or 12 different shapes. /Claes On 2020-06-21 19:16, Peter Levart wrote: Hi, When re-running the benchmark [1] with different lengths of serialized arrays of

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

ev.08/ Regards, Peter On 6/23/20 10:23 AM, Claes Redestad wrote: On 2020-06-23 10:06, Claes Redestad wrote: Hi, On 2020-06-23 09:49, Peter Levart wrote: Hi Chris, Claes, Ok then, here's with benchmark included: http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Thanks, Magnus. Peter On 6/23/20 11:27 AM, Magnus Ihse Bursie wrote: On 2020-06-23 11:17, Peter Levart wrote: Including build-dev since this patch is adding new issue 8248135: https://bugs.openjdk.java.net/browse/JDK-8248135 So here's new webrev with a patch for building benchmarks

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

On 6/23/20 2:47 PM, Chris Hegarty wrote: On 23 Jun 2020, at 10:46, Chris Hegarty wrote: On 23 Jun 2020, at 10:17, Peter Levart wrote: ... http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ Good stuff. Reviewed. I am going to take this latest change and run

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

20 AM, Chris Hegarty wrote: On 24 Jun 2020, at 07:03, David Holmes <mailto:david.hol...@oracle.com>> wrote: Hi Chris, On 24/06/2020 2:30 am, Chris Hegarty wrote: On 23 Jun 2020, at 14:49, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: ... Ok, I'm going to push this t

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

Hi Chris, The patch looks good. Before the patch it made sense to have if (cl != null) in line 750 in ObjectStreamClass, but now nothing in the if block depends on cl, so you could use if (osc != null) instead. It is true that: (cl != null) == (osc != null) always holds there, but readi

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

20, at 17:25, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: Hi Chris, The patch looks good. Before the patch it made sense to have if (cl != null) in line 750 in ObjectStreamClass, but now nothing in the if block depends on cl, so you could use if (osc != null) instead. It i

Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

Hi Joe, For an object to correctly function as an element of a HashSet, its hashCode() and equals() methods must agree: o1.equals(o2) => o1.hashCode() == o2.hashCode(). I see equals() method delegates to a global InstructionComparator instance which can even change. Suppose it does not change. But

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Patrick, In the test(s), you often use sink::accept:     exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(sink::accept))); ...where you could simply pass just sink:     exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).forEach(si

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

ped now as of latest webrev.03: 422 default Stream mapMulti(BiConsumerConsumer> mapper) { Regards, Peter On 7/5/20 10:00 AM, Peter Levart wrote: Hi Patrick, In the test(s), you often use sink::accept:     exerciseOps(data, s -> s.mapMulti((e, sink) -> IntStream.range(0, e).

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Patric, Julia, On 7/2/20 6:45 PM, Patrick Concannon wrote: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.03/ Then I'd like to discuss cancelation (shortcut Streams). Currently mapMulti does not do anythi

Re: RFR 8249217: Unexpected StackOverflowError in "process reaper" thread still happens

Hi Roger, I don't think resolving the ConcurrentHashMap.class ensures initialization of the class. Just loading. But I think CHM is already initialized at that time as it is used in ClassLoader to maintain class loading locks (per class name). Regards, Peter On 7/22/20 4:51 PM, Roger Rig

Re: Possible subtle memory model error in ClassValue

Hi, There might be a way to fix this NPE without adding additional memory fences. The CacheValueMap.cacheArray field is not final because it can change during lifetime of CacheValueMap - it holds an array of entries which can get resized (replaced with bigger array) which is performed while

Re: Possible subtle memory model error in ClassValue

On 8/15/20 10:37 AM, Peter Levart wrote: https://github.com/openjdk/jdk/pull/7 Oops, I forgot to remove the redundant initialization of cacheArray field in constructor, which revealed another place in code where the check for null value has to be made. Here's a modified patch:

Re: SoftCleanable and WeakCleanable

Hi, You are right. For public Cleanable API, only the PhantomCleanable is used currently. It is subclassed by CleanerImpl.PhantomCleanableRef to implement the public API and also a couple of specialized internal implementations. When the public Cleanable API was created, it was thought that

Re: Possible subtle memory model error in ClassValue

On 8/16/20 7:35 PM, Andrew Haley wrote: On 15/08/2020 10:13, Peter Levart wrote: https://github.com/openjdk/jdk/pull/9 Sorry for abusing GitHub pull request mechanism but I don't have bandwidth currently to clone the mercurial repository ;-) That's a lot of work to avoid a si

Re: RFR 8251989: Hex formatter and parser utility

Hi Roger, About methods in Hex.Formatter that append to StringBuilder, like the following one:     public StringBuilder format​(StringBuilder sb, byte[] bytes) ...I was thinking that such method could have more utility if it was specified as:     public A format(A appendable, byte[] b

Re: RFR: 8246774: Record Classes (final) implementation [v3]

On Fri, 25 Sep 2020 02:38:01 GMT, Vicente Romero wrote: >> I have modified the `@since`: 14 -> 16 > > [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) Hi @vicente-romero-oracle , note that besides tests, there is also a JMH benchmark that measures the performance of recor

Re: RFR: 8159746: (proxy) Support for default methods

d open package, is defined in an unconditionally > exported but non-open package. Programs that assume it to be open > unconditionally > will be affected and cannot do deep reflection on such proxy classes. > > Peter Levart contributed an initial prototype [1] (thanks Peter). I think &

Re: RFR: 8159746: (proxy) Support for default methods

On Mon, 28 Sep 2020 13:47:04 GMT, Alan Bateman wrote: >> Hi Mandy, >> In general this looks good but one thing. The Proxy::invokeDefaultMethod >> does a lot of checks (creating derived method >> handles just to check parameters etc.) for every invocation and that means >> performance is not gre

Re: RFR: 8159746: (proxy) Support for default methods

On Thu, 15 Oct 2020 02:54:06 GMT, Mandy Chung wrote: >> Thanks for the input Peter. >> >>> I'm in favour of following the bytecode (method handles) behaviour here >>> even though it allows more than Java language >>> allows. >> >> The proposal intends to follow the bytecode behavior. I can c

Re: RFR: 8159746: (proxy) Support for default methods

On Thu, 15 Oct 2020 18:30:20 GMT, Mandy Chung wrote: >> Hi Mandy, >> >> I'm beginning to think that we somewhat wondered away from the original >> intent which was to mimic the bytecode >> behaviour as much as possible. Bytecode behaviour for super calls >> (invokespecial) is very special and

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On Wed, 14 Oct 2020 18:15:19 GMT, Daniel Fuchs wrote: >> For the common cases, the application should know the type of the referent >> and using `T` in `refersTo` will benefit >> from the compiler type checking. For the unknown type case, cast to >> `Reference` is not ideal but reasonable? >>

Re: RFR: 8159746: (proxy) Support for default methods

On Fri, 16 Oct 2020 18:13:08 GMT, Mandy Chung wrote: >> Hi Mandy, >> >> I read your concerns and have an alternative API proposition here. Instread >> of an abstract class with protected final >> `invokeDefaultMethod` method, we can keep the public static >> `invokeDefaultMethod` and add a `Lo

Re: RFR: 8159746: (proxy) Support for default methods

On Thu, 22 Oct 2020 17:07:55 GMT, Mandy Chung wrote: >> Thanks for the update. Lots of challenges finding the right API as there are >> security and usability issues, not to mention performance and making it look >> like the support for default methods has always been there. >> >> I've skimmed

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung wrote: >> I just want to note that if you have a `Reference ref` at hand, >> you can not just do: >> Referemce r = (Reference) ref; >> ...since those generic types are not related. You have to do something like: >> >> @SuppressWarnings({"unchecked",

Re: RFR: 8159746: (proxy) Support for default methods

On Tue, 27 Oct 2020 19:08:10 GMT, Mandy Chung wrote: >> Hi Peter, >> >> Just a quick reply. I like your idea for a `newProxyInstance` to take an >> invocation handler factory. I went through the security implication and >> also looked into ways to avoid the need of `protected static >> ge

Re: RFR: 8159746: (proxy) Support for default methods

On Wed, 28 Oct 2020 03:06:04 GMT, Mandy Chung wrote: > Hi Peter, > > > Question remains how do we distinguish proxies with old-fassioned > > InvocationHandlers from proxies with InvocationHandlers having access to > > super-default-handler. Both kinds of handlers look the same from Proxy's >

Re: RFR: 8159746: (proxy) Support for default methods

On Wed, 28 Oct 2020 08:35:47 GMT, Peter Levart wrote: >> Hi Peter, >> >>> Question remains how do we distinguish proxies with old-fassioned >>> InvocationHandlers from proxies with InvocationHandlers having access to >>> super-default-handler. Both kinds

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 28 Oct 2020 03:46:55 GMT, Stuart Marks wrote: > Some thoughts regarding the parameter type of refersTo. Summary: I think > `refersTo(T)` is fine and that we don't want to change it to > `refersTo(Object)`. > I agree that we don't have a migration problem here that collections had. So

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Fri, 6 Nov 2020 03:05:45 GMT, Stuart Marks wrote: >> @ePaul wrote: >> >>> The Stream API works just as well with [third party] collection libraries >>> instead of the java.util ones, just using different collectors. Adding a >>> method which directly returns a java.util.List somewhat couple

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Sun, 8 Nov 2020 10:47:08 GMT, Peter Levart wrote: >>> Simon Roberts wrote: >> >>> This discussion of unmodifiable lists brings me back to the thought that >>> there would be good client-side reasons for inserting an UnmodifiableList >>> interface

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Sun, 8 Nov 2020 15:55:58 GMT, Peter Levart wrote: >> Hi Stuart, >> >> I would like to discuss the serialization. You introduce new >> CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this >> change goes into JDK16 for example, JDK15

Re: RFR: 8180352: Add Stream.toList() method [v2]

On 11/17/20 9:08 PM, Stuart Marks wrote: @plevart wrote: Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception. Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases. I would say i

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

Yes Roger, this sounds better to me. Maybe even easier: "There is no guarantee that this effort will recycle any particular number of unused objects, reclaim any particular amount of space, or complete before the method returns (or ever)." So, hypothetically, the effort triggered by System.g

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

On 5/31/19 7:24 PM, Roger Riggs wrote: Hi Martin, True, calling System.gc() and then checking for its hoped-for/expected side-effects is the norm. But its robustness depends on a combination of gc implementation behavior and the particular side-effect expected: allocation, reference processi

EnumSet.class serialization broken - twice

Hi, I recently stumbled on an exception thrown when deserializing stream produced on JDK 8 and read with JDK 11. I narrowed the problem down to serialization/deserialization of a public EnumSet.class object. There were several changes made to EnumSet in the Mercurial history of jdk repo, but

Re: EnumSet.class serialization broken - twice

quirement simply be relaxed with no ill consequences? Regards, Peter On Tue, Jun 18, 2019 at 5:32 AM Peter Levart <mailto:peter.lev...@gmail.com>> wrote: Hi, I recently stumbled on an exception thrown when deserializing stream produced on JDK 8 and read with JDK 11. I

Re: [PATCH] Use StringJoiner where appropriate in java.base

Hi, On 6/20/19 10:50 AM, Kasper Nielsen wrote: Hi, On Wed, 19 Jun 2019 at 14:12, Сергей Цыпанов wrote: Hello, in JDK code base we have many places (mainly in j.u.Arrays) where we convert array to String using verbose constructions with StringBuilder. As far as we have got StringJoiner for

Re: [PATCH] Use StringJoiner where appropriate in java.base

On 6/20/19 2:39 PM, Kasper Nielsen wrote: If you allowed a two-time pass of the primitive array you could actually create a version that only allocated the actual String and backing array. I tried implementing it https://gist.github.com/kaspernielsen/62e4eedffdb395228777925551a45e7f And got a

Re: [PATCH] Use StringJoiner where appropriate in java.base

On 6/21/19 9:41 AM, Andrew Haley wrote: On 6/20/19 9:31 PM, Peter Levart wrote: I would also add overflow checks when computing the length of resulting byte[]. First I would pre-check the length of passed in int[] array (it must be less than Integer.MAX_VALUE / 3), then checking for

Re: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access

Hi Mandy, On 7/2/19 7:20 PM, Mandy Chung wrote: Webrev updated: http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ I just skimmed across code and I think there's a little optimization possible in VerifyAccess:  224 // cross-module access  225 // 1. refc is i

Re: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access

8:24 AM, Peter Levart wrote: Hi Mandy, On 7/2/19 7:20 PM, Mandy Chung wrote: Webrev updated: http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ I just skimmed across code and I think there's a little optimization possible in VerifyAccess:  : ...instead of seting prevLookupModu

Re: EnumSet.class serialization broken - twice

, it would seem sensible to file a bug and start on a fix for the current release(s). Would you be able to do that? Again, thanks for finding this. s'marks On 6/18/19 7:32 AM, Peter Levart wrote: On 6/18/19 4:00 PM, Martin Buchholz wrote: Java Historian says: I was a reviewer for

Re: EnumSet.class serialization broken - twice

On 7/7/19 4:31 PM, Peter Levart wrote: On 6/29/19 2:00 AM, Stuart Marks wrote: Daniel Fuchs pointed me to a weird thing they had to do with the serialVersionUID in one of the JMX classes: https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management

Re: EnumSet.class serialization broken - twice - JDK-8227368

ngeset. webrev.02 is an attempt to sneak the change without being visible in the serialized-form.html. 2. Create draft CSR. I'll try that right away. Regards, Peter Thanks, s'marks [1] http://openjdk.java.net/jeps/3 [2] http://openjdk.java.net/projects/jdk/13/ On 7/7/

Re: EnumSet.class serialization broken - twice - JDK-8227368

On 7/9/19 1:57 AM, Stuart Marks wrote: 2. Create draft CSR. Created: https://bugs.openjdk.java.net/browse/JDK-8227432 Regards, Peter

Re: EnumSet.class serialization broken - twice - JDK-8227368

Hi Stuart, On 7/10/19 4:32 AM, Stuart Marks wrote: 1. New changeset with constant version of EnumSet.serialVersionUID. This is already in the webrev.01 changeset. webrev.02 is an attempt to sneak the change without being visible in the serialized-form.html. Ah. I skipped webrev.01 because I

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Hi, On 7/9/19 8:08 PM, Brian Burkhalter wrote: On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File method

Re: EnumSet.class serialization broken - twice - JDK-8227368

On 7/10/19 6:03 PM, Joe Darcy wrote: Hello, I'd advise against including at least part of the comment     // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely mapping from the SCM to the bug database to pro

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Hi, On 7/11/19 3:51 AM, Ivan Gerasimov wrote: On 7/10/19 5:17 PM, Brian Burkhalter wrote: I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. T

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another thing to consider (done in above webrev.02) is what to do with unbalanced cancelDeleteOnExit(). I think it is better to throw exception than to

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hi Jaikiran, On 7/12/19 9:07 AM, Jaikiran Pai wrote: The new updated webrev is at http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/ I don't know if there are any custom subclasses of Inflater/Deflater around and what they do, but hypothetically consider a subclass of Deflater simila

Re: RFR: 8227587: Add internal privileged System.loadLibrary

Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Hi Brian, On 7/26/19 12:42 AM, Brian Burkhalter wrote: On Jul 11, 2019, at 12:52 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another

Re: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

Hi, I think Daniel is talking about the "dispatch" semantics of unreflectSpecial here, right Daniel? The findSpecial / unreflectSpecial is a MethodHandle equivalent for bytecode instruction invokespecial (sans actual invoking). invokespecial is typically used for implementing the super.metho

Re: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

On 7/31/19 9:59 AM, Peter Levart wrote: Hi, I think Daniel is talking about the "dispatch" semantics of unreflectSpecial here, right Daniel? The findSpecial / unreflectSpecial is a MethodHandle equivalent for bytecode instruction invokespecial (sans actual invoking). invoke

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

Hi Mandy, Just a question... On 8/12/19 10:24 PM, Mandy Chung wrote: Having a second thought, I'm keeping @Stable bci field while zero indicates an invalid BCI that makes it obvious that this field will be updated.  VM will set StackFrameInfo::bci to value+1. http://cr.openjdk.java.net/~mchu

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

On 8/13/19 3:57 PM, Aleksey Shipilev wrote: On 8/13/19 3:33 AM, Mandy Chung wrote: On 8/12/19 5:13 PM, Frederic Parain wrote: 96 // VM adds 1 to the code index to StackFrameInfo::bci field such that 97 // zero (and negative values) indicates invalid BCI. So substract 1. http://cr.openjdk.jav

Re: 回复： 回复： what to do next to fix JDK-8230557. thanks

Hi 未来阳光, As David has pointed out, your proposed fix would break binary and source compatibility of BitSet.size() method, so it is not acceptable. BitSet API allows addressing individual bits using non-negative 'int' typed indexes (analogous to indexes of Java arrays). The range of indexes i

Re: Reply： what to do next to fix JDK-8230557. thanks

javadoc of the method described this corner case, he/she would understand? Regards, Peter Best, lamber-ken --?0?2?0?2-- *??????:*?0?2"Peter Levart"; *:*?0?22019??9??5??(??) 3:51 *??:*?0?2""<2217232...@qq.c

Re: Reply： what to do next to fix JDK-8230557. thanks

patibility problem, it's really a bug. User can't understand why the size method return a negative number.   Best, lamber-ken --  -- ??: "Peter Levart"??: ""<2217232...@qq.com&

  1   2   3   4   5   6   7   8   9   10   >