PhantomReferences

Here's another finalization-related issue, this time hopefully appropriate for this list. This was inspired by looking at the Ugawa, Jones, and Ritson paper from ISMM 2014, which I belatedly had a chance to look at. The java.lang.ref spec says: "An object is phantom reachable if it is neither

JNI WeakGlobalRefs

Is this an appropriate list to discuss JNI? I'm concerned that the current semantics of JNI WeakGlobalRefs are still dangerous in a very subtle way that is hidden in the spec. The current (14+) spec says: “Weak global references are related to Java phantom references

Re: [PATCH] Docfix for Unsafe regarding fence methods

On Fri, Aug 28, 2020 at 1:21 PM Ian Graves wrote: > > Looks like the patch attachment was stripped. I’ll include it inline: > —Ian > > ... > @@ -3458,6 +3462,12 @@ > /** > * Ensures that stores before the fence will not be reordered with > * stores after the fence. > + * > +

Re: Question about String.toUpperCase behaviour

On Tue, Oct 29, 2019 at 1:12 PM Rob Spoor wrote: > > I agree. There is no reason to use == instead of equals. Not for > readability, because it will most likely confuse people who will come > asking why you're not using equals. Not for performance, because since > at least Java 7 String.equals

Re: RFR: 8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs

Looks great to me! Just to be clear, this is intended to guarantee that it's not possible to promote a weak global reference that indirectly points to A after a PhantomReference or a WeakGlobalReference to A has been cleared? Thus this reference clearing must happen more or less atomically. I

Re: FileOutputStream.getFD() vs finalization

lev...@gmail.com> wrote: > Hi, > > Maybe I'm missing something but... > > Hans Boehm je 28. 12. 2017 ob 21:32 napisal: > > The design of the getFD() calls in some Java *Stream classes seems > problematic, and doesn't seem cleanly fixable without a spec change. I > first noti

Re: RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

On Mon, Sep 18, 2017 at 10:52 AM, Kazunori Ogata wrote: > > Hi Peter, > > Peter Levart wrote on 2017/09/18 22:05:43: > > > On 09/18/2017 12:28 PM, Kazunori Ogata wrote: > > > Hi Hans and Peter, > > > > > > Thank you for your comments. > > > > > >

Re: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups

Any chance the example code in the documentation that is quoted below could also be adjusted to e.g. synchronized (obj) { while () { ; obj.wait(); } ... // Perform action appropriate to condition } and similarly for the nanos case?

Re: RFR 9: 8165641 : Deprecate Object.finalize

Agree entirely with Andrew's concern. I would mostly point to the java.lang.Reference documentation. One possible approach follows. Add the following to the apiNote. I would add it at the beginning, since I've rarely encountered the inheritance issues, and they're probably easier to debug: As

Re: [9] RFR (XS): 8169000: Define reference reachability more precisely in java.lang.ref package

The rather-hard-to-decode section 12.6.2 essentially tries to pin down exactly when a reference is guaranteed to remain reachable. It may be worth directly pointing to it. (And perhaps wishing the reader luck :-) ) On Wed, Nov 16, 2016 at 12:21 AM, Zoltán Majó wrote: >

Re: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec

The new version seems less clear to me. Could it be misread as only applying if the value is positive? s/of/indicating a/ ? On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy wrote: > Hello, > > I plan to push with a slightly different wording. Rather than > > ... but

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

The expectation would be that such memory would still be mapped with the same caching behavior as normal memory, e.g. writeback-cacheable, so that it would follow normal Java memory model rules when accessed as normal memory? AFAICT, mapping any kind of memory with different caching behavior is

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

If we look at using purely store fences and purely load fences in the initialized flag example as in this discussion, I think it's worth distinguishing too possible scenarios: 1) We guarantee some form of dependency-based ordering, as most real computer architectures do. This probably

Re: [concurrency-interest] RFR: 8065804: JEP171:Clarifications/corrections for fence intrinsics

, 2014 at 4:36 PM, David Holmes davidchol...@aapt.net.au wrote: Stephan Diestelhorst writes: David Holmes wrote: Stephan Diestelhorst writes: Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm: I'm no hardware architect, but fundamentally it seems to me that load

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

: Hans, (Thanks for your excellent work on C/C++ 11 and your eternal patience) On Tue, Nov 25, 2014 at 11:15 AM, Hans Boehm bo...@acm.org wrote: It seems to me that a (dubiuously named) loadFence is intended to have essentially the same semantics as the (perhaps slightly less dubiously named

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

will be inconsistent. (The other problem of course is that we still don't really know how to define memory_order_relaxed any better than we know how to define ordinary Java memory references.) On Mon, Dec 1, 2014 at 5:05 PM, Martin Buchholz marti...@google.com wrote: On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm