Re: IllegalStateException in CharsetDecoder when inspecting JarFile contents on Java 15

ile a bug and take a > > look. > > > > /Claes > > > > On 2021-01-19 20:19, Vitaly Davidovich wrote: > >> Hi all, > >> > >> I observed the following stacktrace when inspecting a JarFile's contents > >> using a parallel stream (i.e

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

I would also expect clone to run a bit faster than copy constructor, if for nothing else than clone not executing any constructor; this perf diff would probably be more noticeable in interpreter as compiler may inline constructor. In addition, I'd also think that clone can basically be equivalent

Re: JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

Rémi Forax wrote: > On 01/30/2012 10:17 PM, Vitaly Davidovich wrote: > >> I would also expect clone to run a bit faster than copy constructor, if >> for >> nothing else than clone not executing any constructor; this perf diff >> would >> probably be more no

Re: Need reviewer: JDK 8 CR for Support Integer overflow

; The value -x is needed anyway since it's the return value. But a more > important reason why my idea is a bad one is that the condition is > true for x == 0! Writing x == -x && x != 0 is definitely not an > improvement. > > Éamonn > > > On 3 February 2012 10:22

Re: Need reviewer: JDK 8 CR for Support Integer overflow

x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a constant whereas the latter requires negating x (that's a dependency too), tying up a register to store the negation, and then doing the cmp. Sent from my phone On Feb 3, 2012 12:53 PM, "Eamonn McManus" wrote: > My init

Re: cost of Java "assert" when disabled?

Sent from my phone On Feb 16, 2012 6:16 PM, "David Holmes" wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > >> Don't want to sidetrack this thread but I reall

Re: java.io.File field "path" is not declared final

Why not just have one putObjectOrdered for the path as the last action in deserialization? I think a volatile store is overkill here. Sent from my phone On Feb 17, 2012 7:54 AM, "David Holmes" wrote: > On 17/02/2012 10:41 PM, Alan Bateman wrote: > >> On 17/02/2012 12:37, David Holmes wrote: >> >

Re: java.io.File field "path" is not declared final

Actually, I don't even think a volatile write helps here - it doesn't prevent a subsequent (data racy) publishing of the instance from moving before the volatile write. It'll probably work in practice, but isn't JMM compliant, so to speak. Sent from my phone On Feb 17, 2

Re: java.io.File field "path" is not declared final

Nevermind, the storestore barrier won't be in the right place. Where's that Fences API? :) Sent from my phone On Feb 17, 2012 8:55 AM, "Vitaly Davidovich" wrote: > Why not just have one putObjectOrdered for the path as the last action in > deserialization? I think a

Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale

Hi Frederic, Just curious - why are you checking string equality via compareTo() instead of equals()? Thanks Sent from my phone On Feb 23, 2012 10:37 AM, "Frederic Parain" wrote: > This a simple fix to solve CR 6988220: > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220

java.util.UUID.fromString performance

Hi all, I noticed that this method could be made a bit more performant by: 1) creating a statically initialized Pattern for "-" and then calling split() on that. Currently the method calls name.split() which compiles the pattern on each invocation. 2) use Long.parseLong() instead of Long.decode

Re: java.util.UUID.fromString performance

n Feb 28, 2012 9:37 AM, "Alan Bateman" wrote: > On 28/02/2012 14:26, Vitaly Davidovich wrote: > >> Hi all, >> >> I noticed that this method could be made a bit more performant by: >> >> 1) creating a statically initialized Pattern for "-" and

Re: java.util.UUID.fromString performance

mit a webrev patch with > both changes along with your microbenchmark test. Once the change is > incorporated in the jdk8 mainline the sustaining teams can evaluate it for > backporting to jdk 7 and 6. > > Mike > > On Feb 28 2012, at 06:26 , Vitaly Davidovich wrote: > > >

Re: RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result

I thought so too initially but that's optimizing for empty or singleton collections which probably are an edge case? Adding a branch, polymorphic method call, and increasing bytecode size may not be worth it. Sent from my phone On Mar 1, 2012 3:25 PM, "Rémi Forax" wrote: > On 03/01/2012 08:50 PM

