profile
viewpoint

lukesandberg/Regex 14

simple regex implementation for c, based on articles by Russ Cox: http://swtch.com/~rsc/regexp/regexp2.html

lukesandberg/bootstrap-scheme 4

my implementation of peter michaux's bootstrap scheme project: http://peter.michaux.ca

lukesandberg/PexFaultLocalization 4

cs527 project for pex fault localization

lukesandberg/grepJar 3

simple regex grep utility that searches within jar files

lukesandberg/PurelyFunctionalDataStructures 3

an implementations of some of the data structures found in Chris Okasakis book "Purely Functional Data Structures" in the C# language.

lukesandberg/cglib 0

cglib - Byte Code Generation Library is high level API to generate and transform Java byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

lukesandberg/compile-testing 0

Testing tools for javac and annotation processors

lukesandberg/javawriter 0

A utility class which aids in generating Java source files.

lukesandberg/mockito 0

simpler & better mocking

issue commentgoogle/guice

Move Logger binding out to LoggerModule, so users can bind their own Loggers

Running into this years later...

gissuebot

comment created time in 2 hours

issue openedgoogle/guava

Synchronized usage of Concurrent Multi Hash Map

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.

created time in 5 hours

issue commentgoogle/guava

EventBus: Add options to enable ImmediateDispatcher

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.

ckloner

comment created time in 20 hours

issue openedgoogle/guava

EventBus: Add options to enable ImmediateDispatcher

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.

created time in 20 hours

issue commentgoogle/guava

Enable multiple Finalizers for FinalizableReferenceQueue

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.

HannesWell

comment created time in a day

issue commentgoogle/guava

Enable multiple Finalizers for FinalizableReferenceQueue

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.

HannesWell

comment created time in 2 days

issue commentgoogle/guava

Enable multiple Finalizers for FinalizableReferenceQueue

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.

HannesWell

comment created time in 2 days

issue commentgoogle/guava

Enable multiple Finalizers for FinalizableReferenceQueue

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.

HannesWell

comment created time in 2 days

issue commentgoogle/guava

Enable multiple Finalizers for FinalizableReferenceQueue

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

HannesWell

comment created time in 2 days

push eventgoogle/guava

travis-ci

commit sha 2f6c5539f022841a387a5dd10807aab8b0683abf

Generate Javadoc and JDiff for Guava HEAD-jre-SNAPSHOT

view details

push time in 3 days

push eventgoogle/guava

travis-ci

commit sha dcd1ca1316adcce814fb7f08f247581be035123b

Generate Javadoc and JDiff for Guava HEAD-jre-SNAPSHOT

view details

push time in 3 days

delete branch google/guava

delete branch : sync-master-2020/11/24

delete time in 3 days

push eventgoogle/guava

pferaud

commit sha 4709fe4d50cf5249b9e5e40fb8917c610831c317

Internal change. RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=344065888

view details

push time in 3 days

PR merged google/guava

MOE Sync 2020-11-24 cla: yes internal-sync

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

+25 -0

0 comment

16 changed files

cpovirk

pr closed time in 3 days

push eventgoogle/guava

Chris Povirk

commit sha 7112c0339419289cf7175f304d092571c5913ec2

Eliminate contravariant parameter types. This includes actually changing the behavior of AppendableWriter.write to throw if passed null (unlike AppendableWriter.append -- boo, inconsistent Writer contract!).

view details

Chris Povirk

commit sha 3d99abc2349b679a31944d5b06b2f24c31f384e1

Merge.

view details

push time in 3 days

push eventgoogle/guava

Chris Povirk

commit sha 7112c0339419289cf7175f304d092571c5913ec2

Eliminate contravariant parameter types. This includes actually changing the behavior of AppendableWriter.write to throw if passed null (unlike AppendableWriter.append -- boo, inconsistent Writer contract!).

view details

push time in 3 days

push eventgoogle/guava

travis-ci

commit sha 812d6ae7a4079aa1cb1267356e42dd0e0e44fa1c

Generate Javadoc and JDiff for Guava HEAD-jre-SNAPSHOT

view details

push time in 3 days

push eventgoogle/guava

travis-ci

commit sha c6acea8c8da049bd0bfd74675893be9c7e0597d0

Generate Javadoc and JDiff for Guava HEAD-jre-SNAPSHOT

view details

push time in 3 days

create barnchgoogle/guava

branch : sync-master-2020/11/24

created branch time in 3 days

PR opened google/guava

MOE Sync 2020-11-24

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

+25 -0

0 comment

16 changed files

pr created time in 3 days

push eventgoogle/guava

pferaud

commit sha f3a194a87eadfb6ac6c44f67e9d875259760f7c7

Make toImmutableSortedMap levarage collect collectors RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=344044740

view details

push time in 3 days

delete branch google/guava

delete branch : sync-master-2020/11/24

delete time in 3 days

PR merged google/guava

MOE Sync 2020-11-24 cla: yes internal-sync

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

+2 -8

0 comment

1 changed file

cpovirk

pr closed time in 3 days

create barnchgoogle/guava

branch : sync-master-2020/11/24

created branch time in 3 days

PR opened google/guava

MOE Sync 2020-11-24

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

+2 -8

0 comment

1 changed file

pr created time in 3 days

pull request commentgoogle/guava

Fix #4011: Files::createTempDir security vulnerability

CC. So you can update the Syky advisory

  • Benji @benjifin
  • Leeya @leeyashalti
melloware

comment created time in 3 days

pull request commentgoogle/guava

Fix #4011: Files::createTempDir security vulnerability

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

melloware

comment created time in 3 days

issue closedgoogle/guava

Expose Absent and Present as Subtypes of Optional

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.

closed time in 4 days

vgonsalv

issue commentgoogle/guava

Expose Absent and Present as Subtypes of Optional

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.

vgonsalv

comment created time in 4 days

issue openedgoogle/guava

Expose Absent and Present as Subtypes of Optional

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.

created time in 4 days

more