java-gnome-hackers

[java-gnome-hackers] Considering Trove

[Andrew C. <an...@op...>]

I have for some time been very carefully watching the knownProxies
HashMap in [org.freedesktop.bindings] Plumbing.

This is the heart of java-gnome, mapping between our strong Java object
Proxy instances, and instantiated GObjects on the native side. Every
object [Widget, etc] that is created is stored there, in a <long, Proxy>
map.

Now, of course, Java's general utility collections require boxing of
keys which means every addition and every query into that table creates
a Long object wrapping the long [pointer address] as key. Lot of
allocations for nothing, really, not to mention all the Map.Entry
objects that get created.

We have had memory pressure there before (which is why we split Proxy
into Proxy & Pointer, for example). And while it's not the largest
hotspot we have right now, essentially *every single code path* in
java-gnome goes through this table.

As a result I have long speculated that we should replace the
[java.util] HashMap with something a bit smarter, preferably something
that takes long primitives as keys, not Long objects as keys.

++

One possibility is the Trove project, a promising set of collections
that use different algorithms to the [java.util] ones, and which offer
sets and maps with native keys and/or values.
http://trove4j.sourceforge.net/

I did some experimentation and came up with a branch that uses their
TLongObjectHashMap for the knownProxies map. I uploaded it to
'hackers/andrew/trove-external' so you can have a play if you're
interested. It will configure and build if you're on Ubuntu Karmic.
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/trove-external/

Works fine; I'm still trying to figure out if it's an improvement [or
degradation] profiling wise (we need some better tools for this sort of
thing); doing compartive studies of GUI application performance is
notoriously hard, of course.

++

Anyway, there is a bigger question: should we use this, and if we do,
should we incur the cost of an external dependency?

This is a non-trivial question. Not only would it mean "java-gnome build
depends on trove4j", but of course *also* would mean requiring people to
express the location of the trove jar when trying to run a program built
with java-gnome; ie just to run a demo program I had to go from

java -classpath /home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment

to 

java -classpath /usr/share/java/trove-2.0.4.jar:/home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment

{sigh}

[Java's design is so desperately lacking in this regard it's not even
funny; doing something about it is on my list of itches, but that's not
something any of us are going to fix overnight]

There is an alternative, and that would be to import the necessary
[gnu.trove] classes (only) into java-gnome, placing it say in
lib/dependencies/. I'm *not*a huge fan of this idea; I've spent enough
time as a Gentoo Java person to know how much effort we usually have to
spend ripping out embedded junits, jaxens, etc and how horrible static
linking is, etc.

Indeed, it's time Java people stopped being afraid of depending on each
other's code, so perhaps I should just bite the bullet, say "too bad"
and tell people that we now depend on this [or whichever] library. But
given that it is essentially just one single piece of Trove  that we
would be depending on, it is almost tempting to just embed it in our
code base.

++

Anyway, I'd welcome some discussion on all this, both on the topic of
the suitability of Trove's [gnu.trove] TLongObjectHashMap as a
replacement for Sun's [java.util] HashMap, and on the question of other
Java libraries as dependencies.

I'd like to thank Rob Eden, the current Trove maintainer, for his
guidance and encouragement.

AfC
Sydney


-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Fwd: Considering Trove

[Leonardo <som...@gm...>]

---------- Forwarded message ----------
From: Leonardo <som...@gm...>
Date: 2009/10/23
Subject: Re: [java-gnome-hackers] Considering Trove
To: Andrew Cowie <an...@op...>


No Andrew,

Avoid to add another dependency,

See, java gnome is somewhat stable for some years in the java side,
just adding dependencies in the gtk land.

You will have a finite ammount of widgets, i don't believe that one
could do some nasty and stupid application able to blow the memory
just with buttons, :P

if use primitives for keys still a good idea after fine tests don't
add it as dependency, but extract it directly for java-gnome, and only
that class.

belive me when i say that add another jar is a lot bad.

2009/10/23 Andrew Cowie <an...@op...>:
> I have for some time been very carefully watching the knownProxies
> HashMap in [org.freedesktop.bindings] Plumbing.
>
> This is the heart of java-gnome, mapping between our strong Java object
> Proxy instances, and instantiated GObjects on the native side. Every
> object [Widget, etc] that is created is stored there, in a <long, Proxy>
> map.
>
> Now, of course, Java's general utility collections require boxing of
> keys which means every addition and every query into that table creates
> a Long object wrapping the long [pointer address] as key. Lot of
> allocations for nothing, really, not to mention all the Map.Entry
> objects that get created.
>
> We have had memory pressure there before (which is why we split Proxy
> into Proxy & Pointer, for example). And while it's not the largest
> hotspot we have right now, essentially *every single code path* in
> java-gnome goes through this table.
>
> As a result I have long speculated that we should replace the
> [java.util] HashMap with something a bit smarter, preferably something
> that takes long primitives as keys, not Long objects as keys.
>
> ++
>
> One possibility is the Trove project, a promising set of collections
> that use different algorithms to the [java.util] ones, and which offer
> sets and maps with native keys and/or values.
> http://trove4j.sourceforge.net/
>
> I did some experimentation and came up with a branch that uses their
> TLongObjectHashMap for the knownProxies map. I uploaded it to
> 'hackers/andrew/trove-external' so you can have a play if you're
> interested. It will configure and build if you're on Ubuntu Karmic.
> bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/trove-external/
>
> Works fine; I'm still trying to figure out if it's an improvement [or
> degradation] profiling wise (we need some better tools for this sort of
> thing); doing compartive studies of GUI application performance is
> notoriously hard, of course.
>
> ++
>
> Anyway, there is a bigger question: should we use this, and if we do,
> should we incur the cost of an external dependency?
>
> This is a non-trivial question. Not only would it mean "java-gnome build
> depends on trove4j", but of course *also* would mean requiring people to
> express the location of the trove jar when trying to run a program built
> with java-gnome; ie just to run a demo program I had to go from
>
> java -classpath /home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> to
>
> java -classpath /usr/share/java/trove-2.0.4.jar:/home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> {sigh}
>
> [Java's design is so desperately lacking in this regard it's not even
> funny; doing something about it is on my list of itches, but that's not
> something any of us are going to fix overnight]
>
> There is an alternative, and that would be to import the necessary
> [gnu.trove] classes (only) into java-gnome, placing it say in
> lib/dependencies/. I'm *not*a huge fan of this idea; I've spent enough
> time as a Gentoo Java person to know how much effort we usually have to
> spend ripping out embedded junits, jaxens, etc and how horrible static
> linking is, etc.
>
> Indeed, it's time Java people stopped being afraid of depending on each
> other's code, so perhaps I should just bite the bullet, say "too bad"
> and tell people that we now depend on this [or whichever] library. But
> given that it is essentially just one single piece of Trove  that we
> would be depending on, it is almost tempting to just embed it in our
> code base.
>
> ++
>
> Anyway, I'd welcome some discussion on all this, both on the topic of
> the suitability of Trove's [gnu.trove] TLongObjectHashMap as a
> replacement for Sun's [java.util] HashMap, and on the question of other
> Java libraries as dependencies.
>
> I'd like to thank Rob Eden, the current Trove maintainer, for his
> guidance and encouragement.
>
> AfC
> Sydney
>
>
> --
> Andrew Frederick Cowie
>
> Operational Dynamics is an operations and engineering consultancy
> focusing on IT strategy, organizational architecture, systems
> review, and effective procedures for change management: enabling
> successful deployment of mission critical information technology in
> enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>