On Wed, 29 Jul 2026 04:14:42 GMT, Prasanta Sadhukhan <[email protected]>
wrote:
>>>In the original bug the decrease in memory footprint achieved by clearing
>>>these intermediate vectors was minimal compared to other changes.
>>
>> It still bumps the required memory significantly in some cases after the
>> patch if there are no gaps, no? My point was not about an additional
>> optimization, but instead about replacing this logic of cleaning on each gap
>> with cleaning("absorb") "on add".
>
> I think @mrserb has a point...for input with one continuous Y-range,
> subcurves and chains are retained until the entire operation completes..valid
> paths with no gap can therefore consume substantially more heap and
> potentially OOM..
> is it possible that we retain LINK_COUNT code for y with no-gap and if there
> is a gap, we consume it..
I have removed the optimization which was added in this PR for y-gap scenarios.
Reverting this has again no to minimal impact on the original bug JBS-8364373.
Any optimization related to consuming vectors in pruneEdges() will be handled
under https://bugs.openjdk.org/browse/JDK-8389326.
In this bug we are only fixing the newly introduced functional regression with
minimal impact to fix under JBS-8364373.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31971#discussion_r3673979086
