Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Andrei Matyas

Greenhorn
+ Follow
since Apr 15, 2007
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
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



7 years ago
Hello )

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

WeakReferences

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.

SoftReferences

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.
10 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).

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

http://en.wikipedia.org/wiki/Memory-mapped_file
10 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.


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

10x
10 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



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

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 ).
10 years ago
Hello,

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.


10 years ago
Hello,

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.
10 years ago
Hello,

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)