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 locat

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 appro

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 a

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 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.ensur

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 case

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: 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 ins

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: 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: 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: 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 6

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

to know if CDS is enabled or not. > > > (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 &q

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/ > > > Tes

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* tok

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 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 abou

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 b

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 t

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: 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: 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: 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 is

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

On Dec 5, 2019, at 2:39 PM, Vladimir Ivanov wrote: > > Regarding hotspot changes: > >> * ciField.cpp - this one is to trust final fields in the foreign memory >> access implementation (otherwise VM doesn't trust memory segment bounds) > > New packages aren't part of java.base. Considering 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 patter

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 co

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 similar.

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 surpris

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 >>> 33)

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: 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 meth

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 whether

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 allo

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 so

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 the

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: [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: 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 you

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. T

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

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 a

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

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- > n

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 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. https://www.pcg-ra

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 pa

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 f

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: 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 members

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: 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: 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 wi

Re: test/java/lang/invoke/InvokeGenericTest.java

On Sep 9, 2011, at 6:24 AM, Joe Darcy wrote: > So, I recommend the compile line for this test just be > > @compile InvokeGenericTest.java I agree. Thanks, Joe. -- John

review request (L): 7030453: JSR 292 ClassValue.get method is too slow

http://cr.openjdk.java.net/~jrose/7030453/webrev.00 The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. - It does not lock the root WeakHashMap, whi

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote: > FYI, There's one, java.lang.Integer's cache size is tunable via JVM command > line flag -XX:AutoBoxCacheMax, which in turn sets Java system property > "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. > But that's probab

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

On Sep 19, 2011, at 2:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 After some comments from David Holmes (thanks David!) I added internal comments about race conditions. I refreshed the webrev with the additional comments. I also changed one variable to

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

either under a per-class lock or during GC (nulling of weak references). Could I have a re-review? Thanks, -- John On Sep 20, 2011, at 4:10 PM, John Rose wrote: > On Sep 19, 2011, at 2:58 PM, John Rose wrote: > >> http://cr.openjdk.java.net/~jrose/7030453/webrev.00 > > A

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

On Dec 4, 2011, at 6:25 PM, David Holmes wrote: >>> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. >>> uses of class Class and all the classes not visible in those >>> environments when they are being used will be larger. >>> >>> Adding the fields may be the right time/space

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

On Dec 8, 2011, at 1:55 AM, Florian Weimer wrote: > * John Rose: > >> But, in order to respect the "general aim" you are mentioning, I have >> unhoisted one of the two words from the Class instance itself. This >> will cause a minor slowdown in JSR 29

Re: Code review request for javadoc problem in java.lang.invoke.MethodHandle

Yes. Thanks, Joe. -- John On Jan 9, 2012, at 6:17 PM, Joe Darcy wrote: > Please review the simple patch below to fix a javadoc problem in > java.lang.invoke.MethodHandle which stems from the arguments to the {@link} > javadoc tag being reversed.

7127687: MethodType leaks memory due to interning

http://cr.openjdk.java.net/~jrose/7127687/webrev.00/ 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. This is a point fix for JDK 8, and will (pending approval) also be back-ported to JDK 7u. — John Notes on process: This code is pa

7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited

http://cr.openjdk.java.net/~jrose/7087658/webrev.00/ 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited This is a point fix for JDK 8, and will (pending approval) also be back-ported to JDK 7u. — John Notes on process: This code is part of

Re: 7127687: MethodType leaks memory due to interning

ap directly with dummy value to >> simulate the set? Or wrap the WeakHashMap and synchronize the accessors to >> it? >> >> Sent from my phone >> >> On Mar 28, 2012 7:52 PM, "John Rose" wrote: >> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/ &

Re: 7127687: MethodType leaks memory due to interning

Jim's and Remi's comments on the problem are correct. In the current design, MH.type values must be interned. Comments on this design decision are interesting and useful, but this is not new ground; we went over it during the JDK 7 engineering and spec. work. It is likely we will revisit this

Re: 7127687: MethodType leaks memory due to interning

On Mar 28, 2012, at 7:50 PM, David Holmes wrote: > One query I have is whether, given its intended usage, this change might add > pressure to the reference processing subsystem? Not undue pressure, I hope. JSR 292 applications tend to converge rapidly on the number of distinct MethodTypes they

Re: 7127687: MethodType leaks memory due to interning

On Mar 28, 2012, at 5:42 PM, Vitaly Davidovich wrote: > I think you can use diamond generic inference when declaring the weak intern > set > Done; thanks. > Also any reason you didn't use WeakHashMap directly with dummy value to > simulate the set? Or wrap the WeakHashMap and synchronize the acc

Re: RFR (M): 8000989: smaller code changes to make future JSR 292 backports easier

Reviewed; good. This removes a significant source of friction (mismerges) for sharing changes between 7 and 8. — John On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000989 > > 8000989: smaller code changes to make future JSR 292 backports easier

hg: jdk7/tl/langtools: 6829189: Java programming with JSR 292 needs language support

Changeset: e2722bd43f3a Author:jrose Date: 2009-05-04 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e2722bd43f3a 6829189: Java programming with JSR 292 needs language support Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinPr

hg: jdk7/tl/jdk: 6829144: JSR 292 JVM features need a provisional Java API

Changeset: d201987cb76c Author:jrose Date: 2009-05-05 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d201987cb76c 6829144: JSR 292 JVM features need a provisional Java API Summary: JDK API and runtime (partial) for anonk, meth, indy Reviewed-by: mr ! make/docs/CORE_PKG

hg: jdk7/tl/jdk: 6838598: Legal notice repair: jdk/src/share/classes/sun/dyn/FilterGeneric.java

Changeset: bc1deb18bfb1 Author:jrose Date: 2009-08-06 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc1deb18bfb1 6838598: Legal notice repair: jdk/src/share/classes/sun/dyn/FilterGeneric.java Reviewed-by: xdono ! src/share/classes/sun/dyn/FilterGeneric.java

Re: JSR-292: Why not java.lang.dyn?

Thanks, Ben; well said. Putting a multi-language JVM feature under java.lang would be the wrong signal. OTOH, if we ever do a type "Dynamic" in the Java language (a la C#) that would belong in java.lang. But we are not, at present. (Despite an earlier blog proposal of mine!) JVM change

Re: JSR-292: Why not java.lang.dyn?

On Oct 9, 2009, at 7:36 PM, Stepan Koltsov wrote: John, how about multi-language java.lang.Class or java.lang.reflect.Field? How about it? I don't know how to answer this. -- John

Re: Please review java.util.jar.pack.* exceptions

On Nov 2, 2010, at 2:10 PM, Kumar Srinivasan wrote: > These are simple changes to the java.util.jar.pack: > * fixes JCK failures, specifically throwing unexpected exceptions > * minor fixes to the ClassFormatException > * added a new test to catch the JCK type failures up-front, which is >

Re: Please review java.util.jar.pack.* exceptions

On Nov 2, 2010, at 3:04 PM, Mike Duigou wrote: > - ClassReader.java: I think the change of the copyright date is incorrect. It > should be "2001, 2005, 2010" or "2001, 2005-2010". Standard Oracle copyright format has just the first and last year, no ranges and no other years. -- John

Re: review of simple pack200 fix

Reviewed, but the test case has an error; is it intentional? The CODE_ATTRIBUTE_PFX already ends with a dot '.', but you add another dot onto it. This will cause the declaration to be ineffectual, but in a non-obvious way. -- John On Dec 15, 2010, at 2:45 PM, Kumar Srinivasan wrote: > Hi, >

Re: JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names

On Jun 14, 2015, at 7:25 PM, David Holmes wrote: > > > Which reflection method are you referring to? Class.isAnonymousClass is > defined in terms of getSimpleName(): > > public boolean isAnonymousClass() { >return "".equals(getSimpleName()); > } That might be an issue here. Just as (Stri

Re: JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names

What I'm suggesting is that a BC generator might emit a zero length name for a non-anon class, leading to confusion when C.isAnon is called. – John > On Jun 16, 2015, at 5:09 AM, Vladimir Ivanov > wrote: > > John, > >> >> That might be an issue here. Just as (String)null and (String)"" ar

Re: JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names

On Jun 16, 2015, at 8:36 PM, David Holmes wrote: > > On 17/06/2015 8:39 AM, John Rose wrote: >> What I'm suggesting is that a BC generator might emit a zero length name for >> a non-anon class, leading to confusion when C.isAnon is called. > > Is a zero-length &qu

Re: JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names

On Jun 17, 2015, at 6:27 AM, Jochen Theodorou wrote: > > I did not expect that the outer class is not set for Local and Anonymous > classes. I would have thought that the enclosing method is the only > difference. A bit of history (which can be found in the JVMS itself): The EnclosingMethod

Re: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics

On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: > > As I understand it, part of this change is to split intrinsification into one > method that does the checks that then calls a second method which the VM may > intrinsify on the assumption all checks have been performed by the first > method.

Re: RFR 8135248: Add utility methods to check indexes and ranges

On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy wrote: > > Joining this thread late, I think the range checking methods would have a > happier life where they are more often found and used if the they live > somewhere other than the exception classes. > > The class java.util.Objects is not an ide

Re: RFR: JDK-8073187: Unexpected side effect in Pack200

Reviewed. Thank you, thank you, Joda-Time! — John On Sep 23, 2015, at 10:42 AM, Kumar Srinivasan wrote: > > Hi John, Sherman, > > I noticed a flaw in my fix, ie. in a section of the logic that is present > but unused, and reserved for future use, fixed it here anyway, for > correctness. >

Re: Spin Loop Hint support: Draft JEP proposal

On Oct 5, 2015, at 2:41 AM, Andrew Haley wrote: > > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > > I don't think this will work for ARM, which has a rather different > spinlock mecha

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 12:34 PM, fo...@univ-mlv.fr wrote: > > Anyway, in this case the problem is not just overloading, it is the mix of > overloading and type inference as you said. Add type erasure to this cocktail, and it's perfect. My antennae go up when the erased types overlap. When they do

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 8, 2015, at 2:42 PM, Roger Riggs wrote: > > Thanks for the insight, I hope it will help cut down on the thrashing. > > Isn't there a 4th form that throws missing? There are four forms in Optional, but one of them returns "void" and is not relevant here, IMO. The third one I pointed out

Re: Spin Loop Hint support: Draft JEP proposal

On Oct 8, 2015, at 12:39 AM, Gil Tene wrote: > > On the one hand: > > I like the idea of (an optional?) boolean parameter as a means of hinting at > the thing that may terminate the spin. It's probably much more general than > identifying a specific field or address. And it can be used to cove

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

:58 AM, Stephen Colebourne wrote: >> >>> On 9 October 2015 at 01:31, John Rose wrote: >>> This leads me to yet another bikeshed color, FWIW: >>> >>> - T requireNonNull(T) (cf. Optional::get) >>> - T requireNonNullElse(T,T) (cf. Optional::orElse) >

Re: Spin Loop Hint support: Draft JEP proposal

On Oct 8, 2015, at 11:56 PM, Gil Tene wrote: > >> >> On Oct 8, 2015, at 6:18 PM, John Rose wrote: >> >> On Oct 8, 2015, at 12:39 AM, Gil Tene wrote: > … If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8 > and SPARC M7 in a common us

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

On Oct 13, 2015, at 5:53 AM, Roger Riggs wrote: > > We don't have a good handle on when it is too early to use lambda except by > trial and error. > I think there are some improvements in the works so that some simple cases of > Lambda > can be used earlier and will see if they apply. Aleksey

Re: java.lang.reflect.Method.copyOf

On Oct 14, 2015, at 3:38 AM, Remi Forax wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too > encapsulate it in a non mutable class, if possible. OK, I'll bite. Here's a way to make Method its own non-mutable encapsulation, a la List::set or (future feature)

Re: RFC: draft API for JEP 269 Convenience Collection Factories

On Oct 14, 2015, at 10:56 AM, Kevin Bourrillion wrote: > Anyway, since we created these methods, they became an attractive nuisance, > and thousands of users reach for them who would have been better off in > every way using an immutable collection. Our fondest desire is to one day > be able to de

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

On Oct 18, 2015, at 1:49 AM, Jochen Theodorou wrote: > > * Invokedynamic (like invokeinterface and invokevirtual) does not like calls > with null as receiver :-) Jochen, you are one of the few people on the planet who was around JSR 292 when this *was* true. A very early draft of indy piggy-ba

Re: 8139891: Prepare Unsafe for true encapsulation

On Oct 22, 2015, at 7:28 AM, Chris Hegarty wrote: > > To this end I've put together a webrev containing the changes required > for step 1. It contains > - the intrinsic aliasing, > - the new internal Unsafe ( copy of sun.misc.Unsafe ), > - reverts sun.misc.Unsafe to, almost, its 1.8 API, >

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 9, 2015, at 8:46 AM, Roger Riggs wrote: > > The primary purpose of the existing 'requireNonNull' methods is to check for > null > and throw an exception. It is used for explicit testing and producing a > cogent exception. > Returning the value was a secondary benefit that allowed it to b

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 28, 2015, at 4:44 PM, John Rose wrote: > > As I said to you verbally, I'm not going to "die on this hill", but I do > think the name chosen has some disadvantages that could have been avoided > with a very slight mental shift about require. I.e., "

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 30, 2015, at 12:07 PM, Roger Riggs wrote: > > The longer names disambiguate adequately but add to the bulk of the code. > I see maturing systems end up being weighed down by the seemingly necessary > qualification. I agree with your statement of the problem, but (personally) am less repu

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 31, 2015, at 4:17 AM, Remi Forax wrote: > > Hi John, > I think there is a good reason to not reuse/enhance the requireNonNull prefix, > requireNonNull here is used to check a precondition or an invariant (a > contract), hence a name that starts with 'require' like in Eiffel. > (BTW re-rea

Re: Proposed API for JEP 259: Stack-Walking API

On Oct 31, 2015, at 11:50 AM, Remi Forax wrote: > > I think most of the runtime language developers, myself included will kill to > have this feature included into the JDK. > There are several features of dynamic languages that are currently hard to > implement like type specialization, stack r

Re: Proposed API for JEP 259: Stack-Walking API

On Oct 31, 2015, at 12:51 PM, John Rose wrote: > > modules, true polymorphism, value types, native interconnect P.S. Project refs: Jigsaw, Valhalla (List), Valhalla, Panama.

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

t; > what about: > T coalesceNull(T, T) > T coalesceNullGet(T, Supplier) On Oct 31, 2015, at 12:01 AM, John Rose wrote: > P.S. Going for a third way and starting a new family of methods ("notNull*", > "stopNull", etc.) would make me sad too, since we alre

  1   2   3   4   5   >