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

I'll file 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. FJ pool)

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

It's surprising that both variants don't perform the same when JIT compiled. On Mon, Mar 19, 2018 at 3:32 PM, Martin Buchholz wrote: > > > > */ > > public boolean equals(Object obj) { > > if (obj instanceof Boolean) { > > - return value ==

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

On Tue, Feb 13, 2018 at 8:57 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 13/02/2018 13:03, Vitaly Davidovich wrote: > >> : >> So I tried calling getBundle(..., Object.class.getModule()), and that >> worked - great. Interestingly, I did

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

Hi Mandy, Thanks very much for your response. Some comments inline ... On Mon, Feb 12, 2018 at 7:44 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > On 2/12/18 12:36 PM, Vitaly Davidovich wrote: > > Hi all, > > I'm not sure if core-libs is the right mail

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

On Mon, Feb 12, 2018 at 8:14 PM, David Holmes <david.hol...@oracle.com> wrote: > Hi Vitaly, > > See this thread: > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-Febru > ary/013584.html Thanks David! > > > David > > > On 13/02/2018 6:3

IllegalAccessException trying to load a ResourceBundle in 9u181

Hi all, I'm not sure if core-libs is the right mailing list for jigsaw/modules questions these days (rather than jigsaw-dev), so please feel free to forward this there if it's the more appropriate list. I have the following code carried over from java 8 (actually much earlier than that, but

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 11:28 AM Jason Greene wrote: > > > On Jan 12, 2018, at 6:50 AM, Vladimir Ivanov < > vladimir.x.iva...@oracle.com> wrote: > > > > -snip- > > > So, the worst case scenario is: a value written into @Stable > field/array is never visible in some code

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 7:50 AM, Vladimir Ivanov < vladimir.x.iva...@oracle.com> wrote: > Would you be so kind to explain how this breakage occurs? I can >>> understand that improper use of @Stable annotation may break the >>> intended semantics of a program, but to break the integrity of VM? I'm

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 6:36 AM Peter Levart wrote: > Hi Andrew, > > On 01/12/2018 09:47 AM, Andrew Haley wrote: > > On 12/01/18 04:33, Jason Greene wrote: > > > >> The internal @Stable facility provides the desired semantics and > >> precision, but it is heavily locked

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman wrote: > On 04/01/2018 01:35, David Holmes wrote: > >> >> You're not missing anything. It's a class initialization related >> "deadlock". >> >> Thread A has called FileSystems.getDefault() which is doing of >>

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On Wed, Jan 3, 2018 at 8:36 PM David Holmes <david.hol...@oracle.com> wrote: > On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: > > On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman <alan.bate...@oracle.com> > > wrote: > > > >> The stack trace looks like JDK 8

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

d to make sure I'm not missing anything. Thanks Alan > > -Alan > > > On 03/01/2018 16:56, Vitaly Davidovich wrote: > >> Hi all, >> >> Consider the following stacktraces of the main app thread and a background >> thread: >> >> "main"

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

Sorry, I should've mentioned that this is 8u152. On Wed, Jan 3, 2018 at 11:56 AM, Vitaly Davidovich <vita...@gmail.com> wrote: > Hi all, > > Consider the following stacktraces of the main app thread and a background > thread: > > "main" #1 prio=5 os_prio=0

Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

Hi all, Consider the following stacktraces of the main app thread and a background thread: "main" #1 prio=5 os_prio=0 tid=0x01bfd000 nid=0x1958 waiting for monitor entry [0x2b98ceba3000] java.lang.Thread.State: BLOCKED (on object monitor) at

Re: Possible bug in StackFrameInfo#getByteCodeIndex?

On Tue, Dec 12, 2017 at 8:45 AM, David Lloyd wrote: > On Mon, Dec 11, 2017 at 9:03 PM, mandy chung > wrote: > > On 12/11/17 6:31 PM, Martin Buchholz wrote: > >> Java has an unsigned 16 bit type. Could bci be of type "char" ? > > > > Yes but I

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 1:22 PM, Peter Levart <peter.lev...@gmail.com> wrote: > > > On 12/07/2017 06:46 PM, Vitaly Davidovich wrote: > > So no magic here. Just API. > > This is an API version of Hans’s #3 approach. As he said, there’s > performance o

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 1:12 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > - Mail original - > > De: "Vitaly Davidovich" <vita...@gmail.com> > > À: "Peter Levart" <peter.lev...@gmail.com> > > Cc: "core-libs-dev" <co

Re: Finalization and dead references: another proposal

On Thu, Dec 7, 2017 at 12:28 PM Peter Levart <peter.lev...@gmail.com> wrote: > Hi, > > On 12/07/2017 03:27 AM, Vitaly Davidovich wrote: > > So kind of the opposite of WeakReference - a SuperStrongReference :). > > > > Kidding aside, it seems like

Re: RFR 4358774: Add null InputStream and OutputStream

.02, Roger > > On 12/6/2017 10:03 PM, Vitaly Davidovich wrote: > > On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens <jason_mehr...@hotmail.com > > > > wrote: > > > >> Brian, > >> > >> My understand is JDK-6533165 is moving the bytes tha

Re: RFR 4358774: Add null InputStream and OutputStream

On Wed, Dec 6, 2017 at 4:01 PM, Jason Mehrens wrote: > Brian, > > My understand is JDK-6533165 is moving the bytes that are rarely invoked > to a cold method. > > Therefore: > > if (closed) { >throw new IOException("Stream closed"); > } > ==becomes=== > if

Re: Finalization and dead references: another proposal

On Wed, Dec 6, 2017 at 7:38 PM Hans Boehm wrote: > We're still trying to deal with a fair amount of code that implicitly > assumes that finalization or similar clean-up will not occur while a > pointer to the affected object is in scope. Which is of course not true. > > As a

Re: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C

On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley wrote: > On 15/11/17 15:38, Alan Bateman wrote: >> Moving the nativeOrder out of the loop make sense but I'm curious about >> the context for improving this implementation. > > I wonder about lifting ByteOrder.nativeOrder(). Maybe

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

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

Re: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)

On Tue, Nov 7, 2017 at 3:45 PM Remi Forax <fo...@univ-mlv.fr> wrote: > > > On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich < > vita...@gmail.com> wrote: > >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <fo...@univ-mlv.fr> wrote: > > > >>

Re: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)

