Re: INTERN_UTF8CONSTS

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Fri Dec 18 1998 - 12:29:03 EST


>
> I suggest we either remove it or implement it - but stop it being
> optional. I would suggest it was implemented since it's ave lots of
> memory in the constant pool.
>

That would be because we would not duplicate identical utf8 from
different files, right? That would indeed be very beneficial.
Btw, we might want to consider a scheme where we do not need to
keep them at all, for instance, by replacing them with some kind
of hash coding.

I don't understand all the issues involved here, but I have a few questions:

+ should the pool for interned java strings and interned utf8 be the same?
  I believe in the old framework, it was.

+ what limits should be imposed? Remember that a statically limited or
  dynamically growing table is not acceptable in the long run; we need to
  use weak references just like JDK 1.2 does. Edouard sent a test
  program to that effect a while ago.

+ does or should the question of whether utf8 are interned have any impact
  on files outside of string.c. I would very much like it if that were
  not the case --- it's just too errorprone.

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:22 EDT