Running into this years later...

While looking for a Concurrent Multi Hash Map, I found Multimaps.synchronizedMultimap() wrapper which seems to be what I'm looking for. However, the documentation gives an example which I'm not picturing a situation when this might be useful: https://github.com/google/guava/blob/4709fe4d50cf5249b9e5e40fb8917c610831c317/guava/src/com/google/common/collect/Multimaps.java#L566-L583

My take is that put operations will still be outside this synchronized block. Am I getting it wrong?

I went to look for valid usages in the test suite, but only found one that didn't help me much understanding it.

My use case is that I don't really care for non-deterministic behavior as long as it does not result in a fail operation (e.g., throw an Exception). Even if this might not be an issue, I am still curious about a scenario where this should be employed.

Actually I also found issue #3406 related to this problem now. The most problematic thing is only, that the abstract class Dispatcher is package visible. If the implementation of ImmediateDispatchercan be used or not, is not that important because the code is trivial and can easily be reimplemented by extending Dispatcher. I could also create a Pull request to fix this issue if this is OK and is accepted.

This ticket is almost the same as #2986 but deals with the EventBus instead of the AsycEventBus object.

I am using the EventBus object not as global object (static or singleton) but on a single instance per user session. In this scenario, instantiating for each EventBus instance an instance of PerThreadQueuedDispatcher with all the ThreadLocal variables does not make much sense. It would be better to have the possibility to use ImmediateDispatcher.INSTANCE by making Dispatcher.immediate() public - as well as changing the package visibility of the class Dispatcher to public. Changing the package visible constructor EventBus(String,Executor,Dispatcher,SubscriberExceptionHandler) would enable much more flexibility.

The data-structure of the Graph is given, we use the BinaryResource of the Eclipse Modelling Framework. But nevertheless thanks for the link, it looks interesting. Maybe it provides some good ideas (Since it seems to be abandon, it is probably not a good idea to use it directly).

Yes, that sounds reasonable. I'll have to think about it again and hopefully find a better solution. Thanks a lot for your help.