On Tue, Nov 7, 2017 at 1:25 PM Remi Forax wrote: > My bad, > I've calculated that the header was 8 bytes instead of 12, so I've > supposed that the boolean was not stored in a byte. > > For my culture, why the header is 12 bytes, the pointer to the vtable is > on 64bits and

Re: Random.nextLong(long bound)?

On Wed, Oct 18, 2017 at 5:54 PM Steven Schlansker < stevenschlans...@gmail.com> wrote: > My coworker is implementing an algorithm for which he needs a bounded > random long. > He needs to be in full control of the seed and not share the instance > (i.e. not use ThreadLocalRandom). > > Random

Re: java.util.Pair

Similarly, I've used https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleEntry.html and https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleImmutableEntry.html in these circumstances. On Thu, Jul 13, 2017 at 1:29 PM Maurizio Cimadamore <

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

On Thu, Mar 2, 2017 at 11:42 AM, Ulf Zibis <ulf.zi...@cosoco.de> wrote: > > Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: > >> Implicit null checks ... generally don't cost anything. >> > Any additional byte of code in CPU cache prevents other code from staying &

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

On Thu, Mar 2, 2017 at 8:32 AM Ulf Zibis <ulf.zi...@cosoco.de> wrote: > HI, > > first sorry for missing the class wide definition. > > Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: > > > > On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis <ulf.zi...@co

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

On Thu, Mar 2, 2017 at 8:26 AM, Jonathan Bluett-Duncan < jbluettdun...@gmail.com> wrote: > Hi Christoph and Vitaly, > > I am struggling to understand why the null-check for `replacement` has > been moved within the `if (j < 0) { ... }` block. Could one of you explain > to me the reasoning behind

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

