Skip to content

Call the soon-to-exist Global#close when done compiling#3261

Closed
retronym wants to merge 1 commit intosbt:0.13from
retronym:topic/close-compiler
Closed

Call the soon-to-exist Global#close when done compiling#3261
retronym wants to merge 1 commit intosbt:0.13from
retronym:topic/close-compiler

Conversation

@retronym
Copy link
Member

Scala 2.13.3 is likely to have a new method, Global.close.
This will let the compiler release resources, notably file
handles to JARs on the classpath.

This commit calls changes the compiler interfaces to call this
method, falling back to a no-op extension method for backwards
compatibility.

Furthermore, it changes the API to the global cache to let
the caller hand back the compiler instance. By default, this
compiler cache is a no-op (GlobalCache.fresh), and this is
where I've added the close call.

The other code path does not close the Global. AFAIK, caching
global instances (enabled with sbt -Dsbt.resident.limit=<N>)
a unfinished experiment and and not use in the wild. For instance,
I don't see how the current implementation ensures single threaded
access to the cached global instances, I would have expected a
check-out/check-in protocol to deal with that.

In any case, that code path is untouched under this patch.

Scala 2.13.3 is likely to have a new method, `Global.close`.
This will let the compiler release resources, notably file
handles to JARs on the classpath.

This commit calls changes the compiler interfaces to call this
method, falling back to a no-op extension method for backwards
compatibility.

Furthermore, it changes the API to the global cache to let
the caller hand back the compiler instance. By default, this
compiler cache is a no-op (`GlobalCache.fresh`), and this is
where I've added the `close` call.

The other code path does not close the Global. AFAIK, caching
global instances (enabled with `sbt -Dsbt.resident.limit=<N>`)
a unfinished experiment and and not use in the wild. For instance,
I don't see how the current implementation ensures single threaded
access to the cached global instances, I would have expected a
check-out/check-in protocol to deal with that.

In any case, that code path is untouched under this patch.
@retronym
Copy link
Member Author

Marking as on hold so we can perform an end-to-end test after the compiler change.

See scala/bug#10295 / https://github.com/retronym/scala/tree/ticket/10295

@jvican
Copy link
Member

jvican commented Jul 19, 2017

The other code path does not close the Global. AFAIK, caching global instances (enabled with sbt -Dsbt.resident.limit=) a unfinished experiment and and not use in the wild.

This has been removed in Zinc 1: sbt/zinc#340

@dwijnand
Copy link
Member

dwijnand commented Jun 4, 2018

I think we should look to improve the performance of sbt 1 rather than sbt 0.13.

As such, I think we should close this.

@dwijnand dwijnand closed this Jun 4, 2018
@retronym
Copy link
Member Author

retronym commented Feb 26, 2019

@jvican

This has been removed in Zinc 1: sbt/zinc#340

I think the removal was incomplete.

SBT still has logic around sbt.resident.limit and Zinc still includes the cache of Globals.

@jvican
Copy link
Member

jvican commented Feb 26, 2019

SBT still has logic around sbt.resident.limit

Yes, though IIRC it's disabled by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants