Changing the subject to not hijack the thread...
On 11/25/2015 01:54 PM, Andrew Haley wrote:
On 11/25/2015 12:39 PM, Peter Levart wrote:
What do you think?
It's very problematic. First off, collection often clears the young
generation altogether, promoting everything.
This could be a best-effort algorithm. If it must clear the young
generation, it would. User would have to size it accordingly to
accommodate for extra space needed by direct ByteBuffers staying in the
young gen forever.
Secondly, I think we are
already short of header bits in some cases.
How many bits are there for object age? 4 ? This means 16 values. If one
value is "reserved" for eternally-young objects, there would still be 15
values for normal operation.
Thirdly, this requires
all collectors to be changed.
Why? For start, only the most popular collector used in those
applications could be modified and the feature could be optional
(guarded by switch). API calls would be no-ops in unsupported collectors
or when the feature is not enabled.
Fourthy, some collectors don't use
multiple generations: they can just allow a dense prefix to pile up at
the left-hand end of the heap which they don't bother to collect.
Those would not be supported.
Etc, etc...
Maybe. Would have to dive into VM to find out. ;-)
Andrew.
Regards, Peter