On Thu, Mar 2, 2017 at 6:45 AM Claes Redestad wrote: > On 03/02/2017 11:38 AM, Ulf Zibis wrote: > > Hi Vitaly, > > > > I don't see any contract to throw an NPE: > > >

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

ome cases. The other case where I believe this is done is when passing a Supplier to some method that uses it to obtain a default value - even if it's not needed, it's checked for null because most (all?) such methods stipulate that it cannot be null. > > > > Am 02.03.2017 um 00:18 schrieb Vitaly

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

As mentioned offline, I would move the null check right before "return this". On Wed, Mar 1, 2017 at 6:50 PM Christoph Dreis wrote: > Hey Vitaly, > > > Seems like a good idea. You probably want to null check 'replacement' > before the bail out as the method is

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

Seems like a good idea. You probably want to null check 'replacement' before the bail out as the method is specified as throwing NPE in that case. On Wed, Mar 1, 2017 at 4:37 PM Christoph Dreis wrote: > Hey, > > I just noticed a small improvement for

Re: Future plans for sun.misc.Contended

then to see where layout control lands. On Thu, Feb 23, 2017 at 12:41 PM, Andrew Haley <a...@redhat.com> wrote: > On 23/02/17 17:26, Vitaly Davidovich wrote: > > My understanding was it's in sun.misc as an experimental/"unstable" > > annotation, but that it was inc

Future plans for sun.misc.Contended

Hi all, I'm curious if anyone knows the future plans for this annotation, specifically if it's slated to become officially supported in Java SE and if so, what the timeline looks like (if that exists). My understanding was it's in sun.misc as an experimental/"unstable" annotation, but that it

Re: Request/discussion: BufferedReader reading using async API while providing sync API

ely, the nonblocking file io story is complicated and messy. > On 27/10/2016 14:11, Vitaly Davidovich wrote: > > I don't know about Windows specifically, but generally file systems across > major OS's will implement readahead in their IO scheduler when they detect > sequential scans.

Re: Request/discussion: BufferedReader reading using async API while providing sync API

getting > 100% HDD reads... Could it be that the OS reads the file ahead on its > own?... Anyway, I'll look into it. Thanks for the heads up. > > On 27/10/2016 13:53, Vitaly Davidovich wrote: > > > > On Thu, Oct 27, 2016 at 8:34 AM, Brunoais <brunoa...@gmail.com> wrote: &g

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Channel with HeapByteBuffer instead. > > On 27/10/2016 11:47, Vitaly Davidovich wrote: > > > > On Thursday, October 27, 2016, Brunoais <brunoa...@gmail.com> wrote: > >> Did you read the C code? > > I looked at the Linux code in the JDK. > >> Have

Re: Request/discussion: BufferedReader reading using async API while providing sync API

d the JDK (native) source code instead of guessing/assuming. On Linux, it doesn't use aio facilities for files. The kernel io scheduler may issue readahead behind the scenes, but there's no nonblocking file io that's at the heart of your premise. > > > On 27/10/2016 00:06, Vitaly Davidovich

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On Wednesday, October 26, 2016, Brunoais wrote: > It is actually based on the premise that: > > 1. The first call to ReadableByteChannel.read(ByteBuffer) sets the OS >buffer size to fill in as the same size as ByteBuffer. Why do you say that? AFAICT, it issues a read

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz <marti...@google.com> wrote: > > > On Tue, Oct 18, 2016 at 4:26 PM, Vitaly Davidovich <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > >> "jsr166 style" - make

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz <marti...@google.com> wrote: > > > On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > >> >>> > * Change in

Re: RFR: jsr166 jdk9 integration wave 12

On Tuesday, October 18, 2016, Martin Buchholz wrote: > On Tue, Oct 18, 2016 at 10:15 AM, Stuart Marks > > wrote: > > > > > > > On 10/17/16 6:34 PM, Martin Buchholz wrote: > > > >> Most of this is for Stuart - very collection-y. > >> >

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On Wednesday, September 28, 2016, David Holmes wrote: > On 28/09/2016 11:24 PM, Peter Levart wrote: > >> >> On 09/28/2016 03:05 PM, David Holmes wrote: >> >>> On 28/09/2016 10:44 PM, Peter Levart wrote: >>> Hi, According to discussion here:

