JoinPointImpl: Remove thread-locals after usage, where possible
Avoid potential ThreadLocalMap.Entry accumulation. Entry is a
WeakReference. When JoinPointImpl objects are collected by GC, Entry
instances are still be referenced by ThreadLocalMap, which leads to
memory pressure and potentially more full GCs. So, we proactively remove
ThreadLocal<Integer> arcIndex instances when arcIndex has been
decremented back to -1 per thread. This is not perfect, because not each
thread can be expected to proceed, but it should ameliorate the
situation to some degree.
Fixes #302.
Co-authored-by: Alexander Kriegisch <Alexander@Kriegisch.name> Signed-off-by: KimmingLau <294001791@qq.com> Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Revert WeavingAdaptor generated class map optimisation
This was introduced in commit 8a4aa03845 of PR #278 contribution as part
of the #279 fix. The contributor thought that the generated closure
class entries were never used, but in fact AJDT class OSGiWeavingAdaptor
relies on the presence of those entries.
To the best of my present knowledge, it looks as if this change was the
root cause of https://github.com/eclipse-aspectj/ajdt/issues/57.
Therefore, I reverted it, simultaneously refactoring Iterator::remove
usage to delete entries from the map to Collection::removeIf.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Add some code comments and javadoc for SimpleCache::getAndInitialize
- Add TODO to migrate from using ClassLoader::defineClass to the class
definition strategy used in ClassLoaderWeavingAdaptor
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Relates to #117. In commit f986c3d183, the asm-commons dependency became
necessary to pull off the new trick to define classes in arbitrary class
loaders during LTW. The dependency was added to aspectjweaver, but not
to aspectjtools due to an oversight. As aspectjtools is meant to be a
super set of aspectjweaver, add the dependency to the assembly
descriptor.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Raise ClassLoaderWeavingAdaptor::defineClass visibility to protected
Relates to https://github.com/eclipse-aspectj/ajdt/issues/57 and it a
precondition for refactoring phase 2 of child class
OSGiWeavingAdaptor::defineClass, which can now directly call the super
methods instead of using reflection.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The tests from Java 21 were copied to 22. Inactive ones were activated
after their features under test were fixed/implemented. Preview ones
were promotes to final ones for unnamed variables and patterns.
TODO: Add tests for new Java 22 features and maybe adjust or
amend existing feature tests, if preview or final characteristics have
changed since Java 21.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Initially, these tests made sure that an old AJC bug causing
incompatibility to ECJ when using `-proceedOnError` was fixed and there
were no regressions. See also:
Now with the Java 22 changes for JEP 463 "Implicitly Declared Classes
and Instance Main Methods (Second Preview)" in JDT Core, source code is
parsed into a significantly different AST structure than before, even
when using compiler targets < 22. See also https://openjdk.org/jeps/463.
One test has been temporarily adjusted to the byte code created by
ECJ/AJC now.
TODO: Revert/adjust after this upstream bug has been
fixed:
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2205 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The default is 2 in Asciidoctor. A higher TOC level enables developers
and users to post more precise deep-links into docs. In PDF versions, it
is also easier now to navigate from the TOC to a specific subchapter.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
If any of the old Ant builds, e.g. tests/profiling/build.xml, which
have never been mavenised, need JDT Core, they should be converted to
Maven builds and refer to it as a regular dependency. As is, the Ant
builds would not run anyway, because other dependency locations have
changed as well.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In AtAjAnnotationGenTests.testRuntimePointcutsReferencingCompiledPointcuts,
the classpath issues mentioned in the comments do not seem to exist
anymore, with or without the removed lib/bcel/bcel.jar.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove Apache Commons from 'lib' module, update remaining dependencies
Of beanutils, collections, digester and logging actually only digester
and logging are directly used in AspectJ code. Therefore, remove the
unused ones and upgrade the remaining libraries' versions to ones which
also have source JARs on Maven Central. This makes downloading sources
from GitHub and packaging separate commons.jar and commons-src.zip
artifacts superfluous. Hence, we can get rid of them completely.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Throw exception for minimal AJC runtime version violation
When running AJC, throw an AbortException(MINIMAL_JRE_VERSION) instead
of just logging an error, if the minimal JRE version requirement is
violated. Otherwise, in-process compilation would not fail due to the
skipped System.exit(-1) that was used before. In-process compilation is,
for example, relevant for AspectJ Maven Plugin, but also for non-forked
executions of Plexus AspectJ via Maven Compiler.
I am not 100% sure that AbortException is the appropriate exception
type, because it was designed for an aborted compilation process and
here compilation has not even started yet, but it seems to work fine.
Relates to #269.
Fixes #292.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
according to https://rules.sonarsource.com/java/tag/leak/RSPEC-5164/.
Now, there no longer is a thread-local stack of AroundClosure instances,
but rather a list of them, which can only grow but never shrink.
Instead, we now have a thread-local (integer) list index, for every
thread being initialised with pointing to the last element. I.e., every
thread can unwind by decrementing the index while proceeding,
independently of other threads.
A positive side effect is that this approach also works for long-lived
threads from thread pools, used by executor services. Hence, test
Bugs199Tests.testAsyncProceedNestedAroundAdviceThreadPool_gh128, which
was previously commented out, has been activated and passes, see #141.
I am not sure if this brings @AspectJ style, non-inlined, nested around
advice execution functionally on par with native ones, but at least for
current scenarios it seems to work.
Fixes #288, #141.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add regression tests for inheritable thread-local memory leak
Leak was introduced in commit 3c80a36527, fixing #128, but introducing
#288 instead, which was the lesser of two evils, but still bad for some
users unwilling to use native AspectJ syntax for their aspects, avoiding
the problem.
Relates to #288.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
KimmingLau [Wed, 28 Feb 2024 03:50:59 +0000 (11:50 +0800)]
Improved fix for #285
1. Write SAME_BYTES to cacheMap when woven bytes are null
2. Fix TODO in SimpleCache::getAndInitialize, using Optional to help
indicate cache hit for unwoven class
3. Improve test coverage (cache miss, cache hit for unwoven class)
Relates to #285.
Co-authored-by: Alexander Kriegisch <Alexander@Kriegisch.name> Signed-off-by: KimmingLau <294001791@qq.com> Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix: AllTestsAspectJ171 runs correct NewFeatures suite
While fixing #285, I noticed that *.ajc171.NewFeatures was never
executed as part of the AspectJ test suite, because since 2012 falsely
*.ajc1610.NewFeatures was imported and executed a second time instead.
In addition to an outdated AspetJ weaver library in 'lib', this was one
more factor why the regression bug was never spotted.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Add short description to AJC usage message via
messages_aspectj.properties
- Add longer description to ajc.adoc in the AspectJ Development
Environment Guide
While researching how and what to document for AJJ option
'-xmlConfigured', I needed to find out what happens in case of multiple
XML config files. Result: They are merged. the new test case for the old
1.6.4 release verifies and documents that. It can also serve as an
example for reference in case of user questions.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Extend documentation for Antrun execution to fix javadocs
Also update the internal review ID of the OpenJDK bug I created, because
previously I had created a feature request, which has remained
unanswered. But actually, I think it is rather a regression bug, having
found out that before JDK 16 the behaviour was exactly how the feature
request describes it.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
New abstract class JavaVersionSpecificXMLBasedAjcTestCase
Replaces now obsolete base classes
- XMLBasedAjcTestCaseForJava[n]OrLater,
- XMLBasedAjcTestCaseForJava[n]Only.
The new class is parametrised with minimum and maximum Java version and
hence can replace all the other classes. This does not only apply the
DRY principle, but also makes adding tests for new Java versions less
tedious.
By chance, I also noticed missing sanity tests for Java 12, which I
added as a little drive-by benefit.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
SOURCE_INPUTS, TARGET_INPUTS, COMPLIANCE_INPUTS are now populated in a
'for' loop in a static initialiser block. I.e., adding support for a new
Java version is now as simple as incrementing field JAVA_VERSION_MAX. In
case ECJ raises the minimum supporter compiler source/target version,
field JAVA_VERSION_MIN needs to be incremented. But that should happen
less frequently.
This was done to make the 'AspectJ_JDK_Update' tasks as easy and as
little error-prone as possible.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove most MINOR_*, MINOR_* BCEL class file versions
in favour of Constants.ClassFileVersion.of(int, int). The few ones
retained are used from production code, the vast majority of removed
ones only from test code.
This gets rid of yet another 'AspectJ_JDK_Update' tag. One less place to
check and update with each newly supported Java version. :-)
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The hint is meant to help AspectJ developers identify the places where
there are to-dos for releases supporting new Java versions. This is work
in progress, new tags can be added wherever necessary in the future. But
for now, the most important places should be covered:
- AJC version string
- Test infrastructure (test suites, classes and XML files)
- BCEL class file version MAJOR_*, MINOR_* constants
- AjcTask constants for compiler source, target, release
- LangUtil::is*VMOrGreater methods
- ASM and JDT Core dependency versions
- CI workflow file
- Release notes
The to-do to check the tagged places is also mentioned in RELEASE.md.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Remove obsolete section "Deploying the AspectJ installer to
aspectj.dev", because we are publishing releases on GitHub, attaching
installers to them.
- Add section "Publish documentation on website".
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Use Antrun plugin to eliminate javadoc version number in HTML
This is the one issue that cannot be solved regarding reproducible
builds by setting javadoc options, because that header comment is
hard-coded into the JDK with no option to avoid it. I just created an
OpenJDK issue (internal review ID 9076583, not published yet) for it,
but that does not help us today.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add decade 2020-2029 to copyright years in Checklics
FWIW, I just wanted to know if the tests in module 'build' would still
pass. They did not find copyrights for more recent years, so I added
them here.
But I am still unsure, if we need these tests at all. Obviously, they
were not running during CI builds, i.e. they seem to be non-essential.
But chances are, they were forgotten to be added to the suite.
BTW, running the tests in module 'build' with '-Drun.build.tests=true'
is failing, too, because some old JDK classes looked up there no longer
exist in more recent JDKs.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Avoid "Last updated [timestamp]" footer on each docs page
Set Asciidoctor option 'nofooter' to avoid the annoying timestamps. It
makes updating the website difficult, because always there are "changes"
in each file. Diffing real changes in generated files for the website
before committing becomes difficult. Furthermore, the user does not have
any immediate benefit for most documents, as they change infrequently or
never (e.g. old release notes).
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Globally replace "http:" by "https:" in non-XML files
Maybe, the XML files and Maven wrapper files will follow. First, let us
find out if this breaks the build, maybe some tests are asserting on
"http:". But there, the replacement would also have taken place, so
probably it just works.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Classes and methods named '_' are no longer allowed in ECJ, obviously
also not for old target versions like 1.5. This probably is due to
the added support for unnamed patterns and classes in the latest
upstream JDT Core merge. Therefore, we simply rename '_' to '__'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Uri Simchoni [Mon, 5 Feb 2024 06:34:35 +0000 (08:34 +0200)]
Store only weaved class names in the generatedClasses map
The generatedClasses map contained both keys of woven classes that had
generated classes associated with them, and the keys of the generated
classes themselves. It seems like this map is never consulted for the
generated class key - the generated class is generated from within the
context of woven class loading / retransformation, and thus no transform
event is generated for it by the JVM. Because of that, we do not need to
guard against re-weaving it. Other uses of generatedClasses map are for
full/empty tests, where the woven class key is sufficient. This change
simplifies deletion of a class because we do not have to look for its
associated generated classes.
Uri Simchoni [Mon, 5 Feb 2024 06:29:32 +0000 (08:29 +0200)]
Remove WeavingAdaptor.couldWeave()
WeavingAdaptor.couldWeave() tested two things: whether this specific
class (by its name) should be excluded from weaving, and whether the
class has generated classes associated with it (in which case we avoid
weaving to avoid re-creating those generated classes). However, if the
class has generated classes associated, couldWeave() is not called at
all because of the new wovenWithGeneratedClass() test, so we have
only the name test which is now called directly.
Uri Simchoni [Sun, 4 Feb 2024 10:51:15 +0000 (12:51 +0200)]
Use previous weaving result if classes were generated during weaving
A parallel-capable class loader might load the same class multiple times
in multiple threads, see
https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html.
In this scenario, the JVM instrumentation mechanism invokes the AspectJ
weaver twice on the same class. In simple weaving scenarios, this would
just cause weaving logic to run multiple times and produce the same
result for each thread, but if the weaver is generating new classes,
it is undesirable to generate those classes multiple times.
To avoid this, the generatedClasses map in WeavingAdaptor keeps track of
classes for which inner classes were generated and avoids re-weaving
them. However, before this change, if a class was found in the generated
map, the weaver would return the un-woven bytes, which would cause
AspectJ not to work for some of the threads.
This change returns the woven bytes instead of re-running weaving.
Uri Simchoni [Sun, 4 Feb 2024 10:46:03 +0000 (12:46 +0200)]
Change value of woven class in generatedClasses map
Store the woven class and not a generated (inner) class as value of the
woven class name. This has no effect in this commit, because the value
is not consulted at all, but will be used later on.
Test "same class woven concurrently in parallel-capable classloader"
reproduces #279. Originally taken and modified from:
https://gitlab.com/urisimchoni/aspectj-parallel-issue
Co-authored-by: Uri Simchoni <urisimchoni@gmail.com> Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
while creating a CDS archive. Afterward, the application can be run in
its woven state from the CDS archive even without '-javaagent', because
the byte code was archived in its woven state ("poor man's AJC"). See
https://github.com/eclipse-aspectj/aspectj/issues/277#issuecomment-1931142753
for details.
Fixes #277.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
projects / aspectj.git / log