Hi Again,
I also have a comment on the implementation of the hash table and it's
GC-ness. You keep the string pool under a SoftReference because it is
the biggest object so it makes most sense to clear it when heap becomes
full. Other arrays are kept strongly reachable, but you re-generate the
Hi Sherman,
I don't currently have any idea how to squeeze the hashtable any more
further. It is already very compact in my opinion. But I noticed a data
race that could result in navigating the half-initialized data
structure. It is a classical unsafe publication bug. It has been present
bef
Hi Peter,
Thanks for the review and suggestion.
This appears to be a better approach. I was wondering if I should go
this way to cache
those lookup tables as well, but ...
Webrev has been updated as suggested.
Thanks!
Sherman
On 2/3/16 3:26 AM, Peter Levart wrote:
Hi Again,
I also have a
Hi,
Have not heard any feedback on this one so far. I'm adding
a little more to make it attractive for reviewers :-)
On top of the \N now the webrev includes the proposal to add
two more matchers, \X for unicode extended grapheme cluster
and \b{g} for the corresponding boundary.
Issue: https://