Re: RFR: 8166842: String.hashCode() has a non-benign data race

ompute it. At worst, you perform the same computation "unnecessarily". The possible compiler reordering, as discussed in this thread, within hashCode itself is problematic because it can, theoretically, yield 0 erroneously. > > Carsten > > >> David >

Re: RFR: 8166842: String.hashCode() has a non-benign data race

(re-) read of the underlying field. But, otherwise I believe compiler has latitude to schedule loads and reloads as it pleases. But I think this may need to be clarified since this aspect has been brought up. > > Carsten > > On Wed, Sep 28, 2016 at 10:13 AM, Vitaly Davidovich <vi

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

easy. Who could make the decision on that? > > /Claes Thanks > > > On 2016-09-28 16:27, Vitaly Davidovich wrote: > >> Thanks Claes - this is an annoying one! >> >> Will it be backported to 8? >> >> On Wednesday, September 28, 2016, Claes Redestad &

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

Thanks Claes - this is an annoying one! Will it be backported to 8? On Wednesday, September 28, 2016, Claes Redestad wrote: > Thanks for the quick reviews! > > /Claes > > On 2016-09-28 14:14, Remi Forax wrote: > >> yes, >> thumb up. >> >> Rémi >> >> >> On September

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On Wednesday, September 28, 2016, David Holmes wrote: > On 28/09/2016 10:44 PM, Peter Levart wrote: > >> Hi, >> >> According to discussion here: >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2016- >> September/015414.html >> >> >> it seems compact strings

Re: A bit of sugar for j.u.c.locks with try-with-resources?

On Saturday, September 3, 2016, wrote: > > De: "Dr Heinz M. Kabutz" > > > À: "Remi Forax" > > > Cc: "Ivan Gerasimov" >, > "core-libs-dev" > >

Re: A bit of sugar for j.u.c.locks with try-with-resources?

On Friday, September 2, 2016, Krystal Mok <rednaxel...@gmail.com> wrote: > Hi Vitaly, > > Thanks for your comments! > > On Fri, Sep 2, 2016 at 7:55 PM, Vitaly Davidovich <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > >

Re: A bit of sugar for j.u.c.locks with try-with-resources?

Hi Kris, On Friday, September 2, 2016, Krystal Mok wrote: > Hi core-libs developers, > > I mostly live down in the VM world, but recently I've been playing with > j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API > with the try-with-resources

Re: RFR(m): 8140281 deprecate Optional.get()

che.org> wrote: > >> Are you asking Brian to set up another survey monkey for the masses? I >> expect a happy silent majority and a raucous minority just based on >> past results. :-) >> On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" <vita...@gmail.com> wrot

Re: RFR(m): 8140281 deprecate Optional.get()

On Wednesday, April 27, 2016, Andrew Haley <a...@redhat.com> wrote: > On 27/04/16 11:51, Vitaly Davidovich wrote: > > On Wednesday, April 27, 2016, Andrew Haley <a...@redhat.com > <javascript:;>> wrote: > > > >> On 27/04/16 00:38, Vitaly Davidovic

Re: RFR(m): 8140281 deprecate Optional.get()

On Wednesday, April 27, 2016, Andrew Haley <a...@redhat.com> wrote: > On 27/04/16 00:38, Vitaly Davidovich wrote: > > I've yet to hear one supporter on this thread besides yourself and > Stuart. > > Do you really want to turn this discussion into even more of a > bikes

Re: RFR(m): 8140281 deprecate Optional.get()

on > past results. :-) > On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > > I've yet to hear one supporter on this thread besides yourself and Stuart. > Is there some usability surv

Re: RFR(m): 8140281 deprecate Optional.get()

I've yet to hear one supporter on this thread besides yourself and Stuart. Is there some usability survey or something that actually indicates a significant sample of people don't like the name? Guava Optional behaves and is named the same way, and I've not heard anyone complain about that (I and

