yangxu998 / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

EvictionListener is not called during computation #552

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compile the attached file: javac -cp guava-r08.jar Tom.java
2. Run it: java -Xmx50m -cp .:guava-r08.jar Tom

What is the expected output?
It should print a bunch of lines like this that show the size of the Map 
increasing as entries are added:
Size: 1
Size: 2
Size: 3
...

Eventually one or more entries will be gc'd and the EvictionListener should be 
called when the map's public methods size() and/or get() are called, according 
to the MapMaker javadoc: "It will invoke the listener synchronously, during 
invocations of any of that map's public methods (even read-only methods)."  At 
that point, the program should print "Evicted ..." and exit.

What do you see instead?
The size increases, then decreases and increases again.  The EvictionListener 
is never called even though entries are being removed and public methods get() 
and size() are being called.  E.g.,
Size: 4640
Size: 4641
Size: 4642
Size: 4643
Size: 4644
Size: 4645
Size: 4646
Size: 4328
Size: 4324
Size: 4325
Size: 4323
Size: 4259
...
Eventually the program will slow to a crawl then crash, presumably because 
memory is depleted since the notification queue is never drained:
Size: 529
Size: 530
Size: 531
Exception in thread "main" com.google.common.collect.ComputationException: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:167)
    at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:116)
    at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:67)
    at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:623)
    at Tom.main(Tom.java:29)
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at Tom$1.apply(Tom.java:23)
    at Tom$1.apply(Tom.java:20)
    at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:155)
    ... 4 more

What version of the product are you using? On what operating system?
guava-r08.jar

javac -version
javac 1.6.0_22

java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

Ubuntu 10.10

Please provide any additional information below.

Original issue reported on code.google.com by tom%tomm...@gtempaccount.com on 18 Feb 2011 at 10:49

Attachments:

GoogleCodeExporter commented 9 years ago
See the discussion in Issue 482.

Original comment by boppenh...@google.com on 21 Feb 2011 at 10:13

GoogleCodeExporter commented 9 years ago
Yes, this is a bug in release 8 that has already been fixed, and will be 
available in release 9.

Original comment by fry@google.com on 24 Feb 2011 at 2:27

GoogleCodeExporter commented 9 years ago
Issue 579 has been merged into this issue.

Original comment by fry@google.com on 25 Mar 2011 at 8:16

GoogleCodeExporter commented 9 years ago
I am getting a negative size() and isEmpty() of false on a Map with weakKeys() 
and weakValues() using guava r09-rc2. The map is indeed empty and iterating 
over the keySet() shows no entries, but the size(), keySet().size(), and 
entrySet().size() all return the same negative value.

Original comment by jonat...@gmail.com on 1 Apr 2011 at 3:56

GoogleCodeExporter commented 9 years ago
I created issue 591 for the negative size report.

Original comment by fry@google.com on 5 Apr 2011 at 4:02

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09