>> 4- [Informative] A class loader instance is also most likely to maintain >>... > This is not true. Look for the thread "[drlvm] Non-bug difference > HARMONY-1688?", where Eugene Ostrovsky desribed initiating loaders in > details with links to specification.
OK.
>> 7- Each class loader structure maintains a set of boolean flags, one
>>...
> Requires identification of object' class type during GC. Will most
> probably degrade GC performance.
Not necessarily. It really depends whether you want to "always" care
about class unloading, or if you only care about it when doing "major"
collections. Maybe you only want to unload classes on "full
collections", when all generations are collected. In such a case, you
would not do anything special (e.g. not maintain these bits) during any
other collection than full ones.
As for type identification, this is not necessarily required. You only
need to add a pointer in the vtable header (That's a 1-liner in SableVM)
that points to:
1- NULL for any class of an "unloadable class loader" (e.g. bootstrap,
system?)
2- ClassLoader structure, for ones that we wish to unload (user class
loader).
Maybe that's the "big" change to the vtable that was argued about in
this thread? If yes, the "bigness" of it was quite misleading to me;
such a change is a trivial one, to me. In SableVM, it's really just the
following change:
1- Add a field in the vtable "struct" in file type.h (1 line)
2- Initialize the field to non-zero for classes of non-bootstrap loader
(1 line).
No big deal...
As an additional optimization(???), one could set a bit in the object
header when the pointer (in the vtable) is not NULL, yet parsing the
bits might cost more that dereferencing the vtable pointer and checking
the field against NULL. [I know, this is most probably a very bad idea!]
You could even go further and only do class unloading when a special
request is made for it. This way, you don't do anything special during
normal collection. When the special request is done, you do a full GC
and unload any class (and loader) you can...
I guess that some of these ideas had already been somehow discussed on
this thread; I likely did misunderstand some of the few messages I read.
>> 8- Each method invocation frame maintains a hard reference to either its
>>...
> Not generally true for optimizing JITs. "This" (or "class") can be omitted
> from enumeration if it is not used anywhere in the code. Generally, this
> technique reduces number of registers used in the code ("register pressure"
> they call it :)).
OK. Yet, for correctness, you want to make sure that at any time you
want to unload classes, you do make sure that you take into account
classes of active methods. This can be achieved in various ways; I was
proposing one that was natural to SableVM. :-)
>> 9- A little magic is required to prevent premature collection of a class
>>...
> This requires more involvment of a GC in unloading process and affects GC
> code more. In DRLVM, GC is designed to be a replaceable component.
> Moreover,
> we already have 3 different working GCs and MMTk on the way. So, including
> GC into the design is not a good idea for DRLVM.
There is a dependency between GC and class unloading. Somehow, you must
be aware if there are still instances, around, of needed classes. You
don't need to "always" care for class unloading, while doing GC; as I
said above, you could reduce the overhead to well defined moments. [You
could have rules such that: at full collections, only, and no more than
once per 1hour | 10 minutes | ...
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
