P2
FULL PRODUCT VERSION :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
FULL OS VERSION :
Darwin Bobs-MacBook-Pro.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64
A DESCRIPTION OF THE PROBLEM :
Memory grows out of control running jEdit.
I use jEdit on Windows, Linux, and Mac-OS. This problem is occurring only with Java8 on Mac-OS, not on Windows. Since Java8 I haven't used Linux, so no data on that.
I tend to start jEdit and leave it running for weeks at a time. This has worked fine for years, and has not been a problem until Java8 on Mac-OS. It starts out OK, but in a day or two the memory grows to gigabytes, causing serious "memory stress" on my Mac. This does not happen with Java7, so my workaround is to use Java7. Under Java7 the memory stabilizes at under a gig.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
REGRESSION. Last worked in version 7u55
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Install and start jEdit (jedit.org).
Leave it running for a couple of days. Some mild usage might be required. I think there might be a pattern of it happening after a nights sleep.
Observe continuous memory growth. I use the Mac Activity Monitor to check.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: memory to grow to just under a gig and stabilize. (Under J7 it starts out at, say 900M, and later reduces to around 600M.)
Actual: memory grows boundlessly,
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Observe excessive memory growth using Mac Activity Monitor.
System slows to a crawl after a couple of days on my system (8G main memory).
No error messages.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
N/A -- program causing error is jEdit 5.1 or jEdit5.2pre. (Mac shortcut keys do not work with jEdit 5.1)
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Use Java7, not Java8,
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
FULL OS VERSION :
Darwin Bobs-MacBook-Pro.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64
A DESCRIPTION OF THE PROBLEM :
Memory grows out of control running jEdit.
I use jEdit on Windows, Linux, and Mac-OS. This problem is occurring only with Java8 on Mac-OS, not on Windows. Since Java8 I haven't used Linux, so no data on that.
I tend to start jEdit and leave it running for weeks at a time. This has worked fine for years, and has not been a problem until Java8 on Mac-OS. It starts out OK, but in a day or two the memory grows to gigabytes, causing serious "memory stress" on my Mac. This does not happen with Java7, so my workaround is to use Java7. Under Java7 the memory stabilizes at under a gig.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
REGRESSION. Last worked in version 7u55
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Install and start jEdit (jedit.org).
Leave it running for a couple of days. Some mild usage might be required. I think there might be a pattern of it happening after a nights sleep.
Observe continuous memory growth. I use the Mac Activity Monitor to check.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: memory to grow to just under a gig and stabilize. (Under J7 it starts out at, say 900M, and later reduces to around 600M.)
Actual: memory grows boundlessly,
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Observe excessive memory growth using Mac Activity Monitor.
System slows to a crawl after a couple of days on my system (8G main memory).
No error messages.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
N/A -- program causing error is jEdit 5.1 or jEdit5.2pre. (Mac shortcut keys do not work with jEdit 5.1)
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Use Java7, not Java8,