A size-limited cache can use soft-references as a failsafe, but as you note it may not be good enough. If you persist on write rather than write on evict, then you won't have those finalization problems. And if your graph is layed out to be disk-friendly, the I/O read/write might not be expensive as the OS's buffer cache is keeping it too. A library that could be interesting (or not, I've never used it) is Netflix Graph.

Not knowing your use-case, my bias is to use a traditional cache and persist updates on a write. The cache's policy should make a good guess of what to evict, the application behavior will be more predictable, and you can use soft-references as a failsafe if low on memory.

I was partly aware of what you've mentioned. Until some point it is desired that the SoftReference fill up the heap, because I want to avoid to unnecessarily write data to the drive in case they would have fit in the memory. On the other hand when it comes to the point that the memory is too small, I agree that frequent small GC-cycles are potentially slowing down the application. It a dilemma.

The problem I have with size limited or weighted Caches is that even it is likely that the Graphs stored in the DriveCache occupy the vast majority of memory of the JVM (even if it has many GiB) it still possible that some other part of our program also requires a significant amount of memory. Additionally the stored graphs can be relatively small or quite big, it depends on what exactly the user is doing. So a suitable size-limit, that neither causes to frequent writes nor too early out-of-memory errors, is de-facto impossible to guess. It depends on what the user is doing and on the user's machine.

What I have experienced so far is that the SoftReferences tend to be cleared too late, which is probably because the write and clear of the payload-data requires at least one more GC-cycle to really release some data and not only the wrapper around it. And that's probably also a problem for the GC because it does not know that finalizing the softly referenced value triggers the payload-data to be released later too. So I'm already some kind of disenchanted.

I already have implemented the option to use WeakReferences (maybe in conjunction with settings Xms to Xmx to avoid to often GC cycles). Alternatively I thought about a daemon thread that regularly monitors the JVM's memory load with Runtime.get???Memory() and 'manually' frees some data selected according to the LRU schema, if the used memory occupancy reaches a certain threshold (e.g. 90%). But this approach doesn't feel right.

That makes sense. I’m sure you’re aware, but just in case, soft references have a bad reputation. They fill up the heap, require a full GC (STW pause) to collect, and cause GC storms because only enough memory is freed to continue the application. This caused mayhem in traditional collectors like CMS and global lru meant it wasn’t aware of what data was more costly to reload. Newer GCs are more aggressive, e.g. G1 is region based, so the negative impact might be more tolerable. This bad experience led to Guava switching from evangelizing reference collection to size-based caching using weighted values. Hopefully you don’t suffer these problems, but you might find the approach less useful than it originally seemed.

@netdpb thanks for the discussion.

@ben-manes that's a quite clever approach you use and I agree that avoiding the finalizer-thread-per-cache is definitely a benefit. Nevertheless in my use case the additional removal work (in my case writing data to drive) should be done as soon as possible.

I'm using my DriveCache as an extension to the RAM, that only writes data to the drive if the JVM tends to run out of memory. On this way more data can be processed and at the same time drive I/O is avoided as far as possible.

For the background: The DriveCache is used as a value storage (where each value is accessible by its key), that can write the "payload-data" of values to the drive and releases the memory of value and its payload, if the JVM tends to run out of memory. Therefore I'm using mainly SoftReferences for the values, but WeakReferences work too. When a new entry is add to the DriveCache a EntryMetadata-Object is created that has a Soft-/WeakReference to the value-Object and a strong reference to the values "payload-data". The Reference-Object also has a reference to the EntryMetadata-object. Then the key-object is put together with the EntryMetadata-object in the ConcurrentHashMap backing the cache. Once the Reference of an entry is enqueued into the ReferenceQueue of the Cache, the "payload-data" of the entry are written to drive and are then released so they can be garbage collected too. If the written value of a key is requested later, it is loaded from drive. If the memory pressure never becomes high no value-data are written and get(key) just returns the referent of the Soft-/WeakReference.

This only works if the value-object is a wrapper around its actual memory consuming payload-data object and that payload-data can be written to the drive without the value-object. As an example the keys could be some ID, and the values could be Objects of a FixedSizeArrayList class, where the backing array is always the same and can be accessed by the Cache-class (a special subclass is intended). So when the Garbage-Collector decides to finalize the FixedSizeArrayList-Object the DriveCache writes the content of the array to the drive and then releases its reference to the array, so it becomes eligible for garbage collection too. Of course this only works if the value-object and especially its payload-data are not permanently strongly referenced from somewhere else.

In my case the values are Graphs and the Program gets and ordinarily strongly references them from the DriveCache, if they are needed and just releases them when its done using them. So if the memory pressure becomes high in the meantime the Graph is written to drive, if not it just remains in the RAM.

On this way the Garbage-Collector de-facto manages if the cache should swap data to drive or not, just based on if a value is currently used or not and depending on the available RAM. So it is highly adaptive to the current environment without tweaking parameters manualy.

And because if the JVM runs out of memory I cannot wait a few more accesses for clean up. Because writing and releasing the payload-data requires one more GC-cycle already, this is time critical anyway. And for values that consume a signification portion of the overall RAM (e.g. 10%) it can be too late already and WeakReferences must be used.

This code has been reviewed and submitted internally. Feel free to discuss on the PR, and we can submit follow-up changes as necessary.

Commits:

<p> Internal change.

412db47018be7ccee39905468f65cd1f7b9f0eb2

This code has been reviewed and submitted internally. Feel free to discuss on the PR, and we can submit follow-up changes as necessary.

Commits:

<p> Internal change.

412db47018be7ccee39905468f65cd1f7b9f0eb2

This code has been reviewed and submitted internally. Feel free to discuss on the PR, and we can submit follow-up changes as necessary.

Commits:

<p> Make toImmutableSortedMap levarage collect collectors

b499958c1439b0c1c76732ec50daec8b46a1789b

This code has been reviewed and submitted internally. Feel free to discuss on the PR, and we can submit follow-up changes as necessary.

Commits:

<p> Make toImmutableSortedMap levarage collect collectors

b499958c1439b0c1c76732ec50daec8b46a1789b

CC. So you can update the Syky advisory

• Benji @benjifin
• Leeya @leeyashalti

A couple other observations from some quick internal testing:

• This fails at least one internal test. That test sets java.io.tmpdir to /invalid and then expect the createTempDir call to fail. That said, I doubt that any actual production code cares about that behavior. Rather, the test was probably just verifying that the correct type of exception was thrown if the operation did fail. Still, it's possible that there's a behavior change here. I didn't look into whether java.nio.file was creating the missing /invalid parent directory (probably unlikely, since I doubt it has permissions?) or failing to respect the programmatic change to java.io.tmpdir. If the latter, someone might care.

• This breaks some of our J2ObjC users. That said, I was able to mark the method as @J2ObjcIncompatible, and tests passed again. In theory, if a J2ObjC user were using createTempDir, this would be a breaking change. But that may well never come up.

Still, the points stand that this is @Beta and @Deprecated.

It's hard to know what would be least disruptive to users :(

Consider an interface Foo as follows:

interface Foo {
    Optional<Bar> doFoo();
}

Suppose we now have an implementation which wants to provide a stricter contract of always returning a value. Currently it would have to always wrap the value in an Optional. Even if we document that the Optional always had a value, most linters would complain about the lack of an isPresent() check .

Instead, if Present were exposed as a subtype of Optional, we could define it as follows:

interface MyFoo extends Foo{
    Present<Bar> doFoo();
}

This would formally indicate that MyFoo would always return a value, and linting could advise that isPresent() check are unnecessary.

Similarly if we want to indicate that no value is ever returned, we could use the Absent type as well.

Interesting! I'm surprised that (as far as I can recall) we haven't heard this suggested before.

That said...

We do not want to our Optional to compete with the JDK's: We recommend that people use the JDK class if they can. And even if they can't use it today (typically because they target older versions of Android or Java), we don't want to add features that would complicate a future migration to the JDK class.

You could try proposing this to the JDK itself. However, my understanding is that they want to make Optional into an inline type, and I think that may interfere with letting it have a subclass like Present.

The even longer-term hope is that Java will get Kotlin-style support for nullness in the type system. Then methods like Foo.doFoo() can return Bar?, and methods like MyFoo.doFoo() can return Bar.

Consider an interface Foo as follows:

interface Foo {
    Optional<Bar> doFoo();
}

Suppose we now have an implementation which wants to provide a stricter contract of always returning a value. Currently it would have to always wrap the value in an Optional. Even if we document that the Optional always had a value, most linters would complain about the lack of an isPresent() check .

Instead, if Present were exposed as a subtype of Optional, we could define it as follows:

interface MyFoo extends Foo{
    Present<Bar> doFoo();
}

This would formally indicate that MyFoo would always return a value, and linting could advise that isPresent() check are unnecessary.

Similarly if we want to indicate that no value is ever returned, we could use the Absent type as well.