There are 7 int arrays of size the number of objects, so that is big
memory requirement for MAT. The tricky part is ensuring correctness while
efficiently parallelizing this code without excessive locking. Reducing
the memory requirements would be good, as currently this requires 56GB of
RAM for the MAT limit of 2^31 objects.
Hi Andrew
I think we can resolve this by switching to memory-mapped backing for the dominator tree, which should be a straightforward switch. I put up a bug some time back (# 572512); if you are interested I could tidy it up and put something together that allows use of memory-mapped files for sort and should significantly reduce heap space (at the cost of additional 'swapping' is extremely tight).
I think the questions I'd have are: How do we ensure that the correct storage location is used, should it be configurable or automatic, etc.
Did you have any alternative ideas to reduce memory footprint for the algorithm?
In my view we're probably going to need some sort of custom Array storage layer to have more than 2^31 object heaps processed, this might be a place we could experiment with a subset of the API.
Thanks
Jason
As building a dominator tree is a standard computer science problem
someone should first review the literature for any improved algorithms.
--
Andrew Johnson
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mat-dev
