Re: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2]

> On May 4, 2022, at 8:29 PM, Xiaohong Gong wrote: > > The offset check could save the `checkMaskFromIndexSize` for cases that > offset are in the valid array bounds, which also improves the performance. > @rose00 , do you think this part of change is ok at least? That part is ok, yes. I

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v11]

On 21 Mar 2022, at 11:05, ExE Boss wrote: > Actually, this lookup object should probably be kept cached. +1. Good “cache”.

Re: RFR: JDK-8282798 java.lang.runtime.Carrier

On 8 Mar 2022, at 11:53, Jim Laskey wrote: >> I'm not sure I see anything here that would prevent the user from building a >> carrier and casting to Object[] ? > Clarified the comment. You are right. When I reworked the original code I > dropped the intermediate object. For my purposes, it was

Re: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes

It’s kind of sad that you have to do this by hand. The JVM should recognize that those back-to-back if statements (in the bytecode) can be combined into a non-branching O(1) test. One item on my (very long) wish list for the JVM is giving more comprehensive attention to the task of testing

Re: [jdk18] RFR: 8278607: Misc issues in foreign API javadoc

Nice work. I like this API a lot, and the doc is getting a good clear shine on it. The run-on sentence at the top of `Foreign addresses` needs a bit more polish. The long parenthetical comment still reads awkwardly. Maybe it doesn’t need parentheses any more, now that it’s part of (or all

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

So the purpose of TWR is to hold an object with a “close-debt” (debt of a future call to close) and pay it at the end of a block, sort of like C++ RAII (but also sort of not). But fluent syntaxes (which I like very much and hope to see more of in the future!) don’t play well with blocks, so if a

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

On Sep 13, 2021, at 10:24 AM, Vladimir Ivanov mailto:vliva...@openjdk.java.net>> wrote: BTW it can be improved even further by caching the immutable List view of parameters. I would go further: If I were writing MethodType.java today I would probably use List.of as the backing store for the

Re: better random numbers

On Sep 7, 2021, at 4:48 AM, Stefan Zobel mailto:splitera...@gmail.com>> wrote: That "influential researcher" is probably Sebastiano Vigna who has indeed harsh words on PCG: https://pcg.di.unimi.it/pcg.php That link can also be found on ONeill’s blog, along with her responses.

Re: better random numbers

On Sep 5, 2021, at 3:23 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: To increase throughput use vectors or generate more than one random sample per crank turn. But back to back aes steps are probably always twice the latency of a single wide multiply. So I think there might b

Re: better random numbers

On Sep 5, 2021, at 7:44 AM, Andrew Haley wrote: > > On 9/3/21 12:35 AM, John Rose wrote: > >> The reference I’d like to give here is to Dr. Melissa O’Neill’s >> website and articles: > > I'm quite sceptical. Anyone who says a (non-cryptographic) random- > number

Re: better random numbers

On Sep 2, 2021, at 4:35 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have

better random numbers

The state of the art for PRNGs (pseudo-random number generators) is much advanced since ju.Random was written. Surely at some point we will refresh our APIs that produce random numbers. In fact, we have added SplittableRandom, but I think the state of the art is farther enough along to consider

Re: [External] : Re: RFR: 8199318: add idempotent copy operation for Map.Entry

On Jun 3, 2021, at 3:17 PM, fo...@univ-mlv.fr<mailto:fo...@univ-mlv.fr> wrote: De: "John Rose" mailto:r.r...@oracle.com>> À: "Remi Forax" mailto:fo...@univ-mlv.fr>> Cc: "Peter Levart" mailto:peter.lev...@gmail.co

Re: RFR: 8199318: add idempotent copy operation for Map.Entry

On Jun 3, 2021, at 12:46 PM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: I kind of regret that the compiler does not provide automatically an implementation of compareTo if the record implements Comparable. People sucks at writing compareTo and the resulting bugs are hard to find/reproduce.

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On Jun 1, 2021, at 7:02 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: As Alan's archaeology discovered, this flag appears to be a leftover from the original implementation, and I could find no signs of its usage. Note to self and other reviewers of future versions of the JVMS: When

Re: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

On Apr 9, 2021, at 4:00 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: The MH combinator for lookupswitch can use a data-driven reverse lookup in a (frozen/stable) int[] array, using binary search. The bytecode emitter can render such a thing as an internal lookupswitch, if that

Re: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

On Apr 9, 2021, at 11:15 AM, fo...@univ-mlv.fr wrote: > > - Mail original - >> De: "John Rose" >> À: "Remi Forax" >> Cc: "Jorn Vernee" , "core-libs-dev" >> >> Envoyé: Vendredi 9 Avril 2021 20:01:18 >> O

Re: RFR: 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles

On Apr 9, 2021, at 9:55 AM, Remi Forax wrote: > > I think the combinator should be lookupswitch which is more general than > tableswitch with a special case when generating the bytecode to generate a > tableswitch instead of a lookupswitch if the indexes are subsequent. We can get there in

Re: RFR: 8180352: Add Stream.toList() method

I agree with Stuart and Brian that streams should be null-tolerant, including in this case. And of course I’m delighted to see an immutable container as the output to the utility method; I’m a fan of reduced-copy, race-free, bug-resistant algorithms you get from immutability. On Nov 3, 2020, at

Re: Possible subtle memory model error in ClassValue

On Aug 7, 2020, at 2:35 PM, John Rose wrote: > > (Here’s a tidbit of JMM politics: I once heard Doug Lea > considering whether maybe all fields should be treated > more like final fields. I don’t know if this is still a live > idea, but it would make this bug go way, s

Re: Possible subtle memory model error in ClassValue

On Aug 7, 2020, at 9:52 AM, Andrew Haley wrote: > > On 8/7/20 4:39 PM, David Lloyd wrote: > > > However, I'm wondering if this isn't a side effect of what appears > > to be an incorrect double-checked lock at lines 374-378 of > > ClassValue.java [1]. In order for the write to the non-volatile

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

On Jun 24, 2020, at 1:01 PM, John Rose wrote: > > What’s the performance model? It seems like the SpinedBuffer > implementation makes a worst-case assumption about the number > of pending values, that there will be many instead of zero or one. > > But I guess the pipeline s

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

I like this new API point a lot; it allows flexible, local, temporary control inversion in the context of one stream transform. What’s the performance model? It seems like the SpinedBuffer implementation makes a worst-case assumption about the number of pending values, that there will be many

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

On Jun 15, 2020, at 2:58 PM, Mandy Chung wrote: > > Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247444/webrev.00/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8247517 >

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

P.S.C. (post-send clarification) > The workflow would be: > > static final MethodHandle MH_ensureInit > = publicLookup().findVirtual(L…, “ensureInitialized”…); > By that I mean the workflow of the dynamic language implementor. And after hitting “send” I realized that optimizing that one

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On Jun 3, 2020, at 7:38 PM, Mandy Chung wrote: > > On 6/3/20 6:24 PM, John Rose wrote: >> On Jun 3, 2020, at 5:16 PM, Paul Sandoz > <mailto:paul.san...@oracle.com>> wrote: >>> >>> if (UNSAFE.shouldBeInitialized(cls)) { >>> UNSAFE.en

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On Jun 4, 2020, at 12:39 PM, mark.reinh...@oracle.com wrote: > > I agree that the `ensure` prefix is useful here. > > This method can only ensure that a class is initialized, so including > `Class` in the method name seems redundant. I’d go with the shorter > `ensureInitialized`. +1

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On Jun 3, 2020, at 5:16 PM, Paul Sandoz wrote: > > if (UNSAFE.shouldBeInitialized(cls)) { > UNSAFE.ensureClassInitialized(cls); > } > > Although it seems redundant to perform the check, suggesting it is not needed. It’s useful (IIRC) in this kind of code: MethodHandle mh = … something

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

Thanks, Paul! Talking with you about it helped me formulate my thoughts better. > On May 6, 2020, at 9:02 AM, Paul Sandoz wrote: > > Hi John, > > Thanks. For the benefit of others, John and I had a long chat about this and > Joe’s CSR comments. > > I have a better appreciation of your

Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests

On May 1, 2020, at 1:36 PM, Paul Sandoz wrote: > > Hi Remi, > > Thanks for the feedback. I am gonna need to go over this with John. Some > comments inline. > > >> On Apr 20, 2020, at 6:31 AM, Remi Forax wrote: >> >> Hi Paul, >> about the API part (not the implementation), >> there are

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

On Mar 20, 2020, at 10:49 AM, Jorn Vernee wrote: > > W.r.t. the source type being needed, I see the following 4 major cases: > > 1. src=Prim & dst=Prim -> cast convert. For boolean the least-significant-bit > is used to convert it to/from an integer type. > 2. src=Prim & dst=Ref -> box the

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

On Mar 18, 2020, at 3:01 PM, John Rose wrote: > > explicitCastArguments P.S. That method has an intentionally scary name, but behind the name, it’s just “asType, the JVM edition, plus narrowing primitive conversions”. The design center for asType is safe and sane conversions as a

Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

On Mar 18, 2020, at 8:54 AM, Brian Goetz wrote: > > Overall, the approach seems sound, and I like that you are introducing only > one new bootstrap that is usable for a range of things. A few comments and > questions. > > 1. Not sure the explicit source type carries its weight, but

Re: RFR: 8236641: Improve Set.of(...).iterator() warmup characteristics

> On Jan 15, 2020, at 5:46 PM, Stuart Marks wrote: > >  > >> On 1/13/20 8:03 AM, Claes Redestad wrote: >> we're doing plenty of iterations over Set.of() instances during >> bootstrap, which makes these operations show up prominently in >> startup profiles. This patch refactors a few hot

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 13, 2020, at 1:23 PM, Claes Redestad wrote: > > On 2020-01-13 22:18, Paul Sandoz wrote: >> That’s fine, it was really for informational purposes in case it comes in >> handy later on. > > Got it. > >> Speculating: if we had such a public method (with minimal dependencies) I >> suspect

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 13, 2020, at 11:49 AM, Paul Sandoz wrote: > > For information purposes: an alternative salt might be to use mix32 from > Splittable random: > > /** > * Returns the 32 high bits of Stafford variant 4 mix64 function as int. > */ > private static int mix32(long z) { >z = (z ^ (z >>>

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 11, 2020, at 3:59 AM, fo...@univ-mlv.fr wrote: > In my opinion, it's better to introduce an annotation @TrueScottmanFinal > instead of using @Stable in a way it was not designed to be used. And even better than that is fixing “final” so it’s really final. But @TrueScottmanFinal is

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 10, 2020, at 6:48 PM, Claes Redestad wrote: > > Yes. The XOR seems pointless with this approach, but some shifting > might be good. A single multiply mixes the bits of its inputs. If one input is “random” or “white” (50% 1’s irregularly spaced) then the output will probably look

Re: RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

On Jan 10, 2020, at 10:47 AM, Remi Forax wrote: > Seem to be a JIT bug to me, > the fields of Set12 are declared final not @Stable (even if the field storing > the instanceof of Set&2 itself is marked @Stable) so there is no reason not > not let the constant folding happen. It’s part of the

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

On Dec 9, 2019, at 10:16 AM, Peter Levart wrote: > What do you think? Might this be better performance wise? Yes, a fast positive proof that the access is allowed can be implemented along the lines you mention. The owner token could be overloaded in additional ways, if and when we do more

Re: RFR: JEP 359: Records (Preview) (full code)

On Dec 2, 2019, at 4:36 PM, David Holmes wrote: > > You are using CHECK_0 in RecordComponent::create but that method returns oop. > That seems wrong to me, but I see many other oop returning methods also use > CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) CHECK_NULL

Re: New candidate JEP: 370: Foreign-Memory Access API

On Dec 1, 2019, at 8:07 AM, David Lloyd wrote: > > Okay, anyway I'm glad that I'm not the first person to have thought of > these use cases. The API looks good! Thanks for reviewing and commenting! We need to “shake out” our designs exactly like that. — John

Re: New candidate JEP: 370: Foreign-Memory Access API

On Nov 29, 2019, at 4:24 AM, David Lloyd wrote: > > Makes sense, it's still early. But now the seed is planted. :) (It’s better documented. Most of the points made here were not new.)

Re: [14] RFR (S): 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance

Reviewed. > On Nov 29, 2019, at 7:55 AM, Vladimir Ivanov > wrote: > > http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8234923

Re: RFR: 8234335: Remove line break in class declaration in java.base

On Nov 19, 2019, at 4:00 AM, Lance Andersen wrote: > > Seems to be a “your milage varies”. I am fine with whatever the final > decision is. However, I do believe the comment above reads better and aligns > the methods better. FWIW, and as author of many of the lines being changed, I prefer

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 12:39 PM, Claes Redestad wrote: > Similar to other promising candidates like constant folding I think it > opens up some more general questions about observability. For example: > do we retain the original bytecode and mappings everything back to it > so that a debugger would

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 11:24 AM, Claes Redestad wrote: > >> Thanks for suggesting that Vladimir. That indeed is how the existing code >> is organized. > > Yes, not very startup friendly... ;-) No, but it’s maintainer friendly. We can walk and chew gum at the same time. Is it time to think

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 2:28 AM, Vladimir Ivanov mailto:vladimir.x.iva...@oracle.com>> wrote: > >private void emitPopInsn(BasicType type) { > mv.visitVarInsn(popInsnOpcode(type)); >} > Thanks for suggesting that Vladimir. That indeed is how the existing code is organized.

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

On Nov 5, 2019, at 10:17 AM, Remi Forax wrote: > > the rationale to add \ is well explain but why do you want to > introduce \s given we already have \u0020 ? Remi, you are an expert in the field and you got fooled! This is *exactly* why we need \s. The \u syntax is expanded *before*

Re: RFR: 8231355: Remove unused utility methods in libjava

On Oct 7, 2019, at 11:38 AM, Claes Redestad wrote: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8231355 > > Webrev: http://cr.openjdk.java.net/~redestad/8231355/open.00/ > > >

Re: RFR: JDK-8222373 Improve CDS performance for custom class loaders

> (We probably don't want a String type but a more abstract type. That way we > can evolve it to allow more complex representations, such as "read the > bytecode stream from here, but replace the method name "Foo" to "Bar", and > add a new integer field "

Re: RFR: 8215017: Improve String::equals warmup characteristics

On Dec 7, 2018, at 4:11 PM, Claes Redestad wrote: > > - Jim's proposal to use Arrays.equals is _interesting_: it improves > peak performance on some inputs but regress it on others. I'll defer > that to a future RFE as it needs a more thorough examination. > > - what we can do is simplify to

Re: RFR: 8221836: Avoid recalculating String.hash when zero

I agree that this is a good change, and you can use me as a reviewer. I disagree with Aleksey; it's a new technique but not complex to document or understand. The two state components are independent in their action; there is no race between their state changes. Meanwhile, there are two reasons

Re: RFR: 8221723: Avoid storing zero to String.hash

On Apr 1, 2019, at 12:50 PM, dean.l...@oracle.com wrote: > > Wouldn't it be better to write a non-0 value when the computed hash code is > 0, so we don't have to recompute it? Is there some advantage to writing 0 > instead of any other value, such as 1? Zero is the easiest sentinel value

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On Mar 7, 2019, at 4:33 AM, Tagir Valeev wrote: > > Hello, Remi! > > It actually works thanks to auto-boxing/unboxing. E.g. this > implementation works: > > static Iterable range(int from, int to) { > return () -> new PrimitiveIterator.OfInt() { >int cur = from; > >@Override >

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On Jan 11, 2019, at 4:53 PM, David Holmes wrote: > > I think there is a problem knowing when "access check" means just access > check and when it means "access check plus the special hack for setting final > fields". I'm not reading any final field semantics into the existing text, > because

Re: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

On Jan 9, 2019, at 2:04 PM, John Rose wrote: > > you might consider using > a little combinatorial code to generate bad and good class > names P.S. To motivate this suggestion a bit more: I found no problem with your manually-written test vectors of bad and good names, but

Re: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

Nice work. A couple of small points: A qualified class name is one that has a package prefix. So it is surprising that verifyUnqualifiedClassName allows a package prefix. Maybe it needs a different name. The testing looks adequate, but you might consider using a little combinatorial code to

Re: Feature suggestion: Add static equals methods to Float and Double

As I think you expect, isSubstitutible(x,y) will mean that x and y are equivalent for all practical purposes. One hard question is nailing down what are "all practical purposes". Certainly it's unfair to flip a coin while evaluating x and y separately, and claim that a distinct outcome proves a

Re: Extending Java Arrays/Collection Sort API

As you noticed, I jumped into the discussion mid-stream. I've been itching to get index-based sorting into JDK ever since I tried to code Burrows-Wheeler on the JDK and saw a huge footprint overhead due to the need for a proxy object for each byte position in the file to be compressed. Here are

Re: Extending Java Arrays/Collection Sort API

On Nov 27, 2018, at 9:49 AM, Brian Goetz wrote: > > Doug is right that there is an enormous potential list of sort methods, and > we can't include them all. But I do miss the ability to extract indexes > instead of sorting the array itself. Or, slightly more generally, sorting an int[] or

Re: RFR 8206955 MethodHandleProxies.asInterfaceInstance does not support default methods

On Jul 11, 2018, at 9:32 AM, Peter Levart wrote: > > Sorry Paul for hijacking the thread, just answering to Remi ... > > On 07/11/2018 05:31 PM, Remi Forax wrote: >> - Mail original - >>> De: "Peter Levart" >>> À: "Paul Sandoz" , "core-libs-dev" >>> >>> Envoyé: Mercredi 11 Juillet

Re: ImmutableCollections.MapN optimisation ?

On Jun 30, 2018, at 8:39 AM, Martin Buchholz wrote: > >> On Sat, Jun 30, 2018 at 3:54 AM, Remi Forax wrote: >> >> The other problem is more subtle, get() uses probe() and probe() uses an >> infinite loop and not a counted loop, the result is that c2 generates lot >> of assembly codes for

Re: RFR 8195650 Method references to VarHandle accessors

Good fix. Reviewed. > On Jun 25, 2018, at 9:11 AM, Paul Sandoz wrote: > > Gentle reminder. > > I would like to get this reviews and pushed before the ramp down phase one > kicks in this week. > > Paul. > >> On Jun 19, 2018, at 5:08 PM, Paul Sandoz wrote: >> >> Hi, >> >> Please review

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

Good; I like the care to distinguish "nested" classes (using the word "enclosing") from the newer concept of "nests" and "nestmates", as well as the careful framing of how stuff bubbles up from the classfile. (Kudos to Alex!) — John On Jun 19, 2018, at 9:56 PM, David Holmes wrote: > > Some

Re: BiCollector

On Jun 18, 2018, at 2:29 PM, Brian Goetz wrote: > > "bisecting" sounds like it sends half the elements to one collector and half > to the other … The main bisection or splitting operation that's relevant to a stream is what a spliterator does, so this is a concern. Nobody has mentioned

Re: The store for byte strings

On Jun 9, 2018, at 12:18 PM, Xueming Shen wrote: > > Ideally I would assume we would want to have a utf-8 internal storage for > String, even in theory utf8 is supposed to be used externally and utf16 > to be the internal one. Separately from my point about ByteSequence, I agree that "doubling

Re: The store for byte strings

I'm glad to see you are thinking about this, Florian. You appear to be aiming at a way to compactly store and manipulate series of octets (in an arbitrary encoding) with an emphasis on using those octets to represent strings, in the usual sense of character sequences. Would you agree that this

Re: RFR: CSR JDK-8203630 Add instance method equivalents for String::format

On May 23, 2018, at 2:07 PM, Remi Forax wrote: > > Please, don't call it format too ! > Trying to do a :: on a class with instance methods and static methods with > the same doesn't work well, and format() being a varargs will not help. > > I see several reasons to not

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

On May 21, 2018, at 5:48 PM, David Holmes wrote: > > * A nest is a set of classes and interfaces (nestmates) that > * form an access control context in which each nestmate has access to the > * private members of the other nestmates. > * The nest host is the class or

Re: RFR: jsr166 jdk integration 2018-05

On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: > > I like thinking of ArrayList as just an optimized HashMap, Lua-style, and > HashMap.replaceAll also does not increment modCount, supporting our > "structural modification" position. > > The thing that bothers me most

Re: RFR(M): 8202745: Remove hyphens from "out-of-bounds".

On May 7, 2018, at 2:43 PM, David Holmes wrote: > > The grammar can be a bit subtle here. IIUC we would say: > > "Index %d out of bounds for length %d" > > but if we turn it around we'd say: > > "out-of-bounds index %d for length %d" +1 And the hyphens could be

Re: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

Here's another potential stacking: Define an interface ByteSequence, similar to CharSequence, as a zero-copy reference to some stored bytes somewhere. (Give it a long length.) Define bulk methods on it like hash and mismatch and transferTo. Then make File and ByteBuffer implement it. Deal with

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

On Apr 30, 2018, at 4:47 PM, Joe Wang wrote: > > Are there real-life use cases? It may be useful for example to check if the > files have the same header. After equality comparison, lexical comparison is a key use case. By allowing the user to interpret the data around

Re: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled

On Apr 25, 2018, at 12:07 PM, Martin Buchholz wrote: > > For bonus points, only create the shutdown hook the first time readPassword > is called with echo on to appease the Emacs shell users with pitchforks. FTR, I use Emacs shell for everything except jshell, and have to

Re: RFR 8199875: Require first parameter type of a condy bootstrap to be Lookup

Reviewed; it's good. The javadoc text doesn't need to predict the future; it just needs to document the present specification. So the sentence that begins "This constraint allows for the future possibility…" is not really necessary. It's certainly not normative. — John On Apr 6, 2018, at

Re: RFR: Some patches for sherman

In short, Peter is right; sorry Martin. That annotation is private to java.base and not currently a feature that has support beyond its uses in java.base. The purpose of @Stable is to allow lazily evaluated variables (both static and non-static) to be constant-folded like static finals. In the

Re: Raw String Literal Library Support

On Mar 14, 2018, at 6:11 AM, Peter Levart wrote: > > Pattern.compile(string) > > Now if 'string' above is a constant, '~ string' could be a constant too. > Combined with raw string literals, Pattern constants could be very compact. > > > What do you think? There's no

Re: Raw String Literal Library Support

On Mar 13, 2018, at 6:47 AM, Jim Laskey wrote: > > … > A. Line support. > > public Stream lines() > Suggest factoring this as: public Stream splits(String regex) { } public Stream lines() { return splits(`\n|\r\n?`); } The reason is that "splits" is useful with

Re: Raw String Literal Library Support

On Mar 13, 2018, at 11:30 AM, Volker Simonis wrote: > > Would it make sense to have a versions of "lines(LINE_TERM lt)" which > take a single, concrete form of line terminator? (Regular expressions for the win!)

Re: Raw String Literal Library Support

On Mar 13, 2018, at 11:42 AM, Remi Forax wrote: > > it already exists :) > Stream stream = Pattern.compile("\n|\r\n|\r").splitAsStream(string); You want ` instead of " there! Somebody added support recently for `\R`, which is a more unicode-flavored version of your pattern

Re: RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

Looks good. On Feb 27, 2018, at 8:42 AM, Paul Sandoz wrote: > > > >> On Feb 27, 2018, at 7:42 AM, Claes Redestad >> wrote: >> >> Hi, >> >> when generating LF classes with InvokerBytecodeGenerator, almost 5% of >> executed code is

Re: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity

On Feb 1, 2018, at 12:45 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > >> On Jan 31, 2018, at 3:49 PM, John Rose <john.r.r...@oracle.com> wrote: >> >> On second thought, you should also use invokeWithArguments to support jumbo >> arities.

Re: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity

On second thought, you should also use invokeWithArguments to support jumbo arities. This tricky idiom should be put into a utility method, package private for starters. A version of it also appears in BSM invocation code. > On Jan 31, 2018, at 3:23 PM, John Rose <john.r.r...@orac

Re: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity

If you remove the old asType call it’s good! > On Jan 31, 2018, at 3:15 PM, Paul Sandoz wrote: > > Hi, > > Please review this fix to the invoke BSM so that it preserves variable arity, > if any: > > >

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On Jan 29, 2018, at 4:00 PM, John Rose <john.r.r...@oracle.com> wrote: > > Then the various array-backed implementations > (and their sublists) would simply override their respective > stream views. BTW, this notion is more general than you might think. It applies to

Re: [PATCH] Inefficient ArrayList.subList().toArray()

Reviewed (officially). This is a good point-fix. — John P.S. I still think we have some tech. debt to discharge in finding a way to generically provide zero-copy access to array data, across interoperating collections APIs. If we got the deeper, more general answer right, we would be able to

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On Jan 25, 2018, at 2:02 PM, Сергей Цыпанов wrote: > > +return (T[]) Arrays.copyOfRange(root.elementData, offset, > size, a.getClass()); Giving this a quick glance: I think you may want s/size/offset+size/. There should be calls to

Re: [11] RFR JDK-8194554: filterArguments runs multiple filters in the wrong order

>> That's a good idea (I should have started with a simpler test). >> >> Updated: >> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8194554/webrev.01/ >> Thanks, Mandy and Paul. Reviewed. — John

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

That looks good to me. Vladimir Ivanov should take a look. Christmas vacation is just ending in Russia, so he should be around soon. On Jan 8, 2018, at 6:41 PM, Martin Buchholz wrote: > > No takers? ... let's try again. Despite uniform failure to reproduce this > except

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 22, 2017, at 11:57 AM, John Rose <john.r.r...@oracle.com> wrote: > > On Dec 21, 2017, at 5:31 PM, Stuart Marks <stuart.ma...@oracle.com> wrote: >> >> I'd like a blanket assertion that view collections are not serializable. >> >> Now this shoul

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 21, 2017, at 5:31 PM, Stuart Marks wrote: > > I'd like a blanket assertion that view collections are not serializable. > > Now this should be considered distinct from whether view collections are > value-based; I'm fine with considering view collections to be

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On Dec 20, 2017, at 3:45 AM, Peter Levart wrote: > > allocation of ArrayList could be avoided. Imagine a use case where lots of > small files are read into byte[] arrays +1 I was going to write a similar suggestion; thanks for sending it out. These sorts of things

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

On Dec 12, 2017, at 5:24 PM, David Holmes wrote: > > as per getByteCodeIndex() it needs to be able to store "-1" to indicate > no-bci? Yes, that's the essential requirement, to encode a "none" value. FWIW, one natural way to do that here would be to make the int field

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On Dec 11, 2017, at 6:00 PM, John Rose <john.r.r...@oracle.com> wrote: > > class Arrays { > // people who want x.toArray can also use x.copy(Arrays::make): > static T[] make(SequenceContent<T,T[]> content) { … } Correction; that one needs an array type to know what to

Re: [10] RFR 8187254 Rearrange private MethodType constructors

Good. On Dec 11, 2017, at 2:02 PM, Paul Sandoz wrote: > > Please review this small fix to collapse the two private constructors of > MethodType into one. This consolidates all the copying/validation logic into > the factory method makeImpl.

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On Dec 7, 2017, at 5:03 PM, Martin Buchholz wrote: > > (I'm still trying to love this new API) > > The changes to the jsr166 tck are fine. > > I'm not convinced that the new implementation for ArrayList is progress. > The current implementation of toArray(T[]) does > >

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 8, 2017, at 6:19 PM, Claes Redestad wrote: > > I think one can interpret the @implSpec in AbstracList::subList to suggest > that the implementation retrieved will subclass AbstractList, which implies > it's *not* Serializable. As we move away from AbstractList

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 8, 2017, at 4:45 PM, John Rose <john.r.r...@oracle.com> wrote: > > Can anyone point out a reason why the value based > lists of List.of() should serialize while the value based > lists of List.of().subList() should not? Or is there some > reason we should not all

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

+1 (there should) On Dec 8, 2017, at 9:44 AM, Martin Buchholz wrote: > > Should there be changes to general purpose collection testing classes like > test/jdk/java/util/concurrent/tck/CollectionTest.java > test/jdk/java/util/Collection/MOAT.java > that would have caught

  1   2   3   4   >