Re: RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result

Also some collections may not have an O(1) size(). Sent from my phone On Mar 1, 2012 3:52 PM, "Vitaly Davidovich" wrote: > I thought so too initially but that's optimizing for empty or singleton > collections which probably are an edge case? Adding a branch, polymorph

Re: RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result

+1. A no-op sort() on an emptyList or singletonList() behaves in an intuitive manner, IMHO. If the concern is that sort() will hide user bugs, well my answer would be that sort()'s job is just that: sort the collection -- it's not a defense mechanism for catching unrelated user bugs. On Thu, Ma

Re: 7127687: MethodType leaks memory due to interning

Hi John, I think you can use diamond generic inference when declaring the weak intern set. Also any reason you didn't use WeakHashMap 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

Re: 7127687: MethodType leaks memory due to interning

; Sent from my iPhone 4 > > On 2012-03-28, at 9:42 PM, Vitaly Davidovich wrote: > > Hi John, > > I think you can use diamond generic inference when declaring the weak > intern set. > > Also any reason you didn't use WeakHashMap directly with dummy value to > simula

Re: 7127687: MethodType leaks memory due to interning

> > I tried using WeakHashMap initially but then realized the implications. > WeakHashSet is useless, since it uses WeakHashMap, making it not weak at > all. > > This fix has been well tested, as it is integrated in our test system (4 > times a day on several different platfor

Re: 7127687: MethodType leaks memory due to interning

ashMap/WeakHashSet. Maybe WeakInterner > may be more appropriate. > > "although possibly different instance" is THE thing. We only want one > instance of each MethodType in the environment so that MethodType.equals is > a simple == test. > > On 2012-03-29, at 9:

Re: Draft j.u.c JEP

I would prefer that Fences was a JDK API rather than being "hidden" inside a VM one. It is low level but there's nothing unsafe about it in the sense of other APIs inside the Unsafe class, and it would be undesirable if one had to jump through hoops to get access to it like we do for Unsafe today

Re: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please

Hi Kumar, Based on the discussion, should it check for a (retval != JNI_OK || vm == null) instead of (retval < 0 || vm == null)? Regards, Vitaly Sent from my phone On May 7, 2012 4:23 PM, "Kumar Srinivasan" wrote: > Hi, > > Please review > > http://cr.openjdk.java.net/~**ksrini/7166955

Re: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please

I agree it doesn't really matter; using JNI_OK is arguably slightly better as it (1) doesn't assume anything about what non negative value it'll assume and (2) uses the constant defined specifically for this, but I agree it's insignificant in the grand scheme of things. Cheers Sent from my phone

Re: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

That's a bit odd as I thought the Klass object in the VM stored something like 7 supers, which includes interfaces (if I'm not mistaken). I know that instanceof checks against final classes are optimized into a simple cmp against an address, but I'm surprised that a check against an interface for

Re: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

t; > On Fri, May 25, 2012 at 10:12 AM, Mike Duigou wrote: > >> >> On May 24 2012, at 16:32 , Vitaly Davidovich wrote: >> >> > That's a bit odd as I thought the Klass object in the VM stored >> something like 7 supers, which includes interfaces (if I'

Re: Re : Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields]

This is specific to private fields in inner classes - java allows access to them from the outer class, but the JVM doesn't so javac generates synthetic accessor methods for them. Don't think it's a problem for JIT compiler though as it should inline them. Sent from my phone On May 25, 2012 5:23 P

Re: Re : Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields]

In case it's not clear, by JVM not allowing them I simply mean that it doesn't know about nested classes (not a first class concept), so since it's emulated by javac, javac creates these package private synthetic accessors. Sent from my phone On May 25, 2012 5:50 PM, "Vital

Re: Re : Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields]

; wrote: > On 05/25/2012 11:50 PM, Vitaly Davidovich wrote: > >> This is specific to private fields in inner classes - >> > > and methods and constructors > > java allows access to >> them from the outer class, but the JVM doesn't so javac generates >&g

Re: Re : Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields]