Re: RFR(m): 8140281 deprecate Optional.get()

On Tuesday, April 26, 2016, Stuart Marks <stuart.ma...@oracle.com> wrote: > > > On 4/25/16 5:46 PM, Vitaly Davidovich wrote: > >> We've introduced Optional to avoid this. The problem is that the >> obvious >> thing to do is to get() the value out

Re: RFR(m): 8140281 deprecate Optional.get()

On Monday, April 25, 2016, Stuart Marks wrote: > > > On 4/25/16 4:35 PM, Jonathan Gibbons wrote: > >> Since the justification for this change appears to be that the IDEs might >> help >> write people write bad code, why not look to the IDEs to generate a >> warning when

Re: Expecting Integer.valueOf(String) to accept Literal format ...

I don't think the risk of breaking existing code in such a common API is worth the slight convenience improvement. If someone is keen on supporting such things, they can front this API by replacing underscores themselves, or more generally have something else accept underscores and canonicalize

Re: RFR 8151198: VarHandle factory-specific exceptions

fence used in description rather some more general notion; most people using this API will understand compiler fence, no need to make it more abstract. On Saturday, April 9, 2016, Doug Lea <d...@cs.oswego.edu> wrote: > On 04/09/2016 09:03 AM, Vitaly Davidovich wrote: > >> Just

Re: RFR 8151198: VarHandle factory-specific exceptions

Just to confirm - opaque is also a compiler fence right? C++ relaxed doesn't require compiler fence, but it sounds like opaque does. Would be good to clarify this, unless "program order" is the way you want to do that. On Saturday, April 9, 2016, Doug Lea wrote: > On

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

So are there any bootstrap issues with VH that would preclude using it in BufferedInputStream? Is that even known at this point? You mentioned that VH was designed to minimize bootstrapping issues, but where's the "minimized" line drawn? On Wed, Apr 6, 2016 at 10:09 AM, Paul Sandoz

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On Wednesday, April 6, 2016, Remi Forax wrote: > - Mail original - > > De: "Paul Sandoz" > > > Cc: "core-libs-dev Libs" > > > Envoyé: Mercredi 6 Avril 2016 12:37:50 > > Objet: Re: RFR:

Re: Reading subprocess stdout susceptible to deadlock

oger.ri...@oracle.com> wrote: > Hi Vitaly, > > I haven't seen that before, please create a bug and include the stack > traces. > > Thanks, Roger > > > > On 3/30/2016 9:56 AM, Vitaly Davidovich wrote: > >> Hi, >> >> It seems that doing a blockin

Reading subprocess stdout susceptible to deadlock

Hi, It seems that doing a blocking read on a subprocess's stdout can lead to deadlock between the thread doing the read and the process reaper thread. The deadlock occurs because the reader is synchronized on the ProcessPipeInputStream, blocks for more data to consume, and process reaper comes

Re: RFR(XS): 8147844: new method j.l.Thread.onSpinWait() (was j.l.Runtime)

if to say it's unspecified. On Wednesday, March 9, 2016, Ivan Krylov <i...@azulsystems.com> wrote: > To me this is an implementation detail that could change. The barrier is > there to prevent the intrinsic to be hoisted. > > Thanks, > Ivan > > > > On 09/03/20

Re: RFR(XS): 8147844: new method j.l.Thread.onSpinWait() (was j.l.Runtime)

Is it worthwhile to mention ordering effects? In particular, I believe there's a compiler barrier preventing moving ops before the call. Not sure if this needs any attention in the javadoc. On Wednesday, March 9, 2016, Ivan Krylov wrote: > I have added a little example

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

Looks like you have Mark's approval, so we're done :). On Wed, Feb 24, 2016 at 11:06 AM, Ivan Krylov <i...@azulsystems.com> wrote: > On 24/02/2016 18:20, Vitaly Davidovich wrote: > >> If you want, run a poll to get a better feel for what others may think. >> Doug di

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

