This week's book giveaway is in the Spring forum.
We're giving away four copies of Modern frontends with htmx and have Wim Deblauwe on-line!
See this thread for details.
Win a copy of Modern frontends with htmx this week in the Spring forum!

Andrei Matyas

+ Follow
since Apr 15, 2007
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Andrei Matyas

Here you have a piece of code that may break this "Type Safe" rule .... if the add call is allowed

10 years ago
Hello )

But what about the GC activity when using Weak and Soft Refs ?


A few time ago I used WeakRefs to speed up gc collection on big old objects.
Basically when minor collection occurs (quite often) and when WeakReference is the only reference to the underlying object, referents are reclaimed immediately even if the object is present on oldGen space. That means that we can free OldGen objects with a quick minor GC.

It will be nice to test it with different GC strategies on different JDK versions and platforms.


When major collection occurs, and when SoftReference is the only reference to the underlying object, and when memory is low (what the hell does this mean - before an OutOfMemoryException) their referents are reclaimed. This is a dummy form of lazy loading. The question is how the GC decides which SoftReference to collect (based on size, heap time, random ???).

I used SoftReference for caching (in my case the jdbc calls results). Used with a syncro timer (scheduled refresh) it could be a quite simple and efficient caching method.

In this case you are not very portable (behavior may change) between platforms and java versions.
13 years ago
You do a lot of things here ....
Just an idea : Try to use a connection pool or use the same connection instead of opening each time a new db connection (this may take some time).

13 years ago
Don't forget NIOs with memory mapped files. Let your OS do the hard work (lazy loading / paging data / etc..).

Take a look :
13 years ago
This is quite strange. Static calls should be faster. What java version do you use. I've tested it on java 5&6 (on vista) and indeed static calls are faster.

14 years ago
Just curios ...could you re-do your test calling a final method (your implemented method is final ...or ..your implementig class is final). Basically I want to know if inlined methods changes something in your case.

14 years ago
There is no such thing (from java point of view) as a "native heap" so you don't have the equivalent of -Xmx and -Xms when using jni.
I think you are facing here an OS limitation. I don't know if this is a 32 bit restriction (you are able to address 2^32-1 - kernel, drivers, etc.. memory usage).
If i were you I will try to decrease your java heap (in order to free some native memory) or increase the windows virtual mem.

Keep us updated ... this is an interesting issue

14 years ago
I see some synchronized methods .....a well implemented immutable object is automatically thread-safe and have no synchronization issues

Do not forget that in theory an immutable object must:

* the class cannot be overridden so make it final
* all fields are private and final
* the object should be constructed completely in a single step (no setter methods)
* do not provide methods which can change the object

Yes indeed if you don't need high level methods you can forget the wrapper object (a useless ref of 2*4 byte on a 32 bit OS and 2*8 bytes on a 64 bit OS ).
14 years ago

This is normal because ther is no other that that may do a notify. In this case the jvm is smart and the wait call has no effect.

Try adding another thread :

Yes indeed the real memory address of un object is meaningless because the GC can move objects around in memory.
Anyway, for fun, take a look at the Unsafe class maybe this may do what you need.

14 years ago

You should implement a StringWrapper class (contructor with a string arg) that will convert the given string into a byte[] using the encoding "ISO-8859-1" (only 256 char (8 bit instead of 16 bit per char). Than you may use your wrapper in the list/map instead of strings.
14 years ago

1) If you need to cache something at the singleton level why is your map declared static (anyway you should have only one class instance - singleton).
2) The singleton pattern it's not well implemented and it is not thread safe. Please review your singleton implementation using a static init or using a ThradLocal + double checked lock.
In your case I bet that multiple class instances are created (no singleton) and every instance write/read in your static map. Using a HashMap in a multithreaded environment will create deadlock (cycles on its internal structures)