5, 2012 6:06 PM, "Rémi Forax" wrote: > On 05/25/2012 11:55 PM, Vitaly Davidovich wrote: > >> In case it's not clear, by JVM not allowing them I simply mean that it >> doesn't know about nested classes (not a first class concept), so since >> it's

Re: Re : Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields]

associated with them. Anyway, we're in agreement. :) Sent from my phone On May 25, 2012 6:18 PM, "Rémi Forax" wrote: > On 05/26/2012 12:09 AM, Vitaly Davidovich wrote: > >> >> Yes, methods/constructors as well - I should've pointed that out but only >>

Re: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String

FWIW, the few times I "needed" a repeat operation it's always been with a char, not a string. I think a common use case for this to create some layout in the printed string, such as adding a separator (e.g. "*", "-", etc) or adding white space padding (could also be something like

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

In response to a similar question a few months ago, Tom Rodriguez mentioned that c2 is not really susceptible to these redundant stores when making inlining decisions. I guess c1 (and interpreter of course) might be but then in those cases one's not getting max optimization anyway. John Rose ment

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

. Thanks Sent from my phone On Aug 24, 2012 9:02 AM, "Doug Lea" wrote: > Vitaly Davidovich wrote: > > So it sounds like avoiding these locals is basically trying to work >> around current compiler limitations, rather than something more fundamental. >> > &g

RE: why LinkedBlockingQueue#poll(int, TimeUnit) is hanging up?

To eliminate one specific possibility/bug, see if it repros with -XX:+UseMembar Sent from my phone On Sep 10, 2012 2:00 PM, "Iris Clark" wrote: > Forwarding to core-libs-dev. > > iris > > -Original Message- > From: Yegor Bugayenko [mailto:[email protected]] > Sent: Monday, Septembe

Re: why LinkedBlockingQueue#poll(int, TimeUnit) is hanging up?

Symptoms here are eerily similar to http://bugs.sun.com/view_bug.do?bug_id=6822370, hence I'm curious if it still repros with -XX:+UseMembar. Sent from my phone On Sep 10, 2012 8:45 PM, "David Holmes" wrote: > This kind of issue is better discussed, at least initially on Doug Lea's > concurrency

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

Jim, how about an assert with Thread.holdsLock() work for tests? Sent from my phone On Oct 2, 2012 9:34 AM, "Jim Gish" wrote: > Ok -- I have some comments prepared, so I'll wrap it up with that. > However, I am curious about suggested approaches for tests to ensure that > methods are synchronizi

Re: Fwd: AutoCloseable blocking or not

Personally, if an API just had close() I'd expect that when it returns the semantics of close are done. If the resource may take a while to close (whatever "a while" means in the context) I'd expect to have a closeAsync() (or something akin to that) that returns a future or takes a callback to exe

Re: StackTraceElement question

FWIW, .Net's equivalent to this doesn't return the class but exposes the MethodBase (java.lang.reflect.Method analogous) that owns the frame and one can get the defining class from that. Sent from my phone On Oct 8, 2012 10:35 AM, "Krystal Mok" wrote: > On Mon, Oct 8, 2012 at 10:25 PM, Christos

Re: Review CR #6611830: UUID thread-safety and performance improvements

Hi Mike, Unless i missed something, seems like the race can be fixed via same mechanics as String.hashcode; ie since all of the cached values are based on least and most significant bits which are final and the long members are volatile, using lazy evaluation with use of temps should yield the sam

Re: Review CR #6611830: UUID thread-safety and performance improvements

resending as I just realized I replied only to Brian. On Wed, Feb 23, 2011 at 12:19 AM, Vitaly Davidovich wrote: > Hi David/Brian, > > Yes, I meant whether the "entire" string.hashcode technique can be used, > including the default zero values. I agree on the initial -1

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

