-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
-
b64
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8085647 | emb-9 | Hannes Wallnoefer | P4 | Resolved | Fixed | team |
| JDK-8087063 | 8u65 | Hannes Wallnoefer | P4 | Resolved | Fixed | b01 |
| JDK-8079469 | 8u60 | Hannes Wallnoefer | P4 | Resolved | Fixed | b16 |
| JDK-8138529 | emb-8u65 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8081188 | emb-8u60 | Hannes Wallnoefer | P4 | Resolved | Fixed | team |
Currently, the --persistent-code-cache option does not store outer script wrappers when optimistic types are enabled. Although this is a very thin wrapper class, not storing it will cause some parsing and code generation to take place, which shouldn't be necessary.
The only time we should not store the outer script is if optimistic types are enabled but lazy compilation is not, because in this case the outer script would likely contain lots of wrong assumptions that would do harm for later runs when optimistic types are used with lazy compilation (as it should be).
However, for non-optimistic types, lazy and non-lazy compilastion can be mixed in the code cache. In fact, a non-lazy compilation will probably be more efficient because it reads the whole script in one step.
The only time we should not store the outer script is if optimistic types are enabled but lazy compilation is not, because in this case the outer script would likely contain lots of wrong assumptions that would do harm for later runs when optimistic types are used with lazy compilation (as it should be).
However, for non-optimistic types, lazy and non-lazy compilastion can be mixed in the code cache. In fact, a non-lazy compilation will probably be more efficient because it reads the whole script in one step.
- backported by
-
JDK-8079469 Persistent code cache should support more configurations
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-