t if we *are* subjecting naming to critique, then let's iron that out. If you want, run a poll to get a better feel for what others may think. Doug did that recently for some CompletableFuture behavior change proposals. Ultimately, I don't make the call on this anyway so I'm just giving you my opini

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

precedent as event handler callbacks, but this > method does not fit that purpose. Thus, I agree dropping "on" is sensible. > On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrot

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

On Tuesday, February 23, 2016, Doug Lea <d...@cs.oswego.edu> wrote: > On 02/23/2016 04:30 PM, Vitaly Davidovich wrote: > >> Why not drop the (superfluous, IMO) "on" prefix while you're changing the >> receiver? >> > > Because then it reads as if the m

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

Why not drop the (superfluous, IMO) "on" prefix while you're changing the receiver? Thread::spinWait would be in the same style/spirit as Thread::yield, and I don't think there will be much contention. On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene wrote: > > > On Feb 22, 2016, at

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

my $.02 :) On Mon, Feb 22, 2016 at 6:40 PM, Ivan Gerasimov <ivan.gerasi...@oracle.com> wrote: > > > On 22.02.2016 23:43, Vitaly Davidovich wrote: > > 165 final int SAFE_BOUND = (MAX_ARRAY_SIZE >> coder); 166 if > (((SAFE_BOUND - newCapacity) | newCapa

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

165 final int SAFE_BOUND = (MAX_ARRAY_SIZE >> coder); 166 if (((SAFE_BOUND - newCapacity) | newCapacity) < 0) { Do the hotspot compiler engineers know you guys are doing manual branch elimination like this? :) On Mon, Feb 22, 2016 at 2:20 PM, Ivan Gerasimov

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

it via any convention. > "spinLoopHint()" works for me on a Thread to an extent. We should express > intent or declare status for this. Hints don't fit comfortably in a > programming model. > > > > The actual naming does not matter so much as this will only be used by >

Re: API review of VarHandles

t;d...@cs.oswego.edu> wrote: > On 01/22/2016 04:51 AM, 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, IM

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

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley <a...@redhat.com> 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 operatio

Re: API review of VarHandles

On Friday, January 22, 2016, Andrew Haley <a...@redhat.com> 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" t

Re: API review of VarHandles

On Friday, January 22, 2016, Aleksey Shipilev <aleksey.shipi...@oracle.com> 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

Re: API review of VarHandles

+1, good stuff Aleksey (I had actually seen chatter about this change on one of these openjdk lists, but people have already moved away from the field updaters), except every time I think about final instance fields not being treated as constants I get sad :). The other wrinkle is the "am I lucky

Re: API review of VarHandles

On Friday, January 22, 2016, David M. Lloyd wrote: > On 01/21/2016 07:32 PM, 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

Re: API review of VarHandles

, and I do wish there was a way javac could assist there. VH is no worse in this respect, but also no better. On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd <david.ll...@redhat.com> wrote: > On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: > >> Experts need con

Re: API review of VarHandles

whole thing is a lot of gymnastics for something that's > basically a fancy way of accessing a plain field or array element - one of > the most basic concepts in Java. > > > On 01/22/2016 07:40 AM, Vitaly Davidovich wrote: > >> Which existing Atomic* classes? I take it you

Re: API review of VarHandles

Agreed; it's a building block, not an assembled piece. On Friday, January 22, 2016, Brian Goetz 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 >> with setup

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: Reference.reachabilityFence

ing in its current form. sent from my phone On Dec 11, 2015 10:52 AM, "Vitaly Davidovich" <vita...@gmail.com> wrote: > Hi Paul, > > No objections, but just wanted to summarize a couple of possible key > performance issues that were raised on the concurrency-interest

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

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

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

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

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

It's subtle and likely 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-li

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

Re: RFC: AbstractStringBuilder sharing its buffer with String

lev...@gmail.com> wrote: > > > 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'

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

Re: Reference.reachabilityFence

ung up on it. On Tue, Nov 24, 2015 at 12:06 PM, Doug Lea <d...@cs.oswego.edu> 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(Ob

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,

  1   2   3   >