I must say it's a bit odd seeing an atomic field in an otherwise non-threadsafe class. To be pedantic, what's to prevent close (being called on a different thread from one that allocated the filtered output stream) from seeing inconsistent out field values (assume the stream was published unsafely

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Extending coverage of synchronicity problems to the rest of the class could be addressed in the context of another issue, yet to be filed, should this be deemed desirable. On Jun 24, 2015, at 5:34 PM, Vitaly Davidovich wrote: > I must say it's a bit odd seeing an atomic field in an otherw

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

turn; > 161 closed = true; > On Jun 24, 2015, at 6:16 PM, Vitaly Davidovich wrote: > > Sorry, where was the double checked locking in FilterOutputStream? I see > a plain "closed" boolean before. > > > > sent from my phone > > > > The intent

Re: StackOverflowError on HashMap.hashCode() due to self reference

IMHO, this doesn't warrant any special wording -- if someone hits this, I think it's fairly evident what the issue is. You can get the same problem with adding an ArrayList to itself and calling hashCode(). On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok wrote: > Hi everyone, > > I'm sure somebody

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

You'd want to then MapViewOfFileEx later using VirtualAllocEx reservation (to change the mapping), but I don't think MapViewOfFileEx allows specifying a base address that is reserved via VirtualAllocEx. On Tue, Sep 8, 2015 at 3:41 PM, Mike Hearn wrote: > Sorry, seems I must have hit send without

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

The safepoint happiness is unfortunately a separate issue in Hotspot, and it's definitely not happy times :). Part of the problem is the piggybacking of various operations on a safepoint - the safepoint time alone (not counting GC, say) keeps growing. You probably could piggyback this on Guarante

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

avid M. Lloyd wrote: > > On 09/10/2015 08:22 AM, Andrew Haley wrote: > >> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote: > >> > >>> The safepoint happiness is unfortunately a separate issue in > >>> Hotspot, and it's definitely not happy t

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

aley" wrote: > On 09/10/2015 12:25 PM, Vitaly Davidovich wrote: > > > The safepoint happiness is unfortunately a separate issue in > > Hotspot, and it's definitely not happy times :). Part of the > > problem is the piggybacking of various operations on a safep

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

: > On 09/10/2015 03:13 PM, Vitaly Davidovich wrote: > > > So what happens after safepoint is done and thread accesses the > > mapping (it would need protection NONE, not just write)? JVM is then > > going to trap the signal and convert to an exception? > > One of us

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote: > > Yes, so what happens when that guard page is accessed by a thread after > safepoint? > > A segfault and a null pointer exception. > > Andrew. > >

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

09/10/2015 09:35 AM, Vitaly Davidovich wrote: > >> Well, you'd probably want something other than NPE here -- perhaps a new >> dedicated exception to signal this condition. And this means the segfault >> handling now needs to know about this type of situation as well, rather

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

lthough that increases the complexity of the solution somewhat. On Thu, Sep 10, 2015 at 10:45 AM, Andrew Haley wrote: > On 09/10/2015 03:35 PM, Vitaly Davidovich wrote: > > > Well, you'd probably want something other than NPE here -- perhaps a > > new dedicated exception t

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

To be fair, this one sounds like it would initiate an orderly/graceful shutdown whereas a bug in JNI/Unsafe kills it almost instantly (modulo error reporting/core dumping) :) On Thu, Sep 10, 2015 at 2:47 PM, Dawid Weiss wrote: > > there're already ways to bring down the JVM (e.g. JNI, existing U

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

tion(); > return a + (i << 0); > } > > > > That's not all that has to be done of course. There would still have to be > a wait for safe-point to return before unmapping. This is just a > demonstration that maybe guarding mapping with protection is not need

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

vid Holmes" wrote: > On 11/09/2015 6:37 PM, Andrew Haley wrote: > >> On 09/11/2015 07:15 AM, David Holmes wrote: >> >>> On 11/09/2015 12:56 AM, Vitaly Davidovich wrote: >>> >>>> >>>>> Sure, if you like, but t

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

So is this saying that enhancing Hotspot JIT to detect range check patterns better is too much work? On the surface, it seems odd to need intrinsics, a functional interface, and fixed template for getting efficient range checks. Also, this may end up with similar profile pollution problems as thin

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

