Artur Biesiadowski <[EMAIL PROTECTED]> writes:
> Sorry to touch this subject once again - I understand that all of
> these are temporary hacks, but hacks have a tendency to stay for a
> long time (look at MSDOS :).
Classpath's NSA library is not a temporary hack. It exists for
compatibility with Sun's JDK, and any other VMs which lack a VM-level
implementation of NSA. It's very portable, fast, and gracefully
handles collisions.
Japhar has implemented NSA at the VM level. We'll eventually get
around to using it. :)
> Would it be easier/faster to: - use int field for pointer to native
> data (cause problems on 64-bit platform - but good for testing)
This hampers portability.
> - same as above but use long field
This hampers speed, and we loose on any (future) >64 bit platforms.
> - use int field - on 32bit platform direct pointer, on 64 bit
> hashcode for hashtable
This would probably be a good change, if someone wanted to do the
work. It would improve the speed of NSA on 32 bit platforms, but the
Classpath NSA library's primary purpose is to provide backwards
compatibility for Sun's JDK. Our primary focus should be the free
VMs, which already provide NSA support at the VM-level.
> - instead of identity hashcode just use static counter - this way we
> will get nice coverage of all values - no hash conflicts for long
> time
This would be no better than our current implementation.
> - or call for identityHashcode each time - this way native state lib
> is really independent on class.
This is slow -- very slow.
> BTW, does anybody work on java.awt classes, or any of java.awt
> subpackages ?
No one currently. Jim and myself will start work on these after the
GTK+ AWT is finished. We're fairly busy with school at the moment, as
exam time is rapidly approaching.
--
Paul Fisher * [EMAIL PROTECTED]
