[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-11 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805726#comment-17805726
 ] 

ASF GitHub Bot commented on GROOVY-11271:
-

daniellansun merged PR #2030:
URL: https://github.com/apache/groovy/pull/2030




> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Jochen Theodorou (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804416#comment-17804416
 ] 

Jochen Theodorou commented on GROOVY-11271:
---

[~emilles] See 
https://blog.mrhaki.com/2013/11/groovy-goodness-cache-methods.html. in case of 
for example @Memoized(maxCacheSize = 2) a LRU of size 2 is used. If now many 
threads read the memoized results and change the order of what is last recently 
used, this can result in the described problem.

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804358#comment-17804358
 ] 

Eric Milles commented on GROOVY-11271:
--

Can someone explain where this gets used?  What features are impacted by this 
flaw in {{ConcurrentCommonCache}}?

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Daniel Sun (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804349#comment-17804349
 ] 

Daniel Sun commented on GROOVY-11271:
-

{quote}
This is correct, but then it is not much better than a synchronized collection
{quote}

[~blackdrag] After trading off between function and performance, I chosen the 
{{ConcurrentLinkedHashMap}} instead of {{synchronized}} when LRU is enabled.

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804347#comment-17804347
 ] 

ASF GitHub Bot commented on GROOVY-11271:
-

daniellansun opened a new pull request, #2030:
URL: https://github.com/apache/groovy/pull/2030

   https://issues.apache.org/jira/browse/GROOVY-11271




> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Jochen Theodorou (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804244#comment-17804244
 ] 

Jochen Theodorou commented on GROOVY-11271:
---

[~daniel_sun] This is correct, but then it is not much better than a 
synchronized collection

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Daniel Sun (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804211#comment-17804211
 ] 

Daniel Sun commented on GROOVY-11271:
-

The fastest way to fix the issue is abandoning the usage of read lock and use 
write lock instead.

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.

2024-01-08 Thread Jochen Theodorou (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804198#comment-17804198
 ] 

Jochen Theodorou commented on GROOVY-11271:
---

to add ore details: 
https://github.com/apache/groovy/blob/5a3cf7c86feacc6f257cc72942e6ef8789920cf4/src/main/java/org/codehaus/groovy/runtime/memoize/CommonCache.java#L67
This creates a CommonCache where accessOrder is set to true and then any get 
call on the underlying LinkedHashMap can cause a write change, not covered  
appropriately by the checks.
[~sunlan] This looks like a bigger change will be required to fix this

> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
>  Issue Type: Bug
>  Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a 
> thread-safe data structure. However, CommonCache uses the underlying 
> LinkedHashMap, which causes conflicts when using the LRU algorithm because 
> the LinkedHashMap.get method modifies the internal linked list. This 
> conflicts with the read lock used by the get method in ConcurrentCommonCache 
> when multiple threads access it. Due to multithreading conflicts, the maximum 
> cache size of 64 becomes ineffective, ultimately causing memory leaks. 
> Additionally, we have already encountered memory leaks in our production 
> environment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)