if it is intrisified > because > the code that generate the IR node graph can not use the profiling info of > the interpreter > thus the assembly code generated will always bail out if the index is > wrong. > > Rémi > > - Mail original - > > De: "Vital

Re: Optional used as method argument?

Optional really needs value types to be used more widely in these contexts. Given a language that doesn't have non-null baked into the type system or language, the next best thing would be a library solution. It's much better to indicate nullability in the parameter type rather than javadoc; the

Re: Spin Loop Hint support: Draft JEP proposal

Although spin lock would also benefit from this, the spinning is also done when doing message hand off between threads. It's common in low latency space to monopolize the cpu(s) and spin wait for data to arrive; this is to avoid parking the thread in kernel when you know arrival rate is very high.

Re: Spin Loop Hint support: Draft JEP proposal

I agree with David that it should be static though; it doesn't really make sense to be instance. sent from my phone On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" wrote: > Hi Doug, > > Brilliant thought, absolutely…. so obvious that it is completely hidden in > plain sight. In the past dumping these

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

I think this issue is specific to References since they're not treated as strong roots by GC and therefore do not participate in strong reachability graphs. On Wed, Oct 21, 2015 at 10:52 AM, Roger Riggs wrote: > Hi Andrew, > > So then is is correct to conclude that the gc does examine fields in

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

> > queue is marked volatile, so a simple reordering of the lines should be > just as effective: > Reference(T referent, ReferenceQueue queue) { > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > this.referent = referent; > } Won't mean much since the plai

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

> > Yes, if runtime stripes that instance before it is exposed anywhere > (e.g. scalarizes the weakref) If you look at escape analysis code ( http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803), Reference and subclasses get special treatment and ma

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

, I think arguments are > also kept on the stack and are therefore reachable at least until the end > of constructor. How probable is a safepoint between those two statements in > JIT-ed code? Maybe the Reference constructor itself is not in danger > because it is very trivial, but wha

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/5d13c9b094c4/src/share/vm/opto/library_call.cpp#l5629 C2 does inline it but intentionally forbids commoning out reads of Reference.get. However, this needs a real fix not a hack. sent from my phone On Oct 26, 2015 3:22 PM, "Justin Sampson" wr

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

How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. sent from my phone On Oct 31, 2015 3:45 PM, "John Rose" wrote: > 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 requireNonNu

Re: Optional.or() doesn't use a wildcard in its signature

This would require Supplier>, not Supplier>. sent from my phone On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: > If this instance is an Optional , passing an > Optional will fail to compile. > > Regards, > Michael > On 31 Oct 2015 11:21, "Stefan Zobel" wrote: > > > 2015-10-31 19:11 GMT+0

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

yone. Personally, I would fall > for: > > > T checkNull(T, T) > > TcheckNullElseGet(T, Supplier) > > The trick is to remember that "check" can be a synonym for "deter" as in > hockey. > The treat is that "checkNull" reminds every Java pr

Re: Optional.or() doesn't use a wildcard in its signature

f Optional. > So even if the signature were > > public Optional or(Supplier> supplier) > > we'd have to upcast the result of supplier.get() to Optional > which appears to be wrong from a type perspective. > > > Regards, > Stefan > > > > > > > On 3

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Apps that are sensitive to allocations will not use these convenience methods in hot paths, varargs or fixed arg. They're likely to use them when the extra allocation wouldn't matter (non sensitive code, startup/initialization, etc). sent from my phone On Nov 6, 2015 1:29 PM, "Stuart Marks" wrot

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

+1000 sent from my phone On Nov 9, 2015 7:49 AM, "Doug Lea" wrote: > On 11/09/2015 05:43 AM, Chris Hegarty wrote: > >> On 02/11/15 10:45, Aleksey Shipilev wrote: >> >>> On 11/02/2015 02:56 AM, Chris Hegarty wrote: >>> In line with the intended location for other VM annotations, see 813

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

There's another issue with relying on EA, which is EA will not analyze methods above a certain (bytecode) size; IIRC it's around 150. So if this method gets inlined into a bulky method, the varargs will not be eliminated, I believe. I don't think it's a problem for this API for the reasons I ment

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

