Skip to content

Test for memory leaks #29

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
VladUreche opened this issue Feb 24, 2014 · 5 comments
Closed

Test for memory leaks #29

VladUreche opened this issue Feb 24, 2014 · 5 comments
Assignees
@VladUreche
Labels
itype:enhancement

Comments

@VladUreche
Copy link
Contributor

When compiling multiple times:

  • keep a weak reference to the existing RootContext
  • after compiling, do System.gc()
  • assert that the weak reference is dead, so the RootContext was gc-ed
  • later refinement: use yourkit api to print out the links from the root (alive) objects to the objects that were supposed to be dead
@VladUreche VladUreche self-assigned this Feb 24, 2014
@VladUreche
Copy link
Contributor Author

Tentatively assigned to myself, but please feel free to take over the bug.

@dragos
Copy link

dragos commented Feb 24, 2014

I think it's probably better to be more fuzzy about it. We have a memory leaks test in the IDE.

@VladUreche
Copy link
Contributor Author

Yes, it would be good to also have a memory cap test (which should be fuzzy) -- I may be wrong but I think @axel22 has this already working in scalameter.

@DarkDimius
Copy link
Contributor

I have implemented Weak-tracking of Context's during all DottyTests. I believe that it's a better idea than to write customs tests.
https://github.com/DarkDimius/dotty/tree/leaks
But this implementation requires an unreleased build of junit-interface.
Please also note that at least one context always persists as some objects(eg NoDenotation) capture last seen context.

@DarkDimius
Copy link
Contributor

Merged and run with every test.
That's a hack that could show false positives, but I haven't seen them after half a year.

noti0na1 added a commit to noti0na1/dotty that referenced this issue Oct 17, 2019
@noti0na1
Merge pull request scala#29 from noti0na1/dotty-explicit-nulls-small
d4df9e7 
Inline Nullify Policies in JavaNullInterop; combine two TypeMap
@chrislailee chrislailee mentioned this issue Jun 18, 2021
Closed
odersky referenced this issue in dotty-staging/dotty Jun 10, 2022
@odersky
Speed up .nn
2c6590d 
Some tests by Matt had cases where `.nn` figured prominently in the flamegraph.
I optimized it so that the fast path is streamlined and inlined.

In the following test code:
```

  def x: String | Null = "abc"
  val y = x.nn
```
the new implementation is
```
      10: getstatic     #20                 // Field MODULE$:LTest$;
      13: invokevirtual #24                 // Method x:()Ljava/lang/String;
      16: astore_0
      17: getstatic     #29                 // Field scala/runtime/Scala3RunTime$.MODULE$:Lscala/runtime/Scala3RunTime$;
      20: aload_0
      21: invokevirtual #33                 // Method scala/runtime/Scala3RunTime$.nn:(Ljava/lang/Object;)Ljava/lang/Object;
      24: checkcast     #35                 // class java/lang/String
      27: putstatic     #37                 // Field y:Ljava/lang/String;
```
The previous implementation was two bytes shorter, but contained in the critical path

 - A call to a ScalaRuntime method, which was not inlineable by the JIT compiler due to its size,
 - A conversion of a cmparison to a Boolean value (not sure this matters)
 - A cast from the return type `Object` to the actual type.
pikinier20 added a commit that referenced this issue Aug 16, 2022
@pikinier20
Merge pull request #29 from pikinier20/scaladoc/new-ui-scastie
a688472 
Scastie support
bishabosha referenced this issue in dotty-staging/dotty Oct 18, 2022
@odersky @bishabosha
Speed up .nn
38efc41 
Some tests by Matt had cases where `.nn` figured prominently in the flamegraph.
I optimized it so that the fast path is streamlined and inlined.

In the following test code:
```

  def x: String | Null = "abc"
  val y = x.nn
```
the new implementation is
```
      10: getstatic     #20                 // Field MODULE$:LTest$;
      13: invokevirtual #24                 // Method x:()Ljava/lang/String;
      16: astore_0
      17: getstatic     #29                 // Field scala/runtime/Scala3RunTime$.MODULE$:Lscala/runtime/Scala3RunTime$;
      20: aload_0
      21: invokevirtual #33                 // Method scala/runtime/Scala3RunTime$.nn:(Ljava/lang/Object;)Ljava/lang/Object;
      24: checkcast     #35                 // class java/lang/String
      27: putstatic     #37                 // Field y:Ljava/lang/String;
```
The previous implementation was two bytes shorter, but contained in the critical path

 - A call to a ScalaRuntime method, which was not inlineable by the JIT compiler due to its size,
 - A conversion of a cmparison to a Boolean value (not sure this matters)
 - A cast from the return type `Object` to the actual type.
szymon-rd pushed a commit that referenced this issue Dec 9, 2022
@kamilszewczyk0
Merge pull request #29 from szymon-rd/filters-rebuild
d3c9e8e 
fix clearing filters and filter search optimalization
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@VladUreche VladUreche

Labels
itype:enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dragos @VladUreche @DarkDimius