harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Kuznetsov" <boris.v.kuznet...@gmail.com>
Subject Re: Re: [classlib] TwoKeyHashMap
Date Mon, 24 Jul 2006 11:58:54 GMT
In the JSSE provider TwoKeyHashMap is used to store objects in the
session's application layer data (see javax.net.ssl.SSLSession spec).
The name and access control context are used as keys in TwoKeyHashMap
(according the spec. the same named values may not be visible across
different access control contexts).

Removing of TwoKeyHashMap and using other proposed scenario may slow
down the applications that intensively use objects bounded to the SSL
session.

Surely TwoKeyHashMap may be replaced by other techniques.  But it is
more effective than using of key wrapper object or 'map of maps'.
Removing is a simple solution but I believe TwoKeyHashMap also can be
used in other cases to improve performance.

Thanks,
Boris

On 7/24/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
> I would definitely agree these sentiments. Optimization, especially of this
> kind, should only take place after correct implementation (which I assume we
> already have) and significant negative side-effects can be shown. This
> mechanism of optimization just increases the amount of code maintenance and
> amount of quality assurance. In cases like this, I prefer to lean towards
> simplicity.
>
> In any case, there are numerous other approaches to handling the two-key
> scenario:
> * As Alex and other have mentioned, just use a simple wrapper object with
> correct equals/hashCode.
> * If you'd rather avoid that object creation, you can use the first key to
> link to a embedded Map, where you use the second key to link to the desired
> object.
> * If the data set is fairly small, like I imagine this is, then you could
> just use a two-dimensional array and just do brute force searches. This
> could be optimized further by keeping the array sorted and using binary
> searches.
>
> -Nathan
>
> > -----Original Message-----
> > From: Alex Blewitt [mailto:alex.blewitt@gmail.com]
> > Sent: Sunday, July 23, 2006 3:22 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: Re: [classlib] TwoKeyHashMap
> >
> > I don't think that it makes sense to maintain a completely separate
> > data structure just because there's a pair of keys. An object that
> > holds two values will do the job just as well, and there should be no
> > problem with an object being created, used for a lookup, and then
> > recycled in the nursery generation. On the other hand, having a
> > separate algorithm is more likely to result in duplicated information
> > and maintenance.
> >
> > This sounds like premature optimisation to me. After all, how many
> > lookups are being performed in the crypto framework? If it's just a
> > pairing of (say) provider/hash algorithm, how frequently is it being
> > used? Do we have any stats that show the bottleneck is on the access
> > of a value from the hashmap?
> >
> > Alex.
> >
> > On 23/07/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > > It's created for performance optimization. Without it a new object has
> > to be
> > > created every time a record is seeked in a hashmap.
> > >
> > > it's used in crypto framework and JSSE provider.
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/7/22, Geir Magnusson Jr <geir@pobox.com>:
> > > > If it's not being used anywhere, and if no one claims it, +1
> > > >
> > > > (and if it's being used and can be replaced.... +1)
> > > >
> > > > Nathan Beyer wrote:
> > > > > I'm all for removing it. The last time I looked through that code
I
> > came to
> > > > > the same conclusion your questions infer. If I recall correctly,
> > some of the
> > > > > actual Map interface methods won't even work correctly if used.
> > Also, I
> > > > > believe the actual keys were just Strings, so concatenated Strings
> > could
> > > > > even be used.
> > > > >
> > > > > -Nathan
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > > >> Sent: Friday, July 21, 2006 11:52 AM
> > > > >> To: harmony-dev
> > > > >> Subject: [classlib] TwoKeyHashMap
> > > > >>
> > > > >> Does anyone know why we have a TwoKeyHashMap [1] utility class?
> > > > >>
> > > > >> I've only looked at it briefly, but I'm left wondering why the
> > author
> > > > >> chose to write all that rather than use a regular HashMap with
an
> > object
> > > > >> that combines the 'TwoKey's?
> > > > >>
> > > > >> There may be a subtlety I missed.  Anyone know?
> > > > >>
> > > > >> [1]
> > > > >>
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> > > > >>
> > ules/luni/src/main/java/org/apache/harmony/luni/util/TwoKeyHashMap.java?vi
> > > > >> ew=co
> > > > >>
> > > > >> Regards,
> > > > >> Tim
> > > > >>
> > > > >> --
> > > > >>
> > > > >> Tim Ellison (t.p.ellison@gmail.com)
> > > > >> IBM Java technology centre, UK.
> > > > >>
> > > > >> -------------------------------------------------------------------
> > --
> > > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > >> To unsubscribe, e-mail: harmony-dev-
> > unsubscribe@incubator.apache.org
> > > > >> For additional commands, e-mail: harmony-dev-
> > help@incubator.apache.org
> > > > >
> > > > >
> > > > > --------------------------------------------------------------------
> > -
> > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: harmony-dev-
> > help@incubator.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Best regards,
Boris Kuznetsov
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message