Chris, I don't know if you (and others) prefer to discuss this here or start a separate thread, but let me just throw in my vote (again) for including @Contended in SE. I'm sure you're well aware of the ugly hacks people resort to for achieving this currently. False sharing is an effect that we

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

Hi Paul, > There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot > code. Hence why it has remained internal so far. What overflow? OOM of the heap? How is that a "very valid" concern? Why would it be us

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

ion) will help in shaking out bugs/exploits. On Thu, Nov 12, 2015 at 9:00 AM, Paul Sandoz wrote: > > > On 12 Nov 2015, at 14:48, Vitaly Davidovich wrote: > > > > Hi Paul, > > > > There is a very valid concern, since @Contended changes object layout > and i

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

Nov 12, 2015, at 5:48 AM, Vitaly Davidovich wrote: > > > There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot > code. Hence why it has remained internal so far. > > > > What

Re: Reference.reachabilityFence

Hi Paul, Glad you guys are addressing this. It looks like C1 and C2 will actually call this method. Is the longer term plan to teach the compilers that this method does not need to be called but rather expand the live range of the reference? Thanks On Mon, Nov 23, 2015 at 11:38 AM, Paul Sandoz

Re: Reference.reachabilityFence

consider that a bug (or at least missed optimization). sent from my phone On Nov 23, 2015 6:09 PM, "Peter Levart" wrote: > Hi, > > On 11/23/2015 05:50 PM, Vitaly Davidovich wrote: > > Hi Paul, > > Glad you guys are addressing this. > > It looks like C1 and C2

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

Ah, the good 'ole switch statement earning more optimization jiras :). sent from my phone On Nov 23, 2015 7:36 PM, "John Rose" wrote: > On Nov 23, 2015, at 1:42 PM, Aleksey Shipilev > wrote: > > > > Okay, here it is (only tests changed): > > http://cr.openjdk.java.net/~shade/8136500/webrev.06/

Re: Reference.reachabilityFence

One can look at reachabilityFence in same light as requesting gc or finalization, both of which live in Runtime. sent from my phone On Nov 24, 2015 7:54 AM, "David Holmes" wrote: > On 24/11/2015 7:32 PM, Paul Sandoz wrote: > >> >> On 24 Nov 2015, at 01:31, [email protected] wrote: >>> >>>

Re: Reference.reachabilityFence

s better, IMO. sent from my phone On Nov 24, 2015 8:00 AM, "Vitaly Davidovich" wrote: > One can look at reachabilityFence in same light as requesting gc or > finalization, both of which live in Runtime. > > sent from my phone > On Nov 24, 2015 7:54 AM, "David Holmes

Re: Reference.reachabilityFence

d Holmes wrote: > On 24/11/2015 11:00 PM, Vitaly Davidovich wrote: > >> One can look at reachabilityFence in same light as requesting gc or >> finalization, both of which live in Runtime. >> > > I don't quite see how they are "in the same light". Bot

Re: Reference.reachabilityFence

M, Andrew Haley wrote: > Bikeshedding, > > On 11/24/2015 01:07 PM, Vitaly Davidovich wrote: > > How about keepAlive? Reference.keepAlive(Object) reads better, IMO. > > It does indeed. Imperative names for methods almost always read better, > IMO. And although we probably

Re: Reference.reachabilityFence

won't get hung up on it. On Tue, Nov 24, 2015 at 12:06 PM, Doug Lea wrote: > On 11/24/2015 09:09 AM, Andrew Haley wrote: > >> Bikeshedding, >> >> On 11/24/2015 01:07 PM, Vitaly Davidovich wrote: >> >>> How about keepAlive? Reference.keepAlive(Object)

Re: RFC: AbstractStringBuilder sharing its buffer with String

Is that a valid example given StringBuilder isn't threadsafe to begin with? If the SB instance is shared among threads that perform writes to it without external synchronization, it's a bug in that code. Am I missing something? You'd have to ensure that the returned String is stable and effective

Re: RFC: AbstractStringBuilder sharing its buffer with String

> > On 11/28/2015 08:19 PM, Vitaly Davidovich wrote: > > Is that a valid example given StringBuilder isn't threadsafe to begin > with? If the SB instance is shared among threads that perform writes to it > without external synchronization, it's a bug in that code.

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Minor quibble, but why the "on" prefix in the name? Maybe just me, but onXYX is typically used for event notification style APIs. Also, the "wait" part seems inappropriate as the method itself isn't doing any waiting. What was wrong with the original spinLoopHint name? Or cpuRelax()? sent from m

Re: Potential performance improvement for java.util.AbstractList?

sent from my phone On Dec 8, 2015 12:07 AM, "David Holmes" wrote: > > On 8/12/2015 1:39 AM, Rafael Winterhalter wrote: >> >> In this case, one might consider: >> >> if (o instanceof java.util.RandomAccess && (List)o).size() != size()) >>return false; > > > You'd also have to check the type of

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

Can we enhance java to allow specifying lambda capture and how the value is captured? :) This is very subtle to the point where I maybe wouldn't even encourage use of lambda in this context. sent from my phone On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > On 12/08/2015 08:08 PM, Steven Sc

RE: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization

ly to not be easily detected. > > > > > -- > Have a nice day, > Timo > > Sent from Mail for Windows 10 > > > > > > > From: Vitaly Davidovich > Sent: Wednesday, December 9, 2015 00:09 > To: Peter Levart > Cc: core-libs-dev > Subject: Re

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

This has the same problem, doesn't it? The bottom line is if the lambda is () -> you're getting a capture of `this`. On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs wrote: > Hi, > > Another option that should always capture is to define a specific static > method with the needed values as arguments

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

;> this.cleanable = cleaner.register(this, () -> { >>> // DON'T capture any instance fields with lambda since >>> that would >>> // capture 'this' and prevent it from becoming >>> phantom-reachable!!! >>>

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

ent it from becoming > phantom-reachable!!! > _pnr.close(); > }); > > this.pnr = _pnr; > } > > public void close() { > cleanable.clean(); > } > > > Regards, Peter > > On 12/09/2015

Re: Reference.reachabilityFence

Hi Paul, No objections, but just wanted to summarize a couple of possible key performance issues that were raised on the concurrency-interest thread. You may have picked them up already, so pardon the repetition: 1) current impl/prototype is purposely barred from inlining - this will be a compile

Re: Reference.reachabilityFence

ht thing in its current form. sent from my phone On Dec 11, 2015 10:52 AM, "Vitaly Davidovich" wrote: > Hi Paul, > > No objections, but just wanted to summarize a couple of possible key > performance issues that were raised on the concurrency-interest thread. > You may ha

Re: API review of VarHandles

I think the get/setOpaque methods need a bit more explanation ("opaque" is an odd naming choice, IMO). Specifically, it says the operations are done in program order but have no effect on inter-thread ordering/visibility. Is this spec verbiage for a full compiler-only fence? On Thursday, January

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley wrote: > On 22/01/16 00:01, Vitaly Davidovich wrote: > > I think the get/setOpaque methods need a bit more explanation ("opaque" > is > > an odd naming choice, IMO). Specifically, it says the operations are > done > >

Re: API review of VarHandles

On Thursday, January 21, 2016, Brian Goetz wrote: > > I am baffled as to how the original language syntax proposal of using some >> trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new >> bytecodes was considered unacceptable; looking at this API, I know that >> none of the aforem

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley wrote: > On 01/22/2016 11:15 AM, Vitaly Davidovich wrote: > > > I'm guessing opaque is compiler only fence because a method that a > > compiler doesn't inline (as an example) is considered "opaque" to > > th

Re: API review of VarHandles

On Friday, January 22, 2016, Aleksey Shipilev wrote: > On 01/22/2016 03:08 PM, Vitaly Davidovich wrote: > > The VarHandle API isn't ergonomic like Unsafe; this being for power users > > is irrelevant to the ergonomics of the API. Instead, it's fairly verbose > &g

  1   2   3   4   >